Detecting and preventing CTM attacks

In the last months CTM exploitation of vulnerable hubsofts has become the most common form of attack used on DC against other hubs, users, web sites, etc. Many "DDoS tools" are being shared on hubs and on some websites, making these attacks easier and accessible for everyone.
This raises the following problems:

Filtering the traffic caused by CTM exploitation
Detecting if a hub is vulnerable
Finding hubs used to attack someone
Setting existing hubsofts to prevent exploitation
Possible implementations for hubsoft authors that can prevent CTM exploitation
Client-side verifications

The following information is gathered from various sources and presents possible sollutions for these problems. Some of them are implemented, others are under development.

1. Filtering the traffic caused by CTM exploitation

For hubsoft and client developers two firewalls are available that can successfully filter the DDoS traffic caused by the use of CTM exploit - DDoSflt and WFP.

File name	Size	Last update	Description
wfpfirewall21.zip	154798	2008-01-05, 20:06:58	[2008-01-05] WFP Firewall 2.1, all binaries in this package require Microsoft Windows Vista or Microsoft Windows Server 2008 or newer. Install instructions can be found in readme.txt. Copyright © by Morten Larsen, 2007-2008.
DDoSflt105.zip	17527	2008-01-06, 06:32:46	[2008-01-06] DDoSflt firewall, requires Windows NT, 2000, XP, 2003. Copyright © by Albu Cristian, 2007.
DDoSflt106.zip	17793	2008-01-12, 12:14:46	[2008-01-12] DDoSflt firewall, requires Windows NT, 2000, XP, 2003. Copyright © by Albu Cristian, 2007.
DDoSflt107.zip	18032	2008-01-14, 08:13:22	[2008-01-14] DDoSflt firewall, requires Windows NT, 2000, XP, 2003. Copyright © by Albu Cristian, 2007.
DDoSflt108.zip	18463	2008-01-16, 08:55:14	[2008-01-16] DDoSflt firewall, requires Windows NT, 2000, XP, 2003. Copyright © by Albu Cristian, 2007.
Functions.zip	3357	2008-01-16, 08:55:50	[2008-01-16] Information on how to implement the use of these firewalls in applications other than HeXHub.
DDoSflt109.zip	19217	2008-04-25, 14:34:58	[2008-04-25] DDoSflt firewall, requires Windows NT, 2000, XP, 2003. Copyright © by Albu Cristian, 2007.

2. Detecting if a hub is vulnerable

CrazyGuy wrote a freeware program that can be used as a proof of concept for detecting CTM settings of a hubsoft.

File name	Size	Last update	Description
CTMChecker.rar	23287	2008-05-07, 21:28:04	[2008-05-07] Project's executable.
CTMChecker_TestResults.rar	5769	2008-05-07, 21:28:20	[2008-05-07] Test results that include several tests on PtokaX, HeXHub, VerliHub, YnHub and 1 YHub.
CTMChecker_Source.rar	76311	2008-05-07, 21:28:34	[2008-05-07] Project's source code (Visual Basic .Net).

Some more information has come to hand.

In Verlihub 0.9.8c it is possible to "overload" the hub making the CTM check fail even when enabled (source Verlihub developer)
YnHub 1.02 - 1.033 have by default an IP check override for Owner profile (source netcelli , own tests)
YnHub 1.036 have by default only profiles Registered and Regular. Creating a new profile does not by default enable IP override (source own tests)
It is in HexHub not possible to disable the IP correction in CTM, only to disable kick and notification (source Lord_Zero, own test, dchublist)
HexHub does allow to have wrong IP send to self only. Meaning a CTM from User A to User A will not be corrected. This to fool bots looking for this exploit (source Lord_Zero)

This would mean Verlihub 0.9.8c is a bit "unsafer" than at first expected. An upgrade seems mandatory.
YnHub 1.036 is a bit "safer" than 1.033 , however most people upgrading hubsoft will configure the same profiles with the same rights as in previous versions, this appears to be standard behaviour.
HexHub can be considered just as "safe" as VerliHub 0.9.9a where broadcasting a wrong IP is not possible

I've done a few more tests and feel that the program now is reliable enough to be used as a proof-of-concept.
Note that it is not coded to run as an optimized application. It does what it's suppose to do, and that's it.
I have not added any code for reconnection and such, so you will have to restart the program after each test.

Project is made with Visual Studio 2008, solution files included.
Project language : Visual Basic .Net
Test results include several tests on PtokaX, HexHub, VerliHub, YnHub and 1 YHub.

Source: CrazyGuy (The Nighthawk Forum)

3. Finding hubs used to attack someone

The following methods can be used to detect the address of a vulnerable hub:

Using the user search feature provided by some hublists to find the users that send $MyNick commands and finding the most common hubs where they can be found. Some hubsofts do these searches automatically.
Hublist pingers can detect vulnerable hubs, as described below.

Written by yours truly - With collaborative contributions from the following individuals:
Lord_Zero
Introduction
   Hubs today are not like they were years ago. Today, there exist many people using hubs for malicious purposes, and it is this exact thing that should raise concerns to people who run hublists.

   A good hublist will provide a reliable service to both hubowners and users. The hubowners should be provided with a reliable server that will be always available for their needs and supportive in its responses to questions. The users of a hublist should be provided with a safe, impartial, and neutral list of hubs which not only consist of real users, but also do not compromise the experience of the user.

   The experience of a user can be compromised by the following: The use of their client to participate in an attack against another server.

   To ensure that the occurences of such compromise are minimized, certain measures can be taken. This page describes the known process of implementation of such a detection, which is a simple process that only takes a little bit of modification of your pinger. Feel free to discuss this idea further in QSDC DAG Public Hub, where QSDC, NMDC, and ADC are freely discussed, at qsdc-public.qsdc.org:2424 . Your input, if approved, will be added here with proper credit and acknowledgement.

Implementation
   The simplest way to implement CTM detection is to keep track of the CTM count from a hub during a ping session. Most hubs send you CTM data after sending the MyINFO collection, and if you have sent $BotINFO early in the handshake, they will just immediately send $HubINFO after it sent the MyINFOs. There is a simple way around this. After $HubINFO is received, the pinger can linger for a few seconds in the hub to keep track of CTMs. If two or more of the addresses in a 3+ CTM collection are the same, it is likely that the hub is being used to ddos someone, and should be either banned or notified of its vulnerability. The most effective treatment for such hubs is a ban, since many hubowners use their own hubs to CTM flood and do not have any regard for warnings. Your best bet is to round up CTMs from a hub within a 5 second period of time. If there are 3 or more CTMs, check the IPs for any doubles. If all 3 IPs are the same in the collection, you are very likely to have a CTM attack. You can also store an array of structures containing each an IP address detected along with how many times it recurs. If the time of recurring is more than one third of the CTMs detected, and CTMs count in the session is more than 3, the hub is likely being used to attack.

   It must also be noted that the detection described in the above paragraph does not work for all hubsofts due to a number of reasons. The following are possible ways that the detection above cannot be performed:

Some hubsoftwares disconnect the pinger once the pinging is finished, not letting it linger to get traffic afterwards.
Some hubsoftwares do not allow CTMs to be passed to pingers.

   The way these two circumstances can be worked around is to have two bots log into each hub. One bot will be the actual pinger, and another bot will login as a normal user to detect any traces that make a CTM flood evident. In any case in which both instances cannot connect to the hub, the bot that made it into the hub can manage the task of traffic detection. This scenario was presented by Lord_Zero and, if the solution to such the problem scenario is implemented, will make detection of CTM floods even more accurate.

Example
   2/7/2008 10:23:28 PM *** Received CTM from: rotsman.bounceme.net:415 - RockyPinger 216.220.40.244:80
   2/7/2008 10:23:28 PM *** Received CTM from: rotsman.bounceme.net:415 - RockyPinger 216.220.40.244:80
   2/7/2008 10:23:29 PM *** Received CTM from: rotsman.bounceme.net:415 - RockyPinger 216.220.40.244:80
   2/7/2008 10:23:30 PM *** Received CTM from: rotsman.bounceme.net:415 - RockyPinger 216.220.40.244:80
   2/7/2008 10:23:33 PM *** Hub is banned for CTM Floods: rotsman.bounceme.net:415 - Number of packets: 6

Source: The Architect (QSDC Hublist Forum)

4. Setting existing hubsofts to prevent exploitation

HeXHub - all versions replace IPs sent in CTM with user's IP, there is no setting to disable CTM check. All commands are corrected by hub.
Verlihub 0.9.8C and older
   To determine the hub to ignore wrong CTM's: != check_ctm 1
   To determine the hub to check CTM's and kick the user: != check_ctm 3
   To determine the hub to check active searches: != check_asearch 1
Verlihub 0.9.8D and newer
To determine the hub to check CTM's and kick the user: != check_ctm 1
To determine the hub to check active searches: != check_asearch 1
YnHub - go to Security, General Security and enable this option: Check sender ip on ConnectToMe and Search
PtokaX - 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.

5. Possible implementations for hubsoft authors that can prevent CTM exploitation

Currently, the following methods are implemented to prevent the use of CTM exploit:

Verifying sender's IP and ignoring wrong CTM's
Verifying sender's IP and kicking the user if a wrong CTM is detected
Replacing the IP in CTM with user's IP (all HeXHub versions prior to 5.01j)
Replacing the IP in CTM with user's IP if the CTM is sent from a LAN to a LAN user or a WAN user to a WAN user and replacing the IP in CTM with hub's external IP in a CTM sent by an active LAN user to a WAN user or by localhost to any user (HeXHub 5.01j or later)

6. Client-side verifications

The following verifications can be done by a client to detect or to help detecting a CTM flood:

Checking for ports dedicated to common services (like 21, 80, 411, 1411, 4111, etc.). Usually ports lower than 1024 are not set by active users in their clients.
Checking if a client sends a DNS instead of an IP address in a connection request
Detecting slot hammering from users (restricting connection requests to a specific rate)
Op clients can show connection requests in mainchat, operators can verify if there is a user who has the IP given in a CTM

No Comments