ZeroSSL: XSS leading to session hijacking, stealing a private key (and a password hash)

[Michal Špaček]

Hi all,

I've discovered a Cross-Site Scripting (XSS) vulnerability at ZeroSSL web app (https://app.zerossl.com) which may lead to:
- session hijacking
- stealing a certificate private key, provided ZeroSSL has generated one
- stealing a user account password hash

I've first emailed ZeroSSL about the issue on 4 Jan 2023 in the morning, they got back to me the same day at noon and promised they'll investigate.

The thing is, if ZeroSSL has generated a private key (they do so in their web app, they also have an ACME API but that's not affected), the user
can download the key repeatedly from their site. The private key is stored encrypted in the app and is decrypted in the browser before it's being
offered for download in a .zip archive. The decryption key is sha256(password + password), is stored in browser's local storage and... can also be stolen with JavaScript (that was part of my January proof-of-concept link).

Earlier today, I sent a proof-of-concept (PoC) code that demonstrates how to steal a private key for a domain by clicking a link, provided ZeroSSL
has generated the key. After sending the PoC, they have responded this afternoon that they have fixed the XSS but I believe there may be
some more work for them to do.

First, reading Baseline requirements section 4.9.1.1.16 they may need to revoke some certificates because the proof-of-concept consists
of "a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise".

Second, their users are still one XSS away from losing their private keys as my private-key-stealing PoC still works (you can
paste it to your browser devtools console to simulate an XSS, or find a different XSS if you will).

I'm not going to share the PoC at least not for now, but it's less than 1kB of JavaScript which I believe
anyone could write and definitely even better than me.

I'm sending this email to create an informal public record of what happened (I've been cc'ing some friends who are also members of this list
so there's a "private record", sort of) and would like ZeroSSL to self-report a CA Incident as per https://wiki.mozilla.org/CA/Incident_Dashboard
(emailed them the link and the request to self-report an hour ago).

Seems like this is definitely the most interesting XSS I found so far :-) You know, don't stop at alert(1)...

(For transparency: they offered 500 EUR reward for the bug, thanks!)

Thanks,
Michal

--
https://www.michalspacek.com
https://twitter.com/spazef0rze

[Kurt Seifried]

On Thu, Jan 19, 2023 at 10:06 AM 'Michal Špaček' via CCADB Public <pub...@ccadb.org> wrote:

Hi all,

I've discovered a Cross-Site Scripting (XSS) vulnerability at ZeroSSL web app (https://app.zerossl.com) which may lead to:
- session hijacking
- stealing a certificate private key, provided ZeroSSL has generated one
- stealing a user account password hash

I've first emailed ZeroSSL about the issue on 4 Jan 2023 in the morning, they got back to me the same day at noon and promised they'll investigate.

The thing is, if ZeroSSL has generated a private key (they do so in their web app, they also have an ACME API but that's not affected), the user
can download the key repeatedly from their site. The private key is stored encrypted in the app and is decrypted in the browser before it's being
offered for download in a .zip archive. The decryption key is sha256(password + password), is stored in browser's local storage and... can also be stolen with JavaScript (that was part of my January proof-of-concept link).

Earlier today, I sent a proof-of-concept (PoC) code that demonstrates how to steal a private key for a domain by clicking a link, provided ZeroSSL
has generated the key. After sending the PoC, they have responded this afternoon that they have fixed the XSS but I believe there may be
some more work for them to do.

It sounds like ZeroSSL has not fixed this yet? I've assigned this GSD-2023-1001657 (https://gsd.id/GSD-2023-1001657) for tracking purposes, it should probably have a CVE as well since there are actionable steps for people to take.

Also to confirm their system generates a private key/certificate on the server and then offers it up as a ZIP file for download correct?  

First, reading Baseline requirements section 4.9.1.1.16 they may need to revoke some certificates because the proof-of-concept consists
of "a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise".

Second, their users are still one XSS away from losing their private keys as my private-key-stealing PoC still works (you can
paste it to your browser devtools console to simulate an XSS, or find a different XSS if you will).

I'm not going to share the PoC at least not for now, but it's less than 1kB of JavaScript which I believe
anyone could write and definitely even better than me.

I'm sending this email to create an informal public record of what happened (I've been cc'ing some friends who are also members of this list
so there's a "private record", sort of) and would like ZeroSSL to self-report a CA Incident as per https://wiki.mozilla.org/CA/Incident_Dashboard
(emailed them the link and the request to self-report an hour ago).

Seems like this is definitely the most interesting XSS I found so far :-) You know, don't stop at alert(1)...

(For transparency: they offered 500 EUR reward for the bug, thanks!)

Thanks,
Michal

--
https://www.michalspacek.com
https://twitter.com/spazef0rze

--
You received this message because you are subscribed to the Google Groups "CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.
To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/909978403.20230119174530%40michalspacek.cz.

--

Kurt Seifried (He/Him)
ku...@seifried.org

[Ryan Dickson]

Also to confirm their system generates a private key/certificate on the server and then offers it up as a ZIP file for download correct?  

From recent testing, I can confirm users are presented with the option of downloading a ZIP file that contains the corresponding private key after completing domain validation.

Given the following requirements in 6.1.1.3 of the BRs, is it possible from someone representing ZeroSSL to clarify who, if not the CA, is considered to be generating the key pair?

If the Subscriber Certificate will contain an extKeyUsage extension containing either the values id-kp-serverAuth [RFC5280] or anyExtendedKeyUsage [RFC5280], the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA.

Thanks,

Ryan 

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CABqVa396K26Lwr-AH5yvZh9y-JphU9dHAnUrn_bKd2rp2j6nsw%40mail.gmail.com.

[ccadb-...@nummer378.de]

Hello all,

There may be some confusion about who ZeroSSL is, which should probably be cleared first. To my best knowledge, ZeroSSL is not a certificate authority. Rather, they appear to be a reseller for Sectigo. I can not say this for certain, but based on experiments I presume that:

- ZeroSSL's (intermediate) certificate and corresponding key material is owned and controlled by Sectigo. It is listed as one of their certificates in scope for audit and CP/CPS: https://github.com/sectigo/ca_certificate_lists/blob/main/audit/list_for_audit.csv

- Domain validation for "ZeroSSL-issued" certificates is performed by Sectigo as well. CAA records for ZeroSSL have to include only Sectigo. In addtion, some IP addresses used by ZeroSSL's ACME HTTP-01 validation originate from AS48447 / Sectigo Limited.

If this is correct, any key material generated by ZeroSSL is not generated by a CA and hence not a BR violation. If ZeroSSL is not a CA, they might also not monitor this list, nor may they be able to open a CA incident report. In this case, any CA concerns would have to be directed to the CA, Sectigo.

Thanks,
Max

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/CADEW5O9eSAkssoD%3Dtq-PqdKAbeB7ZbQ6_WCUbnkFa7GBe7wrRA%40mail.gmail.com.

[Ryan Dickson]

Thanks for that clarification, Max. 

My original recollection was that they were a reseller, but some of the branding on the ZeroSSL website could be interpreted as suggesting otherwise (like the "Trusted Certificate Authority" badge on the homepage). CCADB confirms the CA owner as "Sectigo".

Looking at https://bugzilla.mozilla.org/show_bug.cgi?id=1699756, it seems ZeroSSL has previously described the certificate request workflow.

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/aeef5be8-cb21-2350-d714-4cf171da11bc%40germancoding.com.

[Michal Špaček]

Friday, January 20, 2023, 2:03:35 AM, you wrote:
> It sounds like ZeroSSL has not fixed this yet?

They have fixed the XSS I've reported (there may be similar issues but they may or may not be
exploitable for stealing the private key). They have not changed the design of the app, so the PoC
code would work for example by running the JS manually in the browser (in devtools console).

The particular XSS is one problem (fixed) and I'd say the "download private key again" feature is
another (which also includes the password hash stored in localstorage).

> Also to confirm their system generates a private key/certificate on the
> server and then offers it up as a ZIP file for download correct?

They generate it in the browser with this lib https://github.com/digitalbazaar/forge
Can be manually verified by running forge.pki.rsa.generateKeyPair(2048); in the devtools console
and watching network traffic.

Michal

--
https://www.michalspacek.cz
https://twitter.com/spazef0rze

[Seo Suchan]

sha256(password + password)
if that's the format it isn't salted and able to build rainbow table right?
or those two passwords are different things?

On 2023년 1월 20일 오전 1시 45분 30초 GMT+09:00, "'Michal Špaček' via CCADB Public" <pub...@ccadb.org> 작성함:

[Martijn Katerbarg]

All, we’re just acknowledging that Sectigo is aware of this thread and monitoring it. We are in touch with ZeroSSL and will follow up with a more detailed response from our end in the first half of next week.

Op vrijdag 20 januari 2023 om 14:50:17 UTC+1 schreef tjt...@gmail.com:

[Corey Bonnell]

> They have fixed the XSS I've reported (there may be similar issues but they may or may not be exploitable for stealing the private key). They have not changed the design of the app, so the PoC code would work for example by running the JS manually in the browser (in devtools console).

Your discovery and responsible disclosure of this XSS vulnerability is an excellent find. However, I don't believe that changes to the application design to prevent key extraction via the devtools console are required. Manual execution of JS in the console to extract keys is akin to attaching gdb to a running Apache process and extracting server private keys from memory. Perhaps user education to prevent users from being duped into blindly copy/pasting code/debugger commands would be useful (or a message output directly to the console warning users [1]), but I don't think this itself is a vulnerability.

> They generate it in the browser with this lib https://github.com/digitalbazaar/forge

The use of such libraries is an excellent way to perform keypair generation directly within the user's browser without the private key ever leaving the machine. However, webpages that perform such keypair generation should ensure that only locally hosted scripts are loaded, or SRI is employed for all externally hosted scripts so that the compromise of an externally referenced webserver (and hosted resources) cannot manifest in the exfiltration of generated keys or other shenanigans.

Thanks,
Corey

[1] https://security.stackexchange.com/a/89792

--
You received this message because you are subscribed to the Google Groups "CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public+un...@ccadb.org.

To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/1652361631.20230120110555%40michalspacek.cz.

[Michal Špaček]

Friday, January 20, 2023, 5:31:30 PM, you wrote:
> Your discovery and responsible disclosure of this XSS vulnerability is an excellent find.

Thanks.

> However, I don't believe that changes to the application design to prevent key extraction via the devtools console are required.

The changes I'm talking about are not about preventing private key extraction via devtools, but about
preventing the extraction by running a JS code in the context of the app. Devtools console (and Self-XSS) is only one
way of doing that, a XSS vulnerability is another.

[Corey Bonnell]

> The changes I'm talking about are not about preventing private key extraction via devtools, but about preventing the extraction by running a JS code in the context of the app. Devtools console (and Self-XSS) is only one way of doing that, a XSS vulnerability is another.

Wouldn't such a XSS vulnerability allow for the exfiltration of session cookies and other local browser state? I suppose I'm struggling to see why the storage of the private key is deemed especially undesirable when there are other as "juicy" (if not more) local state that could be disclosed.

-----Original Message-----
From: Michal Špaček <ma...@michalspacek.cz>
Sent: Friday, January 20, 2023 11:51 AM
To: Corey Bonnell <Corey....@digicert.com>; Kurt Seifried <ku...@seifried.org>
Cc: CCADB Public <pub...@ccadb.org>
Subject: Re: ZeroSSL: XSS leading to session hijacking, stealing a private key (and a password hash)

[Michal Špaček]

Friday, January 20, 2023, 6:48:05 PM, you wrote:
>> The changes I'm talking about are not about preventing private key extraction via devtools, but about preventing the extraction by running a JS code in the context of the app. Devtools console (and Self-XSS) is only one way of doing that, a XSS vulnerability is another.

> Wouldn't such a XSS vulnerability allow for the exfiltration of session cookies and other local browser state? I suppose I'm struggling to see why the storage of the private key is deemed especially undesirable when there are other as "juicy" (if not more) local state that could be disclosed.

In case of ZeroSSL yes, there's a password hash that you could steal with XSS, the hash is used as a private key decryption key.

Session cookies can be marked as HTTP-only which would prevent JavaScript from accessing and stealing them.
ZeroSSL have not done that (yet?) but I've included it in my first report.

I think it shouldn't be possible to download a private key with access to just a logged in
session, or by having a username and a password, or by running an untrusted JS in the context of the app.

