Screwed up metasploit / ruby

[hawaii67]

Well, I did an "update all" in fast-track and it looks like I screwed up something.
When I want to start msfconsole I get this error:

bt framework3 # ./msfconsole
/usr/lib/ruby/1.8/resolv.rb:228:in `getaddress': no address for À¨²À (Resolv::ResolvError)
        from /usr/lib/ruby/1.8/resolv.rb:199:in `getaddress'
        from ./lib/rex/socket.rb:142:in `getaddress'
        from ./lib/rex/socket.rb:191:in `resolv_nbo'
        from ./lib/msf/core/payload.rb:297:in `substitute_vars'
        from ./lib/msf/core/payload.rb:276:in `each_pair'
        from ./lib/msf/core/payload.rb:276:in `substitute_vars'
        from ./lib/msf/core/payload.rb:494:in `internal_generate'
        from ./lib/msf/core/payload.rb:259:in `generate'
         ... 15 levels...
        from ./lib/msf/base/simple/framework.rb:71:in `create'
        from ./lib/msf/ui/console/driver.rb:67:in `initialize'
        from ./msfconsole:78:in `new'
        from ./msfconsole:78

Of course I reinstalled metasploit, ruby, rebootet the box, etc. but nothing helped.
Can somebody please give some suggestions what went wrong here?

Interesting is this message:

no address for À¨²À

Using wireshark I can see DNS queries for the string "À¨²À".
Where does this weird string come from?
What is metasploit resolving at startup??

Thanks in advance for any kind of help.

[imported_relik]

Im trying to reproduce..tested on BT3, Ubuntu and Gentoo, when doing the update all and run autopwn I can't reproduce the same results...

[hawaii67]

On another laptop where metasploit was working I initiated an metasploit update to revision 5651 with the command "svn update".

Since this update metasploit performs a DNS lookup at startup (before the update it didn't!), but for a weird string.
This time this string is

"^S^HM-^HM-|"

tcpdump:

11:27:49.253647 IP 19.8.136.252.32771 > 19.26.36.70.53: 0+ A? ^S^HM-^HM-| (47)

So does anyone have the same weird problem? Can somebody please tell me what's going wrong here?

Thanks.

[ShadowKill]

Just throwing thi sout there, but have yoiu tried asking the guys over at the metasploit forums about it? They would obviously know more about it then we would, I mean, it is theirs

[hawaii67]

Nice advice, but anyway: SOLVED!!!

[imported_relik]

What was the issue?

[hawaii67]

Honestly, I don't know by now.
I renamed the .msf3 directory in my home directory, then metasploit started up normal. Then I copied back the config file which resides in the .msf3 directory - and it is still working (which means no DNS lookup). Weird.
I'll make some other tests later since I want to know what was going on there.

[hawaii67]

Ok, so I performed some more tests.
After copying the config file back to the .msf3 directory msfconsole works fine, as far as I tested it till now (I tried a few exploits against my unpatched win2k box).

Doing the same procedure with msfweb or msfgui both tools are crashing each time at the point of selecting the target, since meetasploit again performs this ominous DNS lookup (checking with tcpdump).

When I remove the config file msfweb and msfgui work as expected. So there must be something in my config file which triggers this DNS lookup behaviour. But why is msfconsole working with that???
That's really weird.

[ShadowKill]

Ok, so I performed some more tests.
After copying the config file back to the .msf3 directory msfconsole works fine, as far as I tested it till now (I tried a few exploits against my unpatched win2k box).

Doing the same procedure with msfweb or msfgui both tools are crashing each time at the point of selecting the target, since meetasploit again performs this ominous DNS lookup (checking with tcpdump).

When I remove the config file msfweb and msfgui work as expected. So there must be something in my config file which triggers this DNS lookup behaviour. But why is msfconsole working with that???
That's really weird.

Think you could post up your config file for us?

[hawaii67]

Sure. Here it is:

[framework/core]
RHOST=192.168.178.25
LHOST=192.168.178.192

[framework/ui/console]
ActiveModule=exploit/windows/smb/ms06_040_netapi

[windows/smb/ms06_040_netapi]
SMBPIPE=BROWSER
SSL=false
SMBDomain=WORKGROUP
SMBName=*SMBSERVER
EnableContextEncoding=false
EXITFUNC=thread
payload=windows/meterpreter/reverse_tcp
SMBPass=
SMB::pad_file_level=0
SMB::pipe_write_min_size=1
SMB::pipe_write_max_size=1024
SMB::obscure_trans_pipe_level=0
DCERPC::ReadTimeout=0
DCERPC::fake_bind_multi_append=0
ConnectTimeout=10
SMBDirect=true
SMB::pipe_evasion=false
DCERPC::fake_bind_multi=true
DCERPC::fake_bind_multi_prepend=0
TCP::send_delay=0
EncoderDontFallThrough=false
SMB::pipe_read_min_size=1
SMB::pad_data_level=0
RHOST=192.168.178.25
SMBUser=
RPORT=445
LHOST=192.168.178.192
DCERPC::max_frag_size=4096
WfsDelay=0
TARGET=0
SMB::pipe_read_max_size=1024
DCERPC::smb_pipeio=rw
TCP::max_send_size=0