Add the ability to use a custom (fake) DNS resolver #240
Conversation
This adds a custom resolver, that will always resolve to the specified ip address. The intended usage is for when doing name-based scans, but have a specified IP address as well. This will provide a resolver that can be added to a Dialer, that will cause all DNS lookups to match the specified IP address.
There was a problem hiding this comment.
Comparing this to #241:
- We get the correct URL output, whereas Use host header, and always connect to IP #241 does not
- We handle the case where we get redirected back to the same host, whereas Use host header, and always connect to IP #241 does not
I think the behavior here is objectively better, although the PR is a bit scarier.
More fundamentally, I think this exposes that ZGrab2 output and perhaps the core scan model it uses doesn't handle HTTP nicely. We try to think of HTTP redirects as part of one scan, but since they can change hosts and ports, it doesn't fit into our current output model.
From a code standpoint, it also means that we have to do stuff like this, rather than just specifying at the module level "connect to this host with these parameters", like we would if we scanned 10 hosts in an input file, rather than 10 hosts as part of a redirect.
At any rate, I'd still merge this one rather than #241.
If both an IP address and a domain are specified for a scan, have the HTTP scanner use a fake resolver in the DialContext, so that we always scan the intended IP and Domain name pair. However, make sure redirects still function as normal, so only use our fake resolver if the domain name matches the original targeted domain name. In addition, the custom resolver is only used if the network specified is one that supports domain names.
6955920 to
82da88e
Compare
|
Some wireshark captures: Command: Command: |
| } | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
This hunk (lines 164-181) addresses the concerns @justinbastress raised, and also adds an additional check against the specified network (similar to what internetAddrList does in the go net library)
There was a problem hiding this comment.
I think I follow -- this dialContext gets called by the HTTP lib for all redirects, and it can decide to pass in the addr as a hostname(?!):port; if the redirect is to our "pinned" host, set a custom resolver for this connection only (a subsequent redirect leads to another dialContext, another Dialer, etc). If it's to another host, we use the default resolver (but if that host redirects back to our pinned host, we are again by another call to this).
|
I like this, and I think it's better than #241 |
3361415 to
0b6845e
Compare
When performing HTTP scans with a domain name, we want to be able to scan that domain name with the specified IP address. Currently, if a domain is specified, the IP address is ignored and we scan whatever the name resolves to.
This adds a fake resolver, that can be attached to a Dialer and cause the http connection to always return the IP address we specify. In the scanner, this also checks that the intended domain name we are about to connect to in our dialContext matches the original target domain name; if it does not, we do not attach the custom/fake resolver.
How to Test
This should return valid results. Replace the IP address with something like 127.0.0.1:
Assuming no web server is running there, it will return a failure.