Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

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 a senior security analyst at WatchGuard Technologies. Specializing in networking security protocols and Internet of Things technologies, Marc's day-to-day responsibilities include researching and reporting on the latest information security threats and ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
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
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. 
5 Ways to Up Your Threat Management Game
Wayne Reynolds, Advisory CISO, Kudelski Security,  2/26/2020
Exploitation, Phishing Top Worries for Mobile Users
Robert Lemos, Contributing Writer,  2/28/2020
Kr00k Wi-Fi Vulnerability Affected a Billion Devices
Robert Lemos, Contributing Writer,  2/26/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
State of Cybersecurity Incident Response
State of Cybersecurity Incident Response
Data breaches and regulations have forced organizations to pay closer attention to the security incident response function. However, security leaders may be overestimating their ability to detect and respond to security incidents. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-3006
PUBLISHED: 2020-02-28
On the QFX3500 and QFX3600 platforms, the number of bytes collected from the RANDOM_INTERRUPT entropy source when the device boots up is insufficient, possibly leading to weak or duplicate SSH keys or self-signed SSL/TLS certificates. Entropy increases after the system has been up and running for so...
CVE-2015-5361
PUBLISHED: 2020-02-28
Background For regular, unencrypted FTP traffic, the FTP ALG can inspect the unencrypted control channel and open related sessions for the FTP data channel. These related sessions (gates) are specific to source and destination IPs and ports of client and server. The design intent of the ftps-extensi...
CVE-2020-6803
PUBLISHED: 2020-02-28
An open redirect is present on the gateway's login page, which could cause a user to be redirected to a malicious site after logging in.
CVE-2020-6804
PUBLISHED: 2020-02-28
A reflected XSS vulnerability exists within the gateway, allowing an attacker to craft a specialized URL which could steal the user's authentication token. When combined with CVE-2020-6803, an attacker could fully compromise the system.
CVE-2019-4301
PUBLISHED: 2020-02-28
BigFix Self-Service Application (SSA) is vulnerable to arbitrary code execution if Javascript code is included in Running Message or Post Message HTML.