Skip navigation
All Places > Information Security > Blog
1 2 3 Previous Next

Information Security

771 posts

It's summer in the northern hemisphere and many folks are working their way through carefully crafted reading lists, rounding out each evening exploring fictional lands or investigating engrossing biographies. I'm hoping that by the end of this post, you'll be adding another item to your "must read" list — a tome whose pages are bursting with exploits carried out by crafty, international adversaries and stories of modern day sleuths on the hunt for those who would seek their fortunes by preying on the innocent and ill-prepared. "What work is this?!" you ask (no doubt with eager anticipation). Why, it's none other than the Cisco 2017 Midyear Cybersecurity Report (MCR)!


This year, Rapid7—along with nine other organizations—contributed content for Cisco's mid-year threat landscape review, and it truly is a treasure trove of information with data, intelligence and guidance from a wide range of focus areas across the many disciplines of cybersecurity.


Avid readers of the R7 blog likely remember our foray into "DevOps" server-ransomware earlier this year. We've been using Project Sonar to monitor MongoDB, CouchDB, Elasticsearch and Docker—what we're calling "DevOps" servers—since January, and we've provided a deep-dive into the state of these services in the Cisco 2017 MCR.


You should read the "DevOps" section within the context of the entire report as other sections provide both reinforcement and additional adversary context to our findings, but we wanted to show a small extension of the MongoDB server status here since we've performed a few more scans since we provided the research results in the MCR:


There are two main takeaways from both the current state of MongoDB (and the other "DevOps" servers).


First: Good show! While there are still thousands of MongoDB (and CouchDB, and Elasticsearch, and Docker, etc) exposed to the internet without authentication, the numbers are generally decreasing or holding steady (discrepancies per-scan are expected since mining the internet for data is notoriousily fraught with technical peril) and it seems attackers have realized that the remaining instances out there are likely non-production, forgotten or abandoned systems. It would be great if the owners of these systems yanked them off of the internet, but the issue appears to have been (at least, temporarily) abated.


Second: Be vigilant! Attackers have had ample opportunity to fine tune their "DevOps" discovery kits as well as their ransom/destruction kits. We've all witnessed just how easy it is for our adversaries to gain an internal foothold when they believe it will be beneficial (ref: WannaCry and Petya-not-Petya). It truly is only a matter of time before the techniques they've perfected on the open internet make their way into our gilded internal network cages. It would be very prudent to take this summer lull to scan for open or weak-credentialed "DevOps" servers in your own environments and make sure they're more properly secured before you find yourself standing feeding bills into a Bitcoin ATM when you should be basking in the sun on the beach.


The Cisco 2017 MCR is absolute "must add" to the reading lists of IT and cybersecurity professionals and we hope you take some time to digest it out over the coming days/weeks.

On Jun. 22, the US Copyright Office released its long-awaited study on Sec. 1201 of the Digital Millennium Copyright Act (DMCA), and it has important implications for independent cybersecurity researchers. Mostly the news is very positive. Rapid7 advocated extensively for researcher protections to be built into this report, submitting two sets of detailed comments—see here and here—to the Copyright Office with Bugcrowd, HackerOne, and Luta Security, as well as participating in official roundtable discussions. Here we break down why this matters for researchers, what the Copyright Office's study concluded, and how it matches up to Rapid7's recommendations.


What is DMCA Sec. 1201 and why does it matter to researchers?

Sec. 1201 of the DMCA prohibits circumventing technological protection measures (TPMs, like encryption, authentication requirements, region coding, user agents) to access copyrighted works, including software, without permission of the owner. That creates criminal penalties and civil liability for independent security research that does not obtain authorization for each TPM circumvention from the copyright holders of software. This hampers researchers' independence and flexibility. While the Computer Fraud and Abuse Act (CFAA) is more famous and feared by researchers, liability for DMCA Sec. 1201 is arguably broader because it applies to accessing software on devices you may own yourself while CFAA generally applies to accessing computers owned by other people.


To temper this broad legal restraint on unlocking copyrighted works, Congress built in two types of exemptions to Sec. 1201: permanent exemptions for specific activities, and temporary exemptions that the Copyright Office can grant every three years in its "triennial rulemaking" process. The permanent exception to the prohibition on circumventing TPMs for security testing is quite limited – in part because researchers are still required to get prior permission from the software owner. The temporary exemptions go beyond the permanent exemptions.


In Oct. 2015 the Copyright Office granted a very helpful exemption to Sec. 1201 for good faith security testing that circumvents TPMs without permission. However, this temporary exemption will expire at the end of the three-year exemption window. In the past, once a temporary exemption expires, advocates must start from scratch in re-applying for another temporary exemption. The temporary exemption is set to expire Oct. 2018, and the renewal process will ramp up in the fall of this year.


Copyright Office study and Rapid7's recommendations

The Copyright Office announced a public study of Sec. 1201 in Dec. 2015. The Copyright Office undertook this public study to weigh legislative and procedural reforms to Sec. 1201, including the permanent exemptions and the three-year rulemaking process. The Copyright Office solicited two sets of public comments and held a roundtable discussion to obtain feedback and recommendations for the study. At each stage, Rapid7 provided recommendations on reforms to empower good faith security researchers while preserving copyright protection against infringement – though, it should be noted, there were several commenters opposed to reforms for researchers on IP protection grounds.


Broadly speaking, the conclusions reached in the Copyright Office's study are quite positive for researchers and largely tracked the recommendations of Rapid7 and other proponents of security research. Here are four key highlights:


  1. Authorization requirement: As noted above, the permanent exemption for security testing under Sec. 1201(j) is limited because it still requires researchers to obtain authorization to circumvent TPMs. Rapid7's recommendation is to remove this requirement entirely because good faith security research does not infringe copyright, yet an authorization requirement compromises independence and speed of research. The Copyright Office's study recommended [at pg. 76] that Congress make this requirement more flexible or remove it entirely. This is arguably the study's most important recommendation for researchers.

  2. Multi-factor test: The permanent exemption for security testing under Sec. 1201(j) also partially conditions liability protection on researchers when the results are used "solely" to promote the security of the computer owner, and when the results are not used in a manner that violates copyright or any other law. Rapid7's recommendations are to remove "solely" (since research can be performed for the security of users or the public at large, not just the computer owner), and not to penalize researchers if their research results are used by unaffiliated third parties to infringe copyright or violate laws. The Copyright Office's study recommended [at pg. 79] that Congress remove the "solely" language, and either clarify or remove the provision penalizing researchers when research results are used by third parties to violate laws or infringe copyright.

  3. Compliance with all other laws: The permanent exemption for security testing only applies if the research does not violate any other law. Rapid7's recommendation is to remove this caveat, since research may implicate obscure or wholly unrelated federal/state/local regulations, those other laws have their own enforcement mechanisms to pursue violators, and removing liability protection under Sec. 1201 would only have the effect of compounding the penalties. Unfortunately, the Copyright Office took a different approach, tersely noting [at pg. 80] that it is unclear whether the requirement to comply with all other laws impedes legitimate security research. The Copyright Office stated they welcome further discussion during the next triennial rulemaking, and Rapid7 may revisit this issue then.

  4. Streamlined renewal for temporary exemptions: As noted above, temporary exemptions expire after three years. In the past, proponents must start from scratch to renew the temporary exemption – a process that involves structured petitions, multiple rounds of comments to the Copyright Office, and countering the arguments of opponents to the exemption. For researchers that want to renew the temporary security testing exemption, but that lack resources and regulatory expertise, this is a burdensome process. Rapid7's recommendation is for the Copyright Office to presume renewal of previously granted temporary exemptions unless there is a material change in circumstances that no longer justifies granting the exemption. In its study, the Copyright Office committed [at pg. 143] to streamlining the paperwork required to renew already granted temporary exemptions. Specifically, the Copyright Office will ask parties requesting renewal to submit a short declaration of the continuing need for an exemption, and whether there has been any material change in circumstances voiding the need for the exemption, and then the Copyright Office will consider renewal based on the evidentiary record and comments from the rulemaking in which the temporary exemption was originally granted. Opponents of renewing exemptions, however, must start from scratch in submitting evidence that a temporary exemption harms the exercise of copyright. 


