Secure hubs - fail to protect against 0.401

[Foxp]

Ok, situation. Some hubs have a security layer called leechblocker, basically it means that unless you are a registered user of the hub in question you can't download (or if the option exisits, search either). I use this in my own hub.

Problem now exists (apparently with only client 0.401 and leechblocking or download blocking by profile) that if a UnRegistered user is trying to get a registered users filelist and that registered user then get's the UnRegistered users list (as for file share validation or just to look) that now the UnRegistered user suddenly has access to the registered users file list AND can download.

This is not good. I would like to see whatever changed in 0.401 to make this possible removed OR add in a ability for hubsoft to control a bit for blocking if the user is not registered for security reasons.

Fox

[BSOD2600]

Since this is a plugin or script running in the hub, this is not a DC++ problem. Its the plugin/script that needs fixing.

[cologic]

This is one of the most singularly fucking stupid threads in recent memory.

[ivulfusbar]

DC++ listens and handles incomming connection regardless if connection traffic has been sent through the hub so your script is useless among the few people who know what they do.

[Foxp]

The leechblocker script is fine for 99% of everything else, it's only version 0.401 that's the issue, so something has changed enough in the DC++ to make the script fail (lua script BTW)

And think about this a moment before you so idiotically dismiss the idea. One of the biggest issues in the P2P world currently is the constant harrassment or threat to users from legal agencies. By using a dedicated protection system against searches/downloads no agencies will randomly come in and get a file list from my users and use it against them. A safe place to transfer files is rare and that's what I try to provide. By requiring registration and detail share checking before registration we consider ourselves reasonably secure, until this new issue came up.

Since my concern is the protection of the users overall I hardly think that is a "singularly fucking stupid" idea. Unless of course, you are a basic leecher in which case it makes sense you would think it was stupid, after all, you're the kind of person we wouldn't want in the hub in the first place.

[Xan1977]

something has changed enough in the DC++ to make the script fail

So then your Ptokax script should be fixed, right?

[Foxp]

In practice, I can't figure out where DC++ changed that made the scrpt fail in such a strange way. Technically the script should still work, obviously it isn't.

However, I feel anything that adds a compromise to user security needs to be considered from all factors.

This doesn't mean I'm not looking at ways to alter the script, been my full-time project for the last 2 weeks! What good is security that isn't effective with the newest releases after all?

Which is why I came here, apparently user security isn't an issue among the people that need it most. Their loss I suppose.

Fox

[Xan1977]

cologic said it best.

[Todi]

Protocol is protocol, some things you can influence through the hub, some things you can't. It should be pretty obvious by reading a protocol guide what things you can do. I doubt DC++ has made any big changes to the protocol from version to version.. well, unless you count the ADC changes, but those don't really apply here...

[Twink]

so I'm guessing his script is blocking filelists by watching for mylist.bz2 transfers when it should also look for the mylist.xml ones?

[ivulfusbar]

so I'm guessing his script is blocking filelists by watching for mylist.bz2 transfers when it should also look for the mylist.xml ones?

No. Hubsofts has no information about what happens on the client<-->client side. They will never have any control of it. They have no control of what you download. And will never have. Its one of the key-points in the DC-architecture. Our friends script is broken and always been broken.

Problem now exists (apparently with only client 0.401 and leechblocking or download blocking by profile) that if a UnRegistered user is trying to get a registered users filelist and that registered user then get's the UnRegistered users list (as for file share validation or just to look) that now the UnRegistered user suddenly has access to the registered users file list AND can download.

You have to learn about how the client-client protocol works, particulary the $Direction part.
The point is that your hub have never ever been secure, you have only assumed it has been. The scripts logic is not consisten with what you want it todo.

[GargoyleMT]

apparently with only client 0.401 and leechblocking or download blocking by profile) that if a UnRegistered user is trying to

We us this same scheme in the DCDev Public hub. Due to the way the client to client protocol works (the fact that it can be either an upload or a download, based on the $Direction command), this isn't foolproof.

It's not affected one bit by 0.401 - you'll see the same behavior back to the earliest clients you can run.


Please, if you're accusing someone of having a bug, make damn sure that it is their problem beforehand.

