2007 A Hacking Odyssey – Reconnaissance

The aim of this series of papers that will take an in-depth look at how someone may target and electronically break into an organisation, is to educate people who may be tasked with looking after and securing a corporate network to do so in an effective manner.

My personal outlook on this issue is that if you have no idea about the steps a would-be attacker will take to try and gain access to your systems, then you as an administrator can not effectively secure your system to an acceptable standard. Some people may disagree about the concept of demonstrating to people how to gain access to networks they are not meant to, whilst others agree with the ‘full disclosure’ approach.

Take a firewall for example – if you don’t understand the steps an attacker will go through to try and get traffic through your firewall, then how can you stop them for doing it? All you can do is configure it the best way you know how and hope it is good enough.

Hacking, Cracking, Hackers and Crackers

Before I start:

If some innocent looking young teenager came up to you and starting talking about hackers and hacking, then chances are you, being the IT professional that you are would mentally dismiss him as not understanding what he was talking about, just because he used the work ‘hack’. Yet, if a university professor type person in his fifties wearing a tweed coat, glasses and smoking a pipe came up to you and starting talking about hackers and hacking then you would more than likely listen to every word he says…… why is this?

Well, the term ‘Hack’ or ‘Hacker’ is a word coined by the media to mean anyone trying to break in to something IT related, whether it’s a Network, Computer or any other type of electronic system.

The more realistic term to use when talking about a hacker in the way the media’s term is meant, is to use the word ‘Cracker’ or ‘Attacker’. A cracker/attacker is someone who tries to gain access to things they have absolutely no right to be accessing. A hacker is someone who tries to make something function in a way it was not originally designed to do; they ‘hack it apart’.

Take an email program for example; a hacker may try to make this email program send something other than an email, thereby making it do something it is not meant to do. Whereas an attacker/cracker will try to gain a level of access to it and read the users emails contained within the application.

People who are new to the IT community will often innocently use the word hacker until

they get flamed by someone for doing so, probably on an IT related web forum, at which point they will usually endeavour to find a different word or face public ridicule on the new IT forum they will inevitably have to find.

There are some people who like to instigate the flaming of the above mentioned people and think that everyone else will presume they are pretty knowledgeable because they make a big fuss of the fact they don’t like the word ‘Hacker’……these are the people you should probably stay away from.

Most people who are secure in their own knowledge of IT and IT security whether for good or bad purposes and who have worked in the area for a while, really don’t care what word is used and can even find themselves using the term ‘hacker’ for ease of instruction when talking to non technical people or media type people. It could also be used to lessen the effect the work ‘Attacker’ has on someone; non IT people can get pretty scared when you say a cyber attacker is out to get them.

For the duration of these papers I will use the term ‘attacker’ to refer to someone trying to do bad things to your computers and to your network. We will also assume the attacker is a ‘he’.

Reconnaissance

For this chapter we will take the mindset of the Attacker and the preliminary steps he may go through to attack your IT emporium.

How does an attacker decide which organisation to target? When he has decided on the organisation how does he set about attacking it, how does he know where to go on the internet to find the specific network he wants to attack, how does he find your geographical location if he wants to wardrive you, how does he find useful information to socially engineer you, how does he find your phone number range to war dial you, how does he find your mail server?

These are just some of the things the attacker will need to know before planning any attack against you and is generically referred to as reconnaissance.

There are different types of attacker; attackers who have picked a target for a specific reason, attackers who pick random targets but have a specific idea about what they want to do to the target when they find one, and then there are attackers who look for random targets to launch random exploits against in an attempt to gain any level of access, without actually understanding what it is they are doing.

This later genre of attackers are commonly referred to as Script Kiddies, Skiddies, SkiDIE’s, Skids etc and are the ones who don’t usually bother with any reconnaissance and jump straight to firing Nmap up and start telenting to any open ports they may

happen to find.

I usually start security related courses off by asking, “What is the first step to take when wanting to attack a network?” 99% of the answers I receive involve the words Nmap and Telnet. Whilst this is a feasible option, there are still lots of steps to take before Nmap is even downloaded.

You may have dismissed Script Kiddies out of hand by what I have mentioned above. Just because they do not understand the ins and outs about what they are doing does not make them any less dangerous than someone who does. Script Kiddies have all the time in the world to try and attack you. They usually come across an exploit of some kind that has been published somewhere, read how to actually perform the exploit and then go off in search of someone to test their new found uber skill on.

Since they have a specific exploit in mind, which may run over a certain port, they can scan away to their hearts content looking for that one system that is vulnerable to the exploit they have.

So, whereas Administrators have to try and secure from 1000’s of possible vulnerabilities, the Script Kiddies only have to find this one vulnerability on your system…..and have an infinite amount of time to find it.

Picking a Target

So, how do pick a potential target?

As good guys you may have a specific reason to attack a target, whether it is your own organisation and are auditing the security of it, or you have been contracted to audit the security of another organisation – if this is the case then step one has been decided for you. As bad guys you could have a grudge against a particular organisation, you could have come across some interesting information in a newsgroup about a certain system being vulnerable, someone may have posted a firewall configuration on a newsgroup/IT help site and not removed any passwords or IP addresses (this used to happen a lot). You could even have been specifically asked by someone to see if you can do any damage against an organisation…..the list goes on.

What if you have no reason to pick a specific target and any will do?

You could trawl through your own firewall logs and find someone who has targeted you in the past; Zone Alarm for example has an annoying popup that can tell you about any external attempts made to gain access to your machine and includes the IP address of the attacker. If you have a home router they all usually have a logging facility and will record any attack attempts.

In true Script Kiddie style you could have stumbled across an exploit and want to try it out, so start looking for susceptible targets.

You could even ping the first IP address that comes into your head, check it is valid and chose that.

When I teach this subject in particular, to find an organisation for the duration of the course I usually enter the first words that pop into my head in to Google, take one of the hits on the first page and use that company to demonstrate the reconnaissance steps against.

In this case the words are ‘Garden Sheds’.

http://www.google.co.uk/search?hl=en&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=garden+sheds&spell=1

The company I chose is Shed Store.

That’s the target picked, now let’s see what we can learn about them…

Research the Target

There are a multitude of perfectly legal methods we can use to research our target and we don’t even have to connect to any of the machines associated with it. Like all good reconnaissance, the intended target should not know what we are trying to do – for this reason we try to use publicly available information that is hosted away from any machine directly belonging to the organisation or has been made to be accessed by the public, i.e. their web server.

Targets own web site

Once you know who your target is the fist thing to do it browse over to their web site and simply have a look at all the information they have made freely available to us.

http://www.shedstore.co.uk/

What info can we get from here?

They have kindly given us their address, phone number range, email domain, who they use for their online billing provider, what their office opening hours are and that they are part of Guardian Buildings.

Quote:

Shedstore (A trading division of Guardian Buildings). Unit 1, Southview Park, Caversham, Reading, Berkshire. RG4 5AF. T: 0870 3500 710 F: 0870 3500 720 E: sales@shedstore.co.uk W:

www.shedstore.co.uk

Quote:

During our office hours of 8.30am to 12.00pm, then 1.00pm to 5.00pm - Monday to Friday, we accept telephone orders and enquiries upon the following numbers. - Sales enquiries & orders: 0845 130 0405 (Local rate) - General enquiries: 0870 3500 710 (National rate) - Customer service enquiries: 0870 3500 710 (National rate)

- (For those customers unable to access '08' numbers, please call 0118 946 4182)

By going part of the way through the order procedure we find out they use http://www.securehosting.com/ to handle their online transactions.

The also have a members only area of the site.

**I will talk about what we can do with all this information later on**

We are starting to build up a ‘feeling’ about this company just from their web site. Going by this web site they seem to be a fairly well established company, they have what looks to be a professionally made web site, the seem to do the majority of their business over the internet, but they don’t necessarily seem IT savvy as they have no need to be, so they maybe rely on external hosting providers to handle the web site, email, billing etc…… this last point is a point worth remembering for later on when we cover social engineering.

None or all of the above ‘feelings’ we get from the web site are necessarily true……we need to confirm it first.

Google

I will not cover Google on this paper as the subject as extremely large and I feel it deserves a paper to itself (whick will be posted soon). Needless to say typing the company name in to Google & Google groups may reveal some information that can be useful to you.

Jobs advertised on company web sites

Although not applicable to this particular web site, let’s say we were using the web site of

a small bank, and on this web site they had a Jobs Section, and in this jobs section they were asking for a PIX firewall administrator to start immediately….

This little gem of information tells us that the bank uses PIX firewalls, that they may have no administrator currently employed to manage it/view the logs etc (hence the immediate start) and that they may be susceptible to a social engineering attack whereby someone who does not normally configure the PIX maybe coerced into making a change OR that a new employee is likely to start very soon, who again will be very susceptible to social engineering to get him to alter the firewall’s configuration…..if you had a phone call from someone claiming to be the boss of your new company on your first day at work, would you say no to him if he told you to maybe change an ACL in the firewall? Maybe, maybe not…..

All this stems from a seemingly innocent job advert….

Newsgroups

Newsgroups are a valuable source of information during the reconnaissance phase of an attack depending on the type of target, as they are usually used by someone to ask for help, i.e. I have a PIX 506E and I want to configure a static NAT for a web server with the IP addresses 192.168.10.10 and 80.80.80.80, how do I do it?

This innocently asked question tells us that particular organisation uses a PIX, the internal IP range, the external IP range and that the administrator is not so confident with configuring it, hence it maybe miss configured and easy to attack…..

Out of Office replies are also sent out to some newsgroups…..what better time to attack a network than when you know the administrator is out of the office and can’t examine any logs…..or if you want to phone someone up and socially engineer them under the guise of being the system administrator…. well you know he won’t be there to get in your way….

If you trawl through it you will find complete router configurations including IP addresses and passwords, firewall configurations that again include IP addresses and passwords, the list goes on. If you have managed to gleam a name from the organisations web site try searching for it and see if it throws anything up.

**When you want to search for say a PIX running configuration that may have been posted in its entirety, it is best to search for a few words that are specific to the configuration. I usually use “mtu outside” – which refers to the Maximum Transmission Unit size for the Outside interface of the firewall and is pretty specific to a firewall - if you know the domain name of your target try including this in your search string as well; most firewalls can be configured with a domain name....

The below link has over 13,000 PIX configurations that have been posted in various newsgroups:

http://groups.google.co.uk/groups/search?hl=en&q=mtu+outside+&qt_s=Search

I find PIX firewall configuration especially useful to search through as there are so many things that need to be deleted from the configuration to not give away any information. So often I see IP addresses deleted but domain names remaining intact, a quick ‘nslookup’ of the domain name will sometimes give you the IP Block assigned to the organisation, once you have worked this out take a look at the Access Control Lists and see what they allow in…..see if there are any Peer IP addresses in the VPN configuration etc

There is a very extensive search function on the Google Groups site, which will allow you to search for almost any aspect of a post, again try and use keywords specific to either the organisation you are researching or are specific to the type of post you are looking for.

You may have to trawl back a while to see if anyone has posted via their company email address in a newsgroup as people are more savvy now-a-days and usually use a hotmail/gmail/Yahoo type web mail account. However, some people sign their messages with their full name, company name and company address……and then explain their entire network setup and what is wrong with it.

We will come back to searching newsgroups in the next section when we go over WHOIS records.

WHOIS

The Internet is a huge directory of domain names and due to various copyright laws, trading laws and DNS workings, there can not be two identical domain names in existence at the same time on the Internet.

