Re: DNS fragmentation attack subverts DV, 5 public CAs vulnerable

2018-12-11 Thread Leo Grove via dev-security-policy
On Tuesday, December 11, 2018 at 11:27:52 AM UTC-6, Hector Martin 'marcan' 
wrote:
> On 12/12/2018 01.47, Ryan Sleevi via dev-security-policy wrote:
> > Is this new from the past discussion?
> 
> I think what's new is someone actually tried this, and found 5 CAs that
> are vulnerable and for which this attack works in practice.
> 
> > https://groups.google.com/d/msg/mozilla.dev.security.policy/KvQc102ZTPw/iLQLKfbbAwAJ
> 
> Looking back, this attack is also documented in the paper linked in that
> thread, but unfortunately it's not open access. I get the feeling this
> may be why that discussion didn't really proceed further in that thread.
> I certainly missed it.
> 
> The paper does list the vulnerable CAs, which are:
> 
> > • COMODO, InstantSSL, NetworkSolutions, SSL.com: these CAs
> > use the same MX email server mcmail1.mcr.colo.comodo.net
> > which uses the same caching DNS resolver. The results from our
> > cache overwriting methods indicates that the DNS resolver software
> > is New BIND 9.x with DNSSEC-validation.

I want to clarify that the only DNS mappings to Comodo from SSL.com are crl and 
crt CNAMEs for UserTrust issued SSL.com SubCAs operated and maintained wholly 
by Sectigo. 

The SSL.com Root CA, which is operated and maintained by SSL.com, does not have 
any dependency on the Comodo/Sectigo DNS and therefore should not be listed as 
one of the vulnerable CAs.

Regards,

Leo Grove
SSL.com
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: SSL private key for *.alipcsec.com embedded in PC client executables

2018-12-11 Thread Matt Palmer via dev-security-policy
On Tue, Dec 11, 2018 at 08:00:59AM +, Jeremy Rowley via dev-security-policy 
wrote:
> I think pretty much every ca will accept a signed file in lieu of an
> actual key.

You'd rather hope so.  If there are any CAs out there who *wouldn't* accept
a signature from the private key as proof of compromise it would be
interesting to hear from them as to why they don't believe that constitutes
proof of compromise.

> Generally provide the key just means some proof of compromise the ca can
> replicate.

Indeed.  The disagreement is around what constitutes "proof" and how much
effort the CA is willing to go to to perform the replication.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


RE: Maximal validity of the test TLS certificate issued by a private PKI system

2018-12-11 Thread Doug Beattie via dev-security-policy

Option 1 is the intended interpretation.  We specified 30 days because the
tokens used for domain validation (Random Number) need to have a useful life
of 30 days.  The 30-day usage period needed to be put into the definition of
the Test Certificate, or into Method 3.2.2.4.9, and we selected the validity
period as the means to convey this requirement.

Note that Method 9 has identified security issues as it relates to shared IP
addresses, so currently it's not permitted to be used (according to Google),
even though it remains in the BRs.  It should be updated or removed.  Method
10 has similar issues which are being mitigated with ALPN approach, but no
work has been done on Method 9 in this regard.

Doug


-Original Message-
From: dev-security-policy  On
Behalf Of Sándor dr. Szoke via dev-security-policy
Sent: Tuesday, December 11, 2018 1:24 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Maximal validity of the test TLS certificate issued by a private
PKI system


It is not absolutely clear for us how to manage the test certificates which
were issued by a CA where there are no certificate chains to a root
certificate subject to the Baseline Requirements (for example an independent
test CA hierarchy).

The BR wording is as follows:

Test Certificate: A Certificate with a maximum validity period of 30 days
and which: (i) includes a critical extension with the specified Test
Certificate CABF OID (2.23.140.2.1), or (ii) is issued under a CA where
there are no certificate paths/chains to a root certificate subject to these
Requirements.


I can interpret the definition in two different ways:

1. by using the listing as a parenthesis, so

Test Certificate: 
A Certificate
{with a maximum validity period of 30 days} AND
which: 
{
(i) includes a critical extension with the specified Test Certificate CABF
OID (2.23.140.2.1), OR
(ii) is issued under a CA where there are no certificate paths/chains to a
root certificate subject to these Requirements.
}

So it means that any test certificate shall have the validity max. 30 days,
AND we have two possibilities:
(i) if the test certificate issued under a CA where there is a certificate
chain to a root certificate subject to the BR, then the test certificate
shall include the critical extension with the specified Test Certificate
CABF OID (2.23.140.2.1)
(ii) if the test certificate is issued under a CA where there are no
certificate chains to a root certificate subject to the BR, then there is no
further requirement.

Question:

if this interpretation is correct, then why do we have a requirement to
limit the validity period of the test certificate for 30 days, if the issuer
CA is out of the scope of the BR?



2. by thinking as an engineer, where the AND operation is higher level than
the OR, the separation looks like this:

Test Certificate: 
A Certificate
{
with a maximum validity period of 30 days AND
which: 
(i) includes a critical extension with the specified Test Certificate CABF
OID (2.23.140.2.1), } OR {
(ii) is issued under a CA where there are no certificate paths/chains to a
root certificate subject to these Requirements.
}

So it means, that
(i) if the test certificate issued under a CA where there is a certificate
chain to a root certificate subject to the BR, then the test certificate
shall include the critical extension with the specified Test Certificate
CABF OID (2.23.140.2.1) AND the validity period of the test certificate is
maximum 30 days
(ii) if the test certificate is issued under a CA where there are no
certificate chains to a root certificate subject to the BR, then there is no
any further requirement

In this interpretation the wording seems to be strange, but the requirement
seems to be more realistic and clear.

Which interpretation is correct?

Is it allowed to issue test TLS certificates in an independent test system
with more than 30 days validity?


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Maximal validity of the test TLS certificate issued by a private PKI system

2018-12-11 Thread Sándor dr . Szőke via dev-security-policy


It is not absolutely clear for us how to manage the test certificates which 
were issued by a CA where there are no certificate chains to a root certificate 
subject to the Baseline Requirements (for example an independent test CA 
hierarchy).

The BR wording is as follows:

Test Certificate: A Certificate with a maximum validity period of 30 days and 
which: (i) includes a critical
extension with the specified Test Certificate CABF OID (2.23.140.2.1), or (ii) 
is issued under a CA where there
are no certificate paths/chains to a root certificate subject to these 
Requirements.


I can interpret the definition in two different ways:

1. by using the listing as a parenthesis, so

Test Certificate: 
A Certificate 
{with a maximum validity period of 30 days}
AND 
which: 
{
(i) includes a critical extension with the specified Test Certificate CABF OID 
(2.23.140.2.1), 
OR
(ii) is issued under a CA where there are no certificate paths/chains to a root 
certificate subject to these Requirements.
}

So it means that any test certificate shall have the validity max. 30 days, 
AND 
we have two possibilities:
(i) if the test certificate issued under a CA where there is a certificate 
chain to a root certificate subject to the BR, then the test certificate shall 
include the critical extension with the specified Test Certificate CABF OID 
(2.23.140.2.1)
(ii) if the test certificate is issued under a CA where there are no 
certificate chains to a root certificate subject to the BR, then there is no 
further requirement.

Question:

if this interpretation is correct, then why do we have a requirement to limit 
the validity period of the test certificate for 30 days, if the issuer CA is 
out of the scope of the BR?



2. by thinking as an engineer, where the AND operation is higher level than the 
OR, the separation looks like this:

Test Certificate: 
A Certificate 
{
with a maximum validity period of 30 days 
AND 
which: 
(i) includes a critical extension with the specified Test Certificate CABF OID 
(2.23.140.2.1), 
}
OR
{ 
(ii) is issued under a CA where there are no certificate paths/chains to a root 
certificate subject to these Requirements.
}

So it means, that 
(i) if the test certificate issued under a CA where there is a certificate 
chain to a root certificate subject to the BR, then the test certificate shall 
include the critical extension with the specified Test Certificate CABF OID 
(2.23.140.2.1) AND the validity period of the test certificate is maximum 30 
days
(ii) if the test certificate is issued under a CA where there are no 
certificate chains to a root certificate subject to the BR, then there is no 
any further requirement

In this interpretation the wording seems to be strange, but the requirement 
seems to be more realistic and clear.

Which interpretation is correct?

Is it allowed to issue test TLS certificates in an independent test system with 
more than 30 days validity?


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: DNS fragmentation attack subverts DV, 5 public CAs vulnerable

2018-12-11 Thread Hector Martin 'marcan' via dev-security-policy
On 12/12/2018 01.47, Ryan Sleevi via dev-security-policy wrote:
> Is this new from the past discussion?

I think what's new is someone actually tried this, and found 5 CAs that
are vulnerable and for which this attack works in practice.

> https://groups.google.com/d/msg/mozilla.dev.security.policy/KvQc102ZTPw/iLQLKfbbAwAJ

Looking back, this attack is also documented in the paper linked in that
thread, but unfortunately it's not open access. I get the feeling this
may be why that discussion didn't really proceed further in that thread.
I certainly missed it.

The paper does list the vulnerable CAs, which are:

> • COMODO, InstantSSL, NetworkSolutions, SSL.com: these CAs
> use the same MX email server mcmail1.mcr.colo.comodo.net
> which uses the same caching DNS resolver. The results from our
> cache overwriting methods indicates that the DNS resolver software
> is New BIND 9.x with DNSSEC-validation.
> • Thawte, GeoTrust, RapidSSL: use the same MX server and
> resolution platform.
> • StartCom4
> , StartSSL: both use the same email server and the
> same DNS resolver.
> • SwissSign: uses New BIND 9.x

> I think we're at the stage where it's less about a call to abstract action,
> and actually requires specific steps being taken, by CAs, to explore and
> document solutions. Saying "push for DNSSEC" doesn't actually lead to
> objective threat analysis' and their mitigations.

My last paragraph was intended as two separate statements; DNSSEC solves
this problem but we can't magically flip a switch and make everyone do
that (heck, my own TLD's registrar still doesn't support it, and yes,
I've been pestering them about it). Given that, I think CAs should be
required to implement practical mitigations against this particular
attack, and I'm hoping that by pointing this out we can start a
discussion about what those mitigations should look like :-)

As you've noted, Let's Encrypt seems to be leading on this front. It
would be interesting to see if any other CAs can document their approach
to mitigating this issue, if any.

-- 
Hector Martin "marcan" (mar...@marcan.st)
Public Key: https://mrcn.st/pub
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: DNS fragmentation attack subverts DV, 5 public CAs vulnerable

2018-12-11 Thread Ryan Sleevi via dev-security-policy
On Tue, Dec 11, 2018 at 11:34 AM Hector Martin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I figured this presentation might be of interest to this list:
>
>
> https://i.blackhat.com/eu-18/Thu-Dec-6/eu-18-Heftrig-Off-Path-Attacks-Against-PKI.pdf
>
> It seems they found 5 (unspecified) public CAs out of 17 tested were
> vulnerable to this attack, which can be performed by an off-path attacker.
>
> The TL;DR is you can force fragmentation by spoofing ICMP fragmentation
> needed packets, and then cause the DNS answer to be split into two
> fragments, one with all the actual anti-spoofing relevant information
> (TXID, UDP source port, etc), and one with the actual DNS answer data of
> interest. Then all you have to do is guess the IPID and keep the UDP
> checksum valid, both of which are practical, and you can spoof the
> second fragment with whatever you want.
>
> Yet another reason to push for DNSSEC everywhere (and pervasive use of
> CAA records to reduce attack surface). This is scary enough I think CAs
> should be required to implement practical mitigations.
>

Is this new from the past discussion?
https://groups.google.com/d/msg/mozilla.dev.security.policy/KvQc102ZTPw/iLQLKfbbAwAJ

There's also other discussions, such as
https://groups.google.com/d/msg/mozilla.dev.security.policy/ydxiw3S3gSw/Q0CpD8zlBQAJ
,
https://groups.google.com/d/msg/mozilla.dev.security.policy/84lxLwhaHPQ/KSsjk-JVAwAJ
,
https://groups.google.com/d/msg/mozilla.dev.security.policy/2teeVLJ44RM/Yqk5GHSpCQAJ

I think we're at the stage where it's less about a call to abstract action,
and actually requires specific steps being taken, by CAs, to explore and
document solutions. Saying "push for DNSSEC" doesn't actually lead to
objective threat analysis' and their mitigations.

In this regard, Let's Encrypt seems to be the industry leader here - with
respect to
https://community.letsencrypt.org/t/validating-challenges-from-multiple-network-vantage-points/40955
and the aforementioned
https://community.letsencrypt.org/t/mitigating-dns-fragmentation-attack/74838

If other CAs are taking steps in this direction, and have public
documentation considering their analysis and design, that'd be extremely
useful to the community.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


DNS fragmentation attack subverts DV, 5 public CAs vulnerable

2018-12-11 Thread Hector Martin via dev-security-policy
I figured this presentation might be of interest to this list:

https://i.blackhat.com/eu-18/Thu-Dec-6/eu-18-Heftrig-Off-Path-Attacks-Against-PKI.pdf

It seems they found 5 (unspecified) public CAs out of 17 tested were
vulnerable to this attack, which can be performed by an off-path attacker.

The TL;DR is you can force fragmentation by spoofing ICMP fragmentation
needed packets, and then cause the DNS answer to be split into two
fragments, one with all the actual anti-spoofing relevant information
(TXID, UDP source port, etc), and one with the actual DNS answer data of
interest. Then all you have to do is guess the IPID and keep the UDP
checksum valid, both of which are practical, and you can spoof the
second fragment with whatever you want.

Yet another reason to push for DNSSEC everywhere (and pervasive use of
CAA records to reduce attack surface). This is scary enough I think CAs
should be required to implement practical mitigations.

