Technical Analysis

Vulnerability Exposure & Notification on Mikrotik (CVE-2021-41987)

2022.03.01D39

Brief

In 2021, we discovered an open directory on Huapi’s C2. We found the source code contained an exploit aiming at Mikrotik routers. More specifically, our analysis found that the exploit would allow the attackers to send specially crafted payloads to achieve Remote Code Execution (RCE) via WAN without any authentications. The targeted RouterOS products include mikrotik-tile-6.46.8, mikrotik-vm-64.8, and mikrotik-vm-6.48.

TeamT5 alerted Mikrotik to patch this vulnerability upon discovery. The patch for this vulnerability was released on 2021/11/17 and can be downloaded from the official Mikrotik website. All affected organizations should update their RouterOS immediately to avoid actors’ exploitation.

HUAPI (aka BlackTech, Palmerworm, or PLEAD) has been active since 2007 and has been targeting Taiwan for over a decade. Huapi’s malwares are highly sophisticated, and some of them use unique anti-analysis packers. Some of Huapi’s malware utilized a modified RC4 algorithm to encrypt the malicious C2 communication. Huapi focused on governmental entities, technology or telecommunication industries, and think tanks. Our observation suggested that over half of the victims were governmental agencies in Taiwan, the United States, Japan, and South Korea.

Attack vector

As a powerful and easy-to-use router, Mikrotik routerboard supports SCEP (Simple Certificate Enrollment Protocol), a service that was designed for simple certificate delivery. During transport, the binary data is encoded in Base64 via HTTP GET. Unfortunately, when processing the data from the payload, a miscalculation may occur if the payload is not properly formatted, potentially resulting in a Heap-based Buffer Overflow.

The open directory we had discovered contained exploit code that targeted mikrotik-tile-6.46.8, mikrotik-vm-64.8 and mikrotik-vm-6.48, along with their corresponding shellcode snippets. In the following sections, we will be analyzing the exploit code that was designed for mikrotik-vm-6.46.8.

Root cause analysis

By sending the following payload, we can cause the service www to crash and potentially trigger a Heap-based Buffer Overflow.

GET /scep/{scep_server_name}?operation=PKIOperation&message={} HTTP/1.1\r\n

The crash can be traced back to the function base64Decode, located under ScepRequest::parseRequest from /nova/lib/www/scep.p. When unpacking the Base64 request, the following code is used to calculate the output buffer size,

output_buffer_length = 3 * (input_buffer_length >> 2)

…which may cause a miscalculation of the output buffer, resulting in an insufficient memory allocation from malloc, leading to a heap overflow.

What happened?

For instance, we assume that the our input data is xxxxxxxxxxxxxxxxhCE, and the length of input buffer is 19. Based on the decompiled code, out_len = 3 * (input_len >> 2) which is out_len = 3 * (input_len // 4) (double slashes represent integer division), thereby allocating 12 bytes as decoded data buffer. However, the decoded data buffer should be 14 bytes instead of 12. This oversight allows the attacker to overwrite data in heap.

Overview of the exploit flow

According to the chunk-recycling mechanism, by overwriting the chunk size of a chunk in bins to a larger value (0x4121), the next malloc call will return a heap chunk overlapped with allocated chunks. This will lead to a heap overflow when writing to the chunk.

The part which will be overwritten is a vtable pointer in a destructor (sub_8052E90) function, and by setting the register edx to 0x8061a74, the instruction call [edx+4] will execute the gadget at 0x8058e89 ( xchg eax, ebp; ret; ) and execute the shellcode after pivoting the stack to the attacker-owned buffer.

Heap spray

The attacker can begin heap spraying by requesting 64 concurrent connections, and close some of them in order to let the vtable pointer be overwriten by the heap overflow later.

The function aaaa assembles the ROP gadgets, and the variable sc contains the shellcode for execution. Mikrotik 4.png

Trigger heap overflow

The function bbbb sends the payloads to the victim server in the aforementioned format.

The parameter message ('x'*801*4+'hCE') in the function bbbb will overwrite the size of next chunk. Here in gdb , it shows that the parameter message has been decoded to c7 1c 71 84 21 at 0x80859f0, and the last byte \x21 has been written as the next chunk size at 0x80859f4.

Attempting to retrieve the oversized chunk on heap

In order to retrieve the overflowed chunk, we need to send out more request. At some point, the register edx will be set to 0x8061a74 when the attempt reaches i=3.

Trigger destructor

The final step of the exploit, set off destructor call [edx+4] by closing connections. Mikrotik 10.png

Fingers crossed

Thanks to the heap spraying at the initial phase of the exploit, the data in the address 0x8061a74 will be modified, thus the instruction call [edx+4] will end up calling 0x8058e89 instead (the address of gadget xchg eax, ebp; ret;) and start executing our gadgets.

Once the gadgets have been hit, 0x8058e89: xchg eax, ebp; ret and 0x8052eb9: leave will allow us to pivot from the stack to the controllable buffer and start to execute our ROP chain from 0x804fbfc.

The ROP chain will try to increase the address of open to the address of mprotect, and the 0x804fc04: pop esp; ret; will set esp to 0x8061a74+8 to wrap up the ROP chain. Lastly, calling mprotect and jump right into the shellcode (0x8061674).

In the exploit, the shellcode can be interpreted as unlink('/nova/store/user.data') + sync() + reboot(), after the target device has finished rebooting. The attacker should then be able to login into web service as admin without a password.

Conclusion

To wrap up, let’s go over the exploit code once again:

1. Low stability

Since add() does not work in our favor and that ASLR is enabled by default, the exploit chain may fail on the first try.
Occasionally, even though the /nova/store/user.dat file will be deleted, the device does not end up rebooting. The shellcode may require extra improvements to make it more stable.
Even in best case scenario, the success rate is only about 5~6%.
Thankfully, in the event where the attack attempt fails, the watchdog process will restart the www service for us. This ensures stability and allows the attacker to not cause noticeable disruption during the attack.

2. Strict prerequisites

The attacker must be aware of the path name scep_server_name before being able to begin such attack.

3. Disclosure Timeline

2021/07/11: Acquire exploit codes from the open directory

2021/10/04: Responsible disclosure to Mikrotik and reserved CVE-2021-41987

2021/11/17: Official patch released

2022/03/01: Full disclosure released

4. Affected versions of RouterOS

6.46.8
6.47.9
6.47.10

About TeamT5 D39

D39 is committed to the field of vulnerability security and vulnerability discovery. The research scope includes systems and devices that are connected to the Internet, such as mobile devices, IoT devices, Linux, and Windows. Our team has held a number of critical or important vulnerabilities and has conducted presentations across various major security conferences, such as Blackhat, HITCON, etc.

Exploit research has always been one of the most advanced fields in network attack and defense. TeamT5 expects to invest resources to cultivate more talents to enter this field, and expects to have more and more world-leading vulnerability research talents in Taiwan. We welcome those who dare to face unknown challenges, are committed to vulnerability research and discovery, and have independent research capabilities to join us. 🤝