Skip navigation
All Places > Information Security > Blog
Deral Heiland

Research Lead (IoT)

Posted by Deral Heiland Employee Nov 1, 2016

It has been an amazing journey serving as the Research Lead for the Internet of Things (IoT) at Rapid7 for past 10 months. I came into the role with more than a decade of experience as a security penetration tester and nearly 15 years of experience conducting security research across such areas as protocol based attacks, embedded device exploitation, and web vulnerabilities, so taking on the role, as Research Lead for IoT was the next obvious progression for me. Being able to focus on IoT specifically has made this job more fun and exciting.

Internet of Things - IoT - Rapid7.jpg

 

So why the focus on IoT research? IoT, while driving significant productivity gains for businesses and consumers, has become the wild west of technology, creating a number of security challenges for all of us. By creating a focused effort in IoT research we can better serve our customers and the security community at large by sharing the knowledge we gain during these efforts. Rapid7’s mission is to empower IT and Security to effectively and safely design, build and deploy technology innovation, and we see IoT as a major driver of innovation across industries. IoT is expected to hit over 20 billion connected devices by the end of the decade, and I anticipate it will also continue to be an ever-changing area of risk. A focused effort is critical to better securing our new IoT driven world.

 

I plan to take the opportunity this role has provided to help forge a path that will add value to the security community at large. For example, my research over the last 10 months has focused on examining a number of IoT technologies from enterprise to consumer-based products, exposing a number of vulnerabilities in their ecosystems. During these research projects we have successfully worked with a number of IoT manufacturers to help them better secure their products and, very importantly, helped them to expand their working knowledge in the area of security. The knowledge gained from these research projects has done more than just uncover vulnerability exposures, it has also helped us shape, identify and develop an understanding of issues plaguing IoT. Additionally, we have been given the opportunity to work with a number of customers, manufacturers and organizations to help better define methods around mitigating security issues related to IoT.

 

Moving forward I am very excited about the opportunities this research role will provide, allowing me to continue to expand my knowledge and understanding in all areas of IoT security. I plan to continue focusing our research efforts across multiple areas of the IoT discipline, including consumer, enterprise, medical, and industrial. Combined with all the IoT research efforts currently being conducted across Rapid7, we plan to work closely with our customers, IoT manufacturers and the security community at large to continue advancing our knowledge and expertise to better secure the new IoT driven world.  Combined with our Strategic Services offering, we are able to extend this knowledge to a wider number of organizations seeking to make the Internet of Things more secure and resilient.

So there's this Thing...

 

We need to talk about Things, you and I. Specifically those connected Things. This isn’t a weird breakup discussion

regarding a relationship you didn’t know we had (I hear that’s called stalking actually, and is an altogether different type of problem). There may be Things on your network that are harbouring a security issue, and that’s not a good place to be either. We can help you track them down (which does bear a slight resemblance to stalking, granted, but we’re security people and they’re just Things so it’s allowed).

thing-addams-family.jpg

 

Mirai - definitely not a Vision of Love

A recent DNS attack sent parts of the Internet into temporary meltdown – not just because our ability to share cat videos and food pictures was impeded. It became apparent that there’s a new kid in town – the Mirai botnet – which takes advantage of weak security in IoT devices. Default credentials are not the internet’s friend.

 

Now, there are plenty of good articles already available for you to read about the technicalities of the Mirai botnet, including this blog post from the highly distinguished Mr Tod Beardsley – so I’m not going to rewrite an already well authored wordy wheel, but like I said earlier we do have something cool for you to find out if you have Things on your own network that could pose a risk.

 

IoTSeeker – it does exactly what it says on the package!

So without further ado, I’d like to introduce you to IoTSeeker – a tool created by the incredibly smart folks on the Metasploit engineering team. IoTSeeker allows you to hunt down IoT devices which are languishing in your eco-system poorly configured with the same creds that they were born with. It’s nice and simple to use, and the scan output (example below) provides you with a list of Things and an indicator as to whether they need re-configuring to be in a more secure state.

IoTSeeker output identifying vulnerable IoT devices on network

 

To run this tool you’ll need to be on a Mac OS or a Linux OS, as IoTSeeker uses the perl module AnyEvent for high parallelism – which essentially means you can quickly scan A LOT of IPs. It’s free, because we’re nice like that, and we plan to keep updating it to include new Things that could be a problem. The steps on how to use IoTSeeker are available when you download the tool – and unless you have the attention span of an ADHD goldfish in a barrel full of squirrels, you’ll be up and scanning in a minute or so, it really is that simple.

 

A very important note: this tool is provided for you to only scan assets for which you have administrative responsibility.

 

Download the IoTSeeker here.

 

Feedback welcomed, and happy Thing Seeking!

This is a guest post from our frequent contributor Kevin Beaver. You can read all of his previous guest posts here.

 

My favorite lyricist, Neil Peart of Rush, once wrote “Why does it happen? Because it happens.” Some deep lyrics on life that many people, unfortunately, apply to their information security programs. These people go through their days, months, and years, letting things “happen”. It could be a user unhappy about the security hoops he must jump through. It could be an executive who repeatedly says “No!” to security budget and initiatives. It could be a denial of service attack. Whatever the situation, it just happens. And life goes on. The motions. The reactiveness. The policies. The assumptions. The breaches.

 

To quote another song, this time from the TV show, Hee-Haw, it seems as if many people in security operate with the mindset of "Gloom, despair, and agony on me...If it weren’t for bad luck, I’d have not luck at all". It’s as if there’s nothing that can be done. Every security problem that these people have is someone else’s fault. There’s always an excuse. One thing that’s glaringly evident in business (and life in general) is that there are followers and there are leaders. Some people just take what comes their way, running themselves ragged constantly putting out fires. They’re needed all the time, work long hours, yet they never get anything done. And the security challenges continue. I think these people secretly enjoy just where they’re at. But that that’s not doing the business any favors and certainly doesn’t address the underlying business risks at play.

 

If you want to take control and ensure that bad choices and habits are not hindering your information security program, you might consider doing these things to get at the root the challenges and make improvements where they’re needed:

 

  • Step back and look at the bigger picture of where you currently are and how things can be improved. There’s always something that can be resolved or done differently to improve security. Do this away from the office on a business retreat or personal vacation. Bring in an unbiased outside party to highlight the gaps if necessary. After all, it’s hard to see the forest through the trees. The important thing is to ask yourself the brutal questions that you may have been avoiding up to this point. The answers to what needs to be done will surface.

 

  • Get management and users on board with your security initiatives and, just as importantly, do what it takes to keep them interested. Information security is not a one-time deal. It’s an ongoing philosophy. If they don’t want to get on board or seem to be interested, then look inward. Your approach may be broken. You need to meet them where they’re at, not where you want them to be.

 

  • Building on my point above, focus on your non-technical skills. Information security is way more than bits and bytes.
    Instead, it’s about communication, relationships, and the business as a whole.  You’ll likely find that deficiencies in these areas are holding you back as much as any technical security issue. Odds are that most of the technical challenges you face can be resolved with improvements in the non-technical areas of your security program.

 

  • Set reasonable goals that you can work on every day of every week and hold yourself accountable to see them through. It’s the hopes, dreams, and wishes approach that sets everyone up for failure. Unfortunately, that’s how many information security programs are run.

 

There’s no one root cause of your security challenges. That said, they’re often very predictable. If you want to see changes, it’s up to you to make things happen. No one else is going to do it for you. Sure, there are others outside of IT and security who are ultimately responsible for security. But if you’re in charge of day-to-day security then you need to be the driving force that makes things happen. The path of blaming others for your security shortcomings is tempting to go down – and it’s very easy to stay on. But it’s not for you. Let the other people who choose that path be the low-hanging fruit that malicious attackers prey on.

October is National Cyber Security Awareness month and Rapid7 is taking this time to celebrate security research. This year, NCSAM coincides with new legal protections for security research under the DMCA and the 30th anniversary of the CFAA - a problematic law that hinders beneficial security research. Throughout the month, we will be sharing content that enhances understanding of what independent security research is, how it benefits the digital ecosystem, and the challenges that researchers face.

 

When we began brainstorming ideas for NCSAM, I suggested something related to distributed denial of service (DDoS) attacks, specifically with a focus on the UDP amplification vulnerabilities that are typically abused as part of these attacks.  Rarely a day goes by lately in the infosec world where you don't hear about DDoS attacks crushing the Internet presence of various companies for a few hours, days, weeks, or more.  Even as I wrote this, DDoS attacks are on the front page of many major news outlets. A variety of services that I needed to write this very blog post were down because of DDoS, and I even heard DDoS discussed on the only radio station I am able to get where I live. Timely.

 

What follows is a brief primer on and a look at what resources Rapid7 provides for further understanding UDP amplification attacks.

 

Background

 

A denial of service (DoS) vulnerability is about as simple as it sounds -- this vulnerability exists when it is possible to deny, prevent or in some way hinder access to a particular type of service.  Abusing a DoS vulnerability usually involves an attack that consumes precious compute or network resources such as CPU, memory, disk, and network bandwidth.

 

A DDoS attack is just a DoS attack on a larger scale, often using the resources of compromised devices on the Internet or other unwitting systems to participate in the attack.

 

A distributed, reflected denial of service (DRDoS) attack is a specialized variant of the DDoS attack that typically exploits UDP amplification vulnerabilities.  These are often referred to as volumetric DDoS attacks, a more generic type of DDoS attack that specifically attempts to consume precious network resources.

 

A UDP amplification vulnerability occurs when a UDP service responds with more data or packets than the initial request that elicited the response(s). Combined with IP packet spoofing/forgery, attackers send a large number of spoofed UDP datagrams to UDP endpoints known to be susceptible to UDP amplification using a source address corresponding to the IP address of the ultimate target of the DoS.  In this sense, the forged packets cause the UDP service to "reflect" back at the DoS target.

 

The exact impact of the attack is a function of how many systems participate in the attack and their available network resources, the network resources available to the target, as well as the bandwidth and packet amplification factors of the UDP service in question. A UDP service that returns 100 bytes of UDP payload in response to a 1-byte request is said to have a 100x bandwidth amplification factor.  A UDP service that returns 5 UDP packets in response to 1 request is said to have a 5x packet amplification factor. Oftentimes a ratio is used in place of a factor. For example, a 5x amplification factor can also be said to have a 1:5 amplification ratio.

 

For more information, consider the following resources:

 

Sonar UDP Studies

 

