Threat Intelligence

3/7/2017
10:30 AM
Marc Laliberte
Marc Laliberte
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

A Real-Life Look into Responsible Disclosure for Security Vulnerabilities

A researcher gives us a glimpse into what happened when he found a problem with an IoT device.

As an information security researcher, a major part of my job is to help software and hardware manufacturers fix security issues before they're exploited by bad guys. When white hat hackers like me find a new zero-day vulnerability in devices or software, we report it directly to the vendor using a series of steps called "responsible disclosure."

I reviewed this process in an earlier post here on Dark Reading. Unfortunately, the disclosure process is sometimes criticized. Some accuse manufacturers of not fixing the problems with their devices, while others accuse researchers of releasing vulnerability information recklessly. But based on my personal experience reporting vulnerabilities, I strongly believe disclosure is beneficial for all parties involved.

To prove this point, I'd like to walk you through a recent research project I completed so you can see the steps we take to find and responsibly disclose a new vulnerability. Some quick background: I'm part of WatchGuard's Threat Lab, and we recently launched an ongoing research project that evaluates Internet of Things devices in response to the growing threats associated with the Mirai botnet. It's worth noting that the vendor highlighted in this example was exemplary in responding to our disclosure and worked to immediately patch the vulnerability.

The product I'll cover in this article is the Amcrest IPM-721S Wireless IP camera. This webcam allows users to view footage at Amcrest's website (called Amcrest View). The first thing I attempted was the obvious goal: viewing from a camera that was not associated with my account. Let's jump in.

I performed most of my investigation using Burp Suite's proxy. My attempts to retrieve connection information for a specific camera with an unauthenticated session failed, confirming that Amcrest verifies ownership of each camera's serial number by the authenticated user before providing connection details. No vulnerability here.

If I couldn't view a camera that I didn't own, how about simply taking ownership of the account that owned the camera?

Amcrest View, like most Web applications, lets users modify account settings such as the associated email address. To change the email address associated with an account, the browser submits a POST request. The POST request contains several parameters with the important ones being “user.userName” and “user.email.” A successful request tells Amcrest View to set the email address for the username in the user.userName parameter to the value of the user.email parameter. As it turned out, my request was successful even when the user.userName parameter didn't match the username of the currently authenticated user session. Houston, we have a problem.

If I wanted to exploit this vulnerability, I could have modified the email address associated with any account and then issued a password reset to take over the account and obtain live access to their cameras (creepy, right?). While confirming the unauthorized account modification vulnerability, I also found the input I passed in the user.email parameter was not validated or fully sanitized. This means the software did not have code to check that the user.email parameter was, in fact, an email address. This could be exploited to inject arbitrary JavaScript into a victim's session — a perfect example of a stored cross-site scripting vulnerability. Attackers use cross-site scripting vulnerabilities to siphon off authentication credentials and load malicious websites full of malware without the victim's knowledge.

After discovering this vulnerability, I turned my notes, screenshots, and code samples into a vulnerability disclosure report, which you can read in full here. I submitted this report to Amcrest on November 4, 2016. Many large vendors have a process in place for reporting vulnerabilities, and if not, a researcher usually sends an email encrypted with the vendor's public PGP key. In this case, I contacted Amcrest's support team to inquire how they would like me to report the vulnerability. Ultimately, I submitted my vulnerability report through a support case.

Now the important question — what is the appropriate amount of time to allow a researcher to respond before publicly disclosing a vulnerability? A researcher should allow vendors a reasonable amount of time to investigate and patch a vulnerability, but there's no industry standard for how long that is. I opt for 60 days, which is common.

Once the vendor has issued a patch, or if the vendor has not responded in a reasonable amount of time, a researcher will usually publish their vulnerability report publicly. This allows end users to protect themselves if the vendor can't or won't fix the problem (the implied threat of public disclosure can put pressure on vendors to fix security issues quickly).

Fortunately, that was not an issue in this case. Amcrest got back to me in just four days to confirm my report. By early December, it had patched the vulnerabilities and issued a security notice that urged customers to update their camera's firmware. I published my security report, satisfied I had helped at least one company and its users become more secure. This was a win-win for all parties involved.

Contrary to what you might read in the news, most vulnerabilities reported to manufacturers turn out like this one. Both parties benefit; the vendor makes their products and customers more secure, and the researcher increases public awareness of vulnerabilities and builds their reputation by publishing their findings. It's not a perfect system, but I strongly believe it's beneficial for everyone involved.

Related Content:

Marc Laliberte is an information security threat analyst at WatchGuard Technologies. Specializing in network security technologies, Marc's industry experience allows him to conduct meaningful information security research and educate audiences on the latest cybersecurity ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
baller188
100%
0%
baller188,
User Rank: Apprentice
3/14/2017 | 5:45:31 AM
Forex and vulnerabilities
Interesting Marc,

I THINK AS TECHNOLOGY ADVANCES AND SOFTWARE AND HARDWARE WILL HIT SECURITY AND VULNERABLE ISSUES ALONG THE WAY. 
RahulR830
50%
50%
RahulR830,
User Rank: Apprentice
3/14/2017 | 1:30:22 AM
Well Written
Interesting article. A RESPONSIBLE disclosure in theory is meant to be a Win-Win for all parties involved. My 5 cents on what could be a perspective distortion - https://goo.gl/RYPw82
It Takes an Average of 3 to 6 Months to Fill a Cybersecurity Job
Kelly Jackson Higgins, Executive Editor at Dark Reading,  3/12/2019
763M Email Addresses Exposed in Latest Database Misconfiguration Episode
Curtis Franklin Jr., Senior Editor at Dark Reading,  3/11/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: LOL  Hope this one wins
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
The State of Cyber Security Incident Response
The State of Cyber Security Incident Response
Organizations are responding to new threats with new processes for detecting and mitigating them. Here's a look at how the discipline of incident response is evolving.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-6149
PUBLISHED: 2019-03-18
An unquoted search path vulnerability was identified in Lenovo Dynamic Power Reduction Utility prior to version 2.2.2.0 that could allow a malicious user with local access to execute code with administrative privileges.
CVE-2018-15509
PUBLISHED: 2019-03-18
Five9 Agent Desktop Plus 10.0.70 has Incorrect Access Control (issue 2 of 2).
CVE-2018-20806
PUBLISHED: 2019-03-17
Phamm (aka PHP LDAP Virtual Hosting Manager) 0.6.8 allows XSS via the login page (the /public/main.php action parameter).
CVE-2019-5616
PUBLISHED: 2019-03-15
CircuitWerkes Sicon-8, a hardware device used for managing electrical devices, ships with a web-based front-end controller and implements an authentication mechanism in JavaScript that is run in the context of a user's web browser.
CVE-2018-17882
PUBLISHED: 2019-03-15
An Integer overflow vulnerability exists in the batchTransfer function of a smart contract implementation for CryptoBotsBattle (CBTB), an Ethereum token. This vulnerability could be used by an attacker to create an arbitrary amount of tokens for any user.