GOURMETTROUGH: NSA Exploit of the Day

Continuing our walk through the NSA’s Tailored Access Operations (TAO) group implant catalog:


(TS//SI//REL) GOURMETTROUGH is a user configurable implant for certain Juniper firewalls. It persists DNT’s BANANAGLEE implant across reboots and OS upgrades. For some platforms, it supports a minimal implant with beaconing for OS’s unsupported by BANANAGLEE.

(TS//SI//REL) For supported platforms, DNT may configure without ANT involvement. Except for limited platforms, they may also configure PBD for minimal implant in the case where an OS unsupported by BANANAGLEE is booted.

Status: GOURMETTROUGH is on the shelf and has been deployed on many target platforms. It supports nsg5t, ns50, ns25, isg1000(limited). Soon- ssg140, ssg5, ssg20

Unit Cost: $0

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. It’s interesting how many of these implants are designed to allow other implants to survive attempts to remove them.

I think it’s important to discuss these implants individually. Because the whole catalog was released at once, it’s easy to focus on the catalog as a whole instead of the individual implants. Blogging them once per day brings back focus.

Posted on January 7, 2014 at 1:16 PM19 Comments


A-Team January 7, 2014 3:29 PM

Bruce, note the leaksource url is missing the GodSurge page of the catalog.

By careful reading of the fine print, especially for SchoolMontana, SierraMontana, and StuccoMontana, you can see that the catalog was put together in June or July 2008.

The TAO division (1st column), upper right hand corner date (2nd column), product name (3rd column and status are provided below. Note some of the items have been widely deployed while others are still in early development (4th column).

S322 21   20 06 08   DEITYBOUNCE     ready
S322 21   20 06 08   GINSU           deployed
S322 21   20 06 08   GODSURGE        ready
S322 21   20 06 08   IRATEMONK       deployed
S322 21   20 06 08   SWAP            deployed
S322 21   20 06 08   WISTFULTOLL     deployed
S322 21   14 07 08   IRONCHEF        ready
S322 22   24 06 08   FEEDTROUGH      many deployed
S322 22   24 06 08   GOURMETTROUGH   many deployed
S322 22   24 06 08   HALLUXWATER     deployed
S322 22   24 06 08   HEADWATER       ready
S322 22   24 06 08   JETPLOW         widely deployed
S322 22   24 06 08   SCHOOLMONTANA   ready
S322 22   24 06 08   SIERRAMONTANA   ready soon
S322 22   24 06 08   SOUFFLETROUGH   deployed
S322 22   24 06 08   STUCCOMONTANA   ready soon
S322 22   01 10 08   DROPOUTJEEP     in dev
S322 22   01 10 08   GOPHERSET       ready not deployed
S322 22   01 10 08   MONKEYCALENDAR  ready not deployed
S322 22   01 10 08   TOTECHASER      ---
S322 22   01 10 08   TOTEGHOSTLY 2.0 in dev
S322 3    05 08 08   COTTONMOUTH-I   available Jan 09
S322 3    05 08 08   COTTONMOUTH-II  available Sep 08
S322 3    05 08 08   COTTONMOUTH-III available May 09
S322 3    05 08 08   CROSSBEAM       90 days ARO
S322 3    05 08 08   FIREWALK        prototype Aug 08
S322 3    05 08 08   HOWLERMONKEY    ready
S322 3    05 08 08   JUNIORMINT      in dev
S322 3    05 08 08   MAESTRO-II      ready
S322 3    05 08 08   SOMBERKNAVE     fall 2008
S322 3    05 08 08   TRINITY         special order
S322 42   20 06 08   CANDYGRAM       ready 8 mos ARO
S322 42   20 06 08   PICASSO         ready
S322 42   20 06 08   TYPHON HX       ready 4 mos ARO
S322 42   25 07 08   NIGHTSTAND      deployed
S322 42   25 07 08   SPARROW II      deployed
S322 42   30 07 08   WATERWITCH      in dev LRIP Aug 08
S322 42   27 01 09   EBSR            ---
S322 42   27 01 09   ENTOURAGE       final testing
S322 42   27 01 09   GENESIS         ready
S322 42   27 01 09   NEBULA          ---
S322 42   -- -- --   CYCLONE Hx9     in production
S322 43   08 07 08   CTX4000         end of service
S322 43   24 07 08   NIGHTWATCH      end of service
S322 43   24 07 08   PHOTOANGLO      in dev
S322 43   24 07 08   RAGEMASTER      ready
S322 43   07 04 09   LOUDAUTO        in dev
S322 43   07 04 09   SURLEYSPAWN     in dev
S322 43   07 04 09   TAWDRYYARD      in dev

S321: Remote Operations Center (ROC)
S322: Access/Advanced Network Technologies (ANT)
S323: Data Network Technologies (DNT)
S324: Telecommunication Network Technologies (TNT)
S325: Mission Infrastructure Technologies (MIT)
S325: ?
S327: Requirements & Targeting (R&T)
S328: Access Technologies Operations (ATO)

DB January 7, 2014 5:01 PM

We need to use open source firewalls. Closed source cannot be audited by the world’s security experts, only those with a vested interest (i.e. they’re being paid by the company). Closed source companies can be served NSL letters with a gag order.

MITM Books January 7, 2014 5:07 PM

Here’s a hypothetical exploit, PSYCHOTROPE.

Using Amazon’s print-on-demand book service, the NSA interdicts the purchase of a technical reference book to be delivered to a software developer. Key elements of a protocol are altered in a subtle way, perhaps substituting digits in a table of numbers. Code is written to conform to this altered reference book and is deployed with a NSA backdoor installed.

Bob S. January 7, 2014 5:12 PM


Re: “We need to use open source firewalls…”

I tried a well known one today. It was constantly phoning home…to England a known NO TRUST country, creating simple ip filters was a tough drill down exercise 9it wants you to accept it’s judgement only, logs were flimsy….and it asked me to view “trusted” ads as well as download a bunch of crapware I didn’t want..

Is there a such a thing as a trusted open source firewall?

G. Bailey January 7, 2014 5:14 PM

@MITM Books

The NSA already does this with the standards process. In some cases, they have strengthened the protocol (e.g. the DES S-boxes were suggested by the NSA, and later it was discovered that they resist differential cryptanalysis). In other cases, it seems that they have a secure backdoor (i.e. one exploitable only by them).

f3jk3fkjnf3kn January 7, 2014 5:28 PM

@G. Bailey: Only exploitable by them, usually because they only deal with the public through cryptography implementations and have more resources and better talent than the public sector.

Most people forget the NSA recruits only exceptional talent and from all over the globe. It’s not a bunch of semi-literate idiots like you see with US politicians and agency PR..

The public’s underestimation of the NSA gives them a major strategic advantage in denial and misdirection..

Nick P January 7, 2014 5:55 PM

@ Bob T

A free one or an open source one? And among open source quality varies. Open source is the minimum requirement needed to avoid the subversion. The code itself must also be trustworthy. That’s why OpenBSD is probably best for firewalls if you’re wanting minimal default configuration, openness, firewall capabilities, and quality code.

NetBSD-based solutions are next bet as their code is easy to read for a BSD and they pick up fixes from OpenBSD often. Next would be a minimal configuration of seBSD or SELinux for the various mandatory controls. With these, one must minimize running processes and preferably disable anything in kernel/usermode that’s unnecessary just in case. And put it on a non-x86 platform (eg POWER) to avoid huge amount of malware and kits targeting Intel.

Then you’re done. Ok, not really: there’s secure configurations and hardening practices at every level for even a NIX system. Yet, OpenBSD on non-x86 is more secure than most commercial firewalls out of the box and the other options can be made more so.

David January 7, 2014 6:46 PM

Not knowing much about Juniper, but having studied Cisco, I googled “Juniper firewall nvram” and had this link at phrack.org show up as the fifth hit. (Not endorsing the link, its validity, or its purpose…just a convenient example.)

So they follow pretty much the same general pattern I’ve seen in others–firmware loading the OS from a local flash/nvram, with configuration files alongside. More permanent storage probably holds the primary image–the fallback in case a sysadmin just wants to go back to start.

Just an educated guess, but they probably put most/all of the security on keeping unauthorized users from accessing the firewall–not keeping anyone who is actually in the system from doing things.

In my own mind, I refer to such systems as “crunchy”–hard outer shell, gooey soft interior. Sure, they are fast, cheap, and configurable, but way too trusting.

Modern desktop OSs have gone the way of trusting no one by default–if nothing else, you have to click the “Are you sure?” dialog when it trips one of the guards.

Detecting changes in these environments means you have to either add an internal audit–subject to corruption, also–or build in an external audit hook–which can be spoofed or used as an additional attack vector.

If I was designing a detection system, I would go the second route, to start with. Design a self-sufficient auditor that “knows” what the config and files should be, and routinely hooks into the remote boxes to check the data there. You still have the spoofing problem (“No spyware here, boss!”), but it’s better than just believing that the system is unhacked.

xyz January 8, 2014 12:48 AM

FEEDTROUGH read through http://www.juniper.net/support/downloads/

GOURMETTROUGH read through R&D.

If you are a sysadmin for “King Edward Memorial” then you are going to register in order to get updates. But if you work for DCHQ then you know someone from Juniper’s R&D or you compile your self.

TinyLittleAnt January 8, 2014 1:16 AM

David: Juniper is basically the same as Cisco (and the lawsuits are there to prove it lol) and nvram is the permanent storage as far as the typical router is concerned. nv means non-volatile, i.e. it doesn’t disappear in a puf of smoke when you turn the power off. When you reflash it the payload is from somewhere else, usually/normally a dedicated serial connection or dedicated (i.e. only used for configuration access) ethernet interface from your computer.

As for “a hard shell that’s squishy on the inside” routers like most network equipment are/were/originated as single-purpose devices. They are not multi-user and thus access is king. Stuff like IOS (Cisco’s router operating system) does have a two-tier command prompt more as a user convenience than anything else and as pointed out above one is supposed to be able to restrict where the router/IOS/nvram accepts access and reflashing from but yeah good look with that considering how deep in the pocket of the NSA they (and everyone else these days) are and how they conveniently use old well known (lots of documented bugs) and dirt cheap (nearly free of cost, nothing else is competitive) consumer GPUs that are nicely overpowered for the tasks (think Pentium I’s).

There’s not much of an environment as such: only configuration, and configuration is typically a one-way street i.e. you don’t pull the configuration from the router to update and push back but instead just push the changes you want made or push a full configuration with the changes included.

Full of holes? Everything is and it’s nothing new.

Progress is measured in adding new layers of holes.

The important parts people don’t seem to know or want to know:
the internet was built on trust, it only works because of trust.

  1. Internet is short for interconnected networks i.e. a network of networks.
  2. You can’t have the kind of interconnected networks we have without routing (ref.: packet switching).
  3. “Trust-less” packet switching is as far as I know both theoretically and practically impossible/meaningless.
  4. In such a scenario the only option is to make each and every connection it’s own independently verified virtual private network.

This is not an internet any more, instead it is a slightly distributed and somewhat vendor and service provider independent “private virtualized software-based POTS” with zero protection of metadata.

Further down this same road you’ll find TOR and I2P, fair enough but this is the road away from the concept of interconnected networks.

All of the above is/should be basic knowledge to anyone at the NSA who isn’t cannon fodder.

Should be but is it? If they knew what they are doing would they continue doing it?

Secret Police January 8, 2014 8:18 AM

Juniper uses a custom version of FreeBSD which doesn’t have stack gap protection and other safeguards enabled by default. Here is the security mitigation of OpenBSD presented to Ru BSDcon last year that explains problems in FreeBSD http://www.openbsd.org/papers/ru13-deraadt/

I would assume they exploit the webserver that’s running the configuration, then flash the BIOS remotely to make it permanent. Mitigate this by configuring with ssh command line, using keys, and nuke any daemons running like apache2. Flash with OpenBGP, run IDS.

David January 8, 2014 8:57 AM


I agree that you can’t (well, not according to the original design) have a trust-less internet, and that these and most routers were set up as single-purpose devices. The crunchiness I was referring to was the internal security of the router, not the way it performs its functions.

I can even support your point of why it’s this way. Computers, even single-purpose ones like routers, are flexible, and it makes perfect sense for a manufacturer to build the system in a way that’s easy to upgrade, simple to access, and still gives the level of security that was viewed as sufficient for the time.

But the NSA revelations have changed the environment. A single hacker is a threat, but mostly a nuisance; they do damage that has to be repaired, costing time and money and maybe reputation.

Criminal organizations and competitors are a bigger threat, but they usually have more specific goals–steal certain data and get away with it where it can be turned into money or advantage.

The NSA takes a completely different approach–gain access to a system, but leave everything functioning as-is. In a way, it’s kind of admirable. Rather than damaging or removing anything, they just want life to go on in a normal fashion while they watch. That is a different security issue than what has been emphasized up to now.

(Hell, if adware and botnet programmers took the same approach, they’d probably try to make computers run better so users wouldn’t complain about poor performance and start looking for the interloper…)

It’s this type of threat where my comments were directed–not redesigning the web or checking the validity of every single packet, but keeping the ninja-style hacks from happening. And, of course, it’s a trade-off: Single-purpose systems are faster; added security is added expense; replacing the all of the current systems is prohibitively expensive and complicated; choosing a security design that works is better than throwing in the flavor-of-the-month fix.

Hope this clarifies. I agree with all of your points, but I think there is a way to do things better–you just have to direct your efforts in the right way.

DB January 8, 2014 1:42 PM

@Bob S: perhaps I should clarify: Only a fully open source security infrastructure can ever be safe in today’s world, closed source can never be. This does not mean that any old open source offering is safe, nor does it mean that it’s easy to use, nor does it mean that it’s done properly. But the more people who get this, the more all closed source solutions should over time be going out of business (or if they’re smart: changing their model of business) and getting replaced with better and better open source offerings.

joe green January 9, 2014 11:47 AM

yeah, we might not have any form of privacy anymore, any hope of political reform using the democratic process is gone, citizens have no control over policy, and any form of domestic protest about it will be easily controlled and stopped; but man, at least these NSA codenames are hilarious

Leave a comment


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.