It was last Friday. We (Plaid parliament of Pwning) took 4th place in iCTF 2009. This year's iCTF was novel. Thousands of bots were running on UCSB, and they were connecting to us according to the search rank in the web search engine they provided. All the bots were using more than 15 different versions of browsers including Perl, Python, Erlang, Java, and C++.
Since my main role was to do binary analysis, I could read almost every browser code. Especially, C++ browsers were interesting to me, and we were the only team who found all the c++ browsers' vulnerabilities and crafted exploits for all of them during the competition.
Here, I will present a walk-through for crefox-1.0 problem, which is the first-level C++ problem.
The most interesting part in this problem is that it uses dlopen function. At first glance, we thought the program uses "safe_printf" function from a certain library. However, this was just a trick! Let's look at the source code below.
The line of strncmp function is the most tricky part in this problem. Note that they first check a weird string and if it matches, it will load a function called "safe_printf". However, the returned function from dlsym is NULL here.
So what will happen when the function pointer f is called? The instruction pointer will go to the address of 0x00000000. So, here, we expect the segfault. Right?
However, the program will not terminate. Why? Let's look at the previous part of the source code before the print_func function is called. The most important part is shown below.
So, the program usesmmap to allocate memory at the address zero! In addition, our page URL is copied to the memory. Therefore, we can execute arbitrary code we provide. Note that mmap used PROT_EXEC option to run the code.
The only problem is that our page URL should start with the string USESAFEPRINTFUNCTIONA. We need to know what will be the instruction for the string. Fortunately, the string represents a valid sequence of instructions as follows.
They are just push and increment instructions. So the next step is really simple. We only need to put our shell code right after the string USESAFEPRINTFUNCTIONA. In this way, a web browser who visits our website (including the string USESAFEPRINTFUNCTIONA and shellcode in the page) will run our shellcode, and connect to our web server.
It was really fun to play iCTF, and all the binary problems were really intriguing. The next two problems are more tricky, and I will explain them later if I have time. :D
Full source code:
reff : http://blog.divine-protection.com/2009/12/ictf-2009-c-binary-review-1.html
Since my main role was to do binary analysis, I could read almost every browser code. Especially, C++ browsers were interesting to me, and we were the only team who found all the c++ browsers' vulnerabilities and crafted exploits for all of them during the competition.
Here, I will present a walk-through for crefox-1.0 problem, which is the first-level C++ problem.
The most interesting part in this problem is that it uses dlopen function. At first glance, we thought the program uses "safe_printf" function from a certain library. However, this was just a trick! Let's look at the source code below.
1 | int |
The line of strncmp function is the most tricky part in this problem. Note that they first check a weird string and if it matches, it will load a function called "safe_printf". However, the returned function from dlsym is NULL here.
So what will happen when the function pointer f is called? The instruction pointer will go to the address of 0x00000000. So, here, we expect the segfault. Right?
However, the program will not terminate. Why? Let's look at the previous part of the source code before the print_func function is called. The most important part is shown below.
ptr = mmap(NULL,
size,
PROT_READ | PROT_WRITE | PROT_EXEC,
MAP_PRIVATE | MAP_ANON | MAP_FIXED, -1, 0);
The only problem is that our page URL should start with the string USESAFEPRINTFUNCTIONA. We need to know what will be the instruction for the string. Fortunately, the string represents a valid sequence of instructions as follows.
0x0: push %ebp
0x1: push %ebx
0x2: inc %ebp
0x3: push %ebx
0x4: inc %ecx
0x5: inc %esi
0x6: inc %ebp
0x7: push %eax
0x8: push %edx
...
It was really fun to play iCTF, and all the binary problems were really intriguing. The next two problems are more tricky, and I will explain them later if I have time. :D
Full source code:
1 | /* |
reff : http://blog.divine-protection.com/2009/12/ictf-2009-c-binary-review-1.html
0 comments:
Posting Komentar