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