Friday, September 4, 2009

Replay Attacks: Why "If it works twice, then it doesn't work" makes sense

Everyone who has ever performed a demo has had the experience of being asked "Can you send that message once more, I want to see will it work a second time". The viewer wants to see was the first successful run just a fluke, and will the demo still work if you run the message through again.

But when you are demoing message-based authentication, you want to see the message blocked when it is resent. This is because, counter-intuitively, it is the same message which just worked a moment previously.

Why is this? The reason is because of replay attacks. If the same message, containing the same authentication tokens, is re-sent, then that message may have come from someone who has sniffed the traffic of a valid user. This is sometimes called a "capture-replay" attack.

Replay attacks are often much misunderstood. I've seen them confused with DoS attacks (because they involve the replaying of messages, but a DoS attack is much less sophisticated and just uses brute force). I've also seen many cases where an organization wishes to create an authentication policy along the lines of "any messages signed by a trusted user will be let in", which is wide open to a replay attack by anyone who can get a hold of a message signed by one of the valid users.

The key to blocking replay attacks is to ensure that something in the message changes each time. Sometimes this is the timestamp, or the message itself if there is enough variation in messages (the Gateway will keep digests of previous messages and if it detects a collision, blocks the message). But standards such as WS-Security UsernameTokens used by XML Gateways have inbuilt support for blocking replay attacks. Let's take a look at this how an XML Gateway blocks a replay attack:

First we use Vordel's free Web Service Testing tool SOAPbox to put a WS-Security UsernameToken into a SOAP message. Click on the "Security" menu and then "Insert Ws-Security Username" token. Enter the details as shown. I have setup a user called "JoeUser" on the Vordel Gateway with a password which matches the password I am using.



We now see the UsernameToken in the message:



Switch over to Design View, and you see the structure of the WS-Security UsernameToken. Notice the Timestamp and the nonce. You may be thinking "hang on, that's not my password there". But it is a password digest, constructed over the original cleartext password, the timestamp, and the random nonce ("number once") which is created by SOAPbox as per the WS-Security specification.



We send this message through to the Vordel Gateway, and it is passed valid:



Notice the timestamp in the message. If an attacker changes the timestamp, that invalidates the digest. An attacker will not have access to the cleartext password and so can't create a new digest. But what if they simply resend the message while within the timestamp window? Let's see by pressing "Send" again in SOAPbox.

We see that the replayed message is detected and blocked by the Vordel Gateway.



Looking at the Vordel Gateway real-time monitoring reports, we see that one message was valid, and the message other message was blocked:



Looking at the real-time Flash-based traffic reports, we see the blocked message was blocked because of its WS-Security UsernameToken.



You don't have to configure anything on the Vordel Gateway for this. It automatically detects replay attack attempts based on replayed WS-Security UsernameTokens and blocks them.

To test this yourself, grab your copy of SOAPbox here. And get an evaluation copy of the Vordel Gateway here.