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
Improve this question
5
  • 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, 2015 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 for instance.
    – zwol
    Jul 30, 2015 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, 2015 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, 2015 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, 2015 at 22:20

4 Answers 4

Reset to default
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.

Improve this answer
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.)

Improve this answer
6
  • I thought bob's password didn't QUITE meat the form.
    – Joshua
    Jul 30, 2015 at 22:33
  • @Joshua Fixed it now :)
    – zwol
    Jul 30, 2015 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, 2015 at 6: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, 2015 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 3, 2015 at 6:25
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

Improve this answer
3
  • This computer is pretty old I wasn't sure if the meanings changed over time.
    – j0h
    Jul 30, 2015 at 15:47
  • @WouterVerhelst: It is disabled for login. It is not disabled for rlogin. You have to look at the answer more closely.
    – Engineer2021
    Jul 30, 2015 at 17:17
  • I changed my answer. I hope that it is now more correct for @WouterVerhelst.
    – Marco
    Jul 31, 2015 at 6:34
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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .