The information security community tends to look down on Internet of Things research and dismiss it as junk hacking. While the recent Mirai botnet attacks have raised the profile of embedded security, owning a “smart “ device still isn’t as sexy as owning a MacBook Air.
But popping IoT devices can potentially cause much more damage. Exploit vulnerabilities in enough set-top boxes, cameras and other embedded systems and an adversary can construct a botnet that’s capable of taking down the Internet for a large swath of the U.S.
Issues with IoT device security didn’t surface with Mirai malware. In fact, two years ago my colleague, Yoav Orot, and I discovered just how easy embedded systems are to pop. In just six hours we managed to tear apart an IP camera he purchased from eBay and discovered two zero-day vulnerabilities. But finding exploits wasn’t our ultimate goal. We wanted to hack the cloud protocol that the camera uses. The cloud protocol is why people buy these cameras. It connects the camera to a web server, allowing people to stream video to their desktops and smartphones without configuring their router’s network settings. But cracking the cloud protocol was a huge undertaking and we decided to shelve our research until we had enough resources to dedicate to this project.
We still lack the time to hack the cloud protocol but with researchers showing a greater interest in IoT security, now is the right time to discuss the two zero-days we discovered. We want to be part of the movement that calls for security to be incorporated into a device from its initial design stage instead of being tacked on after a flaw is publicly revealed.
As for the two zero days we discovered, they’re still unpatched. While others have researched the same flaws we’re going to talk about, we’ve discovered even easier ways to exploit them and use them to cause even greater damage. Since the exploits can be used to gain control of a person’s camera and, theoretically, use the camera as a pivot point to the internal network, we’re not going to reveal many technical details or product information right now. We estimate that this exploit affects hundred of thousands of cameras worldwide and don’t want the bad guys to use our research to attack people or use these cameras in future botnet attacks.
Given the complicated manufacturing and distribution chain surrounding white-box manufacturers, figuring out which vendors are selling the vulnerable cameras has been challenging. However, we’re fairly certain that security flaw can be traced to the company that assembled the cameras. Each camera has a different hardware but the same software, leading us to suspect that assembler also wrote the devices’ software.
The company that assembles the cameras and some of the vendors selling them have been notified about the exploits but we haven’t heard back from them and don’t expect to receive a reply. Some companies, especially those that crank out cheap IoT products, aren’t interested in or can’t patch their products. They’re focused on getting a device to market as quickly as possible, reducing security to an afterthought. In many cases, developing and selling a new model that addresses the exploit is easier and more lucrative than repairing the flawed models, either through a recall or by issuing a software update.
The vulnerable cameras readily available on Amazon from several vendors. In fact, I ordered 31 cameras with the flaw from different retailers on Amazon. In an ironic twist, Vstarcam one of the vendors selling cameras affected by these vulnerabilities brags on its website that users will no longer have “security vulnerability worries” with the device since it tells users if they have a weak password, among other features.
VStarcam should really rethink that part about their cameras not having security vulnerability worries.
Most of the cameras run older versions of Linux, like version 2.6.26, while a few run the most recent version from around 3.0 and up. While the OS is somewhat modern, all the cameras were running extremely old and vulnerable software, especially programs that people use to connect to the Internet. The Web server software found in many of the cameras, for example, was from around 2002.
The first zero day my colleague Yoav and I discovered combined authentication bypass and information disclosure. This allowed us to request any file in the Web server folder. We knew there was a file that contained important information like the password people used to access the camera. So, using the authentication bypass and information disclosure exploit we simply asked the camera to give us the password.
Recently, I also found out that even if you want to set a strong password (even though we have the ability to just ask the camera for the password), you simply cannot, because of the fact that the developer used an ‘or’ operand instead of an ‘and’. That means that a password can only be all numbers or all lowercase characters or all uppercase characters. Lovely.
Having the password allowed me to use the exploit I discovered. This exploit lets me inject commands via Web server, which is important since the Web server itself runs as root, all Web server commands run as root as well. And since I have root access, it doesn’t matter if users change their passwords: with root access, I can always take control the camera. In addition to being able to move the camera and see the images it’s sending (or make it send different images), I can also execute code. And by using a site like Shodan or Censys, which lets people search for specific devices connected to the Internet, I can run queries, find other cameras with the vulnerabilities, execute malicious code on them and within minutes build a botnet of hundreds of thousands of devices.
Like we mentioned earlier, we’re not disclosing the full technical details just yet. This would allow any attacker to use them to compromise a vulnerable camera. Unfortunately, even though we’ve responsibly disclosed the flaws, this may not lead to the vulnerabilities getting fixed. The cameras aren’t designed to receive software updates so the zero-day exploits can’t be patched. To show that this research is authentic, I put together a video that shows the vulnerabilities being exploited.
The only way to guarantee that an affected camera is safe from these exploits is to throw it out. Seriously. This isn’t an ideal solution, but the only other way to update it would be to use a script I created to identify which cameras are vulnerable. The script, however, includes the exploits’ code. This means attackers could use the script for nefarious purposes, so I don’t want to release it.
I’m also not releasing the names of all the camera vendors. This would encourage hackers to look for the software flaws. I named VStarcam since their cameras are readily available from eBay and Amazon. Their cameras are also sold under the name Eye4.
Unlike the cameras from other vendors I researched, VStarcam has its email address, phone number and mailing address listed on its website, making it easy for me to contact them, which I did by email. However, VStarcam never replied. Other cameras I ordered were literally delivered in a white box without a manufacturer’s name or even a logo, making it impossible to figure out who to contact. And the cameras weren’t much help in revealing what company made them: they weren’t branded.
However, I will say the other models I researched can be easily purchased on eBay and Amazon. I’ve discovered at least 10 different models from different manufacturers that all have the vulnerabilities. While the cameras’ Web user interfaces and brand logos are all different, the software and hardware are the same in each model. For example, the cameras have all the features even if they don’t appear in the user menu. If you know the URL that leads to the configuration page of that feature, you can access this feature directly, even if the model you have does not “officially” support it.
Cybereason developed a tool that helps people determine if their camera is vulnerable to these zero-day threats. Input some information about the camera and we’ll tell you if your camera is affected. Check it out.
MEYE
MCI
VST*
XXC
005*
J MTE
WEV
PIPCAM
SURE
NIP
EST
VIEW
PSD
People tend to look down on IoT research and call it junk hacking. But that isn’t the right approach if researchers hope to prevent future Mirai botnet attacks. A smart (insert device here) is still a computer, regardless of its size. It has a processor, software and hardware and is therefore vulnerable to malware just like a laptop or desktop. Whether the device records The Walking Dead or lets you watch your cat while you’re at work, attackers can still own it. And if they do own your IoT device, the potential consequences can impact both consumers and enterprises.
Researchers should work on junk hacking because these efforts can improve device security (and consumer security in the process), keep consumer products out of the garbage heap and prevent them from being used to carry out DDoS attacks.
March 8th, 2017 update:
Security researcher Pierre Kim published a comprehensive list of Ip cameras affected by these vulnerabilities and even found similar vulnerabilities. Check it out here.
Amit Serper is Principal Security Researcher at Cybereason. He specializes in low-level, vulnerability and kernel research, malware analysis and reverse engineering on Windows, Linux and macOS.
Over the last five years ransomware operations evolved both in capabilities and the degree of organizational structure behind it. In this webinar, we’ll cover the changes, what they mean and how cybersecurity strategies need to adapt to match this changing threat. But most importantly, have we learned from our past mistakes?
The challenge with threat hunting is the fidelity of the detections. How does a threat analyst have trust in the tools they use–and of course, if they don’t trust them, then how long does it take them to verify manually?
