SSD Advisory – Cisco AnyConnect Privilege Elevation through Path Traversal

Vulnerability Summary
The update functionality of the Cisco AnyConnect Secure Mobility Client for Windows is affected by a path traversal vulnerability that allows local attackers to create/overwrite files in arbitrary locations. Successful exploitation of this vulnerability allows the attacker to gain SYSTEM privileges.

An independent Security Researcher, Yorick Koster, has reported this vulnerability to SSD Secure Disclosure program.

Affected Systems
Cisco AnyConnect Secure Mobility Client for Windows, Version 4.8.01090.


Vendor Response
Cisco has released a patch, available from:

Vulnerability Details
Cisco AnyConnect Secure Mobility Client contains functionality to auto-update itself. Auto-update also works for low-privileged users, which is possible because the update is initiated from a service called Cisco AnyConnect Secure Mobility Agent and is running with SYSTEM privileges. This service exposes TCP port 62522 on the loopback device to which clients can connect and send commands to be handled by this service. One of these command is to launch the vpndownloader application and update AnyConnect.

A path traversal vulnerability exists in the vpndownloader application for Windows that allows a local user to create and run files outside of the temporary installer folder. Successful exploitation of this vulnerability allows a local attacker to gain SYSTEM privileges.

The AnyConnect auto-update functionality has been affected by a number of vulnerabilities in the past that can be abused by local users to gain SYSTEM privileges (eg. Kostya Kortchinsky, Securify, Project Zero, SerializingMe). Cisco has made a number of changes to mitigate these attacks, amongst these changes are:

  • Executables need to have a valid Authenticode signature from Cisco Systems, Inc.
  • (New) versions of vpndownloader.exe are copied to %ProgramData%\Cisco\Cisco AnyConnect Secure Mobility Client\Temp\Downloader.
  • Proper NTFS Permissions are (now) set on the %ProgramData%\Cisco\Cisco AnyConnect Secure Mobility Client\ folder.
  • the vpndownloader.exe executable must have vpndownloader.exe configured as the original filename in its version information.
  • When vpndownloader.exe launches additional installation files, these files also need to have a valid Authenticode signature from Cisco Systems, Inc..
  • Installation files are copied in a separate temporary folder under %ProgramData%\Cisco\Cisco AnyConnect Secure Mobility Client\Temp\Installer before they are executed.

In a nutshell, the auto-update mechanism works by send a message to the AnyConnect Agent to launch vpndownloader.exe and instruct it to perform a certain action (as command line argument). This action is either moving/copying a profile (XML) file to a profile folder or launch a Cisco signed installer file. Technically, this doesn’t need to be an installer file, any Cisco signed executable will do. When vpndownloader.exe is instructed to run an installer file, the file is first copied to a temporary folder under %ProgramData%\Cisco\Cisco AnyConnect Secure Mobility Client\Temp\Installer.

After the file has been copied, the digital signature is checked including the signer of the file. If all checks out, the file is launched from the temporary folder and the folder is deleted after execution has completed.
Because the executable is copied to a new temporary folder, and the folder has proper NTFS permissions, it is not possible to perform a file/DLL planting attack to run arbitrary code. In addition, the file must be signed by Cisco and the signature must be valid, preventing the execution of arbitrary executable.

A path traversal vulnerability exists in the step where the (user-supplied) executable is copied into the temporary folder. vpndownloader.exe will extract the target file name from the source file name. Essentially it does this by searching for the last occurrence of the backslash (\) character in the source path, the right part after the backslash is treated as the filename and is used as the target file name. AnyConnect does not take into account that the Windows API also accepts the forward slash (/) as directory separator character. Because of this it is possible to cause vpndownloader.exe to create files outside its temporary folder.

Since the signature verification is done after the file is copied, it is possible for an attacker to copy any file to any location residing on the same volume as %ProgramData% (generally C:\). Copying of the file is done with SYSTEM privileges – when vpndownloader.exe is launched through the AnyConnect Agent. If the target file exists and SYSTEM has write access to this file, it will be overwritten with the attacker-supplied file. This alone is enough for a local user to gain elevated privileges.

Another attack scenario is to hijack a DLL that is loaded by a Cisco signed executable. Most Cisco executable are affected by DLL hijacking, a common DLL that is used by Cisco applications is the dbghelp.dll file. The attack consists of two steps:

  1. Create an attacker-controlled dbghelp.dll file outside of the temporary folder to prevent removal, traversing one folder up is enough.
  2. Launch a Cisco signed executable which is vulnerable to DLL hijacking from the same folder, again using the path traversal vulnerability.

When the Cisco signed executable is launched through the AnyConnect Agent, it will also run with SYSTEM privileges. The code in the attacker-controlled DLL will also run with these privileges. The application itself is opened within Session 0. Windows 10 1803 has removed the Interactive Services Detection Service, which makes it impossible for users to interact with any GUI displayed in Session 0. This of course does nothing to stop an attacker from gaining SYSTEM privileges, but it does require an additional step for the attacker to launch a GUI application with elevated privileges.

The POC is a PowerShell module which has the function Invoke-ExploitAnyConnectPathTraversal. This function has two modes.

Without arguments:
This mode tries to hijack %ProgramFiles%\Common Files\microsoft shared\ink\HID.dll, which is used by the on-screen keyboard. Run the following commands in a PowerShell prompt:

  1. Import-Module .-ExploitAnyConnectPathTraversal.psm1
  2. Invoke-ExploitAnyConnectPathTraversal
  3. Lock the Windows session or sign out
  4. Open accessibility tools in the login screen and launch the on-screen keyboard

A PowerShell prompt should open (behind the keyboard) running as SYSTEM. (Note that the on-screen keyboard of Windows 7 isn’t affected by this DLL hijack).

With arguments:
Running the function with arguments will create three files within %ProgramData%\Cisco\Cisco AnyConnect Secure Mobility Client\Temp\Installer:

  • payload.bat
  • dbghelp.dll
  • cstub.exe

cstub.exe is a Cisco signed executable, which will be launched by vpndownloader. dbghelp.dll is hijacked to run payload.bat. The provided argument(s) are written to payload.bat and thus will run as SYSTEM.

  1. Import-Module .-ExploitAnyConnectPathTraversal.psm1
  2. Invoke-ExploitAnyConnectPathTraversal

SSD Advisory – iOS powerd Uninitialized Mach Message Reply to Sandbox Escape and Privilege Escalation

