Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Coverage differences between public and private Collaborator instances

Nicolas | Last updated: Apr 06, 2016 09:03PM UTC

I recently tested Collaborator using different injection scenarios. I noticed that the vectors used are different, depending if Collbaorator is defined by its DNS name (public or private instance) or its IP address (private only). Given the injection point "http://_HERE_:31337/yolo", only a private instance defined by its IP address will trigger a "Out-of-band resource load (HTTP)" event. Other ones will only trigger "External service load (DNS)". That's because, in the first case, a vector uses "[PRIVATE_COLLAB_IP]/[DYNAMIC_BURP_TOKEN]" and the target will connect to port TCP/80 and not TCP/31337. Why not add this check to other Collaborator modes?

PortSwigger Agent | Last updated: Apr 08, 2016 12:28PM UTC

If a user configures a private Collaborator server only by IP address, without a DNS domain assigned to it, then we can't use any DNS-based techniques to trigger or detect interactions. We can only use actual services (like HTTP) to connect to the IP address. For this reason, it is more effective to use a dedicated domain or subdomain for private Collaborator servers.

Burp User | Last updated: Apr 11, 2016 09:03PM UTC

I understand the limitations of an IP-based private Collaborator server, thanks ;-) My point is that, depending on the injection point, an IP-based instance may trigger additional connections (here "HTTP" vs "only DNS") than a DNS-based instance (public or not). So, in this scenario, the IP-based instance _is_ more effective than DNS ones.

PortSwigger Agent | Last updated: Apr 12, 2016 07:50AM UTC

Thanks for the follow-up, and apologies for misreading your original post. It looks like an unusual edge-case, due to the presence of the port number after the point where input is injected. The reason the IP-based Collaborator works better in this case is solely due to the presence of a slash in the resulting payloads. So if the payload used for a DNS-based Collaborator server included a slash after the injected domain name, it would trigger the HTTP interaction as well. Is that right? To be honest, I'm not sure if we will worry about this case. We don't want to add a trailing slash to our DNS-based payload, because that might break some other situations where it works. And we don't want to add an entire new payload just to cover this edge case. Since the DNS interaction still occurs in this situation, maybe the user can live without the HTTP one happening? What do you think? (At some point we will release some manual testing tools with Collaborator integration which would make following up cases like this much easier.)

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