Rapid7's Project Sonar has been performing a variety of UDP scans on a monthly basis and uploading the results to scans.io for consumption by the larger infosec/network community for nearly three years. Infosec practitioners can use this raw scan data to research a variety of aspects related to UDP amplification vulnerabilities, including geographic/sector specific patterns, amplification factors, etc.  There are, however, some caveats:

 

  • Although we do not currently have studies for all UDP services with amplification vulnerabilities, we have a fair number and are in the process of adding more.
  • Not all of these studies specifically cover the UDP amplification vulnerabilities for the given service.  Some happen to use other probe types more likely to elicit a response.  In these cases, the existence of a response for a given IP simply means that it responded to our probe for that service, is likely running that service in question, but doesn't necessarily imply that the IP in question is harboring a UDP amplification vulnerability.
  • Our current usage of zmap is such that we will only record the first UDP packet seen in response to our probe.  So, if a UDP service happens to suffer from a packet-based UDP amplification vulnerability, the Sonar data alone may not show the true extent.

 

Currently, Rapid7's Project Sonar has coverage for a variety of  UDP services that happen to be susceptible to UDP amplification attacks.

 

Dennis Rand, a security researcher from Denmark, recently reached out to us asking for us to provide regular studies of the qotd (17/UDP), chargen (19/UDP) and RIPv1 services (520/UDP). When discussing his use cases for these and the other existing Sonar studies, Dennis had the following to add:

 

"I've been using the dataset from Rapid7 UDP Sonar for various research projects as a baseline and core part of the dataset in my research has been amazing.

 

This data could be used by any ISPs out there to detect if they are potentially being part of the problem.  A simple task could be to setup a script that would pull the lists every month and the compare it against previous months, if at some point the numbers go way up, this could be an indication that you might have opened up for something you should not, or at least be aware of this fact in you internal risk assessment.

 

Also it is awesome to work with people who are first of doing this for free, at least seen from my perspective, but still being so open to helping out in the research, like adding new service to the dataset help me to span even wider in my research projects."

 

For each of the studies described below, the data provided on scans.io is gzip-compressed CSV with a header indicating the respective field values, which are, for every host that responded, the timestamp in seconds since the UNIX epoch, the source address and port of the response, the destination address and port (where Sonar does its scanning from), the IP ID, the TTL, and the hex-encoded UDP response payload, if any.  Precisely how to decode the data for each of the studies listed below is an exercise currently left for the reader that may be addressed in future documentation, but for now the descriptions below in combination with Rapid7's dap should be sufficient.

 

DNS (53/UDP)

 

This study sends a DNS query to 53/UDP for the VERSION.BIND text record in the CHAOS class. In some situations this will return the version of ISC BIND that the DNS server is running, and in others it will just return an error. Data can be found here in files with the -dns-53.csv.gz suffix.  In the most recent run of this study on 10/03/2016, there were 7,963,280 endpoints that responded.

 

NTP (123/UDP)

 

There are two variants of this study.

 

The first sends an NTP version 2 MON_GETLIST_1 request, which will return a list of all recently connected NTP peers, generally up to 6 per packet with additional peers sent in subsequent UDP responses. Responses for this study can be found here in files with the ntpmonlist-123.csv.gz suffix.  This probe used in this study is the same as one frequently used in UDP amplification attacks against NTP.  In the most recent run of this study on 10/03/2016, 1,194,146 endpoints responded.

 

The second variant of this study sends an NTP version 2 READVAR request and will return all of the internal variables known to the NTP process, which typically includes things like software version, information about the underlying OS or hardware, and data specific to NTP's time keeping. The responses can be found here in files with the ntpreadvar-123.csv.gz suffix. In the most recent run of this study on 10/03/2016, 2,245,681 endpoints responded.

 

Other UDP amplification attacks in NTP that continue to enable DDoS attacks are described in R7-2014-12.

 

NBNS (137/UDP)

 

This study has been described in greater detail here, but the summary is that this study sends an NBNS name request.  Most endpoints speaking NBNS will return a wealth of metadata about the node/service in question, including system and group/domain names and MAC addresses.  This is the same probe that is frequently used in UDP amplification attacks against NBNS.  The responses can be found here in files with the -netbios-137.csv.gz suffix.  In the most recent run of this study on 10/03/2016, 1,768,634 endpoints responded.

 

SSDP/UPnP (1900/UDP)

 

This study sends an SSDP request that will discover the rootdevice service of most UPnP/SSDP-enabled endpoints.  The responses can be found here in files with the -upnp-1900.csv.gzsuffix.  UDP amplification attacks against SSDP/UPnP often involve a similar request but for all services, often resulting in a 10x+ packet amplification and a 40x+ bandwidth amplification.  In the most recent run of this study on 10/03/2016, 4,842,639 endpoints responded.

 

Portmap (111/UDP)

 

This study sends an RPC DUMP request to version 2 of the portmap service.  Most endpoints exposing 111/UDP that are the portmap RPC service will return a list of all of the RPC services available on this node.  The responses can be found here in files with the -portmap-111.csv.gz suffix.  There are numerous ways to exploit UDP amplification vulnerabilities in portmap, including the same one used in the Sonar study, a portmap version 3 variant that is often more voluminous, and a portmap version 4 GETSTAT request.  In the most recent run of this study on 10/03/2016, 2,836,710 endpoints responded.

 

Quote of the Day (17/UDP)

 

The qotd service is essentially the UNIX fortune bound to a UDP socket, returning quotes/adages in response to any incoming 17/UDP datagram.  Sonar's version of this study sends an empty UDP datagram to the port and records any responses, which is believed to be similar to the variant used in the UDP amplification attacks.  The responses can be found here in files with the -qotd-17.csv.gzsuffix.  In the most recent run of this newly added study on 10/21/2016, a mere 2,949 endpoints responded.

 

Character Generator (19/UDP)

 

The chargen service is a service from a time when the Internet was a wholly different place.  The UDP variant of chargen will send a random number bytes in response to any datagram arriving on 19/UDP.  While most implementations stick to purely ASCII strings of random lengths between 0 and 512, some are much chattier, spewing MTU-filling gibberish, packet after packet.  The responses can be found here in files with the -chargen-19.csv.gz suffix.  In the most recent run of this newly added study on 10/21/2016, only 3,791 endpoints responded.

 

RIPv1 (520/UDP)

 

UDP amplification attacks against the Routing Information Protocol version 1 (RIPv1) involve sending a specially crafted request that will result in RIP responding with 20 bytes of data for every route it knows about, with up to 25 routes per response for a maximum response size of 504 bytes, but RIP instances with more than 25 routes will split responses over multiple packets, adding packet amplification pains to the mix.  The responses can be found here in files with the -ripv1-520.csv.gzsuffix.  In the most recent run of this newly added study on 10/21/2016, 17,428 endpoints responded.

 

metasploit modules

 

Rapid7's Metasploit has coverage for a variety of these UDP amplification vulnerabilties built into "scanner" modules available to both the base metasploit-framework as well as the Metasploit community and Professional editions via:

 

 

Each of these modules uses the Msf::Auxiliary::UDPScanner mixin to support scanning multiple hosts at the same time. Most send probes and analyze the responses with the Msf::Auxiliary::DRDoS mixin to automatically calculate any amplification based on a high level analysis of the request/response datagram(s).

 

Here is an example run of auxiliary/scanner/ntp/ntp_monlist:

 

msf auxiliary(ntp_monlist) > run
[+] 192.168.33.127:123 NTP monlist request permitted (5 entries)
[+] 192.168.32.139:123 NTP monlist request permitted (4 entries)
[+] 192.168.32.139:123 - Vulnerable to NTP Mode 7 monlist DRDoS (CVE-2013-5211): No packet amplification and a 37x, 288-byte bandwidth amplification
[+] 192.168.33.127:123 - Vulnerable to NTP Mode 7 monlist DRDoS (CVE-2013-5211): No packet amplification and a 46x, 360-byte bandwidth amplification
[+] 192.168.32.138:123 NTP monlist request permitted (31 entries)
[+] 192.168.33.128:123 NTP monlist request permitted (23 entries)
[+] 192.168.32.138:123 - Vulnerable to NTP Mode 7 monlist DRDoS (CVE-2013-5211): 6x packet amplification and a 285x, 2272-byte bandwidth amplification
[+] 192.168.33.128:123 - Vulnerable to NTP Mode 7 monlist DRDoS (CVE-2013-5211): 4x packet amplification and a 211x, 1680-byte bandwidth amplification
[+] 192.168.33.200:123 - Vulnerable to NTP Mode 7 monlist DRDoS (CVE-2013-5211): 2x packet amplification and a 2x, 8-byte bandwidth amplification
[*] Scanned 256 of 512 hosts (50% complete)
[+] 192.168.33.251:123 NTP monlist request permitted (10 entries)
[+] 192.168.33.251:123 - Vulnerable to NTP Mode 7 monlist DRDoS (CVE-2013-5211): 2x packet amplification and a 92x, 728-byte bandwidth amplification
[+] 192.168.33.254:123 - Vulnerable to NTP Mode 7 monlist DRDoS (CVE-2013-5211): 2x packet amplification and a 2x, 8-byte bandwidth amplification
[*] Scanned 512 of 512 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(ntp_monlist) >

 

There is also the auxiliary/scanner/udp/udp_amplification module recently added as part of metasploit-framework PR 7489 that is designed to help explore UDP amplification vulnerabilities and audit for the presence of existing ones.

 

Nexpose coverage

 

Rapid7's Nexpose product has coverage for all of the ntp vulnerabilities described above and in R7-2014-12, along with:

 

 

Additional information about Nexpose's capabilities with regards to UDP amplification vulnerabilities can be found here.

 

Future Research

 

UDP amplification vulnerabilities have been lingering since the publication of RFC 768 in 1980, but only in the last couple of years have they really become a problem.  Whether current and historical efforts to mitigate the impact that attacks involving UDP amplification have been effective is certainly debatable.  Recent events have shown that only very well fortified assets can survive DDoS attacks and UDP amplification still plays a significant role.  It is our hope that the open dissemination of active scan data through projects like Sonar and the availability of tools for detecting the presence of this class of vulnerability will serve as a valuable tool in the fight against DDoS.

 

If you are interested in collaborating on Metasploit modules for detecting other UDP amplification vulnerabilities, submit a Metasploit PR. If you are interesting in having Sonar perform additional relevant studies, have interests in related research, or if you have questions, we welcome your comments here as well as by reaching out to us at research@rapid7.com.

 

Enjoy!

