[Cscwg-public] Final CSCWG meeting minutes March 11, 2021

Dean Coclin dean.coclin at digicert.com
Thu Mar 25 16:57:46 UTC 2021


Here are the final minutes of the subject meeting:

 

Attendees:

 

Atsushi Inaba

Bruce Morton

Chris Kemmerer

Corey Bonnell

Daniela Hood

Dimitris Zacharopoulos

Ian McMillan

Mario Vuksan (guest)

Sebastian Schulz

Tim Crawford

Tim Hollebeek

Tomas Gustavsson

Tomislav Pericin (guest)

 

Bruce read the antitrust statement.

 

Group agreed to not approve previous meeting's minutes until next meeting as
they were just sent to the management list on Tuesday.

 

Ian: Mario will be presenting a follow-up to his previous presentation from
last time. Information-sharing to mitigate against attackers CA-hopping and
abuse of code signing certificates. Tomislav will be joining Mario today to
present his research on the abuse of code-signing and what possibilities we
have to leverage this information.

 

Mario: Let's go deeper into the data that we have. This also boils down into
the interactions at the end, such as malicious files that were signed by a
stolen certificate. There's things here beyond the signing process, such as
tricking the software validators. We will be presenting breakdowns in terms
of malware type and geographic distribution.

 

Tomislav: We collect many files and our static analysis tooling analyzes
them. Classified more than 10 billion binaries to date. Saw over 200k unique
code-signing digital certs. Authenticode signatures mainly, but also others
such as Android. We break down the categories based on malware type and how
often each type of malware is signed. People are more likely to click if
Smartscreen shows a real-sounding org name. Attackers may sign a bunch of
benign binaries to have users not encounter Smartscreen prompts.

Sebastian: Where do you get the definitions for the various categories of
malware?

Tomislav: Our naming scheme tends to align with AV vendor naming and
classification. There are sometimes multiple threat types within a single
binary. Labelling that is a challenge, but what we generally do is choose
the most dangerous classification.

Tim: What are the trends over time?

Tomislav: A few years ago there were only a few types of ransomware, now
there's hundreds.

Mario: Ransomware is being commercialized. Full organizations are being
setup with HR, CEO, etc. that ransom companies. We have had a problem with
well-funded organizations that appear to be real companies that ransom.

Tomislav: I wrote a blog about how you can impersonate an applicant when
applying for a certificate. Here is a breakdown of top countries where
signed malware is from. US and Russia are top regions.

Tomas: Are these tracked to issuance, or are malware being signed by stolen
certs?

Tomislav: We don't see a lot of stolen certs in use, but rather impersonated
companies. It's possible to get EV CS certs from an impersonated company.
Currently tracking one malware group. We're searching for a good model for
how we can share information about malware

Sebastian: In the case of private key compromise, it may hurt software
publishers if the CS cert is revoked. Definitely need a good mechanism for
information-sharing.

Tim H: There was in fact an CABF WG about this topic 5 years ago. There's a
lot of complicated legal issues when you try to do info sharing. The
consensus ended up being that we continue to use the cert problem report
format. If you suspect that one is being misused, please report to CAs. In
most cases you will not have trouble proving misuse. I would not rely on
keyCompromise CRL reason codes as evidence on whether a key was actually
compromised.

Dimitris: We already have the policy where an App Software Supplier can ask
for a specific cert to be revoked. Like Tim said, every CA must have a CPR
mechanism. you can report these compromised certs. As part of the research,
it would be useful to track responsiveness of CAs to problem reports. If we
can determine the date of compromise, we can backdate the revocation. 

Tomislav: We see that the revocation is commonly backdated to the date of
issuance.

Tim H: Sometimes we backdate to when the malware signing date, or when we
think the compromise occurred. The revocation dates are carefully
considered.

Tomislav: That is what we see. One complicated case now is Solarwinds or
Adobe.

Ian: Regarding having a correlation of Server using CA 1 and then CA2 certs,
do malware actors switch after revocation? 

Tomislav: they aren't concerned about the specific CA. They only care about
if it's trusted. They buy off the black market; they just want something
that works. First, they sign a bunch of benign files to build reputation. 

Bruce: In the black market, are there two parties involved? One party gets
legitimate certs then sells them? 

Tomislav: No, generally attackers scrape info and register companies. Then
they buy using that info. Then they sell the cert from a premium.

Ian: For a standard OV CS cert with 0 reputation vs. EV with reputation is
worth less (pricing tier)

Tomislav: We have a feed that lists when a cert is first used

Bruce: We're trying to find a way for CAs to take care of high risk cert
issuance. A lot of cases here that irrespective of issuance, malware is
signed. the issuance happened; is there a process for CAs to search to find
certs that signed malware? Or, you could tell us that it signed malware? We
need to gather the names of the black market certs and block them. But does
that help? Black market can just keep getting new names.

Ian: It would be interesting to know how many names are recycled. Another
thing mentioned was heuristics, such as how likely a cert is fraudulent.

Bruce: This is good data, we need to think more about the right questions to
ask. Are there any changes we need to make to BRs to integrate? Two
integration points: high risk requests or revocation

Ian: I'm interested what Tim brought up about the learnings for the previous
WG. This data looks very powerful. Not sure if we want to mandate its use in
the CSBR, but are there vulnerabilities in the validation practices that
this data can inform?

Dimitris: There are a collection of reporting mechanisms in CCADB. The next
useful step is to be reported more easily. From a CSBR standpoint, we could
mandate disclosure.

Bruce: If I can search continually and address problems vs. having others
notify us. 

Ian: You may actually want to go both ways. I may want to monitor my own
business and certs I've issued. What Dimitris said is also valuable so
researchers can more easily notify CAs.

Dimitris: Or even MSFT itself can exercise its ability to directly notify
CAs of fraudulent certs.

Ian: Individually, as MSFT, this is important data that we can use to
monitor on our own.

Bruce: In a lot of cases, it's your own users that get the benefit. If
there's 10,000 different certs that are abusive, it's a big job for
researchers to notify many CAs.

Ian: When you see malware families affecting a broad userbase, we need to be
pulling all the levers to protect the ecosystem.

Dimitris: Even if there's just 1 file that is malicious, it's signed by just
1 CA. 

Bruce: Dimitris, on your comment about how the CSBR can specify how people
can contact CAs to notify, we already do that in the CPS. Or we can mandate
a separate reporting address just for code signing.

Ian: Do you have data on TLS?

Tomislav: we only have code signing. It's an interesting cross-point. There
are tools that clone TLS certs into codesigning certs. If I was doing a
search of certs, I might find a self-signed "cloned" codesigning cert with
google.com's public key.

Bruce: With 10 minutes left, let's follow up again next meeting.

 

Tomas's presentation will be moved to April.

 

Bruce: Let's take a few minutes to discuss the proposed ballots.

Ian: The first ballot I sent out is about OCSP and TSR max validity.
Dimitris brought up max validity restrictions for Oracle JRE timestamping.
I'm ok holding off on max validity change, but going ahead with OCSP
changes. I'm contacting Oracle directly as well as experimenting myself.

Bruce: That's a good approach since the two topics aren't related.

Dimitris: I also sent a follow-up regarding the appendix. I was also
wondering about the requirement for 10 years after expiration of ICA.

Ian: That requirement is there to keep track of revocations.

Bruce: Can we issue last CRLs?

Dimitris: We do issue last CRLs because we believe you should not use the
private key after CA expiration.

Bruce: For subscriber key protection, we need to make sure CC EAL is listed
in EV CS key protection.

Ian: That's a quick change. I also like the renumbering that you proposed. I
can do this change under CSC-6. Or should I combine with OCSP ballot?

Bruce: It doesn't feel controversial to put it in. I don't object to being
in the CRL/OCSP ballot.

Dimitris: Since we're doing editorial changes, there's a problem in section
15 item 9.

Ian: I can fix that too.

 

Bruce: Looking forward to Ian's ballot updates. Next meeting is March 25th.

 

Meeting adjourned.

 

 

Corey Bonnell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210325/1eb40573/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4916 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210325/1eb40573/attachment-0001.p7s>


More information about the Cscwg-public mailing list