Using Wireshark to Troubleshoot Exploits
Wireshark has many use cases that are not only limited to networking. One example is using it to troubleshoot exploits, which makes it a useful addition to a pentester's toolset. This post will demonstrate how to use Wireshark to troubleshoot a phpMyAdmin remote code execution exploit (CVE-2018-12613). Burp Suite can also be used to troubleshoot exploits and this has been covered in a previous post.
We start by running the exploit without any parameters to identify its usage and required parameters:
All of the above parameters are required to run the exploit. We will be running the exploit against a vulnerable instance of phpMyAdmin (192.168.1.101), which is running version 4.8.1.
The phpMyAdmin instance is using the credentials root:P@ssw0rd
, which we provide to the exploit and then run it:
However, in the above screenshot, the exploit returns the message: Unable to find the version
and was not successful as it did not return the output of the whoami
command. To troubleshoot this, let's use Wireshark to view the network traffic that is sent by the exploit. We start a live capture using Wireshark and add the filter tcp.port == 8080
to only show phpMyAdmin traffic. Next, the exploit is rerun again with the same parameters as before and the phpMyAdmin traffic now appears in Wireshark:
We also see a GET request that was made to /phpmyadmin/index.php
. Let's view the related packets by right-clicking on the request and selecting Follow > HTTP Stream:
Here we can see that an HTTP 404 status code was returned in the response:
This suggests that the /phpmyadmin/index.php
path does not exist on the server. Relooking at the phpMyAdmin instance path and the path provided as an argument to the exploit, we can see that they don't match:
So it looks like the path provided to the exploit was not correct. We set the exploit path to /index.php
and rerun it. The exploit now runs successfully and we can see the output of the whoami
command that is www-data
:
Though this example may seem contrived, it highlights an important aspect of exploits: the output returned by a non-working exploit may not always point to the underlying issue. This is where being able to view the network traffic that was generated by an exploit with Wireshark can help facilitate troubleshooting. This is because it may include useful information that may not be found in the exploit output on the command line.
tags: oscp penetration testing wireshark