Security Summer School

User Tools

Site Tools

session:05

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
session:05 [2018/06/26 19:39]
Razvan Deaconescu [06. Challenge - Call me] 		session:05 [2020/07/19 12:49] (current)
Line 1: Line 1:
-= 0x05. Dynamic Analysis+====== 0x04. Dynamic Analysis ======
  
-== Slides+===== Resources =====
  
-Slides are available {{:session:session_5.pdf|here}}.+[[https://security.cs.pub.ro/summer-school/res/slides/05-dynamic-analysis.pdf|Session 4 slides]]
  
-Challenges archive is at [[https://security.cs.pub.ro/summer-school/res/arc/05-dynamic-analysis-skel.zip|Session's tutorials and challenges archive]].+/*[[https://security.cs.pub.ro/summer-school/res/arc/05-dynamic-analysis-skel.zip|Session's tutorials and challenges archive]]*/
  
-== Tutorials+/*[[https://security.cs.pub.ro/summer-school/res/arc/05-dynamic-analysis-full.zip|Session's solutions]]*/ 
 + 
 +Get the tasks by cloning [[https://github.com/hexcellents/sss-exploit|Public GitHub Repository]]. 
 + 
 +===== Tutorials =====
  
 <note warning> <note warning>
-The current session relies heavily on the concepts presented in [[session:02]]. If you're not comfortable with the information presented during [[session:02]] please take the time to review it. +In the current session we will use GDB extensively. We assume that you are familiar with its basic usage and will move on quickly to some of its more advanced features.
-</note>+
  
-The first part of this session will give you a walkthrough of the most common GDB principles that we are going to use in exploitation. We are going to use these concepts in practice to evade a basic key evaluation program. Furthermore the second part of the session we will be going through some of the most common vulnerabilities including buffer overflows.+To brush up on the GDB basics, read [[session:04-gdb]]. 
 +</note>
  
 +The first part of this session will give you a walkthrough of the most common GDB principles that we are going to use in exploitation. We are going to use these concepts in practice to evade a basic key evaluation program.
 Let's get to it! Let's get to it!
  
-=== Before GDB+==== Before GDB ====
  
 One thing you should always do before firing up GDB is to try to learn all the available information on the executable you're trying to debug through the techniques that have been presented so far. One thing you should always do before firing up GDB is to try to learn all the available information on the executable you're trying to debug through the techniques that have been presented so far.
Line 26: Line 31:
 </code> </code>
  
-=== GDB Basic Commands +==== GDB Basic Commands ==== 
-==== Getting help with GDB+=== Getting help with GDB ===
  
 Whenever you want to find out more information about GDB commands feel free to search for it inside [[http://www.gnu.org/software/gdb/documentation/|the documentation]] or by using the ''help'' command followed by your area of interest. For example searching for help for the ''disassemble'' command can be obtained by running the following command in GDB: Whenever you want to find out more information about GDB commands feel free to search for it inside [[http://www.gnu.org/software/gdb/documentation/|the documentation]] or by using the ''help'' command followed by your area of interest. For example searching for help for the ''disassemble'' command can be obtained by running the following command in GDB:
Line 42: Line 47:
 </code> </code>
  
-==== Opening a program with GDB+=== Opening a program with GDB ===
  
 A program can be opened for debugging in a number of ways. A program can be opened for debugging in a number of ways.
Line 56: Line 61:
 </code> </code>
  
-Furthermore we can attach GDB to a running service if we know it's process id:+Furthermore we can attach GDB to a running service if we know its process id:
 <code bash> <code bash>
 $ gdb --pid [pid_number] $ gdb --pid [pid_number]
 </code> </code>
  
-==== Disassembling+=== Disassembling ===
  
-GDB allows disassembling of binary code using the ''disassemble'' command (it may be shortened to ''diasas''). The command can be issued either on a memory address or using labels.+GDB allows disassembling of binary code using the ''disassemble'' command (it may be shortened to ''disas''). The command can be issued either on a memory address or using labels.
 <code bash> <code bash>
 (gdb) disas *main (gdb) disas *main
Line 87: Line 92:
 </code> </code>
  
-==== Adding Breakpoints+=== Adding Breakpoints ===
  
 Breakpoints are important to suspend the execution of the program being debugged in a certain place. Adding breakpoints is done with the ''break'' command. A good idea is to place a breakpoint at the main function of the program you are trying to exploit. Given the fact that you have already run ''objdump'' and disassembled the program you know the address for the start of the main function. This means that we can set a breakpoint for the start of our program in two ways: Breakpoints are important to suspend the execution of the program being debugged in a certain place. Adding breakpoints is done with the ''break'' command. A good idea is to place a breakpoint at the main function of the program you are trying to exploit. Given the fact that you have already run ''objdump'' and disassembled the program you know the address for the start of the main function. This means that we can set a breakpoint for the start of our program in two ways:
Line 110: Line 115:
 </note> </note>
  
-==== Listing Breakpoints+=== Listing Breakpoints ===
  
 At any given time all the breakpoints in the program can be displayed using the ''info breakpoints'' command: At any given time all the breakpoints in the program can be displayed using the ''info breakpoints'' command:
Line 124: Line 129:
 </note> </note>
  
-==== Deleting Breakpoints+=== Deleting Breakpoints ===
  
 Breakpoints can be removed by issuing the ''delete breakpoints'' command followed by the breakpoints number, as it is listed in the output of the ''info breakpoints'' command. Breakpoints can be removed by issuing the ''delete breakpoints'' command followed by the breakpoints number, as it is listed in the output of the ''info breakpoints'' command.
Line 143: Line 148:
 </code> </code>
  
-==== Execution flow+=== Execution flow ===
  
 Execution flow can be controlled in GDB using the ''continue'', ''stepi'', ''nexti'' as follows: Execution flow can be controlled in GDB using the ''continue'', ''stepi'', ''nexti'' as follows:
Line 194: Line 199:
 </note> </note>
  
-=== Examine and Print, your most powerful tools+==== Examine and Print, your most powerful tools ====
  
 GDB allows examining of memory locations be them specified as addresses or stored in registers. The ''x'' command (for //examine//) is arguably one of the most powerful tool in your arsenal and the most common command you are going to run when exploiting. GDB allows examining of memory locations be them specified as addresses or stored in registers. The ''x'' command (for //examine//) is arguably one of the most powerful tool in your arsenal and the most common command you are going to run when exploiting.
Line 277: Line 282:
 </code> </code>
  
-=== GDB command file+==== GDB command file ====
  
 When exploiting, there are a couple of commands that you will issue periodically and doing that by hand will get cumbersome. GDB commands files will allow you to run a specific set of commands automatically after each command you issue manually. This comes in especially handy when you're stepping through a program and want to see what happens with the registers and stack after each instruction is ran, which is the main target when exploiting. When exploiting, there are a couple of commands that you will issue periodically and doing that by hand will get cumbersome. GDB commands files will allow you to run a specific set of commands automatically after each command you issue manually. This comes in especially handy when you're stepping through a program and want to see what happens with the registers and stack after each instruction is ran, which is the main target when exploiting.
Line 365: Line 370:
 </note> </note>
  
-=== Using GDB to modify variables+==== Using GDB to modify variables ====
  
 GDB can be used to modify variables during runtime. In the case of exploitation this comes in handy as the program can be altered at runtime with the purpose of changing the execution path to desired branches. GDB can be used to modify variables during runtime. In the case of exploitation this comes in handy as the program can be altered at runtime with the purpose of changing the execution path to desired branches.
  
-=== GDB PEDA+==== GDB PEDA ====
  
 As you can see using GDB can be cumbersome, this is why we recommend using the PEDA (//Python Exploit Development Assistance// for GDB) plugin presented in the previous session. As you can see using GDB can be cumbersome, this is why we recommend using the PEDA (//Python Exploit Development Assistance// for GDB) plugin presented in the previous session.
Line 382: Line 387:
 </note> </note>
  
-==== PEDA Commands+[[https://github.com/hugsy/gef|Gef]] and [[https://github.com/pwndbg/pwndbg|Pwndbg]] are two other GDB plugins that are popular for exploit development. You can use either one of them or use [[https://medium.com/bugbountywriteup/pwndbg-gef-peda-one-for-all-and-all-for-one-714d71bf36b8|this configuration]] to switch between them. However, this tutorial is designed with PEDA in mind. 
 + 
 +=== PEDA Commands ===
  
 ''pdis'' command gives a pretty output that is similar to what the ''disas'' command in GDB prints:<code bash> ''pdis'' command gives a pretty output that is similar to what the ''disas'' command in GDB prints:<code bash>
Line 466: Line 473:
 </note> </note>
  
-==== Altering variables and memory with PEDA and GDB+=== Altering variables and memory with PEDA and GDB ===
  
 In addition to basic registers, GDB has a two extra variables which map onto some of the existing registers, as follows: In addition to basic registers, GDB has a two extra variables which map onto some of the existing registers, as follows:
-* ''$pc -- $eip'' +  * ''$pc -- $eip'' 
-* ''$sp -- $esp'' +  * ''$sp -- $esp'' 
-* ''$fp -- $ebp''+  * ''$fp -- $ebp''
  
 In addition to these there are also two registers which can be used to view the processor state In addition to these there are also two registers which can be used to view the processor state
Line 496: Line 503:
  
 <note tip> <note tip>
-Notice that the flags that are sent are printed in all-caps when the ''eflags'' command is issued.+Notice that the flags that are set are printed in all-caps when the ''eflags'' command is issued.
 </note> </note>
  
Line 536: Line 543:
 PEDA does not offer enhancements in modifying registry values. For modifying registry values you can use the GDB ''set'' command. PEDA does not offer enhancements in modifying registry values. For modifying registry values you can use the GDB ''set'' command.
  
-<code bash>+<code>
 gdb-peda$ p/x $eax gdb-peda$ p/x $eax
 $10 = 0x1 $10 = 0x1
Line 544: Line 551:
 </code> </code>
  
-=== Enough with GDB (for a while)+==== Enough with GDB (for a while) ====
  
 The following section will describe the process of function calling in detail. Understanding function calling and stack operations during program execution is esential to exploitation. The following section will describe the process of function calling in detail. Understanding function calling and stack operations during program execution is esential to exploitation.
  
-=== The Stack+==== The Stack ====
  
-The stack is one of the areas of memory which get's the biggest attention in exploitation writing.+The stack is one of the areas of memory which gets the biggest attention in exploitation writing.
  
-==== Stack Growth+=== Stack Growth ===
  
 The stack grows from high memory addresses to low memory addresses. The stack grows from high memory addresses to low memory addresses.
Line 579: Line 586:
 As we can see ''$esp'' now points to ''0xbffff338'' (''0xbffff33c-0x4''). As we can see ''$esp'' now points to ''0xbffff338'' (''0xbffff33c-0x4'').
  
-==== Frame pointers and local function variables+=== Frame pointers and local function variables ===
  
 Whenever the processor is entering the execution for a function, a special logical container is created on the stack for that function. Whenever the processor is entering the execution for a function, a special logical container is created on the stack for that function.
Line 668: Line 675:
 We then set a breakpoint for another function called ''pass_accepted'', continued execution and entered a password that we know is going to pass validation. Once the breakpoint is hit, we can see the same 2 instructions ''push ebp'' and ''mov ebp,esp''. We then set a breakpoint for another function called ''pass_accepted'', continued execution and entered a password that we know is going to pass validation. Once the breakpoint is hit, we can see the same 2 instructions ''push ebp'' and ''mov ebp,esp''.
  
-The two instruction which can be noticed at the beginning of any function are the instructions required for creating the logical container for each function on the stack.+The two instructions which can be noticed at the beginning of any function are the instructions required for creating the logical container for each function on the stack.
  
 In essence what they do is save the reference of the old container (''push ebp'') and record the current address at the top of the stack as the beginning of the new container(''mov ebp,esp''). In essence what they do is save the reference of the old container (''push ebp'') and record the current address at the top of the stack as the beginning of the new container(''mov ebp,esp'').
Line 678: Line 685:
 As you can see the EBP register always points to the stack address that corresponds to the beginning of the current function's frame. That is why it is most often referred to as the frame pointer. As you can see the EBP register always points to the stack address that corresponds to the beginning of the current function's frame. That is why it is most often referred to as the frame pointer.
  
-In addition to the two instructions required for creating a new stack frame for a function. There are a couple more instructions that you will usually see at the beginning of a function+In addition to the two instructions required for creating a new stack frame for a function, there are a couple more instructions that you will usually see at the beginning of a function
  
 If you analyze the instructions at the beginning of main, you can spot these as being: If you analyze the instructions at the beginning of main, you can spot these as being:
Line 756: Line 763:
   - The value ''0x01'' is placed at the address of EBP-0x4 (the local variable ''a'' takes the value 1).   - The value ''0x01'' is placed at the address of EBP-0x4 (the local variable ''a'' takes the value 1).
  
-==== Function parameters+=== Function parameters ===
  
 The stack is also used to pass in parameters to functions. The stack is also used to pass in parameters to functions.
Line 821: Line 828:
 If you don't understand why the offset for the parameters starts at EBP+0x08 and not EBP follow through with the next section. If you don't understand why the offset for the parameters starts at EBP+0x08 and not EBP follow through with the next section.
  
-==== Calling functions (call and ret)+=== Calling functions (call and ret) ===
  
-When calling a function the callee placed the a return address on the stack. This address is nothing more than a bookmark so that execution can resume where it left of once the called function finishes execution.+When calling a function the callee places the return address on the stack. This address is nothing more than a bookmark so that execution can resume where it left off once the called function finishes execution.
  
 The last instruction in functions is usually a ''ret'' instruction that resumes execution to the callee. The last instruction in functions is usually a ''ret'' instruction that resumes execution to the callee.
Line 842: Line 849:
 {{ :session:stack-convention.png?600 |}} {{ :session:stack-convention.png?600 |}}
  
-=== Buffer Overflows+==== Buffer Overflows ====
  
 Now that we have a complete overview of the stack we can step forward to stack based buffer overflows. Now that we have a complete overview of the stack we can step forward to stack based buffer overflows.
  
-A buffer overflow takes place when there is a lack of checking regarding boundaries and usually result in complete control of the program's instruction pointer. This takes place when a buffer overflows it's boundaries and overwrites the return address of a function.+A buffer overflow takes place when there is a lack of checking regarding boundaries and usually result in complete control of the program's instruction pointer. This takes place when a buffer overflows its boundaries and overwrites the return address of a function.
  
 A typical example of buffer overflows can be seen in the following picture: A typical example of buffer overflows can be seen in the following picture:
Line 852: Line 859:
 {{ :session:s5_buffer_overflow.jpg?500 |}} {{ :session:s5_buffer_overflow.jpg?500 |}}
  
-== Challenges+===== Challenges =====
  
-=== 01. Challenge - Explore The Simple Password Protected Bash+==== 01. Challenge - Explore The Simple Password Protected Bash ====
  
 Use GDB and PEDA to run the code provided in the [[https://security.cs.pub.ro/summer-school/res/arc/05-dynamic-analysis-skel.zip|Challenges archive]]. The executable gets input from the user and evaluates it against a static condition. If it succeeds it then calls a ''password_accepted'' function that prints out a success message and spawns a shell. Use GDB and PEDA to run the code provided in the [[https://security.cs.pub.ro/summer-school/res/arc/05-dynamic-analysis-skel.zip|Challenges archive]]. The executable gets input from the user and evaluates it against a static condition. If it succeeds it then calls a ''password_accepted'' function that prints out a success message and spawns a shell.
Line 866: Line 873:
 </note> </note>
  
-=== 02. Challenge - Simple Password Protected Bash Destruction+==== 02. Challenge - Simple Password Protected Bash Destruction ====
  
-What is the condition against which your input is evaluated in the executable contained in the [[https://security.cs.pub.ro/summer-school/res/arc/05-dynamic-analysis-skel.zip|Challanges archive]]?+What is the condition against which your input is evaluated in the executable contained in the executable ''sppb''?
  
  
Line 874: Line 881:
 The ultimate goal is to be able to craft an input for the binary so that the ''password_accepted'' function is called (modifying registers while running the program in GDB is just for training purposes). The ultimate goal is to be able to craft an input for the binary so that the ''password_accepted'' function is called (modifying registers while running the program in GDB is just for training purposes).
 </note> </note>
-=== 03. Challenge - Buffer Overflow Bash 
  
-Use GDB and PEDA to run the code provided in the [[https://security.cs.pub.ro/summer-school/res/arc/05-dynamic-analysis-skel.zip|Challanges archive]]. The executable gets input from the user to post to a board and is exploitable through buffer overflows.+==== 03. Challenge - Domino ====
  
-Your task is to use GDB and PEDA to run a buffer overflow attack and spawn a shell.+Analyse the binary, reverse engineer what it does and get a nice message back.
  
-<note tip> +==== 04. Challenge - Call me ====
-Gather as much info about the executable as possible through the techniques you have learnt in previous sessions.+
  
-Be careful about endianness.+Investigate the binary in ''04-challenge-call-me/src/call_me'' and find out the flag.
  
-The shell can be spawned by calling code that is already existing inside the executable.+<note tip> 
 +There is something hidden you can toy around with.
 </note> </note>
  
-<note important> +<note tip> 
-If you are using python for payload generation, use python2 not python3.+The challenge name is a hint.
 </note> </note>
  
-=== 04. Challenge - Domino+==== 05. Challenge - Snooze Me ====
  
-Analize the binary, reverse engineer what it does and get a nice message back. +I wrote a simple binary that computes the answer to life, the universe and everything. It swear it works... eventually.
-=== 05. Challenge - SmashTheStack01+
  
-Download level01 from Smash the stack and solve it using peda. Break on *main, step through the execution and figure out what it does and how to crack it.+==== 06. Challenge - Phone Home ====
  
-''$ scp level1@io.netgarage.org:/levels/level01 . # Password is level1''?+To protect their confidential data from those snooping cloud providers, the authors of ''06-challenge-phone-home/src/phone_home'' have used some obfuscation techniques.
  
-=== 06. Challenge - Call me +Unfortunately, the key feature of the application is now unreachable due to a bug. Can you bypass the impossible condition?
- +
-Investigate the binary in ''06-challenge-call-me/src/call_me'' in the [[http://security.cs.pub.ro/summer-school/res/arc/05-dynamic-analysis-skel.zip|session archive]] and find out the flag. +
- +
-<note tip> +
-There is something hidden you can toy around with. +
-</note> +
- +
-<note tip> +
-The challenge name is a hint. +
-</note>+
session/05.1530031179.txt.gz · Last modified: 2018/06/26 19:39 by Razvan Deaconescu

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki