DLL hijacking in Notepad++ version 8.5.4

[wowter-code]

Notepad++ versions 8.5.4 and earlier are vulnerable to DLL hijacking, which allows attackers to execute arbitrary code by placing any of the following DLLs in the same directory as notepad++.exe:

• C:\Program Files\Notepad++\MSASN1.dll
• C:\Program Files\Notepad++\TextShaping.dll
• C:\Program Files\Notepad++\iertutil.dll

Steps to Reproduce the Issue

1. For identifying the called DLLs that are not found during the execution, the following filters can be used in Process Monitor Sysinternals tool:

2. After monitoring the process, the DLLs marked with red were found as exploitable:

3. For testing the attack, a DLL file was created with Cobalt Strike, renamed as MSASN1.dll and placed in C:\Program Files\Notepad++\MSASN1.dll using the PowerShell command:

Copy-Item .\test.dll "C:\Program Files\Notepad++\MSASN1.dll"

4. Stop and Start notepad++ process with the commands:

Stop-Process -Name notepad++
Start-Process -FilePath "C:\Program Files\Notepad++\notepad++.exe"

5. A reverse shell (beacon) is obtained in Cobalt Strike:

6. Performing cleanup with the following commands:

Stop-Process -Name notepad++
Remove-Item "C:\Program Files\Notepad++\MSASN1.dll"

7. The process is the same for hijacking the DLLs:

C:\Program Files\Notepad++\TextShaping.dll
C:\Program Files\Notepad++\iertutil.dll 

Expected Behavior

notepad++.exe application should not look during runtime for inexistent DLLs.

Actual Behavior

notepad++.exe application is loading and executing the malicious provided DLLs leading to arbitrary code execution.

Note: All of the NOT FOUND DLLs were tested but the other did not worked due to the entry points generating errors during runtime.

[sredna]

Examples using Program Files is a bit silly (IMHO) since only admins can write there anyway. Your steps to reproduce should start with 1) Run PowerShell as elevated admin.

In Process Monitor, if you double-click one of the entries and look at the call stack, I would bet that it is not Notepad++ that is loading these directly but rather some other Microsoft code and you should be reporting the issue to them. iertutil just contains undocumented functions used by the shell.

Calling SetDefaultDllDirectories early in WinMain might prevent some of these but can also cause issues with 3rd-party shell extensions in the open/save dialog if they rely on %path% and use relative paths in the registry...

[wowter-code]

Hello,

There was a similar case: #12113 - this was categorized as a security issue and a CVE was issued for it: https://nvd.nist.gov/vuln/detail/CVE-2022-32168

About this "I would bet that it is not Notepad++ that is loading these directly but rather some other Microsoft code and you should be reporting the issue to them", you are partially right. But my kind question is why the reverse shell comes from notepad++.exe process? This indicates that the notepad++.exe is loading and executing some untrusted/unsigned DLLs that could be planted by malicious actors.

If you want to find more about this technique please see this: https://www.crowdstrike.com/blog/dll-side-loading-how-to-combat-threat-actor-evasion-techniques/

This issue with DLL hijacking is based on the DLL search order which is as follows:

• The directory from which the application is loaded. In this case the installation directory C:\Program Files\Notepad++\ or any directory where notepad++ is copied and run.
• C:\Windows\System32
• C:\Windows\System
• C:\Windows
• The current working directory
• Directories in the system PATH environment variable
• Directories in the user PATH environment variable

When notepad++.exe runs it is looking first for those 3 DLLs into C:\Program Files\Notepad++. Since they are not there and an attacker can place them, they will be executed prior to the legitimate DLLs located in C:\Windows\System32.

Reproduce the issue without admin rights

1. Copy notepad++.exe binary to any folder. In this case I placed it on C:\Users\user\Desktop\Notepad++ PoC and created one of the above DLLs into the same folder:

2. Once notepad++.exe is run from this folder, the TextShaping.dll is loaded, executed and a reverse shell is obtained:

CWE List

CWE-427: Uncontrolled Search Path Element

Recommendations:

• ensure that only signed DLLs are loaded by the application
• follow secure coding practices, avoid using insecure loading techniques, and always validate the integrity of the DLLs they load.

Impact:

Unauthorized Code Execution: By replacing a legitimate DLL with a malicious one, an attacker can execute arbitrary code within the context of the vulnerable application. This could lead to a variety of attacks, such as remote code execution or even full system compromise.

Application Manipulation: DLL hijacking can allow an attacker to modify the behavior of the targeted application, potentially causing erratic behavior, crashes, or other unexpected outcomes.

Bypassing Security Measures: If the vulnerable application relies on the legitimate DLL to implement security features, a malicious replacement could bypass or disable these security measures.

Persistence: If the DLL hijacking attack is successful, it can provide a persistent foothold on the system, allowing the attacker to maintain access even after system reboots or software updates.

Difficulty in Detection: DLL hijacking can be challenging to detect because the compromised DLL often looks like a legitimate file, and the malicious code might remain dormant until triggered.

[sredna]

why the reverse shell comes from notepad++.exe process

Because Windows does not keep track of which dll that created the socket.

A common example of this is, let's say Notepad++ calls shell32::Foo and Microsoft implemented Foo as

void Foo() {
if (something()) Bar();
}

Bar is implemented in iertutil and the linker settings has set iertutil to be delay loaded. If Foo is called, iertutil will be loaded by the delay load hook without a full path to system32 and you get the issue seen here. Having Notepad++ manually load iertutil with a full path before calling Foo will fix the issue but it is a game of whack-a-mole that makes assumptions about internal Microsoft code.

I don't expect you to actually report this to Microsoft because just knowing where to report it is hard and they are just going to ignore you anyway. This issue has been around for 20 years, they don't care.

[wowter-code]

@sredna - Thank you for clarifying this!

Let's wait for @donho to advise on this. As I mentioned, a similar issue with (UxTheme.dll) was identified here: #12113 - this was categorized as a security issue and a CVE was issued for it: https://nvd.nist.gov/vuln/detail/CVE-2022-32168

Thank you!

[sredna]

a similar issue with (UxTheme.dll)

While the end result might be the same, the cause is different. Notepad++ actively uses functions in UxTheme, it never knowingly uses iertutil nor TextShaping!

Microsoft could easily fix this for all Windows dlls by using a custom delay load helper:

The helper function for linker-supported delayed loading is what actually loads the DLL at runtime. You can modify the helper function to customize its behavior. Instead of using the supplied helper function in delayimp.lib, write your own function and link it to your program.

All Microsoft would have to do is to use a custom __delayLoadHelper2 that calls GetSystemDirectory and LoadLibrary when delay loading is called to load a dll. Like I said, this issue has been around for 20 years and Microsoft is not interested in fixing it even though it is easy for them to fix and ultimately it is their code that unsafely loads dlls.

In the end, Notepad++ will probably have to work around this by calling SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32) or loading the problematic dlls manually before calling any functions outside kernel32.

[donho]

As I mentioned, a similar issue with (UxTheme.dll) was identified here: #12113 - this was categorized as a security issue and a CVE was issued for it: https://nvd.nist.gov/vuln/detail/CVE-2022-32168

UxTheme.dll & the dll in issue #12113 are loaded directly by Notepad++, so it's the responsibility of Notepad++ to make them be loaded securely. Whereas the 3 dll pointed out in this issue (and I believe there are many more) are loaded by the system (ie. not directly by Notepad++).

Furthermore, via Notepad++ installer, the default installation directory is C:\Program File\Notepad++\. Any manipulation in this directory needs Admin privilege.
For people who install program in other directories than C:\Program File\Notepad++\, I think they know what they are doing.

As a result, it's not the security issue in Notepad++ to me.