The PACKET 0' DEATH FastTrack network vulnerability
===================================================

Vulnerability Overview
----------------------
There exists a vulnerability in the FastTrack network
core that can be used by an attacker to take control
of all FastTrack network supernodes. The attacker can
either crash all supernodes or insert arbitrary code
in each supernode's address space. Crashing all
supernodes means that no-one can search for files on
the FT network or connect to the FT network.

A little FastTrack network background
-------------------------------------
The FastTrack (FT) network is the most popular p2p
network in use today. At any given time 3-5 million
people are connected to the FT network, and even more
people have an FT client application, such as Kazaa,
iMesh, or Grokster, installed on their computer.
According to Sharman Networks (owner of Kazaa), Kazaa
has been downloaded over 228 million times and each
week 2.5 million people download Kazaa.

The FT network is a decentralized network, and each
client must connect to a supernode to be able to
search for files. The most recent supernode list is
stored in the registry. Up to 200 supernode IPs and
ports can be stored. Not everyone can become a
supernode. To become a supernode you must have a
Windows NT/2000/XP OS, enough RAM, fast enough CPU, a
non-local IP, fast Internet connection, and various
other requirements imposed by the application itself.
Each supernode typically has 100-300 clients connected
at a given time, but it's possible to have up to 1000
clients per supernode, but Kazaa internally limits
this to 600. This and a lot more FT network options
can be easily changed by whomever controls the FT
network. Only they have the private RSA key needed to
sign the FT network options packet (stored in the
registry as network_config once authenticated). They
also can use that packet to send update notifications
to all clients. Last time this happened was when Kazaa
v2.0.2 was released, which probably was sometimes in
Oct/Nov 2002.

To protect the FT network from people who wants to
reverse engineer the protocol, the owners of the FT
network added encryption to all supernode packets. The
encryption seems to be made by the FT network
creators. Nothing else is encrypted, such as files
transferred to other users.

Vulnerability Information
-------------------------
Packet 0 (possibly called "KAZAA_CONNECTION_INFO", but
from here on called "Packet 0' death", note the zero)
is used to send up to 200 supernode IPs to clients and
supernodes. The supernodes' packet 0' death handler
(possibly class "supernode_connection_t") is different
from the other packet 0' death handlers, and it also
contains the buffer overflow bug. The supernode packet
0' death handler assumes only 200 supernode entries
can be received, but if you send more you can
overwrite the return address and more of the stack.

The size of the packet must be a multiple of 8 bytes
or the whole packet is ignored, and since max packet
size is 65535 bytes, a total of 8191 supernode entries
can be sent. Of these 8-byte entries, only the first 6
bytes are stored on the stack. This means that you can
send 49146 bytes of code to each supernode. If more is
required the code could download the rest manually.
Format of each entry:

DWORD = Supernode IP in network order.
WORD  = Supernode port in network order.
BYTE  = Can't be used by attacker's code. Set it to 0.
BYTE  = Can't be used by attacker's code. Set it to 0.

The IP and port fields are later BSWAP'd by the FT
code.

The IP cannot be a private IP address. Kazaa v2.0.2
considers these IP ranges to be private and ignores
all packet entries with private IPs:

* 127.b.c.d
* 10.b.c.d
* 0.b.c.d
* 172.16.0.0 - 172.31.255.255
* 192.168.c.d
* 255.255.255.255

Also, the supernode port cannot equal 0000h. Kazaa
ignores all entries whose port equals 0.

I tested executing code a couple of times, and it may
only work about 50% of the time since the stack
sometimes has another address. Instead of executing
code the supernode will just crash.

Since executing code doesn't work all the time, a
possible exploit could first download all supernode
IPs and ports from the supernode. Then send the packet
0' death and try to execute code. If the infected
supernode doesn't reply back within say 30 secs, we
can assume it crashed. If it didn't crash, ignore all
supernode IPs we downloaded and let the infected
supernode use them. Now try next supernode. When no
more left, call ExitProcess.

With Kazaa v2.0.2, all that is required to crash the
supernode is to send 203 entries. Example: Send packet
0' death, 203 entries all equal to: 0FFFFFFFEh,
0FFFFFFFFh.

Discovery
---------
I discovered this vulnerability either in Dec 2002 or
Jan 2003 when writing K++
(http://www.geocities.com/random_nut/). Since there
will soon be Open Source FT implementations using the
FT network I notified Sharman Networks (owner of
Kazaa) and Joltid (owner of FastTrack network). I
waited 2 weeks but didn't get a reply.

Affected programs
-----------------
Kazaa v2.0.2 has been tested. But it's very likely
that this bug is present in previous and later Kazaa
versions, such as the latest Kazaa v2.1.0 which was
released a couple of months ago. It's also very
possible that iMesh and Grokster also are affected.

Testing
-------
I used a modified K++ to make two of my computers
supernodes, and then sent a command to the other
supernode to crash it. Kazaa v2.0.2 was tested. I
don't have any intentions at the moment to release any
exploit code since all script kiddies in the world
would use it to close down the FT network or parts of
it.

Contact
-------
random_nut@yahoo.com - I don't check it often, though,
so be patient. ;)

Misc
----
http://www.geocities.com/random_nut/ - K++
http://www.kazaa.com/ - Owner of Kazaa
http://www.joltid.com/ - Owner of FT network


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html