Conclusion—what's next?

In the world of policy, change typically occurs over time in small (often hard-won) increments before becoming enshrined in law. The Copyright Office's study is one such increment. For the most part, the study is making recommendations to Congress, and it will ultimately be up to Congress (which has its own politics, processes, and advocacy opportunities) to adopt or decline these recommendations. The Copyright Office's study comes at a time that House Judiciary Committee is broadly reviewing copyright law with an eye towards possible updates. However, copyright is a complex and far-reaching field, and it is unclear when Congress will actually take action. Nonetheless, the Copyright Office's opinion on these issues will carry significant weight in Congress' deliberations, so it would have been a heavy blow if the Copyright Office’s study had instead called for tighter restrictions on security research.


Importantly, the Copyright Office's new, streamlined process for renewing already granted temporary exemptions will take effect without Congress' intervention. The streamlined process will be in place for the next "triennial rulemaking," which begins in late 2017 and concludes in 2018, and which will consider whether to renew the temporary exemption for security research. This is a positive, concrete development that will reduce the administrative burden of applying for renewal and increase the likelihood of continued protections for researchers.


The Copyright Office's study noted that "Independent security test[ing] appears to be an important component of current cybersecurity practices". This recognition and subsequent policy shifts on the part of the Copyright Office are very encouraging. Rapid7 believes that removing legal barriers to good faith independent research will ultimately strengthen cybersecurity and innovation, and we hope to soon see legislative reforms that better balance copyright protection with legitimate security testing.


Petya-like Ransomware Explained

Posted by todb Employee Jun 27, 2017

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. We have confirmed 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,,, and 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.


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.



These issues were discovered by Orlando Barrera II of Rapid7, Inc, and disclosed in accordance with Rapid7's vulnerability disclosure policy.



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.



Figure 1: Adding XSS to Name and Description


Figure 2: Navigating to the Workspace fires the Name field XSS


Figure 3: Navigation to the Workspace fires the Description field XSS


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.


Figure 4: Editing file details


Figure 5: Navigating to the Workspace fires the File Details Description XSS



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

Senator Ed Markey (D-MA) is poised to introduce legislation to develop a voluntary cybersecurity standards program for the Internet of Things (IoT). The legislation, called the Cyber Shield Act, would enable IoT products that comply with the standards to display a label indicating a strong level of security to consumers – like an Energy Star rating for IoT. Rapid7 supports this legislation and believes greater transparency in the marketplace will enhance cybersecurity and protect consumers.


The burgeoning IoT marketplace holds a great deal of promise for consumers. But as the Mirai botnet made starkly clear, many IoT devices – especially at the inexpensive range of the market – are as secure as leaky boats. Rapid7's Deral Heiland and Tod Beardsley, among many others, have written extensively about IoT's security problems from a technical perspective.


Policymakers have recognized the issue as well and are taking action. Numerous federal agencies (such as FDA and NHTSA) have set forth guidance on IoT security as it relates to their area of authority, and others (such as NIST) have long pushed for consistent company adoption of baseline security frameworks. In addition to these important efforts, we are encouraged that Congress is also actively exploring market-based means to bring information about the security of IoT products to the attention of consumers.


Sen. Markey's Cyber Shield Act would require the Dept. of Commerce to convene public and private sector experts to establish security benchmarks for select connected products. The working group would be encouraged to incorporate existing standards rather than create new ones, and the benchmark would change over time to keep pace with evolving threats and expectations. The process, like that which produced the NIST Cybersecurity Framework, would be open for public review and comment. Manufacturers may voluntarily display "Cyber Shield" labels to IoT products that meet the security benchmarks (as certified by an accredited testing entity).


Rapid7 supports voluntary initiatives to raise awareness to consumers about product security, like that proposed in the Cyber Shield Act. Consumers are often not able to easily determine the level of security in products they purchase, so an accessible and reliable system is needed to help inform purchase decisions. As consumers evaluate and value IoT security more, competing manufacturers will respond by prioritizing secure design, risk management practices, and security processes. Consumers and the IoT industry can both benefit from this approach.


The legislation is not without its challenges, of course. To be effective, the security benchmarks envisioned by the bill must be clear and focused, rather than generally applicable to all connected devices. The program would need buy-in from security experts and responsible manufacturers, and consumers would need to learn how to spot and interpret Cyber Shield labels. But overall, Rapid7 believes Sen. Markey's Cyber Shield legislation could encourage greater transparency and security for IoT. Strengthening the IoT ecosystem will require a multi-pronged approach from policymakers, and we think lawmakers should consider incorporating this concept as part of the plan.

Deral Heiland

In Fear of IoT Security

Posted by Deral Heiland Employee Jun 21, 2017

I wish I had a dime for every time I have heard someone say “With so many vulnerabilities being reported in the Internet of Things, I just don’t trust that technology, so I avoid using any of it." I am left scratching my head because these same people seem to have no issues running a Windows operating system.


As a researcher focused on the Internet of Things (IoT), I regularly release new vulnerabilities around IoT product ecosystems, which can include hardware, mobile application and cloud web servers, and APIs. The main goal when doing this work is better security. The hope is that the knowledge gained and shared in the course of this research will help manufacturers build better products and help those using IoT make better decisions around the deployment and management of IoT technology. Unfortunately, any vulnerability my peers and I discover during research can be—and often is— made out to be worse than it really is. Now don’t get me wrong: I want the work I do to be taken seriously, but we still need to take a complete risk model into consideration when evaluating IoT issues. We can refer back to one of the most succinct risk formulas below:


Risk = Probability x Impact


Unfortunately, I think we have a tendency to forget about this formula. Every time I discuss my IoT findings with reporters, customers, or the general public, I like to discuss the associated risk, because it varies quite a bit based on “how” and “by whom” the affected IoT technology is being used.


A good example of this is the IoT tracking device research I conducted in the past year. If I told you a malicious actor could identify and use a simple low-energy Bluetooth dongle hanging on my keychain “used to find lost keys” to track me anywhere I go via Global Positioning System (GPS) data, what would you say about that?  Our initial response would most likely be that this is horrible and scary, and that response is 100% understandable...but if we think through this using the risk formula, it can easily become both clearer and less dire.


First, what is the probability of someone's taking the time and effort to identify such a flaw in a product so they could track us? This leads to several new questions:

  • Would anyone need or want to track me?
  • Am I a very high-profile person, such as a politician or celebrity?
  • Do I have any reason to believe someone is currently interested in stalking or tracking me?

If the answer is “no,” then the probability part of the equation quickly drops to nearly zero, or “very unlikely.” Remember basic math: If zero is multiplied by anything, it still equals zero—meaning the risk of this occurring is very low. Now if you do fall within the narrow category of users who may be at higher risk, then you might want to consider the benefit versus risk of using such technology, but for the most part few of us fall into that category.


If we talk through the risk of using IoT and apply the basic risk formula, we can better identify the true risk and, armed with that knowledge, focus on properly mitigating and/or reducing it.


When thinking about purchasing and deploying IoT at home or in business, there are more questions we can ask that can help us understand other aspects of the risks associated with IoT:

  • Does the product support over-the-air security patching? Having the ability to quickly patch a product when vulnerabilities are found helps to reduce risk and is a key indicator of a more mature security program on the vendor's part.
  • Has the vendor had an independent security review done on their product? Vendors who proactively test their products prior to going to market often deliver a more secure product; this is also another key indicator of a mature security process.


And, when we deploy our newly purchased IoT technology, what can we do as users/consumers to reduce risk?

  • We should change default passwords and set complex passwords on all accounts and services (and choose devices/services that support this or even stronger authentication mechanisms).
  • We should strongly consider deploying the solution within an isolated VLAN environment to protect our core business or home networks from any malicious traffic aimed at or coming from an IoT component.


I strongly encourage both businesses and consumers to embrace IoT and all the benefits that come with IoT solutions, but to do so with eyes wide open using common-sense risk evaluation, along with deployment and management best practices. This way, you can securely take advantage of all IoT has to offer.


Rapid7 can help you test the security of your IoT devices. Learn more about our IoT security services.

In April 2017, President Trump issued an executive order directing a review of all trade agreements. This process is now underway: The United States Trade Representative (USTR) – the nation's lead trade agreement negotiator – formally requested public input on objectives for the renegotiation of the North American Free Trade Agreement (NAFTA). NAFTA is a trade agreement between the US, Canada, and Mexico, that covers a huge range of topics, from agriculture to healthcare.


Rapid7 submitted comments in response, focusing on 1) preventing data localization, 2) alignment of cybersecurity risk management frameworks, 3) protecting strong encryption, and 4) protecting independent security research.


Rapid7's full comments on the renegotiation of NAFTA are available here.


1) Preserving global free flow of information – preventing data localization

Digital goods and services are increasingly critical to the US economy. By leveraging cloud computing, digital commerce offers significant opportunities to scale globally for individuals and companies of all sizes – not just large companies or tech companies, but for any transnational company that stores customer data.


However, regulations abroad that disrupt the free flow of information, such as "data localization" (requirements that data be stored in a particular jurisdiction), impede both trade and innovation. Data localization erodes the capabilities and cost savings that cloud computing can provide, while adding the significant costs and technical burdens of segregating data collected from particular countries, maintaining servers locally in those countries, and navigating complex geography-based laws. The resulting fragmentation also undermines the fundamental concept of a unified and open global internet.


Rapid7's comments [pages 2-3] recommended that NAFTA should 1) Prevent compulsory localization of data, and 2) Include an express presumption that governments would minimize disruptions to the flow of commercial data across borders.


2) Promote international alignment of cybersecurity risk management frameworks

When NAFTA was originally negotiated, cybersecurity was not the central concern that it is today. Cybersecurity is presently a global affair, and the consequences of malicious cyberattack or accidental breach are not constrained by national borders.


Flexible, comprehensive security standards are important for organizations seeking to protect their systems and data. International interoperability and alignment of cybersecurity practices would benefit companies by enabling them to better assess global risks, make more informed decisions about security, hold international partners and service providers to a consistent standard, and ultimately better protect global customers and constituents. Stronger security abroad will also help limit the spread of malware contagion to the US.


We support the approach taken by the National Institute of Standards and Technology (NIST) in developing the Cybersecurity Framework for Critical Infrastructure. The process was open, transparent, and carefully considered the input of experts from the public and private sector. The NIST Cybersecurity Framework is now seeing impressive adoption among a wide range of organizations, companies, and government agencies – including some critical infrastructure operators in Canada and Mexico.


Rapid's comments [pages 3-4] recommended that NAFTA should 1) recognize the importance of international alignment of cybersecurity standards, and 2) require the Parties to develop a flexible, comprehensive cybersecurity risk management framework through a transparent and open process.


3) Protect strong encryption

Reducing opportunities for attackers and identifying security vulnerabilities are core to cybersecurity. The use of encryption and security testing are key practices in accomplishing these tasks. International regulations that require weakening of encryption or prevent independent security testing ultimately undermine cybersecurity.


Encryption is a fundamental means of protecting data from unauthorized access or use, and Rapid7 believes companies and innovators should be able to use the encryption protocols that best protect their customers and fit their service model – whether that protocol is end-to-end encryption or some other system. Market access rules requiring weakened encryption would create technical barriers to trade and put products with weakened encryption at a competitive disadvantage with uncompromised products. Requirements to weaken encryption would impose significant security risks on US companies by creating diverse new attack surfaces for bad actors, including cybercriminals and unfriendly international governments.


Rapid7's comments [page 5] recommended that NAFTA forbid Parties from conditioning market access for cryptography in commercial applications on the transfer of decryption keys or alteration of the encryption design specifications.


4) Protect independent security research

Good faith security researchers access software and computers to identify and assess security vulnerabilities. To perform security testing effectively, researchers often need to circumvent technological protection measures (TPMs) – such as encryption, login requirements, region coding, user agents, etc. – controlling access to software (a copyrighted work). However, this activity can be chilled by Sec. 1201 of the Digital Millennium Copyright Act (DMCA) of 1998, which forbids circumvention of TPMs without the authorization of the copyright holder.


Good faith security researchers do not seek to infringe copyright, or to interfere with a rightsholder's normal exploitation of protected works. The US Copyright Office recently affirmed that security research is fair use and granted this activity, through its triennial rulemaking process, a temporary exemption from the DMCA's requirement to obtain authorization from the rightsholder before circumventing a TPM to safely conduct security testing on lawfully acquired (i.e., not stolen or "borrowed") consumer products.


Some previous trade agreements have closely mirrored the Digital Millennium Copyright Act's (DMCA) prohibitions on unauthorized circumvention of TPMs in copyrighted works. This approach replicates internationally the overbroad restrictions on independent security testing that the US is now scaling back. Newly negotiated trade agreements should aim to strike a more modern and evenhanded balance between copyright protection and good faith cybersecurity research.


Rapid7's comments [page 6] recommended that any anti-circumvention provisions of NAFTA should be accompanied by provisions exempting security testing of lawfully acquired copyrighted works.


Better trade agreements for the Digital Age?

Data storage and cybersecurity have undergone considerable evolution since NAFTA was negotiated more than a quarter century ago. To the extent that renegotiation may better address trade issues related to digital goods and services, we view the modernization of NAFTA and other agreements as potentially positive. The comments Rapid7 submitted regarding NAFTA will likely apply to other international trade agreements as they come up for renegotiation. We hope the renegotiations result in a broadly equitable and beneficial trade regime that reflects the new realities of the digital economy.

Patrick Laverty

About User Enumeration

Posted by Patrick Laverty Employee Jun 15, 2017

User enumeration is when a malicious actor can use brute-force to either guess or confirm valid users in a system. User enumeration is often a web application vulnerability, though it can also be found in any system that requires user authentication. Two of the most common areas where user enumeration occurs are in a site's login page and its ‘Forgot Password’ functionality.


The malicious actor is looking for differences in the server’s response based on the validity of submitted credentials. The Login form is a common location for this type of behavior. When the user enters an invalid username and password, the server returns a response saying that user ‘rapid7’ does not exist. A malicious actor would know that the problem is not with the password, but that this username does not exist in the system, as shown in Figure 1:



Figure 1: User Does Not Exist


On the other hand, if the user enters a valid username with an invalid password, and the server returns a different response that indicates that the password is incorrect, the malicious actor can then infer that the username is valid, as shown in Figure 2:



Figure 2: Username is Valid


At this point, the malicious actor knows how the server will respond to ‘known good’ and ‘known bad’ input. So, the malicious actor can then perform a brute-force attack with common usernames, or may use census data of common last names and append each letter of the alphabet to generate valid username lists.


Once a list of validated usernames is created, the malicious actor can then perform another round of brute-force testing, but this time against the passwords until access is finally gained.


An effective remediation would be to have the server respond with a generic message that does not indicate which field is incorrect. When the response does not indicate whether the username or the password is incorrect, the malicious actor cannot infer whether usernames are valid. Figure 3 shows an example of a generic error response:



Figure 3: Generic Error Response

The application’s Forgot Password page can also be vulnerable to this kind of attack. Normally, when a user forgets their password, they enter a username in the field and the system sends an email with instructions to reset their password. A vulnerable system will also reveal that the username does not exist, as shown in Figure 4:



Figure 4: Username Does Not Exist


Again, the response from the server should be generic and simply tell the user that, if the username is valid, the system will send an instructional email to the address on record. Figure 5 shows an example of a message that a server could use in its response:


Figure 5: Example Message


Sometimes, user enumeration is not as simple as a server responding with text on the screen. It can also be based on how long it takes a server to respond. A server may take one amount of time to respond for a valid username and a very different (usually longer) amount of time for an invalid username. For example, Outlook Web Access (OWA) often displays this type of behavior. Figure 6 shows this type of attack, using a Metasploit login module.



Figure 6: Invalid and Valid User


In this example, the ‘FAILED LOGIN’ for the user 'RAPID7LAB\admin' took more than 30 seconds to respond and it resulted in a redirect. However, the user 'RAPID7LAB\administrator' got the response ‘FAILED LOGIN, BUT USERNAME IS VALID’ in a fraction of a second. When the response includes ‘BUT USERNAME IS VALID’, this indicates that the username does exist, but the password was incorrect. Due to the explicit notification about the username, we know that the other response, ‘FAILED LOGIN’, is for a username that is not known to the system.


How would you remediate this? One way could be to have the application pad the responses with a random amount of time, throwing off the noticeable difference. This might require some additional coding into an application, or may not be possible on a proprietary application.


Alternately, you could require Two-Factor Authentication (2FA). While the application may still be vulnerable to user enumeration, the malicious actor would have more trouble reaching their end goal of getting valid sets of credentials. Even if a malicious actor can generate user lists and correctly guess credentials, the SMS token may become an unbeatable obstacle that forces the malicious actor to seek easier targets.


One other way to block user enumeration is with a Web Application Firewall (WAF). To perform user enumeration, the malicious actor needs to submit lots of different usernames. A legitimate user should probably never not need to send hundreds or thousands of usernames. A good WAF will detect and block single IP address making many of these requests. Some WAFs will drop these requests entirely, others will issue a negative response, regardless of whether the request is valid.


We recommend testing any part of the web application where user accounts are checked by a server for validity and look for some different types of responses from the server. A different response can be as obvious as an error message or the amount of time a server takes to respond, or a subtler difference, like an extra line of code in a response or a different file being included. Adding 2FA or padding the response time can prevent these types of attacks, as any of these topics discussed could tip off a malicious actor as to whether a username is valid.


You can read about Rapid7's web application security testing solutions here.


National Exposure Index 2017

Posted by todb Employee Jun 14, 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, 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

natexp-2017-small.pngWhen 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 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.

I’ve never been a big fan of – or have believed in the value of – security policies. Sure, they’re necessary for setting expectations and auditors want to see them. They can also serve as a sort of insurance policy to fall back on when an unexpected security “event” occurs. But, at the end of the day, security policies often contribute minimal value to the overall information security function. As I’ve seen time times before: many organizations have great paperwork but their security program stinks.


If you’re reading this blog, you’re no doubt somehow responsible for information security in your business. You may not be responsible for everything security-related but odds are good that the things you’re doing, such as vulnerability scanning, penetration testing, and incident response, are an integral part of your overall security program. That’s all good but there’s an elephant in the room. It’s your security policies. You know those documents that are scattered about making your information security program look better than it actually is.


Don’t get me wrong. I’m not trying to be critical of or shun your efforts. I know what you’re up against, but I also see what the research shows and what happens when people have a false sense of security. When it comes to policies, one of the best things you can do, starting today, is to stop relying on them to fix your security problems. And tell your peers and management to do the same thing. You can tell them I said so. I’ve heard it a thousand times: “We have a policy for that.” The assumption is since there’s a policy, then all is well in IT. That’s hardly the case.


