Securing the unsecure ?!

Seasons greetings everyone from us at DCDev

Wanted to rant about private only scripts and the idiocy usage of em since a script really cant determine if its public or private.

Private only scripts are mainly used in Ptokax / Verlihub or any soft using lua scripting interface.

So what does the tag stand for in DC++

1/1/1

first digit is unregistered usually determined as public hub but all it really is is unregistered.

second digit is registered here is where most people thing it means private and hidden away in the deep corners of the direct connect network (it kinda amuses me) since it could be a public vip or just an account on hub that you registered yourself at.

Third and last is of course the operator digit this really doesn’t show if its private or public either.

and using hublist to check if same user is online at other hubs on NMDC is pretty dumb too since, It might be an shared connection.

What if the person has a brother or sister that uses DC++ and likes to be  on a public hub to talk about nothing and everything.

plus it really cracks me up that we are talking about securing private hubs that are communicating via cleartext protocol using NO ENCRYPTION thats really funny how secure is the hub in that regard let me tell you’ll.

Its really just a waste so in the holiday seasons i leave you with the words of wisdom your only as secure as your own box (hub).

P.S for all those people making these scripts for god sake do it right and put in a 60-90 second delay before kicking the poor sap since there can be a slight delay in updating myinfo on NMDC and for that matter ADC since i know the idiocy is gonna continue.

I help those who help themselves! – Zoidberg (Futurama)

DC++ pointing out the corrupted

One of the latest enhancements in DC++ is the hub referral on client-client connections, proposed by Jan Vidar Krey. The current bazaar trunk implements this mechanism and the next DC++ version that will be released soon will also have it. The purpose of this extension is to point out the corrupted hub that is sending the current client to a non DC client, with obvious malevolent purpose. This implies that the hub is either using exploitable software, or that it’s intentionally abusing the clients. Either way, the hubowners are solely responsible.

On connecting to the other party, DC++ will also send the hub URL that it used to connect to the hub sending out the CTM message. By packet inspection, an attacked party can figure out which is the corrupted hub (only a pointer is required, such that they have a point of reference ) . Another good part about this extension is that it works on both ADC and NMDC ( some workaround was found for NMDC: adding the url to the PK string since NMDC is not extensible nor flexible in this matter ) , with the least effort from the clients and it does not bother them in any way. A normal client should ignore the specific message ( I don’t find any particular usage for it ).

We strongly recommend all mods to inherit this extension and other clients out there to implement it so the CTM attacks impact on DC software will stop being so great.

DC++ CTM Proof

In a previous post I was wondering if the whole concept of centralization is obsolete or has major flaws. The problem that is bothering everybody in the last years is that clients can be used ( unwillingly ) as tools in distributed denial of service attacks. Jan Vidar Krey is proposing a hub refferal on c-c connections that can point to a source of CTM attacks via the messages that the client sends on first connection attempt. In this case an attacked entity can see the hub with problems/intentional flooding that is causing the attacks.

As a first step to prevent this kind of abuses in DC++, poy added a static IP protection for the major hublists that were attacked via the client. This kind of measure is just temporary since hublists can change IP anytime and it protects only them, not everybody else that can be attacked ( Also the fun part is that the hublist server is actually running a DC client and wants to download from other users, it can’t ! ) .  A second step was to dynamically resolve the hublist ip’s and block them for c-c connections.

The main idea that I considered is to practically check all the users on a specific hub to see if they actually are real. On CTM receive the client should not connect but send another CTM to see if that IP actually connects to them . This will make sure that the user is the actual owner of that specific IP address. Of course the biggest problem is if the user is passive, in which case it can’t send a CTM back. This could be against the protocol principles but it’s a solution to see if the other peer really exists. I don’t know if a RCM would do something good in this situation but it’s a start.

Another thing that should be done ( if not implemented already ) is that on c-c connections if the first attempt was unsuccessful then no further attempts should be done until the user at least reconnects or changes state ( passive/active ). Also the hubs should be trustworthy. In a previous post I suggested a way to make hubs trustful via a CA authority system, but most people were quite reticent about it. Perhaps this could be the only way to make hubs trustful. Warning messages will not help too much ( Strong DC implements such messages ) since most of the users either don’t read them or don’t care. We shouldn’t let users question this problem, but solve it for them. Continuous problems from the Direct Connect network might be a cause to mark DC software ( and DC++ ) as badware, which will definitely take down the network. It’s time to do something about it.

I’m hoping for more ideas how to make DC++ proof against CTM abuses and I’m waiting for opinions from you as well.

Are centralized networks doomed from the start ?

Recently I heard bad rumors around the DC network. Some malevolent person ( unknown ) has written several scripts for the most known DC hub software, that allow the hub owners to use their users in abusive forms of flooding, using the CTM feature of the protocol. These scripts have started to spread around and now “script kiddies” use it for flame wars and endless childish attacks.

Also, important sites that currently hold on the DC community like the major hublists OpenHublist or DCHublist and the ADC counterpart ADCHublist were attacked and were down for a long time. The major community for ADC , ADCPortal was also attacked ( ADCPortal also provide an alternative wiki to the one on the ADC Project ).

My first concern is that this problem can spread up to the centralized networks principle. In this case, the central node ( hub ) has the power to absolutely control the leaves that are connected, thus it can abusively send them in possible attacks at wish. This might be a serious problem for the centralized networks.

Secure policies have to be enabled in clients and hubs so that this kind of flaws do not affect the community. I don’t know yet if it’s possible in this current situation or the whole concept of centralization is flawed. I hope not, because the Direct Connect community has it’s advantages and there are a lot of people involved and which benefit from it every day.

My advice from the users: make sure you actually know what hubs you are using, and how your client can be abusively used for other purposes than the ones designed, and make sure you are using a proper firewall and perhaps package inspection to see if your computer is not part of a BotNet or similar flooding network.

And one last thing, Happy new year and all the best from the DC++ team.

Multiple shares in NMDC, revisited

Multiple shares in NMDC have been on topic for years, and will probably continue for years to come. Well, the current approach is simple; use a different port in each hub you’re in. So, if you’re in 5 hubs, the ports used will be (e.g.) 5000, 5001, 5002, 5003 and 5004 when using the CTM/RCM.

That this solution isn’t scalable haven’t bothered people to implement it. Patching a bad protocol does not make the protocol suddendly good. Oh well… People are free to implement away.

Encryption in NMDC, revisited

While cologic exhausted the encryption topic, I want to give a heads up in regards to TLS in NMDC. There are more and more clients that have implemented TLS in NMDC. The current technique is by specifying an ‘S’ in the end of the CTM (after the port, that is). Apparantly, YnHub and Ptokax (if I remember correctly, Verlihub, too) will not block this information and DC++ should be able to operate nicely when specified (even if it doesn’t support it).

Do note that NMDC encryption will not appear in DC++ (unless Jacek changes his mind, which is highly unlikely).

Decentralization in its inception?

An important part of the DC community is its ability to change and the ability of the developers to think of new and interesting ways to improve the experience that is Direct Connect. One important section of change is the posibility to take an existing program, like DC++, and change it to ones own liking. One of these clients is StrongDC++, which have features that are not in e.g. DC++ and some features that have migrated its way back to DC++.

A new exiting approach that can only be described as a way to extend Direct Connect is the ability to create a decentralized version of DC, using commands and functionality similar to ADC (and NMDC, albeit only insofar as the initial startup). The proposal have been made by, as can be noted by the page title, the StrongDC++ client and its authors (other people are as well involved).

Basically, the new protocol will be able to operate without a hub, and where one might still be able to share and download with others. However, it should be noted that to get a list of users, one need to connect to a hub and ask for other clients’ support for this feature.

(Note that I’m not saying that this will or will not be a feature incorporated in DC++.)

ADC hub referrer

In my Denying distributed attacks post, I described that users can be redirected to hubs. What I didn’t describe was whether there was a way for another hub to see if a user has been redirected or not. That is, something similar to the HTML referrer.

At the time, neither ADC nor NMDC had this type of functionality. However, before the official ADC 1.0 specification, a hub referral field was added to the INF.

What this means is that if a hub redirects a user, the client will automagically tell the hub so, when it successfully connects.

(NMDC still do not have this functionality.)

[If you're not a hub (but eg a HTTP server) that's being targeted, yes, you will need to do some communicating to find out from which address the user came from.]

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

Restricting $ in file names

As of version 0.703, DC++ is able to share files containing “$” in their name. This is (obviously) because that restriction was removed. It was removed because it’s completely irrelevant at this time; DC++ will only use TTHs to request files. As such, it doesn’t matter if the file name is written in a special way (except maybe how it should be stored on the end computer, but that’s a different matter) when it comes to downloading.

All of this is now fine, but why wasn’t it previusly fine to share those types of files? Actually, this isn’t a restriction that has been set because the NMDC protocol didn’t support it; This is an artificial restriction in DC++. (Most likely because of its initial coding.)

You see, the NMDC GET command do require a $ in the command (besides in the beginning), but it’s not something a client couldn’t work around.

The command NMDC use is “$Get $|”. If the client start to search from the beginning (after “$Get”) after the $ to find the offset, a file name containing a $ will obviously break/behave unexpectadly. However, if the client would search backwards from the first |, it would be able to catch the correct offset and file name, even if the file name contain a $.

(Yes, of course, we still have a restriction for “|” in the GET and a file’s name.)

Note: I don’t know if DC++ has fixed this kind of behaviour for other commands still in operation in DC++.

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

ADC’s client-client handshake

I previously wrote about NMDC’s client-client handshake sequence, and today I thought I’d talk about ADC’s handshake sequence.

As with the previous post, there’s going to be a client and a server that speaks, where the ‘client’ is the one that want to download and ’server’ that one that’s going to upload.

For starters, the required commands are “SUP”, “INF”, “GET” and “SND”. The INF is going to contain the users CID, but I’ll use the same CID for both for simplicitly sake. [The both CIDs will still be the same size...]

(Note that the ‘\n’ is one character.)

Server
CSUP ADBASE\n

Client
CSUP ADBASE\nCINF IDWTFUTQBI4NT6MKTRT2EHSMGZM5H2BVM5IZD65FA\n

Server
CINF IDWTFUTQBI4NT6MKTRT2EHSMGZM5H2BVM5IZD65FA TO123456789\n

Client
CGET file TTH/PPUROLR2WSYTGPLCM3KV4V6LJC36SCTFQJFDJKA 0 -1\n

Server
CSND file TTH/PPUROLR2WSYTGPLCM3KV4V6LJC36SCTFQJFDJKA 0 12345\n

At which point the server starts streaming the file to the client. (The client will of course stop listening for the file when 12345 bytes have been received, and disconnect or send another GET. )

The server has sent 133 characters, or bytes. The client has sent 120 characters, or bytes.

This is pretty much what a normal client to client handshake sequence looks like. Note that the token (after the TO) is completely arbitrary. Also, the INF may contain more information; This is just what is required. I don’t see a point at the moment to send more stuff, but oh well…

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”