putsi – Team ROT Information Security / Team ROT Information Security Tue, 05 Jan 2021 07:13:29 +0000 en-US hourly 1 https://wordpress.org/?v=6.2 /wp-content/uploads/2020/08/cropped-ROT2-WHITE-BG.eps_-2-32x32.png putsi – Team ROT Information Security / 32 32 Custom HTML on private collaborator domain /1692/ Mon, 04 Nov 2019 20:52:46 +0000 /?p=1692 .flex_column.av-2m3618-b829f09cdcce6639a67e296daeb7f0a1{ -webkit-border-radius:0px 0px 0px 0px; -moz-border-radius:0px 0px 0px 0px; border-radius:0px 0px 0px 0px; padding:0px 0px 0px 0px; }

Serving custom HTML on private collaborator domain

Note: Portswigger has now added support for custom HTML so this blog post is not needed!

https://portswigger.net/burp/documentation/collaborator/deploying#adding-custom-content-to-your-collaborator-server


Hosting a private Burp Collaborator on custom domain can be very handy. It allows you for example to bypass WAFs, to use it on closed networks, to use different port numbers, to appear more professional with branded domain and so on. However it currently has some limitations, one of them being the hard-coded index page. When the collaborator domain is accessed without using any actual collaborator subdomain, a generic web page like above will be shown to the user.
It would be useful to be able to customize this. For example, the default page could instruct viewers how to contact the collaborator owner. Another example would be serving any additional payload files from the same domain.
According to Portswigger support, there is a feature request for customizing it but currently there is no supported way to serve custom content. There are hackish ways to achieve it, but not all are working as intended so let’s take a look how not to do it and how to actually do it.

Wrong ways to implement

An easy way would be using Nginx or HAProxy between the user and collaborator and making it proxy HTTP-requests from collaborator subdomains to collaborator and proxy other subdomains to web server (or serve directly the custom content). This however will lose the user’s IP for HTTP-requests as the Nginx’s/HAProxy’s IP will be shown on all HTTP-request interactions in collaborator.

Another easy way would be using a DNS-proxy which points some specific subdomains to the web server and proxies DNS-queries for all other subdomains to the DNS-server in collaborator. This will lose the user’s IP for DNS-requests as the DNS-proxy’s IP will be shown on all DNS-request interactions in collaborator.

Working way to serve custom html

Well how can we do this without losing the original IP on DNS-request and HTTP-request? Linux kernel supports Netfilter Queue which provides an API for viewing, modifying and dropping packets directly from the Kernel Packet Filter queue. It can be used along with Scapy to transparently inspect DNS-queries and to return fake DNS-replies.
Basically we’ll need to make NFQueue intercept all packets to port 53/UDP (DNS), then parse the DNS-request inside the packet. Then we’ll need to check if the DNS-request is for A-record and what (sub-)domain is it asking for. This (sub-)domain will then be checked against a list of (sub-)domains (e.g. collab.fi and www.collab.fi). If it doesn’t match any (sub-)domain on the list, the packet will be passed back on the queue without any modifications. If it matches something on the white list, Scapy will be used to create a fake DNS-reply pointing towards our web server. This fake DNS-reply will then be sent back to the source and the original packet will be dropped. It’s not actually that hard to do and now there is a script for doing all that automatically!
There are still some limitations with this method, as it fakes the DNS-replies you’ll need to have two IPs. One IP is associated with your collaborator domain and another IP is associated with the web server that you want to serve the custom html with. You don’t need two different virtual machines, having two public IPs on single VM should be enough. Collaborator listening on the first IP and web server listening on the second IP. Please let me know if there is a way to make this work with a single IP!

How to do this automatically

If you installed your private collaborator using the previous guide, you should still have the privatecollaborator-directory. Run git pull inside the directory and you should get the latest code including a new extendburp-directory. The directory contains an installation script, systemd service and dnsmitm.py-script which implements the actual magic.
To install, simply open the extendburp-directory and run the following command:  ./extend_burp.sh TARGET_IP COLLABORATOR_DOMAIN
The TARGET_IP-parameter should be IP of the web server that will serve the custom content and COLLABORATOR_DOMAIN-parameter is your private burp collaborator domain.
After the script is done, your server should respond to DNS-queries in the following way thus redirecting the user to correct HTTP-destination:

  • DNS-query for www.yourcustomdomain.com -> Returns IP of the web server.
  • DNS-query for yourcustomdomain.com -> Returns IP of the web server.
  • DNS-query for AnythingElseLikeCollaboratorId.yourcustomdomain.com -> Returns IP of the Burp Collaborator.

In case you want to redirect more subdomains to the web server, simply insert those in the dnsmitm.py script.
Over and out –putsi.

]]> Self-hosted Burp collaborator with custom domain /self-hosted-burp-collaborator-with-custom-domain/ Thu, 23 May 2019 22:15:55 +0000 /?p=1558

Self-hosted Burp collaborator for fun and profit


The Burp Suite Collaborator is a valuable tool for penetration testers and bug bounty hunters. It basically gives you unique subdomains and logs all interactions (DNS, HTTP(S), SMTP(S)) towards the subdomains. This can be used for example to detect SSRF-vulnerabilities and exfiltrate data.
Burp Suite Professional provides a collaborator service under the domain burpcollaborator.net and using it is usually fine. However on the rare occasions it can be blacklisted / blocked or otherwise unreachable from the target. Luckily, the Burp collaborator can also be self-hosted and set to use a whole custom domain.
This blog post guides how to set up private Burp Collaborator instance on Amazon AWS and how to configure it to use a whole domain with a free Let’s Encrypt SSL-certificate.
Note: If you’d like to use DigitalOcean instead of AWS, the automation script supports also that (with and without floating IP).
If you’d like to use some completely other IaaS-platform, make sure that the VM’s network interface IP matches the public IP and the script should yet again work.

Step 1: Create AWS Instance and Elastic IP

TL;DR: Create Ubuntu Server 18.04 instance and assign Elastic IP to it. Allow inbound SMTP(S), HTTP(S) and DNS from everywhere and ports 9090&9443 from your own IP.
First we’ll need to create a virtual machine for the Collaborator. Log in to your AWS-account and follow the steps:

  1. First, lets create the virtual machine.
  2. Navigate to Instance wizard and select Ubuntu Server 18.04 LTS (HVM), SSD Volume Type.
  3. Select t2.micro or t3.micro depending on which has the free tier eligible tag on your AWS region. Then click Next: Configure Instance Details.
  4. Uncheck T2/T3 Unlimited as it might cause some expenses and then click Next: Add Storage.
  5. Go with default size and click Review and Launch.
  6. Click Launch.
  7. Create a new keypair and download it and click Launch instances.
  8. Next, lets create free-tier eligible Elastic IP. This allows us to always have a static IP which can be linked to AWS virtual machines. Its not required but it makes things easier if you need to re-create your virtual machine.
  9. Navigate to Allocate new address and click Allocate.
  10. Go back to the Elastic IP List, right click your Elastic IP, and Associate Address to the virtual machine created in the previous steps.
  11. Next, go to Instances and click your instance. On bottom of the page, click the Security Group and it should open.
  12. Create Inbound rules like in the image below. Use your own PC IP for the port 9443 and 9090 as you don’t want anyone else using your collaborator.

Step 2: Configure the collaborator domain

Next we’ll have to configure the domain to have the Elastic IP as nameserver. Most providers require two unique nameservers so we will use one.one.one.one as the second one. If your domain is registered on GoDaddy, see here for GoDaddy-specific instructions, otherwise follow the steps below.

  1. First, find out hostname for your Elastic IP. You can for example use MxToolbox and it should give you something like ec2-00-00-00-00.eu-north-1.compute.amazonaws.com.
  2. Next, add nameservers for your collaborator domain in domain registrar settings. Use hostname from the previous step as first nameserver and one.one.one.one as second nameserver:
  3. Done! All DNS-queries towards your private collaborator domain should now end up in the Elastic IP.

Instructions for domains registered in GoDaddy:

  1. Go to My Domains on GoDaddy.
  2. Click the three black dots next to your collaborator domain and then click Manage DNS.
  3. In Advanced Features section click the Host names.
  4. Add ns-host with your Elastic IP:
  5. Next, modify the domain nameservers on the DNS Management page. Select Custom and set ns.YOUR_COLLABORATOR_DOMAIN as first one and one.one.one.one as second one:
  6. Done! All DNS-queries towards your private collaborator domain should now end up in the Elastic IP.

Step 3: Configure the virtual machine

Next you’ll need to fetch Let’s encrypt certificate and configure the virtual machine and do some other stuff. There’s a script for it so let’s use that. The script also implements automatic certificate renewal so you don’t have to manually renew the Let’s Encrypt every 90 days.

  1. First, use the keypair you downloaded to log in to the virtual machine:
    • chmod 0600 newpair.pem
    • ssh -i newpair.pem ubuntu@YOUR_ELASTIC_IP
  2. Clone the scripts:
    • git clone https://github.com/putsi/privatecollaborator && cd privatecollaborator
  3. Copy your Burp Suite Professional JAR-file to the privatecollaborator-directory.
    • scp -i newpair.pem /your/own/pc/burp.jar ubuntu@YOUR_ELASTIC_IP:~/privatecollaborator/
  4. Run the installer script and place your domain as a command line parameter. The email is for Let’s Encrypt expiry notifications and can either be a valid one or a non-existing one:
    • sudo ./install.sh collab.fi your@email.fi
  5. Accept any package installations that the script suggests and also enter your email address for Lets Encrypt notifications.
  6. Let’s Encrypt should now succeed creating a certificate for you. If it fails, you can try to run the install-script again couple of times. If it still fails, your domain DNS configuration from earlier steps most likely hasn’t refreshed yet. If that’s not the case, check your domain DNS configuration for typos and also check the security group inbound rules for port 53.
  7. You can now start the Burp collaborator service.
    • sudo service burpcollaborator start

Step 4: Configure Burp Suite

If you didn’t do it already on previous step, start the private collaborator by running: sudo service burpcollaborator start. Then check logs with sudo systemctl status burpcollaborator. It should tell you about listening on various ports and should not show any errors.
Next start up your Burp Suite and open Project Options -> Misc. Set up the private collaborator config according to the below image, but using your own domain instead of collab.fi:

Then click Run health check and wait for results. It should succeed on everything else than inbound SMTP (this is due to AWS policies):

If everything was OK, you should now be able to use the private collaborator instance normally on Burp Suite:

Conclusions

We made it! It works!
Now you can for example add more non-standard ports to the configuration or do whatever else you might imagine.
In the future, this blog post will hopefully be updated on the subject of how to extend the Collaborator. Potential subjects include:

  • Capturing interactions for protocols other than DNS, HTTP(S) and SMTP(S).
  • Serving custom content as HTTP(S)-response.
  • Dockerize the whole process.
  • Run as a less-privileged user and properly set iptables redirections.
  • Create a single-click setup for AWS.
  • Something else? Let us know what you’d like to learn and we will see if we can help.

Over and out –putsi.

]]> Hello world /first-blog-post/ /first-blog-post/#respond Mon, 16 Jan 2017 09:56:22 +0000 https://rotfi.wordpress.com/?p=4 Let’s try doing some public disclosures and CTF writeups here.
Posts are written by members of team ROT.

]]> /first-blog-post/feed/ 0