MP4___Spring_2024

Mini Project #4: Vulnerability Exploitation in ICS Protocol CS6263/ECE 8813: Introduction to Cyber Physical System Security Assigned: March 20, 2024 Due: April 3, 2024, 11:59pm EST Introduction This two part project will focus on using the SHODAN search engine and ICS-CERT database to find devices visible on the net and their particular vulnerabilities. In the second part we will pretend as if one of the nodes that was found via Shodan has a real vulnerability in an ICS protocol library (that has now been patched) that you will exploit. 1 Part 1 (20 Points) Cyberattacks are on the rise and a major contributing factor to this is the fact that many of these devices are accessible/visible just by a quick search online. SHODAN ( https://www.shodan.io/ ) is a search engine that lets the user find specific types of devices (webcams, routers, servers, etc.) connected to the internet using a variety of filters. 1. Using Shodan’s filters find devices accessible through the net under these categories: (a) Industrial Control Systems: i. Modbus protocol ii. ENIP protocol iii. BACnet protocol (b) Web cameras (c) Printers Shodan gives the option of generating reports, when you create a free account. Please use your GT credentials to create an account and generate reports for the above mentioned categories and turn in your reports. 2. Now that you know how to look for specific devices on the internet, let’s say you used Shodan and found that a local Industrial Plant uses Allen Bradley Micrologix 1100 family of PLCs. The next step is to find if this model/family of PLC has any known vulnerabilities. Use ICS-CERT ( https://www.cisa.gov/uscert/search ) database to find all the vulnerabilities you can find for this particular model. Submit 1

Mini Project #4 Vulnerability Exploitation in an ICS Protocol your findings in the form of a PDF containing the Model number, the vulnerability discovered, brief description of the vulnerability . Your report must include at least four vulnerabilities with their descriptions in your own words (you will not receive credit for simply copy/pasting text). 3. Hopefully, you have found a Buffer overflow vulnerability from your search of the ICSCERT database. We know for sure that this particular model 1763-L16BWA suffers from Buffer overflow vulnerability. Go back to Shodan and search for this particular model to find how many devices you can find for this model. To search for this particular model, Go to Explore EtherNet/IP and append the model number into the search field. Generate and submit a report . You can use the PDF Mage Firefox plug-in to generate your reports Link 2 Part 2 (80 Points) Buffer Overflow is a very popular vulnerability that is exploited by attackers. For more information on Buffer Overflow, please see the following links: 1. How Buffer Overflow Attacks Work 2. Buffer Overflow Exploit 3. First Stack Buffer Overflow to modify Variable 4. How to exploit a buffer overflow vulnerability - Practical 5. Detailed explanation of a return to libc attack 6. GDB Cheatsheet of common commands In this section, you will exploit a buffer overflow vulnerability in the libmodbus library. NOTE: This is different from the buffer overflow vulnerability you found in the previous section. We’re now pretending as if you found a device that suffers from the buffer overflow vulnerability in the libmodbus library. This vulnerability exists in version 3.0.4 (and previous ones), and was patched in version 3.1.2 at February 10, 2015. The vulnerability can be found in the modbus reply function and is exploited by the remote write/read requests. In this function, rsp is a buffer which was defined in the stack. This buffer is used when the server tries to read/write from/to the registers (see the modbus reply function in modbus.c file). Since the number of requested registers is not checked in this function, rsp can be overwritten. This is exactly the main vulnerability of the modbus reply function. We have provided you with a virtual machine (VM) image for this part of project. We do not recommend using your own ubuntu instance or VM because the underlying architec- ture of the machine could change the address structure of the registers causing variation in your solution. Our VM’s image link is: Image Link Georgia Institute of Technology 2 Cyber Physical Systems Security

Mini Project #4 Vulnerability Exploitation in an ICS Protocol 5. Explain what you did in each step with details and support your report with screen- shots (e.g., stack, addresses, terminal after the successful exploitation). You can find the libmodbus library functions in the modbus/src directory in modbus.c file. Also, the source code of the server ( unit-test-server.c ) is available at Desktop/modbus/tests . gdb (if you’re using gdb for the first time, we recommend checking out here ) can be used to find the aforementioned addresses and test/debug your exploit. However, it should be noted that your final exploit (i.e., the final version of your client.py ) should work outside of gdb. Again, the successful exploit will lead to the following statement printed in the server terminal. Congratulations! You have executed the secret function! Note: It totally is fine to receive the segmentation fault after the congratula- tions message, as seen below. Georgia Institute of Technology 4 Cyber Physical Systems Security

Mini Project #4 Vulnerability Exploitation in an ICS Protocol 2.2 Opening a New Shell in the Server (30 Points - No Partial Credit) Once you finish the previous part, this part should be easy for you. In order to complete this part, you should modify the client.py file in such a way that a new shell is opened in the terminal that server runs. If you check the current shell in the server terminal (i.e., sudo echo $ 0 ) before exploiting the server code, you will see bash . After the successful exploitation, you should see sh as the current shell. It is totally fine if your exploit in this part works only inside the gdb, as seen below. Hint 1: ROP Attack Example Hint 2: Not everything highlighted in Hint 1 applies to our use-case, as an exact imple- mentation of what is listed will not work, remember this is a real-world vulnerability. It is up to you to figure out what to do (using breakpoints and stepping through code will be very helpful). Explain what you did in each step with details and support your report with screenshots (e.g., stack, addresses, terminal after the successful exploitation). Georgia Institute of Technology 5 Cyber Physical Systems Security

Mini Project #4 Vulnerability Exploitation in an ICS Protocol A modbus write and read registers This function code performs a combination of one read operation and one write operation in a single MODBUS transaction. The write operation is performed before the read. Holding registers are addressed starting at zero. The request specifies the starting address and number of holding registers to be read as well as the starting address, number of holding registers, and the data to be written. The byte count specifies the number of bytes to follow in the write data field. The normal response contains the data from the group of registers that were read. The byte count field specifies the quantity of bytes to follow in the read data field. Figure 1: Modbus Documentation for modbus write and read registers Here is an example of a request to read six registers starting at register 4, and to write three registers starting at register 15: Figure 2: Example Payload for modbus write and read registers Georgia Institute of Technology 7 Cyber Physical Systems Security

Mini Project #4 Vulnerability Exploitation in an ICS Protocol The example payload unit-test-client.c uses the stuct.pack function to send the request. Table 1: Example Payload Name Data Transaction Identifier < 00 >< 00 >< 00 >< 00 >< 00 > Size of Request < 0F > Unit Identifier + Function Code < FF >< 17 > Read Starting Address < 00 >< 6B > Quantity to Read < 00 >< 03 > Write Starting Address < 00 >< 6C > Quantity to Write < 00 >< 02 > Write Byte Count < 04 > Write Registers Value < 00 >< 00 >< 00 >< 00 > When executed in the python script it will look like: m = struct.pack( ’21B’ ,0x00,0x00,0x00, 0x00,0x00, 0x0F, 0xFF,0x17,0x00,0x6B,0x00,0x03,0x00, 0x6C, 0x00, 0x02, 0x04, 0x00,0x00,0x00,0x00) s.send(m) Example Response: < 00 >< 00 >< 00 >< 00 >< 00 >< 09 >< FF >< 17 >< 06 >< 02 >< 2B >< 00 >< 00 >< 00 >< 00 > Here is another example of how to send a Modbus TCP packet via the pack method structure. Georgia Institute of Technology 8 Cyber Physical Systems Security

Mini Project #4 Vulnerability Exploitation in an ICS Protocol C Questions and Answers This section answers potential questions that might arise as you are working. Question 1: How do I get started? Answer 1: You might start by adding the code they provided to client.py: m = struct.pack( ’21B’ ,0x00,0x00,0x00, 0x00,0x00, 0x0F, 0xFF,0x17,0x00,0x6B,0x00,0x03,0x00, 0x6C, 0x00, 0x02, 0x04, 0x00,0x00,0x00,0x00) s.send(m) Start the server, then run client.py. The message that client.py ’sends’ above will be received by the server and will result in the modbus write and read registers function being called. Question 2: My current output is: The client connection from 127.0.0.1 is accepted Waiting for a indication... <XX><XX><XX><XX><XX><XX><XX>... [XX][XX][XX][XX][XX]... Congratulations! You have executed the secret function ! My question is, do I need to adjust it such that this part: [XX][XX][XX][XX][XX]... is not outputted? I’m assuming that is the ”response packet”? Answer 2: If you think about the structure of the program, this makes sense. The server code shows that there are 3 methods in the program (secret function, enum, and main). We’re calling main when the program is run. This function handles the receipt of incoming requests and sending their replies using modbus c. Since the buffer overflow is changing the return address of the return from the main function (secret function and enum are not being directly called), it is this last return that is being redirected to run the secret function. Thus, seeing the reply from the modbus request is expected. Georgia Institute of Technology 10 Cyber Physical Systems Security

