7

Supposing there is private/secret data on a machine (i.e a x86 arch) the most reasonable thing to me would be to encrypt this data, so to protect it.

I understand that the purpose of secured,safe,untampered & secret data is only served when the key/passphrase is kept safe. Also I know that, as there is software necessary for the de-/encryption I have to some degree trust this software (i.e. need to trust linux kernel, gnu software, LUKS framework for linux-based disk encryption. etc.). Being mostly open source an autid of the software mentioned above might seem at least possible.

Still what is with the PC BIOS software? The most common thing is that it is a proprietary (closed source) peace of code. Theoretically and I think practically there is a good change that some malware in the PC BIOS is setting up a keylogger --> passphare is captured --> data safety is nil. (right?)

Also I have just started hearing (with some shock) about the x86 feature of the Secured Management Mode SMM which it seems can be exploited to work in a bluepill fashion with some rootkit. Also again this could do arbitrary mischief and of course seems to break my encryption purpose by logging the keys.

Even worse I wonder about the optionrom thing in the BIOS. To what I understand the PC Bios would load and execute code from a device (like a network card chip) and execute(!!!) it. So at worst a chinese/american/german (name any other untrusted country/organisation of your choice) could manifacture devices as some kind of computer virus (using this optionrom feature).

With all that I really wonder about the value of disk encryption if there is so much unkown and danger before the (maybe trusted - because open source) linux kernel runs.

Honestly if I was to create a rootkit I would also seek to put(or anchor) it somewhere in the TPM, PCBIOS, optionroms, kernel etc. Only for the kernel there is some trust.

I would be very happy to hear your thoughts.

Good questions like:

give insight mostly about how to keep PC BIOS free/save from malware? etc, but my paranoia is also to not know what the BIOS does (closed source) in the first place.

some Update

About the threat from changing/tampering the BIOS code I wonder if the linuxBIOS or coreboot(www.coreboot.org) projects do not show both the possibility to modify bios by (also malware) own code and the option to do this on purpose for security reasons. After all a selfwritten or at second best open source BIOS seems doable as the things BIOS do are not "the world" (just some initialization work). So I still fear that -given the hardware documentation or reverse engineering- it is doable to create a malware bios and deploy it (see flashrom.org tool)

Update: Another source showing the problem of proprietary firmware/hardware is http://arstechnica.com/security/2015/02/how-omnipotent-hackers-tied-to-the-nsa-hid-for-14-years-and-were-found-at-last/

Community
  • 1
humanityANDpeace
  • 1,432
  • 1
  • 12
  • 24
  • Even if changing tampering BIOS would be difficult. What about the optionrom which might trigger "untrusted code" to be executed from bios? – humanityANDpeace Oct 01 '12 at 09:46

2 Answers2

4

Your question essentially boils down to risk management. The simplest way to analyse a particular risk is to see where it falls in terms of the following three categories:

  • Probability - What's the chance that this risk will become a problem?
  • Impact - If a problem occurs due to this risk, how much of a problem is it?
  • Cost - How much will it cost to reduce this risk probability or impact to an acceptable level?

Note that cost is not just monetary - it includes time, effort, convenience, etc.

Most risks cannot ever be fully mitigated. The goal is to find an acceptable balance between probability, impact and cost. Now let's look specifically at your issue:

Probability
In reality, the probability of an attacker installing fake BIOS and TPM chips is tiny. Anecdotally, I can't quote a single case in the history of infosec where a real attacker has done this. As far as I'm aware, it's only ever been demonstrated in lab conditions. Your real risk is having a hardware keylogger device installed between the keyboard and USB or PS/2 port. How likely is it that an attacker will have physical access? The attacker has a risk model too - are they likely to risk of being caught for the sake of what you're protecting? Be realistic here - are you protecting a photo sharing web service used by 20 people, or a bank with tens of thousands of customers? I'd argue that the probability of BIOS / TPM attacks is minuscule, but the probability of hardware keyloggers is low to medium, depending on your storage and access circumstances.

Impact
What do you stand to lose? What's the absolute maximum fiscal loss, including projected sales losses due to loss of confidence? How much are you likely to have to pay in overtime when your staff are cleaning up after a breach? Might you be sued or fined for breach of data protection laws, such as DPA 1998? From your projected loss model, how much has it cost other companies in similar circumstances? Remember that your loss risk should be relative to business operations as a whole. Think in terms of assets - what do you consider to be important? Is it your source code? Is it your financial records? Your product design documents? What at-risk information are you most concerned about losing? I'd guess you're looking at high impact here, since keyloggers would allow an attacker to gain almost uninhibited access to your network.

Cost
How much will it cost you to bring the risk or impact down to an acceptable level? Note that mitigation methods may not have to be implemented across every machine. Can proper access controls and auditing be used? Is your physical security strong enough?

A few potential ways to reduce risk of tampering:

  • Don't give staff access to areas they don't need to be! If you use RFID key fobs for keyless entry, don't allow the CEO's PA to use theirs to get into the server room.
  • Locks on computer cases, to prevent internal tampering.
  • Place computer towers inside locked cabinets, to make it difficult to interfere with keyboard cables.
  • Remove or disable USB slots on servers and computers that don't need them.
  • Laptops kept in a locked cabinet when not in use.
  • Use Kensington locks on laptops and other sensitive equipment.
  • Use security tape to seal servers and other high-risk systems.
  • Use high quality locks. This one scares me more than anything else - I recently learnt to pick them and the cheap ones are way too easy to break. A decent Yale lock will keep an skilled intruder busy for 3-4 minutes. Cheap non-brand ones can take less than 15 seconds. Maglocks alone aren't sufficient, and can be defeated with a home-made electromagnet, a small circuit, and a laptop battery.
  • Have your alarms and CCTV systems tested frequently, and prioritise the placement of security sensors (e.g. PIRs, cameras, magnetic entry sensors, etc) in high risk areas.

All in all, you could probably bring this risk down to an acceptable level by implementing 4 or 5 of those ideas.

