Hints

General Approach

Those notes and questions should help you find the vulnerability and write the exploit faster.

First of all you need to determine which bitness the binary has? 32bit, 64bit? Use file for that!

Generally ASLR will be enabled so you need to find an information leak first. Some tasks will make it easier some harder ;) To be clear: It is not of any use if you find a way to alter the control flow (e.g, by overwriting a return address) when you don’t know where to jump! Sometimes it could be the case that you find a first leak (e.g. a pointer to the binary’s .text section), then execute some code with ROP to get other data you need (e.g. a pointer to libc’s .text section). But remember to check the easy way first, e.g. if there is a leak on the stack… can you get everything you need already?

Next you should check if the binary has security features enabled. What does checksec say? If stack canaries are enabled you have to leak or brute-force them. Remember brute-forcing only works with forked processes! If you find a way to leak information you might be able to read and inject the canary with your payload again so that the stack canary check passes. If there are no stack canaries this is your lucky day ;) If NX is disabled you can try to execute your good old shellcode if not you have to reuse code from somewhere else either with ret2lib or ROP. You can use all the executable code that is available (the binary’s code, libc’s code, ld’s code, …). If PIE (Position Independent Executable) is disabled you could (if there is such a possibility) jump to the binary’s code since it’s addresses will not be randomized by ASLR (maybe there is a nice function within the binary that gives you a shell?). If PIE is enabled and you want to jump (return) to a function within the binary you would have to find a leak to the binary’s code (i.e. an address/pointer into the binary’s .text section) first or brute-force some addresses (remember the partial overwrites?). If there is no function in the binary that you could use you need to use other code (shellcode, ret2lib, ROP, …). In that case you’d also need to find an address leak to to the code you need for the code-reuse-attack. Keep the information from checksec in mind and also your ideas and conclusions about the properties of your exploit.

BUT, first of all you have to find the bug! :) Just follow this exemplary (but not exhaustive!) list:

• Did you run the program? Could you identify some strings and find the corresponding parts in your disassembler/decompiler? If you enter some data, how does the program behave?
• Could there be an overflow? What functions lead to overflows in general?
• It the (target) buffer of the over-read or over-write operation on the stack or the heap? (stack vs. heap leak; stack vs. heap overflow)
• Is there a printf function which contains a format-string vulnerability? Format string vulnerabilities are very powerful because you can leak information (e.g. stack canaries) or write data (write-what-where). It can itself be used to alter the control flow (e.g. via GOT overwrites) but also be combined with a stack overflow (e.g. you leak the canary with printf and do the rest with a stack overflow and some shellcode, ret2lib, or a ROP chain).
• Is there a call to malloc, calloc, free, etc.? If not there won’t be a heap-related bug! If there are calls to heap-related functionality you should find out whether there is a heap buffer overflow or a use-after-free bug! If it’s a use-after-free bug can you easily get the free()ed chunk back or do you have to do some massaging first to manipulate the data you want? ;)

Sheet 5

• there are no format string vulnerabilities on this sheet!

• if can’t find the gadget you are looking for try to enable multiple branch gadgets

  Notebook App

  • what if you set the printing function to puts() and than have heap allocation with the same size before that?
  • have closer look at the struct printable_note

  ROP ROP ROP ROP ROP

  • have a look at the Hello-World ROP chain in order to build your ROP chain
  • Remember how to set argv**
  • Are you able to leak something interesting from the stack?

  Bad Characters And A Non-Executable Stack

  • when building our ROP chain it might helpful in the case of mprotect() to jump at an offset where some registers gets set for us
  • remember that the read() function is not putting a NULL-byte at the end of the string
  • before your shellcode gets into the stack where was it before when reading from stdin? Maybe you find some nice space in LIBC?

  C++ and vtables

  • How is PabeUser::set_username(std::string) invoked at assembly level?

  • What if you change the pointer from set_username(std::string) to 0x401360 ?

Sheet 6

• there are format string and heap vulnerabilities on this sheet

Task 26 – Improved PABE Service

• What do you think about pabes awesome echo service? Might there some bug in it?

• Is there some nice GOT-entry which you could overwrite?

Task 27 – Two Bugs

• Are you able to leak everything you need to know?

• Which kind of code reuse attack do you know?

Task 28 – A little printer developed during Xmas

• What do you know about dangling pointers?

• Do you remember format string bugs?

Task 29 – Some Poison for the Cash machine

• Have a look at backdoor function

• How can you setup RDI when invoking the backdoor function?

• Which functions offers you the possiblity that your allocation gets into the TCACHE

• Can you see the diference between the cashbox_delete and the cashbox_update functions? What can you use after that?

Task 30 – Bank Robbery 2.0

• Can you configure your panic()-function wisely?

• Are you able to influence the allocation on the heap in a way that you are able to overwrite something nice there?

Both Sheets

• There won’t be an unlink vulnerability in the exercises! =)
• Some of the task descriptions are already very specific in what you have to do! Please read them carefully since they might already tell you how to approach the task ;)

Happy hacking!