Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 9 Aug 2010 08:53:07 +0400
From: Solar Designer <>
Subject: Re: Cracking CISCO ASA 5510

On Sat, Aug 07, 2010 at 08:04:58PM -0600, Robert Ramsey wrote:
> In my Pix, I have a login password, enable password, and user account
> password.  I set each password to "cangetin".  The original entries
> look like this:
> enable password TynyB./ftknE77QP encrypted
> passwd TynyB./ftknE77QP encrypted
> username rramsey password jgBZqYtsWfGcUKDi encrypted privilege 15
> I modify them:
> enable:TynyB./ftknE77QP
> passwd:TynyB./ftknE77QP
> rramsey:jgBZqYtsWfGcUKDi

That's correct.

> Without any salt, the first two passwords are obviously the same.
> Looking at the associated threads for the example below, it looks like
> the first few characters of the username are used for salt.  Since the
> login password and enable password doesn't have a user name, they
> don't have any salt (which is why they look the same).  How does jtr
> know that there's no salt for the "enable" and "passwd" accounts?

It simply doesn't directly support the salted kind of these hashes.

> I added "cangetin" to the beginning of the password.lst so each
> password would break immediately.  When I run john on my three
> passwords the "enable" and "passwd" accounts break immediately (as
> predicted) but the rramsey account doesn't.  In fact, when I hit the
> space bar to get a status, I can see that john is trying other
> passwords.  Why doesn't the rramsey account break right away?

Same answer as above - it does not directly support the salted kind of
these hashes.  Please refer to this posting:

for how to get around that with a wordlist rule or an external mode.

Here's a specific example (using an external mode).  Add the following
to your john.conf:

void filter()
	int i;

	i = 0;
	while (word[i])
	word[i++] = 'r';
	word[i++] = 'r';
	word[i++] = 'a';
	word[i++] = 'm';
	word[i] = 0;

Then run:

$ ./john -i -e=newpix
Loaded 1 password hash (PIX MD5 [pix-md5 MMX])
cangetinrram     (rramsey)
guesses: 1  time: 0:00:00:01  c/s: 8141  trying: cangett1rram - cangetinrram

As you can see, the password gets cracked quickly.  As a side effect,
the extra "rram" is seen on the cracked password - you need to remove it
manually (or mentally).

Also, the issue described here:

for Oracle hashes applies to PIX ones as well.  1.7.6-jumbo-6 erroneously
detects 3 different salts on your hashes for this reason (but then it
cracks them anyway, albeit in a slightly longer time).  I'll fix this in
the next jumbo patch update.

> I tried two tests.  First test had all three passwords in one file.
> Since john stated "no different salts" I figured I should put rramsey
> in a separate file.  With rramsey in its own file, I still wasn't able
> to break it right away...

You do need separate invocations per salt - with different external
modes (or different wordlist rules) adding the salt.  Someone needs to
improve pixMD5_fmt.c (or add a new "format") to support these hashes
properly (without external hacks).

> [rramsey@...ora run]$ ./john
> Loaded 3 password hashes with no different salts (PIX MD5 [pix-md5 SSE2])

Apparently, you're using a jumbo-patched version older than
1.7.4-jumbo-2, so it does not yet have the bug described above. :-)


Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.