3.2.1) Client connection limits
Through the use of certain messages in the Battle.net protocol, it is possible
to enter a channel beyond the normal 40 user limit. This was due to the fact
that the method a game client would use to return to a chat channel after
leaving a game would not properly check the user count. After miscreants
exploited this vulnerability to put thousands of users into one channel, which
subsequently lead to server crashes, Blizzard finally fixed this
vulnerability.
3.2.2) Chat message server overflow
The server software often assumed that the client would only perform 'sane'
actions, and one of these assumptions dealt with how long of a chat message a
client could send. The server apparently copied a chat message indicated by a
Battle.net protocol client into a fixed 512-byte buffer without proper length
checking, such that a client could crash a server by sending a long enough
message. Due to the fact that Blizzard's server binaries are not publicly
available, it would not have been easy to exploit this flaw to run arbitrary
code on the server. This serious vulnerability was fixed within a day of
being reported.
3.2.3) Client authentication
Aside from general sanity checks, Blizzard also has had some issues relating
to authentication. Blizzard currently has two systems in use for user account
password authentication. In order to create a third party client, these
systems had to be understood and third party implementations reduced. This
has revealed several flaws in their implementation.
The first system Blizzard utilizes is challenge-response system that uses a
SHA-1 hash of the client's password. The game client implementation of this
system lowercases the entire password string before hashing it, significantly
reducing password security. (A third party client could opt not to do this,
and as such create an account that is impossible to log on to through the
official Blizzard game clients or the text-based protocol. The text-based
protocol sends a user's password in cleartext, after which the server
lowercases the password and internally compares a hash of it with the account
in question's password in a database.) However, a more serious security
problem remains: in SHA-1, there are a number of bit rotate left (``ROL'')
operations. The Blizzard programmer responsible for implementing this
apparently switched the two parameters in every call to ROL. That is, if
there was a ``define ROL(a, cool.gif (...)'' macro, the programmer swapped the two
arguments. This drastically reduces the security of Battle.net password
hashes, as most of the data being hashed ends up being zero bits. Because of
the problem of incompatibility with previously created accounts, this system
is still in use today.
The second system Blizzard utilizes is one based off of SRP (Secure Remote
Password, see
http://srp.stanford.edu). Only Warcraft III and it's expansion
use this system for password authentication. This product has it's own
account namespace on Battle.net, so that there are no backwards compatibility
issues with the older ``broken SHA-1'' method. It is worth noting that
Warcraft III clients and older clients can still communicate via chat, however
- the server imposes a namespace decoration to client account names for
communication between namespaces, such that a client logged on as Warcraft III
would see a user ``User'' logged on as Starcraft on the USEast Battle.net
network as ``User@USEast''. However, this system is also flawed, albeit less
severely. In particular, the endian-ness of calculations is reversed, but
this is not properly accounted for in some parts of the implementation, such
that some operations expecting to remove trailing zero bits instead remove
leading zero bits after converting a large integer to a flat binary buffer.
There is a second flaw, as well, although it does not negatively impact the
security of the client: In some of the conversions from big numbers to flat
buffers, the server does not properly zero out bytes if the big number does
not occupy 32 non-zero bytes, and instead leaves uninitialized data in them.
The result is that some authentication attempts will randomly fail. As far as
the author knows, this bug is still present in Battle.net.
3.2.4) Client namespace spoofing
With the release of Warcraft III, a separate account namespace was provided
for users of that product, as mentioned above. The server internally keeps
track of a user's account name as ``xusername'', where x is a digit specifying
an alternate namespace (the only currently known namespace designation is 'w',
for Warcraft III). This is known due to a message that exposes the internal
unique name for a user to protocol clients. While the character '' has never
been permitted in account names, if a user logs on to the same account more
than once, they are assigned a unique name of the format 'accountnameserial',
where 'serial' is a number that is incremented according to how many duplicate
logons of the same account there are. Due to a lack of parameter checking in
the account creation process, it was at one time possible to create
accounts,via a third party client, that were one character long (all of the
official game clients do not allow the user to do this). For some time, such
accounts confused the server into thinking that a user was actually on a
different (non-existent) namespace, and thus allowed a user who logged on to a
single character account more than once to become impossible to 'target' via
any of the user management functions. For example, such a user could not be
sent a private message, ignored, banned or kicked from a channel, or otherwise
affected by any other commands that operate on a specific user. This was, of
course, frequently abused to spam individuals with the victims being unable to
stop the spammer (or even ignore them!). This problem has been fixed in the
current server version.
3.2.5) Username collisions
As referred to in the previuos sub-section, for some time the server allowed
Diablo Shareware clients. These clients did not log on to accounts, and
instead simply assigned themselves a username. Normal procedures were
followed if the username was already in use, which involved appending a serial
number to the end to make a unique name. Besides the obvious problem of being
able to impersonate someone to a user who was not clever enough to check what
game type one was logged on as, this creates an additional vulnerability that
was heavily exploited in ``channel wars''. If a server became split from the
rest of the network due to load, one could log on to that server using Diablo
Shareware, and pick the same name as someone logged on to the rest of the
network using a different game type. When the server split was resolved, the
server would notice that there were now two users with the same unique name,
and disconnect both of them with the ``Duplicate username detected.'' message
(this is synonymous with the ``colliding'' exploits of old that used to plague
IRC). This could be used to force users offline any time a server split
occurred. Being able to do so was desirable in the sense that there could
normally only be one channel operator in a channel at a time (barring server
splits, which could be used to create a second operator if the channel was
entirely emptied and then recreated on the split server). When that operator
left, the next person in line would be gifted with operator permissions
(unless the operator had explicitly 'designated' a new heir for operator
permissions). So, one could ``take over'' a channel by systematically
disconnecting those ``ahead of'' one's client in a channel. A channel is
ordered by a user's age in the channel.
3.2.6) Server de-synchronization
At one time, a race condition such that if a malicious user were to log on to
two connected (i.e. not-split) servers at the same time, the two servers would
cease to communicate with another, causing a server split to occur. It is
difficult to provide an exact explanation for why this would occur given the
collision elimination mechanism described above for users that are logged on
with the same unique name, but it is assumed that in the process of
synchronizing a new user between servers, there is a period of time where that
a second server can also attempt to synchronize the same user and cause one of
the servers to get into a invalid state. According to observations, this
invalid state would eventually be resolved automatically, usually after 10-15
minutes.
3.2.7) Seeing invisible users
Battle.net administrators have the ability to become invisible to normal
users. However, until recently, this was flawed in that the server would
expose the existence of an invisible user to regular users during certain
operations. In particular, if one ignores or unignores a user, the server
will re-send the state of all users that are ignored or unignored in the
current channel. Before this bug was fixed, this list included any invisible
users. It is worth noting that the official game clients will ignore any
unknown users returned in the state update message, so this vulnerability
could only be utilized by a third party client.
3.2.8) Administrative command discovery
Originally, Battle.net would provide no acknowledgement if one issued an
unrecognized chat command ("slash-command"). Blizzard later changed the
server software to respond with an error message if a user sent an unknown
command, but the server originally silently ignored the command if the user
issued a privileged (administrator-only) command. This allowed end users to
discover the names of various commands accessible to system administrators.
3.2.9) Gaining administrative privileges
Due to an oversight in the way administrator permissions are assigned to
Battle.net accounts, it was at one time possible to overwrite the account of
an administrator with a new account and keep the special permissions otherwise
associated with the account. (An account can be overwritten like so if it has
not been accessed in 90 days). This could have very nearly resulted in a
disaster for Blizzard, had a more malicious user discovered this vulnerability
and abused such privileges.
3.2.10) Obtaining passwords
Eventually, Blizzard implemented a password recovery mechanism whereby one
could associate an e-mail address with an account, and request a password
change through the Battle.net protocol for an account at logon time. This
would result in an e-mail being dispatched to the registered address. If the
user then replied to the mail as instructed, they would be automatically
mailed back with a new account password. Unfortunately, as originally
implemented, this system did not properly perform validation on the
confirmation mail that the user was required to send. In particular, if a
malicious user created an account ``victim'' on one Battle.net network, such
as the Asian network, and then requested a password reset for that account,
they could alter the return email slightly and actually reset the password for
the account ``victim'' on a different Battle.net network, such as the USEast
network. This exploit was actually publicly disclosed and saw over a day of
heavy abuse before Blizzard managed to patch it.
4) Battle.net server emulation
Blizzard 'declared war' on the programmers of servers that implement the
Battle.net protocol some time ago when they took the developers of ``bnetd''
to court. As of Warcraft III, they have taken active measures to make life
difficult for developers programming third party Battle.net-compatible
servers. In particular, two actions are of note:
During the Warcraft III Expansion beta test, Blizzard implemented an
encryption scheme for the Battle.net protocol (this was only used during the
beta test and not on production Battle.net). This consisted of using the RC4
cipher to encrypt messages send and received from the server. The tricky part
was that Blizzard had hardcoded constants that were encrypted using the cipher
state, but never actually sent on the wire (these constants were different for
each message). This made implementing a server difficult, as one had to find
each magic constant. Unfortunately, Blizzard neglected to consider the policy
of someone releasing a hacked version of the client that zeroed the RC4
initialization parameters, such that the entire encrypted stream became
plaintext.
After several patches, Blizzard implemented a scheme by which a Warcraft III
client could verify that it was indeed connecting to a genuine Blizzard
Battle.net server. This scheme worked by having the Battle.net server sign
it's IP address and send the resulting signature to the client, which would
refuse to log on if the server's IP address did not match the signature.
However, in the original implementation, the game client only checked the
first four bytes of the signed data, and did not validate the remaining
(normally zero) 124 bytes. This allows one to easily brute-force a signature
that has a designed IP address, as one only has to check 32 bits of possible
signatures at most to find it.
5) Conclusion
Developing a platform to support a diverse set of requirements such as
Battle.net is certainly no easy task. Though the original design could have
perhaps been improved upon, it is the author's opinion that given what they
had to work with, Blizzard did a reasonable job of ensuring that the service
they set out to create stood the test of time, especially considering that
support for all the future features of their later game clients could not have
been predicted at the time the system was originally created. Nevertheless, it
is the author's opinion that a system designed where clients are untrusted and
all actions performed by them are subject to full validation would have been
far more secure from the start, without any of the various problems Blizzard
has encountered over the years.
05-22-2007, 02:24 AM
Inside Battle.Net
Similar Threads
