Rapid7 Blog

Tod Beardsley  

AUTHOR STATS:

232

Apache Struts S2-052 (CVE-2017-9805): What You Need To Know

Apache Struts, Again? What’s Going On? Yesterday’s Apache Struts vulnerability announcement describes an XML Deserialization issue in the popular Java framework for web applications. Deserialization of untrusted user input, also known as CWE-502, is a somewhat well-known vulnerability pattern, and I would expect…

Apache Struts, Again? What’s Going On? Yesterday’s Apache Struts vulnerability announcement describes an XML Deserialization issue in the popular Java framework for web applications. Deserialization of untrusted user input, also known as CWE-502, is a somewhat well-known vulnerability pattern, and I would expect crimeware kits to incorporate this vulnerability well before most enterprises have committed to a patch, given the complications that this patch introduces. What’s The Catch? The problem with deserialization vulnerabilities is that oftentimes, application code relies precisely on the unsafe deserialization routines being exploited—therefore, anyone who is affected by this vulnerability needs to go beyond merely applying a patch and restarting the service, since the patch can make changes to how the underlying application will treat incoming data. Apache mentions this in the "Backward Compatibility" section of S2-052. Updates that mention, "it is possible that some REST actions stop working" is enough to cause cold sweats for IT operations folks who need to both secure their infrastructure and ensure that applications continue to function normally. What Can I Do? Organizations that rely on Apache Struts to power their websites need to start that application-level testing now so as to avoid becoming the next victims in a wave of automated attacks that leverage this vulnerability. Remote code execution means everything from defacements to ransoms and everything in between. In the meantime, Rapid7’s product engineering teams are working up coverage for organizations to detect, verify, and remediate this critical issue. A Metasploit module is in progress, and will be released shortly to help validate any patching or other mitigations. InsightVM customers with content at “Wednesday 6th September 2017” or later (check Administration --> General to confirm content version) can determine whether they have a vulnerable version of Apache Struts present on Unix hosts in their environment by performing an authenticated scan. The vulnerability id is struts-cve-2017-9805 should you wish to set up a scan template with just this check enabled. It has also been tagged with 'Rapid7 Critical.' An unauthenticated check for CVE-2017-9805 is available for InsightVM and Nexpose under the same id, struts-cve-2017-9805. This check does not remotely execute code; instead, it detects the presence of the vulnerable component against the root and default showcase URIs of Apache Struts instances. In addition to these specific updates, we’ve also produced a quick guide with step-by-step instructions on how InsightVM and Nexpose can be used to discover, assess, and track remediation of critical vulnerablities, including this Apache Struts vuln. Not an InsightVM customer? Download a free 30-day trial today to get started. Should I Panic? Yes, you should panic. For about two minutes. Go ahead and get it out of your system. Once that’s done, though, the work of evaluating the Apache Struts patch and how it’ll impact your business needs to get started. We can’t stress enough the impact here—Java deserialization nearly always leads to point-and-click remote code execution in the context of the web service, and patching against new deserialization bugs carries some risk of altering the intended logic for your specific web application. It’s not a great situation to be in, but it’s surmountable. If you have any questions about this issue, feel free to comment below, or get in touch with your regular Rapid7 support contacts.

You've Got 0-Day!

Hey all, it feels like it's been forever since I wrote a blog post that wasn't about some specific disaster currently consuming the Internet, so I just wanted to drop a note here about how I'll be speaking at UNITED 2017, Rapid7's annual security summit…

Hey all, it feels like it's been forever since I wrote a blog post that wasn't about some specific disaster currently consuming the Internet, so I just wanted to drop a note here about how I'll be speaking at UNITED 2017, Rapid7's annual security summit in Boston September 11-14. Specifically, I'll be closing out the Research and Collaborate track at UNITED on a topic near and dear to my heart: the vagaries of vulnerability disclosure. Vuln disclosure is a funny business; when you're on the receiving side, it's at best some unwelcome news about some bug in your product that's putting your customers at risk. If you're on the giving side, it's pretty much an invitation for angry letters from CTOs and their attorneys. So why bother? Turns out, despite all the emotional pain associated with it, reasonable vulnerability disclosure is pretty much the most effective tool we have to make the internet-connected products and services we produce and use that much stronger in the face of an increasingly hostile public network. We need vuln disclosure conversations in order to get better at what we do, since it's literally impossible to write, assemble, package, and deliver software of any complexity completely vulnerability-free on the first try. So, the goal of this talk is to share some stories about my experiences in vuln handling from both sides. As director of research here at Rapid7, I'm often the first point of contact for software and technology vendors when one of our researchers uncovers a vulnerability. On the flip side, I also get notifications about Rapid7 product bugs from security@rapid7.com, so I spend a fraction of my work life helping to get those bits of nastiness resolved. If you're looking for tips and advice on how to handle vulnerability disclosures—either as a discoverer, or as someone responsible for patching shipping software—then I hope my experiences will give you some insight into how this surprisingly emotion-driven business of disclosure works. Haven't yet signed up to join us at UNITED this year? Register here.

Petya-like Ransomware Explained

TL;DR summary (7:40 PM EDT June 28): A major ransomware attack started in Ukraine yesterday and has spread around the world. The ransomware, which was initially thought to be a modified Petya variant, encrypts files on infected machines and uses multiple mechanisms to…

TL;DR summary (7:40 PM EDT June 28): A major ransomware attack started in Ukraine yesterday and has spread around the world. The ransomware, which was initially thought to be a modified Petya variant, encrypts files on infected machines and uses multiple mechanisms to both gain entry to target networks and to spread laterally. Several research teams are reporting that once victims' disks are encrypted, they cannot be decrypted. For this reason, there's dissent on whether the Petya-like attack should be called ransomware at all. Whatever you call it, our advice is the same: Back up, patch against MS17-010 vulnerabilities (mitigation against internal spread), and block TCP/445 traffic.Don’t pay the ransom, since decryption by the attacker is impossible. Read on for further information on infection vectors, IOCs, and additional Rapid7 resources. In the early morning hours of June 27, 2017, UTC 3 time, ransomware that appears to be an updated variant belonging to the Petya family surfaced in Eastern Europe (read a sample summary here). Incident detection and response professionals around the world immediately started connecting this Petya-like ransomware with the same EternalBlue exploits used by the WannaCry ransomware. Since the attack was so widespread, collecting a sample was pretty straightforward, and Rapid7's incident response team is currently analyzing what is actually going on here. This blog post will be updated throughout the day with what we know about the ransomware, as well as what Rapid7 customers can do to prevent, detect, and respond to it. In the meantime, organizations are strongly advised to take the following actions: Ensure that all Windows systems have been patched against MS17-010 vulnerabilities. Employ network and host-based firewalls to block TCP/445 traffic from untrusted systems. If possible, block 445 inbound to all internet-facing Windows systems. Ensure critical systems and files have up-to-date backups. Backups are the only full mitigation against data loss due to ransomware. Rapid7 has a ransomware resources page available here. For those already hit by this ransomware, our best guidance right now is to work with law enforcement and incident response experts. Our own incident responders are available 24/7 on the hotline: 1-844-RAPID-IR. Unfortunately - though we really hate to say so - the bottom line here is that if you don't have thorough and timely backups, paying the ransom will need to remain an option for you. See 14:30 PM update for details. Update 13:45 PM EDT: We've confirmed that this ransomworm achieves its initial infection via a malicious document attached to a phishing email, requiring a victim to download and open it (update: see the 16:50 text below). After that, it does indeed use the EternalBlue and DoublePulsar exploits to spread laterally. Unlike WannaCry, though, it is currently using these mechanisms to spread only on internal networks. While this is bad news for compromised organizations, the good news is that the spread directly across the internet is rather limited. The worse news is that there is still plenty of SMB on the internet to go after. Here's a map of the exposed SMB we've generated from some fresh Sonar data: Malware rarely stays static for long, so it's only a matter of time before a variant of this malware is released that uses SMB to spread directly across the internet, just like WannaCry. Update 14:30 PM EDT: Victims of this attack are directed to contact an email address once they've paid the ransom; however, the email account in question has been disabled by the German company that hosts it. Therefore, victims who pay the ransom are reportedly unable to recover their files. More details here. Update 15:30 PM EDT: We've identified the IP addresses 95.141.115.108, 185.165.29.78, 84.200.16.242, and 111.90.139.247 as fine candidates to watch for at your firewall. If you get connection attempts there sources from your internal network, either someone is infected, or someone is monkeying around with live malware samples. Jon Hart goes into more detail on these, and their associated domain names, on this gist. Update 16:50 PM EDT: There have been some reports of Petya-like infections occurring in networks that seemed to lack the initial phishing component. While this might not appear to be possible, there are scenarios where this can seem to happen. First, recall that infected computers actively search their local network for targets vulnerable to the issues addressed in MS17-010. Second, some of these devices are quite mobile, and hop around networks. If my laptop gets popped by this ransomware in my home network at FooCorp, then I take it to my local coffee shop's wifi, and infect someone from BarCom, when that BarCom employee goes back to the office, his incident response people are going to see this race around their network without the phishing email kicking everything off. This is one scenario where the phishing component would not be immediately obvious. There may be more to this malware, though, and our own IR engineers are still running through static and dynamic analysis, so we may have more on how this thing vectors around in the coming hours. Update 18:00 PM EDT: We've confirmed that this ransomware uses a lightly modified version of mimikatz to extract credentials from memory for use in its psexec and WMI vectors for spreading. Mimikatz is a widely-used open source security tool used primarily by security researchers to understand how credential handling is performed in Windows environments. (Thanks, Tim and Mike!) Update 20:15 EDT: For Rapid7 customers, you should be aware that we've already pushed the unique Indicators of Compromise (IOCs) out to all our InsightIDR users, and we've just published a handy HOWTO for InsightVM folks on scanning for MS17-010, which hits the exploit vector being leveraged in this attack. In the meantime, this is a fine time to review your own backup and restore capabilities -- especially the restore part. It seems unlikely we'll have any more updates through the night, but we're still pursuing analysis work. Once we learn anything new, we'll be updating here.

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

National Exposure Index 2017

Today, Rapid7 is releasing the second National Exposure Index, our effort to quantify the exposure that nations are taking on by offering public services on the internet—not just the webservers (like the one hosting this blog), but also unencrypted POP3, IMAPv4, telnet, database servers,…

Today, Rapid7 is releasing the second National Exposure Index, our effort to quantify the exposure that nations are taking on by offering public services on the internet—not just the webservers (like the one hosting this blog), but also unencrypted POP3, IMAPv4, telnet, database servers, SMB, and all the rest. By mapping the virtual space of the internet to the physical space where the machines hosting these services reside, we can provide greater understanding of each nation's internet exposure to both active attack and passive monitoring. Even better, we can point to specific regions of the world where we can make real progress on reducing overall risk to critical internet-connected infrastructure. Measuring Exposure When we first embarked on this project in 2016, we set out to answer some fundamental questions about the composition of the myriad services being offered on the internet. While everyone knows that good old HTTP dominates internet traffic, we knew that there are plenty of other services being offered that have no business being on the modern internet. Telnet, for example, is a decades-old remote administration service that offers nothing in the way of encryption and is often configured with default settings, a fact exploited by the devastating Mirai botnet attacks of last October. But, as security professionals and network engineers, we couldn't say just how many telnet servers were out there. So we counted them. Doing Something About It We know today that there are about 10 million apparent telnet servers on the internet, but that fact alone doesn't do us a lot of good. Sure, it's down 5 million from last year—a 33% drop that can be attributed almost entirely to the Mirai attacks—but this was the result of a disaster that caused significant disruption, not a planned phase-out of an old protocol. So, instead of just reporting that there are millions of exposed, insecure services on the global internet, we can point to specific countries where these services reside. This is far more useful, since it helps the technical leadership in those specific countries get a handle on what their exposure is so they can do something about it. By releasing the National Exposure Index on an annual basis, we hope to track the evolving internet, encourage the wide-scale deployment of more modern, secure, appropriate services, and enable those people in positions of regional authority to better understand their existing, legacy exposure. Mapping Exposure We're pretty pleased with how the report turned out, and encourage you to get a hold of it here. We have also created an interactive, global map so you can cut to the statistics that are most important for you and your region. In addition, we're releasing the data that backs the report—which we gathered using Rapid7's Project Sonar—in case you're the sort who wants to do your own investigation. Scanning the entire internet takes a fair amount of effort, and we want to encourage a more open dialogue about the data we've gathered. You're welcome to head on over to scans.io and pick up our raw scanning data, as well as our GitHub repo of the summary data that went into our analysis. If you'd like to collaborate on cutting this data in new and interesting ways, feel free to drop us a line and we'll be happy to nerd out on all things National Exposure with you.

R7-2016-23, R7-2016-26, R7-2016-27: Multiple Home Security Vulnerabilities

Executive Summary In October of 2016, former Rapid7 researcher Phil Bosco discovered a number of relatively low-risk vulnerabilities and issues involving home security systems that are common throughout the United States, and which have significant WiFi or Ethernet capabilities. The three systems tested were offerings…

