AMD Chipset Driver Information Disclosure Vulnerability
We recently discovered a critical information disclosure vulnerability that affected the AMD Platform Security Processor (PSP) chipset driver for multiple CPU architectures.
The vulnerability allowed non-privileged users to read uninitialised physical memory pages, where the original data was either moved or paged out.
Please note that the list of affected products may not be complete, as we were able to verify this vulnerability in two different systems using Ryzen 2000 and 3000 series CPUs, which are not currently listed in the AMD advisory.
*Latest Ryzen 5000 series CPUs chipset driver for PSP was not tested, but it is recommended that you update to the latest version.
At the time of writing the latest chipset drivers for the affected CPU architectures, can be found here.
*Update 17/09/2021: AMD revised their advisory with additional CPU architectures that were affected, including Ryzen 5000 series and Threadripper CPUs.
Another local privilege escalation vulnerability in Cisco AMP, Immunet & ClamAV
If you have been following our blog you will know that Zeroperil recently found a local privilege escalation vulnerability affecting Cisco AMP and Immunet; CVE-2021-1280. At the same time we also found a secondary vulnerability affecting Cisco AMP and Immunet, resulting in local privilege escalation which is detailed in this post.
Disclosure was coordinated with Cisco in order to allow the issue to be fixed before being made public.
CVE-2021-1386 is very similar to CVE-2021-1280 in that it again involves SFC.exe which is a system service loading a DLL, and also involves freshclam.exe.
Using the ProcMontool from Microsoft SysInternals we were able to see that the SFC.exe service attempts to load the DLL libclamunrar_iface.dll.9.0.4 and searches for this DLL in each directory contained within the system PATH environment variable.
SFC.exe searches for libclamunrar_iface.dll.9.0.4
Using ProcMon we could also see that freshclam.exe (which is periodically executed by the system service SFC.exe) also attempts to load libclamunrar_iface.dll.9.0.4 from each directory contained within the system PATH environment variable.
In order to exploit this vulnerability, an attacker would need to be able to write a DLL into one of the system PATH locations. This isn’t as difficult as you may think, during our time on Red Team engagements we have often seen misconfigured directory permissions on directories that are in the PATH environment.
For example Python 2.7 by default has a world writable installation directory, and the installer often adds the installation directory to the PATH environment variable.
In the image below, the vulnerability is being exploited using a default installation of Python 2.7, signified by the SUCCESS output in ProcMon as the malicious dll is successfully loaded from the C:\Python27\ directory.
freshclam.exe searches for libclamunrar_iface.dll.9.0.4
Using this technique it was possible for a standard low privileged user to obtain SYSTEM privileges:
cmd.exe with SYSTEM privilege obtained by exploiting the vulnerability
Conclusion
In order to mitigate vulnerabilities and attacks like this, it is essential that you ensure the system PATH environment variable does not contain writable paths, something that every enterprise should check after installing new software.
Software vendors should run tools such as ProcMon as part of their quality assurance pipeline, in order to detect this kind of vulnerability.
Full-spectrum EDR hook detection with low false positives
One of our side projects recently required us to generate a list of functions being hooked by an EDR with the following requirements:
Low false positive rate
Check a list of DLL’s not just NTDLL
Locate hooks in the second or third instruction of a function
Detect WOW syscall stub tampering
No ASCII art
We did a quick Google to see if there was an existing tool that could give us an answer quickly and found that EDR hooking is something that has been generating a lot of noise recently on social media, some of it good and some we are unsure if it’s a joke; one blog we read showed a screenshot of redirected functions from kernel32 to kernelbase, with the claim they found some hooks!
In the end we decided to spend a few hours putting together our own tool; the imaginatively titled HookDump
Dumping the hooks of an EDR
The details
Naive hook scanning solutions will simply scan a loaded DLL for jmp instructions in the first byte of a function, leading to many false positives, for example exported variables etc.
HookDump has a low (zero?) false-positive rate, this is achieved by loading each DLL examined twice, once using LoadLibrary and secondly by reading from disk into a buffer. Exported functions are resolved in both loaded copies, several instructions are disassembled from both copies and then the instructions are compared. Using this method HookDump can detect hooks in the first second or third instruction of a function.
Hooks visible in the second instruction of function, NTDLL
We have observed some EDR’s creating a fake entry for NTDLL in the PEB module list, combined with page guards/no-execute memory access permissions and exception handlers, trusted execution flow is redirected to the real NTDLL in an attempt to thwart shellcode manually locating function addresses by parsing the exports table. This is an old technique going back to 2005; Piotr Bania first detailed it in Phrack magazine #63. HookDump is able to locate the original copy of NTDLL and examine it for hooks.
HookDump also examines multiple DLL’s instead of just looking at NTDLL, the list of libraries is stored in the source file LibraryList.inl and was created by dumping a list of DLL’s loaded in explorer.exe using SysInternals ProcessExplorer.
Dumping hooks located in DLL’s other than NTDLL
Update Version 1.1
Some security products also modify the WOW64 syscall stub in 32 bit executables, HookDump now also detects this. Using this method, there is usually no need for direct jmp hooks in NTDLL so you may find that the tool only detects WOW64 syscall modification and no other hooks when running the 32 bit version. As with any tools like this, if you are unsure of the output, proper verification can be achieved by attaching a debugger and locating the hooks manually.
Source Code
Source code is available in the Zeroperil GitHub repository. Obviously, this hasn’t been tested against every single security product. If you find a bug, please feel free to fix it and send us a pull request
Local privilege escalation in Cisco Immunet and Cisco AMP
ZeroPeril recently took a look at two Cisco security products for Windows, Cisco Immunet and Cisco AMP. We discovered a local privilege escalation that affects both products.
One particular component common to both products is SFC.exe which is a system service, this service periodically executes a child process Freshclam.exe with SYSTEM permissions. Freshclam.exe is a part of ClamAV which is integrated into Cisco AMP and Cisco Immunet, and is used for updating ClamAV signature files in the product.
An investigation using ProcMon from Sysinternals, showed that both SFC.exe and Freshclam.exe attempted to read a non-existent file from a path on the user’s C drive:
freshclam.exe attempting to read C:\SSL\openssl.cnf
sfc.exe attempting to read C:\SSL\openssl.cnf
On Windows, any standard non-privileged user can create arbitrary directories in the C: drive if they do not already exist, so we decided to create this directory containing a blank file called openssl.cnf. Another run of ProcMon showed that both processes will indeed read the file if it exists.
sfc.exe and freshclam.exe read openssl.cnf if it exists
We investigated ways to exploit this by consulting the openssl.cnf documentation and immediately our eyes were drawn to the section about engine configuration, specifically, the example that is given for loading a dynamic link library:
Next, we decided to put together a simple DLL that would spawn a command prompt in the interactive session, by duplicating the primary token from a WinLogon.exe process, which runs as SYSTEM in the same session as the interactive user. We placed this dll on the following path: C:\ampwn\ampwn.dll
Using a specially crafted openssl.conf file, as shown below:
We were then able to coerce both sfc.exe and freshclam.exe to load our dll.
sfc.exe loading our dll ampwn.dll
By abusing the openssl.cnf file in this way we then obtained an interactive command prompt process running with full system privileges:
Command prompt running as SYSTEM, launched by sfc.exe system service
Conclusion
If you are using the OpenSSL libraries in your project, it’s worth checking if there is a default SSL config path that could be writable by a low privilege user, as this could be used by a SYSTEM service or high privileged process as described in this post.
We are two individuals who are extremely passionate about technology and information security, joining forces and combining years of hands-on experience in order to turn our innovative ideas into reality and bring exciting new technologies into the industry.
Currently we spend most of our time in R&D for our upcoming releases and are very excited to share more information with you in the near future.
While that part of our efforts is ongoing, we are dedicating some time into developing a simple website where we can start sharing some research ideas and other interesting findings whenever our busy schedule permits.