This is a guest post from Art Manion, Technical Manager of the Vulnerability Analysis Team at the CERT Coordination Center (CERT/CC). CERT/CC is part of the Software Engineering Institute at Carnegie Mellon University.

 

October is National Cyber Security Awareness month and Rapid7 is taking this time to celebrate security research. This year, NCSAM coincides with new legal protections for security research under the DMCA and the 30th anniversary of the CFAA - a problematic law that hinders beneficial security research. Throughout the month, we will be sharing content that enhances understanding of what independent security research is, how it benefits the digital ecosystem, and the challenges that researchers face.

 

The CERT/CC has been doing coordinated vulnerability disclosure (CVD) since 1988. From the position of coordinator, we see the good, bad, and ugly from vendors, security researchers and other stakeholders involved in CVD. In this post, I'm eventually going to give some advice to security researchers. But first, some background discussion about sociotechnical systems, the internet of things, and chilling effects.

 

While there are obvious technological aspects of the creation, discovery, and defense of vulnerabilities, I think of cybersecurity and CVD as sociotechnical systems. Measurable improvements will depend as much on effective social institutions ("stable, valued, recurring patterns of [human] behavior") as they will on technological advances. The basic CVD process itself -- discover, report, wait, publish -- is an institution concerned with socially optimal [PDF] protective behavior. This means humans making decisions, individually and in groups, with different information, incentives, beliefs, and norms. Varying opinions about "optimal" explain why, despite three decades of debate and both offensive and defensive technological advances, vulnerability disclosure remains a controversial topic.

 

To add further complication, the rapid expansion of the internet of things has changed the dynamics of CVD and cybersecurity in general. Too many "things" have been designed with the same disregard to security associated with internet-connected systems of the 1980s, combined with the real potential to cause physical harm. The Mirai botnet, which set DDoS bandwidth records in 2016, used an order of magnitude fewer username and password guesses than the Morris worm did in 1988. Remote control attacks on cars and implantable medical devices have been demonstrated. The stakes involved in software security and CVD are no longer limited to theft of credit cards, account credentials, personal information, and trade or national secrets.

 

In pursuit of socially optimal CVD and with consideration for the new dynamics of IoT, I've become involved in two policy areas: defending beneficial security research and defining CVD process maturity. These two areas intersect when researchers chose CVD as part of their work, and that choice is not without risk to the researcher.

 

The security research community has valid and serious concerns about the chilling effects, real and perceived, of legal barriers and other disincentives [PDF] to performing research and disclosing results. On the other hand, there is a public policy desire to differentiate legitimate and beneficial security research from criminal activity. The confluence of these two forces leads to the following conundrum: If rules for security researchers are codified -- even with broad agreement from researchers, whose opinions differ -- any research activity that falls out of bounds could be considered unethical or even criminal.

 

Codified rules could reduce they grey area created by "exceeds authorized access" and the steady supply of new vulnerabilities (often discovered by accessing things in interesting and unexpected ways). But with CVD, and most complex interactions, the exception is the rule and CVD is full of grey. Honest mistakes, competing interests, language, time zone, and cultural barriers, disagreements and other forms of miscommunication are commonplace. There's still too little information and too many moving parts to codify CVD rules in fair and effective way.

 

Nonetheless, I see value in improving the quality of vulnerability reports and CVD as an institution, so here is some guidance for security researchers who choose the CVD option. Most of this advice is based on my experience at the CERT/CC for the last 15 years, which is bound to include some personal opinion, so caveat lector.

 

  • Be aware. In three decades of debate, a lot has been written about vulnerability disclosure. Read up, talk to your peers. If you're subject to U.S. law and read only one reference, it should be the EFF's Coders' Rights Project Vulnerability Reporting FAQ.

 

  • Be humble. Your vulnerability is not likely the most important out of 14,000+ public disclosures this year. Please think carefully before registering a domain for your vulnerability. You might fully understand the system you're researching, or you might not, particularly if the system has significant, non-traditional-compute context, like implantable medical devices.

 

  • Be confident. If your vulnerability is legit, then you'll be able to demonstrate it, and others will be able to reproduce. You're also allowed to develop your reputation and brand, just not at a disproportionate cost to others.

 

  • Be responsible. CVD is full of externalities. Admit when you're wrong, make clarifications and corrections.

 

  • Be concise. A long, rambling report or advisory costs readers time and mental effort and is usually an indication of a weak or invalid report. If you've got a real vulnerability, demonstrate it clearly and concisely.

 

  • PoC||GTFO. This one goes hand in hand with being concise. Actual PoC may not be necessary, but provide clear evidence of the vulnerable behavior you're reporting and steps for others to reproduce. Videos might help, but they don't cut it by themselves.

 

  • Be clear. Both with your intentions and your communications. You won't reach agreement with everyone, particularly about when to publish, but try to avoid surprises. Use ISO 8601 date/time formats. Simple phrasing, avoid idiom.

 

  • Be professional. Professionals balance humility, confidence, candor, and caution. Professionals don't need to brag. Professionals get results. Let your work speak for itself, don't exaggerate.

 

  • Be empathetic. Vendors and the others you're dealing with have their own perspectives and constraints. Take some extra care with those who are new to CVD.

 

  • Minimize harm. Public disclosure is harmful. It increases risk to affected users (in the short term at least) and costs vendors and defenders time and money. The theory behind CVD is that in the long run, public disclosure is universally better than no disclosure. I'm not generally a fan of analogies in cybersecurity, but harm reduction in public health is one I find useful (informed by, but different than this take). If your research reveals sensitive information, stop at the earliest point of proving the vulnerability, don't share the information, and don't keep it. Use dummy accounts when possible.

 

In a society increasingly dependent on complex systems, security research is important work, and the behavior of researchers matters. At the CERT/CC, much of our CVD effort is focused on helping others build capability and improving institutions, thus, the advice above. We do offer a public CVD service, so if you've reached an impasse, we may be able to help.

 

Art Manion is the Technical Manager of the Vulnerability Analysis team in the CERT Coordination Center (CERT/CC), part of the Software Engineering Institute at Carnegie Mellon University. He has studied vulnerabilities and coordinated responsible disclosure efforts since joining CERT in 2001. After gaining mild notoriety for saying "Don't use Internet Explorer" in a conference presentation, Manion now focuses on policy, advocacy, and rational tinkering approaches to software security, including standards development in ISO/IEC JTC 1 SC 27 Security techniques. Follow Art at @zmanion and CERT at @CERT_Division.

Deral Heiland

Avoiding Default Fail

Posted by Deral Heiland Employee Oct 26, 2016

As the Internet of Things (IoT) quickly flood into the market place, into our homes and into our places of employment, my years of pen testing experience and every research project I spin up reminds me IoT has weak defaults -- especially default passwords, which will be the undoing of all of us.

 

passwd.jpg

 

You would think after pointing out the issues with default password for years most of us would learn to start changing those passwords before deployment. Unfortunately that’s not the case. I think we are aware of the massive Distributed Denial of Service (DDoS) attacks that have taken place and impacting availability of resources and services on the Internet over the last couple weeks. Malware infected IoT devices are being used to cause these DDoS.  The malware, also know as Mirai, leveraged default passwords in IoT devices to infect these devices and mark them as part of a large Bot-Net which was then used to conduct DDoS attacks. As we begin to use IoT-based technology more, we need to be diligent about how default settings, such as passwords, are maintained. As shown by these DDoS attacks, if we do not properly reconfigure the passwords on our devices when they are deployed, then they could potentially be used to cause mayhem on the internet, impacting us all.

 

To go beyond the simple network service password issues we have other default settings that are typically overlooked. The two that come to mind are Wi-Fi SSID and WPA/WPA2 Pre shared keys. Since a large number of the IoT based technologies also utilize Wi-Fi services, we need to take a closer look at these solutions during deployment.

 

First, lets talk about the Service Set Identifier SSID. SSID is the human readable name that gets assigned to the wireless network. You may be thinking, "what's wrong with the SSID name? It can't be used to attack me." Maybe not directly, but it does often reveal the product details that have been deployed and that information can then be used by a malicious actor to plan out how he or she can attack you. I always encourage users to rename the SSID to something completely different and unrelated to yourself or your location. This may not stop a knowledgeable attacker but at least it doesn’t make their job easier.

 

Next are Wi-Fi passwords, typically referenced as Pre-Shared Keys (PSK). Though the default setting of the PSK may appear to be complex (Figure 1), it is not and in many cases is easily cracked in a short period of time. For example, if a malicious actor is successful in identifying the product that is in use, they can then identify the standard default PSK length and pattern being used. This information can then be leveraged further to decrease the length of time needed to crack the PSK. So the solution is to never trust the defaults, but rather change the defaults when you deploy the technology.

 

psk.pngFigure 1:  Default WPA2 PSK

 

So when it comes to proper use of passwords, whether network or Wi-Fi, I would recommend a long password that is at least 32 characters, contains alpha numeric, upper and lower case, and a special character. I know such passwords can be difficult or impossible to remember, I feel your pain. So another option is passphrases. Passphrases can be difficult to guess and crack, but often are easy for the owner to remember because it has meaning to them. For example the phrase “My favorite vacation was in Peru” is 32 characters including spaces, making it hard to guess. It has meaning to me, the owner, so I can more easily remember it. If you want to make this password even better, you could easily change some characters to numbers or special characters and modify the case on other characters. *For example “my faVorit3 vaCation wa$ in Peru.” It's the same phrase just made more secure with a few simple alterations. With these minor alterations, it makes the passphrase more complex and it is unlikely anyone will ever guess or easily crack your password.

 

*Editor's Note: This is not Deral's password, and it shouldn't be yours either. It's already been used on the internet!

This is a guest post from Kurt Opsahl, Deputy Executive Director and General Counsel of the Electronic Frontier Foundation.

 

October is National Cyber Security Awareness month and Rapid7 is taking this time to celebrate security research. This year, NCSAM coincides with new legal protections for security research under the DMCA and the 30th anniversary of the CFAA - a problematic law that hinders beneficial security research. Throughout the month, we will be sharing content that enhances understanding of what independent security research is, how it benefits the digital ecosystem, and the challenges that researchers face.

 

It’s been thirty years since Congress enacted the Computer Fraud and Abuse Act, the primary federal law to criminalize hacking computers. Since 1986, the CFAA has been amended many times, most often to make the law harsher and more expansive.

 

While it was written to focus on what were then relatively rare networked computers, the ubiquity of the Internet means today that almost every machine more useful than a portable hand held calculator is a “protected computer” under the law.

 

As the anti-hacking law’s scope expanded, so did the penalties. Today there is little room for hacking misdemeanors under the CFAA.  Even where there is, there’s virtually no crime that can’t be upgraded to a felony by an aggressive U.S. Attorney through the simple expedient of tying the crime to a parallel state law.  This ends up meaning that you might get sentenced to community service for vandalizing a printed billboard, but endure two years in prison for vandalizing a Web page.

 

There are many problems with the CFAA and its interpretation. The Department of Justice has used the anti-hacking law to criminalize violations of Terms of Service or iterating a URL. But one problem stands out: the over-criminalization of curiosity.

Hacker Manifesto_Crime is that of curiosity.png

A few months before the CFAA originally passed, the e-zine Phrack published the The Hacker Manifesto, in which The Mentor explained to the world his crime: curiosity. The Mentor, a hacker affiliated with the Legion of Doom, celebrated exploring and outsmarting, discovering a “door opened to a world” beyond the mendacity of the day-to-day.

 

Over the years of working on the EFF’s Coders’ Rights Project, we’ve had the honor of representing many smart and skilled security researchers, who’ve made considerable contributions to our collective security.

 

We won’t be naming names, but at least a few of these luminaries got their start in computer security from curiosity, figuring out at a young age how the machines in their lives worked, and how to make those machines work in unexpected ways. An intellectual adventure, but one fraught with the risk that these unexpected ways could cross the line into “access without authorization,” and then felony charges.

 

Perhaps the clearest example of the danger of criminalizing curiosity comes from the prosecution of Aaron Swartz.  In 2011, a federal grand jury in Massachusetts charged Aaron Swartz with multiple felonies for his alleged computer intrusion to download a large number of academic journal articles from the MIT network.

 

Swartz was instrumental in the development of key parts of modern technologies, including RSS, Creative Commons, and Reddit, getting his start at an early age.  He was just 14 when he joined the working group that authored RSS 1.0. Yet for his curiosity, Swartz was facing a maximum sentence of decades in prison.  Realistically, he would have had to serve less time, but even so he would have been saddled with felony convictions forever.  Instead, Swartz took his own life, and the world lost a bright star could have continued to bring great things to the Internet.

 

Paul Allen and Bill Gates provide the counterexample. In his autobiography, Allen told the story of when the two founders of Microsoft “got hold of” an administrator password at the Computer Center Corporation (which they called C-Cubed), a company that provided timeshare computers to the pair.

 

With the cost of access mounting, eighth grade Allen and Gates wanted to use the password to give themselves free access to the timeshare servers.  However, C-Cubed discovered the hack.  As Allen explained:

“We hoped we'd get let off with a slap on the wrist, considering we hadn't done anything yet. But then the stern man said it could be ‘criminal’ to manipulate a commercial account. Bill and I were almost quivering.”

But instead of calling the police, Dick Wilkinson, one of C-Cubed’s partners, kicked them off the system for six weeks, letting them off with a warning. Eventually, C-Cubed exchanged free computer time for bug reports, allowing the kids to play and learn, so long as they carefully documented what led the computer to crash.

 

Computer security will always be difficult, and protecting our networks and devices requires the hard work of skilled security researchers to find, publish and fix vulnerabilities. The skills that allow security researchers to discover vulnerabilities and develop proof of concept exploits are often rooted in satisfying their curiosity, sometimes breaking some rules along the way.

 

Society may still want to discourage intentionally destructive behavior, and hold people accountable for any harm they may have caused, but certainly not every hack needs to be a felony, backed by stiff sentences and they lifelong encumbrances that come with being a felon. By allowing for infractions and misdemeanors, coupled with recognition that a little mischief may be an early sign of someone who will be vital to protecting us all.

 

Kurt Opsahl is the Deputy Executive Director and General Counsel of the Electronic Frontier Foundation. In addition to representing clients on civil liberties, free speech and privacy law, Opsahl counsels on EFF projects and initiatives. Opsahl is the lead attorney on the Coders' Rights Project, and is representing several companies who are challenging National Security Letters. Additionally, Opsahl co-authored "Electronic Media and Privacy Law Handbook." Follow Kurt at @kurtopsahl and the EFF at @eff.

Since its inception, our wonderful connected world has been a battleground for cybercriminals vs law enforcement and security professionals, who are locked into a twisted dance of punches and counterpunches as the arena in which they fight evolves around them. We continue to connect more and more Things, providing new and elaborate opportunities for attackers to launch their weapons of mass disruption.

 

Not everything is awesome, but you are part of a team!lego.JPG

Somewhere down the line, if you’re connected you’re going to be (or have already been) affected – whether it’s a device you own being pwned, or your account being compromised on a third party system. Cybercrime doesn’t care which language(s) you speak, or where you pay your taxes, your data and information have a value either directly or indirectly (I can pretty much guarantee that someone reading this will have at some point re-used a web account password on their corporate network account). As cybercrime naturally transcends traditional borders, a consolidated global effort is required to combat this global foe. And yes, it needs reiterating – We Are All Responsible – you can’t reap the benefits of the internet without playing a part in keeping it safe. You don’t necessarily have to be an expert either – Team Global Security, which you are a part of (welcome to all of our new members!), has some very strong players in its ranks, and regardless of your level of expertise you do have an important part to play. Awareness, vigilance and frankly Just Not Being Bloody Stupid (yeah I’m looking at you, with the re-used password on your corporate account – go and change it right now, thanks) are all important ways in which you can help the cause.

 

You have the security industry and profession on your side, and your government too. That’s pretty solid backing I’d say. If you’ve ever uttered the words “the government should be doing something about this” then you’ll be pleased to know when it comes to Cyber Security there are multiple collaborative initiatives happening Right Now. “Wow, that IS awesome!” I hear you say. Yes. Very Awesome Indeed.

 

So what’s going on?

As I type this blog, the U.S. are in the midst of the 13th annual National Cyber Security Awareness Month – a joint venture between the National Cyber Security Alliance (NCSA) and the U.S. Department of Homeland Security (DHS). Every week in October has a theme [PDF], covering everything from securing critical infrastructure to how to practice good security habits on your personal devices. If you’re of a Twitter persuasion, take a look at the #ncsam or #cyberaware tweets to get information and advice from industry gurus, vendors and businesses. Or if you love our blog (and of course you do), check out the series we have going. And whilst this is billed a U.S. party, Team Global Security can absolutely benefit from the event.

 

ncschq_1064381.jpgAcross the pond in the UK, the big news here is the opening of the National Cyber Security Centre. Whilst many of the NCSC team will operate from GCHQ in Cheltenham, around half of the 700 staff will be based in some rather stunning London offices close to Buckingham Palace.

Via four key objectives, the centre aims to be the beating heart of the Government’s strategy for the UK to become “the safest place to live and work online”.

These objectives cover a multitude of areas, ranging from the all-important knowledge sharing through to being front and centre on critical national cyber security issues:

  • To understand the cyber security environment, share knowledge, and use that expertise to identify and address systemic vulnerabilities.
  • To reduce risks to the UK by working with public and private sector organisations to improve their cyber security.
  • To respond to cyber security incidents to reduce the harm they cause to the UK.
  • To nurture and grow our national cyber security capability, and provide leadership on critical national cyber security issues.

The centre opening coincided with the launch of a new website, which is an excellent resource for both people and organisations in the UK, and for the wider global audience too.

 

mbs.jpg

In Singapore, the government recently announced the formation of GovTech – a new agency established to “transform public service delivery with citizen-centric services and products.” Security naturally falls under the remit of the agency - GovTech will also play a critical role in overseeing the public sector’s ICT infrastructure, putting in place policies for critical infrastructure and cybersecurity to enable the operation of a secure and resilient Smart Nation.

 

No matter whether you’re a citizen of the US, the UK, Singapore, or somewhere else entirely, there is plenty of information, advice and best practice sitting at your fingertips. Global issues need a global response, and these initiatives are vital efforts to help us all enjoy this wonderful connected world.

 

Rapid7 has your back

If you think your organisation would benefit from some cyber security awareness training, maybe it’s time to book in a pen test, or you’d like some help with your overall security program - we’re happy to help you. Do you need more foot soldiers to help you fight the good fight? Your army of cyber guardians are ready for enlistment [PDF]. Our team is your team – let us know how we can be of assistance.

Executive Summary

 

While examining the functionality of three vendors' device tracker products, a number of issues surfaced that leak personally identifying geolocation data to unauthorized third parties. Attackers can leverage these vulnerabilities to locate individual users' devices, and in some cases, alter geolocation data for those devices. The table below briefly summarizes the twelve vulnerabilities identified across three products.

 

Vulnerability

Device

R7 ID

CVE

Cleartext Password

TrackR Bravo

R7-2016-18.1

CVE-2016-6538

Tracking ID Exposed

TrackR Bravo

R7-2016-18.2

CVE-2016-6539

Unauthenticated Access

TrackR Bravo

R7-2016-18.3

CVE-2016-6540

Unauthenticated Pairing

TrackR Bravo

R7-2016-18.4

CVE-2016-6541

Tracking ID Exposed

iTrack Easy

R7-2016-20.1

CVE-2016-6542

Duplicate Registration

iTrack Easy

R7-2016-20.2

CVE-2016-6543

Unauthenticated Modification

iTrack Easy

R7-2016-20.3

CVE-2016-6544

Weak Session Management

iTrack Easy

R7-2016-20.4

CVE-2016-6545

Base64 Encoded Password

iTrack Easy

R7-2016-20.5

CVE-2016-6546

Cleartext Password

Zizai Tech Nut

R7-2016-22.1

CVE-2016-6547

Session Token Leaked

Zizai Tech Nut

R7-2016-22.2

CVE-2016-6548

Unauthenticated Pairing

Zizai Tech Nut

R7-2016-22.3

CVE-2016-6549

 

Credit

 

These issues were discovered by Deral Heiland and Adam Compton of Rapid7, Inc. and disclosed in accordance with Rapid7's disclosure policy.

 

Product Description

 

Bluetooth Low Energy (BLE) device trackers are small hardware tokens that are designed to be attached to personal items such as keyrings, wallets, or purses. These devices pair with the user's smartphone via Bluetooth, and can alert the user when the device moves out of range. The tracking hardware tokens themselves do not maintain network connections, but rely on associated smartphone apps to report geolocation data.

 

The devices examined were the TrackR Bravo from TrackR, the iTrack Easy from KKMCM.com, and the Nut from Zizai Tech. The Tile from TILE, Inc. was also examined, but none of these issues were discovered with this product, aside from a minor screenshot caching issue which does not appear to reveal private information.

 

Vulnerability Details

 

For each product, vulnerability details and possible mitigations are discussed below. Users concerned about these issues should reach out to their respective vendors using their normal support mechanisms, and update their mobile applications when fixes are released.

 

Until vendor-supplied fixes are available, the risks associated with these vulnerabilities should be weighed against the benefits of continuing to use these tracker devices and applications.

 

Most of the vulnerabilities described are only exploitable by an adversary who is in close physical proximity to the affected devices; the effective range of an exploit is noted on the summary table for each vendor.

R7-2016-18: Multiple Vulnerabilities in Trackr Bravo

 

Vulnerability

R7 ID

CVE

Range

Cleartext Password

R7-2016-18.1

CVE-2016-6538

Local Device

Tracking ID Exposed

R7-2016-18.2

CVE-2016-6539

Bluetooth

Unauthenticated Access

R7-2016-18.3

CVE-2016-6540

Internet

Unauthenticated Pairing

R7-2016-18.4

CVE-2016-6541

Bluetooth

 

The TrackR mobile app also caches screenshots when minimized; while no critical information appears to be exposed in this way, it is a best practice to clear unique data and use a generic application image for context switching.

R7-2016-18.1: Cleartext Password (CVE-2016-6538)

Examination of the TrackR Bravo mobile application running on an iPad revealed that the account password used to authenticate to the cloud API was stored in cleartext in the cache.db. Examining the cache.db file reveals the cleartext password as shown in Figure 1.

TrackR cleartext password_Fig 1.pngGiven typical user habits of password reuse, this sort of password disclosure can impact other online services.

 

Mitigation for R7-2016-18.1

A vendor-supplied patch should configure the mobile app to prevent storing potentially sensitive information such as passwords in cleartext. While some local storage is likely necessary for normal functionality, such information should be stored in an encrypted format that requires device authentication.

 

Users are strongly advised to avoid reusing passwords between services whenever possible in order to limit the damaging effects of accidental or intentional exposure of account credentials.

 

R7-2016-18.2: Device Tracking ID Exposed (CVE-2016-6539)

The TrackR device ID can be obtained by being in close proximity to a TrackR device and utilizing a Bluetooth low energy (BLE) application to monitor for BLE devices. The TrackR ID is the manufacturer device ID, which is constructed of a manufacture identifier of four zeroes (0000), followed by the BLE MAC address in reverse (0f7c-XXXXXXd9) for a combined TrackR ID of 00000f7c-XXXXXXd9. This is shown in Figure 2.

 

TrackR device ID_Fig 2.png

Mitigation for R7-2016-18.2

A vendor-supplied patch should change the tracker ID so that is not directly related to the manufacturer device ID, nor the device's BLE MAC address.

 

Absent a vendor-supplied patch, users should be mindful of when they use the TrackR device in public spaces, as this ID can be reused on the cloud-hosted service to track devices (and therefore, the user) remotely as described in R7-2016-18.3.

 

R7-2016-18.3: Unauthenticated Access (CVE-2016-6540)

Unauthenticated access to the cloud-based service maintained by the vendor is allowed for querying or sending GPS data. Authentication appears to only be used to sync data back to the mobile application during application install or reinstall.

 

An adversary can access GPS data for any TrackR device from any web browser without authentication by using the tracker ID number (Figure 3), which can be discovered while being in Bluetooth range, as described above as R7-2016-18.2. The URL format is https://phonehalocloud.appspot.com/rest/tracker/00000f7c-XXXXXXd9.

 

TrackR tracker ID Bluetooth URL.png

Mitigation for R7-2016-18.3

A vendor-supplied patch to the cloud service should enable authentication before GPS data can be queried or written to the via the cloud service API.

 

Absent a vendor-supplied patch, users should be mindful of when they use the TrackR device in public which will expose the device ID, as described in R7-2016-18.2.

 

R7-2016-18.4: Unauthenticated Pairing (CVE-2016-6541)

TrackR Bravo device allows unauthenticated Bluetooth pairing, which allows unauthenticated connected applications to write data to various device attributes.

 

In the below example, this vulnerability allowed the device's advertised name to be changed via BLE - Generic Access 0x1800 Device name 0x2A00 as shown in Figure 4:

TrackR Device Name Change_Fig 4.png

This lack of write access authorization also allows an adversary to enable the device's remote alarm, triggering the alarm to both cause annoyance and drain the device's battery. Figure 5 describes this access via "BLE - Generic Access 0x1802 Device name 0x2A06."

 

TrackR alarm trigger_Fig 5.png

 

Mitigation for R7-2016-18.4

While the device is designed to pair with any nearby application to perform crowd-sourced, opportunistic geolocation services, a vendor-supplied patch should enable proper authenticated pairing for write access so only the authorized user's mobile application can pair and alter data on the device.

 

Absent a vendor-supplied patch, users should be mindful using the TrackR device in public spaces.

 

R7-2016-20: Multiple Vulnerabilities in iTrack Easy

 

Vulnerability

R7 ID

CVE

Range

Tracking ID Exposed

R7-2016-20.1

CVE-2016-6542

Bluetooth

Duplicate Registration

R7-2016-20.2

CVE-2016-6543

Internet

Unauthenticated Modification

R7-2016-20.3

CVE-2016-6544

Internet

Weak Session Management

R7-2016-20.4

CVE-2016-6545

WLAN

 

The iTrack mobile app also caches screenshots when minimized; while no critical information appears to be exposed in this way, it is a best practice to clear unique data and use a generic application image for context switching.

 

R7-2016-20.1: Tracking ID Exposed (CVE-2016-6542)

The iTrack device tracking ID number, also called "LosserID" in the web API, can be obtained by being in range of an iTrack device. The tracker ID is the device's BLE MAC address, as shown in Figure 6.

 

iTrack tracker ID_Fig 6.png

 

Mitigations for R7-2016-20.1

A vendor-supplied patch should change the tracker ID so that is not directly related to the manufacturer device ID, nor the device's BLE MAC address.

 

Absent a vendor-supplied patch, users should be mindful of when they use the iTrack device in public spaces, as this ID can be reused on the cloud-hosted service to track devices (and therefore, the user) remotely as described in R7-2016-20.2 and R7-2016-20.3.

 

R7-2016-20.2: Duplicate Registration (CVE-2016-6543)

A captured device MAC/losserid can be registered under multiple user accounts, as seen in Figure 7, allowing shared access to the cmd:getgps data.

 

iTrack losserid_Fig 7.png

This getgps data value is set when an iTrack device comes into detection range of another user's iTrack mobile application. The mobile application then sets the getgps GPS data for that detected device's losserID with the cmd:setothergps.

 

This vulnerability can be exploited by an adversary to register the authorized user's device, and therefore gain access to GPS data any time the device comes in proximity of a running instance of the iTrack mobile application.

 

Mitigations for R7-2016-20.2

A vendor-supplied patch should prevent the duplicate registration of devices.

 

Absent a vendor-supplied patch, users should be mindful of using the iTrack device in public spaces, as described in R7-2016-20.1.

 

R7-2016-20.3: Unauthenticated Modification (CVE-2016-6544)

The getgps data can be written without authentication by setting the data using the parametercmd:setothergps. An example of this is shown in Figure 8.

 

iTrack getgps_Fig 8.png

This vulnerability can be exploited by an adversary to alter the GPS location data of a lost device.

 

Mitigations for R7-2016-20.3

A vendor-supplied patch should require authentication before allowing write access for the data stored for getgps.

 

R7-2016-20.4: Weak Session Management (CVE-2016-6545)

Session cookies are not used for maintaining valid sessions. The user's password is passed as a POST parameter over HTTPS using a base64 encoded passwd field on every request. An example of this is shown in Figure 9, collected using standard man-in-the-middle (MitM) techniques.

iTrack passwd field_Fig 9.png

It is a best practice to manage web service sessions with session cookies, rather than resending the user's password. Session cookies can be expired or invalidated upstream after a timeout period or in the event of a compromise. In this implementation, sessions can only be terminated when the user changes the associated password.

 

Mitigations for R7-2016-20.4

A vendor-supplied patch should enable proper session management.

 

Absent a vendor-supplied patch, users should be mindful of when they use the iTrack device in public spaces and avoid connecting their mobile device to an unknown or open, public WiFi access point.

 

R7-2016-20.5: Cleartext, Base64-Encoded Password (CVE-2016-6546)

Examination of the iTrack Easy mobile application running on an iPad revealed that the account password used to authenticate to the cloud API was stored in a cleartext format in the cache.db. Examining the cache.db file reveals the base64-encoded password as shown in Figure 10.

iTrack cleartext password_Fig 10.png

Given typical user habits of password reuse, this sort of password disclosure can impact other online services.

 

Mitigation for R7-2016-20.5

A vendor-supplied patch should configure the mobile app to prevent storing potentially sensitive information such as passwords in cleartext. While some local storage is likely necessary for normal functionality, such information should be stored in an encrypted format that requires device authentication.

 

Users are strongly advised to avoid reusing passwords between services whenever possible in order to limit the damaging effects of accidental or intentional exposure of account credentials.

 

R7-2016-22: Multiple Vulnerabilities in Zizai Tech Nut

 

Vulnerability

R7 ID

CVE

Range

Cleartext Password

R7-2016-22.1

CVE-2016-6547

Local Device

Session Token Leaked

R7-2016-22.2

CVE-2016-6548

WLAN

Unauthenticated Pairing

R7-2016-22.3

CVE-2016-6549

Bluetooth

 

R7-2016-22.1: Cleartext Password (CVE-2016-6547)

Examination of the Zizai Tech Nut mobile application running on an iPad revealed that the account password used to authenticate to the cloud API was stored in cleartext in the cache.db. Examining the cache.db file reveals the cleartext password as shown in Figure 11.

Zizai Tech Nut password cleartext_Fig 11.png

Given typical user habits of password reuse, this sort of password disclosure can impact other online services.

 

Mitigation for R7-2016-22.1

A vendor-supplied patch should configure the mobile app to prevent storing potentially sensitive information such as passwords in cleartext. While some local storage is likely necessary for normal functionality, such information should be stored in an encrypted format that requires device authentication.

 

Users are strongly advised to avoid reusing passwords between services whenever possible in order to limit the damaging effects of accidental or intentional exposure of account credentials.

 

R7-2016-22.2: Session Token Leaked (CVE-2016-6548)

