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
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Security Technologies to Watch in 2017
Emerging tools and services promise to make a difference this year. Are they on your company's list?
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7445
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

CVE-2015-4948
Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

CVE-2015-5660
Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

CVE-2015-6003
Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

CVE-2015-6333
Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.