Polynomial
  • 133,763
  • 43
  • 302
  • 380
  • 2
    Regarding key loggers at banks, the big one was the Sumitomo bank attack, that very nearly succeeded: http://news.bbc.co.uk/1/hi/uk/7909595.stm – Rory Alsop Oct 01 '12 at 08:27
  • I really appreciate the elaborate explenations and information regarding the aspects of risk management. This has been really done very well, thank you. Still my doubts and concerns are that encryption is supposed to promote some level of safety. Indeed I fear that all safety measures taken (kernel safety) would mean little when an attacker can use ways (before the kernel acts) hence bios. I am not conviced by the "only in lab conditions" remark. Arguably such a bios tamper attack seems hard to implement. But in place it is a remote and not a local attack. Maybe worth the effort for some? – humanityANDpeace Oct 01 '12 at 09:21
  • @humanityANDpeace I have some experience with hardware tampering and reverse engineering, and can tell you that desoldering modern chips is a _nightmare_ if it's anything but a DIP or SOIC case, especially on multi-layer boards. I have to get my SOIC desoldering done professionally, with expensive desoldering equipment. BIOS chips are usually [TQFP](http://en.wikipedia.org/wiki/TQFP) cases, and TPMs are often [BGA](http://en.wikipedia.org/wiki/Ball_grid_array), which are almost impossible to desolder without destroying the pads or board, even with the proper equipment in a lab. – Polynomial Oct 01 '12 at 09:29
  • @Polynomial I absolutely trust your opinion in this point of changing any hardware / disecting chips. Might there nonetheless be enough "room" to modify BIOS code by simply flashing the code stored in the BIOS ROM? Additionally we need not go so far. If the source of the BIOS is not open, how can we be sure there is not some kind of backdoor in the BIOS right from the manufacture. This is mere conjecture and yes , sorry paranoia, but conceivable, right? If I was a reputable TLA I would make this my backdoor to IT hardware in some way. malware in user or kernel space is nothing compared :) – humanityANDpeace Oct 01 '12 at 09:38
  • @humanityANDpeace The BIOS standard requires them to implement a checksum that allows only authorised vendor code to be flashed to it. This is usually implemented by a custom hash function in the chip's inbuilt ROM, which cannot be altered. It's possible to de-cap a BIOS chip and use an electron microscope to reverse engineer the algorithm and key constant, but the equipment is expensive and the expertise required is uncommon. The more modern chips use public key cryptography to authenticate the update payloads, so even decapping is useless. – Polynomial Oct 01 '12 at 09:45
  • @humanityANDpeace Note that modern boards have DualBIOS, which means that even if you found a way to alter the signature checking code on the primary BIOS chip, the secondary BIOS chip will recognise the integrity failure (a checksum is exchanged at boot) and restore the original image. It's exceedingly difficult to break the integrity of a modern BIOS. – Polynomial Oct 01 '12 at 09:48
  • @Polynomial Thank you for all the information you so readily know and can share. great! Reading about projects like "coreboot" provoked the false impression that bios can be in some way flashed. At least I was not yet aware of all the measures taken to prevent this. In a way this is a releave to the extent that malware will less likely (or impossibly) get on the BIOS. This leaves of course the problem with the untrusted original code in the BIOS? – humanityANDpeace Oct 01 '12 at 09:58
  • @humanityANDpeace A BIOS is a [microcontroller](http://en.wikipedia.org/wiki/Microcontroller), so it can indeed be exploited via code execution vulnerabilities. However, these issues are very rare and always require the attacker to have kernel-mode code execution privileges on the machine. At that point, your risk model doesn't matter, because they've *already* compromised the box entirely. The network card one that you mentioned before attacked the firmware of a network card, and not the system BIOS, allowing the attacker to steal network frames, but not access the system. – Polynomial Oct 01 '12 at 10:13
1

I'm going to come right out and say that you are right in that your BIOS could be compromised, in fact your entire computer could be designed with the expressed purpose of siphoning up every single piece of information on it. Additionally there's absolutely no way you could ever be sure otherwise. There's no tool set or method that will ever give you peace of mind here.

The fact is that it's extremely unlikely that even if your hardware was able to be taken over that someone with that capability would want to do it to you. Subjecting a bios and making it work with software based threats is difficult, very difficult in fact, and unnecessary as pure software-based malware that uses unpatched vulnerabilities in OS or loaded software will do just as well and is much easier.

The chances are that your biggest threat is from data loss due to theft or misplacement of your device, and that's what encryption is there to protect you against. It won't protect your data from being siphoned off by malware while the machine is on and the data unencrypted, but it will if you leave your laptop in a taxi.

GdD
  • 17,321
  • 2
  • 41
  • 63
  • I thank you for your opinion. The first paragraphed seems to confirm my worries regarding the topic. Anyhow drawing some insights also from the excellent answer of Polynomial, the thing maybe is: Not to be 100% sure, but to be 10% surer. If one would have a open source BIOS as I understand this would help. – humanityANDpeace Oct 01 '12 at 09:42
  • "Data loss". Sometimes not having the data anymore is bad. Sometimes the fact that another person has the data is even worse. Backups will mitigate the changes of data loss due to misplacement or theft of the device. The SMM, BIOS, rootkit thing is worse to me as the data is actually not even lost, but given to somebody – humanityANDpeace Oct 01 '12 at 09:43
  • Not really @humanityANDpeace, if the hardware is designed to collect and report on information an open-source bios isn't going to help much. – GdD Oct 01 '12 at 09:44
  • thank you. So you consider hardware a viable way to espionage, etc? It makes me wonder about: if hardware is to this extend "IT-security-dangerous", where do TLAs and other organisations buy their fancy equipment? – humanityANDpeace Oct 01 '12 at 09:52
  • Viable yes, worthwhile no from an espionage perspective, at least on PC hardware. It's a great deal of risk for the manufacturer for one as if it was ever found out they'd lose their business, and the logistics are difficult. Network equipment is a different story, high-end routers concentrate a great deal of data and are have a better risk-reward proposition for espionage. – GdD Oct 01 '12 at 09:58
  • "ever found out". Despite the picture that Polynomial depict of investigating on the hardware itself (opening chips etc etc). Something which is rather impossible for the "average tin foil hat affactionato" I can really not estimate the risk? And even if the manufacturer would commit some error and it would be discovered, it would merely drain on his reputation (if this at all is important). One of the few ways I would conveive possible for discovering "manufacturar deploid rootkit" is when it is used (i.e. by sniffing network traffic of such a PC for unusualities).A risk mitigatable – humanityANDpeace Oct 01 '12 at 10:07