FEEDTROUGH: NSA Exploit of the Day
Today’s item from the NSA’s Tailored Access Operations (TAO) group implant catalog:
FEEDTROUGH
(TS//SI//REL) FEEDTROUGH is a persistence technique for two software implants, DNT’s BANANAGLEE and CES’s ZESTYLEAK used against Juniper Netscreen firewalls.
(TS//SI//REL) FEEDTROUGH can be used to persist two implants, ZESTYLEAK and/or BANANAGLEE across reboots and software upgrades on known and covered OS’s for the following Netscreen firewalls, ns5xt, ns25, ns50, ns200, ns500 and ISG 1000. There is no direct communication to or from FEEDTROUGH, but if present, the BANANAGLEE implant can receive and transmit covert channel comms, and for certain platforms, BANANAGLEE can also update FEEDTROUGH. FEEDTROUGH however can only persist OS’s included in its databases. Therefore this is best employed with known OS’s and if a new OS comes out, then the customer would need to add this OS to the FEEDTROUGH database for that particular firewall.
(TS//SI//REL) FEEDTROUGH operates every time the particular Juniper firewall boots. The first hook takes it to the code which checks to see if the OS is in the database, if it is, then a chain of events ensures the installation of either one or both implants. Otherwise the firewall boots normally. If the OS is one modified by DNT, it is not recognized, which gives the customer freedom to field new software.
Status: (S//SI//REL) FEEDTROUGH has on the shelf solutions for all of the listed platforms. It has been deployed on many target platforms.
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.
The plan is to post one of these a day for the next couple of months.
Nicholas Weaver • January 6, 2014 2:22 PM
Most of the TAO bios-attacks just strike me as “duh”: If you want persistence across reboots and software updates, you hide in the BIOS/firmware. You do it right, you even intercept the firmware reflash so you can persist across a “firmware update”.
What is needed is probably a “high/low” rootkit style test: An in-the-OS dump of the firmware and a “clip to the motherboard” dump of the firmware, basically a device that reads the FLASH directly by hooking onto the pins and reading the contents directly.
Difference? You got a BIOS rootkit.
(What actually surprises me is their emphasis on persistence, not just here but with the whole QUANTUMNATION suite: With such an ability to compromise systems with QUANTUM, so much of their workflow would work just fine with NO persistence, which makes detecting the attack much much harder)