RE: SSL private key for *.alipcsec.com embedded in PC client executables
As a follow-up, The certificate was revoked about 2 hours ago:
https://crt.sh/?id=300288180&opt=ocsp
-Original Message-
From: Doug Beattie
Sent: Tuesday, December 11, 2018 8:09 AM
To: 'dev-security-policy@lists.mozilla.org'
Cc: 'Xiaoyin Liu' ; Mark Steward
Subject: 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
&g
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: 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
> > uDVMtvvBM4qrhWm+Sv
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
> Lmd
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&u=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&u=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&u=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
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.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
> uDVMtvvBM4qrhWm+SvkwDQYJKoZIhvcNAQELBQADggEBAIEPnMZ0HBnwXJNoEDEz
> K0afVI5xtNgONjV5QViIgGWaqG+sKjLHjxU040gXPi7ycSKlgbEOF4WE5jvLLFBS
> 890txX4kpLJhcsCHyomwCrTe6V83f20zBa50svQau2L0pnOeeFbAsDAM4PsvaABp
> ziT6keCFUGyfrZCsjJWroT4gco74H+Ra8zLf4MTx9yJ65ERZabJZxD4n6V7tWc6U
> Ey2Tyjx9STCJXnNoogre+gh149nQJR4waUwxEicQDMpGOmEpFMoBAULPrPXksaGI
> T5xbQd74wqC01awRP20+QxHIcQHrEDQUM9GfqJgo8Z4cjNss4PNxTu3jupgS16mA
> K0o=
> -END CERTIF
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://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. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