(This advisory follows up on a vulnerability provided in Hack2Win Extreme competition, that won the iOS Privilege Escalation category in our offensive security event in 2018 in Hong Kong – come join us at TyphoonCon – June 2019 in Seoul for more offensive security lectures and training)
Vulnerabilities Summary
The following advisory describes security bugs discovered in iOS’s powerd, which leads to arbitrary address read with unlimited amount of memory and an arbitrary address deallocation with arbitrary size, which can lead to Sandbox Escape and Privilege Escalation.
Vendor Response
“Power Management
Available for: iPhone 5s and later, iPad Air and later, and iPod touch 6th generation
Impact: A malicious application may be able to execute arbitrary code with system privileges
Description: Multiple input validation issues existed in MIG generated code. These issues were addressed with improved validation.
CVE-2019-8549: Mohamed Ghannam (@_simo36) of SSD Secure Disclosure (”
An independent Security Researcher, Mohamed Ghannam, has reported this vulnerability to SSD Secure Disclosure program.
Affected systems
iOS versions before 12.2.
Vulnerability Details
The powerd has its own MIG implementation, it’s based on _SC_CFMachPortCreateWithPort which is nothing more than a wrapper of CFMachPortCreateWithPort, it hosts a MIG callback called mig_server_callback(). This Callback is the main MIG resource handler which acts like mach_msg_server() in user-space or ipc_kmsg_server() in XNU kernel.
When powerd receives a Mach message, it allocates a reply message buffer via CFAllocatorAllocate with the default allocator and then later the reply message got partially initialized in pm_mig_demux().

We can notice that pm_mig_demux() doesn’t well initialize the reply buffer and only considers the message reply as Simple Mach Message and not a Complex Mach Message .
Unlike the MIG kernel, the MIG semantics in user-space (at least for powerd) is a bit different, the MIG routine takes the ownership of all passed objects (Mach ports, OOL memories and OOL ports), in case of failure, the MIG routine deallocates the appropriate object and returns KERN_SUCCESS (except for some few MIG routines which break this rule) which makes the MIG handler thinks that the routine returned successfully and took the ownership of all passed arguments. This is very important to understand because the bugs hugely rely on this logic.
Another important thing to mention, is that powerd uses retval parameters to store the real return value, this is kind of informing the client whether the Mach message request succeed or failed.

_io_pm_connection_copy_status() is a simple function which does nothing but returns KERN_SUCCESS, by looking to the MIG generated code, we can see that it has to reply with a complex message :

From the described above, we are obviously in front of an uninitialized OOL descriptor with full control of the address and size data members.
With some basic knowledge on how Mach IPC works, it’s possible to turn this into arbitrary code execution.
it’s worth noting that this bug does not cause any crash or a undefined behavior (unless the attacker filled memory with meaningful data), and will always returns success to the sender as we’ve seen earlier.
By controlling the uninitialized memory via spraying the heap, we could successfully fake the address and size members of mach_msg_ool_descriptor_t, thus we could reliably read an arbitrary memory address of powerd with unlimited amount of content.

Here we came across a problem, we cannot control an important member of mach_msg_ool_descriptor_t which is the .deallocate flag, if it is set to TRUE, the sender will directly deallocate the memory, otherwise, it won’t.
Unfortunately, _io_pm_connection_copy_status() sets .deallocate = FALSE, so we cannot make anything more than just reading powerd’s memory content.
We can make this bug more impcatful by finding a vulnerable function with .deallocate flag set to TRUE
After inspecting few MIG methods, we came across this MIG call:

If we can make sendData to be NULL, the method will jump into exit block and returns KERN_SUCCESS without initializing array_data and array_dataLen.
gHIDEventHistory is a global variable and we don’t have a direct control over it, after looking for a way of controlling it, it is safe to say that there is no direct way to make it invalid.
How can we make gHIDEventHistory invalid?
After inspecting powerd’s behavior, we came across this fact: if we will start a fresh powerd service process, gHIDEventHistory will still contain NULL and only after some time and via a MIG routine it will become a valid CFArray.
We came into this conclusion:
If we can force powerd to restart we can have gHIDEventHistory set to NULL which is sufficient to make sendData to NULL and trigger the bug shown above. In order to do this , we need another memory corruption to just make powerd crashe and Launchd has nothing to do but spawn a fresh powerd instance.
Here is a trivial bug NULL pointer dereference:

We can control details_ptr. If we will pass a malformed serialized data into IOCFUnserialize(), it will return NULL, and CFRelease() is called later within details_ptr without checking its value.
By testing out the primitive described above and combining the bugs together, we can turn this bug into Use-After-Deallocate. As an example, we can deallocate the CoreFoundation Library and reading its content with unlimited size:

And by deallocating such mandatory library, we would expect a random crash as follows:

Approach for exploitation
Once we have the two reliable primitives, we are in front of multiple ways to reach controlling the flow of the execution, in the exploit, we tried to do the following:
We have powersource objects which has a description CF object, this object can be updated by the attacker as he wishes if the current working powersource object has been created by himself.
We will send a very large CF Object with lots of CFData objects with some tagged values, and since we have a reliable primitive to read unlimited amount of memory from powerd, we can locate these objects and get the offset of one of the CFData objects. Later with the deallocation primitive, we will deallocate the located CFData object in page-aligned manner, and re-fill it with user controlled memory.
By sending multiple Mach OOL messages with .copy = MACH_PHYSICAL_COPY, otherwise, we can’t refill memory as we would like, since powerd MIG routines deallocate OOL descriptor in the end of each function, we can successfully control the ISA pointer of the CFData, and by releasing the target powersource->description, we get a PC control with X0 pointing to our controlled payload. And the exploitation becomes straightforward.
Source Code
You can find the full source code of the exploit here:
iOS powerd Uninitialized Mach Message Reply to Sandbox Escape and Privilege Escalation
The exploit that will be provided here, steals powerd’s task port using ROP/JOP chains as follow:


SSD Advisory – Odoo CRM Code Execution

Vulnerability Summary
The following advisory describe arbitrary Python code execution found in Odoo CRM version 10.0
Odoo is a suite of open source business apps that cover all your company needs: CRM, eCommerce, accounting, inventory, point of sale, project management, etc. Odoo’s unique value proposition is to be at the same time very easy to use and fully integrated.
An independent security researcher has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program.
Vendor response
Odoo has done a private disclosure for the issue we reported, and the patch was merged in all supported branches.
CVE: CVE-2017-10803
The full public disclosure will be available at

SSD Advisory – ManageEngine Code Execution

Vulnerability Summary
The following advisory describes Unrestricted File Upload vulnerability that leads to Code Execution found in ManageEngine Firewall Analyzer and ManageEngine OpManager.
ManageEngine Firewall Analyzer is a browser-based firewall/VPN/proxy server reporting solution that uses a built-in syslog server to store, analyze, and report on these logs. Firewall Analyzer provides daily, weekly, monthly, and yearly reports on firewall traffic, security breaches, and more. This helps network administrators to proactively secure networks before security threats arise, avoid network abuses, manage bandwidth requirements, monitor web site visits, and ensure appropriate usage of networks by employees.
ManageEngine OpManager is a comprehensive network monitoring software that provides the network administrators with an integrated console for managing routers, firewalls, servers, switches, and printers. OpManager offers extensive fault management and performance management functionality. It provides handy but powerful Customizable Dashboards and CCTV views that display the immediate status of your devices, at-a-glance reports, business views etc. OpManager also provides a lot of out-of-the-box graphs and reports, which give a wealth of information to the network administrators about the health of their networks, servers and applications.
An independent security researcher, Yasser Ali (, has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program.
Vendor response
ManageEngine has released patches to address these vulnerabilities and issued the following advisory:

SSD Advisory – Sentora Web Hosting Control Panel Multiple Vulnerabilities

Vulnerabilities Summary
The following advisory describes two (2) vulnerabilities found in Sentora Web Hosting Control Panel that lead to remote code execution.
Sentora is a free to download and use web hosting control panel developed for Linux, UNIX and BSD based servers or computers. The Sentora software can turn a domestic or commercial server into a fully fledged, easy to use and manage web hosting server.
The vulnerabilities found in Sentora Web Hosting Control Panel are:

  • Authenticated Code Execution
  • Privilege Escalation

An independent security researcher has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program.
Vendor Response
The vendor has released an new version of the product which addressed the vulnerabilities.