Http://wiki.ucalgary.ca/page/Courses/Computer Science/CPSC 525.F2014/Tutorial Schedule

From wiki.ucalgary.ca
Jump to: navigation, search

Tutorial topics that we will discuss each week are below.

Tutorial session 1 takes place on Monday and Wednesday from 2:00 pm to 2:50 pm at MS205.

Tutorial session 2 takes place on Tuesday and Thursday from 2:00 pm to 2:50 pm at EDC384 .


Sessions
Session Date Topic Slides/Exercises/Web Links
1 15,16 Sep Introduction, Familiarizing with 'Security' words, Hacking attempts Slide1 : [[1]]
Exercises :[[2]]
2 17,18 Sep Introduction to "Hacking the Abacus", Setting up VM environment for experiments Web Links
Hacking the Abacus: An Undergraduate Guide to Programming Weird Machines : [[3]]
Exercises : [[4]]

15, 16 Sep : Introduction, Familiarizing with 'Security' words, Hacking attempts

Exercise 1: Web browser password storing

Do you save password into your browser? Lets check where these passwords are saved and is it encrypted or clear text?

Steps:

  • 1. Identify your browser ( Safari, Internet Explorer, Mozilla etc.)
  • 2. If you have already any saved password then go to step 3, otherwise save any password. For example, try to login to 'My UofC' and save password.
  • 3. Search youtube or google for your specific browser on how to hack browser password. I have provided one example in the slide for Safari.
  • 4. Whats your observation? How easy or difficult it is?
  • 5. Where these passwords are stored in your system?
  • 6. How do you protect those? (hint: using encryption) What is key-chain?


Courses/Computer Science/CPSC 525.W2016/Tutorial Notes < Courses‎ | Computer Science‎ | CPSC 525.W2016 Tutorial topics that we will discuss each week are below.

Tutorial session 1 takes place on TBA and TBA from TBA to TBA at TBA.

Tutorial session 2 takes place on TBA and TBA from TBA to TBA pm at TBA .

Sessions Session Date Topic Slides/Exercises/Web Links 1 15,16 Sep Introduction, Familiarizing with 'Security' words, Hacking attempts Slide1 : 1 Exercises :2 2 17,18 Sep Introduction to "Hacking the Abacus", Setting up VM environment for experiments Web Links Hacking the Abacus: An Undergraduate Guide to Programming Weird Machines : 3 Exercises : 4 3 22,23 Sep No Tutorial 4 24,25 Sep Vulnerability Assessment and How it relates to "CIA" Introduction to NESSUS, CVE, CWE Web Links A vulnerability scanner-NESSUS: 5 Common Vulnerabilities and Exposures: 6 Common Weakness Enumeration: 7 Exercises: 5 29,30 Sep No Tutorial x 6 1,2 Oct File Access, File Permission Exercises 7 6,7 Oct Introduction to SVN, ptrace(2) 8 8,9 Oct Open work time for Assignment1 ~ No tutorial 9 13,14 Oct No Tutorial ~13 oct Thanksgiving Day -University Closed ~ 10 15,16 Oct s-bit, User IDs(Real and effective), Multiuser note taker s-bit and User IDs

  • Understanding how Alice can execute ./simplenote and write to a file /tmp/notes as Bob. Here Alice and Bob both have execution permission to file ./simplenote whereas Bob has the write permission to file /tmp/notes.
  • Exercise 10,11,12,13

Multiuser note taker

  • Understanding how Alice and Bob can write to file notes but Alice or Bob can read only his/her writings
  • Exercises 14

11 20,21 Oct Memory Segmentation in C and using GDB 12 22,23 Oct No tutorial 13 27,28 Oct No tutorial 14 29,30 Oct No tutorial 15 3,4 Nov No Tutorial 16 5,6 Nov No Tutorial 17 10,11 Nov No Tutorial ~ Reading Days - No Lecture ~ 18 12,13 Nov No Tutorial 19 17,18 Nov No Tutorial - Self Study Roll Your Own Vulnerability (Exercise 3.9 from Hacking The Abacus) Exercise detail can be found below 20 19,20 Nov No Tutorial - Self Study Case Study: A Simple Stack-based Buffer Overflow (Exercise 3.10 from Hacking the Abacus) Exercise detail can be found below 21 24,25 Nov 22 26,27 Nov 23 1,2 Dec 24 3,4 Dec Contents [hide] 1 15, 16 Sep : Introduction, Familiarizing with 'Security' words, Hacking attempts 2 17,18 Sep : Introduction to 'Hacking the Abacus', Setting up VM environment for experiment 3 24, 25 Sep : Vulnerability Assessment and How it relates to "CIA" 4 01,02 Oct: File Access, File Permission 5 06, 07 Oct : Introduction to SVN, ptrace(2) 6 15, 16 Oct : s-bit, User IDs(Real and Effective), Multiuser note taker 7 17, 18 Nov : Roll your own vulnerability 8 19,20 Nov :Case Study: A Simple Stack-based Buffer Overflow (Exercise 3.10 from Hacking the Abacus) 15, 16 Sep : Introduction, Familiarizing with 'Security' words, Hacking attempts[edit] Exercise 1: Web browser password storing

Do you save password into your browser? Lets check where these passwords are saved and is it encrypted or clear text?

Steps:

1. Identify your browser ( Safari, Internet Explorer, Mozilla etc.) 2. If you have already any saved password then go to step 3, otherwise save any password. For example, try to login to 'My UofC' and save password. 3. Search youtube or google for your specific browser on how to hack browser password. I have provided one example in the slide for Safari. 4. Whats your observation? How easy or difficult it is? 5. Where these passwords are stored in your system? 6. How do you protect those? (hint: using encryption) What is key-chain? Exercise 2: Bypassing your OS login

Do you know that it is possible to bypass your OS login credentials and gain access? Lets do this exercise.

Steps:

1. Identify your Operating system name and version ( Windows xp/7/8, Mac OS x version / Linux etc.) 2. In the slide I have provided an example of bypassing Mac OS. Search youtube for your version. 3. Whats your result? Are you successful? If not, what was the barrier. 4. How do you protect bypassing OS credential?

17,18 Sep : Introduction to 'Hacking the Abacus', Setting up VM environment for experiment[edit] Exercise 3: Creating environment for experiment"

Steps:

Installing Virtual Machine, for example, Oracle VM VirtualBox 8, VMWare 9

1. Download: VirtualBox 10, VMWare 11 2. Install your preffered OS into the VM. [Note: Always download iOS files or other files from trusted sources. When you type "download linux ios" in google, how many links appear? Which one is trusted? ] 3. Configure IP address. Exercise 4: Beating up your OS

This exercise is from the tutorial book "Hacking the Abacus", Page 28

To get things started, we are going to ask you to abuse your OS in a number of ways. This lab exercise is a prime example of learning through failure modes. Rather than trying to memorize a long list of traditional OS principles and roles (i.e., schedul- ing, resource management, memory management, user management, persistent storage management, device management, security, protection, network and communications management), we’re going to ask you to test the limits of your system. What can’t it do? Just how many processes can you create? Why can’t you create more? Why can you not do some activity that seems perfectly plausible?

This first lab exercise should also provide some form of catharsis; we are giving you permission to be mean to your OS. Go wild.

Synopsis

In this exploratory task, you will abuse an operating system in a number of ways and report your observations.

Learning Outcomes

The purpose of this task is to help you achieve the following outcomes:

1. explore failure and error conditions in the context of an OS 2. understand the power and semantics of a “superuser” user and the distinction between privileged kernel mode execution and merely being “root” 3. learn about the limits of processing, disk, and memory allocation and deallocation 4. develop an understanding of the resource limit mechanism in Linux Description

1. Kill init. Without modifying the OS kernel, make your best attempt to kill the init process. What happens? 2. Kill All Processes. Try to kill every process on the box. What happens? Can you be sure? What is the best order for doing this (i.e., what is the most reliable mechanism to do this)? Killing yourself before the job is done does not seem effective... 3. Bye Bye File System. Delete the contents of your filesystem (hint: explore the use of the rm command at the root of your directory tree). Make sure you succeed in doing this. What happens to your machine? Can you successfully reboot? 4. No More Room. Fill all available disk space. Describe what you did and what happens. How long did it take? 5. No More Space. Write a program that allocates all available memory and searches it for the string “password”. What happens to your system when you run this program? What happens to your program when you run this program? How long does it take? 6. Fork Bomb. Write a program that invokes fork(2) in an infinite loop. What, if anything, happens to your machine? Is this what you expect? Look at the kernel control path for the do fork implementation of fork(2). Hint: use a tool like LXR. 7. Thick Filters. How many iptables rules can you insert before you noticeably affect the receipt and processing of network packets on your machine? This question will require you to (1) learn something about iptables (the Linux fire- wall) rules, (2) develop some way of measuring how long it takes for a packet to traverse your kernel. Consider the use of ICMP from a remote machine. 8. Flip Bits. Write a program that opens /dev/mem and writes a random amount of randomly–generated bytes to an arbitrary location in the file. Repeat as long as you can. Keep track of the addresses you’ve written to. Catch and ignore SIGSEGV (which you might get if writing to a read-only address or memory location/range). Describe any errors you see. Perform this experiment for ten trials. Keep track of the most interesting errors as well as a log of all the ad- dresses you were able to write to. Did this work as expected? Could you write to all locations in memory? Why or why not? Again, look at the kernel source code that implements the /dev/mem psuedodevice.  Notes, Hints, and Recommendations

You may perform the above tasks in any order you wish.

It may be useful to maintain several snapshots of your VM guest, one per task (so that, for example, after you delete the file system contents, you don’t have to do a full reinstall). For many of these tasks, you will probably wish to acquire root privileges.

24, 25 Sep : Vulnerability Assessment and How it relates to "CIA"[edit] Exercise 5: Finding vulnerabilities of our system

The purpose of this exercise is to find publicly known vulnerabilities of our operating system using a standard vulnerability scanner 'NESSUS'. NESSUS is a widely used tool for vulnerability scanning.

Steps

1. Download the 7 day trial version and install it. You might need to use your ucalgary email address. download link : 12 2. Before scanning, you need to set up policy. Go to 'policy tab' and click '+New Policy'. 3. There are different policies. For this exercise, lets set our policy to 'Basic Network Scan'. You can find details of other policies here 13. 4. Now, Go to tab 'Scan' and click '+New Scan'. Here refer to the policy name that you've created just now. Run the scan. 5. It'll generate a report. My system scan report looks like this one - 14. 6. You'll find different vulnerabilities , Critical, High, Medium, Low, Info. [Note: How these are classified? CVSS is a vulnerability scoring system designed to provide an open and standardized method for rating IT vulnerabilities. Detail of CVSS : 15, Detail of scoring metrics: 16. 7. NESSUS generated scan report 17 with one critical vulnerability "Mac OS X<10.9.5 Multiple Vulnerabilities " for my system. Lets select this vulnerability detail. 8. In the detail page, you'll find different information. In the left side, there are Description(List of vulnerabilities and its description), Solution(How this can be patched), See Also (list of references for further analysis), Output, Ports, Host. In the Right side, you'll see, Plugin Details (NESSUS uses different plugins to identify vulnerability 18), Risk Information(Risk calculated using CVSS parameters 19), Vulnerability Information ( If it is exploitable, which tool can be used to exploit etc.), Reference Information (CVE IDs). This 2 links will help you to visualize. 20 and 21 Exercise 6 : Understanding Vulnerability in detail and CVE

Here, we'll try to understand what NESSUS has found as vulnerability. We'll look into any vulnerability and try to understand its detail.

Steps A case study

1. Lets have a closer look into the critical vulnerability "Mac OS X<10.9.5 Multiple Vulnerabilities " for my system. 2. In "See Also" section, there are several urls listed. Lets select the second one - http://support.apple.com/kb/HT6443 22. 3. You'll find the detail information of the multiple vulnerabilities in terms of Available for, Impact, Description and CVE ID. Lets take the last one ruby. 4. Detail of ruby Available for: OS X Mavericks v10.9 to v10.9.4

Impact: A remote attacker may be able to cause arbitrary code execution

Description: A heap buffer overflow existed in LibYAML's handling of percent-encoded characters in a URI. This issue was addressed through improved bounds checking. This update addresses the issues by updating LibYAML to version 0.1.6

CVE-ID

CVE-2014-2525

5. Detail of CVE-2014-2525: You'll find detail of CVE at https://cve.mitre.org 23. You can have further idea of who is this organization, what they do, how they process CVE id. Common Vulnerabilities and Exposures (CVE®) is a dictionary of common names (i.e., CVE Identifiers) for publicly known information security vulnerabilities. CVE’s common identifiers make it easier to share data across separate network security databases and tools, and provide a baseline for evaluating the coverage of an organization’s security tools. If a report from one of your security tools incorporates CVE Identifiers, you may then quickly and accurately access fix information in one or more separate CVE-compatible databases to remediate the problem24.

This page 25 describes CVE-2014-2525 as Heap-based buffer overflow in the yaml_parser_scan_uri_escapes function in LibYAML before 0.1.6 allows context-dependent attackers to execute arbitrary code via a long sequence of percent-encoded characters in a URI in a YAML file.


Exercise 7: Understanding CWE

From the above exercise, we were able to get the detail of vulnerability CVE-2014-2525. Here, we'll try to dig down a further to understand the exploit "Heap-based buffer overflow".

Steps

1. There is a website which maintains all known software weaknesses. It is CWE -http://cwe.mitre.org 26. CWE™ International in scope and free for public use, CWE provides a unified, measurable set of software weaknesses that is enabling more effective discussion, description, selection, and use of software security tools and services that can find these weaknesses in source code and operational systems as well as better understanding and management of software weaknesses related to architecture and design. 2. lets search "Heap-based buffer overflow" and find the detail here http://cwe.mitre.org/data/definitions/122.html27. 3. It shows the detail as "A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc()". It also shows, Time of Introduction (of this weakness like architectural design or implementation), Available platform (like C/C++), Common Consequences ( in terms of CIA -Confidentiality, Integrity, Availability, Access Control or Other) Exercise 8: How this vulnerability relates to code and CIA

From exercise 7, we get to know the weakness detail. It shows the consequences as below:

1. Availability : Technical Impact: DoS: crash / exit / restart; DoS: resource consumption (CPU); DoS: resource consumption (memory) Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.

2. Integrity, Confidentiality, Availability, Access Control Technical Impact: Execute unauthorized code or commands; Bypass protection mechanism; Modify memory Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. Besides important user data, heap-based overflows can be used to overwrite function pointers that may be living in memory, pointing it to the attacker's code. Even in applications that do not explicitly use function pointers, the run-time will usually leave many in memory. For example, object methods in C++ are generally implemented using function pointers. Even in C programs, there is often a global offset table used by the underlying runtime.

3. Example code: While buffer overflow examples can be rather complex, it is possible to have very simple, yet still exploitable, heap-based buffer overflows:

Example Language: C

define BUFSIZE 256 int main(int argc, char **argv) {

char *buf;

buf = (char *)malloc(sizeof(char)*BUFSIZE);

strcpy(buf, argv[1]);

}

The buffer is allocated heap memory with a fixed size, but there is no guarantee the string in argv[1] will not exceed this size and cause an overflow.

