Creating an Exploit PoC and Metasploit Module for CVE-2022-40022
I was helping a teammate on an internal network pentest. One of my tasks was screenshotting and reviewing HTTP/S services for default credentials and exploitable versions. That’s when I stumbled upon a Remote Code Execution (RCE) vulnerability in Symmetricom SyncServer. This post outlines the challenges we faced when developing the exploit proof of concept (PoC) and Metasploit code.
First, I found that the system was using the manufacturer default password. After authenticating, I started poking around for any function in the GUI which may be exploitable. One of the most frequent things I look for after gaining access to a web appliance through default credentials is a connection to LDAP (Active Directory). If I find an LDAP connection configured I immediately see if I can update the LDAP server IP address, point it to my system, change the protocol from LDAPS to LDAP (plaintext), if necessary, and click test. This is referred to as a “passback attack” and if successful you can frequently capture Active Directory credentials. In this case I never found that the system was connected to LDAP for authentication.
While poking around in the web GUI, I found a diagnostics page with a ping function. From past experience I knew that this function was likely to be passing user supplied input to the ping command and was a good place to look for command injection. I tried all of the usual command injection characters such as
| & < > ;
with no success. After some googling for more ways to do command injection in PHP I found backticks and $(). Submitting the id command enclosed in backticks in the hostname parameter and encoding the backticks as %60 resulted in seeing “uid=0” in the output.
If you look closely you’ll notice that there’s something missing in the output. The output of ‘id’ should include more than just the user id. In this case it’s missing the group id. That’s when I noticed that the output returned only the first word. I attempted to redirect the output to file using the > character since the software version also had a LFI vulnerability which would allow me to read any file, but this failed.
Now that I had a simple working proof of concept showing I could execute commands as root I felt a surge of adrenaline. I searched for existing RCE CVE’s in the product and didn’t find any. Yay, I was going to have another RCE CVE and my first Metasploit module! But what was that really going to do for me besides stroke my ego? My focus as team lead is developing my team, not myself. I decided to stop pushing so hard to find a path to shell and Metasploit module by myself and ask for help. I reached out to my team and opened a Teams call to share my discovery. During the call I shared what I had so far and we talked about what was standing in our way to getting a full shell. I invited the team to share in the CVE and Metasploit module bragging rights. Anyone on our team who helped make progress on it would have their name added to the Metasploit module.
At this point we were running out of time and had to wrap things up. I asked the client to keep our pentest laptop for a while longer and grant us access to continue working on this and the client agreed. For a week or so we didn’t touch this. We had to write pentest reports and start new pentest projects. I briefly worked on this a bit by myself and discovered that if you strip out the cookie, the response is a 302 redirect to login but it still executes your command and shows the output in the 302 response page!
I travelled onsite (different customer) for a physical social engineering engagement with longtime friend and coworker, Justin F. One morning when Justin and I were having breakfast on our way to the client site we talked about the filtering preventing us from saving output to a file and how the HTTP response only returned the first word of output. This is when Justin mentioned ${IFS} (Internal Field Separator). We had to head out to the client site so we agreed to look at it together from our hotel rooms after work that day.
After work that day Justin and I sat down in my hotel room and started working on using ${IFS} to separate words in the command we were trying to inject. That quickly led to getting a full shell and we were whooping it up in excitement.
Whoop, whoop! Pizza and beer time!
The next step was developing a Metasploit module, which ended up taking much more time than getting a root shell. This was due to our lack of understanding of Metasploit module creation and Ruby. Also, all of the Linux HTTP modules generally used > to redirect output to a file and that character was filtered by the application. I mainly worked with Rob on this part as Justin was busy with other projects. We asked the Metasploit team for help in the Metasploit Slack. They were great to work with and helped us work through issues along the way. You can find the module documentation here, and the module code here.
While working on the Metasploit module we found that there was a CVE that could cover this that we had somehow overlooked in our searches. However, not only did the CVE not link to any PoC code, but it also didn’t include enough information to know for sure if this was the same or a different vulnerabillity. We had found and exploited RCE in the SyncServer S100 (end of life model) but this CVE was in the currently supported S650 and didn’t list any details on vulnerable endpoints or parameters. I reached out to psirt@microchip.com via PGP encrypted email. I gave them the model, URL, and vulnerable parameter and asked if what I found was already covered by CVE-2022-40022. I received replies but never an answer. They seemed to be responding but avoiding answering my question. That’s when I decided that I should assume it was the same vulnerability as the CVE and document the CVE number and link in the Metasploit module.
While waiting for the Metasploit module to be published, I saw that there were eleven affected systems exposed to the Internet via a Shodan search. I was very uneasy about the thought of publishing exploit code for an End of Life system that was still exposed to the Internet. I spent some time trying to track down system owners and sent emails to those I could identify.
The thing I’m most happy about is that while going through the process of creating an exploit proof of concept and Metasploit module I was able to include the team that I mentor and two of them (Robert Bronstein and Justin Fatuch) also got their first Metasploit module. I greatly appreciate the help of Rob and Justin and the Metasploit dev team!
