CRACKING
WEP WITH WINDOWS XP PART 2 CONTINUED
Port Scanning
We know the IP range in use by either the output of the ipconfig
command or, if we managed to connect to the AP as an adminstrator, we
could see the current IP setup, so we can scan the network to see what
hosts are active.
I prefer NMAP for this, but any port scanner will do:
To perform a ping sweep with NMAP we use the –sP switch:
Code:
H:\>nmap -sP 192.168.2.0/24
The 192.168.2.0/24 tells NMAP to ping all hosts between 192.168.2.0 –
255, the /24 is an abbreviated way of telling it the subnet mask –
255.255.255.0.
This may return something similar to this:
Code:
Starting Nmap 4.03 (
http://www.insecure.org/nmap ) at 2006-08-28 16:21 GMT Daylight Time
Host 192.168.2.1 appears to be up.
Host 192.168.2.2 appears to be up.
Host 192.168.2.5 appears to be up.
Nmap finished: 256 IP addresses (3
hosts up) scanned in 68.844 seconds
We know what 192.168.2.1 is and now we also know what other hosts are
active on the network.
As most of you probably know, you don't connect to an actual 'computer'
- you connect to a service that the computer is running. This could be
a service that the OS is running, eg, NetBIOS or a Third Party Service
eg, VNC.
To talk to other computers, most services use ports.
For the most part, a service will use a pre-defined port (by default).
So, if you scan a computer’s ports, you can find out what services are
running.
Once you have a list of used ports and services, then research these
services to see what they do - if you find one that interests you,
research how to exploit this service, so that you can compromise the
computer running it.
This is known as port scanning, and the main reason for doing it is to
discover what services are running on each host.
**Be careful not to alert anyone on the network with overenthusiastic
port scanning. If a host has a firewall active and a message pops up
saying ‘Connection attempt from 192.168.2.x port 139’, the owner may be
a bit suspicious if the IP is one that should not be in use. Try to use
a passive scan such as the –sS switch in NMAP**
NetBIOS
It is possible to connect to a NetBIOS share that the firewall on the
AP may have been protecting – here is an extract from a NetBIOS paper I
wrote a few months ago: (Note the IP Addresses will have changed since
this was written, and will belong to someone else by now!)
Quote:
After you have downloaded Nmap go and get winfo from here:
http://ntsecurity.nu/toolbox/winfo/
When you have this browse to C:\WINDOWS\system32 and drop the winfo
file there. Or you can manually edit your path for the command prompt
to include the location of the winfo file.
Now we have nmap we want it to scan a range of IP’s but as we are
trying to gain access to the NetBIOS shares, we only need to scan ports
139 and 445. So we issue the following command:
Code:
Nmap –sS –P0 81.32.12.0-255
–p139,445
Here we have told nmap to conduct a SYN Stealth scan, without pinging
the hosts, against the IP range of 81.32.12.0 – 81.32.12.255 only on
ports 139 & 445.
Here are the results of the scan:
Code:
Interesting ports on 81.32.12.204:
PORT STATE SERVICE
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
Interesting ports on 81.32.12.205:
PORT STATE SERVICE
139/tcp closed netbios-ssn
445/tcp filtered microsoft-ds
Interesting ports on
206.Red-81-32-12.dynamicIP.ri
PORT STATE SERVICE
139/tcp closed netbios-ssn
445/tcp filtered microsoft-ds
Interesting ports on 81.32.12.207:
PORT STATE SERVICE
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
Interesting ports on 81.32.12.208:
PORT STATE SERVICE
139/tcp closed netbios-ssn
445/tcp filtered microsoft-ds
Interesting ports on
222.Red-81-32-12.dynamicIP.ri
PORT STATE SERVICE
139/tcp closed netbios-ssn
445/tcp filtered microsoft-ds
Interesting ports on
223.Red-81-32-12.dynamicIP.ri
PORT STATE SERVICE
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
Interesting ports on 81.32.12.224:
PORT STATE SERVICE
139/tcp closed netbios-ssn
445/tcp filtered microsoft-ds
Interesting ports on 81.32.12.225:
PORT STATE SERVICE
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
Interesting ports on
226.Red-81-32-12.dynamicIP.ri
PORT STATE SERVICE
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
Interesting ports on 81.32.12.227:
PORT STATE SERVICE
139/tcp closed netbios-ssn
445/tcp filtered microsoft-ds
Interesting ports on 81.32.12.248:
PORT STATE SERVICE
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
**OUTPUT TRUNCATED**
Nmap finished: 256 IP addresses
(256 hosts up) …..
OK, now looking at the output of the scan, there is three states a port
can be in, Closed, Filtered or Open.
Closed speaks for itself, Filtered usually means it is open/active but
is protected by a firewall of some kind and Open means it is open and
un-protected.
So we trawl through the results and find that 81.32.12.240 has an open
port on 139…
So we will go and take a look at it.
Just a side note - we scanned for port 445 to as it is possible to have
port 139 open but not have the file sharing service running - if port
445 is open as well as 139 it usually means that the file sharing
service is up and runnning and could save us some time when chosing
which host to attack.
Fire up the command prompt again and use the in-built NBTSTAT utility
that comes with Windows. The command we give is:
Nbtstat –a [ip address]
Like so:
Code:
H:\>nbtstat -a 81.32.12.240
Local Area Connection:
Node IpAddress: [192.168.2.3]
Scope Id: []
NetBIOS Remote Machine Name Table
Name Type Status
---------------------------------------------
MASSAMA <00> UNIQUE
Registered
MASSAMA <20> UNIQUE
Registered
GRUPO_TRABAJO <00> GROUP
Registered
GRUPO_TRABAJO <1E> GROUP
Registered
MAC Address = 00-53-45-00-00-00
So what is all this telling us?
Well what we are looking at mainly is the ‘TYPE’ status. We want to see
<20> there. A common misconception is that if you can connect to
a box in the above mentioned manner, that file sharing is enabled. This
is not always the case. When we have connected we need to see the
<20> there to tell us File Sharing is enabled, if it is not there
and you are at a level that means you are reading this – you may as
well move on to another box
The following table lists all the possible entries you can get:
Code:
<computername> 00 U
Workstation Service
<computername> 01 U
Messenger Service
<.._MSBROWSE_> 01 G Master
Browser
<computername> 03 U
Messenger Service
<computername> 06 U RAS
Server Service
<computername> 1F U NetDDE
Service
<computername> 20 U File
Server Service
<computername> 21 U RAS
Client Service
<computername> 22 U Exchange
Interchange
<computername> 23 U Exchange
Store
<computername> 24 U Exchange
Directory
<computername> 30 U Modem
Sharing Server Service
<computername> 31 U Modem
Sharing Client Service
<computername> 43 U SMS
Client Remote Control
<computername> 44 U SMS
Admin Remote Control Tool
<computername> 45 U SMS
Client Remote Chat
<computername> 46 U SMS
Client Remote Transfer
<computername> 4C U DEC
Pathworks TCP/IP Service
<computername> 52 U DEC
Pathworks TCP/IP Service
<computername> 87 U Exchange
MTA
<computername> 6A U Exchange
IMC
<computername> BE U Network
Monitor Agent
<computername> BF U Network
Monitor Application
<computername> 03 U
Messenger Service
<domain> 00 G Domain Name
<domain> 1B U Domain Master
Browser
<domain> 1C G Domain
Controllers
<domain> 1D U Master Browser
<domain> 1E G Browser
Service Elections
<INet~Services> 1C G
Internet Information Server
<IS~computername> 00 U
Internet Information Server
As you can see there are many different services that we can connect
to. The scope of this paper is File Sharing though, so we will just
concentrate on the <20> field.
So, after discovering we can ‘nbtstat’ to another box and we have
established that the File Sharing Service is running we want to see
what shares are available on a box.
For this we again use an inbuilt command in Windows. The ‘net’ command.
Or more specifically the ‘net view’ command.
Code:
H:\>net view \\81.32.12.240
System error 5 has occurred.
Access is denied.
Woops. Ok so this guy is not as open as he first appeared and we can't
get a list of his shares. This may be because he is not running any
shares or because he has locked down his box and prevented if from
displaying his shares to the casual internet user.
I have put this in to this paper for a few reasons. The first being, if
you scour the internet looking for NetBIOS tutorials, you will find
hundreds that have been wrote and performed and an internal LAN, which
is conveniently setup to allow anonymous access to the File Sharing
service. This paper is using live IP addresses in real life scenarios
on the real internet – not a pre-constructed LAN. If you don’t agree
with the using a real IP scenario – this paper is not for you and you
should stop reading it now.
Another reason I left it in is to show that just because you can see
the NetBIOS table and it has the <20> File Sharing service
running, does not mean you can connect to it!
The final reason is to demonstrate that you will not always be
successful with this attack and it can take a lot of trail and error. I
have given lessons in the past that have gone on for in excess of 60
minutes before we have found an open and suitable host.
Original Tutorial
by nokia for TheTAZZone-TAZForum
Originally posted on September 2nd, 2006 here
Do not use, republish, in whole or in part, without the consent of
the Author. TheTAZZone policy is that Authors retain the rights to the
work they submit and/or post...we do not sell, publish, transmit, or
have the right to give permission for such...TheTAZZone merely retains
the right to use, retain, and publish submitted work within it's
Network.