[Foxp]

I never accused anyone of having a bug!!! That's an assumption on your part. For the sake of continuity I'll post the relevant script so at least you'll have that. However, no where did I say there was a bug anyplace, just there was a change in configuration and I'm trying to place where so security can be adapted to fit.

You all have to quit jumping to conclusions (yes, I do it too sometimes).

here's the code in question:

Code: Select all

smDebugging       = "0"   -- Default is "0" (silent mode). "1" sends msgs to OPs
smBlockSearches   = "1"   -- Default is "0" (do not block searches)
smBlockSearchExceptions = { "scores", "sheet music" }

MsgToAliens = "\t\t\t*** WARNING ***\r\n\t"..
            "YOU ARE UNABLE TO DOWNLOAD OR SEARCH IN THIS HUB\r\n\t"..
            "Only registered users can download.\r\n\t"..
            "You still can chat...\r\n\t"..
            "...but the hub won't let you download or search until you register.\r\n"..
            "\tIn order to become a registered member:\r\n\t"..
            "1) Read !rules for share requirements\r\n\t"..
            "2) only then, ask an OP for a password.\r\n\t"..
            "We hope you will join us."

LetLeechCommand = "!letleech"

smBot = frmHub:GetHubBotName() -- This line gets bot name from PtokaX hubsoftware;
                               -- therefore, your Hub Bot should be enabled.



ToBlock = { "^$ConnectToMe%s(%S+)", "^$RevConnectToMe%s(%S+)", "^$Search%s+(%S+)"}
LetLeech = {}

--// This function is called when hub or script starts
function Main()
  frmHub:EnableFullData(1)
  frmHub:UnregBot(smBot)
  frmHub:RegBot(smBot)
  --// If thus configured, remove search from blocking table:
  if smBlockSearches == "0" then
    for i,v in ToBlock do
      if v == "^$Search%s+(%S+)" then ToBlock[i] = nil end
    end
  end
end

--// This function is fired when a new user (non-OP) finishes login
function NewUserConnected(user)
  if user.iProfile == -1 then
    user:SendPM(smBot,"\r\n"..MsgToAliens)
  end
end

--// This function is fired when new data arrives
function DataArrival (user, data)

  --// See if data is the !letleech command:
  if strsub(data, 1, 1) == "<" then
    local line=strsub(data,1,strlen(data)-1)  -- remove last char
    local s,e,cmd = strfind(line, "%b<>%s+(%S+)")
    local s,e,arg = strfind(line, "%b<>%s+%S+%s+(%S+)")
    if strlower(cmd)==strlower(LetLeechCommand) then
      if user.iProfile ~= 0 and user.iProfile ~= 1 then
        SendToAll(smBot, "...but you are not an OP!")
        return nil
      end
      who = GetItemByName(arg)
      if not who then
        SendToOps(smBot, arg.." is not online.")
        return 1
      end
      if who.iProfile ~= -1 then
        SendToOps(smBot, arg.." is registered and does not need a leech license.")
        return 1
      end
      LetLeech[arg] = 1
      SendToOps(smBot,arg.." has been granted a special leech license.")
      who:SendData(smBot,arg..", you are now authorized to download for this session.")
      return 1
    end
  end

  --// See if data should be blocked:
  for _,blockstring in ToBlock do
    local _, _, who = strfind(data, blockstring)
    if who then return smBlock(user,data,who) end
  end
end

function smBlock(user,data,who)
  local report
  local profnam = GetProfileName(user.iProfile)
  if profnam then
    profnam = strlower(profnam)
  else
    profnam = "alien"
  end
--// Activity by Masters, OPs, VIPs and REGs are just reported to OPs:
--// Also, searches pass if they are in the exception list:
--// Data also passes if user is in LetLeech list:
  if (user.iProfile ~= -1) or smMatchException(data)
      or IsInLeechList(user) then
    report = "\t"..user.sName.." ("..profnam..") sends:\r\n\t"..data
    smDebugToOPs(report)
    return nil
  end
--// Alien (not registered) users get blocked:
  local report = "\tBlocked from "..user.sName.." ("..
        profnam.."):\r\n\t"..data
  smDebugToOPs(report)
  return 1
