########################################################################
Application: Unreal Tournament (Win version, Linux and Mac not tested)
Version: all the version (436 vulnerable too)
Bug: UT servers send a great number of packets to every host
that send only 1 packet to them, for 2 min and 30 sec
Risk: UT servers used as flooders, DDoS risk
Author: Auriemma Luigi (e-mail: bugtest at sitoverde.com)
########################################################################
Sections:
1) Introduction
2) Bug
3) The Code
4) Fix
5) Philosophy
###
1) Introduction
First, I want to say that this bug has been showed to Epic
(utbugs436at_private) over one month and half ago (and I have
resended a request of infos about the bug some weeks ago), but the only
answer that I have received from them has been the auto-reply of the
server!
Then some days ago I have contacted the support of Lokigames that have
worked to the Linux porting of the game (supportat_private) but
no answer (the bug-tracker fenris.lokigames.com is unreacheable).
I think that they are not more interested to UT because Unreal
Tournament 2003 will be ready in some weeks (July if it is all ok).
However I have specified my choose of post this advisory also if no
patches are ready at the moment in the Philosophy section.
- Important:
Some days ago I have found, with some difficult, a discussion started
by Jeff Calvert in the "Vuln-Dev" section of the SecurityFocus's
Bugtraq, a lot of time ago (May 28 2000), that show the problem of do
a DoS with the UT servers, but this discussion was dead after about
some mails.
I think that is INCREDIBLE that a so important and danger problem
(for me a DDoS attack so simple to do is a real risk...) that is
known from the year 2000 already exist.
However it exist and this advisory want to explain it.
---
2) Bug
The UDP is a connection-less protocol so is "normal" that it is
insecure, but UT don't do any control about the packets that it
receives!
However the bug is really simple and really danger, the follow is a
simple example.
First the list of the UT default ports found on the home of the
game, http://unreal.epicgames.com:
* UDP 7775 and 7776 are used only for LAN games. You don't need
to route them through a firewall.
* UDP 7777 is for gameplay (...the dangerous port...).
* UDP 7778 is for server querying.
* UDP 7779+ are allocated dynamically for each helper UdpLink
objects, including UdpServerUplink objects.
* UDP 27900 is for server querying, if you enable the master server
uplink. Some master servers use other ports, like 27500.
Now the example, we have 3 hosts:
A - the attacker
B - the UT server
C - the victim
- The host A send 1 empty UDP packet with the source IP of the host C
to the port 7777 (UT default port) of the host B.
- The host B begin to send about 10 packets/second of the size of 46
bytes to the host C and it will stop to send after 2 minutes and 30
seconds (default UT timeout).
- The host C will receive all these packets and it will reply with an
ICMP port unreacheable message that will be ignored by the host B.
- The host A after 2 mins and 30 secs can restart the attack.
So with this bug an attacker can flood (in anonimity) other hosts.
Every packets that the UT server send have a size of 46 bytes (and
the packets that we send to it are 28 bytes), for this IN THEORY if I
send 156 packets to an UT server with the sender address of an user
that have a 56K modem and the sender port that is different for each
packets (a good choose is to use incremental or random ports), this
last will be flooded with 7200 bytes for 2 minutes and 30 seconds.
The number of packets sended by the server seem to be the same also if
I change the "Network speed" option in the net settings of UT.
Naturally this attack have 2 effects.
The first is the DoS against the victim and than the DoS versus the
same UT server that must send a great quantity of packets, so it use
a lot of network band and CPU.
I think that this attack is a bit similar to the smurf attack, but
UnrealTournament is really a great game with a lot of players and
servers in all the world, so there is no problem to found servers to use
for the attack (for the smurf attack you need misconfigured routers that
are more difficult to found, but with UT you can found servers without
any problem).
For this I think that this bug is really danger and can be used for do
DDoS.
Then I hope that the same error wille not be present in UT 2003, but I
also hope that this problem will be fixed soon.
All the tests, are been made on my LAN on the Win version of
UnrealTournament (v436). (Linux and Mac has not be tested, but it use
the same protocol of sure).
Naturally I have done also some test on Internet and the results are the
same.
---
3) The Code
I have attached the proof-of-concept of the attack, it is called
utflood.c and it must be compiled on Linux.
With little modifications it can be ported to Win (for example using
Winject at http://big.badlink.net).
The others files are a simple program for see info about the server
(hlinfol.c for Linux and hlinfow.* for Win), only for fun.
You can also found a copy of this advisory and an italian version of it.
---
4) Fix
No official fix (sorry).
The only fix that I have found and that is really useful is to set a
different port in the unrealtournament.ini file near the option
"Port=" and change the 7777 with other ports.
But not only this!!!
From the console we must insert the "preferences" command and do the
following for erase the MasterServers support:
- Under "Networking / Master Server Uplink", set "DoUplink" to False
or
- Under "Networking / Server Beacon", set "DoBeacon" to False
The master servers are that servers that contain all the info about
the multiplayer-games in the world, and the most big are:
unreal.epicgames.com and master0.gamespy.com.
However I can't continue, because this is a security advisory not a
DDoS paper...
This is my fix, other suggestions?
---
5) Philosophy
Ok, 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 UT 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
This archive was generated by hypermail 2b30 : Wed Jul 03 2002 - 12:30:57 PDT