After Black Hat: Shaming is Easy (When You Don't Encrypt)

Aug 12, 2016 | by RSA

During the Black Hat 2016 NOC outbrief session, Grifter, aka Neil Wyler made a counter-intuitive statement to a crowd of roughly 500 attendees, eager to see which of their online activities would be exposed center stage:

"I look forward to the day when I can't see anything you're doing on the Black Hat network".

Wait... what? A primary goal of the Black Hat NOC is to gain visibility and insight into anything that might threaten the integrity or availability of the conference, so why is the man responsible for doing exactly that insisting that conference-goers hide their activity from plain sight? In the security operations and incident response realm, we've all been waving the flag of "pervasive visibility" as the only way to respond effectively and thoroughly to nefarious activity. If you're blind, you don't stand a chance.

This is where we need a dissection of the concept. Nobody is suggesting that we need to neuter all monitoring solutions. Full visibility is more critical now than it has ever been before. But, with today's eroded perimter and omnipresent wifi, what's equally critical is protecting ourselves and our companies from unnecessary exposure and expansion of attack surfaces. Looking at the Black Hat network, let's distill it down to two classes of network: core (trusted) and conference-wifi (un-trusted).

Maximum visibility into and out of the core operations and applications that keep the conference running smoothly is paramount. The more that can be seen and understood here, the better. But on the un-trusted side, the conference wifi, while it was certainly interesting and informative to see the endless transfer of malware and lolcats, it became very clear that even a gathering of the world's foremost cyber security professionals bubbles up evidence of surprisingly poor OPSEC. Whats more, and arguably worse, is that many commercial applications are equally careless. This, as Grifter will tell you, is what the NOC does NOT want to have to see (although it would dramatically reduce the humor score of the NOC outbrief session).

Let's take a look at stats from all of the clear text activity captured by RSA NetWitness. A "wall of sheep", of sorts:

  • Network sessions with cleartext auth: ~315,000 (~200K non-SNMP)
  • Unique usernames: 568
  • Unique passwords: 800
  • Cleartext search engine queries: 5,355
  • Cleartext emails: 687

We don't need much more commentary beyond Dave Glover's previous post on the topic. We all recognize the problem here, but if we expect our users to protect themselves, we need to protect ourselves. Especially at Black Hat.

But those stats aren't the focal point (punch line?) of this post. What's arguably more concerning than exposure from poor end-user habits is exposure from poor application development and implementation. We (and our users) have more individual control over the former than the latter. During the conference we noticed 4-5 enterprise-class applications from well known vendors sending WAY too much information back to their mother ships in the clear. Specific vendors won't get called out here - maybe it's poor development, maybe it's poor implementation, maybe both - but the fact of the matter is that there is no need (eg.) for in-the-clear HTTP POST (HTTP over port 443, almost sneaky) of host information back up to a corporate server over the internet.

Specifically, in one of the better examples:

  • Hostname
  • AD Domain
  • Serial Number
  • Product Version
  • Full Software Inventory
  • Full Software Versions
  • Product License Details
  • User's Family Tree*

* Not really, but may as well have.

For one application in particular we found the same agent on 50 different hosts communicating to their 7 unique organizations in this manner, sending a total of about 10MB (~100MB uncompressed) of sensitive data outbound within a few hours.

facepalm?

So, while us users certainly need to get our act together, us vendors do as well. Not encrypting over un-trusted networks shouldn't be an option.

Author: RSA

Category: Research and Innovation, RSA Point of View

Keywords: Black Hat 2016, Black Hat NOC