COMMAND
Weak Token in Mail.Com Application Allows Compromise of Arbitrary User's Data
SYSTEMS AFFECTED
Some free Web mail services powered by mail.com
PROBLEM
Following is based on Black Watch Labs Security Advisory.
Products affected are free Web mail services powered by mail.com
(two underlying free Web mail applications were identified, and
this vulnerability pertains to only one of them. Services that
use the other application are not vulnerable as far as we know.
The free Web mail offered directly by mail.com is not vulnerable)
The mail application employs a weak security scheme. It assigns
session-IDs ("tokens") for logged-in users which allow reading of
arbitrary users' messages and private information, if enough
effort is invested.
The mail service, upon successful login, assigns an encoded
session-ID for the user, in the following manner:
1. The mailbox's number (a decimal number consisting of around 8
digits) is concatenated with a colon symbol, and the current
time (in seconds since 01/01/1970, based on the server's clock,
9-10 decimal digits) is appended to it, reading
nnnnnnnn:ttttttttt (where nnnnnnnn is the number of the
mailbox, and ttttttttt is the time). This string will be
referred to as the clear session-ID.
2. A base letter is randomly generated, probably in the range A-J.
3. The encoded session-ID consists of the base letter,
concatenated with pairs of capital letters, each pair
conforming to a character in the clear session-ID, where this
character's ASCII code is represented in two decimal digits,
and these digits are taken as an offset relative to the base
letter. For example, if the base letter is A, then a character
"1", whose ASCII code is 49 is represented as EJ, and if the
base letter is G and the character to encode is ":", whose
ASCII code is 58, then the encoded representation is LO.
This encoded session-ID identifies the session, and is given back
to the user via a cookie (if the user is willing to accept such
one), or as part of the URL. In both cases, the name of the
parameter (or the cookie) is "iNAME", e.g.
iNAME=BFKFGGGGHGBGIGHGFGJGIGDGFGIGCGDGFGDGI
In many cases BHL encountered a situation wherein both the cookie
and the URL trailer were sent to the user. Apparently, the
session is identified by the encoded session-ID, and by it alone.
Empirically, the session is not accessible if one changes the
timestamp, the mailbox number, or even the base-letter (of course,
re-adjusting the rest of the string).
The session is alive as long as the user has not logged-out, and
the account is not idle for longer than 6 hours. Therefore, if
an attacker gains the encoded-session-ID while the session is
still alive, he/she can access all the information residing in
the user account, such as personal information and messages.
The encoded session-ID can be reconstructed statistically (that
is, an attacker can generate several candidates, one of which will
be correct) relatively easily. First, the attacker needs to guess
(or know beforehand) a mailbox number. Then, the attacker should
estimate when the owner of the mailbox accesses the mailbox (a
fair estimate would be once a day). Next, the attacker needs to
know the approximate time on the mail server (easily done if the
attacker opens a valid account there, and decodes the session-ID
which contains the server time). Now, in order to gain access to
the mailbox, the attacker needs to write a script that generates
for each second of the day, all possible 10 encoded session-IDs
(one per each possible base-letter), and send these to the server
(either as a cookie or embedded into a request URL). If indeed
the owner of the mailbox logged-in during the day, then the
script will discover it, and as a final step in the script, it
should get all the mailbox info.
In a side note it should be stated that the application does not
sanitize HTML and JavaScript when a user of the application views
the body of a mail message sent to him/her. As a result, most of
the standard exploits (e.g. embedding links and Javascripts in
various tags) work well and can be used as standalone attacks or
in conjunction with the above vulnerability (e.g. to establish
the initial link between email address and mailbox number).
Identifying the vulnerable application can be done by checking
whether the suspected application is willing to serve clients
that disallow cookies (only the vulnerable application does
that), and that once the user logged-in, the URLs have the
"iNAME=..." trailer. If such is the case, the attack method
described above is applicable. Naturally we do not provide an
automated script that implements the attack.
Black Watch Labs is a research group operated by Perfecto
Technologies Ltd., the leader in Web application security
management. Black Watch Labs was established to further the
knowledge of Web application security within the Internet
community.
SOLUTION
Vendors using the mail.com product have been notified as has
mail.com. Vendor patch or workaround is not available at the
time of this release.