The problem here is not that they store an encrypted private key but that it's rather easy to get it.
Which of course is best solved by not storing the key in the first place :-)
So in all cases we're kind of circling back to the design of the app here.

[David Spitzer-Dulagan]

Hello everyone,

Sectigo notified us of this thread and as a representative of ZeroSSL I would like to provide a few clarifications. The vulnerability that was reported to us by Michal indeed was unknown and we were greatful that he reported it. We've fixed the issue on the same day it was reported and are currently working on releasing additional hardening of our web app that should prevent similar vulnerabilities on the platform in the future with the first release scheduled for Monday.

Currently we have no reason to believe that Michal's findings were exploited by any third parties. The access logs we scanned didn't show any suspicious requests to the vulnerable URL. I'd also like to note that the exploit of the vulnerable URL would have only worked if the targeted ZeroSSL user would have had an active session while clicking on the malicious link.

The way we generate the private keys is documented in the following thread: https://bugzilla.mozilla.org/show_bug.cgi?id=1699756#c4

We believe this practice to be sufficiently secure. It was also discussed at length with our partner Sectigo as well as with representatives from Mozilla and others. We take security very seriously and are in contact with our partner Sectigo in regards to staying compliant with the CA/Browser Forum requirements and are always open to inputs. We believe that the service that we render to our users on zerossl.com has increased security on the public internet overall by allowing users that are not so technically well-versed to secure their websites and other online services with tls/ssl certificates that would otherwise still be unencrypted.

Let me know if you have any further questions or suggestions for us.

David

[Martijn Katerbarg]

All,

We have been following this thread and have also been in direct contact with ZeroSSL since this report became public.

With all that has been discussed, we are satisfied with the way ZeroSSL has been handling this vulnerability, investigation and disclosure.

Since the method of key generation has been discussed in the past, we do not believe there is any need for us to take action at this time.

Regards,

Martijn

Op vrijdag 20 januari 2023 om 20:12:11 UTC+1 schreef david....@stack.holdings:

[Amir Omidi (aaomidi)]

(Full disclosure, I am an engineer on Google Trust Services. I am sending this email in my personal capacity)

Hi Martijn,

Thank you for following up on this.

I noticed that ZeroSSL is using a public CDN (jsdelivr) for getting the Forge (https://github.com/digitalbazaar/forge) code to the end user. Considering that Forge is explicitly calling out to take care when using externally built & distributed copies of Forge (https://github.com/digitalbazaar/forge#security-considerations), are there any plans for ZeroSSL to stop using a CDN they don't control for distributing this?

Beyond that, ZeroSSL to this day doesn't have multi factor authentication. Are there plans on this being added? Right now with one password leak, an attacker can very easily get the private keys and certificates for an impacted user.

Finally, I'm noticing that the forge ZeroSSL uses from jsdeliver is 6 years old (<script src="https://cdn.jsdelivr.net/npm/node-...@0.7.0/dist/forge.min.js"></script>). Have there been any security updates since then? Is there a reason ZeroSSL hasn't updated their use of this critical dependency?

I'm not entirely sure if I feel comfortable with closing this as a no-op, but I'll leave it you and other folks at CCADB.

Cheers!

Amir

[David Spitzer-Dulagan]

Hi Amir,

> I noticed that ZeroSSL is using a public CDN (jsdelivr) for getting the Forge (https://github.com/digitalbazaar/forge) code to the end user. Considering that Forge is explicitly calling out to take care when using externally built & distributed copies of Forge (https://github.com/digitalbazaar/forge#security-considerations), are there any plans for ZeroSSL to stop using a CDN they don't control for distributing this?

Yes, the library will be moved to ZeroSSL's CDN with one of the next updates to the application, including an update to the library. We currently have a strong focus on improving the frontend and its security with several refactoring efforts on the way, one of which concerning the build system, which will allow us to finally move the forge library away from jsdelivr.

> Beyond that, ZeroSSL to this day doesn't have multi factor authentication. Are there plans on this being added? Right now with one password leak, an attacker can very easily get the private keys and certificates for an impacted user.

This has proven to be a difficult topic and an initial approach was scrapped but it is again on our dev roadmap for this year. 

Best,

David