Brian, I’m not sure if you’re still looking for information about what Prolexic (and now Netcraft) have reported about attacks using the Direct Connect network.
A little bit of history may help understand what the Direct Connect network is. It got its start in December of 1999 by Jon Hess, then a high school student. It was heavily inspired by Internet Relay Chat (IRC), and the social aspect of chatting can be seen in his design (I have a couple old interviews of him bookmarked at home that may give a little more information). This was the year of Napster, when peer-to-peer networks were getting their start, and before Justin Frankel (of Winamp) had released Gnutella (which first pioneered decentralized peer to peer networks). Direct Connect was designed around separate, user run, independent hubs, tied together only loosely by a “hub list.” This design is a lot more like Napster’s centralization than Gnutella’s decentralization, especially since hubs themselves do not interlink (though there are some protocol commands for doing so.) Because of this design, Jon developed two separate programs: a client software (which we call NMDC for NeoModus Direct Connect [NeoModus was the company name Jon used to publish his software (see the Wayback machine at http://web.archive.org/web/*/www.neo-modus.com)%5D) and a hub software. Each hub software had an option to register on the hub list, but it was not mandatory.
Shortly after it became popular, many people worked on reverse engineering the protocol that Jon used. Once enough knowledge of the protocol was obtained, clients were created, including DC++ by Jacek Sieka in November of 2001. Today, nearly all of the clients on the Direct Connect network are open source, and quite a few hubs are as well. The protocol used today is nearly identical, but (mostly) backwards compatible with the original client and hub. Jon’s software has fallen out of favor, and DC++ is (probably) the most popular client for the network. There are also many derivatives of DC++, since it is licensed under the GNU General Public License. There are a number of hubs, YnHub ( http://ynhub.org/) is one of the more popular ones, since it works on Windows, has a nice GUI, and contains enough options so that hub owners can run hubs the way they like. Hubs have grown, but a “big” hub is well under 10,000 users, and most probably in the 500 – 2500 user range.
The abuse, as can see it, doesn’t exploit any bugs in DC++ per-se. Nothing as glorious as buffer overflows, at least. Only not armoring itself against ways the protocol could be misused to hurt others. The protocol was intended to be proprietary, and wasn’t designed to protect against malicious clients or hubs.
The two commands which are being exploited are the following commands:
$ForceMove <ip or address:optional port>
This command forces a DC client to disconnect from the current hub and try to connect to the address specified. (It is used in some multi-hub configurations to shuffle users between hubs, generally as a form of load balancing.) The original DC hub software had a port of 411, but it allowed customization. A malicious hub can “$ForceMove http://www.example.com:80” to multiple users and get them to try to connect to that server using the DC protocol. In DC++ 0.699 (released Dec. 18, 2006), DC++ will try to connect once, but not reconnect unless it has successfully completed a full Direct Connect handshake with the remote address. This type of attack shouldn’t be very effective with DC++ 0.699. Versions before this will reconnect on a slightly variable scale, in between 2 and 3 minutes. ($ForceMove is what we typically classify as an “operator” command, so normal users should not (unless the hub is configured for it) be able to use this command to initiate an attack. Rogue operators on white hat hubs could, however.)
$ConnectToMe <RemoteNick> :<SenderPort>
This is the command that instructs the receiving user (<RemoteNick>) to try to connect to SenderIp on SenderPort (via TCP). This connection is nearly exclusively for downloading of files. This command, as does the above, and most others, passes through the hub. A white hat hub will check <SenderIp> against the IP address of the sender, and only relay the command if they match. A black hat hub may not do that. Or worse, it may modify well formed $CTMs (as we shorten it) to contain the IP of a machine it would like pummeled with connections. DC++ (as will any DC client) will try to connect to the remote IP on the specified port once. It will not retry on its own, but it will try one time per $CTM. (I'm not sure whether it can be persuaded to try multiple connections to the same IP/port at the same time.) This attack cannot succeed without the complicity of the hub in the attack.
Prolexia certainly has drawn attention to this subject, but they're not the first to suffer such attacks. Hublist.org, created by Marko Virkkula (aka Gadget), was the default hub list for DC++ for a long period of time (July 2003). Hublist.org has been experiencing attacks since April of 2006, and the methods used above may be a direct result of his war of escalation against the attackers. A domain I bought ( dcpp.net) to host DC++'s web presence was definitely attacked by one of the two above methods. We changed hosting companies once, but were ultimately forced to pare back our web site and move a smaller version of it back to sourceforge.net's project space. I wasn't involved enough in the administration of either host machine to come away with the specifics of the attack, other than that it was DC traffic directed to the HTTP port.
As for preventing or mitigating the severity of this type of attack, I think there are a couple key points. We cannot change the protocol radically to fix this, as we're (Jacek Sieka, Fredrik, myself, and couple other regular contributors) only in control of one of the clients. (There is a developer community that represents quite a few of the packages, but not all of them.) All client and hub software would also need to be changed, and users would have to upgrade their respective software. We have an alternate protocol under development (ADC) that should lessen the concerns (as IP addresses are distributed to each client during the initial connection to the hub). That said, users can (and should) upgrade their client when a new version of DC++ comes out. On the release of a new stable version, each user with an older client is told about it once per startup of the application. Currently, 0.698 is marked as stable, so users need to ensure they have 0.699 installed. Developers who base their DC client on DC++ can sync their client more quickly following a release of DC++, or backport all of the fixes. Most importantly, we know that some of the hubs on the DC network are not to be trusted. They may be either public hubs (registered on one or more hub list) or private hubs (unregistered but allowing new members or protected via user name and password). Users who watch the output of their client can guess whether they're being involved in an attack. For the $ForceMove attacks, one of their hub windows will show as disconnected, with a long line of "*** Connecting …" messages without a single success. Users should close this window, and be wary if they decide to visit the hub that issued the redirect. For users involved in a $ConnectToMe attack, the "transfer view" of their client will show a number of upload connections in the "Connecting…" state. Through the process of elimination, they can determine which hub is issuing these bogus connection attempts. We have been burned with these attacks as well, so we'll keep looking for ways of improving the program.
Direct Connect: Just These Guys, Ya Know? 
You must be logged in to post a comment.