[Full-Disclosure] The PACKET 0′ DEATH FastTrack network vulnerability

Oder: ‚the possibly biggest DDOS on earth ever since‘ kurzum … erschreckend

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

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

* Die DSGVO-Checkbox ist ein Pflichtfeld

*

Zustimmung zur Datenspeicherung lt. DSGVO