moth //
Recently, BHIS penetration tester Dale Hobbs was on an Internal Network Penetration Test and came across an RPC-based arbitrary command execution vulnerability in his vulnerability scan results.
I had mentioned in passing that I was working on learning more about remote procedure calls, and Dale invited me to take a look at this vulnerability with him, an invitation that I happily accepted.
Quick disclaimer before the party starts: All credit to the initial disclosure of this vulnerability goes to Ron Bowes and Tenable. Even though this vulnerability is 10 years old at this point, this blog post will unfortunately not be accompanied by exploit code in order to protect Tenable’s intellectual property rights. For the same reason, specific exploit bytes are also redacted in cases where they were taken directly from packet captures. While I would love to eventually release the exploit code to the public for the benefit of other information security practitioners, this blog post instead focuses on the process of creating (and more importantly troubleshooting) exploit development.
With all of that out of the way — it’s party time.
Let’s start this adventure by looking at what Nessus has to say about this vulnerability. Nessus Plugin ID 59642 details that the vulnerability allows privileged command execution through an unauthenticated RPC interface.
Sounds relatively simple, but I’ve been burnt by assumptions of simplicity countless times before this. Before getting too eager, let’s take a look at what other information is available regarding the vulnerability. The upSploit URL in the references section looks promising, so let’s go there first and—
Oh. Ok, maybe the Internet Archive has a reference to it. Plugging in the URL, there turned out to be a single copy of the page, saved in 2013.
Well, let’s take a look and see what we’re working with. According to the archived article, a typical exploit connection looks something like the following:
unidata72 Alright, that’s a start, but it’d be really cool to see how Nessus is exploiting this vulnerability. According to Tenable, there are no known exploits available for the vulnerability.
Maybe looking at their script source code will give some insights, as can often be done for other findings during a test. Looking at the plugin file name will show us where to look and—
Ah. Uncool. From what I’ve read, an nbin file is a compiled Nessus file format that allows vendors to provide proof-of-concept code without disclosing the technical details to everybody. A good idea, but frustrating to run into while testing. Clearly, Nessus has some secret sauce going on, because the vulnerability scan shows that the ipconfig Windows command was successfully executed, and the output was received.
So, here’s the million-dollar question: How can we figure out what an nbin file is doing if we can’t see the source code? After mulling this over, Dale had an idea that led us down the road to our eventual destination of having a working exploit.
Dale was able to configure his vulnerability scanner to just run the specific plugin. He began a packet capture (pcap), ran the limited vulnerability scan, and then sent the resulting pcap file over to me so we could both look at the results. With the pcap in hand, we were then able to toss it into Wireshark and take a look at the relevant stream by searching for ipconfig in the packet bytes. The relevant TCP stream is shown below. IP addresses have been redacted. In the case where the last octet is shown, “.32” represents the testing host and “.74” represents the target host.
By following the TCP stream in Wireshark, another window is opened to display an ASCII view of the relevant conversation.
Now that we’ve taken a look at the ASCII representation of the TCP stream, let’s switch the output to Raw to see what bytes are being sent to the server.
The two heavily redacted lines in red are sent from the client to the server, and that’s what we’ll be referencing in order to start crafting our own exploit. But first, it’s maybe best for us to analyze the communication a bit closer. The following diagram shows an annotated look at what we saw while listening to the conversation:
With a better understanding of the vulnerability, and with the packet capture serving as a model of successful exploitation, it’s time to start writing our own exploit.
After an unsuccessful but mercifully brief attempt at writing the exploit in C, I was convinced by fellow BHIS penetration tester David Fletcher to switch to Python and Scapy. After some time getting reacquainted with Scapy, it was time to start building in earnest. The first step was to build all of the necessary packets sent by the client.
My first naive attempt of using Scapy to build the exploit predictably went poorly and was not made easier by the fact that I did not initially have access to directly experiment with the vulnerable system. Instead, I relied on a simple HTTP server running on a machine I controlled, just to get the conversation structure set up properly before running it live against the target. According to Wireshark, it looks like a few things went wrong all at the same time.
By adding some debugging output to the exploit to print the sequence and acknowledgement numbers, we can see that the numbers aren’t being updated properly, as the acknowledgement number is supposed to be changing.
At this point, it was getting to be early evening on Friday, and I was feeling like giving up, as our time frame to work on this vulnerability was quickly coming to a close. I got up for a walk to clear my head. I spent the first few minutes of my walk messaging David about some of the issues I was encountering, and he graciously gave me some good pointers. Clearly my sequence and acknowledgement numbers weren’t adding up, and we discussed the required update logic until I finally had a rough understanding of what needed changing. By the time I got back from my walk, I was convinced that we needed to see this through, and so we did.
I woke up the next afternoon and got on my computer to start looking at what exactly was wrong with my sequence and acknowledgement numbers. After tweaking the relevant number update logic, I checked Wireshark again and observed that the behavior seemed a bit better.
That said, I was still seeing a lot of “Destination unreachable (Communication administratively filtered)” in Wireshark, which confused me. On a virtual machine, I instead observed reset packets sent from the client to the server in response to every packet received.
So, what’s going on here? It turns out that Scapy’s troubleshooting documentation has a note on this very issue. The issue boils down to the client operating system responding to packets with a reset because the conversation did not originate from the client operating system directly. The Scapy documentation notes that the issue can be circumvented with an iptables command:
iptables -I OUTPUT -d xxx.xxx.xxx.74 -j DROP From my (and David’s) understanding, the firewall rule is necessary to prevent our host from killing a connection when it sees packets in conversations that didn’t originate from the OS’s own network stack. The OS sees the response packets from the server and sends resets because the OS isn’t aware that Scapy is the one handling the conversation.
With the firewall rule in place, I was able to verify that packets were being sent and received properly from my virtual machine to my test server. The following screenshot shows the closest I could get in testing to verify functionality without having Dale test it in his client’s environment.
I sent the latest exploit to Dale and had him run it. From the looks of the resulting pcap file, we can see that we’re about halfway there. From the errors, it looked like the sequence and acknowledgement numbers were still slightly incorrect.
The issue was fixed by removing an erroneous + 1 from the else block shown below. The following screenshot shows the final sequence/acknowledgement number update function:
After sending Dale the modified exploit, I logged off for the day to enjoy the rest of my Saturday. I woke up the next morning to an unexpected message from Dale: The exploit had worked.
After some celebration, my eyes were drawn to the end of the resulting output, shown below.
…Where’s the rest of our command output? The exploit performed by Nessus only had a single response packet containing all of the command output. Dale provided another pcap and we were able to see that the command output response was being split into two packets. The missing command output was contained within the second of two packets highlighted in the following screenshot.
Talking again with David, he noted that the packet options were likely incorrect. This prompted me to take a look at the packet options used by Nessus:
From what I could see, the SYN packet needed to specify a large window size, maximum segment size, and window scale. Doing so was relatively easy by plugging in some Scapy options into the packet.
While doing that, I also took the opportunity to clean up the output and added arbitrary command output support.
While implementing the ability to specify arbitrary commands, I reviewed the padding present in the command packet. The original packet observed from Nessus had four bytes of padding. This padding is likely to be important, but I figured it would be interesting to confirm. I removed most of the padding from the packet and observed that the server’s response contained no command output, as shown in the following screenshot:
Looking at the payload length of the second PSH ACK packet sent from the client, we can figure out the most likely padding value. The payload length is 56 bytes. Given that there are four bytes of padding, we can safely guess that padding is done to make the payload length to be a multiple of eight bytes, because 52 mod 8 is 4 and 52 plus 4 is 56. With that in mind, I kludged together the necessary padding in the code:
With the padding fixed, we were then able to issue commands to the vulnerable server. Seeing the properly formatted ipconfig output was equal parts thrilling and relieving.
After that, we were pretty much done. Dale requested an option to disable the sequence and acknowledgement number output, which I obliged by making that part of a new verbose option.
To verify that the arbitrary command execution part of this whole deal was working, Dale ran a few additional commands, namely a simple whoami command and a more complex net group 'Domain Admins' /domain command. Both commands worked like a charm.
And with that, my first successful adventure in exploit development is at a close. I suppose I should sum up some lessons learned during this process, especially given that I can’t publish the code:
My sincerest thanks to Ron Bowes and Tenable for the vulnerability disclosure and details, to penetration testers like David Fletcher for giving me pointers in the right direction (and also general encouragement), and finally to Dale Hobbs for inviting me to go on this adventure with him, for testing the exploit code, and providing me pcaps over the weekend while I was finishing the code up.
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。