| 2015-02-08 18:04:10 |
poy |
description |
http://te-home.net/?id=54&title=Second+largest+exploit+in+NMDC+history
Original announcement as of in 2015.02.08 : http://pastebin.com/SVpUGnNe |
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 2004? 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 2.3.4.5:12345 F?F?0?1?mp3|
How we do it
$Search 1.2.3.4://2.3.4.5:12345 F?F?0?1?mp3|
Where 1.2.3.4 is your own IP address and 2.3.4.5:12345 is the target IP address with port number that we would like to flood. 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 request with invalid port number, 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 2.3.4.5:12345 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 1.2.3.4://2.3.4.5:12345, the server takes 1.2.3.4 as the IP address of the request, which is correct, and //2.3.4.5:12345 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 1.2.3.4://2.3.4.5:12345, the client takes 1.2.3.4:// as invalid protocol of the request, and 2.3.4.5:12345 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 others apply function Util::decodeUrl on active search request address. I was on the other hand very happy 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. Later I fixed this exploit in Verlihub and Lord_Zero fixed it in HeXHub. Today we can see that most largest hubs on DC run PtokaX, which is still vulnerable.
Which clients are vulnerable?
Every single one of them are. I was only looking at DC++, StrongDC++ and others based on them though.
What's the most interesting part?
The most interesting part of 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 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.
Refs:
- <http://te-home.net/?id=54&title=Second+largest+exploit+in+NMDC+history>
- <http://pastebin.com/SVpUGnNe> |
|
