[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bastille and Comcast CVE IDs

My questions would be:

1) Is this web server documented? (if not, stronger case for CVE)
2) Is this web server needed to admin the device? E.g. my dsl/cablemodems both have a web server running on port 80/443, which show me a status page and allow login/admin if I access the page. Or is this web server running on a non-standard port for whatever purposes? (If yes, stronger case for a CVE)
3) can this web server be disabled, in the sense of CAN it be disabled (is there a config switch for this), and/or does disabling it break the product? Is it needed? (If it can't be disabled then a stronger case for the CVE, conversely if not needed a stronger case as well)
4) can the web server be contacted? (e.g. is it on localhost only, the LAN (e.g. semi trusted) interface only, or the WAN interface (e.g. the Internet)

Generally speaking I apply the above matrix for services and whether or not they need a CVE (so in most cases we deal with this by ensuring that the services run on localhost only/are firewalled, well documented, and so on).

And obviously the easy case:

5) if there is a specific flaw that can be exploited, then a CVE



On Mon, Oct 2, 2017 at 10:43 AM, Coffin, Chris <ccoffin@mitre.org> wrote:
> I don't see #23 as anything different than "device runs a web server."

True. But another side is that "device runs a web server" could and should be handled differently based on whether it's standard system with an OS vs. a closed appliance. In other words, a "Linux system running Apache" probably wouldn't ever get a CVE as it's more like a config issue, but in this case it would since it's an undocumented web server on a modem. At the very least it's an exposure I think.

Even if we were to decide against assigning these in the future, I'd say it's still important to alert folks to these kinds of issues. Does anyone disagree?

Chris

-----Original Message-----
From: Art Manion [mailto:amanion@cert.org]
Sent: Monday, October 2, 2017 11:27 AM
To: Coffin, Chris <ccoffin@mitre.org>; Kurt Seifried <kseifried@redhat.com>
Cc: cve-editorial-board-list <cve-editorial-board-list@lists.mitre.org>
Subject: Re: Bastille and Comcast CVE IDs

On 2017-10-02 11:27, Coffin, Chris wrote:

>> CVE-2017-9479
>> https://github.com/BastilleResearch/CableTap/blob/master/doc/advisories/bastille-22.syseventd.txt
>>
>> CVE-2017-9480
>> https://github.com/BastilleResearch/CableTap/blob/master/doc/advisories/bastille-23.upnp-directory-write.txt
>
> Here, problem number 22 (CVE-2017-9479) is unauthenticated execution of various commands as root. These commands can achieve a variety of results. From a penetration-testing perspective, the interest is in exfiltrating sensitive information for use in other attacks.
>
> Problem number 23 (CVE-2017-9480) is the existence of an undocumented HTTP server that provides access to a /var/IGD/ directory tree containing zero or more files, and is reachable without authentication. From a penetration-testing perspective, the interest is in immediately continuing the process of exfiltrating information.
> However, even if problem 22 were fixed, a configuration file could still be present in the HTTP server's directory tree if problem 22 had been exploited at any time before the fix occurred. That is the primary reason for a separate CVE. Also, it is possible that files are sometimes written to the HTTP server's directory tree for unrelated reasons, e.g., a Comcast technician copies files there while resolving a customer problem.

"Undocumented" can be an aspect of a vulnerability.  I'm not going to push for reject or disputed, but:

But what would be different about a Linux system running Apache and an attacker (possibly using other vulnerabilities) putting files in the Apache root to then download them?

Unless there is some other legitimate process that puts configuration files in /var/IGD, I don't see #23 as anything different than "device runs a web server."

 - Art



--
Kurt Seifried
kurt@seifried.org
Page Last Updated or Reviewed: October 02, 2017