[NCAP-Discuss] [Ext] Revised draft of NCAP Study 1 report
Rubens Kuhl
rubensk at nic.br
Sat Feb 8 23:02:19 UTC 2020
While I can't speculate on what Verisign would do with ORDINAL, to this date every data point available to Verisign was used in a commercial way, as an anti-competitive tool to delay delegation of more TLDs or to paint those TLDs as security threats without factual basis. So, that affirmation would be difficult to take at face value.
Rubens
> On 8 Feb 2020, at 19:39, Danny McPherson <danny at tcb.net> wrote:
>
>
> Heya folks, just to set the record straight on the Verisign end of this, an exchange between Jeff Schmidt and our CTO regarding this topic is included inline here.
>
> Further, we have no record of ICANN ever reaching out to Verisign on this matter -- the ICANN correspondence page agrees with this.
>
> -Danny
>
> [snip]
>
> From: Burton Kaliski <bkaliski at verisign.com>
> Date: Thursday, June 14, 2018 at 10:58 AM
> To: Jeff Schmidt <jschmidt at jasadvisors.com>
> Cc: Patrick Kane <pkane at verisign.com>, "McPherson, Danny" <dmcpherson at verisign.com>
> Subject: RE: Operational Research Data from Internet NAmespace Logs (ORDINAL) Dataset
>
>
> Jeff,
>
>
> We’ve taken a little time to reflect internally on our recent communications with you about the Operational Research Data from Internet NAmespace Logs (ORDINAL) dataset. We have a perhaps similar sense of surprise and disappointment that our request to access the dataset from this public source was denied, considering that you had just asked us to help sponsor it.
>
> For the record, here’s our understanding of our communications about ORDINAL with you and with the US Department of Homeland Security’s Information Marketplace for Policy and Analysis of Cyber-risk & Trust (IMPACT), the host of the dataset:
>
> August 29, 2016: JAS Advisors asks Verisign to consider participating in an investment to preserve the domain corp.com for research purposes. Verisign would be a “responsible buyer,” the proposal states, and an investment by Verisign would help a protect the Internet. Verisign subsequently declines, based in part on our lack of commercial interest in the data.
> March 31, 2017: JAS Advisors sets up the ORDINAL dataset on ImpactCyberTrust.org as a way of making DNS data logs, including logs related to corp.com, available to the research community.
> March 9, 2018: JAS Advisors sends email to DNS-OARC dns-operations mailing listannouncing the ORDINAL dataset and inviting researchers to “look into these unique datasets and make the Internet a better place.”
> March 22, 2018: Verisign researcher contacts IMPACT to request access to the ORDINAL dataset in response to JAS Advisors’ solicitation on the mailing list. (Request: DSR-5495)
> March 29, 2018: Not having received an acknowledgement of the request, Verisign researcher contacts the IMPACT Coordinating Center for a status update. IMPACT administrator responds that they contacted the provider (JAS Advisors) and were still waiting for an answer.
> April 4, 2018: JAS Advisors asks Verisign (in thread below) to consider supporting the ORDINAL data set.
> April 12, 2018: Verisign responds to JAS (in thread below) stating that “to the extent the resource is openly available to the research community, we’ll consider it as a data source, but we’re not ready otherwise to be any more involved.” Verisign also asks JAS about the Verisign researcher’s outstanding request to access the ORDINAL dataset.
> April 13, 2018: Verisign researcher contacts the IMPACT Coordinating Center again for status. IMPACT administrator provides the same response: still waiting for an answer from JAS.
> April 19, 2018: Verisign researcher receives notification from IMPACT administrator that the request to the ORDINAL dataset has been denied, but no reason for denial is provided.
> April 23, 2018: Verisign researcher receives this reason for denial from IMPACT administrator: “This dataset is not permitted for commercial usage. I understand that your rationale may be that this is internal research. However, given Verisign’s commercial products that directly overlap with this data and subject area, it was felt that a non-commercial argument could not be made in this circumstance.”
> May 2, 2018: Verisign receives email from JAS (in thread below) stating that stating that Verisign’s position not to support the ORDINAL data set is “surprising and disappointing” and that “the owner of corp.com ... has decided to not make the data available to Verisign.”
>
> As the Verisign researcher noted in the request to participate in the ORDINAL project, Verisign had no intent of using the ORDINAL dataset for commercial purposes. We only intended on using the telemetry of the ORDINAL project to expand on previous theories as to why and how names are leaked into the public DNS. Our expectation is that, as provider of the dataset to IMPACT, JAS Advisors understood this commitment and our non-commercial intent.
>
> This is the same commitment we’ve demonstrated in our research on the name collision problem, where we’ve regularly made the results of our internal research available to the public, as evidenced by the publication list below. Indeed, the value of this analysis was referenced in JAS Advisors’ report to ICANN on the name collision problem, which acknowledges Verisign:
>
> “for extensive and insightful public comments, valuable interaction with the JAS team throughout our study, and for their overall leadership on this issue including hosting the Workshop and Prize on Root Causes and Mitigation of Name Collisions (WPNC) in London”.
>
> Our surprise and disappointment come from the sudden change of the view of our intent — which from reviewing the chronology appears to a response to our decision not to support the ORDINAL dataset at this time, rather than any change in our approach.
>
> -- Burt
>
> Verisign Name Collision Publications
> US-CERT WPAD Name Collision Vulnerability
> Client-side Name Collision Vulnerability in the New gTLD Era: A Systematic Study (Appearing in ACM Conference on Computer and Communications Security, CCS, 2017)
> MitM Attack by Name Collision: Cause Analysis and WPAD Vulnerability Assessment in the New gTLD Era (Appearing in IEEE Security and Privacy 2016)
> Enterprise Remediation for WPAD Name Collision Vulnerability
> Focused Analysis of .CBA Queries
> RFC 8023: Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions
> New gTLD Security, Stability, Resiliency Update: Exploratory Consumer Impact Analysis
> Difference Between Apples and Oranges (Regarding name collisions in new gTLDs versus in .com and other existent top level domains)
> New gTLD Security and Stability Considerations (PDF)
> Analysis Techniques for Determining Cause and Ownership of DNS Queries
> The Effectiveness of Block Lists in Preventing Collisions
> What's in a Name (Collision): Modeling and Quantifying Collision Potential
> Detecting Search Lists in Authoritative DNS
>
>
>> -----Original Message-----
>> From: Jeff Schmidt <jschmidt at jasadvisors.com>
>> Sent: Wednesday, May 02, 2018 10:22 AM
>> To: Kaliski, Burt <bkaliski at verisign.com>
>> Cc: Kane, Pat <pkane at verisign.com>; McPherson, Danny
>> <dmcpherson at verisign.com>
>> Subject: [EXTERNAL] Re: Operational Research Data from Internet NAmespace
>> Logs (ORDINAL) Dataset
>> Thanks gents for discussing. Admittedly this is a surprising and disappointing
>> position Verisign has taken in not supporting this public service.
>> After speaking with the owner of corp.com, he has decided to not make the
>> data available to Verisign.
>> Thank you,
>> Jeff
>> -----Original Message-----
>> From: "Kaliski, Burt" <bkaliski at verisign.com>
>> Date: Thursday, April 12, 2018 at 5:57 PM
>> To: Jeff Schmidt <jschmidt at jasadvisors.com>
>> Cc: Pat Kane <pkane at verisign.com>, "McPherson, Danny"
>> <dmcpherson at verisign.com>
>> Subject: RE: Operational Research Data from Internet NAmespace Logs
>> (ORDINAL) Dataset
>> Hi Jeff --
>> We've made the rounds and maintain the same position as previously: to the
>> extent the resource is openly available to the research community, we'll
>> consider it as a data source, but we're not ready otherwise to be any more
>> involved than that.
>> Along these lines, one of Verisign's researchers has recently put in a request
>> for access to the data.
>> I won't be at RSA this year, but will let Pat / Danny reply separately as to
>> their plans / availability.
>> Thanks for providing us another opportunity to consider corp.com.
>> -- Burt
>> > -----Original Message-----
>> > From: Jeff Schmidt [mailto:jschmidt at jasadvisors.com]
>> > Sent: Wednesday, April 11, 2018 12:16 PM
>> > To: Kaliski, Burt <bkaliski at verisign.com>
>> > Cc: Kane, Pat <pkane at verisign.com>; McPherson, Danny
>> > <dmcpherson at verisign.com>
>> > Subject: [EXTERNAL] Re: Operational Research Data from Internet
>> NAmespace
>> > Logs (ORDINAL) Dataset
>> >
>> >
>> > Thanks, look forward to chatting soon!
>> >
>> > Unrelated, will anyone be at RSA next week? I'll be passing through
>> > Sunday -
>> > Tuesday if anyone wants to link-up. (m) 614-218-5412.
>> >
>> > Thx,
>> > Jeff
>> >
>> >
>> > -----Original Message-----
>> > From: "Kaliski, Burt" <bkaliski at verisign.com>
>> > Date: Thursday, April 5, 2018 at 5:41 PM
>> > To: Jeff Schmidt <jschmidt at jasadvisors.com>
>> > Cc: Pat Kane <pkane at verisign.com>, "McPherson, Danny"
>> > <dmcpherson at verisign.com>
>> > Subject: RE: Operational Research Data from Internet NAmespace Logs
>> > (ORDINAL) Dataset
>> >
>> > Hi Jeff --
>> >
>> > It's good to hear from you again. I appreciate your following up on
>> > this
>> > opportunity. Let me synch with Pat on this (we may reach out to Danny
>> > as
>> > well), and one of us will get back to you shortly.
>> >
>> > -- Burt
>> >
>> > > -----Original Message-----
>> > > From: Jeff Schmidt [mailto:jschmidt at jasadvisors.com]
>> > > Sent: Wednesday, April 04, 2018 10:45 AM
>> > > To: Kaliski, Burt <bkaliski at verisign.com>; Kane, Pat
>> > <pkane at verisign.com>
>> > > Subject: [EXTERNAL] Operational Research Data from Internet
>> NAmespace
>> > Logs
>> > > (ORDINAL) Dataset
>> > >
>> > >
>> > > Hi Burt, Pat:
>> > >
>> > > Hope you gents are well! Sorry in advance for (another) conversation
>> > about
>> > > collisions and corp.com!
>> > >
>> > > Short version: As you know, Mike O'Connor wants to sell corp.com. I
>> > > probably
>> > > have an unhealthy amount of benevolent energy to "preserve" corp.com
>> > for
>> > > good purposes. I worked a deal where DHS provided some funds to
>> > license
>> > > corp.com from Mike; JAS is donating the rest of the resources to run
>> > the
>> > > Operational Research Data from Internet NAmespace Logs (ORDINAL)
>> > Dataset
>> > > and associated processes.
>> > >
>> > > https://impactcybertrust.org/dataset_view?idDataset=794
>> > >
>> > > http://ordinal.jasadvisors.com
>> > >
>> > > corp.com is in there along with roughly 50 other domains we've
>> > identified as
>> > > colliding and purchased on the open market.
>> > >
>> > > So. I'd like to ask for Verisign's help with ORDINAL. JAS is
>> > currently
>> > > donating
>> > > time and resources for this. DHS provided a small grant to license
>> > corp.com
>> > > from Mike O'Connor because I fear he will sell corp.com if we don't
>> > keep
>> > him
>> > > interested, and we'll then lose the name forever. From a JAS
>> > perspective,
>> > > I'd like
>> > > to keep this going and continue purchasing/licensing interesting
>> > colliding
>> > > names
>> > > into ORDINAL and make the data available to researchers. It's
>> > currently a
>> > > money-losing endeavor for JAS - a "public service" if you will ;-)
>> > I've
>> > > asked
>> > > ICANN for some assistance but money is very tight over there right
>> > now.
>> > The
>> > > corp.com data and collisions data in general will start to become more
>> > > valuable
>> > > to the ICANN community given the current SSAC tasking on
>> > corp/home/mail
>> > > obviously and the possibility of a second round. I'd hate to see it
>> > > disappear right
>> > > when the data could become useful to the Internet.
>> > >
>> > > I'd like to ask for Verisign's help with ORDINAL. Can we setup a
>> > short chat
>> > > sometime soon?
>> > >
>> > > Thanks!
>> > > Jeff
>> > >
>> > >
>> > >
>> >
>
>
> ORIGINAL EMAIL FROM MATT LARSON TO NCAP-DISCUSS:
>
> On 2020-02-05 02:01, Matt Larson wrote:
>>> On Jan 29, 2020, at 3:48 PM, Rubens Kuhl <rubensk at nic.br> wrote:
>>> I was under the impression that corp.com [1] was now part of
>>> ORDINAL, but the fact that it's for sale for USD 1.7 Mi goes against
>>> that assumption
>>> Perhaps Jeff (JAS) could clarify it.
>> Jeff Schmidt sent the text below to clarify the situation with
>> corp.com [5]. Please also see the attached PowerPoint presentation.
>> Matt
>>> Begin forwarded message:
>>> FROM: Jeff Schmidt <jschmidt at jasadvisors.com>
>>> SUBJECT: [EXT] FOR POSTING TO THE NACP LIST
>>> DATE: February 4, 2020 at 12:29:18 PM EST
>>> TO: David Conrad <david.conrad at icann.org>, Matt Larson
>>> <matt.larson at icann.org>
>>> Hia gents:
>>> I hear that there was an inquiry about corp.com [1] by the NCAP;
>>> please feel free to publish the below response _in its entirety_.
>>> It is good to have this history a part of “the record.” You may
>>> post/share this as you see fit. Thanks!
>>> Corp.com [1] has been owned by Mike O’Connor for just under
>>> forever. Mike recognizes that corp.com [1] is unique and he has
>>> graciously made data available to a number of researchers –
>>> including JAS – over the years in the best interest of the
>>> Internet. The corp.com [1] data – and the understanding of the
>>> underlying phenomena driving the traffic – contributed materially
>>> to the JAS collisions work/reports and to our discovery of MS15-011
>>> thru 014 (CVE-2015-0008) as well as vulnerabilities JAS discovered
>>> and privately reported to PeopleSoft/Oracle, Symantec, Trend Micro,
>>> and IBM.
>>> Through Mike’s quiet generosity, the Internet is a safer place
>>> today.
>>> My interest, as a security professional, is that corp.com [1]
>>> remain in “responsible hands.” There remains significant danger
>>> if corp.com [1] becomes controlled by an “irresponsible” party.
>>> I have tried for years to get “responsible parties” interested
>>> in acquiring corp.com [1] – including several firms on this list
>>> – however none have expressed interest. Fortunately, the US
>>> Department of Homeland Security (DHS) stepped-up – the *ONLY*
>>> party to do so I might add – and provided a small grant for JAS to
>>> lease corp.com [1] from Mike, collect data, and make it available to
>>> qualified researchers. During the years corp.com [1] was delegated
>>> to JAS, we spent far more money hosting, collecting, and storing
>>> data than we ever got from grants. No one except the US DHS
>>> expressed any willingness to help. My understanding is that ICANN
>>> wrote letters to Microsoft, Verisign, and other relevant parties
>>> informing them of these issues, but they did not engage. I tried to
>>> engage Microsoft at a number of levels, but they were not
>>> interested.[1] JAS got poor and Mike sat on a valuable asset for
>>> years in the altruistic interest of global Internet SSR.
>>> A few months back, Mike and I concluded that we have done
>>> everything we can do; with Mike not getting any younger, he would
>>> sell the domain with a clear conscience. JAS has no further
>>> business relationship with Mike or corp.com [1] and we are no longer
>>> technically hosting the domain.
>>> I have attached a technical presentation I gave to IMPACT
>>> researchers in 2018. It contains more technical information about
>>> the traffic observed at corp.com [1] and some cool “DITL”
>>> statistics.
>>> A few high level observations during the 8-month period 2019-01-24
>>> - 2019-09-18:
>>> * 384,001 unique client IPs sent queries to corp.com [1]. These
>>> clients are almost all recursives ranging from gigantic public
>>> recursives (Google, OpenDNS) to private recursives run by companies
>>> ranging from SMBs to large multi-nationals.
>>> * 37,046,965 unique qnames were sent to corp.com [1]. A plurality
>>> of these qnames are related to Microsoft technologies, particularly
>>> Active Directory. A subset of these are exploitable by techniques
>>> similar to MS15-011 thru 014 and trivially exploitable using
>>> well-known tools like Responder/SMB-Relay[2].
>>> * For additional perspective, in one month, the HTTP/S website JAS
>>> ran at corp.com [1] received requests from 379,403 unique clients
>>> for WPAD configuration files. Note these are IP addresses of
>>> specific end machines received over HTTP/S, not DNS recursive
>>> servers as above. Therefore, this is one of several long- lived
>>> target lists of almost certainly vulnerable Microsoft Windows
>>> machines. Another party made a big deal about purely theoretical
>>> WPAD vulnerabilities in the new gTLD space a few years back;
>>> colliding WPAD queries are much more common and much more dangerous
>>> in .com than in any other namespace just given the size and gravitas
>>> of .com. Want an instant foothold into about 30 of the world’s
>>> largest companies according to the Forbes Global 2000? Control
>>> corp.com [1]. Anyone claiming namespace collisions in .com, country
>>> code, and other legacy TLD space aren’t dangerous just doesn’t
>>> understand – or doesn’t want to understand.
>>> * JAS temporarily created MX records and accepted email destined to
>>> corp.com [1]. After about an hour we received in excess of 12
>>> million emails and discontinued the experiment. While the vast
>>> majority of the emails were of an automated nature, we found some of
>>> the emails to be sensitive and thus destroyed the entire corpus
>>> without further analysis.
>>> * JAS temporarily accepted protocol level connections to SMB/CIFS
>>> and WebDAV over HTTP/S (!!) and found a large number of dangerous
>>> connections requesting \\SYSVOL [2], \\NETLOGON [3], \\USER [4], and
>>> other dangerous Microsoft mount points directly exploitable by the
>>> techniques described in MS15-011 thru 014. We discontinued the
>>> experiment after 15 minutes and destroyed the data. It was
>>> terrifying. A well-known offensive tester that consulted with JAS
>>> on this experiment remarked that during the experiment it was
>>> “raining credentials” and that “he’d never seen anything
>>> like it.”
>>> * Microsoft incorrectly claims these issues are resolved. Unless
>>> administrators overtly enable SMB Signing (via a new feature called
>>> “UNC Path Hardening” which they added as a response to our
>>> bugs), most modern, fully-patched Windows machines remain
>>> vulnerable.[3]
>>> Someone will eventually purchase corp.com [1]. I sincerely hope
>>> the acquiring party is “responsible.” Once it’s lost, it’s
>>> gone forever.
>>> Jeff Schmidt
>>> [1] Microsoft Windows product groups acted honorably upon our
>>> reporting of the vulnerabilities and responded appropriately;
>>> however, other parts of the company were not interested in
>>> discussing corp.com [1].
>>> [2] https://github.com/lgandx/Responder
>>> [3]
>> https://security.stackexchange.com/questions/134388/how-does-unc-path-hardening-and-smb-signing-work-under-the-hood
>> Links:
>> ------
>> [1] http://corp.com/
>> [2] file:////SYSVOL
>> [3] file:////NETLOGON
>> [4] file:////USER
>> [5] http://corp.com
>> _______________________________________________
>> NCAP-Discuss mailing list
>> NCAP-Discuss at icann.org
>> https://mm.icann.org/mailman/listinfo/ncap-discuss
>> _______________________________________________
>> By submitting your personal data, you consent to the processing of
>> your personal data for purposes of subscribing to this mailing list
>> accordance with the ICANN Privacy Policy
>> (https://www.icann.org/privacy/policy) and the website Terms of
>> Service (https://www.icann.org/privacy/tos). You can visit the Mailman
>> link above to change your membership status or configuration,
>> including unsubscribing, setting digest-style delivery or disabling
>> delivery altogether (e.g., for a vacation), and so on.
>
> _______________________________________________
> NCAP-Discuss mailing list
> NCAP-Discuss at icann.org
> https://mm.icann.org/mailman/listinfo/ncap-discuss
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/ncap-discuss/attachments/20200208/f5fab470/signature-0001.asc>
More information about the NCAP-Discuss
mailing list