Re: So some blindspots that came up as a result of CVE for service discussion

[Kurt Seifried <kurt@seifried.org>]

Another good example, a facebook issue:

https://philippeharewood.com/facebook-business-takeover/

TL;DR: you could add yourself as an admin to a business and hijack it. Probably good for people to review these for the vuln time period and I bet facebook could notify every company that had an admin added while the vuln was present. Having a CVE here would be a good example of adding awareness, e.g. a sample CVE description:

The Facebook /business/aymc_assets/admins/import/ API endpoint was vulnerable to a lack of authentication vulnerability allowing attackers to add themselves as an admin to any business on Facebook. The API was vulnerable from $DATE1 to $DATE2, all businesses are encouraged to check and verify their admin list (URL or instructions here) for potential malicious accounts. 

Also it seems like we might want to revisit allowing URL's in the description if it links to "how to fix this" kind of stuff. 

On Wed, Oct 31, 2018 at 12:48 PM Kurt Seifried <kurt@seifried.org> wrote:

Or part of the attack is that the attacker could delete or alter the log files (e.g. a flaw in CloudTrail on AWS for example puts us into that catch-22). 

On Wed, Oct 31, 2018 at 12:20 PM Pascal Meunier <pmeunier@cerias.purdue.edu> wrote:

Lisa,
        I like that document, except for the requirement that "there is something the
customer can do, post-fix, to detect earlier exploitation."  That assumes you have perfect
knowledge of what a customer would or could do, but the customer can have a different
perspective.  For example, a customer may decide that the best action is to change
providers!  That option will likely not be considered as something a customer can do, by
the provider, one reason being the conflict of interest.

Pascal

On Wed, 2018-10-31 at 17:20 +0000, Lisa Olson wrote:
> I’ve been brainstorming with colleagues here are Microsoft.  The attached document
> distills our thoughts and provides some examples.
>
> From: Kurt Seifried <kurt@seifried.org>
> Sent: Thursday, October 25, 2018 10:32 AM
> To: cve-editorial-board-list <cve-editorial-board-list@mitre.org>
> Subject: So some blindspots that came up as a result of CVE for service discussion
>
> So we had a good CVE for services discussion today and some blindspots were identified,
> the biggest one (and something the board will have to deal with) being:
>
> CVE Database - practical vs. theoretical?
>
> So in past the CVE database has largely been for exploitable vulnerabilities, although
> we don't require proof of exploitation typically most are pretty self explanatory, We do
> have cases like the Linux Kernel where we, out of caution, assign a lot of CVE's (http:/
> /cve.mitre.org/cgi-
> bin/cvekey.cgi?keyword=linux+kernel<https://na01.safelinks.protection.outlook.com/?url="">
> ttp%3A%2F%2Fcve.mitre.org%2Fcgi-
> bin%2Fcvekey.cgi%3Fkeyword%3Dlinux%2Bkernel&data="" href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsoft.com%7C559
> 77085ef7c4896844808d63a9ffe5d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6367608561853
> 43092&sdata=aBr1GPrl0N6oM6yXYOxgNFAPZQQ7JxWuK%2BjBNKVEjog%3D&reserved=0>;) because
> typically these flaws are found to be exploitable with enough work.
>
> However one aspect of this is that with software we can't know if it has been exploited
> or not, we don't even know in some cases who is running this stuff.
>
> This leads us to the cloud, most cloud providers do quite a bit of logging, and can in
> some cases definitely say "yes there is a vulnerability in service X, but we checked all
> our logs and it was never exploited/triggered", so in this case we definitely have a
> vulnerability, but we also have (as far as we know) definitive proof it was never
> exploited.
>
> So in this case, if we have proof it wasn't exploited, should it get a CVE or not? I can
> see arguments going both ways, but I'd like to get the Boards take on this.
>
> --
> Kurt Seifried
> kurt@seifried.org<mailto:kurt@seifried.org>

--

Kurt Seifried
kurt@seifried.org

--

Kurt Seifried
kurt@seifried.org