Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
On the exploit websites I see security analysts and hackers targeting the /etc/passwd file when showing the proof of concept.
If you have a local file inclusion or path traversal vulnerability on your server, and hackers are able to access (view, read, but NOT edit) the /etc/passwd file, what are the repercussions of this? Aren't all passwords obfuscated in this file by design?
The only real repercussion is reconnaissance - the attacker can learn login names and gecos fields (which sometimes help guess passwords) from the /etc/passwd file.
One reason for this is that, 20 years ago or so, most Unix variants shifted from keeping hashed passwords in the /etc/passwd file and moved them to /etc/shadow. The reason for this was that /etc/passwd needed to be world readable for tools like 'finger' and 'ident' to work. Once passwords were segregated into /etc/shadow, that file was made readable only by root.
That said, /etc/passwd remains a popular 'flag' for security analysts and hackers because it's a traditional "hey, I got what I shouldn't" file. If you can read that, you can read other things under /etc as well, some of which can be useful to an attacker. But it's harder to test for (say) /etc/yum.conf if you don't know if yum's on the system; /etc/passwd is always there and is a reliable test of whether access worked.
Put differently, the implicit repercussion of getting /etc/passwd is that the attacker has circumvented controls and can get arbitrary readable files, which means "I win!"*
*No actual guarantee of win, express or implied
ls -l will stop showing usernames if you remove /etc/passwd; it's not PAM-aware. That's the sort of hidden dependency that drove hashes out of /etc/passwd.
Jul 1, 2015 at 19:16
While @gowenfawr hits the main points, I have a few to add:
Most systems, but not all, hide the actual passwords in /etc/shadow. To see if your system is vulnerable, check a real user account. If it looks like
stighemmer:x:...
Then your passwords are safe.
If it looks like
stighemmer:kjsaashgdkwqvbm:...
Then your passwords are NOT safe.
Yes, the password is obfuscated using a one-way hash function, but that is not enough. Having this file allows the hacker to check if a given user has a certain password without actually trying to log in.
In 1970, this check was slow, and things were reasonably safe. Today, a hacker can check millions of passwords per second. If one of your users has a guessable password, that user's account will be hacked. And the limit for what is "guessable" is pushed with every processor generation.
Now you have checked, and found that your passwords are safely stored in /etc/shadow. Good, problem solved.
Not quite. /etc/passwd contains more information.
It contains the full name of every user. This is very useful for social engineering attacks.
It contains a list of system users, which indicates what software is installed.
So, I get an email going "Hey Stig, I have forgotten the postgres password. Could you remind me? Signed, Other Real User". Since my helpful email client doesn't show the full email address I will not notice that this email comes from a remote country. I reply, "It is 'S3CR37'". Oops, the company database just got hacked.
Of course, this is not the only way full names get exposed, you need to teach the users about social engineering attacks anyway.
This may help an attacker to do a brute force attack in low times, so the attacker doesn't need discover the usernames because he already has got them but he can aim the attack only to discover the passwords.
Unless you aren't using shadow passwords, access to /etc/passwd is not the massive risk that the filename would imply (and if you aren't using shadow passwords in this day and age, you've got a problem).
The first unix systems actually stored passwords in /etc/passwd, which is why the file is called that. It also stored some other aspects of user metadata, like the user's home directory, shell, and so forth. In retrospect, this was not the greatest design decision ever made, because it meant that programs which used this metadata needed to be able to read /etc/passwd in order to get at that data.
The passwords in /etc/passwd were encrypted using the algorithms of the time, but including the encrypted passwords was still a needless exposure risk, and so shadow passwords were implemented to resolve that. The format of /etc/passwd couldn't change, for historical reasons, but modern systems just put a placeholder there (x is common). The actual password-related information (the actual hashes, how old the password is, and so on) are stored in another file, /etc/shadow, that only root can read.
This is not to say that access to /etc/passwd is completely harmless. It still yields a list of usernames, and although that's theoretically harmless (since usernames aren't supposed to be secret), it can be depressing to learn just how many people use their username as their password. It happens less often in this day and age, but it still happens often enough to be worth a try.
Also, the GECOS field in /etc/passwd often contains metadata like users' real names. That can be useful for quick guesses in and of itself, or for doing detailed searches that may yield more likely guesses. This is fairly sophisticated stuff, though, going well beyond (and potentially not even requiring) getting access to /etc/passwd itself
When performing vulnerability assessments for clients, I use /etc/passwd as a "hey, I got LFI in this application and you should be aware". It is a simple, well-known file that generally has sufficient permissions on the filesystem to show that I can read files. Being that this is a vulnerability assessment, I, and the client, only care about the vulnerability being present, proof provided, and guidance on how to resolve the issue.
When I am performing a pentest for a client, this file, though normally does not contain passwords, gives me a lot of information. From it, I have login names to start guessing passwords for and I can use the existing LFI to then attempt to read files out of the user homedirs.
This same reasoning applies to XSS proof of concepts and <script>alert(1)</script>. It is not the worst thing you can do with XSS, but it is proof that I as an attacker have the ability to execute JavaScript under my control.
An attacker can look at manually created Users (UID >500 or >1000 on most linuxes i touched so far) and also look at assigned shells (/bin/ba(sh)) to learn what users might work on services and/or webapps available on the machine. SSH is not the only Target!
This information is not only usefull for generic bruteforce but also for every attack that might involve the knowlege of valid username (be creative).
As mentioned above: When an Attacker can read /etc/passwd he can also read so much more on the system and systematically determine if there are ways for getting reverse shells and local privelege escalation.
I recommend you read up on some linux privesc guides (mubix & g0tmilk for starters) and get your hands on some vulnerable vms for some hands-on privesc training (vulnhub.com / kioptrix is a good starting point).
