UNITED Summit: Day 2

Cisco Smart Install (SMI) provides configuration and image management capabilities for Cisco switches. Cisco’s SMI documentation goes into more detail than we’ll be touching on in this post, but the short version is that SMI leverages a combination of DHCP, TFTP and a proprietary TCP protocol to allow organizations to deploy and manage Cisco switches. Using SMI yields a number of benefits, chief among which is the fact that you can place an unconfigured Cisco switch into an SMI-enabled (and previously configured) network and it will get the correct image and configuration without needing to do much more than wiring up the device and turning it on. Simple “plug and play” for adding new Cisco switches. But, with the great power and heightened privileges comes great responsibility, and that remains true with SMI. Since its first debut in 2010, SMI has had a handful of vulnerabilities published, including one that led to remote code execution (CVE-2011-3271) and several denial of service issues (CVE-2012-0385, CVE-2013-1146, CVE-2016-1349, CVE-2016-6385). Things got more interesting for SMI within the last year when Tenable Network Security, Daniel Turner of Trustwave SpiderLabs, and Alexander Evstigneev and Dmitry Kuznetsov of Digital Security disclosed a number of security issues in SMI during their presentation at the 2016 Zeronights security conference. Five issues were reported, the most severe of which easily rated as CVSS 10.0, if risk scoring is your thing. Or, put more bluntly, if you leave SMI exposed and unpatched and have not followed Cisco’s recommendations for securing SMI, effectively everything about that switch is at risk for compromise. Things get even more gnarly quickly when you consider what a successful attack against a Cisco switch exposing SMI would get an attacker. Even an otherwise well-protected network could be compromised if a malicious actor could arbitrarily reroute a target’s traffic at will. In direct response to last year’s research, Cisco issued a security response hoping to put the issue of SMI security to bed once and for all. They effectively claim that these issues are not vulnerabilities, but rather “misuse of the protocol”, even while encouraging customers to disable SMI if it was not in use. True, this largely boils down to a lack of authentication both in some of the underlying protocols (DHCP and TFTP) as well as SMI itself, which is a key part of achieving the aforementioned installation/deployment simplicities. However, every SMI-related security advisory published by Cisco has included recommendations to disable SMI unless needed. Most recently, they’ve provided various coverage for SMI abuse across their product lines, updated the relevant documentation that details how to properly secure SMI, and released a scanning tool for customers to use to determine if their networks are affected by these SMI issues. To further help Cisco customers secure their switching infrastructure, they’ve also made available several SMI related hardening fixes: CSCvd36820 automatically disables SMI if not used during bootup CSCvd36799 if SMI is enabled it must show in the running config CSCvd36810 periodically alerts to the console if SMI is enabled Ultimately, whether we call this protocol a vulnerability or a feature, exposed SMI endpoints present a very ripe target to attackers. And this is where things get even more interesting. Given that up until recently there was no Cisco provided documentation on how to secure SMI and no known tools for auditing SMI, it was entirely possible that scores of Cisco switches were exposing SMI in networks they shouldn’t be without the knowledge of the network administrators tasked with managing them. Sure enough, a preliminary scan of the public IPv4 Internet by these same original SMI researchers showed 251,801 systems exposing SMI and seemingly vulnerable to some or all of the issues they disclosed. The Smart Install Exploit Tool (SIET) was released to help identify and interact with exposed SMI endpoints, which includes exploit code for a variety of the issues they disclosed. As part of Cisco’s response to this research, they indicated that the SIET tool was suspected in active attacks against organizations’ networks. A quick look through Rapid7 Labs’ Project Heisenberg for 2017 shows only minimal background network noise on the SMI port and no obvious large-scale scanning efforts, though this does not rule out the possibility of targeted attacks. As with many situations like this in security, it's like a case of “if you build it, they will come” gone wrong, almost a “if you design it, they’ll misuse it.” There are any number of ways a human or a machine could mistakenly deploy or forget to secure SMI. Until recently, SMI had little mention in documentation, and, as evidenced by the three SMI related hardening fixes, it was difficult for customers to identify that they were even using SMI in the first place. Plus, even in the presence of a timely patching program, any organization exposing SMI to hostile networks but failing to do their security due diligence are easy targets for deep compromise. To top it all off, by following the recommended means of securing SMI when it is actually being used for deployment, you must add specific ACLs to control who can speak to SMI enabled devices, thereby severely crippling the ease of use that SMI was supposed to provide in the first place. With all of this in mind, we decided to reassess the public Internet for exposure of SMI with several questions in mind: Have things changed since the publication of the SMI research in 2016 and the resulting official vendor response in 2017? Are there additional clues that could explain why SMI is being exposed insecurely? Can Rapid7 assist? The methodology we used to assess public Internet for SMI exposure is almost identical to what the Zeronights researchers used in 2016, except that after the first-pass zmap scan to locate supposedly open SMI 4786/TCP endpoints, we utilized the logic demonstrated in Cisco’s smi_check to determine if the endpoint actually spoke the SMI protocol. Our study found ~3.2 million open 4786/TCP endpoints, the vast majority of which are oddly deployed SSH, HTTP and other services, as well as security devices. It is worth noting that while the testing methodologies between these two scans appear nearly identical, both are relying on possibly limited public knowledge about the proprietary SMI protocol. Future research may yield additional methods of identifying SMI. Using the same logic as in smi_check, we identified 219,123 endpoints speaking SMI in July and 215,317 endpoints in a subsequent scan in August 2017. Answering our first question, we see there was a ~13% drop in the number of exposed SMI endpoints between the Zeronights researcher’s original study and Rapid7 Labs’ Sonar scan in July of 2017, but it is hard to say what the cause was. For one, the composition of the Internet has changed in the last year. Two, Sonar maintains a blacklist of addresses whose owners have requested that we cease scanning their IPs and it is unknown if the Zeronights researchers had a similar list, which means that there were likely a few fundamental differences in the target space between these two disparate scans. So, despite a history of security problems and Cisco advising administrators to properly secure SMI, a year later things haven’t really changed. Why? Examining SMI exposing IPs by country, as usual it is no surprise that countries with a large number IPv4 IPs and significant network infrastructure are at the top of those exposed: Repeating this visualization but examining the organizations that own the IPs exposing SMI, a possible pattern appears -- ISPs: Unfortunately this is where things get a little complicated. The data above seems to imply that the bulk of the organizations exposing SMI are ISPs or similar, however that is also an artifact of how the attribution process happens here. In cases where a given organization is its own ASN and they expose SMI, our reporting would attribute any of the IPs that that ASN is responsible for to the organization in question. However, in cases where a given organization is not its own ASN, or if it uses IP space that it doesn’t control, for example it just gets a cable/DSL/etc router from their ISP, then the name of that organization will not be reflected in our data. Proprietary protocols are interesting from a security perspective and SMI is no exception. Being specific to Cisco switches, you’ll only find this in Cisco shops that didn’t properly secure the switch prior to deployment, so there are limited opportunities for researchers or attackers to explore this. While proprietary protocols are not necessarily closed, SMI does appear that way in that there is almost no public documentation on the protocol particulars beyond what the Zeronights researchers published in 2016. Despite the lack of documentation at the time, these researchers employed a simple method for understanding how the protocol works and it turned out to to be highly effective -- exercising SMI functionality while observing the live protocol communication with a network sniffer. There are several areas for future research which may provide value: When properly secured, including applying all the relevant IOS updates and following Cisco’s recommendations with regards to securing SMI, what risks remain in networks that utilize SMI, if any? When improperly secured, are there are additional risks to be explored? For example, what about the related SMI director service that exposes 4787/TCP? Are there safer or quieter ways to carry out the attacks described by the Zeronights researchers such that more accurate vulnerability coverage could exist? Is there a need for vulnerability coverage similar to SIET’s in Metasploit? What is current state of the art with regards to post-compromise behavior on network switches like this? What methods are (or could) attackers employ to establish advantageous footholds in the networks and devices serviced by a compromised switch? In order to ensure that Rapid7 customers are able to identify assets exposing SMI in their environments, we have added SMI fingerprinting and vulnerability coverage to both Metasploit as of September 1 in auxiliary/scanner/misc/cisco_smart_install, and InsightVM as of the August 17, 2017 release via cisco-sr-20170214-smi. Interested in this research? Looking to collaborate? Questions? Comments? Leave them below or reach out via research@rapid7.com!

In the latest release of AppSpider Pro version 7.0 you will find some great new features which will improve the crawling, attack and overall usability of the product. Below are a few of the key new enhancements you will find in the release. Chrome/WebKit Integration With the introduction of the Chrome/WebKit browser, AppSpider Pro now supports both Chrome and Internet Explorer as default browsers. These integrated browsers facilitate AppSpider's crawling and attack functionality, so with the added support of the Chrome browser, AppSpider now has improved coverage for web applications that aren’t fully compatible with Internet Explorer. Validation Scan Need a quick way to verify that a vulnerability has been remediated by your development team? AppSpider's new validation scan method allows users to target a scan against a previously scanned application and rescan only selected vulnerabilities rather than re-running a complete scan. Save time and get immediate visibility into remediation status. Improved UI Updates Looking for real-time and at-a-glance information of your scans? AppSpider Pro's main UI screen has been updated to give you visibility into scan status, number of vulnerabilities found, number of links crawled, authentication used and the attack policy which was used. All of your scan info in one place makes it easier than ever for you to monitor scan progress.. Confidence level for findings Based on the experience and research of Rapid7’s engineering teams, a confidence level for findings is now available in HTML and JSON reports to provide users with a visual indicator of how certain AppSpider is that a particular finding is valid. New Attack Modules The following attack modules have been added as a part of this release: ASP.NET Serialization: ASP.NET Serialization security module checks for serialized binary objects. Serialized data can potentially be intercepted and read by malicious users. Furthermore, in some cases controls might use serialized data for internal processing, so a malicious code may be processed on the web server. Cross-site scripting (XSS), (DOM based Reflected via Ajax Request): DOM Based XSS (or as it is called in some texts, "type-0 XSS") is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim's browser used by the original client-side script, so that the client-side code runs in an “unexpected” manner. HTTP Query Session Check: HTTP Query Checks parameter values which can expose an application to various security risks. HTTP User Agent Check: HTTP User-Agent Check is performed to understand whether user-agent sniffing is turned on. Session Upgrade: Reports a risk factor for exposing or binding the user session between states of anonymous users and authenticated users. For additional details on these feature please review the AppSpider Pro 7.0 User guide here (PDF).

It's been a hot minute since the last Metasploit Wrapup. So why not take in our snazzy new Rapid7 blog makeover and catch up on what's been goin' down! You can't spell 'Struts' without 'trust' Or perhaps you can! With the all the current news coverage around an Apache Struts vulnerability from earlier this year (thanks to its involvement in a consumer credit reporting agency data breach), there's a new Struts vuln getting attention. Due to how untrusted, user-provided data is handled during deserialization, it's possible to achieve remote code execution on vulnerable versions of Struts (which reportedly go back to 2008!). Struts devs were quick to release a patch to address the new vuln, while Metasploit dev @wvu was quick to create an exploit module for Framework. For additional details and musings, check out this blog post from R7's Tod Beardsley, Director of Research. Better living through Meterpreter There've been a number of substantial improvements to Meterpreter going on, some of which have been released since the last wrapup post. Transport-agnostic encryption (wat?) Colloquially referred to as CryptTLV (because, well, it encrypts the TLV message payloads between Framework and Meterpreter), this new mechanism has a couple of immediate benefits for MSF users: Doesn't require OpenSSL (reducing Meterpreter payload size by roughly 80%!) Operates at the packet payload level, allowing it work across various transports types (TCP, UDP, so on...) There's some more work coming along in this vein. Stay tuned. Playing a 'pivotal' role It's what you do once you have your foothold on a multi-homed system connected to a private network: you pivot. Which leads to further discovery, moving around, and sometimes more pivoting. We've recently upgraded this key Meterpreter feature with the following: Works over named pipes More performant than the existing tunnelling mechanism (and latency doesn't compound as you make additional pivots!) Traffic is encrypted with CryptTLV Definitely worth taking for a spin, so let us know what you think! And SO MANY NEW MODULES! Seriously, there's a bunch of neat stuff that's been added. Check out the New Modules list below, where you'll find stuff to help you with all the following: scanning credential gathering container detection privilege escalation remote code execution denial of service C2 server software exploitation (Tod gets the credit on this) New Modules Exploit modules (9 new) Docker Daemon - Unprotected TCP Socket Exploit by Martin Pizala QNAP Transcode Server Command Execution by 0x00string, Brendan Coles, and Zenofex VMware VDP Known SSH Key by phroxvs exploits CVE-2016-7456 Malicious Git HTTP Server For CVE-2017-1000117 by NOBODY exploits CVE-2017-1000117 IBM OpenAdmin Tool SOAP welcomeServer PHP Code Execution by Brendan Coles and SecuriTeam exploits CVE-2017-1092 Apache Struts 2 REST Plugin XStream RCE by wvu and Man Yue Mo exploits CVE-2017-9805 Windows Escalate UAC Protection Bypass (Via COM Handler Hijack) by Matt Nelson, OJ Reeves, and b33f Gh0st Client buffer Overflow by Professor Plum PlugX Controller Stack Overflow by Professor Plum Auxiliary and post modules (6 new) BIND TKEY Query Denial of Service by Alejandro Parodi, Ezequiel Tavella, Infobyte Research Team, and Martin Rocha exploits CVE-2016-2776 Asterisk Gather Credentials by Brendan Coles TeamTalk Gather Credentials by Brendan Coles Identify Cisco Smart Install endpoints by Jon Hart Linux Gather Container Detection by James Otten Multi Gather Maven Credentials Collection by elenoir Get it As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub: Pull Requsts 4.15.6...4.16.6 Full diff 4.15.6...4.16.6 To install fresh, check out the open-source-only Nightly Installers, or the binary installers which also include the commercial editions.

The following is a guest post by Christopher Hart, an attorney at Foley Hoag and a member of Foley Hoag’s cybersecurity incident response team. This is not meant to constitute legal advice; instead, Chris offers helpful guidance for building an incident preparation and breach response framework in your own organization. A data breach is a business crisis that requires both a quick and a careful response. From my perspective as a lawyer, I want to provide the best advice and assistance I possibly can to help minimize the costs (and stress) that arise from a security incident. When I get a call from someone saying that they think they’ve had a breach, the first thing I’m often asked is, “What do I do?” My response is often something like, “Investigate.” The point is that normally, before the legal questions can be answered and the legal response can be crafted, as full a scope of the incident as possible first needs to be understood. I typically think of data breaches as having three parts: Planning, managing, and responding. Planning is about policy-making and incident preparation. Sometimes, the calls that I get when there is a data breach involve conversations I’m having for the first time—that is, the client has not yet thought ahead of time about what would happen in a breach situation, and how she might need to respond. But sometimes, they come from clients with whom I have already worked to develop an incident response plan. In order to effectively plan for a breach, think about the following questions: What do you need to do to minimize the possibility of a breach? What would you need to do if and when a breach occurs? Developing a response plan allows you to identify members of a crisis management team—your forensic consultant, your legal counsel, your public relations expert—and create a system to take stock of your data management. I can’t emphasize enough how important this stage is. Often, clients still think of data breaches as technical, IT issues. But the trend I am seeing now, and the advice I often give, is to think of data security as a risk management issue. That means not confining the question of data security to the tech staff, but having key players throughout the organization weigh in, from the boardroom on down. Thinking about data security as a form of managing risk is a powerful way of preparing for and mitigating against the worst case scenario. Managing involves investigating the breach, patching it and restoring system security, notifying affected individuals, notifying law enforcement authorities as necessary and appropriate, and taking whatever other steps might be necessary to protect anyone affected. A good plan will lead to better management. When people call me (or anyone at my firm’s Cybersecurity Incident Response Team, a group of lawyers at Foley Hoag who specialize in data breach response) about data breaches, they are often calling me about how to manage this step. But this is only one part of a much broader and deeper picture of data breach response. Responding can involve investigation and litigation. If you’ve acted reasonably and used best practices to minimize the possibility of a breach; and if you’ve quickly and reasonably complied with your legal obligations; and if you’ve done all you can to protect consumers, then not only have you minimized the damage from a breach—which is good for your company and for the individuals affected by a breach—but you’ve also minimized your risks in possible litigation. In any event, this category involves responding to inquiries and investigation demands from state and federal authorities, responding to complaints from individuals and third parties, and generally engaging in litigation until the disputes have been resolved. This can be a frustratingly time-consuming and expensive process. This should give you a good overall picture of how I, or any lawyer, thinks about data security incidents. I hope it helps give you a framework for thinking about data security in your own organizations. Need assistance? Check out Rapid7's incident response services if you need assistance developing or implementing an incident response plan at your organization.

AWS instances present many challenges to security practitioners, who must manage the spikes and dips of resources in infrastructures that deal in very short-lived assets. Better and more accurate syncing of when instances are spun up or down, altered, or terminated directly impacts the quality of security data. A New Discovery Connection Today we’re excited to announce better integration between the Security Console and Amazon Web Services with the new Amazon Web Services Asset Sync discovery connection in InsightVM and Nexpose. This new connection is the result of customer feedback and we would like to thank everyone who submitted ideas through our idea portal. This new integration has some notable and exciting improvements over our existing AWS discovery connection that we can’t wait for you to take advantage of. Automatic Syncing with the Security Console as AWS assets are spun up and spun down As assets are created and decommissioned in AWS, the new Amazon Web Services Asset Sync discovery connection will update your Security Console. This means that users will no longer have to worry about their Security Console data being stale or inaccurate. That means no more chasing down assets in AWS for remediation only to find that the instances no longer exist or carving out time to clean up decommissioned AWS assets from the Security Console. Import AWS Tags and Filtering by AWS Tags One feature that we’ve gotten a lot of requests for is importing tags from AWS. With the Amazon Web Services Asset Sync discovery connection, you can now synchronize AWS tags and even use them to filter what assets get imported. You can also filter tags themselves so you only see tags that are important to you. Once the tags are synced, they can be used just like any other tag within Nexpose—that includes using them to filter assets, create dynamic asset groups, and even create automated actions. Remove a tag in AWS? Nexpose will detect the change and automatically remove it as well. Use AssumeRole to Fine-Tune Adding to Sites Users can now leverage AWS AssumeRole to decide which of their assets across all of their AWS accounts to include in a single site without having to configure multiple AWS discovery connections in their Security Console. Coupled with tag-based filtering, this makes managing your AWS assets much more straightforward. AssumeRole is now also available to Security Consoles outside of the AWS environment. Ad-Hoc Scans with the Pre-Authorized Engine Another feature users have requested is more flexibility in selectively scanning sites that contain AWS assets. As part of the Amazon Web Services Asset Sync discovery connection, users will now be able to select which assets they wish to scan with the AWS pre-authorized engine within a site. Use the Security Console Proxy Proxy support is also available for the Amazon Web Services Asset Sync discovery connection. If users already have a proxy server configured and enabled via their Security Console settings, they do not have to change their firewall settings to take advantage of this new discovery connection. Simply check the “Connect to AWS via proxy” box during configuration and the connection will use the configured proxy. Existing AWS Discovery Connections The previous AWS discovery connection will still be available; we recommend users transition to this new, more powerful and flexible the Amazon Web Services Asset Sync discovery connection for managing their AWS assets. Next Steps To take advantage of this new capability, you will need version 6.4.55 of the Security Console for Nexpose and InsightVM. Not already using InsightVM? Get a free trial here.

Day one of Rapid7’s UNITED Summit is almost over! We kicked off this morning with welcome remarks from CEO Corey Thomas (after a very, ahem, colorful performance by the Blue Man Group!), who spoke on the need to de-silo data and teams in the interest of driving innovation and solving big problems. He made a point of calling out the cybersecurity industry’s tendency to believe that security teams can be successful independently of IT—a shackle, as Corey put it, that holds us back, often unnecessarily. One of Corey’s most powerful attributes as a speaker is the way he constantly evokes forward motion; at UNITED, he asked key questions for the security industry as a whole and for Rapid7 as a company: How can we harness our collective imagination to create a sense of optimism in our field and beyond? Are the organizational models of the past really serving us today? What areas of expertise will ensure our continued relevance and success in a changing world? Looking ahead with clarity and focus is a talent our CEO has in spades. We’re thrilled to be able to share Corey’s vision so intimately with our customers and the community! We chose a formidable speaker and technologist as UNITED’s opening keynote: Nicholas Negroponte spoke eloquently on everything from the breakdown of barriers between the natural and manmade worlds to the need for innovation and the inevitability of change. UNITED’s thematic notes resonated in the MIT Media Lab co-founder’s words—we in technology are both witness and driver to the crumbling walls of old models and distinctions, whether those borders lie between nation-states or between IT and security teams. As we look to package and deliver information in new ways (a car from a seed!), it’s urgent that we ask whether we’re developing new approaches to big problems. “When I wake up in the morning, I ask myself a question,” Negroponte told the UNITED audience. “‘Will normal market forces do what I’m doing today?’ If the answer is yes, I stop. They don’t need me.” Rapid7 Chief Product Officer Lee Weiner and Customer Success SVP Stephanie Furfaro offered smart, actionable answers to the morning’s big questions on the future of technology with a powerhouse presentation on customer-centered innovation. UNITED attendees got a close-up look at how the vision for Rapid7’s Insight platform informs and enhances individual product improvements—from fresh container security assessment functionality in InsightVM to uniting UBA and SIEM capabilities with InsightIDR. Much like Corey Thomas recognizes the pressing need for collaboration between IT and security teams, Lee and Stephanie put strong emphasis on synergy between product and customer success teams. As Stephanie said right off the bat, “Our customers are heroes….We want to be there when you need us.” A rousing round of applause for our three Rapid7 Customer Award winners marked the end of the morning presentations and the beginning of an afternoon that included talks on everything from automation and container security to the evolution of the CVE and cybersecurity for trade agreements. The Metasploit crew kicked off their exclusive UNITED CTF, Deral Heiland and Craig Smith led an IoT lab complete with hands-on demos, and a slew of different Rapid7 teams gave 1:1 expert consultations (at no cost!) for attendees. This afternoon we’ll host a series of industry roundtables so UNITED guests can share challenges and solutions with others in their industry. Want to gear up for tomorrow? Plan your day with the full agenda, and if you’re extra motivated, get up early to join the UNITED running club for a 5K jogging tour of Boston! Not here in person? Follow the #R7UNITED hashtag on Twitter and take advantage of the UNITED live stream showing tomorrow’s fireside chat and Dan Geer’s closing keynote. Thanks to everyone who made the trip out to Boston to join us this week, and to those of you watching at home! You’re all our heroes.

It's a big month, with Microsoft patching 85 separate vulnerabilities including the two Adobe Flash Player Remote Code Execution (RCE) fixes bundled with the Edge and Internet Explorer 11 updates. Continuing recent trends, the bulk of Critical RCE vulnerabilities are client-side, primarily in Edge, IE, and Office. Microsoft has also released patches for today's branded public disclosure, "BlueBorne", which is a collection of vulnerabilities affecting the Bluetooth stacks from multiple vendors. The Microsoft-specific issue is CVE-2017-8628, a spoofing vulnerability that could allow a man-in-the-middle attack when in physical proximity to an affected system. In terms of exploitability, CVE-2017-8759 (a flaw in the way the .NET framework processes untrusted input) is the most urgent as it is known to already be exploited in the wild. Any attacker able to persuade a user to open a maliciously crafted document or application will be able to take control of affected systems with the same privileges as the user. Among the Office vulnerabilities, CVE-2017-8742, CVE-2017-8743, and CVE-2017-8744 are memory corruption vulnerabilities that could lead to RCE which Microsoft has classified as being likely to be exploited. Administrators should prioritize rolling out .NET fixes to workstations, then any relevant Windows 10 (which bundle Edge) and IE updates, followed by the Microsoft Office and system-level patches. As usual, there are also server-side patches that need to be applied. SharePoint sees a fix for a XSS vulnerability (CVE-2017-8629) as well as for two RCE vulnerabilities that also apply to Office Online Server (CVE-2017-8631) and CVE-2017-8743). Exchange Server also gets some love with fixes for CVE-2017-11761 and CVE-2017-8758 (Information Disclosure and Privilege Escalation, respectively). Of course, standard Windows Server systems are also getting critical fixes, such as that for CVE-2017-0161, an RCE in NetBIOS Over TCP/IP (NetBT).

