Thales Blog

News From Black Hat: Awesome And Scary

August 6, 2013

Black Hat Thales PartnersLast week I had the privilege to attend both the Black Hat and DefCon conferences in Las Vegas, Nevada.  Both conventions cover roughly the same topic: computer security, approached from the point of view of an attacker.  If Black Hat and DefCon were brothers, Black Hat would be the elder son that played by the rules, went to grad school, and got a nice corporate job.  DefCon would be the punk younger brother that's smart, creative, but had a few run-ins with the law, and is mending his ways.

This blog post covers Black Hat – Look for my observations from DefCon later.

When I say that Black Hat approaches security "from the point of view of an attacker", I don't mean that these are the bad guys!  Rather, these are professionals who find weaknesses in systems and then disclose those weaknesses to the appropriate people or organizations.  The basic outline for every talk is along the lines of "Here's this cool technology you may or may not have heard about, here's how it works, and here's how I broke it".  Frequently the "here's how I broke it" part is accompanied by an actual live demonstration of the vulnerability.

On Monday and Tuesday, I took a course called "Ultimate Hacking" - which, as its name implies, taught me some of the basics of breaking into machines.  Perhaps one of the biggest eye-openers for me was the availability of tools to do most of the work - often it was a few simple commands and then *bam* - privileged access to a machine.  If you're an attacker, the basic methodology of an attack looks like:

  • Enumerate - Also known as reconnaissance - figure out what's on the network and what you can attack
  • Penetrate - Break in
  • Escalate - Move from an unprivileged user to a privileged user
  • Pillage - Acquire info, credentials, and data
  • Expand Influence - Use what you've learned to attack other machines
  • Cleanup - Hide your tracks

Vormetric defends against the "Pillage" part of this methodology with a Data Centric Security solution.  We ensure that privileged users can't actually see sensitive data.  So many other security companies focus on the network, or the access to machines - "system-centric security" rather than "data-centric security".  Ultimately, it's the data that everyone is after.  That's what Vormetric does: protect data and report on data accesses.

Moving on, Wednesday and Thursday were the actual "Black Hat Briefings", a.k.a. the actual talks.  Typically these shock and awe the audience with how a previously-thought-secure technology isn't actually secure.  Here are a few of my favorites.

First up, a talk called "TLS Secrets" by NextGen$.  Time to geek out a little.  TLS (Transport Layer Security, responsible for basically all the encrypted traffic on the internet) normally has a 4-way handshake for the start of a connection. But this can be reduced to a three-way handshake through the use of TLS "sessions".  Basically how this works is that the server gives the client a little blob of data that is AES-128 CBC encrypted.  Inside this little blob is the session ID and the data key used to encrypt traffic.  The client then hands this back to the server on the reconnect.  What this means is that:

  • the entire security of TLS rests on the key used to encrypt this session info,
  • which is AES-128,
  • which means that no matter what fancy cipher you use... does not really matter
  • and you have no forward secrecy.  (Forward secrecy is the property that if your credentials are stolen, an attacker can't decrypt previous communication.)

The attack would be this: the attacker records all your encrypted TLS communication.  Then they break into the server that you were talking to, find the key used to encrypt the session state, and bam - all your communication is now decryptable.  Not good.  How did it get this way?  The key for session state is very poorly managed, with no rotation or anything.

So...key takeaway: disable TLS Sessions.  The performance gain is minimal, and they're just dangerous.

Next up, my Awesome/Scary award went to "Traffic Interception and Remote Mobile Phone Cloning with a Compromised CDMA Femtocell".  You've got to love a talk that starts with "There's a red line we put down on the floor. If you're in front of that line, then it's likely that you're in range for your phone to contact our femtocell.  If you don't want this, put your phone into airplane mode or turn it off.  But if you don't mind, we're looking for volunteers..."

The talk did everything promised: intercepted voice, text, and MMS, plus a cloned phone.  There's no indication on your phone that you're not talking to a real cell tower, either.  Scary.  Here I thought that browsing through my phone would be moderately safe... although the presenters did say that hacking mobile data (as opposed to voice/text) would be "harder".  Hmmm.

Going back to the TLS nerd in me, the next talk was titled "SSL, gone in 30 seconds: a BREACH beyond CRIME".  Part of the job of the exploit writer is to make catchy acronyms for their exploits, and these guys did a good job.  This was an amazing hack.  The vulnerability is that TLS does not hide the packet length.  When compression is used with TLS, problems can happen.  The speakers explained how compression works - when a pattern matching a previous pattern is found, the second pattern just becomes a pointer to the first.  This affects the size of the packet.  So if you're trying to guess a secret (like a session id in the body of an https response) then you first try to match one letter.  If you see the size go down a byte due to compression, you have a match, if the size doesn't go down a byte you don't have a match.

Let's say the secret you want to guess is inside an encrypted web page, and the text around it looks like "secret=password".  You know the first part is "secret=" and you want to guess the last part.  To do this, you try "secret=a", "secret=b", "secret=c" and so on until you hit "secret=p", and the compression algorithm makes it just little bit smaller.  You then start again with "secret=pa", "secret=pb", "secret=pc" and realize that 'pa' is the smallest.  You then try again with "secret=paa", "secret=pab", "secret=pac", etc, until you've got the whole word "password".

These guys broke an outlook web access session id from inside a TLS session in 43 seconds, live on stage.  Devastating.  The most effective remediation: turn off all compression in TLS.

Those are my highlights from Black Hat, check back soon for my notes on DefCon.