######################################################################
Application: Half-life (and all the mods that run on it)
Version: All the versions (1.1.0.9 vulnerable too)
Bug: Wrong management of the players in multiplayer game
Risk: The multiplayer server can be filled with fake players,
so nobody can play in that server.
Author: Auriemma Luigi (e-mail: bugtest at sitoverde.com)
######################################################################
1) Introduction
2) Bug
3) The Code
4) Fix
5) Philosophy
---
1) Introduction
This bug has been showed to Valve and the support of Sierra at the
following mail addresses over 1 month ago: contact@valvesoftware.com
and support@sierra.com.
Unfortunally nobody has answer to my mails (2 mails to Valve), but
I have decided to publish this all the same so if Valve don't release
patch somebody else can try to solve the problem...
---
2) Bug
The protocol of Half-life multiplayer server is simple, and I have
seen that it is really similar to the Quake3 protocol, but this last
is compressed or ciphred.
However the handshake beetween the client and the server (default port
27015) is the following:
- the client send an UDP datagram to the server with the a challenge
request.
The request is: "\xff\xff\xff\xffgetchallenge\n"
- the server send the key of the current challenge to the client.
This key change when Halflife start.
(a little strange thing is that the key sended by the server is an
unsigned int but the client read it as an int (???))
- the client now have the key so for complete the handshake it send
the connection request:
"connect %protocol %challenge_key %cd_key %player_info"
%protocol can be get by querying the server with an info request
but it is not useful, the %challenge_key was get, the %cd_key is
a key generated with the cd key inserted during the installation.
With a same %cd_key, in the same server can play max 4 players, so
we use a key filled with random chars and we can insert infinite
player from the same IP.
EACH PLAYER MUST HAVE AN UDP SOURCE PORT DIFFERENT!!!
%player_info is a set of not important options to send to the
server for give info about the new player.
- now the handshake is finished and for the server a new player is
entered, but it is WRONG!!!
Now the server answer with an acknowledgement, where we can see
our IP and our port.
If the server have reached the maximum number of players, it will
answer with "Server Full", and if the challenge_key that we have
sended to it is wrong, it will answer with "Bad Challenge".
Naturally exist a timeout for the players connected to the server
and it is 60 seconds (default).
So every 60 secs (or less) the attacker can "create" new players so
the server will be filled forever and the real players that want to
play in it will receive a "Server full" message.
The server admin can only see that the maximum number of players is
reached, but when he watch the names of the players in his server, he
found nobody!
---
3) The Code
I have attached a proof-of-concept of the attack that run on Linux
and Win.
Other detailed info about the attack can be found in the code.
The UDP packets are not spoofeds but we can control the real
situation on the server, because it send to us messages as "Server
full" and "Bad challenge" if the key as changed (this key change every
time that Half-Life is started).
A spoofed version of the code is possible but, as I have explained
before, we cannot control if the server is up, if the maximum number of
players has been reached, if the key is changed, and others.
I have also attached an utility for see info about the Half-life
servers only for fun.
---
4) Fix
No official fix available.
A possible fix is to set a password, so only if someone know it can
attack the server, because if the attacker don't know the password,
the server will answer with "BADPASSWORD".
---
5) Philosophy
It's not rigth to post an advisory if there are not patches or
tricks to fix the bug, but I think that this is a good method to show
the problem to the community.
Then the Valve team don't have answer to me and I hope that this
advisory can get their attention.
I'm really hopeful about the full disclosure, because with that
"everyone" can know the real effects of an attack, the real danger of
a bug, someone can learn a bit of programming (I have learn a bit of
C from the source code of some exploits) and it's useful for all the
people that are hopeful in this type of disclosure.
No secrets!
---
Any type of feedback is really welcome!
Byez
---
Crea, espandi e gestisci la tua mail da numero verde, senza scatti telefonici !
Questo ed altri servizi da numero verde solo su http://www.sitoverde.com
Info promozioni web Aziende: 011 274 10 92 edimedia@edimedia.com
Attachment:
hl.zip
Description: Half-life advisory & code
