Re: Ncrack 0.2 Alpha - SSH behaviour

[Robin Wood <robin () digininja org>]

On 31 August 2010 17:00, Mike Westmacott <mike.westmacott () irmplc com> wrote:
> Hi Robin,
> As I understand it nmap will attempt to determine what the maximum number of concurrent connections is when it starts 
> up, and will throttle back connections if it starts to see them being closed (according to debug). My issue here is 
> that I have two large files (I'm not saying it's down to size though!) - both which contain the correct password for 
> the user - and one of them will correctly identify the password, the other will not. I have run the tests with the 
> same level of parallelism and connection delay. In my test scenario I was running 360000 passwords against 1 user in 
> about 25 minutes (De-ICE VM is local to test machine). My 'good' file reported all instances of the correct password 
> logged in successfully, my 'bad' one reported no successful logins - and in fact marked the logins as failed.
> Having said that after a while of testing my DeIce VM started to disconnect virtually all SSH logins early so it 
> needed a reboot!

Oh well, there goes my theory!

I'll have a look at the ncrack throttling stuff, could be useful in my work.

Robin

> Best regards,
> Mike
>
> Mike Westmacott |  Security Consultant
>
> Information Risk Management Plc
>
> -----Original Message-----
> From: Robin Wood [mailto:robin () digininja org]
> Sent: 31 August 2010 12:58
> To: Mike Westmacott
> Cc: nmap-dev () insecure org
> Subject: Re: Ncrack 0.2 Alpha - SSH behaviour
>
> On 31 August 2010 12:49, Mike Westmacott <mike.westmacott () irmplc com> wrote:
> > Hi,
> >
> > I've been testing ncrack 0.2 and have found some behavior where for some
> > wordlists it will report that a password failed even though it is the
> > correct one yet on others it will be ok.
> >
> > This may be related to the overall size of the wordlist and also to the
> > parallelicty in effect. I was testing against DeICE 1.100 with a
> > username/password that is found as part of the testing against that VM
> > (I will avoid divulging this info on the list!). I was using a 3.3mb
> > wordlist which also contains some symbolic and alphanumeric passwords.
> > If I extract all words that begin with the same letter as the password
> > then I get a match. If I concat that file together to make it >3.3mb it
> > still works. If I put the password at various intervals throughout the
> > original password file it doesn't match (indeed it writes the login
> > failed) - even when it's the first password.  By removing parallelism
> > the problem went away. I was only ever testing against 1 explicit user.
> >
> > I can put together a tar of options, results, debug output and the
> > dictionary files - please let me know if you would like to see the
> > results.
> >
> > Overall though I was hugely impressed by the speed although found
> > tweaking the retry delay was essential to getting it working ok (or
> > maybe I was being confused by the problem I have just described - not
> > sure :)
>
> I've not tried ncrack but I am working on an ssh bruteforcer of my own
> and I've found a problem when testing against openssh, there is a
> MaxStartups value that governs the "maximum number of concurrent
> unauthenticated connections" check man sshd_config for more info.
>
> I don't know if it was designed to protect against brute force attacks
> but it does it because if you fire loads of passwords at once then you
> trigger this limit and all new connections are rejected.
>
> The default is 10 connections so when I go parallel I hit this limit
> fairly quickly, if I go single threaded and put a slight pause in
> between attempts then I can go through large lists.
>
> This may be completely down the wrong track but it worth looking at if
> it hasn't already been.
>
> Robin
>
> Disclaimer
> Any advice prepared and/or services undertaken by Information Risk Management Plc. ("IRM") are strictly private and 
> confidential, and may also be protected by legal privilege.
> This email is intended only for the use of the addressee. If you are not the intended recipient you may not copy, 
> disclose to anyone else or otherwise use the content of this email and/or any attachment and should return them to 
> the sender immediately and delete them from your system.
> Non-business related content is not authorised by IRM and we shall not be liable for it.
> Where relevant, any quotation contained within this email is exclusive of VAT at the current rate and valid for 30 
> days from the date of this email, unless specified to the contrary. IRM does not authorise the creation of contracts 
> on its behalf by email.
> All attachments have been scanned for viruses using regularly updated programs. IRM cannot accept liability for any 
> damage you incur as a result of virus infection. The contents of this email reflect the opinions of the author only.
> It is your responsibility to notify IRM immediately of any changes in circumstances which could render any 
> information previously provided to be inaccurate or which would otherwise have a bearing on the advice being rendered 
> and/or services being performed. IRM does not accept any liability for inaccuracies, errors, losses, damages, 
> failures, any missed timelines or problems which arise as a result of you not providing accurate, complete and timely 
> information and/or instructions.
> IRM is a publicly owned company registered in England and Wales under Registration Number 03612719. A list of 
> directors' names is available for inspection at our registered office. Information about IRM is available from 
> www.irmplc.com.
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/