I am confused about LFI where I have seen many broken web-app demos demonstrate LFI where they traverse to a directory similar to /etc/passwd. How are these passwords being stored exactly? I do not understand why there is a directory for passwords. Surely a database would be in-use and the passwords would not be lying around like this?

Quite new to ethical hacking and pen-testing and would appreciate any insight into this.

  • 2
    /etc/passwd is not a directory, it is a file on *nix systems that used to store the password hash and other user information. Nowadays, it doesn't contain the password hash anymore, but still contains information on what users exist on the system and related information. It is a good example for demonstrating LFI because it is generally readable by all users.
    – nobody
    Mar 14, 2022 at 19:56
  • See askubuntu.com/questions/654923/… for why /etc/passwd is often used by ethical hackers for proof of concept, and as a way of showing a method of gaining access to a system.
    – mti2935
    Mar 14, 2022 at 20:47

2 Answers 2


Most often when testing for LFI exploits, you try to traverse to /etc/passwd to validate that the webapp is vulnerable to LFI, not usually to find passwords. There's a few good reasons to go for /etc/passwd:

  • It exists on all linux systems so it's a reliable target.
  • It's readable by all users so even the low privileged user should have permissions to read it.
  • It lists all user accounts, including whether they have a login shell. Also useful in a pentest.

While it's possible to set a user password in /etc/passwd, it's foolishly insecure (remember everyone can read it). So what's in it then?

jdoe:*:202:202:John Doe:/home/jdoe:/bin/bash

That * means that the hashed password is stored in /etc/shadow which is owned by root and should not be readable except by root. Learn more about /etc/passwd here


First, the LFI issue.

OWASP Local File Include definition:

Local file inclusion (also known as LFI) is the process of including files, that are already locally present on the server, through the exploiting of vulnerable inclusion procedures implemented in the application. This vulnerability occurs, for example, when a page receives, as input, the path to the file that has to be included and this input is not properly sanitized, allowing directory traversal characters (such as dot-dot-slash) to be injected. Although most examples point to vulnerable PHP scripts, we should keep in mind that it is also common in other technologies such as JSP, ASP and others.

What you usually see is someone exploiting a PHP script to load a non-PHP file. In those cases, if the file does not contains <?php (or <? if short_open_tag = On), the file will be displayed instead of executed.

Now, /etc/passwd: it's a file on *nux systems with some information on all users: its username, name, UID, shell, and home folder. /etc/passwd must be world-readable because it contains the UID->username mappings, home folders (so you can map ~username to /home/users/external/u/username, for example). It does not contains the passwords anymore, those are stored on /etc/shadow and it's restricted: only root can read it.

As /etc/passwd is world-readable, it's used as a PoC to see if you really achieved local file inclusion. If you try to include /etc/passwd and fails, it's because the LFI failed, not because the file does not exist.

You must log in to answer this question.

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