Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Burp Collaborator: Polling server not started ?

Philippe | Last updated: Mar 07, 2017 12:05AM UTC

I am testing a private instance of Burp collaborator. The health check is failing. ## The error ## ``` Initiating health check Server address resolution Warning Polling server address resolution Success Polling server connection Error ``` ``` The capture server hostname el3oigq0cdf676pwcsfhfke15sb5po96d92.b.burp.me could not be resolved to an IP address. Ensure that an appropriate DNS entry exists for the server. No connections to the polling server at polling.burp.me could be opened. The collaborator will not work in this configuration. ``` ## DNS ## DNS queries are logged to the console of Burp Collaborator. But B.C. does not respond to the DNS query. ``` # nslookup AAA.b.burp.me Server: 8.8.8.8 Address: 8.8.8.8#53 ** server can't find AAA.b.burp.me: SERVFAIL ``` My DNS configuration ``` NS b.burp.me ns1.burp.me A ns1.burp.me 64.137.x.x A polling.burp.me 64.137.x.x ``` ## Polling server ## For some reason the polling server is not started (port 9090, 9443) ``` > netstat -na tcp6 0 0 :::25 :::* LISTEN tcp6 0 0 :::443 :::* LISTEN tcp6 0 0 :::587 :::* LISTEN tcp6 0 0 :::80 :::* LISTEN tcp6 0 0 :::465 :::* LISTEN tcp6 0 0 :::22 :::* LISTEN udp6 0 0 :::53 :::* ``` ## Log ## ``` 2017-03-06 16:39:41.977 : Listening for HTTP on 80 2017-03-06 16:39:41.979 : Listening for DNS on 53 2017-03-06 16:39:41.981 : Listening for SMTP on 25 2017-03-06 16:39:41.982 : Listening for SMTP on 587 2017-03-06 16:39:42.111 : Listening for HTTPS on 443 2017-03-06 16:39:42.136 : Listening for SMTPS on 465 2017-03-06 16:39:50.079 : Request received: A0CF... 2017-03-06 16:39:50.101 : Sending response: A0CF... ``` No error / warning. Afterword, DNS queries are received and logged. ## Complete configuration ## Since the application does not log anything special, here is my complete configuration : ``` { "serverDomain" : "b.burp.me", "workerThreads" : 10, "eventCapture": { "localAddress" : ["64.137.x.x", "127.0.0.1"], "publicAddress" : "64.137.x.x", "http": { "ports" : 80 }, "https": { "ports" : 443 }, "smtp": { "ports" : [25, 587] }, "smtps": { "ports" : 465 }, "ssl": { "certificateFiles" : ["burp.me.key.pkcs8", "www.burp.me.crt"] } }, "polling" : { "localAddress" : "127.0.0.1", "publicAddress" : "64.137.x.x", "http": { "port" : 9090 }, "https": { "port" : 9443 }, "ssl": { "hostname" : "polling.burp.me" } }, "metrics": { "path" : "....", "addressWhitelist" : ["1.2.3.4"] }, "dns": { "interfaces" : [{ "name":"ns1", "localAddress":"64.137.x.x", "publicAddress":"64.137.x.x" }], "ports" : 53 } } ```

Liam, PortSwigger Agent | Last updated: Mar 08, 2017 03:16PM UTC

Hi Phillippe, Thanks for your message. At the moment foo.b.burp.me is resolving to 184.168.221.34 and polling.b.burp.me is resolving to 184.168.221.61. However, it loos like there is an IIS server running instead of the Burp Collaborator server. Burp collaborator needs to be launched on a server that has nothing bound to ports 80 and 443. Please let us know if you need any further assistance.

Burp User | Last updated: Mar 08, 2017 06:02PM UTC

@Liam Tai-Hogan Burp.me is not the domain name I use.

PortSwigger Agent | Last updated: Mar 09, 2017 08:39AM UTC

Hi Philippe, Thanks for getting back to us. The configuration you provided looks good to us, it might be a problem with your infrastructure. To attempt to diagnose the problem, can you run the following commands and see if any of them resolve? Replace 64.137.x.x with your public collaborator IP. If none of them worked, you can also execute them from the Burp Collaborator server box. $ dig b.burp.me @64.137.x.x $ dig random.b.burp.me @64.137.x.x $ dig polling.b.burp.me @64.137.x.x $ dig +trace b.burp.me If none of them work, you can diagnose if the queries are reaching the server, by executing from the Burp Collaborator server: $ tcpdump -vvv -s 0 -l -n port 53 The Burp Collaborator server should be responding to the queries if the subdomain you are querying matches the one in your config file. Also, make sure you are executing the jar with the command line argument --collaborator-config=myconfig.config Please let us know if you need any further assistance.

PortSwigger Agent | Last updated: Mar 09, 2017 08:54AM UTC