Mini Project #4 Vulnerability Exploitation in an ICS Protocol Question 3: How do you suggest interpreting the long list of hex values when running x/128xw &rsp ? Answer 3: The command x/128xw &rsp shows 128 words of memory (4 byte blocks) from the current rsp location moving higher in memory. This covers the registers and such created when the server starts. Question 4: How do I line up my bytes with the stack? Answer 4: Try inserting padding bytes to cover 1 or more spaces that you need. Question 5: How do I find the address of /bin/sh ? Answer 5: Search for the /bin/sh string in gdb. Also, going through the attached HINT link will help. Question 6: When I run the sample request provided in the project description, my server terminates with: ERROR Connection reset by peer: read Quit the loop: Connection reset by peer Is it expected that the server terminates after every request? Answer 6: Yes, what you got is expected because the server exits at the end of requests. Question 7: For Part 2.2: After sending the correct payload from client22.py, are we allowed to use gdb to modify a memory location or a register in the server? This appears to be the only way to get the exploit to work. Answer 7: No, we will only run your client file for grading. Any other solution will receive zero in this part. Question 8: Which parts need to work with GDB and which don’t? Answer 8: You will need to use GDB to investigate how to construct and test your packets. Keep in mind that when running your finalized code: • Part 2.1 needs to work OUTSIDE of GDB. ie - sudo ./unit-test-server • Part 2.2 will only work INSIDE of GDB. ie - sudo gdb ./unit-test-server Georgia Institute of Technology 11 Cyber Physical Systems Security

Mini Project #4 Vulnerability Exploitation in an ICS Protocol vulnerability in modbus replay you understand. Look at the provided source code. Step through it as you read over the vulnerability description. Step 5) Watch the linked references on buffer overflow. Focus particularly on how the stack is built. What goes into it and when. What memory location in the stack needs to be replaced. These references are awesome and explain the problem in detail. If you don’t understand how or why a particular memory location is being changed, watch them again and perhaps find other resources. Step 6) Go through Appendix B. If you don’t understand any part of it, go through it again or look for references on Youtube and the provided links. Run the commands in gdb. The one to display the stack starting at &rsp is your friend here. This displays the stack starting with the variable rsp and keeps going past it. Trying to do anything of this before you’ve completed the first phase (modbus packet creating and validation) is largely a frustrating waste of time. Step 7) Now you need figure out the proper memory location(s) that you need to change in order to exploit the vulnerability. Provided gdb commands through instructions and linked references are key here. Step 8) Use the ’set *[ADDRESS] = new value’ command in gdb. This lets you man- ually test locations that you think should be changed to specific values you think they should be. Do this before trying to do with with client.py. Once you get the right ad- dress and value to cause the secret function to run, you can start trying to manipulate rsp. Putting It Together Step 9) Look at the stack memory starting with rsp. Match up against what you saw from step 3. Now starts the most difficult part, figure out a way to manipulate rsp through the client.py. This goes back to my first reply above that said what to think about regarding starting location and qty for read and write. You’ll again need to heavily rely on your knowledge from step 1 and comparisons to what is in the stack (rsp variable). Build from there. Visual Exercise As a visual exercise to help understand this, load up excel. First column, should be the register number (start at 0 and increment down to 20 or so), second column, register value. Fill these in with 0x0000. Pick one of the registers to write to and put in 0xFFFF (2 bytes) in the register value column for the register number you chose. Now pick a register to start reading from and a qty to read. Highlight those cells. Those will be the values read in. Pick different register start and/or qty. How does that affect where the number you wrote is positioned within the highlighted cells? Keep doing this until you understand the relationship between writing and reading registers. As far as the 4 vs 8 digits. A modbus register is 2 bytes, a memory address location is 4 bytes Georgia Institute of Technology 13 Cyber Physical Systems Security