Burp Collaborator always only gets 127.0.0.1 as source for lookups

[schniggie]

Hi,

I really like knary but since ever I got the problem, that when combining/integrating knary with a private Burp Collab instance, the IP information is lost when knary forwards the request to the Collab instance, see:

Is there a way to fix this behaviour?

[sudosammy]

Hi! Thanks for your issue. It comes at a very interesting time because I was just debating whether or not to remove burp collab support in the future versions of knary! We found so many issues (similar to this one) when using knary with burp I often think it would be easier just to axe support for it 😂

Can you send me your .env file (with domains redacted) so I can try to reproduce?

[schniggie]

cat .env

DNS=true
HTTP=true
BIND_ADDR=0.0.0.0
#BIND_ADDR=172.31.1.100
EXP_IP=88.999.125.999
CANARY_DOMAIN=redacted.de
TLS_CRT=/etc/letsencrypt/live/dns.redacted.de/fullchain.pem
TLS_KEY=/etc/letsencrypt/live/dns.redacted.de/privkey.pem
SLACK_WEBHOOK=REDACTED

DEBUG=true
LOG_FILE=knary.log
BLACKLIST_FILE=blacklist.txt

BURP=true
BURP_DOMAIN=burp.dns.redacted.de
BURP_DNS_PORT=8053
BURP_HTTP_PORT=8080
BURP_HTTPS_PORT=8443

[sudosammy]

Hi there! I think I have fixed this in the dev branch. https://github.com/sudosammy/knary/tree/dev - The new version of knary requires a change in how the DNS is setup though. It should hopefully be easier now as you only need to point your domain's name servers to ns.redacted.de and set the glue record to your knary server. knary is now its own root nameserver for all requests *.redacted.de rather than only for *.dns.redacted.de.

If you're keen to try it out, git clone && git checkout dev, do the DNS setup as detailed in the dev README and run knary using your existing .env config.

[schniggie]

Hi sorry for my delay. Just pulled the dev branch and compiled it. Now facing the following issue:

/home/burp/knary# ./knary
 __
|  |--.-----.---.-.----.--.--.
|    <|     |  _  |   _|  |  |
|__|__|__|__|___._|__| |___  |
 @sudosammy     v3.3.0 |_____|

[+] Listening for http(s)://*.offsec-testzone2.xxx.net requests
[+] Listening for *.offsec-testzone2.detss.xxx.net DNS requests
[+] Working in collaborator compatibility mode on subdomain *.burp.offsec-testzone2.xxx.net
[+] Posting to webhook: https://matter.xxx.com/hooks/XXX
[+] Checked for updates
[+] Sent heartbeat message
[+] Got A question for: test1337.offsec-testzone2.xxx.net.

So

dig test1337.offsec-testzone2.xxx.net +short
xx.48.xx.20

works fine.

However when tying the burp forwarded subdomain it fails:

/home/burp/knary# ./knary
 __
|  |--.-----.---.-.----.--.--.
|    <|     |  _  |   _|  |  |
|__|__|__|__|___._|__| |___  |
 @sudosammy     v3.3.0 |_____|

[+] Listening for http(s)://*.offsec-testzone2.xxx.net requests
[+] Listening for *.offsec-testzone2.detss.xxx.net DNS requests
[+] Working in collaborator compatibility mode on subdomain *.burp.offsec-testzone2.xxx.net
[+] Posting to webhook: https://matter.xxx.com/hooks/XXX
[+] Checked for updates
[+] Sent heartbeat message
[+] dial udp xx.77.xx.10:51879->127.0.0.1:8053: bind: cannot assign requested address
[+] dial udp xx.77.xx.10:38066->127.0.0.1:8053: bind: cannot assign requested address

The error is raised by:

dig test.burp.offsec-testzone2.xxx.net +short

Burp collab is running and DNS is listening on 8053, see:

ss -tulpen | grep 8053
udp   UNCONN 0      0        [::ffff:127.0.0.1]:8053            *:*    users:(("java",pid=1669360,fd=21)) ino:5923798 sk:28 cgroup:/system.slice/cron.service v6only:0 <->

I am confused :)

[sudosammy]

Hey! Sorry I didn't see this sooner, must have just missed the email. Right. I see why this is happening. This is going to be harder to fix than I thought haha. Might need to create a packet from source: https://pkg.go.dev/github.com/google/gopacket?utm_source=godoc#hdr-Creating_Packet_Data

... Hmm.. I think I'll move to release version 3.3.0 without this fix in it and then focus on it

[schniggie]

Just saw you pushed a new release. I assume this issue here is still open, based on the changelog items or should I give it a try?

[sudosammy]

No unfortunately I suspect this is still an issue in the 3.x brach. I will check it out more soon :)

[sudosammy]

Hi, does the latest version of knary v3.4.1 report the correct IP address to burp for HTTP(S) requests?