DC++ and DDoS attacks – the full story

Hello, (security) world!

This is my first post on StormSecurity blog and I am going to talk about a paper I wrote called DC++ and DDoS attacks. This is a rather old subject (2007) but this kind of attack can hit a server anytime even in nowadays and there are not so many companies out there prepared to handle it. This paper describes in detail the anatomy of such an attack and also talks about a tool I wrote – HubMonitor– that is able to detect the attacker hubs. You can download it from here.

The paper is intended to be a full reference on this topic but I am going to highlight here the most interesting ideas of it.

What is it about?

I believe many of you used or still use the DC++ network to download or upload files. It’s not a secret although most of the time is not a legal activity. The DC++ network is pretty much spread around the world and there are many people using it. But what they don’t know is that they could participate anytime in a devastating DDoS attack against a victim server. The DC++ clients won’t know this and they would not care either but the victim server could be easily shutdown because of them.

Last year, there were many reports of DDoS attacks against web servers: Prolexic, SecurityFocus, etc. People started to patch DC++ hubs but…

Why is this still actual?

Do you know who are the persons that own the DC++ hubs you connect to? Most probably no. So you can’t trust them. You can’t know if they will use your DC++ client in a DDoS attack or not. And they COULD do that anytime. You won’t know it but others will suffer.

There still are many unpatched hub servers out there (Verlihub-0.9.8c, Verlihub-0.9.8d-rc1, Ynhub < 1.0306, Ptokax < 0.3.5.2) and others have custom backdoored hub software that can be used anytime to generate a DDoS attack.

Connections hitting the victim:

connections/sec = hub_no * hub_clients * $CTMs/sec
where:
hub_no = number of hubs participating in the attack
hub_clients = average number of clients on each hub
$CTMs/sec = number of $ConnectToMe commands received by each client per second

For a moderately big attack, the variables are:
hub_no ~= 5
hub_clients ~= 5000
$CTMs/sec ~= 1
=> 25.000 connections/sec

How to stop it?

Lots of money is needed to effectively stop such an attack. Because it is an application layer attack, the good solution is a deep packet inspection capable device but this is very expensive. There are other ways described in the paper to try to defend against it.

But when you want to find the attacker hubs, there’s a real problem. The packets reaching the victim contain no information about him. Here is where HubMonitorcomes into scene. This application connects simmultanously to many suspected DC++ hubs and listens for attack packets. When it receives specific packets related to the victim server, it declares the hub as attacker and legal measures can be taken.

Conclusion

Although the number of DDoS attacks generated using DC++ network has decreased, hacker teams could set up anytime such an attack against a victim server and the intensity of the attack could easily overwhelm it. HubMonitor is a tool that can be used to find the attacker hubs. You can find more details about it and about this kind of attacks in my paper.

Advertisements

12 Responses to “DC++ and DDoS attacks – the full story”

  1. […] they look legitimate to classic firewalls and easily pass  through them (for an example look here). The only way to stop this kind of attacks is deep packet inspection (layer 7 inspection) which […]

  2. Great article, good job! However, I hope not to get in the situation that would require me to re-read it 🙂

  3. Thanks a lot for a great article. My website was attacked a few days ago by the same method you described in your paper. I found out that simply dropping the packet is better than sending tcp-reset because socket is released faster.

    I have downloaded and compiled your HubMonitor software. It was compiled and run, but I have not figured out why it keeps failing on resolveName() error. The hub I tried is online and resolved in DNS.

    Thanks

    • stormsecurity Says:

      Thanks for your feedback!
      About the name resolving problem, make sure that you specify the hub address in the right format (hub_name:port) in the configuration file.

  4. I got HubMonitor working. The program just does not read XML format.

    Thanks

    • stormsecurity Says:

      It was not designed to read XML format. The input file should contain on each line entries like:

      hub_name:port or hub_ip:port

  5. might wanna add a little something since i belong to the dcpp development team that we added a little bit to client called REF that refers where the CTM came from since then DDoS traffic like this has dramatically dropped

    http://www.adcportal.com/wiki/index.php/REF

    might be a little late adding this but i thought since its getting hits that it was worthwhile

  6. Well all it takes are some to get useful data out of a CTM DDoS only one updated client will betray the hub thats used for malicious purposes that seems too put a stop to the hardcore CTM DDoSers since they don’t want abuse complaints hailing over them via their ISP.

  7. […] dar nu are rost. Mulţumesc Domnului Ing. pentru document , voi îl puteţi downloada de aici : https://stormsecurity.wordpress.com/2008/08/11/dc-and-ddos-attacks/ Articole asemanatoare:RussKill. Application to perform denial of service attacksProiectele […]

  8. […] HTTP DDoS com solicitações inválidas (semelhante a um ataque de DC + + ) […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: