The Last Class

Well thank you for a really wonderful semester. I've enjoyed the energy and encouragement to go as deep as we've ever gone into x86 exploitation. I know not everyone will have kept pace to the end (completely expected) but I will keep the videos up and the notes will stay up until the start of next spring (then be archived at https://sec.prof.ninja/spring22).

Feel free to DM me in Discord for any help you need in the future.

This iteration of this course will lead to a vulnerability hunting team here at UD and you're welcome to stay involved.

A look back:

I like to list off the various skills we've explored during the semester:

In fact, let's do a quick jaunt through the mastery tasks with emojis.

I added stoplight colors to our mastery tasks in the discord, adjust each of them to reflect your current mastery of the concepts.

Green means you could probably deploy the skill in a live scenario.

Yellow means you think you get it intellectually but need to practice.

Red means you've got no idea what I'm talking about.

Last mastery check-in

OK so what sort of stuff did we cover:

• How to just use C, the language of languages
• The basics of x86
• How to reverse engineer a binary and see the intention behind it
• How to write and compile a simple program directly in assembly
• The reason for and mechanics of calling conventions
• The essence of the stack and use of rsp and rbp
• The nature of memory segments and their permissions
• The concept and execution of shellcode
• Stack smashing/buffer overflow exploits for overwriting local variables
• Controlling the stack at a ret to change the RIP
• How to debug via r2, pwntools, and connecting to a process
• ROP gadgets and ROP chaining
• Address space randomization via PIE and ASLR
• ret to glibc (go to walmart)
• Lazy-linking and the GOT and PLT
• How printf vulnerabilities can be used for leaks
• How printf vulnerabilities can be used to make a write-what-where
• How a write-what-where can be used to control the RIP via the GOT
• How syscalls control access to the OS
• The syscall calling conventions
• How SROP can be used to control ALL registers at once
• The goals of the heap for dynamic memory allocation (performance and defragmentation)
• The structure of the main_arena
• The why and how of smallbins and largebins
• The why and how of the unsorted bin
• The why and how of fastbins
• The why and how of tcache
• The tcache struct format
• pwndbg for heap visualization
• The House of Force for a nearly arbitrary write-what-where
• The fastbin dup for a nearly arbitrary write-what-where
• Use-after-free for finding a heap leak (leaking singly linked list pointers)
• Use-after-free for finding a glibc leak (leaking a main_arena address)
• The __free_hook as a target for RIP control
• Finding glibc one_gadgets
• The classic find_fake_fast __malloc_hook trick
• Triggering a top_chunk free using only mallocs
• The unsorted_bin half-attack, a write-where
• Filestream structs: _IO_FILE, vtables, and chains
• The house of orange: your first vtable hijack
• Using debug versions of glibc for finding security checks
• The source control for finding (possibly contributing) security patches
• The research process for finding novel exploits in glibc
• FSOP for generating leaks, arbitrary reads, arbitrary writes, and program control
• Creating fake chunks via a poison null byte
• The house of einherjar

Pretty deep.

What's missing?

We took an interesting path through this topic.

So what would I have liked to cover with you that we didn't?

• kernel exploitation, less protections, different malloc
• writing our own reverse engineering display for some esoteric architecture
• a heap exploit flowchart (given these weaknesses you unlock these exploits)
• static analysis tools
• symbolic execution engines (z3 and angr)
• a case-study on a piece of malware
• an ARM exploit
• an example of these exploits being used via a higher-level language (e.g. exploiting Chrome malloc via javascript )
• exploring Just-In-Time compilation vulnerabilities
• WASM, Java Byte Code, Python Byte Code vulnerabilities with the same principles (i.e. virtual machine exploitation)

Secure Software Design?

So for the CISC students who came in with different expectations I do want to confirm that the topic is in-fact one and the same. I encourage you to learn the CERT guidelines real quick:

Let's go through them real quick: CERT Coding Standards

memset your junk and delete your pointers.

Help make the world secure and not just the one project.

There is a whole world of secure software processes: almost like a project management class. Something like this:

Take a look at the SDL: SDL from microsoft

I also find it helps to contextualize all of this by looking at the MITRE ATTACK framework:

Use the charts: https://attack.mitre.org/matrices/enterprise/

Sure, but what about a PWN career?

OK so suppose you love PWNing like me and want to make a career of it?

So being a top CTFer is a great job door-opener, we learned about them because a large company uses CTFs as their cyber interview process (top score gets the job).

But also bug bounties, CVE hunting, malware detection, forensics.

OK so what about more practice?

Here are a ton of problem sets:

CTF flowcharts

Also compete every weekend with us!

OK Go Forth

Thanks again, I wish you nothing but the best. Any way I can help let me know.