Looking at areas across your information security program—from security assessments to patch management to mobile computing—you may have a policy mandating this or that. Even a policy as basic as acceptable computer usage that’s known by everyone is likely in place. They’re probably all very well-written and would satisfy the requirements of many a gullible auditor. But how is it working for you? Probably not as well as you had hoped—or as well as management believes it does.


The following scenarios describe very common misconceptions about enterprise security:

  • We have a password policy. Yet all passwords across all systems are nowhere near compliant. Executives are often exempt. Some passwords are unenforceable. Numerous risks are further facilitated because strong passwords are assumed to be in place, but they’re really not.
  • We have an acceptable usage policy. But users don’t know about it. There’s no tracking or accountability for violations. There’s little to no integration with user awareness and training initiatives. Why even state what the rules are when they’re ignored?
  • We have a data backup policy. However, desktops, mobile devices, and even IoT and cloud data are being overlooked. Shadow IT-borne systems are completely out of the loop. The lack of backups of some of the most critical data is unknown until a ransomware infection hits.
  • We have a patch management policy. Still, patches are not being applied (especially third-party patches for Java and Adobe products) and malware and related exploits are still occurring.


You see where I’m going with this.


The interesting thing is that most of the IT and security pros I work with understand the reality of the policy vs. practice disconnect. It’s often people outside of those circles who assume that all is well in security because, after all, it’s documented. I’m convinced that if you’re going to have a truly resilient security environment, you’re going to have to move beyond the paperwork. See this disconnection for what it is. Bring it up in security discussions. Use it as leverage to get more support for your security initiatives. Ask for help. Whatever you do, don’t assume that policies will keep your environment locked down. Assumptions about these types of security challenges make fools of us all.

This is a continuation of our CIS critical security controls blog series.


Workstations form the biggest threat surface in any organization. The CIS Critical Security Controls include workstation and user-focused endpoint security in several of the controls, but Control 8 (Malware Defenses) is the only control to strictly focus on antivirus and malware across the organization. It's pretty important, too: Malware networks are often run by organized criminals who profit from both the stolen identities of end users and access to the extensive computing and network resources that malware is designed to exploit. To a lesser extent, malware is also used for corporate and nation-state espionage, acts of vandalism, strategic attacks on infrastructure, and just about any circumstance where an attacker wants to compromise multiple hosts with minimal effort. Simply put: Malware is a big problem, and it puts everyone at risk. Much like disease prevention, malware prevention relies on a combination of "computing hygiene" and herd immunity; if it's done right, we all have a part in reducing the impact of malware and the risks associated with it.


What this control covers

Control 8 covers malware and antivirus protection at  system, network, and organizational levels. It isn’t limited to workstations, since even servers that don't run Windows are regularly targeted (and affected) by malware. Control 8 should be used to asses infrastructure, IoT, mobile devices, and anything else that can become a target for malicious software—not just endpoints.


This control has been specifically included in version 6 of the CIS Critical Controls in a way that focuses on preventing the spread of worms and other self-propagating malicious code, but it's important to note that the Malware Defenses control is actually just a small subset of a good malware protection program. Following Control 8 will significantly improve any kind of incident response program you're developing, and it'll also help with the "top five" CIS controls, since it's dependent on them for effective implementation.



Antivirus not dead, sun still rises: a note on terminology

The term “malware” can be a little misleading, because it's often used to only describe viruses, or a specific subset of all of the malicious software used to attack information systems. The generally accepted definition of malware includes viruses, worms, ransomware, and anything that is purpose-built to be malicious software; that is what I'm going to stick with here. The nice part of this, though, is that many of the controls and mitigation techniques for viruses also cover typical malware. Another added bonus is that any decent antivirus software still scans for most malware signatures and malicious behavior. Despite claims to the contrary, antivirus is not dead; it just grew up.


How To Implement it

Centralize, automate, and configure

The first step is a pretty big one, but the good news is that it’s also fairly easy if you’ve even partially implemented “big five” critical controls. Asset configuration and management tools, as well as continual patching and careful system configuration, can go a long way in stopping most malware infections. This includes ransomware like CryptoLocker, WannaCrypt, and others, since they rely on poorly-configured or unpatched systems to spread.

Simply put: You probably already have a good start if you’re using any centrally managed antivirus service and managing your workstation and endpoint configuration. Central management of antivirus and antimalware clients is pretty important, since the logs generated by these systems can be used to aid in the incident detection process and generally help with cleanup and response. It’s also important for the obvious reasons: Antivirus still protects against viruses, and centrally managed ones mean you can control precisely how.


Log your incidents, and track them over time

As Cindy Jones discussed in an earlier post on logging, tracking and reporting incident information at a log level is pretty important.800px-John_Deere_2054_DHSP_forestry_swing_machine%2C_Kaibab_National_Forest_1.jpg It also acts as a good indicator of network health and security. Enterprise-level antivirus and antimalware solutions usually have some form of logging facility, and this—in concert with other logs from firewalls, network instruments, and critical systems—will give the security team a clear picture of what’s going on inside the network. Logging both detection and response information from your antivirus is a good way to help color in that picture. Aside from detection statistics, it is critical to log what has been done with it when it’s detected, and where it came from. Unfortunately, relying on individual incidents can be like drinking from a water cannon, so rather than relying on alerts for every incident, track the rate of change and the types of infection until you need to look at individual alerts or systems. If you don’t already have one, you will need to build a service that can monitor the number of infected and damaged machines in order to give you a clear picture of where the malware is.


Antimalware everything, all the time

As I mentioned at the top of this post, network devices and other "non-computer" elements of your organization's information systems are vulnerable to malware. At an organization and policy level, you should be making it clear that everything on your network needs to have an antivirus installed, and anything that is run by your IT team should have an enterprise antivirus client that reports back to you. This is helpful for a few reasons: you will have visibility into the systems with the antivirus or endpoint protection client running, and you also can ensure that you’re not granting network access to devices that may be carrying malware. While it may be tempting to ignore some systems, and some vendors don't make clients for some OSes, it's a good idea to aim for as much antivirus/antimalware coverage as possible.


OS-level malware, removable media, installation and tampering detection

Malware can show up from nearly anywhere, and removable media is a major source of infection. It’s critical that you set up your antivirus policy to scan removable media before it’s allowed on anything, and limit who can install software. Removing root privileges also removes the risk of user-installed software or malware attacking critical system objects, or exploiting access to administrator rights and privileged system objects. I’ve personally responded to ransomware cases where the only thing that limited the damage to the organization (and the end user) was the lack of local administrative privilege on the system that got infected. While this isn’t mentioned in Control 8, it’s brought up in Controls 14 and 5.


Watch your edges

