Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Private Burp Collaborator DNS Server handles custom CNAME records not RFC1034 conform

Mathias | Last updated: Nov 10, 2021 03:03PM UTC

Hi, I am currently using the private Burp Collaborator and ran into a non RFC1034 conform behavior of the dns server when using a custom CNAME-Record[1]. My custom DNS config snippet: "customDnsRecords": [ { "label": "_acme-challenge", "record": "1234.acme.example.com", "type": "CNAME", "ttl": 300 } ] When I query the Burp Collaborator dns server for the CNAME-Record everything is fine: # dig _acme-challenge.collaborator.example.com CNAME @<burp-collaborator-ip> ... ;; ANSWER SECTION: _acme-challenge.collaborator.example.com. 300 IN CNAME 1234.acme.example.com. ... When I query the Burp Collaborator dns server for a TXT-Record: # dig _acme-challenge.collaborator.example.com TXT @<burp-collaborator-ip> # -> an empty answer is returned Expected behavior: -> the CNAME-Record should be returned by the Burp Collaborator dns server See RFC1034[2] chapter "3.6.2. Aliases and canonical names" for more information. This bug currently prevents the DNS-01 challenge used by Let's Encrypt from being used with CNAME delegation. [3] Thanks, Mathias [1] https://portswigger.net/burp/documentation/collaborator/deploying#add-custom-dns-records [2] https://datatracker.ietf.org/doc/html/rfc1034 [3] https://letsencrypt.org/docs/challenge-types/#dns-01-challenge

Michelle, PortSwigger Agent | Last updated: Nov 11, 2021 10:37AM UTC

Thanks for your message. TXT records allow the domain administrator to enter text into DNS, originally this was intended as a way of human-readable notes but is now used by a number of tools to verify domain ownership by requiring the domain administrator to add a TXT record containing a specific piece of TXT (as you see during the Let's Encrypt DNS challenge). During the domain verification challenge, the value your provider will want you to respond with will vary and needs to be configured in DNS once your provider has specified what they expect to see. With the current version of Burp you can configure a TXT record for your private Collaborator server in the customDnsRecords section of the configuration file, for example: "customDnsRecords": [ { "label": "_acme-challenge", "record": "275fe5b909adb10e41c78066e9485f7d", "type": "TXT", "ttl": 60 }, { "label": "test", "record": "hackxor.net", "type": "CNAME" } ] The ttl value is optional and is in seconds. Once you have specified this in the configuration file you should restart the Collaborator Server and you can continue with the Let's Encrypt domain verification process. I hope this helps, please let us know if you have any questions.

Mathias | Last updated: Nov 11, 2021 11:50AM UTC

Thank you for pointing out how the Letsencrypt DNS-01 challenge works. Using the TXT Record, which contains the value provided by the ACME server is the default way. But there are also other ways to respond to the DNS-01 challenge. In our case it's the DNS alias mode. [1] Using this mode, you provide a CNAME-Record, which points to a DNS-Record which then contains the TXT-Record with the "challenge" of the ACME server. To use this mode, the dns server needs to respond accordingly to rfc1034. In case there is a CNAME-Record, the server must respond with it, no matter which resource record type the client requested. [1] https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode

Michelle, PortSwigger Agent | Last updated: Nov 12, 2021 10:36AM UTC

Sorry if I misunderstood exactly how you were trying to set this up previously. Burp Suite Collaborator isn't a full-blown DNS server. To allow it to work with domain verification processes such as the one used by Let's Encrypt we added in functionality to allow the TXT records to be manually configured so the Collaborator Server itself would respond with the value (as described in the last post) and this has been used successfully. Can you tell me more about your use case and why you would prefer it to respond with the CNAME record so that you can use alias mode?

Mathias | Last updated: Nov 12, 2021 01:33PM UTC

I am using the Let's Encrypt alias mode because then I can reuse some automation tools which are running on our infrastructure. If I want to use the TXT challenge system, I need to rework the whole setup to get this running for just this use case of the collaborator. But let's skip the Let's Encrypt part and get over to a more generic explanation, because this bug also affects others. A CNAME record points to another dns resource record. This can be an A, AAAA, TXT, CNAME or any other record type. Let's do an example (for easier explanation): We have a CNAME-Record "haxor.collaborator.example.com" which points to "my-webserver.example.com". This "my-webserver.example.com" record has an A-Record which contains the IPv4 address of my webserver (192.0.2.1). If a user now opens the website http://haxor.collaborator.example.com in his browser, a request is sent to my webserver (192.0.2.1). Let's have a deeper look at the DNS handling of the browser (to simplify everything we only use IPv4 here): The browser needs an IPv4 address to send it's request to. To do that, it will send out a DNS Request to get the A-Record of "haxor.collaborator.example.com". But "haxor.collaborator.example.com" does not have any A-Record, it only has a CNAME-Record. Because of the CNAME-Record, the DNS server has to send that information back to the browser, to give the browser the possibility to then query "my-webserver.example.com" for the A-Record. I hope this example will make the point a bit more clearer. To summarize the DNS server handling in a bit more programmer kind: If we have a CNAME-Record for the requested record, we return that CNAME-Record. For any other requested record type we only return the value if we have a defined record. In any other case we return an empty answer.

Michelle, PortSwigger Agent | Last updated: Nov 15, 2021 10:04AM UTC

Thanks for the update. As we mentioned before Burp Collaborator isn’t designed to be a full-blown DNS server so doesn’t currently respond to TXT requests with the CNAME record. The functionality to add custom DNS records and set specific custom CNAME and TXT records was added with domain verification processes in mind but was not intended to make Collaborator behave like a full DNS server in all respects. As the current custom DNS records do not allow you to do what you need, one option could be to use the process that a number of people used prior to the custom TXT records being introduced. This involved stopping the collaborator and running a DNS server of your choice. Once the domain has been verified and you have the cert + key you can revert back to running collaborator. I am happy to raise this as a feature request with the team, to help them prioritize this work it would be good to get a better understanding of how using DNS alias-mode for this process is beneficial for you compared to the options that are currently available with the Collaborator server.

Mathias | Last updated: Nov 15, 2021 10:59AM UTC

Thank you for your reply. Perhaps I have described the problem incomprehensibly in my previous messages. I understand, that the Burp Collaborator is not a full-blown DNS server. And that's ok! To my understanding, it is supporting custom TXT and CNAME records (based on the information in your documentation [1]). The handling of custom TXT records is implemented correctly (from my point of view). The problem is the current handling of custom CNAME records. It's not a feature request or any special handling of some Let's Encrypt server. It's definitely a bug in your current implementation how you handle custom CNAME records. In a nutshell, custom CNAME records are not usable at the moment, because the handling of it in your DNS server is not RFC-compliant. [1] https://portswigger.net/burp/documentation/collaborator/deploying#add-custom-dns-records

Michelle, PortSwigger Agent | Last updated: Nov 16, 2021 10:35AM UTC