Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Burp Collaborator - Wildcard certificate problem

Sven | Last updated: Jul 18, 2015 07:27AM UTC

Hi all, I have an internal collaborator Server up and running on a physical server with the following config: { "serverDomain" : "collaborator.test.com" "eventCapture" : { "https": { "hostname" : "collaborator.test.com" } }, "polling" : { "https": { "hostname" : "collaborator.test.com" } } } The collaborator server is starting without problems. According to the documentation, if I use the setting "hostname" a wildcard certificate for *.collaborator.test.com should be created. When I go to a site like https://1111.collaborator.test.com the CN for the certificate is still collaborator.test.com and not 1111.collaborator.test.com, therefore no wildcard certificate has been created. On my testing laptop the collaborator health check in Burp tells me "Server HTTPS Connection (trust enforced) - Warning" and "Verify DNS interaction - Error". Am I doing something wrong? How can I get the wildcard certificate provided by Burp Collaborator? I just want to have an easy setup for testing of an internal collaboration server, before using it within a production environment with our own certificate. Is it also possible to disable the SSL validation check for testing purposes on the server with the vulnerabilites? If so, what needs to be done? Thanks and cheers, Sven

PortSwigger Agent | Last updated: Jul 20, 2015 07:53AM UTC

Thanks for this. Firstly, it looks like there is indeed a bug in that when the Collaborator server auto-generates a self-signed certificate it is using the serverDomain hostname, and not adding the wildcard prefix. Apologies for that - it seems we focused our testing on using real wildcard certificates rather than auto-generated ones. We'll get it fixed in the next Burp release. That said, even if the wildcard part was working then you would of course still see certificate errors because of the certificate being self-signed. In terms of testing out a non-production deployment, you can just ignore the SSL warnings in the health checker. If you want to test the set-up with some lab vulnerabilities, then just use labs where the vulnerable server uses HTTP for its server-side requests or uses HTTPS but does't validate the SSL. The SSRF-based labs in WAVSEP are suitable for testing this. (The error you mentioned relating to DNS is probably unrelated to the SSL certificate issue, and that needs to be investigated separately.)

PortSwigger Agent | Last updated: Jul 20, 2015 10:15AM UTC

Just to follow up on this, actually it's likely that the DNS error is related to the SSL one. Since you are using a self-signed cert (and the CN is also wrong due to the wildcard bug), when Burp polls to verify interactions it will also fail due to the SSL error. To protect sensitive scan data, Burp enforces SSL trust when polling the Collaborator, and so the polling/verification will fail when the SSL certificate is self-signed. You can avoid this problem by checking the box to make Burp poll over plain HTTP. (We're also going to update the wording in the health check dialog to explain this requirement in cases where the Collaborator SSL certificate is invalid / self-signed.)

PortSwigger Agent | Last updated: Jul 29, 2015 10:50AM UTC

Just to let you know that today's release (1.6.23) hopefully fixes the issue you identified with the self-signed certificate not containing the wildcard prefix.

Burp User | Last updated: Aug 03, 2015 01:29AM UTC

Hi Dafydd, I just read the release notes of Burp and was going back to this post. Thanks for your response and explanation. Will give it a try in a few days. Thanks for fixing this so quickly. Thanks and cheers, Sven

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.