16

I have a computer that I need to boot into, but the passwords seem to be bogus. Additionally I can't mount the drive for writing, and it is a mips processor, so I can't stick it in another machine to run it.

Anyhow, they passwd file has some users that look like this, with a star after the user-name. does that mean blank password or what? 

root:8sh9JBUR0VYeQ:0:0:Super-User,,,,,,,:/:/bin/ksh
sysadm:*:0:0:System V Administration:/usr/admin:/bin/sh
diag:*:0:996:Hardware Diagnostics:/usr/diags:/bin/csh
daemon:*:1:1:daemons:/:/dev/null
bin:*:2:2:System Tools Owner:/bin:/dev/null
uucp:*:3:5:UUCP Owner:/usr/lib/uucp:/bin/csh
sys:*:4:0:System Activity Owner:/var/adm:/bin/sh
adm:*:5:3:Accounting Files Owner:/var/adm:/bin/sh
lp:VvHUV8idZH1uM:9:9:Print Spooler Owner:/var/spool/lp:/bin/sh
nuucp::10:10:Remote UUCP User:/var/spool/uucppublic:/usr/lib/uucp/uucico
auditor:*:11:0:Audit Activity Owner:/auditor:/bin/sh
dbadmin:*:12:0:Security Database Owner:/dbadmin:/bin/sh
rfindd:*:66:1:Rfind Daemon and Fsdump:/var/rfindd:/bin/sh
Jeff Schaller
  • 66,199
  • 35
  • 114
  • 250
j0h
  • 3,467
  • 8
  • 27
  • 36
  • 13
    Note that you've posted DES password hashes. DES password hashes are pretty easy to break nowadays. Don't connect this computer to a network until you've changed the passwords. – Gilles 'SO- stop being evil' Jul 30 '15 at 23:25
  • 2
    I would recommend not connecting this computer to the public Internet *at all*, to be quite frank. Put it on a firewalled network long enough to slurp data off it, sure, but then it should be retired. If the operating system is as old as it looks, it is probably riddled with security holes from the kernel on up -- [predictable TCP initial sequence numbers](https://en.wikipedia.org/wiki/TCP_sequence_prediction_attack) for instance. – zwol Jul 30 '15 at 23:51
  • The password for the `lp` user is ridiculously weak. And because DES based passwords are limited to ASCII and can only be 8 characters long, you don't get more than 53 bits of entropy. Switch to a stronger hash if you can, and change the passwords. – kasperd Jul 31 '15 at 17:09
  • Adding some numbers to my previous comment: My laptop could break the `lp` password in 630 milliseconds. The `root` password is a lot stronger. I let a brute force attack run for five hours before I terminated it. It did not break the `root` password within those five hours. But you should of course still follow the previous recommendation and change the password. – kasperd Jul 31 '15 at 22:10
  • for the record you know that story that the most popular password is password? well password1 can't be far behind. ridiculously weak indeed. – hildred Jul 31 '15 at 22:20

4 Answers4

23

You have to check man passwd:

If the encrypted password is set to an asterisk (*), the user will be unable to login using login(1), but may still login using rlogin(1), run existing processes and initiate new ones through rsh(1), cron(8), at(1), or mail filters, etc. Trying to lock an account by simply changing the shell field yields the same result and additionally allows the use of su(1).

Usually accounts with * in password field don't have a password e.g: disabled for login. This is different to account without password which means the password field will be empty and which is nearly always a bad practice.

taliezin
  • 9,085
  • 1
  • 34
  • 38
13

The accounts with passwords are the accounts with a glob of base64 gibberish in the second field:

root:8sh9JBUR0VYeQ:0:0:Super-User,,,,,,,:/:/bin/ksh
lp:VvHUV8idZH1uM:9:9:Print Spooler Owner:/var/spool/lp:/bin/sh

This computer appears to be using the traditional, DES-based crypt(3) password hash. This hash is quite weak by modern standards; if you can't manage to get a root login any other way, you can probably brute-force recover the password, using John the Ripper or similar software. Also, technically that is not base64 but an older, similar encoding, but you probably needn't worry about that.

The distinction between :*: and :!: mentioned in other answers is too new to be relevant to your problem. On a UNIX system this old, there are only three different things that can appear in the password field:

alice::1001:1001:Alice Can Log In Without A Password:/home/alice:/bin/ksh
bob:WSy1W41d4D1Gw:1002:1002:Bob Must Supply A Password:/home/bob:/bin/ksh
carol:ANYTHING ELSE:1003:1003:Carol Cannot Log In At All:/home/carol:/bin/ksh

If the contents of the password field are empty, you can log in with no password.

If the contents of the field are the valid crypt hash of some password, you can log in with that password.

Otherwise you can't log in as that user. * is just the conventional thing to use - it's visually obviously not a valid password hash. It was probably picked by whoever wrote the passwd program.

(The point of having user IDs in the password file who can't log in is that they can still own files, they can still have cron jobs, and daemons can use setuid to assume that identity. In fact, it's best practice to run all daemons (that don't have to run as root) under such user IDs, so that you have some level of assurance that only the daemon is running under that identity.)

(The accounts with /dev/null in the shell field are locked out against root using su to run programs under that user identity, as well as regular login. Nowadays you are much more likely to see /bin/false or /sbin/nologin used for that purpose; I suspect that on this system the latter does not exist and the former is a shell script.)

(The password for Bob is "bobpassw", encrypted using the old algorithm, but on a modern Linux machine; it might not be what your computer would produce for the same password and salt. One of the reasons the old algorithm is considered no good anymore is it has a hard upper limit of 8 characters in a password.)

(I know the system is really old because it's using DES-based password hashing, because it isn't using a shadow file, and because root's shell is /bin/ksh rather than anything newer and more ergonomic.)

zwol
  • 7,089
  • 2
  • 19
  • 31
  • I thought bob's password didn't QUITE meat the form. – Joshua Jul 30 '15 at 22:33
  • @Joshua Fixed it now :) – zwol Jul 30 '15 at 23:47
  • If he needs to boot into the machine, wouldn't it be faster booting in recovery mode or booting with a USB live CD/DVD and change the password to another one than using john the ripper? – YoMismo Jul 31 '15 at 06:58
  • @YoMismo A computer this old (my educated guess is it's from the early 1990s) may not _have_ a recovery mode. It probably does have the ability to boot from some kind of removable media, but it might be quite difficult to find an bootable CD or tape or whatever. A modern liveCD is definitely _not_ going to work. – zwol Jul 31 '15 at 12:49
  • @zwol I would try to start the system with an actual distro and chroot to his old system, most probably `passwd` wouldn't need to have mounted --bind /dev /sys .... – YoMismo Aug 03 '15 at 06:25
  • @YoMismo That would work if this computer had any hope of running a modern "distro" -- but it probably doesn't. Based on some of j0h's other questions ([1](https://unix.stackexchange.com/questions/219488/how-can-i-run-old-programs-from-a-mips), [2](https://unix.stackexchange.com/questions/219230/warning-filesystem-seems-to-be-mounted-read-only)) it's an SGI Indigo workstation, which dates to 1991. The only modern OS that *might* support it is NetBSD. – zwol Aug 03 '15 at 12:51
8

This means that it is disabled for direct login. It is a user that is used for running services or to be used for rlogin. Check https://en.wikipedia.org/wiki/Passwd#Password_file

Marco
  • 893
  • 9
  • 19
4

About your actual question, see taliezin's answer (and accept that one ;)

About your other problem: Search for the string 8sh9JBUR0VYeQ on the disk to figure out the disk block(s) it resides in. Then dd that disk block(s) into a file, replace that string with a known password hash (the old crypt() one - same length) and write the disk block(s) back to the old location - possibly doing a full backup of the disk before. Since this approach doesn't change the size of the file, no file system meta data need to be updated.

Bodo Thiesen
  • 306
  • 3
  • 9