National Cyber Week Quals
Team: Times heals all sorrows Get over, no worries ‘Cause nothing is more precious than love Nobel, faithful, she is as pure as the driven snow Oh dear heart, so sweet
Rank: 9 / 54
gandalf
Binary Exploitation
491 pts
4
KaZooYa
Binary Exploitation
496 pts
3
veight
Binary Exploitation
500 pts
0
gandalf
Description
You are currently playing as Gandalf, a powerful wizard known for exorcising, hunting, and even striking deals with devils or dark spirits. Recently, a friend entrusted you with a Dybbuk Box, an ancient and cursed artifact that holds dark spirits within. To destroy the malevolent entities trapped inside, you need to craft a powerful spell. However, the box is sealed with several intricate locks that must be bypassed before you can open it and confront the chained spirits, putting an end to their dark influence once and for all.
Author: Brandy
nc 103.145.226.92 24234
Analysis
we're given the following files
└──╼ [★]$ tree .
.
├── gandalf
└── libc.so.6the program is divided into 2 stage, locked and unlocked each with different interface to interact with.
since's the binary is stripped, the function names below are renamed based on my understanding
in the main function we can see that a call to prefix() has to return 1 in order to continue to the next stage
this is the interface we're dealing with in the locked stage
the first and fourth option does nothing, the third option provides a format string vuln but I don't find a way for it to return 1, so I take it as a bait
the only way to continue to the next stage is through the second option
the seed is determined using the current time and thus can be replicated, we can predict the random number easily.
this is the interface when we continue to the unlock stage where it became the typical CRUD Heap challenge, without the Update
first option is the show option
second option is the allocate option
third option is the free option and where the vulnerability lies because the pointer is not cleared enabling UAF
the fifth option does nothing while the fourth option exits and sixth option returns.
I also want to mentioned that the binary applies seccomp
Exploitation
first, to pass the locked stage we simply need to replicate the seed and reverse the random number generation, I wrote the following function to do so:
next since this is a heap challenge, seccomp will actually use quite a lot of heap space, can be seen in the bins below
so in order to make the exploitation easier to debug, I cleaned the bins first
with the bins cleaned, I utilize UAF to get an easy libc leak through unsorted bin and heap leak
because of seccomp, we're forced to do an ORW ROP, to do this we need an arbitrary read to environ and arbitrary write to write the ROP payload.
we'll achieve it through tcache poisoning, but without the edit function how are we gonna achieve this?
we can do this through double free, but since libc is 2.35, double free on the tcache will not work, however it is still applicable through the fastbin thus the technique fastbin dup
first we'll allocate the tcache to its max size (7) and then link 3 chunk into fastbin with the pattern A - B - A to cause a double free
to profit, since tcache takes priority, we'll just need to consume all the tcache and then proceed to overwrite the first fastbin's 8 bytes with the target/address you want to achieve read/write, in this case I want to gain arb read to environ to leak stack
now we can allocate one more chunk to gain access to it, however notice that the allocate function uses fgets to take input, this means we have to overwrite the contents of it possibly deleting the stack address, even a new line will make the it NULL terminated and puts will unable to print it.
to bypass this we can easily request malloc of size 0x0, this will make malloc default to return a chunk of size 0x20 but since the size passed to fgets is still 0x0, we are not going to input anything to it.
next using the same technique we'll write ROP payload to the stack, however we can't do this within the main's stack frame, this is because before returning, the binary will call sleep() which is not allowed by the seccomp
which means if wanted to ROP it must be from the stack frame of the fgets call inside the second option's function.
another thing to note is that fastbin holds a maximum size of 88 bytes chunks, which is not big enough for an ORW ROP payload. to get around this, we will write a shorter ROP payload that calls read which then followed by the bigger ORW ROP.
here's the exploit being ran againts remote
below is the full exploit:
Flag: NCW{b1c3a7d9e8f4a2b6c9e7d5a3b8f1c2e4d7b9a8c1f5e6a2b9d4c7e5b3a8d9c2f4b7e1a3c6d8f2a7b5e9c1d3f6a4b7e2c5d9a1f3e7d6b8c2a4e9d1f5b3c7a6d2e8b4c1f9d5b7a2c3e4f8b9d6a1c5e7d3b8a9c2f4d1b5e6c3a7d9b8c4f1e2a6d5b3e7c9f2d8a1c3e5b7d6a9f4e2c1b8d7f3a5}
KaZooYa
Description
Everything's digitalized nowadays, I think it's time a zoo too.
Author: Xovert
nc 103.145.226.92 7272
Analysis
given the following files
running the binary, we're greeted with an address leak and these options
I tried to decompile the binary in ghidra, but it turns out its made out of C++ and ghidra is not clean, so its time for IDA to shine
we can see that the leaked address is a global variable called globalbuf, taking a look at init() reveals that globalbuf contains an mmap'ed rwx address.
in IDA we can see that globalbuf is referenced by getstr
which is called in two functions, editName and feedback
in init I also take notice that there's an vector of type Animal reserved for length of 4. as you'll see later there's also a class called Monke and Cat whjch I assumed they're inherited from Animal
I won't bother with decompilation of other of the options as it is quite messy, and with C++ I much prefer dynamic analysis
in short, we can interact with each of the option using the functions below:
I want to mention at this point I had read a bit on reversing C++ objects from these 2 blog:
one thing that stood out to me while reading it is that in every instantiated object, the first 8 bytes always points to the respective class vtable. I wanted to clarify this and also get a bigger picture of the object's attributes
if I create a Monke and Cat class as follow
we end up with the following chunks
the first 0x30 sized chunk is the reserved vector while each of the 0x70 chunks are objects and the 0x20 sized chunks are the object name's attribute
we can see that both Monke and Cat has the same composition derived from Animal that can be summarised below
there are NULLs and other values that I'm not sure, but I decide to take it for granted.
when we choose the option to hearSound it is actually do some derefencing to the vtable to call the appropriate method
examining in GDB, first is to dereference the object and take the vtable address
then it adds the offset to the table which corresponds to the method it wants to call, in this case it corresponds to makeSound
Exploitation
the vulnerability here is Heap Overflow, using the example in analysis we can see that name occupies a 0x20 sized chunk
however in editName, memcpy copies the amount whatever amount that was returned by prior getstr which is hard coded to input a size of 0x50. we can see this in action
this means we can control the vtable and control what the binary will call upon hearSound, since we have an rwx page, we can put the shellcode there using getStr in feedback and make the object jumps there.
notice that the method that is called is in the 2nd index, so we need to put our shellcode address in the 2nd index of the table.
to do this, the rwx region will act as both the vtable and the place where our shellcode resides.
we'll use editName to overwrite the vtable and feedback to setup the vtable and shellcode
here's the exploit being ran againts remote
below is the full exploit:
Flag: NCW{f5dd5940e67302053400694fbc4564a5e8d783a6f3a8cf0859450b5ff1d4a03a}
veight
Description
Goal run "/readflag"
Author: Enryu
nc 103.145.226.92 11101
Hint 1
Ini basic v8 exploit sih dan jangan terlalu overthinking, build dulu version debugnya 12.7.1, belajar dulu bang di https://faraz.faith/2019-12-13-starctf-oob-v8-indepth/ walaupun tidak sama tetap bisa bersatu, dulu 64-bit sekarang 32-bit
my first V8 pwn :D
Analysis
The writeup assumes the reader has basic knowledge about V8 exploitation, if you're not familiar with it I suggest these two resource that I used to solve this challenge:
we're given the following files
this is the content of args.gn
and here's the patch
above changes are the actual code that defines the new builtin function behaviour and can be explained as follows:
first it checks the argument is exactly 2 using
DCHECK_EQ(2, args.length());, recall with OOP,thisis always passed as the first argumentthen it checks for the first argument has to be a type of
JSArrayit then cast the first argument to
JSArrayand create a new number from the second argumentnext it changes the length of the array to be the said number
above changes are quite irrelevant but important to add the builtin function correctly
the patch in bootstrapper.cc installs the builtin function and defines what the method is called, in this case its whutset
to conclude to this is how we can use the new builtin function
this of course introduces an OOB vulnerability which is I think is the most common and the most powerful vulnerability in the V8 exploitation scope.
Exploitation Foundation
as per my understanding, the steps to pwn a V8 is to slowly build up these primitives:
leak float array maps and object array maps
construct
AddressOfprimitiveconstruct
FakeObjectprimitiveconstruct arbitrary read and arbitrary write primitive
though this is probably only applicable to the easier and introductory side of the challenges as I haven't explore the other more advanced stuff.
nonetheless I think it provides a good foundation to someone who is new to this, and I'll go with it
first setting up our debugging environment in gdb:
then let's start off by defining our helper function, objects, and arrays:
through debug printing and examining the memory I found out we end up with this memory layout:
can be verified through telescope in gdb
Getting Maps
with this, to leak the map of floating array, we can change the length of the float_arr to gain OOB and read float_arr[4] this will return properties | maps, as we only want the maps we'll only grab the lower 32 bits
to leak the obj_arr's map, we can calculate its offset using the map we previously leaked or make use of the OOB to read it, both works
AddressOf Primitive
now alleviating OOB, we can get an address of an object,
first, we'll put the object we want the address of within the array
then we'll change the obj_array's map into a floating one
then, accessing the elements of the obj_array will treated as a raw floating point instead of an object address that will be dereferenced, again because of pointer tagging, the treated raw float is 8 bytes, though the object's address is only the lower 32 bits.
lastly, restore the map to the original object map to perform cleanup
we can try if this is working
it works!
FakeObject Primitive
fake object is one of the most confusing primitive as I first learn V8 exploitation, the purpose of it will eventually be used to gain arbitrary read/write. to better understand this, there's this diagram in the youtube video I linked before that helped me greatly understand this:
the diagram is for V8 version <= 8
the concept is roughly the same as fake chunk in heap exploits, we want to construct a fake object, in this case its JSArray of type floating points. to do this we have to trick the V8 such that a variable will hold an address at the fake object and treat it as an object.
the gist of it is that, later on we will alleviate the fake object's elements to an arbitrary address, accessing the fake object will then dereference the address enabling us able to read/write to it.
first, we'll set obj_arr[0] to the address where we want to put the fake object at, note that I also preserve the length of FixedArray just in case. (if you're getting confused here, take a look again at our memory layout above)
next, the map of obj_arr is still an object, but for good measures, I decided to make sure that the map is indeed an object array map
next, accessing the element will dereference the address we just put before, since the array is an object type, the V8 will then store variable fake as an object. this is the overall gist of the primitive.
Arbitrary Read
from the diagram before, we're going to craft a fake object within a floating array, so let's setup just that:
then we'll calculate the offset to our fake object from arb_rw_arr's JSArray
then different from V8 below version 8, where we would put our elements at arb_rw_arr[2], since the map and properties are 32 bit each, the elements would be placed at the lower bits at arb_rw_arr[1]
this also applies to the offset when reading, where the map and length in FixedDoubleArray is both 32 bit, the offset would be only 0x8 instead of 0x10 as previously shown in the diagram.
then when we treat fake as an array, such as fake[0], the V8 will look at the map and confirmed that it is an JSArray of type float and then read at the raw values at *(elements - 0x10).
let's put it into the test
however it failed,
I tried changing the address to other ones, but it returns the same result
we expect result to contain the map | properties of arb_rw_arr but instead we get what looks like a higher bits of lib address. the reason for this is because our fake object only fakes the map and elements field and completely ignore the properties and length fields.
so let's fix that, I set the properties to 0x725 which seems to be constant throughout the objects I debug printed, for the length it could as arbitrary as you want. we end up with this script for this primitive:
now putting it to the test once more:
now we get the result as expected
Arbitrary Write
arbitrary write is exactly the same with read, but instead of return fake[0] we do assignment on it
however as explained in the NUS Greyhat's video, copying large amount of memory this way will not work and will cause a segfault (I'm also not sure why), a better way to do this is through the Dataview buffer's backing store
it's basically a field that points to region of memory where you then can use the Dataview methods to alter the content of it.
using the arb_write above, you can overwrite the backing store to point to your arbitrary address and then uses its method to write to it
Code Execution
to gain code execution, I will go through the web assembly shellcode route, where we will allocate a page for a wasm code to get an rwx page and overwrite it with our shellcode instead.
I initially thought of why bother go through the previous primitives if we're able to execute wasm code anyway, can't we just make the wasm code our malicious code instead? the answer is no because its simply not a valid wasm code (I think lol)
to do this, lets instantiate a valid web assembly:
the next part is quite different from the blog and video I linked, in their case, the rwx page can be found at an offset from wasm_instace however in this case I found the offset is quite random and not always fixed.
after quite a bit of repeated dp(wasm_instance) I found that the wasm_instance has a field called trusted_data that contains the rwx page, which seems to be at a fixed offset.
so calculate the offset and do the dereferencing stuff, we're able to get a reliable address of the rwx page
next, using arbitrary write we'll copy the our shellcode to the rwx page, and finally execute the wasm function.
and here's the script being ran againts remote:
below is the full exploit:
Flag: NCW{603f1e4f172d5a4305e649aea9425636}
Last updated