Building A Proof Of Concept Hardware Implant

You’ve no doubt heard about the “hardware implants” which were supposedly found on some server motherboards, which has led to all sorts of hand-wringing online. There’s no end of debate about the capabilities of such devices, how large they would need to be, and quite frankly, if they even exist to begin with. We’re through the looking-glass now, and there’s understandably a mad rush to learn as much as possible about the threat these types of devices represent.

EEPROM (left) can be edited to enable SMBus access on this card (header to the right)

[Nicolas Oberli] of Kudelski Security wanted to do more than idly speculate, so he decided to come up with a model of how an implanted hardware espionage device could interact with the host system. He was able to do this with off the shelf hardware, meaning anyone who’s so inclined can recreate this “Hardware Implant Playset” in their own home lab for experimentation. Obviously this is not meant to portray a practical attack in terms of the hardware itself, but gives some valuable insight into how such a device might function.

One of the most obvious attack vectors for hardware implants is what’s known as the Baseboard Management Controller (BMC). This is a chip used on modern motherboards to allow for remote control and monitoring of the system’s hardware, and promises to be a ripe target for attackers. There are a few sideband channels which can be used by the BMC chip to talk to other chips. To keep things simple [Nicolas] focused on the older I2C-derived SMBus (rather than the newer and more complex NC-SI), demonstrating what can be done once you have control of that bus.

Only problem was, he didn’t have a motherboard with a BMC to experiment with. After a little research, the answer came in the form of the Intel EXPI9301CTBLK network card, which features the 82574L SMBus chip. This allows for experimenting with a subset of SMBus functionality on any machine with a PCI-E slot. Even better, the card has an SMBus header on the top to plug into. [Nicolas] describes in detail how he enabled the SMBus interface by modifying the card’s EEPROM, which then allowed him to detect it with his HydraBus.

With the hardware setup, the rest of the write-up focuses on what you can do with direct control of SMBus on the network card. [Nicolas] demonstrates not only creating and sending Ethernet packets, but also intercepting an incoming packet. In both cases, a running instance of tcpdump on the host computer fails to see the packets even exist.

He goes on to explain that since SMBus is very similar to I2C and only requires four wires, the techniques shown could easily be moved from the Hydrabus dev board used in the demo, to a small microcontroller like the ATtiny85. But you would still need to find a way to add that microcontroller directly onto the network card without it being obvious to the casual observer.

Our previous coverage of suspected hardware implants sparked considerable discussion, and it looks like no matter what side of the fence you’re on, the debate isn’t going away anytime soon.

43 thoughts on “Building A Proof Of Concept Hardware Implant

    1. Reading his conclusions in his proof of concept the reality is he’s claiming it’s not feasible in the manor bloomberg suggested.

      So while I am sure they are exploring similar systems and have been or decades probably with good results the original story is looking like bunk.

        1. Ring 0 exploit is not needed when you create the sillycones and fabricate the device who needs exploits when you can tamper with the Arm to make the legs do something they should not.

  1. When I first saw the reports of the purported Supermicro “attack” I thought that everybody who was focusing on how difficult it would be to make a tiny embedded microcrontroller interact with the outside world for espionage was missing the point.

    It would make a great trojan horse logic bomb.

    Imagine a small microcontroller sitting on a configuration bus. It’s just listening for the right activation signal to come along, and when it hears that signal it forces a reboot, then configures itself to short all the bus signals to ground, effectively locking up the configuration system and bricking the board.

    Imagine this happening to a large chunk of the servers in your system one sunny afternoon.

    1. If the “economic war” ever heats up, that just may be the case. But as previous years have demonstrated why do all that when the current state of our hardware is so poor.

    2. Exactly, a lot of the people who rush to dismiss it have a strange assumption that the chip is the whole attack. It could just be preparation for another attack, you’ve got to think as creatively as an attacker.

      1. +1
        I didn’t want to write this in the other thread eg odd chips found on motherboards from China as already too many superficial people perturbed (ie pi**ed) I come across as a know it all, you should see what I’m doing now though :D
        We all have egos and some to provoke advancement too, so to the numb nut annonymous fascile nick’s who criticise personally without anything useful get an education puh-lease !
        Best thing you can do is uni level food chemistry and microbiology after any earlier degrees such as to establish intellectual discipline and then look closely through commercial data and peer reviewed journals just Why the published levels of (key brain functional) minerals homeostatic levels are so abysmally low and correlate that with average declining intelligence levels where fructose consumption highest across demographics ;-)

  2. Find the ESD steering diode array on the SMBus, it will be connected to VCC and GND, and each of the data lines.

    Replace it with a micro with the same foot print (and pin out for power and ground).

    Then just pull lines low to modify the data bits.

    Even better would be the pass through ESD steering diode array (high speed type).

    Then you could cut (mask the Gerbers), on the motherboard data lines and have everything on the SMBus pass through your micro.

  3. Given few of any of the chips we use are made in the USA, it is just going to be a matter of time before the “device” in on a popular chip, if it is not there already. Next thing we will be having to decap the chips and follow the leads from the pins or pads to to the die and than check the die against the lithography for the chip. And than hope that there is nothing in the ceramic or plastic under the die and between the pins or pads. IMHO this is just the infantile beginnings of what is to come.

    1. How many people are actually able to decap and decode the silicon anyway. They’d still have to trust the documentation provided for the chip, and hope the extras aren’t hidden somewhere. How do we know that there aren’t some bonus features in chips we’ve been using for years. As long as the chips behave as expected, there would be little reason to pop the top, and try to figure out. Some might, simply to see if the chip is the real-deal, or a cheap knock off, but wouldn’t dig real deep into each circuit on the chip. To save a few pennies, a lot of people would go for the cheapest, even if a sketchy, unknown source, understanding it’s a gamble. But, with data storage push into the ‘Clouds’, rather than kept safe and secure onsite, kind of have to wonder how long there has been a way to to take a peek at what people are storing.

      1. Decoding is a tough nut to crack, but decapping and inspection for clumsy additions is already well within any hobbyist’s reach.

        If you want to look in more detail, the number of hackerspaces with electron microscopes keeps growing. Maybe help your local space acquire and operate one..

    2. Even for US-made chips, how do you know that the NSA didn’t make Intel design a backdoor into every one of its CPUs? The might have, they might not have, but there’s basically no way to prove they haven’t.

      1. I was thinking about that right after I posted the thread, and you are right. The Juniper fiasco a bunch of years ago signs that the NSA was behind it (https://www.wired.com/2015/12/researchers-solve-the-juniper-mystery-and-they-say-its-partially-the-nsas-fault/), as did the Lotus notes encryption fiasco (https://news.ycombinator.com/item?id=5846189) Or for a really interesting read, https://www.atlasobscura.com/articles/a-brief-history-of-the-nsa-attempting-to-insert-backdoors-into-encrypted-data

        And I would not count on the “extra” functions in the chip to be added “crudely”. There is no reason they should look any different than what is already there. It is all made out of the same base components. Hell, for all we know some popular chips now may do “interesting” things with the right undocumented opcodes or combinations thereof. It is like the chip would act and work normally if you use it normally but also have some capabilities or extensions that could be turned on or accessed via software.

    3. Even decapping the chip isn’t much of an option anymore now that 3D ICs are starting to become practical. In which case, you’d have to start having to de-layer the silicon as well which with <10 um lithographies would be impossible for anyone except the most well-funded experts to do without damaging the chip.

  4. Oddly enough SuperMicro denied that ever happened. It surfaced in a response in the Register not too long ago.

    Oddly enough every time I need to build a kernel for Slackware-11.0 as running on my Dell Dimension system, I note that the kernel 2.4.33.3 has callouts for the IPMI functions, naturally since I Think that the system does not have one, I turn that off. And this is spooky.

    One more thing, Tom were you at the Hack A Day-NYC meet for the Thursday before the Maker Faire events? I was, and gave Brian a really bad feeling about something. (And not because of the fuzzy diplomats.)

    1. The bigger issue is that this kind of device wouldn’t be able to operate infrastructure of the targets successfully. Not only that but all those involved are clear that it simply hasn’t happened.

      It just seems unlikely to me to be honest.

      Given that there is no proof to corroborate the reality is the article served no purpose other than to torpedo Super Micro.

      There you have your motivation for the report.

      On the balance I think it’s far more likely the report if false and intended to damage Super Micro than true and being covered up by conspiracy.

      1. This is one thing that bothers me…
        There should be “some” proof. Somewhere. Anywhere. That this has actually happened.

        I read the Blomberg article and all I got out of it was fud.
        Yeah, it would suck if that happened. But show me it actually happened.

        I actually want some backlash to hit Blomberg for this if it turns out to be false, because it literally torpedoed their shares and supply chain manipulation is something that you can only go so far to prevent.
        At some point you need to trust that the chip youre buying is actually what you ordered.

        Would supermicro be able to sue?

  5. “the 82574L SMBus chip”

    The 82574L is a PCIe gigabit Ethernet “LOM” (Lan On Motherboard) adapter. I put a couple in a design from about a decade back, which is how I remembered the number.

    Whilst it does have an SMBus for implementing security backdoors, it would be a stretch to describe as “the 82574L SMBus chip.”

    BTW, I did not connect that interface on my board.

  6. I would implement a JTAG interface with a receiver sensitive to a certain frequency of microwaves. Use the RF to feed data to the JTAG and gain control that way. Most of the logic will be at the transmitter side, and can use a trace as an antenna.

  7. And this is why Defense-in-Depth is so important. Sure the BMC can access data and send/receive packets without the OS being aware, but a network firewall would definitely see it. Such an attack could be mitigated through proper network segmentation and proper vigilance. Although sensitive data should never be handled in a way that an external system would know where it is. Encrypt everything and only use encryption systems that properly implement ASLR, add random padding before and after, and overwrite sensitive information in memory once done using it and before freeing that chunk of memory.

    Really, its a case of why the first rule of InfoSec is “Trust nothing”, and particularly, “never trust a system to secure itself”. Always be suspicious of everything a system does and always assume that the system has already been compromised.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.