Executive Summary In October of 2016, former Rapid7 researcher Phil Bosco discovered a number of relatively low-risk vulnerabilities and issues involving home security systems that are common throughout the United States, and which have significant WiFi or Ethernet capabilities. The three systems tested were offerings from Comcast XFINITY, ADT, and AT&T Digital Life, and the issues discovered ranged from an apparent "fail open" condition on the external door and window sensors, to weak, pre-shared WiFi access passwords, to cleartext communications over the network. Rapid7 has been in touch with all three vendors over the last few months, per our standard disclosure policy, and was involved with both communicating the issues and helping to resolve them in a timely manner. Today, we're happy to report that all of the identified issues have been either resolved or sufficiently mitigated against! In all cases, customers who use these products for home security should not need to apply patches manually or otherwise alter their current system configurations for any software updates, as all vendors have the capability to remotely update any problematic networked components. Before getting into the technical details of the issues discovered, we'd like to state that risk of exploitation of these issues was relatively low before fixes were implemented. In all cases, attackers would have to be reasonably close to the target's residence, and in some cases, be in possession of low-power jamming equipment. Attackers could not exploit these issues from across the Internet. Finally, we also would like to acknowledge ADT, AT&T Digital Life, and Comcast XFINITY for their responsiveness and engagement in discussing, validating and resolving these issues in a timely fashion. Methodology The issues discovered and documented in this advisory were all discovered using standard assessment tools and techniques applied to a single residential installation in the researcher's home, and all equipment was originally installed by authorized technicians. All screenshots, video captures, and other evidence of compromise were collected from the researcher's own systems. It's important to note that the two "Insecure Sensor Fail Open" issues identified as R7-2016-26.1 and R7-2016-27.1 were discovered by using radio frequency (RF) shielding, rather than RF jamming. In a shielded test, the researcher is able to guarantee a failure event on the sensors by physically wrapping the sensors in RF-blocking material, and observing the resulting behavior on on the systems' base stations. In this way, the researcher may be able to simulate a radio interference condition, rather than actually creating one. While shielding has the advantage of creating a more controlled failure event, one shortcoming of this technique is that shielding will not activate any RF interference detection on the base stations, since no detectable RF noise is generated. In short, shielding creates an ideal situation for testing failure conditions, while an active RF jamming event more closely resembles an actual attack. Unfortunately, intentionally creating RF interference, even for the purpose of testing one's own equipment, continues to be a contentious subject in the offensive security testing community, and so shielding is meant as the closest approximation of what low power jamming would do. Vulnerability Overview Below is an overview of the vulnerabilities and exposures discovered during testing. Each vendor's home security platform is explored in turn, along with any recommended remediations or mitigations, as well as a statement provided by the vendor. Again, all vulnerabilities were disclosed and discussed privately with each vendor before publication. Description Vendor R7 ID CVE Status Insecure Sensor Fail Open ADT R7-2016-26.1 CVE-2016-6570 Mitigated by sensor placement Weak WPA2 Pre-Shared Key ADT R7-2016-26.2 CVE-2016-6571 Fixed Cleartext WLAN Communications ADT R7-2016-26.3 CVE-2016-6572 Mitigated by R7-2016-26.2 Insecure Sensor Fail Open AT&T Digital Life R7-2016-27.1 CVE-2016-6573 Mitigated by sensor placement Default physical access administrative credentials AT&T Digital Life R7-2016-27.2 CVE-2016-6574 Fixed Insecure Network Administrative Access AT&T Digital Life R7-2016-27.3 CVE-2016-6575 Mitigated by R7-2016-27.2 Cleartext WLAN Communications AT&T Digital Life R7-2016-27.4 CVE-2016-6576 Mitigated by R7-2016-27.2 Cleartext Credential Storage and Display AT&T Digital Life R7-2016-27.5 CVE-2016-6577 Mitigated by R7-2016-27.2 Weak WPA2 Pre-Shared Key Comcast XFINITY R7-2016-23.1 CVE-2016-6568 Fixed Cleartext WLAN Communications Comcast XFINITY R7-2016-23.2 CVE-2016-6569 Mitigated by R7-2016-23.1 In the cases involving the WiFi networked components, potential attackers would have to be reasonably close to the target's residence and within line-of-sight, and are limited by the signal strength of the attacking equipment. They could not exploit these issues from across the internet, and could not scale these attacks outside of a limited geographic range. In the cases of creating RF interference to cause external door and window sensors to go offline, the attacker would need to carefully modulate their interference signal strength in order to avoid triggering anti-jamming detection technologies already provided by the vendor. Triggering these detection mechanisms would cause an alert to be sent to the vendor's normal monitoring systems. In addition, onsite motion sensors installed as part of the complete security system would either be wired – and thus immune to radio frequency interference – or wireless, which would make it extremely difficult to jam both an external sensor and an internal sensor yet still avoid triggering anti-jamming detection. In cases of the cleartext transmission vulnerabilities and exposures documented in this advisory, these are dependent on other vulnerabilities being exploited first. For example, if an attacker finds it impossible to associate to the network, it is immaterial (practically speaking) that the communications over that WiFi network are themselves in the clear, as all of the home security WiFi networks employ industry-standard encryption provided by WiFi Protected Access II (WPA2). That said, a defense-in-depth posture is usually recommended for networks that carry sensitive information, so that a failure in one component does not expose the entire network and its assets to compromise. R7-2016-26: ADT Home Security Three issues were identified with ADT's home security solution: Exterior sensors appear to fail open when RF transmissions are blocked; systems were installed with a weak, pre-shared WPA2 key for authentication to the wireless network; and cleartext communications on that network. A failure condition in the 908.42 MHz radio frequency band will cause the system to fail open, and the base system will fail to report a communications failure with the associated devices. In addition, due to a weak, pre-shared key shipping with the WiFi access point component of the product, an attacker can rapidly compromise the network on which the security cameras communicate. Finally, all communications to and from the security cameras are conducted in the clear. Once an attacker is associated with the WiFi network, it is possible to capture the administrative credentials to the camera and the provided access point's administrative credentials. R7-2016-26.1: ADT Insecure Sensor Fail Open (CVE-2016-6570) A failure condition in the sensor's RF band can cause the system to fail open, and the base system may fail to report a communications failure with the associated devices. Exploiting the insecure fail open issue can be accomplished with commodity RF jammers. Failing Open In order to cause the system to fail open, an attacker would need to block communication in the sensor's RF band. While jamming devices are illegal to operate in the US, they are relatively easy to buy or build using commodity electronics equipment. This issue is essentially identical to R7-2015-23: Comcast XFINITY Home Security System Insecure Fail Open, and those details are immediately applicable in this case. For testing purposes, jamming was simulated by physically shielding the devices to effectively block all radio communications. Remediation The RF jamming attack can be mitigated by two shipping solutions. One, the system's base station is equipped with interference detection, so an attacker would need to ensure that any jamming signal has sufficient power to effectively block communication from the exterior sensor, but not so much power as to be detected by the base station. Two, many of ADT's home security systems are installed with interior, wired motion sensors. Because these sensors do not rely on RF communications, they are effectively immune to this attack, and therefore, any movement after jamming the exterior sensor will be alerted on by these motion sensors. In the case where interior motion sensors are wireless, again, the attacker would need to ensure that jamming is sufficient to block both the exterior sensor and the interior motion sensor, but not the base station. Such an attack would be extremely tricky to implement, require physical reconnaissance in order to plan the attack, and may be impossible depending on the placement of the base station and interior motion sensors. R7-2016-26.2: ADT Weak WPA2 Pre-Shared Key (CVE-2016-6571) Exploiting the weak WPA2 pre-shared key (PSK) can be accomplished with a WiFi deauthentication and offline cracking attack. Deauthentication First, an attacker would locate the ADT gear, using standard tools such as the Aircrack-NG WiFi security assessment toolkit. Figure 1 demonstrates the use of airodump-ng<span>.</span> Once identified, the attacker can then deauthenticate one of the cameras, as shown in Figure 2. Doing this allows the attacker to capture the WPA2 handshake, which is then subjected to cracking with Aircrack-ng, as shown in Figure 3. Because the vendor-supplied password is exactly thirteen characters, consisting only of numbers, it generally does not take very much time to crack with typical consumer-grade hardware. Remediation The vendor updated all components of customers' WiFi networks with a more complex generated password during the first quarter of 2017. R7-2016-26.3: ADT Cleartext WLAN Communications (CVE-2016-6572) Exploiting the cleartext communications can be achieved once the attacker is associated with the special-purpose WiFi network, and can provide an attacker with administrative credentials and direct camera feeds. Camera Credential Collection Once the attacker recovers the WPA2 pre-shared key, they can then connect to the device network and capture a camera's credentials via a brief ARP spoofing attack and posing as the base station. This is shown in Figure 4. The attacker can then reuse these credentials to log in the cameras directly and access live video feeds, as seen in Figure 5. Remediation The upgraded password complexity implemented as a solution R7-2016-26.2 makes associating to the WiFi network difficult to impossible, and thus, effectively mitigates the malicious use of cleartext communications on the WPA2 WiFi network. R7-2016-27: AT&T Digital Life Home Security Five issues were identified with AT&T Digital Life's home security solution: exterior sensors appear to fail open when RF transmissions are blocked; physical network access is governed by an easily-guessed default administrative credential; network administrative access does not challenge for a credential; the WiFi network uses cleartext communications; and saved credentials are stored and displayed in cleartext. AT&T Digital Life's home security systems ship with a base station, window and door sensors, motion sensors, wireless cameras, and a mobile app, as described by the vendor. A failure condition in the 433.92 MHz radio frequency band used by AT&T Digital Life's third party home security equipment can cause the system to fail open, and the base system may fail to report a communications failure with the associated devices. WiFi access control appears to be sufficient and reasonable, since the WPA2 network is secured with a 32-character password made up of uppercase, lowercase, and numeric characters. Due to an installation error, access to this network can be accomplished via a physically accessible LAN Ethernet port to the base station, and access to the shipped Cisco management interface is controlled by easily-guessed default credentials. Since the time of this discovery, AT&T Digital Life has updated their installation procedures to ensure that this LAN Ethernet port is disabled after initial setup on customer sites. R7-2016-27.1: AT&T Digital Life Insecure Sensor Fail Open (CVE-2016-6573) A failure condition in the sensor's RF band can cause the system to fail open, and the base system may fail to report a communications failure with the associated devices. Exploiting the insecure fail open issue can be accomplished with commodity RF jammers. Failing Open In order to cause the system to fail open, an attacker would need to block communication in the sensor's RF band. While jamming devices are illegal to operate in the US, they are relatively easy to buy or build using commodity electronics equipment. This issue is essentially identical to R7-2015-23: Comcast XFINITY Home Security System Insecure Fail Open, and those details are immediately applicable in this case. For testing purposes, jamming was simulated by physically shielding the devices to effectively block all radio communications. It should be noted that AT&T does not believe that jamming (unlike shielding) can be performed without triggering certain anti-jamming alerts. Remediation The RF jamming attack can be mitigated by two shipping solutions. One, the system's base station is equipped with interference detection, so an attacker would need to ensure that any jamming signal has sufficient power to effectively block communication from the exterior sensor, but not so much power as to be detected by the base station. Two, AT&T Digital Life's home security systems are typically installed with at least one interior, wireless motion sensor. In this case, the attacker would need to ensure that jamming is sufficient to block both the exterior sensor and the interior motion sensor, but not the base station. Depending on the placement of the interior motion sensor, such an attack could be extremely tricky to implement, since it would require physical reconnaissance in order to plan the attack, and may be impossible depending on the relative placement of the base station and interior motion sensors. R7-2016-27.2: AT&T Digital Life Default physical access administrative credentials (CVE-2016-6574) If an attacker is able to physically access the base station and connect to an enabled Ethernet port, access to an administrative interface is possible. Physical-Only Administrative Access Assuming an attacker can physically connect to the base station via an Ethernet port, they can connect to an administrative web service on the default gateway (http://192.168.29.1:80) and provide the easily-guessed login credentials of "admin:admin." From here, the attacker has complete administrative control over the device and can learn the WiFi SSID and pre-shared key. This key would be difficult to impossible to crack in an offline deauthentication attack, since it is a complex, 32-character string. However, once physical access is achieved and the administrative interface is loaded in a browser, the key is displayed to the logged-in attacker. Remediation During testing, disabling the Ethernet diagnostic port was a manual step that field technicians could accidentally skip, and that appears to have been the case during the installation at the researcher's residence. Since this report, AT&T Digital Life has thoroughly reviewed its automatic post-installation verification procedures, and now ensures that every installation of its home security system does, in fact, disable the physical Ethernet port. Disabling this port does not require an on-premises visit, and can be achieved remotely by AT&T Digital Life. It is impossible to enable this port locally; field technicians must activate this port with an authenticated service call. R7-2016-27.3: AT&T Digital Life Insecure Network Administrative Access (CVE-2016-6575) If it is possible to learn the WPA2 pre-shared key, other administrative interfaces become available to the attacker over the local WiFi network. Port 8090 Once the attacker is associated with the WiFi network, he can then connect to the administrative web interface for the system, which is listening on port 8090/TCP. This interface does not challenge for authentication credentials, and from this interface, the attacker can add or remove devices, cameras and keypads, and can also disarm any alarm-related functionality, as shown below. Remediation As there is no reasonable way for an attacker to perform an offline bruteforce attack on the WPA2 key due to the strength of this pre-generated key, physical access is required as well as access to an active, administrative Ethernet LAN port. Therefore, due to remediations provided in R7-2016-27.1 and R7-2016-27.2 described above, this attack vector is effectively mitigated. R7-2016-27.4: AT&T Digital Life Cleartext WLAN Communications (CVE-2016-6576) If an attacker can achieve wireless administrative access, credentials can be learned through ARP spoofing. Camera Credential Collection Once the attacker recovers the WPA2 pre-shared key, he can then connect to the device network, and capture a camera's credentials via a brief ARP spoofing attack and posing as the base station. This is shown in Figure 9. Remediation As with R7-2016-27.3 above, the remediations provided for R7-2016-27.2 effectively mitigate this attack, since the attacker can no longer learn the WPA2 pre-shared key. R7-2016-27.5: AT&T Digital Life Cleartext Credential Storage and Display (CVE-2016-6577) If an attacker can achieve wireless administrative access, credentials can be learned directly from associated devices. These credentials can be discovered without ARP spoofing by accessing the administration web page on port 8090, since it is displayed in cleartext, as shown in Figure 10. Remediation As with R7-2016-27.3 and R7-2016-27.4 above, the remediations provided for R7-2016-27.2 effectively mitigate this attack, since the attacker can no longer learn the WPA2 pre-shared key. R7-2016-23: Comcast XFINITY Home Security A certain generation of Comcast XFINITY's Home Security product was found to utilize a weak algorithm to generate its per-premise WPA2 security key. While a sufficiently random WPA2 key cannot be bruteforced, the weak keys generated by the algorithm in question could be bruteforced in one to two months on average with commodity hardware, giving a physically-proximate and persistent attacker access to the WiFi network over which the touchscreen and cameras communicate. Once the attacker achieved access to the network, they could have captured administrative credentials to the camera and the access point, which are sent in the clear between the touchscreen and these two devices. Finally, it was noticed that the URLs used to view camera feeds were not protected by session authentication. While session-controlled access to individual feeds is a more standard approach to securing video streams, the URLs were randomized with a sufficient (128-bit) keyspace to prevent live brute-forcing. Access is conducted over HTTPS, and the URLs are periodically regenerated. After discussing this approach with Comcast XFINITY and CERT/CC, we came to the conclusion that this implementation does not present any practical security concerns. Nonetheless, Comcast XFINITY agreed with our suggestion and has since implemented session authentication as an additional layer of security. R7-2016-23.1: Comcast XFINITY Weak WPA2 Pre-Shared Key (CVE-2016-6568) Exploiting the weak WPA2 PSK can be accomplished with a WiFi deauthentication and offline cracking attack. Deauthentication First, an attacker would locate the Comcast XFINITY gear, using standard tools such as the Aircrack-NG WiFi security assessment toolkit. Figure 11 demonstrates the use of airodump-ng: Once identified, the attacker can then deauthenticate one of the cameras, as shown in Figure 12: Doing this allows the attacker to capture the WPA2 handshake, which is then cracked using aircrack-ng, as shown in Figure 13: Because the vendor-supplied password is exactly eight characters, consisting of uppercase letters and numbers, it is quite feasible to crack this password with typical consumer-grade hardware. Remediation The vendor has updated all components of customers' WiFi networks with a much longer, mixed-character password, during a staged rollout across all installations throughout the first quarter of 2017. R7-2016-23.2: Comcast XFINITY Cleartext WLAN Communications (CVE-2016-6569) Exploiting the cleartext communications can be achieved once the attacker is associated with the special-purpose WiFi network, and can provide an attacker with administrative credentials. Camera Credential Collection Once the attacker recovers the WPA2 pre-shared key, they can then connect to the device network and capture a camera's credentials via a brief ARP spoofing attack and posing as the base station. This is shown in Figure 14. The attacker can then reuse these credentials to log in the camera base station, and access live video feeds. An example taken from the researcher's camera is shown in Figure 15. Router Credential Collection Both the administrative touch screen and the cameras log into the WiFi router periodically to check for firmware updates. By ARP spoofing the router interface, the router's administrative credentials can also be collected. This is shown in Figure 16. Once administrative router access is secured, the attacker can perform all normal administrative functions, such as providing a malicious firmware update or redirecting DNS traffic to a name server controlled by the attacker, as seen in Figure 17. Remediation The upgraded password complexity implemented as a solution to R7-2016-23.1 makes associating to the WiFi network difficult to impossible, and thus effectively mitigates the malicious use of cleartext communications on the WPA2 WiFi network. Vendor Statement on R7-2016-23 Our customers' safety and security is our top priority.  We have developed and deployed fixes for the issues reported by Rapid7, which they identified as low-risk. For the vast majority of affected customers, these issues are fully mitigated. A small number of XFINITY Home customers need to make manual updates, and we are contacting those customers by email and/or phone. At XFINITY Home, we regularly perform stringent information security testing of our products, both before and after we launch them.  However, no product can ever be completely free of security vulnerabilities, and experts intent on hacking into any system will discover vulnerabilities.  So another way we maintain our customers' trust is by responding quickly and effectively to reported vulnerabilities. We are grateful to Rapid7 security researcher Phil Bosco and research director Tod Beardsley for responsibly disclosing these vulnerabilities to us.  While Rapid7 identified these issues as low risk, XFINITY Home moved quickly to remediate them. Credit All of the issues described in this vulnerability disclosure were discovered by former Rapid7 researcher Phil Bosco and disclosed by Rapid7 according to our standard disclosure policy. Disclosure Timeline R7-2016-26 (ADT) Wed, Oct 26, 2016: Vendor contacted Fri, Oct 28, 2016: Disclosed details to the vendor Wed, Nov 09, 2016: Discussed details with the vendor Fri, Nov 18, 2016: Disclosed details to CERT/CC Mon, Nov 21, 2017: CERT/CC assigned CVE-2016-6570, CVE-2016-6571, and CVE-2016-6572 Fri, Jan 27, 2017: Discussed vendor's plans for remediation Thu, Mar 16, 2017: Vendor confirmed remediation is on track Fri, Apr 28, 2017: Further clarification from the vendor on mitigations (ongoing through May) Wed, May 17, 2017: Public disclosure of R7-2016-26. R7-2016-27 (AT&T Digital Life) Wed, Oct 26, 2016: Vendor contacted Mon, Nov 07, 2016: Details disclosed to the vendor Wed, Nov 09, 2016: Discussed details with the vendor Fri, Nov 18, 2016: Disclosed details to CERT/CC Mon, Nov 21, 2017: CERT/CC assigned CVE-2016-6573, CVE-2016-6574, CVE-2016-6575, CVE-2016-6576, and CVE-2016-6577 Thu, Jan 12, 2017: Clarified fixes and mitigations with the vendor Tue, Mar 28, 2017: Further clarifications on disclosure content with the vendor (ongoing through May) Wed, May 17, 2017: Public disclosure of R7-2016-27. R7-2016-23 (Comcast XFINITY) Wed, Oct 26, 2016: Vendor contacted Fri, Oct 28, 2016: Disclosed details to the vendor Tue, Nov 08, 2016: Discussed details with the vendor Fri, Nov 18, 2016: Disclosed details to CERT/CC Mon, Nov 21, 2017: CERT/CC assigned CVE-2016-6568 and CVE-2016-6569 Fri, Jan 27, 2017: Discussed vendor's plans for remediation Thu, Mar 16, 2017: Vendor confirmed remediation is on track (ongoing through May) Thu, Mar 16, 2017: Vendor also implemented session controls for video URLs Wed, May 17, 2017: Public disclosure of R7-2016-23.

R7-2017-02: Hyundai Blue Link Potential Info Disclosure (FIXED)

Summary Due to a reliance on cleartext communications and the use of a hard-coded decryption password, two outdated versions of Hyundai Blue Link application software, 3.9.4 and 3.9.5 potentially expose sensitive information about registered users and their vehicles, including application usernames,…

Summary Due to a reliance on cleartext communications and the use of a hard-coded decryption password, two outdated versions of Hyundai Blue Link application software, 3.9.4 and 3.9.5 potentially expose sensitive information about registered users and their vehicles, including application usernames, passwords, and PINs via a log transmission feature. This feature was introduced in version 3.9.4 on December 8, 2016, and removed by Hyundai on March 6, 2017 with the release of version 3.9.6. Affected versions of Hyundai Blue Link mobile application upload application logs to a static IP address over HTTP on port 8080. The log is encrypted using a symmetrical key, "1986l12Ov09e", which is defined in the Blue Link application (specifically, C1951e.java), and cannot be modified by the user. Once decoded, the logs contain personal information, including the user's username, password, PIN, and historical GPS data about the vehicle's location. This information can be used to remotely locate, unlock and start the associated vehicle. This vulnerability was discovered by Will Hatzer and Arjun Kumar, and this advisory was prepared in accordance with Rapid7's disclosure policy. Product Description The Blue Link app is compatible with 2012 and newer Hyundai vehicles. The functionality includes remote start, location services, unlocking and locking associated automobiles, and other features, documented at the vendor's web site. Credit This vulnerability was discovered by independent researchers William Hatzer and Arjun Kumar. Exploitation for R7-2017-02 The potential data exposure can be exploited one user at a time via passive listening on insecure WiFi, or by standard man-in-the-middle (MitM) attack methods to trick a user into connecting to a WiFi network controlled by an attacker on the same network as the user. If this is achieved, an attacker would then watch for HTTP traffic directed at an HTTP site at 54.xx.yy.113:8080/LogManager/LogServlet, which includes the encrypted log file with a filename that includes the user's email address. It would be difficult to impossible to conduct this attack at scale, since an attacker would typically need to first subvert physically local networks, or gain a privileged position on the network path from the app user to the vendor's service instance. Vendor Statement Hyundai Motor America (HMA) was made aware of a vulnerability in the Hyundai Blue Link mobile application by researchers at Rapid7. Upon learning of this vulnerability, HMA launched an investigation to validate the research and took immediate steps to further secure the application. HMA is not aware of any customers being impacted by this potential vulnerability. The privacy and security of our customers is of the utmost importance to HMA. HMA continuously seeks to improve its mobile application and system security. As a member of the Automotive Information Sharing Analysis Center (Auto-ISAC), HMA values security information sharing and thanks Rapid7 for its report. Remediation On March 6, 2017, the vendor updated the Hyundai Blue Link app to version 3.9.6, which removes the LogManager log transmission feature. In addition, the TCP service at 54.xx.yy.113:8000 has been disabled. The mandatory update to version 3.9.6 is available in both the standard Android and Apple app stores. Disclosure Timeline Tue, Feb 02, 2017: Details disclosed to Rapid7 by the discoverer. Sun, Feb 19, 2017: Details clarified with the discoverer by Rapid7. Tue, Feb 21, 2017: Rapid7 attempted contact with the vendor. Sun, Feb 26, 2017: Vendor updated to v3.9.5, changing LogManager IP and port. Mon, Mar 02, 2017: Vendor provided a case number, Consumer Affairs Case #10023339 Mon, Mar 06, 2017: Vendor responded, details discussed. Mon, Mar 06, 2017: Version 3.9.6 released to the Google Play store. Wed, Mar 08, 2017: Version 3.9.6 released to the Apple App Store. Wed, Mar 08, 2017: Details disclosed to CERT/CC by Rapid7, VU#152264 assigned. Wed, Apr 12, 2017: Details disclosed to ICS-CERT by Rapid7, ICS-VU-805812 assigned. Fri, Apr 21, 2017: Details validated with ICS-CERT and HMA, CVE-2017-6052 and CVE-2017-6054 assigned. Tue, Apr 25, 2017: Public disclosure of R7-2017-02 by Rapid7. Tue, Apr 25, 2017: ICSA-17-115-03 published by ICS-CERT. Fri, Apr 28, 2017: Redacted the now-disabled IP address for the LogManager IP address.

Metasploit, [REDACTED] Edition

Why should [REDACTED] have all the fun with spiffy codenames for their exploits? As of today, Metasploit is taking a page from [REDACTED], and equipping all Metasploit modules with equally fear-and-awe-inspiring codenames. Sure, there are catchy names for vulnerabilities -- we remember you fondly, Badblock…

Why should [REDACTED] have all the fun with spiffy codenames for their exploits? As of today, Metasploit is taking a page from [REDACTED], and equipping all Metasploit modules with equally fear-and-awe-inspiring codenames. Sure, there are catchy names for vulnerabilities -- we remember you fondly, Badblock -- but clearly, unique names for exploits is where the real action is at, especially when you're [REDACTED][REDACTED][REDACTED][REDACTED][REDACTED]. So, instead of running boring old exploit/windows/smb/ms08_067_netapi, now you can don your onyx tactleneck, and use CRISPYTRUFFLE like the international man of mystery that you are. Need to scan for telnet banners? Sure, you could use auxiliary/scanner/telnet/telnet_version, like some kind of civilian, or you can be a shadowy puppetmaster and unleash the awesome power of HIDDENBOYFRIEND. Or, maybe you're looking to deploy one of Metasploit's payloads as a standalone executable, given to your operative in the field. Once you've lost your tail and met your contact in a darkened, rain-slicked alley, you can hand off a USB key loaded up with VENGEFULPONY, and trust he'll do what it takes to get back across the border. In order to enable these ultra-top-secret codenames, you'll need to run a fresh checkout of the development version of the Metasploit Framework. If you're on one of the binary versions of Metasploit, they'll be getting these codenames as well, so you can check if they're available by setting the environment variable DANGERZONE, like so: $ DANGERZONE=1 ./msfconsole -q msf > use CRISPYTRUFFLE msf exploit(ms08_067_netapi) > So take a moment today, April 1st, to read yourself into [REDACTED] by visiting http://www.5z8.info/eid-howto_j0b9mh_openme.exe. Make sure you're behind at least seven proxies when you do so, since [REDACTED] is probably watching.

R7-2016-28: Multiple Eview EV-07S GPS Tracker Vulnerabilities

Seven issues were identified with the Eview EV-07S GPS tracker, which can allow an unauthenticated attacker to identify deployed devices, remotely reset devices, learn GPS location data, and modify GPS data. Those issues are briefly summarized on the table below. These issues were discovered by…

Seven issues were identified with the Eview EV-07S GPS tracker, which can allow an unauthenticated attacker to identify deployed devices, remotely reset devices, learn GPS location data, and modify GPS data. Those issues are briefly summarized on the table below. These issues were discovered by Deral Heiland of Rapid7, Inc., and this advisory was prepared in accordance with Rapid7's disclosure policy. Vulnerability Description R7 ID CVE Exploit Vector Unauthenticated remote factory reset R7-2016-28.1 CVE-2017-5237 Phone number Remote device identification R7-2016-28.2 None (identification) Phone number range Lack of configuration bounds checks R7-2016-28.3 CVE-2017-5238 Phone number Unauthenticated access to user data R7-2016-28.4 None (server-side issue) Web application Authenticated user access to other users' data R7-2016-28.5 None (server-side issue) Web application user account Sensitive information transmitted in cleartext R7-2016-28.6 CVE-2017-5239 Man-in-the-Middle (MitM) Network Web application data poisoning R7-2016-28.7 None (server-side issue) Web application Product Description The EV-07S is a personal GPS tracker device used for personal safety and security, described at the vendor's website as being primarily intended for tracking elderly family members; disabled and patient care; child protection; employee management; and pet and animal tracking. Test devices were acquired from Eview directly, and an example is shown below in Figure 1. R7-2016-28.1: Unauthenticated remote factory reset## Given knowledge of the EV-07S's registered phone number, the EV-07S device can be reset to factory level setting by sending "RESET!" as a command in an SMS message to the device. Only the phone number is required; no password or physical access is required to accomplish this task. After a factory reset, the device can then be reconfigured remotely via SMS messages without need of password. The product manual states this functionality, so it appears to be a fundamental design flaw with regard to secure configuration. Mitigation for R7-2016-28.1 A vendor-supplied patch should prevent the device from allowing unauthenticated factory reset without having physical access to the device. Absent a patch, users should regularly check their device to ensure the configuration has not be deleted or altered. R7-2016-28.2: Remote device identification The EV-07S device, once set up with a password, should not respond to any SMS queries sent to the device's phone number. According to the user manual, no password is needed to send "reboot" and "RESET!" commands to the device. Testing showed, in spite of user manual statement, that the "reboot" command required a password if device is set up for authentication. Further manual fuzzing test via SMS reveled that the command "REBOOT!" will cause the device to respond with the message "Format error!". Due to providing this negative response, a malicious actor could use this command to enumerate all devices by trying all likely phone numbers, commonly known as a war dialing operation, using SMS messages containing the "REBOOT!" command. Mitigation for R7-2016-28.2 A vendor-supplied patch should disable the response from the "REBOOT!" command when password protection is enabled. R7-2016-28.3: Lack of configuration bounds checks Several input configuration fields were discovered to not be performing proper bounds checks on incoming SMS messages. If a device's phone number is known to an attacker, this lack of bounds checking allows the overly long input of one configuration setting to overwrite data of another setting. An example of this is shown in Figure 3, where the "Authorized Number" setting A1 is used to overwrite setting B1: Mitigation for R7-2016-28.3 A vendor-supplied patch should implement bounds checks and input sanitization on all entered configuration data. Absent a vendor-supplied patch, users should be mindful of entering any values of excessive length. In the case with Authorized Number setting anything over 20 characters will overwrite the next setting in line. R7-2016-28.4: Unauthenticated access to user data A malicious actor can gain access to user data including account name, TrackerID and device IMEI id. This is done by posting userId=**5XXXX**&trackerName=&type=allTrackerswith a the target's userID number to the API.  An example of this shown below in Figure 4: Given the small keyspace involved with guessing valid user IDs of 5 digits, it appears trivial to determine all valid user IDs. Mitigation for R7-2016-28.4 A vendor-supplied patch on the vendor web application should prevent unauthenticated access to individual user data. Absent a vendor-supplied patch, users should be careful when trusting the realtime tracking services with their device. R7-2016-28.5: Authenticated access to other users' data An authenticated user can gain access to others users configuration and device GPS data if they know or guess a valid userId, device IMEI or TrackerID. The following three examples (Figures 5 through 7) show this level of access from one authenticated account being able to access another account's data. Mitigation for R7-2016-28.5 A vendor-supplied patch should prevent access to other users data. Absent a vendor-supplied patch, users should be careful when trusting the realtime tracking services with their device. R7-2016-28.6:  Sensitive information transmitted in cleartext The web application used for realtime tracking web application, hosted at http://www.smart-tracking.com , does not utilize SSL/TLS encryption for HTTP services. Also the EV-07S device passes IMEI and GPS data to this website over the Internet on TCP port 5050 without any encryption. An example of this captured unencrypted data is show below in Figure 8: Mitigation for R7-2016-28.6 A vendor-supplied patch on both the server and the client should enable encrypted transfer of data to website, as well as an update of the website to enable HTTPS service and serve these pages only over HTTPS. Absent a vendor-supplied patch, users should be careful when trusting the realtime tracking services with their device. R7-2016-28.7:  Data poisoning An unauthenticated attacker can poison the realtime tracking data by injecting device data similar to the data structure shown above in Figure 8 to the server at www.smart-tracking.com over TCP port 5050. The attacker can do this only if they know a device's IMEI number, but that data is learnable through mechanisms described above. An example of this is shown in Figure 9, where the device's realtime tracking data was poisoned to make the device appear to be Moscow, Russia (it was not). Mitigation for R7-2016-28.7 A vendor-supplied patch should enable authentication before allowing device data to be posted to the site on TCP port 5050. Absent a vendor-supplied patch, users should be careful when trusting the realtime tracking services with their device. Disclosure Timeline Mon, Dec 12, 2016: Initial contact made to the vendor. Tue, Dec 20, 2016: Vendor responded and details provided to info@eviewltd.com. Tue, Dec 27, 2016: Disclosure to CERT/CC, VU#375851 assigned. Wed, Mar 08, 2017: CVEs assigned in conjunction with CERT/CC. Mon, Mar 27, 2017: Vulnerability disclosure published.

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.

Multiple Vulnerabilities Affecting Four Rapid7 Products

Today, we'd like to announce eight vulnerabilities that affect four Rapid7 products, as described in the table below. While all of these issues are relatively low severity, we want to make sure that our customers have all the information they need to make informed security…

Today, we'd like to announce eight vulnerabilities that affect four Rapid7 products, as described in the table below. While all of these issues are relatively low severity, we want to make sure that our customers have all the information they need to make informed security decisions regarding their networks. If you are a Rapid7 customer who has any questions about these issues, please don't hesitate to contact your customer success manager (CSM), our support team, or leave a comment below. For all of these vulnerabilities, the likelihood of exploitation is low, due to an array of mitigating circumstances, as explained below. Rapid7 would like to thank Noah Beddome, Justin Lemay, Ben Lincoln (all of NCC Group); Justin Steven; and Callum Carney - the independent researchers who discovered and reported these vulnerabilities, and worked with us on pursuing fixes and mitigations. Rapid7 ID CVE Product Vulnerability Status NEX-49834 CVE-2017-5230 Nexpose Hard-Coded Keystore Password Fixed (6.4.50-2017-0809) MS-2417 CVE-2017-5228 Metasploit stdapi Dir.download() Directory Traversal Fixed (4.13.0-2017020701) MS-2417 CVE-2017-5229 Metasploit extapi Clipboard.parse_dump() Directory Traversal Fixed (4.13.0-2017020701) MS-2417 CVE-2017-5231 Metasploit stdapi CommandDispatcher.cmd_download() Globbing Directory Traversal Fixed (4.13.0-2017020701) PD-9462 CVE-2017-5232 Nexpose DLL Preloading Fixed (6.4.24) PD-9462 CVE-2017-5233 AppSpider Pro DLL Preloading Fix in progress (6.14.053) PD-9462 CVE-2017-5234 Insight Collector DLL Preloading Fixed (1.0.16) PD-9462 CVE-2017-5235 Metasploit Pro DLL Preloading Fixed (4.13.0-2017022101) CVE-2017-5230: Rapid7 Nexpose Static Java Keystore Passphrase Cybersecurity firm NCC Group discovered a design issue in Rapid7's Nexpose vulnerability management solution, and has released an advisory with the relevant details here. This section briefly summarizes NCC Group's findings, explains the conditions that would need to be met in order to successfully exploit this issue, and offers mitigation advice for Nexpose users. Conditions Required to Exploit One feature of Nexpose, as with all other vulnerability management products, is the ability to configure a central repository of service account credentials so that a VM solution can login to networked assets and perform a comprehensive, authenticated scan for exposed, and patched, vulnerabilities. Of course, these credentials tend to be sensitive, since they tend to have broad reach across an organization's network, and care must be taken to store them safely. The issue identified by NCC Group revolves around our Java keystore for storing these credentials, which is encrypted with a static, vendor-provided password, "r@p1d7k3y5t0r3." If a malicious actor were to get a hold of this keystore, that person could use this password to decrypt and expose all stored scan credentials. While this is not obviously documented, this password is often known to Nexpose customers and Rapid7 support engineers, since it's used in some backup recovery scenarios. This vulnerability is not likely to offer an attacker much of an advantage however, since they would need to already have extraordinary control over your Nexpose installation in order to exercise it. This is because you need high level privileges to be able to actually get hold of the keystore that contains the stored credentials. So, in order to obtain and decrypt this file, an attacker would need to already have at least root/administrator privileges on the server running the Nexpose console, OR have a Nexpose console "Global Administrator" account, OR have access to a backup of a Nexpose console configuration. If the attacker already has root on the Nexpose console, the jig is up; customers are already advised to restrict access to Nexpose servers through normal operating system and network controls. This level of access would already represent a serious security incident, since the attacker would have complete control over the Nexpose services and could leverage one of any number of techniques to extend privileges to other network assets, such as conducting local man-in-the-middle network monitoring, local memory profiling, or other, more creative techniques to increase access. Similarly, Global Administrator access to the Nexpose console would, at minimum, allow an attacker to obtain a list of every vulnerable system in scope, alter or skip scheduled scans, and create new and malicious custom scan templates. That leaves Nexpose console backups, which we believe represents the most likely attack vector. Sometimes, backups of critical configurations are stored in networked locations that aren't as secure as the backed-up system itself. We advise against this, for obvious reasons; if backups are not secured at least as well as the Nexpose server itself, it is straightforward to restore the backup to a machine under the attacker's control (where he would have root/administrator), and proceed to leverage that local privilege as above. Designing a Fix While encrypting these credentials at rest is clearly important for safety's sake, eventually these credentials do have to be decrypted, and the key to that decryption has to be stored somewhere. After all, the whole point of a scheduled, authenticated scan is to automate logins. Storing that key offline, in an operator's head, means having to deal with a password prompt anytime a scan kicks off. This would be a significant change in how the product works, and would be a change for the worse. Designing a workable fix to this exposure is challenging. The simple solution is to enable users to pick their own passwords for this keystore, or generate one per installation. This would at least force attackers who have gained access to critical network infrastructure to do the work of either cracking the saved keystore, or do the slightly more complicated work of stepping through the decryption process as it executes. Unfortunately, this approach would immediately render existing backups of the Nexpose console unusable -- a fact that tends to only be important at the least opportune time, after a disaster has taken out the hosting server. Given the privilege requirements of the attack, this trade-off, in our opinion, isn't worth the future disaster of unrestorable backups. While we do expect to implement a new strategy for encrypting stored credentials in a future release, care will need to be taken to both ensure that the customer experience with disaster recovery remains the same and support costs aren't unreasonably impacted by this change. Mitigations for CVE-2017-5320 As of August of 2017, a fixed version has been released. CVE-2017-5228, CVE-2017-5229, CVE-2017-5231: Metasploit Meterpreter Multiple Directory Traversal Issues Metasploit Framework contributor and independent security researcher Justin Steven reported three issues in the way Metasploit Meterpreter handles certain directory structures on victim machines, which can ultimately lead to a directory traversal issue on the Meterpreter client. Justin reported his findings in an advisory, here. Conditions Required to Exploit In order to exploit this issue, we need to first be careful when discussing the "attacker" and "victim." In most cases, a user who is loading and launching Meterpreter on a remote computer is the "attacker," and that remote computer is the "victim." After all, few people actually want Meterpreter running on their machine, since it's normally delivered as a payload to an exploit. However, this vulnerability flips these roles around. If a computer acts as a honeypot, and lures an attacker into loading and running Meterpreter on it, that honeypot machine has a unique opportunity to "hack back" at the original Metasploit user by exploiting these vulnerabilities. So, in order for an attack to be successful, the attacker, in this case, must entice a victim into establishing a Meterpreter session to a computer under the attacker's control. Usually, this will be the direct result of an exploit attempt from a Metasploit user. Designing a Fix Justin worked closely with the Metasploit Framework team to develop fixes for all three issues. The fixes themselves can be inspected in the open source Metasploit framework repository, at Pull Requests 7930, 7931, and 7932, and ensure that data from Meterpreter sessions is properly inspected, since that data can possibly be evil. Huge thanks to Justin for his continued contributions to Metasploit! Mitigations for CVE-2017-5228, CVE-2017-5229, CVE-2017-5230 In addition to updating Metasploit to at least version 4.3.20, Metasploit users can help protect themselves from the consequences of interacting with a purposefully malicious host with the use of Meterpreter's "Paranoid Mode," which can significantly reduce the threat of this and other undiscovered issues involving malicious Meterpreter sessions. CVE-2017-5232, CVE-2017-5233, CVE-2017-5234, CVE-2017-5235: DLL Preloading Independent security researcher Callum Carney reported to Rapid7 that the Nexpose and AppSpider installers ship with a DLL Preloading vulnerability, wherein an attacker could trick a user into running malicious code when installing Nexpose for the first time. Further investigation from Rapid7 Platform Delivery teams revealed that the installation applications for Metasploit Pro and the Insight Collector exhibit the same vulnerability. Conditions Required to Exploit DLL Preloading vulnerabilities are well described by Microsoft, here, but in short, DLL preloading vulnerabilities occur when a program fails to specify an exact path to a system DLL; instead, the program can seek that DLL in a number of default system locations, as well as the current directory. In the case of an installation program, that current directory may be a general "Downloads" folder, which can contain binaries downloaded from all sorts of places. If an attacker can convince a victim to download a malicious DLL, store it in the same location as one of the Rapid7 installers identified above, and then install one of those applications, the victim can trigger the vulnerability. In practice, DLL preloading vulnerabilities occur more often on shared workstations, where the attacker specifically poisons the Downloads directory with a malicious DLL and waits for the victim to download and install an application susceptible to this preloading attack. It is also sometimes possible to exercise a browser vulnerability to download (but not execute) an arbitrary file, and again, wait for the user to run an installer later. In all cases, the attacker must already have write permissions to a directory that contains the Rapid7 product installer. Usually, people only install Rapid7 products once each per machine, so the window of exploitation is also severely limited. Designing a Fix In the case of Metasploit Pro, Nexpose, and the Insight Collector, the product installers were updated to define exactly where system DLLs are located, and no longer rely on dynamic searching for missing DLLs. An updated installer for Appspider Pro will be made available once testing is completed. Mitigations for CVE-2017-5232, CVE-2017-5233, CVE-2017-5234, CVE-2017-5235 In all cases, users are advised to routinely clean out their "Downloads" folder, as this issue tends to crop up in installer packages in general. Of course, users should be aware of where they are downloading and running executable software, and Microsoft Windows executables support a robust, certificate-based signing procedure that can ensure that Windows binaries are, in fact, what they purport to be. Users who keep historical versions of installers for backup and downgradability purposes should be careful to only launch those installation applications from empty directories, or at least, directories that do not contain unknown, unsigned, and possibly malicious DLLs. Coordinated Disclosure Done Right NCC Group, Justin Steven, and Callum Carney all approached Rapid7 with these issues privately, and have proven to be excellent and accommodating partners in reporting these vulnerabilities to us. As a publisher of vulnerability information ourselves, Rapid7 knows that this kind of work can at times be combative, unpleasant, and frustrating. Thankfully, that was not the case with these researchers, and we greatly appreciate their willingness to work with us and lend us their expertise. If you're a Rapid7 customer who has any questions about this advisory, please don't hesitate to contact your regular support channel, or leave a comment below.

Under the Hoodie: Actionable Research from Penetration Testing Engagements

Today, we're excited to release Rapid7's latest research paper, Under the Hoodie: Actionable Research from Penetration Testing Engagements, by Bob Rudis, Andrew Whitaker, Tod Beardsley, with loads of input and help from the entire Rapid7 pentesting team.This paper covers the often occult art of…

Today, we're excited to release Rapid7's latest research paper, Under the Hoodie: Actionable Research from Penetration Testing Engagements, by Bob Rudis, Andrew Whitaker, Tod Beardsley, with loads of input and help from the entire Rapid7 pentesting team.This paper covers the often occult art of penetration testing, and seeks to demystify the process, techniques, and tools that pentesters use to break into enterprise networks. By drawing on the experiences of dozens of pentesters in the field, based on real, qualified data drawn from the real-life experiences of those pentesters, we're able to suss out the most common vulnerabilities that are exploited, the most common network misconfigurations that are leveraged, and the most effective methods we've found to compromise high-value credentials.Finding: Detection is EverythingProbably the most actionable finding we discovered is that most organizations that conduct penetration testing exercises have a severe lack of usable, reliable intrusion detection capabilities. Over two-thirds of our pentesters completely avoided detection during the engagement. This is especially concerning given that most assessments don't put a premium on stealth; due to constraints in time and scope, pentesters generate an enormous amount of malicious traffic. In an ideal network, these would be setting off alarm bells everywhere. Most engagements end with recommendations to implement some kind of incident detection and response, regardless of the specific techniques for compromise were used.Finding: Enterprise Size and Industry Doesn't MatterWhen we started this study, we expected to find quantitative differences between small networks and large networks, and between different industries. After all, you might expect a large, financial industry enterprise of over 1,000 employees would be better equipped to detect and defend against unwelcome attackers due to the security resources available and required by various compliance regimes and regulatory requirements. Or, you might believe that a small, online-only retail startup would be more nimble and more familiar with the threats facing their business.Alas, this isn't the case. As it turns out, the detection and prevention rates are nearly identical between large and small enterprises, and no industry seemed to fare any better or worse when it came to successful compromises.This is almost certainly due to the fact that IT infrastructure pretty much everywhere is built using the same software and hardware components. Thus, all networks tend to be vulnerable to the same common misconfigurations that have the same vulnerability profiles when patch management isn't firing at 100%. There are certainly differences in the details -- especially when it comes to custom-designed web applications -- but even those tend to have the same sorts of frameworks and components that power them.The Human TouchFinally, if you're not really into reading a bunch of stats and graphs, we have a number of "Under the Hoodie" sidebar stories, pulled from real-life engagements. For example, while discussing common web application vulnerabilities, we're able to share a story of how a number of otherwise lowish-severity, external web application issues lead to the eventual compromise of the entire internal back-end network. Not only are these stories fun to read, they do a pretty great job of illustrating how unrelated issues can conspire on an attacker's behalf to lead to surprising levels of unauthorized access.I hope you take a moment to download the paper and take a look at our findings; I don't know of any other research out there that explores the nuts and bolts of penetration testing in quite the depth or breadth that this report provides. In addition, we'll be covering the material at our booth at the RSA security conference next week in San Francisco, as well as hosting a number of "Ask a Pentester" sessions. Andrew and I will both be there, and we love nothing more than connecting with people who are interested in Rapid7's research efforts, so definitely stop by.

12 Days of Haxmas: Giving the Gift of Bad News

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. This holiday season, eager little hacker girls and boys around the world will be tearing open their new IoT gadgets and geegaws, and set to work on evading tamper evident seals, proxying communications, and reversing firmware, in search of a Haxmas miracle of 0day. But instead of exploiting these newly discovered vulnerabilities, many will instead notice their hearts growing three sizes larger, and wish to disclose these new vulns in a reasonable and coordinated way in order to bring attention to the problem and ultimately see a fix for the discovered issues. In the spirit of HaXmas, then, I'd like to take a moment to talk directly to the good-hearted hackers out there about how one might go about disclosing vulnerabilities in a way that maximizes the chances that your finding will get the right kind of attention. Keep It Secret, Keep it Santa First and foremost, I'd urge any researcher to consider the upsides of keeping your disclosure confidential for the short term. While it might be tempting to tweet a 140-character summary publically to the vendor's alias, dropping this kind of bomb on the social media staff of an electronics company is kind of a jerk move, and only encourages an adversarial relationship from there on out. In the best case, the company most able to fix the issue isn't likely to work with you once you've published, and in the worst, you might trigger a defensive reflex where the vendor refuses to acknowledge the bug at all. Instead, consider writing a probing email to the company's email aliases of security@, secure@, abuse@, support@, and info@, along the lines of, "Hi, I seem to have found a software vulnerability with your product, who can I talk to?" This is likely to get a human response, and you can figure out from there who to talk to about your fresh new vulnerability. The Spirit of Giving You could also go a step further, and check the vendor's website to see if they offer a bug bounty for discovered issues, or even peek in on HackerOne's community-curated directory of security contacts and bug bounties. For example, searching for Rapid7 gives a pointer to our disclosure policies, contact information, and PGP key. However, be careful when deciding to participate in a bug bounty. While the vast majority of bounty programs out there are well-intentioned, some come with an agreement that you will never, ever, ever, in a million years, ever disclose the bug to anyone else, ever — even if the vendor doesn't deign to acknowledge or fix the issue. This can leave you in a sticky situation, even if you end up getting paid out. If you agree to terms like that, you can limit your options for public disclosure down the line if the fix is non-existent or incomplete. Because of these kinds of constraints, I tend to avoid bug bounties, and merely offer up the information for free. It's totally okay to ask about a bounty program, of course, but be sure that you're not phrasing your request that can be read as an extortion attempt — that can be taken as an attack, and again, trigger a negative reaction from the vendor. No Reindeer Games In the happy case where you establish communications with the vendor, it's best to be as clear and as direct as possible. If you plan to publish your findings on your blog, say so, and offer exactly what and when you plan to publish. Giving vendors deadlines — in a friendly, non-threatening, matter-of-fact way — turns out to be a great motivator for getting your issue prioritized internally there. Be prepared to negotiate around the specifics, of course — you might not know exactly how to fix a bug, and how long that'll take, and the moment you disclose, they probably don't, either. Most importantly, though, try to avoid over-playing your discovery. Consider what an adversary actually has to do to exploit the bug — maybe they need to be physically close by, or already have an authorized account, or something like that. Being upfront with those details can help frame the risk to other users, and can tamp down irrational fears about the bug. Finally, try to avoid blaming the vendor too harshly. Bugs happen — it's inherent in the way we write, assemble, and ship software for general purpose computers. Assume the vendor isn't staffed with incompetents and imbeciles, and that they actually do care about protecting their customers. Treating your vendor with respect will engender a pretty typical honey versus vinegar effect, and you're much more likely to see a fix quickly. Sing it Loud For All to Hear Assuming you've hit your clearly-stated disclosure deadline, it's time to publish your findings. Again, you're not trying to shame the vendor with your disclosure — you're helping other people make better informed decisions about the security of their own devices, giving other researchers a specific, documented case study of a vulnerability discovered in a shipping product, and teaching the general public about How Security Works. Again, effectively communicating the vulnerability is critical. Avoid generalities, and offer specifics — screenshots, step-by-step instructions on how you found it, and ideally, a Metasploit module to demonstrate the effects of an exploit. Doing this helps move other researchers along in helping them to completely understand your unique findings and perhaps apply your learnings to their own efforts. Ideally, there's a fix already available and distributed, and if so, you should clearly state that, early on in your disclosure. If there isn't, though, offer up some kind of solution to the problem you've discovered. Nearly always, there is a way to work around the issue through some non-default configuration, or a network-level defense, or something like that. Sometimes, the best advice is to avoid using the product all together, but that tends to be the last course of defense. Happy HaXmas! Given the recently enacted DMCA research exemption on consumer devices, I do expect to see an uptick in disclosing issues that center around consumer electronics. This is ultimately a good thing -- when people tinker with their own devices, they are more empowered to make better decisions on how a technology can actually affect their lives. The disclosure process, though, can be almost as challenging as the initial hackery as finding and exploiting vulnerabilities in the first place. You're dealing with emotional people who are often unfamiliar with the norms of security research, and you may well be the first security expert they've talked to. Make the most of your newfound status as a security ambassador, and try to be helpful when delivering your bad news.

On the Recent DSL Modem Vulnerabilities

by Tod Beardsley and Bob Rudis What's Going On? Early in November, a vulnerability was disclosed affecting Zyxel DSL modems, which are rebranded and distributed to many DSL broadband customers across Europe. Approximately 19 days later, this vulnerability was leveraged in widespread attacks across the…

by Tod Beardsley and Bob Rudis What's Going On? Early in November, a vulnerability was disclosed affecting Zyxel DSL modems, which are rebranded and distributed to many DSL broadband customers across Europe. Approximately 19 days later, this vulnerability was leveraged in widespread attacks across the Internet, apparently connected with a new round of Mirai botnet activity. If you are a DSL broadband customer, you can check to see if your external TCP port 7547 is accessible to the Internet by using popular public portscanning services provided by WhatsMyIP, SpeedGuide, or your own favorite public portscanning service. If it is, your ISP should be able to confirm if your modem is vulnerable to this attack. Vulnerability Details On November 7, "Kenzo" disclosed two vulnerabilities affecting the Zyxel D1000 DSL modem on the Reverse Engineering blog, here. This DSL modem is used by residential DSL subscribers in Ireland, and appears to be distributed by the Irish ISP, Eir. It's unknown if Kenzo disclosed these issues to either Zyxel or Eir prior to public disclosure. Two issues were identified, both involving the TR-064 SOAP service on the DSL modem, running on TCP port 7547. The first is a command injection vulnerability in the way the device parses new NTP server configurations, where an attacker can enclose an arbitrary shell command in backticks when setting the NewNTPServer1 parameter. The second is an information leak vulnerability where an attacker can access the GetSecurityKeys command to learn the device's WiFi and administrative password. Kenzo provided a proof-of-concept Metasploit module to exercise these vulnerabilities to expose the administrative web service on the Internet-facing side of the modem and to extract the administrative password to that admin web service. On November 26th, the command injection issue was being actively exploited in the wild, apparently as part of another wave of Mirai-style IoT botnet activity. In particular, DSL modems provided to Deutsche Telekom customers in Germany and Austria, under the brandname "Speedport," appeared to be vulnerable. As a result of this attack, many Telekom subscribers were knocked offline on November 27th, and DT has since updated the Speedport firmware. Today, on November 29th, the Metasploit open source project has started work on converting Kenzo's original, special purpose proof-of-concept exploit to a more generally useful Metasploit module that can be used to test the vulnerability in a safer and more controlled way. That work continues on Pull Request #7626. Exploit Activity Details Rapid7's Heisenberg Cloud started picking up malicious SOAP HTTP POST requests to port 7547 on November 26th. We were able to pick up these requests due to the “spray and pray” nature of the bots searching for vulnerable targets. To-date, we've seen over 63,000 unique source IP addresses associated with these attempts to take over the routers, peaking at over 35,000 unique attempts per day on November 27th. As the map below shows, the bots attempting to take over the routers are geographically dispersed. As the below temporal flow diagram shows, different regions are more prevalent as sources of this activity on different days (the source regions are on the left, the days they were active are on the right). There was little change in the top 10 source countries (by unique node count) over the attack period, but some definitely stood out more than others (like Brazil and the U.K.). We've also seen all malicious payload types, though not all of them appeared on all days as seen in the third chart. Not all payloads were evenly distributed across all countries: What Can You Do to Protect Yourself? The vulnerabilities being exploited in these attack are present in Zyxel DSL modems, which are commonly used in European and South American consumer markets, and may be rebranded by regional ISPs, as they are for Eir and Deutsche Telekom. The vulnerabilities described do not appear to affect the cable modems commonly used in the United States. If you are a DSL customer and concerned that you may be vulnerable, you can use popular portscanning services provided by WhatsMyIP, SpeedGuide, or others to assess if your external TCP port 7547 is accessible from the Internet. If the port times out or is otherwise not reachable, you're in the clear. If it is accessible, you should contact your ISP to see if a) this can be restricted, and b) if you are running a vulnerable device. For ISPs, it is A Bad Idea to expose either TR-069 or TR-064 services to arbitrary sources on the Internet; while ISPs may need access to this port to perform routine configuration maintenance on customer equipment, it should be possible for local and edge firewall rules to restrict access to this port to only IP addresses that originate from the ISP's management network. Meanwhile, penetration testers should follow the progress of converting Kenzo's original proof-of-concept to a fully functional Metasploit module over at Pull Request #7626 on Metasploit's GitHub repository. If you are an open source security software developer, we'd love to have your input there. Update (2016-Nov-30): This blog post originally referred to the vulnerable service as TR-069, but it's since become clear this issue is in a related service, TR-064.

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

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