This site uses cookies. In order to read how we handle cookies please click here. Click on this message to accept and hide.
Go to top

Second largest exploit in NMDC history

Hi all good and bad DC users and developers out there.

I guess it's time to reveal second largest exploit in NMDC history that I found about 9 months ago. Do you remember the good old CTM exploit discovered by Team Elite back in 2006? Well, this one is pretty much alike.

How does it work?

Extremely easy I would say, all you need to do is to send malicious active search request to any vulnerable hub:

How it should be
$Search F?F?0?1?mp3|

How we do it
$Search F?F?0?1?mp3|

Where is your own IP address and is the target IP address with port number that we would like to flood using UDP traffic. In most cases your own IP address needs to be real, because the hub might ignore your search request or even kick you due to mismatch between your real IP address and the one stated in the request.

If the hub is not filtering requests with invalid port number, a vulnerable hub, it will broadcast the message to all its users. Each user who shares any MP3 files on the hub will then respond by sending 10 search results using UDP traffic to address mentioned in our example.

That is one malicious request in one hub, now imagine thousands of bots sending these malicious requests non stop to several public hubs with 5000 users on each, you should be able to hear a bomb exploding on target side. I did alot of tests actually, and came up to receiving traffic at speed of 1 Gbit/s, at that point hardware limits were reached. It should be possible to push the record even higher with better hardware. smile

What is servers mistake?

In above example the server takes as the IP address of the request, which is correct, and // as the port number of the request. Does the second part look like a port number? Not to me, but to server it does, sadly.

What is clients mistake?

In above example the client takes as invalid protocol of the request, and as the IP address and port number of the request, which are correct. I keep wondering for long time, but can't understand yet why DC++, StrongDC++ and other clients apply function Util::decodeUrl on active search request address. I was on the other hand very glad when I saw that clients didn't apply that function on active CTM request. biggrin

Which servers are vulnerable?

The only hub software that initially did check for invalid port in CTM and Search request was FlexHub, any other hub servers were forwarding the requests as is, allowing the exploit. I fixed the exploit in Verlihub 1.0.0 RC2 as of 2014-06-14 and about same time Lord_Zero fixed it in his HeXHub. Today we can see that most largest hubs on DC run PtokaX, which is still vulnerable. It is now known that exploit has been fixed in PtokaX version as of 2015-02-20.

Which clients are vulnerable?

Every single one of them are. I was only looking at DC++, StrongDC++ and few other based on them. The exploit is fixed in AirDC++ version 2.91 and in all FlylinkDC++ versions since 2015-02-21. DC++ fixed the bug since release version 0.851 and ApexDC++ since version 1.6.2 released on 2016-05-28. StrongDC++ and ApexDC++ are is still vulnerable.

What's the most interesting part?

The most interesting part about this exploit is that UDP protocol is portless, meaning that target server will receive all UDP traffic regardless of any open ports or firewalls at server level. By sending as much traffic as target server download speed allows, you will overwhelm the target connection and the server will no longer receive and respond.

What can we do about it?

Fix this, sure, but how? If we look back at CTM exploit, yet today we see hubs that don't check for valid IP address in CTM requests, from that we can learn that there will always be hubs running old vulnerable hub servers even after 10 years. By that I'm trying to say that first of all fix should be implemented in DC clients, to protect its users.

Final words

I'm not sure if this is a mistake initially made by server developers or client developers, probably both are involved equally. No matter the answer, this exploit is the second largest exploit after CTM, and it's standing before you.

I'm really proud to present this exploit for you because DC developers need to learn and to see what they are doing, to stop making such trivial mistakes.

Have fun fixing your servers and clients, and ofcourse get prepared for people flooding each other using this exploit, that's what humanity has always been doing - making war against eachother.
Posted by RoLex on 2015-02-08 12:42 3 comments 9 likes

Ledokol Ledokol 2.8.5

Changes in 2.8.5
Fixed: Correctly send $NoReport command to pingers, report by S0RiN
Fixed: Check syntax of oldclean command, report by KCAHDEP
Fixed: Don't notify user commands as messages sent to hub security
Fixed: Missing ban time when adding forbidden MyINFO parts
Changed: myinfadd command parameter syntax to <type> <"lre"> ["time"] ["note"]
Changed: Modify existing forbidden MyINFO item when it's added again
Changed: Restrict access of forced infected user detection report to AVDB
Changed: Replace new line character with space in antivirus detection file names
Changed: Country code gag now uses LRE instead of country code, request by KCAHDEP
Added: Optional parameter to add note for each forbidden MyINFO item, request by Uhlik
Added: Cache for protected users list, it's called too often, we don't want to put high load on MySQL server
Added: lretoplain command to convert LRE to plain text, idea by KCAHDEP
Added: histshowipclass configuration to show user IP in main chat history to users with set class and above, request by KCAHDEP
Removed: Messages on hub restart and stop, hub itself will do that for us

File information: Ledokol 2.8.5
Posted by ledokol on 2015-01-08 18:40 0 comments 1 like

Merry Christmas

Merry Christmas 2014 by WiZaRd
Posted by WiZaRd on 2014-12-20 19:46 0 comments 1 like

Ledokol Ledokol 2.8.4

Changes in 2.8.4
Fixed: Correctly remove user from operator ranks when he deletes his own registration
Changed: User registration notification now rely on plugin callbacks instead of command scans
Added: Public user registration notification for all classes, empty regnewpubmsg* to skip notification for that class, idea by KCAHDEP
Added: cURL will use same local address for connections as hub itself when defined
Added: cURL helper function now returns response headers if requested
Added: Avdb-Version-Count and Avdb-Delete-Count extension headers to use with AVDB load process

File information: Ledokol 2.8.4
Posted by ledokol on 2014-11-17 14:38 0 comments 0 likes

Verlihub Verlihub 1.0.0-RC4

Now with automatic crash report.

Changes in 1.0.0-RC4
Changelog is available on

File information: Verlihub 1.0.0-RC4
Posted by verlihub on 2014-11-17 14:26 0 comments 0 likes