[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20100920180720.5596.qmail@securityfocus.com>
Date: 20 Sep 2010 18:07:20 -0000
From: yawninglol@...il.com
To: bugtraq@...urityfocus.com
Subject: Battle.net Mobile Authenticator MITM Vulnerability
The Blizzard Entertainment Battle.net mobile authenticator application
that is used as part of an optional two factor authentication scheme to
safeguard accounts is vulnerable to a passive eavesdropper during the
initialization process which occurs once per the lifetime of a given
device.
An overview of how the application and protocol works is available at:
http://bnetauth.freeportal.us/specification.html
Summary:
The Mobile Authenticator client/server initialization protocol is insecure.
Any attacker that is able to capture the request/response pair can fully
compromise the Serial Number/Secret Key which is vital to the secure
operation of the authentication mechanism.
Description:
The vulnerability exists when an attacker is able to intercept the
initialization request and response bodies sent to and from the mobile
device to the server.
An attacker that is capable of intercepting the encrypted request/response
pair will also be able to derive time stamp information.
Since the key generation algorithm seeds a pseudo random number generator
via "Time since the Unix Epoch", the search space for valid one time pad
keys that correspond to the encrypted cypher text is fairly small.
(This is dependent on how much clock skew exists between the attacker's
computer and the mobile device running the authenticator code.)
The factor that compounds this poor choice of pad generation algorithm is
that the response leaks quite a few bits of the pad.
The response format is as thus:
uint64_t current server time
uint8_t encrypted initialization response[37] (RespCypherText)
uint8_t secret key[20]
uint8_t authenticator serial number[17]
The authenticator serial number is always formatted as:
"EU-1234-5678-9012" or "US-1234-5678-9012".
Given the serial number format it is possible to derive portions of the key
like thus:
key[20]: RespCypherText[20] ^ 0x45 ('E') or 0x55 ('U')
key[21]: RespCypherText[21] ^ 0x55 ('U') or 0x53 ('S')
key[22]: RespCypherText[22] ^ 0x2D ('-')
key[27]: RespCypherText[27] ^ 0x2D ('-')
key[32]: RespCypherText[32] ^ 0x2D ('-')
The other bytes that make up the authenticator serial number all leak the top
4 bits of the relevant byte since the plain text will always range between
0x30->0x39. This gives the attacker 11 bytes out of the 37 byte pad which
is more than sufficient to establish a high confidence match.
Given the small search space it is trivial to brute force through the plausible
pads, and from there recover the rest of the one time pad key.
Further compounding the issue of a leaky key, the way in which RSA is used is
insecure. Since the payload is unarmored, there is a one to one correspondence
between each plain text and cypher text pair. With a minor amount of guesswork
to determine the mobile model string that the originating device used, the
attacker is able to determine if his decryption is correct. Though due to the
tiny search space such steps experimentally appear to be unneccecary.
Vendor was notified via e-mail, no response received in ~7 days.
Powered by blists - more mailing lists