PWN Wars: A New Hope

For today's main problem we have 2 things going on to learn about:

Part 1: Shellcode

What is shellcode?

It was the first major exploit to rock the world about 25 years ago and it works like this:

You write bytes into memory that are, themselves, instructions/opcodes that the computer could execute.

Then you jump the instruction pointer to those instructions and bam, you've written your own win condition.

Practical PWN shellcode

When should you consider shellcode during a PWN problem?

If you see NX Disabled or Has RWX Segments during a checksec

I typically start a PWN with a call to checksec --file=yourpwnbin and the output will tell me the protections in place.

For this case we're looking for NX disabled (non-executable stack disabled == stack is both writable AND executable)

How do you make your own shellcode?

There is a quick and easy answer: pwntools shellcraft

There are medium answers: googling shellcode databases

There are expert answers: writing your own

My original project 1 was intended to help you learn how to write your own, because now and again you need to.

The situations where you need to are a problem that is doing some sanity checking on your payload but can be made vulnerable to shellcode.

In those cases you'll need to be able to take something off the shelf and tweak it to fit your problem, but those problems are fairly rare and for those of you in the class that are going to be the world class pwners you can do that on your own time.

The Easy Way:

It's just 1-3 lines!!

Couple of notes:

The context matters. If you need a 64-bit shellcode you need the line context.arch="amd64" otherwise you'll get 32-bit shellcode.

The output of the shellcraft module is actually assembly code that does something cool (run /bin/sh in our case here). But you can turn pretty ASM into op codes with the line asm(b"pretty stuff here")

There is a lot of beauty in this particular shell code, like avoiding null bytes and new line characters and trying to fit into 48 bytes or so.

If you want a more foundational approach to shellcode take a look at my old notes: Spring class 8

Part 2: Address Randomization

So in this problem we are given an address leak. Why? What is that all about? How do we process it?

There is a lot of ways that leaks will happen to us this year and this one will be one of the most straight forward.

Addresses that get randomized:

There are usually 3 segments we need to handle:

• the .data segment which has the .main opcodes/instructions (randomization is turned OFF by NO PIE)
• the stack segment which has our local variables, return address for smashing, etc
• the glibc segments which are the walmart segments that have every chunk of functionality we need to run the world

These addresses are different every time the program executes (in order to stop us hackers). Throughout the course we will find various ways to get around these defenses.

OFFSETS are key (but not for this problem)

That is, given an address from one of these segments you'll need to deduce where in the segment is the leak, and how far from the leak is an address you need to know.

We will explore again soon which things are in each segment and jumping around from leak to target like gymnasts

How to parse leaks

If you are given a leak (or manufacture a leak) you'll have to parse the data.

In pwntools you'll want to get an example response from the process and parse it. Here are several methods: