Thursday, October 18, 2012

How I broke a Toshiba UNIX server passwd file.

  When I was living in HillSide Illinois, which is a small city out west of Chicago, a Polish friend of mine purchase a crate of  unix servers. These servers where heavy duty  and used in some type of US military  organization & and was purchased for 80 dollars from the GSA outlet. The servers had a simple 400meg SCSI HDD made by quantum, I believe it was a  fireball series iirc.

One of the problem with these servers, they had no standard network interface and only offered a  console connection  via RS232c 25pin interface. All attempts to try to log in in via the console was not fruitful. So I needed away to  try to hack the  systems filesystems to try to recover the system admin password known as ( root or super-user ). The best ideal that I came up with, was to remove the SCSI drive attach it to one of my numerous servers that was laying around my  apartment.

1st I tried a Sun Sparc Classic pizza box server, and tried to mount the  target SCSI drive as ufs filesystem. Solaris 2.5 complained repetitively with my attempts to mount the  drive. So I quickly gave up on that servers and moved on to plan B.

Plan B, I moved to a Debian  server and attach the quantum fireball to one of my SCSI drive attachments. I was not able to mount the drive with any of the standard  Linux filesystem type  that was support by that kernel. So the next best ideal that surprisingly work was to dd the target drive from the military unix-server and dump all of the contents to a local file.


dd if=/dev/sdb of=/home/kfelix/hacktheserverdrive.file

After execution of the unix dd  tool, I was able to term into a 2nd console session and run a simple grep and search against the dumped  file "/home/kfelix/hacktheserverdrive.file".

Basically since we wanted only  the root account, and all unix systems has a root account in a passwd or shadow ( master.passwd on some  BSD systems ),  that looks similar to this;

root:$2a$08$DkR4NLnLBoZXQtDvQcERV.WCopPAG6dLs6dirWl29clc7UNCnJhKi:0:0:daemon:0:0:Some account:/root:/bin/csh

The above  would be the root  account.

The 2nd  field in the above file ( bold section ) is the salted hash password, which is what we need to build our  file for passing to john the ripper ( a common password cracker ). So the grep command was executed against the dd dumped_file, & executed with the following arguments

cat /home/kfelix/hacktheserverdrive.file | grep "root:" 

That would catch any ascii text that had the word root: in it, &  display the output on the screen similar to this fashion;

# cat /etc/passwd | grep "root:"
root:$2a$08$DkR4NLnLBoZXQtDvQcERV.WCopPAG6dLs6dirWl29clc7UNCnJhKi:0:0:daemon:0:0:some user :/root:/bin/csh
daemon:*:1:1::0:0:daemon acccount:/root:/sbin/nologin

Once I found the match, I took the displayed  password and built my own  passwd file and ran john-the-ripper against that password file.

And  after  6 hours, my  Compaq Linux-Server, displayed a match. The password was an all lowercase and the word was   world1s.

Yes these servers had a simple password that was easily cracked with little to no-effort. And a simple unix open-source code was compiled and executed against the encrypted password.


Here's other examples of weak passwords that where cracked by the john the ripper. These password where broken in less than  20mins.

# john --show test.file

2 password hashes cracked, 6 left
# john test.file
Loaded 5 password hashes with 4 different salts (FreeBSD MD5 [32/64 X2])
guesses: 0  time: 2:21:49:13 (3)  c/s: 11632  trying: SThy17t - SThy16r
guesses: 0  time: 2:21:49:17 (3)  c/s: 11632  trying: ST62ey9 - ST62ea9
guesses: 0  time: 40:20:29:09 (3)  c/s: 11678  trying: 3jgT2h - 3jgT2x
guesses: 0  time: 40:20:29:17 (3)  c/s: 11678  trying: 3jirgr - 3jirgn
guesses: 0  time: 42:22:24:33 (3)  c/s: 11679  trying: 44ab yow - 44ab yoy
guesses: 0  time: 58:03:00:51 (3)  c/s: 11679  trying: 39eshoe! - 39eshoff
guesses: 0  time: 58:03:00:52 (3)  c/s: 11679  trying: 39esh-is - 39esh-it
guesses: 0  time: 58:04:03:01 (3)  c/s: 11679  trying: 3rki8ang - 3rki8ani
guesses: 0  time: 58:19:58:47 (3)  c/s: 11679  trying: ttpsb064 - ttpsb063
guesses: 0  time: 58:19:58:48 (3)  c/s: 11679  trying: ttpsnr1a - ttpsnr1D
guesses: 0  time: 124:21:21:07 (3)  c/s: 11620  trying: atina967 - atina960
guesses: 0  time: 215:23:55:04 (3)  c/s: 11561  trying: 305ermco - 305ermcs
guesses: 0  time: 230:08:15:07 (3)  c/s: 11555  trying: fbsov2lu - fbsov2l*
guesses: 0  time: 230:19:39:36 (3)  c/s: 11543  trying: gnsmygs4 - gnsmygs8
guesses: 0  time: 230:19:39:37 (3)  c/s: 11543  trying: gnsmhfmo - gnsmhfmi
guesses: 0  time: 236:18:58:03 (3)  c/s: 11396  trying: vevpumu - vevpumj
guesses: 0  time: 236:18:58:21 (3)  c/s: 11396  trying: vevrofo - vevrofr
guesses: 0  time: 236:18:58:22 (3)  c/s: 11396  trying: vevrt3z - vevrt3$

As you can see this unix-server, which happens to be a vmserver has been running for some quite time :)

Moral of this story, becareful of the password strength and what you use. And 2nd if you dispose of anything critical, you should wipe the drive with a few passes of the dd command or  better yet destroyed the drive to make any information recovery almost impractical.

When I was in the military we would  drill holes on a press, or use a drive shredding devices.


Ken Felix
Security Network Engineer
kfelix "a t"

No comments:

Post a Comment