end

function smMatchException(data)
  if strfind (data, "^$Search%s+(%S+)") then
    for _,exceptword in smBlockSearchExceptions do
      if strfind (strlower(data), strlower(exceptword)) then
        return 1
      end
    end
  end
  return nil
end

function IsInLeechList(user)
  for i,v in LetLeech do
    if i == user.sName then return 1 end
  end
  return nil
end

function smDebugToOPs(data)
  if smDebugging == "1" then
    SendToOps(smBot,data)
  end
end

[GargoyleMT]

Problem now exists (apparently with only client 0.401 and leechblocking or download blocking by profile)

...
This is not good. I would like to see whatever changed in 0.401 to make this possible removed OR add in a ability for hubsoft to control a bit for blocking if the user is not registered for security reasons.

[Foxp]

Problem now exists (apparently with only client 0.401 and leechblocking or download blocking by profile)
...
This is not good. I would like to see whatever changed in 0.401 to make this possible removed OR add in a ability for hubsoft to control a bit for blocking if the user is not registered for security reasons.

And? Nowhere in here do I say it was a bug, just that we have tested this (with over 18 clients and many versions of same) and the only one we get the problem with is 0.401. My statement stands. Just that it's a problem, and that is also true. There are 10 people working on this problem at the moment that I'm aware of, doing cross-testing every 15 minutes or so all hours of the day and night, the stantment stands. DC++ 0.401 is the only issue, regardless of others saying it has always been a problem with all past versions, nope, never has been and we test regularly.

Now don't mistake here, this is mostly a team of seasoned programmers and testers, several of whom have been coding and working protocols likely longer than many of you have been alive. Myself included, I'm a e-learning developer specializing in new protocol development for e-learning application and management, not some rookie teen just out of school.

If you can't offer facts and reasonable suggestions you are only part of a global problem of wasted internet users and will always be users. Obviously I'm not directing this at you but rather those interested in providing the best security for the users (however underserving in this case) overall.

Fox

[ivulfusbar]

the person who wrote that script has no knowledge about how the dc-protocol works. If he/she did, then this would not be an issue since its extremly easy to solve. Study the protocol and it will become clear to you. Hint, examine active/passive users and $Direction.

how-many-people-do-you-need-to-write-a-broken-script-ly'ers? (Apperently 10) ;))

[GargoyleMT]

If you can't offer facts ...

$Direction is caught in UserConnection.cpp. An event is fired, UserConnectionListener::DIRECTION, which is caught in ConnectionManager.cpp/ Please have your team of programmers verify that 0.401 included no change to the way this protocol command is handled.

[cologic]

Whether DC++ 0.401 behaves differently from other versions is an unimportant side issue.

More centrally, the original poster is now asking for a (possibly nonexistent) change in DC++'s behaviour to be reverted to provide what would become illusory client-side security. If nothing else, what if people just use DC++ 0.401? This is why I made my previous comment.

But of course, I'm sure I'm just a basic leecher, one of them "wasted internet users".

[GargoyleMT]

But of course, I'm sure I'm just a basic leecher, one of them "wasted internet users".

After this thread, we all may feel the urge to become wasted internet users.

[Sedulus]

w00t, more Hall of Fame material :)

Foxp: for you information, that leechblocker script that you are using was created after someone saw it (actually it limited <25GB sharing users from downloading from users with a >25GB share) running in my DCH++ hub. I know, because I've read and posted in that thread on the PtokaX board back then. (I'm not claiming originality, I stole the idea from someone else). when I wrote it, I knew that this was a problem and has been for every client out there, unless the client cheats on the $Direction command. the only bug I see is that this was not documented in the script.

I see two fixes for your situation:
- don't download from unregged users at all, unless you share nothing.
- mod your hub to convey information about who is unregistered to dc++. and mod dc++ to fetch that info and use it to refuse uploads. luckily you have a team of seasoned programmers, so that should be a piece of cake :)

P.S. to prevent further undocumented "security issues", you should note that when modding dc++, you'll also need to check the connecting users IP (use $UserIP hub support for this), otherwise the connecting user can lie about his/her nickname and fetch files after all.