Why is everybody so concerned about etc/passwd?

Question

Here is the content of my vagrant machine of this particular file:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/us$
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
syslog:x:100:103::/home/syslog:/bin/false

Could anybody explain me why it is bad if some evil guy could get this file of my production server?

Solution 1

Key point is that Pentesters/white-hats/ethical hackers as well as black-hat target /etc/passwd as proof of concept, as a test of possibility of gaining access to a system.

Technically /etc/passwd isn't that scary. In the past it used to store private data, passwords obviously, but as of nowadays you'd need to be more worried about /etc/shadow - most Linux systems nowadays use shadow suite of utilities to keep a hashed and salted password in /etc/shadow, which unlike /etc/passwd isn't world-readable. (unless you use pwunconv command, which actually moves the hashed passwords back into `/etc/passwd).

The only more or less sensitive piece of info is the usernames. If you have sshd or telnet on the server and a username with weak password, there is a potential for a brute force attack.

By the way, your very same question has been asked before. Here I merely restated some of the concepts mentioned there already.

Small addition: this is a little far-fetched, but I've noticed that you have bash as root shell. Now, suppose you have a user on the system that has bash as their shell, even worse - that user is sudoer. Now, if you bash is outdated or unpatched, an attacker could try to exploit the Shellshock vulnerability to steal data or execute a fork-bomb bring your system down temporarily. So yes, technically /etc/passwd isn't a big deal, but it does give an attacker an idea of some of the information on what to attempt

Additional edit, 11/18/2016

Having used an Ubuntu server on Digital Ocean for a while, it came to my attention, that most brute force attacks against my server were carried out for root user - 99% of the entries for failed password in /var/log/auth.log were for root. /etc/password, as I mentioned before, gives attacker look at the list of users, and not just system users, but human users as well, which means more potential venues for attack. Let's remember that not all users are security conscious and don't always create strong password, so an attacker's bet on human error or overconfidence has quite a high probability of being jackpot.

Solution 2

In order to log on to a machine you need to know both the user name and password.

/etc/passwd provides information on users which gives you half of the information you need and used to include a hash of your password.

A hash being something calculated from your password. It is difficult to find a password from a hash but not the other way round. If you have both you can try brute force attempts to find the password offline then only try to connect to the computer once you have found it.

Today security is improved because the hashes are stored in a different file /etc/shadow which by default is not readable by most users.

But, if I had access to both /etc/passwd and /etc/shadow I could probably find your password using a brute force 'dictionary' attack. Since I can do this locally on my machine you would not notice many failed attempts to find your password and I would only need to connect to your machine again once I knew the password. I am then free to do whatever I want.

There is more information here on Wikipedia

Comments

[Mark Smith]

Back in the old days it contained the encrypted passwords for every user - where the :x: is now. If you got it (which was easy as it's readable by all, so you just need one login) you could brute-force crack the passwords. Now they're stored in /etc/shadow which is not readable by all so less likely to "get out", but which would have the same issue if it did.

[user207421]

@MarkSmith It contained encrypted passwords when? AFAIK it started life as hashed passwords. Certainly since I first used Unix in 1982.

[Mark Smith]

@EJP You are correct, hashed, not encrypted. My mistake.

[funguy]

@Rinzwind From which line you can tell this? :)

[Lie Ryan]

@funguy: www-data user is usually used by web servers. Ubuntu and probably Debian used this user as the default Apache user.

[Rinzwind]

@funguy www-data is the default apache user. There are more: uucp is unix to unix copy; that means you copy files between systems. And "irc" and "gnats" are also easy to spot.

[thomasrutter]

It's not just that encrypted passwords have moved into /etc/shadow. The "encryption"/hashing scheme has also improved markedly since those days. The original DES based encryption and even its successor MD5 were easier to brute force. Which isn't to say that you should share your /etc/shadow with impugnity... an easily cracked password is still an easily cracked password.

[kos]

+1, great answer. Adding to this, I'd like to say also that, in general, information is power; leaving aside the infamous Shellshock, one might gather, for example, informations about the running processes, which could be exploited also; for example, on OP's machine, Apache is running, and that's another potential hole left uncovered

[Freedo]

Hmm... So would you to suggest changing defaults usernames to confuse an attacker?

[Sergiy Kolodyazhnyy]

@Freedom That doesn't help. User and Group id's remain the same if you change log-in. For instance, here's my testuser: testuser1:x:1001:1001:,,,:/home/testuser:/bin/bash. After I run sudo usermod testuser1 -l testuser2 sudo usermod testuser1 -l testuser2 , the entry has different username but gid and uid are the same: testuser2:x:1001:1001:,,,:/home/testuser:/bin/bash. If password is unchanged, attacker can make a guess and still crack the system. Requiring the password to expire and to be changed every once in a while is a better approach, but also not bullet proof.

[Dewi Morgan]

Changing default usernames IS useful, for those accounts that have SSH logins (or other remote logins). So is changing the default ports for those logins of course. Anything which lets you keep your logs clear of billions of random drive-by scans by script-kiddies will mean that you can focus on the more deliberate attacks. If your custom names turn up in your failed-login logs, you know it's a serious attempt to get in, rather than a drive-by.

[Rick Chatham]

Feels like you should probably mention 'rainbow tables' here just to give some idea of how that brute force attack works.