A domain name refers to an organisations “Internet presence” and is usually related to their normal company name. I.e. The domain name for Barclays Bank is Barclays.co.uk (http://www.barclays.co.uk/) 99% of the time this also means their email addresses will end in Barclays.co.uk.

Keeping track of all these domain names was historically done by Network Solutions until 1999 when they lost the monopoly for domain name registration. As the Internet grew so did the amount of suffixes attached to domain names ( .com, .co.uk, .org etc) and so did the amount of registrars.

Any domain name ending in . .aero, .arpa, .biz, .cat, .com, .coop, .edu, .info, .int, .jobs, .mobi, .museum, .name, .net, .org, .pro, and .travel are registered with Internic; who can be found here: http://www.internic.net .

The country code top-level domains – which are two letter suffixes that refer to the

country, I.e. uk, jp, au will inform the attacker what country the target is in. A list of ccTLD’s can be found here: http://www.iana.org/root-whois/index.html

What if your targets domain name does not fall under InterNIC’s remit? Well, there is a very helpful site called Uwhois that will inform us of where to look for the registration details or our particular domain.

http://www.uwhois.com/domains.html

We browse to Uwhois and enter “shedstore” in the domain box, tick .co.uk and click Go.

Depending on who the domain is registered with Uwhois may show us the complete registration record or it may tell us where to go and look for the records.

In our case we are told that the domain name is registered:

Quote:

The answer to your domain search is ________________________________________ Uwhois search forshedstore.co.uk Registered

Notice shedstore.co.uk is a hyperlink? Click on it and you will be taken to either the registration details or you will be told where to look:

Quote:

[whois.nic.uk]

We now know that whois.nic.uk holds the registration records. Type that into Google and the first hit you get is for Nominet. http://www.nominet.org.uk/other/whois/

Browse to Nominet and enter shedstore.co.uk as the search term:

Quote:

Domain name: shedstore.co.uk

Registrant: Keith Taylor

Trading as:

Guardian Buildings

Registrant type: UK Partnership

Registrant's address: Guardian Buildings Unit 1 Southview Park Caversham Reading Berkshire RG4 5AF United Kingdom

Registrant's agent: Thus plc t/a DSVR [Tag = DSVR] URL: http://www.dsvr.co.uk

Relevant dates: Registered on: 24-Jan-2000 Renewal date: 24-Jan-2008 Last updated: 20-Jun-2006

Registration status: Registered until renewal date.

Name servers: ns0.serve.co.uk ns0.serve.net.uk

Now we are getting some information that we can use to aid our attack. We have a name of someone who is probably fairly high up in the Guardian Buildings organisation; Keith Taylor. We also know Shed Store is part of the Guardian Building group from information we were able to get from their web site.

We have the address of both Shed Store and Guardian buildings; again we have this from their web site and from this WHOIS record.

We now know who they use to host their web site and who they used to register their domain name from the Registrant’s Address information: URL: http://www.dsvr.co.uk .

We can see the record was renewed in June 2006, so ‘Keith Taylor’ is probably still working for the organisation.

Finally we have the most important piece of information to us so far; the name servers, which I will talk about in a minute.

You maybe thinking, Yeah, Ok I have all this information but what use is it to me? It will all become apparent right after I run through DNS and DNS zone transfers.

Domain Name Service – DNS

DNS could be considered the post office and telephone directory of the Internet. Without it the Internet would not be anywhere near as efficient and easy to use as it is today.

In a nut shell DNS takes an IP address and ties it in to a domain name. I will presume most people know what an IP address is and will not insult you all be explaining it (PM J_K9 if you need to know)

To explain DNS it is best to give an example; so if you go to your RUN prompt (Start > Run) and type CMD into it and press enter(Or your Linux equivalent) You will get a black box popping up; this is your command prompt.

Whenever we want to perform any DNS queries, or interact with DNS in anyway we use a program called ‘nslookup’. (Linux users may want to use ‘dig’ instead of nslookup as most recent Linux distro’s have butchered the nslookup program somewhat)

Type nslookup:

Code:

Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Nokia>nslookup Default Server:  speedtouch.lan Address:  192.168.1.254

>

Notice the prompt changes to ‘>’, this tells us we are now in the nslookup application and not in the normal command prompt.

The Default Server will tell you what your own DNS server is. (this may not always be an actual server, especially if you are using a home router. If you are using a home router then the IP address show will usually be that of the router)

At the ‘>’ prompt type google.com:

Code:

C:\Documents and Settings\Nokia>nslookup Default Server:  speedtouch.lan Address:  192.168.1.254

> google.com Server:  speedtouch.lan Address:  192.168.1.254

Non-authoritative answer: Name:    google.com Addresses:  64.233.187.99, 64.233.167.99, 72.14.207.99

>

You will see that the output of the command you entered is three different IP addresses.

Now at the prompt type in one of these IP addresses:

Code:

> 64.233.167.99 Server:  speedtouch.lan Address:  192.168.1.254

Name:    py-in-f99.google.com Address:  64.233.167.99

>

**Tip – right click the blue bar on top of your command prompt and select properties, in the Edit Options field make sure Quick Edit and Insert Mode are ticked. You can now copy and paste as you would normal text. Try highlighting a Google IP address in the normal way by moving your cursor over it with the mouse button pressed, the text will go white; now right click. To paste the text simply right click again and the text will be pasted where the flashing cursor is.**

The output from the above command tells us the IP belongs to Google.com.

What you have just done is preformed a DNS query to find out the IP address(es) that Google use for their web presence; when you entered the domain name you done a forward DNS lookup and when you entered the IP address you done a reverse DNS

lookup (rDNS).

You may still be thinking what the hell you are on about but it will become apparent now:

Try typing one of the IP addresses you got from your DNS lookup into your web browser. You are still taken to Google.

Your computer does not talk to other computers by using words such as Google.com. When you enter Google.com into your browser your computer needs to convert this into a form both it and other computers will understand. As you probably know everything on the Internet needs an IP address, as this is how all traffic is addressed on the Internet (it is different on an internal LAN but for now assume everything uses IP addresses). So something needs to take google.com and convert it to an IP address to enable your computer to go out on to the Internet and find the server that hosts the Google web site.

If you haven’t guessed it already, it is DNS’s job to do this.

Without DNS you would have to remember 64.233.167.99 and use this when you wanted to go to Google. Then when you wanted to go to Hotmail you would have to enter 64.4.33.7, and then if you wanted to go to Digg you would have to enter 64.191.203.30…… can you see how confusing this would become. If you wanted to advertise your business web site you would have to use an IP address and hope everyone could remember it……

DNS allows us to use a human readable syntax that we can remember easily, to browse the Internet. Without it, the Internet would be very chaotic.

You can find a very good explanation of DNS here: http://en.wikipedia.org/wiki/Domain_name_system

But what has all this got to do with our reconnaissance? Well there are different types of DNS records that will be used for different services. If we wanted to send an email to an organisation the a DNS record would tell the appropriate mail server the IP address of where that organisations mail server is located. This records is called an MX record (Mail Exchange), DNS records can also be used for web servers, FTP servers etc.

If we could get our hands on all of these DNS records for our target domain, we would have a huge chuck of valuable information for when it comes to the next phase of our attack; as we would know where to go to try and gain specific entry to the network….if we wanted to exploit their mail server DNS would tell us where it is, if we wanted to attack their FTP server DNS would tell us where it is……..

DNS servers support something called a Zone Transfer and what this is, is a way of the DNS server telling someone all the information it has about a certain domain, MX records, A records, PTR records etc.

There is a catch to this though and that is properly configured DNS servers only support Zone Transfers to authorised people and sometimes not at all. To go back to the WHOIS record we found, the very last entry listed is the DNS servers that our target uses:

Quote:

Name servers: ns0.serve.co.uk ns0.serve.net.uk

So let us try and see if a Zone Transfer will work on these DNS servers:

Go back to your nslookup prompt:

Code:

C:\Documents and Settings\Nokia>nslookup Default Server:  speedtouch.lan Address:  192.168.1.254

>

And type “server ns0.serve.co.uk” (you could even do an nslookup for this and use the IP address if you wanted to )

Code:

> server ns0.serve.co.uk Default Server:  ns0.serve.co.uk Address:  212.69.220.10

>

This is telling the nslookup application to query the server you have specified and not your own default one. (Obviously since this is where the information relating to the shedstore.co.uk domain is located, it is the server we need to get the info off)

To ask it for all the information it has on the shedstore.co.uk domain (a Zone Transfer), we use the following command:

Code:

> ls -d shedstore.co.uk

If Zone Transfers are enabled to casual users, and we have the right DNS server for our domain, it should reply will all of the DNS records it holds:

Code:

> server ns0.serve.co.uk Default Server:  ns0.serve.co.uk Address:  212.69.220.10

> ls -d shedstore.co.uk [ns0.serve.co.uk]  shedstore.co.uk.               SOA    ns0.serve.co.uk hostmaster.dsvr.co.uk. (2 006122800 3600 1800 86400 3600)  shedstore.co.uk.               NS     ns0.serve.co.uk  shedstore.co.uk.               NS     ns0.serve.net.uk  shedstore.co.uk.               MX     5    mx81.emailfiltering.com  shedstore.co.uk.               MX     10   mx82.emailfiltering.com  shedstore.co.uk.               MX     20   mx83.emailfiltering.com  shedstore.co.uk.               A      212.69.210.106  ftp                            CNAME  www.shedstore.co.uk  mail                           CNAME  www.shedstore.co.uk  smtp                           CNAME  www.shedstore.co.uk  www                            A      212.69.210.106  shedstore.co.uk.               SOA    ns0.serve.co.uk hostmaster.dsvr.co.uk. (2 006122800 3600 1800 86400 3600) >

** Tip – there will nearly always be two name servers listed on the WHOIS records – if the first one does not allow Zone Transfers always try the second one too, as this is usually a backup DNS server and may not be configured the same as the first one.. **

So what have we got?

We have the Start of Authority (SOA) which is the authoritative DNS server for the shedstore.co.uk domain – the numbers after it are pretty unimportant to us but refer to the zones serial number, refresh rate, retry rate etc.

The Name Server (NS) records basically tie the domain name to the DNS server. Think

of it a mapping so others can find the correct DNS server.

The MX records which we have already covered refer to where all email should be sent to for the domain. In our case it looks like Shed Store is outsourcing their email to a hosting provider of some kind.

The CNAME or Canonical name records are aliases and point back to the A record. They are usually used when there is more than one type of service using the same IP address. In this case it is FTP, HTTP and SMTP.

The A record (Address record) is the main DNS record and does the actual mapping of the domain name to the IP address. The CNAME records referred to above all refer to this A record. ( if you now do an nslookup for shedstore.co.uk it is this very A record that will be consulted to return the IP address to you)

The one glaring omission is a PTR record – which handles the rDNS lookup. (the opposite of the A record so to speak) If you do an nslookup on the IP address 212.69.210.106 you won’t get shedstore.co.uk:

Code:

C:\Documents and Settings\Nokia>nslookup 212.69.210.106 Server:  speedtouch.lan Address:  192.168.1.254

Name:    internetdesign.dsvr.co.uk Address:  212.69.210.106

This is another indication that the website is hosted by a third party, probably called Internet Design and they have only bothered to update the A record and not the PTR record. If you go back to the WHOIS record it will back this theory up:

Code:

Registrant's agent:          Thus plc t/a DSVR [Tag = DSVR]          URL: http://www.dsvr.co.uk

If we couple this with the fact the DNS server itself is not configured adequately and we were able to complete a Zone Transfer we could come up with the conclusion that this is a very sloppy setup and could mean they are not using as good a web hosting service as they could do, that they do not understand the DNS implications of their own setup, that

the have never tested their security - hence more proof they may not be very IT savvy……

IP Address

Just like domain names are registered and entered on a WHOIS database, IP addresses are also registered and entered on a database. For Europe and Asia an organisation called RIPE handles this. (http://www.ripe.net/) and for America ARIN handles it (http://www.arin.net/index.shtml). If you browse to them and enter the IP address mentioned in the A record you will find out who it is registered to:

Code:

inetnum:         212.69.210.0 - 212.69.211.255 netname:         DSVR descr:           Hosting in iP House country:         GB admin-c:         NOC5587-RIPE tech-c:          NOC5587-RIPE status:          ASSIGNED PA  mnt-by:          AS5587-MNT source:          RIPE # Filtered role:            AS5587.NET Network Operations address:         Victoria Building address:         Salford Quays address:         M5 2SP phone:           +44 207 3455256 fax-no:          +44 207 3455257

As I said it is not really applicable in this case as it is only for a web server that belongs to a hosting company. But if it was for an organisation that hosted their web server internally you would be able to get more contact details for the company from here. In this case we only get the name and address of the hosting company, which is in Salford Keys, Manchester. – It may come in handy for a social engineering attempt later on, who knows but it is worth writing it all down.

Mail Server

Mail servers are a good way of finding information out about a company and what email addresses are valid in the company. It is possible to telnet to a mail server on both port 25 and 110. When you connect you are greeted with a banner saying the type of mail server and its version.

Open a command prompt again and type the following:

Code:

C:\Documents and Settings\Nokia>telnet shedstore.co.uk 25

This is telling the telnet application to open a connection to shedstore.co.uk on port 25.

You should now see this:

Code:

220 internetdesign.dsvr.co.uk ESMTP Exim 4.52 Wed, 07 Feb 2007 20:03:06 +0000

The mail server banner is telling us the type of mail server is Exim, and it is located in the UK. It also tells us that this mail server belongs to the same people who host Shed Stores web site….but the MX records from the DNS Zone Transfer are for a different company. The must have a web mail solution and another hosted email solution.

Going by the MX record they also have email hosted with emailfiltering.com So they may have another domain name in place for email, or it may have something to do with the Guardian Buildings organisation that they are a part of. It’s hard to tell exactly why they have another email solution but it is something worth bearing in mind.

Code:

MX     5    mx81.emailfiltering.com

Browse to emailfiltering.com in your browser and see if there is a web site for it.

Yes, there is – but it has a URL redirect in place and takes you to http://www.emailsystems.com/ . If you put an ‘s’ after the HTTP (https://www.emailsystems.com/ ) and go to their secure site you are presented with a logon…….probably where you go to check your emails on line…..

Try telenting to the mail server mentioned in the MX record on port 25……now this is a seriously locked down mail server……my guess is their email hosting company do know what they are doing, unlike their web hosting company.

All this information comes in handy when we try to social engineer some information out of the companies we have discovered are target uses.

FTP

Did anyone notice their was a CNAME record for an FTP server? Let us see if it is active.

Go back to your command prompt and type:

Code:

C:\Documents and Settings\Nokia>ftp shedstore.co.uk

You should be presented with the following:

Code:

C:\Documents and Settings\Nokia>ftp shedstore.co.uk Connected to shedstore.co.uk. 220 ProFTPD 1.3.0rc2 Server (ProFTPD) [212.69.210.106] User (shedstore.co.uk:(none)):

It has told us what type of FTP server it is (ProFTPD) and is asking for a user name and password. At this point DO NOT try and gain access to anything. Remember we are researching the target passively and do not want to try and connect to anything directly related to the Shed Store company until we have taken the proper countermeasures to obscure our own identity and location on the WWW.

Web hosting companies typically provide FTP access for their customers so they can upload their web site and make any changes that are needed. I pointed out that there is a members only part to the web site earlier on, my guess would be that members can logon and maybe buy direct from the company via the user portal? If so all their details are stored on the server somewhere and if we manage to get FTP access we can also get access to all of the files and do not have to worry about trying to exploit the web service….

At this point it is enough for us to just know it is there and how to access it.

*Hey look, we have learnt they have a web site, a mail server and an FTP server and the IP address of them all…..and we didn’t have to fire up Nmap up once to tell us what services they have….**

Social Engineering

Social Engineering is the art of interacting with someone with the sole reason of maliciously soliciting information out of them. The common example is to get a user

name and password, but this is not always the case. I have endless hours of fun teaching this and getting students to phone places up and trying out what they learn in real life. It is an incredibly hard skill to master. But once you have mastered it you can save yourself hours of pain staking work trying to crack user accounts etc the hard way.

Most people think Social Engineering is something reserved for the determined attacker or for the people carrying out a Pen Test. I would suspect that 99% of the people reading this have never tried it or are ever likely too……yet they wouldn’t think twice about firing Nmap up and scanning someone’s system. In my view if you can get some information out of someone such as a password, well then it saves you having to spend hours running a dictionary attack or trying to brute force the password which you have just got hold of in a few minutes via social engineering. NEVER underestimate the Social Engineering stage of reconnaissance it nearly always pays off and saves you a lot of time and hassle.

The reason not many people do it is that to carry out an effective Social Engineering attack you need a rather large set of gonads, a very good reason to want to do it and some prior information about the person or the persons organisation that you are speaking to.

Social Engineering is not something that can be taught and is more of a skill you pick up over time. The more you do it, the better you can become at it.

There are a couple of facts about human beings in general that need to be mentioned to better explain how to carry out effective social engineering attacks:

Humans are very easily programmed and become stuck when something happens out of the ordinary. Being extra nice to someone and making that person like you and want to help you, does pay off sometimes People generally do not say no to an authoritative figure or to someone who is higher placed then them in the organisational structure. It is usually easier to coerce someone into doing something they don’t normally do, than to coerce them into doing something they do everyday.

Humans are very easily programmed and become stuck when something happens out of the ordinary.

Think of a normal hand shake; if someone walks up to you and extends their hand in a motion that signifies to you that they are about to shake yours, you are programmed to lift your hand up in response.

In certain scenarios such as when meeting someone, this is expected. But what if it happens in a situation you don’t expect it, i.e. when you are walking down the street and a perfect stranger walks up to you with an outstretched hand signifying that he wants to

shake hands with you? You still lift your hand to respond to that person, maybe not very far but you will still do it.

Now what if when meeting someone, and when you expect a hand shake, the person stops half way through extending their hand and puts it in their pocket? You still extend yours and when something happens you don’t expect, such as someone putting their hand in their pocket, your programming breaks down and for a second or two you go into limbo as you have no idea what to do. Why - Because like as not this will have never happened to you before so you have no programmed response to it.

Consider this – whilst you are in limbo during this hand shake, if the other person was to ask you what your phone number is, what would you do? You are programmed to respond to a question, so whilst your mind is in limbo wondering what the hell to do, the programmed part of it will respond to the question that has just been directed towards you and unless you manage to stop yourself in time you will answer the question.

When I was learning about Social Engineering the course was taught by a Psychologist and not an IT security professional. Half way though one talk the speaker invited a hypnotist into the seminar. The first thing this hypnotist done was to walk up to someone near the front of the audience and introduce himself – just as they were about to shake hands he put his in his pocket and said something to him, in a few seconds this guy was hypnotised and answered any question the guy asked him. He very effectively utilized the moment when his mind was wondering what it should do, to hypnotize him.

I’m not suggesting you need to walk around shaking hands with people and hypnotising them to socially engineer them, but am trying to demonstrate that when something happens out of the ordinary, people let their guard drop very temporarily and the mind is very open to external influences.

To apply this psychology to a ‘real life’ social engineering attack – imagine you phone up the web hosting company that Shed Store use (we know this info from the DNS records and the WHOIS record), and went through the normal process everyone goes through when initiating a phone call – the other person says hello, you say hello and state the reason why you are phoning – the other person will go through the process they have probably gone through 1000’s of times and asks you for your credentials to authenticate yourself……… Ooops, we hang up as we can’t do that.

To apply the methodology of breaking someone’s programming you need to do something unexpected that may have never happened to the other person before.

The list of how to do this is endless – but you have just found out your name server allows anonymous Zone Transfers right? So your going to be a tad angry – what’s the odds that if you phone up and instead of saying 'hello' which the poor help desk dude will be expecting, you start yelling down the phone straight away asking why their DNS server is miss configured. What you are going to do is put them in a situation they may have not been in before and do not know how to handle properly (chances are at the help

desk level they will not even know what a DNS Zone Transfer is). So whilst they are fumbling around trying to make sense of what you are angry about, mention (in a very pissed off voice) you cant logon to your web server and need to know your details – now this is something the person will be programmed to do and will understand, so whilst they are still trying to figure out what the hell a DNS Zone Transfer is and who they can escalate it too, they will be only too happy to do something they are familiar with (and which gives them a bit of breathing space) and lookup the details for you.

Of course you don’t have to rant and rave at someone to throw them of their guard. Try phoning an up-market hotel who do not normally give out the details of who is staying in a certain room…..when they answer just simply ask if they have the time (be very polite), I can pretty much guarantee the receptionist will have never had this happen to her before…so whist she is in the state of registering what you have just asked and what she should do in response to you, ask her who is staying in room 101 – her programming will kick in and she may very well divulge the information to you. The trick is to be nice and extra polite to her.

After you have tried this method a few times you will develop a few methods that usually work most of the time and stick to them.

Being extra nice to someone and making that person like you and want to help do, does pay off sometimes

This one kind of speaks for itself and is not something I need to cover in great detail. Use your charm to try and make someone like you enough to want to help you. This usually works best when talking to someone of the opposite sex (unless you swing the other way). The best way to do it is not to try and solicit any information during your first conversation. Phone up initially, explain who you are (or who you are pretending to be) and ask an innocent question that will not require her to ask you some questions to authenticate yourself. Such as:

“Hi, I’m Keith Taylor the Managing Director of Shed Store, well Guardian Buildings but you have us down as Shed Store. You host one of our web sites called shedstore.co.uk and I was wondering if you are experiencing any technical difficulties again, as at the moment we can’t reach it.”.

If we examine that seemingly harmless and everyday initial introduction more closely you can see what we have just done:

“Hi, I’m Keith Taylor the Managing Director of Shed Store” = Using the name we got from the WHOIS record we have introduced ourselves to her – putting a name to a voice on the telephone forces her to automatically construct a mental picture of you, which will aid us in getting her on our side. We have told her we are very high up in the company, the MD no less. How many MD’s does she speak to on a daily basis? Not many I bet, so we will now stick in her mind and she will remember us next time we call. By identifying

the company we are from, we allow her to learn a little more about us by offering her extra information, which goes in our favour but more importantly we let her know what company we are from so when we try to extract some information from her later on she may not feel the need to authenticate us.

“well Guardian Buildings but you have us down as Shed Store” – This again offers her a little more information to add to her mental picture of us. The second part of this sentence implies we have contacted them before and have regular dealings with them – again adding to our authenticity.

“You host one of our web sites called shedstore.co.uk” – Here we have told her what our web site is and that we are indeed one of their customers. This is important later on when we ask her for our login details, as she will not need to ask us what our domain name is which is usually the prelude to asking us to authenticate ourselves – we will be breaking her programming.

“I was wondering if you are experiencing any technical difficulties again, as at the moment we can’t reach it” – This reinforces the fact we have spoken to them before as we mentioned the word ‘again’. But more importantly it is a question that does not require her to authenticate us and is something she will have to search for, and gives you that ‘moment of silence’ to make idle chat with her……get to know her….and make her like and trust you.

She now has a mental image of you, knows who you work for, knows a little more info about your organisation than she may normally get to find out with most customers (which could make you stand out amongst others), she knows you are a Managing Director which again makes you more likely to be remembered by her (and all women like important men don’t they?), we have let her know that we have phoned up before, she knows your domain name – which means she won’t have to ask for it, she knows you are having technical difficulties but are still being nice to her – not many other customers would be as nice when experiencing technical difficulties, again you will stick out in her mind because of this.

After this all you can do is use your charm during the ‘moment of silence’ to get to know her.

Give it a few hours and phone back up, you may have to do this a few times until the same person answers the phone.

The second conversation could go something like this:

“ Hi <insert her name!> it’s Keith again the MD from shedstore.co.uk. I phoned you earlier to ask about some technical difficulties, I’m just wondering if you are having some issues now as we can’t access our site again and are really starting to lose business over this.”

“ Hi <insert her name!>” – You must use her name here as it tells her we have remembered her, and everyone likes to be remembered, right? Especially by an MD…

“it’s Keith again the MD from shedstore.co.uk” – This time we just use the first name, to make the conversation more friendly and social, we reinforce the fact we are an MD and again we tell her our domain name.

“I phoned you earlier to ask about some technical difficulties, I’m just wondering if you are having some issues now as we can’t access our site again and are really starting to lose business over this.” – This last part is designed to make her go off and search for something again – which will give us another moment of silence to make idle chit chat. Most important we have no emphasised that this is a serious matter to our business and needs to be resolved…but we are still being very civil and chatty to her……..this will be out of the norm for most cases she has experienced when something is going wrong….and it stresses the fact that we must be an exceptionally nice person if we are still being nice to her….hell I would want to marry me!

The knack here is to make idle chat but around a subject that you can refer to later on.

The third time you phone up, don’t mention anything work related. Start the conversation off about the subject you made idle chat about. When you feel the time is right say something along the line of “Oh I’ve forgot what it is I’m phoning for now….Oh that’s right, I can’t remember my logon for the shedstore account, can you help us out?” – Or words to that effect.

If you have done your part right she will know your domain name, be under the impression you work for Shed Store and may just go right ahead and give you the credentials you need.

I have provided a theoretical example that only uses three phone calls. In reality it could take week or even months to gain the trust of someone and it is not always done over the phone, it can quite easily be done in person. You only get one shot, if you try it to soon and she asks for credentials, obviously you can’t supply then and have to hang up wasting what could be weeks of effort in trying to gain her trust.

People generally do not say no to an authoritative figure or to someone who is higher placed then them in the organisational structure. & It is usually easier to coerce someone into doing something they don’t normally do, than to coerce them into doing something they do everyday.

You should have grasped the basics by now. If you can convince them you are important enough, they maybe willing to skip procedure to accommodate your request. Or, if you can put them under enough direct ‘managerial’ pressure they may rush the job and again not authenticate you.

The last one relates to things like the job advert I mentioned further up the page: It will be easier to get the person filling in for the missing firewall admin to make a change that it will be to get the regular firewall admin to make the change.

Accidentally phoning the wrong person, when you know the real person is away (maybe by an OOO reply to a newsgroup) can be a lot more rewarding that phoning the correct person.

Likewise instead of phoning a hosting company who are trained to authenticate people before dealing with them, try phoning the target company direct and claiming to be from the hosting centre…..it maybe easier to coerce an un-trained company employee who has never had to ask anyone for credentials in their life to part with some logon details.

Prior Information

What ever tactic you decide to use you are always going to need one thing – prior information about the person/organisation you are trying to imitate. You can’t pretend to be someone else if you know nothing about them…

What information have we managed to get from all of the above steps?

Company name – An obvious one that we need

Domain name – Handy to guess email addresses, needed for WHOIS lookups and for social engineering attempts.

Office Opening hours – What better time to attack their network than when they are not there, or if you want to phone someone claiming to be an employee it is best to do so when they are not in the office

Telephone number range – People still do use modems. With the phone range we can Wardial the company looking for them.

Company Address – A post code is often used in authentication steps. We also now know were to go to look through their rubbish if you are that way inclined Senior Person from the company – From the WHOIS record we know the name of a person who is likely to be high up in the company. Also good as a search string in newsgroups

Name Servers – You have seem why these are important

Mail Servers – In this case the email is outsourced – another avenue for a social engineer attack, either to the target claiming to be from the email company, or vice versa. The also may have a second email service for another domain.

Web site hosting company – As above; ideal for Social Engineering attempts. We also know they host a web mail solution for the company too – more info we can use for our social engineering. If we did want to social engineer them we also know their address and phone number from the RIPE record we looked up.

FTP Site – We know they have FTP access to the web site. This can come in very handy when wanting to try and exploit parts of the web site as all we have to do is find an FTP logon, we don’t need to spend a lot of time looking for web vulnerabilities.

Caller ID spoofing

You could use all of the information we have gathered together so far and you could use the very best methods of social engineering and it could all fail. They are not foolproof methods as they have a huge human element to it, and humans are very unpredictable.

However, there is one final trick in our arsenal that can sometimes work when all other attempts fail and that is to spoof our caller ID.

If someone was to ring you up at work and say “Hi its Jim, I am filling in for the System Administrator today.” You may or may not believe him. If he called and said the same thing but on your caller ID display it came up that he was indeed calling from the Sys Admins desk then the chances are that you would indeed believe him……unless his desk is in the same room as you of course.

Think of Caller ID spoofing as instantaneous credibility

It is relatively easy to spoof a caller ID, the hard part is finding what number to spoof it too.

TeleSpoof: http://www.telespoof.com/ is probably the most popular service to use since Star38 and Comophone where forced to shutdown due to very negative publicity…usually CallerID ‘falsification’ services do not stay in business very long but TeleSpoof seem to be doing a good job of it so far.

You have to pay to use TeleSpoof but it is relatively cheap and is worth trying out on your friends a few times to get the hang of it all.

If you have a VoIP setup than you can spoof your own caller ID for free, notably the Asterisk PBX is quite good for doing this and is free…

Once you have learnt of a telephone number, probably via a WHOIS record or a RIPE / ARIN record, which both usually list the System Administrators of organisation (and what better person could you pick to pretend to be!) you can spoof away and see who reveals information to you.

If you can’t find the System Administrators number, usually phoning reception and asking for it will work…. After all, why would they not give it to you?

Summary

Reconnaissance is not very glamorous, it is tedious, probably not much fun to read about and is almost never done by Script Kiddies. It is largely based on common sense and reading publicly available information, However, it is a very important part of the bigger picture. It puts you 'in tune' with the target so you don't go wondering in blindly Nmap'ing away. There is not much skill involved in it - which is why I think it puts the Skiddies off....

I have tried to run through all the steps an attacker may go through when researching your organisation. I have chosen a real life company as nothing in this paper is illegal to do. The company I chose looks to be a largely web based company and I have not revealed anything that could list their internal network presence, although there are a few ways of finding it out and the more astute of you may be able to do so by utilizing most of what I have mentioned.

The next part will cover the prelude to gaining access to a network – i.e. network discovery, mapping out a network, scanning for services, looking for weaknesses, WLAN scanning etc and will utilize the information we have learnt here. I won’t use Shed Store for this as they are a real organisation trying to run a business over the Internet and it would not be right to demonstrate methods of accessing their network, if indeed there are any.

If someone from Shed Store does read this hopefully they will look at it as a free partial vulnerability assessment and leave it at that.

Remember to write everything down that you learn about a target, no matter how small and trivial it maybe. You never know when that little bit of information may come in handy. Try out your social engineering on a few innocent people in a harmless manner; maybe try and find out who is staying in a particular hotel room etc. After a while you will get good at it and be able to use it for more ‘daring’ situations.

Some of you maybe wondering why I have not mentioned Google much at all – that is because I plan on writing another paper in the near future on how to use Google from a ‘hacking’ prospective.

Please post any questions in this thread or start a new one in the relevant forum; PM’s, Email’s and MSN messages will not be answered.

Nokia

2007 A Hacking Odyssey: Part Two – Network Scanning & Nmap Part 1

Quote:

Due to post size limits I have had to split this paper into two halves. Please find the second half here: http://tazforum.thetazzone.com/viewtopic.php?t=5766

If you have followed part one you will have most of the information needed to allow you to progress on to the second phase of your attack/Pen test.

You can find part one here: http://tazforum.thetazzone.com/viewtopic.php?t=5445

The second phase can be generically summed up as ‘Scanning’. To even start this phase we need of an absolute minimum one thing; an IP address. If you have not been able to glean and IP address during your reconnaissance phase, then you will need to go back and persevere with it, because until you get one you will not be able to do anything else….you can’t scan something if you don’t know where it is.

Scanning typically involves all or some of the following:

Covered in this paper: War Driving War Dialling Network Mapping Port Scanning

Covered in Part 3: Vulnerability Scanning IPS and IDS detection and evasion Firewall ‘auditing’ PBX scanning

Scanning a network is a very unique activity as all networks are different; they are configured in different ways, secured in different ways, use different hardware, have different services running, respond differently to various scans and use different software/OS’s – to name but a few of the variations. For this reason it is impossible to write a step by step paper along the line of ‘enter this command and you will get this output, now enter this command and you have exploited the service’. It just won’t work this way.

What I will do however is explain the theory of how it all works and explain how to use the most common tools for doing this; the most common of these common tools being Nmap, hence a large part of this paper will be devoted to it.

I will briefly cover War Dialling and War Driving first though, as they are not terribly hard to understand.

**Before I go on I need to point out that the scanning phase is the complete opposite to the reconnaissance phase in terms of exposing yourself to the target network. Reconnaissance when done properly is nearly completely passive and is entirely legal. Scanning on the other hand is not passive in any way shape or form and is for the most part illegal. You WILL leave log entries on the remote system when scanning it. Whether these look suspicious to an administrator or are suspicious enough to set off an IDS alarm is entirely up to you and the methods you chose to adopt**

War Dialling

Pretty much everyone has heard of War Dialling in today’s cyber world. It was probably made famous by the film War Games – where a young teenager connects to a government network via a Modem.

This file was released in the early 80’s and the technique used in it is still valid today…

Before VPN’s and Remote Access software were readily available the only feasible way for an employee to connect to the corporate LAN or indeed for an administrator to connect to a remote system was via a Modem; which they would ‘Dial in’ to.

Even though there are a lot more secure methods for remote access in today’s world, it does not mean that remote access via a modem does not still exist anywhere. A lot of people use the ‘if it is not broke, then don’t fix it’ philosophy. Couple this with the price of a modem (£5) and you have a very quick and extremely cheap remote access solution, albeit not a very efficient one but a working one all the same.

Think of your own dial up connection (everyone over the age of 10 must have been unlucky enough to of had a dial up connection at some point). You dial out onto the internet, usually to your ISP, enter a user name and password and viola you are connected to the Internet.

Obviously data flows both ways through this connection. If used in the conventional sense the data coming back is return traffic to one of your legitimate requests, i.e. a web page you have requested to see.

However what if the return traffic is not legitimate…….how does your modem know this……well, it doesn’t.

To use a dialup connection you must have a phone line, right? If you have a phone line then you will have a phone number. If someone dials this phone number and the line is connected to your modem…..what will they dial in to? Yep you guessed it; your modem

and in effect your computer.

A very popular procedure amongst employees was to install some remote control software such as VNC and set it to listen on the COM port that the modem was using. Then when they go home, they can dial in to the line attached to their computer and be greeted with the VNC login prompt.

In modern times (modern from an IT point of view) there is a plethora of remote control software available to any user for free or for very cheap. And all they need is a phone line installed by their desk. Chances are they will already have a phone next to their desk….so when they leave at night they connect this up to their modem, go home and dial their own number, connect to the free edition of VNC they have installed and start working from home. As far as they are concerned they are doing the company a favour as they can get more work done and it hasn’t cost the company a penny……what do they care about network security, that’s the job for they guy who keeps saying no to them whenever they ask for something……..sod him, right?

Unfortunately it is not just clueless end users who do this; Routers, switches and firewalls used to be remotely managed via a dialup link into them, with basic authentication. How often does a network infrastructure get upgraded? Not very often……..

Sadly in my experience of pen testing, 60% of the unsecured modems I find are attached to routers and not to end user work stations. System Admins come and go and they have a lot more to think about than one poxy phone line coming into an old router…….

The most common application used for War Dialling is probably THC-Scan (The Hackers Choice - http://www.thc.org/thc-scan/). It runs on pretty much anything that has a kernel and an emulator (yes even a MAC) and is extremely easy to use.

Obviously the final thing we need is a range of phone numbers right? If you have read part one you may have noticed the first two things we ever learnt about the target……its phone numbers and office hours. Why are the office hours important? Well we don’t want to try and take over a PC whilst the user is sitting in front of it do we….also if they do plug their phone line into the computer it is going to be so they can work from home….which won’t be in office hours will it?

I won’t cover instructions on how to use it as I don’t want to spend too much time on War Dialling, but there is a very good video tutorial showing how to use it on the above mentioned site and very extensive documentation is included with the download.

So you dial away and look at the log detailing what it found. If you use the Nudge feature of THC you may very well see some banners that can be very informative to use – such as ‘Hi, I’m a PC, or Hi, I am a MAC’. You will need to learn to recognise the return strings from the various modems it finds to be able to know what is listening behind the modem, i.e. VNC, PC Anywhere etc.

Some commercial War Diallers have a database that will tell you this automatically; if you don’t mind paying for them then this is a good choice to go for. PhoneSweep is probably the best commercial one available (http://www.sandstorm.net/products/phonesweep/) you can see a screen shot to better explain what I mean about identifying the system type – THC will just show you the raw output and it will be up to you to trawl through the logs and work out what system is what.

That’s pretty much it for War Dialling, find a modem, dial into it, see what remote control software is listening on the COM port, try and connect to it. The most common software listening will probably be VNC as it is free…..there is also a well publicized exploit for circumventing VNC authorisation……

War Driving

War Driving derives its name from War Dialling. If War Dialling is phoning every number in a range to find a modem, then War Driving is driving round an area looking for every Wireless Access Points.(WAP). There are subsets of War Driving such as War Walking, War Mountain Biking, War Flying, War sitting on the bench outside the building with my laptop hoping I don’t look suspicious…generically they can all be safely called War Driving.

The chances of finding a WAP in today’s world are much greater that the chances of finding a modem. In the past most security/hacking type books typically confined Wireless LAN (WLAN) hacking to a few pages at the back of the book, however now-a-days it is becoming more and more popular and more and more rewarding in terms of illegally accessing a network. Due to this the newer security and hacking books tend to devote a lot more page space to WLAN hacking.

When conducting a Pen Test, after the reconnaissance phase I usually set up a laptop and leave someone with it to carry out the War Dialling , whilst that is running I will drive around the targets building and War Drive it. By the time I get back we are able to go through the results of both assessments. If we find any ‘miss configurations’ it usually gives us a general impression as to the state of the network and its security.

WLAN’s obviously use radio transmissions to transmit data from one node to another. Our aim as WLAN hackers is to put ourselves within range of these transmissions so we can also receive them and look at the contents being sent.

Before we do this we obviously need to find the Wireless networks.

WLAN’s all have a network name, which is what distinguishes them from each other and helps employees know which one they are meant to connect to. This network name is known as the Extended Service Set Identifier or ESSID. If you open your wireless network properties and search for networks, you will end up with a list of networks that

your wireless adaptor is within range of. Each of these will have a name, what you are looking at is the ESSID of each WLAN.

ESSID’s are transmitted in clear to every wireless client that may be listening; this forms part of the ‘beacon’ that is transmitted periodically by the AP and is included on most packets leaving the WAP. Likewise when a client is associated with an AP, this also transmits the ESSID in clear.

It is possible for a wireless client that is not associated with an AP to send a ‘probe request’ to the AP asking for various bits of information. Normally the ESSID is included with these requests and any AP that does not have the same ESSID will drop the packet.

The rules of the various 802.11 protocols say that it must acknowledge a probe request that is using the ESSID configured on the AP OR that has the ESSID parameter set to ‘Any’.

If you re-read the above statement you will see a fairly large whole in the 802.11 implementations that we can exploit: “OR that has the ESSID parameter set to ‘Any’.”….

SO, if we send probe requests and set the ESSID bit to ‘any’…then all WAP’s within range must respond to the requests….. and when the WAP’s send traffic what is included in the packet, yep the ESSID.

Netstumbler (http://www.netstumbler.com/) which is arguably the most popular War Driving tool around uses this ‘flaw’ in the 802.11 protocols. It sends out 100’s of probe requests with the ESSID bit set to any and waits for return traffic. When this traffic comes it extracts the ESSID, sending MAC address, wireless channel and approximate signal strength of the WAP or the wireless client. If your wireless adaptor is set to receive a DHCP IP address (one that is automatically assigned to you) then Netstumbler will also record the IP range in use on that WLAN.

Wireless Access Points can be configured to ignore probe requests with the ESSID bit set to ‘any’, but as we will see later on this does not really increase the WLAN security. They will however defeat Netstumbler static of using the ‘any’ ESSID and will remain hidden to it.

Personally I don’t like Netstumbler due to it being very very noisy…..100’s of probe requests with the ESSID set to ‘any’ will set wireless IDS alarms of in an instant. Couple this with the fact it won’t pick up WLAN’s with the ESSID set to ‘any’ and you are found wanting when conducting an ‘Active Scan’. You set all the IDS’s off and may still not find all the WLAN’s.

It must be mentioned that Netstumbler comes into its element when using it with a GPS and a decent antenna though.

So how do we find the WLAN’s that are ignoring probe requests with the ‘any’ ESSID bit set and at the same time avoid setting off IDS’s?

To accomplish this we need to put of card into Monitor mode (sometimes referred to as rfmon mode)

Most people confuse promiscuous mode with monitor mode. They are two very different things. Promiscuous mode will listen to all traffic that is sent on a WLAN that it is currently associated with. If it is not associated with a certain WLAN, then it will not accept traffic from it. Monitor mode on the other hand listens to all WLAN traffic without associating to any WLAN.

Obviously if we have not associated with a WLAN and are not sending any packets to any, then no one will know we are there and no IDS alarms will be raised.

Airodump (http://www.wirelessdefence.org/Contents/Aircrack_airodump.htm) which run on *nix platforms, Airodump-ng (http://www.aircrack-ng.org/doku.php?id=airodump-ng) which runs on Windows platforms and Wellenreitter (http://www.remote-exploit.org/) which is now part of the BackTrack live CD are the most popular tools for this and are all capable of capturing packets in monitor mode. For the anoraks that use a MAC, Kismet will run on your *cough* MAC (http://www.kismetwireless.net/index.shtml) as well as pretty much any other OS too.

See here for a tutorial on using Airodump and indeed how to crack the WEP encryption: http://www.tazforum.thetazzone.com/viewtopic.php?t=2069

There will be a counterpart explaining packet injection with Windows and how to crack WPA-PSK at some point in the near future.

Which ever one you chose to use you will more than likely need extra drivers to put your wireless adaptor into monitor mode. Once in monitor mode you can chose to capture all packets as either an ‘.ivs’ file (for WEP cracking) or a ‘.cap’ file for viewing with applications such as Ethereal or Wireshark as it is now known.

The only occurrence left that we may find is if the WAP has been configured to not reply to probe requests set to ‘any’ and it is not broadcasting the ESSID with its beacons and is not a whole lot of traffic going over it. As long as there are clients associated with it (Airodump will tell us this, as will Wellenreitter) we can force a client off the WLAN and make it have to re-associate again. Commonly referred to as a Deauthentication Attack or Deauth for short, this forces traffic to be sent over the WLAN and will reveal the ESSID to us. It also forms the basis for WPA-PSK hacking.

A deauth attack utilizes yet another weakness with the 802.11 protocols, whereby a client will accept and obey a deauthentication packet that is sent by the AP without any

authentication at all. In a nutshell what this means is that if we can send a deauthentication packet to a wireless client and make the packet look like it came from the AP, then the client will disassociate from that WLAN.

To take it one step further if we send the deauthentication packet to the broadcast address of the LAN then all of the wireless clients will disassociate from it.

When the clients re-associate to the LAN they have to broadcast an association packet which contains the ESSID in plain text to announce to the AP that they want to associate with it, otherwise no AP will answer, as if you remember from earlier they will only answer to their own ESSID, (or the ESSID of ‘any’ if configured to do so).

This is a slightly more noisy way of finding the ESSID, but nowhere near as noisy as Netstumbler. You may set IDS alarms off with this too, so use it with caution.

The trick in all of the above is finding the right WLAN for your target as you could be up 10’s of WLAN in the area, so you need to know which one is the right one.

Most companies will name their WLAN something relevant to them or even name it the same as the company name. If this is the case then they have just made your job a lot easier. If the ESSID does not give you any info and you still have no idea which one belongs to your target you could try using the signal strength to make a best guess as to which WLAN is coming from your targets building, maybe visit the reception of your target and ask for directions to somewhere and then have a look at your WLAN sniffer’s logs to see what network had the strongest signal for the time you were in the building. If this is not providing you with any results you could even try phoning the IT dept up and asking them…..most will tell you the name there and then.

The final things to say are that if you are having trouble picking up the signal, try again at night time or better yet at night time after it has been raining. Wireless signals travel further at night and further still when the ground is damp. If you still can’t get a signal try using a better antenna.

Mapping the Network

If we are going to try and gain entry to the network, it is a good idea to know the layout of it. Any half decent attacker will draw out his findings so that he has a diagram with as much information as he can find, which might be a lot or a very little.

It is rather hard to map out networks that use NAT/PAT as our traces won’t get past the border router or firewall – we can’t trace to an internal IP address over the internet. However, if we have managed to find a way in via our War Driving and/or Dialling attempts then we already have access to the internal address space so can trace away to our hearts content. Either way a trace route works the same and the inner workings of it

are very simple.

An IP packet has a Time To Live field set in it, commonly referred to as a TTL. Every layer 3 device such as a router or a layer 3 switch will decrement this TTL field by one as it routes the packet.

(See here if you are unsure what layer 3 refers to)

Once the frame has passed through enough layer 3 devices to reduce the TTL field to zero the layer 3 device who reduced it to zero, will drop it altogether. Without the TTL theoretically an IP packet would travel around a network for ever….

(According to the RFC the TTL is decremented by one for every second that the router has it. Due to the routing speed of most routers they typically have it for a lot less then a second, so it is safe to say that it will be reduced by one for every router it passes though)

When this last router drops the packet it needs to send something back to the original sender to say that the packet has timed out, as per RFC rules. To do this it will send an ICMP Time Exceeded message (ICMP type 11 as defined in RFC792).

Here is where the trace part comes in:

We now that only a router will send the ICMP time exceeded message. The source IP address of this times exceeded message will be the routers IP address. If we know what the original TTL setting was we can determine how many hops away the router that sent the time exceeded message is. (A hop is considered to be a routing device that the packer passes through, so two hops means it has gone through two routers)

So we set the TTL to one – then send it to the first router, this will decrement the TTL to zero and be forced to drop the packet and send the ICMP message to us – when we receive this message we learn the IP address of the first router.

Then we set the TTL to a value of two – the first router decrements the TTL to one, but then as it is not zero it sends it on to the next router in its path – this router receives it, decrements the TTL to zero and is forced to send the ICMP type 11 message to us – thereby giving us the IP address of the second router.

Then we set the TTL to three and the same process occurs until it gets to the final router.

Setting all thses TTL fields manually can be quite a time consuming task, so MS and *nix have an application that will do it for us. The Microsoft version is called tracert and the *nix version is called traceroute.

Simply open up a command prompt and type ‘tracert’ followed by the destination IP address or Fully Qualified Domain Name (FQDN):

Code:

  C:\Documents and Settings\Nokia>tracert google.com

Tracing route to google.com [72.14.207.99] over a maximum of 30 hops:

  1    95 ms    99 ms    99 ms  speedtouch.lan [192.168.1.254]   2   241 ms   256 ms   257 ms  brnt-bam-2.inet.ntl.com [194.145.148.7]   3   239 ms   248 ms   251 ms  brnt-t3core-1a-ge-110-0.inet.ntl.com [213.105.19 9.85]   4   223 ms   227 ms   245 ms  bre-bb-a-so-130-0.inet.ntl.com [213.105.174.245]

  5   240 ms   255 ms   247 ms  gfd-bb-b-so-120-0.inet.ntl.com [213.105.172.150]

  6     *      217 ms   226 ms  nth-bb-a-so-000-0.inet.ntl.com [62.253.185.97]   7   256 ms   247 ms   245 ms  nth-bb-b-so-200-0.inet.ntl.com [213.105.172.194]

  8   279 ms   265 ms   248 ms  tele-ic-1-as0-0.inet.ntl.com [62.253.184.2]   9   250 ms   278 ms   268 ms  212.250.14.66  10   245 ms   268 ms   277 ms  72.14.238.244  11   319 ms   316 ms   317 ms  216.239.46.112  12   359 ms   352 ms   356 ms  72.14.233.113  13   344 ms   349 ms   337 ms  66.249.94.96  14   343 ms   341 ms   337 ms  66.249.94.118  15   353 ms   349 ms   343 ms  eh-in-f99.google.com [72.14.207.99]

The numbers on the side indicate what the TTL was for that hop. The next three columns tell us the round trip time and the last part of it tells us the FQDN of the router if there is a DNS entry in existence for that IP address, or it will just tell us the IP address of it.

You can usually tell by the trace route output which routers belong to the same organisation; the first seven hops in my trace all belonged to NTL.

Some times however the routers won’t play by the rules and will be configured to not send ICMP Time Exceeded messages out. If this is the case you will get some **** instead of an IP address. You could also be unlucky enough to come across a router that will not allow ICMP type 11 packets to pass through it. If this is the case you will get all

****’s from this router onwards as the return packets can not get to you hence you can’t trace the routers IP address.

Ping Sweep

To go hand in hand with traceroute you can also PING a target or a targets subnet to see what hosts are active on it.

There are hundreds of tools available but I suppose the most common is Nmap. Use the –sP option to Ping Sweep a subnet. For example if we ping sweep the IP addresses adjacent to Google (we found Google’s IP from our trace route) we will be able to see what is alive:

Code:

C:\Documents and Settings\Nokia>nmap -sP 72.14.207.0-255

Starting Nmap 4.03 ( http://www.insecure.org/nmap ) at 2007-02-13 20:38 GMT Standard Time Host 72.14.207.4 appears to be up. Host 72.14.207.5 appears to be up. Host 72.14.207.6 appears to be up. Host 72.14.207.8 appears to be up. Host eh-in-f9.google.com (72.14.207.9) appears to be up. Host eh-in-f19.google.com (72.14.207.19) appears to be up. Host eh-in-f32.google.com (72.14.207.32) appears to be up. Host eh-in-f33.google.com (72.14.207.33) appears to be up. Host eh-in-f34.google.com (72.14.207.34) appears to be up. Host eh-in-f35.google.com (72.14.207.35) appears to be up. Host eh-in-f36.google.com (72.14.207.36) appears to be up. Host eh-in-f37.google.com (72.14.207.37) appears to be up. Host eh-in-f38.google.com (72.14.207.38) appears to be up. Host eh-in-f39.google.com (72.14.207.39) appears to be up. Host eh-in-f40.google.com (72.14.207.40) appears to be up. Host eh-in-f41.google.com (72.14.207.41) appears to be up. Host eh-in-f42.google.com (72.14.207.42) appears to be up. Host eh-in-f43.google.com (72.14.207.43) appears to be up. Host eh-in-f44.google.com (72.14.207.44) appears to be up. Host eh-in-f45.google.com (72.14.207.45) appears to be up. Host eh-in-f46.google.com (72.14.207.46) appears to be up. Host eh-in-f47.google.com (72.14.207.47) appears to be up. Host eh-in-f48.google.com (72.14.207.48) appears to be up. Host eh-in-f49.google.com (72.14.207.49) appears to be up. Host eh-in-f50.google.com (72.14.207.50) appears to be up. Host eh-in-f51.google.com (72.14.207.51) appears to be up.

Host eh-in-f52.google.com (72.14.207.52) appears to be up. Host eh-in-f53.google.com (72.14.207.53) appears to be up. Host eh-in-f54.google.com (72.14.207.54) appears to be up. Host eh-in-f56.google.com (72.14.207.56) appears to be up. Host eh-in-f57.google.com (72.14.207.57) appears to be up. Host eh-in-f58.google.com (72.14.207.58) appears to be up. Host eh-in-f59.google.com (72.14.207.59) appears to be up. Host eh-in-f60.google.com (72.14.207.60) appears to be up. Host eh-in-f61.google.com (72.14.207.61) appears to be up. Host eh-in-f62.google.com (72.14.207.62) appears to be up. Host eh-in-f63.google.com (72.14.207.63) appears to be up. Host eh-in-f64.google.com (72.14.207.64) appears to be up. Host eh-in-f65.google.com (72.14.207.65) appears to be up. Host eh-in-f66.google.com (72.14.207.66) appears to be up. Host eh-in-f67.google.com (72.14.207.67) appears to be up. Host eh-in-f68.google.com (72.14.207.68) appears to be up. Host eh-in-f69.google.com (72.14.207.69) appears to be up. Host eh-in-f70.google.com (72.14.207.70) appears to be up. Host eh-in-f71.google.com (72.14.207.71) appears to be up. Host eh-in-f72.google.com (72.14.207.72) appears to be up. Host eh-in-f73.google.com (72.14.207.73) appears to be up. Host eh-in-f74.google.com (72.14.207.74) appears to be up. Host eh-in-f75.google.com (72.14.207.75) appears to be up. Host eh-in-f76.google.com (72.14.207.76) appears to be up. Host eh-in-f77.google.com (72.14.207.77) appears to be up. Host eh-in-f78.google.com (72.14.207.78) appears to be up. Host eh-in-f79.google.com (72.14.207.79) appears to be up. Host eh-in-f80.google.com (72.14.207.80) appears to be up. Host eh-in-f81.google.com (72.14.207.81) appears to be up. Host eh-in-f83.google.com (72.14.207.83) appears to be up. Host eh-in-f84.google.com (72.14.207.84) appears to be up. Host eh-in-f88.google.com (72.14.207.88) appears to be up. Host eh-in-f91.google.com (72.14.207.91) appears to be up. Host eh-in-f93.google.com (72.14.207.93) appears to be up. Host eh-in-f95.google.com (72.14.207.95) appears to be up. Host eh-in-f96.google.com (72.14.207.96) appears to be up. Host eh-in-f97.google.com (72.14.207.97) appears to be up. Host eh-in-f99.google.com (72.14.207.99) appears to be up. Host eh-in-f100.google.com (72.14.207.100) appears to be up. Host eh-in-f101.google.com (72.14.207.101) appears to be up. Host eh-in-f104.google.com (72.14.207.104) appears to be up. Host eh-in-f107.google.com (72.14.207.107) appears to be up. Host eh-in-f112.google.com (72.14.207.112) appears to be up. Host eh-in-f115.google.com (72.14.207.115) appears to be up. Host eh-in-f117.google.com (72.14.207.117) appears to be up. Host eh-in-f121.google.com (72.14.207.121) appears to be up.

Host eh-in-f123.google.com (72.14.207.123) appears to be up. Host eh-in-f129.google.com (72.14.207.129) appears to be up. Host eh-in-f133.google.com (72.14.207.133) appears to be up. Host eh-in-f161.google.com (72.14.207.161) appears to be up. Host 72.14.207.162 appears to be up. Host 72.14.207.164 appears to be up. Host 72.14.207.165 appears to be up. Host eh-in-f176.google.com (72.14.207.176) appears to be up. Host eh-in-f177.google.com (72.14.207.177) appears to be up. Host eh-in-f178.google.com (72.14.207.178) appears to be up. Host eh-in-f179.google.com (72.14.207.179) appears to be up. Host eh-in-f180.google.com (72.14.207.180) appears to be up. Host eh-in-f181.google.com (72.14.207.181) appears to be up. Host eh-in-f182.google.com (72.14.207.182) appears to be up. Host eh-in-f183.google.com (72.14.207.183) appears to be up. Host eh-in-f184.google.com (72.14.207.184) appears to be up. Host eh-in-f187.google.com (72.14.207.187) appears to be up. Host eh-in-f190.google.com (72.14.207.190) appears to be up. Host eh-in-f191.google.com (72.14.207.191) appears to be up. Host eh-in-f196.google.com (72.14.207.196) appears to be up. Host eh-in-f212.google.com (72.14.207.212) appears to be up. Host 72.14.207.221 appears to be up. Host 72.14.207.222 appears to be up. Host 72.14.207.224 appears to be up. Host 72.14.207.225 appears to be up. Host 72.14.207.227 appears to be up. Host 72.14.207.228 appears to be up. Host 72.14.207.230 appears to be up. Host 72.14.207.231 appears to be up. Host 72.14.207.233 appears to be up. Host 72.14.207.234 appears to be up. Host 72.14.207.236 appears to be up. Host 72.14.207.237 appears to be up. Host 72.14.207.251 appears to be up. Host 72.14.207.252 appears to be up. Host 72.14.207.253 appears to be up. Host 72.14.207.254 appears to be up. Nmap finished: 256 IP addresses (109 hosts up) scanned in 22.328 seconds

Oh my, doesn’t Google have rather a lot of servers.

The last thing to note is that just like ICMP time exceeded messages; ICMP replies can also be blocked by routers & firewalls and the actual host can also be configured not to reply to ICMP requests.

Port Scanning

Port scanning is a very useful tool that is very much in favour of the attackers. If we are to find a way into a network then it will more than likely be through a vulnerable service of some kind.

Most newcomers find ‘ports’ a difficult concept to grasp due to them trying to think of them as physical ports, hence when I say there are 65356 different ports you probably try and picture the back of a computer with all these ports sticking out of it.

The ports are entirely configured in software and in very simple terms all they are is a way of keeping traffic from different services separate.

A service can be a Mail Server, a Web Server, an FTP server etc. If someone sends you an email, you don’t want it going to your web server do you?

So all these services are given their own ports to use by way of a port number. There are 65356 TCP ports and 65356 UDP ports.

Take a SMTP Mail server and a Web server for example:

An SMTP Mail server usually uses port 25 (TCP) and an FTP server will usually use port 21 (TCP)

If I send you an email, your computer can’t just simply read it and determine it is an email and needs to go to the mail server – like wise if I send you a file via FTP your computer cant read this and know it is a file destined for the FTP service…only the relevant services will know what to do with the data. So we need a way to tell your computer to send the right data to the right service.

To accomplish this we put the destination port number in the packet and then send it to the computer. This way when the data arrives at the computer all it has to do is look for a port number, if it says port 25 then it knows to send it to the service listening on port 25, which will be the Mail server – the mail server receives this traffic, understands what it is and passes it on up to your mail client so you can read it.

If I want to send you a file via FTP I first open up a channel to you on port 21. Your computer receives this data, looks at the destination port number and knows where to send it to, in this case the service listening on port 21; FTP.

There is more to it than this, but in essence this is what happens.

The obvious limitation to this is that every service needs to be listening on the correct port – if I am to send an email to you I need to know that your mail server is listening on port 25 for me to put the destination port number in the packet…if you have your mail

server listening on port 50, when I send an email to you, your computer will look at the port number (25), see there is no service listening on that port and drop the data. You would also be disrupting the service that should be listening on port 50.

For this reason the Internet Assigned Numbers Authority (IANA) have a very strict registration process to control which service will listen on which port.

From the IANA web site:

Quote:

The port numbers are divided into three ranges: the Well Known Ports, the Registered Ports, and the Dynamic and/or Private Ports.

The Well Known Ports are those from 0 through 1023.

DCCP Well Known ports SHOULD NOT be used without IANA registration. The registration procedure is defined in [RFC4340], Section 19.9.

The Registered Ports are those from 1024 through 49151

DCCP Registered ports SHOULD NOT be used without IANA registration. The registration procedure is defined in [RFC4340], Section 19.9.

The Dynamic and/or Private Ports are those from 49152 through 65535

In layman’s terms; Well Known ports are used for the most common services specific to network and Internet functionality, such as FTP, SMTP, Telnet, HTTP, DNS etc

Registered Ports are for common services that are not specific for the functionality of a Network or the Internet such as PC games, Kazza, SQL cluster manager, Anti Virus etc – things that are widely used and that others need to know the port number in advance for.

The Dynamic and private ports can be used by anyone for anything.

You can find a constantly updated list of port assignments on the IANA web site: http://www.iana.org/assignments/port-numbers

So, taking it a step further and looking at it from a bad guy’s point of view, if someone wants to run a mail server and receive email then they need to have a mail server listening on port 25.

If we send a data packet to that port and we get a response back, we know that as per IANA regulations that is has to be a mail server who sent this response. If we don’t get a response back then there is nothing listening on that port, hence there is no service

running.

There are two mail types of protocol used for the transmission of data over a network and the Internet; User Datagram Protocol (UDP) and Transmission Control Protocol (TCP). Even though they both do the same job, they do it in very different ways. If you are not to sure about how TCP and UDP works and the differences between the two, please read THIS before continuing on with this paper as you will need to have a rudimentary understanding of it to understand how a port scan works and the benefits of using different types of scan.

Which brings us nicely on to Nmap….

Nmap (Part 1 of 3)

Nmap is probably the worlds most famous and useful port scanner. It runs on pretty much every Operating System and is relatively straight forward to use. For Windows there is a graphical version and a command line version, which can both be found here: http://insecure.org/nmap/download.html

For this paper I shall use the Command Line Interface (CLI) version however if you have never used it before it maybe worth while to use the graphical version until you are comfortable with it.

After installing Nmap and the Winpcap drivers that come with it Windows XP Service Pack 2 users should install the registry file. It can be found in, C:\Program Files\Nmap, simply right click on ‘nmap_performance.reg’ and select merge – the latest release has this as an install option.

You can now use Nmap by typing nmap directly into a command prompt. You need to be an administrator/root of the host you install Nmap on to use all of its features. If you already have Nmap installed use the following command to ensure you have the latest version (Version 4.20 as of this writing): “nmap --version”

If you do not add any option after typing nmap it will display a list of commonly used parameters that you can use for your scan:

Code:

Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Nokia>nmap Nmap 4.03 ( http://www.insecure.org/nmap ) Usage: nmap [Scan Type(s)] [Options] {target specification} TARGET SPECIFICATION:   Can pass hostnames, IP addresses, networks, etc.

  Ex: scanme.nmap.org, microsoft.com/24, 192.168.0.1; 10.0.0-255.1-254   -iL <inputfilename>: Input from list of hosts/networks   -iR <num hosts>: Choose random targets   --exclude <host1[,host2][,host3],...>: Exclude hosts/networks   --excludefile <exclude_file>: Exclude list from file HOST DISCOVERY:   -sL: List Scan - simply list targets to scan   -sP: Ping Scan - go no further than determining if host is online   -P0: Treat all hosts as online -- skip host discovery   -PS/PA/PU [portlist]: TCP SYN/ACK or UDP discovery to given ports   -PE/PP/PM: ICMP echo, timestamp, and netmask request discovery probes   -n/-R: Never do DNS resolution/Always resolve [default: sometimes]   --dns-servers <serv1[,serv2],...>: Specify custom DNS servers   --system-dns: Use OS's DNS resolver SCAN TECHNIQUES:   -sS/sT/sA/sW/sM: TCP SYN/Connect()/ACK/Window/Maimon scans   -sN/sF/sX: TCP Null, FIN, and Xmas scans   --scanflags <flags>: Customize TCP scan flags   -sI <zombie host[:probeport]>: Idlescan   -sO: IP protocol scan   -b <ftp relay host>: FTP bounce scan PORT SPECIFICATION AND SCAN ORDER:   -p <port ranges>: Only scan specified ports     Ex: -p22; -p1-65535; -p U:53,111,137,T:21-25,80,139,8080   -F: Fast - Scan only the ports listed in the nmap-services file)   -r: Scan ports consecutively - don't randomize SERVICE/VERSION DETECTION:   -sV: Probe open ports to determine service/version info   --version-intensity <level>: Set from 0 (light) to 9 (try all probes)   --version-light: Limit to most likely probes (intensity 2)   --version-all: Try every single probe (intensity 9)   --version-trace: Show detailed version scan activity (for debugging) OS DETECTION:   -O: Enable OS detection   --osscan-limit: Limit OS detection to promising targets   --osscan-guess: Guess OS more aggressively TIMING AND PERFORMANCE:   Options which take <time> are in milliseconds, unless you append 's'   (seconds), 'm' (minutes), or 'h' (hours) to the value (e.g. 30m).   -T[0-5]: Set timing template (higher is faster)   --min-hostgroup/max-hostgroup <size>: Parallel host scan group sizes   --min-parallelism/max-parallelism <time>: Probe parallelization   --min-rtt-timeout/max-rtt-timeout/initial-rtt-timeout <time>: Specifies       probe round trip time.   --max-retries <tries>: Caps number of port scan probe retransmissions.   --host-timeout <time>: Give up on target after this long

  --scan-delay/--max-scan-delay <time>: Adjust delay between probes FIREWALL/IDS EVASION AND SPOOFING:   -f; --mtu <val>: fragment packets (optionally w/given MTU)   -D <decoy1,decoy2[,ME],...>: Cloak a scan with decoys   -S <IP_Address>: Spoof source address   -e <iface>: Use specified interface   -g/--source-port <portnum>: Use given port number   --data-length <num>: Append random data to sent packets   --ttl <val>: Set IP time-to-live field   --spoof-mac <mac address/prefix/vendor name>: Spoof your MAC address   --badsum: Send packets with a bogus TCP/UDP checksum OUTPUT:   -oN/-oX/-oS/-oG <file>: Output scan in normal, XML, s|<rIpt kIddi3,      and Grepable format, respectively, to the given filename.   -oA <basename>: Output in the three major formats at once   -v: Increase verbosity level (use twice for more effect)   -d[level]: Set or increase debugging level (Up to 9 is meaningful)   --packet-trace: Show all packets sent and received   --iflist: Print host interfaces and routes (for debugging)   --log-errors: Log errors/warnings to the normal-format output file   --append-output: Append to rather than clobber specified output files   --resume <filename>: Resume an aborted scan   --stylesheet <path/URL>: XSL stylesheet to transform XML output to HTML   --webxml: Reference stylesheet from Insecure.Org for more portable XML   --no-stylesheet: Prevent associating of XSL stylesheet w/XML output MISC:   -6: Enable IPv6 scanning   -A: Enables OS detection and Version detection   --datadir <dirname>: Specify custom Nmap data file location   --send-eth/--send-ip: Send using raw ethernet frames or IP packets   --privileged: Assume that the user is fully privileged   -V: Print version number   -h: Print this help summary page. EXAMPLES:   nmap -v -A scanme.nmap.org   nmap -v -sP 192.168.0.0/16 10.0.0.0/8   nmap -v -iR 10000 -P0 -p 80 SEE THE MAN PAGE FOR MANY MORE OPTIONS, DESCRIPTIONS, AND EXAMPLES

Some of these options you will use all the time and some you may never use but if you spend a few minutes to read through them it will give you a basic understanding of the way you configure nmap to scan for you.

The syntax is generally ‘nmap’ followed by the scan type and any scan option, followed

by the IP address or IP address range, followed by the ports you want to scan (not always required), followed by the output you want i.e. filename and file type:

Code:

Nmap –sT –P0 80.80.80.80 –p 80 –oN scan.doc

This simple scan tells Nmap to conduct a TCP connect scan, against 80.80.80.80 on port 80 and to save the results to a file called scan.doc.

**I use the IP address of 80.80.80.80 in this paper purely due to the fact it is quick to type**

The following pages will cover all of the Scan Types, most of the scan options and a few maybe not so well known tips and tricks we can do perform with Nmap.

As this moment in time there are 12 different types of scan you can perform with nmap:

1) TCP Connect –sT

This is the ‘scan by the rules’ option and will try to establish a full and RFC compliant TCP connection to the remote host on the necessary port. If the connection is successful then the port is reported as being open. Although this is the most reliable scan type it is also the most risky for a would-be attacker as the connection will be recorded by the remote system due to it being a complete connection.

The syntax for this would be: nmap –sT 80.80.80.80. (obviously substitute 80.80.80.80 for the IP address you want to scan)

2) TCP SYN scan -sS

The SYN scan is a little stealthier than the Connect scan as it does not establish a full TCP connection. Instead of completing the full TCP three-way handshake it will only go through half of it. If you have read the above paper I linked to you will understand the three-way TCP handshake:

SYN SYN-ACK ACK

The initiating host sends a packet marked with a SYN flag, next the receiving host will respond with a SYN-ACK and finally to complete the three-way handshake the initiating host will send an ACK packet. (This ACK is then flagged in all subsequent packets for that connection – remember this for later)

In plain speak the SYN packet saying ‘I have some data for you, do you want it?’ to with the receiving station will send a SYN-ACK which means ‘Yes I do, please send it’ and the initiating host responds with the ACK which means ‘OK, here it comes’.

Now if we send the initial SYN packet and the remote host responds with the SYN-ACK packet as it should BUT we do not send the expected ACK packet, then we have not completed a valid connection. If we send a FIN packet, which tells the remote host to tear down any connection it may have, and then our connection attempt may not get logged due to the connection being terminated before it was complete.

The fact that the remote host responded with a SYN-ACK on the port we sent the SYN packet to is enough to tell us that there is a service listening on that port and that is all we need to find out…

Some modern firewalls and routers will recognise this pattern of packets (SYN, SYN-ACK, FIN) as a SYN scan though and may still log it.

The syntax for a TCP SYN scan is: nmap –sS 80.80.80.80

3)TCP ACK scan -sA

Following on from the packets we have sent and received so far, it makes sense to try and send an ACK packet and see what we get. This is where we start to break the rules of TCP connections. So far we have complied with the RFC rules that dictate a valid TCP connection starts with a SYN, then has a SYN-ACK and then has an ACK (which we bent a little on the last scan by not sending a final ACK but the connection was still initiated by the book)

By sending an ACK packet first we hope to get past any packet filters that may be filtering our normal SYN/SYN-ACK packets.

Some older non-stateful packet filters base their decision on what packets to allow and what to drop solely on the TCP control bit (the SYN/ACK etc). If you were on an internal LAN that allowed all outgoing traffic but denied all inbound traffic you would not be able to do anything on the Internet as nothing would reach you, i.e. when you wanted to view a web page the data would not get to you as your packet filter would be blocking it all..

To get around this problem non-stateful packet filters such as a border router or a low end firewall will look at the TCP control bit and see if it is a SYN or an ACK; if it is a SYN then it must be someone trying to originate a connection from the Internet, hence it will drop the packet. However if the ACK bit is set, then by the RFC rules it must belong to a connection that is already established, and since it won’t let SYN packets in, only out, the connection must have been established by an internal host therefore it will allow the packet through.

However there is a slight difference with this type of scan – our first two scans (TCP Connect and SYN) will determine if a port is open by the response it receives from the remote host. If a SYN-ACK comes back the port obviously is open and replying to the SYN packet as normal, however when a SYN packet is destined to a port that is closed the remote host will send a RST (Reset) packet back. Nmap will determine the port state by these responses and show you the port as open or closed accordingly.

If you send a packet that does not comply with the RFC rules (such as an ACK packet that does not follow a SYN, SYN-ACK) then it will respond with a RST packet and reset the connection.

Can anyone see where we are going to run into trouble here? If we send a TCP ACK packet to a remote host, as it does not comply with the rules we will get a RST packet back…..but we have just said that if a port is closed a RST packet will also be sent back…..so no matter if the port is open or closed the remote host will always send a RST packet back to an ACK scan probe……….what use is this ACK scan then?

The ACK scan is used to test non-stateful packet filtering rules. So say a border router has been configured to block all packets to ports 100-200 but to allow them on port 80, further to this established connections are allowed on all ports over 1024.

When we scan this with an ACK scan the packet filtering device will drop all packets destined to ports 100 – 200 as this is what it has been told to do – so we will either get no response or an ICMP Destination Unreachable response back, either way Nmap will know the probe failed. When it gets to port 80 the packet filter will let the traffic through and the host on the other side of the packet filter will send a RST packet because as we know an ACK packet is not a valid way to start a TCP connection – if a RST packet comes back Nmap knows the packet filter must have allowed the packet through (otherwise either an ICMP unreachable or nothing at all would have come back) and will mark it as UNfiltered. When it gets to port 1024 and over as the packet filter has been told to allow established connections through (packets with the ACK flag) all of our probes will be allowed to traverse the packet filter and we will get back a load of RST packets – therefore Nmap will flag the ports as UNfiltered.

Going off this output we will be able to determine that port 80 and all ports over 1024 will accept incoming packets that are part of a valid connection.

This type of scan does not actually tell us if a port is open or closed on the remote host; it only tells us if the packet filter device allowed the packet through or dropped them, as even if there was a Web Server running on the host behind the packet filter, it will still send a RST packet back when a probe comes to port 80……likewise if there was no Web Server running then a RST packet will still come back.

The theory of the ACK scan can be quite confusing if you are new to TCP connections and packet filters but just remember that it will only tell us if a packet filter will allow the

packets into the network, it will not tell us if the port is actually open on the remote host.

The syntax for the ACK scan is: nmap –sA 80.80.80.80 The output will be something similar to the following:

Code:

PORT      STATE      SERVICE 53/tcp    UNfiltered domain 80/tcp    UNfiltered http 443/tcp   UNfiltered https 1025/tcp  UNfiltered NFS-or-IIS 1026/tcp  UNfiltered LSA-or-nterm 1027/tcp  UNfiltered IIS 1029/tcp  UNfiltered ms-lsa 1030/tcp  UNfiltered iad1 1031/tcp  UNfiltered iad2 1032/tcp  UNfiltered iad3 1033/tcp  UNfiltered netinfo 1040/tcp  UNfiltered netsaint

If there is no mention of the port then it is deemed to be blocked by the packet filtering device, if it says UNFiltered then obviously the packet filter let the ACK packet through.

4) FIN Scan –sF, Xmas-Tree Scan –sX and Null Scan –sN

So far we have not managed to scan a remote host in a way that is not likely to leave log entries. We have initiated a connection in the proper way and two thirds of the way and the ACK scan will not tell us what ports are open. This is pretty useless to someone who needs to know what ports are open but does not want to leave log entries, a.k.a. an attacker.

Nmap includes a range of stealth scans; they are called stealth scans as they do not open a connection to a remote host in a normal everyday way. They violate the normal TCP protocol rules by sending unexpected packets and packets that are meaningless to a remote host that does not have a valid connection.

The first of these stealth scans is a FIN scan. This sends a packet to a remote host with the FIN flag set. Normally the FIN flag would signal the end of a connection and mark it to be reset, however if we have never setup a valid connection with the remote host we have no need to send a FIN packet.

The TCP protocol state that if an unexpected FIN packet arrives destined to a closed port then a RST packet should be returned and if an unexpected FIN packet arrives on an open

port, then nothing should be returned – the packet should be ignored.

Using these TCP connection rules Nmap is able to determine if a port is open or closed by looking to see if a RST packet comes back or not – if it does the port is closed, if it doesn’t the port is open.

It’s important to remember that a FIN scan will not work against a Windows based hosts, as Microsoft do not follow the TCP rules completely and their Operating Systems will return a RST packet in response to a unsolicited FIN packet arriving on a closed or open port. Hence Nmap will think that all ports are closed – however if you run a –sT or a –sS scan on the same target and Nmap reports that there are ports open, it is a safe assumption that you are scanning a Windows box (this method was used a lot until Nmap OS detection was added and improved) – it is worthwhile noting that some Cisco, HP and IRIX equipment also respond to a unsolicited FIN packet in the same way as Windows – there is also one extra little used use for this; if you are scanning a web server that is behind a firewall and only permitting traffic to port 80 and when you scan it with a SYN scan Nmap reports the port as open but a FIN scan comes back as closed, then you know there is a high chance of the web server running on a Windows based machine just from this very quick and easy scan – a fact which can come in very handy when trying to exploit the web server or perform SQL injection.

The syntax for a FIN scan is: nmap –sF 80.80.80.80

5) Xmas Tree Scan –sX

The Xmas tree scan works in exactly the same way as the FIN scan except that is sets the PSH (Push) and URG (urgent) flag in conjunction with the FIN flag. This may get around some IDS/IPS setups. This scan still has the same effect on the Windows OS as the FIN scan.

The syntax for a Xmas tree scan is: nmap –sX 80.80.80.80.

6) Null Scan

To follow on from the logical pattern we are using so far the Null scan does the opposite of the Xmas tree scan and does not set any TCP control bits at all. The TCP RFC dictates that a RST packet should be sent from closed ports and an open port should drop the incoming packet – in exactly the same way as the pervious two scans. Again this may defeat some IDS/IPS setups and still has the same effect on Windows.

The syntax for a Null scan is: nmap –sN 80.80.80.80

We have run out of options for the TCP control bits now; we have tried setting the SYN, SYN-ACK, FIN, FIN-URG-PSH TCP control bits and also tried setting none of them. (You may notice that RST is missing, this is because the TCP RFC says that a RST

packet is responded to with a RST packet regardless of if the port is open or closed, hence we would be no more the wiser than before we started.)

Wouldn’t it be good if we could play with these TCP control bit’s ourselves and create our own scan parameters to try and find miss configurations in firewalls, IPS’s, Routers and packet filtering devices? …..Well we can and it is very simple to do.

7) Customise your TCP packet

To customise out own TCP packets we use the ‘--scanflags’ option followed by the TCP control bit(s) we want to set, such as:

Nmap --scanflags FINACKSYN 80.80.80.80.

This will obviously send TCP probes with the FIN, ACK and SYN flags set. You can have some god results with poorly configured network border security devices by using this option. It is an individual trial and error technique though and one you should practise on your own equipment so you can get to understand what works with what type of configuration.

You can specify scan types to tell Nmap how to interpret the responses it receives. By default it uses a –sS.

8) FTP Bounce scan

In my experience not a lot of people seem to know about the FTP Bounce capabilities of Nmap. The FTP bounce feature exploits a very old feature of FTP servers whereby a client that has connected to an FTP Server can instruct it to send a file to a remote host other than the machine the client is connecting from.

This feature was very useful in the early days when bandwidth and connection speeds could be very low. Instead of having the file transferred to your own machine over a very slow link, you could have it transfer the file to a different machine you knew was using a faster link than yourself.

However, with the advances in technology faster links are a lot more common and bandwidth, or lack of bandwidth to be more exact, is not sure a problem anymore. Due to this (and probably due to Nmap) more and more FTP servers disable the File Forwarding feature and some even do not have the feature available at all.

There are still some FTP server on the Internet that can be used for this or if you manage to take over a remote FTP server that supports File Forwarding you could turn it on and use it to commit your terrible Nmap cyber crimes without bringing the forces of good to your own doorstep.

It all works by Nmap sending a request to the FTP server and telling it to send a file to

X.X.X.X IP address on port X. If the FTP server comes back and says that it was unable to establish a connection on that port then Nmap will show the port as closed. If the FTP server is able to make a connection on the specified port, it will come back as able to establish a connection but unable to transfer the file – hence Nmap will list the port as open.

The benefits of this are that in so far as the target machine (the one you port scanned) all the connection attempts came from the FTP server. For anyone to find out that it was in fact you port scanning the target machine they would have to find the owner of the FTP server and ask him to look through his logs – and if the admin of the FTP server is slack enough to allow File Forwarding through his FTP server than chances are he may not even keep logs..…

It can be time consuming to find an FTP server that allows File Forwarding but if you do find one be sure to keep the IP Address to yourself to ensure it stays configured that way for as long as possible. If half the world starts using it for FTP Bounce scans pretty soon the admin is going to figure out what is going on and configure it correctly.

To find one, use the “-p” switch, this is a feature of Nmap which I will cover later on that allows you to specify which port you want to scan. Then chose a subnet and scan them all of port 21 (FTP). Once you find some hosts listening on port 21 try and use them to conduct your FTP Bounce scan…..if it works your in luck, if it doesn’t then you will have to keep looking.

Nmap 123.123.123.0-255 –p21 – This will scan all hosts from 123.123.123.0 right through to 123.123.123.255 on port 21 only, looking for a live FTP Server.

Once you have found an FTP server try connecting to it to see if it allows Anonymous logons. (Use the user name ‘anonymous’ and anything for the password). If it does you’re in look and can try an Nmap bounce scan straight away. If it doesn’t allow anonymous logons you can either try and find a valid user name and password with a program such as Brutus or Hydra, or move on to another FTP server. I will cover how to use Brutus in a separate paper.

Once you have found either a valid logon for an FTP server or one that allows anonymous logons, use the following command to launch your FTP Bounce scan:

nmap –b username:password@IP_of_FTP_server IP Address to scan

So:

nmap –b nokia:taz@123.123.123.123 80.80.80.80

Would logon to 123.123.123.123 with the user name of nokia, the password of taz and then attempt to port scan 80.80.80.80

The following shows the result of a successful logon to an FTP Server that I use for FTP Bounce scans

Code:

C:\Documents and Settings\Nokia>nmap -v -b nokia:si£u31@X.X.X.X 81.80.80.80 Hint: if your bounce scan target hosts aren't reachable from here, remember to u

se -P0 so we don't try and ping them prior to the scan

Starting Nmap 4.03 ( http://www.insecure.org/nmap ) at 2007-02-17 19:11 GMT Stan dard Time Resolved ftp bounce attack proxy to X.X.X.X (X.X.X.X). DNS resolution of 1 IPs took 0.22s. Mode: Async [#: 1, OK: 0, NX: 1, DR: 0, SF: 0, TR: 1, CN: 0] Attempting connection to ftp://nokia:si£u31@X.X.X.X Connected:220 ProFTPD 1.2.5rc1 Server (*******************0

Login credentials accepted by ftp server!

If Nmap manages to successfully logon to an FTP server but you receive the following:

“Your ftp bounce server doesn't allow privileged ports, skipping them.”

It means the FTP server is configured to not send anything to ports 0-1024 less for port 20 & 21 – this was an early way of preventing such things as Nmap from connecting to ‘well known’ ports except for 20 & 21 – which is mostly the only ports it will need to connect too to send a file.

If your FTP Bounce server does not allow it to act as a proxy at all, eventually you will get the message:

Quote:

Your ftp bounce server sucks, it won't let us feed bogus ports!

You may find more false positives with this type of scan than any other for obvious reasons, so you should try and verify your results with another type of scan if possible.

The mort astute of you and those that think for themselves rather than blindly following a

tutorial may have realised another use for this type of scan.

The FTP server will more than likely be sitting on a LAN with a fully routable internet IP address…….if we can find out the IP range in use on the internal LAN we can use this method to port scan internal hosts by specifying an internal IP at the end of the Nmap command, or even try scanning 127.0.0.1 (localhost A.K.A itself). If you find port 80, 25 etc open the odds are that this could be acting as an FTP, Web and Mail server - even though the external IP addresses maybe different for these three services a firewall can translate them all to the same internal host.

This method could be used as a long-winded ping seep method also – if you can find out the internal IP range in use you can try a port scan each host in that range and see what positives you get back. If you get a positive back the host must be alive so you have the IP address of a valid internal machine. The FTP server will usually be on a DMZ so theoretically you can find the internal hosts of the DMZ, work out what ports are open and try and tie these in with the external IP’s in use. As mentioned in the previous paragraph if port 25 is open on an internal host you know there is a mail server – if you have taken the time to [url= http://www.tazforum.thetazzone.com/viewtopic.php?t=5445]conduct a reconnaissance [/url] then you will know the external IP for the mail server….chances are you have just found the internal IP of it.

A lot of people write-off FTP bounce scans as being dated and useless in today’s world, yet I do occasionally come across susceptible servers during Pen testing and they can be a very good path into a network and help you understand the topology better. If you happen to stumble upon a susceptible public FTP server, be sure to keep it as quiet as possible…..9) Idle Scanning -sI

Idle scanning is perhaps a more realistic way of obscuring your real location on the www. Although FTP bounce scans will work, there are a lot of variables that have to fall into place. Wouldn’t it be better if we could use something that does not require logon details? Well, luckily for us there is a way we can use another host to bounce our probes off without anyone knowing we are doing it.

A little knowledge of TCP and IP is needed to totally understand how an Idle Scan works; if you are not too familiar with these protocols I would suggest you read THIS to allow you to follow the following few paragraphs more closely.

Part of an IP header includes the IP ID. This is used in case any fragmentation occurs whilst this packet is on its travels around the LAN/Internet. For example; say you send an email, following the rules of OSI this will go through all the various layers until it ends up as a frame and ready to be place on the Ethernet cables as voltages and sent to wherever it is destined for.

During its trip down the OSI model it will pass the IP part of the Network layer – here, amongst other things, if will be assigned a unique identifier called the IP ID. We will say

our email fits into on packet and this packet is assigned the IP ID of 3333.

This packet becomes a frame when it reaches layer 2, and it converted to bits and sent on to the actual cable at layer one.

On its travels it bumps into a router. This router decides that the packet is too big to be routed and sent any further, so decided to fragment the packet in to two parts and send it on its way.

Now, without the IP ID, when the receiving station received these two packets it would have absolutely no way to tell that they were originally part of the same packet and hence the same email, resulting in your email not being delivered.

What would have happened (in layman’s terms) is when the router decided to fragment the packet it will have added one to the IP ID, so IP ID + 1. The IP ID was 3333 for our packet, so the router will have left the first packets IP ID as 3333 but will have incremented the other packets to 3333-1, if it had fragmented it into three the thirds IP ID will be 3333-2 on so on.

Now when the packet arrives at the receiving host it looks at the IP ID, sees that the two packets have the same IP ID, looks for the incremented on (3333-1) and reconstructs the packet – sends it on its way up the OSI resulting in the email being displayed on your screen.

** It is a bit more complicated than this as things like Fragment Offsets are used – the ‘-1’ is not literally added to the IP ID but you get the general idea**

But how does all this help us scan a target?

As I mentioned, the IP ID is a unique identifier to that packet and as such the next packet the host sends must have a new IP ID. Windows, FreeBSD and some Linux boxes all increment the IP ID by a set variable for each packet. So after sending our email with the IP ID of 3333, if the set variable was one, our next email will have the IP ID of 3334, etc. (For the remainder of this chapter we will say it increments by one)

As we know from the previous chapters, if a SYN packet arrives out of the blue then the receiving host will presume that someone wants to open a TCP connection to it and will respond with a SYN|ACK. However if a SYN|ACK arrives out of the blue then a RST packet is sent back to the initiating host. Finally, if a RST packet arrives out of the blue then the packet is to be dropped and nothing is to be returned. – remember this!

If we were to spoof the source IP address of our probe and send a SYN packet to our target, following the above reasoning the target would have to send a SYN|ACK packet back to whatever the IP address is we spoofed in the probe. Obviously our spoofed host did not send the initial SYN packet in the first place, so will be forced to respond with to the unsolicited SYN|ACK packet with a RST packet.

Again following the above mentioned rules, if we send a SYN packet to our target with a spoofed source IP address but the port is closed, then the target will send a RST packet back to our unsuspecting host – however as a RST packet required no further action our spoofed host will not need to send any packets back to the target machine.

Some of you may have already worked out how we can abuse these rules of TCP and make them work to our advantage.

If we send a SYN|ACK packet to the host we want to use as a zombie (the IP address we are going to spoof), when it replies with a RST packet we are able to see the IP ID it uses. If we then send another SYN|ACK packet, the zombie will again reply to it and we will see the new IP ID – simple maths will tell us by how much it has incremented. We can carry on doing this until we are positive we have worked out how much it will increment by.

Quote:

192.168.5.10 --> 192.168.5.15 TCP; D=80 S=59242 SYN ACK=9995679210 SEQ=153927672 LEN=0 WIN=3042 192.168.5.15 --> 192.168.5.10 TCP; D=59242 S=80 RST WIN=0 ID=4532

192.168.5.10 --> 192.168.5.15 TCP; D=80 S=61347 SYN ACK=9995679210 SEQ=153927495 LEN=0 WIN=3042 192.168.5.15 --> 192.168.5.10 TCP; D=61347 S=80 RST WIN=0 ID=4533

If you look at the above [edited] output you can see that 192.168.5.10 sent a packet to 192.168.5.15, the packet was TCP the destination port was 80, the source port was 59242, it was a SYN ACK packet with a sequence number of 153927672

Then as we know a RST packet should be sent in reply to an unsolicited SYN|ACK.

192.168.5.15 sent a packet to 192.168.5.10 which was TCP destined to port 59242 with a source port of 80, it was a RST packet and had the IP ID of 4532

The second trace shows the same types of packets but note that the IP ID has gone up by one. We do this as many times as is necessary to determine that a) the host is idle and b) we are sure what the IP ID is incremented by.

If the IP ID shows no set pattern and increments by a seemingly random amount each time, then chances are the host is not idle – Nmap will very helpfully tell us if this happens.

So, after working out that our zombie host is indeed idle and that the IP ID is incrementing by one each time we probe it; we then send a SYN packet to out TARGET

but with source IP of our ZOMBIE – the target responds to the SYN request with a SYN|ACK and send this to our zombie, the zombie receiving this SYN|ACK out of the blue will respond with a RST packet – therefore increasing its IP ID by one. If we now send a SYN|ACK to our zombie the RST packet the is sent by way or a reply to us will have an IP ID +2 from when we last probed it as it has just sent a RST packet to our target.

If the port on our target is closed it will send a RST packet to our zombie and as we know the zombie will not reply to that RST packet, so when we probe it again the IP ID will increase by +1 and not +2.

Learn the IP ID Code:

+++++++++++++                                        ++++++++++++++ +           +                STEP 1                  +            + +    US     +->--->--->---> SYN|ACK -->-->-->-->-->- +   Zombie   + +192.168.1.1+                STEP 2                  +192.168.5.10+ +           +---<---<---<-RST (IP ID=1000) <---<---<-+            + +++++++++++++                                        ++++++++++++++

+++++++++++++                                        ++++++++++++++ +           +                STEP 1                  +            + +    US     +->--->--->---> SYN|ACK -->-->-->-->-->- +   Zombie   + +192.168.1.1+                STEP 2                  +192.168.5.10+ +           +---<---<---<-RST (IP ID=1001 <---<---<--+            + +++++++++++++                                        ++++++++++++++

+++++++++++++                                        ++++++++++++++ +           +                STEP 1                  +            + +    US     +->--->--->---> SYN|ACK -->-->-->-->-->- +   Zombie   + +192.168.1.1+                STEP 2                  +192.168.5.10+ +           +---<---<---<-RST (IP ID=1002) <---<---<-+            + +++++++++++++                                        ++++++++++++++

If the port is open

Once we have learnt the IP ID and that it increments by one, we can launch our Idle Scan against the target.

Code:

+++++++++++++                                        ++++++++++++++ +           +                STEP 1                  +            + +    US     +->->SYN(Fake source IP 192.168.5.10)->->+   Target   +

+192.168.1.1+                                        +192.168.5.15+ +           +                                        +            + +++++++++++++                                        ++++++++++++++                                   Step 2  SYN|ACK       |   |                                     To spoofed IP      SYN  ^                                     Responding to      ACK  |                                     Our SYN packet      |  RST---                                                         |   |    |                                                      ++++++++++++++ |                                                      +            + |                                                      +   Zombie   + |                                                      +192.168.5.10+ |                                                      +            + |                                                      ++++++++++++++ |                                         

                                                                    |                                         |---------------------------                                       Step 3 RST                                       The Zombie responds to the              SYN|ACK with a RST, thereby increasing its IP ID by one. If we now send a SYN|ACK direct to the Zombie we can look at the IP ID and see if it has been incremented or not. If it has incremented a RST must have been sent, indicating the port on the target is open.

Now we probe out zombie to learn the IP ID:

Code:

+++++++++++++                                        ++++++++++++++ +           +                STEP 1                  +            + +    US     +->--->--->---> SYN|ACK -->-->-->-->-->- +   Zombie   + +192.168.1.1+                STEP 2                  +192.168.5.10+ +           +---<---<---<-RST (IP ID=1004) <---<---<-+            + +++++++++++++                                        ++++++++++++++

We left the IP ID at 1002, it is now 1004 which indicates that a packet has been sent in response to our probe directed towards out target. This tells Nmap that a SYN|ACK came from the target to the zombie and that the port is open.

If the port is closed

Code:

+++++++++++++                                        ++++++++++++++ +           +                STEP 1                  +            + +    US     +->->SYN(Fake source IP 192.168.5.10)->->+   Target   + +192.168.1.1+                                        +192.168.5.15+ +           +                                        +            + +++++++++++++                                        ++++++++++++++                                   Step 2  RST           |                                        To spoofed IP      RST                                      Responding to       |                                        our SYN packet      |                                      as the port is      |                                             closed        ++++++++++++++                                                      +            +                                                      +   Zombie   +                                                      +192.168.5.10+                                                      +            +                     -------------------------------- ++++++++++++++                               

        As we know nothing is sent in response to an unsolicited RST packet therefore our Zombie does not reply and the IP ID does not increment by one.   

                                       

+++++++++++++                                        ++++++++++++++ +           +                STEP 1                  +            + +    US     +->--->--->---> SYN|ACK -->-->-->-->-->- +   Zombie   + +192.168.1.1+                STEP 2                  +192.168.5.10+ +           +---<---<---<-RST (IP ID=1003) <---<---<-+            + +++++++++++++                                        ++++++++++++++

We left the IP ID at 1002, as it is now 1003 we know that it could not have possibly replied to the target host indicating a RST packet was sent to the zombie in response to our SYN packet. This tells Nmap that the port was closed and it will report it to you as such.

**If you do not tell Nmap to not ping the host (-P0, covered later) then it will first send an ICMP request to the host from your real IP address. So consider using the –P0 option, however Nmap does use ICMP to determine scan speeds etc so it may lead to more unreliable results**

You should be able to better understand why the host has to be idle for this scan to work; if it is not we will not be able to tell the IP ID incremented due to our probe to the target machine or due to normal traffic.

There are more uses for this type of scan, or to log the IP ID of a host to be more exact as it can be used to gauge how busy the client is, if there is a cluster of nodes using a virtual IP; in fact Fyodor posts an example of this on his site using hping:

Quote:

# hping2 -c 10 -i 1 -p 80 -S beta.search.microsoft.com. HPING beta.search.microsoft.com. (eth0 207.46.197.115): S set, 40 headers + 0 data bytes 46 bytes from 207.46.197.115: flags=SA seq=0 ttl=56 id=57645 win=16616 rtt=21.2 ms 46 bytes from 207.46.197.115: flags=SA seq=1 ttl=56 id=57650 win=16616 rtt=21.4 ms 46 bytes from 207.46.197.115: flags=RA seq=2 ttl=56 id=18574 win=0 rtt=21.3 ms 46 bytes from 207.46.197.115: flags=RA seq=3 ttl=56 id=18587 win=0 rtt=21.1 ms 46 bytes from 207.46.197.115: flags=RA seq=4 ttl=56 id=18588 win=0 rtt=21.2 ms 46 bytes from 207.46.197.115: flags=SA seq=5 ttl=56 id=57741 win=16616 rtt=21.2 ms 46 bytes from 207.46.197.115: flags=RA seq=6 ttl=56 id=18589 win=0 rtt=21.2 ms 46 bytes from 207.46.197.115: flags=SA seq=7 ttl=56 id=57742 win=16616 rtt=21.7 ms 46 bytes from 207.46.197.115: flags=SA seq=8 ttl=56 id=57743 win=16616 rtt=21.6 ms 46 bytes from 207.46.197.115: flags=SA seq=9 ttl=56 id=57744 win=16616 rtt=21.3 ms

As you can see for the [IP] ID there are obviously two different hosts sitting on that particular IP.

Idle scanning can also be used to test out firewall rules that only allow access from certain IP addresses. Obviously you will need to find out what the allowed IP address is. If you scan a target that is located behind a firewall that is only allowing packets from a certain IP address to reach it, your probes will all be dropped (Nmap will show them as filtered), however if you spoof the source IP to an allowed one your probes will get through and you can check the host who does actually have the real IP you spoofed to see if the IP ID is incrementing or not.

There are a lot of variables that need to be known and fall into place to allow the above to happen, but nonetheless it is possible.

IP ID detection is also used in OS detection too, as certain OS’s increment it by certain

amounts.

The syntax for an idle scan is: namp –sI zombie IP > Target IP

Nmap –sI 192.168.5.10 192.168.5.15

10) Window Scan –sW

