Friday, November 9, 2018

Here is a link to my BSIDES talk regarding the 0-day I found, exploited, and reported:

https://youtu.be/YoNrNBnmwuY

Friday, October 20, 2017

SLAE64 Exam - Assignment 7 of 7 (Cryptor)

This post is the seventh of 7 exam assignments of the Pentester Academy's x86/64 Assembly and Shellcoding on Linux.

SLAE64 - 1501

Success in these 7 assignments results in the Pentester Academy's SLAE64 certification.

http://www.securitytube-training.com/online-courses/x8664-assembly-and-shellcoding-on-linux/index.html


All 3 files  used in this assignment are here:
https://github.com/clubjk/SLAE64-3/tree/master/exam/cryptorAssignment:


Create a custom crypter like the one shown in the “crypters” video
Free to use any exisSng encrypSon schema 
Can use any programming language 

I chose an AES encryption script created by Blu3Gl0w13. Check out his excellent blog here.

I elected to use the execve-stack shellcode as a base for this assignment.  I extracted its shellcode using a modified objdump command.



I pasted the shellcode into encryptor.py as well as choosing a key of 'clubjk'.




I executed the script and it outputted encrypted shellcode.



I pasted this encrypted shellcode in decryptor.py as well as adding the key of 'clubjk'.



I executed the encryptor.py and the decrypted execve-stack shellcode executed uneventfully.



It worked. Yay.

Files used in this assignment:

execve-stack.nasm
encryptor.py
decryptor.py

All are here:
https://github.com/clubjk/SLAE64-3/tree/master/exam/cryptor

Thursday, October 19, 2017

SLAE64 Exam - Assignment 6 of 7 (Polymorphic Shellcode)

This post is the sixth of 7 exam assignments of the Pentester Academy's x86/64 Assembly and Shellcoding on Linux.

SLAE64 - 1501

Success in these 7 assignments results in the Pentester Academy's SLAE64 certification.

http://www.securitytube-training.com/online-courses/x8664-assembly-and-shellcoding-on-linux/index.html


All 3 files  used in this assignment are here:
https://github.com/clubjk/SLAE64-3/tree/master/exam/polymorphic

Assignment:

  • Take up to 3 shell codes from Shell-Storm and create polymorphic versions of them to beat pattern matching
  • The polymorphic versions cannot be larger than 150% of the existing shellcode
  • Bonus points for making it shorter in length than original
http://shell-storm.org/shellcode/files/shellcode-878.php - (cat /etc/password)   (82 bytes)

I took the nasm file from the above link, nasm-compiled and linked it.  Used a modified objdump command to extract its shellcode.



I pasted the shellcode into the shellcode.c template.




I compiled the shellcode.c template with the modified gcc command:


$   gcc -fno-stack-protector -z execstack shellcode1.c -o shellcode1

I executed the shellcode, confirmed that it executed "cat /etc/passwd", and noted it's size (82 bytes).


    Polymorphic version of the original nasm

    I made the following modifications to the original nasm to create a polymorphic version to evade pattern matching:


    (did this in each of the four "xor rax, rax" commands.

    I did the same thing for a "xor rdx, rdx" command.



    I nasm compiled and linked it, then extracted its shellcode and pasted into the shellcode.c template.
    I executed it, confirmed that it executed "cat /etc/passwd" and noted it had 97 bytes.






    I created a binary based upon the above shellcode, then a shellcode binary  and executed it.


    Then I created a polymorphic version of its nasm with the following edits.





    Then I created shellcode from this nasm and executed it.



    I confirmed that it executed "execve /bin/sh" as the original did and that it's size was 56 bytes.


    http://shell-storm.org/shellcode/files/shellcode-896.php - (add "127.1.1.1 google.lk" to /etc/hosts)  (113 bytes)


    I made the following edits in 3.nasm.







    I executed the new version of the shellcode, saw that it added the line to /etc/hosts, and that it's size was 133 bytes.



    Test results:



    Files used in this assignment:

    1.nasm
    1poly.nasm
    shellcode1.c
    shellcode1poly.c

    2.nasm
    2poly.nasm
    shellcode2.c
    shellcode2poly.c

    3.nasm
    3poly.nasm
    shellcode3.c
    shellcode3poly.c
















    Wednesday, October 18, 2017

    SLAE64 Exam - Assignment 5 of 7 (Analysis of Shellcode)

    This post is the fifth of 7 exam assignments of the Pentester Academy's x86/64 Assembly and Shellcoding on Linux.

    SLAE64 - 1501

    Success in these 7 assignments results in the Pentester Academy's SLAE64 certification.

    http://www.securitytube-training.com/online-courses/x8664-assembly-and-shellcoding-on-linux/index.html


    •  Take up at least 3 shellcode samples created using Msfpayload for linux/x86_64
    •  Use GDB to dissect the funcSonality of the shellcode
    •  Document your analysis 
    All 3 shellcode.c's used in this assignment are here:

    I chose 3 msfvenom shell to analyze and disect with GDB:

    • linux/x64/shell_bind_tcp
    • linux/x64/shell_reverse_tcp
    • linux/x64/exec

    linux/x64/shell_bind_tcp

    I reviewed this shell code's basic options:


    The only required option for this shellcode is the LPORT which defaults to 4444

    I generated shellcode in c format:

    I noticed a few null bytes ("\x00") in the shellcode, so I re-ran the command with the -b (bad character removal) option:


    I noted that the shellcode size was 127 bytes.

    I pasted the shellcode into the shellcode.c template:


    I compiled it with the following command:


     gcc -fno-stack-protector -z execstack shellcode.c -o shellcode

    I loaded the shellcode binary into GDB with the following command:

    $ gdb -q ./shellcode -tui

    I set up the GDB interface as follows:


    Note: I defined the intel syntax via the .gdbinit file.

    I "stepi'd" until the decoding loop finished:


    I noticed that the code at <code+39> had decoded into something resembling a syssocket syscall (0x29).  I advanced the execution to the first syscall and examined the registers:

    Note also used the "x/6xg $rsp" command to show the first six positions on the stack.


    I noticed that prior to the execution of the syscall command, that rax had the syssocket value of 41, the rdi had 2, the rsi had 1 and rdx had 0.  I executed the first system call and noted the return value of 3 in rax.  



    I stepi'd to the next system call and examined the registers and stack:


    This time the rax had 49 (bind), the rdi had 3, the rsi had the value of the default port 4444 (0x5c11) and the rdx had a value of 16.  I executed the system call and noted the return value of 0.

    I stepi'd to the next system call.


    The rax had 50 (listen).  The rdi had 3 (int fd) and the rsi had memory location of port 4444.

    I steps'd to the next system call.



    The rax had 33 (dup).  The rdi had 4 (oldfd) and the rsi has 2 (newfd).  The syscall was followed by a jne command which repeated the syscall until the rsi decremented to 0.  Then the syscall executed with a return value of 0 in rax.

    I stepi'd to the last system call.



    The rax had 59 (execve).  The rdi had the memory location that holds the /bin//sh string (in hex) and the rsi had a pointer which pointed to the memloc of the /bin//sh string.

    I executed the syscall, and in another terminal connected to the bind via netcat.



    It worked.  Yay.

    inux/x64/shell_reverse_tcp


    I reviewed this shell code's basic options:


    I noticed that it had two basic options; the LHOST and the LPORT(which defaults to port 4444).

    I generated the shellcode in c format:

    I noticed a null byte ("\x00"), so I reran it adding msfvenom's -b (bad character removal) switch:



    Next, I  pasted the shellcode in the shellcode.c template:


    I compiled it with the following gcc command:


    $   gcc -fno-stack-protector -z execstack shellcode.c -o shellcode

    I put the resulting binary (shellcode) in gdb and examined the state of the registers and stack at the start of the code section of the binary.

    $ gdb -q ./shellcode -tui


    I noticed that the decoding stub ended at <code+37> (after the loop finishes) and that the rest was gibberish that would decode when the loop finished.  I advanced to when the loop finishes and examined the decoded shellcode (starting at <code+39>).



    After the decoding loop finished, I examined the first 8 assembly instructions and notice that now the opcode resembled a syssocket system call set up (0x29; 41).  I advanced the the first system call and examined the state of the registers and stack.



    Prior to the first system call the rax contained 41 (syssocket).  The rdi contained 0; rsi was 1, rdx was 0.
    I executed the syscall and noted a return value of 3 in the rax.

    I advanced to the next syscall and examined the state of the registers and stack.



    This time the rax held 42 (connect).  The rdi had 3; rsi held the memory location of the IP (0x0100007f; which is 127.0.0.1) and the port (0x5c11; which is 4444).  The rdx held 16 (length of string in rsi).  I executed the syscall.


    Next was the dup section (33).  I stepi'd through the jne loop and watched as the rsi decremented to 0.   I executed the syscall and noted the return value of 0 in the rax.

    I advanced to the next syscall.



    The rax held 59 (execve). The rdi had the stack pointer to the /bin//sh string.  The rsi had the stack pointer that pointed to the memloc of the /bin//sh string.  The rdx held 0.

    I executed the syscall.



    It worked. Yay.

    linux/x64/exec

    I reviewed this shell code's basic options:


    I noted that the only argument was the CMD.  I planned to the use the string "cat /etc//passwd" (added an extra "/" to the string to make it an even 16 bytes).

    I generated and examined the shellcode in c format.


    I noticed some null bytes, so I reran the command with the -b switch.


    I pasted the shellcode into the shellcode.c template as before and compiled it with a modified gcc command as before.

    Then, I put the shellcode binary in gdb.

    gdb -q ./shellcode -tui



    I set up gdb by setting a breakpoint for the beginning of the shellcode ("code") section of the c-based binary.  I also set up the tui interface to display the assembly and registers.

    I saw that the decoder stub ended at the loop command (<code+37>).  Noticed that after the loop were commands that were unrecognized by gdb or unusual in shellcode.  I stepi'd through the loop function and noticed that the code from <code+39> changed to recognizable syscall preparation commands.



    Seeing indications that the code after the stub had decoded properly, I advanced to the first syscall and inspected the state of the registers and stack.



    The rax held 59 (execve).  The rdi held memloc of the "/bin/sh" string.  The rsi held memloc pointer to the "/bin/sh" string.  I executed the syscall.



    The "cat /etc/passwd" command successfully executed.

    It worked. Yay.