GINSU: NSA Exploit of the Day

Today’s item from the NSA’s Tailored Access Operations (TAO) group implant catalog:

GINSU

(TS//SI//REL) GINSU provides software application persistence for the CNE implant, KONGUR, on target systems with the PCI bus hardware implant, BULLDOZER.

(TS//SI//REL) This technique supports any desktop PC system that contains at least one PCI connector (for BULLDOZER installation) and Microsoft Windows 9x, 2000, 20003, XP, or Vista.

(TS//SI//REL) Through interdiction, BULLDOZER is installed in the target system as a PCI bus hardware implant. After fielding, if KONGUR is removed from the system as a result of an operation system upgrade or reinstall, GINSU can be set to trigger on the next reboot of the system to restore the software implant.

Unit Cost: $0

Status: Released / Deployed. Ready for Immediate Delivery

Page, with graphics, is here. General information about TAO and the catalog is here.

In the comments, feel free to discuss how the exploit works, how we might detect it, how it has probably been improved since the catalog entry in 2008, and so on.

Posted on January 29, 2014 at 2:28 PM35 Comments

Comments

BJP January 29, 2014 3:00 PM

This sounds very much like an implementation of the PCI device Linux kernel backdoor described in https://blogs.oracle.com/ksplice/entry/hosting_backdoors_in_hardware

Use the expansion ROM capability in the BIOS to execute code from the PCI device prior to reading the MBR, set up interrupt handlers to inject your code into the Windows kernel and have at it. This is probably one of dozens of implementations of this general theme.

And none of it shows up on any malware scan since it’s not on disk, anywhere, ever.

Tony H. January 29, 2014 3:10 PM

Interesting that it calls BULLDOZER a “PCI bus hardware implant”. Not necessarily something that plugs into a PCI slot (where it would be quite likely to be noticed). I wonder what form factor a BULLDOZER takes, and how it connects to the bus.

pegr January 29, 2014 3:15 PM

For your Oracle link:

“Unless you work for something like a government intelligence agency, though, you shouldn’t realistically worry about installing commodity hardware from reputable vendor”

I believe that should be, “Unless you are targeted by a government intelligence agency,…”

LOL!

pegr January 29, 2014 3:17 PM

Tony:

That could be anywhere on the PCI bus, including the chipset! I’d imagine that could be applied to the physical bus itself, much like installing a “mod chip” on a video game console.

Iain Moffat January 29, 2014 3:27 PM

@Tony and pegr: It also occurs to me that the implant could replace a PCI card expected to be in the machine with one that has been modified – given that the exploit does not mention any particular make and model of PCI-bus computer as a target I expect it will be something generic like an ethernet or graphics card if it is hidden in plain sight that way.

Andrew Wallace January 29, 2014 3:47 PM

Any analysis of the exploit(s) within this series of releases should be discussed privately.

Such discussion should be behind closed doors at research institutes and laboratories.

Otherwise, you are feeding the hand that bites you with useful information.

biteyfeedey January 29, 2014 4:24 PM

Re: feeding the hand that bites you.

Yes, ideally all of us potential targets would discuss these exploits, without the NSA being privy to those discussion, as then the NSA wouldn’t know which ones we’ve figured out how to defeat.

But, the next best solution is to discuss everything in the open, so everyone knows how they work and how to defeat them –that makes us at least a little safer than not discussing them at all.

Since realistically, any really productive discussion is going to need enough participants that it probably won’t be hidden from the NSA anyway, we should talk in the open.

RobertT January 29, 2014 4:33 PM

Sure sounds to me like exploit persistence from a PCI card ROM. Trouble is how do you find these problems, removing every installed card, connecting cable, (even motherboard) is hardly practical for an individual let alone a corporation, so what do you do?

Even a LiveCD boot is vulnerable to this sort of persistent exploit.

Sounds like it is game over for security on Windoze or any typical PC based platforms. I guess I should be happy unfortunately I know first hand how insecure Andriod is so there is absolutely nothing to change over too.

Josh Rubin January 29, 2014 4:46 PM

Does NSA offer a removal service for misplaced backdoors?

Sort of like unexploded bombs.

Tony H. January 29, 2014 5:54 PM

Interesting that it calls BULLDOZER a “PCI bus hardware implant”. Not necessarily something that plugs into a PCI slot (where it would be quite likely to be noticed). I wonder what form factor a BULLDOZER takes, and how it connects to the bus.

Moderator January 29, 2014 6:16 PM

The fellow most recently known as “Spyderman” is a banned user who is most likely having a manic episode. Please don’t make the distraction worse by responding. (I would say “please don’t encourage him” but I see little evidence he notices what anyone else says.)

Brandioch Conner January 29, 2014 6:36 PM

The diagram seems to indicate radio transmit/receive. So it is possible that this includes a radio. So maybe a Faraday cage or equivalent.

Or not.

Anyway, the first step here would be detection. Are your supposedly secure systems sending out packets that you cannot account for? Whether over the wire or via radio frequencies.

Beyond that, swap your components on a regular basis. Try to pick the components from a variety of sources. If possible, hand over the old components to people who can take them apart at the chip level. See if they find anything unusual.

Chris Abbott January 29, 2014 7:06 PM

I think a good solution to these things would be to have available a SHA-512 hash of the original factory BIOS so that you could find a way to tell if it’s been jacked with in transit.

Thing January 29, 2014 7:36 PM

From (very rusty) memory, the PCI spec allows for multiple BIOS rom images per device (to support multiple CPU architectures). The BIOS/FW scans for and loads all BIOS ROM extensions during POST so in theory you could use any free space (if there is enough) or swap out any soldered or socketed flash with a larger part. Your device now contains the original BIOS ROM ext + the exploit BIOS ROM ext (with tweaks to the PCI CSRs as appropriate). This would retain the original functionality of the option card and allow the exploit to be loaded during POST.

Nick P January 29, 2014 7:46 PM

@ Andrew Wallace

That’s a nonrisk. Without help of blog comments, the NSA managed to subvert hardware, BIOS, peripherals, OS’s, middleware, crypto standards, supply chain, emission security, and service providers. So far, they seem to have no obstacles to getting to most American targets systems. That all the secrecy and esoteric knowledge already exists at NSA means theyre years to decades ahead of us.

Open discussion gives us the advantage, not them.

n0n3 January 29, 2014 8:17 PM

Still, i guess we’ll have to wait another decade or so for the next snowden to lift the lid on how the government makes use of things like haarp and S-Quad / v2k

RonK January 30, 2014 1:02 AM

@ RobertT

Even a LiveCD boot is vulnerable to this sort of persistent exploit.

But if you look closely, the revealed OS eavesdropping injection is designed only for Windows, which indicates that the NSA doesn’t have magical AI exploits which are platform-independent. This indicates that if we could develop new OSs which are intentionally polymorphic by design, we might be OK.

In the meantime, you might be OK if you ran something OTS, but really esoteric, like Inferno. (Because, in that case, the NSA would probably classify you as a high risk for detecting and revealing their intrusion method). Or, maybe not…

Peter January 30, 2014 3:37 AM

@Tony H, the description says that it requires “one PCI connector (for BULLDOZER installation)”, which sounds synonymous with “one PCI slot”. It doesn’t say “one free PCI connector”, though. Maybe BULLDOZER’s form factor is a PCI slot, and they unsolder the existing one to replace it?

Samuel Creshal January 30, 2014 6:26 AM

Food for thought: There used to be a lot of PCI devices with unused option ROM ZIF sockets (network cards, e.g.). Guess we now know what those were used for. 🙂

Clive Robinson January 30, 2014 7:05 AM

@ RonK,

    But if you look closely, the revealed OS eavesdropping injection is designed only for Windows, which indicates that the NSA doesn’t have magical AI exploits which are platform-independedent…

Er I think it’s more likely to be didn’t, the docs six years old, back then Linux, Solaris, OS/2 were not on much Internet stuff outside of servers, for which the catalog shows better attack vectors.

Since then a lot has changed even “for gain” cyber crooks regard *nix sufficiently low hanging fruit to write exploits for…

And this has made me think, most of these software attacks were already in the wild either by researchers or cyber-crooks. Which raises the question of just who wrote them…

I’m tending to think traditional NSA staffers did not write these from scratch so either the code base or writers were “imports”.

Thus it may be possible to identify the code writers from thos who were having their collars felt by the likes of the Feebies back then and/or attended BlackHat etc…

It might be time to think about “outing” some of them in various ways.

As for the hardware stuff I know certainly similar equipment was available on the open market in the UK back in the 80’s&90’s because I was designing and selling it as I’ve mentioned befor on this blog (long before Ed Snowden went to the NSA, and no I’ve never made it a secret).

For the record UK Agencies like MI5 are not good customers, they talk potential deals and ask for a sample, which they then “Chinese Copy”[1] or give to their favourd partners like Marconi (as was).

The journalist Duncan Campbell [2] has quite a bit to say on this as they served a warrent on his home/office by booting in the door, where they found his “Telephone Tap Detector” that used Time Domain Refectomatry (TDR) and got one of their favoured manufactures to make it for them to use and give to MI6/GCHQ/CIA/NSA…

[1] When the term “Chinese copy” or “Chinese Knock Off” was first coined the “China” it refered to was the Republic of China (ROC) which is now more commonly known as Taiwan.

[2] There are a number of Duncan Campbells associated with newspapers, he was most famously linked with the ABCtrial and Zircon Satelite revelations in the Thatcher era, and later wrote about the effective Colonial Dictatorship in Hong Kong and is linked these days to the “Echelon Report” he did for the EU. http://en.m.wikipedia.org/wiki/Duncan_Campbell_(journalist)

erm January 30, 2014 8:12 AM

@Tony H and Peter

Couldn’t it also be an implant embedded in any PCI device? As in, it could come installed in a new PC or they could wait for the target to order any PCI card (new soundcard/USB card/network card, granted they aren’t as common as they were years ago), intercept the shipment, and implant BULLDOZER into the PCI card so that the target installs it into his computer himself?

RonK January 30, 2014 8:15 AM

@ Clive

Er I think it’s more likely to be didn’t

Uh, I understand by this that you believe that the NSA has multi-platform attacks (against a large variety of known OSs). I agree that this is likely. When I said “magical” it was because I was talking about attacks which are somehow totally independent of the particular binary form of the OS, so they would work against a highly individualized/polymorphic OS. To solve this general problem would be equivalent to solving the halting problem, I think, no?

paul January 30, 2014 8:49 AM

How many people who aren’t either security fiends or builders of their own hardware look inside their computer on a regular basis?

tom January 30, 2014 2:10 PM

Now here’s a fellow who actually knows something about persisting malware and PCI buses:

http://resources.infosecinstitute.com/nsa-bios-backdoor-god-mode-malware-deitybounce/
http://resources.infosecinstitute.com/pci-expansion-rom/

“Initial Program Loader (IPL) Device Primer: The second item of background knowledge you need to know pertains to the IPL device. A RAID controller or other storage controller is an attractive victim for firmware malware because they are IPL devices, as per BIOS boot specification. The BIOS boot specification and PCI specification dictate that IPL device firmware must be executed at boot if the IPL device is in use. IPL device firmware is mostly implemented as PCI expansion ROM. Therefore, IPL device firmware is always executed, assuming the IPL device is in use. This fact opens a path for firmware-level malware to reside in the IPL device firmware, particularly if the malware has to be executed at every boot or on certain trigger at boot.

For more details on IPL device firmware execution, see: https://sites.google.com/site/pinczakko/low-cost-embedded-x86-teaching-tool-2. You need to take a closer look at the boot connection vector (BCV) in the PCI expansion ROM in that article. The system BIOS calls/jumps-into the BCV during bootstrap to start the bootloader, which then loads and executes the OS. BCV is implemented in the PCI expansion ROM of the storage controller device. Therefore, the PERC RAID controller in Dell PowerEdge servers should implement BCV as well to conform to the BIOS boot specification.

IPL device PCI expansion ROM also has a peculiarity. In some BIOS implementations, it’s always executed, whether or not the IPL device is being used. The reason is that the BIOS code very probably only checks for the PCI device subclass code and interface code in its PCI configuration register. See the “PCI PnP Expansion ROM Peculiarity” section at https://sites.google.com/site/pinczakko/low-cost-embedded-x86-teaching-tool-2#pci_pnp_rom_peculiarity.

We know that PCI expansion ROM initialization is initiated by the motherboard BIOS from the Malicious Code Execution in PCI Expansion ROM article (http://resources.infosecinstitute.com/pci-expansion-rom/). The motherboard BIOS calls the INIT function (offset 03h from start of the PCI expansion ROM) with a far call to start add-on board initialization by the PCI expansion ROM. In the DEITYBOUNCE case, the add-on board is the PERC PCI/PCIe board or the PERC chip integrated with the PowerEdge motherboard”

Clive Robinson January 30, 2014 4:04 PM

@ RonK,

I wish it were as dificult as solving the halting problem but it’s not.

Without going into all the messy details (some of which are given above by @tom) the process a PCI card has to under go is,

1, either identify the CPU and present low level code or the BIOS has an bytecode interpreter which runs generic F-code.

2, The code fromthe PCI device needs to examine the bootloader and identify the OS.

There are a couple of ways it could do this one of which is to pull in boot sectors etc and “walk the line” till it identifies the OS, one way is to take control of the bootloder through subroutine hooks another is to put in a custom bootloader such as a modified second stage GRUB. If not walking the line it needs some reliable OS identifing method equivalent of looking for “magic numbers”. Whilst this may appear dificult to do there are only a limited number of main stream OS’s it needs worry about.

What it needs if it cannot identify the OS is to do an ET and call home somehow and send a chunk of code back home for identifing.

Which sugests there may be a defence mechanism for a few smart people one of which is to develop your own PCI code to effectivly act as a BIOS extender with teeth. If you ensure your code is loaded first then you can put in a CLI and control what the other PCI cards do or don’t under human control.

One such might be the equivalent of an Inline Media Encryptor, which wipes memory sets up the vector tables etc and then pulls in a section of HD to RAM disk, and decodes it with an operator entered key.

I’ sure with a little more thought a working solution could be found, however care has to be excercised otherwise you end up in the old ECM – ECCM – ECCCM game.

Clive Robinson January 30, 2014 4:14 PM

@ Paul,

    How many people who aren’t either security fiends or builders of their own hardware look inside their computer on a regular basis?

I think we could say even for the few that did they probably would not know what to look for.

And that’s the problem, even for those that did look at best all they are going to see is “chip numbers”. I’m reasonably sure that the NSA has sufficient resources to re-lable chips.

BUT… if you hunt around on the web you will find hobbyists who are hooking upto JTag pins and seeing whats in the chips and in some cases re-programing them.

I suspect it would not be an overly onerous task to come up with a bit of hardware to clamp onto the required pins and re-flash the chip. It’s certainly something I would consider for the more run of the mill cards and hard drives.

Lawrence D’Oliveiro January 30, 2014 5:33 PM

Judging from the name, this will not be the last…

“But wait, there’s more!”

Figureitout January 31, 2014 12:04 PM

tom
–Yeah it is nice, had that particular tutorial bookmarked when I get a chance to have a go at this HDD w/ a broken SATA board, or I don’t even know. Might have to cut some metal though to get at just some exterior pins.

Also kind of OT, FFT on the RasPi, just saw on hackaday. Pretty sweet:

http://www.raspberrypi.org/archives/5934

thunker February 1, 2014 2:21 AM

BULLDOZER would not be a PCI card. Understand what the document markings “TS//SI//REL” mean and then think about the problem the NSA is solving.

Any hardware must be highly resistant to detection: logical, physical, and RF.

If it is detected it must be highly resistant to analysis about its origin and purpose.

If its purpose is suspected its origin must be deniable.

BULLDOZER is a ‘covert channel’ mechanism that interfaces with the PCI bus. It is probably small, simple, and programmable. Reliability must be high, and multiple units exposes the device to detection. I think GINSU is the software or firmware that runs on BULLDOZER. GINSU is capable of installing and checking on the status of KONGUR. It appears that KONGUR is installed on the hard drive and capable of subverting the security mechanisms of Micrsoft Windows Vista. Although the diagram shows a RF link to a field computer, it may not have RF capability.

James Sutherland February 2, 2014 6:01 AM

Rough guess: BULLDOZER has its own CPU core (ARM Cortex-M3?) and a little bit of RAM+ROM on which a small application like GINSU can run to probe and subvert the host machine in various ways via DMA, like identifying the operating system and installing an OS-specific payload.

Being just a ROM would not fit as well – you’d be too tied to the card you’re attaching. Some have optional ROM spaces, some don’t – but what size? Voltage? Speed? One NIC will have an empty socket for a 5V boot ROM, the next, a surface-mount 3.3V EEPROM already present – but the PCI bus and sockets are standard: voltage, spacing, pin layout – not too hard for them to have made a replacement PCI socket with a single die wired into the right pins. Nothing too arduous for an outfit with its own chip fab!

Presumably most likely targets will be paranoid enough that even if they suspected a piece of hardware had been subverted, they’d destroy all trace of it rather than let it be analysed publicly, which is a shame. Oh, to get some motherboards and hard drives from the Iranian nuclear programme, or similar…

Something about the status of “has been deployed on many target platforms” for many of these items seems rather disturbing to me.

Figureitout February 14, 2014 12:55 PM

AlanS
–I’m not sure they’re the same people, but yeah that guy deserves some air time, his blog and that site has excellent stuff that just happens to be very relevant to me right now (BIOS/DMA research). His blog and that site is going on the next squid post.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.