If you take a closer look at the above trace outputs and the descriptions I gave of each field you may notice I didn’t describe what the WIN=xxxx field is for. This is because I wanted to talk about it here instead.

Quote:

192.168.5.10 --> 192.168.5.15 TCP; D=21 S=56545 ACK=0 LEN=0 WIN=3042 192.168.5.15 --> 192.168.5.10 TCP; D=56545 S=21 RST WIN=0 ID=5324

192.168.5.10 --> 192.168.5.15 TCP; D=23 S=61513 ACK=0 SEQ LEN=0 WIN=3042 192.168.5.15 --> 192.168.5.10 TCP; D=61513 S=23 RST WIN=0 ID=5325

As we all know TCP is a stateful connection with error checking. The error checking part of this means that both parties involved need to verify that what has been sent is actually what is received.

To ensure complete error checking not only do the individual packets needs to be checked but the amount of packets sent needs to be checked also. It’s no use having a method of checking that packets are intact, if you can’t check you have received all of them in the first place.

TCP packets included a Cyclic Redundancy Check (CRC) commonly referred to as a Checksum which pertains to the integrity of the packet. This is a mathematical algorithm that is derived by the size of the TCP packet – this produces a result which is added to the tail end of the TCP header. When the receiving station receives the TCP packet it will put it through the exact same mathematical algorithm that the sending station used and compare the result with the number in the checksum field. If the data has been altered even minutely the checksum result will be wildly different and a request for the retransmission of the packet is sent.

That takes care of the individual packets, but does not provide anyway of checking if all of the packets have been received. Obviously if we don’t get all of the data the CRC checks will still be valid but the data will be useless to us.

For this reason another option in the TCP header that needs to be set is the Window size

(nothing to do with the Windows OS). This Window size tells the sending station how much data to send, before it will need an acknowledgment from the receiving station, or to be more exact how much unacknowledged data can be in the connection flow.

So, say during the initial three-way handshake the window size is set to 64KB. The sending station will send 64KB of data and then stop. It will now wait for an acknowledgment to come from the receiving station to say how much data is has received. If it comes back saying it has received 64KB then all is well and the traffic flow commences for another 64KB. If it comes back saying it has only received 32KB then something has gone wrong and some data needs to be resent – as there is still the 64KB limit for unacknowledged traffic to be sent in the connection the sending station can only send another 32KB until an acknowledgement is needed (the receiving host has only acknowledged 32KB of it, so if any data exceeding 32KB is sent then there will be a violation of the initial 64KB limit that was established)

You may be thinking, that’s very nice but how do this help us port scan a remote host though?

Well, if you study the trace even more closely you will see a sort of pattern that the different packets follow:

Code:

192.168.5.10 --> 192.168.5.15 TCP; D=21 S=56545 ACK=0 LEN=0 [b]WIN=3042[/b] 192.168.5.15 --> 192.168.5.10 TCP; D=56545 S=21 RST [b]WIN=0 [/b]ID=5324

192.168.5.10 --> 192.168.5.15 TCP; D=23 S=61513 ACK=0 SEQ LEN=0 [b]WIN=3042[/b] 192.168.5.15 --> 192.168.5.10 TCP; D=61513 S=23 RST [b]WIN=0[/b] ID=5325

See if you can work it out with before reading on……

The WIN sizes of the RST packets are all ‘0’. Why would this be?

As we know from our ACK scan, if an ACK comes in to a port then a RST is sent back regardless of if the port is open or closed, BUT if the port does happen to be closed then no further communications can occur on that port anyway, so why send back a value telling the initiating host how much data it can send before it needs an acknowledgment if the port is closed? There is no need to do this, so the WIN size is 0 on a RST packet from a closed port in response to an ACK. Also, as there is no service sitting behind the port to set the WIN size the default will also be 0.

This tells Nmap that the port is closed.

If the port is open then yes a RST packet is still sent in response to an unsolicited ACK packet, however as there is a service sitting on that port to set the WIN size and further communication is possible, then the WIN size may be set to a non-zero value:

Quote:

192.168.5.10 --> 192.168.5.15 TCP; D=80 S=51876 ACK=0 LEN=0 WIN=3042 192.168.5.15 --> 192.168.5.10 TCP; D=51876 S=80 RST WIN=4096 ID=5378

192.168.5.10 --> 192.168.5.15 TCP; D=8080 S=64281 ACK=0 SEQ LEN=0 WIN=3042 192.168.5.15 --> 192.168.5.10 TCP; D=64281 S=8080 RST WIN=4096 ID=5379

So, although a RST is still sent back, there WIN size is 4096 and Nmap will inform us that the port is open.

This method is very similar to the ACK scan mentioned earlier, however as we know the ACK scan can’t determine open or closed ports (as a RST is sent by both) and is mainly used for packet filtering auditing, whereas the WIN scan can make an informed guess by looking at the WIN size to see if the port is open or not.

If you are able to put yourself in front of a host in such a way that you can sniff the traffic going to it, you could use this method to port scan a target with a spoofed IP address that is maybe behind a packet filtering device.

If you sent an ACK scan to a host on a DMZ (behind a packet filtering device) with a spoofed source IP, the responses would go back to the host with the IP you have spoofed. By looking at these responses via sniffing, you will be able to determine if the packets got through to the DMZ host and if the port is open – just by looking at the WIN size of the packet, and of course all logs lead back to the host whose IP you spoofed. The host does not have to be idle either.

Of course this will also work for normal port scans via a spoofed IP as you will be able to see all the responses going back to the host with the real IP – as you have absolutely nothing to do with this host and have never sent a single packet to it, then this is truly an anonymous method of scanning with endless variants on port scanning techniques.

Sadly once again Nmap becomes a victim of its own success. Since there are literally hundreds of papers out there detailing how the various Nmap scans work, it was

relatively simple for manufactures to make the RST packet from a closed port include a non-zero WIN value, which in effect ‘breaks’ this type of scan.

That being said, there are still a large number of un-patched/legacy machines out there that are susceptible to this type of scan.

The syntax for a Window scan is: nmap –sW ip address

Nmap –sW 80.80.80.80

11) Maimon scan –sM

Lastly for those who want to scan BSD boxes the Maimon scan may come in useful.

Uriel Maimon discovered that sending a FIN/ACK probe to a BSD box resulted in the probe being dropped if the port was open, and a RST being returned by a closed port, whereas non BSD boxed would return a RST regardless of the port state.

The syntax for this scan is: nmap –sM ip address

Nmap –sM 80.80.80.80

That covers all available ‘type of scan’ available to Nmap users when scaning TCP ports, there are a lot of options to use in conjunction with these scan types which I will cover shortly after I have explained UDP scanning.

12)UDP Scanning

Due to the nature of User Datagram Protocol (UDP) and its connectionless method of data transmission it is very hard to reliably scan the UDP stack of ports.

We already know that a TCP session requires a three-way handshake, ergo if we send a SYN packet we will get a SYN|ACK back from an open port.

UDP does not have anything in its rules to say it has got to send a single thing back in response to a packet arriving at an open port.

If we send a packet to a closed port we may get an ICMP type 3 code 3 reply – port unreachable. If this happened Nmap will inform us that the port is closed.

If any other ICMP type 3 messages are returned such as Host unreachable (code 1), Protocol unreachable (type 2) etc then Nmap will mark the port down as filtered – meaning something is receiving the probes but it may not be the interned target, i.e. it may be a packet filter of some kind, hence Nmap can’t say if the port is open or closed.

If no reply is received from the probe then the port is displayed as open|filtered which means that Nmap was unable to confirm the port was definitely closed hence could be open or be behind a packet filter of some kind.

As you can see due to the unreliable nature of UDP port scanning via empty USP datagram’s is a fairly unreliable method to use.

It is usually the service that replies on a UDP port – take port 53 for example which is the DNS port. If you send an empty UDP probe to it (which is what Nmap will do with the default USP scan) then the DNS server is never going to reply to it – why should it as there are no rules such as those in TCP to say it has to.

However if you conduct a ‘version scan’ ,which I will cover next, then Nmap will try to connect to the service that listens on the port by default.

So take our DNS service on port 53 for example – Nmap knows DNS uses UDP:53 so by carrying out a version scan Nmap will consult its database, look for a nslookup query and send it out to the target on port 53. If a reply comes back to this DNS query then Nmap will inform you that the port was open.

As you can see, for UDP ports it is the actual service that will reply to Nmap, but to get it to reply we need to give it information it can understand, not just a blank UDP packet. For this reason usually a version scan is conducted in conjunction to the UDP scan.

Timing is another issue with UDP scanning, as most operating systems (especially Linux) will limit the rate that the ICMP type 3 messages can be sent out at. Most set it to one every second but this can be changed manually by the user of the machine. If nmap has to wait one second for every probe on every port and you are scanning all 65,536 ports then you are going to be in for a long wait…….

The syntax for a UDP scan is: nmap –sU ip address

nmap –sU 80.80.80.80

It is possible to conduct a TCP scan and a UDP scan at the same time:

nmap –sT –sU 80.80.80.80

Version Scanning

All of the above is great providing that any services are using the port number they are meant to, i.e. the mail server is listening on port 25 and the FTP server is listening on port 21 etc.

There is however nothing illegal about setting your FTP server to use port 54321 and setting your mail server to use port 60000. In fact some companies do this to certain services and PAT/Port Forward them on to the correct port internally.

Code:

+++++++++++++                              ++++++++++ +           +                              +Firewall+ +    Us     +FTP logon request port 54321  +        + +81.81.81.81+--->--->--->--->--->--->-->-->+>-->    + +           + ftp someftpserver.com:54321  +    V   + +++++++++++++                              +    |   +                                            +    V   +                                            +    |   +FTP request port 21                                            +    >-->-->-->-->- ++++++++                                            ++++++++++          +      +                                                                +      + The firewall will take the FTP traffic destined for 54321      + FTP  + and will be configured to Port Forward the request to          +Server+ the FTP server on Port 21. To our knowledge the FTP Server     +      + is listening at ‘someftpserver.com:54321’. A basic port scan   +      + will only tell us that port 54321 is open, it won’t say what   ++++++++ is listening behind it, which is where the version scan comes in handy as we will now know there is an FTP service there.

So the old security by obscurity technique, whereby reconfiguring the default ports your service listens on to confuse would be attackers, does not really help anymore.

But how does Nmap know it is an FTP server listen on port 54321?

To accomplish this is does something called Banner Grabbing. To demonstrate Banner Grabbing it is best to show it first hand; so if you open up a command prompt (go to Start > Run > type cmd > press enter, if you don’t know how to do this). You will know have a black command window open.

Type: ftp wu-ftpd.org

Code:

C:\Documents and Settings\Nokia>ftp wu-ftpd.org

Once you have successfully connected, you will be greeted with some information:

Code:

Connected to wu-ftpd.org. 220 ftp.wu-ftpd.org FTP server ready. User (wu-ftpd.org:(none)): 530 Please login with USER and PASS.

This information is known as the banner and is what Nmap will grab. Once it has this banner it will compare it to an internal database and look for a match, it will also continue to probe the service to solicit as many responses as possible to enable it to get an accurate result.

If you really want to continue logging in to the FTP server with anonymous credentials, you can do like so:

Code:

ftp> user anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 230-Welcome to the FTP server for the WU-FTPD Development Group 230- 230-This server is the primary distribution site for the WU-FTPD daemon. 230- 230-The pub directory contains the distribution and supporting files. 230- 230-If you are uploading contributions; please place them in the incoming 230-directory and email wuftpd-members@wu-ftpd.org announcing your upload. 230- 230 Guest login ok, access restrictions apply. ftp>

Ok, well this is all well and good but what has it got to do with version scanning? Well although we were able to identify this as an FTP server by trying to connect to it via FTP on the default port, what version FTP server is it using? If we wanted to try and exploit it we will need to know the version to know what vulnerabilities it has.

It may also be of interest to know if there is anything else listening on it, so let’s give it a quick SYN scan:

Code:

C:\Documents and Settings\Nokia>nmap wu-ftpd.org

Starting Nmap 4.20 ( http://insecure.org ) at 2007-02-24 18:39 GMT Standard Time

Interesting ports on 67.66.8.211: Not shown: 1692 closed ports PORT   STATE SERVICE 21/tcp open  ftp 22/tcp open  ssh 25/tcp open  smtp 26/tcp open  unknown 80/tcp open  http

Nmap finished: 1 IP address (1 host up) scanned in 334.140 seconds

We can see there are FTP, SSH, Mail and Web servers available to connect to. However Nmap only makes this determination by listing what should be using those ports – if the mail server was listening on port 80, Nmap would still list is as HTTP. We could telnet and SSH to all the different ports and see if any banners are displayed, however an Nmap version scan will be much more productive for us and tell us exactly what services are using these open ports, which is informative if we want to try and exploit these services.

Go and Google “generic mail server exploit”……… Good luck with that….however if you Google ‘remote exploit Exchange 2003 sp1’ you will get a lot of hits, if you Google ‘remote exploit exchange 2003 sp2’, you will get a different set of hits…..knowing the version and patch state is essential to exploiting any service.

Take a look at port 26…..how are we going to exploit that? Well we could nip over to the IANA web site and see what should be running on port 26:

http://www.iana.org/assignments/port-numbers

Quote:

# 26/tcp Unassigned # 26/udp Unassigned

Hmmmm, that’s no help…..

So, let’s fire Nmap up and see if that can tell us more information about port 26 and the others, to enable us to narrow our search for an exploit:

Code:

C:\Documents and Settings\Nokia>nmap -sV wu-ftpd.org

Starting Nmap 4.03 ( http://www.insecure.org/nmap ) at 2007-02-24 18:03 GMT St dard Time   Interesting ports on 67.66.8.211: (The 1669 ports scanned but not shown below are in state: closed) PORT   STATE SERVICE VERSION 21/tcp open  ftp 22/tcp open  ssh     SSH 1.2.33 (protocol 1.5) 25/tcp open  smtp    Postfix smtpd 26/tcp open  ssh     OpenSSH 3.1p1 (protocol 1.99) 80/tcp open  http?

Good, so now we know it is an SSH service listening on port 26; version OpenSSH 3.1p1 using protocol 1.99 to be exact. A Google search for ‘remote exploit OpenSSH 3.1p1 protocol 1.99’ will help tremendously if you wanted to try and exploit this service.

So now not only do we know what type of service is listening on the port, we also know the exact version number and patch state of it and can start researching the various vulnerabilities that this service suffers from.

We can see what version Mail Server is on port 23 and that there is a different SSH deamon listening on port 22.

However, we didn’t get lucky with the FTP and Web server this time as the second part of Nmap’s output shows us:

Code:

2 services unrecognized despite returning data. If you know the service/version please submit the following fingerprints at http://www.insecure.org/cgi-bin/s vicefp-submit.cgi : ==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)============== SF-Port21-TCP:V=4.03%I=7%D=2/24%Time=45E07F1C%P=i686-pc-windows-windows%r( SF:GenericLines,27,"220\x20ftp\.wu-ftpd\.org\x20FTP\x20server\x20ready\.\r SF:\n")%r(Help,4D,"220\x20ftp\.wu-ftpd\.org\x20FTP\x20server\x20ready\.\r\ SF:n530\x20Please\x20login\x20with\x20USER\x20and\x20PASS\.\r\n"); ==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)============== SF-Port80-TCP:V=4.03%I=7%D=2/24%Time=45E07F18%P=i686-pc-

windows-windows%r( SF:GetRequest,FB8,"HTTP/1\.1\x20200\x20OK\r\nDate:\x20Sat,\x2024\x20Feb\x2 SF:02007\x2017:20:17\x20GMT\r\nServer:\x20Froglegs/104\.75\x20\(Unix\)\r\n SF:Last-Modified:\x20Thu,\x2022\x20Jan\x202004\x2012:51:39\x20GMT\r\nETag: SF:\x20\"3b034b-ebd-400fc75b\"\r\nAccept-Ranges:\x20bytes\r\nContent-Lengt SF:h:\x203773\r\nConnection:\x20close\r\nContent-Type:\x20text/html\r\n\r\ SF:n<!DOCTYPE\x20HTML\x20PUBLIC\x20\"-//W3C//DTD\x20HTML\x203\.2\x20Final/ SF:/EN\">\r\n<html>\r\n\x20<head>\r\n\x20\x20<title>WU-FTPD\x20Development SF:\x20Group</title>\r\n\x20</head>\r\n<!--\x20Background\x20white,\x20lin

SF:ks\x20blue\x20\(unvisited\),\x20navy\x20\(visited\),\x20red\x20\(active SF:\)\x20-->\r\n\x20<body\x20BGCOLOR=\"#FFFFFF\"\x20TEXT=\"#000000\"\x20LI SF:NK=\"#0000FF\"\x20VLINK=\"#000080\"\x20ALINK=\"#FF0000\">\r\n\x20\x20<h SF:1\x20ALIGN=\"CENTER\">\r\n\x20\x20\x20WU-FTPD\x20Development\x20Group\r SF:\n\x20\x20</h1>\r\n\r\n<BLOCKQUOTE>\r\n<hr\x20NOSHADE>\r\n\x20\x20<p>\r SF:\n<STRONG><EM>SECURITY\x20VULNERABILITY\x20DISCOVERED!</EM></STRONG>\r\ SF:n<P>\r\n<STRONG>A\x20vulnerability\x20has\x20been\x20found\x20in\x20the SF:\x20current\x20versions\x20of\x20WU-FTPD\x20up\x20to\x202\.6\.2\.\x20\r SF:\nInformation\x20describing\x20the\x20vulnerability\x20is\x20available\ SF:x20from</STRONG>\r\n<ul>\r\n<li><a\x20href=\"http://w")%r(HTTPOptions,A SF:0,"HTTP/1\.1\x20200\x20OK\r\nDate:\x20Sat,\x2024\x20Feb\x202007\x2017:2 SF:0:17\x20GMT\r\nServer:\x20Froglegs/104\.75\x20\(Unix\)\r\nContent-Lengt SF:h:\x200\r\nAllow:\x20GET,\x20HEAD,\x20OPTIONS,\x20TRACE\r\nConnection:\ SF:x20close\r\n\r\n")%r(RTSPRequest,1CC,"HTTP/1\.1\x20400\x20Bad\x20Reques SF:t\r\nDate:\x20Sat,\x2024\x20Feb\x202007\x2017:20:18\x20GMT\r\nServer:\x SF:20Froglegs/104\.75\x20\(Unix\)\r\nConnection:\x20close\r\nContent-Type: SF:\x20text/html;\x20charset=iso-8859-1\r\n\r\n<!DOCTYPE\x20HTML\

x20PUBLIC SF:\x20\"-//IETF//DTD\x20HTML\x202\.0//EN\">\n<HTML><HEAD>\n<TITLE>400\x20 SF:Bad\x20Request</TITLE>\n</HEAD><BODY>\n<H1>Bad\x20Request</H1>\nYour\x2 SF:0browser\x20sent\x20a\x20request\x20that\x20this\x20server\x20could\x20

SF:not\x20understand\.<P>\nThe\x20request\x20line\x20contained\x20invalid\

SF:x20characters\x20following\x20the\x20protocol\x20string\.<P>\n<P>\n</BO SF:DY></HTML>\n");

Here is your change to help Nmap’s usefulness with regard to version scanning. It very kindly asks us to go to a URL and submit the fingerprint we received.

The nmap-service-probe file which can be found in your install directory holds all the fingerprints that Nmap can currently use to compare banners and probe responses against. This was last updated on 10th Jan 07 (version 4.21ALPHA2) and is updated on a regular basis only because its users submit fingerprints to be included in it.

The more fingerprints is has, the more reliable it will become. So if you know what the service is, pop along to http://www.insecure.org/cgi-bin/servicefp-submit.cgi and submit your fingerprints that Nmap does not recognise. C+P everything that has an SF: at the beginning of the line.

Likewise if you think that something is being reported wrongly and want to tell the Nmap developers about it, then a URL is provided for this also:

Code:

Service detection performed. Please report any incorrect results at http://insec ure.org/nmap/submit/ . Nmap finished: 1 IP address (1 host up) scanned in 192.594 seconds

I included the FTP service in this paper to inform of the fingerprint submission page and to encourage you to do it and also to demonstrate the fact that you should not rely on the one tool to do everything for you. Nmap is good but it is not perfect, if it returns a null value for something like a version scan then you can always telnet in to the port and take a look for yourself – Nmap just automates this procedure but may sometimes provide more information then we can get manually due to the large database it has.

Our main lesson here was port 26 – nmap was able to inform us of the service and version of that service to allow us to progress with our assessment/attack further….SSH

using a non default port…

This can also be used for the power of good and enable Sys Admins to determine versions of services and their patch state on an internal LAN in a relatively small amount of time.

The final thing to say is that it is always a good idea to include this with a UDP scan to improve the reliability of UDP results.

The syntax for this scan is: nmap –sV ip address

nmap –sV 80.80.80.80

Ping Sweeps

A lot of people don’t understand Nmap’s full potential when it comes to ‘ping’. Typically a ping refers to an ICMP echo request being sent to a host and an ICMP echo reply being sent back to the initiating host. For the majority of people this is enough to determine if a host is up or down.

However, it is considered good security practise in today’s world to block most ICMP types from entering a network – take a PIX firewall for example, by default it will block every ICMP type from coming in to the network it is protecting – so an internal users can send the ICMP echo request out to the Internet but the reply will never get back in, resulting in a **timed out** being displayed to the user.

This can really mess Nmap up if using the default scan options as the first thing it will do is try and ping the host – if no reply is received the scan will be aborted.

To overcome this obstacle we can simply use the –P0 switch in our command, which will tell Nmap to not ping the host we are scanning; a fact which Nmap will helpfully inform us of:

Code:

C:\Documents and Settings\Nokia>nmap -sT 80.80.80.80

Starting Nmap 4.20 ( http://insecure.org ) at 2007-02-25 13:55 GMT Standard Time

Note: Host seems down. If it is really up, but blocking our ping probes, try -P0

Nmap finished: 1 IP address (0 hosts up) scanned in 3.937 seconds

With the –P0 option:

Code:

C:\Documents and Settings\Nokia>nmap -P0 -sT 80.80.80.80

Starting Nmap 4.20 ( http://insecure.org ) at 2007-02-25 13:55 GMT Standard Time

Stats: 0:03:16 elapsed; 0 hosts completed (1 up), 1 undergoing Connect() Scan Connect() Scan Timing: About 72.66% done; ETC: 14:00 (0:01:13 remaining) Interesting ports on 80.80.80.80: Not shown: 1696 filtered ports PORT   STATE SERVICE 80/tcp open  http

Nmap finished: 1 IP address (1 host up) scanned in 253.344 seconds

So either the host is sting behind a firewall of some kind that is blocking ICMP or the host itself is ignoring our ICMP packets.

(Try an ACK scan to see if you can determine if it is behind a packet filter or maybe a stateful firewall, and maybe what it will allow through it)

Nmap does you ICMP response times to judge the speed of its scan, so you may run in to timing issues if you use the –P0 switch.

If you are using the Idle Scan option or spoofing your IP address it is a good idea to use the -P0 option as Nmap will use your real IP address to ping the host before starting the scan – it can’t use the spoofed IP address as it needs to receive the ICMP echo request back.

However, as mentioned Nmap does not always think of ping in the typical ICMP way but we may still need to ping a host that is behind a firewall which is blocking all ICMP types. How can we do this?

Nmap includes a range of non ICMP pings:

Nmap can determine if a host is alive and the latency to that host be sending a variety of TCP packets with different flags set, to a specific port; known as a TCP ping.

TCP ACK:

In the same way the TCP ACK scan works, Nmap can send a TCP packet to a specific port on a host with the ACK bit set. Just like the ACK scan if a RST packet is returned Nmap will deem the host to be alive, if not RST is received Nmap deems the host to either be ‘dead’ or that the packets where filtered.

So even though ICMP may be blocked we could ping it with a TCP packet instead.

Do not think of this as a port scan as it is not; its sole aim is to detect if a host is alive behind a given IP address that may have ICMP filtering active.

The syntax for it is PA<port numbers>:

nmap 80.80.80.80 –PA25

You can still specify a normal scan option too if you so desire:

nmap –sT 80.80.80.80 –PA25

If you want to ping multiple port simply separate them with a comma.

To prove it works, consider the following output:

Code:

C:\Documents and Settings\Nokia>ping 87.237.61.100

Pinging 87.237.61.100 with 32 bytes of data:

Request timed out. Request timed out. Request timed out. Request timed out.

Ping statistics for 87.237.61.100:     Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),  

So something is blocking ICMP from reaching that host; lets try the TCP ACK Ping:

Code:

C:\Documents and Settings\Nokia>nmap  81.80.80.34 -PA80

Starting Nmap 4.20 ( http://insecure.org ) at 2007-03-02 20:18 GMT Standard Time

Stats: 0:00:01 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan

SYN Stealth Scan Timing: About 1.41% done; ETC: 20:18 (0:00:28 remaining)

By pressing the space bar we can get Nmap to give us some information to tell us what stage it is at. Notice the ‘0 hosts completed (1 up)’ part – Nmap has successfully pinged the host with a non ICMP packet. ‘(1 up)’.

TCP SYN Ping:

The TCP SYN Ping is exactly the same as a TCP ACK Ping, except is uses a SYN packet instead of an ACK packet. Stateful firewalls with usually filter out unsolicited ACK packets, hence a TCP ACK Ping may fail. To overcome this we can ping a host on a well known port that we thing may have a chance of getting through a firewall – usually ports 80 and 25.

We will send a SYN packet to make the firewall think we want to establish a valid connection to the service that is listening on that port.

The syntax is:

Nmap <ip address> -PS<port numbers>

Again separate multiple port numbers with a comma.

UDP Ping:

A UDP ping works in conjunction with ICMP and relies on an ICMP Port Unreachable message to be retuned by the host if a UDP packet is sent to a closed port.

For this reason you should try and ping a port that has a good chance of not being open, as open UDP ports may drop a packet completely that it does not understand (See UDP port scanning, above, for a more detailed description)

The syntax for a USP ping is:

Nmap <ip address> -PU<port numbers>

Again, separate the port numbers with a comma if you want to scan multiple ports.

UDP Pinging is an inherently unreliable ping due to it relying heavily on ICMP packets, which as we know are usually filtered out.

ICMP Mask and Tine-Stamp pings:

There are two rather antiquated pings that Nmap still supports called an ICMP Time-Stamp ping and an ICMP Mask ping.

I would strenuously suggest staying away from both of these as, a) the chances of them working are very remote, and b) they stand out like a MAC at a Defcon meeting to someone analysing the packets flowing through a network.

A timestamp request is a prehistoric method for two hosts to synchronize their clocks – now-a-days NTP is the preferred method. There is a small plus to using this method and that is if it works you have a very good chance of successfully attacking the network as anyone who allows there packets to traverse layer 3 devices probably does not understand their job to well.

An ICMP Mask Ping is an ICMP query to a host asking it for it’s subnet mask. If this works then just like the timestamp request the chances of the network not being secured properly are very high, or the OS patching state is not very recent or even that they are using legacy infrastructure hardware on the network.

They syntax for the timestamp request is:

nmap <ip address> -PP

And the syntax for the Mask Ping is:

nmap <ip address> -PM

I think this is waaay getting two long now, so will end Part two here.

In Part three I will cover further basic Nmap options, Nmap timing options, OS fingerprinting, real world examples of using all the options and some not so well known tips and tricks for using Nmap.