In this article, I will demonstrate how to exploit Minishare v1.4.1 through a buffer overflow.
Murmur: In the previous article, I spent hours trying to get calc.exe to launch. In this practice, however, I spent less than 30 minutes developing and completing the exploit script!
Buffer Overflow
The vulnerability is caused by the following process:
After receiving an HTTP request, the server application splits the data based on a pattern such as HTTP/1.X.
The first part is treated as the method (or URL) and stored in a buffer.
During this process, the server application does not properly check the boundary or length of the data, allowing an attacker to store an excessive amount of data in the buffer, which causes a stack-based buffer overflow.
Note: I found that many reports online state that this vulnerability is caused by the HTTP method, such as GET, POST, or HEAD. However, my experiments show that this is inaccurate. The method itself is not the key point; the large amount of data is. A buffer overflow can occur even when the HTTP method is omitted. In this article, however, I discovered this phenomenon toward the end, so many of the screenshots were taken using an HTTP method. The final exploit script does not contain any HTTP method.
First, I tried to crash the server application by sending a large amount of data:
Next, we need to execute the shellcode. To do so, the EIP value needs to point to an address on the stack, since the shellcode is located on the stack in this scenario.
To achieve this, we need the CPU to execute jmp esp. Therefore, we simply need to overwrite EIP with an address containing the jmp esp instruction. We can use mona to search for this instruction in all loaded modules:
if sys.stdin in read_sockets: line = sys.stdin.readline() ifnot line: break shell_sock.sendall(line.encode())
if shell_sock in read_sockets: data = shell_sock.recv(1024) ifnot data: print("\n[-] Connection closed by target.") break sys.stdout.write(data.decode(errors='ignore')) sys.stdout.flush()
In this article, I demonstrated how to exploit a legacy application using a classic stack-based buffer overflow.
Unlike the previous article, I spent only about 30 minutes developing the completed exploit script. I hope this demonstrates that my exploit development skills have been improving!
In the next article, I will start practicing SEH-based buffer overflows.
This is the end of this article. If you have any comments or suggestions, please feel free to leave them below!