Playing with ms08_067

[dualboot]

awesome post, led me to nmap.org where i found some more very interestng things about nmap,



thanks pureh@te keep up the great work.

[jorgan]

sometimes meterpreter wont work against win2003 sp2. meterpreter on xp sp3 works all the time. this was my tests, anyone tested?...

[secure_it]

sometimes meterpreter wont work against win2003 sp2. meterpreter on xp sp3 works all the time. this was my tests, anyone tested?...

Yup easily its working WIN SP 3,within few seconds I am able to get shell & user hashes along with dropping of nc

[imported_Deathray]

First of all, let me state this is an excellent thread. Haven't had one of these in months. Thanks pureh@te!



Tried this on my SP3 XP Box and it crashes with the firewall on! Now if I turn it off it will go through. Note that "file and printer sharing" is on by default. I used the metasploit framework with the windows/smb/ms08_067_netapi exploit and meterpreter as the payload.

Are you using bind_tcp ?
reverse_tcp should bypass the firewall, but in order to use bind_tcp you have
to execute this command first netsh firewall set portopening TCP 6112
where 6112 is the port listened on by meterpreter. You could do that with for
example the "Windows Execute Command" payload.

[adri_ht_]

Are you using bind_tcp ?
reverse_tcp should bypass the firewall, but in order to use bind_tcp you have
to execute this command first netsh firewall set portopening TCP 6112
where 6112 is the port listened on by meterpreter. You could do that with for
example the "Windows Execute Command" payload.

Thanks for the hint. I'll test it out as soon as I find an unpatched system since I patched mine the same day I saw this thread. I never though of this, but yes Windows Firewall prevents outbound traffic which could prevent in this case the meterpreter bind_tcp payload from communicating back. I guess I will have to google how reverse_tcp does it. If you have a good read on this, please let me have it. Thanks.

[imported_cybrsnpr]

I never though of this, but yes Windows Firewall prevents outbound traffic which could prevent in this case the meterpreter bind_tcp payload from communicating back. I guess I will have to google how reverse_tcp does it

You've got this a bit twisted. A bind_tcp payload will open a socket on the victim box and listen for connections to it. The problem with this is that a host based firewall may block incoming connections so that when your "evil hacker" box attempts to connect to the bind_tcp backdoor, it's incoming packet is blocked by the firewall and therefore cannot establish a connection with the listening bind_tcp socket.

A reverse_tcp backdoor does the opposite of a bind_tcp. It does not create a local listening socket, it establishes a reverse connection outbound from the victim to whatever IP and port you specified when you created the payload. This technique takes advantage of the fact that most network based firewalls may not allow traffic into the network, but will normally allow outbound traffic without any problem. Especially if your reverse_tcp shell is calling out to a popular port such as port 80 or 443. Also, some host based firewalls will allow these connections even if they are blocking incoming connections (usually because the user got tired of clicking "allow" or "deny" all the time).

For your specific problem, since file and print sharing is turned on, try a reverse_tcp to port TCP/139 of your "evil hacker" box (make sure samba is not running when you do this).

If you want to learn more about reverse_tcp, google for "shoveling a shell". That is the term normally associated with reverse_tcp connections.

[whitedraven]

this one was fun. I was playing with the ms08_067 before i read this thread (last month), but wish I read this first.
Target:Household mates pc
Execution:MSF3console ruby script
Actions:turned on webcam, and old webcamxp server software, for the

[adri_ht_]

You've got this a bit twisted. A bind_tcp payload will open a socket on the victim box and listen for connections to it. The problem with this is that a host based firewall may block incoming connections so that when your "evil hacker" box attempts to connect to the bind_tcp backdoor, it's incoming packet is blocked by the firewall and therefore cannot establish a connection with the listening bind_tcp socket.

A reverse_tcp backdoor does the opposite of a bind_tcp. It does not create a local listening socket, it establishes a reverse connection outbound from the victim to whatever IP and port you specified when you created the payload. This technique takes advantage of the fact that most network based firewalls may not allow traffic into the network, but will normally allow outbound traffic without any problem. Especially if your reverse_tcp shell is calling out to a popular port such as port 80 or 443. Also, some host based firewalls will allow these connections even if they are blocking incoming connections (usually because the user got tired of clicking "allow" or "deny" all the time).

For your specific problem, since file and print sharing is turned on, try a reverse_tcp to port TCP/139 of your "evil hacker" box (make sure samba is not running when you do this).

If you want to learn more about reverse_tcp, google for "shoveling a shell". That is the term normally associated with reverse_tcp connections.

Indeed I was a bit confuse, but now thanks to you I completely understand the difference between both of them. Thanks

[imported_n000b]

@anonymoususer

R u sure you done it on XP-SP2 as it does not have the payload for xp-sp2 and i have myself tried on 3 machines of XP-SP2 which has the port open but exploit doesnt work neither the script tell

results like:
|_ smb-check-vulns: This host is vulnerable to MS08-067

but just show port open


@pureh@te

its just AWSOME we need more like that

[lenn1]

[-]Windows 2003[SP2] payload loaded
[-]Initiating connection
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.5/threading.py", line 460, in __bootstrap
    self.run()
  File "7132.py", line 136, in run
    self.__DCEPacket()
  File "7132.py", line 108, in __DCEPacket
    self.__trans.connect()
  File "/usr/lib/python2.5/site-packages/impacket/dcerpc/transport.py", line 294, in connect
    self.setup_smb_server()
  File "/usr/lib/python2.5/site-packages/impacket/dcerpc/transport.py", line 291, in setup_smb_server
    self.__smb_server = smb.SMB('*SMBSERVER',self.get_dip(), sess_port = self.get_dport())
  File "/usr/lib/python2.5/site-packages/impacket/smb.py", line 1293, in __init__
    raise ex
error: (111, 'Connection refused')

whats wrong ?