Mini Project #4: Vulnerability Exploitation in ICS Protocol
CS6263/ECE 8813: Introduction to Cyber Physical System Security Assigned: July 5, 2023 Due: July 19, 2023, 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
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 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
2.1 Executing Existing Malicious Program (50 Points – No Partial Credit)
In the desktop of the VM, there is a folder named “modbus”, where the libmodbus library has been installed. The client and server files can be found in this directory: Desktop/mod- bus/tests/.libs. The client code can send a packet to the server to first write in multiple registers and then read multiple registers. The server code receives the packets, writes to the specified registers and reads the given registers, and finally responds to the client’s request. There is a function named secret function in the server file which is not executed under normal conditions. The aim of this part of the assignment is to send a request from the client code such that the secret function is executed. If you successfully execute the secret function, you will see the send packet and the following statement in terminal (no response packet). You should only modify the client.py file to exploit the server.
Congratulations!
You have executed the secret function!
You are required to use the modbus write and read registers function in the client which sends a packet to the server requesting write to multiple registers first, and then, read from multiple registers. This way, you can put the specified values in the rsp buffer and redirect the server program to malicious functions.
1. Import the OVA file to VirtualBox. (Username: student, Password: student)
2. Go to the following directory and run the server and client files: Directory:
Desktop/modubs/tests/.libs
You can run the server in the first terminal: sudo ./unit-test-server You can run the client in the second terminal: sudo python client.py
In the first step, try to construct and send a typical message to the server to see its behaviour and then change the client file to cause the malicious behaviour. Once you constructed a normal packet follow the next steps.
3. Run the server code in the gdb debugger (sudo gdb ./unit-test-server) and determine the location of the rsp buffer in the stack. Determine the return address of the modbus reply function and the starting address of secret function.
4. Design the payload such that you can overwrite the return address of the mod- bus reply function and run the secret function.
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
Georgia Institute of Technology 3 Cyber Physical Systems Security
Mini Project #4 Vulnerability Exploitation in an ICS Protocol
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
程序代写 CS代考 加微信: cstutorcs
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
Deliverable and Submission Instructions
Create a zip file named
|– client21.py
|– client22.py
|– vulnerabilities.pdf (part 1.2)
|– report.pdf (part 2.1 and 2.2)
|– shodanreports
|– modbus_protocol.pdf
|– enip_protocol.pdf
|– bacnet_protocol.pdf
|– webcams.pdf
|– printers.pdf
|– model.pdf (from 1.3)
Georgia Institute of Technology 6
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
浙大学霸代写 加微信 cstutorcs
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.
Transaction Identifier
Size of Request
Unit Identifier + Function Code Read Starting Address Quantity to Read
Write Starting Address Quantity to Write
Write Byte Count
Write Registers Value
<00><00><00><00><00> <0F>
<00><03> <00><6C> <00><02>
<04> <00><00><00><00>
Table 1: Example Payload
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)
Example Response: <00><00><00><00><00><09>
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
CS Help, Email: tutorcs@163.com
Mini Project #4 Vulnerability Exploitation in an ICS Protocol
B Executing Typical Message with GDB
Some important points that might be helpful for you:
1. It is very important where you put your breakpoints. Pay a special attention to mod- bus reply in the main function of the unit test server.c file, and line 912 in modbus.c, where the modbus reply returns to the main function.
2. b [line number] or [function name] puts a breakpoint in certain line number or at the beginning of a certain function.
3. info frame shows the registers while your program is paused in a breakpoint.
4. You can print out the first n words from the top of the stack at any breakpoint with
x/nwx $esp.
5. You can disassemble any function with disassemble function name.
Georgia Institute of Technology 9 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?
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)
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]…
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”?
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?
Try inserting padding bytes to cover 1 or more spaces that you need.
Question 5:
How do I find the address of /bin/sh?
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?
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.
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?
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
D Prior Experience
In the past, this assignment has taken students anywhere from a few hours to the full 2 weeks. Yes, it helps to have prior experience with concepts like the stack, buffer overflow exploits, and GDB, but they are not required, as part of this assignment is to help teach these concepts. In a previous semester a student had a very detailed response to how to approach this assignment which helped many students.
Original Question: I’ve spent many hours and every payload I create do always writes to the same place on the stack. What do I do?
There are 2 major understanding paths for this project. One is understanding modbus and how to form packets to send and receive data. The other is understanding the vulner- ability and stack memory locations that need to be manipulated. Then you piece those 2 items together.
Modbus Understanding
Step 1) Understand the modbus packet structure exactly. If I were talking to you right now and said, please tell me all of the fields, sizes, values, and their purposes within the modbus packet. You should be able to tell me, without referencing anything, generally what they are. But if you don’t have a very good understanding of the modbus packet format for what we are supposed to be sending and the format of what the server will be sending back, then you will have almost no chance of doing this assignment. What does the function code do? what should it be? what does the response packet look like? What comes after the function code? what values should you set and why? Some (not all) of fields are briefly in Appendix A, but if you haven’t found a deeper resource on the internet for the modbus TCP packet structure and studied it thoroughly, you are in for a world of hurt with this project.
Step 2) Read the python doc page for struct.pack. Make sure you know how to build data strings with it and have the format parameter set correctly.
Step 3) Using your knowledge from 1, construct a packet to do a simple task like writing and reading from 1 register (and the same one). Run this without gdb, the server program outputs both the received data from your client (in <>’s) and the data sent back (in [ ]’s). Get this working as expected. If you cannot make it work, that means you should go back to Step 1. You can verify that you are using the struct.pack correctly by looking on the server side at the received data in <>, if it doesn’t match the packet you are trying to construct, then you are doing something wrong with struct.pack, go back to Step 2.
Once you are building a proper modbus packet and getting the expected response, you can start worrying with gdb, because you are ready to move on to understanding the stack.
Vulnerability Understanding
Step 4) Read through the instructions. Make sure everything that is described about the Georgia Institute of Technology 12 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