A tale of an almost and one CVE (Danijel Grah)
| May 15th, 2023Level: Technical
Abstract:
As a security enthusiast, an obsolete tablet presented an opportunity to install Kiwi Syslog server from SolarWinds, but connecting to the tablet posed a challenge. Upon inspecting the tablet for restrictions, a curiosity-driven decision was made to run some PowerSploit scripts to check for possible privilege escalation. An unquoted service path vulnerability was discovered in the Kiwi Syslog server and reported to SolarWinds (CVE-2021-35231). The Kiwi Syslog Server version 9.7.2.1 has a “”Unquoted Service Path”” vulnerability which allows local privilege escalation. The default BINARY_PATH_NAME in the Kiwi Syslog Server service points to C:\Pogram Files(x86)\Syslogd\nasm.exe. We can place an executable named “”Program.exe”” in the “”C:\”” folder and because of unquoted service path and the Windows search order, the C:\Program.exe is executed as the NT Authority System next time the service is restarted.
The tablet was part of larger setup where the environment was prepared to evaluate Microsoft Defender and Sentinel. With an offensive mindset and again a lot of curiosity the decision was made to investigate how Microsoft Defender could be abused for privilege escalation. As vendors put a lot of effort into securing security products, we cannot expect to find much. But the Incident Response feature was interesting. When contacting support, Microsoft may ask for the output package of the “”Microsoft Defender for Endpoint Client Analyzer”” tool. This guidance is available in the article “”Collect support logs in Microsoft Defender for Endpoint using live response”” (https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/troubleshoot-collect-support-log?view=o365-worldwide). It was discovered that the “”Microsoft Defender for Endpoint Client Analyzer”” tool does not check the integrity of PowerShell modules and allows an attacker to gain “”nt authority\system”” privileges on the victim machine. If an endpoint has been compromised to an extend and the attacker has permissions to write to specific paths, he can execute a PowerShell module implant attack (Powersplanting). Microsoft didn’t recognize this as an vulnerability since by default the paths listed below are not writable by a none admin user. Since the console runs as NT Authority\System, the following search order for loading modules is considered:
- .\WindowsPowerShell\Modules
- C:\Program Files\WindowsPowerShell\Modules
- C:\Windows\system32\WindowsPowerShell\v1.0\Modules
- C:\Program Files\Microsoft Monitoring Agent\Agent\PowerShell
For accessing “.\WindowsPowerShell\Modules” we would need system privileges, therefore the next path is C:\Program Files\WindowsPowerShell\Modules\. To exploit the vulnerability, we need write permissions in C:\Program Files\ (not enabled by default). If the conditions are met, we can create a malicious BitsTransfer module, place it into C:\Program Files\WindowsPowerShell\Modules\BitsTransfer\BitsTransfer.psm1 and provide the necessary arguments as in the original BitsTranfer module. The result is a working privilege escalation.
Bio:
Danijel Grah has been in cyber security for almost ten years. He began his career as a consultant, later moved into research, and today at NIL he works in the Security Operations Center (SOC). Danijel has rich experience in penetration testing and security hardening,
programming, consulting, and developing systems of cyber defense. He has published and presented research papers at various international conferences in the field of information security, and he has confirmed his knowledge and experience with industry certificates such as GRID.
Video/recordings: