lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