I think my Coreboot/Pureboot may have been hacked. Just rebooted today, and both my key and phone TOTP were bad. I haven’t installed any kernel level updates (which can change the boot selection menu), and I definitely havent installed any firmware updates.
I have had the occasional Purism key go bad but my phone kept the 6 digit code correctly. In this case both were bad. I am treating this as a hack, and wiping everything.
Obviously I need to wipe the firmware too. Is there a hard reset button on the motherboard? A hacked SPI might be resistant to a simple USB reinstall.
This is troubling. I run Qubes. Lately I have left my random browsing DVMs on overnight. Not browsing naughty pages or anything, but I am all over the place for tech info of various kinds.
I REALLY hope that’s the case. I had noticed there was maybe already a 15sec offset between my phone and pureboot/heads. Last good boot was a weeks ago. I refreshed the key a few times over the course of a minute, and never got a match.
If you did get hacked then PureBoot is working as designed and alerted you to it. There could be other explanations for a false positive though.
It could possibly be that someone tampered/reset the TPM or modified the boot flash, but I believe to do either one within Qubes would require access to dom0. I don’t believe a DVM has access to either device, although I could be wrong.
HOTP between Librem Key and the laptop could also alert if the incremental counter in /boot was reset or somehow the counters between the Librem Key and the laptop got too far out of sync (this is one reason why you can only use a single Librem Key with a particular laptop in PureBoot).
If you truly believe it was tampered with, and that this isn’t a false positive caused by some other error, depending on your risk tolerance, then yes, a complete reflash of PureBoot and a re-enrollment of your Librem Key would be the way to go, along with a “paranoid mode” backup/restore of Qubes (special option to the command-line version of the Qubes backup tool).
Yes, VMs in Qubes aren’t supposed to have access. However, there is always the potential for a VM escape bug in Xen hypervisor, though typically low. From there the malware would’ve needed the ability to modify the boot flash, which is yet another significant hurdle, but again not impossible.
What troubles me the most is that both my phone and key were showing failure, something which I’ve never had before. Perhaps it was the internal TPM clock or something. Again, super duper hope that’s the case, caz either that or, 2) I was hacked with a pretty top level, qubes targeting, Coreboot+heads compliant piece of malware or 3) I was physically compromised, In which case Im totally pwned even if I flash the SPI, because anyone that went to all that trouble would install a physical keylogger not dependent on firmware.
At any rate, can anyone confirm whether there is a physical reset button or clear mos jumper pins on the mobo, and where I mighy find it? I also emailed tech support.
but to reset what exactly? There is a reset button on both the L13 and L15, but it’s just a hard reset (ie, cuts power to both the EC and CPU), it doesn’t clear anything. There is no CMOS data to clear.
System clock being out of sync w/ phone clock would explain the TOTP error. The HOTP Librem Key error could be explained if you booted too many times w/o Librem Key inserted, such that its incrementing counter got out of sync.
Other explanations, hopefully you would have noticed, such as if you updated PureBoot to a new version, or changed one of the settings within PureBoot that requires a reflash (such as changing the GPG keyring in PureBoot) or resetting HOTP/TOTP codes.
Hmm, I guess I thought that there was usually a factory reset type button that reloads factory firmware from some storage chip.
But yeah, now that I think about it, CMOS is for BIOS settings, not the actual firmware.
So my best bet (in the absence of a SPI connector), is to use a USB and flash that way from Pureboot? I would think there’s the potential that an already compromised firmware might just make it look like it flashed, while still keeping the malicious bits. Is that a possibility, or am I misunderstanding how flash ROM works here?
flashing (w/erase settings option) via Pureboot is certainly sufficient. The option to flash the SPI chip directly via an external programmer certainly exists, but IMO is overkill.
while theoretically possible, it’s highly unlikely that Pureboot would be lying to you about actually reflashing. Someone capable of that would have avoided detection in the first place.
After giving it some more thought, I’m pretty sure that this is a sync issue, and unlikely a hack. I remember now, the last time I rebooted, my key and phone were both off, and I had to refresh quite a few times until I finally found a match.
Altho… hw clock --show and date are synced. I also checked all the files in /boot for last modified, and they were all from 3 weeks ago when I updated to a new kernel point release. Of course, a good hacker would just change the last modified times and clear the history.
I also think now, that it’s highly unlikely that the Pureboot flash itself was hacked. Last I checked you couldn’t flash the ROM from Qubes anyways. If there was a hacker, it seems quite unlikely that they would’ve found both a Xen VM escape, and then also developed a way to flash Pureboot ROM from Qubes dom0. Seems silly to do so when you’re up against the zero day clock, and so few people use Pureboot.
Regardless, I’m going to take the safe route and reinstall Qubes. Maybe I’ll even still flash the ROM just for fun.
i believe the best practice when you notice something you can’t explain is to just start from the higher levels down (not the other way around) … i.e clean install the OS is the FIRST thing you do after you’ve checked some files in the / hierarchy itself … if after you clean install a STABLE OS (do not apply updates yet) you notice the same problems occurring at the lower-levels THEN and ONLY then you escalate your paranoia level
My problem originates at the /boot level. That would be a pretty fundamental compromise. Depending on risk tolerance, certain actions are reasonable/unreasonable.
Im about 98% sure that it’s just a sync issue between the TOTP and my key and phone. However my risk tolerance for this machine doesn’t allow for that 2% possibility of being pwned. I have system backups that can get me going again fairly quickly.
Im about 99.5% sure that I don’t need to flash ROM. But Im already going to all this trouble, so I might as well.
Hopefully this will all be over by late tonight, lol
Alright so at this point I reflashed the BIOS back to Coreboot. Im slightly annoyed that there is no option for me to flash at all now, without going through PureOS, which I otherwise have no reason to do. I have the ROM image on a usb stick. Is there any reason I can’t flash to Pureboot from Coreboot directly??
why did you do that? You could have simply reflashed PureBoot, you gained nothing by flashing coreboot first.
You can of course flash Pureboot using Purism’s coreboot utility script. You can’t do that from Qubes, because Qubes’ built-in flashrom is too old, and trying to compile a newer one in dom0 is more of a hassle than its worth. So just boot a PureOS live USB and flash from there.
Ok so I downloaded pureos-9.0-gnome-live_20200806-amd64.hybrid.iso
But I’m not seeing a signature file, and I don’t know which PGP pubkey Purism uses to sign binaries. Does Purism sign binaries? Obviously I can check the sha, which I did and matches, but hypothetically if the server gets hacked or I get MITM an attacker would just put their own sha256 that matches their malicious version of the OS.
I see an old issue for this on the forums. Really should have a well publicized pubkey that all binaries are signed with.
what is the name of the package for a CLI install of GtkHash (this is the name to look for in the software-center) ?
oh and by the way - why isn’t a GUI-front-end included out-of-the-box in the default PureOS Amber (Stable) of a tool to verify bootable .iso files. i get it that you can do it from the CLI but that’s not the point of PureOS now is it ?
The command sha256sum is in the coreutils package - but I would have thought that is already installed.
The command shasum is in the perl package.
Who can say? I always verify my .iso downloads from the shell. That is in part because the relevant command can verify the hash against the downloaded known values, not just calculate the hash - but maybe the GUI version can do that too.
FWIW both coreboot and flashrom are reproducible builds. That means you can, at your discretion, rebuild both coreboot and flashrom from source and have byte for byte identical binaries as the ones we deliver. This can allow you to inspect the source code for errors (again, at your discretion) and be assured that the source code actually does produce the binary you’re using.
Reproducible builds further reduce the surface area for tampering.