Examination of the Nut mobile application running on an iPad revealed three requests which communicated without encryption (HTTP, rather than HTTPS). These requests contained the user's authenticated session token within the URL. Examples of these URLs are shown in the table below.

 

 

 

An adversary can capture these requests and reuse the session token to gain full access to the user's account. An example of this technique is shown in Figure 12.

Zizai Tech Nut session token_Fig 12.png

 

Mitigation for R7-2016-22.2

A vendor-supplied patch should configure the mobile app to always communicate over HTTPS, rather than the cleartext HTTP protocol. In addition, the mobile application should pass session tokens only via HTTP headers or as part of a POST request, rather than embedding the token in the URL.

 

Absent a vendor-supplied patch, users should be mindful of when they use the Nut mobile application in public spaces and avoid connecting their mobile device to an unknown or open, public WiFi access point.

 

R7-2016-22.3: Unauthenticated Pairing (CVE-2016-6549)

The Nut device allows unauthenticated Bluetooth pairing, which allows unauthenticated connected applications to write data to the device name attribute.

 

In the below example, this vulnerability allowed the device's advertised name to be changed via BLE - Generic Access 0x1800 Device name 0x2A00 as shown in Figure 13:

 

Zizai Tech Nut device name_Fig 13.png

 

Mitigation for R7-2016-22.3

While the device is designed to pair with any nearby application to perform crowd-sourced, opportunistic geolocation services, a vendor-supplied patch should enable proper authenticated pairing for write access so only the authorized user's mobile application can pair and alter data on the device.

 

Absent a vendor-supplied patch, users should be mindful using the Nut device in public spaces.

 

Disclosure Timeline

This vulnerability is being disclosed in accordance with Rapid7's disclosure policy.

 

  • Thu, Aug 25, 2016: Attempted contact with vendors.
  • Fri, Sep 09, 2016: Disclosed details to CERT/CC as VU#617567, VU#974055, and VU#402847
  • Fri, Sep 09, 2016: CVEs assigned by CERT/CC
  • Mon, Oct 17, 2016: Disclosed R7-2016-18 to TrackR as issue #295585.
  • Tue, Oct 25, 2016: Public Disclosure.
todb

Mirai FAQ: When IoT Attacks

Posted by todb Employee Oct 24, 2016

Update: Following the attack on Dyn back in October, there is some speculation over whether a similar Mirai-style attack could be leveraged to influence the election. This feels like FUD to me; there doesn't seem to be a mechanism to knock out one critical service to kick over enough state and county election websites, Dyn-style, to make such an attack practical. It could potentially be feasible if it turns out that a lot of city, county, and state websites are sharing one unique upstream resource, but without knowledge of that being the case, worries about a surgical DDoS against the election seems more like hyperbolic speculation than anything else.

 

Unless you've been blessed with some long DNS TTLs, you probably noticed that some name-brand chunks of the Internet seemed to go missing on Friday, October 21, including Twitter, GitHub, and Pandora. Over the weekend, it became clear that this was another (yes, another) IoT-based denial-of-service attack, where many thousands of devices with direct access to the internet participated in a wide-scale attack on DynDNS, unbeknownst to their legitimate owners, as part of a botnet called "Mirai."

 

What is Mirai?

Mirai is a botnet -- a malicious software application that is designed to gain unauthorized access to Linux-powered devices and conscript them into a distributed infrastructure of clients. Once enlisted, these machines have the capability to perform a variety of denial-of-service attacks against a target dictated by the attacker. In the Friday attacks, the target was Dynamic Network Services' managed DNS service (heretofore referred to as simply "Dyn").

 

How does Mirai work?

In order to gain access to IoT devices (and really, any Linux computer running telnet), Mirai does not exploit any software vulnerabilities. Instead, it simply tries to guess telnet login credentials for computers accessible via telnet from the internet. Some of these username and password combinations are pretty bad choices for anything hanging out on the internet, like "admin / admin" and "root / root," and some are associated with specific video surveillance systems, like "root / juantec" and "root / klv123." The complete list of credentials is published at GitHub, as part of the Mirai source code.

 

Once compromised, software is installed on that device that can kick off a variety of attacks as described in the source code, such as UDP or ACK flooding, DNS water torture, HTTP request flooding, and other volume-based attacks.

 

In the most recent attack, Dyn's services were knocked offline. Since Dyn provided DNS services exclusively for some major services, that meant that we could no longer figure out "where" on the Internet these services lived.

 

How big is Mirai?

Given the vagaries of internet-wide scanning, it's hard to say how many devices were involved in the Mirai botnet, but the order of magnitude looks to be in the hundreds of thousands range. For a sense of scale, we can look at the recent scans from the National Exposure Index, where we found 15 million apparent telnet servers. We also peeked at a recent Sonar scan of HTTPS certificates, where we found about 315,000 web servers providing a certificate associated with Dahua Technologies, one of the vendors of video surveillance systems that was targeted in the attack. Not all of these telnet servers or video systems are going to be vulnerable, and there are other vendors associated with the attack, but this "hundreds of thousands" figure seems about right.

 

With all these compromised and compromisable devices, Mirai is capable of sustaining hundreds of gigabytes per second of traffic against a chosen target.

 

What's Being Done to Fix This?

For this immediate issue, it looks like the heroic engineers at Dyn have been busy reconfiguring their routing in order to be able to weather further attacks. At the same time, their downstream customers are implementing more robust fall-back strategies with other DNS providers. This is not a vote of no confidence against Dyn, of course; disasters and outages happen, and it's only prudent for name-brand services to have fall-backs like this in place.

 

The fundamental problem of having many, many thousands of insecure devices on the internet remains an issue, though. BCP38 describes techniques for filtering traffic at the edge of an Internet Service Provider's network, which helps defend against DoS attack schemes that generate packets with forged source addresses, but this isn't particularly helpful against the threat demonstrated by Mirai.

 

What Can I Do?

First and foremost, you should not be exposing your telnet ports to the internet. Period. Full stop. End of story.

 

It doesn't matter how much you think you need unfettered access to telnet over the internet, you need to stop it. Now. There are much better alternative protocols, such as SSH for shell access, and HTTPS for GUI-based control, both of which offer modern security features like encryption and mutual authentication. Don't merely change your telnet access credentials; stop using them, and make it impossible for others to control your network bandwidth via telnet.

 

If you rely on a cloud service -- and who doesn't, these days -- then you should find out what their redundancy plans are in the event of not only an attack on their infrastructure, but an attack on their upstream providers. Reputable providers are quite forthcoming with sharing this information with their customers, and usually publish real-time status pages, like this one.

 

The Post-Mirai Reality

Unfortunately, the cost associated with exposing insecure devices is not just borne by the operators of these devices. While it may be creepy to know that anonymous, internet-based attackers can access your home or office camera feeds, the attacker in this case was not interested in those video streams at all. Instead, the attacker only cared about the processing power and network bandwidth of the vulnerable device.

 

Solving for externalities like this is extremely difficult, but given our track record, we know that technology professionals are pretty gifted at coming up with novel solutions to seemingly intractable problems. I'm confident we can come up with a solution that protects IoT devices, protects the rest of the network from those IoT devices, and still manages to preserve the open and distributed nature of the internet.

October is National Cyber Security Awareness month and Rapid7 is taking this time to celebrate security research. This year, NCSAM coincides with new legal protections for security research under the DMCA and the 30th anniversary of the CFAA - a problematic law that hinders beneficial security research. Throughout the month, we will be sharing content that enhances understanding of what independent security research is, how it benefits the digital ecosystem, and the challenges that researchers face.

 

This year, NCSAM is also focused on taking steps towards online safety, including how to have more secure accounts. In 2016, just like in most of the last 15 years, we learned new information about recent and not so recent data breaches at large organizations, during which sensitive account information was made public. Essentially, these breaches have unearthed data on what puts accounts at higher risk for a breach. Putting aside the concerns about non-password account information being made public, one of the factors that determines how bad a data breach is for users is the format of leaked passwords.

 

  • Are they plaintext?
    • Plaintext passwords are just the actual password that a user would type.
    • For example, the password "taco" is stored as "taco" and when made public, can be used by an attacker right away.
  • Have they been hashed?
    • Hashed passwords are mathematical one way transformations of the original password, meaning that it is easy to transform the password into a hash, but given a hash, it's very difficult to recover the original password.
    • For example, the password "taco" is stored as "f869ce1c8414a264bb11e14a2c8850ed" when hashed with the MD5 hash algorithm, and the attacker must recover the original password from this hash in order to use it.
  • Have they been salted and hashed?
    • Hashed passwords are good, but there are several tools and methods that can be used to try to reveal the original password.
    • There are even dictionaries that connect hashes back to their original passwords. Submitting "f869ce1c8414a264bb11e14a2c8850ed" to http://md5.gromweb.com/ reveals that the word "taco" was used to generate that hash.
    • Adding a "salt" to a password, means to add extra data to it before it gets hashed.
    • For example, the password "taco" is combined with the word "salsa" before being hashed, and the resulting hash is stored as "6b8dc43f9be3051e994cafdabadc2398".
    • Now, an attacker looking up the hash "6b8dc43f9be3051e994cafdabadc2398" in a dictionary won't find anything, and will be forced to create a new dictionary which ideally is time consuming.
  • Have they been hashed with a well studied unbroken algorithm?
  • Have they been hashed multiple times? Or with a computationally expensive algorithm? Or with a memory expensive algorithm?
    • These and other questions get into the nitty gritty of how passwords can be stored scurely so that they are of little use to an attacker once they are made public.

 

Luckily, there are plenty of resources for security engineers to follow in order to make their sites more secure, and in particular, their storage of passwords more secure even if they are disclosed. Dropbox has an interesting post about how they store passwords, and this talk by Alec Muffet from Facebook, which describes their methods for storing passwords, is really interesting. In fact, there is an entire conference dedicated to passwords and the engineering that goes into keeping them secure. This site tracks published details about password storage polices of various sites, and this presentation provides the motivation for doing so.

 

That's great, but I'm not a security engineer, what do I need to know about passwords?

 

There is an unending list of articles, blog posts, howto guides and comics written about passwords. Passwords are going away. Passwords will eventually go away. Passwords are here to stay. Passwords are insecure. Two factor authentication will save us all. Biometrics will save us all. Whatever your opinion you probably have multiple accounts with multiple websites and ideally you're using multiple passwords. It's a good idea to recognize that whether or not the sites you use are doing a good job of protecting your passwords, you too can take steps to make your password use more secure.

 

If you take nothing else away from this post, remember to setup a password manager (there are many), actually use it to create different passwords for each account you have, routinely look into whether your account information has been leaked recently, and if it has, change the password associated with that account.

 

What's the big deal?

 

If you have an account with an online service, like an email provider, a social network, or an ecommerce site, then it is very likely that you have a password associated with that account. It's also likely that you have more than a few accounts, and having so many accounts you have most likely been tempted to use the same or similar usernames and passwords across accounts.

 

While there are clear benefits (among some privacy / tracking drawbacks) to having a consistent identity across services (ironicjen182@gmail.com, ironicjen182@facebook.com, ironicjen182@totallylegitonlinebusiness.biz), there are clear drawbacks to using the same password across services, mainly that if one of these services is attacked and account information is leaked, your accounts with identical or similar usernames at the other services could be vulnerable to misuse by an attacker.

 

Ok, but who cares? It's just my (hotmail | twitter | ebay | farmersonly) account.

 

You should care, these accounts paint a very detailed picture of who you are and what you do. For instance, you email has a record of emails you have sent and of those sent to you, and from that an attacker can learn a surprising amount about you. With email providers that offer effectively unlimited email storage and provide little incentive for users to erase emails, it's nearly impossible for a user to be sure that nothing useful to an attacker is buried somewhere inside.

 

Furthermore, your email (and social media accounts) are effectively an extension of you. When an attacker has control of your account, emails, tweets, snaps sent from your account are accepted as coming from you, and attackers can take advantage of those assumptions and the trust that you've built up with you contacts.

 

For example, consider the Stranded Traveler Scam in which an attacker sends a message to one or more of your contacts claiming to be in a bad situation somewhere far away, and if they could just wire some money, things would surely work out. There are news reports about these types of scams all the time (2011, 2011, 2012. 2013, 2014, 2015, 2016) Because the email has come from your account and bears your name, your relatives, friends and coworkers are more likely to believe it is actually you writing the message than a scammer. Similar attacks involve sending malware in attachments and requesting wire transfers for family members or executives, or requesting w-2 forms for employees. None of these attacks require that takeover of your account, but are certainly strengthened by it.

 

Really, how often does this happen? Can't I just deal with it when I hear about it on the news?

 

You could do that, and it would be better than not doing anything at all, but breaches that leak account information happen surprisingly frequently and they don't always make the news that you read. Sometimes, we don't learn about them for weeks or years after they happen, meaning that passwords you used a long time ago may have been known to attackers for a while before you were made aware of a breach.

 

Is my password really out there?

 

Sometimes. Maybe. It's hard to say. Often, sites will hash passwords before they are stored. However, different sites use different hash methods which have different security characteristics, and some methods previously believed to be secure are no longer considered so.

 

Shouldn't these sites be more secure?

 

That would be nice, but data security is a difficult and quickly changing field and not every site prioritizes security as highly as you might like.

 

Fine, what should I do?

 

You should to a few things:

  1. Use a password manager
  2. Use a different password for every account you have
    • Now that you have a password manager storing all your passwords, there's no need to reuse passwords
  3. Use complex passwords
    • Most password managers can create long random strings of letters, numbers and symbols for you. Since the password manager stores these passwords and you don't have to remember them, there's no need to use simple or short passwords.
  4. Keep an eye on sites that catalog leaked account information.
    • Have a look from time to time at sites that keep track of leaked accounts to see if your account has been leaked. haveibeenpwned.com is usually kept up to date and is easy to use.

Whether employees realize it or not, they can wreak havoc on internal and external security protocols. Employees' daily activities (both work and personal) on their work devices (computers, smartphone, and tablets) or on their company’s network can inflict damage. Often called “insider threats,” employees’ actions, both unintentional or intentional, are worth paying heed to whenever possible. Gartner’s Avivah Litan reported on this thoroughly in her “Best Practices for Managing Insider Security Threats, 2016 Update,” where it is made clear that businesses aren’t on their own in regards to responding to this growing, often unpredictable and unmitigated challenge.

 

Avivah recommends four strong approaches you should consider when developing an insider threat program, which she reinforces with analysis, data, and additional content. In the hopes of expanding this list and providing even more thoughts, Rapid7’s security experts, inspired by the four outlined approaches in the report, got together to provide some additional approaches. Where applicable we have also provided links to resources, both product and research, that can help your team combat insider threats. After all, we’re in this together!

 

Recommendation #1: “Start insider threat programs with a risk assessment, in order to prioritize efforts. Deploy business processes and technologies that prevent many insider threats in the first place.”

 

Yes, but be wary of risk assessments not tied to your business objectives and limitations. While a risk assessment is a solid starting point, any miscues could do more harm than good. For example, poor risk assessment will actually overload the security team and create paralysis unless it is relevant, actionable, and sustainable. Some risk assessment services use both people and technology to examine your own technologies, people, and processes. But they are not all created equal and it is important to review the way they will measure risk and what tools they might use.

 

It’s important to consider two types of risk assessment: a one-off audit done by a third party (like a penetration test or a cybersecurity maturity assessment), as well as continuous assessment and good security hygiene. One thing we often see are risk assessments using tools from the CVSS-only scoring world of legacy vulnerability management players. In this world you are ultimately left with a list of hundreds of ‘critical’ vulns, which is a list you’ll never get through to even start thinking about insider threats. Even many penetration tests / external risk assessments fall into the trap of providing a list of problems without context and focus on what attackers really care about. It’s important for teams to do this risk assessment, but do it in a way that properly prioritizes this beyond CVSS and takes into account the age of the vulns, exploitability, and more.

 

Our solutions can help:

In case you didn’t know, our solutions, Nexpose and Metasploit, let you go beyond “vulnerability assessment” to exactly what Gartner is suggesting – a RISK assessment. Because Nexpose prioritizes vulnerabilities by the ease with which they’d be used in an attack, our risk scores are a true picture of how susceptible a system is to a breach, whether insider or external. Nexpose vulnerability checks include checks for default passwords, and limiting these vulns make it more difficult for insider threats to access systems they shouldn’t. Metasploit lets you conduct simulated phishing attacks on your employees, and it lets you test their ability to spot not just suspicious links but suspicious requests for information.

 

Recommendation #2: “Combine technical methods with nontechnical controls, such as security awareness training linked to employee monitoring, for the most successful results in your insider threat program.”

 

Don’t dehumanize the employee experience. People are the key for sure here and security awareness training should run the gamut from overall education to phishing exercises. It’s critical for businesses to iterate to employees that although there will be monitoring for security purposes, their privacy can continue to be respected.

 

For a more successful deployment, executive staff and the security team must ensure that employees have transparency and trust into the process. One of the best alerting mechanisms in every organization isn't technology, it's the employees. If users worry about being under the user behavior magnifying glass after they report something, they're likely to stop speaking up when weird stuff happens. A best practice is to have an authority outside of security, such as a risk or privacy officer, explicitly define who has access to the technology, to what information, and ensure that the policy is regularly reviewed and enforced. During security awareness and compliance training, the security team has an opportunity to share the importance of identifying anomalous behavior, since compromised credentials has been a top attack vector behind breaches (Verizon Data Breach Investigations Report) for five years running.

 

Our solutions can help:

New technology, such as User Behavior Analytics, can correlate the millions of actions taken on the network to the users and assets behind them. This can expose risky user behavior, whether it be unintentional negligence or malicious insider threat. When InsightIDR is first deployed in a customer environment, the technology starts to create a baseline of typical user behavior. Many organizations immediately improve their security posture and validate existing controls by identifying non-expiring passwords, shared accounts, and administrators they otherwise did not know about. From there, InsightIDR highlights notable and anomalous behavior that may be indicative of a compromised or rogue employee account.

 

 

Recommendation #3: “(For technical insider threat programs) Start with readily available data, such as directory data and access logs, to achieve quicker results. Increase the types of information ingested over time, recognizing analytics can only be as good as the data they consume.”

 

Yes and YES. This is something we truly believe in, and we think that you can not only get a lot out of the data you already have, but you can do it more easily than ever before. If you want to identify insider threats, you need to first understand what is normal behavior for your users and the first step is to tie the majority of events back to those users. This requires Active Directory, to provide details on who is logged into each device at any given time, and it requires DHCP, to know which IP address is assigned to these devices. The next big step is to obtain endpoint data, such as local event logs and process details, to increase the types of behavior you can see.

 

Ultimately, start with basic data analytics to look for known patterns of malicious behavior and look for solutions that have automated the collection, unification, and correlation of your data. It is also smart to add on top of that folks who have done this before in order to get immediate benefit for any security analytics program.

 

Our solutions can help:

In general, insider threats are a risk to an organization, whether they’re intentional or unintentional. Rapid7 combines both technology, with our InsightIDR solution, and a team of incident responders constantly understand what the highest risk users and assets are in the organization. This evaluation is not just a look at the technological systems, but it’s also a deep understanding of the business. This allows the team to be more targeted in their hunting for threats later and to put policies in place to minimize insider threat risk later on. The time up front makes it easier to mitigate risk through prioritization of what’s most important to the organization. The deep knowledge the team has of attacker behavior and user behavior helps them better identify insider threats.

 

 

Recommendation #4: “Start with basic data analytics to look for known patterns of malicious behavior. Graduate to more advanced analytics like anomaly detection once your organization is able to manage the results.”

 

Analytics reign supreme. This is where the focus of analytics needs to be more automated. Let’s assume you’ve done all the above, and did it right, the last thing you now want to do is learn how to write or even manage analytics. Focus on automating the analysis as much as possible. This isn’t about just having a library of analytics created with an attacker’s mindset, it also needs to be considered in how log search is performed and visualized. It’s no longer acceptable to spend time data splunking around when your goal is to find that insider threat before it hurts you.

 

Our solutions can help:

If you don't have log aggregation in place, this is a great start, as it will save you lots of time and headaches during incident investigations, and is an integral part of meeting today's compliance standards. Most log aggregation tools come with the ability to create custom alerts, which can help solve basic use-cases and provide visibility into the environment. InsightIDR works by creating a User-IP-Asset link from integrating with Active Directory, DHCP, and Endpoint Data, as well as an existing network and security stack. What takes InsightIDR beyond just analyzing logs are Intruder Traps, such as Honey Pots and Honey Credentials, which reliably detect intruders earlier in the attack chain.

 

Ultimately, there’s a lot of methods to consider when developing an insider threat program. But as can be seen above, not all approaches are made equal. It’s imperative to be thoughtful and conscientious about how insider threats are approached and handled.

October is National Cyber Security Awareness month and Rapid7 is taking this time to celebrate security research. This year, NCSAM coincides with new legal protections for security research under the DMCA and the 30th anniversary of the CFAA - a problematic law that hinders beneficial security research. Throughout the month, we will be sharing content that enhances understanding of what independent security research is, how it benefits the digital ecosystem, and the challenges that researchers face.

 

2016 can be characterized as the year that IoT security research took off, both here at Rapid7 and across the security researcher community. While IoT security research was certainly being conducted in years past, it was contentious within our community as "too easy" or simply "stunt hacking." But as the body of research in this space grows along with the prevalence of IoT, it's become obvious that this sort of "easy" hacking is critical to not only the security of these devices in and of themselves, but to the safety of the people nearby these devices.

 

After all, the hallmarks of IoT is both the ability to interact with the real, physical space around the devices, and to communicate with other devices. Security failures, therefore, can both directly affect the humans who are relying on them and open attack vectors against nearby devices and the networks they are connected to.

 

With that in mind, I'd like take a moment to consider the more noteworthy events in IoT Security, and how together, they make the case that this year is when we stopped considering IoT security "junk hacking," and started taking these things seriously.

 

IoT Security in 2016

 

In January, Brian Knopf announced that the "I Am the Cavalry" security research advocacy group will be publishing an open, collaboration-driven cybersecurity rating system for IoT devices, in contrast to Underwriter Labs' proprietary standards. This isn't the first announced strategy to comprehensively rate the security of IoT devices, but it's certainly the most open. Transparency is crucial in security research and testing, since it allows for independent verification, reproducibility, and accountability.

 

In March, researcher Wish Wu of Trend Micro reported a pair of vulnerabilities in a Qualcomm component of the Android operating system which, if exploited, can allow a malicious application to grab root-level permissions. Wu presented these findings and others in May at the Hack in the Box security conference. While these bugs have been patched by Google, these findings remain significant for two reasons. One, Android is rapidly becoming the de facto standard operating system for the Internet of Things -- not just smartphones -- so bugs in Android can have downstream effects in everything from television set-top boxes, to children's toys, to medical devices. Second, and more worrying, many of these devices do not have the capability to get timely security updates or to upgrade their operating systems. Given the lack of moving parts in these machines, they can chug along for years without patches.

 

In May, researcher Earlance Fernandes and others at the University of Michigan demonstrated several vulnerabilities in Samsung's SmartThings platform for home automation, which centered around abusing and subverting applications to gain privileges, including a remote attack to reset a door lock PIN. Design issues of over-privileged applications are certainly not limited to Samsung's software engineering, but is commonplace in IoT infrastructure. Oftentimes, the services and applications that ship on IoT devices aren't designed with privilege constraints in mind. If the service does what it's supposed to do with administrative / root privileges, there isn't a lot of incentive to design it to work in a less permissive model, especially when designers aren't considering the motives or opportunity of a malicious user. In other words, while most traditional computers have pretty solid user privilege models, IoT devices often ignore this fundamental security concept.

 

In September, the Michigan Senate Judiciary Committee passed a bill that forbids some forms of "car hacking," but importantly, includes protections for research activities. These exemptions weren't included in the original text of the bill, but thanks to the efforts of Rapid7's Harley Geiger, we've seen a significant change in the way that legislators in Michigan view automotive cyber security and the value of security research there. While this bill is not yet law, the significance of this shift in thinking can't be understated.

 

Also in September, some of the early fears of widespread IoT-based insecurity manifested in the highly public IoT-powered DDoS attack against journalist Brian Krebs. This attack was made possible, in part, by the massive population of unpatched, unmanaged, and unsecured home routers, a topic explored way back in January by yours truly. Of course, I'm not saying I called it, but... I kinda called it.

 

Some closing pictures

 

Who doesn't love a good Google Trends graph? We can see from the below that interest in the "IoT Security" search term has doubled since the beginning of 2016, and I'd be surprised to see it hit any significant decline in the years to come.

 

iot security google trends graph.png

 

While much of this interest is pretty doomy and/or gloomy, it's healthy to be considering IoT security today, and I'm glad that IoT appears to be getting the respect and serious attention it deserves in the security research community. It's only through the efforts of individual, focused security researchers that we'll able to get a handle on the issues that bedevil the IoT-scape. Otherwise, we're looking at a future as envisioned by Joy of Tech:

Joy of Tech Internet of Ransomeware Things.png

Due to a lack of certificate validation with a configured remote Microsoft Exchange server, Nine leaks associated Microsoft Exchange user credentials, mail envelopes and their attachments, mailbox synchronization information, calendar entries and tasks. This issue presents itself regardless of SSL/TLS trust settings within the Nine server settings panel.

 

October 13, 2016 update: Version 3.1.0 was released by the vendor to address these issues.

 

Credit

 

Discovered by Derek Abdine  of Rapid7, Inc., and disclosed in accordance with Rapid7's disclosure policy.

 

Product Description

 

The Nine mobile application for Android is a Microsoft Exchange client that allows users to synchronize their corporate email, tasks, and calendar entries to Android-based devices (phones, tablets, etc.). At the time of writing, Nine is listed in the Google Play store with 500,000 - 1,000,000 installs.

 

Exploitation

 

An attacker in a privileged position within the same network as the mobile device running Nine can man-in-the-middle (MitM) traffic to the remote Exchange server (such as outlook.office365.com in the case of outlook365 corporate email). Attacks can be trivialized in open wireless environments, or by WiFi stalking unsuspecting Nine users with a rogue wireless access point (WAP herein) to trick the mobile device into connecting to an attacker-controlled network.

 

In one scenario, an attacker may setup a WAP in a backpack broadcasting a well-known SSID, such as "Starbucks," bridged to a 3G/4G mobile data connection. The attacker could funnel HTTPS traffic to mitmproxy which serves self-signed certificates from an otherwise invalid certificate authority (CA). From that point on, the attacker would merely wait for a Nine user to come within range of the rogue WAP. Communication between Nine and the remote Exchange ActiveSync service may happen when the victim opens his or her phone, when an email is received (and push is enabled), or when the phone polls the remote service. All communication packets contain the victim's credentials in a HTTP basic authentication header.

 

In a variant of the above scenario, an attacker may visit the same open WiFi (for example, on an airliner or in a coffee shop, etc.) environment an unsuspecting user is in and poison that user's DNS queries for the Exchange server. The rest of the attack would work as explained above.

 

The image below depicts a decrypted capture of MitM'd traffic by mitmproxy, an open source tool. The highlighted area in red contains base64-encoded account credentials.

 

Rapid7_Disclosure_Nine.jpg.jpg

 

Mitigation

 

As mentioned earlier, users can disable push synchronization in Nine and synchronize manually, only in trusted networks (or over VPN connections to trusted networks).

 

IT administrators can look for MUA strings prepended with "Nine-" in their ActiveSync logs, and determine appropriate next steps for those users who are currently using the NineFolders app to access organization data. Customers of Rapid7's InsightIDR can identify Nine clients by simply searching for "where(/Nine-/i)" in the Log Search page.

 

Disclosure Timeline

This vulnerability is being disclosed in accordance with Rapid7's disclosure policy.

 

  • Tue, Aug 09, 2016: Attempted contact to the vendor.
  • Thu, Aug 25, 2016: Disclosed details to CERT.
  • Fri, Aug 25, 2016: CVE-2016-6533 assigned by CERT.
  • Tue, Oct 11, 2016: Public disclosure.
  • Wed, Oct 12, 2016: Vendor response with notification of fixed version (release timing TBD).
  • Thu, Oct 13, 2016: Vendor released version 3.1.0 to address these issues.

Being great is, well… great, right? But as we all know it doesn’t happen in a vacuum, it’s an equation:

 

Greatness = Individual Excellence + Teamwork + Meaningful Customer Relationships

 

Coincidentally (or not), these items make up three of the five core values we strive towards here at Rapid7 – the other two play a role as well in ‘Disciplined Risk Taking’ and ‘Continuous Learning’, but we all know blog posts need three things, it’s some sort of Internet rule. Now, let’s be honest, public displays of boasting are not what we are about here, but when you witness a tidal wave of public support from your customers on the Gartner Peer Insights portal and, simultaneously, your company comes out on top of the coverage for the SANS Top 20 Security Controls (2016 PDF poster), you have to pause for just a moment to let people know.

 

This is important, especially during National Cybersecurity Awareness month, because it’s all about our customers and employees working together to create killer solutions and services. And in this world where we all want the benefits of being interconnected but understand the risks, the heroes have become the IT and security teams. Equipping these teams is what drives us each day. Below is more info on each of these accolades, and a big thank you to our entire community for giving us this amazing moment.

 

Rapid7 Provides the Most Coverage for the SANS Top 20 Critical Security Controls

Many organizations rely on the SANS Top 20 Critical Security Controls (now a joint venture with SANS and the Center for Internet Security) to help them understand what they can do to minimize risk and harden resiliency. The Critical Security Controls run the gamut from asset identification and management to continuous monitoring and secure configurations. How does it work? Well SANS surveyed industry vendors in March 2016, using the Center for Internet Security (CIS) document “A Measurement Companion to the CIS Critical Security Controls (Version 6)” as the baseline. The “heat map” below has shaded areas totaling the number of measurements a vendor covers divided by the total number of measurements listed for that Critical Control. As you see below, Rapid7 leads the way.

 

SANS top 20 critical controls vendor rankings

This is a representation of our full portfolio including pen testing (Metasploit), vulnerability management (Nexpose), application security (AppSpider), and SIEM/UBA/EDR (InsightIDR). If you are already using one of our products in one area, we should show you how our solutions work together to get you even more coverage. Ultimately though, this helps people understand that our solutions provide the quality, usability, and ultimately, the insight that security professionals need to get the job done.

 

Gartner Peer Insight: Security Product Reviews for Rapid7 at the Top

If you haven’t checked out Gartner Peer Insights yet, it’s a resource fed by the user community themselves where they provide in-depth reviews about products they are using, ranging from SIEM and UBA, to vulnerability management, and application security. We are proud of what our customers say about us, and we are always listening for ways to improve their experience and success using our solutions. Below you'll see where Rapid7 stacks up in terms of overall peer rating on Gartner Peer Insight in the SIEM category:

gartner review for SIEM security solutions

Go take a look at what folks are saying, and then do your own searches for the solutions you need!

 

And if you have any questions or need to talk to us about any of our solutions just let us know in the comments or contact us page. Now that we’re done celebrating we’re back at work, with all of you, to keep progressing!

Filter Blog

By date: By tag: