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 [2019/07/12 12:22]
Radu-Nicolae NICOLAU (78289) 		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 61: Line 66:
 </code> </code>
  
-==== Disassembling+=== Disassembling ===
  
 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. 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.
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 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 gets 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 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 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. 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.
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.
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 executable ''sppb''? 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 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> +
- +
-<note important> +
-If you are using python for payload generation, use python2 not python3. +
-</note> +
- +
-=== 04. Challenge - Domino +
- +
-Analize the binary, reverse engineer what it does and get a nice message back. +
- +
-=== 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. +
- +
-''$ scp level1@io.netgarage.org:/levels/level01 . # Password is level1''? +
- +
-=== 06. Challenge - Call me +
- +
-Investigate the binary in ''06-challenge-call-me/src/call_me'' and find out the flag.+
  
 <note tip> <note tip>
Line 914: Line 898:
 </note> </note>
  
-=== 07. Bonus - Challenge - Lucky Number+==== 05. Challenge - Snooze Me ====
  
-Investigate the binary in ''07-challenge-lucky-number/src/lucky_number'' and find out the flag.+I wrote a simple binary that computes the answer to life, the universe and everything. It swear it works... eventually.
  
-<note tip> +==== 06. Challenge - Phone Home ====
-What uncalled functions are interesting? +
-</note>+
  
-<note tip> +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.
-The key is a continuous 16 bytes area in the executable. +
-</note>+
  
 +Unfortunately, the key feature of the application is now unreachable due to a bug. Can you bypass the impossible condition?
session/05.1562923346.txt.gz · Last modified: 2019/07/12 12:22 by Radu-Nicolae NICOLAU (78289)

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