So, I just watched Jacob Applebaum’s presentation at CCC (I’m catching up) and frankly, I haven’t seen a more shameful display of zealotry and laziness in quite some time. That’s not security expertise – that’s mostly pitching policy using iffy examples, which just undermines the political arguments. Open source does not magically make things more secure – never has, never will. Just because you can ‘inspect’ code doesn’t magically fix other problems or prevent that code from being full of holes.
If you want to argue this with me, Rule #1 is ‘bring technical facts and knowledge.’ If you can’t do extensive modifications of a PC BIOS without breaking it and/or write a device driver, go get more knowledge. There’s a whole Internet out there to learn from. And unlike so many of the supposed ‘security experts’ I actually bothered to take the time to learn how the PC BIOS works back in the 90′s, instead of pulling conspiracy theories out of my butt that can and have been completely disproved by basic forensic analysis.
This is how the BIOS works. No, you don’t get to argue this, unless you want to completely undermine every technical argument ever made. Check the link – this is an NIST paper. The fact that supposed ‘security researchers’ were incapable of reading this paper is beyond shameful. This is basic, basic research people!
That’s the reason this is linked here. This is one of the authoritative papers on BIOS process security post-UEFI, period. If you aren’t intimately familiar with it, you aren’t qualified to make any statements whatsoever regarding BIOS ‘infections’ or security or anything related.
Doubly so if you failed to understand the most basic of forensic processes. In the case of a contaminated BIOS, that’s on non-volatile storage. It is not some magical part where you can hide 50MB of payload. On a modern system, it’s an 8 pin SPI flash smaller than your pinky fingernail. If there is any suspected contamination, you cut power and you connect an SPI reader you bought for $10 off eBay to get a clean dump. It’s that bloody simple, and always has been. The only thing that’s changed is the size of the part and the reader.
You have also failed utterly at basic PC hardware period if you think such things can only exist in the BIOS; hell, you failed utterly at basic security forensics. Somebody like me should not be able to call you out on that lack of knowledge – really, this is incredibly basic stuff. MBR viruses and such are not new, and they’ve been a favored vector for lots of nastiness because it’s fairly hard to catch. That’s why any modern BIOS has a switch to detect any changes to the disk MBR. (Whoever removed that from UEFI behaviors should be beaten with the cluebat.)
We’ve already been over, at great length, why cross-platform BIOS infection claims are utter BS. I’m not going to waste time doing that again, because it’s an absolute fact, and I don’t care if people who couldn’t take the time to read 800-147 are unable to accept facts. However, I said I was going to talk TAO and why the slides say BIOS and more importantly, why it works.
For this discussion, I’m going to be working from alleged “FEEDTROUGH” and walk you through the actual process of how such a system actually works. If you don’t like technical facts dismantling pure hyperbole from people who are treading dangerously close to ‘flourinated water is a mind control drug’ kookery, you’ll want to look away now.
Bear in mind, there will be a great deal of oversimplification for two reasons. One, I will not under any circumstances disclose information or hypothesis which put proprietary information at risk. There are zero exceptions to this rule, ever. Two, I will not disclose information which would enable bad actors to reproduce the results. I don’t even store that information electronically.
First of all, the most important part of FEEDTROUGH is that it only works on a very specific set of platforms. Specifically, Juniper Netscreen ns5xt, ns25, ns50, ns200, ns500 and ISG1000. It does not magically work on any other platform, it does not work on other products, and so on. It’s very tightly targeted, because that’s absolutely mandatory. If you’re working that low level, you must have a very high level of common components and common code. That’s why FEEDTROUGH isn’t one singular sample – it’s a minimum of 2 versions * number of ScreenOS versions.
Here’s how it breaks down and why it’s 2 * ScreenOS:
- ns5xt is a unique device, running an internally developed BIOS and an AMCC PowerPC 405GP
- ns25, ns50, ns200 and ns500 use an internally developed BIOS and an x86 CPU with ancillary ASICs
- The ISG 1000 uses the same basis as the ns25-ns500 in a different chassis with further additional ASICs and backplane.
So for 6 devices, you actually only have to deal with two different BIOSes and two different architectures. This repeats a lot more than vendors like to admit. It happens because it reduces development time and costs and increases overall reliability – obviously good things. They just don’t like to admit it for marketing reasons. It makes differentiation more difficult.
The thing is though, the only part alleged to be in the BIOS is the persistence implant “DNT payload.” The DNT payload doesn’t actually do anything at all in terms of spying or infiltration. Funny, isn’t that exactly what I’ve been saying? Oh right, it is. It also explicitly states that it is absolutely dependent on additional ‘implants’ – specifically BANANAGLEE – to perform any communications. Hey look, something else I called out.
So what does FEEDTROUGH do? How can it possibly evade forensic analysis of the BIOS IC? That’s easy – it’s not in the damn BIOS, exactly like I’ve said before. Juniper is more than capable and qualified to do a proper forensic analysis against a proof clean BIOS build. FEEDTROUGH resides in another element entirely – one that’s more difficult to catch, if not nearly impossible. Because getting a proof clean firmware image for some parts just is impossible – that’s somebody else’s proprietary and highly sensitive data. They don’t just hand it out, even to close partners.
So here’s a picture of how FEEDTROUGH more or less works. I say more or less because this is a hypothesis at this point, and proving it is exceptionally difficult because, well, see immediately preceding paragraph.
“TAO” infections like this don’t work on the BIOS, in fact. They merely use it as a lever. If they were stupid enough to put it in the BIOS, we would have detected it long ago with basic forensics. Unethical as they are, they are not stupid enough to do the equivalent of leaving the payload out in the open where any guy with $10 and an eBay account can find it and isolate it. Common frigging sense!
But they need it to start prior to btxld (the FreeBSD boot loader, or take your pick of boot loader) and persist past switch to real-mode. That means it can’t be in CPU registers, it has to be in device registers. You can set an awful lot of device registers in 512 bytes of data (the size of an MBR), and those devices such as the Intel i82574L, have internal flash that cannot be physically isolated and dumped. It’s part of the MAC’s actual die and sole access is through the MAC. There’s also a LOT more space in there for them to do bad things with, since the MAC has isolated RAM on die as well which not surprisingly, holds contents past boot.
Yes, you should basically be going “oh holy shit” right now. Especially when you consider an Ethernet MAC has no such thing as a ‘proof clean’ image – the flash contains the unique MAC address embedded in it.
Oh, and there is essentially ZERO safety in DMA operations on every OS out there. Once you’re into DMA, reads and writes are basically at the hardware level and there is no sane way to do a safety check to make sure it didn’t just decompress a piece of malware into volatile RAM. Any sort of checks in this space would have a tremendous negative impact on performance – we’re talking VLB speed or lower from PCI-X 133MHz devices negative.
So that’s how a TAO infection works, in essence. The diagrams are simplified for the audience (which is not technically literate) which incidentally obfuscates the real mechanics. Stuff like FEEDTROUGH can only ever work on a limited set of devices with a limited set of software because it is absolutely dependent on having common code and common hardware at an extremely low level. So for example, if you took a FEEDTROUGH sample and attempted to infect an ISG 2000 with it, you wouldn’t be able to because it doesn’t have the device which actually carries the infection. Similarly, if you boot to an unsupported OS, FEEDTROUGH won’t work – it depends on certain drivers operating a certain way to execute the OS level payload.
That’s why you have GOURMETTROUGH overlapping (nsg5t, ns25, ns50, some ISG 1000) – that covers a different device which is common across the supported platforms and uses a different execution method to support other OS versions. In other words, it is highly likely an ns25 or ns50 can carry both FEEDTROUGH and GOURMETTROUGH but only one of them would actually function.
JETPLOW (Cisco PIX) works in essentially the same fashion, but exploits the fact that PIX is based on a fundamentally flawed OS – Finesse – to install a persistent back door on the OS itself. SOUFFLETROUGH exploits the fact that the SSG 300/500 series is basically an off-the-shelf x86 system to exploit weaknesses in Intel SMM. (Good luck analyzing THAT; Intel is not going to let their SMM code base be inspected by anyone, ever. That is the height of sensitive proprietary data.) You get the idea.
Point being they are all extremely narrow in what they can target and operate on and highly restricted in being able to operate as intended. Just upgrading ScreenOS can break a FEEDTROUGH or GOURMETTROUGH infection. And when you narrow the targets sufficiently – specifically to a common BIOS, common OS, and common device – it actually becomes technically possible, doable, and extremely efficient from the standpoint of hiding your infection and preventing removal.
So anyone looking at the BIOS, well, great job wasting a ton of time and effort on something pointless? Like I said: they’re not going to leave something like that in a part that can easily be isolated and analyzed forensically where it can’t be hidden. And don’t tell me they subverted the supply chain – they’d have to hijack at least four manufacturers in multiple countries, at least twelve production lines, and there would be highly detectable variations.
SPI Flash parts are highly interchangeable and ordered ‘as-is’ without modifications from tier 1 resellers typically. So you’d have to preload ALL images onto EVERY part because you’d have no idea if it was going to Cisco, Juniper, Huawei, or Joe’s Raspberry Pi. It’s not feasible and it’s not possible – especially since almost all those production lines are in other countries. Plus it would cost billions upon billions because you’d have to use much more expensive parts with custom lithography to essentially build a two-bank SPI as a single-bank, plus a microcontroller to execute and stealth bank two. Nevermind that the IC would be physically larger due to the laws of physics, a dead giveaway that it’s counterfeit or tampered.
They’re also not subverting the manufacturers. I’ve talked with people who most decidedly would know and the latest round of information is the first they’ve heard of these exploits. Nobody wants to be shipping a device which is subverted in this way, because the second they get found out, they just lost all their customers. No person on earth would ever trust them again, and they would go bankrupt in short order. They want rid of this stuff more than anyone else. And if they were subverted (inserting it themselves) they could just yank it out easily; they wouldn’t be trying to figure out how it got in and how to prevent it.
And it’s still highly OS dependent. Period. Anything like using device internal functions to convert a port to a mirror port would be easily discovered just by plugging in a cable to the infected port. The NSA doesn’t have physical access to the device and can’t prevent physical access. So anything they do has to be extremely difficult to detect even when the engineers who designed the device have physical access. They can’t tell if somebody’s taken an infected device from a customer for a thorough tear-down (and believe me, that’s the first thing they would do if they saw any untoward behavior suspected of being a security breach,) and remotely destroy the evidence. Hell, there’s probably samples in labs that have continually escaped detection.
So no. They’re still not infecting the BIOS. Most Ethernet MACs have burst writable (meaning: can be written to during normal operation) flash, as do many USB controllers and so on. These parts are very hard to forensically inspect because the storage is on the die and accessed via on-die controllers. Operations to and from these devices are not checked for safety or security because of the difficulty and performance impact – they just have to be assumed as “safe.” That’s where the initial payload resides and execute from.
So there you have it; the most reasonable hypothesis at this point as to how they’re doing it and where they’re doing it. Unfortunately, as I said, forensically analyzing the parts likely to carry the infection is extremely difficult to put it mildly. Even I can’t get access to the required equipment and resources to do it. But that’s where it’s going to be found.
That’s where people need to be looking – especially manufacturers – right now. That’s also why I’m publishing this; so that the manufacturers who do have the necessary tools can start digging in the right places. (Again, I’m not going to go in depth because even the analysis involves a lot of proprietary and confidential information. And trust me – you cannot get access to the equipment. Some of it costs hundreds of thousands of dollars – yep, high barrier to detection.)
And yes, stay tuned – I’m probably going to muse some more on securing these critical elements in the future. If you think BIOS security is broken, you haven’t seen anything yet – these suspect devices have zero security.