Seperate results for seprate clients (feature discussion)

[brannondorsey]

It seems to me, given my limited experience with this tool and combing through the source, that the configuration of both the "round robin" and "dns rebind" behavior is "global". By that I mean that any client will trigger the DNS server to respond with it's next response IP address, rather than having programmed DNS responses maintained separately for separate client. E.g. If my dns.conf looks like this:

A some.website 192.168.200,192.168.1.1

And I make one DNS request from client A, with IP 170.30.28.50, I will receive a response of 192.168.200. If client B, with IP 180.33.250.79 then makes a request it would receive a response of 192.168.1.1.

If, however, I want to do a DNS rebind/round robin attack against multiple client IP addresses at once, it would be useful to "save program state" for each client. For instance, if I delivered a payload that sent one request to my server to GET the payload contents of an HTML file that contained JavaScript that made a second request (using the same domain name, but expecting it to resolve to an IP on the victim's local network), I would want to be able to deliver that payload to two separate clients/victims at the same time without worrying that their activity would interfere with each other. Does that make sense?

Essentially, I'd like the round robin and dns rebind functionality to be local to requesting IPs. If IP A requests once, I'd like it to return 192.168.200, and if IP B requests immediately after, I'd like it to also receive 192.168.200. The next time both of them make a DNS lookup it should resolve to 192.168.1.1 to both of them. Am I correct in assuming this is not how the tool currently works?

The reason I bring this up is that I would be happy to add this functionality, but wanted to first propose it here and discuss it. This is something that would be very useful to me in my research as it allows the tool to be used in a "production" scenario, where many different clients can be attacked at once without stepping on each other's toes so to speak.

[Crypt0s]

Hey thanks for the feedback!

FakeDNS does already allow this behavior I think:

Currently the rebind rules allow you to specify a number of times that FakeDNS will respond with the first record before returning the second, and this is handled on a per-client basis so that each client individually has to request the original DNS name in the rule that many times before the rebind kicks in.

[brannondorsey]

Thanks for getting back to me. I've been playing with FakeDNS for the past few days, and I've got to say, really nice work 👍.

I see that this behavior does in fact exist. However, it wasn't working in practice and it took me a while to figure out why. Turns out, my ISP's DNS servers were making the requests to the FakeDNS instance I had running in the cloud on my behalf. That's all fine and dandy, except for the fact that they were load balancing, switching the servers that were making the requests every few seconds. FakeDNS treated them each as separate clients (which indeed they were), even though they were all making requests on behalf of the same machine. This caused terribly irregular behavior as you can imagine. My solution was to identify unique clients by random subdomains instead of IP address like so. I took this little trick from jaqen, essentially having my payload JS embed iframes to {UUID}.attacker.com instead of attacker.com to keep victims seperate.

This solution solved the problem nicely and it is something that I can see others benefiting from in the future. That said, I implemented it in a relatively hacky way (by just swapping dictionaries keyed on IP addresses with ones keyed on domain names). If you are up for it, I think we could find a more elegant way of handling support for both of these behaviors in the cli (something I'm willing to implement). What do you think?

[brannondorsey]

One solution would be to include a --unique-by <ip|subdomain|both> cli param. --unique-by ip is the current behavior as is. --unique-by subdomain would be the version I've got in my fork, and --unique-by both would key the history object on ip + subdomain.

[Crypt0s]

This is a good idea! I'll have a think on it and review your proposed solution. One thing I'm considering is writing a more complex .ini-based rule system which would allow more granular stuff.

[Crypt0s]

Oh and thanks for helping and contributing!

[brannondorsey]

No problem, thanks for making such a rad tool. I'll be using it in my research for a while and I'm happy to help with development and discussion along the way.

Which brings me to another topic of discussion. I would be happy to open a new issue on this subject explicitly if that seems more appropriate. I bring it up here because you mention you are thinking of a new .ini system and wanted to throw this out there.

I'm developing a PoC that allows an attacker to deliver payloads to arbitrary machines on the victim's LAN by having them click on a malicious link to a domain whose DNS is controlled by FakeDNS. The PoC targets certain devices with known services (chromecast, roku, etc...) on known ports. The problem is that the attacker doesn't know the IP addresses that were allocated to to those devices by DHCP, so it naively sweeps large ranges of IP subnets (e.g. 192.168.1.1/24) with the payload, hoping at least one of those IPs belongs to the target device. Technically, I accomplish this with 256 different iframe embeds in the browser (for whatever reason, modern browsers don't find that fishy!)

So far, I've been accomplishing this w/ a dns.conf file that looks like so:

A attacker\.domain 189.39.42.89
# these regexes matches IP_OCTET.UUID.DOMAIN.TLD
A 2\..{36}\.attacker\.domain 189.39.42.89 1%192.168.1.2
A 3\..{36}\.attacker\.domain 189.39.42.89 1%192.168.1.3
A 4\..{36}\.attacker\.domain 189.39.42.89 1%192.168.1.4
A 5\..{36}\.attacker\.domain 189.39.42.89 1%192.168.1.5
A 6\..{36}\.attacker\.domain 189.39.42.89 1%192.168.1.6
#etc...
A 255\..{36}\.attacker\.domain 189.39.42.89 1%192.168.1.255

Having a 256 line dns.conf isn't really as bad as it sounds. That is, until you think about scaling this to larger subnets like 192.168.1.1/16. Or if you want more custom control like 10.0.0-5.0-127.

Ideally, it would be great if FakeDNS would support some sort of system of dynamically defining DNS resolution rules using the domain name itself. It would be great if I could make a request like:

192.168.1.48.ff3384d9-d594-4563-8e0f-ddb927ca1edb.attacker.domain

And know that it would resolve to 189.39.42.89 the first time and 192.168.1.48 every time after that. Going further, we could even take the approach of defining the entire rule in the domain name:

# correctly escaping/url-encoding of course
A_189.39.42.89_1%192.168.1.1,192.168.0.1.ff3384d9-d594-4563-8e0f-ddb927ca1edb.attacker.domain

note: I've omitted the regex part of the .conf line entry as it this url scheme would be self-referential (it defines it's own rule, therefore it wouldn't need to define the regex match that also satisfies itself).

This would be particularly nice because it would allow an attacker to generate new DNS resolution rules on the fly without needing to update the dns.conf.

Now, you might be thinking subdomain schemes like that would look pretty damn sketchy flying across the network, and I would agree with you! We could also add some base64 encoding support to obfuscate the dynamic rule like so:

# base64 encoded version of 
"A 189.39.42.89 1%192.168.1.1,192.168.0.1"
QSAxODkuMzkuNDIuODkgMSUxOTIuMTY4LjEuMSwxOTIuMTY4LjAuMQ==.ff3384d9-d594-4563-8e0f-ddb927ca1edb.attacker.domain

A label may contain zero to 63 characters. The null label, of length zero, is reserved for the root zone. The full domain name may not exceed the length of 253 characters in its textual representation. (From Wikipedia)

^ We might encounter issues with this occasionally, but we could probably come up with a work around.

Anyway, I wanted to propose this and discuss it a bit. Given that you are rethinking the configuration system, this seems like a great time to talk about including this kind of dynamic functionality. This would greatly increase the power and appeal of FakeDNS imho, especially in production attack/test scenarios. What are your thoughts?

[Crypt0s]

this is a great idea and I think a solution perfectly suited to fakeDNS. I'll call the behavior of generating rules on the fly from a DNS request the "automangler" feature and I can start banging that out soon I think.

Base64 looks weird too, maybe rot13? I'll try and make it able to handle several encodings maybe but start with one just to kick it off.

[Crypt0s]

I'm creating a new ticket for the automangler and leaving this open to address the unique issue.