dingo_boy

I am not in the security business so the following question may seem naive. ISTM that Metasploit is held up as the tool that can best identify network insecurities. The idea is, AIUI, that the pen-tester (or attacker) identifies the IP range, scans it with Nmap or perhaps Nessus, then uses Metasploit to exploit these results and gain a shell (ideally Meterpreter) which provides almost total control over the victim. There is a good set of videos on Security Tube which detail the immense power of Meterpreter (http://www.securitytube.net/video/1175). The problem I have with this video series is that the focus is on what happens after the exploit has been successful. The first video shows that the exploit is performed on an unpatched XP box and, quite understandably, the exploit works and shell access is granted. But this is a test - it is not real. Similarly, "Metasploit: The Penetration Testers Guide" (2011) runs the test exploit against a XP SP2 box. This does not strike me as particularly up-to-date. Here is my question: is it likely these days that a pen-tester or an attacker would successfully deploy Metasploit against an IP:port combination. By "successfully", I mean obtain a shell. Let's say that Nmap showed something like this: 80/tcp open http Apache httpd 2.2.3 ((CentOS)) 443/tcp open ssl/http Apache httpd 2.2.3 ((CentOS)) 3389/tcp open ms-wbt-server Microsoft Terminal Service Or this: 21/tcp open ftp Solaris ftpd 80/tcp open http Apache httpd 1.3.37 ((Unix) FrontPage/5.0.2.2634 mod_ssl/2.8.28 OpenSSL/0.9.8d) Or this: 80/tcp open http Apache httpd 2.2.9 ((Debian) mod_wsgi/3.3 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0) 443/tcp open ssl/http Apache httpd 2.2.9 ((Debian) mod_wsgi/3.3 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0) I've searched in msfconsole and, IMO, there are so many caveats or restrictions for the Apache exploits (many of which are years old) that even the older versions of Apache could not be exploited. The same applies to other popular web services like IIS. Maybe I am missing something in the way that professionals use Metasploit. Am I?

Thanks for your advice - I have done some more experimentation. I don't understand this. If I disconnect, change the MAC, then re-connect, surely I am now a 'new' computer so why would the DHCP try to re-allocate me the same IP then get concerned because the MAC is different? Here is what I tried I went to my friend's WPA router which I have never connected to before. I first spoofed the MAC (like in post 1) and I was unable to connect. I then spoofed the MAC for wlan0 (my laptop's NIC) and I was unable to connect. I then removed the spoofed MAC for wlan1 and was able to connect. I then removed the spoofed MAC for wlan0 and was able to connect. Now, I have no idea why I cannot connect with a spoofed MAC but I do know that Wireshark shows different information for when I am successful compared to when I fail to connect. This relates to the four-way WPA handshake. I base my experiences on this page written about the handshake by the aircrack-ng team: http://www.aircrack-...ckets_8_9_10_11 Successful: Replay counter can start at (for example) 4. So the first set is 4 and 4 then 5 and 5 (then it connects). The nonce values for 1 and 3 are the same. The nonce values for 2 and 4 are not the same. The nonce value for 4 is 0000000000000000000000000000000000000000000000000000 Failure: The replay counter always starts at 0. So I might see 0 and 0 then 1 and 1 then 2 and 2 then 3 and 3 and so on (because there is never a connection). The nonce values for 1 and 3 are the same (as above). The nonce values for 2 and 4 are the same (different). The nonce value for 4 is therefore not a string of zeros (different). What I do not know is why these differences are happening merely because I spoofed the MAC. This happens, as I said, for wlan1 and wlan0. The only thing I can think of is that the way in which I am spoofing the MAC causes the problem. Here is what I do under Ubuntu 10.04: sudo ifconfig wlan1 down hw ether 00:C0:CA:04:AC:2D sudo ifconfig wlan1 up The check the change has been made with ifconfig. I really have no idea what is going on. All suggestions greatefully appreciated!

I have WPS set up but I have never used it. I manually set-up the WPA. I'm not entirely sure what you mean by error messages. Dmesg showed "reason code 15" which is (according to the IEEE) signfies a "4-Way Handshake timeout". This would make sense as I was never able to connect and Wireshark shows multiple attempts. However, what I do not understand is why changing the MAC would cause this handshake error?

I have a WPA network. I connect to it with my Asus 036H. No problems. Let's say the MAC is 00:C0:CA:02:DC:3F. I then change the MAC to 00:C0:CA:04:AC:2D. The OUI is the same. Now I cannot connect. There is no MAC filtering. I used Wireshark to inspect the four way handshake. In each case: a) AP to client b) Client to AP. c) AP to client. d) Client to AP. In each case: a) Replay counter 1. b) Replay counter 1. c) Replay counter 2. d) Replay counter 2. However, the difference was with the nonce values. The genuine MAC showed that the nonce for packets 1 and 3 was the same. The spoofed MAC showed that the nonce for packets 2 and 4 was the same but the nonce for packets 1 and 3 was different. My understanding (http://www.aircrack-...?id=wpa_capture) is that the values for 1 and 3 must be the same for the handshake to complete. What I do not understand is why spoofing the MAC modifies the handshake? When I remove the ASUS then plug it in (thereby removing the spoofed MAC) and try to connect it immediately works. It appears that spoofing the MAC changes the identical nonce values to 2 and 4 (which does not work). Why is this happening? Thanks!

Hello! Are any of you guys familiar with the Social Engineer Toolkit? I am attempting to use its Credential Harvester program but I ran into a slight problem. The Credential Harvester clones a website which has POST login forms. All POST information is transmitted to the attacker once the target connects to his IP and enters details. I am having problems with Hotmail. The only site seems to be login.live.com. Everything redirects to this site so I have no alternatives to clone. I clone the site in the Harvester which seems to work. This process creates an index.html file. I then go to my IP address which loads the index.html but all I see is a blank page. The source reveals that the page has, in fact, loaded but nothing is displayed. I believed that the problem was the base href="" (empty) so I set it to https://login.live.com/pp1300. However, this did not change anything as the page still refused to load. The source of the index.html (from Firefox) claims that JavaScript is disabled. This is not the case. And I also unloaded NoScript and HTTPS-Everywhere to simulate a 'normal' browser. Does any one know why the page will not load? Thanks! Initial source below (I can provide more should you wish). <html dir="ltr" lang="EN-US"><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"/><meta http-equiv="X-UA-Compatible" content="IE=5"/><script type="text/javascript">var g_dtFirstByte=new Date();</script><base href=""/><noscript><meta http-equiv="Refresh" content="0; URL=https://login.live.com/jsDisabled.srf?mkt=EN-US&lc=1033"/>Windows Live ID requires JavaScript to sign in. This web browser either does not support JavaScript, or scripts are being blocked.<br /><br />To find out whether your browser supports JavaScript, or to allow scripts, see the browser's online help.</noscript><title>Sign In</title><meta name="description" content="Powerful free e-mail with security from Microsoft - Windows Live Hotmail is a best in class e-mail service that helps you organize and manage all your online stuff in one place"/><meta name="PageID" content="i5030"/><meta name="SiteID" content="64855"/><meta name="ReqLC" content="1033"/><meta name="LocLC" content="1033"/><script type="text/javascript"></script><link rel="shortcut icon" href="http://Https://secure.shared.live.com/~Live.SiteContent.ID/~16.3.16/~/~/~/~/images/favicon.ico" /> <link rel="image_src" href="http://Https://secure.shared.live.com/~Live.SiteContent.ID/~16.3.16/~/~/~/~/images/Windows_Live_v_thumb.jpg" / >