What's Happening In Security #13
- 3 minsRapid-fire:
- North Korean IT worker scam works again on a US based cybersecurity firm
- Financial institution in the Middle East was DDoSed for 6 days
Millions of Computers Compromised by Secure Boot Issue
Many machines use a process called “Secure Boot” to ensure that software used while the machine boots up is trusted by the Original Equipment Manufacturer (OEM). This ensures that malware can’t take control of the computer during the boot process. The Unified Extensible Firmware Interface firmware (UEFI) contains a database of trusted keys which it uses to check the firmware, bootloader, and other important pieces of software to ensure they haven’t been tampered with. If a discrepancy is found, the firmware halts the processes!
If a malicious party were able to insert malware at such a low level of the computer’s processes they would be able to wreak havoc and likely go undetected while doing so. Residing in this area of the computer, the malware would be able to influence important software like the operating system which means it would easily be able to hide itself. In 2011 a malware called Mebromi did just that. In response to this, security architects came up with Secure Boot. Through the use of public key cryptography, we would be able to set up a chain of trust and sleep better as a result.
But what if someone working at a device manufacturing company accidentally published the private portion of their company’s platform key to github…
Essentially for machines running certain versions of the UEFI firmware, Secure Boot no longer matters. If any software can be signed using the correct key, verification doesn’t mean much.
Unfortunately this wasn’t the end. An additional 21 platform keys were found in various Certificates containing keys labeled “DO NOT TRUST” made their way into production.
How did this happen?
- Security is not always the number one priority. Talking about their own experiences at their workplace, a poster on Bruce Schneier’s blog said, “Where marketing staff call the shots, quality control is impossible”
- Sometimes company’s can be pressured to hand out keys earlier than they’d want for testing purposes, and sometimes these keys end up being irresponsibly used in production
- Poor key management
- There are alternatives to Secure Boot that would involve embedding the public key portion of they key directly into the hardware which could remove some of these issues
How do we do better?
The last point I raised about alternative techniques to Secure Boot is likely not the best solution. I believe that new technology isn’t the solution, because Secure Boot itself isn’t necessarily the issue here. It may have some flaws, but that’s not what brought us to this place. The mistakes that compromised these computers were human ones.
My takeaways from this are:
- Limit access to important credentials. Whether it’s passwords or keys, limit their distribution as much as possible so there are fewer opportunities for a leak a la committing to github
- Have processes in place to ensure that critical information is kept track of in code and that it is never shipped
- Refresh your keys relatively frequently. If your credentials are leaked
While creating 100% foolproof solutions is impossible, staying vigilant and proactive can help us minimize risks and protect our systems effectively.
Here are some resources if you want to go further into the details and get some more opinions on the matter:
- Shout out to Dave who has a great video explaining the issue
- DarkReading
- The Original Report from Binarly
- ArsTechnica
Siddhantha Bose
Living, learning, and meeting people along the way