Part 2: CTM Review and the errors of past

Site Announcements
Locked
Toast

Part 2: CTM Review and the errors of past

Post by Toast » 27 Jan 2009, 09:31

I was requested to explain how the CTM exploit works, without the technical terms. So here we go:

CTM stands for "connect to me", and its a part of the NMDC protocol, in the old hubsoft there was an options that allowed the hubowner to turn off the check if the sender of the CTM request had the same ip, now we all know about the patch that was included in sDC++, the infamous "Someone is trying to use your client to spam x.x.x.x..." didn't have that much effect, users mostly found it annoying, but it was a really good effort by Big_Muscle, since it was one of the first measures in defining this problem on Direct Connect.

Now CTM Checking in NMDC hub software can be turned off for some reason and that is how an attacker can exploit the hub. I'm going to try and explain how its done in a human way so everyone can understand.

Now if that option is turned off, an attacker comes in and requests everyone in the hub connects to him at another ip (the place he wants attacked), now every client is trying to connect to that place so if the hub contains 1000 user these 1000 users are now trying to connect to that site at the rate the attacker wants to set, since he/she is is controlling the rate of the attack with his CTM requests.

Now with the upcoming protocol change for NMDC, the clients will refer to the hub the CTM was sent from, meaning that attacked parties have some means of tracing where the attack came from.

Here are the options that must be checked in order to be listed at hublists these days.

Verlihub 0.9.8C and older
  • To determine the hub to ignore wrong CTM's: !set check_ctm 1
    To determine the hub to check CTM's and kick the user: !set check_ctm 3
    To determine the hub to check active searches: !set check_asearch 1
    To determine if the hub is set up correctly: !getconfig
Verlihub 0.9.8D and newer
  • To determine the hub to check CTM's and kick the user: !set check_ctm 1
    To determine the hub to check active searches: !set check_asearch 1
    To determine if the hub is set up correctly !getconfig
YnHub
  • go to Security, General Security and enable this option: Check sender ip on ConnectToMe and Search
PtokaX 0.4.x.x
  • go to Settings, Advanced, Advanced security and be sure that the option to Check if user send correct ip in protocol command (DDoS protection) is enabled.
PtokaX 0.3.5.2 or 3.6.0.0
  • go to Settings,then Options tab and make sure that the option to 'Check user IP in commands' is enabled.
Its not recommended to run than 0.3.5.2 haven't got this option so potentially insecure.

Now, what can we do for the future? Well, I'm going to give some suggestions at the end of this article, in the meantime we still have a problem with malicious scripts that have been made for Verlihub that allow the hubs to send fake CTM's to users in order to facilitate DDoS attacks.

the loophole that allows the hub to send fake CTM's could be patched so that LUA or Python plugin doesn't have access to call CTM functions, also the protocol change will help pinpoint the hubs in order to shut them down, by abuse complaints.

I'm not sure if Hexhub and Ptokax allows sending of fake CTMs as well, but if they do then NMDC has huge problems ahead and the developers should take care of it if that is the case (this part needs verification).

I know that this bug has been discussed alot and but in the background and there has been a whitepaper written about it and it is a bit crude... of how its done, in any case its just a matter of time before a security advisory number is made of this bug since there are plenty of exploit tools out there right now for users to download and abuse.

These are corrupted hubs in which case some other things need to be done :
  • Implement Poys patch into clients
  • Implement some protection in the client, as suggested here
  • make hubs more secure an option is signing
  • hublists should implement the anti CTM system

Pietry
Senior Member
Posts: 328
Joined: 04 Dec 2007, 07:25
Location: Bucharest
Contact:

Re: Part 2: CTM Review and the errors of past

Post by Pietry » 27 Jan 2009, 11:34

Very good point, all the community not just ADC should be aware of all this and start the movement to change something.
Just someone

Toast

Re: Part 2: CTM Review and the errors of past

Post by Toast » 27 Jan 2009, 11:38

The only hubsoft that still has major issues is ynhub its still being exploited even with the patch by redirect bots and the developer really dont do anything on the site at all so my next article is about badware :)

Dj_Offset
Member
Posts: 53
Joined: 15 Sep 2008, 21:48
Location: adcs://adcs.uhub.org:1511
Contact:

Re: Part 2: CTM Review and the errors of past

Post by Dj_Offset » 27 Jan 2009, 13:57

Note, not checking the IP of a CTM does not save bandwidth, quite on the contrary.
It does require a *little* (as in not even remotely noticable) more processing, and if the IP does not match, then do not allow the message to be broadcasted --- bandwidth SAVED!

HaArD
Junior Member
Posts: 15
Joined: 27 Oct 2008, 20:23

Re: Part 2: CTM Review and the errors of past

Post by HaArD » 27 Jan 2009, 14:24

As DJ_Offset mentioned there is no bandwidth cost... and if a CTM is prevented bandwidth is actually saved.

I think crippling the script API to prevent access to CTM is a bad idea. Anyone who would run a hub with a script that used the CTM exploit could just as easily run an older hub that didn't prevent the script from working. The only people hurt would be script developers who interact with CTM for legitimate/useful purposes.

It's also worth mentioning that any hubsoft built from the SDCH source for example DDCH (http://devdch.com/) and PTDCH (http://www.ptdch.com/) are immune to this exploit and always have been since CTM checking is built into the core and is not an option that can be turned off (I've never understood the option... when is an incorrect IP on a CTM acceptable???) .

Pietry
Senior Member
Posts: 328
Joined: 04 Dec 2007, 07:25
Location: Bucharest
Contact:

Re: Part 2: CTM Review and the errors of past

Post by Pietry » 27 Jan 2009, 14:54

Even if this is built into the core, it doesn't mean somebody can't read the source and remove the check, and spread the bad version among malevolent people so that they could flood with it. So the solution is to do some protection in the client and hublists
Just someone

Toast

Re: Part 2: CTM Review and the errors of past

Post by Toast » 27 Jan 2009, 21:23

Edited a bit the CTM bandwidth part

HaArD
Junior Member
Posts: 15
Joined: 27 Oct 2008, 20:23

Re: Part 2: CTM Review and the errors of past

Post by HaArD » 27 Jan 2009, 22:53

Pietry, Totally agreed... a client side reference back to the source on the actual connection (The Ref: proposal) is the most effective as it neuters the ability of any hub, even a corrupted hub, to inflict an untraceable DDOS. It's dead simple to modify the source to make a hubsoft an effective tool for this bypassing an build in protections or ignoring settings, but it's damn difficult to convince people en masse to download any new client (this is even true for a new release of the DC++ core but in time it will get our there...)

poy
Member
Posts: 78
Joined: 26 Nov 2008, 17:04

Re: Part 2: CTM Review and the errors of past

Post by poy » 28 Jan 2009, 14:52

HaArD wrote:but it's damn difficult to convince people en masse to download any new client (this is even true for a new release of the DC++ core but in time it will get our there...)
the good thing about Jan's way is that even if only a few do upgrade, referrers will still be found in logs.

Locked