The following post is a guest blog by Bo Weaver, Senior Penetration Tester at CompliancePoint. If you're attending UNITED, you can catch Bo's talk at 11:45 AM on Thursday, September 14 in the Phish, Pwn, and Pivot track. Hi! I’m Bo. I’ll be speaking at Rapid7’s UNITED Summit in Boston this week, and Rapid7's community manager asked me to write a little blog about my talk. I marvel how on the net we make up new words for a common digital thing—even spell check says "blog" isn’t a word! I know what a "bog" is and I know in our line of work a "blob" is a large chunk of data in a database table. Living in the mountains makes finding bogs kinda hard, but the chunk of word data below is swampy enough to qualify. I’ve worked in the security field for over twenty years. Long before the Internet I worked in private security, mostly undercover on corporate and industrial espionage. This was back in the day when you actually had to physically steal stuff. I also did a lot of work in Executive Protection. My Internet career started even before that when I was in the Navy: I studied as an Electronic Technician while in school; we all worked on a little R&D project called ARPANET. While working on this I never thought that it would turn into what it’s become! In the 90s I did a lot of work with BBSes and then dialup ISP in the Southeast—mostly securing these networks. Since then I’ve had about every network security job there is. I've learned a lot over the years, and I'll be sharing some of that knowledge at UNITED. My passion has always been hacking. For roughly the last 5 years I have been working for Compliancepoint, an Atlanta-based security consulting company as a senior penetration tester and security researcher. The thing I love most about my job here is that we test everything from Mom and Pop companies running an online business to major corporate and government networks. We get to see it all. My talk at UNITED is about reducing complexity and how even big problems can have relatively simple solutions. Sometimes organizations think they need to throw millions at a problem when some time, some knowledge, and little expense can fix even major issues. I learned about KISS in engineering school and have never forgotten: “Keep It Simple, Stupid”. Doesn’t matter if you’re building a toaster or a world network. Kiss it! See the full UNITED agenda here.

On August 31, 2017, NoMotion’s “SharknAT&To” research started making the rounds on Twitter. After reading the findings, and noting that some of the characteristics seemed similar to trends we’ve seen in the past, we were eager to gauge the exposure of these vulnerabilities on the public internet. Vulnerabilities such as default passwords or command injection, which are usually trivial to exploit, in combination with a sizable target pool of well-connected, generally unmonitored internet-connected devices, such as DSL/cable routers, can have a significant impact on the general health of the internet, particularly in the age of DDoS and malware for hire, among other things. For example, starting around this time last year and continuing until today, the internet has been dealing with the Mirai malware that exploits default passwords as part of its effort to replicate itself. The SharknAT&To vulnerabilities seemed so similar, we had to get a better idea of what we might be facing. What we found surprised us: the issues are actually not as universal as initially surmised. Indeed, we found that clusters of each of the vulnerabilities are found almost entirely in their own, distinct regional pockets (namely, Texas, California, and Connecticut). We also observed that these issues may not be limited to just one ISP deploying a particular model of Internet router but perhaps a variety of different devices that is complicated by a history of companies, products, and services being bought, sold, OEM’d and customized. For more information about these SharknAT&To vulnerabilities and Rapid7’s efforts to understand the exposure these vulnerabilities represent, please read on. Five Vulnerabilities Disclosed NoMotion identified five vulnerabilities that, at the time, seemed limited to Arris modems being deployed as part of AT&T U-Verse installations: SSH exposed to the Internet; superuser account with hardcoded username/password. (22/TCP) Default credentials “caserver” in https server NVG599 (49955/TCP) Command injection “caserver” in https server NVG599 (49955/TCP) Information disclosure/hardcoded credentials (61001/TCP) Firewall bypass no authentication (49152/TCP) Successful exploitation of even just one of these vulnerabilities would result in a near complete compromise of the device in question and would pose a grave risk to the computers, mobile devices, and IoT gadgets on the other side. If exploited in combination, the victim’s device would be practically doomed to persistent, near-undetectable compromise. Scanning to Gauge Risk NoMotion did an excellent job of using existing Censys and Shodan sources to gauge exposure; however, they also pointed out that some of the at-risk services on these devices are not regularly audited by scanning projects like this. In an effort to assist, Rapid7 Labs fired off several Sonar studies shortly after learning of the findings in order to get current information for all affected services, within reason. As such, we queued fresh analysis of: SSH on port 22/TCP to cover vulnerability 1 HTTPS on 49955/TCP and 61001/TCP, covering vulnerabilities 2-4 A custom protocol study on port 49152/TCP for vulnerability 5 Findings Vulnerability 1: SSH Exposure Not having a known vulnerable Arris device at our disposal, we had to take a bit of an educated guess as to how to identify affected devices. In NoMotion’s blog post, they cite Censys as showing 14,894 vulnerable endpoints. A search through Sonar’s SSH data from early August showed just over 7,000 hosts exposing SSH on 22/TCP with “ARRIS” in the SSH banner, suggesting that these may be made by Arris, one of the vendors involved in this issue. There are several caveats that could explain the difference in number, including the fact that Arris makes several other devices, which are unaffected by these issues, and that there is no guarantee that affected and/or vulnerable devices will necessarily mention Arris in their SSH protocol. A follow-up study today showed similar results with just over 8,000. It is assumed that the difference in Rapid7’s numbers as compared to NoMotion’s is caused by the fact that Sonar maintains a blacklist of IP addresses that we’ve been asked to not study, as well as normal changes to the landscape of the public Internet. A preliminary check of our Project Heisenberg honeypots showed no noticeable change in the patterns we observe related to the volume and variety of SSH brute force and default account attempts prior to this research. However, the day after NoMotion's research was published, our honeypots started to see exploitation attempts using the default credentials published by NoMotion. September 13, 2017 UPDATE on SSH exposure findings The researchers from NoMotion reached out to Rapid7 Labs after the initial publication of this blog and shared how they estimated the number of exposed, vulnerable SSH endpoints. They did so by searching for SSH endpoints owned by AT&T U-Verse that were running a particular version of dropbear. Repeating our some of our original research with this new information, we found nearly 22,000 seemingly vulnerable endpoints in that same study from early August concentrated in Texas and California. Armed with this new knowledge, we re-analyzed SSH studies from late August and early September and discovered that seemingly none of the endpoints that appeared vulnerable in early August were still advertising the vulnerable banner, indicating that something changed with regards to SSH on AT&T U-Verse modems that caused this version to disappear entirely. Sure enough, a higher level search for just AT&T U-Verse endpoints shows that there were nearly 40,000 AT&T U-Verse SSH endpoints in early August and just over 10,000 in late August and early September, with the previously seen California and Texas concentrations drying up. What changed here is unknown. Vulnerabilities 2 and 3: Port 49955/TCP Service Exposure US law understandably prohibits research that performs any exploitation or intrusive activity, which rules out specifically testing the validity of the default credentials, or attempting to exploit the command injection vulnerability. Combined with no affected hardware being readily available to us at the time of this writing, we had to get creative to estimate the number of exposed and potentially affected Arris devices. As mentioned in NoMotion’s blog, they observed several situations in which the HTTP(S) server listening on 49955/TCP would return various messages implying a lack of authorization, depending on how the request was made. Our first slice through the Sonar data from August 31, 2017 showed ~3.4 million 49955/TCP endpoints open, though only approximately 284,000 of those appear to be HTTPS. Further summarization showed that better than 99% of these responses were identical HTTP 403 forbidden messages, giving us high confidence that these were all the same types of devices and were all likely affected. In some HTTP research situations we are able to examine the HTTP headers in the response for clues that might indicate a particular vendor, product or version that would help narrow our search, however the HTTP server in question here returns no headers at all. Furthermore, by examining the organization and locality information associated with the IPs in question, we start to see a pattern that this is isolated almost entirely to AT&T-related infrastructure in the Southern United States, with Texas cities dominating the top results: The ~53k likely affected devices that we failed to identify a city and state for all report the same latitude and longitude, smack in the middle of Cheney Reservoir in Kansas. This is an anomaly introduced by MaxMind, our source of Geo-IP information, and is the default location used when an IP cannot be located any more precisely than being in the United States. As further proof that we were on the right track, NoMotion has two locations, both in Texas. It’s likely that these Arris devices were first encountered in day-to-day work and life by NoMotion employees, and not scrounged off of eBay for research purposes. We’ve certainly happened upon interesting security research this way at Rapid7—it’s our nature as security researchers to poke at the devices around us. Because this HTTP service is wrapped in SSL, Sonar also records information about the SSL session. A quick look at the same devices identified above shows another clear pattern -- that most have the same, default, self-signed SSL certificate: This presents another vulnerability. Because the vast majority of these devices have the same certificate, they will also have the same private key. This means that anyone with access to the private key from one of these vulnerable devices is poised to be able to decrypt or manipulate traffic for other affected devices, should a sufficiently-skilled attacker position themselves in an advantageous manner, network-wise. Because some of the SharknAT&To vulnerabilities disclosed by NoMotion allow filesystem access, it is assumed that access to the private key, even if password protected, is fairly simple. To add insult to injury, because these same vulnerable services are the very services an ISP would use to manage and update or patch affected systems against vulnerabilities like these, should an attacker compromise them in advance, all bets are off for patching these devices using all but a physical replacement. It is also very curious that outside of the top SSL certificate subject and fingerprint, there is still a clear pattern in the certificates: there is a common name with a long integer after it, which looks plausibly like a serial number. Perhaps at some point in their history, these devices used a different scheme for SSL certificate generation, and inadvertently included the serial number. Some simple testing with a supposedly unaffected device showed that this number didn’t necessarily match the serial number. Examining Project Heisenberg’s logs for any traffic appearing on 49955/TCP shows only a minimal amount of background noise, and no obvious widespread exploitation yet in 2017. Vulnerability 4: Port 61001/TCP Exposure Much like with vulnerabilities 2 and 3 on port 49955/TCP, Sonar is a bit hamstrung when it comes to its ability to test for the presence of this vulnerability on the public internet. Following the same steps as we did with 49955/TCP, we observed ~5.8 million IPs on the public IPv4 Internet with port 61001/TCP open. A second pass of filtering showed that nearly half of these were HTTPS. Using the same payload analysis technique as before didn’t pay dividends this time, because while the responses are all very similar -- large clusters of HTTP 404, 403, and other default looking HTTP response -- there is no clear outlier. The top response from ~874,000 endpoints looks similar to what we observed on 49955/TCP -- lots of Texas with some Cali slipping in: The vast majority of the remainder appear to be 2Wire DSL routers that are also used by AT&T U-Verse. The twist here is that Arris acquired 2Wire several years ago. Whether or not these 2Wire devices are affected by any of these issues is currently unknown: As shown above, there is still a significant presence in the Southern United States, but there is also a sizeable Western presence now, which really highlights the supply chain problem that NoMotion mentioned in their research. While the 49955/TCP vulnerability appears to be isolated to just one region of the United States, the 61001/TCP issue has a broader reach, further implying that this extends beyond just the Arris models named by NoMotion, but not necessarily beyond AT&T. Repeating the same investigation into the SSL certificates on port 61001/TCP shows that there are likely some patterns here, including the same exact Arris certificate showing up again, this time with over 45,000 endpoints, and Motorola making an appearance with 3/4 of a million: Examining Project Heisenberg’s logs for any traffic appearing on 61001/TCP shows there is only a minimal amount of background noise and no obvious widespread exploitation yet in 2017. Vulnerability 5: Port 49152/TCP Exposure The service listening on 49152/TCP appears to be used as a kind of a source-routing, application layer to MAC layer TCP proxy. By specifying a magic string, the correct opcode, a valid MAC and a port, the “wproxy” service will forward on any remaining data received during a connection to port 49152/TCP from (generally) the WAN to a host on the LAN with that specified MAC to the specified. Why exactly this needs to be exposed to the outside world with no restrictions whatsoever is unknown, but perhaps the organizations in question deploy this for debugging and maintenance purposes and failed to properly secure it. In order to gauge exposure of this issue, we developed a Sonar study that sends to the wproxy service a syntactically valid payload that elicits an error response. More specifically, the study sends a request with a valid magic string, an invalid opcode, an invalid MAC and an invalid port, which in turn generally causes the remote endpoint to return an error that allows us to positively identify the wproxy service. Because this vulnerability is inherent in the service itself due to a lack of any authentication or authorization, any endpoint exposing this service is at risk. As with the other at risk services described so far, our first step was to determine how many public IPv4 endpoints seemed to have the affected port open, 49152/TCP. A quick zmap scan showed nearly 8 million hosts with this port open. With our limited knowledge of the protocol service, we looked for any wproxy-like responses, which quickly whittled down the list to approximately 42,000 IPv4 hosts exposing the wproxy service. We had hoped that a quick application of geo-IP and we’d be done, but it wasn’t quite that simple. Using the same techniques as with other services, we grouped by common locations until something caught our eye, and immediately we knew something was up. Up until this point, all of this had landed squarely in AT&T land, clustering around Texas and California, but several different lenses into the 49152/TCP data pointed to one region—Connecticut: Sure, there are a few AT&T mentions and even 5 oddly belonging to Arris in Georgia, but otherwise this particular service seemed off. Why all Texas/California AT&T previously, but now Frontier in Connecticut? Guesses of bad geo-IP data wouldn’t be too far off, but in reality, Frontier acquired all of AT&T’s broadband business in Connecticut 3 years ago. This means that AT&T broadband customers who were at risk of having their internal networks swiss-cheesed by determined attackers with a penchant for packets for at least 3 years are now actually Frontier customers using AT&T hardware, almost certainly further complicating the supply chain problem and definitely putting customers at risk because of a service that should have never seen the public internet in the first place. Examining Project Heisenberg’s logs for any traffic appearing on 49152/TCP and there is largely just suspected background noise in 2017, albeit a little higher than port 49955/TCP and 61001/TCP. There are a few slight spikes back in February 2017, perhaps indicating some early scouting, but it is just as likely to have been background noise or probes for entirely different issues. Some high level investigation shows a deluge of blindly lobbed HTTP exploits at this port. Conclusions The issues disclosed by NoMotion are certainly attention-grabbing, since the initial analysis implies that AT&T U-Verse, a national internet service provider with millions of customers, is powered by dangerously vulnerable home routers. However, our analysis of what’s actually matching the described SharknAT&To indicators seems to point to a more localized phenomenon; Texas and other Southern areas are primarily indicated, with flare ups in California, Chicago, and Connecticut, with significantly lower populations in other regions of the U.S. These results seem to imply which vendor is in the best position to fix these bugs, but the supply chain problems detailed above add a level of complication that will inevitably leave some customers at risk unnecessarily. Armed with these Sonar results, we can say with confidence that these vulnerabilities are almost wholly contained in the AT&T U-Verse and associated networks, and not part of the wider Arris ecosystem of hardware. This, in turn, implies that the software was produced or implemented by the ISP, and not natively shipped by the hardware manufacturer. This knowledge will hopefully speed up remediation. Interested in further collaboration on this? Have additional information? Questions? Comments? Leave them here or reach out to research@rapid7.com!

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

Contained within this post is a secret look into the talk-planning life of Samantha Humphries, Rapid7's senior manager for international solutions, and Katie Ledoux, a senior security analyst. Let's watch what happens. From: Caitlin Condon Sent: 16 August 2017 15:26 To: Samantha Humphries; Katie Ledoux Subject: Re: Blog post for your GDPR session at UNITED Sam! Katie! How would you two feel about writing a blog post on your UNITED session on GDPR and how it’s going to affect U.S.-based companies? It seems like some folks here think this is a Europe-only issue. Your session should debunk that myth. You game? From: Samantha Humphries Sent: 16 August 2017 16:26 To: Katie Ledoux Subject: Re: Blog post for your GDPR session at UNITED Hey Katie, I started writing about how to our session will help UNITED attendees understand what GDPR is, how they can prepare, and how our own governance team has addressed and overcome challenges...AND THEN I CHECKED OUT THE BLOODY AGENDA FOR UNITED. Have you seen the list of sessions that are running concurrently with ours?! Rajeev is talking about how bots are changing IT and security as we know it; Rebekah and the DoJ are speaking on cyber threat exchange with the government; and Leon’s session is on hacking with “flair”—I don’t even know what that means! Do you think he’ll have drones?! What if nobody comes to our session? I can’t even ask my mum to make up the numbers, because she lives here in the UK! Yours panickingly, Sam From: Katie Ledoux Sent: 16 August 2017 16:48 To: Samantha Humphries Subject: Re: Blog post for your GDPR session at UNITED Sam, calm down, I’m sure...WHOA, Leon told me he might have a light show to go with his ‘flair’ and I think he might be serious! We need costumes and vodka shots! Do you think we can have live animals on stage? From: Samantha Humphries Sent: 16 August 2017 17:33 To: Katie Ledoux Subject: Re: Blog post for your GDPR session at UNITED Right, how about this? http://www.argos.co.uk/product/3144114 Everyone loves hearing from Compliance Stormtroopers—it is known! I’ll see if Kyle’s got budget for them. Will report back in a mo. From: Samantha Humphries Sent: 16 August 2017 19:33 To: Katie Ledoux Subject: FW: Re: FW: Blog post for your GDPR session at UNITED Sigh. The boss said no...but he didn’t say anything about the vodka shots. From: Kyle Flaherty Sent: 16 August 2017 18:06 To: Samantha Humphries Subject: Re: FW: Blog post for your GDPR session at UNITED Sam, you know we don’t shell out for stormtrooper costumes unless it’s for a keynote talk. You and Katie have an awesome session planned—you don’t need gimmicks to talk about why GDPR applies to ANY organization in the world that holds personal data about EU citizens, regardless of vertical, company size, or geographic location. Attendees will want to learn about how they can prepare and why GDPR is a good thing! Take a breath. /kff DISCLAIMER: There is no commitment to provide vodka shots, live animals, or costumes at our GDPR or GDP-argh talk. You will get a full 568mls of GDPR goodness though, including some great insights into what GDPR is, how you need be preparing, and how we’re thinking about GDPR internally at Rapid7. We should also mention that if you come dressed as a Stormtrooper, you get extra points. See you there! (Here's how to register if you've not done so already!)