DDoS exploit with proposed queuing scheme
 

When reading the proposed queuing scheme on rfc-gnutella (http://rfc-gnutella.sourceforge.net/...ella_queue.txt) it occured to me that when implemented this widely anyone could go around crawling through gnutella and direct a distributed denial of service attack on any server on the net.

Crawl gnutella and search for common files like "nude" or "Britney" and request some/all results with the new header;

GET /get/123/foobar.txt HTTP/1.0
Range: bytes=0-
User-Agent: Some Client 1.0
X-Host: 123.1.2.3:80

Where 123.1.2.3 is the (in this example web-) server you'd like to hit.


To prevent this you can;

a) Only allow a change of port.
AFAIK the outgoing and incomming IP address of any "normal" firewall is always the same. But you need to know which port is to be used for the callback.
X-Callback-port: 6346

b) Don't do callbacks
Keeping a socket open requires virtually no IP packets at all, so why not keep some of the queued sockets open?

Request from client
GET /get/123/foobar.txt HTTP/1.0
Range: bytes=0-
User-Agent: Some Client 1.0
X-Queue-Request

Response from server when immedeately queuing.
HTTP 100 OK
Server: Some Server 1.0
X-Queued: position=3; eta=42; ID={123432-45673-58787-65465465}
Server waits with transmission until a slot is available.

When there is no queue-slot available, it asks the client to retry.
HTTP 503 Server Busy
Server: Some Server 1.0
X-Queue-Retry: 600
X-Queued: position=8; eta=3600; ID={123432-45673-58787-65465465}
The client waits 10 minutes (600) and retries the request. The retry time can be estimated by the server as the eta for the first queue-slot (plus some)

Request from client when retrying
GET /get/123/foobar.txt HTTP/1.0
Range: bytes=0-
User-Agent: Some Client 1.0
X-Queue-Request: ID={123432-45673-58787-65465465}

c) ... (anyone?)


---

Although option a) is a _lot_ simpeler to implement, I personally don't like the idea of callbacks. It seems to me that if you want something, then come and get it.

My 60GB drive is full and I now have to start figuring out what to delete.
Why are people thinking about new ways to get more files when everything works fine?
I think the people complaining are the same people who are behind a firewall and wonder why they can't get anything via a push. Dumb arses complaining when it's their fault.
The problem doesn't exist. There are plenty of files, and you can fill up a 60GB drive with a modem connection.
And before adding this, why don't you developers get with it and ask the user what his upload bandwidth is and then open more upload slots till it's used up?
WHY ISN'T ANYONE WORKING ON THAT SIMPLE THING? It's been more than a year now and no one has done this, are all developers lame?

Re: DDoS exploit with proposed queuing scheme
 

Hoi Frans,

:eek: You're right. It has been implemented on a small, non-public scale only, so thank goodness for that. But someone could indeed create false requests which could lead to a DDoS.

Solution A, just sending the port (as the receiver can detect the IP by itself) seems most suitable in this case. The reason for a callback instead of keeping the port open is that the QUEUE (no emphasis) is used when a client is out of upload sockets. That indicates a limit set by either the end-user or as a precautionary limit on non-server operating systems like Windows 9x and Windows ME (which have terrible time opening and maintaining many socket connections).

I'd like to point out that with the introduction of a file mesh based on the HUGE proposal, the QUEUE will have a less important role. Nonetheless, it still has a good use so carefully examining all issues is a must. Thanks for pointing this important one out.

There have been several discussion about resolving an ID (similar to the ClientID [a GUID]) to an IP address, almost acting like an alternative to a DynDNS-like domain name (like DNS2GO, TZO), so an IP does not need to be transmitted at all times. However, in its current proposed form it could also cause a similar DDoS attack.

I'm glad you pointed this out, and it should have been obvious. There are a number of other areas in Gnutella that need to be addressed as well, but solutions are not always as easy to find as they may seem. I hope more people come forward in improving the vulnerabilites in Gnutella :) Thanks again!

isn't this more or less an inherent problem of the gnutella protocol (and probably other p2p) ?
I could make a client to distribute query hits, pongs or pushes with a faked ip and port. That would have the same effect.

The question is how serious is this problem.

If i understand correctly, for an attack using the queing proposal, each faked request results in only one connection to the target. This means an attacker would have to generate just as much requests as he wants the target to recieve, which doesn't seem very effective to me.
An attacker could just as well attack the target directly (except that through gnutella his ip will be hidden).

The same more or less goes for fake push requests (as i see it, the queing proposal is just a sort of delayed push).

Queryhits seem even less effective as it relies on the end user to actually start a download based on the hit.
Each fake queryhit probably results in less than one connection to the target on average.

I'm unsure about the effect fake pongs would have. But i don't think they would be much more effective than the others.


Any serious DoS'er would probably choose more effective ways than poisoning gnutella.

Ok, this are some sunday morning thoughts, feel free to shoot some holes in it :D

To ragger
I think you're right. From a single host you cannot do a lot of harm. The best you can do is adding the gnutella attack to your own (Gnutella's response will be delayed)

Still, it is a very simple and obvious scheme. And there is no real use for directing a queue request to a different IP.

Adding those two with a script kiddie and a grummy site operator, you get bad press about gnutella/p2p. (Like: grummy.com attacked by exploit in Gnutella)

Aan Cultiv8ter:
How's the weather in Philly?

Koud en regenachtig, as opposed to a few days ago :(