11-30-2017, 02:48 PM
The TACACS+ hash-mode was kind of fun to implement, as it's almost as close as being completely broken. However, I wouldn't use it personally as we only need to crack a single raw MD5 to break it.
Additionally there's a good analysis of the protocol security from Solar Designer, you can find it here: https://www.openwall.com/articles/TACACS+...l-Security
For the rest of this post I will assume that you have understood the basic algorithm used by TACACS+ explained in the link above or the RFC that you can find here: https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-07.
Here's some example hashes from JtR:
The third column is a session id. Since we also know the password (1234) I can use it in combination with the the sequence number in the fifth column to manually decrypt that data. It's important to visualize the plaintext data in order to explain how to crack TACACS+ in hashcat. It's not important how I did that exactly, I only need it for demonstration. Here's some keystreams I manually computed for each sequence:
And if I apply these sequences and decrypt them, the output is the following:
1:
2:
3:
4:
5:
6:
Beside all the protocol insecurities described in Solar Designer analysis (the missing padding problem in this example), how can we crack the TACACS+ password? The problem is that we can't easily crack it, because there's not much of known plaintext data.
Good thing is: We can attack it even if we only know *some* of the plaintext. But be warned, it's not much. Actually it's only the header (5-8 byte depending on sequence). Since there's multiple variations possible this goes down from 56 bits to 40 bits. We will end up in lots of false positives. However, there's a solution!
The sequence number in the MD5 comes to the rescue. Since this effectively changes the key produced by the MD5 we can compare all the passwords with each other. Very important: A password that is a false positive in sequence 2 will (very very likely) not produce a false positive in sequence 4.
To make use of that, I recommend putting hashcat into --keep-guessing mode for this hash-mode. In a post-process, we can then compare them and if we find one password that matched in all the sequences we can easily filter out the correct one:
Here's a little perl script to automate that process and to use with your potfile:
And here it is:
Finally let me add that you can convert your .cap files to hashcat compatible hashes using the hcxtools from https://github.com/ZerBea/hcxtools/commits/master
Additionally there's a good analysis of the protocol security from Solar Designer, you can find it here: https://www.openwall.com/articles/TACACS+...l-Security
For the rest of this post I will assume that you have understood the basic algorithm used by TACACS+ explained in the link above or the RFC that you can find here: https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-07.
Here's some example hashes from JtR:
Code:
$tacacs-plus$0$6d0e1631$573908bd8ed2c28efaff1bf00d07578a9a$c001
$tacacs-plus$0$6d0e1631$f7711e4b904fc4a4753e923e9bf3d2cc33e9febd3d2db74b9aa6d20462c2072013c77345d7112400d7b915$c002
$tacacs-plus$0$6d0e1631$5361cabdcfaa9e1d1550$c003
$tacacs-plus$0$6d0e1631$d623c7692ca7b12f7ecef113bea72845$c004
$tacacs-plus$0$6d0e1631$8e8a9a886885084924b6$c005
$tacacs-plus$0$6d0e1631$db7c01e77499$c006The third column is a session id. Since we also know the password (1234) I can use it in combination with the the sequence number in the fifth column to manually decrypt that data. It's important to visualize the plaintext data in order to explain how to crack TACACS+ in hashcat. It's not important how I did that exactly, I only need it for demonstration. Here's some keystreams I manually computed for each sequence:
Code:
563809bc8ed6c78e8e8b62c06c742ee4f9e2aee3482505cceabc608b90bfaea9f9e2aee3482505cceabc608b90bfaea9
f3711e6e904fcef1065be01eda90b1a9409adeeb585fde2df3c5b3700bad692a19920020a57f456db2833571b4a187d4
5364cabdcfcbfa707c3ecc094b283d35a0ab267b702eee9a3c3b90fdcfc57beb619e9073cee1576c4ba6df247296af93
d322c7632ca7e14e0dbd867cccc312659a62dae17678cb348df4f9eab4675eab6680ccda5cf423e403817e9c28dc084f
8e8f9a8868e46c244dd8900600ff4a953712d196f41454a04e1d0ace65caf32c3ff391b99952e1b176daa2e03be6d211
da7c01e7749931d89c47424a85316d296540b62ef082376c6b8d92ff37f249a468882fcbf4b4d843ee17bfc447b14d42And if I apply these sequences and decrypt them, the output is the following:
1:
Code:
00000000: 0101 0101 0004 0500 7474 7930 6173 796e ........tty0asyn
00000010: 63 c2:
Code:
00000000: 0400 0025 0000 0a55 7365 7220 4163 6365 ...%...User Acce
00000010: 7373 2056 6572 6966 6963 6174 696f 6e0a ss Verification.
00000020: 0a55 7365 726e 616d 653a 20 .Username: 3:
Code:
00000000: 0005 0000 0061 646d 696e .....admin4:
Code:
00000000: 0501 000a 0000 5061 7373 776f 7264 3a20 ......Password: 5:
Code:
00000000: 0005 0000 0061 646d 696e .....admin6:
Code:
00000000: 0100 0000 0000 ......Beside all the protocol insecurities described in Solar Designer analysis (the missing padding problem in this example), how can we crack the TACACS+ password? The problem is that we can't easily crack it, because there's not much of known plaintext data.
Good thing is: We can attack it even if we only know *some* of the plaintext. But be warned, it's not much. Actually it's only the header (5-8 byte depending on sequence). Since there's multiple variations possible this goes down from 56 bits to 40 bits. We will end up in lots of false positives. However, there's a solution!
The sequence number in the MD5 comes to the rescue. Since this effectively changes the key produced by the MD5 we can compare all the passwords with each other. Very important: A password that is a false positive in sequence 2 will (very very likely) not produce a false positive in sequence 4.
To make use of that, I recommend putting hashcat into --keep-guessing mode for this hash-mode. In a post-process, we can then compare them and if we find one password that matched in all the sequences we can easily filter out the correct one:
Code:
$tacacs-plus$0$6d0e1631$f7711e...400d7b915$c002:I[s)|~#
$tacacs-plus$0$6d0e1631$f7711e...400d7b915$c002:4XdKNPF
$tacacs-plus$0$6d0e1631$f7711e...400d7b915$c002:9bf_6z+
$tacacs-plus$0$6d0e1631$f7711e...400d7b915$c002:1234
$tacacs-plus$0$6d0e1631$d623c7...3bea72845$c004:2u}0K!^
$tacacs-plus$0$6d0e1631$d623c7...3bea72845$c004:ei,}3W#
$tacacs-plus$0$6d0e1631$d623c7...3bea72845$c004:1234
$tacacs-plus$0$6d0e1631$d623c7...3bea72845$c004:i8}42d$Here's a little perl script to automate that process and to use with your potfile:
Code:
$ perl -ne 'while (<>) { chomp; /(c00\d):(.*)/ or next; $db->{$2}->{$1} = undef; } for $pw (keys %{$db}) { next if scalar keys %{$db->{$pw}} == 1; print "$pw\n" }' < hashcat.potfileAnd here it is:
Code:
1234Finally let me add that you can convert your .cap files to hashcat compatible hashes using the hcxtools from https://github.com/ZerBea/hcxtools/commits/master