01,02 Oct: File Access, File Permission[edit] In our previous tutorial, we had seen, how to use a scanner to find a known vulnerability and how this vulnerability is related to some code like buffer overflow. Lets do a buffer overflow exploit. But, before doing that, we need to familiarize ourselves with some coding techniques and tools like debugger. So, in today's tutorial we'll play with file access and permissions. Often, you'll hear that "Hackers were able to gain access through some arbitrary code". So, knowing access and its properties is important. For example, how you'd be able to create a file and execute that file using root privilege (assuming you don't have root privilege)?

Exercise 9

In how many ways you can create file? Probably, if you are a Windows user, then you'll just right click and create a file. You can also use some shell/bash command like 'touch'. But today, we'll see how we can write a simple c code to create a file and give the file some access privileges.

We created a simple c code that accepts input as text from user and create the file, write the text to that file and close that file after saving. We used file descriptor open(2). See man open(2). We have seen how we can pass the parameters for a file with flags ReadOnly/WriteOnly/ReadWrite Only File/Create File/Append File. We have seen the header <fcntl.h> and the actual binary values of these flags After that, how the privileges read/write/execute can be given to User/Group/Other by using <sys/stat.h> How to change the file privilege using chmod command (using numbers, u/g/o & +- r/w/x) While passing these parameters, why we are using OR operator instead of AND Finally, we understood what this piece of code mean 

 fd = open(datafile, O_WRONLY|O_APPEND, S_IRUSR|S_IWUSR)

SimpleNote.c


//accepts a note as a command line argument and adds it to the end of the file //file location /tmp/notes //functions — usage(), fatal(), ec_malloc() 

 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
 #include <fcntl.h>
 #include <sys/stat.h>
 void usage(char *prog_name, char *filename) {
  printf("Usage: %s \n", prog_name, filename);
  exit(0);
 }
void fatal(char *);            // A function for fatal errors
void *ec_malloc(unsigned int); // An error-checked malloc() wrapper
int main(int argc, char *argv[]) {
  int fd; // file descriptor
  char *buffer, *datafile;
  buffer = (char *) ec_malloc(100);
  datafile = (char *) ec_malloc(20);
  strcpy(datafile, "/tmp/notes);
  if(argc < 2)                 // If there aren't command-line arguments,
    usage(argv[0], datafile); // display usage message and exit.
 strcpy(buffer, argv[1]);     // Copy into buffer.
 printf("[DEBUG] buffer   @ %p: \'%s\'\n", buffer, buffer);
 printf("[DEBUG] data file @ %p: \'%s\'\n", datafile, datafile);
 strncat(buffer, "\n", 1); // Add a newline on the end.
// Opening file
 fd = open(datafile, O_WRONLY|O_APPEND, S_IRUSR|S_IWUSR);
   if(fd == -1)
    fatal("in main() while opening file");
   printf("[DEBUG] file descriptor is %d\n", fd);
// Writing data
  if(write(fd, buffer, strlen(buffer)) == -1)
    fatal("in main() while writing buffer to file");
// Closing file
 if(close(fd) == -1)
    fatal("in main() while closing file");
 printf("Note has been saved.\n");
 free(buffer);
 free(datafile);

} 

// A function to display an error message and then exit
 void fatal(char *message) {
 char error_message[100];
 strcpy(error_message, "[!!] Fatal Error ");
 strncat(error_message, message, 83);
 perror(error_message);
 exit(-1);

} 

// An error-checked malloc() wrapper function
 void *ec_malloc(unsigned int size) {
 void *ptr;
 ptr = malloc(size);
 if(ptr == NULL)
    fatal("in ec_malloc() on memory allocation");
 return ptr;

} 06, 07 Oct : Introduction to SVN, ptrace(2)[edit] SVN

URL of Repository --> https://forge.cpsc.ucalgary.ca/svn/courses/c525/yourName

General commands:

Here, URL == Repository and Path== working directory

Checkout : Copying files from URL to Path svn checkout URL[@REV]... [PATH] svn checkout https://forge.cpsc.ucalgary.ca/svn/courses/c525/yourName /pathInYourLocalComputer

Add : Adding file in your Path svn add hello.txt

Commit : Adding file to URL svn commit -F msg hello.txt

output: Sending hello.txt Transmitting file data . Committed revision 5.

Update : Updating files on Path svn update [PATH...]

Import : Committing a file or tree into URL svn import [PATH] URL

For details : http://svnbook.red-bean.com


ptrace(2)

We have analyzed man ptrace(2) and a code snyfer.c

snyfer.c http://wiki.ucalgary.ca/page/Courses/Computer_Science/CPSC_601.29.ISSA/20110211CodeSession

15, 16 Oct : s-bit, User IDs(Real and Effective), Multiuser note taker[edit] Understanding s-bit

Exercise 10

Using code from exercise 9, we'll create access control matrix for the files ./samplenote and /tmp/notes. Then for three users (for example, Alice, Bob and Charlie), we'll try to execute ./samplenote and read /tmp/notes. We'll analyze our observation.

Exercise 11

We'll add s bit to ./samplenote (chmod u+s ./samplenote). Repeat exercise 11 and analyze our observation. What happened and why? Understanding User IDs

Exercise 12

A simple code uid_demo.c to understand real user and effective user. Create access control matrix for ./uid_demo For three users (like Alice, Bob and Charlie), we'll execute ./uid_demo and find real user id and effective user id. Analyze our observation Exercise 13

Add s bit (chmod u+s ./uid_demo) Repeat exercise 12. What happened and why? Can we explain exercise 11 now? Multiuser note taker

So far we've experimented with a single user of a file. What is the case, if we want a file can be written by 3 users but users are only able to view his/her portion? For example, Alice, Bob and Charlie can write to file notes but Alice can read only her writings not Bob's or Charlie's one.

Exercise 14

We'll look into the code notetaker.c and note search.c and explain the case 17, 18 Nov : Roll your own vulnerability[edit] Exercise 15

This exercise is from "Hacking The Abacus"- Exercise 3.9

In it, we will create a very contrived, artificial vulnerability and “exploit” for it.

Understanding code injection vulnerabilities and exploits is a non-trivial topic precisely because the common understanding seems to rely on the same notion that underlies the act of cramming too many clothes in a suitcase. Sure, an “overflowed buffer” seems to sound a lot like a burst suitecase, but the analogy is ultimately misleading. A buffer overrun is not about piling copious amounts of data into a small space! Rather, it is about constructing a series of memory write operations to very specific locations; “buffers” (whatever they are) are simply an attractive target because they reside near important control flow artifacts and are often receptor sites for data memory write operations.

Synopsis

You will write a small program that writes to a buffer on its stack. You will also construct a payload to write to this buffer.

Learning Outcomes

Here, we intend you to have the following outcomes:

1. Put into practice your knowledge of shellcode 2. Learn about the function call calling convention 3. Learn about activation records and structure on x86 4. Get a hands-on appreciation of what a simple stack–based buffer overflow actually is Materials

gcc. ld. an editor. nasm. udcli.

In the references below, there is a link that discusses x86 calling conventions, and how mixing control data and normal data in the same contiguous memory location entails risk. You should read it.

Description

This is preparation for understanding basic stack-based buffer overflows, but the larger lesson is that anywhere control information and pointers are mixed with writeable data, you have an opportunity for employing a “write primitive” as an attacker. This includes dynamic instances of structure types on the heap. Or other dynamic memory areas, such as those created via mmap(2) or mapped in from files.

More importantly, this demonstrates how x86 systems fail to take advantage of segmentation support to differentiate between different types of memory. Systems need support for fine-grained separation of memory segments that can be efficiently enforced.

Task 1: Construct a Payload Write a small piece of standalone assembly code that executes a system call (do something interesting, like open, read, or write to a file, or fetch the process ID). You know how to do this from previous labs. Don’t create a valid ELF (or do, and just extract .text) Store the resulting bytes in a file. We will revisit it. Task 2: Write a Vulnerable Program Write a small, intentionally-vulnerable program that opens the “payload” file and reads in the bytes to a buffer on the program’s stack; you should construct this buffer and the payload so that you overwrite the return address. Make sure to disable any protections and enable something else (hints are below).

Task 3: Reconstruct a Payload Take your payload from Task 1 and rewrite it so that the right parts of it overwrite the return address on the stack. Task 4: Make it Work Running your victim program on your payload should cause your “injected” shellcode to execute and achieve the goal of your shellcode. Notes, Hints, and Recommendations

You will want to read the overview of calling conventions on x86 here: http://www.unixwiz.net/techtips/win32-callconv-asm.html

You may or may not wish to use strcpy(3). Or write your own. Or use memset. You probably want to turn off various protections to make this work: compiling programs with fno-stack-protector turning off ASLR: as root: ‘echo 0 > /proc/sys/kernel/randomize_va_space’ marking executables as needing executable data areas: ‘execstack -s a.out’ You probably want to read this classic Phrack article: “Smashing the Stack for Fun and Profit” http://www.phrack.com/issues.html?issue=49&id=14&mode=txt You can see an example of a gdb trace of an overflow in action at: http://pages.cpsc.ucalgary.ca/˜locasto/teaching/2011/ISSA/code/session.txt

19,20 Nov :Case Study: A Simple Stack-based Buffer Overflow (Exercise 3.10 from Hacking the Abacus)[edit] Exercise 16

This lab is a guided exercise and walkthrough of the libpng stack-based vulnerability and a PoC exploit (thanks to Chris Evans).

Synopsis

In this lab, we will take an up-close look at a real vulnerability. The point isn’t to see this as the state of the art – instead, it is about seeing exactly what the semantics of a code injection attack are and how it depends on the environment of the program’s process address space and code! One special thing to note is how the actual control transfer happens way after the target buffer is overflowed and target state is corrupted!

Only after the program begins to return up a deep call chain (after doing a bunch of other valid processing) does the exploit complete and begin execution (well, crashing in this particular case b/c the payload is malformed).

Materials

The hardest part of this lab is actually the setup; you will need to fetch the vulnerable version of libpng from an archive and a library dependency (zlib). You then need to compile from source and then compile a utility (a sample PNG viewer) included with the libpng source. If you follow the instructions in the various Makefiles you will be fine. But consider this a baptism by fire of the Linux command line and Makefiles.

You should read these files first:

You can find a PoC file here: pngtest_bad.png

Learning Objectives

The point of this lab is to provide a hands-on assessment of an old stack-based buffer overflow vulnerability and the resulting exploit. This takes the previous lab and cranks it up a notch: the vuln is in real, widely used software, and we get a richer address space than just a simple program copying a string from a file.

Description

Using gdb, this session we will take a guided tour of the operation and execution of a real exploit on a real (but old) vulnerability. While the specific type of vulnerability is less likely to be a problem or easily exploitable for most current commodity systems, the principles involved are illustrative from both an attack and defense perspective.

Task 1: Setup Find the vulnerable version of libpng and install it to a local subdirectory (not the whole machine) following the directions in the Makefile and documentation. Task 2: Compile rpng-x In the contrib/gregbook directory, compile the rpng-x viewer against your vulnerable library. Task 3: Run rpng-x on the PoC exploit PNG Run rpng-x on Chris Evan’s sample PNG. Does the program crash? Now run it in gdb and observe the state of the process when it crashes. Task 4: Analysis Using gdb and the source code, diagnose what happened. We can look at a wealth of information in both the source code (at the source level definition of various functions) and at the assembly level. We first observe how rpngx reacted when fed the proof-of-concept test case to exercise the vulnerability. We observe some output error messages and then a segfault. We start rpng-x in gdb and begin to place breakpoints from the png handle tRNS() function in the ’pngrutil.c’ file. Reconstruct the call chain from the source!

Hint: you can drive the initial location by searching for the error message. At each step, keep track of the state of the stack: what activation records are there, and what information do they contain?

We place breakpoints at different related functions (e.g., png crc finish, png read data, png default read data) and look at them both at the source level as well as disassembly within gdb. One tricky part of this procedure is that the call chain involves a function pointer, but simple stumbling around the right source files and reading the code will help you out. Also, the function pointer eventually resolves to a function that calls fread().

The key problem seemed to be that the length of a fixed-sized local buffer (256 declared bytes – find out what constant this is!) – and specifically the amount of space allocated on the stack (300 bytes) was smaller than the 512 bytes of data that fread(3) ultimately stuffs into that fixed-sized local buffer.

Task 5: Modify PoC We can able to modify the PoC exploit to include shell code that does something interesting, such as issuing a CC or invoking exit(2) with some value. Change the PoC file in a hex editor. Inject a NOP sled over Chris’s payload, then place a CC in a strategic spot. Where the code returns to depends on your environment, so you may have to fiddle a bit and map the offsets in the file to the address in memory on the stack. Task 6: Drop a Shell If you are creative enough, you can spawn a shell once you get the return address correct (via stack examination of where the NOP sled landed on the stack).

Notes, Hints, and Recommendations

Like the previous lab, your machine likely has a number of countermeasures in place already, and performing basic exploit research to understand the basic concepts (e.g., those presented in “Smashing the Stack for Fun and Profit” http://www.phrack.com/issues.html?issue=49&id=14&mode=txt ) requires you to turn them off to remove some complexity. This includes, but isn’t limited to:

compiling programs with fno-stack-protector

  • turning off ASLR: as root,

‘echo 0 > /proc/sys/kernel/randomize_va_space’

  • marking executables as needing executable data areas: execstack -s a.out

Navigation menu RobinenriqueTalkPreferencesWatchlistContributionsLog outPageDiscussionReadEditView historyUnwatch More

Search Go Main Page Recent changes Help pages All pages Popular pages Faculties and Departments Clubs Print/export Create a book Download as PDF Printable version Tools What links here Related changes Upload file Special pages Permanent link Page information This page was last modified on 27 December 2015, at 11:42. Content is available under Creative Commons Attribution/Share-Alike License unless otherwise noted. Privacy policyAbout wiki.ucalgary.caDisclaimersCreative Commons Attribution/Share-Alike License Powered by MediaWiki

Retrieved from "http://wiki.ucalgary.ca/index.php?title=Http://wiki.ucalgary.ca/page/Courses/Computer_Science/CPSC_525.F2014/Tutorial_Schedule&oldid=70579"