Network-level scanning is definitely helpful, especially if you have the capacity to spot command and control traffic, malicious DNS and URL requests, and other stuff. It’s less helpful if you’re just replicating the work that your antivirus clients are already doing. In this case, IDS and logging are also going to play a huge role—specifically, log session lengths, DNS requests, and traffic patterns to look for access with Command and Control networks used by known malware. Session length logging can also give hints about data exfiltration, and looking at things like failed attempts to authenticate on services may also act as a virus or worm attack indicator. Looking at inbound and outbound network traffic from unusual IP addresses, or known bad actor addresses, will also help in identifying malware patterns as they emerge and localizing any response activities.


One last word on malware prevention

While the CIS doesn't include this in the top five controls, I think Control 8 is19507441846_450dc547b7_b.jpg still one of the most important. Good malware prevention actually does as much to help other people as it does for you and your network; you're cutting down the rate of transmission and infection and helping reduce the threat created by the people who use malware to commit crimes. Robust malware prevention techniques and programs actively reduce the threat to legacy systems and "high risk" networks that can't patch their systems for one reason or another. Fighting malware requires that we treat it like measles or smallpox: vaccinate against it, clean up infections, and monitor populations at risk. While it's often inconvenient or difficult, the end result is safer computing for everyone.






Banner photo courtesy of the author- Safety notice from Angus Railyards (now a grocery store), Montreal.
Flu virus TEM image from Wikimedia Commons courtesy of the CDC's fantactic Public Health Image Library (PHIL)

Forestry Swing machine (and logs) in Kaibab National Forest, AZ also from Wikimedia commons.

Inoculation picture courtesy of The University of Victoria's Flickr feed, originally from The Montreal Star.

This post describes a vulnerability in Yopify (a plugin for various popular e-commerce platforms), as well as remediation steps that have been taken. Yopify leaks the first name, last initial, city, and recent purchase data of customers, all without user authorization. This poses a significant privacy risk for customers. This vulnerability is characterized as: CWE-213 (Intentional Information Disclosure).


Product Description

Yopify is a notification plugin for a variety of e-commerce platforms, including BigCommerce, WooCommerce, Shopify, and LemonStand. The product is produced by Centire, an IT company based in India. Yopify provides a feature where website visitors are, every few seconds, presented with a popup containing information about one of the last 50 purchases from the site, such as the one shown here:


Screen Shot 2017-03-21 at 10.02.28 PM.jpeg


The purported use case is that by demonstrating existing customer activity, it replicates the public bustle and hubbub of a real-world shop, and makes potential customers more engaged. As you can see, the example above contains personal information about the customer (first name, last initial, city).


The various plugin sites for major e-commerce platforms show over 300 reviews of Yopify, which suggests that the number of exploitable sites is at least in the hundreds, and perhaps thousands.



This vulnerability was discovered by Oliver Keyes, a Rapid7, Inc. senior data scientist. This advisory was prepared in accordance with Rapid7's vulnerability disclosure policy.



Yopify works by having the e-commerce site load a JavaScript widget from the Yopify servers, which contains both the code to generate the UI element and the data used to populate it, stored as JSON. This widget does not require any authorization beyond a site-specific API key, which is embedded in the e-commerce site's source code, and is easily extractable with a regular expression.


The result is that by scraping a customer site to grab the API key and then simply running something like:


curl ''


where `3edb675e08e9c7fe22d243e44d184cdf` is the site ID and `t` is a cache buster, someone can remotely grab the data pertaining to the last 50 customers. This is updated as purchases are made. Thus an attacker can poll every few hours for a few days/weeks/months and build up a database of an e-commerce site's customer set and associated purchasers.


The data exposed to this polling was, however, far more extensive than the data displayed. While the pop-up only provides first name and last initial, the JSON blob originally contained first and last names in their entirety, along with city-level geolocation. While the casual online customer wouldn't have seen that, a malicious technical user could have trivially gained enough information to potentially target specific users of specific niche e-commerce sites.


Vendor Statement

We were unaware of this security threat when we created the app, however have taken the necessary steps alongside Shopify and Rapid7 to come to a satisfactory resolution where users privacy exposure is reduced.



Minimally, we believe users should be asked if they want their name, location, and purchase information shown to complete strangers. Sending and display of the information should be off by default to protect customer privacy and safety.

On May 18, Yopify responded to the bug report by Base64-encoding the JSON blob. This obfuscation may stop some unsophisticated users from finding the information, but it is in no way encrypted. However, by May 20 Yopify did make an additional update and the client no longer receives the full last name even in the JSON, but only the first letter of the last name. This is an improvement as it does limit the exposure of user data, and makes identifying individuals more difficult.

However, as personal information is still sent and displayed, we recommend that until Yopify adds opt-in functionality, users with privacy concerns avoid using e-commerce sites with Yopify installed. Users will know it is installed given the frequent pop-ups displaying other customers' information when they browse an affected site. In addition, we encourage e-commerce store owners to request Yopify add this functionality, or remove the widget in order to protect their customers' privacy.


Disclosure Timeline

This vulnerability advisory was prepared in accordance with Rapid7's vulnerability disclosure policy.

  • Tue, Feb 28, 2017: Discovered by Rapid7's Oliver Keyes
  • Wed, Mar 22, 2017: Initial vendor contact (Yopify)
  • Thu, Mar 30, 2017: Additional vendor contact (Shopify), as no response received from Yopify yet
  • Thu, Mar 30, 2017: Response from Shopify
  • Fri, Mar 31, 2017: Details sent to, who forwarded information to Yopify
  • Wed, Apr 5, 2017: Additional vendor contact (Centire). Sent reminder to Yopify, and clarification/update to Shopify.
  • Fri, Apr 7, 2017: Additional disclosure to
  • Fri, Apr 7, 2017: Disclosed to CERT/CC
  • Fri, Apr 14, 2017: Reached back out to, no response
  • Wed, Apr 26, 2017: CVE-2017-3211 assigned by CERT/CC
  • Wed, May 17, 2017: Reached back out to Yopify and Centire
  • Thu, May 18, 2017: First response from Yopify; JSON Base64 encoding change deployed
  • Sat, May 20, 2017: Additional patch deployed by Yopify: full last name no longer sent to client, only first letter
  • Wed, May 31, 2017: Public disclosure

With the scent of scorched internet still lingering in the air from the WannaCry Ransomworm, today we see a new scary-and-potentially-incendiary bug hitting the twitter news. The vulnerability - CVE-2017-7494 - affects versions 3.5 (released March 1, 2010) and onwards of Samba, the defacto standard for providing Windows-based file and print services on Unix and Linux systems. Check out Samba's advisory for more details.


We strongly recommend that security and IT teams take immediate action to protect themselves.


Who is affected?

Many home and corporate network storage systems run Samba and it is frequently installed by default on many Linux systems, making it possible that some users are running Samba without realizing it. Given how easy it is to enable Samba on Linux endpoints, even devices requiring it to be manually enabled will not necessarily be in the clear.


Samba makes it possible for Unix and Linux systems to share files the same way Windows does. While the WannaCry ransomworm impacted Windows systems and was easily identifiable, with clear remediation steps, the Samba vulnerability will impact Linux and Unix systems and could present significant technical obstacles to obtaining or deploying appropriate remediations. These obstacles will most likely present themselves in situations where devices are unmanaged by typical patch deployment solutions or don’t allow OS-level patching by the user. As a result, we believe those systems may be likely conduits into business networks.


How bad is it?

The internet is not on fire yet, but there’s a lot of potential for it to get pretty nasty. If there is a vulnerable version of Samba running on a device, and a malicious actor has access to upload files to that machine, exploitation is trivial.


In a Project Sonar scan run today, Rapid7 Labs discovered more than 104,000 internet-exposed endpoints that appear to be running vulnerable versions of Samba on port 445. Of those, almost 90% (92,570) are running versions for which there is currently no direct patch available. In other words, “We're way beyond the boundary of the Pride Lands.” (sorry - we promise that’s the last Lion King reference. Maybe.)


Samba 445 major_minor_vulnerable_version_counts_updated.png

We’ve been seeing a significant increase in malicious traffic to port 445 since May 19th; however, the recency of the WannaCry vulnerability makes it difficult for us to attribute this directly to the Samba vulnerability. It should be noted that proof-of-concept exploit code has already appeared on Twitter, and we are seeing Metasploit modules making their way into the community.


We will continue to scan for potentially vulnerable endpoints and will provide an update on numbers in the next few days.


RESEARCH UPDATE – 5/25/17We have now run a scan on port 139, which also exposes Samba endpoints. We found very similar numbers to those for the scan of port 445. On port 139, we found approximately 110,000 internet-exposed endpoints running vulnerable versions of Samba. Of these, about 91% (99,645) are running older, unsupported versions of Samba (pre-4.4).


Samba 139 major_minor_vulnerable_version_counts_updated.png



What should you do to protect yourself?

The makers of Samba have provided a patch for versions 4.4 onwards.


A workaround for unsupported and vulnerable older versions (3.5.x to 4.4.x) is available, and that same workaround can also be used for supported versions that cannot upgrade. We also recommend that users of older, affected versions upgrade to a more recent, supported version of Samba (4.4 or later) and then apply the available patch.


Organizations should be reviewing their official asset and configuration management systems to immediately identify vulnerable systems and then perform comprehensive and regular full network vulnerability scans to identify misconfigured or rogue systems. Additionally, organizations should review their firewall rules to ensure that SMB/Samba network traffic is not allowed directly from the internet to their assets.


Many network-attached storage (NAS) environments are used as network backup systems. A direct attack or worm would render those backups almost useless, so if patching cannot be done immediately, we recommend creating an offline copy of critical data as soon as possible.


In addition, organizations should be monitoring all internal and external network traffic for increases in connections or connection attempts to Windows file sharing protocols.


How can Rapid7 help?

We are working on checks for Rapid7 InsightVM and Rapid7 Nexpose so customers can scan their environments for vulnerable endpoints and take mitigating action as quickly as possible.


We also expect a module in the Metasploit Framework very soon, enabling security professionals to test the effectiveness of their mitigations, and understand the potential impact of exploitation.


We will notify users of the availability of these solutions as soon as they are available.


PRODUCT UPDATE – 5/25/17 We have authenticated checks available for Samba CVE-2017-7494 in Rapid7 InsightVM and Rapid7 Nexpose.  The authenticated checks relate to vendor-specific fixes as follows:

  • ubuntu-cve-2017-7494
  • debian-cve-2017-7494
  • freebsd-cve-2017-7494
  • oracle_linux-cve-2017-7494
  • redhat_linux-cve-2017-7494
  • suse-cve-2017-7494


PRODUCT UPDATE 2 – 5/25/17 – We now have both authenticated and unauthenticated remote checks in Rapid7 InsightVM and Rapid7 Nexpose. In the unauthenticated cases we use anonymous or guest login to gather the required information, and on systems that are hardened against that kind of login, the authenticated remote check is available.


Not a Rapid7 customer? Scan your network with InsightVM to understand the impact this vulnerability has on your organization. We also have a step-by-step guide on how to scan for Samba CVE-2017-7494 using our vulnerability scanners.


PRODUCT UPDATE 3 - 5/25/17 - We now have a Metasploit module available for this vulnerability, so you can see whether you can be exploited via Samba CVE-2017-7494, and understand the impact of such an attack. Download Metasploit to try it out.


P.S. yes, we know the lion is called Simba. But who doesn't love a gratuitous and tenuous cartoon lion reference?! Rowr.

This blog is a continuation of our blog post series around the CIS Critical Controls.


The biggest threat surface in any organization is its workstations. This is the reason so many of the CIS Critical Security Controls relate to workstation and user-focused endpoint security. It is also the reason that workstation security is a multibillion-dollar industry. For the next two posts, I’ll be covering the specifics of Controls 7 and 8, which focus on the biggest weak points in Information Security: web browsers, email, and malware. This set of posts is intended to help you understand how to properly control the threat surface without limiting usability.


Email and web access are critical for most day-to-day operations in any organization, but they’re also a significant source of attacks and incidents. Properly securing email servers, web browsers, and mail clients can go an extremely long way in limiting incidents that routinely make news headlines. Good configuration and control of email and web browsers is also going to significantly reduce the number of low-level incidents your organization will encounter on a monthly basis.


What the CIS Critical Control 7 covers

Critical Control 7 has eight sections that cover the basics of browser and email client safety, secure configuration and mail handling at the server level. The control pays specific attention to concepts like scripting and active component limiting in browsers and email clients, attachment handling, configuration, URL logging, filtering and whitelisting. The premise of the control is fairly straightforward: browser and email client security are critically important for low-level risk mitigation. If your browsers and email aren’t secure, your users and your network aren’t either.

It’s worth noting that this control as well as Controls 1, 2 and 8 are often directly connected, and tie into quite a few of the other 20 pretty easily. As I mentioned in the posts for Controls 1 and 2, properly implemented browser and email security will improve any organizations security posture with regards to the other controls.


How To Implement it

Since this control touches on a number of typically different IT functions, it’s important to have the people who run the various systems implicated on board when working with it. Personally, I love dealing with controls like this, as they have the potential to unify an IT or IT/IS department in terms of strategy and process, which always helps improve security awareness and capacity.


Start with filtering

Successful implementations of Control 7 usually work from two sides: the server/network side and the endpoint configuration/application side. Networking and email server teams should start by limiting how attachments are handled and forwarded from the mail server to clients, and implement content filtering first. In many cases, this is already set up on mail servers for purposes of space management or security, but it’s worthwhile to go a step further and ensure that potentially malicious content is being filtered before it reaches any user’s inboxes.


