Bug Hunting and Exploit Development 4: Writing Metasploit Framework MSF Exploit Modules скачать в хорошем качестве

Bug Hunting and Exploit Development 4: Writing Metasploit Framework MSF Exploit Modules

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/document... 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