11

I understand that CPU silicon (for example) is scrutinized for backdoors but there are other aspects of a computer system that may "leak data" to the outside world unbeknownst to the owner regardless of driver or OS configuration.

I'm looking for advice on how to protect myself from hardware-based exploits such as CPU-silicon backdoors, Bluetooth or wifi hardware-based vulnerabilities, or even hacks in BIOS of the motherboard or any connected devices.

Some examples of a hardware hack could include

  • A hard drive that has modified firmware (e.g. IRATEMONK)
  • Setting a jumper pin to enable discreet functionality
  • A undocumented keyboard sequence (other than control-alt-delete) that bypasses a BIOS password

  • A bluetooth receiver that "wakes up" when a magic packet is seen

  • An integrated camera and microphone that records data to NVRAM when conditions apply

  • A GPS receiver that wakes up when at a certain location.

Question

What guidelines should I follow to purchase hardware (computers, networking equipment, power supplies, etc) that is secure at a hardware & firmware perspective? (before the OS level)

The answers I'm looking for could be either legal/contractual, or technical in nature.

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • Related: [OWASP Top 10 style security guide for implementation in hardware devices](http://security.stackexchange.com/q/24166/396) – makerofthings7 Dec 02 '12 at 15:32

3 Answers3

8

Your questions is about preventing the inclusion of hardware that contains intentionaly created backdoors, but I suggest that in addition to prevention you consider detection, mitigation, and response.

There are different levels of sophistication in creating and detecting hardware backdoors. So, in part you need to understand your own level of expertise in detecting intentional hardware vulnerabilities. Doing design analysis is a good place to start. The general architecture should make sense and be familiar. A true from scratch hardware design is quite rare. Therefore look for the components of the design that deviate from previous revisions and other design for similar components.

Perform your own hardware security testing. Using your system security design create tests for the given piece of hardware and attempt to determine whether it passes or fails your security model for the intended system.

Mitigation of hardware security issues include strategies such as treating as much hardware as possible as untrusted and only investing trust in hardware that is critical to the secure operating of your system.

Only do business with people you trust in jurisdictions where harms done by companies and individuals may be fairly adjudicated.

this.josh
  • 8,843
  • 2
  • 29
  • 51
  • 6
    *"Only do business with people you trust in jurisdictions where harms done by companies and individuals may be fairly adjudicated."* - Great insight! *"Mitigation of hardware security issues include ..."* - Excellent advice! I especially like the last 2 sentences of your answer. (Personally, I would focus on those last 2 sentences over doing security review/testing of hardware, as it'll probably be very hard to detect hardware backdoors through review/testing -- whereas those last two sentences are generally applicable.) – D.W. Dec 03 '12 at 09:09
1

I had exactly this problem when bringing in kit for a client some years ago. At the time, our assumption was that anything super nasty would:

  1. need power
  2. there would be a reasonable probability that only a small percentage of devices would be affected and not all of them
  3. An expectation that goods-in software based testing would not always pick up a hardware attack.

It's really worth drawing up a goods-in testing plan to meet your threat model even if it is just to get an in-house engineer to pop the lid and have a look to see if anything looked different from the standard issue kit or indeed there is any sign of a power source or link to an onboard USB, disk power. Try and buy "standard issue" kit to help this strategy.

Now, I understand that it won't protect against the very sophisticated attacks but unless your threat model is that extreme then its hard to justify a business case to spend the effort checking down at the chip level.

Some places impose quarantine on kit (and software) for a month or so before usage. This was to help protect against 0 day hardware attacks (someone else might notice first).

There are software based checks that may work depending on the kit you are buying. e.g. if it is server kit - then get the management card in the server to report on all the hardware found and add this to your CMDB and use scripting/reporting to see oddball configurations.

Callum Wilson
  • 2,533
  • 10
  • 15
-2

For the hardware to function correctly (correctly as in preforming what ever it was designed to do even if its malicious thing ) it needs a driver.

A hard disk for example cant preform something on its own , There must to be an order issued to the device via driver ,so even the "physical" security can be achieved through OS level By having signed and authenticated drivers only (Windows usually gives you a warning if your installing a driver from unknown source ).

HSN
  • 1,188
  • 12
  • 23
  • 1
    Thats not quite accurate. You can have signed drivers interact with untrusted hardware, as the driver has no way to guarantee authenticity or security, unless you have proof, which is what I think @makerofthings7 is looking for. – Steve Dec 02 '12 at 10:12
  • I clarified and added some examples – makerofthings7 Dec 02 '12 at 13:52