Practical strategies for exploiting FILE READ vulnerabilities

  • And what are the generic prevention / detection strategies for web applications.

1. FILE READ — what’s that?

The result of many vulnerabilities in web applications and similar technologies is the so-called file read, which is ability to read content of files. This means that an attacker can learn the contents of some files that are located on some server belonging to the application infrastructure. From the methodology standpoint, file read itself is often consequence of other vulnerabilities being present, such as:

  • SQL Injection
  • SSRF
  • XXE
  • Path traversal
Click HERE for full size picture.

1.1 File read and LFI/RFI

Often, File Read vulnerability may be the result of LFI / RFI (Local / Remote File Inclusion) vulnerability. How are they different? Read means that we can know the content of a file, display or transfer its content to ourselves. This is the case we are discussing.

1.2 Exploitation of file reading… so what exactly?

A vulnerability that leads to reading files can have a different level of risk. It all really depends on what actually results from the fact that we can read a file?

2. Confirming the vulnerability — TIPS & TRICKS

If a vulnerability or functionality of the application offers us the ability to read files on the system, we will usually find out about it in two ways:

  • We will be able to read some file from webroot, eg .js file, whose relative location is known from browsing the server, e.g.
  • Try to provoke Stack Trace / other error message. This might allow you to know the absolute path that exists on the server and try to reference the existing files like below:
  • Try to read the path “.” or “/” — so read a directory, not a file. In some cases, it may happen that the application will display the full directory listing, which will make the task even easier — by displaying all the files contained there
  • Try to read files other than /etc/passwd — especially shorter and not containing non-alphanumeric characters, e.g. on Linux they can be /etc/hostname or /etc/issue,
  • There is a much bigger problem with “sure” files on Windows, but if we control the full path, we can refer to the UNC path (if you don’t know this technique — read on!)

2.1 Do not get confused by the application

Just because a file is unreadable doesn’t mean it doesn’t exist. It could also happen because:

  • The file is too large, or contains characters that “cannot be digested” by the application for some reason. Often, such situation can occur in the case of binary files and in the case of reading files through the XXE vulnerability
  • The application cannot access the file we want to read. Well-configured applications are not allowed to read files on the file system, so files can only be read from webroot. Of course, this still leaves the attacker or tester a lot of room for maneuver — we will also consider such a variant later on.
  • If we want to read a file from another directory using a technique such as Path Traversal, we can use different types of encoding — sometimes ../../ will not work or will be filtered by the application, but e.g. \\ ..\\ ..\\ .. will be alright. Many examples of this type of coding can be found on THIS wordlist, which you can of course modify for the needs of individual tests.
  • It is worth taking the above into account if during the tests we suspect that such a vulnerability exists — it is best to check several different options, because the vulnerability may be somewhat camouflaged.

3. Getting to the core

We can read files on the server and we want to show how dangerous this vulnerability is, or we even want to obtain additional information and take control over the server. What we do? What files do we read?

3.1 Linux

· /etc/issue — this file should always exist, it is rather short, but it contains very important information that is useful further — the exact version of the operating system. Thanks to this, we can re-create the environment locally and then find out which files definitely exist on the same version of the system.

find / -type f -size -510c -name "*.gif" 2>/dev/null

3.2 Windows

The situation on windows is a bit more complicated, because Windows is much poorer in “interesting files” compared to Linux. To confirm the existence of a vulnerability, we can try to read, for example:

  • C:\boot.ini — as above
  • Remember that on windows you sometimes need to escape the backslash so use “\\” instead of “\”
use auxiliary/server/capture/smb module

3.3 TIPS & TRICKS — remaining techniques

Depending on the technology and what files we find on the server, interesting information that can help us get to administration panels, databases, etc. may be in files.

  • Configuration files and included by other files. It is worth checking if any files are “required” or “included” and then follow the trail of subsequent attachments. Finally, we can get to some configuration file that supports e.g. database connections.
  • If we can list directories, we can try to find a sessions directory on Apache — then mount the filename as our PHPSESSID cookie and possibly hijack other people’s sessions
  • A .htpasswd file that may contain credentials that we may try to crack.
  • web.config — on older .NET versions, the web.config file contains the so-called Machine Key used to encrypt ViewState parameters. Reading it can help us perform a deserialization attack against the application. You can read more about this technique HERE.
  • the new .NET Core no longer uses this mechanism
  • .ASP files and similar to .PHP files may contain sensitive data
  • .JSP files similar to .ASP and .PHP — we are looking for sensitive data
  • /WEB-INF/web.xml — we are looking for hidden endpoints
  • downloading and decompiling .jar libraries in order to find secrets in the code or to learn about the application logic
web.xml may contain paths to hidden application endpoints (servlets) in servlet-mapping elements
  • In Node.js or ruby we can search for .env, / config files
  • One of the interesting methods may be to run the Content Discovery tool (Dirb, FFuf, GoBuster, Burp Intruder etc.) directly on the vulnerabilities. We can then use a technology-specific wordlist.
  • If the application allows it (it will not be overwhelmed by the number of queries), above technique can find many files. It’s like content discovery on steroids.

4. Summary

There are many problems that may result in reading files. In fact, it depends on the configuration of the application whether the attacker or the pentester will be able to escalate this vulnerability further. And what can the administrator do to defend himself or detect that someone is trying / exploiting such a vulnerability?

  • The application should operate in the context of a separate user who has appropriate restrictions, e.g. no external access via SSH, and cannot log in with the key alone, and has very limited access to the file system,
  • It is recommended to use the Principle of least privilege — that is, the user should not be able to do anything except the actions required for the operation of the application, e.g. reading and writing only to appropriate locations in the webroot,
  • Reading files can often be a derivative of other vulnerabilities such as eg XXE, so it is an effect, not a cause. Nevertheless, it is worth monitoring any attempts to refer to resources that contain specific sequences of characters ../ .. \ etc. These types of requests, especially in large numbers, almost certainly mean that someone is trying to get deep into our application,
  • We protect other services through the use of a firewall and block administrative interfaces against access from outside — then there will be no situation where someone reads, for example, a configuration file for a service and then “enters” us through, for example, Tomcat.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
AFINE

AFINE

If you’re looking for the good guys who are ready and able to hack you, need look no further. We professionally find vulnerabilities before the bad guys do.