In this blog post I’m going to discuss the XSS vulnerability that I found in sslcheck.certcc.ir. Certcc has developed its own SSL configuration assessment service (like SSLLabs.com). The good point about this is that websites that are only reachable from Iran’s IP addresses can be tested using this service. I was playing around with this website to see how it works in contrast to SSLLabs.com, I found out that it gives you much more options like entering ip addresses, testing custom ports and also testing services that work with SSL like SMTP, IMAP and POP3. There was a part of the report from the website that parsed the SSL certificate and showed its fields and it also worked with self-signed certificates.
Well, parsing fields from self-signed certificates, storing them in the database and showing it on the website means that you are giving the user the ability to inject html into your page, after all one could create a certificate with Organization name of “<h1>Org</h1><script>alert(‘xss, much?’)</script>” and if sanitization or encoding isn’t applied to this data before showing it on the page, you are vulnerable to stored XSS.
Vulnerable SSLCheck software version was 2.1.6 (release date 1395/06/13). Under SSLCheck subdomain, there’s a form where you enter in your domain name or ip address of your website running SSL, you select the service (HTTPS, SMTP, …) and then the system starts scanning for your server’s SSL configurations just like Qualy’s SSLLabs.com website.
What came up to my mind right away was that if the attacker could control the fields in an SSL Certificate, there’s a chance that this data isn’t sanitized well. At first glance, it doesn’t look like it can be tampered with and be fed into the system via end users and that’s likely the reason why developers failed to address this issue.
What I did was to generate a self signed certificate with custom fields as follows:
We generate our certificate with <script>alert(‘xss’)</script> in the OU field.
We now point SSLCheck to fetch our certificate and TaDaaaaa!
What SSLCheck does wrong can be analyzed from two sides:
- Invalid SSL Certificates are parsed and shown on the page . Since Certificate Authorities do sanitize fields in SSL Certificates, one option would be to only parse and show fields for valid and publicly trusted SSL Certificates on the page.
- SSL Certificate fields aren’t sanitized before being displayed on the page or stored in the database. Basically any input from systems out of our control, be it the end user or 3rd party systems has to be sanitized before being displayed on the page. Encoding html characters or using a whitelist can fix this vulnerability.
Since certcc is an ISAC and is working with lots of CERTs, I was expecting a quick response and this was the case.
|Initial Report to CertCC||2/2/2017|
|Initial Response||2/2/2017 <12hrs|