[NCAP-Discuss] [Ext] Revised draft of NCAP Study 1 report
Jeff Schmidt
jschmidt at jasadvisors.com
Sun Feb 9 01:41:42 UTC 2020
[I seem to be read-only on the NACP list. I filled-out the SOI last week but it may not be through yet. If this doesn't hit the list could you forward please? Thanks!]
Hia Danny:
Everything in that email is correct, of course. A bit of “color” since we’re assembling historical data “for the record” at this point:
(1) I haven’t been (at all!) shy about asking folks for help with corp.com. My stated purpose is to provide Mike “responsible options” for disposing of his strange and valuable asset. Sadly, I have not been successful. Yes, I absolutely asked Verisign, Microsoft, and a dozen others whom I thought may care about internet security and the Greater Good. Yes, I certainly was “surprised and disappointed” that Verisign, Microsoft, and others showed no interest in those things. But that is their right as much as it is Mike's right to dispose of his asset in any way he chooses.
(2) Yes, Verisign's access request to ORDINAL data was denied. It took several weeks to revert because there were a number of substantial discussions about Verisign's request. It was not done lightly. There were two reasons the request was denied:
(a) The DHS funds were specified for non-commercial use; as stated in VRSN's 10Q: "We are a global provider of domain name registry services and internet infrastructure, enabling internet navigation for many of the world’s most recognized domain names..." Purely on a prima facie basis, it is hard to square that with non-commercial use of a DNS dataset. All of the other requesters were Universities. This was a clear case of "which one is not like the other."
(b) I have worked with various parts of the US Government for nearly 30 years. Think what you will to about the USG, nearly every USG employee I have dealt with is honorable and genuinely concerned about the efficient use of taxpayer dollars. Serious concerns were discussed about providing Verisign - a gigantic for-profit corporation - with data that was subsidized by taxpayer dollars. Especially since Verisign had just a few weeks earlier declared they had zero interest in the data. Some referred to that as an attempt to "freeload."
At this point, I realized we were just too far apart so I ceased communications with Verisign.
Below Burt's 2018 email to me that Danny forwarded is a detailed thread of my communication with Verisign on this matter. I would encourage members of this list to read the entire thread to better understand what transpired.
Thanks,
Jeff
On 2/8/20, 4:40 PM, "NCAP-Discuss on behalf of Danny McPherson" <ncap-discuss-bounces at icann.org on behalf of 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: smime.p7s
Type: application/pkcs7-signature
Size: 4350 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ncap-discuss/attachments/20200209/55aa56cf/smime-0001.p7s>
More information about the NCAP-Discuss
mailing list