This Week in Security: Expert Takes on the Headlines
« Back to Blog

This Week in Security: Expert Takes on the Headlines

By Cylance Research and Intelligence Team

My Other Robot Is Your Robot

In yet another ‘Internet of Insecure Things’ tale, Rapid7 recently disclosed a handful of vulnerabilities affecting Double Robotics’ popular telepresence robot system. While not exactly the kinds of issues that would lead to a robot uprising anytime soon, especially given that these aren’t exactly autonomous devices, they still could have potentially allowed a malicious person to do some bad things (perhaps an iPad-on-wheels chasing you around to the tune of Yakety Sax).

The issues that were disclosed included unauthenticated access to device serial numbers, user information, GPS coordinates of the device, and even the possibility of controlling the device itself without the user’s consent. Unauthorized control of the device could have been achieved either by taking advantage of a weakness in the Bluetooth pairing process, wherein the ‘challenge PIN’ was not actually required to pair to the device; or by obtaining a user’s session token (which never actually changed) for Double Robotics’ web API, and then using the token to remotely control the target device. 

Luckily, Double Robotics addressed the unauthenticated access and session management issues (currently #2 on the OWASP Top 10), but there are still some takeaways: 

·        For web applications and APIs, robust authentication, authorization, and session management are crucial for security. Ensure that the server and framework(s) you’re using have good (secure!) support for all of the above. The Open Web Application Security Project (OWASP) has a great Session Management Cheat Sheet, as well as an overall development guide. Also, be sure to conduct security assessments/application penetration tests against your web applications/services.

·        If your device supports Bluetooth or Bluetooth Low Energy (BTLE), ensure that you take advantage of security features that are available, including authenticated pairing and encryption. It’s also advisable to test the Bluetooth security configuration in development (and production) to ensure it is resilient against any attacks. For more information on Bluetooth security features, check out NIST’s Guide To Bluetooth Security (SP 800-121). If you’re looking to test Bluetooth security, a tool like Pwnie Express’ BlueHydra could be useful.

SS7: Super (In)Secure...7?

Signaling System 7 (SS7) has been a core protocol in telecommunications and mobile networks for years, but hasn’t been aging gracefully from a security standpoint. As far back as 2008, researchers demonstrated the ability to track cell phones by taking advantage of vulnerabilities in SS7, and in 2014, researchers demonstrated how to profile users and track devices with high precision by abusing SS7.

Thus far, it hasn’t been (publicly) stated whether these issues are truly being addressed, but some members of Congress are pushing for answers. Rep. Ted Lieu (D-Calif.) and Sen. Ron Wyden (D-Ore.) recently sent a letter expressing their concerns about SS7 security to Secretary of Homeland Security, John F. Kelly. In the letter, they ask Kelly if there is doubt about a surveillance threat; what resources DHS has for identifying threats to SS7; what assistance is being provided to wireless carriers to help identify SS7-related vulnerabilities and attacks; and what DHS is doing for public awareness. Lieu and Wyden have asked for a response by the end of March 2017.

To learn more details about SS7, its inner workings, and the impact of the vulnerabilities therein, we’d strongly recommend you check out Tobias Engel’s presentation, “SS7: Locate. Track. Manipulate” at Chaos Computer Congress 31 in 2014 (video hereslides here). Incidentally, his presentation also includes suggested countermeasures/defenses for mobile operators/carriers. 

For mobile customers, while there aren’t a whole lot of significant defenses, for those inclined to be better aware of whether they are potentially falling prey to rogue cellular base stations or IMSI catchers, there are tools such as Android IMSI-Catcher Detector and SnoopSnitch (for Android users, anyway). If privacy is of utmost concern, consider using a phone (or app) which implements ZRTP, such as SilentCircle's Blackphone2 or OpenWhisper's Signal app.

As an aside, as far as the future of SS7 security goes, interestingly enough, there is at least some public research about using machine learning to bolster SS7 security.

Die, Die Mirai Darling

It seems like you can’t even so much as mutter the letters “IoT” without the inexorable mention of the Mirai botnet. For those unfamiliar, Mirai was the source of one of the largest distributed denial of service (DDoS) attacks to date, by way of compromising insecure IoT devices, and using them to effectively render several popular Internet services unreachable. As the source code for the Mirai ‘bot’ software was released late last year, it should come as no surprise that attackers are adapting it for even more advanced maleficence, according to a BankInfoSecurity interview with Arbor Networks’ Gary Sockrider. Of note, Sockrider points out that Mirai’s prevalence and evolution will likely lead to ‘multi-terabit’ DDoS attacks. 

Equally chilling is news from CSO Online, featuring insights from sources such as Level 3 Communications and the malware research group, Malware Must Die. Level 3’s CSO, Dale Drew, for instance, mentioned there were between 500,000 and 600,00 devices infected with Mirai at one time or another, and that Level 3 has been taking down various Mirai Command and Control (C2) hosts as frequent as “every four hours”. The article also highlights that, according to Malware Must Die, a Chinese group is adapting Mirai to specifically target a Taiwanese manufacturer’s IoT products.  

While we’ve covered Mirai before (and it’s unlikely this will be the last time, based on its seemingly unending prevalence), we’ll remind readers of some tips to help reduce their risk of succumbing to Mirai or other IoT attacks: 

·        Change default passwords (and even usernames, if possible) on routers, wireless access points, and other network devices. Make the password long (minimum of 12-14 characters) and use a combination of lowercase and uppercase alphabetical characters, numbers, and symbols.

·        Keep firmware and patches up-to-date on devices, and be sure to get updates only from the manufacturer's site or service. Most devices have a built-in web page or app to perform the update, and an increasing number of home network devices update automatically.

·        If the device has a built-in firewall, review configuration options to block unnecessary ports and services. Additionally, if there are options to configure services such as Universal Plug and Play (UPnP), disable them if they are not necessary. 

For more tips and information, check out the following links:

·        https://staysafeonline.org/stay-safe-online/keep-a-clean-machine/securing-your-home-network
·        https://staysafeonline.org/stay-safe-online/keep-a-clean-machine/malware-and-botnets

For manufacturers of IoT or otherwise Internet-connected embedded devices, we urge you to review some of the information recently published by NIST and the Department of Homeland Security:

·        https://www.nist.gov/programs-projects/nist-cybersecurity-iot-program
·        https://www.dhs.gov/securingtheIoT

Tags: