Bug Hunting and Exploit Development 4: Writing Metasploit Framework MSF Exploit Modules
Channel: Z. Cliffe Schreuders
Date: 2015-06-22

This video is part of the computer/information/cyber security and ethical hacking lecture series; by Z. Cliffe Schreuders at Leeds Beckett University. Laboratory work sheets, slides, and other open educational resources are available at http://z.cliffe.schreuders.org. 

The slides themselves are creative commons licensed CC-BY-SA, and images used are licensed as individually attributed.

Topics covered in this lecture include:
Writing an MSF exploit module
MSF modules are written in Ruby, and leverage the MSF libraries
Ruby is an object-oriented scripting language, in some ways similar to Perl and Python
Automatic memory management
It is relatively easy to learn
Some easy to follow online Ruby tutorials:
https://www.ruby-lang.org/en/documentation/quickstart/
http://www.codecademy.com/en/tracks/ruby
Writing an MSF exploit module

FTP exploit

EIP offset
The first important thing to determine is the offset from the start of the buffer to the return address overwrite (which gets copied to EIP)
Metasploit’s pattern_create feature
Use pattern_create(size), rather than “AAAAAAA...”
Also a command:
pattern_create.rb 5500
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac...
EIP offset
After writing the buffer with pattern_create(1000), the new EIP value can be used to calculate the offset:
/usr/share/metasploit-framework/tools/
pattern_offset.rb EIP-value 1000

The output from the above command will give an offset
Now that you know where the return pointer is stored you can point it anywhere you like...
You can now control EIP
Now that you know where the return pointer is stored you can point it anywhere you like...
Since you have control of the buffer, this is a potential place to put a payload, such as shell code
For now, lets assume we can put code in the buffer
The payload could be stored either before or after the return code overwrite
Understanding the stack
A simple method of visualising the stack is to write 'A's then 'B' for the EIP then 'C's
If we put our payload in the buffer, we can't simply overwrite EIP with the address for our payload (for example, 0x00B2FC34) because the stack moves each time
Also, the exact size of the stack may be slightly different due to control flow
Getting to the payload
The most straightforward is to find a register that is pointing into our buffer
In this example ESP and EDI are both pointing somewhere in our buffer (after EIP)
Put some NOPs and the payload there
Then point EIP at some existing code that jumps to that register
JMP instructions
JMP instructions jump to a location pointed to by a register
If we find a register such as EBP pointing to our code...
Look for a JMP EBP in memory and point the return pointer at it
Getting there...
Search through shared code for a “JMP ESP” – better to use a DLL that ships with the vulnerable program, rather than one that ships with Windows (since it is less likely to change)
send = "A" * offset + little_endian_return_address + "\x90" * 30 + payload.encoded
Specify bad characters that may stop our attack from working: typically 0x00, 0x0A, and 0x0D
Finishing touches
Store the platform specific details separately:
Figure out what the maximum space there is for the payload
Test for other possible bad characters
Defences: ASLR
There are a number of approaches that are used to make it harder to exploit stack smashing buffer overflows
Address space layout randomization (ASLR) randomly sets the location of the stack heap and libraries
As we have seen ASLR makes things tricky, since an exploit can't hard code memory addresses in the stack, it also means that we often resort to using libraries that are compiled without ASLR in order to get to our payload
Nonexecutable Stacks (NX), AKA DEP 
Prevents executable code from running in the stack segment – no payload code on the stack
Typically hardware dependent
Nonexecutable Stacks (NX), AKA DEP
Does not stop attacks on the heap: heap spraying involves filling the heap with lots of shell code – more likely to hit if we point the return address at the heap
There are various ways to bypass NX/DEP, but do exploit development much more complex
Arc injections, where we jump to existing code still works (AKA, ret-to-libc)
Mark the stack as executable (if allowed)
Copy payload into executable regions
Change DEP settings
Return Oriented Programming (ROP)
An advanced form of arc injection: ROP
Use the stack to jump to existing code that does something and then jumps to the next set of instructions to carry out, and so on
All without executing anything directly from the stack!
“ROP chains” are made up of “gadgets”: sections of  instructions that can be chained together
Not enough
The commonly deployed protections make it harder to do simple exploit demonstrations
However, it is still possible for clever attackers to circumvent these protections
Defencive programming is still a necessity
Conclusion