HackTheon Sejong 2024 Preliminaries - Writeup

type

status

date

slug

summary

Forensics

Rumor

1

We unzip the EVENTLOG.zip file and there are many events:

The are so many events (9040) but not so many categories (about 50), so we scan through each categories to find the server communicated using Mail protocol like SMTP.

And here we got it:

So the IP address of the mail server that Thunderbird trying to communicate is 92.68.200.206.

And here we have the flag:

2

Tracing through the log event, i can see a nc64.exe file being executed

With an IP and port available, i think this might be a reverse shell which grant attacker a way to get in the victim’s machine and execute commands

⇒ submit 3868 to get flag

i’m not sure about the above pid because im writing this after the ctf end, and i have no way to make sure if that pid is true. But the process is nc64.exe.

3

It’s seems that event ID 1 contains command, by going through these event, there is a large number of ip being pinged. The ip range is 192.168.100.0.

Using above website to calculate CIDR notation

⇒ submit 192.168.100.0/24 to get flag.

4

Focus on the time range after the last ping to random 192.168.100.x ping, by going through all the event and decode it ( it’s true, we did that =(( ), i found this sus base64 string.

It’s a reverse shell payload.

⇒ submit the base64 string to get flag

5

Again by going through all the event (at least we have lesser than before), we found this “secret” file. At first we didnt expect it it the key but it’s still worth a try. And it gave us flag surprisingly!!!

⇒ submit secret.tar.qz to get flag

stegoART

We are given an image. The first thing is AperiSolve it. AperiSolve comes in handy when you don’t know what to do (in steg challs there are many XD), it will just brute all the tools and one may know how to proceed. There ZSteg found something:

b1, g, lsb, xy seems interesting. These are some kind of coordinates, and so many that Zsteg did not give it all. We run it again, this time with the -E or --extract option to get all of those coordinates.

The coordinates look close together, seems like they are trying to resemble some patterns. How about we draw them out using some Python?

solve.py

83.6KB

Running the script we got the following image:

We submitted I_LOVE_XY and nailed it.

Misc

MS Office

submit the file to online analyzer, it said that the file should be in .pptx

Change the extension and open the file, we can see the key

⇒ submit that string to get flag

PNG

We see that the png file is corrupted. We checked it with hexedit .

It’s easy to see that the PNG magic bytes is not present. We added it:

Then we open the image and get the plaintext answer:

And there we got the flag:

Confidential

We got a pdf after unzipping the file:

Then we parse it using pdf-parser , and discovered something special. An embedded hexlified JS:

We parse all of them and get the following JS:

We run it, dump the output to a file and check its bytes:

It’s a PKZip file, and we see some archives in it. But when we directly unzip it, there goes an error. The Zip file is corrupted.

We then tried to fix the header but to no result. We then dump all bytes of the corrupted zip file to CyberChef and try to extract only necessary data:

We traverse through files, trying to find any suspicious content, then we have the following one:

We submit the string I_cant_b3li3v3_y0u_put_a_fil3_1n_a_PDF and got the flag.

Pwn

Findiff

There are 2 version: vsftpd and vvsftpd. Using bindiff we can see that the new version vvsftpd has a few changes:

The command size to fetch gets increased from 0x1000 to 0x4000

Inside init_connection, there is a new signal call to getFlag

So if we can cause SIGSEGV, the flag will be printed out for us.

Solve script:

Intelitigation

The binary has a custom canary mitigation, this canary value is loaded through this function

The canary is saved in the binary itself

So when we connect, we are given the binary which will include the canary value

The vulnerability is a simple stack overflow:

Knowing the canary, we can abuse partial overwrite to return to main, doing this will print out the address of the function main too, due to printf.

There was one useful gadget that set rdi to rsp:

And there was one function that open any file and output the content:

Using these two, we can read /flag

Account

Vulnerability

The vulnerability is one null byte overflow in edit account buffer.

Imagine if account has type 1 and buf = “AAAA”, then len will be calculated with strlen and equal to 5. And if we edit with a 16 bit string “AAAA”, then the 2 * get16Len will be qual to 4.

This means, strcpy16 will be called. strcpy16 will put an extra 2 null byte at the end, so in total, 6 bytes will be used.

But the buffer only have 5 bytes, so we overflow with 1 null byte.

There are 3 types of chunk on the heap:

Account struct

Group struct

The account buffer, which we can control size and content.

Heap allocator

There is a custom heap allocator which is very simple.

There is a large page of 0x1000 bytes, this is the area malloc will return memory from.

Every allocated chunk will be linked in a singly-linked list, when we free the chunk it will set inuse to 2, and when we malloc.

To reuse a free chunk, the size has to be equal

If there is no free chunk, it will return a pointer at the top chunk, using allocator→off + allocator→page

Exploitation

We use the null byte overflow to write into the type of account struct. Then we set the type again to 1. Now we can overflow into the ref count of account struct. It looks something like this:

By overwriting refcount to 1, we can add an account to group and free it right after to achieve dangling pointer → UAF.

Then we reclaim this dangling pointer memory with a group struct.

Now, the UAF account will have buffer pointing to group account list. So if we add any account to this new group and print out the content of UAF account, we will leak the address of heap page.

We will now reclaim, the UAF account with arbitrary data to achieve arbitrary read.

Do the same thing again, to leak libc address.

Remember, this dangling account pointer is also where group 1 struct is. So we can reclaim and overwrite group struct vtable to achieve RIP redirection.

Finally we can trigger the calling of vtable, by using add account to group operation.

Solve script:

Rev

Decrypt Message 2

The encryption scheme is simple:

Xor the message with a random key of 5 bytes.

The key value will be sorted in an ascending order, the message will be divided in 5 bytes block and will be shuffle according to that key sorting.

Here idx[n], is the index of key n in the newly sorted array.

Recover the key

We are given the encrypted message and the first 5 bytes of the original message.

Because the first step will change the message value, and the second step will shuffle the value. We can shuffle all possible enumeration of the first 5 bytes of encrypted message then xor with the 5 bytes of original message.

Doing this we can generate all possible keys.

Now valid keys have to have printable characters and, encrypting the original 5 bytes with this key will result in the same encrypted message.

So that’s what we do

Recover key script:

Now we have the key, to actually retrieve the msg, we have to use this key to decrypt the cipher text

The idea is to reorder the byte in cipher and then xor with the key

⇒ submit BrU7e_fORcE_l5_p0w3rFu1i! to get flag

Decrypt Message 1

This is the important algo for this chall

Simply recreate the algo and brute force each byte

Reorder the hex in that list for each element, we get the string “GODGPT!!!!!!”

⇒ submit GODGPT!!!!!! to get the flag

Revact

Inspect the web, we can see a sus .js file

Going through the code, and focus mainly on the className “mt-5”, we can see there is some checking here

Along with that, the correct or wrong string is decided base on this

With all of these things, the key we need is “XG@@DzX”

⇒ submit “XG@@DzX”

Web

DogGallery

We searched here and there, thinking that we may have to do a reverse challenge once again, until we answer the question, how did the dog images rendered?

Then we found this suspicious client-side request:

So the image is actually accessed from a S3 bucket named htodogpics using the following pattern: http://htodogpics.s3-website.ap-northeast-2.amazonaws.com/KakaoTalk_20240322_${e}.jpg .

So we try to get our feet in the bucket and here we listed them all.

And the final punch.

We submit IMPORTANT_S3_P0L1CY_ByJ and nailed the challenge.

Forensics

Rumor

1

2

3

4

5

stegoART

Misc

MS Office

PNG

Confidential

Pwn

Findiff

Intelitigation

Account

Vulnerability

Heap allocator

Exploitation

Solve script:

Rev

Decrypt Message 2

Recover the key

Decrypt Message 1

Revact

Web

DogGallery

👋Hello World!

HackTheBox - Trip to Guru #2