Rapid7 Blog

Google  

Metasploit, Google Summer of Code, and You!

Spend the summer with Metasploit I'm proud to announce that the Metasploit Project has been accepted as a mentor organization in the Google Summer of Code! For those unfamiliar with the program, their about page sums it up nicely: Google Summer of Code is a…

Spend the summer with Metasploit I'm proud to announce that the Metasploit Project has been accepted as a mentor organization in the Google Summer of Code! For those unfamiliar with the program, their about page sums it up nicely: Google Summer of Code is a global program focused on introducing students to open source software development. Students work on a 3 month programming project with an open source organization during their break from university. This is an amazing program that helps remove the financial barriers of contributing to Open Source. Basically how it works is you (a university student) work on an Open Source project over the summer (12 weeks) with a mentor who has experience working on that project. As long as you keep at it and hit your milestones, Google gives you money along the way based on performance. Pay your rent, stock the fridge, get coffee, whatever. Open Source is the heart of the Metasploit community, but it's more than that to me. It's the means by which we, as programmers, can help improve the world a little bit at a time. We all stand on the shoulders of giants, building greater things because others before us have built great things. Like many OSS contributors, I personally started contributing to an Open Source project because it allowed me to get my work done more efficiently. By working together on Open Source, we can help others get their work done too, and enable them to build greater things. By working on Metasploit in particular, you will be helping to democratize offensive security, improving the world by giving everyone access to the same techniques that bad guys use, so they can be better understood and mitigated. If Metasploit is not where your heart lies, I encourage you to consider contributing to one of the other GSoC security projects. We have a list of project ideas that will have you writing some awesome code for great justice. Most everything requires at least a little Ruby, but if you're more comfortable in C or Python, there are options for you as well. Whatever you choose, I'm super excited to see what you will accomplish. Important dates to know: Student Application Period - March 20, 2017 - April 3, 2017 Student Projects Announced - May 4, 2017 If you are interested in participating, you should definitely check out the rest of the GSoC timeline. You will need to apply to us and also through GSoC's application page when it goes live next week on March 20th. So please come work with us. Be the shoulders others can stand on.

Mobile App & API Security - Application Security's "Where Waldo"

[A version of this blog was originally posted on February, 1 2013] As I have discussed in previous posts and at conferences, like OWASP AppSecUSA, while the number of attacks continue to increase, the attack techniques aren't new at all. They are actually the same…

[A version of this blog was originally posted on February, 1 2013] As I have discussed in previous posts and at conferences, like OWASP AppSecUSA, while the number of attacks continue to increase, the attack techniques aren't new at all. They are actually the same old attacks like SQL Injection showing up in new places including API's, mobile application services and AJAX applications. Because these newer technologies have exploded in popularity and become more mainstream, we keep seeing these same old vulnerabilities popping up in new places. I always say it's like Where's Waldo, and we simply need to understand the new landscape and start looking for Waldo again. Over the last several years, there has been a major evolution in how applications are being built with new underlying technologies, application architectures and data formats, but have application scanners evolved with them? These new technologies have grown at such a fast rate, we haven't been able to keep up at either end. On one end, developers aren't able to build these new applications securely because they are up against deadlines from the business and delivering on new technologies. And on the other end, web application scanners were architected in the golden days of web application security when almost all web applications were static and relatively simple HTML pages. While scanners have never and will never cover all 100% of a web application, our belief is that they can and should cover as much as possible. Unfortunately, most application security scanners haven't kept pace with the changing applications. Security professionals and application scanning vendors should be actively working to close the coverage gap detailed above to improve both the efficiency (reduce manual efforts) and effectiveness (find more vulnerabilities) of security efforts. The AppSpider team at Rapid7 continues to be committed to closing this gap. Our customers tell us that AppSpider automatically tests their AJAX applications and API's much more thoroughly than other options. We believe AppSpider is the only scanner that truly begins to address these newer technologies and formats like AMF, JSON and REST. But feel free to check it out for yourself. We welcome input and feedback. In my blogs, I'll detail the technologies used in modern applications and demonstrate why they create challenges for modern web scanners. In addition, I'll give you pointers on how you can determine if your application security scanners are effectively scanning and attacking these newer technologies. We will discuss the following kinds of applications and technologies: 1. RIA & HTML5 AJAX Applications: JSON (JQuery), REST, GWT (Google WebToolkit) Flash Remoting (AMF) HTML5 Applications (addressed in subsequent paper) 2. Mobile Backends powered by JSON, REST and other custom formats 3. Web Services JSON, REST XML-RPC, SOAP (addressed in subsequent paper) 4. Challenging Application Workflows Sequences: Shopping Cart and other strict processes XSRF/CSRF Tokens If you would like to read the full whitepaper on this topic, you can download it here. [Note: This blog has been transferred from Dan Kuykendall's blog, manvswebapp.com, as part of Rapid7's acquisition of NT OBJECTives. For more information on the acquisition, click here.]

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

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

Securing the Shadow IT: How to Enable Secure Cloud Services for Your Business

You may fear that cloud services jeopardize your organization's security. Yet, your business relies on cloud services to increase its productivity. Introducing a policy to forbid these cloud services may not be a viable option. The better option is to get visibility into your shadow…

You may fear that cloud services jeopardize your organization's security. Yet, your business relies on cloud services to increase its productivity. Introducing a policy to forbid these cloud services may not be a viable option. The better option is to get visibility into your shadow IT and to enable your business to use it securely to increase productivity and keep up with the market.Step one: Find out which cloud services your organization is usingFirst, you'll want to figure out what is actually in use in your organization. Most IT departments we talk to underestimate how many cloud services are being used by a factor of 10. That's shocking. The easiest way to detect what services are commonly in use is by leveraging Rapid7 UserInsight, a solution for detecting and investigating security incidents from the endpoint to the cloud. For this step, UserInsight analyzes your web proxy, DNS, and firewall logs to outline exactly what services are in use and which users are subscribing to them. This is much easier than sifting through raw log files and identifying which cloud service may be behind a certain entry.Step two: Have a conversation with employees using these servicesKnowing who uses which services enables you to identify the users and have a conversation with them about why they use the service and what data is shared with this service. UserInsight makes it easy to correlate web proxy, DNS, and firewall activity to a user because it keeps track of which user had which IP address on the corporate LAN, WiFi, and VPN, All of this information is just one click away.Based on this information, you can:Move the users to a comparable but more secure service (e.g. from Dropbox to Box.com), Talk with users about why a certain service is not suitable for use on the corporate network (e.g. eDonkey), andEnable higher security on existing services by consolidating accounts under corporate ownership and enabling stronger monitoringStep three: Detect compromised accounts through geolocation of cloud and on-premise accountsCompromised credentials are leveraged in three out of four breaches, yet many organizations have no way to detect how credentials are being used. UserInsight can detect credential compromise in on-premise systems and in the cloud. One way to do this is through geolocation. If a user's mobile device accesses email in New York and then a cloud service is accessed from Germany within a time span of 20 minutes, this indicates a security incident that should be investigated.UserInsight integrates with dozens of cloud services, including Salesforce.com, Box.com, and Google Apps to geolocate authentications even if they happen outside of the corporate network. The solution correlates not only cloud-to-cloud authentications but also cloud-to-on-premise authentications, giving you much faster and higher quality detection of compromised credentials. With Amazon Web Services (AWS), UserInsight can even detect advanced changes, such as changed passwords, changes to groups, and removed user policies. Read more about UserInsight's ability to detect compromises of AWS accounts.Step four: Investigate potential exfiltration to cloud servicesIf attackers compromise your corporate network, they often use cloud storage services to exfiltrate information, even if the company is not even using a particular service. When investigating an incident that involves a certain compromised user, you can review that user's transmission volume to figure out if and how much data was exfiltrated this way. UserInsight makes this exceedingly easy, breaking volume down by user and enabling you to see the volume on a timeline.If you would like to learn more about how UserInsight can help you get more visibility into your organization's cloud service usage, enabling productive conversations and better cloud security, sign up for a free, guided UserInsight demo on the Rapid7 website.

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

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

Weekly Update: Apache Struts Exploit, Android Meterpreter, and New Payloads

Apache Struts ExploitThis week's update includes an exploit for a pretty recent vulnerability in Apache Struts, thanks to community contributor Richard @Console Hicks. The struts_include_param module exercises the vulnerability described at OSVDB 93645, disclosed on May 23, 2013, a bare two weeks ago,…

Apache Struts ExploitThis week's update includes an exploit for a pretty recent vulnerability in Apache Struts, thanks to community contributor Richard @Console Hicks. The struts_include_param module exercises the vulnerability described at OSVDB 93645, disclosed on May 23, 2013, a bare two weeks ago, and originally discovered by Eric Kobrin and Douglad Rodrigues.The reason why I bring this up is not just because it's a solid exploit for a recent vulnerability (it is), but also because it illustrates, to a small extent, the Metasploit philosophy of disclosing working, tested exploits pretty much as soon as vulnerabilities are made public.If you are bothered by this stance, then maybe it's time to drag out a dusty old security meme: Defense in Depth. I know for sure there are IT operations folks out there who believe that there is absolutely nothing they can do in the face of zero-day vulnerabilities. This is a horrible, horrible place to be. The fact is, there are volumes and volumes written on defense in depth: you can segment your network, instrument your servers, keep an eye on egress rules, and generally make life a huge hassle for would-be attackers armed with zero (or 14, or 30) day vulnerabilities that you haven't patched against yet.I'm heartened that Google appears to have taken a similiar stance on this, with their announced policy of disclosing active, in-the-wild exploits in the interest of public safety. An Internet giant like Google taking an anti-secrecy stance like this is pretty powerful, and I'm looking forward to the next few weeks of vulnerability disclosures from them.Android MeterpreterOnce, a few weeks back, a fellow named timwr popped into the Metasploit IRC channel on Freenode and complained, rather rudely I might add, "How come there's no Android Meterpreter?" Egypt immediately responded with something along the lines of, "because you haven't written it yet." That, my friends, is how new ports of Meterpreter are made.Timwr, mihi, and Egypt got together over the next several weeks, and as of May 28 or so, we now have a pretty decent Meterpreter app for Android. Expect a much more whiz-bang blog post on this soon, but in the meantime, it's pretty fun to mess around with it now. We don't have mcuh in the way of Android exploits right now, of course, but that brings me to another topic.New PayloadsThis week's update also includes new payloads for ARM and 64-bit Windows. We've three new payloads, all from community contributor @dcbz32, to create reverse TCP and reverse HTTPS connections, as well as a simple shell payload. Hooray, our ARM support is getting more robust all the time; now if only we could convince people to start writing up decent Android and embedded system exploits...In addition, we also have a 64-bit Windows payload for reverse HTTPS, from community contributor agix. This has been a long standing feature request, because while in most cases, 32-bit payloads work just fine on 64-bit platforms, this isn't the case 100% of the time. While this payload works like a champ on Windows 7 and related platforms, it most notably is not supported for Windows 8 targets. Something funny is going on in Win8-land specifically, and it's proving squirrelly to nail down. So, good job to Microsoft for making post-exploit development a little bit harder on their latest platform (: . If you happen to have expertise in this area, we'd love to get your input on putting something solid together for Win8 reverse HTTPS connections as shellcode; ideally, we can end up with one payload for both 64-bit platforms.New ModulesWe've five new modules this week, including the Apache Struts exploit. Check 'em below.Memcached Remote Denial of Service by Gregory Man exploits CVE-2011-4971Apache Struts includeParams Remote Code Execution by Douglas Rodrigues, Eric Kobrin, and Richard Hicks exploits CVE-2013-1966Oracle WebCenter Content CheckOutAndOpen.dll ActiveX Remote Code Execution by juan vazquez and rgod exploits ZDI-13-094Lianja SQL 1.0.0RC5.1 db_netserver Stack Buffer Overflow by Spencer McIntyre exploits CVE-2013-3563CouchDB Login Utility by espretoAvailabilityIf 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 today when you check for updates through the Software Updates menu under Administration.For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

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