Hi Philippe, Thanks for getting back to us. We are glad to hear that we are on the right track towards fixing this. It appears that Burp Collaborator is unable to read the data of the certificates. Can you please check for us if the content of the certificates looks correct? If you read the files www.h3x.in.crt and intermediate.crt you should see a BEGIN CERTIFICATE and END CERTIFICATE block with base64 encoded data. You can also run the following command to validate that the certificate data is not corrupted: bc. $ openssl x509 -in www.h3x.in.crt -text -noout $ openssl x509 -in intermediate.crt -text -noout For the private key, in your h3x.in.key.pkcs8 file, you should see a BEGIN PRIVATE KEY END PRIVATE KEY, without the word ENCRYPTED. You can validate that it is correct by running: bc. $ openssl rsa -in h3x.in.key.pkcs8 -check It should output: 'RSA key ok'. Hopefully, this will help to diagnose the certificates issue. Please, let us know if you need further assistance.

Burp User | Last updated: Mar 09, 2017 07:05PM UTC

I am passing the configuration file in the argument: > java -Xms10m -Xmx200m -XX:GCTimeRatio=19 -jar burpsuite_pro.jar --collaborator-server --collabotor-config=config.json The DNS requests are reaching the Burp collaborator instance. I have not idea what are the response. For instance : ``` # dig AAAA.b.xxx.in ; <<>> DiG 9.9.5-3-Ubuntu <<>> AAAA.b.xxx.in ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34436 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;AAAA.b.xxx.in. IN A ;; Query time: 172 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Mar 09 13:56:22 EST 2017 ;; MSG SIZE rcvd: 42 ``` Does produce : ``` 2017-03-09 13:56:22.269 : Request received: 68DC000000010000000000010441414141016203XXXX0000010001000029100000008000000B00080007000118004089D9 2017-03-09 13:56:22.271 : Sending response: 68DC800500010000000000000441414141016203XXXX0000010001 2017-03-09 13:56:22.300 : Request received: 5C70000000010000000000010441414141016203XXXX00000100010000291000000080000000 2017-03-09 13:56:22.302 : Sending response: 5C70800500010000000000000441414141016203XXXX0000010001 2017-03-09 13:56:22.331 : Request received: 0F80000000010000000000000441414141016203XXXX0000010001 2017-03-09 13:56:22.333 : Sending response: 0F80800500010000000000000441414141016203XXXX0000010001 ``` I would be expecting the Burp collaborator DNS handler to respond with its own IP to receive potential request..

Burp User | Last updated: Mar 09, 2017 07:12PM UTC

According to Wireshark it is responding Server failure.

Burp User | Last updated: Mar 09, 2017 07:45PM UTC

Here is my exact configuration: ``` { "serverDomain" : "b.h3x.in", "workerThreads" : 10, "eventCapture": { "localAddress" : ["64.137.209.103", "127.0.0.1"], "publicAddress" : "64.137.209.103", "http": { "ports" : 80 }, "https": { "ports" : 443 }, "smtp": { "ports" : [25, 587] }, "smtps": { "ports" : 465 }, "ssl": { "certificateFiles" : ["h3x.in.key.pkcs8", "www.h3x.in.crt", "intermediate.crt"] } }, "polling" : { "localAddress" : "127.0.0.1", "publicAddress" : "64.137.209.103", "http": { "port" : 9090 }, "https": { "port" : 9443 }, "ssl": { "hostname" : "polling.h3x.in" } }, "metrics": { "path" : "Q6ZQlnTmaVyCPf0lx1Jr" }, "dns": { "interfaces" : [{ "name":"ns1", "localAddress":"64.137.209.103", "publicAddress":"64.137.209.103" }], "ports" : 53 } } ```

Burp User | Last updated: Mar 09, 2017 08:10PM UTC

I just realized I had a typo in the argument passed to burp.

Burp User | Last updated: Mar 09, 2017 08:12PM UTC

I now have the error : "No certificates specified. The certificateFiles parameter, if specified, should contain at least one certificate."

Burp User | Last updated: Mar 09, 2017 08:53PM UTC

I do not understand the certificate error.. Two workarounds I needed: 1. The polling server only listen to the local address (bug?). I set my publicAddress to the local one in order to expose the port. "localAddress" : "64.137.X.X", 2. The suggested configuration use 9090 and 9443 () while the Burp Health Check is using 80 and 443. Configure Burp Health Check to use "IP:9090" explicitly

PortSwigger Agent | Last updated: Mar 10, 2017 09:51AM UTC

Hi Philippe, We are glad that you managed to get your Collaborator server working. We will look into improving the error handling of the Collaborator server so that it is easier to debug in the future. Let us know if you have further queries. Cheers.

Burp User | Last updated: Mar 10, 2017 07:59PM UTC

Thanks a lot Guifre ! That was it. The PKCS8 key was in the right format. The certificate was in DER format. Burp is expecting PEM. The following conversion worked: ``` openssl x509 -in mycert.crt -out mycert.crt.pem -inform DER -outform PEM ```

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