Rapid7 Blog

Transportation  

R7-2017-02: Hyundai Blue Link Potential Info Disclosure (FIXED)

Summary Due to a reliance on cleartext communications and the use of a hard-coded decryption password, two outdated versions of Hyundai Blue Link application software, 3.9.4 and 3.9.5 potentially expose sensitive information about registered users and their vehicles, including application usernames,…

Summary Due to a reliance on cleartext communications and the use of a hard-coded decryption password, two outdated versions of Hyundai Blue Link application software, 3.9.4 and 3.9.5 potentially expose sensitive information about registered users and their vehicles, including application usernames, passwords, and PINs via a log transmission feature. This feature was introduced in version 3.9.4 on December 8, 2016, and removed by Hyundai on March 6, 2017 with the release of version 3.9.6. Affected versions of Hyundai Blue Link mobile application upload application logs to a static IP address over HTTP on port 8080. The log is encrypted using a symmetrical key, "1986l12Ov09e", which is defined in the Blue Link application (specifically, C1951e.java), and cannot be modified by the user. Once decoded, the logs contain personal information, including the user's username, password, PIN, and historical GPS data about the vehicle's location. This information can be used to remotely locate, unlock and start the associated vehicle. This vulnerability was discovered by Will Hatzer and Arjun Kumar, and this advisory was prepared in accordance with Rapid7's disclosure policy. Product Description The Blue Link app is compatible with 2012 and newer Hyundai vehicles. The functionality includes remote start, location services, unlocking and locking associated automobiles, and other features, documented at the vendor's web site. Credit This vulnerability was discovered by independent researchers William Hatzer and Arjun Kumar. Exploitation for R7-2017-02 The potential data exposure can be exploited one user at a time via passive listening on insecure WiFi, or by standard man-in-the-middle (MitM) attack methods to trick a user into connecting to a WiFi network controlled by an attacker on the same network as the user. If this is achieved, an attacker would then watch for HTTP traffic directed at an HTTP site at 54.xx.yy.113:8080/LogManager/LogServlet, which includes the encrypted log file with a filename that includes the user's email address. It would be difficult to impossible to conduct this attack at scale, since an attacker would typically need to first subvert physically local networks, or gain a privileged position on the network path from the app user to the vendor's service instance. Vendor Statement Hyundai Motor America (HMA) was made aware of a vulnerability in the Hyundai Blue Link mobile application by researchers at Rapid7. Upon learning of this vulnerability, HMA launched an investigation to validate the research and took immediate steps to further secure the application. HMA is not aware of any customers being impacted by this potential vulnerability. The privacy and security of our customers is of the utmost importance to HMA. HMA continuously seeks to improve its mobile application and system security. As a member of the Automotive Information Sharing Analysis Center (Auto-ISAC), HMA values security information sharing and thanks Rapid7 for its report. Remediation On March 6, 2017, the vendor updated the Hyundai Blue Link app to version 3.9.6, which removes the LogManager log transmission feature. In addition, the TCP service at 54.xx.yy.113:8000 has been disabled. The mandatory update to version 3.9.6 is available in both the standard Android and Apple app stores. Disclosure Timeline Tue, Feb 02, 2017: Details disclosed to Rapid7 by the discoverer. Sun, Feb 19, 2017: Details clarified with the discoverer by Rapid7. Tue, Feb 21, 2017: Rapid7 attempted contact with the vendor. Sun, Feb 26, 2017: Vendor updated to v3.9.5, changing LogManager IP and port. Mon, Mar 02, 2017: Vendor provided a case number, Consumer Affairs Case #10023339 Mon, Mar 06, 2017: Vendor responded, details discussed. Mon, Mar 06, 2017: Version 3.9.6 released to the Google Play store. Wed, Mar 08, 2017: Version 3.9.6 released to the Apple App Store. Wed, Mar 08, 2017: Details disclosed to CERT/CC by Rapid7, VU#152264 assigned. Wed, Apr 12, 2017: Details disclosed to ICS-CERT by Rapid7, ICS-VU-805812 assigned. Fri, Apr 21, 2017: Details validated with ICS-CERT and HMA, CVE-2017-6052 and CVE-2017-6054 assigned. Tue, Apr 25, 2017: Public disclosure of R7-2017-02 by Rapid7. Tue, Apr 25, 2017: ICSA-17-115-03 published by ICS-CERT. Fri, Apr 28, 2017: Redacted the now-disabled IP address for the LogManager IP address.

Pen Testing Cars with Metasploit and Particle.io Photon Boards

TL;DR This post details how to use the MSFRelay library for Photon boards to write your own Metasploit compatible firmware. Specifically for an add-on called Carloop. If you have a Carloop and just want it to work with Metasploit without having to write any…

TL;DR This post details how to use the MSFRelay library for Photon boards to write your own Metasploit compatible firmware. Specifically for an add-on called Carloop. If you have a Carloop and just want it to work with Metasploit without having to write any code (or read this) then I've also provided the full code as a library example in the Particle library and can be found here. Photons Ready Particle.io has a $20 hobbyist board designed to make IoT devices. They are positioned kind of like the Arduiono of IoT. Once you plug in the board for the first time you will use a phone application to setup the WiFi. From there it talks to the Particle.io cloud. It does all the initial IoT heavy lifting for you but other than that the board provides no additional functions. It is waiting on you to login to the web-based programmer and push firmware changes over the air (OTA) to the device. NOTE: it is possible to keep all your development local but since the “normal” development workflow uses Particle.io's cloud we will as well. Here is what the board looks like: These devices are very tiny and run the STM32 ARM Cortex M3 microcontrollers. Which is a very capable chipset. Now the idea with the Photon is to attach things to the digital and/or analog pins to make it actually do something useful. So to make our tutorial more interesting we will take advantage of the STM32's builtin CAN-bus support and use the Carloop.io attachment. This will allow us to easily plug into the OBD-II port of our vehicle and will provide a more complicated and interesting tutorial. Note: This tutorial focuses on the Photon (WiFi) device but Particle.io also offers the Electron (Cellular) device that should also work the same. Getting Started We will assume you went through the Particle.io tutorial and got the photon board registered with your WiFi and connected to your network. You should also have setup your Particle.io account during this process. Verify your device is online via the Console link on the Particle.io page. It should look similar to the below image: Obviously your ID and Name will vary. Next go to the IDE link (Note you may have to hit the back button) and click the button “Create a New App”. Go ahead and give it a name and a description. I named mine MSFCarloop. The IDE already creates a setup and loop method that if you programmed Arduinos before you should be familiar with that structure. We will now add the Metasploit Framework relay (MSFRelay) library. Search for MSF-Relay and you should see a library called spark-msf-relay. Once you click on that library you will be prompted to add this library to your project. This will import the library and add an “include” in the beginning of you program. Now we will add a few lines of code. First define a global MSFRelay variable as msf. The you must use msf.begin() in the setup loop and msf.loop() in the main loop. Msf.begin() sets up the webserver and msf.loop() handles the incoming request. You may notice I've also included msf.setup(). This is optional but if you include it, the device will automatically publish the LocalIP it obtained when it connected to the WiFi to your Particle.io console. Once you've added this code go ahead and flash it to your device by pressing the little lightning bolt. Once the device is flashed it should reboot and if you view the Particle.io console log you should see the device come up and the LocalIP posted. Your IP address will be whatever local IP the device received from your network. This is the IP you will plug into as RHOST variable for Metasploit's auxiliary/client/hardware/connect module. At this stage you are up and running and Metasploit compatible! You can connect to the device but you can't do much yet because we didn't actually wire anything up. If you want you can connect, check the uptime and do things like toggle the onboard LED via Metasploit. But since we are doing car hacking we should trudge on and build out the rest of the Carloop firmware. First go ahead and load the carloop library the same way you added the spark-msf-relay. It will add a header. We don't really need it for such a simple project but if you get any of the carloop accessories such as GPS, it will come in handy. You will need to create a carloop global variable like below: In the setup add a carloop.begin() and in the main loop() add carloop.update() Overriding the base methods To enable the automotive extensions in Metasploit you must report that you are an automotive device. You should also report that we have one CAN bus available. To do this we should extend the MSFRelay class to make our own custom class. I've called my class MSFCarloop. You will want to update the msf global and change it from MSFRelay to whatever you named your custom class. You can look at the spark-msf-relay.h for a list of overrides and look at the HWBridge API on the return syntax. To support the Automotive extension functions we will override on_request_uri. The on_request_uri method can be used to handle any request that does not come with the base relay such as specific custom hardware commands or to support additional extensions. We will use it to handle the automotive extensions. To support the automotive extension you need to handle three calls: supported_buses, cansend and isotpsend_and_wait. Responses from the request should be a HttpResponseStatic object that you can return via the client object. Don't worry if you can't read the screenshot. The code in it's entirety is included at the end of this post. A convenience function is used here, parseQuery(uri). This method breaks down the query parameters into a C map or what is often called a Hash in scripting languages. Above has some examples on how to handle optional arguments such as timeout for isotopsend_and_wait. Now you just need to create your cansend and isotpsend_and_wait methods. Feel free to just copy them from the Appendix. In these methods we use a structure called CANMessage. This is provided by Particle. MSFRelay has some other convenience features that are used: asc2nibble(char) and incPacketCount(). The method asc2bibble(char) takes a character representing a hex value and converts it to decimal. If the value passed in isn't hex then a value > 0x0F is returned. This is primarily used to validate user input. The second function incPacketCount() is used to increment the sent packets as well as time stamp when the last packet left. Test it out! Push the firmware to your device if you haven't already. Once it is done updating, fire up Metasploit and connect to it. msf > use auxiliary/client/hwbridge/connect msf auxiliary(connect) > set RHOST 10.1.10.130 RHOST => 10.1.10.130 msf auxiliary(connect) > run [*] Attempting to connect to 10.1.10.130... [*] Hardware bridge interface session 1 opened (127.0.0.1 -> 127.0.0.1) at 2017-01-30 22:23:47 -0800 [ ] HWBridge session established [*] HW Specialty: {"automotive"=>true} Capabilities: {"automotive"=>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.130) Appendix / This #include statement was automatically added by the Particle IDE. #include <carloop.h> // This #include statement was automatically added by the Particle IDE. #include <spark-msf-relay.h> Carloop<CarloopRevision2> carloop; class MSFCarloop : public MSFRelay { public: String get_hw_specialty() { return "{ \"automotive\": true }"; } String get_hw_capabilities() { return "{ \"can\": true }"; } bool on_request_uri(String uri) { if(uri.startsWith("/automotive/supported_buses")) { HttpResponseStatic resp("[ { \"bus_name\": \"can0\" } ]", strlen("[ { \"bus_name\": \"can0\" } ]")); client << resp.status(200); return true; } else if(uri.startsWith("/automotive/can0/cansend")) { std::map <String, String>params = parseQuery(uri); if(params.find("id") == params.end() || params.find("data") == params.end()) { HttpResponseStatic resp(not_supported(), strlen(not_supported())); client << resp.status(404); } else { String msg = cansend(params["id"], params["data"]); HttpResponseStatic resp(msg, strlen(msg)); client << resp.status(200); } return true; } else if(uri.startsWith("/automotive/can0/isotpsend_and_wait")) { std::map<String, String>params = parseQuery(uri); if(params.find("srcid") == params.end() || params.find("dstid") == params.end() || params.find("data") == params.end()) { HttpResponseStatic resp(not_supported(), strlen(not_supported())); client << resp.status(404); } else { int timeout = 2000; int maxpkts = 3; if (params.find("timeout") != params.end()) timeout = params["timeout"].toInt(); if (params.find("maxpkts") != params.end()) maxpkts = params["maxpkts"].toInt(); String msg = isotp_send_and_wait(params["srcid"], params["dstid"], params["data"], timeout, maxpkts); HttpResponseStatic resp(msg, strlen(msg)); client << resp.status(200); } return true; } return false; } String cansend(String id, String data) { bool success; unsigned char tmp; int i; String resp; success = false; CANMessage message; if (strlen(data) > 16 || strlen(data) == 0 || strlen(id) > 7) return String("{ \"status\": \"not supported\" }"); if (strlen(id) < 9) { for(i = 0; i < strlen(id); i++) { if((tmp = asc2nibble(id[i])) > 0x0F) { return String("{ \"status\": \"not supported\" }"); } message.id |= (tmp << (2-i)*4); } } message.len = strlen(data) / 2; for(i=0; i< message.len; i++) { tmp = asc2nibble(data[i * 2]); if(tmp > 0x0F) return String("{ \"success\": false }"); message.data[i] = (tmp << 4); tmp = asc2nibble(data[i * 2 +1]); if(tmp > 0x0F) return String("{ \"success\": false }"); message.data[i] |= tmp; } success = carloop.can().transmit(message); resp ="{ \"success\": "; if(success) { incPacketCount(); resp +="true"; } else { resp += "false"; } resp += " }"; return resp; } String isotp_send_and_wait(String src, String dst, String data, int timeout, int maxpkts) { bool success = false; bool first = false; bool data_first = false; unsigned char tmp; unsigned int i, dst_id, current_pkts; unsigned long current_time; String resp; success = false; CANMessage message, answer; if (strlen(data) > 14 || strlen(data) == 0 || strlen(src) > 7 || strlen(dst) > 7) return String("{ \"status\": \"not supported\" }"); if (strlen(src) < 9) { for(i = 0; i < strlen(src); i++) { if((tmp = asc2nibble(src[i])) > 0x0F) { return String("{ \"status\": \"not supported\", \"reason\": \"srcid is invalid\" }"); } message.id |= (tmp << (2-i)*4); } } tmp = 0; dst_id = 0; if (strlen(dst) < 9) { for(i = 0; i < strlen(dst); i++) { if((tmp = asc2nibble(dst[i])) > 0x0F) { return String("{ \"status\": \"not supported\", \"reason\": \"dstid is invalid\" }"); } dst_id |= (tmp << (2-i)*4); } } message.len = (strlen(data) / 2) + 1; message.data[0] = strlen(data) / 2; for(i=0; i< message.len - 1; i++) { tmp = asc2nibble(data[i * 2]); if(tmp > 0x0F) return String("{ \"success\": false, \"reason\": \"Byte " + String(data[i*2]) + " is invalid (" + String(i * 2)+ ")\" }"); message.data[i+1] = (tmp << 4); tmp = asc2nibble(data[i * 2 +1]); if(tmp > 0x0F) return String("{ \"success\": false, \"reason\": \"Byte " + String(data[i*2]) + " is invalid (" + String(i * 2 + 1) + ")\" }"); message.data[i+1] |= tmp; } carloop.can().clearFilters(); carloop.can().addFilter(dst_id, 0x7FF); success = carloop.can().transmit(message); if(success) { incPacketCount(); resp = "{ \"Packets\": ["; first = true; current_pkts = 0; current_time = millis(); while(current_pkts < maxpkts && millis() - current_time < timeout) { while(carloop.can().receive(answer)) { if (answer.id == dst_id) { if(first) { resp += "{ "; } else { resp +=", {"; } resp += " \"ID\": \""; resp += String::format("%03x", answer.id); resp += "\", "; data_first = true; resp += "\"DATA\": ["; for(i = 0; i < answer.len; i++) { if(data_first) { resp += "\""; } else { resp += ", \""; } resp += String::format("%02x", answer.data[i]); resp += "\""; data_first = false; } resp += " ] }"; first = false; current_pkts++; } } } resp += " ] }"; } else { return String("{ \"success\": false, \"reaons\": \"Couldn't transmit packet, bus busy?\" }"); } return resp; } }; MSFCarloop msf; void setup() { msf.setup(); msf.begin(); carloop.begin(); } void loop() { msf.loop(); carloop.update(); }

Metasploit Framework Valentines Update

Valentines day is just around the corner! What could be a nicer gift for your sweetie than a bundle of new Metasploit Framework updates? The community has been as busy as ever delivering a sweet crop of sexy exploits, bug fixes, and interesting new features.…

Valentines day is just around the corner! What could be a nicer gift for your sweetie than a bundle of new Metasploit Framework updates? The community has been as busy as ever delivering a sweet crop of sexy exploits, bug fixes, and interesting new features. Everyone Deserves a Second Chance Meterpreter Scripts have been deprecated for years in favor of Post Exploitation modules, which are much more flexible and easy to debug. Unfortunately, the Internet still abounds with blogs and other advice still recommending their use, and it is clear the word still hasn't gotten out. In a previous Metasploit release, we attempted an experiment removing all of the scripts that already had Post Exploitation modules. Unfortunately, this caused even more confusion since it looked like Metasploit was broken. Now, Metasploit will kindly suggest that users explore the vast world of Post modules instead. For now, all of the built-in Meterpreter scripts you know and love are back for one last dance, but you should really look at dumping those guys. Remember, there are many more Post modules in the sea! Traverse your Way into my Life With this release, we have a number of directory traversal updates, both offensive and defensive. First off, we have added a module for exfiltrating arbitrary data from a Cisco Firepower management console. The default credentials are also documented, so if you run into one of these in the wild, there is a good chance you can make a special connection. And in the "it's not you, it's me" department, Justin Steven has been busy finding and fixing a number of directory traversal bugs in Metasploit's session handler, that can be exploited if you interact with a rogue Meterpreter session. Of course you should practice "safe sess(ions)", but if you can't, update your Metasploit Framework and get protected. You Stole my Creds, my Phone, my Car, and my Heart If you're looking for credentials to add to your little black book, Metasploit release also adds credential extraction modules for Advantech WebAccess, Metrocontrol Weblog, and Cisco Firepower Management Console. And once you have filled your cred list, you can now manipulate them in a more powerful way thanks to improvements in credential management. Android Meterpreter adds a number of new features sure to make keeping up with your bae even easier (that doesn't sound creepy at all does it!) Android Meterpreter now supports stageless HTTPS, which makes it easier to keep your payloads secure, fast, and reliable. If you have trouble with your Android sessions falling asleep after you connect, keep them going all night (and day) long with the new wakelock command. Metasploit makes its first foray into car hacking with a new hardware bridge session type, along with a number of new modules for administering and exploiting OBD-II / CANbus networks in modern vehicles. But, it's not limited to just these, you can add your own hardware devices by implementing the HWBridge specification. Don't let your car spoil your next date, hack back! There are many more improvements and modules to enjoy as well, and they are all available now. So why not update your console with someone special, and make everyday a very special Metasploit Valentines day. For full details, see the latest detailed Metasploit release notes: https://community.rapid7.com/docs/DOC-3575

Car Hacking on the Cheap

Metasploit's HWBrige comes with an automotive extension. This works out of the box if you happen to have a SocketCAN compatible CAN sniffer hanging around. However, if you don't have one, there is a decent chance you have a cheap sub $10 vehicle dongle in…

Metasploit's HWBrige comes with an automotive extension. This works out of the box if you happen to have a SocketCAN compatible CAN sniffer hanging around. However, if you don't have one, there is a decent chance you have a cheap sub $10 vehicle dongle in a drawer somewhere. If not you can probably pick one up on ebay super cheap. Metasploit supports the ELM327 and STN1100 chipsets that are very popular in these dongles. Metasploit comes with a tool to connect these devices provided your device uses a USB connector or is Bluetooth. Here is a sample of an inexpensive ELM327 Bluetooth dongle: These devices are not very fast and are only meant to query diagnostic services. However, it is possible to transmit raw CAN packets with these devices. These devices are not good for sniffing, but Metasploit can use them for transmission just fine. Both the USB version and the Bluetooth version speak serial. So you will need to get the ruby gem ‘serialport' $ gem install serialport Once that is installed go ahead and plug in your device. If it is a bluetooth device you will need to configure your system to connect to that as well: $ rfcomm connect /dev/rfcomm1 "00:0D:18:AA:AA:AA" Once your device is up and running and you know what Serial port it is connected to (check dmesg if unsure) then you are ready to start. First you must run the elm327_relay.rb program: $ cd tools/hardware $ ruby elm327_relay.rb -h Usage: elm327_relay.rb [options] Specific options: -b, --baud <serial_baud> (Optional) Sets the baud speed for the serial device (Default=115200) -s, --serial <serial_device> (Optional) Sets the serial device (Default=/dev/ttyUSB0) -h, --help Show this message As you can see it takes only two parameters, the serial port and the baud of your device. Specify any changes you need from the defaults then start the relay. $ ruby elm327_relay.rb -s /dev/ttyUSB1 Connected. Relay is up and running... If you see a message that the relay is up and running then you are all set! Currently the relay's port is hard coded to port 8080. So now from your local machine or another machine on your network with Metasploit you can connect to this relay msf > use auxiliary/client/hwbridge/connect msf auxiliary(connect) > run [*] Attempting to connect to 127.0.0.1... [*] Hardware bridge interface session 1 opened (127.0.0.1 -> 127.0.0.1) at 2017-01-31 13:32:40 -0800 [+] HWBridge session established [*] HW Specialty: {"automotive"=>true} Capabilities: {"can"=>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 (127.0.0.1) That's it. You can run all the same post modules like post/hardware/automotive/getvinfo. Currently only the CANbus interface is supported on the ELM327s but additional protocol support maybe added. Also do not expect great speed from one of these devices. If you have a post module that floods the bus, it probably will not work very well using an ELM327 chipset.

Rapid7's Position on the U.S. Executive Order on Immigration

On Friday, January 27th, 2017, the White House issued an Executive Order entitled, “Protecting The Nation from Foreign Terrorist Entry into The United States.”  As has been well-publicized, the Order suspends some immigration from seven Muslim-majority countries — Syria, Yemen, Sudan, Somalia, Iraq, Iran and Libya…

On Friday, January 27th, 2017, the White House issued an Executive Order entitled, “Protecting The Nation from Foreign Terrorist Entry into The United States.”  As has been well-publicized, the Order suspends some immigration from seven Muslim-majority countries — Syria, Yemen, Sudan, Somalia, Iraq, Iran and Libya — for 90 days, halts the refugee program for 120 days, and suspends the admission of Syrian refugees indefinitely. Since being issued on Friday, it has resulted in thousands of people being stranded and detained, away from their homes and families, and facing immense uncertainty over their futures. Below is the response that Rapid7's president and CEO, Corey Thomas, shared with media over the weekend: “As a midsize company with a global customer and employee base, these actions increase fear, uncertainty, and the cost of running a business, without clearly articulated security benefits. I believe that this action not only risks serious harm to innocent lives, it also weakens the position of US companies over time, and thus weakens the US economy. I am supportive of thoughtful security measures that are clearly communicated and well executed; however, these executive actions do not meet that standard. “We want to applaud and thank the Massachusetts senators and representatives that have taken a stand against this action.” We hope for swift and positive resolution for all those adversely affected by this Order.

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!

All the (moving) Things!!

Until recently, I was running a small security testing company called Theia Labs.  Theia was small, just myself and a few other contractors, but we built a solid reputation within the auto industry.  During that time, I even wrote the book the Car…

Until recently, I was running a small security testing company called Theia Labs.  Theia was small, just myself and a few other contractors, but we built a solid reputation within the auto industry.  During that time, I even wrote the book the Car Hacker's Handbook. When Rapid7 approached me about potentially acquiring Theia Labs, I was really excited. Joining Rapid7 allowed me to move my tools and continue working on my research as I had before. However, now I have a larger team to collaborate with and the ability and support to expand my reach!  In the past, I was primarily focused on automotive research and, while I had a few projects in other spaces, I didn't have the time or resources to give those other industries the attention that they need. Now, as part of Rapid7, I am able to tackle all things transportation!One of my favorite things about Rapid7 is that they allow me to focus on solving problems the right way.  Often security companies spread themselves too thin and operate as if, because they do web security, they can handle all sectors of security. While these teams often have great talent, they miss a lot of subtleties  that come from having specialist knowledge within a particular industry.  For instance, many security companies see un-encrypted communication and immediately want to lock it down with AES 256, PKI-based code signing, etc.  While this isn't necessarily bad conceptually, in practice it's not the actual issue, and they tend to not understand that there maybe a very good reason those channels were not encrypted to begin with.  Most people who buy vehicles feel they have the right to work on them or take them to an independent mechanic.  How do you do that if all the devices have been locked down so only the manufacturer has a key?  If you need to send a single bit that says "brake now!" do you really want to hamper the speed of decoding that message with layers of encryption?  What is the core problem you are trying to solve?  These are the kinds of problems that we work on solving.I now have the resources to sit down with engineers at design time and all the way through their design and engineering processes.  We have to make the right decisions about security, usability, and function – and can creatively find ways to mitigate potential issues without causing unnecessary restrictions on your engineers or customers. This helps prevent developers from creating costly issues such as producing millions of PCB boards, with serious security flaws that are only discovered after the fact  Ensuring secure design principles are considered at the outset can reduce the number of late-stage security issues and make solving security problems much easier.  Rapid7 already has a host of solutions for the enterprise and is committed to making organizations more secure.  With new research we can integrate IoT, transportation, manufacturing and all other aspects of your business directly into the security pipeline.Planes, trains, automobiles, ships, satellites, drones ... fun times ahead!Read more about our new services and how you can engage with us here.Craig Smith

Hacking Cars is Sexy

Five years ago, if you wanted to publicly demonstrate a car hack it usually meant you would (at the very least) get a series of cease and desist letters.  Of course this made it very hard for researchers to report problems.  If a security researcher…

Five years ago, if you wanted to publicly demonstrate a car hack it usually meant you would (at the very least) get a series of cease and desist letters.  Of course this made it very hard for researchers to report problems.  If a security researcher found something that they were concerned about and wanted to see it addressed, they would turn to the vendor to try and get it fixed.  Unfortunately, automaker's websites didn't have a place to report security findings.  You could try contacting support or talking to a dealership but that would almost never get to corporate, and when it did, it just meant you were about to be threatened with a lawsuit. What's a researcher to do if they reach out to a vendor and they vendor never gets back to them?  Researchers tend to get concerned that an issue is being ignored, so they often would go to the press or give a talk at a conference -- effectively trying to raise awareness or shame the vendor into taking action.  Of course when that happens, you are bound to get the hate from the auto industry.  This creates a viscous cycle that is hard to break from. To make matters worse, hacking cars is sexy!  It must be, the media loves covering car hacking.  The good thing about this attention is that it gets more researchers interested into looking at automotives through a security lens.  The auto-industry tends to still hate this kind of press but it's mainly because of the tone of many of these articles take.  And honestly, I hate fear mongering articles just as much as they do. In the last two years we have seen many automotive companies participating in security events and even participating in the Car Hacking Village at Defcon.  A few have security specific contact pages and even bug bounty programs.  This has created a great feedback cycle. Let's take a recent security finding by Keen Security Labs.  Keen had done excellent research recently by successfully remotely exploiting a Tesla and gaining low level CAN bus controls.  For those not familiar with CAN bus, it's a bus network that grants low level controls to a car.  What those controls are vary on the vehicle and bus you have control over.  The full details of the attack are not public at the time of this writing, however here is their demonstration video: Car Hacking Research: Remote Attack Tesla Motors by Keen Security Lab - YouTube It appears Keen did some thorough research but what is the most exciting thing about this is what they did with the finding.  They contacted Tesla through Tesla's collaborative disclosure methods.  Tesla assessed the probability of exploitation to the customer base and determined it was relatively low due to the specific conditions necessary to perform the attack.  However, they still pushed out a patch to their customers in under two weeks of being notified of the vulnerability.  Keen worked with Tesla and once the issue was address they released their demo. THIS is the news story.  While the hack is cool and all (and sexy!) the real proof is that a significant finding was received and quickly addressed by the auto industry.  When I first started in automotive security five years ago, I thought this day would never come.  Hopefully the media will soon start to showcase the handling of findings so we can showcase to those industries still catching up that, this is how the system is suppose to work.  All software has bugs, cars are software, the question is: What do you do about it once one is discovered?

Rapid7 Supports Researcher Protections in Michigan Vehicle Hacking Law

Yesterday, the Michigan Senate Judiciary Committee passed a bill – S.B. 0927 – that forbids some forms of vehicle hacking, but includes specific protections for cybersecurity researchers. Rapid7 supports these protections. The bill is not law yet – it has only cleared a Committee…

Yesterday, the Michigan Senate Judiciary Committee passed a bill – S.B. 0927 – that forbids some forms of vehicle hacking, but includes specific protections for cybersecurity researchers. Rapid7 supports these protections. The bill is not law yet – it has only cleared a Committee in the Senate, but it looks poised to keep advancing in the state legislature. Our background and analysis of the bill is below.In summary:The amended bill offers legal protections for independent research and repair of vehicle computers. These protections do not exist in current Michigan state law.The amended bill bans some forms of vehicle hacking that damage property or people, but we believe this was already largely prohibited under current Michigan state law.The bill attempts to make penalties for hacking more proportional, but this may not be effective.BackgroundEarlier this year, Michigan state Senator Mike Kowall introduced S.B. 0927 to prohibit accessing a motor vehicle's electronic system without authorization. The bill would have punished violations with a potential life sentence. As noted by press reports at the time, the bill's broad language made no distinction between malicious actors, researchers, or harmless access. The original bill is available here.After S.B. 0927 was introduced, Rapid7 worked with a coalition of cybersecurity researchers and companies to detail concerns that the bill would chill legitimate research. We argued that motorists are safer as a result of independent research efforts that are not necessarily authorized by vehicle manufacturers. For example, in Jul. 2015, researchers found serious security flaws in Jeep software, prompting a recall of 1.4 million vehicles. Blocking independent research to uncover vehicle software flaws would undermine cybersecurity and put motorists at greater risk.Over a four-month period, Rapid7 worked rather extensively with Sen. Kowall's office and Michigan state executive agencies to minimize the bill's damage to cybersecurity research. We applaud their willingness to consider our concerns and suggestions. The amended bill passed by the Michigan Senate Judiciary Committee, we believe, will help provide researchers with greater legal certainty to independently evaluate and improve vehicle cybersecurity in Michigan.The Researcher ProtectionsFirst, let's examine the bill's protections for researchers – Sec. 5(2)(B); pg. 6, lines 16-21. Explicit protection for cybersecurity researchers does not currently exist in Michigan state law, so we view this provision as a significant step forward.This provision says researchers do not violate the bill's ban on vehicle hacking if the purpose is to test, refine, or improve the vehicle – and not to damage critical infrastructure, other property, or injure other people. The research must also be performed under safe and controlled conditions. A court would need to interpret what qualifies as "safe and controlled" conditions – hacking a moving vehicle on a highway probably would not qualify, but we would argue that working in one's own garage likely sufficiently limits the risks to other people and property.The researcher protections do not depend on authorization from the vehicle manufacturer, dealer, or owner. However, because of the inherent safety risks of vehicles, Rapid7 would support a well-crafted requirement that research beyond passive signals monitoring must obtain authorization from the vehicle owner (as distinct from the manufacturer).The bill offers similar protections for licensed manufacturers, dealers, and mechanics [Sec. 5(2)(A); pg. 6, lines 10-15]. However, both current state law and the bill would not explicitly give vehicle owners (who are not mechanics, or are not conducting research) the right to access their own vehicle computers without manufacturer authorization. However, since Michigan state law does not clearly give owners this ability, the bill is not a step back here. Nonetheless, we would prefer the legislation make clear that it is not a crime for owners to independently access their own vehicle and device software.The Vehicle Hacking BanThe amended bill would explicitly prohibit unauthorized access to motor vehicle electronic systems to alter or use vehicle computers, but only if the purpose was to damage the vehicle, injure persons, or damage other property [Sec. 5(1)(c)-(d); pgs. 5-6, lines 23-8]. That is an important limit that should exclude, for example, passive observation of public vehicle signals or attempts to fix (as opposed to damage) a vehicle.Although the amended bill would introduce a new ban on certain types of vehicle hacking, our take is that this was already illegal under existing Michigan state law. Current Michigan law – at MCL 752.795 – prohibits unauthorized access to "a computer program, computer, computer system, or computer network." The current state definition of "computer" – at MCL 752.792 – is already sweeping enough to encompass vehicle computers and communications systems. Since the law already prohibits unauthorized hacking of vehicle computers, it's difficult to see why this legislation is actually necessary. Although the bill's definition of "motor vehicle electronic system" is too broad [Sec. 2(11); pgs. 3-4, lines 25-3], its redundancy with current state law makes this legislation less of an expansion than if there were no overlap.Penalty ChangesThe amended bill attempts to create some balance to sentencing under Michigan state computer crime law [Sec. 7(2)(A); pg. 8, line 11]. This provision essentially makes harmless violations of Sec. 5 (which includes the general ban on hacking, including vehicles) a misdemeanor, as opposed to a felony. Current state law – at MCL 752.797(2) – makes all Sec. 5 violations felonies, which is potentially harsh for innocuous offenses. We believe that penalties for unauthorized hacking should be proportionate to the crime, so building additional balance in the law is welcome.However, this provision is limited and contradictory. The Sec. 7 provision applies only to those who "did not, and did not intend to," acquire/alter/use a computer or data, and if the violation can be "cured without injury or damage." But to violate Sec. 5, the person must have intentionally accessed a computer to acquire/alter/use a computer or data. So the person did not violate Sec. 5 in the first place if the person did not do those things or did not do them intentionally. It's unclear under what scenario Sec. 7 would kick in and provide a more proportionate sentence – but at least this provision does not appear to cause any harm. We hope this provision can be strengthened and clarified as the bill moves through the Michigan state legislature.ConclusionOn balance, we think the amended bill is a major improvement on the original, though not perfect. The most important improvements we'd like to see are Clarifying the penalty limitation in Sec. 7;  Narrowing the definition of "motor vehicle electrical system" in Sec. 2; andLimiting criminal liability for owners that access software on vehicle computers they own.However, the clear protections for independent researchers are quite helpful, and Rapid7 supports them. To us, the researcher protections further demonstrate that lawmakers are recognizing the benefits of independent research to advance safety, security, and innovation. The attempt at creating proportional sentences is also sorely needed and welcome, if inelegantly executed.The amended bill is at a relatively early stage in the legislative process. It must still pass through the Michigan Senate and House. Nonetheless, it starts off on much more positive footing than it did originally. We intend to track the bill as it moves through the Michigan legislature and hope to see it improve further. In the meantime, we'd welcome feedback from the community.

Rapid7, Bugcrowd, and HackerOne file pro-researcher comments on DMCA Sec. 1201

On Mar. 3rd, Rapid7, Bugcrowd, and HackerOne submitted joint comments to the Copyright Office urging them to provide additional protections for security researchers. The Copyright Office requested public input as part of a study on Section 1201 of the Digital Millennium Copyright Act (DMCA). Our…

On Mar. 3rd, Rapid7, Bugcrowd, and HackerOne submitted joint comments to the Copyright Office urging them to provide additional protections for security researchers. The Copyright Office requested public input as part of a study on Section 1201 of the Digital Millennium Copyright Act (DMCA). Our comments to the Copyright Office focused on reforming Sec. 1201 to enable security research and protect researchers. Our comments are available here. Background Sec. 1201 of the DMCA prohibits circumventing technological protection measures (TPMs) to access copyrighted works, including software, without permission of the owner. That hinders a lot of security research, tinkering, and independent repair. Violations of Sec. 1201 can carry potentially stiff criminal and civil penalties. 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. These temporary exemptions automatically expire at the end of the three-year window, and advocates for them must reapply every time the exemption window opens. Sec. 1201 includes a permanent exception to the prohibition on circumventing TPMs for security testing, but the exception is quite limited – in part because researchers are still required to get prior permission from the software owner, as we describe in more detail below. Because the permanent exemption is limited, many researchers, organizations, and companies (including Rapid7) urged the Copyright Office to use its power to grant a temporary three-year exemption for security testing that would not require researchers to get prior permission. The Copyright office did so in Oct. 2015, granting an exemption to Sec. 1201 for good faith security research that circumvents TPMs without permission. However, this exemption will expire at the end of the the three year exemption window,  after which security researchers will have to start from zero in re-applying for another temporary exemption. The Copyright Office then announced a public study of Sec. 1201 in Dec. 2015. The Copyright Office undertook this public study, as the Office put it, to assess the operation of Sec. 1201, including the permanent exemptions and the 3-year rulemaking process. This study comes at a time that House Judiciary Committee Chairman Goodlatte is reviewing copyright law with an eye towards possible updates, so the Copyright Office's study may help inform that effort. Rapid7 supports the goal of protecting copyrighted works, but hopes to see legal reforms that reduce the overbreadth of copyright law so that it no longer unnecessarily restrains security research on software. Overview of Comments For its study, the Copyright Office asked a series of questions on Sec. 1201 and invited the public to submit answers. Below are some of the questions, and the responses we provided in our comments. "Please provide any insights or observations regarding the role and effectiveness of the prohibition on circumvention of technological measures in section 1201(a)." Our comments to the Copyright Office emphasized that Sec. 1201 adversely affects security research by forbidding researchers from unlocking TPMs to analyze software for vulnerabilities. We argued that good faith researchers do not seek to infringe copyright, but rather to evaluate and test software for flaws that could cause harm to individuals and businesses. The risk of harm resulting from exploitation of software vulnerabilities can be quite serious, as Rapid7 Senior Security Consultant Jay Radcliffe described in 2015 comments to the Copyright Office. Society would benefit – and copyright interests would not be weakened – by raising awareness and urging correction of such software vulnerabilities. "How should section 1201 accommodate interests that are outside of core copyright concerns[?]" Our comments responded that the Copyright Office should consider non-copyright interests only for scaling back restrictions under Sec. 1201 – for example, the Copyright Office should weigh the chilling effect Sec. 1201 has on security research in determining whether to grant an exemption for research to Sec. 1201. However, we argued that the Copyright Office should not consider non-copyright interests in denying an exemption, because copyright law is not the appropriate means of advancing non-copyright interests at the expense of activity that does not infringe copyright, like security research. Should section 1201 be adjusted to provide for presumptive renewal of previously granted exemptions—for example, when there is no meaningful opposition to renewal—or otherwise be modified to streamline the process of continuing an existing exemption? Our comments supported this commonsense concept. Currently, the three-year exemptions expire and must be re-applied for, which is a complex and resource-intensive process. We argued that a presumption of renewal should not hinge on a lack of "meaningful opposition," since the opposition to the 2015 security researcher exemption is unlikely to abate – though that opposition is largely based on concerns wholly distinct from copyright, like vehicular safety. Our comments also suggested that any presumption of renewal of exceptions to Sec. 1201 should be overcome only by a strong standard, such as a material change in circumstances. Please assess whether the existing categories of permanent exemptions are necessary, relevant, and/or sufficient. How do the permanent exemptions affect the current state of reverse engineering, encryption research, and security testing? Our comments said that Sec. 1201(j)'s permanent exemption for security testing was not adequate for several reasons. The security testing exemption requires the testing to be performed for the sole purpose of benefiting the owner or operator of the computer system – meaning research taken for the benefit of software users or the public at large may not qualify. The security testing exemption also requires researchers to obtain authorization of owners or operators of computers prior to circumventing software TPMs – so the owners and operators can dictate the circumstances of any research that takes place, which may chill truly independent research. Finally, the security testing exemption only applies if the research violates no other laws – yet research can implicate many laws with legal uncertainty in different jurisdictions. These and other problems with Sec. 1201's permanent exemptions should give impetus for improvements – such as removing the requirements1) that the researcher must obtain authorization before circumventing TPMs, 2) that the security testing must be performed solely for the benefit of the computer owner, and 3) that the research not violate any other laws. We sincerely appreciate the Copyright Office conducting this public study of Sec. 1201 and providing the opportunity to submit comments. Rapid7 submitted comments with HackerOne and Bugcrowd to demonstrate unity on the importance of reforming Sec. 1201 to enable good faith security research. Although the public comment period for this study is now closed, potential next steps include a second set of comments in response to any of the 60 organizations and individuals that provided input to the Copyright Office's study, as well as potential legislation or other Congressional action on Sec. 1201. For each next step, we will aim to work with our industry colleagues and other stakeholders to propose reforms that can protect both copyright and independent security research.

New DMCA Exemption is a Positive Step for Security Researchers

Today the Library of Congress officially publishes its rule-making for the latest round of exemption requests for the Digital Millennium Copyright Act (DMCA).  The advance notice of its findings revealed some good news for security researchers as the rule-making includes a new exemption to…

Today the Library of Congress officially publishes its rule-making for the latest round of exemption requests for the Digital Millennium Copyright Act (DMCA).  The advance notice of its findings revealed some good news for security researchers as the rule-making includes a new exemption to the DMCA for security research:“(i) Computer programs, where the circumvention is undertaken on a lawfully acquired device or machine on which the computer program operates solely for the purpose of good-faith security research and does not violate any applicable law, including without limitation the Computer Fraud and Abuse Act of 1986, as amended and codified in title 18, United States Code; and provided, however, that, except as to voting machines, such circumvention is initiated no earlier than 12 months after the effective date of this regulation, and the device or machine is one of the following:(A) A device or machine primarily designed for use by individual consumers (including voting machines); (B) A motorized land vehicle; or (C) A medical device designed for whole or partial implantation in patients or a corresponding personal monitoring system, that is not and will not be used by patients or for patient care. (ii) For purposes of this exemption, “good-faith security research” means accessing a computer program solely for purposes of goodfaith testing, investigation and/or correction of a security flaw or vulnerability, where such activity is carried out in a controlled environment designed to avoid any harm to individuals or the public, and where the information derived from the activity is used primarily to promote the security or safety of the class of devices or machines on which the computer program operates, or those who use such devices or machines, and is not used or maintained in a manner that facilitates copyright infringement.”Basically this means that good-faith security research on consumer-centric devices, motor vehicles and implantable medical devices is no longer considered a violation of the DMCA (with caveats detailed below). It's a significant step forward for security research, reflecting a positive shift in the importance placed on research as a means of protecting consumers from harm.A brief history of the DMCAThe DMCA was passed in 1998 and criminalizes efforts to circumvent technical controls that are designed to stop copyright infringement. It also criminalizes the production and dissemination of technologies created for the purpose of circumventing these technical controls. That's an incredibly simplified explanation of what the law does, and this is a good time for me to remind you that I'm not a lawyer.The statute includes a number of exceptions that relate to security research – one for reverse engineering (section 1201 (f)), encryption research (section 1201(g)), and security testing (section 1201(j)); however, these are very limited in what they allow. Acknowledging that technology moves fast, the statute also includes provisions for a new rule-making every three years, during which, requests for new and additional exemptions can be made. These are reviewed through a lengthy process that includes opportunities for support and opposition to the exemptions to be lodged with the Library of Congress. After reviewing these arguments, the Copyright Office makes a recommendation to the Library of Congress, who then issues a rule-making that either approves or rejects the submitted exemptions. Exemptions that are approved will automatically expire at the end of the three year window (as opposed to the exceptions, which are permanent unless subject to a change via legislative reform through Congress).Today's rule-making is the product of the latest round of exemption requests. A number of submissions relating to research were filed – a couple for a broad security research exemption, one for medical devices, one for cars, and even something for tractors.  The Library of Congress effectively rolled these into one exemption, which is why it covers consumer-centric devices, automobiles, and implantable medical devices.What does the new exemption mean for security research?Well firstly, it's an important acknowledgement of two things: 1) that research is critical for consumer protection, and 2) that laws like the DMCA can negatively impact research.This is significant not only in what it allows within the context of the DMCA, but also that it sets a precedent and presents an opportunity for a broader discussion on these two points in the Government arena.In terms of what is specifically allowed now, users are able to circumvent technical protections to conduct research on consumer-centric devices, automobiles, and implantable medical devices (that are not or will not be used for patient care).This is not carte-blanche though, and it's important to understand that.  There are a number of limits and questions raised by the language of the exemption:You are allowed to circumvent technical controls to conduct research, but you are NOT allowed to make, sell, or otherwise disseminate tools for circumventing these controls. So you can only conduct research to the extent that it doesn't require such tools.The exemption won't come into effect for a year. This is so other relevant agencies can update their policies. In his article on Boing Boing, Corey Doctorow points out that “the power to impose waiting times on exemptions at these hearings is not anywhere in the statute, is without precedent, and has no basis in law.” (Interestingly, the Library of Congress is excluding research on voting machines from the year delay.)It remains to be seen what the agencies referenced (Department of Transport, Environmental Protection Agency, and the Food and Drug Administration) will do and how that will impact the way this exemption can be applied. It's probably fair to say the exemption's dissenters will be actively lobbying them to find a way to limit the impact of the exemption.  It falls to those of is in the security research community to try to engage these agencies to ensure they understand why research is important, and to try to address any concerns they may have.The research must apply to consumer-centric devices (or cars, or implantable medical devices). What does that mean and where do you draw the line?  For example, we regularly hear of research findings in SOHO routers or printers.  These are devices designed for use in both home and work environments.  Do they count as “primarily designed for use by individual consumers?” I really hope these kinds of devices are included in this classification as they do represent a great deal of consumer risk. It's also somewhat strange to me that we're not granting business users the same protections we're giving individual consumer users.The exemption does NOT allow for research on devices relating to critical infrastructure or nuclear power. It's understandable that these areas raise considerable concern, but at the same time, do we really want flaws in these systems to be left unmitigated?  Doesn't that create more opportunities for bad actors to attack high value targets, potentially with very serious repercussions?For medical devices, the research cannot be conducted on devices that are being, or will be, used for patient care.  That seems pretty reasonable to me.Also, it's important to remember that, as noted above, the rule-making resets every three years, so this exemption will be in effect for a maximum of two years before we have to reapply and go through the entire process again (because of the year delay the Library of Congress has imposed on the exemption).But it IS a positive step?Yes, despite these qualifiers and limitations, I believe it is a positive step.  This is not just because in-and-of itself it enables more research to be conducted without concern of legal action, but also because it may indicate a bigger shift.Just last week, I wrote a blog about a proposed legislative amendment that was significantly rewritten in response to feedback from the security research community.  The TL;DR of that post is that it seems like a hugely positive step that the amendment's authors were prepared to engage and listen to the research community, and were concerned about avoiding negative consequences that would chill security research.Couple that with this exemption being approved, and I continue to have hope that we're starting to see a shift in the way the Government sector understands and values security research.  I'm also seeing a shift in the way the research community engages the Government, and how're we're participating in discussions that will shape our industry.It's not a silver bullet; given the complexity of the challenges we're addressing, we're not going to solve concerns around the right-to-research overnight. It's going to be a long path, but every step counts.  And today I think we may have taken “one giant leap” for research-kind ~ @infosecjen

Low and Slow: Attackers Easily Hide From Time-Blind Alerts

Many organizations focus their detection strategy almost exclusively on malware, not realizing that attackers don't need it to compromise their networks. When you start to look at the extensive intruder behavior outside of malware, you quickly recognize the massive detection challenges we face today. Not…

Many organizations focus their detection strategy almost exclusively on malware, not realizing that attackers don't need it to compromise their networks. When you start to look at the extensive intruder behavior outside of malware, you quickly recognize the massive detection challenges we face today. Not only do these intruders change their techniques when they become easy to detect, but all too much of the detection available depends on events occurring at a single point in time. This inability to automatically correlate events over time to only trigger intelligent, valuable alerts is one of the most significant limitations we need to overcome and I will explain why we need to leverage more sophisticated rules engines, for lack of a better term, with some basic examples. Most IOCs are designed to indicate "bad only" activity Network compromises are no longer likely to be a single piece of malware with a known signature running amok and installing itself on every system it can reach. Sure, there are always going to be infections in your organization which involve a piece of known malware, but more malicious activities come in the form of unknown software, attackers with interactive tools, and seemingly legitimate access through stolen credentials. The IOCs most organizations use to detect these activities are dependent on guaranteed negative attributes seen simultaneously, such as attempting to send unencrypted data on a non-standard port to a .su domain (because what good things are occurring on Soviet Union domains these days?). This can be effective against certain threats, but it's the equivalent of searching for villains by checking every mustachioed man's house for stockpiles of rope and large mallets. Building up more and more rules for alerting on this kind of activity has helped a lot of organizations thwart attacks, but it also takes a great deal of experience with missed attacks to compile a solid series of rules which either may alert again or may never trigger at all. Do you alert when you see a man with both rope and mallet, but just hasn't shaved in a day? What if someone with a mustache has been seen with both, but never at the same time? If the only certainty is for a threat to possess all three attributes at once, this emphasizes how limited very strong indicators of compromise can be when used in solutions which only correlate data points at a single point in time. Attackers have adjusted to use a great deal more "grey" behavior If you want to evade "bad only" detection, your best bet is to avoid activity that can only possibly be malicious. Since attackers are motivated people and motivated people adjust their approach to a problem when they have been unsuccessful, they have started using remote administration tools, stolen credentials, and a compromised machine in your company's primary country to serve as their access point. Then, to get the data out, they encrypt it and transmit over port 443. All of these actions, in isolation, are not enough to trigger any "known bad" alerts, so they have a nearly unlimited amount of time to operate, until a database administrator is lucky enough to notice his account being used without his permission. These attackers are not the old school villain tying a damsel to railroad tracks, but closer to "The Talented Mr. Ripley". No single action is enough to raise your suspicion, and you occasionally get an uncomfortable feeling, but by the time you realize what is happening, you are already a victim. We don't have the luxury of viewing all of the events of an attack from the audience's viewpoint. That is left to the follow-up reports wrapping it into a single hindsight narrative scapegoating the security team as incompetent. Building alerts for "possibly bad" activity causes alert fatigue A lot of the more funded teams recognized the shift toward questionable behavior rather than the obviously malicious, so they started building rules to alert on both. However, due to limitations in the rules engines at their disposal, they had to create a great deal of rules guaranteed to generate a lot of false positives. Without being able to look at activity even one minute before or after an event, alerts were the best way to take billions of events and pare them down to hundreds of thousands for triage. However, just as quickly as new attacker behaviors were learned and corresponding rules created, the triage teams started to lose the sense of urgency because they knew over ninety percent of the alerts would be false positives. The teams creating the rules are not to blame. It is the rules engines themselves. Just as you can tweak a car alarm's sensitivity so it doesn't sound when a loud truck passes, you can tweak or remove rules which are too frequently triggered, but the amount of effort involved is tremendous because you are still tweaking the triggers based on simultaneous events. Think about the last time you saw anyone urgently rush over to make sure an alarming car wasn't being stolen. Car alarms can only recognize events in the moment, so they are never going to be as useful as a human interpreting a slight nudge of the car to mean nothing unless it is then followed by another indicator a few moments later. Detection for modern intruders must correlate actions across time You aren't going to pick up the nuance of tripley not being the real Tom Ripley simply by creating a rule to flag every account which opens two concurrent VPN sessions running from different origination IP addresses. The chances these session overlap are incredibly rare, even if stolen, because the intruder is going to use various means to access the network, change accounts frequently after initial access, and use a lot more "low and slow" actions than malware of years past. We don't have the benefit of enjoying every single moment as dogs do, but as humans recognize cause and effect rather well, we can realize when an event explains what occurred two minutes earlier. We need our rules engines and detection to be able to effectively identify the sequence of negative events over time. At Rapid7, this recognition and comparison of events over time was built into the UserInsight solution from day one. We've moved from static indicators of compromise, such as concurrent VPN sessions, to behavioral patterns happening over the course of an hour or day. We are not trying to create the most IOCs of any solution ever, but each is designed as an intelligent, low-noise alert which can wait after witnessing event X until a follow-up event Y occurs within a given time period before triggering. Accessing a new asset for the first time is not noteworthy enough to cause a team to investigate the event, but accessing a few new assets in an hour might be extremely abnormal for the real tripley and, thus, warrant an alert. Near-time events are much more likely than simultaneous events, but they're a much bigger analytical challenge. UserInsight leverages its cloud-based analytics platform to detect these types of events, and we're constantly building out even more sophisticated intruder behavior patterns. As older solutions now offer you the ability to Hadoop this data and NoSQL that data with the promise to immediately bring all the benefits of security analytics, you need to ask how it improves your team's ability to detect and investigate attacks. There are benefits to these technologies when built into the core of solutions, but as an afterthought, they give your team a lot more questions you can ask your historical data for reporting purposes, but not smarter alerts or clear answers. If you want to learn more about UserInsight and our approach to detecting intruder behavior, check out the Rapid7 Incident Detection and Response page. I think you'll find we have the services and solutions to bring low-noise incident alerting into your organization.

Making Your Voice Heard for the Future of Automotive Safety

TL;DR: Show Your Support to Secure the Future of Automotive SafetyAbout a year and a half ago, Josh Corman and I began having a discussion about the rapid adoption of technology that has the ability to impact human life and public safety. We came…

TL;DR: Show Your Support to Secure the Future of Automotive SafetyAbout a year and a half ago, Josh Corman and I began having a discussion about the rapid adoption of technology that has the ability to impact human life and public safety. We came to the conclusion that technology is advancing faster than our ability to security it. When we say "our", this is all of us. It is the software developers who write the code that drives the hardware we are using. It is the consumers who need to securely maintain this technology. It is the businesses who go to market with the products that we buy. These early discussion became a security conference talk at BSidesLV and DEF CON in 2013. Rather than presenting to these communities on what we need to do to solve these problems, we wanted to start a conversation. Most of our community members had been focused on finding the latest zero day in consumer and business software powering traditional internet access technologies and information systems, while only a handful had focused on technology that would truly touch or impact human lives. We saw this as a problem and wanted to work to motivate people to spend more time "researching what matters" but in a way that would drive positive change.The presentations started a number of conversation both online and offline. Today, the online conversations are taking place on Twitter and a Google Group mailing list. The offline conversations are happening at non-infosec industry events, with media, at private manufactures events, and even on Capital Hill.During the first year, we honed our mission and the the group became focused on technologies within medical devices, automobiles, home electronics and public infrastructure industries.The future of this activity which has become known as "I am The Cavalry" (or IATC, or even just the "Cavalry Movement") is making strides to become a 501(c)(3) educational foundation focused on providing opportunities to build public awareness and hold open collaboration sessions between security researchers and industry representatives on developing news ways to tackle the security problems we'll face in the future.At DEF CON 22, Josh and I gave a presentation on what the Cavalry has been up to over the previous year, but also announced the results of a major initiative.We spent about 9 months collaborating with security researchers, automotive engineers, policy makers, insurance agents, accident investigators, and standards organizations to develop a "Five Star Automotive Cyber Safety Program" through an Open Letter to the Automotive Industry."This letter urges carmakers to:Acknowledge that vehicle safety issues can be caused by cybersecurity issues;Embrace security researchers as willing allies to preserve safety and trust;Attest to these five foundational capabilities to improve visibility of their Cyber Safety programs;Initiate collaboration now to avert negative consequences in the future."If you are interested in the future our automotive safety (and who isn't?) please sign the Change.org petition and join the several hundred other people from around the world who are in support of this important cause.This is just the start of things to come. I hope you will join us!Nicholas J. Percoco (@c7five)Vice President, Strategic ServicesRapid7

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