Re: smb-brute: Case sensitive passwords

[Ron <ron () skullsecurity net>]

Fyodor wrote:
> Hi Ron.  I'm quite excited about the new SMB functionality in general!
> I am speaking at CanSecWest next month and I'm trying to think of good
> ways to use one or more of the smb scripts to demonstrate the power of
> the scripts themselves, and of NSE in particular.
>
> I haven't thought about it enough, but one idea might be to
> demonstrate the way the scripts can chaing together.  I could have a
> VM running Windows and show how the accounts can be determined by one
> method (or guessed), then the passwords brute forced, then other
> scripts take over and determine detailed information about the system.
That's great! I have something that might help you a bit, but I'd like
to keep it off the list for now (I'll send it separate).

But here's another idea for you. I'd like to automate this in the
future, but for now it's a manual process.

1. Run a full smb-enum-users for every system you can. Record every
username in a file.

2. Do a smb-brute and smb-pwdump with that user list and the standard
unpw dictionary (or even use smb-brute to get passwords and use those
passwords in fgdump -- should have the same result except evade
antivirus better).

3. Take the password hashes discovered in this way and put them all into
another file, the new password file

4. Run smb-brute again, this time using the username list and the file
with the hashes instead of the standard unpw file

5. Goto 3 until you stop getting new accounts

6. Do what you want with the passwords (crack them with Rainbow Tables, etc)

So basically, as you're going along you're collecting passwords and
adding them to your bruteforce list, then using those to collect
passwords from other systems. This assumes that users use the same
password on different systems, not an unrealistic guess.

And incidentally, if you need help presenting at CanSecWest, and can get
me in for free, let me know ;)

> For the rest of my email, I think I misunderstood your message.  I
> responded with the thought that you were going to try every
> capitalization combination of every unpw library password in sequence.
> But now I think I understand that you are verifying using
> case-insensitive Lanman that a password has the right letters, and
> then using case-sensitive NTLM to determine the exact case.  I think
> that is a great idea!
Yup, that's what I'd meant.

> I'll include the rest of my email, even though I think much of it is
> based on my misunderstanding.  As some of the ideas/data might still
> be useful for unpw.
>
> On the subject of capitalization, perhaps this capitalization brute
> force should be an option people have to specify.  Or at least it
> should only happen after all as-is passwords have been gone through.
> Then it should probably go through all of them with just the first
> letter capitalized before continuing on to try other capitalization
> schemes.  As you noted, there are only a small number of relatively
> likely capitalizations.  Take a look at a password cracker such as
> John the Ripper for a good idea of the sort of permutations which are
> most valuable.  Solar Designer based many of his decisions there on
> real-world testing.
>
> Many people here probably saw the unfortunate phpbb hack a few days
> ago, where an attacker compromsied their databases and posted a list
> of 28,635 user passwords and more than 100 megabytes of database
> dumps.  Now those passwords are particularly lame, but the
> capitalization stats are dramatic:
>
> All lower-case passwords: 28,290 (98.8%)
> One or more capital letters: 345 (1.2%)
>
> Even with a four letter example such as "test", the capitalization
> brute force makes the cracking take 16 times as long.  One an average
> password file, it probably takes at least 64 times as long.  That's a
> bitter pill if we're only gaining 1.2%.
>
> Also, it might be better to offer these sorts of permutations in unpw
> rather than the smb brute force script itself.  They are just as
> applicable to the other brute forcers.
>
> As a first order of business, I'll bet that improving our password
> list by mixing in more data (including, perhaps, the PHP list) would
> be much more effective than brute forcing every capitalization of the
> existing words.  Though I do agree that having the capitalization
> brute force option is good to have for when people want an intensive
> check.  I think the key is to timebox (as you mentioned) based on how
> long the user is likely to want to gring the service, and try the most
> likely password candidates first.
I agree with the part about including case modifications and such in
unpw. I have a list of changes to unpw I'd like to make (I keep my TODO
list on a piece of paper, but I could probably put these ones in the
regular TODO file):
- Append/prepend numbers
- Try l33tsp34k
- Change case, like one capital or two capitals
- Allow the addition of passwords in run time (so if pwdump finds stuff,
add them to the pw list)
- Check common passwords first (the username and blank)
- Save statistics on passwords (which ones were the most successful?) --
either for one run or overall. Probably too complicated, but something
to think about.

Most of those should probably be "off" by default, with script-args
available to turn them on.

> > One option, if this becomes an issue, is to timebox it, make sure that
> > no crack takes longer than, say, 10 seconds. At 10 seconds (or
> > whatever), give up and move onto the next account. I dislike that idea,
> > though.
>
> I actually think it is promising.  Sometimes people just want to do a
> quick sweep for obvious passwords since they are in a hurry.  In other
> cases they have more time and are willing to spend days trying to
> crack an account.
I was going to suggest including this in unpw, but from a quick look it
seems that it's already there, but isn't used by any scripts. I wonder
if that can be integrated a little more, like by having it totally stop
returning usernames/passwords when the time runs out?

> > The only real issue is that this script won't find passwords if a server
> > is set to NTLM-only, or if somebody uses a password greater than 14
> > characters. But I don't think either of those is common enough to
> > matter.
>
> Does Vista still allow Lanman by default?  Is there a way to detect
> whehter a server is set to NTLM-only before doing the grinding?
That's a good question, I hadn't tested this against Vista. Vista
doesn't support Lanman by defalt.

I don't know if there's any way to check whether or not Lanman is being
used. I can't think of one off the top of my head. The simplest way is
probably to check the OS and make assumptions, if it's Vista+ then
downgrade automatically. Besides that, I can go back to honouring the
smbtype parameter so the user can force it not to use the Lanman trick.

> Cheers,
> -F

Ron

-- 
Ron Bowes
http://www.skullsecurity.org/

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org