Schneier on Security
A blog covering security and security technology.
« Matt Blaze on TAO's Methods |
| Twitter Users: Please Make Sure You're Following the Right Feed »
January 7, 2014
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 PM
• 19 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
Yet Another BIOS implant. The same things apply as my comments yesterday.
I tend to think that COTS has been a godsend to the intrusion community. Standards rule!
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)
S327: Requirements & Targeting (R&T)
S328: Access Technologies Operations (ATO)
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.
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.
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?
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).
@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..
@ 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.
I just want access to the program that names these things.
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.
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.
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?
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.
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.
@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.
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
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.