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

resolve_hostname added db logging #2132

Merged
merged 3 commits into from Jul 22, 2013

Conversation

webstersprodigy
Copy link
Contributor

Simple change to resolve_hostname post module, just logging to db.

@wvu
Copy link
Contributor

wvu commented Jul 22, 2013

Is it really a good idea to clutter the hosts list with resolved hostnames?

@webstersprodigy
Copy link
Contributor Author

I think the most typical use for the resolve_hostname module would be post exploit where you would want IPs resolved internal hostnames that you can't get from outside. To use this with resource scripts you need a way to get the info back (e.g. say you have an internal hostname that doesn't resolve from outside and you want to programatically pivot). To me it seems like hosts list made the most sense as a place to save.

@wvu
Copy link
Contributor

wvu commented Jul 22, 2013

Yeah, @jvazquez-r7 and I discussed this a bit, and that's what we agreed on. Maybe make the logging optional? I dunno. There's also post/windows/recon/resolve_ip.

@wvu
Copy link
Contributor

wvu commented Jul 22, 2013

resolve_ip could use some fixin', too. The option descriptions are totally wrong.

@webstersprodigy
Copy link
Contributor Author

Yeah, I like optional logging better. Like if you're using this to see if internal hosts resolve google.com you don't want google added to hosts.

@wvu
Copy link
Contributor

wvu commented Jul 22, 2013

Yep!

@wvu
Copy link
Contributor

wvu commented Jul 22, 2013

I don't think the default option should be true, but that's just my opinion.

@webstersprodigy
Copy link
Contributor Author

I like default true, but I don't really care if it's changed to false either :)

@todb-r7
Copy link

todb-r7 commented Jul 22, 2013

Hey, most modules don't even ask. If you have a database, the least surprising thing would be to log it in a way that you can get at it from the hosts command.

@todb-r7
Copy link

todb-r7 commented Jul 22, 2013

Works for me, I can tell that fake local drivers/etc/hosts in fact resolve right.

msf post(resolve_hostname) > run

[*] fakehost resolves to 1.2.3.4
[*] www.metasploit.com resolves to 208.118.237.137

@todb-r7
Copy link

todb-r7 commented Jul 22, 2013

Also tested combining HOSTFILE and HOSTNAME works as expected (both are tried), and setting SAVEHOSTS false means the results aren't saved.

todb-r7 pushed a commit that referenced this pull request Jul 22, 2013
Also incidentally updated the description.
@todb-r7 todb-r7 merged commit aa159f1 into rapid7:master Jul 22, 2013
@wvu
Copy link
Contributor

wvu commented Jul 22, 2013

Thanks, @todb-r7!

@kernelsmith
Copy link
Contributor

Good place for a contributor-to-be to get their chops started.
I still think we need a good way to mark and track things like this that might be good for n00bz

On Jul 22, 2013, at 12:51 PM, wvu-r7 notifications@github.com wrote:

resolve_ip could use some fixin', too. The option descriptions are totally wrong.


Reply to this email directly or view it on GitHub.

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

Successfully merging this pull request may close these issues.

None yet

4 participants