Rapid7 Blog

IoT  

Multiple vulnerabilities in Wink and Insteon smart home systems

Today we are announcing four issues affecting two popular home automation solutions: Wink's Hub 2 and Insteon's Hub. Neither vendor stored sensitive credentials securely on their associated Android apps. In addition, the Wink cloud-based management API does not properly expire and revoke authentication tokens, and…

Today we are announcing four issues affecting two popular home automation solutions: Wink's Hub 2 and Insteon's Hub. Neither vendor stored sensitive credentials securely on their associated Android apps. In addition, the Wink cloud-based management API does not properly expire and revoke authentication tokens, and the Insteon Hub uses an unencrypted radio transmission protocol for potentially sensitive security controls such as garage door locks. As most of these issues have not yet been addressed by the vendors, users should ensure mobile devices enable full disk encryption if possible, and avoid the use of these products for sensitive applications until the vulnerabilities are patched. While the potential impact is high, these vulnerabilities are not exploitable over the internet: access to the user's phone, or close proximity to connected devices in the replay case, is required for exploitation. This post provides additional details on the vulnerabilities and steps users can take to protect themselves. Rapid7 ID CVE Product Vulnerability Status R7-2017-19.1 CVE-2017-5249 Wink Android App Insecure Storage of Sensitive Information Patched in v6.3.0.28 R7-2017-19.2 n/a Wink API Insufficient Session Expiration Unpatched; fix planned R7-2017-20.1 CVE-2017-5250 Insteon Hub Insecure Storage of Sensitive Information Unpatched R7-2017-20.2 CVE-2017-5251 Insteon Hub Authentication Bypass by Capture-replay Unpatched Wink: Android app authentication token storage and API authentication token revocation vulnerabilities Two issues related to authentication were discovered in the Wink Android mobile application and related API: CVE-2017-5249, R7-2017-19.1, CWE 922 (Insecure Storage of Sensitive Information): the OAuth token used by the Wink Android application to authorize user access was not stored in an encrypted and secure way. R7-2017-19.2, CWE 613 (Insufficient Session Expiration): when users log out of the Wink Android application, the authentication token used for that session is not revoked, nor does the generation of new tokens revoke older ones. There is no way currently for users to see all valid authentication tokens connected to their account, but there is a method available to revoke all authentications aside from their current one (detailed below). No CVE was assigned to this issue, as remediation would likely be done on Wink's servers. Product Description Wink Hub 2 is a smart home system designed to help consumers manage multiple home IoT products and protocols from various vendors. It is composed of a hub device as well as a mobile application for user interaction. More information can be found on the vendor's product page. Credit These issues were discovered by Deral Heiland, Research Lead at Rapid7, Inc. This advisory was prepared in accordance with Rapid7's disclosure policy. R7-2017-19.1 Details and Exploitation During analysis of the Android mobile application for Wink (Wink application version 6.1.0.19 on Android 5.1 running kernel 3.10.72), it was discovered that the OAuth token is stored unencrypted within the following file: /data/data/com.quirky.android.wink.wink/shared_prefs/user.xml To determine the longevity of this preference file, the Android device was rebooted, after which the unencrypted OAuth token shown in Figure 1 below was still present. It was determined that the token remained until the user logged off manually. Based on the nature of IoT technology, users typically stay logged in, however. Thus the authentication tokens are likely to stay valid indefinitely, unless the user doesn't interact with the application for more than 30 days. Remediation A vendor-supplied patch for the mobile app should be provided to prevent storing potentially sensitive information, such as authentication tokens, in cleartext. While local storage is likely necessary for normal functionality, sensitive information should be stored in an encrypted format that requires authentication to decrypt. In the case of Android, there is a built-in secure storage method that should be used. [Updated Sept 22, 2017] The latest version of the Wink Android application, v6.3.0.28, fixed the authentication storage issue. This was released on Sep 13, 2017. Users should update to this version immediately. Users should also consider enabling full-disk encryption (FDE), and be sure to log out of the Wink application when not in use. Enabling FDE will protect the authentication tokens on the device from being accessed. iPhones enable FDE by default, and most modern Android devices are capable of enabling it. FDE also adds an additional layer of protection by adding a boot password. If FDE is not possible for a particular device, the user should be especially careful not to lose the device, as sensitive data may be recoverable. R7-2017-19.2 Details and Exploitation Further examination of the Wink app's use of OAuth revealed that the normal user logout process does not include OAuth token revocation. When the user logs out from the mobile application, it only sends a delete request for the mobile device tracker in specific (as shown in Figure 2 below). This tracker plays no direct roll in the authentication process. When the user logs back in, they are assigned a new OAuth token. However, testing showed that the previous OAuth token still remained valid. To further validate the security of this, the user's password was changed, at which point revocation of that user's tokens was expected. The system rebooted, but the original OAuth token still remained valid, as shown in Figure 3: This means that if a user loses their mobile device, or if it is stolen, a malicious actor could extract the unencrypted OAuth token from the user.xml file, giving the malicious actor full access to the Wink Hub 2 remotely. Remediation A vendor-supplied patch should be provided to revoke the user's OAuth token after logout from the mobile application. In addition, a mechanism should be added to allow for the revocation of all tokens across all mobile devices with access to the user's Wink Hub 2. This would help prevent unauthorized access to the device and services even if a device is lost or compromised. [Updated Sept 22, 2017] Wink reports that they plan to address this issue in the near future through a server-side change. [Updated Sept 26, 2017] Users are currently able to force a log out of other user sessions. This can only be done by going to change your password, and then selecting the "Log Out Others" option presented in figure 4: This step will invalidate all associated OAuth tokens, except for the one currently in use by the user. This lowers exposure greatly, as it is much less likely for an attacker to have that current token, rather than an older one. We recommend users change their password and log out other sessions associated with their account to avoid exposure. If users are able to view sessions associated with their account in the future, they should review that regularly. R7-2017-19 Disclosure Timeline Wed, Jul 19, 2017: Initial contact with Wink Wed, Jul 20, 2017: Wink acknowledged receipt Fri, Jul 28, 2017: Details disclosed to Wink Mon, Jul 31, 2017: Wink acknowledged Android token issue, plans to fix Mon, Aug 14, 2017: Rapid7 reserved CVE-2017-5249 for R7-2017-19.1 Mon, Aug 14, 2017: Disclosed to CERT/CC Fri, Sep 22, 2017: Public blog disclosure; presented at DerbyCon 7.0 Fri, Sep 22, 2017: Wink confirmed that R7-2017-19.1 was fixed on Sep 13, 2017, and that they intend to fix R7-2017-19.2 in the near future. Insteon Hub: Unencrypted credential storage and radio replay vulnerabilities Two issues related to authentication and radio transmission security were discovered in the Insteon Hub: CVE-2017-5250, R7-2017-20.1, CWE 922 (Insecure Storage of Sensitive Information): the OAuth token used by the Insteon Android application to authorize user access is not stored in an encrypted and secure way. CVE-2017-5251, R7-2017-20.2, CWE 294 (Authentication Bypass by Capture-replay): the radio transmissions used for communication between the Hub and connected devices are not encrypted, and do not provide sufficient protections to guard against capture-replay attacks. These issues can be used to compromise and control an Insteon Hub environment. Product Description The Insteon Hub is a smart home system designed to help consumers connect various home IoT products and manage home automation. It is composed of a hub device as well as a mobile application for user interaction. More information can be found on the vendor's product page. Credit These issues were discovered by Deral Heiland, Research Lead at Rapid7, Inc. This advisory was prepared in accordance with Rapid7's disclosure policy. R7-2017-20.1 Details and Exploitation Analysis of the Android mobile application for Insteon Hub (Insteon application version 1.9.7) revealed that the account and password for both Insteon services and the Hub hardware was stored unencrypted within the following file: /data/data/com.insteon.insteon3/shared_prefs/com.insteon.insteon3_preferences.xml To determine the longevity of this file, the Android device was rebooted, after which the plaintext username and password shown in Figures 1 and 2 below was still present. It was determined that the account credentials remained in the file until the user logged off manually. Based on the nature of IoT technology, users typically stay logged in. Remediation A vendor-supplied patch should be made to the mobile app to prevent storing sensitive information, such as user credentials, unencrypted. While local storage is likely necessary for normal functionality, sensitive information should be stored in an encrypted format that requires authentication to decrypt. In the case of Android, there is a built-in secure storage method that should be used. Absent a vendor-supplied patch, users should consider full-disk encryption (FDE), and be sure to log out of the Insteon Hub application when not in use. Enabling FDE will protect the authentication tokens on the device from being accessed. iPhones enable FDE by default, and most modern Android devices are capable of enabling it. FDE also adds an additional layer of protection by adding a boot password. If FDE is not possible for a particular device, the user should be especially careful not to lose the device, as sensitive data may be recoverable. R7-2017-20.2 Details and Exploitation The Insteon Hub uses radio signals to communicate with connected devices, specifically a 915MHz Frequency Shift Keying (FSK) communication protocol. Analysis of this protocol revealed that the transmissions do not appear to be encrypted, nor to contain any security mechanisms to prevent replay attacks. A malicious actor can easily capture and replay the radio signals at any time to manipulate any device being managed via this communication protocol. To test the Insteon Hub's security against replay attacks, an Insteon Garage Door Control Kit (Device 43) was configured via an Insteon Hub (2245-222). Using software-defined radio (SDR), the 915MHz radio signal used to open and close the door via the Garage Door Control device was captured. Once captured, the signal was filtered to remove background noise and then replayed to successfully actuate the Insteon Garage Door Control device. This confirmed that the Insteon RF protocol is vulnerable to replay attacks, and is shown in Figure 3 below: Remediation A vendor-supplied patch should be provided to configure the 915MHz signal to encrypt the data being communicated, or to apply a rotating certificate to prevent replay of captured RF signals. Absent a vendor-supplied patch, users should avoid using the Insteon's radio-control features with security-related and access control devices if they are concerned about potential radio eavesdroppers. R7-2017-20 Disclosure Timeline Wed, Jul 19, 2017: Initial contact with Insteon Wed, Jul 20, 2017: Insteon acknowledged receipt Fri, Jul 28, 2017: Details disclosed to Insteon Mon, Jul 31, 2017: Insteon acknowledged receipt, intent to review Mon, Aug 14, 2017: Rapid7 reserved CVE-2017-5250 for .1 and CVE-2017-5251 for .2 Mon, Aug 14, 2017: Disclosed to CERT/CC Fri, Sep 22, 2017: Public blog disclosure; presented at DerbyCon 7.0

