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 On Wednesday, January 25, 2023 at 9:20:53 PM UTC+1 [email protected] wrote: > (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/[email protected]/dist/forge.min.js > <https://cdn.jsdelivr.net/npm/[email protected]/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 > > On Wednesday, January 25, 2023 at 2:41:09 PM UTC-5 [email protected] > wrote: > >> 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 >> [email protected]: >> >>> 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 >>> >>> On Friday, January 20, 2023 at 5:26:14 PM UTC+1 [email protected] >>> wrote: >>> >>>> 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 [email protected]: >>>> >>>>> 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" <[email protected]> 작성함: >>>>> >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 >>>>> > >>>>> >>>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/86e65003-b34e-4866-803f-085459ee3d44n%40ccadb.org.
