πŸ”’
There are new articles available, click to refresh the page.
Before yesterdayZeroPeril Blog

CVE-2021-26333

15 September 2021 at 10:07

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.

The complete report can be downloaded here.

The official advisory by AMD can be found here.

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.


Disclosure Timeline

  • Vendor Contacted: 08/04/2021
  • Vendor Replied: 09/04/2021
  • Vendor Acknowledged: 12/5/2021
  • Public Disclosure: 14/09/2021

The post CVE-2021-26333 appeared first on ZeroPeril Blog.

CVE-2021-1386

7 April 2021 at 16:02

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 ProcMon tool 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 searching for unrar library
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 searches for libclamunrar_iface.dll.9.0.4
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:

SYSTEM cmd.exe
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.

Affected Products

  • CiscoΒ AMP for Endpoints Windows Connector
  • ClamAV for Windows
  • Immunet

Timeline

Initial discovery: 10/12/2020
Reported: 10/12/2020
Vendor replied: 11/12/2020
Issue acknowledged: 14/12/2020
Disclosed: 07/04/2021

The Cisco disclosure of this issue can be found here.

The post CVE-2021-1386 appeared first on ZeroPeril Blog.

Coordinated Disclosure Policy

31 March 2021 at 14:57

We have updated our coordinated disclosure policy document.

TL; DR

Public disclosure will generally occur within a 90 days time frame of first notifying the vendor of an issue.

There are a few caveats to this, such as situations where the vendor fails to respond.

Please read the full disclosure policy document for more information.

Download

The post Coordinated Disclosure Policy appeared first on ZeroPeril Blog.

HookDump

30 March 2021 at 12:57

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 πŸ™‚

The post HookDump appeared first on ZeroPeril Blog.

CVE-2021-1280

20 January 2021 at 16:00

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:

[engines]
foo = foo_engine

[foo_engine]
dynamic_path = /some/path/fooengine.so
some_ctrl = some_value
default_algorithms = ALL
other_ctrl = EMPTY

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:

openssl_conf = openssl_init
[openssl_init]
engines = engine_section
[engine_section]
ampwn = ampwn_section
[ampwn_section]
engine_id = ampwn
dynamic_path = c:\ampwn\ampwn.dll
init = 0

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.

Timeline

Initial discovery: 10/12/2020
Reported: 10/12/2020
Vendor replied: 11/12/2020
Issue acknowledged: 14/12/2020
Disclosed: 20/01/2021

The Cisco disclosure of this issue can be found here:

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-amp-imm-dll-5PAZ3hRV

The post CVE-2021-1280 appeared first on ZeroPeril Blog.

HELLO WORLD!

16 November 2020 at 14:23

Welcome to ZeroPeril Ltd.

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.

Keep calm and stay tuned!

Kyriakos & Tom

The post HELLO WORLD! appeared first on ZeroPeril Blog.

  • There are no more articles
❌