Baltimore is not EternalBlue

Recently a misleading and terribly researched article (via  Nicole Perlroth and Scott Shane) came out in the NYT which essentially blamed the NSA and ETERNALBLUE for various ransomeware attacks on American city governments, including Baltimore. This then ballooned to PBS and the BBC and a bunch of other places, all of which parroted its nonsense.

For starters, when you research the malware in question, it is something called "RobinHood", which has been analyzed here.

Hmm. Don't see anything about ETERNALBLUE, do we?

Explicitly, all available analysis claims it gets basically manually installed on the targets, probably after someone gets phished or a simple web exploit is used to break into a network. It's also fairly hard to believe that ETERNALBLUE is truly in play considering it has been patched for TWO YEARS and the OS it was useful against (Windows 7/2008) is due to be EOLed by Microsoft next year. And while yes, MS08-067 was useful on penetration tests for a long time, and no doubt ETERNALBLUE will always be useful somewhere, on geriatric machines left in closets next to Wang computers and the odd SPARC workstation, it's not going to be a professional ransomware crew's goto, because it would alert everyone and probably never work.

Generally what everyone uses for lateral movement is Active Directory. You can learn more about it from Microsoft Research themselves in this Infiltrate2015 talk! Because this is a design flaw, it's not something you can really patch.

A giant pile of wrong from the article because the authors don't know what they are talking about.

In case you're curious, hackers had exploits a long time before "until a decade ago", and in fact, were the originators of the domain, with powerful toolkits that nations copied. (This slide is from one of my recent policy talks)

First of all, "NOBUS" when used officially means only capabilities controlled by strong cryptography - exploits are never in that category. They are always a risk/reward calculation. Secondarily hackers had amazing exploits during the Cambrian explosion after the 1996 papers on buffer overflows came out. Here is a talk from Infiltrate2019 which covers a bit of the history.

I'm not sure what their UNNAMED BUT AMAZING sources said about ETERNALBLUE and the Baltimore ransomeware attack, but you have to apply a bit of basic cognition to the question and that particular exploit being used to do lateral movement for this ransomware is neither supported by any public facts, nor my own sources on the issue.

In addition, it is hard to say that ETERNALBLUE is anything other than the particular exploit leaked by the SHADOWBROKERS. Metasploit and many others have released combo-packs targeting many vulns fixed in that patch to provide more reliable exploits against many more target operating systems. Once a patch comes out, no matter who found the bug that led the patch, anyone can reverse engineer the patch to write an exploit. SO IT DOESN'T MATTER IF A BUG IS LEAKED/FOUND OR DISCOVERED INTERNALLY BY MICROSOFT IN TERMS OF RISK IF YOU HAVEN'T PATCHED TWO YEARS LATER. This is unfortunately a point that has to be made since Nicole and Scott started their bizarre and baseless ideological blame-game.

-----
EXTRAS:
For another well researched position on this, please see Rob Graham's piece here.

Hope is not a NOBUS strategy

So typically the first thing I do when I get a new implant to look at is see if the authors implemented public key encryption into it, or if they just have some sort of password authentication, and then maybe a symmetric algorithm for protecting their traffic. This was, for a while, a good way to track nation states because people who wanted their implants "easier" to deploy did not put public keys in them, whereas those of us who wanted a NOBUS backdoor generated a new public key per target (like this amazing one, Hydrogen, from 2004).

In fact, let's talk about a few key features of Hydrogen because most people have forgotten them and they're relevant, and let's do it in the form of my favorite thing, a numbered list:

1. Embedded public key used to encrypt all traffic (and prevents MITM)
2. Not easy to write an IDS or Nessus scanner script for, since the only handshake was a one byte back and forth and there was no defined standard destination/source port
3. Uses Twofish instead of AES, for "reasons"
4. Replay attack resistant (due to blind key exchange, which on many unix's was hashes of ps -aux since you could not then depend on /dev/urandom existing)
5. Can be installed permanently or just used as a RAT
6. Pure POSIX-compatible C code
1. Ports cleanly to such amazing operating systems as DEC UNIX, SCO UNIX, without any #ifdefs
2. Even ports to Windows (but via a few minor #ifdefs)
7. 40K binaries - can be uuencoded and cut and pasted over slow links
8. Connectback or Connect-To via Environment variables because of...
1. Commandline spoofing (aka, you can call it ps -ef)
9. Deployment scripts which write directly into the binary without needing recompile
10. Bi-directional TCP and UDP redirection/Command Execution/File Transfer/Environment Variable setting, etc.
11. Export Controlled!

It's easy to say that an implant with blind key exchange is better than one that uses a symmetric key, right up until you try to manage a lot of implants and find yourself needing a database to try to figure out which private keys go to which hosts, and of course, since your tools were probably written by hackers and not cryptographers, it's easy to get the math wrong, especially in the late 90's when so much was just getting started. Likewise, your big number library that you're dragging around to every operating system is half the size of your implant. As a final note: any bugs in your implant (aka, crashes, failure to let you in because you messed up the key, freezes, etc.) are fatal in a way that bugs in your word processor most definitely are not.

So it ends up not being a matter of technical capability, but one of POLICY.

From a policy perspective, we don't want to add implants to a host that can be taken over by an adversary. And we want all traffic in transit to be protected by strong encryption as well. It was rare to find cryptographics of this type in a remote access trojan for the time. BO2k, for example, had symmetric crypto as an optional plugin (and was mostly used for jokes). Modified SSHd's were sometimes used around then, but were large and clunky and had many drawbacks (such as not supporting socket redirection and being annoying to modify).

CNE OPSEC is often an exercise in risk reduction and probability calculation. True NOBUS capability, on the other hand, is mathematically based, something others cannot replicate, ideally something baked in as early as possible (i.e. the specification or hardware). In that sense no software vulnerability is NOBUS, much as we may want them to be.

OPSEC is a thing

Note: One of the many things you will NOT learn in this article is HOW the Chinese did anything

I want to point out that Nicole Perlroth, David E. Sanger and Scott Shane have, as usual, written an article (here) that is more advocacy than news. They say never to pick a fight with someone who buys ink by the barrel, but this article is pure nonsense. Let's let Rob Lee, who knows what he's talking about, say it succinctly.

The Symantec blogpost, which is as close as we can get to real information here, tells a sparse story - we know that a Chinese group used SMB exploits, which may or may not have been related to EQGRP code (?), to penetrate a few hosts in various places about a year before ShadowBrokers went public. Interestingly none of those places was 5EYES, despite the constant hysteria that they will "use our own tools against us!"

Let's briefly delve into possible reasons why they showed restraint:

• This would likely get caught by EINSTEIN if sent in the clear over the wire
• If they hacked something EQGRP also was resident on, then they would possibly notice, which would lead to a massive investigation
• They don't need SMB bugs and kernel implants to get anything done in particular or they would have rewritten these bugs from scratch without using DoublePulsar

It's likely we don't know anything more than a small fraction of what they used the exploits or their variant of DoublePulsar against, assuming that BUCKEYE is the correct attribution and, in fact, it's not just EQGRP pretending to be BUCKEYE. The possibilities are endless with this little data, which is why it's amusing to see a fifteen page NYT report breathlessly fanning controversy over an imagined timeline.

But regardless, let's talk for a second. As we like to say, OPSEC is not using encrypted messengers and onion routers, but understanding your operating environment to a level of obsessive detail. And to that end, there are things you need to know before throwing an exploit to maintain control of your exploit:

• Is my traffic going over a sat link that people are listening to, even if they are not my target? (/usr/bin/traceroute - DO YOU HAVE IT?)
• Will network latency/packet loss affect heap layout?
• How busy is the target machine? 
• Do I have a safe place to send my exploit logic close to the target, or should I just establish an encrypted tunnel that exits as close as possible to the target?
• What IPS/IDS/etc does the target have installed? 
• What kind of residue is left when this exploit fails? Or even when it succeeds? Are there CORE dumps to delete?
• How many times has this exploit been used against this target? Have any of those boxes been discovered? Could they be watching for it?
• What is the target's offensive capability? Could they have found a similar bug and plugged it into their version of EINSTEIN? 
• What does it mean to be close to this target? How close is close enough? Is it possible to be closer? When is the best time to throw this exploit - during busy hours or off hours?
• Can you run your exploit over an encrypted protocol (HTTPS? SMB+Privacy? IPSEC?) directly to the target?

We don't know that BUCKEYE didn't find these bugs on their own, or buy them from the same source, or get handed a bunch of intel from the Russians who run ShadowBrokers right after they got it but long before they announced. What we do know, is contrary to Matt Blaze and friends, exploits almost NEVER get caught in the wild when used, which is why it's so interesting when they are!

Look, the Chinese are the best in the world by every measure I can find, and they're going to catch you sometimes even if you make all the right decisions. It's a thing.

---
Resources
https://www.wired.com/story/nsa-zero-day-symantec-buckeye-china/?mbid=social_twitter&utm_brand=wired&utm_campaign=wired&utm_medium=social&utm_social-type=owned&utm_source=twitter