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 Collaborator Server Refuses requests

Matt | Last updated: May 13, 2015 07:01PM UTC

I am trying to setup a private Collaborator server, and am running into issues with the DNS server. The server starts up fine; listening on port 80, 443, and 53. However, when I run a "netstat -plntu" on the server port 80 and 443 are in the listen state, but not 53: Proto Recv-Q Send-Q Local Address Foreign Address State tcp6 0 0 :::80 :::* LISTEN tcp6 0 0 :::443 :::* LISTEN udp6 0 0 :::53 :::* - Also when I run a Dig command "dig @servername google.com +norecurse" from a computer on the same network I get: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 61553 ;; flags: qr ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 Finally when running the health check from the Burp client it gets an error because it cannot resolve the polling.servername. It goes to the Collaborator server first for the lookup, it is then refused, and gets bounced back to my internal network's DNS. I am pretty much stuck on where to go from here. Is the Collaborator DNS setup to always refuse? Is there a way to get the DNS to get into a listen state? Did I miss some key thing in the documentation as to why the <crazy random string.server and polling.server are not getting resolved by the DNS?

PortSwigger Agent | Last updated: May 14, 2015 07:54AM UTC

If the ports used by the Collaborator server are free/unused, and you are running the Collaborator with sufficient privileges to bind to them, then it will do so. There is nothing special you need to do to "make" the Collaborator listen and receive traffic on UDP/53. We would recommend investigating whether any other service is using UDP/53 already, or whether any configuration on this system could be preventing Burp from correctly listening on the port.

Burp User | Last updated: May 14, 2015 04:52PM UTC

Nothing is running on port 53. I added Accept statements into Iptables on the box for both UDP and TCP traffic for 53. I also ran an nmap of the box: Starting Nmap 6.46 ( http://nmap.org ) at 2015-05-14 11:45 CDT Nmap scan report for localhost (127.0.0.1) Host is up (0.000011s latency). Not shown: 1989 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 443/tcp open https 631/tcp open ipp 3389/tcp open ms-wbt-server 5910/tcp open cm 5911/tcp open cpdlc 53/udp open|filtered domain 68/udp open|filtered dhcpc 123/udp open ntp 631/udp open|filtered ipp I can tell traffic is getting to the service as I see java exceptions thrown when running nmap because the service can't handle multiple requests at one time. At this point the only way I can even see that anything is wrong is because the Burp heal checker throws errors, and every DNS attempt of the services responds with a REFUSED.

PortSwigger Agent | Last updated: May 15, 2015 07:53AM UTC

Looking into this a bit more, I think it sounds like the Collaborator DNS server is actually listening and responding on UDP/53, but it is responding to your queries with the "refused" answer. This happens when there is a mismatch between the "serverDomain" field configured in the Collaborator config file and the domain/subdomain that you are doing a lookup for. The Collaborator only answers DNS queries for the same domain configured in the "serverDomain" field, or any subdomain.

Burp User | Last updated: May 21, 2015 07:53PM UTC

I'd also note from your first post that the "LISTENING" services are listening on IPv6 address space (hence tcp6 and udp6).

PortSwigger Agent | Last updated: May 22, 2015 03:46PM UTC

Setting a specific IPv4 address for the local capture address should cause Burp to try to bind to that interface specifically, so it would be surprising if it actually bound to a different, IPv6, interface instead. But it sounds like this might be an OS configuration issue. Can you just try disabling IPv6 on this machine if you aren't using it?

Burp User | Last updated: Jan 07, 2016 07:03PM UTC