Building a Car Hacking Development Workbench: Part 1

Introduction There is a vast body of knowledge hiding inside your car. Whether you are an auto enthusiast, developer, hobbyist, security researcher, or just curious about vehicles, building a development bench can be an exciting project to facilitate understanding and experimentation without risking possible damage…

Introduction There is a vast body of knowledge hiding inside your car. Whether you are an auto enthusiast, developer, hobbyist, security researcher, or just curious about vehicles, building a development bench can be an exciting project to facilitate understanding and experimentation without risking possible damage to your vehicle. This is a perfect project for people of a wide range of ages and skill levels. Even if you have never worked on a car before, or you do not feel like your Electronics-Fu skills are strong, there are dozens of blogs, training videos, and reference guides on the internet that can supplement the information in this guide. This the first part of a three-part series. Part one covers how to build the physical bench. Part two will discuss how to read wiring diagrams and serve as the primer to part three, where we will re-engineer common circuitry. A car hacking workbench consists of the critical electronics that control the vehicle, plus bits and pieces of the electrical harness. This is like a neurosurgeon operating on a heart, brain, and spinal cord outside of the human body, except more accessible to the squeamish. Within this guide, we will explore: Finding a suitable vehicle Extracting the critical components Building and powering a workbench Re-engineering circuits and sensors Experimenting with your bench You can adapt the following steps to any vehicle. We chose a 2006 Dodge Stratus, 2.7L, four-door sedan. This vehicle has a Controller Area Network (CAN) Bus interface accessible through the On-board Diagnostics (OBD-II) port. By reassembling the electrical components, we can connect to the vehicle's “brain” through the OBD-II port, and experiment with traffic on the CAN Bus. Note: Some vehicle manufacturers do not share standards between production lines, or even between builds of the same make or model that are a year apart. Find information, such as wiring diagrams and parts, that are specific to your vehicle. For example, If you are working with a heavier class of vehicle, it may interface with the CAN Bus through a J1939 diagnostics port instead of an OBD-II connector. You may also find that newer hybrid vehicles have different power voltages that you need to be aware of while constructing your bench. Tools This project is going to take more than just a simple screwdriver and a pair of clippers. This is not a complete list, but here are some tools that you may want to have on hand: Phillips and flathead screwdrivers in assorted sizes Loppers and/or wire cutters Basic set of standard and metric socket wrenches, plus extension bits Wire strippers Safety equipment (gloves, goggles, light-weight face mask) Voltmeter (a cheap basic model is fine) Multimeter Flashlight Important Note: When working in an old and dirty car or environment (such as a vehicle in a junkyard), WEAR A DUST MASK! Removing an electrical harness can expose you to heavy amounts of dust and bacteria. When the electrical harness is out of the car, wipe down all the components and cables with a small amount of a mild soap and water to reduce the risk of illness. Time Requirements Anyone with a moderate amount of mechanical or electrical knowledge could complete this project over a weekend (16-20 hours). Those with more limited knowledge of these two key areas may need two weekends: One to remove the physical components and a second to reassemble and test. Part Requirements No two vehicles are identical; however, all vehicles possess some commonalities. Your build may not require every component mentioned in this guide, but you should be at least familiar with the following terms: Power Distribution Center (PDC) – Channels power from the battery into the rest of the vehicle. Junction Box (also known as a fuse panel) – Fuses protect the wiring system. If a component faults and causes a power surge, the fuse will sacrifice itself to protect the wires in your vehicle from melting and causing severe damage. Powertrain Control Module (PCM) – Controls input and output to over a hundred various sensors placed on the engine and throughout the vehicle, then injects data into the CAN Bus, the vehicle information network. Generally, the PCM is a combination of the Engine Control Unit (ECU) and Transmission Control Unit (TCU). This is important to know, as wiring diagrams can introduce confusion by using PCM, ECU, and TCU interchangeably. Instrument Cluster (IC) – Located in the dash, this device is monitored by the driver and contains indicator levels, speedometer, RPM gauge, etc. Immobilizer (sometimes referred to as the skim module) – Connected to the ignition switch in the steering column, the immobilizer authorizes the key in use while starting the car. If the immobilizer is missing, unpowered, or the wrong key is in use, then the car will not start. Body Control Module (BCM) – Controls the functions associated with various circuits of the vehicle's accessories and communicates via the CAN Bus. May share a housing with in junction box. Ignition Switch & Key – The keys, tumbler, and power feed that start the vehicle. In order to source a vehicle to use for this project, we recommend that you call junkyards in your area and ask if they have any wrecked vehicles that still have all their components, electrical harness, and keys. Yes, it is that simple. Pro Tip: make friends with the working professionals at the junk yards. I am not saying have them over for dinner or invite them to your weekly poker game, but explain your project and what you are looking for. Vehicles regularly come into junkyards following an accident. So, let the junkyard know what you're looking for in a vehicle. If they don't have what you're looking for, they may call you when something arrives. As for the type of vehicle that you are looking for… that is completely up to you. If you just want a workbench to train on, then any vehicle newer than 2005 will do. Just remember that larger-class vehicles, such as class 3 or 6 , may use a J1939 connector instead of an OBD-II. Step 2 – Removing the Electrical Harness First, and most important: DO NOT CUT ANYTHING! At least not yet, anyway. Before you grab the clippers and go to town hacking into wires, I suggest taking the time to identify and label components, connectors, couplings, wires, and sensors. This will save an incredible amount of time in the long run. If you skip this step now, when everything is out of the vehicle and you're building your workbench later, you get to play a not-so-fun game called, “Where Does This Go?” (You may notice there aren't any pictures supporting this process) I played the game, and it's not fun. I can positively recommend: label everything before you begin! Even if you don't know what every piece under the hood is, marking items with a simple A, B, C pattern now can significantly reduce confusion in the future. Second, take detailed pictures of connectors while they are still connected. If you choose to forego pictures, don't worry. Most connectors are designed to fit in only one socket and in only one direction. Also, for the ease of maintenance, engineers use couplings to attach wiring extensions from sensors and components to the main electrical harness. After completing the labeling and identification process, start to remove the components and wiring harness. There are two practical ways of removing everything that you need. The first way is to simply unbolt and disconnect everything from the front of the engine compartment and unbolt anything in your path until you reach the steering wheel, then remove everything in one long piece. There is a tiny hiccup in this course of action: getting the cables out in one piece may require passing everything through a hole in the vehicle's firewall, which may be smaller than some of the major components. To make this process simpler, disconnect any unit that will not fit before passing the cables through the hole, pull the cables just far enough, and reconnect the unit when the last connector is through the other side. This way you won't forget how something was connected in the first place. The second way is to cut the entire system into two large pieces: one consisting of everything under the hood and a second made up of everything within the vehicle. This method makes it easy to remove all pieces from the vehicle, but will require that you reconnect two pieces with electrical caps or other types of connectors. Now, grab your safety gear and tools, roll up your sleeves, and get to it. Just a heads up, do not wear something that you will want to wear ever again. This can be an extremely dirty job. Mike Rowe would be proud. Furthermore, if you cherish your health, even just the tiniest bit, wear a dust mask. Step 3 – Initial Testing Now that everything is out of the car, make sure that it can receive power. If you cut the harness into pieces, you will need to reattach the cut wires. Reconnect the harness to the instrument cluster, PDC, PCM, BCM, and ignition systems. At this point, you can just lay everything out across a large flat surface. Powering your harness is different from normal power management in a vehicle. Some components can be directly powered from the battery and others wait until the car is running. Plus, when the car is running, everything is powered from the alternator, which is an AC circuit. Instead we will need to use power from an outlet, which is a DC circuit. Luckily, we are not powering an entire car, so we can replicate the battery's DC connection through the Power Distribution Center (PDC). Car batteries generally hold approximately 12.6 volts (or slightly higher) when the vehicle is not running, and will shoot up between 13.7V to 14.7V when running (except for hybrid or electric vehicles, which are completely different ball games, and too much detail for this section). If you have a variable power station, you are good to go, but portability and expense can become an issue. During this project, I used a generic variable DC power adapter cranked up to 12V at 1.2 amps and did not experience any trouble powering the harness and components. You may have to strip the ends of the adapter and either solder the wires (safe option) or like me, clamp down partially stripped wires with alligator clips (not recommended, but okay for initial testing only). Screw terminals are also a safe option, and perhaps the most versatile power management utility if you are unsure how you want your bench to look at the moment. To complete the power connection, find the positive terminal on the PDC, usually indicated with a red plus symbol. Inside the PDC there should be a metal bar that transfers current to the various fuses and relay circuits, and in turn to the rest of the vehicle. Connect the negative (grounding) wire of the adapter to a vehicle ground. If you are unsure if the circuit is complete, check for continuity with a voltmeter by connecting one probe on positive and the other on cables (which we recommended that you label earlier) to ground. Keep changing the probe from one ground point to another until the voltmeter shows continuity and/or holds a tone indicating the completed circuit. Finally, plug in the 12V DC power adapter to the power source (i.e., a wall outlet). Provided the ignition system was hooked up, power is available, the immobilizer is connected, and the keys are in the ignition switch, when you turn the key, the instrument panel should light up. Just about every sensor available through the instrumentation cluster will indicate there's a problem. Take a deep breath, it's normal: obviously, a missing car engine will cause warnings! If you didn't get power, check connectors, couplings, and fuses first. If power still isn't going through the system, grab your handy-dandy multimeter and check all available grounding wires. If you have never used a multimeter to check volts, resistance, amps, or continuity, then I suggest watching this video from Ratchet and Wrenches. Switch your multimeter into continuity mode and touch each prong to the positive and grounding (negative) wires of your adapter. If you do not hear a beep, the circuit is incomplete. Move the negative prong of the multimeter around to various grounding points until you hear a beep. Now move your grounding (negative) wire from your power source to that new location. This should correct the problem. Important Note: When power is available, and the instrument cluster is active, disconnect the DC power adapter from the power source, THEN the PDC and grounding point. Failure to do so could create a spark, shock you, or possibly start a fire in a worst-case scenario. Step 4 – Unwrap & Thin Out the Electrical Harness Now that you have power to the main components, start removing the black electrical tape and fire barrier from all wires in the harness. I recommend wearing gloves, as the stickiness of the tape can tear into your hands after a while. You may be tempted to cut into the tape surrounding the wires, which is fine, but make sure that you do not cut any of the wires during the process. After stripping the tape from the wires, spread the electrical harness and connected components as far apart as possible. Examine the harness for any connectors that are not plugged into any equipment. These connectors are not needed to complete the bench, and can be removed. While clipping connectors, leave a 6-8” pigtail. You do not want to clip the wires at the base of the connectors; depending on how you develop your workbench beyond this guide, you may need one of those connectors in the future. Now that unnecessary connectors are gone, remove excess wires that are not connected to anything. This will help thin out the harness and keep the cable management process clean. Step 5 – Design & Build Your Workbench This step in the process is COMPLETELY YOUR OWN! That said, you may have space requirements. While I was building my workbench, I wanted it to be portable and not too bulky, so I could ship it across the country for peers to learn from and practice on. Pictures available online through web searches show that some people have the system stretched out on a lab table, a large board, or even the garage floor. Others have used Lego and Erector sets to build vertical mounting racks.  My entire bench had to fit inside a large travel case, so there were height, width, and length requirements. No matter how you choose to build your workbench, leave enough physical space between components that both hands can easily work inside without a struggle. Design, build, and then re-power the unit. If the instrument cluster lights up after turning the key to the start position on the ignition switch, you are good to go. Ready for part two? Read it here.

Copyright Office Calls For New Cybersecurity Researcher Protections

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…

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

Legislation to Strengthen IoT Marketplace Transparency

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…

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.

In Fear of IoT Security

I wish I had a dime for every time I have heard someone say “With so many vulnerabilities being reported in the Internet of Things, I just don't trust that technology, so I avoid using any of it." I am left scratching my head…

I wish I had a dime for every time I have heard someone say “With so many vulnerabilities being reported in the Internet of Things, I just don't trust that technology, so I avoid using any of it." I am left scratching my head because these same people seem to have no issues running a Windows operating system. As a researcher focused on the Internet of Things (IoT), I regularly release new vulnerabilities around IoT product ecosystems, which can include hardware, mobile application and cloud web servers, and APIs. The main goal when doing this work is better security. The hope is that the knowledge gained and shared in the course of this research will help manufacturers build better products and help those using IoT make better decisions around the deployment and management of IoT technology. Unfortunately, any vulnerability my peers and I discover during research can be—and often is— made out to be worse than it really is. Now don't get me wrong: I want the work I do to be taken seriously, but we still need to take a complete risk model into consideration when evaluating IoT issues. We can refer back to one of the most succinct risk formulas below: Risk = Probability x Impact Unfortunately, I think we have a tendency to forget about this formula. Every time I discuss my IoT findings with reporters, customers, or the general public, I like to discuss the associated risk, because it varies quite a bit based on “how” and “by whom” the affected IoT technology is being used. A good example of this is the IoT tracking device research I conducted in the past year. If I told you a malicious actor could identify and use a simple low-energy Bluetooth dongle hanging on my keychain “used to find lost keys” to track me anywhere I go via Global Positioning System (GPS) data, what would you say about that?  Our initial response would most likely be that this is horrible and scary, and that response is 100% understandable...but if we think through this using the risk formula, it can easily become both clearer and less dire. First, what is the probability of someone's taking the time and effort to identify such a flaw in a product so they could track us? This leads to several new questions: Would anyone need or want to track me? Am I a very high-profile person, such as a politician or celebrity? Do I have any reason to believe someone is currently interested in stalking or tracking me? If the answer is “no,” then the probability part of the equation quickly drops to nearly zero, or “very unlikely.” Remember basic math: If zero is multiplied by anything, it still equals zero—meaning the risk of this occurring is very low. Now if you do fall within the narrow category of users who may be at higher risk, then you might want to consider the benefit versus risk of using such technology, but for the most part few of us fall into that category. If we talk through the risk of using IoT and apply the basic risk formula, we can better identify the true risk and, armed with that knowledge, focus on properly mitigating and/or reducing it. When thinking about purchasing and deploying IoT at home or in business, there are more questions we can ask that can help us understand other aspects of the risks associated with IoT: Does the product support over-the-air security patching? Having the ability to quickly patch a product when vulnerabilities are found helps to reduce risk and is a key indicator of a more mature security program on the vendor's part. Has the vendor had an independent security review done on their product? Vendors who proactively test their products prior to going to market often deliver a more secure product; this is also another key indicator of a mature security process. And, when we deploy our newly purchased IoT technology, what can we do as users/consumers to reduce risk? We should change default passwords and set complex passwords on all accounts and services (and choose devices/services that support this or even stronger authentication mechanisms). We should strongly consider deploying the solution within an isolated VLAN environment to protect our core business or home networks from any malicious traffic aimed at or coming from an IoT component. I strongly encourage both businesses and consumers to embrace IoT and all the benefits that come with IoT solutions, but to do so with eyes wide open using common-sense risk evaluation, along with deployment and management best practices. This way, you can securely take advantage of all IoT has to offer. Rapid7 can help you test the security of your IoT devices. Learn more about our IoT security services.

IoT Security Testing Methodology

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…

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. 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 urges NIST and NTIA to promote coordinated disclosure processes

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…

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 commentsThe 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" commentsNTIA 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 comingRapid7 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.

R7-2016-28: Multiple Eview EV-07S GPS Tracker Vulnerabilities

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…

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 Description R7 ID CVE Exploit Vector Unauthenticated remote factory reset R7-2016-28.1 CVE-2017-5237 Phone number Remote device identification R7-2016-28.2 None (identification) Phone number range Lack of configuration bounds checks R7-2016-28.3 CVE-2017-5238 Phone number Unauthenticated access to user data R7-2016-28.4 None (server-side issue) Web application Authenticated user access to other users' data R7-2016-28.5 None (server-side issue) Web application user account Sensitive information transmitted in cleartext R7-2016-28.6 CVE-2017-5239 Man-in-the-Middle (MitM) Network Web application data poisoning R7-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. 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. 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: 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=allTrackerswith a the target's userID number to the API.  An example of this shown below in Figure 4: 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. 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: 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). 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.