Thoughts?
-- 
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: SSL private key for *.alipcsec.com embedded in PC client executables

2018-12-11 Thread Arvid Vermote via dev-security-policy
Based on the information reported in this thread GlobalSign has started the 
necessary activities to investigate this potential misuse. 

Arvid

On Tuesday, December 11, 2018 at 8:24:43 AM UTC+1, Mark Steward wrote:
> This time it's just hanging around in memory, no need to do anything
> about the anti-debug.
> 
> $ openssl x509 -noout -modulus -in 300288180.crt|md5sum
> f423a009387fb7a306673b517ed4f163  -
> $ openssl rsa -noout -modulus -in alibaba-localhost.key.pem|md5sum
> f423a009387fb7a306673b517ed4f163  -
> 
> You can verify that I've signed lorem ipsum with the following:
> 
> $ wget https://crt.sh/?d=300288180 -O 300288180.crt
> $ wget https://rack.ms/b/UsNQv74sfH40/msg.txt{,.sig-sha256.b64}
> $ openssl dgst -sha256 -verify <(openssl x509 -in 300288180.crt
> -pubkey -noout) -signature <(base64 -d msg.txt.sig-sha256.b64) msg.txt
> 
> As the domain name suggests, this is part of the
> AlibabaProtect/"Alibaba PC Safe Service" that comes bundled with the
> Youku client.
> 
> 
> Mark
> 
> 
> Mark
> On Tue, Dec 11, 2018 at 5:37 AM Xiaoyin Liu via dev-security-policy
>  wrote:
> >
> > Hello,
> >
> > I think I found a SSL certificate misuse issue, but I am not sure if this 
> > is indeed a misuse, so I want to ask about it on this list.
> >
> > Here is the issue: After I installed Youku Windows client 
> > (https://pd.youku.com/pc, installer: 
> > https://pcclient.download.youku.com/youkuclient/youkuclient_setup_7.6.7.11220.exe),
> >  it starts a local HTTPS server, listening on localhost:6691. Output of 
> > “openssl s_client -connect 127.0.0.1:6691” indicates that this local server 
> > uses a valid SSL certificate, issued to "Alibaba (China) Technology Co., 
> > Ltd.” CN=*.alipcsec.com, and issued by GlobalSign. It’s a publicly trusted 
> > OV cert, and is valid until Jan 13, 2019. Later, I found that 
> > local.alipcsec.com resolves to 127.0.0.1, and 
> > https://local.alipcsec.com:6691/ is used for inter-process communication.
> >
> > It’s clear that the private key for *.alipcsec.com is embedded in the 
> > executable, but all the executables that may embed the private key are 
> > packed by VMProtect, and the process has anti-debugging protection. I tried 
> > plenty of methods to extract the private key, but didn’t succeed. I 
> > reported this to Alibaba SRC anyway. They replied that they ignore this 
> > issue unless I can successfully extract the key.
> >
> > So is this a certificate misuse issue, even if the private key is 
> > obfuscated? If so, do I have to extract the private key first before the CA 
> > can revoke the cert?
> >
> > Thank you!
> >
> > Best,
> > Xiaoyin Liu
> >
> > Here is the certificate:
> > -BEGIN CERTIFICATE-
> > MIIHTjCCBjagAwIBAgIMCpI/GtuuSFspBu4EMA0GCSqGSIb3DQEBCwUAMGYxCzAJ
> > BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTwwOgYDVQQDEzNH
> > bG9iYWxTaWduIE9yZ2FuaXphdGlvbiBWYWxpZGF0aW9uIENBIC0gU0hBMjU2IC0g
> > RzIwHhcNMTgwMTEyMDgxMTA1WhcNMTkwMTEzMDgxMTA1WjB7MQswCQYDVQQGEwJD
> > TjERMA8GA1UECBMIWmhlSmlhbmcxETAPBgNVBAcTCEhhbmdaaG91MS0wKwYDVQQK
> > EyRBbGliYWJhIChDaGluYSkgVGVjaG5vbG9neSBDby4sIEx0ZC4xFzAVBgNVBAMM
> > DiouYWxpcGNzZWMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
> > 9PJcPzpUNRJeA8+YF8cRZEn75q+fSsWWkm6JfIlOKorYXwYJB80de4+Bia3AgzfO
> > wqwWfPGrRYh5OY4ujjsKF5XkWG22SLlzi5xB9zAeVKHYTo2U6aKrKnht9XyYvnZX
> > ocIuaSxkqq4rQ9UwiEYB6lvy8RY1orYu33HtrGD5W3w9SWf2AwB0rCNp0BeSRaGB
> > JEEXzgVECbL+deJZgZflae1gQ9q4PftDHuGXLNe8PLYq2D4+oKbYvbYtI9WKIMuh
> > 1dL70QBbcW0y4jFr2/337H8/KhBaCb3ZBZQI4LUnYL8RVeAVJFpX/PuiHMh9uNTm
> > oW1if7XQswJCWx3td5tWiwIDAQABo4ID5TCCA+EwDgYDVR0PAQH/BAQDAgWgMIGg
> > BggrBgEFBQcBAQSBkzCBkDBNBggrBgEFBQcwAoZBaHR0cDovL3NlY3VyZS5nbG9i
> > YWxzaWduLmNvbS9jYWNlcnQvZ3Nvcmdhbml6YXRpb252YWxzaGEyZzJyMS5jcnQw
> > PwYIKwYBBQUHMAGGM2h0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9nc29yZ2Fu
> > aXphdGlvbnZhbHNoYTJnMjBWBgNVHSAETzBNMEEGCSsGAQQBoDIBFDA0MDIGCCsG
> > AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAI
> > BgZngQwBAgIwCQYDVR0TBAIwADBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vY3Js
> > Lmdsb2JhbHNpZ24uY29tL2dzL2dzb3JnYW5pemF0aW9udmFsc2hhMmcyLmNybDAn
> > BgNVHREEIDAegg4qLmFsaXBjc2VjLmNvbYIMYWxpcGNzZWMuY29tMB0GA1UdJQQW
> > MBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUoIFBQJomlUEiLibD+luC
> > PKGhbykwHwYDVR0jBBgwFoAUlt5h8b0cFilTHMDMfTuDAEDmGnwwggH0BgorBgEE
> > AdZ5AgQCBIIB5ASCAeAB3gB2AN3rHSt6DU+mIIuBrYFocH4ujp0B1VyIjT0RxM22
> > 7L7MAAABYOlsKGEAAAQDAEcwRQIhANem+QHeaxpf7wmjtQe6rdbf5o/JKiM6aVgy
> > 0gnJk/UTAiBNZ0newmCtHi/f1uzmmzWNeVIl4apUko2yChwTUJObMAB1AKS5CZC0
> > GFgUh7sTosxncAo8NZgE+RvfuON3zQ7IDdwQAAABYOlsJ/wAAAQDAEYwRAIgUAxl
> > oaOwXSSPUdDmix7rwcaD2/QAiQcj0Iij14ZB5dMCIG0hAMD7iukwI28DIgy+StxR
> > 2B1LB1PLyMGa1ByTxyx6AHUAVhQGmi/XwuzT9eG9RLI+x0Z2ubyZEVzA75SYVdaJ
> > 0N0AAAFg6WwodQAABAMARjBEAiB5dRrIvSx5euaya6RItzL6bbRt4QtLj3XbrU5d
> > hpLOqgIgTTN315YeiNg+dYmtCCCU1OG56IhScJsP0Kac+JmrI98AdgDuS723dc5g
> > uuFCaR+r4Z5mow9+X7By2IMAxHuJeqj9ywAAAWDpbCrrAAAEAwBHMEUCIAvmesN/
> > F1V57QuX69pubfx7pW2tCJRHREznZOZbEniVAiEA37SmlQQYZhAUFJ02dE5SfNlE
> > 

RE: SSL private key for *.alipcsec.com embedded in PC client executables

2018-12-11 Thread Doug Beattie via dev-security-policy
Thank you for this report.  We've verified disclosure of the private key for
this certificate and have notified the customer that their certificate will
be revoked.  Due to the large customer impact, we're provided them 24 hours
to get new client executables prepared and ready for download by their
customers.  We'll post a message when the certificate has been revoked.

https://crt.sh/?id=300288180 


Doug

-Original Message-
From: dev-security-policy  On
Behalf Of Xiaoyin Liu via dev-security-policy
Sent: Tuesday, December 11, 2018 6:52 AM
To: Mark Steward 
Cc: dev-security-policy@lists.mozilla.org
Subject: Re: SSL private key for *.alipcsec.com embedded in PC client
executables

Thank you for your helpful reply, Mark! Finally I found the key in memory
too.



I sent another report with the private key to Alibaba. Hopefully they will
take actions. If Alibaba doesn't reply me tomorrow, I will report to
GlobalSign.



Best,
Xiaoyin




From: Mark Steward 
Sent: Tuesday, December 11, 2018 3:24:21 PM
To: xiaoyi...@outlook.com
Cc: dev-security-policy@lists.mozilla.org
Subject: Re: SSL private key for *.alipcsec.com embedded in PC client
executables

This time it's just hanging around in memory, no need to do anything about
the anti-debug.

$ openssl x509 -noout -modulus -in 300288180.crt|md5sum
f423a009387fb7a306673b517ed4f163  -
$ openssl rsa -noout -modulus -in alibaba-localhost.key.pem|md5sum
f423a009387fb7a306673b517ed4f163  -

You can verify that I've signed lorem ipsum with the following:

$ wget https://crt.sh/?d=300288180 -O 300288180.crt $ wget
https://rack.ms/b/UsNQv74sfH40/msg.txt{,.sig-sha256.b64}
$ openssl dgst -sha256 -verify <(openssl x509 -in 300288180.crt -pubkey
-noout) -signature <(base64 -d msg.txt.sig-sha256.b64) msg.txt

As the domain name suggests, this is part of the AlibabaProtect/"Alibaba PC
Safe Service" that comes bundled with the Youku client.


Mark


Mark
On Tue, Dec 11, 2018 at 5:37 AM Xiaoyin Liu via dev-security-policy
 wrote:
>
> Hello,
>
> I think I found a SSL certificate misuse issue, but I am not sure if this
is indeed a misuse, so I want to ask about it on this list.
>
> Here is the issue: After I installed Youku Windows client
(https://pd.youku.com/pc, installer:
https://pcclient.download.youku.com/youkuclient/youkuclient_setup_7.6.7.1122
0.exe), it starts a local HTTPS server, listening on localhost:6691. Output
of "openssl s_client -connect 127.0.0.1:6691" indicates that this local
server uses a valid SSL certificate, issued to "Alibaba (China) Technology
Co., Ltd." CN=*.alipcsec.com, and issued by GlobalSign. It's a publicly
trusted OV cert, and is valid until Jan 13, 2019. Later, I found that
local.alipcsec.com resolves to 127.0.0.1, and
https://local.alipcsec.com:6691/ is used for inter-process communication.
>
> It's clear that the private key for *.alipcsec.com is embedded in the
executable, but all the executables that may embed the private key are
packed by VMProtect, and the process has anti-debugging protection. I tried
plenty of methods to extract the private key, but didn't succeed. I reported
this to Alibaba SRC anyway. They replied that they ignore this issue unless
I can successfully extract the key.
>
> So is this a certificate misuse issue, even if the private key is
obfuscated? If so, do I have to extract the private key first before the CA
can revoke the cert?
>
> Thank you!
>
> Best,
> Xiaoyin Liu
>
> Here is the certificate:
> -BEGIN CERTIFICATE-
> MIIHTjCCBjagAwIBAgIMCpI/GtuuSFspBu4EMA0GCSqGSIb3DQEBCwUAMGYxCzAJ
> BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTwwOgYDVQQDEzNH
> bG9iYWxTaWduIE9yZ2FuaXphdGlvbiBWYWxpZGF0aW9uIENBIC0gU0hBMjU2IC0g
> RzIwHhcNMTgwMTEyMDgxMTA1WhcNMTkwMTEzMDgxMTA1WjB7MQswCQYDVQQGEwJD
> TjERMA8GA1UECBMIWmhlSmlhbmcxETAPBgNVBAcTCEhhbmdaaG91MS0wKwYDVQQK
> EyRBbGliYWJhIChDaGluYSkgVGVjaG5vbG9neSBDby4sIEx0ZC4xFzAVBgNVBAMM
> DiouYWxpcGNzZWMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
> 9PJcPzpUNRJeA8+YF8cRZEn75q+fSsWWkm6JfIlOKorYXwYJB80de4+Bia3AgzfO
> wqwWfPGrRYh5OY4ujjsKF5XkWG22SLlzi5xB9zAeVKHYTo2U6aKrKnht9XyYvnZX
> ocIuaSxkqq4rQ9UwiEYB6lvy8RY1orYu33HtrGD5W3w9SWf2AwB0rCNp0BeSRaGB
> JEEXzgVECbL+deJZgZflae1gQ9q4PftDHuGXLNe8PLYq2D4+oKbYvbYtI9WKIMuh
> 1dL70QBbcW0y4jFr2/337H8/KhBaCb3ZBZQI4LUnYL8RVeAVJFpX/PuiHMh9uNTm
> oW1if7XQswJCWx3td5tWiwIDAQABo4ID5TCCA+EwDgYDVR0PAQH/BAQDAgWgMIGg
> BggrBgEFBQcBAQSBkzCBkDBNBggrBgEFBQcwAoZBaHR0cDovL3NlY3VyZS5nbG9i
> YWxzaWduLmNvbS9jYWNlcnQvZ3Nvcmdhbml6YXRpb252YWxzaGEyZzJyMS5jcnQw
> PwYIKwYBBQUHMAGGM2h0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9nc29yZ2Fu
> aXphdGlvbnZhbHNoYTJnMjBWBgNVHSAETzBNMEEGCSsGAQQBoDIBFDA0MDIGCCsG
> AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAI
> BgZngQwBAgIwCQYDVR0TBAIwADBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vY3Js
> Lmdsb2JhbHNpZ24uY29tL2dzL2dzb3JnYW5pemF0aW9udmFsc2hhMmcyLmNybDAn
> BgNVHREEIDAegg4qLmFsaXBjc2VjLmNvbYIMYWxpcGNzZWMuY29tMB0GA1UdJQQW
> MBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUoIFBQJomlUEiLibD+luC
> 

Re: SSL private key for *.alipcsec.com embedded in PC client executables

2018-12-11 Thread Xiaoyin Liu via dev-security-policy

On 2018/12/11 14:39, Matt Palmer via dev-security-policy wrote:
> On Tue, Dec 11, 2018 at 05:37:41AM +, Xiaoyin Liu via dev-security-policy 
> wrote:
>> It’s clear that the private key for *.alipcsec.com is embedded in the
>> executable,
> There are ways of implementing SSL such that the private key doesn't *have*
> to be stored locally.  They all require the TLS termination point to be able
> to communicate with the service that *does* hold the private key, so a good
> way to test that the key is stored locally is to remove external
> connectivity and then try to establish a TLS connection.  If you still can,
> the key has to be *somewhere*.
I see. Thank you for the info! Indeed the connection can be established
even if Internet is disconnected.
>> packed by VMProtect, and the process has anti-debugging protection.  I
>> tried plenty of methods to extract the private key, but didn’t succeed.  I
>> reported this to Alibaba SRC anyway.  They replied that they ignore this
>> issue unless I can successfully extract the key.
> That sounds like it might be an admission that the binary *is* in the
> executable, and they're just hoping you won't be able to get it.
>
>> So is this a certificate misuse issue, even if the private key is
>> obfuscated?  If so, do I have to extract the private key first before the
>> CA can revoke the cert?
> Sadly, some CAs do indeed require you to *actually* produce the private key
> in order for them to consider the key compromised.  Given that people can
> pull apart Nation-State grade malware I think "we don't *know* that anyone's
> found it yet" is lamentably short-sighted, but absent an explicit rule that
> a key is considered compromised if it can be shown that it *must* be in
> a local executable, some CAs will continue to stick to their current
> standards.
>
> You can see how a similar situation played out in the past, in
> https://groups.google.com/d/msg/mozilla.dev.security.policy/pk039T_wPrI/tGnFDFTnCQAJ
>
> However, I don't know what GlobalSign's policy is regarding revocation
> proof.  Rather than just talking to Alibaba, it would be worth contacting
> GlobalSign's problem reporting address (which is listed in the problem
> reporting list in the CCADB, at
> https://ccadb-public.secure.force.com/mozilla/AllProblemReportingMechanismsReport)
> and putting the situation to them.

Thank you for the links! I will contact GlobalSign tomorrow if Alibaba
doesn't take action by then. I just want to give Alibaba some time to
update their cert, to avoid disrupting users. Of course, if other people
on the list have already reported to GlobalSign, then I won't.


Best,

Xiaoyin

> - Matt
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: SSL private key for *.alipcsec.com embedded in PC client executables

2018-12-11 Thread Jeremy Rowley via dev-security-policy
I think pretty much every ca will accept a signed file in lieu of an actual 
key. Generally provide the key just means some proof of compromise the ca can 
replicate.

From: dev-security-policy  on 
behalf of Matt Palmer via dev-security-policy 

Sent: Monday, December 10, 2018 11:39:31 PM
To: dev-security-policy@lists.mozilla.org
Subject: Re: SSL private key for *.alipcsec.com embedded in PC client 
executables

On Tue, Dec 11, 2018 at 05:37:41AM +, Xiaoyin Liu via dev-security-policy 
wrote:
> It’s clear that the private key for *.alipcsec.com is embedded in the
> executable,

There are ways of implementing SSL such that the private key doesn't *have*
to be stored locally.  They all require the TLS termination point to be able
to communicate with the service that *does* hold the private key, so a good
way to test that the key is stored locally is to remove external
connectivity and then try to establish a TLS connection.  If you still can,
the key has to be *somewhere*.

> packed by VMProtect, and the process has anti-debugging protection.  I
> tried plenty of methods to extract the private key, but didn’t succeed.  I
> reported this to Alibaba SRC anyway.  They replied that they ignore this
> issue unless I can successfully extract the key.

That sounds like it might be an admission that the binary *is* in the
executable, and they're just hoping you won't be able to get it.

> So is this a certificate misuse issue, even if the private key is
> obfuscated?  If so, do I have to extract the private key first before the
> CA can revoke the cert?

Sadly, some CAs do indeed require you to *actually* produce the private key
in order for them to consider the key compromised.  Given that people can
pull apart Nation-State grade malware I think "we don't *know* that anyone's
found it yet" is lamentably short-sighted, but absent an explicit rule that
a key is considered compromised if it can be shown that it *must* be in
a local executable, some CAs will continue to stick to their current
standards.

You can see how a similar situation played out in the past, in
https://clicktime.symantec.com/a/1/z7t2f8C-xqcp0GyPdbPYq0AzStbSzZZLsAiWkgf1Qao=?d=wSt3-FOUxECayz11Nt0P1X794-iSgW_g8FHinkPNGP7yfJPdd43QxrqJq3ndOpqrfgFw_4kll_w4koZ4Fmhjm-pcmi1trfuhDJqNhLBZkLi3TtVf47PYEeawoI-Mpx8DGzrTx5czVUdsV-RH1iiNRrYjkCzYnHRhDFHmso6ZD7x37NwvEAjNwTwDRwm8lYv0D0UMvBq4vgoqr5pH26lNrieRBNTT0qsApxp-JlfSw6GRoBhhI0oO4mfoXv7xBpYCP1UeKy330eCmN67TFaqUHmXGdFgWj4ZubHj8J6W24Jf4MpGU1ux-HGd0zFGdQNELTXDP8jIbA_mr_P7ZJ2cUzEcCUC3XkhmjEZ5ioLZvmfl0I_BLAeIr1AifJapBnpkdWJwvXTCfadOvB7ehq5XKKIvwne6LkOxTK8KgWL_I7al_WgtjU6FoRr9ftMQgvGT_Xp2Z_OCQJA%3D%3D=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsg%2Fmozilla.dev.security.policy%2Fpk039T_wPrI%2FtGnFDFTnCQAJ

However, I don't know what GlobalSign's policy is regarding revocation
proof.  Rather than just talking to Alibaba, it would be worth contacting
GlobalSign's problem reporting address (which is listed in the problem
reporting list in the CCADB, at
https://clicktime.symantec.com/a/1/Q235mwJymdbdGiH8YOe0XcXtTxxDAnyPflk1ft55vMI=?d=wSt3-FOUxECayz11Nt0P1X794-iSgW_g8FHinkPNGP7yfJPdd43QxrqJq3ndOpqrfgFw_4kll_w4koZ4Fmhjm-pcmi1trfuhDJqNhLBZkLi3TtVf47PYEeawoI-Mpx8DGzrTx5czVUdsV-RH1iiNRrYjkCzYnHRhDFHmso6ZD7x37NwvEAjNwTwDRwm8lYv0D0UMvBq4vgoqr5pH26lNrieRBNTT0qsApxp-JlfSw6GRoBhhI0oO4mfoXv7xBpYCP1UeKy330eCmN67TFaqUHmXGdFgWj4ZubHj8J6W24Jf4MpGU1ux-HGd0zFGdQNELTXDP8jIbA_mr_P7ZJ2cUzEcCUC3XkhmjEZ5ioLZvmfl0I_BLAeIr1AifJapBnpkdWJwvXTCfadOvB7ehq5XKKIvwne6LkOxTK8KgWL_I7al_WgtjU6FoRr9ftMQgvGT_Xp2Z_OCQJA%3D%3D=https%3A%2F%2Fccadb-public.secure.force.com%2Fmozilla%2FAllProblemReportingMechanismsReport)
and putting the situation to them.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/0DB1rX6Nb0O0ODt9aZeLn-fDlAWawyUHF7uk_TFf9aU=?d=wSt3-FOUxECayz11Nt0P1X794-iSgW_g8FHinkPNGP7yfJPdd43QxrqJq3ndOpqrfgFw_4kll_w4koZ4Fmhjm-pcmi1trfuhDJqNhLBZkLi3TtVf47PYEeawoI-Mpx8DGzrTx5czVUdsV-RH1iiNRrYjkCzYnHRhDFHmso6ZD7x37NwvEAjNwTwDRwm8lYv0D0UMvBq4vgoqr5pH26lNrieRBNTT0qsApxp-JlfSw6GRoBhhI0oO4mfoXv7xBpYCP1UeKy330eCmN67TFaqUHmXGdFgWj4ZubHj8J6W24Jf4MpGU1ux-HGd0zFGdQNELTXDP8jIbA_mr_P7ZJ2cUzEcCUC3XkhmjEZ5ioLZvmfl0I_BLAeIr1AifJapBnpkdWJwvXTCfadOvB7ehq5XKKIvwne6LkOxTK8KgWL_I7al_WgtjU6FoRr9ftMQgvGT_Xp2Z_OCQJA%3D%3D=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy