Product: ILEX International Sign&go 7.1.2 build 201804160953
ILEX International Sign&go is a modular global SSO solution from ILEX International. It offers Strong Authentication, Web Access Management, Mobile Access Management, Identity Federation functionalities through common architecture and administration.
Type: Local Privilege Escalation
Summary: Due to over permissive access rights on a logging directory, the ILEX International Sign&Go software can be abused to perform privileged file operations, such as arbitrary file creation. This can be exploited, e.g. via DLL hijacking on the privileged Sign&Go process, to obtain SYSTEM privileges on the local machine. This vulnerability was patched in recent versions and users should update to the latest version.
Introduction
When conducting audits on Windows laptops, I usually test for common privilege escalation techniques, namely using Procmon (from Sysinternals), to analyse the behaviour of installed non-system applications.
While doing a recent assessment I was looking at the Procmon output and noticed the Sign&go process writing to a log file inside the C:\ProgramData
directory:
I also noticed there were a lot of DLL hijacking opportunities that could be used for persistence:
The above process was actually a service, setup to automatically start at boot, and running as ‘SYSTEM’:
The service binary is located at C:\Program Files\Sign and go 7.1 Workstation Security Suite\sngWSService.exe
:
It’s also digitally signed:
Permissive directory access rights
Checking the permissions of the C:\ProgramData\Ilex\S&G\Logs
directory, it was possible to see that it was inheriting the permissions from C:\ProgramData
:
So as a regular user or in an enterprise environment, an Authenticated User will have Read and Write permissions on the C:\ProgramData\Ilex\S&G\Logs
directory.
Vulnerability Analysis
We have a Windows service running as ‘SYSTEM’, performing operations on user-controlled files and directories without impersonation.
All the conditions are gathered to use one of the several techniques to abuse Windows filesystem features, that James Forshaw developed and also released as the Symbolic Link Testing Toolkit, for researchers to use as Proof-of-Concept.
In this case, I will use Object Manager Symbolic Links to exploit the vulnerability, since unprivileged users can create symbolic links in the Windows Object Manager, in order to escalate privileges to SYSTEM. As an unprivileged user we can chain a mount point that resolves to the \RPC Control\
directory with an Object Manager Symbolic Link in that directory.
@Abusing privileged file operations (Provadys) - TROOPERS 2019
Exploit Chain
To exploit the vulnerability, we will need to:
- Delete all files in
C:\ProgramData\Ilex\S&G\Logs
- Create a pseudo-symlink named
C:\ProgramData\Ilex\S&G\Logs\000-sngWSService1.log
that points to C:\Windows\System32\pwned.dll
- note that the service can write to 000-sngWSService[1-2].log
, so when exploiting the vulnerability, first check what file is being used by the service.
- A regular user is not allowed to restart the service in order to force a file write operation, however, if the computer loses network connectivity the service will start writing error messages on the log file. So this third step can either be disconnecting the computer from the network or just wait it out (it can take a long time or be in a few minutes, so YMMV).
The steps above will use the symlink technique to divert the file write operation on the log file to an arbitrary file with an attacker-chosen name.
@Abusing privileged file operations (Provadys) - TROOPERS 2019
Exploit
I have written a Proof-of-Concept in Powershell and C++ and the code can be found here.
The powershell exploit will drop on disk two binaries from the Symbolic Link Testing Toolkit (CreateSymlink.exe and DeleteMountPoint.exe) and a reverse shell in DLL format, so it’s not very OPSEC safe.
To compile the C++ exploit, it’s necessary to link it with the Symbolic Link Testing Toolkit.
Powershell Exploit Execution:
Timeline
- 2020-07-08: CVE request sent to MITRE.
- 2020-07-13: Ticket opened with the vendor that included the vulnerability details.
- 2020-07-16: Ticket status feedback request.
- 2020-07-22: Ticket status feedback request.
- 2020-08-05: Ticket status feedback request.
- 2020-08-12: Ticket status feedback request.
- 2020-08-17: Answer from ILEX requesting some details.
- 2020-08-17: Feedback given to ILEX.
- 2020-08-18: ILEX accepted and confirmed the vulnerability.
- 2020-09-10: ILEX contacted again via LinkedIn.
- 2020-09-15: ILEX meeting to give further details.
- 2020-09-28: Patch released.
- 2020-11-10: Publication of this advisory.
- 2020-11-10: MITRE assignment of CVE-2020-23968.