Talking about crypto at Securi-Tay 2014 (Dundee, Scotland)

I’m doing a talk about cryptography at Securi-Tay 2014 on the 15th of January, up in Dundee, Scotland. The talk is aimed at people who are interested in cryptography from a practical perspective, but are put off by the slew of hieroglyphs and maths-speak that tends to plague the field. The talk is entitled “Breaking bad crypto without breaking your brain”. I promise that there are no Breaking Bad references in there, primarily because I seem to be the only person on earth that still hasn’t started watching it.

Securi-Tay is a great conference, organised by Ethical Hacking students at the university, with some help from other nice folk and sponsors. I attended (and spoke) last year, and it was great from both technical and social aspects. There’s a really good line-up of talks so far, and it’s always great to see the student talks dealing with things from brand new perspectives, as well as the staple talks from professionals and seasoned researchers.

Tickets are £20 a head, and there’s free booze after the con, so it’s an absolute bargain – come join us!


A quick crypto lesson – why “MAC then encrypt” is a bad choice

In light of the numerous recent attacks against SSL, I thought I’d offer up a quick and simple crypto lesson about why MAC-then-encrypt schemes are bad. This post will require only a minimum of knowledge about cryptography, so hopefully it’ll be useful to a wide range of people.

This is not designed to be a full and detailed description of how SSL works, or how various attacks against it works, but rather a short primer on the subject for those who know a bit about crypto but don’t really understand how something as seemingly strong as SSL might be broken. Some parts have been generalised or simplified for brevity and ease of understanding, so please don’t take anything I say here as a literal description of how it all works.

Anyway, let’s get started…

A secure network protocol has two main jobs:

  1. Keep the information in the conversation completely confidential.
  2. Prevent an attacker from tampering with the conversation.

The first part, as you probably already know, is performed by encryption. This usually involves exchanging one or more secret session keys between two endpoints, then using them with a cipher of some kind in order to provide safety against eavesdroppers.

The second part is a little more involved. In this case, when I say “tampering with the conversation”, I mean forging packets that look like they came from a legitimate endpoint, in such a way that they have a meaningful effect on the security of the conversation. This part is often implemented via a Message Authentication Code (MAC), which verifies that all data received was in fact sent by an authorised endpoint. Usually, a HMAC hash will be used, which is a keyed version of a cryptographic hash function. By using the session key as the key for the HMAC hash, it is possible to produce a hash of the payload in a way that cannot be forged by anyone that does not know the session key. By computing the same HMAC hash on the receiving end, using the same session key, it is possible to verify the authenticity of the data.

However, there’s a catch. One implementation option, called MAC-then-encrypt, is to compute the MAC on the plaintext data, then encrypt the data. The receiving endpoint then decrypts the data using the session key, and verifies its authenticity. Unfortunately, this means that an unauthenticated attacker can send arbitrary messages, and the receiving endpoint must decrypt them first in order to verify the MAC. Without knowing the session key, the attacker will likely produce garbage data after decryption, and the MAC will not match.

There is, however, an interesting trick that can be done here. Block ciphers require the length of all plaintext messages to be a multiple of the cipher’s block size. Since there is often a length discrepancy, padding is used to ensure that the message length is extended to fit. There are many different algorithms for generating padding data, but the padding is usually reliant on the plaintext in some way. This padding is checked during the decryption phase, and invalid padding results in an error. An attacker can flip certain bits in the ciphertext to modify this padding, and identify changes in behaviour and timing based on these altered bits. This is called a padding oracle attack, and can lead to full discovery of the plaintext.

A better solution, called encrypt-then-MAC, is to encrypt the data first, then compute the MAC of the ciphertext. This leads to a situation where the receiving endpoint checks the MAC first, before performing decryption, and drops the connection if the MAC is incorrect. Since the attacker can’t forge the MAC without knowing the session key, this completely negates the padding oracle attack.

How is all of this relevant to SSL? Well, in TLS 1.0 and earlier, a MAC-then-encrypt scheme was used. This resulted in various attacks, including BEAST and Lucky 13. In TLS 1.1 and later, these types of attacks are prevented.

Hopefully this has given you some insight into one of the ways that SSL can be vulnerable.

Why are botnets so bad at authentication?

You’d think that people writing botnets would be well versed in systems security, but from a quick look around I see that most botnets have some serious problems. The biggest issue with any botnet is command and control. How can the owner communicate with their bot nodes without having people steal their botnet by sniffing the traffic? Very few botnets out there seem to do anything to solve this issue, which baffles me. I recently found a botnet’s command and control channel on IRC and sat in there with a nickname similar to one of the bots and waited. The owner came online, authenticated with a password:

* jaxcx (none@C7A8F60F.70A4D926.D9A031DB.IP) has joined #jaxcnc
<jaxcx> .login gemma_2008
<j1F87E5A5> b 0 1 1 16701
<j81E0690F> b 0 1 0 25811
<jA18A5DF3> b 0 1 0 30246
<jaxcx> .av add avast.exe
<jaxcx> .c
* jaxcx (none@C7A8F60F.70A4D926.D9A031DB.IP) Quit (Quit)

I then logged in as him (.login gemma_2008) and tried some commands. After some playing about, I discovered his botnet ran as a process called ‘scvhost.exe’, which I then added to the bot’s AV list just as he added Avast. They all quit due to ping timeout a few minutes later.

The fatal flaw there was authentication – everything was simple plaintext. At an absolute minimum you’d expect challenge-response (CHAP) style login:

<owner> .auth
<bot1234> challenge 4356462135
<bot4567> challenge 3023843571
<bot4321> challenge 5430587478
<owner> .login bot1234 e737b251fb9581502c91e56d95cbe43e
<bot1234> .ok bot5678 owner 325e117a80e658027dd60ea2101823ae
<bot1234> .ok bot4321 owner 51d8e811dc92e387e037f91944218491

Confusing? Let’s break it down line by line.

<owner> .auth
The owner asks to authenticate to the botnet.

<bot1234> challenge 4356462135
<bot4567> challenge 3023843571
<bot4321> challenge 5430587478

The bots give a challenge value which the user must append to his password, which he then hashes with MD5. The owner only has to authenticate to one bot.

<owner> .login bot1234 e737b251fb9581502c91e56d95cbe43e
The owner decides to authenticate to bot1234, so he calculates the MD5 hash of “password4356462135” and uses it to log in. The bot verifies that the hash matches.

<bot1234> .ok bot5678 owner 325e117a80e658027dd60ea2101823ae
<bot1234> .ok bot4321 owner 51d8e811dc92e387e037f91944218491

The bot that was authenticated to now authenticates to the other bots on behalf of the user.

Of course this is just an example. It could be improved by using private messages to perform all the authentication, or by having a more secure password challenge format. The holy grail is, of course, asymmetric cryptography. Since the .NET framework makes it trivial to use RSA, one could simply authenticate by taking a random challenge value and producing a digital signature for it. The botnet clients have the public key embedded in them, which is then used to prove the authenticity of the user.

What I really don’t understand is why these methods aren’t being used. Are bot writers really that lazy, or am I missing something?