Hi, It appears AlwaysOnSSL is not completely disabled - if we trust CT as a timestamping service, [1] was issued after Hanno's email.
I believe AlwaysOnSSL has at least two separate paths to issuance - in addition to the website, there's also an API on CertCenter's website. [2] While reading the API docs, I noticed a "generatePrivateKey" option; a quick read of their client API example code indicates CertCenter is generating keys server-side for their customers. I had hoped that after the Trustico debacle resellers would have discontinued this practice. While I welcome the availability of free and low-cost certificates, I share Hanno's concern about CertCenter/AlwaysOnSSL. Alex [1] https://crt.sh/?id=1097197338 [2] https://api.certcenter.help/docs/tutorial-integrate-alwaysonssl On Wed, Jan 9, 2019 at 8:59 AM Hanno Böck via dev-security-policy <[email protected]> wrote: > > Hi, > > AlwaysOnSSL was a free certificate authority operated by CertCenter. > I recently noticed that their main webpage was gone, but pieces of the > service were still online. > I immediately found a few web security issues. I reported those to > certcenter and digicert (which is the root CA their intermediate chains > to). > > This is what I reported: > > Partly disfuctional > =================== > > The service seems to be partly disfunctional. The start page is just > showing an empty document. > > However when directly calling subpages, e.g. > https://alwaysonssl.com/issue.php > there still seems to be an operational service. > > This looks to me like AlwaysOnSSL is not actively maintained. > > XSS > === > > The certificate issuance form has a trivial injection issue. Simply > putting something like ">test<h1> will inject HTML. CSP+XSS Auditor > prevent this from being a simple XSS, but I'm pretty sure this can be > bypassed with enough effort. > > CSRF > ==== > > The forms don't seem to contain any CSRF tokens. I haven't analyzed > this in detail, but I believe this likely means an attacker can > interfere with the issuance process and may be able to inject his own > CSR and forge a certificate. > > Account management > ================== > > I have an existing account for alwaysonssl.com from previous tests. > There seems to be no way of either deleting the account or changing the > password. I consider not offering a password changing option a security > problem as well. > > > I believe all of these issues show that alwaysonssl.com is an > unmaintained, partly broken service with a total lack of secure coding > practice, yet it's able to issue valid certificates that chain down to > a digicert root. > > ----------------- > > > In response to this the service was completely disabled. > > In one of the response mails CertCenter wrote me: > "Among other things, we operate a web application firewall that > prevent requests when it detects dangerous data. An XSS request like > the one you carried out apparently did not consider the WAF to be > relevant." > > This IMHO shows a serious lack of knowledge about web security basics > and an undeserved trust in WAFs. (The WAF filter was easily bypassable, > they also had a CSP which I believe was bypassable, too, but they > switched the service off before I could show that.) > > Given the service is switched off now I think there's nothing > particularly to do, but maybe it's a reminder to have a closer look at > the security of CA issuance web systems. > > -- > Hanno Böck > https://hboeck.de/ > > mail/jabber: [email protected] > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
