NeoModus Direct Connect was initially a file-sharing client for Windows and Mac users that provided file-sharing capabilities for any type of file within a hub-centric, peer-to-peer network. NeoModus Direct Connect inspired the creation of open-source versions of the client, such as Open Direct Connect and later DC++. DC++ itself has several specialized spin-off open-source versions as well, such as ApexDC++ and StrongDC++, which are refined with features particular to user groups, such as filters, language packs, and search capabilities.
Inside my University the most popular way of sharing files is using these DC Hubs. Not only us, there are many hubs in local networks of many educational institutions. For example, look at this cool utility in IIT-B. There are many hubs on the internet as well whose list is available here. So, I was intrigued to understand this protocol better to see how secure it is. Moreover no major analysis is available on the internet for me to go through.
What did I do?§
The commands in the protocol start with a '$' sign and end with a '|'. The list of commands are available here. Since the analysis is currently in progress, I will try to update this section whenever I find something new. The hacks are classified into three categories
- Client Side - The bugs which are caused because of improper handling in client softwares
- Hub Side - The bugs which are caused because of hub softwares
- Protocol Side - The bugs which try to use the protocol in unexpected ways
Client Side Hacks§
User Spoofing in public/private chat§
The command to send public and private messages are of the following format
$<john> cats are cute| $To: john From: peter $<peter> dogs are more cute|
If you register your nick as john>, some clients strip out the trailing > and display the message which makes it appear as if it is from john. The message commands will look like
$<john>> I really don't care about what you think| $To: peter From: john> $<john>> You are an idiot|
Some clients on which I tested this are
- StrongDC++ (<=2.42)
- DC++ (<=0.843)
- I am sure there will be many more...
Hub Side Hacks§
Vulnerable Lua Scripts (From SQLi to RCE)§
Like every other place, insecure extensions bring in more vulnerabilities. Most of the hub softwares make available a lua scripting engine to make things more extensible. There are tons of lua scripts already present on the internet whose functionality vary from chat logging to anagrams. Check here for some sample scripts. So, how can you exploit these?? Check this! There are scripts which use SQL databases, some chat loggers write directly to a log file with certain naming etc... So if you are lucky enough to find a script which uses unescaped user data in its db queries, you might actually end up having a SQLi right there. One way to go is to make yourself Admin or elevate it to RCE if possible. How to detect it? Generally to keep things simple for the normal users, hubs send command of the following format which clients tend to display as hub options for a user. The user command looks like this
$UserCommand 2 6 Kick$$To: %[nick] From: %[mynick] $<%[mynick]> You are being kicked====|$Kick %[nick]|| $UserCommand 255 1|
So, dig around nicely for such instructions and you might get lucky finding some lua scripts which provide some extra functionality. Try fingerprinting the script, search on internet, do a source code review & BOOM!! <-- All this if you are lucky :P
Sample UserCommands grabbed from a hub. There is lot of information leak which will tell you which script it is ;)
UserCommand 1 3 LJ palace\.:: Ranks\Live user location statistics by country $<%[mynick]> +cclive| UserCommand 1 3 LJ palace\.:: Ranks\Live user location statistics by city $<%[mynick]> +citylive %[line:<cc>]| UserCommand 1 3 LJ palace\.:: Ranks\All time user location statistics $<%[mynick]> +cchist| UserCommand 1 3 LJ palace\.:: Hub news\Read hub news $<%[mynick]> +hubnews %[line:<lines>]| UserCommand 1 3 LJ palace\.:: Releases\List of available releases $<%[mynick]> +rellist %[line:<type>] %[line:<lines>] %[line:<category or publisher>]| UserCommand 1 3 LJ palace\.:: Releases\Find release by name or category $<%[mynick]> +relfind %[line:<name>]| UserCommand 1 3 LJ palace\.:: Chat history\Main chat history $<%[mynick]> +history %[line:<lines>]| UserCommand 1 3 LJ palace\.:: Chat history\Your main chat history $<%[mynick]> +myhistory %[line:<lines>]| UserCommand 1 3 LJ palace\.:: Custom nicks\Get users real nick $<%[mynick]> +realnick %[line:<nick>]| UserCommand 1 3 LJ palace\.:: Custom nicks\Custom nick list $<%[mynick]> +custlist| UserCommand 1 3 LJ palace\.:: Hublist\Show friendly hubs $<%[mynick]> +showhubs| UserCommand 1 3 LJ palace\.:: Other\Calculate an equation $<%[mynick]> +calculate %[line:<equation>]|
Protocol Side Hacks§
Spoofing Share Size§
Since there is no practical way for the hub to verify your share size, you can spoof yours to attract people to browse your shared files. This is not a huge attack on its own, but it has helped to draw the attention of users and make them download some malware :P. The command in which share size is sent looks like this.
$MyINFO $ALL johndoe <++ V:0.673,M:P,H:0/1/0,S:2>$ $LAN(T3)[email protected]$1234$|
Eavesdropping on users§
The protocol is designed in such a way that whenever a user searches for a file, all the clients connected to that hub get this search query. If you are using a dc client software, you will never know what others are searching since the clients automatically send the search results by actually searching your shared files, but if you use a handcrafted client you can easily categorize all the searches of a particular user. When the download slots for a file are not enough, the client software tries to search using the TTH of the file. Again this search is sent to all the connected clients. It is easy to match a TTH to a file, by just searching it on the hub itself ;). Though this is facilitated by the protocol itself, I find it amusing to see what other users are searching for. So, some screenshots of search queries that are extracted from some online hubs :P are present here, here & here.
Instead of the ip addresses we can easily track the searches using registered nicks on the hub. All the TTH searches are the files that are being downloaded by users. Some searches on my university hubs xD
Spreading malware (Spoofing search results)§
We have already seen that the hub sends the search query to every connected client for results. We can send fake results as there is no way a hub can verify if we have a file or not. So, if the user wants to download one of our results, we can just send malware. But this is not as simple as it seems. There are many factors which are to be considered. For example, search queries can be of following types
$Search 192.168.1.5:412 T?T?500000?1?Gentoo$2005| $Search Hub:SomeNick T?T?500000?1?Gentoo$2005| $Search 192.168.1.5:412 F?T?0?9?TTH:TO32WPD6AQE7VA7654HEAM5GKFQGIL7F2BEKFNA| $Search Hub:SomeNick F?T?0?9?TTH:TO32WPD6AQE7VA7654HEAM5GKFQGIL7F2BEKFNA|
So, whenever you get one search query, you can send a convincing fake result. I wrote a small python script which sends a fake result for every search :P
$SR MyNick F:_\search_term.proper_extension<0x05>file_size 5/5<0x05>HubName (192.168.1.1:411)|
But this is not as easy as it seems because our search results have to be convincing. Things to keep in mind
- If the file is big and there are matching results, then the victim client will try to download part of file from other clients.
- Using appropriate file extension when particular type of files are searched. Clients will filter results which donot match extension
- Using a unique TTH hash for every different fake file :P
- Using convincing file size because there cannot be a movie mp4 file of 25kB :P
- Let me tell you it is more complicated to produce convincing results, best way is to cache the search results and extract useful filenames and TTH hashes. This is tricky.
Just watching the world burn (Making downloads of all users useless)§
There are few people who just want to watch the world burn. For them, there is a facility in NMDC. The clients search using TTH hashes for alternate sources to download a part of file. If you respond to that search and send random binary data, the downloaded file will end up being useless. Nothing particularly of interest, but will be fun to mess with few people. This feat will require huge processing power and great bandwidth even for an active hub with users in two digits.