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

Information Security

767 posts

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.

WannaCry Overview

Last week the WannaCry ransomware worm, also known as Wanna Decryptor, Wanna Decryptor 2.0, WNCRY, and WannaCrypt started spreading around the world, holding computers for ransom at hospitals, government offices, and businesses. To recap: WannaCry exploits a vulnerability in the Windows Server Message Block (SMB) file sharing protocol. It spreads to unpatched devices directly connected to the internet and, once inside an organization, those machines and devices behind the firewall as well. For full details, check out the blog post: Wanna Decryptor (WannaCry) Ransomware Explained.


Since last Friday morning (May 12), there have been several other interesting posts about WannaCry from around the security community. Microsoft provided specific guidance to customers on protecting themselves from WannaCry. MalwareTech wrote about how registering a specific domain name triggered a kill switch in the malware, stopping it from spreading. Recorded Future provided a very detailed analysis of the malware’s code.


However, the majority of reporting about WannaCry in the general news has been that while MalwareTech’s domain registration has helped slow the spread of WannaCry, a new version that avoids that kill switch will be released soon (or is already here) and that this massive cyberattack will continue unabated as people return to work this week.


In order to understand these claims and monitor what has been happening with WannaCry, we have used data collected by Project Sonar and Project Heisenberg to measure the population of SMB hosts directly connected to the internet, and to learn about how devices are scanning for SMB hosts.


Part 1: In which Rapid7 uses Sonar to measure the internet

Project Sonar regularly scans the internet on a variety of TCP and UDP ports; the data collected by those scans is available for you to download and analyze at WannaCry exploits a vulnerability in devices running Windows with SMB enabled, which typically listens on port 445. Using our most recent Sonar scan data for port 445 and the recog fingerprinting system, we have been able to measure the deployment of SMB servers on the internet, differentiating between those running Samba (the Linux implementation of the SMB protocol) and actual Windows devices running vulnerable versions of SMB.


We find that there are over 1 million internet-connected devices that expose SMB on port 445. Of those, over 800,000 run Windows, and — given that these are nodes running on the internet exposing SMB — it is likely that a large percentage of these are vulnerable versions of Windows with SMBv1 still enabled (other researchers estimate up to 30% of these systems are confirmed vulnerable, but that number could be higher).


We can look at the geographic distribution of these hosts using the following treemap (ISO3C labels provided where legible):

fig1.png[ Figure 1 ]


The United States, Asia, and Europe have large pockets of Windows systems directly exposed to the internet while others have managed to be less exposed (even when compared to their overall IPv4 blocks allocation).


We can also look at the various versions of Windows on these hosts:

fig2.png[ Figure 2 ]


The vast majority of these are server-based Windows operating systems, but there is also a further unhealthy mix of Windows desktop operating systems in the mix—, some quite old. The operating system version levels also run the gamut of the Windows release history timeline:

fig3.png[ Figure 3 ]


Using Sonar, we can get a sense for what is out there on the internet offering SMB services. Some of these devices are researchers running honeypots (like us), and some of these devices are other research tools, but a vast majority represent actual devices configured to run SMB on the public internet. We can see them with our light-touch Sonar scanning, and other researchers with more invasive scanning techniques have been able to positively identify that infection rates are hovering around 2%.


Part 2: In which Rapid7 uses Heisenberg to listen to the internet

While Project Sonar scans the internet to learn about what is out there, Project Heisenberg is almost the inverse: it listens to the internet to learn about scanning activity. Since SMB typically runs on port 445, and the WannaCry malware scans port 445 for potential targets, if we look at incoming connection attempts on port 445 to Heisenberg nodes as shown in Figure 4, we can see that scanning activity spiked briefly on 2017-05-10 and 2017-05-11, then increased quite a bit on 2017-05-12, and has stayed at elevated levels since.


incoming-connections.png[Figure 4]


Not all traffic to Heisenberg on port 445 is an attempt to exploit the SMB vulnerability that WannaCry targets (MS17-010). There is always scanning traffic on port 445 (just look at the activity from 2017-05-01 through 2017-05-09), but a majority of the traffic captured between 2017-05-12 and 2017-05-14 was attempting to exploit MS17-010 and likely came from devices infected with the WannaCry malware. To determine this we matched the raw packets captured by Heisenberg on port 445 against sample packets known to exploit MS17-010.


Figure 5 shows the number of unique IP addresses scanning for port 445, grouped by hour between 2017-05-10 and 2017-05-16. The black line shows that at the same time that the number of incoming connections increases (2017-05-12 through 2017-05-14), the number of unique IPs addresses scanning for port 445 also increases. Furthermore, the orange line shows the number of new, never- before- seen IPs scanning for port 445. From this we can see that a majority of the IPs scanning for port 445 between 2017-05-12 and 2017-05-14 were new scanners.


unique-source-ips.png[ Figure 5 ]


Finally, we see scanning activity from 157 different countries in the month of May, and scanning activity from 133 countries between 2017-05-12 and 2017-05-14. Figure 6 shows the top 20 countries from which we have seen scanning activity, ordered by the number of unique IPs from those countries.


ips-by-country.png[ Figure 6 ]


While we have seen the volume of scans on port 445 increase compared to historical levels, it appears that the surge in scanning activity seen between 2017-05-12 and 2017-05-14 has started to tail off.


So what?

Using data collected by Project Sonar we have been able to measure the deployment of vulnerable devices across the internet, and we can see that there are many of them out there. Using data collected by project Heisenberg, we have seen that while scanning for devices that expose port 445 has been observed for quite some time, the volume of scans on port 445 has increased since 2017-05-12, and a majority of those scans are specifically looking to exploit MS17-010, the SMB vulnerability that the WannaCry malware looks to exploit.


MS17-010 will continue to be a vector used by attackers, whether from the WannaCry malware or from something else. Please, follow Microsoft’s advice and patch your systems. If you are a Rapid7 InsightVM or Nexpose customer, or you are running a free 30 day trial, here is a step by step guide on on how you can scan your network to find all of your assets that are potentially at risk for your organization.


Coming Soon

If this sort of information about internet wide measurements and analysis is interesting to you, stay tuned for the National Exposure Index 2017. Last year, we used Sonar scans to evaluate the security exposure of all the countries of the world based on the services they exposed on the internet. This year, we have run our studies again, we have improved our methodology and infrastructure, and we have new findings to share.



Basics of Cyber Threat Intelligence

Cyber Threat Intelligence is analyzed information about the opportunities, capabilities, and intent of cyber adversaries. The goal of cyber threat intelligence is to help people make decisions about how to prevent, detect, and respond to threats against their networks. This can take a number of forms, but the one people almost always turn to is IOCs. IOCs, or indicators of compromise, are technical network artifacts that can alert a defender that their system is compromised. These include things like IP addresses, domain names, hashes, file names, etc. IOCs are often a good way to detect malicious activity, but they are not the only output of threat intelligence, and often they are not the best output.


Threat Intelligence for WannaCry

In the case of WannaCry (get an overview of the WannaCry vulnerability here) – the primary IOCs available are the hashes and file names of the ransomware samples. By the time you alert on those on your system, it is already too late: the system is already being encrypted. WannaCry also uses a cryptographic loading mechanism that prevents the malicious DLL from ever touching the disk, which means that antivirus will not detect or block it. The hashes are useful from a research perspective, such as identifying new variants or tracking changes to the malware, but they are not useful for detection.


Likewise, there are a few blogs that have published IP addresses that are related to the campaign, but have not provided information as to the nature of those IPs. This makes it hard to know how to handle them or use them in incident detection and response scenarios. Many of the IPs associated with WannaCry are so associated because they have been seen scanning for port 445. We know that WannaCry must scan for that port to identify systems to compromise; however, Wanna Cry is not the only thing that scans the internet, and blocking or alerting on scanning IPs will create a large number of false positives.


The kill switch domain is a good indicator that you have compromised systems on your network that should be remediated. Contact with this domain - which should be allowed to prevent encryption! – can be used as a way to track what systems are compromised and launch investigations accordingly. It is not a prevention method, but it can help identify hosts compromised with this variant. The InsightIDR threat community has a threat list that will alert (but not block) this domain to assist with identification of compromised hosts.


A Better Approach


IOC-based threat intelligence is not the best approach for dealing with WannaCry—a vulnerability-based approach is. The best indicator that you will be compromised is whether or not you are vulnerable to the ETERNAL BLUE exploit that WannaCry uses as an initial attack vector. One researcher put a SMB honeypot up with port 445 open and was exploited in less than 3 minutes. With the way that WannaCry is spreading, if you are vulnerable, you will be compromised. Ensuring that all of your systems are patched, port 445 is not open to the internet, and network segmentation is in place are all far better things to focus on than finding IOCs for WannaCry.


For information on how to scan for, and remediate, MS17-010 with Nexpose and InsightVM, please read this blog.


WannaCry is Just the Beginning...

The reality is that we're likely to see more attacks leveraging this attack vector.


The basic equation for threats is as follows:

Threat = opportunity + capability + intent


Screen Shot 2017-05-15 at 7.35.41 PM.png


For the WannaCry Ransomworm, the equation looks like this:


WannaCry = Unpatched flaw in SMB + ETERNAL BLUE with ransomware and worming capabilities + Desire for $$$


But we have an almost unending list of potential threats, since the opportunity and capability are both public. It is almost guaranteed that we will see other threats where:


Opportunity = Unpatched flaw in SMB

Capability = Some variation of ETERNAL BLUE

Intent = Money, power, chaos, revenge, etc.


We can monitor for new capabilities that are being developed, we can brainstorm potential threat actor intents to understand whom the threat may target, but what will remain the same across all of these threats is the opportunity that the attacks have. If we can remove that opportunity then the threats will not exist, and will become an insubstantial threat, as the attackers will have no way to leverage their capabilities.


Want to learn more? Visit our resource page filled with relevant information around WannaCry.

Mark the date: May 12, 2017.


This is the day the “ransomworm” dubbed “WannaCry” / “Wannacrypt” burst — literally — onto the scene with one of the initial targets being the British National Health Service. According to The Guardian: the “unprecedented attack… affected 12 countries and at least 16 NHS trusts in the UK, compromising IT systems that underpin patient safety. Staff across the NHS were locked out of their computers and trusts had to divert emergency patients.” A larger estimate by various cybersecurity firms indicates that over 70 countries have been impacted in some way by the WannaCry worm. As of this post's creation time, a group with the Twitter handle @0xSpamTech has claimed responsibility for instigating the attack but this has not yet been confirmed.


What is involved in the attack, what weakness(es) and systems does it exploit, and what can you do to prevent or recover from this attack? The following sections will dive into the details and provide guidance on how to mitigate the impact from future attacks.


What is "Ransomware"?


“malicious software which covertly encrypts your files – preventing you from accessing them – then demands      payment for their safe recovery. Like most tactics employed in cyberattacks, ransomware attacks can occur after      clicking on a phishing link or visiting a compromised website.” (


However, WannaCry ransomware deviates from the traditional ransomware definition by including a component that is able to find vulnerable systems on a local network and spread that way as well. This type of malicious software behavior is called a “worm” and the use of such capabilities dates back to 1988 when the Morris Worm spread across the internet (albeit a much smaller neighborhood at the time).


Because WannaCry combines two extremely destructive capabilities, it has been far more disruptive and destructive than previous cases of ransomware that we’ve seen over the past 18-24 months.


While the attackers are seeking ransom — you can track payments to their Bitcoin addresses:

  • 115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn
  • 12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw
  • 13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94

here: there have been reports of this also corrupting drives, adding a destructive component as well as a ransom-recovery component to the attack.


What Systems Are Impacted?

WannaCry only targets Microsoft Windows systems and is known to impact the following versions:

  • Microsoft Windows Vista SP2
  • Windows Server 2008 SP2 and R2 SP1
  • Windows 7
  • Windows 8.1
  • Windows RT 8.1
  • Windows Server 2012 and R2
  • Windows 10
  • Windows Server 2016
  • Windows XP


However, all versions of Windows are likely vulnerable and on May 13, 2017 Microsoft issued a notification that included links to patches for all impacted Windows operating systems — including Windows XP.

As noted, Windows XP is impacted as well. That version of Windows still occupies a 7-10% share of usage (as measured by NetMarketshare):


and, this usage figure likely does not include endpoint counts from countries like China, who have significant use of “aftermarket” versions of Windows XP and other Windows systems, making them unpatchable.

The “worm” component takes advantage of a Remote Code Execution (RCE) vulnerability that is present in the part of Windows that makes it possible to share files over the network (known as “Server Message Block” or SMB). Microsoft released a patch -MS17-010 - for this vulnerability on March 14th, 2017 prior to the release of U.S. National Security Agency (NSA) tools (EternalBlue / DoublePulsar) by a group known as the the Shadow Brokers. Rapid7’s Threat Intelligence Lead, Rebekah Brown, wrote a breakdown of this release in a blog post in April.


Vulnerability detection tools, such as Rapid7’s Metasploit, have had detection capabilities for this weakness for a while, with the most recent Metasploit module being updated on April 30, 2017.

This ransomworm can be spread by someone being on public Wi-Fi or an infected firm’s “guest” WiFi and then taking an infected-but-not-fully-encrypted system to another network. WannaCry is likely being spread, still, by both the traditional phishing vector as well as this network worm vector.


What Can You Do?

  • Ensure that all systems have been patched against MS17-010 vulnerabilities.
  • Identify any internet-facing systems that have not been patched and remediate as soon as possible.
  • 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.


NOTE: The Rapid7 Managed Detection & Response (MDR) SOC has developed detection indicators of compromise (IOCs) for this campaign, however we are only alerted once the malware executes on a compromised system. This is not a mitigation step.


UPDATE - May 15, 2017: For information on how to scan for, and remediate, MS17-010 with Nexpose and InsightVM, please read this blog.


A Potentially Broader Impact

We perform regular SMB scans as a part of Project Sonar and detected over 1.8 million devices responding to full SMB connection in our May 3, 2017 scan:

Some percentage of these systems may be Linux/UNIX servers emulating the SMB protocol but it’s likely that a large portion are Windows systems. Leaving SMB (via TCP port 445) open to the internet is also a sign that these systems are not well maintained, and are also susceptible to attack.


Rapid7’s Heisenberg Cloud — a system of honeypots spread throughout the internet — has seen a recent spike in probes for systems on port 445 as well:



Living With Ransomware

Ransomware has proven to be an attractive and lucrative vector for cybercriminals. As stated previously, backups, along with the ability to quickly re-provision/image an impacted system, are your only real defenses. Rapid7 has additional resources available for you to learn more about dealing with ransomware:


If you’d like more information on this particular ransomworm as seen by Project Sonar or Heisenberg Cloud, please contact research [at] rapid7 [dot] com.


Many thanks to the many contributors across Rapid7 who provided vital information and content for this post.


For more information and resources on WannaCry and ransomware, please visit this page.

Yesterday President Trump issued an Executive Order on cybersecurity: “Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure.”


The Executive Order (EO) appears broadly positive and well thought out, though it is just the beginning of a long process and not a sea change in itself. The EO directs agencies to come up with plans for securing and modernizing their networks; develop international cyber norms; work out a deterrence strategy against hacking; and reduce the threat of botnets – all constructive, overdue goals. Below are an overview, a highlight reel, and some additional takeaway thoughts.


Cybersecurity Executive Order Overview

Executive orders are issued only by the President, direct the conduct of executive branch agencies (not the private sector, legislature, or judiciary), and have the force of law. All public (not classified) EOs are published here. This cyber EO is the first major move the Trump White House (as distinct from other federal agencies) has made publicly on cybersecurity.


The cyber Executive Order takes action on three fronts:

  1. Federal network security. Directs agencies to take a risk management approach, adopt the NIST Framework, and favor shared services and consolidated network architectures (including for cloud and cybersecurity services).
  2. Protecting critical infrastructure. Directs agencies to work with the private sector to protect critical infrastructure, incentivize more transparency on critical infrastructure cybersecurity, improve resiliency of communication infrastructure, and reduce the threat of botnets.
  3. National preparedness and workforce development. Directs agencies to assess strategic options for deterring and defending against adversaries. Directs agencies to report their international cybersecurity priorities, and to promote international norms on cybersecurity.


Cybersecurity Executive Order Highlights

  • Federal network cybersecurity:
    • The US will now manage cyber risks as an executive branch enterprise. The President is holding cabinet and agency heads accountable for implementing risk management measures commensurate with risks and magnitude of harm. [Sec. 1(c)(i)]
    • Agencies are directed to immediately use the NIST Framework for Improving Critical Infrastructure Cybersecurity (NIST Framework) to manage their cyber risk. [Sec. 1(c)(ii)]
    • DHS and OMB must report to the President, within 120 days, a plan to secure federal networks, address budgetary needs for cybersecurity, and reconcile all policies and standards with the NIST Framework. [Sec. 1(c)(iv)]
    • Agencies must now show preference for shared IT services (including cloud and cybersecurity services) in IT procurement. [Sec. 1(c)(vi)(A)] This effort will be coordinated by the American Technology Council. [Sec. 1(c)(vi)(B)]
    • The White House, in coordination with DHS and other agencies, must submit a report to the President, within 60 days, on modernizing federal IT, including transitioning all agencies to consolidated network architectures and shared IT services – with specific mention of cybersecurity services. [Sec. 1(c)(vi)(B)-(C)] Defense and intel agencies must submit a similar report for national security systems within 150 days. [Sec. 1(c)(vii)]


  • Critical infrastructure cybersecurity:
    • Critical infrastructure includes power plants, oil and gas, financial system, other systems that would risk national security if damaged. The EO states that it is the government’s policy to use its authorities and capabilities to support the cybersecurity risk management of critical infrastructure. [Sec. 2(a)]
    • The EO directs DHS, DoD, and other agencies to assess authorities and opportunities to coordinate with the private sector to defend critical infrastructure. [Sec. 2(b)]
    • DHS and DoC must submit a report to the President, within 90 days, on promoting market transparency of cyber risk management practices by critical infrastructure operators, especially those that are publicly traded. [Sec. 2(c)]
    • DoC and DHS shall work with industry to promote voluntary actions to improve the resiliency of internet and communications infrastructure and “dramatically" reduce the threat of botnet attacks. [Sec. 2(d)]
    • Agencies shall assess cybersecurity risks and mitigation capabilities related to the electrical sector and the defense industrial base (including supply chain). [Sec. 2(e)-(f)]


  • National preparedness and workforce:
    • The EO reiterates the US government’s commitment to an open, secure Internet that fosters innovation and communication while respecting privacy and guarding against disruption. [Sec. 3(a)]
    • Cabinet members must submit a report to the President, within 90 days, on options for deterring adversaries and protecting Americans from cyber threats. [Sec. 3(b)]
    • Cabinet members must report to the President, within 45 days, on international cybersecurity priorities, including investigation, attribution, threat info sharing, response, etc. The agencies must report to the President, within 90 days, on a strategy for international cooperation in cybersecurity. [Sec. 3(c)]
    • Agencies must report to the President, within 120 days, how to grow and sustain a workforce skilled in cybersecurity and related fields. [Sec. 3(d)(i)]
    • The Director of National Intelligence must report to the President, within 60 days, on workforce development practices of foreign peers to compare long-term competitiveness in cybersecurity. [Sec. 3(d)(ii)] Agencies must report to the President, within 150 days, on US efforts to maintain advantage in national-security-related cyber capabilities. [Sec. 3(d)(iii)]


The Executive Order is just the start

As you can see, the EO initially requires a lot of multi-agency reports, which we can expect to surface in coming months, and which can then be used to craft official policy. There are opportunities for the private sector to provide input to the agencies as they develop those reports, though the 2-4 month timelines are pretty tight for such complex topics. But the reports are just the beginning of long processes to accomplish the goals set forth in the EO - it will take a lot longer than 60 days, for example, to fully flesh out and implement a plan to modernize federal IT. The long haul is beginning, and we won't know how transformative or effective this process will be for some time.


Thankfully, contrary to prior rumors, the EO does not over-expand the role of DoD in securing national networks, nor does the EO call for an expansion of government authority over the private sector (although the reports agencies must produce under the EO may call for new authorities). However, the EO also does not directly touch on important topics such as data breach, IoT insecurity, support for strong encryption, vuln disclosure, or unfilled critical appointments (such as a national CTO). Rapid7 applauds the effort toward enforcing enhanced security to better protect organizations, infrastructure, and individuals through the EO, though we hope to see further consideration on other key cybersecurity issues in the future.

Filter Blog

By date: By tag: