Wednesday, May 8, 2019

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

No comments:

Post a Comment