2

I'm playing around with Hydra and an xmpp authentication.

I created a basic xmpp server of my own, reproducing an authentication (server side) from a clear text pcap file. I think I got something wrong in my connections handling (I'm creating one thread per new connection but I close it on error) but nevermind, this is not my point.

I fixed this scalability problem. For those interested, it was due to an optimization from Hydra, not replaying the first, let's call it "Hello request". A regular authentication needs 4 requests or responses from a client, 4 packets from the server too. And this optimization skips the first, going straight to the 2nd, that looks like that in my case : <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SCRAM-SHA-1'/>

Stats / Info :

  • Conf of the VM : 2 CPU, 2 GB RAM.
  • Password location in the wordlist : 795th position out of 60k.
  • Single task : ~50 tries / min -> ~17min to find the password.
  • 16 tasks : ~820 tries / min -> 1h14min to complete without finding the pw ('cause of the connections handling problem).

New stats (after optimization) :

  • Single task : ~90 tries / min -> 9min 13s
  • 16 tasks : ~1400+ tries / min -> 33s

The question is: is Hydra splitting the wordlist into 16 equal parts? And how?

One part size is ~3.8k passwords. Is the thread 1 working on the first 3.8k passwords? The thread 2 working on the 3801rst -> 7600 ? and so on till thread 16? So that the last 16 tested passwords would be the 3799th, 7599th and so on?

The other possibility is that the thread 1 for example proceeds every 1%16 (modulo) password from the wordlist, so that the passwords are tested in the same order than if we had only 1 task (/ thread) running.

I can test it myself but if someone already did, please enlighten my darkness.

|improve this question
  • This question would definitely benefit from some formatting. ;) Also could you maybe include why this is important and what implications it has? – Tom K. Nov 29 '18 at 14:44
  • Is it better this way ? :) It's important if you sort your passwords by relevance (relevant passwords at first). – T. Rode Nov 29 '18 at 16:26
  • The hydra manual says that the default number of tasks is 16, so if using a file, it breaks it up into 16 sections to test each section in parallel. – schroeder♦ Nov 29 '18 at 17:18
  • Yes thanks, but the question is how are they processed. Either 1.2.3.4.5...59999.60000 with 16 threads, or in my case 1.3801.7601... 2.3802.7602... to end with 3800th.7600th... I don't know if that's clear. – T. Rode Nov 29 '18 at 23:12
0

I found the answer.

Hydra is, I think, doing a modulo [number of tasks] to create each "subfile" that are processed in parallel. Why that ? Because it's 99% the same sequence of passwords test, I mean they are processed in the same order.

ie : Password number 1 will be tested as number 1 launching 16 tasks, password number 2000 will be tested in 2000th position as well in the 16 tasks hydra processing.

It also means the thread/task 1 will process password 1, 17, 33, 49...

Thread/task 2 will process password 2, 18, 34, 50... and so on.

And of course passwords are processed sequentially, ie in the same order, if you launch hydra with only 1 task.

I tested it on 8k passwords and it's almost all the time the same order in both cases, with very little variation sometimes.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.