STUCCOMONTANA: NSA Exploit of the Day

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

STUCCOMONTANA

(TS//SI//REL) STUCCOMONTANA provides persistence for DNT implants. The DNT implant will survive an upgrade or replacement of the operating system—including physically replacing the router’s compact flash card.

(TS//SI//REL) Currently, the intended DNT Implant to persist is VALIDATOR, which must be run as a user process on the target operating system. The vector of attack is the modification of the target’s BIOS. The modification will add the necessary software to the BIOS and modify its software to execute the SIERRAMONTANA implant at the end of its native System Management Mode (SMM) handler.

(TS//SI//REL) STUCCOMONTANA must support all modern versions of JUNOS, which is a version of FreeBSD customized by Juniper. Upon system boot, the JUNOS operating system is modified in memory to run the implant, and provide persistent kernel modifications to support implant execution.

(TS//SI//REL) STUCCOMONTANA is the cover term for the persistence technique to deploy a DNT implant to Juniper T-Series routers.

Unit Cost: $

Status: (U//FOUO) STUCCOMONTANA under development and is expected to be released by 30 November 2008.

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 17, 2014 at 2:06 PM11 Comments

Comments

justSayingItAgain January 17, 2014 5:47 PM

I find stepping through these slides one at a time quite the worthwhile project so thank s for providing this forum. We’ve got no one to blame but ourselves if those that can don’t add informed commentary to it.

True, there could have been some bundling of very similar ones. But look at the crappy coverage of the most important leak to date in the NY Times — one story three weeks late making light of NSA antics, no docs, with minimal added value from unnamed senior officials who aren’t familiar with the docs either.

I can see from the Times coverage why no one in their right mind would ever bother leaking to them. Let’s hope the Guardian didn’t share too much — the Times no doubt forwarded all that they got straight to the NSA, just like they did with the Cointelpro fbi docs, ditto with all the other stories they’ve suppressed or delayed over the years in service to govt.

Tom Ames January 17, 2014 8:01 PM

Does anyone yet know who leaked these documents and to what end? In part, it seems like this is a catalog of what we’d expect a modern (or at least modern c. 2008) spy agency would be doing with our money. The descriptions read like a gee-whiz compendium of cool gear, and imply that the NSA is doing much more than vacuuming up wholesale personal information from citizens.

Is it reasonable to propose that this “leak” may be a propaganda effort from the NSA, with Congress perhaps being the primary target?

65535 January 18, 2014 2:59 AM

The same MO again:

  1. BIOS hack
  2. A second implant to make the hack persistent and call home with the data stream.
  3. SMM pawned
  4. Juniper Edge router with Juno OS

Again, the reboot of the router would seem to be the indication of an infection. Even on Microsquish Servers if there is a reboot a window pops up asking for a reason (a hint to check the system for infection). I would assume other vendors have that function also.

I see a huge opportunity for Anti-Virus vendors to get into BIOS AV products. Also, I have a feeling that someone is playing fast a loose at Juniper. I can only shake my head in disgust.

Here is awkward non-denial:

“SOLUTION:

“Juniper Networks recently became aware of, and is currently investigating, alleged security compromises of technology products dated from 2008 and made by a number of companies, including Juniper. We take allegations of this nature very seriously and are working actively to address any possible exploit paths. As a company that consistently operates with the highest of ethical standards, we are committed to maintaining the integrity and security of our products. We are also committed to the responsible disclosure of security vulnerabilities, and if necessary, will work closely with customers to implement any mitigation steps.

”The alleged security compromises included indications of “software implants” and a method for installing malicious code in BIOS. Juniper Networks is not aware of any such BIOS implants in our products and has not assisted anyone in the creation of such implants.

”Juniper maintains a Secure Development Lifecycle, and it is against Juniper policy to intentionally include “backdoors” that would potentially compromise our products or put our customers at risk.

”Juniper will continue to aggressively investigate this report as we do all reports of potential vulnerabilities in our products, and will continue to notify our customers according to our Security Incident Response Team policies.

”In 2008 Juniper published this Advisory related to ScreenOS Firmware Image Authenticity Notification”

http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10605

Joel January 18, 2014 4:41 AM

@65535:

Which part of that is awkward? Unless I’m falling for their weasel words, that basically sounds like a denial to me.

Larry January 18, 2014 11:56 AM

What are the chances that re-flashing the BIOS with a stock firmware image, using stock flashing software, would that wipe out the trojan implant?

BlackAngel January 18, 2014 1:44 PM

@Tom Ames • January 17, 2014 8:01 PM
Does anyone yet know who leaked these documents and to what end? In part, it seems like this is a catalog of what we’d expect a modern (or at least modern c. 2008) spy agency would be doing with our money. The descriptions read like a gee-whiz compendium of cool gear, and imply that the NSA is doing much more than vacuuming up wholesale personal information from citizens.
Is it reasonable to propose that this “leak” may be a propaganda effort from the NSA, with Congress perhaps being the primary target?

Snowden grabbed the documents. I think that if you would claim Snowden was a black bag job sending out disinformation, one would be stretching it way beyond mind bending.

A January 18, 2014 5:17 PM

Identifying their command-control-and-exfiltration protocol on the network could help find broken firewalls and discourage NSA from accessing the already-broken ones. It could be used by other TAO products, too. There are challenges:

  • The protocol might (or might not!) be hard to detect. Connections might use standard ports like HTTP or ping. Imagine checking for incoming connections where hash(remote host, remote port, timestamp, secret)=0x0000, or complicated port-knocking-type setups.
  • Even if you recognize the protocol, you probably can’t do really interesting things like remove implants remotely, because the actual meaningful content would be encrypted/authenticated.
  • Who knows how many or few firewalls are actually broken right now.
  • Of those firewalls, who knows how many have a persistence implant (rather than just getting broken anew on reboot).
  • Now that this is public, they might’ve stopped communicating with and/or removed the implant from all or some target routers, to avoid discovery.

Getting a copy of the implant would be a huge win. Looking at BIOSes of routers from major service providers in as low-level a way as possible is about all I can think of.

I’d almost bet that the NSA’s key hardened strategic targets–the governments/militaries who are not close US allies–have known the general shape of this for a long time. If Congress was right to be skeptical about Huawei equipment, then they might well have learned it by watching what we did to them. Allies + US citizens, on the other hand, only find out now.

A-Team January 19, 2014 10:50 AM

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

Nick January 20, 2014 8:02 AM

The attack seems to rely on being able to re-flash the BIOS.
Presumably BIOSes are stored in some kind of EEPROM so that they can be updated.
Wouldn’t it be a defense to put a jumper into the write-enable line of the EEPROM, so that to re-flash the BIOS requires somebody to physically plug in the jumper, and always take it out again after re-flashing with a known-good BIOS?
The OS can then check that the jumper is disabled before it completes booting, for example by executing the sequence to erase the entire EEPROM, which should fail if all is well.

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.