Cookie header appended to requests indefinitely

[sagishahar-zz]

Hello,

It appears that the the number of HTTP Cookie headers increases within each request. This essentially makes the HTTP request fairly large, and probably reduces the overall efficiency.

To illustrate the problem I have captured 4 subsequent requests and responses with BurpSuite while using Hydra v8.1 (installed through Kali Linux repositories). You can find the capture here: http://pastebin.com/53LRg72Y

In case you need the command that was used during the capture, it is: hydra 10.1.0.3 -l admin -P /usr/share/wordlists/top500.txt http-post-form "/dvwa/login.php:username=^USER^&password=^PASS^&Login=Login:F=failed" -vV -t1

Thank you for your hard work, sagi-

[vanhauser-thc]

True! Thats a bug...

[vanhauser-thc]

I checked in a fix but can not test it. Can you please try if this fixes the issue?

[sagishahar-zz]

Unfortunately, no good news. In fact, it's worse now because the number of Cookie headers have doubled. In the screenshot, you can see the actual request below the table (marked in orange):

From the screenshot, you can also notice that I have marked in red some GET requests. These requests are sent to the target server prior to every request sent for brute forcing purposes. I am not sure if this is a feature or a bug, so I didn't create a new issue. However, this doubles the amount of traffic sent to the server.

I would suggest sending one GET request before the attack to verify that the target is up (marked in green) and thereafter only brute forcing requests.

I haven't looked at the actual code, so feel free to ignore my suggestion.

[ghost]

Those preceding GET requests are actually aimed at gathering the cookies from the server :D

[ghost]

I'm thinking of fixing this bug with libapreq which greatly simplifies handling the HTTP protocol. Is it ok if I insert a new dependency? Of course, we'd have to update configure too.

[vanhauser-thc]

No that would be a very, very bad idea. It would mean that the http-form module would only work where this library is present. Is this library a standard on any Linux, Cygwin, OS X and FreeBSD installation without the need of installing something optional? If so, OK, otherwise no.

[sagishahar-zz]

@Strunk18 The whole point of a cookie is to maintain a session as the HTTP protocol is stateless. In other words, the cookie worth something only after one was successfully authenticated to the web application. Therefore, it is unclear to me why the cookie value is necessary prior to successful authentication?

I have not seen yet that the web server will not accept an authentication request without the cookie value. However, if the implementation of the extra GET request tries to address this edge case then why not reuse the cookie that was captured initially with the first GET request before attempting to perform the brute force attack?

[vanhauser-thc]

@sagishahar there are web services that only accept autentication if you sent a preset cookie, that is why this is necessary.

[vanhauser-thc]

@Strunk18 this bug is now three weeks old and breaks the module for most use cases. please submit a fix asap, otherwise I have to revert your patch and release a 8.2 without it. I can't leave it this way.

[vanhauser-thc]

@sagishahar - Strunk18 provided a fix - can you please test if this fixes the issue? I am at a security conference in canada while writing this so I the first time I can take a look at the fix is in 2-3 days ... :)

[vanhauser-thc]

fixed