SET trying to connect to an OSX shell on Windows victim

[vaffunculo1986]

Hey everyone,

it seems to me like SET is trying to connect to my Windows 7 machine with an OSX shell, I have tried this with gnome 64bit and KDE 64bit installed to the HDD, running a bootable USB, and a LiveDVD, to attack both a Win7 and XP machine with known vulnerabilities. The ou
tput I
get from the meterpreter is as follows:[*] Command shell session 1 opened (192.168.1.112:8080 -> 192.168.1.100:49679) at 2012-06-25 16:51:07 -0600[*] Session ID 1 (192.168.1.112:8080 -> 192.168.1.100:49679) processing InitialAutoRunScript 'post/osx/gather/enum_osx'

msf exploit(handler) > sh
[-] Post failed: NoMethodError undefined method `chomp' for nil:NilClass
[-] Call stack:
[-] /opt/metasploit/msf3/modules/post/osx/gather/enum_osx.rb:46:in `run'

msf exploit(handler) > sessions -i

Active sessions
===============

Id Type Information Connection
-- ---- ----------- ----------
1 shell osx GET / HT
TP/1.1
Host: 192.168.1.112:8080 User-Agent: Mozilla/5.0 (Windows NT 6... 192.168.1.112:8080 -> 192.168.1.100:49679 (192.168.1.100)


I have tried completely removing SET and Metasploit and re-installing both then running the updates. I have also used 2 different PC's with different hardware and still come up with the same errors. My network consists of a linksys wireless router with no restrictions or blocking of any kind and both attacker and victim on the same network. I've read through the bugs and fixes sections on this forum and haven't found anything, google is not helping either. Any help would be appreciated!

Thanks

[TechKnight]

I'm seeing the same issue. Anyone know what's going on here?

[TechKnight]

The output I get from the meterpreter is as follows:[*] Command shell session 1 opened (192.168.1.112:8080 -> 192.168.1.100:49679) at 2012-06-25 16:51:07 -0600[*] Session ID 1 (192.168.1.112:8080 -> 192.168.1.100:49679) processing InitialAutoRunScript 'post/osx/gather/enum_osx'

I was having the same problem, so I showed it to my boss and he showed me what I was doing wrong. It appears that like me, on the victim system you were visiting port 8080 on the malicious site. That's the port the OSX listener is running on. Not specifying the port and letting it default to 80 loaded the page and attempted the exploit properly.