Implement SPF, or something similar

At the same time, implementing Sender Policy Framework at a DNS level and on the mail servers should cut down on the amount of spam and malicious traffic that is coming in to the system. It should be noted that while SPF is not an anti-spam measure, it's effective as a control for malicious mail traffic. It’s important that the SPF records and implementation include receiver-side verification (this is actually directly mentioned in sub-control7.7). Typically, this section of Control 7 is overlooked, as it's a high-effort measure, but it's worthwhile for a number of reasons, including SMTP traffic reduction, better junk mail sorting, compatibility with other services, and a general reduction in those "I didn't send a message to this person, but I'm being notified that I did" conversations with your colleagues.


It's also worth noting that there are a few pitfalls in implementing it. has a good overview of SPF best practices, which should serve as a good starting point. While the CIS recommends SPF, there are alternative systems and strategies. I'd suggest looking into DKIM and DMARC, since they work well in combination with SPF although they're not directly mentioned in the CIS Critical Control 7. If you're using a third-party provider for e-mail, it's assessing this with their personnel; they may have extra expertise on hand, or have done it already.


Configure all the things!

By far, the hardest part of this control is managing the browsers and clients on your network. It’s inevitable that there will be roadblocks, but the good news is that there are a number of good ways to handle browser configuration that should both enable your users, and limit the risks from 3908396264_351e7f2ae6.jpgmalicious code in websites (and any attachments that do get through your already iron-clad email server). Typically, Rapid7 recommends that workstations have a “2 browser” system- one should be well secured, and seriously limit access for third-party scripting, ads, and any software that hasn’t been reviewed by the security team. The second should be used for general Internet access, and anything that is considered remotely risky.


The other configuration should usually be less secure, but limited in use to internal or organization specific services. Usually, this means script based applications or software that require old, out of date or insecure code and components. For example, if your corporate intranet relies on Flash and ActiveX scripts to manage employee benefits, it’s probably a good idea to set up a browser so that your users access the intranet with a specially configured browser for that task. This can be as simple as putting a link or batch file on workstation desktops with specific startup info for the browser, or leaving the homepage set to the specific resource in question. I’ve seen more complex configurations that rely on secure jumphosts, Citrix, or remote desktop and network limitations, but these are often cumbersome for most users, and not recommended.


One last bit of advice

The simple axiom to follow when implementing this control is: You need to make it simple for the users, or they will find a way around it. It's important to consider this when applying controls 7 and 8, because increasing complexity or the effort your users have to put in often leads to privilege misuse or other workarounds to defeat the controls. In this context, it's worth remembering that human error is still the major source of most breaches and incidents. This includes phishing and clickjacking campaigns, which often foil the best of us, despite well configured systems.


A note on URL requests, privacy and security

Subcontrol 7.4 specifically identifies URL request logging as a necessity for the identification of potentially compromised systems. This subcontrol actually overlaps with Critical Control 6, which Cindy Jones discussed in an earlier post. While it’s important to have this data for incident response and awareness purposes, it’s worth considering how long it’s kept, and how it’s managed; it’s extremely important that the request logs are considered private or limited-access data, and aren’t being shared in a way that could put users of your network at risk. This also applies to any TLS or encrypted traffic monitoring that you may be undertaking.


SPF diagram courtesy of

"Double Fail" image courtesy of Dmitry Baranovskiy via Flickr

Arapahoe Basin and ski poles banner courtesy of the author. As with security, proper configuration is often what makes or breaks good skiing.


Related Blog Posts:

Control 1: Inventory of Authorized and Unauthorized Devices Explained

Control 2: Inventory of Authorized and Unauthorized Software Explained

Control 3: Secure Configurations for Hardware & Software Explained

Control 4: Continuous Vulnerability Assessment & Remediation Explained

Control 5: Controlled Use of Administrative Privilege Explained

Control 6: Maintenance, Monitoring and Analysis of Audit Logs Explained

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.



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.








Insecure Sensor Fail OpenADTR7-2016-26.1CVE-2016-6570Mitigated by sensor placement
Weak WPA2 Pre-Shared KeyADTR7-2016-26.2CVE-2016-6571Fixed
Cleartext WLAN CommunicationsADTR7-2016-26.3CVE-2016-6572Mitigated by R7-2016-26.2
Insecure Sensor Fail OpenAT&T Digital LifeR7-2016-27.1CVE-2016-6573Mitigated by sensor placement
Default physical access administrative credentialsAT&T Digital LifeR7-2016-27.2CVE-2016-6574Fixed
Insecure Network Administrative AccessAT&T Digital LifeR7-2016-27.3CVE-2016-6575Mitigated by R7-2016-27.2
Cleartext WLAN CommunicationsAT&T Digital LifeR7-2016-27.4CVE-2016-6576Mitigated by R7-2016-27.2
Cleartext Credential Storage and DisplayAT&T Digital LifeR7-2016-27.5CVE-2016-6577Mitigated by R7-2016-27.2
Weak WPA2 Pre-Shared KeyComcast XFINITYR7-2016-23.1CVE-2016-6568Fixed
Cleartext WLAN CommunicationsComcast XFINITYR7-2016-23.2CVE-2016-6569Mitigated 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.


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.


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.


Figure 1: Identifying associated devices

Once identified, the attacker can then deauthenticate one of the cameras, as shown in Figure 2.


Figure 2: Deauthenticating an identified device

Doing this allows the attacker to capture the WPA2 handshake, which is then subjected to cracking with Aircrack-ng, as shown in Figure 3.


Figure 3: Bruteforce cracking of the WPA2 pre-shared key

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.


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.


Figure 4: ARP spoofing to recover the Base64 credentials

The attacker can then reuse these credentials to log in the cameras directly and access live video feeds, as seen in Figure 5.


Figure 5: Direct video feed of the researcher's residence (and cat)


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.


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 ( 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.


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.


Figure 6: Front door armed state


Figure 7: Disarming the front door sensor


Figure 8: Front door sensor is disarmed


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.


Figure 9: Basic Authorization header collection


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.


Figure 10: Browsing to stored credentials


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.


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:


Figure 11: Identifying associated devices

Once identified, the attacker can then deauthenticate one of the cameras, as shown in Figure 12:


Figure 12: Capturing the WPA2 handshake

Doing this allows the attacker to capture the WPA2 handshake, which is then cracked using aircrack-ng, as shown in Figure 13:


Figure 13: Bruteforce cracking of the WPA2 pre-shared key

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.


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.


Figure 14: ARP Spoofing to capture Base64 credentials

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.


Figure 15: Video capture from the researcher's residence

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.


Figure 16: ARP spoofing the router

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.


Figure 17: Changing DNS addresses


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.




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.

Filter Blog

By date: By tag: