XP - SP3 and windows firewall

[automatica]

Hi guys, fairly new to this specific linux distro but have used Jaunty quite a bit in the past. I've been having fun reading in this forum for the last week or so.

Anyway, getting to the point quickly, a couple of friends and I pulled out our old junker laptops or desktops, installed backtrack to the hard drive in a dual boot config, and agreed that we would pentest each other (only rule is no personal emails... but we can leave awkward comments on each other's facebook or myspace wall if we so desire ) . In the process of learning, we decided instead of rolling with the WINE VM XP SP2 set up, we'd have XP with SP3 (although one machine has Vista Home) and windows fire wall turned on in a dual boot system on our new backtrack machines. The goal, try and hack/crack each other as we're learn by doing kind of people.

That said, I'm running through this to try the test with metasploit -
Metasploit Unleashed - Mastering the Framework

There's one problem I'm seeing here -

Setting up your Windows XP SP2

For this section we will download our target VM and use Wine to run a windows application known as WinRAR. This application will aid us in extracting the target VM from a split zip file. We encourage you to verify the integrity of the files to ensure you will have successful results. The process is very simple to do since back|track4 has the necessary applications to do this.

Source: Windows XP SP2, section 2 on metasploit unleashed

When I run through the metasploit tuts, I get the following when my friends or myself open the files -

[*] Handler failed to bind to 192.168.1.6 binding to 0.0.0.0
[*] Started reverse handler
[*] Starting the payload handler...

Would the following be why my meterpreter/reverse_tcp isn't working and freezes up at the payload handler -

1. It's the XP SP3 that's causing the meterpreter/reverse_tcp to hang up as it should be SP2
2. It could be the windows or perhaps router firewall getting in my way
3. A combo of both?

I figured it's either that the 3 of us on our tester machines are running XP SP3 or Vista Home (no idea what SP my friend has there as I despise Vista with a passion) or the windows/router firewall, as it will filter network traffic and it may be filtering out my reverse_tcp. However I'm new to metasploit and reading and testing so I figured I'd leave it up to the pro's.

Thanks guys.

Ok, I just tried the meterpreter/reverse_tcp pdf exploit on a vista machine... no dice. It always seems to keep freezing up at the payload handler stage. We turned off vista's firewall and AV for this test and still got blocked. Time to try it on the SP3 with the same set (no firewall, no AV). In the mean time I'm thinking the following for the vista test -

1. Even though the exploit in the pdf section of the metasploit section says it got in a vista machine, this kind of exploit may not be designed for vista.

or...

2. I got something wrong with my routing and networking.

Back to the experimentation.

[Liuser]

1. What exploit are you attempting to use?
2. The target machine must be vulnerable to the exploit.
3. You need to make sure you have chosen the appropriate "Target" OS + SP. The memory mappings on SP2 and SP3 differ.
4. Are your target machines on the same subnet? Are your machines behind any firewalls? Try to telnet/netcat to the target port.
5. Is 192.168.1.6 your local IP? This should be your machine's IP if you are using reverse_tcp.

[killadaninja]

A handler will fail to bind because.
A. You are giving it the wrong address.
B. The port you defined is already in use.
C. Both of the above.

[automatica]

@ ninja: You are totally right, ID-10t error on my part that was corrected in yesterday's test run. Still unsuccessful but at least one of the bugs was ironed out.

1. What exploit are you attempting to use?
2. The target machine must be vulnerable to the exploit.
3. You need to make sure you have chosen the appropriate "Target" OS + SP. The memory mappings on SP2 and SP3 differ.
4. Are your target machines on the same subnet? Are your machines behind any firewalls? Try to telnet/netcat to the target port.
5. Is 192.168.1.6 your local IP? This should be your machine's IP if you are using reverse_tcp.

1. We are using the pdf "Client Side Attacks" from chapter 8 of Metasploit Unleashed - Mastering the Framework. As far as the payloads we have been trying on each other, we're used windows/meterpreter/reverse_tcp and windows/meterpreter/reverse_tcp_allports.

2. Our target machines include 1 Vista machine (unsure as to SP) and two XP SP3 systems.

3. I will have to check that on the reverse_tcp, I think the command is "show targets" to see what the payload will affect so I'll be doing that if we do another test run today.

4. Good idea on the telnet, I'll give it a shot and report back. These test machines are not apart of the same subnet, as all three test machines are on different ISP's and even scattered across different states as the members of my test team are located in different areas. As far as firewalls, yes they did have the windows firewall set to on as of two days ago. Yesterday during our test runs we decided to simplify the test and turn off the windows firewall. They will remain off until we get the test working, and then we'll turn them back on to throw on another layer of complicity.

5. 192.168.1.6 is not my local IP. I made an ID-10t error on the first test set. My local is 192.168.1.37, and we corrected the tests yesterday for that. I shouldn't have been such an idiot and ran a netstat -a when I ran the first test set. The second test set was a little more successful in that my local IP was listening for a connection on port 4455 (the LPORT I set it to), but we still were not able to penetrate each other's machines.

I'll check back here, but I think I tapped the mat to early in creating this thread. Aside from the fact I was being an idiot on the local IP routing for this attack, and I'm not checking to make sure our test machines are vulnerable to said exploits... yeah I need to research a little more.

Right now, I'm going to check and make sure vista and XP-SP3 are vulnerable. Also from the specific Adobe attack we were running, I noticed it's written for Adobe Reader 8.1.2. All of our test computers are using v. 9 something... so it lookslike I either need to make our test machines vulnerable or rework the exploit to hit the current conditions the machines are in.

[Liuser]

You shouldn't be using local IPs then. You should be using your external IP, then on your router/FW you need to configure port forwarding. I think that is your main misconfiguration at the moment.

[automatica]

You're totally correct Liuser, we just ran a netstat on one of the victim machines. The payload worked fine on the victim machine but I still got no feedback on backtrack. The reason, it was trying to connect to my local IP.

Back to the lab for me.

Thanks guys.

[Liuser]

What you can also try to do, is use VMs for now. It will eliminate the complexities of the network, so you can focus on exploiting on the same network first. Then when you have that down, start introducing the victim machines on different networks.