IoT: Friend or Foe?

Since IoT can serve as an enabler, I prefer to consider it a friend.  However, the rise of recent widespread attacks leveraging botnets of IoT devices has called the trust placed in these devices into question. The massive DDoS attacks have quieted down for now,…

Since IoT can serve as an enabler, I prefer to consider it a friend.  However, the rise of recent widespread attacks leveraging botnets of IoT devices has called the trust placed in these devices into question. The massive DDoS attacks have quieted down for now, but I do not expect the silence to last long. Since many of the devices used in recent attacks may still be online and many new IoT vulnerabilities continue to be identified, I expect what comes next will look similar or the same as past attacks. While we're enjoying a lull before that happens, I figured it's time for another good heart-to-heart discussion about the state of IoT security, including what it means to use IoT wisely and how to keep ourselves and each other safe from harm. First I would like to level set: security vulnerabilities are not unique to IoT. We have been dealing with them for decades and I expect we will have them with us for decades to come. We need to focus on building a healthy understanding and respect for the use and security of IoT technologies. This will help us make better-informed decisions in relationship to its associated risk and deployment. So why do IoT security vulnerabilities appear to have become such a threat lately? I think the answer to that question has four parts. The mass quantity of currently deployed devices. Unfortunately we cannot fix this issue as these devices are already in place and the deployment growth is expected to skyrocket by the end of the decade. Further, I don't think we should want to fix this issue; there's nothing worse then avoiding new technology solely out of fear. Common vulnerabilities. IoT technology has taken a beating (rightly so) over the last year or two because of all of the simple vulnerabilities that are being discovered. Simple issues such as weak encryption, unauthenticated access to services, and default passwords hardcoded in the firmware are commonplace and just a small sample of core, basic issues within these devices. Ease of use. We are living in a plug-and-play generation. As a manufacturer, if your product doesn't just work out of the box, it is unlikely anyone will buy it. So, sadly, we continue to trade security for usability. Exposure through unfettered access. Your plug-and-play IoT technology is exposed to any anonymous entity on the Internet. This is analogous to giving your car keys and a bottle of whiskey to not just your sixteen-year-old, but all possible sixteen-year-olds around the world. Nothing good will come of it. So since we are not going to abandon IoT, this makes the first item unfixable. With that said, expect billions more IoT devices to enter our environment over the next coming years. This makes the remaining three items all that much more critical. So let us next discuss these items and look at possible solutions and next steps moving forward. Common vulnerabilities: We are never going to solve this issue overnight, but it's not like we can just throw up our hands and give up.  In our current IoT world we have dozens of new startups producing new products constantly, as well as dozens of established companies — that have never produced IoT products before — releasing new and “enhanced” products every month. To address these issues it would be great to see these companies implement a security program to facilitate security best practices in the design of their products. For these companies, contacting and partnering with non-profit organizations focused on the public good (like our friends at builditsecure.ly, or I Am The Cavalry) can help them during the design phase. Last but not least, every manufacturer of IoT needs to develop a sound process for handling discovered security issues within their products, including an effective security patching process. Ease of Use: Everyone likes a product that is easy to deploy and operate, but we need to consider security as part of that deployment. Default passwords issues have been haunting us for years and it's time we exorcise that demon. We need to start making setting a password part of the deployment process of all IoT technology including consumer grade solutions. Passwords are not the only issue we have. Another issue often encountered, is the enabling of all function and services of a given product. Whether they are being used or not has also been a common issue. In those cases only services needed for basic operations should be enabled all other features should be enabled as needed. Of course this will require vendors to put more attention into documentation and making their product management console more intuitive.  In the end with a little work we can expect to see "ease-of-use" also become "ease-of-security" in our IoT products. Exposure: In the case of exposure issues, these are often just unplanned deployments without consideration of the impact or risk. Exposing IoT management services directly to the Internet such as Telnet, SSH and even web consoles should be avoided, unless you truly need the whole internet knocking at your IoT door. If remote management is vital to the operations of a product it is best practices to make those services available behind VPN or require two factor or both (depending on the nature of the IoT solution being deployed). Another solution is to leverage basic firewall configurations to restrict administrative access to a specific IP address on the host device. Also we do not want to forget that it is very common for IoT technology to have management and control services that do not conform to the standard port numbers. I have seen telnet on a number of different ports besides TCP port 23.  So it is important to understand the product you're deploying in detail, this will help you to avoid accidental exposures. As added food for thought on deploying IoT technology, consider taking a look at a blog we created several months ago on IoT best practices getting-a-handle-on-the-internet-of-things-in-the-enterprise. So in conclusion, in the debate around the trustworthiness of IoT, we need to turn our attention away from fear, uncertainty, and doubt, and focus on working together to resolve the three issues I have pointed out here. With some diligence and cooperation, I am sure we can better manage the risk associated with the use and deployment of IoT technology. With the growth of IoT expected to skyrocket over the next several years, we pretty much have no choice.

