Learning Nmap: The Basics – LINUX For You


Learning Nmap: The Basics – LINUX For You.

Learning Nmap: The Basics

By Rajesh Deodhar on August 1, 2010 in How-TosTools / Apps · 0 Comments

Mapping a network

Nmap, the network mapping tool, is the starting point when analysing any network. It is an exciting tool — compact and power-packed. This article looks at the range of functions and options it supports.

The Nmap man page describes it as a security/network exploration tool and port-scanner. Nmap (Network Mapper) is a versatile open source tool, which systems administrators can’t do without. Some of its interesting features include:

  • It’s fast!
  • Uses raw IP packets in various innovative ways for scanning.
  • Can detect operating system versions (and if it’s unable to detect, it requests the user to send the scan signature to the developer, for incorporation in future versions of Nmap).
  • Provides various interesting options to scan the network.

Caution: While using Nmap, be warned regarding the following information!
Under the stringent rules of the Indian Cyber Law 2000 and its further amendments till date, even a port scan on a public IP may land you in jail. Do not scan computers that you do not own, or run scans over networks that you do not own, without written permission from the owners.You may also scan the scanme.nmap.org website for testing. This permission only includes scanning via Nmap, and you are not allowed to test exploits and/or denial of service attacks. Don’t forget to follow the rules listed in the Nmap man page. Abuse of this service will be reported to the government by the site owners.

Use Nmap very carefully, and only for discovery/audits of your network. As we’ll see in this article, it is a very powerful tool, and could cause disruption/damage to the target system or network.

Fully understand what you are doing, even with scripted scans, before you do it. Ignorance will not excuse anybody from being prosecuted under the law.

Also note that if you have a website of your own, either hosted at a hosting provider or on a rented physical server, the server and network do NOT belong to you even though you own the website’s content. You should ideally obtain permission from such hosting providers/server owners to carry out even “testing” probes of your own website.

The basic command line syntax to invoke Nmap is as follows:

nmap [scan type(s)] [options] {target specification}

Nmap has a huge list of command-line options, generally categorised into target specification, host listing, port specifications, service identification, scan technique, scripted scans and output options.
Some of the Nmap switches only work when run as the root (superuser). Let’s look at some of the basic Nmap commands:

  • nmap -sL 192.168.10.0/24 — Lists all the hosts scanned (all responding IPs in the subnet from 192.168.10.1 to 192.168.10.254).
  • nmap -p80,443 192.168.10.10-20 — Scans the IP address range looking for open ports 80 and 443.
  • nmap -p T:80,8080,6588,800 172.16.0.1/22 — Scans all hosts between 172.16.0.1 and 172.16.3.254, looking for open TCP ports 80, 8080, 6588 and 800 (the default listening ports for various proxy servers).
  • nmap -sP 192.168.10.10,20 — Ping scans two hosts in a fast scan.
  • nmap -PN 192.168.10.0/29 — Scans all the hosts in the 192.168.10.1 to 192.168.10.6 range. Sometimes, host-based firewalls deny ping requests, and it is difficult to scan such hosts. The -PN scan is useful in such cases; it scans the hosts assuming them to be online.
  • nmap -A -F 192.168.10.1 — Detects target OS and services running on it, in fast-scan mode.

These basic commands are useful for standard scans in any network, and serve a variety of purposes including checking open ports; whether unintended services (like terminal services, VNC, FTP, etc) are running on important hosts; obtaining a list of IP addresses to be scanned, and so on.

However, these simple and straightforward scans may not fulfil all requirements. Sometimes, for example, special scans are required in order to test intrusion detection/prevention systems. There might also be the need to conceal the identity of the scanner from the target host.

Nmap does indeed provide various ways to conceal your IP address (you can also conceal your MAC address by spoofing) though you have to be careful while using these commands. They require an in-depth knowledge of TCP/IP protocols, and may disrupt the systems/network or cause damage if not run properly. Let’s look at some stealth techniques to conceal the identity of the scanning system.

Idlescan

nmap  -v  -sI  192.168.10.100  192.168.10.105

This scan will probe 192.168.10.105 while pretending that the scan packets come from another host; the target’s logs will show that the scan originated from 192.168.10.100. This is called a zombie host.

In our networking context, zombie hosts are those controlled by other hosts on the network. Not all hosts can be used as zombies, as certain conditions are required to be met before this is possible. (Using packages like hping may enable you to find a zombie host on the network.) The -v switch increases the verbosity of the output.

Decoy host

nmap -sS -P0 -D 192.168.10.201,192.168.10.202,192.168.10.203 192.168.10.50

This command is especially useful while testing IDS/IPS. The -sS option will perform a SYN scan on the target host. While doing so, it will spoof the packet contents to make the target host see them as coming from the specified (-D) decoy hosts. The -sI and -D switches can’t be combined, for obvious reasons.

Now, a word of caution: be careful not to cause an unintended Denial of Service (DoS) attack while using the -D option. To understand how this could happen, we need to know how a TCP handshake operates. TCP, being a connection-oriented protocol that guarantees delivery of packets, operates with a three-way handshake:

  • The client initiates the communication by a SYN
  • The server acknowledges with a SYN-ACK
  • The client again sends an ACK, and now they can communicate

If the -D switch is used, and there is a live host at the decoy IP address, then the SYN-ACK reaches the actual host at the decoy IP address, and not the host running the Nmap scan. Since the real host at the decoy address did not initiate the connection, it closes the connection by sending a TCP Reset (RST). There’s no problem with this.

However, a problem occurs if the decoy IP address is not active on the network — there is no RST sent to the scan target, which keeps the connection open. As Nmap continues to generate more and more requests to the target with the decoy IP as the source, the scan target has a growing list of open connections for which it maintains the “connection initiated” state. This ends up consuming more and more resources on the target, and may cause a DoS to other, legitimate hosts and communications.

Other interesting command-line options

Nmap’s creators have considered many possibilities while designing it. One case in point is the -ttl option. To understand its use, let’s once again go into some detail on the IP protocol. Packet headers contain a field called TTL (Time To Live). The TTL field is set by the machine from which the packet originates. Every machine that receives and relays it on the route towards its destination, decrements the TTL field value by some amount.

If the TTL field value falls to zero before the packet arrives at its destination, then the packet is dropped, and an ICMP error is sent back to the sender. This mechanism is intended to prevent packets that could not be delivered to the target from remaining in circulation on the network and swamping the network resources.

Although TTL was originally meant to be a measure of time, as indicated by its name, in practice, its value is reduced by one on each hop (relaying of the packet) and not by some number of seconds. Thus, the value of the TTL field actually determines the maximum number of hops for which the packet can be relayed without being discarded.

A typical default value for TTL on many operating systems is 128. However, Nmap’s -ttloption lets you define a custom value for scan packets, which is a very useful feature. This includes, for example, ensuring that the packet is not relayed from your LAN onto the WAN/Internet. Fantastic, isn’t it?

Some of the other important Nmap command-line options that require an understanding of the TCP/IP protocol include:

  • Fragmentation of packets (-f and -ff options)
  • Using the “FTP bounce” technique to scan via FTP servers (-b)
  • Changing the scan delay (-scan_delay is especially useful if the target has IDS/IPS, and blocks scan requests)
  • Timing policies (-T)
  • Scripted scans

Listing active hosts on the network

A common sequence in network testing is to first generate a list of all active hosts in a network. The list can be used as an input to other applications, which lack the capacity to scan for active hosts but must be given one or more target IP address. Here is a short command sequence that does this:

nmap -sP -n -oG hostlist 192.168.10.0/24

cut -d " " -f2 hostlist > iplist

The first command executes a ping scan (-sP) and generates a list of active hosts in the target range/network. This list will be stored in the file hostlist in greppable format (-oG). The second command reads the data from the file, splits each line into fields based on a space character delimiter, and outputs the second field (the IP address), thus generating a new file, iplist, which is simply the list of active IP addresses/hosts in the given range.

The Zenmap GUI

Nmap has a huge list of command-line options that are difficult to remember and use, even for experienced administrators. Zenmap, a GUI for Nmap, simplifies this considerably. It even provides ready-made scan profiles from which you can choose. The commands you generate in the GUI can also be run at a command line, if required. The GUI also has a very important added function — a graphical display of discovered hosts, and the hops required to reach each host! A sample output from this feature is shown in Figure 1.

Sample Zenmap discovered hosts display

Figure1: Sample Zenmap discovered hosts display (click to enlarge)

We hope that the few important concepts about the TCP/IP protocol, the power of Nmap, and the other ideas interested you!

References

  • Nmap Network Scanning, the official guide to the Nmap Security Scanner
  • Nmapin the Enterprise: Your Guide to Network Scanning, by Angela Orebaugh and Becky Pinkard

Advertisements

Advanced NMap: Some Scan Types – LINUX For You


Advanced NMap: Some Scan Types – LINUX For You.

Advanced NMap: Some Scan Types

 

 

By Rajesh Deodhar on November 1, 2010 in How-TosSysadminsTools / Apps · 0 Comments

Advanced Nmap

A broad overview and the basic features of NMap have been covered in an earlier article in this series of articles on Nmap. In this article, we discuss in detail various NMap scan types, and the practical use of these commands to scan various devices and networks.

Before we begin understanding NMap scan types, let us start with the basics, including understanding the 3-way TCP handshake. TCP/IP is not a single protocol, but a suite comprising various protocols, some of which are detailed in Table 1.

Table 1: Various TCP/IP protocols
1. Application layer FTP, HTTP, SNMP, BOOTP, DHCP
2. Transport layer TCP, UDP, ICMP, IGMP
3. Network layer ARP, IP, RARP
4. Data link layer SLIP, PPP

UDP and TCP

UDP is a connection-less protocol that does not assure the delivery of packets at the other end. However, that does not mean it is an unreliable protocol; higher-level applications must take care to verify that data has been received at the other end. This practice has its own uses, like with live audio/video transfers, where real-time delivery is a must.

TCP is a connection-oriented protocol, which assures delivery of packets. ICMP packets are used to convey error messages, if any. The TCP three-way handshake is used to establish and reset connections, and this concept is key to understanding various NMap scan types. In the TCP three-way handshake:

  1. A “client” initiates communication with a SYN (Synchronise) packet with a randomly generated number, X.
  2. The server acknowledges with a SYN-ACK (Acknowledgement), X+1 and a randomly generated number, Y.
  3. The client again sends an ACK, followed by Y+1, thus completing the handshake. Now the client and server can start data transfer.

After the data transfer is complete, a FIN (Finish) packet is sent by the client, to end the connection.

Nmap uses/tweaks this handshake very effectively for various scan types. Before we proceed, let us be clear about two basic but important aspects of Nmap scans:

  1. By default, Nmap scans 1,000 most common ports for each protocol. The list of these ports can be modified in the nmap-services file, typically stored in /etc/services. (I have never used this; the default ports are almost always sufficient!
  2. Root privileges are required to run any scan that modifies the standard TCP handshake.

Now, let us try to understand the detailed workings of various NMap scan types.

TCP SYN Scan -sS

This is the default Nmap scan, used to detect open TCP ports in the target range. At the start of a SYN Scan, NMap initiates a TCP handshake with a standard SYN packet, to the required TCP port of the device to be scanned (target). The target’s response, giving details of port status, differs depending on the status of the destination port (see Table 2).

Table 2: SYN scan client responses
Port status Client response Inference
Open Standard response SYN-ACK Service running on the port
Closed Standard response RST Service not running on the port
Filtered No response Firewalled port

If the device responds with a SYN-ACK, Nmap sends an RST instead of an ACK, resetting the session, rather than completing the handshake for data transfer. If ACK was sent instead of RST, the connection would be left open till session time-out, making the device prone to a denial of service type of situation.

To run a SYN scan, root privileges are required under Linux. A SYN scan is used to find the status of TCP ports on various devices on the network. Since the SYN scan works on TCP, it will work across all operating systems and other devices that implement TCP, such as controllers, PLCs, network printers, Ethernet switches, and mobile phones.

Since it does not open a valid TCP connection, it’s quiet, and difficult to detect. However, careful network monitoring will reveal too many RST frames in traffic, due to one RST frame per scanned port. Here’s a sample SYN scan that will return various open TCP ports:

nmap -sS 192.168.100.100

Ping Scan -sP

This scan is used to find active hosts in the range. Rather than using ports like a SYN scan, a ping scan starts by sending an ICMP echo request to the target range. Active devices on the network will respond with an ICMP echo reply, thus revealing their status.

A firewalled host with blocked ICMP will not respond to the ICMP echo request. The obvious basic use of this scan is to find all active hosts on the network. This set of two commands gives a list of all active IP addresses in the 192.168.100.0/24 range:

nmap -sP -n -oG hostlist 192.168.100.0/24    ## grep'able output file, hostlist
cut -d " "-f2 hostlist > iplist    ## list of all active IPs in the target range, iplist)

The ping scan uses only one packet for the request, and may get one packet in response, thus making it the fastest of all Nmap scan types, with the lowest footprint. The ping scan cannot be combined with other scan types.

UDP Scan -sU

This is used to find the status of UDP ports in the target range. At the start of the UDP scan, Nmap sends a 0-byte UDP packet directed towards a UDP port. The target’s response differs depending on the status of the scanned port:

  1. Open port: Data on the scanned UDP port.
  2. Closed port: ICMP error message indicating no service is running on this port.
  3. Open/Filtered port: No ICMP message; Nmap waits for the timeout, and can’t determine whether the port is open, or filtered by a firewall.

UDP can be used to detect malware/spyware effectively. The following sample UDP scan command will return open/closed/open/filtered UDP ports on the host:

nmap -sU 192.168.100.100
Table 3: Summary of SYN, ping and UDP scans
Scan type Facets
SYN scan (-sS) — Scan TCP ports
  • Does not leave a log entry
  • Requires root access.
  • Traffic of RST frames increases with use of SYN scan.
  • Gives information about TCP ports.
Ping scan (-sP)— Identify active hosts
  • Very difficult to trace — only two standard ICMP frames, which are very common in network traffic, are required to complete the scan.
  • Root privilege not required to run the scan.
  • Yields a device inventory by identifying active devices on the network.
UDP scan (-sU) — Scan UDP ports
  • Uses 0 byte UDP data, causing low overhead on the network.
  • Requires root access.
  • Many operating systems put restrictions on UDP traffic, thus this scan can be very slow if run on devices running those operating systems
  • Works well on Microsoft operating systems, since Microsoft does not restrict UDP port traffic.
  • Best for scanning known UDP ports used by spyware/malware for communication.

Please try out these scanning techniques, hands-on, before further exploring various other scan options provided by NMap. And don’t forget to keep a watch on this series for further details!

Advanced Nmap: FIN Scan & OS Detection – LINUX For You


Advanced Nmap: FIN Scan & OS Detection – LINUX For You.

Advanced Nmap: FIN Scan & OS Detection

 

By Rajesh Deodhar on January 1, 2011 in How-TosSysadminsTools / Apps · 0 Comments

Scan time!

Nmap is a fantastic tool, and I just can’t refrain from praising it, every time I use it. The earlier articles in this series have detailed many important Nmap scan types. Let us continue with some more intricacies of Nmap, by discussing various other command-line options.

A TCP SYN scan (which we have covered earlier) leaves a lot of fingerprints on the target host, thus revealing the identity of the scanning host. Some of the hosts with Intrusion Detection Systems (IDS) and firewalls do watch for SYN packets targeted at particular ports. So how does a penetration tester work around this?

FIN scan

The Nmap FIN scan comes in handy in such circumstances. The standard use of a FIN packet is to terminate the TCP connection — typically after the data transfer is complete. Instead of a SYN packet, Nmap initiates a FIN scan by using a FIN packet. Since there is no earlier communication between the scanning host and the target host, the target responds with an RST packet to reset the connection. However, by doing so, it reveals its presence. A FIN scan is initiated using a command like nmap -sF 192.168.100.100.

OS detection

With so many different operating systems and versions around, it is really interesting how Nmap detects the operating system of a target in a very short time. Let us study the OS detection command in detail. Table 1 shows a sample output that’s running an OS detection command against a target PC with an Intel Ethernet card, while running Windows XP SP3.

Table 1: Analysing the output of an OS detection scan
Item Interpretation
nmap -O -v -oversiondetect.txt 192.168.2.101 Syntax of the executed command. -v increases the verbosity of the output.
Initiating OS detection (try #1) against 192.168.2.101 OS detection uses a combination of ICMP echo, TCP and UDP packets.
Host 192.168.2.101 is up (0.0030s latency). Discovered the host status in practically no time
Interesting ports on 192.168.2.101:
Not shown: 997 closed ports

 

PORT    STATE SERVICE
135/tcp open  msrpc
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds
Lists detected open ports on the host
MAC Address: 00:16:76:CE:8C:3C (Intel) MAC address of the host’s Ethernet card, and its manufacturer
Device type: general purpose  
Running: Microsoft Windows XP With at least one open and one closed port on the target host, Nmap can detect the target OS effectively. To instruct Nmap to detect OS on only such hosts, to save scan time, use the --osscan-limit option
OS details: Microsoft Windows XP SP2 or SP3 or Windows server 2003  
Network Distance: 1 hop The host is in the same network
TCP Sequence Prediction: Difficulty=264 (Good luck!) TCP sequence prediction: The TCP 3 way handshake is initiated by a SYN packet followed by an initial sequence number. If this number can be predicted, an attacker can construct a spoofed packet which will appear to have been sent by the scanned host. This denotes the difficulty of predicting the initial sequence number.
IP ID Sequence Generation: Incremental  
Read data files from:/usr/share/nmap  
OS detection performed. Please report any incorrect results at http://nmap.org/submit/. Gives the user a chance to submit incorrect OS detection data to the Nmap team, for improvements in the next version.
# NMap done at Tue Nov 30 20:13:03 2010 — 1 IP address (1 host up) scanned in 3.56 seconds Completed the whole OS detection for one host in less than 4 seconds!

Security by obscurity? Assuming you are a Web developer, would you be interested in running an httpd service on a non standard TCP port — say, 1793 — rather than on the standard TCP port 80? In the early days, before I knew enough about various Nmap scan techniques, I thought this was just incredible! I felt I’d found a gold mine! If a service is running on a nonstandard port, it does add a great layer of security.

Welcome to the world of Nmap, which detects practically any service, even running on a non-standard port.
Table 2 shows Nmap scan output against a live IPCop firewall with its Web interface configured on the TCP port 1775. By default, IPCop runs the SSH service on the non-standard TCP port 222 (as against the standard SSH port 22). The output is filtered.

Table 2: Nmap scan output against a live IPCop firewall
Item Interpretation
# NMap 5.00 scan initiated Tue Nov 30 21:04:17 2010 as:
nmap -v -O -PN -p222, 1775 -sV -oIPCopOS.txt 121.xxx.xxx.xxx
The command line, to cut scan time -PN is used and port numbers are specified.
Initiating OS detection (try #1) against 121.xxx.xxx.xxx.static-pune.vsnl.net.in (121.xxx.xxx.xxx) Live host on the web.
Host 121.xxx.xxx.xxx.static-pune.vsnl.net.in (121.xxx.xxx.xxx) is up (0.052s latency).  
Interesting ports on 121.xxx.xxx.xxx.static-pune.vsnl.net.in (121.xxx.xxx.xxx):

 

PORT     STATE SERVICE VERSION
222/tcp  open  ssh     OpenSSH 4.7 (protocol 2.0)
1775/tcp open  http    Apache httpd
  • SSH port discovered on 222 along with its version
  • HTTP port 1775 detected along with its version
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port  
Device type: firewall  
Running: IPCop Linux 2.4.X  
OS details: IPCop firewall 1.4.10 – 1.4.18 (Linux 2.4.31 – 2.4.34) Though one open and one closed port was missing, NMap detected the OS and Kernel version.
TCP Sequence Prediction: Difficulty=206 (Good luck!)  
IP ID Sequence Generation: All zeros  
Read data files from: /usr/share/nmap  
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .  
# NMap done at Tue Nov 30 21:04:30 2010 — 1 IP address (1 host up) scanned in 13.61 seconds  

While scanning real-world networks, the situation may demand that you specify the targets in various ways, if for example, you wish to specify the range of IP addresses from 192.168.100.0 to 192.168.100.127. To specify every host individually is impractical, so you can specify this range in two different ways: 192.168.100.0/25 or 192.168.100.0-127. Select the syntax that best suits your needs.

A word of caution — take care when you use the CIDR notation. Initiating a scan against public IPs with /16 will start a scan against the full Class B range. To verify which IP addresses will be scanned by the range you specified, add the -sL option the first time you run the command. This will only list all the hosts in the scan range, and will not initiate a scan. After verifying the range, you can remove the -sL parameter.

Please try out these scanning techniques, hands-on, before exploring further. And don’t forget to keep a watch on this series for more tips and tricks, including real-world scanning examples!

Cyber Attacks Explained: DNS Invasions – LINUX For You


Cyber Attacks Explained: DNS Invasions – LINUX For You.

Cyber Attacks Explained: DNS Invasions

By Prashant Phatak on February 22, 2012 in OverviewSecuritySysadmins · 1 Comments

Yet another kind of cyber attack, eh?

We often read about defaced websites whose pages get changed to some malicious content. How do hackers do it and how do we protect our infrastructure from them? This article is about how hackers invade DNS (domain name systems). DNS invasion is technically advanced and a harmful attack on a network or Web infrastructure. Network administrators are urged to learn more about it and strive to secure the infrastructure they manage.

As we all know, the DNS exists because it’s impossible for humans to remember IP addresses for sites, but easy to remember alphanumeric names. The DNS system was created when the Internet was a friendly place — leading to quite a few issues.

Figure 1 shows how name resolution fundamentally works. When an application (like a browser) wants to connect to a destination service, it queries the DNS server, asking for the IP address. This query is sent over UDP port 53 as a single request and receives a single-packet reply from the server. (Note that since UDP data space is limited to 512 bytes, the protocol stack automatically uses the TCP protocol for queries and replies.) When the client receives a reply, it updates its local cache with the received entry, speeding up subsequent queries to the same domain. Entries in local cache are automatically purged after their TTL (Time to Live) expires.

Name resolution

Figure 1: Name resolution

The DNS uses record types like A, CNAME, SOA, MX, etc. While explaining these is beyond the scope of this article, it is important for administrators to know the usage of each, and before implementing them, they should be evaluated from the security standpoint. Before we learn about DNS-based attacks, we need to know about two types of queries — iterative and recursive.

  • An iterative DNS query: When a client queries a DNS server, asking if it has the answer for a given domain name, the DNS server may or may not have the answer ready. If the DNS server doesn’t have an answer, instead of shutting the request down, it sends the name of an upstream DNS server that might have the answer. This is usually called a DNS referral. The client sends the query to the next (referred) server; if that one too doesn’t have an answer, it sends a referral to yet another upstream server. This process continues till either the client gets an IP address or gets a “query failed” error message.
  • The recursive DNS query: In this case, the query begins by a client host requesting a name resolution to its immediate DNS server. If the DNS server does not have the answer, it is supposed to do the job of talking to upstream servers, instead of merely providing their referral names. Again, if the upstream server does not have an answer, it needs to take on the responsibility further. This continues till either the root domain server is reached, which must have the answer, or if the queried name itself does not exist, in which case an error message percolates down the chain to the client. Unlike the iterative method, a recursive query proves to be more aggressive in getting query results.

Iterative queries are usually made by DNS servers while recursive queries are made by clients, which helps to reduce the burden of referral searches. From the security perspective, it is important to know the basics of DNS, such as, there can be multiple DNS servers in an organisation replicating their zone records to each other in order to maintain name resolution consistency.

DNS data can be updated dynamically without needing any service to be restarted, and when a change is made on the master server, it triggers replication to partner servers automatically. The actual time required for replication is defined by the TTL of each record. In case of geographically dispersed DNS servers, this time period can be as long as a day, since all servers in the chain maintain their own cache to speed up replication.

DNS security attacks

It has been observed that systems administrators spend a lot of time designing security around applications, servers and other infrastructure components, but unfortunately tend to forget hardening DNS servers. Please refer to Figure 2, which shows possible breach points where the DNS can be vulnerable to attacks. By design, the DNS heavily relies on UDP, does not contain security by itself, and does not have foolproof built-in authentication — which makes it more susceptible to hacking than other network-based services. Let’s look at a few very common DNS attacks.

Possible attack points

Figure 2: Possible attack points

DNS cache poisoning

This attack lets name resolution to be tweaked in two ways. In one method, the hacker installs a rootkit or a virus, which is intended to take control of the local DNS cache of the client. Once done, entries in the local DNS are altered to point to a different IP address.

For example, if a browser tries to access http://www.cnn.com/, instead of getting the CNN IP address, it gets an IP set by the hackers’ script, which is usually in the hackers’ own Web farm, and hosts viruses or shows some derogatory information.

In a different and more dangerous approach, the hacker attacks a DNS server and alters its local cache — so all servers using that DNS server for resolution end up at a wrong IP address, causing a system-wide failure, apart from information loss or theft.

In rare cases, hackers can access a root DNS server, which holds the base entries that form the root domain, such as .com.net or any country-specific name system. Hackers then modify entries on that server, which triggers automatic replication, and can cause serious global outages for multiple businesses and websites. Though such situations are rare, they have occurred — and that too, very recently, involving a famous social community chatting website.

DNS hijacking

This attack is also commonly used to bend the DNS system. Here, the client DNS cache on a client is not altered, but instead the client’s DNS settings are changed to point to the hackers’ own DNS server. Usually the purpose is not to steal data, but to gather statistical data from the client computer. All name resolution requests going to the hacker are resolved to the correct addresses, but the hacker learns of the typical sites visited by the client.

This information can further be used by online advertisers to target that client with Web-visit-specific advertisements. Some ill-behaved e-thieves also redirect users to their own websites, or search engines, either to gain money from advertisements, or simply to steal data and use it for social engineering. While it is inappropriate to use this feature for any personal gain, it is being used by many well-known websites and ISPs to collect user browsing statistics.

DNS spoofing

This refers to merely a man-in-the-middle type of attack in which the hacker gains access to the network the DNS server is on, and performs ARP cache poisoning and spoofing on that network. Once MAC-level control is achieved, the hacker then fetches the IP address of the DNS server, and starts sniffing and spoofing requests meant for the real DNS server.

The hacker’s machine resolves all DNS queries, completely bypassing the real DNS server. This has serious consequences, because all machines on that network can be completely unaware of this, and end up sending DNS traffic to the hacker’s machine.

There is an alternate method called DNS ID spoofing. Each DNS request and response carries a unique identifier, to differentiate between various simultaneously generated requests to a DNS server. This unique ID is usually a combination of the MAC address and the date/time stamp, and is created by the protocol stack automatically.

A hacker uses a sniffer to look at one or more DNS requests and responds with their respective unique number, but with a false IP address. This results in the client’s local cache being updated to this fabricated address. Further damage can be caused by hosting a virus on the machine at that IP address.

DNS rebinding

Also called DNS pinning, this is an advanced type of attack. In this method, the hacker first registers his own domain name and sets the TTL value of that domain at a lower value, which prevents that domain name from being cached.

DNS denial of service

As we learnt in the very first article of this series, bombarding the UDF port 53 or TCP port 53 with DNS queries can cause a DoS attack. Another method is to perform a ping of death or a TCP SYN flood attack. The idea behind this is to overwhelm server resources (CPU and memory) to stop it responding to queries. Though DNS servers are protected by firewalls, if care is not taken to block DNS UDP ports from non-trusted networks, it exposes the name resolution system to this attack.

DNS amplification

Amplification means to provide the DNS server with a task heavier than it is capable of handling. There are multiple ways to stress the server and eventually make it non-functional. In one method of amplification, a Trojan is written to poison and populate the local cache of multiple client hosts. This forces all infected clients to send their name requests to a particular name server, which is being targeted by the hackers.

Each server can only respond to a certain number of queries (based on CPU speed and configuration) and eventually starts queuing up requests. As more and more clients get infected, the increasing number of queries ultimately makes the server give up.

In another type of attack, a hacker poisons the DNS server’s cache; instead of changing the associated IP address of an A or CNAME record, a change is made to the domain name. To make it worse, the domain name is made to contain a few hundreds or thousands of characters. This starts the replication process, and hence the download of multiple kilobytes of data from the main name server to its replicating partners, and eventually to clients.

Upon expiration of the TTL, the replication process initiates again, and results in the breakdown of one or more DNS servers in the chain. This trick actually simulates a distributed denial of service attack, and hence is very dangerous and hard to control.

Protecting FOSS systems

In the FOSS world, the DNS service is a well-known implementation across the globe, simply because it proves to be the fastest available name resolution mechanism. A widely used and famous example is the Bind utility/service. However, since most DNS attacks exploit the basic design lacunae, it becomes a tougher task to protect FOSS-based name resolution systems.

The very first step to protect a FOSS DNS server is to lock it down at the network level. Besides the server management ports, only the DNS query ports should be allowed and the rest must be blocked on the firewall as well as in OS-based port filtering.

The second important step is to not install any other software on a DNS server, other than the name server service itself. This precaution must be followed especially in the case of an externally facing corporate root name server that holds all internal name spaces, and resolves external name queries for the local area network.

It is often found that vulnerability in another program on the name server leaves a back door open, resulting in intrusion into the name service. While most critical infrastructures implement a firewall, a UTM device and powerful anti-virus or anti-Trojan software, it becomes imperative to have an intrusion detection system (IDS) in place. An IDS is capable of filtering out sneaky Layer 2 and Layer 3 attacks such as ARP spoofing, IP spoofing, packet sniffing, etc.

Besides the above crucial precautions, there are a few advanced methods that can be followed too. As we learnt earlier, each query carries its own unique identifier and is marked in the UDP packet. Unfortunately, due to the design of DNS stacks based on RFC standards, these identifiers are easily predictable, and hence randomising those can be a good idea to prevent spoofing attacks. Similarly, the UDP port on which the name server responds is predictable too, and can be randomised.

There are open source tools available on the Internet for just this purpose; however, please note that it adds a bit of a delay in query resolution. A fairly recent and popular protection technique is DNSSEC (DNS Security Extensions). It protects clients and systems from cache poisoning attacks by digitally signing records using public key encryption. While working in a similar fashion to SSL, the querying and answering hosts need to establish a digital trust between each other; once it is achieved, name resolution takes place.

Once the process is completed, the session is torn down, thus protecting the security at either ends. DNSSEC is being implemented by most ISPs in the world.

DNS invasion is a common phenomenon in the IT security world. It involves exploiting DNS design loopholes to gain access to the IT infrastructure or to lure the client computers to a phishing farm. FOSS is also susceptible to such attacks and hence network administrators must understand the techniques to protect their infrastructure from information loss or theft.

Aircrack-ng: Wi-Fi Troubleshooting, Auditing and Cracking Made Easy – LINUX For You


Aircrack-ng: Wi-Fi Troubleshooting, Auditing and Cracking Made Easy – LINUX For You.

Aircrack-ng: Wi-Fi Troubleshooting, Auditing and Cracking Made Easy

By Ajay Gupta on January 1, 2011 in How-TosSecuritySysadminsTools / Apps · 10 Comments

Wi-Fi penetration testing

Wi-Fi technology has today become almost ubiquitous for wireless local area networks at offices, restaurants, homes, airports, hotels, etc. However, with increased Wi-Fi usage and awareness, hackers (or, rather, crackers) are exploiting the security weaknesses/vulnerabilities of Wi-Fi networks and Wi-Fi capable devices. This article discusses Aircrack-ng, a security tool that can be used by attackers and also by the “white hats”, who seek to secure a Wi-Fi network by trying to break into it first and then fixing the flaws that are found.

The two prime factors fuelling the rapid growth of Wi-Fi are the constant advancements in Wi-Fi technology, and the Wi-Fi capability in almost all consumer electronic (CE) devices that are being manufactured today — laptops, smartphones, cameras, printers/scanners, televisions, music players, etc.

As mentioned earlier, attackers are using the security weaknesses/vulnerabilities in Wi-Fi networks or Wi-Fi capable devices to intrude into them. After such an intrusion, attackers can maliciously exploit the network/device for their personal gains. Assisting these attackers in their mission is the availability of a variety of tools to detect and exploit various Wi-Fi vulnerabilities.

Among these tools, one that stands out is Aircrack-ng. It’s an open source utility, freely available for use, and is very popular equally among crackers and Wi-Fi penetration testers/auditors alike. It is the most comprehensive toolkit for troubleshooting and auditing Wi-Fi networks, and covers the earlier as well as the latest-known Wi-Fi exploits and vulnerabilities.

Aircrack-ng is basically a suite of tools that has been crafted to achieve the following objectives:

  1. Capture raw Wi-Fi packets in an intended airspace, on various channels of interest, and then analyse them to show the various Wi-Fi networks and Wi-Fi clients that were operating during the collection period.
  2. Break WEP and WPA PSK (pre-shared key)-type Wi-Fi networks by exploiting the known vulnerabilities of such networks.
  3. Injection/replay of Wi-Fi packets into the airspace.
  4. Exploit the weaknesses present in various Wi-Fi clients, to establish fake connections with such clients, in order to launch man-in-the-middle type of attacks.

Installation

Aircrack-ng can be installed on a Linux operating system (Fedora, Red Hat, Ubuntu, etc.) by compiling the source code on the host machine. As of this writing, the latest version of Aircrack-ng is 1.1, and you can obtain its source code here.

For Aircrack-ng tools to work, you need a compatible wireless card, and an appropriately patched driver. You can learn more about compatible cards on the project homepage. However, since installing patched drivers for Aircrack-ng can be tedious and complicated for many users, you can instead use the BackTrack Live Linux distribution, in the form of a Live CD/DVD/USB, to run Aircrack-ng flawlessly. Aircrack-ng and many patched wireless drivers (as required by Aircrack-ng) are already included in the BackTrack distribution.

Aircrack-ng utilities

Aircrack-ng, being a suite of tools, consists of a number of independent tools, each one accomplishing a certain task. To achieve certain objectives related to Wi-Fi auditing/cracking/troubleshooting, one or more tools of the suite are used in combination. Here are some of the important tools included in the suite.

Airmon-ng

This tool is very basic, and is used primarily to enable or disable the monitor mode on a wireless interface. It is frequently used in combination with other tools. Monitor mode puts the wireless interface into a promiscuous state, to enable it to sniff all the Wi-Fi data within range. You can also specify the channel for the monitor mode via this tool.

The basic usage is airmon-ng [channel], where indicates if you wish to start or stop the interface;  specifies the interface name; [channel] optionally sets the card to a specific channel.

Airodump-ng

This tool captures raw Wi-Fi packets through the wireless interface that’s in monitor mode, and dumps them into one or more file formats. The dumped file can be used by other tools for specific analysis. Along with capturing the raw traffic, Airodump-ng also displays in the output screen, a list of detected Access Points (APs) and wireless clients.

The list contains details for APs, such as, the SSID, the channel, encryption mechanism, authentication method, power level, etc. For wireless clients, the list shows the connected AP, power level, data rate, etc. Airodump-ng provides a variety of options, such as the use of a single channel or multiple channels for capturing and filtering output screen results on the basis of AP BSSID, etc. These options provide great flexibility in various scenarios. If one has a connected GPS receiver, then Airodump-ng can also log the coordinates of the found APs.

The basic usage is airodump-ng , where  indicates one or more options to be used while running the tool; and  indicates the monitor mode interface to be used for capturing the Wi-Fi traffic.

Some commonly used options are:

  • -f  — time in milliseconds between hopping channels, if multiple channels are used.
  • --output-format  — possible output formats are pcap, ivs, cvs, gps, kismet, netxml. The option can be specified multiple times if more than one output format is required.
  • --bssid  — filter APs by BSSID value.
  • --channel  — comma-separated list of channels for capture.
  • --write  — dump file prefix.

Example 1: If you wish to limit the Wi-Fi data capture to a single AP with BSSID00:11:22:33:44:55 operating on channel “8″ using the interface ath0, and write the captured data into a file with prefix capture and output format pcap, then issue the following command:

airodump-ng -c 8 --bssid 00:11:22:33:44:55 -w capture --output-format pcap ath0

Aircrack-ng

This is the main tool, used for recovering keys of WEP- and WPA PSK-based Wi-Fi networks. Aircrack-ng is able to break the WEP key once enough encrypted packets have been captured with Airodump-ng. The two methods used for breaking the WEP key are PTW and the FMS/Korek method.

PTW is the default, and requires a few data packets, particularly ARP request/reply packets, to crack the WEP key. However, PTW is limited to breaking of 40- and 104-bit WEP keys. The FMS/Korek method incorporates brute-force cracking and other statistical mechanisms to discover the WEP key. It requires a relatively large number of captured data packets, and is often used when the PTW method fails. To crack WPA/WPA2 PSK, only the dictionary method is supported, for which a capture of four WPA handshake packets is required.

The basic usage is aircrack-ng , where  is a comma-separated list of captured-data files, either in .pcap or .ivs format.

Some of the commonly used options are:

  • -a  — forces either WEP (by specifying the value 1) or WPA/WPA2-PSK (specify 2) cracking.
  • -b  — BSSID value (AP MAC address) is used to select the target network for key cracking. All data packets in the capture files that contain the same BSSID value are used for cracking.
  • -e  — The ESSID value is used to select the target network for key cracking, and thus use only corresponding data packets in the capture files.
  • -K — Invokes the Korek WEP cracking method.
  • -z — Invokes the PTW WEP cracking method (the default in the latest version).
  • -w  — Used to specify the path of a word-list file for the WPA dictionary attack.

Example 2: If you wish to recover the WEP key for an AP with the MAC address00:11:22:33:44:55, and the corresponding capture file is output.cap, then you needs to invoke Aircrack-ng as follows:

aircrack-ng -b 00:11:22:33:44:55 output.cap

If the command is successful, the WEP key for the target network will be displayed on the screen.

Example 3: If you wish to recover the WPA PSK for an AP with the MAC address00:11:22:33:44:55, using the word-list file password.lst (required for a dictionary attack), and the corresponding capture file is output.cap, then run the following command:

aircrack-ng -b 00:11:22:33:44:55 –w password.lst output.cap

If the command is successful, and the WPA PSK is contained in the word-list/dictionary file, then this key will be displayed on the screen.

Aircrack-ng includes many optimisations to standard key-cracking algorithms, and hence is much faster than other available Wi-Fi key cracking programs. One can run Aircrack-ng and Airodump-ng simultaneously, as Aircrack-ng will auto-update when new packets are captured by Airodump-ng. Aircrack-ng is widely used by crackers to recover keys of WEP and WPA/WPA2 PSK to intrude into the network, while Wi-Fi penetration testers use the same tool to test the effectiveness of a WEP or WPA/WPA2-PSK key.

Aireplay-ng

The primary goal of this tool is to generate Wi-Fi traffic to be used later by Aircrack-ng to crack the WEP and WPA PSK keys. To achieve this goal, Aireplay is designed to implement the following attacks, which inject one or more Wi-Fi packets into the network:

  • De-authentication attacks: Aireplay-ng can send de-authentication packets to one or more clients that are associated with an AP, in order to capture the WPA handshake, discover hidden SSIDs, or generate ARP requests (to be used in WEP cracking).
  • Fake authentication attacks: In these attacks, Aireplay-ng sends authentication and association packets to a WEP AP to associate with it. This may be needed when no clients are connected to the AP, and you need to generate Wi-Fi traffic to break the WEP key of the AP.
  • Interactive packet replay attacks: In such cases, one can choose a specific packet to replay (inject) from the live flow of packets in the wireless card, or from a pcap format file. Replaying particular packets in a WEP Wi-Fi network can generate more traffic, which can be used by Aircrack-ng to recover the WEP key.
  • ARP request replay attacks: These attacks are very useful to generate enough ARP traffic that can be used by Aircrack-ng to break the WEP key using the PTW method. Here, Aireplay-ng listens for an ARP packet, and then retransmits it to the AP, which in turn generates an ARP packet again that is then replayed once more by Aireplay-ng. This process is repeated until enough ARP packets (for WEP cracking) are generated by the AP.
  • Café Latte attacks: This is useful to obtain the WEP key from an unassociated client. In this, Aireplay-ng listens for an ARP packet from the client, then modifies it and sends it back to the client, so that the client generates a new ARP packet. When enough ARP packets are generated by the client, encrypted correctly with the client WEP key, Aircrack-ng can be used to recover the WEP key from those packets.

The basic usage is aireplay-ng , where indicates the attack type and associated options and  indicates the wireless interface to be used for replay (injection).

Some of the common options are:

  • Attack options (select the attack type)

    • -0 — De-authentication attack.
    • -1 — Fake authentication attack.
    • -2 — Interactive packet replay attack.
    • -3 — ARP request replay attack.
    • -6 — Café Latte attack.

  • Filter options (for filtering a packet from a source)

    • -b  — Mac address of the AP
    • -d  — Destination MAC address
    • -s  — Source Mac address
    • -m  — Minimum length of the packet
    • -n  — Maximum length of the packet
    • -u  — Type of packet
    • -v  — Subtype of packet

  • Replay options (to be used while replaying for a particular attack)

    • -x  — Number of packets per second
    • -a  — Set AP MAC address
    • -c  — Set destination MAC address
    • -h  — Set source MAC address

  • Source options (to select a source of packets for an interactive packet replay attack)

    • -r  — pcap file to be used for source of selection/filtering packets.

Example 4: If you wish to de-authenticate (disconnect) a client 00:0F:22:33:44:55associated to an AP with the MAC address 00:11:22:33:44:55, using ath0 as the replay interface, then you invoke Aireplay-ng as follows:

aireplay-ng -0 -a 00:11:22:33:44:55 -c 00:0F:22:33:44:55 ath0

Airdecap-ng

This tool is used to decrypt the WEP/WPA/WPA2 capture files. Also, it can be used to strip the wireless headers from an unencrypted wireless capture file. The output is a new file with the suffix as -dec.cap, which is basically the decrypted/stripped version of the input file.

The basic usage is airdecap-ng , where  indicates the input pcap file. Some of the common options are:

  • -l — Do not remove MAC header
  • -b  — Mac Address of the AP to select the packets in the input file for decryption
  • -k  — WPA/WPA2 Pairwise Master key in Hex
  • -w  — WEP key in Hex
  • -p  — WPA/WPA2 passphrase
  • -e  — SSID of the network to select the packets in the input file for decryption

Example 5: If you wish to decrypt the packets from a WPA network with the ESSIDdecrypt-test and the passphrase password, from the input file wpa.cap, then you need to invoke Airdecap-ng as shown below:

airdecap-ng -e ‘decrypt-test’ -p password wpa.cap

Other documentation

Looking over some of the most important tools in the Aircrack-ng suite, you might have got a clearer picture of the comprehensiveness of the suite. Apart from the tools described, Aircrack-ng contains many more for various other purposes. The Aircrack-ng website is very well maintained in terms of documentation for the various tools, from their usage perspective.

People who are still unaware of Wi-Fi security weaknesses and loopholes that can lead to intrusion and malicious attacks from outsiders should learn that Aircrack-ng is really a great suite to test your Wi-Fi setup. With it, you can locate unwanted APs at an office, check that authorised Wi-Fi networks are appropriately encrypted, and test the strength of the encryption pass-phrase and keys.

In recent times, Aircrack-ng has been fully ported to the Nokia N900, making it far more convenient for users, who can now carry the most popular Wi-Fi auditing tool in their pockets.