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.
The Vulnerability
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.
Along with web server information and cipher suites, there’s SSL certificate fields parsed and shown on the screen.
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:
And then started a pretend web server using openssl.
After pointing SSLCheck to scan my server’s ip address the custom fields in the certificate are shown in the page, this way we can find out which fields can be used to inject html into the page. The next step would be to generate another certificate with html tags and javascript and try to load it into the page.
Fair enough, the certificate is fetched from the server, it is then parsed and html data is injected into the page and also saved in SSLCheck’s database so that the report can be accessed later using a link. This way we can run our custom javascript and change the look of this page and have a link to it and use it for phishing or other malicious acts.
We generate our certificate with <script>alert(‘xss’)</script> in the OU field.
We now point SSLCheck to fetch our certificate and TaDaaaaa!
I could inject my javascript into their page, I was also given a URL so that I could share the link for this report. One abuse case scenario would be to create a phishing webpage on top of this page under certcc domain and use it to steal admin credentials.
Mitigation
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.
The solution they chose to implement was to encode the fields so that injected javascript or html isn’t executed or parsed by the browser.
Timeline
Since certcc is an ISAC and is working with lots of CERTs, I was expecting a quick response and this was the case.
| Title | Date |
| Initial Report to CertCC | 2/2/2017 |
| Initial Response | 2/2/2017 <12hrs |
| Vulnerability Fixed | 27/2/2017 |
| Report Published | 16/3/2017 |
Hi, good job, I read your article and useful for me, thank U.
Are U explain this for me that how I do this:
“create a phishing webpage on top of this page under certcc domain and use it to steal admin credentials.”
I’ll add the description to the blog post.