Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automangler #22

Open
Crypt0s opened this issue Mar 23, 2018 · 9 comments
Open

Automangler #22

Crypt0s opened this issue Mar 23, 2018 · 9 comments
Assignees

Comments

@Crypt0s
Copy link
Owner

Crypt0s commented Mar 23, 2018

Allow special DNS requests to indicate that FakeDNS should handle them with a rule system embedded within the request itself -- automatically mangling the request based on the request itself.

@Crypt0s Crypt0s self-assigned this Mar 23, 2018
@brannondorsey
Copy link
Contributor

Great to hear you are on bored with this functionality 👍. Rot13 sounds like a nice solution for obfuscation, especially considering it doesn't add any extra characters. It would probably be nice to have the obfuscation optional as the non-rot13 version would likely be useful for debugging and dev. I'd imagine the flag for rot13/not-rot13 would also have to be embedded in the domain name itself as well.

Should we chat here about the format these requests would take? So far, my initial proposal would be something like this:

# 1st ip, number of times to return 1st ip, 1st rebind ip, second rebind ip, UUID, domain
189.39.42.89_1%192.168.1.1,192.168.0.1.ff3384d9-d594-4563-8e0f-ddb927ca1edb.attacker.domain

Not saying that is necessarily the best method/syntax, plus it uses reserved % and , URL characters, but it illustrates the idea (original proposal here).

Here are some things to consider:

  • We probably need a flag in the request to tell FakeDNS "hey, this is an automangler request, ignore your config and treat it as such"
  • We need a flag for the presence of rot13 (or whatever obfuscation we use)
  • We need to be able to define the initial response IP in the request
  • We need to be able to define rebind and round-robin response IPs in the request
  • We don't need to define a match pattern as the request itself will always satisfy that pattern (i.e. we don't need to say A example.com 189.39.42.89 in the request, just 189.39.42.89.

We should keep in mind that each subdomain/label has a max of 63 characters and the entire domain name can't be greater than 255.

One thing that I love about this feature is that it means that separate parties can share a single FakeDNS instance running in the cloud as neither of them need access to the install/config file to generate their malicious requests. That is awesome because it decreases the barrier-to-entry to use FakeDNS / experiment with DNS rebinding attacks. In fact, I just registered rebind.network for that very purpose (well, still not sure if it's a good idea to publicly advertise a malicious DNS server for the world to use... but maybe, haha).

Request for comments?

@Crypt0s
Copy link
Owner Author

Crypt0s commented Mar 28, 2018

OK, I have an idea but this is where it gets tricky

DNS specifies that each dot in the domain name is a "label" which has it's own length and can even have it's own encoding -- see IDNA and international domain names outside of ASCII (https://en.wikipedia.org/wiki/Internationalized_domain_name#ToASCII_and_ToUnicode)

I suggest that by making the first label (subdomain) a known, FakeDNS-only value which denotes a rule-query, then have each successive label build the rule, and have IP addresses converted from decimals to bytes. An example is this:

A example.com 189.39.42.89

becomes

FAKEDNS.A.example.com.BD.27.2A.59.attacker.domain

where optionally rot-13 is applied to everything up to the IP address section.
This does get a little trickier when we bring IPv6 lookup into the mix which is why instead of using labels to separate all rule elements, we could also use delimiters such as .0F0F0F00F. or some other "unique" value to separate rule areas.

@Crypt0s
Copy link
Owner Author

Crypt0s commented Mar 28, 2018

I wonder if there are legitimate uses for such a service? Something something something cloudflare.

@brannondorsey
Copy link
Contributor

FAKEDNS.A.example.com.BD.27.2A.59.attacker.domain

  • FAKEDNS makes sense to have a constant here, but would that have to be "FAKEDNS"? Or is the goal just to signify that the domain name is an automangled domain that contains instructions to be followed? What if we made the value of this constant user definable, is that silly?
  • We don't need example.com to be in the domain right? In the current usage of FakeDNS this is required because regexes map to rules. But with the automangler, domains define their own rule, so including a traditional domain is unnecessary and actually serves no purpose.
  • Do you suggest the byte representation of IPV4s for light obfuscation or some other reason? It would likely still be helpful to see non-byteified IPs for debugging and illustration.

It would also be useful to include arbitrary labels in-between the rule definitions and attacker.domain (a method I've been using for keeping "clients" separate). We could move the FAKEDNS constant to act as this sort of separator between the automangler rule and the rest of the domain.
Something like:

A.189.39.42.89-1%192.168.1.1.FAKEDNS.5e934108-5999-40ee-9f96-32bf0e5f9699.attacker.domain
A.189.39.42.89-1%192.168.1.1.FAKEDNS.some-subdomain.attacker.domain
A.189.39.42.89-1%192.168.1.1.FAKEDNS.attacker.domain

Where do DNS rebind and round robin rules fit into your proposed URL schema? % and , are not allowed in domain labels, so that's off the table I think. There are two solutions I can think of that might work nicely...

What if we opted for human-readable rule labels like:

189.39.42.89.1time.192.168.1.1.forever.FAKEDNS.some-subdomain.attacker.domain
189.39.42.89.1time.192.168.1.13.5times.192.168.1.1.forever.FAKEDNS.some-subdomain.attacker.domain

Another option is that we could opt for implicit barriers between IPs due to their fixed length and replace the current config's % (used for rebind rule definition e.g. 10%) with the allowed '-' character.

# in full urls, these could look like
A.189.39.42.89.10-192.168.1.1.FAKEDNS.attacker.domain #rebind
A.189.39.42.89.192.168.1.1.192.168.1.13.FAKEDNS.attacker.domain #round robin

@brannondorsey
Copy link
Contributor

brannondorsey commented Mar 28, 2018

I wonder if there are legitimate uses for such a service? Something something something cloudflare.

How exactly do you mean legitimate? Penetration testing would def be my most use case. Or do you mean existing service that does this? I haven't ever heard of one, but maybe... I've never used cloudflare before.

@brannondorsey
Copy link
Contributor

It looks like Tavis Ormandy's rbndr actually provides this type of functionality. He's got a public server up that allows anyone to use his malicious DNS server too: https://lock.cmpxchg8b.com/rebinder.html

Granted, his implementation doesn't feature some of the features we are talking about here.

@Crypt0s
Copy link
Owner Author

Crypt0s commented Mar 30, 2018

Goal was any constant value -- user definable is probably a good idea!

We don't need example.com to be in the domain right? In the current usage of FakeDNS this is required because regexes map to rules. But with the automangler, domains define their own rule, so including a traditional domain is unnecessary and actually serves no purpose.

That's true, I must not have been paying attention.

Do you suggest the byte representation of IPV4s for light obfuscation or some other reason? It would likely still be helpful to see non-byteified IPs for debugging and illustration.

I suggest it because this way because it's less space, lightly obfuscated, and also because it could be combined into one "label" with no dots in between. You can't do that with the decimal numbers. I really wasn't paying attention when I made the example rule because I should have removed the dots in between the octets. This makes the rule a little more compact to eyeball.

Where do DNS rebind and round robin rules fit into your proposed URL schema? % and , are not allowed in domain labels, so that's off the table I think. There are two solutions I can think of that might work nicely...

of the two, i like using keywords the most but in the comment above i also suggest using some uncommon hex keywords as well.

Probably we don't have to do any worries about obfuscation if we enable rot-13 as an option.

@brannondorsey
Copy link
Contributor

Hey @Crypt0s, I've implemented this basic functionality as a standalone DNS server called whonow. I opted for the human-readable version of the automangler rules proposed and went with a keep-it-simple-stupid philosophy to the package: It does one one thing and one thing only. I wrote it in Node.js, but the functionality should be pretty easy to convert 1-to-1 into python if you feel so inclined.

I didn't mean to fork our efforts, I just needed this functionality quickly for some of my research and opted to spend the afternoon rolling it myself. Feel free to lift whatever ideas + code you like from that repo (or of course, contribute to it). This could also serve as a nice first version that we can both play with and learn what needs improving/how this system works in general.

@Crypt0s
Copy link
Owner Author

Crypt0s commented May 3, 2018

brannon:

no worries! I'll check out your implementation and mention you in the code/commits for the idea :)
Sorry I'm so slow! I have a few projects going on right now. Cheers!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants