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

https://youtu.be/YoNrNBnmwuY

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

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.

http://shell-storm.org/shellcode/files/shellcode-603.php - ("execve /bin/sh")  (30 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

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:

https://github.com/clubjk/SLAE64-3/tree/master/exam/analysis

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.