WonderShell
Found By: Tomer Peled & Netanel Cohen
POC:https://github.com/netanelc305/WonderShell
Background
A few months ago, we released two articles (shamelessly plugged here) on Listary and Plex. The articles were about security vulnerabilities in their IPC communication (among other vulnerabilities). In our next vulnerability search, we focused on the misuse of socket communication and its consequences.
Enters Dr. Fone, a seemingly benign application to transfer data between two phones. Yet, as it turns out, it can be used as a “backdoor” that will not remove itself even after uninstallation.
We managed to gain an RCE from USER to SYSTEM(!!!) In two different ways — both of them were persistent on the system after the program’s removal
Elevation Service:
We started by looking for a vulnerable application that listens for connections by using the process hacker’s network tab:
We now know that elevation service is listening on port 12345
We also noticed through Procmon that processes are being spawned under “ElevationService.exe”
We wanted to dig deeper, so we started by using the go-to tool for language identification Detect-It-Easy and this is its output for ElevationService and Dr. Fone
Furthermore looking at the Wireshark communication on port 12345, we could see a path being passed to the service:
Right before the path,we saw a string that was either system_s or elevat_s. We correlated between the string and the programs that were executed by “ElevationService.exe” ; it was a one-to-one match. A definite lead for an RCE.
We used Dnspy to reverse the main Dr.Fone component and search for the function that sends this packet . After a few searching and cross-referencing with Wireshark, we came across this snippet::
We started checking if we missed an RPC communication from the application.
We quickly saw that this was not a classic RPC communication through WinAPIs. We did this by looking at RPCView and by looking at the import table of the DLL:
Looking at the export table we found call_s which is being imported into the c# main application:
y looking at the function’s instructions, we found the strings system_s and elevat_s:
By Importing this dll and function ourselves, we were able to reach an LPE execution:
We found a hardcoded localhost(127.0.0.1) that was used in the packet creation.
By changing the hardcoded IP 127.0.0.1 with a hex editor, we could also reach our coveted RCE! But since this was a somewhat ugly implementation of an RCE, we tried to break the packet structure down.
While trying to reverse the DLL, we also decided to search the web for the hex bytes of the packet and were able to find out that this entire DLL is an implementation of the “msgpack” library!
Like the ones found here:
https://github.com/msgpack-rpc/msgpack-rpc-cpp
http://msgpack.org/rpc/rdoc/current/MessagePack/RPC.html
https://pypi.org/project/msgpack/
We then used the python implementation and were able to create a short script that will give us an RCE from USER to SYSTEM privileges by creating and sending packets.
InstallAssist
As part of dr.Fone toolkit, it is possible to install different modules to handle different tasks, such as “WhatsApp Transfer”, ”Data Recover”.
When asked to install a module, Dr. Fone will first download the module, and then the InstallAssistService will perform the actual installation.
After researching InstallAssistService.exe, we found that the service is listening on a random UDP port; furthermore, the port number is saved in the location:
“C:\ProgramData\Wondershare\ModuleUpgrade\port”
The service sends a packet containing the instruction on what to execute and under which context to execute it.
After a little reversing of the InstallAssist Service we found the following code snippet
The service logs EVERYTHING…. including error codes, the reason for failure, and most importantly, the received message format.
After inspecting the log files, it was easy to figure out the expected message structure:
filePath — File to execute.
Parameters — parameters.
Authority — under what user context to execute.
CallPid — doesn’t matter. It can be a random number.
Finally, we created our payload with the same format and sent it to all UDP ports (since we attack remotely and have no way to know the specific port).
The payload, of course, can be customized for an LPE attack where the port is known from the file
Executable Path — Powershell.exe
Parameters — Reverse shell
Authority — Admin.
CallPid — Just a random number
And we got a SYSTEM shell.
Conclusion
Both “InstallAssist” and “ElevationService” can be used for LPE and RCE attacks both are persistent even after removing the application!
Dr.Fone is installed on many endpoints globally (millions according to Wondershare); Security personnel in companies should be aware of these “backdoors” and ensure outbound communication from these services is blocked by the organization’s firewall until Wondershare patch these vulnerbilities.
Disclosure Timeline
02/12/2021 - Disclosed to Wondershare inc.
02/12/2021 - CVE Request Sent
03/12/2021 - supplied initial details to wondershare customer support
06/12/2021 -Received email from Wondershare saying their product manager does not consider these vulnerabilities bugs
06/12/2021 - another email was sent to their customer service to make sure they are not going to fix these RCE vulnerabilities
06/12/2021- Israel National Cyber Directorate was notified about these vulnerabilities
06/12/2021-Received email from Wondershare saying that they are closing this ticket with no steps to resolve these vulnerabilities
09/12/2021 -Israel National Cyber Directorate decided to let MITRE handle this case
13/12/2021- Ticket closed by Wondershare
15/12/2021- CVE Numbers Received
22/02/2022-Wondershare was notified about this article
23/02/2022–27/03/2022 We tried to explain to wondershare the issue again including supplying them with the scripts the article video POC and several emails with detailed explanations on the problem
28/02/2022- Ticket Closed again by wondershare
29/02/2022-Email Sent to wondershare with no response
26/04/2022 -Article published
