35

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?

kos
  • 41,378
funguy
  • 493
  • 19
    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. – Mark Smith Jul 31 '15 at 06:49
  • 8
    For one I can tell you have a webserver on this machine. Combined with your IP adress it might be hackable >:-D – Rinzwind Jul 31 '15 at 09:19
  • 3
    @MarkSmith It contained encrypted passwords when? AFAIK it started life as hashed passwords. Certainly since I first used Unix in 1982. – user207421 Jul 31 '15 at 09:55
  • @EJP You are correct, hashed, not encrypted. My mistake. – Mark Smith Jul 31 '15 at 09:58
  • @Rinzwind From which line you can tell this? :) – funguy Jul 31 '15 at 12:29
  • 3
    @funguy: www-data user is usually used by web servers. Ubuntu and probably Debian used this user as the default Apache user. – Lie Ryan Jul 31 '15 at 12:43
  • 3
    @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. – Rinzwind Jul 31 '15 at 14:25
  • 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. – thomasrutter Jul 30 '18 at 00:21
  • lol. Back in the really old days, it contained the plaintext passwords for every user. Encryption of passwords was a later innovation. Of course this would be a bad idea now, but this was in earlier Unix days and pre-dated Linux or widespread use of computers outside of research facilities. – thomasrutter Mar 13 '23 at 09:43

2 Answers2

48

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.

Sergiy Kolodyazhnyy
  • 107,880
  • 6
    +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 – kos Jul 31 '15 at 07:55
  • 1
    Hmm... So would you to suggest changing defaults usernames to confuse an attacker? – Freedo Jul 31 '15 at 15:01
  • @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. – Sergiy Kolodyazhnyy Jul 31 '15 at 22:28
  • 1
    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. – Dewi Morgan Aug 01 '15 at 00:08
11

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 rather easy to calculate a hash from a password, but is almost impossible to calculate the original password from a hash. If you have the hash, 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.

However, 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 on Wikipedia: Passwd

PoolloverNathan
  • 7
Warren Hill
  • 22,462
  • 28
  • 71
  • 89
  • Feels like you should probably mention 'rainbow tables' here just to give some idea of how that brute force attack works. – Rick Chatham Aug 06 '15 at 16:13