ON-AIR: Broadcasting Insecurity

Note: Rebekah Brown was the astute catalyst for the search for insecure broadcast equipment and the major contributor to this post. Reports have surfaced recently of local radio station broadcasts being hijacked and used to play anti-Donald Trump songs (https://www.rt.com/viral/375935-trump-song-hacked-radio/…

Note: Rebekah Brown was the astute catalyst for the search for insecure broadcast equipment and the major contributor to this post. Reports have surfaced recently of local radio station broadcasts being hijacked and used to play anti-Donald Trump songs (https://www.rt.com/viral/375935-trump-song-hacked-radio/). The devices that were taken over are Barix Exstream systems, though there are several other brands of broadcasters, including Pkyo, that are configured and setup the same way as these devices and would also be vulnerable to this type of hijacking. Devices by these manufacturers work in pairs. In the most basic operating mode, one encodes and transmits a stream over an internal network or over the internet and the other receives it and blasts it to speakers or to a transmitter. Because they work in tandem, if you can gain access to one of these devices, you have information about the other one, including the IP address and port(s) it's listening on. After seeing the story, we were curious about the extent of the exposure. The View from the Control Room We reviewed the January 31, 2017 port 80 scan data set from Rapid7's Project Sonar to try to identify Barix Instreamer/Exstreamer devices and Pyko devices based on some key string markers we identified from a cadre of PDF manuals. We found over a thousand of them listening on port 80 and accessible without authentication. They seem to be somewhat popular on almost every continent and are especially popular here in the United States. Many of these devices have their administration interfaces on something besides port 80, so this is likely just a sample of the scope of the problem. Because they operate in pairs, once you gain access to one device, you can learn about their counterparts directly from the administration screens: It's trivial to reconfigure either the source or destination points to send or receive different streams and it's likely these devices go untouched for months or even years. It's also trivial to create a script to push a new configuration to all the devices very quickly (we estimated five minutes or less). What is truly alarming is not only are these devices set up to be on the internet without any sort of authentication, but that this issue has been brought up several times in the past. The exposure – which in this case, is really a misconfiguration issue and not strictly a software vulnerability – was identified as early as April 2016, and this specific hijacking technique emerged shortly after the inauguration. Coming Out of a Spot The obvious question is that if this issue was identified nearly a year ago, why are there still systems that are susceptible on the internet? The answer is that just because an issue is identified does not automatically mean that the individuals responsible for securing them are aware that they are vulnerable or of what the impact would be. As much as we as an industry talk about information sharing, often we aren't sharing the right information with the right people. Station owners and operators do not always have a technical or security background, and may not read the security news or blogs. Even when the main stream media published information on the impacted model and version, system operators may not know that they are using that particular model for their broadcast, or they may simply miss the brief media exposure. We cannot and should not assume that people are aware of the issues that are discovered, and therefore we are making a greater effort to inform U.S. station owners by reaching out to them directly in coordination with the National Coordinating Center for Communications (COMM-ISAC) and the National Association of Broadcasters (NAB). We've offered not only to inform these operators that they are vulnerable, but also to help them understand the technical measures that are required to secure their systems, down to walking through how to set a password. What is intuitive to some is not always intuitive to others. Cross Fade Out While hijacking a station to play offensive music is certainly not good, the situation could have been — and still can be — much more serious. There are significant political tensions in the U.S. right now, and a coordinated attack against the nearly 300 devices we identified in this country could cause targeted chaos and panic. Considering how easy it is to access and take control of these devices, a coordinated hijacking of these broadcast streams is not such a far-fetched scenario, so it is imperative to secure these systems to reduce the potential impact of future attacks. You can reach out to research@rapid7.com for more information about the methodology we used to identify and validate the status of these devices.

Exiting the Matrix: Introducing Metasploit's Hardware Bridge

Follow the white rabbit... Metasploit is an amazing tool. You can use it to maneuver through vast networks, pivoting through servers and even embedded OSes.  Having a single interface for your team and yourself to control a web of servers and networks is extremely powerful.…

Follow the white rabbit... Metasploit is an amazing tool. You can use it to maneuver through vast networks, pivoting through servers and even embedded OSes.  Having a single interface for your team and yourself to control a web of servers and networks is extremely powerful.  But sometimes you want to do more than control the virtual world. You want to control the physical world. You need to exit the Matrix. We recently announced a new addition to Metasploit to help you do exactly that: the Hardware Bridge API. The Hardware Bridge API extends Metasploit's capabilities into the physical world of hardware devices. Much in the same way that the Metasploit framework helped unify tools and exploits for networks and software, the Hardware Bridge looks to do the same for all types of hardware. From within Metasploit you can now branch out into a Metasploit compatible hardware device to remotely control and use it for your penetration testing needs. How does it work? There are two ways to connect a physical device to Metasploit: Build support directly into your firmware to make your device Metasploit compatible, or Create a relay service. A relay service is required if your device does not have a way to naturally communicate on Ethernet. Many useful hardware tools such as Software Defined Radio (SDR) devices are controlled solely through a USB port. In order to connect an SDR device like this to Metaslpoit then the machine that SDR is connected to would run a relay service. This uses a REST API, the details of which can be found here: Metasploit Hardware Bridge API. Why REST? There are trade-offs with any solution. Embedded systems typically don't support REST because that would require they run some types of mini-web server. Newer embedded systems, especially IoT devices, have no problem running web servers locally but if you have hardware that doesn't have WiFi or Ethernet capabilities we make it easy to create relays for your device. We will provide several examples in the Metasploit tools section demonstrating how to leverage the Metasploit framework to handle all of your http/web needs so you can focus on serial, usb, or whatever communication channel your device uses. We also plan on providing libraries for common microcontrollers and embedded systems to quickly allow your device to support Metasploit. So what can the Hardware Bridge do? Technically, anything. The API provides some core functionality that you should support, although most of commands are optional. These core features mainly watch power, and get versioning information and the devices capabilities. There are certain "specialties" the device can support that will trigger extra capabilities on the Metasploit end. At launch, this will include the Automotive extension. Getting out of your dreams, getting into your car If your device supports CAN, Metasploit will automatically provide several interactive vehicle-related commands. This will also mark your Hardware Bridge (HWBridge) session as an Automotive session that can be viewed in your session list or via modules that are designed to work only on automotive systems. This allows exploit developers to focus on writing automotive tools without having to worry about the attached hardware. It also provides internal Metasploit APIs to make common automotive calls easier, such as getting the vehicle speed or requesting a security access token from the Engine Control Unit (ECU). Hardware devices can teach Metasploit new tricks! You don't have to wait for Metasploit updates or specific support for your new device. Hardware devices can expose any functionality they have to the Metasploit Framework. This is typically something that is unique to your hardware device. It could be as simple as exposing the LEDs, or as complicated as a series of commands that run on MIL-STD-1553 bus systems. When functionality is taught via the API to Metasploit, they show up as interactive commands in the HWBridge session. This allows for support of specific hardware support without forcing the developer to the strict rules of an API, and these commands can also be used by post exploitation modules. How can I use it? If you have read this far I can assume you are ready to take the red pill. This first release comes with support for SocketCAN. If you have a Linux system and a CAN bus sniffer that support SocketCAN you can get started without anything else. The local_hwbridge module is provided as an example of a simple relay system. You can run the relay locally or on a remote machine. msf > use auxiliary/server/local_hwbridge msf auxiliary(local_hwbridge) > run [*] Auxiliary module execution completed [*] Using URL: http://0.0.0.0:8080/6xOv7GqFs3YTeIE [*] Local IP: http://10.1.10.21:8080/6xOv7GqFs3YTeIE [*] Server started. msf auxiliary(local_hwbridge) > The local_hwbridge defaults will automatically detect any SocketCAN interfaces you have and should just work without having to type in any options. A relay service does not have to run within Metasploit but can be its own service, or if the REST API is supported by the hardware itself, you can skip this step. Next you need to connect to a relay or a supported piece of hardware to establish a HWBridge session. msf > use auxiliary/client/hwbridge/connect msf auxiliary(connect) > set rhost 10.1.10.21 rhost => 10.1.10.21 msf auxiliary(connect) > set targeturi 6xOv7GqFs3YTeIE targeturi => 6xOv7GqFs3YTeIE msf auxiliary(connect) > run [*] Attempting to connect to 10.1.10.21... [*] Hardware bridge interface session 1 opened (127.0.0.1 -> 127.0.0.1) at 2017-01-17 11:02:34 -0800 [+] HWBridge session established [*] HW Specialty: {"automotive"=>true} Capabilities: {"can"=>true, "custom_methods"=>true} [!] NOTICE: You are about to leave the matrix. All actions performed on this hardware bridge [!] could have real world consequences. Use this module in a controlled testing [!] environment and with equipment you are authorized to perform testing on. [*] Auxiliary module execution completed msf auxiliary(connect) > sessions Active sessions =============== Id Type Information Connection -- ---- ----------- ---------- 1 hwbridge cmd/hardware automotive 127.0.0.1 -> 127.0.0.1 (10.1.10.21) Once connected, a HWBridge session will be established. If you are familiar with using meterpreter you will feel very at home using a hwbridge. Jumping on a session you can see a list of commands by typing help or run a post module such as the supplied getvinfo (Get Vehicle Info) module. msf auxiliary(connect) > sess 1 [*] Starting interaction with 1... hwbridge > supported_buses Available buses can0, can1, can2 hwbridge > run post/hardware/automotive/getvinfo CANBUS=can2 [*] Available PIDS for pulling realtime data: 46 pids [*] [1, 3, 4, 5, 6, 7, 8, 9, 11, 12, 13, 14, 15, 16, 17, 19, 20, 21, 24, 25, 28, 31, 32, 32, 33, 44, 45, 46, 47, 48, 49, 50, 51, 60, 61, 64, 65, 66, 67, 68, 69, 70, 71, 73, 74, 76] [*] MIL (Engine Light) : OFF [*] Number of DTCs: 0 [*] Engine Temp: 48 °C / 118 °F [*] RPMS: 0 [*] Speed: 0 km/h / 0.0 mph [*] Supported OBD Standards: OBD and OBD-II [*] Mode $09 Vehicle Info Supported PIDS: [2, 4, 6, 8] [*] VIN: 1G1ZT53826F109149 [*] Calibration ID: UDS ERR: {"RCRRP"=>"Request Correctly Received, but Response is Pending"} [*] PID 6 Response: ["00", "00", "C4", "E9", "00", "00", "17", "33", "00", "00", "00", "00"] [*] PID 8 Response: ["00", "00", "00", "00", "00", "00", "00", "00", "00", "00", "00", "00", "00", "00", "00", "00", "00"] Feel free to look at the source to post/hardware/automotive/getvinfo.rb to see how to use Metasploit's Unified Diagnostic Service (UDS) API to make modules like these very simple. There are a lot more automotive modules and other services coming. How can I help? This is the initial release of the HWBridge. We are looking for feedback from both hardware developers and exploit writers. If there are automotive features you would like to see, let us know. If you're a hardware developer who wants to be Metasploit compatible, let us know how we can help you.  Metasploit condensed a slew of independent software exploits and tools into one framework and now we want to do the same for hardware. As you exit the Matrix, please watch your step!

12 Days of HaXmas: Year-End Policy Comment Roundup

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…

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!

12 Days of HaXmas: 2016 IoT Research Recap

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…

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. As we close out the end of the year, I find it important to reflect on the IoT vulnerability research conducted during 2016 and what we learned from it. There were several exciting IoT vulnerability research projects conducted by Rapid7 employees in 2016, which covered everything from lighting automation solutions to medical devices. Through this research, we want to give the "gift" of more information about IoT security to the community. In the spirit of the celebrating the holidays, let's recap and celebrate each of these projects and some of the more interesting findings. Comcast XFINITY Home Security System 2016 opened with a research project on the Comcast XFINITY Home Security System which was published in January 2016. Phil Bosco, a member of the Rapid7's Global Services pen test team, targeted his XFINITY home security systems for evaluation. During testing, Phil discovered that by creating a failure condition in the 2.4 GHz radio frequency band used by the Zigbee communication protocol, the Comcast XFINITY Home Security System would fail open, with the base station failing to recognize or alert on a communications failure with the component sensors. This interesting finding showed us that if communication to the systems sensors is lost, the system would fail to recognize that lost communication. Additionally, this failure also prevented the system from properly alarming when the sensor detected a condition such as a open door or window. This vulnerability allowed anyone capable of interrupting the 2.4 GHz Zigbee communication between sensor and base station to effectively silence the system. Comcast has since fixed this issue. Osram Sylvania Lightify Automated Lighting Since automated lighting has become very popular I decided to examine the OSRAM Sylvania LIGHTIFY automated lighting solution. This research project consisted of looking at both the Home and Pro (enterprise) versions. This project ended up revealing a total of nine issues, four in the Home version and five in the Pro. The Pro version had the most interesting of these results which included identifying issues consisting of persistent Cross Site Scripting (XSS) and Weak default WPA2 pre-shared keys (PSKs). The XSS vulnerabilities we found had two entry points with the most entertaining one being an out of band injection using WiFi Service Set Identifier (SSID) to deliver the XSS attack into the Pro web management interface. A good explanation of this type of attack delivery method is explained in a Whiteboard Wednesday video I recorded. Next, the finding that I would consider the most worrisome is the WPA PSK issue. Default passwords have been a scourge of IoT recently. Although, in this case the default password are different across every Pro device produces, closer examination of the WPA PSK revealed they were easily cracked. So how did this happen? Well, in this case the PSK was only eight characters long, which is considered very short for a PSK, and it only used characters that were hexadecimal lowercase (abcdef0123456789) which makes the number of combinations or key space much easier to brute force  and can allow a malicious actor to capture a authentication handshake and brute force it offline in only a few hours. Bluetooth Low Energy (BLE) Trackers You ever get curious about those little Bluetooth low energy (BLE) tracker dongles you can hang on your key chain that helps you locate your keys if you misplace them? So did I, but my interest went a little further then finding my lost keys. I was interested in how they worked and what, if any, security issues could be associated to their use or misuse. I purchased several different brands and started testing their ecosystem, yes ecosystem, that is all of the services that make an IoT solution function, which often includes the hardware, mobile applications and cloud APIs. One of the most fascinating aspects of these devices is the crowd GPS concept. How does that work? Let's say you attach one of the devices to your bicycle and it gets stolen. Every time that bicycle passes within close proximity to another user of that specific product their cell phone will detect your dongle on the bicycle and send the GPS location to the cloud allowing you to identify its location. Kind of neat and I expect it works well if you have an area with a good saturation of users, but if you live in a rural area there's less chance of that working as well. During this project we identified several interesting vulnerabilities related to the tracking identifiers and GPS tracking. For example, we found that the devices' tracking ID was easy identified and in a couple cases was directly related to the BLE physical address. Combining that with some cloud API vulnerabilities, we were able to track a user using the GPS of their device. Additionally, in couple cases we were able to poison the GPS data for other devices. With weak BLE pairing, we were also able to gain access to a couple of the devices and rename them and set off their location alarms which drained the small batteries for the devices. Animas OneTouch Ping Insulin Pump Rapid7's Jay Radcliffe, a member of the Global Services team and security researcher at Rapid7, found several fascinating vulnerabilities while testing the Animas OneTouch Ping insulin pump. Jay is renowned for his medical device research, which has a personal aspect to it as he is diabetic. In the case of the Animas OneTouch, Jay found and reported three vulnerabilities which include cleartext communication, weak pairing between remote and pump, and replay attack vulnerability. During this research project it was determined that these vulnerabilities could be used to potentially dispense insulin remotely, which could impact the safety and health of the user. Jay worked closely with the manufacturer to help create effective mitigations for these vulnerabilities, which can be used to reduce or eliminate the risk. Throughout the project, there was positive collaboration between Jay, Rapid7 and Johnson & Johnson and patients were notified prior to disclosure. Conclusion: Stepping back and taking a holistic look at all of the vulnerabilities found during these research projects, we can notice a pattern of common issues including: Lack of communication encryption Poor device pairing Confidential data (such as passwords) stored within mobile applications Vulnerability to replay attacks Weak default passwords Cloud API and device management web services vulnerable to common web vulnerabilities These findings are not a surprise and appear to be issues we commonly encounter when examining an IoT product's ecosystem. What is the solution to resolving these issues then? First, IoT manufactures can easily apply some basic testing across these areas to quickly identify and fix vulnerabilities on products prior to going to market. Second, we as end users can change default passwords, such as the standard login password and WiFi WPA PSK, to protect our devices from many forms of compromise. It is also important to note that these IoT research projects are just a few examples of the dedication that Rapid7 and its employees have in regards to securing the world of IoT.  These research projects allow us to continually expand our knowledge around IoT security and vulnerabilities. By working closely with vendors to identify and mitigate issues, we can continue to help those vendors in expanding their working knowledge of security, which will flow into future products. Our work also allows us to share this knowledge with consumers so they can make better choices and mitigate common risks that are often found within IoT products.

IoT Security vs Usability

Recently we all have found ourselves talking about the risk and impact of poorly secured IoT technology and who is responsible. Fact is there is enough blame to go around for everyone, but let's not go there. Let us start focusing on solutions that can…

Recently we all have found ourselves talking about the risk and impact of poorly secured IoT technology and who is responsible. Fact is there is enough blame to go around for everyone, but let's not go there. Let us start focusing on solutions that can help secure IoT technology. Usability has been an issue that has plagued us since the beginning of time. As an example, just going back to my youth and seeing my parents VCR flashing 12:00 all the time. We laugh at that, because it showed us their lack of understanding around how technology works, and of course it was not a real risk to anything other then knowing what time it is and not being able to preset and record shows. Today, the inability to understand or configure our technology is much more of a risk than the flashing 12:00 on our parents' VCR. Such misconfigured IoT devices can lead to various compromises of our information or allow our technology to be used in attacks against others. Currently we often find IoT devices working out of the box with every feature enabled and also using default passwords, and of course this approach has come back to haunt us in a number of cases. I am sure we all agree that the days of every feature being enabled and default passwords out the box needs to change. Although, don't get me wrong, I still think IoT technology should be easy to deploy -- but with security built in. So what should that look like? Let me break it down in a few basic items that I think are paramount to getting to that point. No default passwords enabled. It is easy enough during deployment of a product to have the user set a strong password. In cases where each device has a unique default password, those should also be changed and if not, the user should be warned that the password has not been changed and then forced to acknowledge that with a multi-step process each time they use the products. Check out this new tool built by the Metasploit team at Rapid7 called IoTSeeker which scans your network for IoT devices and let's you know if the default password is being used. Initial installation should only enable needed services for functionality. These extra services should only be configurable after initial setup. A check box list for features during initial setup is not the way to go. It will only lead to user selecting every one of them just to make sure the installation works. I know, because in a past life I have watched coworkers do exact thing during product installations. Good documentation is critical for walking a user through the secure setup. This documentation, beside covering standard setups and which may include an intuitive web wizard, should include guidance on enabling expanded features or specific services that have security implications the user should be made aware of during setup. With the ever-expanding list of capabilities and features associated with IoT its imperative that the end user is given guidance "Good Documentation" to help with selecting and implementing the most secure methods during setup of their device. Automated firmware patching should be the default. If not, the user should be prompted every time they use the product when firmware updates are available. Patching allows us to fix security issues within the products moving forward. We are always going to have problems and having the ability to correct them on the fly is important. This simple list points out items that create a solid foundation from where we can continue building on IoT security and at the same time maintain a solid resemblance of usability; however, I expect it will still take a while before we see these items commonplace within all new IoT -- and I am looking forward to that day. If you are looking for a second opinion on how you should be securing the IoT devices used within your environment, check out our IoT security services.

On the Recent DSL Modem Vulnerabilities

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…

by Tod Beardsley and Bob Rudis What's Going On? Early in November, a vulnerability was disclosed affecting Zyxel DSL modems, which are rebranded and distributed to many DSL broadband customers across Europe. Approximately 19 days later, this vulnerability was leveraged in widespread attacks across the Internet, apparently connected with a new round of Mirai botnet activity. If you are a DSL broadband customer, you can check to see if your external TCP port 7547 is accessible to the Internet by using popular public portscanning services provided by WhatsMyIP, SpeedGuide, or your own favorite public portscanning service. If it is, your ISP should be able to confirm if your modem is vulnerable to this attack. Vulnerability Details On November 7, "Kenzo" disclosed two vulnerabilities affecting the Zyxel D1000 DSL modem on the Reverse Engineering blog, here. This DSL modem is used by residential DSL subscribers in Ireland, and appears to be distributed by the Irish ISP, Eir. It's unknown if Kenzo disclosed these issues to either Zyxel or Eir prior to public disclosure. Two issues were identified, both involving the TR-064 SOAP service on the DSL modem, running on TCP port 7547. The first is a command injection vulnerability in the way the device parses new NTP server configurations, where an attacker can enclose an arbitrary shell command in backticks when setting the NewNTPServer1 parameter. The second is an information leak vulnerability where an attacker can access the GetSecurityKeys command to learn the device's WiFi and administrative password. Kenzo provided a proof-of-concept Metasploit module to exercise these vulnerabilities to expose the administrative web service on the Internet-facing side of the modem and to extract the administrative password to that admin web service. On November 26th, the command injection issue was being actively exploited in the wild, apparently as part of another wave of Mirai-style IoT botnet activity. In particular, DSL modems provided to Deutsche Telekom customers in Germany and Austria, under the brandname "Speedport," appeared to be vulnerable. As a result of this attack, many Telekom subscribers were knocked offline on November 27th, and DT has since updated the Speedport firmware. Today, on November 29th, the Metasploit open source project has started work on converting Kenzo's original, special purpose proof-of-concept exploit to a more generally useful Metasploit module that can be used to test the vulnerability in a safer and more controlled way. That work continues on Pull Request #7626. Exploit Activity Details Rapid7's Heisenberg Cloud started picking up malicious SOAP HTTP POST requests to port 7547 on November 26th. We were able to pick up these requests due to the “spray and pray” nature of the bots searching for vulnerable targets. To-date, we've seen over 63,000 unique source IP addresses associated with these attempts to take over the routers, peaking at over 35,000 unique attempts per day on November 27th. As the map below shows, the bots attempting to take over the routers are geographically dispersed. As the below temporal flow diagram shows, different regions are more prevalent as sources of this activity on different days (the source regions are on the left, the days they were active are on the right). There was little change in the top 10 source countries (by unique node count) over the attack period, but some definitely stood out more than others (like Brazil and the U.K.). We've also seen all malicious payload types, though not all of them appeared on all days as seen in the third chart. Not all payloads were evenly distributed across all countries: What Can You Do to Protect Yourself? The vulnerabilities being exploited in these attack are present in Zyxel DSL modems, which are commonly used in European and South American consumer markets, and may be rebranded by regional ISPs, as they are for Eir and Deutsche Telekom. The vulnerabilities described do not appear to affect the cable modems commonly used in the United States. If you are a DSL customer and concerned that you may be vulnerable, you can use popular portscanning services provided by WhatsMyIP, SpeedGuide, or others to assess if your external TCP port 7547 is accessible from the Internet. If the port times out or is otherwise not reachable, you're in the clear. If it is accessible, you should contact your ISP to see if a) this can be restricted, and b) if you are running a vulnerable device. For ISPs, it is A Bad Idea to expose either TR-069 or TR-064 services to arbitrary sources on the Internet; while ISPs may need access to this port to perform routine configuration maintenance on customer equipment, it should be possible for local and edge firewall rules to restrict access to this port to only IP addresses that originate from the ISP's management network. Meanwhile, penetration testers should follow the progress of converting Kenzo's original proof-of-concept to a fully functional Metasploit module over at Pull Request #7626 on Metasploit's GitHub repository. If you are an open source security software developer, we'd love to have your input there. Update (2016-Nov-30): This blog post originally referred to the vulnerable service as TR-069, but it's since become clear this issue is in a related service, TR-064.

Featured Research

National Exposure Index 2017

The National Exposure Index is an exploration of data derived from Project Sonar, Rapid7's security research project that gains insights into global exposure to common vulnerabilities through internet-wide surveys.

Learn More

Toolkit

Make Your SIEM Project a Success with Rapid7

In this toolkit, get access to Gartner's report “Overcoming Common Causes for SIEM Solution Deployment Failures,” which details why organizations are struggling to unify their data and find answers from it. Also get the Rapid7 companion guide with helpful recommendations on approaching your SIEM needs.

Download Now

Podcast

Security Nation

Security Nation is a podcast dedicated to covering all things infosec – from what's making headlines to practical tips for organizations looking to improve their own security programs. Host Kyle Flaherty has been knee–deep in the security sector for nearly two decades. At Rapid7 he leads a solutions-focused team with the mission of helping security professionals do their jobs.

Listen Now