51

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?

  • 9
    To make a PoC easy to follow, a file with well-known significance is targeted. /etc/passwd is a favorite even though in modern systems it won't give you much info. – ztk Jun 30 '15 at 18:08
  • 2
    25 or so years ago, you would have been able to attack the hashed passwords stored in that file (hence the name) but I don't think anyone on the planet runs a non-shadow system since at least a decade. – Damon Jul 1 '15 at 8:03
  • @Damon I beg to differ. Plenty of ancient Unix(-like) systems still going strong today. Nobody dares to upgrade in fear of breaking the application or because management can't be convinced (Budget for upgrade? Why? It works, doesn't it?) – Tonny Jul 2 '15 at 12:03
  • 1
    @dr01: Encrypted? Not in any properly designed system. Rather, a one way cryptographic hash should be used (with salting, etc) – Ben Voigt Jul 2 '15 at 18:34
  • 1
    @dr01, eh? No. Encryption implies recoverability if a key is present, and that property doesn't exist. – Charles Duffy Jul 2 '15 at 22:07
89

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

  • 8
    I'd suggest a correction that getting /etc/passwd means not that the attacker can get any arbitrary file, but any world readable files since any running process should be able to read /etc/passwd. – Steve Sether Jun 30 '15 at 20:54
  • @SteveSether thanks, good point, modified to reflect. – gowenfawr Jun 30 '15 at 21:02
  • I'd also like to add that /etc/passwd is no longer required on most (all?) modern Linux distributions as Pluggable Authentication Modules (PAM) provide robust authentication schemes (which can include use of /etc/passwd and /etc/shadow). I personally use decoy values for /etc/passwd and /etc/shadow knowing that if the system is breached the attacker may try to make use of those files (and by all means go for it, bad guys!). See PAM reference here: tldp.org/HOWTO/User-Authentication-HOWTO/x115.html – Nick Jul 1 '15 at 19:02
  • 3
    @Nick, correct me if I'm mistaken, but 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. – gowenfawr Jul 1 '15 at 19:16
  • That is correct. Most applications are not built with PAM support. Your ls reference is not really an issue in embedded systems where there aren't any "users" so to speak. All critical boot mechanisms support this style of operation, however, and for those interested in mastering the security of their operating environment(s) this (PAM-based) method (when customized & implemented properly) will thwart most advanced attacks against these hardened systems. – Nick Jul 1 '15 at 20:51
20

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.

  • 5
    The password is not encrypted, it is hashed – Tobias Kienzler Jul 2 '15 at 10:31
  • @stig-hemmer, just a quick heads up that I requested an edit to your question changing "Encrypted" to "Hashed". I think you can reject this edit if you feel it does not conform with the meaning of the post, feel free to. I felt the edit was appropriate after reading this post on meta.. – Cowthulhu Jan 12 '18 at 15:31
7

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.

7

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

  • Passwords were hashed, not encrypted. – Philipp Claßen Feb 21 '18 at 10:01
4

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.

  • 2
    I'm not sure why this got a downvote. – Gene Jul 2 '15 at 11:32
0

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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.