Establishing asset ownership in vulnerability reporting

Who's stuff is this anyway?

Something I see people struggle with consistently in vulnerability reporting is being able to answer the question of ownership and "where to report my findings." It might seem like an obvious question to answer, but large organizations, cross-border reporting, mergers and acquisitions, and the simple fact that "not everyone knows where their stuff is in the first place" can make this a difficult question to answer.

It's essential to make sure you're talking to the right folks.

Here are some practical tips for establishing ownership and thereby identifying the appropriate coordinator to contact.

Context

For this problem, there are three persona's to consider:

1. Coordinator: The entity or team tasked with making certain security information gets to the right place.
2. Fixer: The entity or team that is enabled to triage and action the remediation of security issues.
3. Owner: The entity legally responsible for the asset. They are usually the ones who pay and get paid for whatever the asset does.

Did you notice the order? It's deliberate because it's how the chain of conversation most frequently works in the real world. The rub is that finders often invert this "order of effectiveness" and, in doing so, send their reports to the wrong place and become frustrated by the outcomes.

Note: This post is referring to dynamic, publicly-addressable systems. We'll do a follow-up on non-hosted assets in the future.

Example

Google owns Google Android, the Android development team fixes Google Android, and Google controls coordination/intake for vulnerability reports. As a large organization has been doing this a long time, Google had the good sense to lay this all out and make it clear... but what if you're trying to help an organization that hasn't?

Counter-example

In a recent attempted report, the Sakura Samurai crew found vulnerabilities in a range of Indian Government entities. They then went looking for a coordinator for the "Indian Government" and found the VDP page for the National Critical Information Infrastructure Protection Centre (NCIIPC). Presuming that this intake offered coordination on behalf of all Indian Government agencies, they sent their findings to it, and a fair amount of confusion ensued.

Why this matters

Aside from needing to get the issue resolved, contacting the right place also matters when considering the safety of submitting a vulnerability. A perceived parent organization might have a very different reaction to inbound vulnerability reports to the actual parent. Ultimately, the organization that owns the assets sets the vulnerability disclosure policy, so mapping the asset and the owner together should be a part of any security researchers reporting and disclosure workflow.

Tips

Okay, how do I figure out who owns this thing and where I should report the vulnerability?

Forward lookup

1. Is the owner obvious? As the Indian Government example above demonstrates, this is an excellent question to ask yourself more than once - but once you are confident, start here.
2. With the company name or their main domain as your key, you can check out the diodb for a contact point or interrogate any security.txt files which may exist.

Reverse lookup

Ok, so it's not immediately apparent, or you want to double-check. What now? The following tips are in order of the authority of their response.

1. security.txt: Check the asset for a security.txt file. If one exists, you'll get a quick and authoritative answer.
2. Whois lookup: A quick whois on the FQDN will often point you in the right direction. The exceptions here are usually around PaaS/IaaS hosted assets.
3. Authoritative DNS: What is the authoritative DNS for the FQDN, and who owns that DNS server?
4. crt.sh: Do a certificate transparency lookup on the domain or FQDN - A lot of organization-level information can be found this way
5. Direct certificate inspection: If the target serves via an SSL certificate, inspecting the certifying chain and certificate details often provides useful attribution of the owner.
6. Copyright and legal notices: It seems trite but you'll often find that the legal entity named in a legal notice on a web target is different (or counterintuitive) to the domain name.
7. ASN lookup: If there's no domain to work from, query the IP address with an ASN lookup tool and find the owner.
8. diodb: The disclose.io contact database is an easy place to search for this type of information, and we've recently added the ability to search on incomplete names/FQDNs, which can help find the owner.
9. Google it! - Busting out the research skills and double-checking the FDQN, IP, or other asset details can be a short path for knowing who to ping.
10. Contact Us: In some instances, an organization may maintain a security point of contact on their “Contact Us” page of a web application.

Catch-all

1. Local Computer Emergency Response Center (CERT). With few exceptions, the country that hosts the asset has a CERT. Security issue coordination is their job, and they are quite good at it, so this is the ever-present default option. The downside of CERTs is that you don't get to interact directly with the owner for clarification, fix, or Q&A - So while it's ever-present, it's often also the option of last resort.

Originally published at https://blog.disclose.io on March 21, 2021.