On Thursday, September 27, 2018 at 10:22:05 PM UTC-7, Dimitris Zacharopoulos wrote: > Forgive my ignorance, but could you please explain what was your > ultimate goal, as "an attacker", what were you hoping to gain and how > could you use this against Relying Parties? > > I read your email several times but I could not easily find a case where > your fake address creates any serious concern for Relying Parties. Even > if you used the same street address as CloudFlare, the CA would check > against the database and would find two company records that share the > same address. That would obviously block the process and additional > checks would take place. Now, as a way to delay certificate issuance for > CloudFlare, I find it interesting but it certainly doesn't seem to > affect Relying Parties.
I think Ryan's reply was spot on, but I do want to clarify a couple of things. First, CAs typically make lookup requests to D&B by specifying the company's DUNS number. This means that they aren't searching for a given company name; any conflicting companies would not come up in a search. Also, I think you overestimate validation agents; Comodo actually found the real Cloudflare on another QIIS and emailed me saying they found a "similar" company, but was happy to ignore it when I gave them a valid DUNS number. > And to take this one step further, I believe there are several GISs that > also accept whatever address you tell them because: > > 1. They have no reason to believe that you will lie to them (they know > who you are and in some Jurisdictions you might be prosecuted for > lying to the government) > 2. No foreseeable harm to others could be done if you misrepresent your > own address. > > Since we are discussing about Data/Information Sources, the BRs define > how CAs should evaluate a Data Source and declaring it "Reliable". > > > "3.2.2.7 Data Source Accuracy > > Prior to using any data source as a Reliable Data Source, the CA SHALL > evaluate the source for its reliability, accuracy, and resistance to > alteration or falsification. The CA SHOULD consider the following during > its evaluation: > > 1. The age of the information provided, > 2. The frequency of updates to the information source, > 3. The data provider and purpose of the data collection, > 4. The public accessibility of the data availability, and > 5. The relative difficulty in falsifying or altering the data. > > Databases maintained by the CA, its owner, or its affiliated companies > do not qualify as a Reliable Data Source if the primary purpose of the > database is to collect information for the purpose of fulfilling the > validation requirements under this Section 3.2." > > The EVGs also describe how to evaluate and declare the "Qualified" status: > > > "11.11.5. Qualified Independent Information Source > > A Qualified Independent Information Source (QIIS) is a regularly-updated > and publicly available database that is generally recognized as a > dependable source for certain information. A database qualifies as a > QIIS if the CA determines that: > > (1) Industries other than the certificate industry rely on the database > for accurate location, contact, or other information; and > > (2) The database provider updates its data on at least an annual basis. > > The CA SHALL use a documented process to check the accuracy of the > database and ensure its data is acceptable, including reviewing the > database provider's terms of use. The CA SHALL NOT use any data in a > QIIS that the CA knows is (i) self-reported and (ii) not verified by the > QIIS as accurate. Databases in which the CA or its owners or affiliated > companies maintain a controlling interest, or in which any Registration > Authorities or subcontractors to whom the CA has outsourced any portion > of the vetting process (or their owners or affiliated companies) > maintain any ownership or beneficial interest, do not qualify as a QIIS." > > > In my understanding, this is the process each CA must perform to > evaluate every Data Source before granting them the "Reliable" or > "Qualified" status. Self-reported information without any supporting > evidence is clearly not acceptable. I have not evaluated this database > that you mention but if they accept self-reporting for "Street Address" > and don't perform any additional verification (like asking you for a > utility bill or cross-referencing it with a government database), then > the "Street Address" information is unreliable and the CA's evaluation > process should catch that. > > That doesn't mean that the rest of the information is also unreliable. > For example, an Information Source might describe in their documentation > practices how they verify each piece of information, for example: > > * the Jurisdicion of Incorporation (they check official government > records), > * registry number (they check official government records), > * the name of legal representative (they check official government > records), > * the official name of the legal entity (they check official > government records), > * street address (they check the address of a utility bill issued > under the name of the legal entity), > * telephone numbers (self-reported), > * color of the building (self-reported), > > and the CA, during evaluation, might decide to accept only the first 5 > as Reliable/Qualified Information as they have higher level of > assurance. That would be the right thing to do. For the rest of the > information, the CA should probably request additional validation > information from the Applicant. > > Sorry for the long email, quoting requirements always does that :) > > > Dimitris. > > On 27/9/2018 2:52 πμ, Ian Carroll via dev-security-policy wrote: > > Hi, > > > > In April and May of this year, I attempted to change the address listed in > > Dun & Bradstreet of my (Kentucky-incorporated) company "Stripe, Inc" to an > > address in Toledo, Ohio that did not exist (185 Berry Street Toledo Ohio). > > I was wondering the extent of validation Dun & Bradstreet would do on the > > data. > > > > To my surprise, they accepted my change request a couple days later. This > > is concerning, of course, because D&B is a QIIS backing most EV certificate > > requests in the United States. > > > > After this worked, I realized this was probably worth exploring more, so I > > took my "Cloudflare, Inc" company (also incorporated in Kentucky) and > > requested that Dun & Bradstreet change its address to "102 Townsend St San > > Francisco CA". You might notice that this is the same address as the real > > Cloudflare, but with the street number incremented by one. > > > > D&B accepted that change request as well. This meant I controlled a DUNS > > number that would resolve to a very similar address to CF, with my phone > > number on it. > > > > I ordered two EV certificates from Comodo (order #s 136665865 and > > 141269115) with these fake DUNS numbers. I successfully completed the > > validation and callback process for the Cloudflare order, and Comodo was > > about to issue the certificate, but both of my orders were silently deleted > > before they were about to be issued. > > > > Comodo would not give me any information about why they (silently) rejected > > my orders, but Dun & Bradstreet banned my account shortly after, so it is > > safe to say they reported me after they realized something went wrong. > > > > I think this is a strong indictment of D&B as a QIIS. The definition of a > > QIIS, in my opinion, is incredibly lax, but "which is generally recognized > > as a dependable source of such information" is hard to meet here. > > > > I am also, frankly, annoyed that Comodo seems to have silently discovered > > that D&B was unreliable and then ignored it without reporting it further. I > > myself have been meaning to send this for a while, given I did this in May, > > but various things have made it difficult for me to find the time. > > > > Let me know if I can provide any further information. > > _______________________________________________ > > dev-security-policy mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
