5 ms·
5. When a server was installed and switched on, the microchip altered the operating system’s core so it could accept modifications. The chip
by newsDerp 8y ago
5. When a server was installed and
switched on, the microchip altered
the operating system’s core so it
could accept modifications. The chip
could also contact computers controlled
by the attackers in search of further
instructions and code.
So, in typical vulnerability/payload/exploit fashion, the board's bus is vulnerable by default, because the chip pierces all the usual lines of defense protecting against network and operator I/O. It carries a payload intended to target very common features used everywhere commodity servers are used, one that likely listens for DMA traffic on the bus, and alters the signal stream, by escaping upon the occurrence of a magic sequence, and inserting its own signal, before resuming the authentic stream in flight.
The payload could be pretty small, since the server boards are likely using OS packages that match the chipset. This limits the software to a small set of well known targets, Linux, Windows, Apple. Target their kernels, and you only have to snip out a small chunk of bytes, and splice your own pre-defined package in. Splice in a miniature runtime, that operates a turing complete set of operations, and open up a listener that waits for network access, and now, your payload can enable arbitrary code execution, irrespective of permissions.
Now, to exploit, the payload needs to time the opportunity to splice itself onto the disk correctly. If certain well-known chunks of code will always exist in each given operating system, then with every disk access event one just needs to wait for the inevitable moment those magic system-specific bytes travel over the bus, in order to replace the known bytes with the poisoned modification. Events might target when the bytes are originally installed with the OS, or every time the OS reads those known bytes back into live memory, from any source.
The total payload package could probably fit inside a couple of megabytes, pack on a few more for the "listen & splice" part of the attack to round out the entire mass, and all we know how much data an SD card can fit into say... five grains of rice?
- RL_Quine 8y agoIt's not particularly magical, there's consumer chips around which are not a whole lot bigger (though obviously in a more standard package). You don't get a lot of resources, but you don't really need it if all the other frameworks are in place in other software. If this sort of thing is something you can buy on Mouser for a few cents, the espionage grade material is probably an order or magnitude more higher quality. https://www.microchip.com/wwwproducts/en/ATtiny4 https://www.microchip.com/wwwproducts/en/ATtiny4 For scale, this alone is about the size of a large SMD capacitor and would basically be lost in most designs today.
- newsDerp 8y agoFigure it's custom silicon, given the nature of the story, and "magic" in the sense of "magic number programming" to time the attack. https://en.wikipedia.org/wiki/Magic_number_%28programming%29 https://en.wikipedia.org/wiki/Magic_number_%28programming%29 For example, looking for ELF or Portable Executable headers, as a crude estimate to determine attack opportunities. In this case, the magic numbers would probably be more selective and sophisticated, but still have an aspect of hard-coded values, since we're talking custom silicon.
- Sidnicious 8y agoFor another example, I have a couple of these which are a bit bigger but have an ARM SoC and onboard Bluetooth (with antenna): https://www.digikey.com/en/product-highlight/t/taiyo-yuden/eyshsnzwz-bluetooth-module https://www.digikey.com/en/product-highlight/t/taiyo-yuden/e...
- RL_Quine 8y agoThat's a crazy module, I had no idea anything of that scale existed for Bluetooth radios.
- pjc50 8y agoThis sounds like speculation. I'm quite capable of coming up with my own unfounded speculation, but there is a real report out there with the actual details in that really needs to be made public, legally or otherwise. There ought to be a CVE about this. Where is it?
- baybal2 8y agoThey didn't do anything to the CPU, what they did is the modchipped the line from EEPROM and the board management controller. They probably found it out when they were repeatedly tried to reflash the BMC flash, and saw that checksums did not match.
- ThePhysicist 8y agoThat would make a lot of sense and would give the attacker a way to interface with all of the other hardware (network, disk etc.). Do you have a source for this information?
- baybal2 8y agoI looked up supermicro blade motherboards, and saw that the chip was right near the IPMI chip's line to spi flash. And prior to that, there were already persistent rumors in the Chinese interney of certain Chinese mobos sending "weird garbage on ICMP," and "BMCs that somehow boot and work with their flash memory soldered off" Remembering that, I might even suggest that this is not a modchip that does something with signal on the go, but just a very tiny flash chip that has the modded firmware. Going further from that, to pack, say, 16 mB on a sandgrain sized chip, the densities need to be like that of best flash chips out there, which also means that they have access to last gen flash fab.
- pjc50 8y agoA photo of such a motherboard with a big arrow pointed at the additional chip would be a useful addition to this discussion.
- baybal2 8y agoSupermicro 6128 aka x10 series microblade. Those were very popular among Chinese DC operators during Broadwel era. https://www.itcreations.com/dist/landing/i/MBI-6128R-T2/MBI-6128R-T2-5.png https://www.itcreations.com/dist/landing/i/MBI-6128R-T2/MBI-... Left of the sata connector. An empty space with 8 pads for an smt eeprom or flash. It is occupied by the thingy on bugged boards. Right below is the Aspeed chip - the BMC
- ThePhysicist 8y agoHm, but DMA messages get distributed over a parallel bus and this chip seems to employ a serial interface, so I would assume that it's not directly connected to anything that requires high throughput (i.e. memory, disk and peripheral access).