Re: DNS fragmentation attack subverts DV, 5 public CAs vulnerable
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
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
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
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
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
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
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
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
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
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
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
