Solving this was a ticket for an after party for this year’s BlackHat organized by Awake Security. Although I couldn’t go to the BlackHat this year nor the after party, I found this challenge very interesting and worth a post.

If anyone wants to try the challenge, this is the actual PCAP file downloaded from this registration form.

Let’s dive in!

Reading the instruction

When you open up the PCAP file, you’ll notice that there’s a HTTP GET request to /instructions.hello. Let’s see what’s in there first by “Follow HTTP Stream”.

Well, it looks like a normal instruction except one thing: Accept-Encoding: gzip, xor. Never heard of xor encoding for HTTP request, maybe a clue for the flag.

Weird stuff in mDNS

When you look through other frames, you’ll notice a few mDNS packets buried in a bunch of TCP packets. But the search queries definitely don’t look legit, like alert.msg, cyberchef.helps and key.version? They might be another clue for the flag!

Are they really just TCP?

You might be stuck at this point (well, I was), as what’s left were five similar TCP connections between 75.101.121.222:44344 and 192.168.1.116 in which you can find little human readable strings, except for “Agbogbloshie” and “Golden Showers Far East Import” (WTF?).

But if you look closely enough, you’ll realize that the data payload of many of these packets starts with the bytestring 16 03 03 00.

Unfortunately, I don’t know the header bytestring of every common protocol by heart, so I just googled it and found that it’s a header for TLS packet! (This web page has a great explanation for the protocol format.)

Now, all you need to do is to decode these packets as SSL stream.

Finding the flag

Once you decode them as SSL and go through them, you’ll realize one weird thing: Encrypted Alert in the frame 524.

If you remember the earlier clue alert.message, you’ll realize this packet probably has some clue. The packet header says the message length is 308 (or 0x0134 if you prefer hex), so I extracted the message part (from the bytestring 50 4b 03 to the end, which is right after the length header) and use Cyberchef to figure out what it is. (cyberchef.helps was another clue from mDNS packet.)

When you use the Detect File Type operation, you’ll see that this is a zip file!

Cool, let’s just unzip it — this is the unzipped file in Cyberchef.

Umm, it’s still not really readable… But remember, you still have two remaining clues: key.version from mDNS and xor from the instruction page.

Aha, maybe XORing this file with the Encrypted Alert’s version (0x00de)?

And here it is, found the flag!

Originally published at taishi8117.github.io on August 9, 2017.

Today, I will show you how to exploit a simple buffer overflow against my custom vulnerable TCP server, by developing a custom exploit module for Metasploit Framework. As you know, Metasploit Framework is the most popular pentesting tool out there. It is extremely powerful and covering exploits of most public vulnerabilities, and thanks to its user-friendly framework, it is also really easy to develop your own exploit module.

So, let’s dive in. I have prepared a stupidly simple and vulnerable TCP server in C, as well as its client in Python — you can download them from here.

Vulnerable Server

The source code for the vulnerable server is located here. It is a very simple TCP server, so I will omit explaining what each code does, but below is the vulnerable part, which is called as soon as a client socket is accepted.

First, it reads 4-byte header, indicating how many bytes to read for the body. And using that value, it then reads the body into buffer. As you can guess, it is obvious that int read_bytes = read(cli_fd, buffer, to_read); has a buffer overflow vulnerability, since to_read can be much larger than 1024!

Let’s try it out. I will use Ubuntu 14.04 64-bit for this experiment, although I will compile the server in 32-bit mode for the sake of simplicity.

For the Makefile, make sure that if you are compiling in 32-bit mode on a 64-bit machine, CFLAGS=-m32 is turned on, as well as -fno-stack-protector and -z execstac.

Also, I will do this experiment without ASLR. If you want to learn how to bypass ASLR, you can check the previous article.

Let’s look at how this server behaves. Open a terminal, and compile and start the server by ./tcp_server 1234. On another terminal, modify the Python client, so MESSAGE = "Hello\n" and executes it. You should see the following.

And on the server terminal, you should see the following.

Cool! Let’s also check the offset for EIP, using GDB and peda’s pattern_create function. In this case, since the buffer size is 1024, I created a pattern with 1200 characters, so it will be large enough to overflow.

Copy the pattern to the value of MESSAGE for the client script. Then start the server inside the GDB by run 1234, and on another terminal, start the client. The output on the client terminal should look like the following.

On the other hand, the output for the server side should look like the following.

Using pattern_search, we now know that EIP will be overwriten by 4 bytes starting from 1040th character in the body. This means that including the 4-byte header, the RET address needs to start from 1044th character. We also know that the address of the top of the stack is 0xffffcfe0, from which our payload will be written and executed. Now, we know everything for the exploit!

Writing an exploit module for Metasploit Framework is quite simple, but you need to first set up the development environment. Although I will not elaborate on this, you can refer to this page, which has a perfect instruction!

Now, I assume that you have successfully set up the development environment for Metasploit :-)

Just to give you some sense of how the codes are organized, exploit modules are located under metasploit-framework/modules/exploits directory, payloads are under metasploit-framework/modules/payloads, and the core library for Metasploit is located under metasploit-framework/lib/msf.

For this article, I will create a module called bof_lab.rb under metasploit-framework/modules/exploits/custom directory. It can be downloaded from here. If you want to test it with Metasploit Framework, make sure bof_lab.rb is copied somewhere under metasploit-framework/modules/exploits, so it is automatically loaded!

I will also not elaborate on the details of how to develop a custom module, since there are a lot of documentation out there. You should probably read this first, if you are interested. Instead, I will briefly explain the code.

First, I included Metasploit’s TCP library (include Msf::Exploit::Remote::Tcp), as I need to connect to a TCP server.

In initialize(), you need to define some information about the exploit module, such as name, description, payload encoding and target architecture. In this case, I will not use any payload encoding for the sake of simplicity, and the target architecture would be linux x86 (this is because I compiled the server in 32-bit mode). I will also define Ret to indicate where the payload will be located (which is 0xffffcfe0 as we found earlier).

check() method is for testing whether a target is vulnerable. But for the sake of simplicity, I made it to return that the target host is always vulnerable.

Now, exploit() is the core part of this module, as the name suggests obviously.

It basically connects to the server, sends A for 1044 times (which is the offset), and Ret and finally the payload. That’s it, super simple!!

Exploit!

Now, let’s try an exploit!

Note that my environment was the following:

• Server (10.0.1.130) listening on port 1234, username: sirius
• MSF (127.0.0.1), reverse handler listening on port 8888

First, start the msfconsole and direct to the module that you just created.

Let’s specify options, according to the environment. For payloads, I will use linux/x86/shell/reverse_tcp, so I can get a shell of the server. You can also specify other payloads, if you want to play around with different ways.

Here we go! You got it!

Originally published at taishi8117.github.io on July 24, 2016.

For those who are not so familiar with ASLR, it is a common countermeasure technique against traditional stack-based stack buffer overflow exploit — it randomizes the memory address layout (e.g. stack) every time a program is run so that an attacker cannot know the exact location of shellcodeo or variable etc. beforehand. It is enabled by default for most recent operation systems, and it is fairly effective for 64-bit systems (the range of randomization of address layout is 28-bit). However, for 32-bit systems, the range of randomization of address layout is so much smaller that bruteforcing is feasible.

So, in this article, I will demonstrate a bruteforce against ASLR in 32-bit system, so that an arbitrary shellcode can be run. Note that other countermeasure techniques (e.g. DEP, Canary) are not used for the sake of simplicity in this experiment. (I promise that I will post about attacks against these techniques in the future!) Also, source code used in this article can be downloaded from here.

I will use Ubuntu 14.04 32-bit for this experiment.

And here is a simple vulnerable program that I will use. As you can see, vuln() function has a buffer overflow vulnerability when strcpy is called.

And for Makefile, make sure that -fno-stack-protector and -z execstack are included in the flags.

After it was compiled, make sure that ASLR is turned on. Note that echo 1 | sudo tee /proc/sys/kernel/randomize_va_space can turn on ASLR. (echo 0 to disable, echo 2 to enable full ASLR)

Let’s examine how the program behaves when its buffer is overflowed.

As you can see, 4 bytes starting from 112th character in the input string will overwrite EIP.

Let’s also check how ASLR affects the address of buffer.

As you can see, the location of buffer is randomized every time the program is run, and it is impossible to guess its exact location for the next execution. However, if you examine the location of buffer enough times, you will realize that its location is within the range of 0xbf*****c. In this case, there are 1048576 possible locations where buffer is loaded. So, you can use a strategy — randomly pick a memory address within the valid range, and run the program repeatedly until buffer happens to be located at that location and that’s when the shellcode is executed.

Let’s also write a shellcode that executes ‘/bin/sh’ so you can get a shell. I will not explain the details of how to write shellcode, but there are lots of resources on the web that you can find very useful.

Now, we have everything that’s needed to exploit this program. Below is the exploit code written in Python. Note that in order to increase the chance of shellcode being executed, I added 4096 bytes of NOP instruction right before the inserted shellcode. In this way, if the returned address (=addr_buffer+bufsize+offset+4) happens to be within this NOP range, the shellcode is properly executed as well (the longer the NOP sled, the less number of attempts necessary for a successful attack).

And here it is! The shell was given after 998 attempts in my case. You can experiment in your environment too. Normally for this program with 4096 bytes of NOP sled, around 1000 times of attempts are necessary for a successful attack, which is significantly less than 1048576 (the number of possible address location of buffer)!

Originally published at taishi8117.github.io on November 11, 2015.

In this article, let’s exploit a simple SUID-ed program with a stack-based Buffer Overflow to add a new root-priviledged user with a chosen password. This example is referenced from the book Hacking: the Art of Exploitation.

I’m using x86_64, but I will compile the program in 32bit mode.

The program shown above simply appends buffer to the file /var/notes. When strcpy is called to copy argv[1] to buffer, it can cause a buffer overflow — when more than 100 characters are stored in argv[0], then the remaining string would be overflowed. The Makefile shown below is used to compile and chown/chmod the program.

When argv[1] is not over 100 characters, it works perfectly.

Since the offset between buffer and datafile is 100 (same as the size of buffer), the overflowed strings of argv[1] will be overwritten to datafile.

By exploiting this BOF, let’s create a new user with a chosen password by appending to /etc/passwd file. Following the format of /etc/passwd in UNIX system, I will add username myroot with password password — myroot:AA6tQYSfGxd/A:0:0:me:/root:/bin/bash. As shown below, password is encrypted using Crypto() OpenSSL cryptographic library with a salt “AA”. Note that the 3rd & 4th entry (i.e. “0:0”) indicates root privilege. If you want to know the format of /etc/passwd more in detail, refer to a link here.

The content of datafile needs to be /etc/passwd, but the last entry in /etc/passwd needs to specify the user’s default shell. So, let’s create a symbolic link with the name /tmp/etc/passwd pointing to /bin/bash. Then, adjust the length of the user ID info (comment section), so that the location of /etc/passwd would be at 100.

Good. And here it is, you get the root shell.

Originally published at taishi8117.github.io on November 7, 2015.

ksnctf is one of the beginner level CTF websites. This article is the write-up for the question 4 Villager A, in which you need to exploit the Format String Vulnerability to capture the flag!

Note that this article includes a complete solution. If you are looking for some hints for Villager A, you should refer to these keywords: Format String Vulnerability and GOT overwrite.

Write-up

Connect to the server

Using given information, access to the server ssh -p 10022 q4@ctfq.sweetduet.info
In the server, you can find

Analysis

Since I don’t have an access to read flag.txt, it seems that I need to somehow exploit q4 (SUID=root) to read the file. Let’s disassemble main().

It seems that at <main+48>, fgets() is called to get a string from stdin; at <main+72>, printf() is called to output the string. But, it’s kind of weird that printf() was called at <main+60> to output “Hi, “, and after that, putchar() was called to output “\n” (0xa). Why are they called separately, instead of calling just one like printf("Hi, %s\n", input); as you probably more familiar to write. Now, I’m getting suspicious that there is a format string vulnerability in this program. (I mean, it’s a CTF program)
What if I input some kind of format string at <main+48>?

It’s now clear that there is a format string vulnerability at <main+72>. So, let’s think about how to exploit it to read flag.txt.

Realize that 0x1 is moved into [esp+0x418] right before the jump to <main+205>. Then, 0x1 is brought back to eax, followed by jne at <main+219> – if the value of eax is not 0 (or ZF = 0), it jumps to <main+102> that is a loop asking “Do you want the flag?”, as shown below.

On the other hand, if the jump was not taken, then it opens flag.txt and print it out (from <main+212> onwards) One possibility to attack this program is by using format string attack to change the value of [esp+0x418] to 0 before jne at <main+219>, but it wouldn’t work because mov [esp+0x418], 0x1 happens after the string vulnerability. Moreover, ASLR (Address Space Layout Randomization) is enabled on this system, so guessing the stack address of [esp+0x418] is very hard.

Exploitation

Remember that ASLR doesn’t disable the randomization of memory address of code section. If I can somehow set eip to <main+221> (0x08048691), I should be able to read flag.txt.
Right after the format string vulnerability, putchar@plt is called, using PLT. That means, if I modify the address referred at putchar@plt to <main+221>, I can modify eip!
Let’s examine.

So, it seems that if I change the value stored at 0x80499e0 to be 0x08048691 (<main+219>), I can read flag.txt.

As examining the format vulnerability, it seems that the input string is stored at 6th place from the top of the stack.

Capture the flag!

Now, we got all the informatin needed.

• modify the value at 0x80499e0 to 0x8048691
• offset is 6

Some calculation

Thus, the exploit code is

Then, the flag was: FLAG_nwW6eP503Q3QI0zw

Originally published at taishi8117.github.io on October 20, 2015.