PENTESTING WITH TOOLS Network Scanning: the Basic t oolsfiles.accuvant.com/web/files/pentest_network_scanning_article.pdf · PENTESTING WITH TOOLS T his will allow the reader to have

Page 32 http://pentestmag.comStartKit 01/2013(01)

PENTESTING WITH TOOLS

This will allow the reader to have not only a better understanding of how the network scanners work on the discovery phase, but

also be able to implement their own scanners or use other programs to gather this information in the case nmap or other tools would trigger IDS sig-natures and the engagement requires not being caught by it (Red Team).

A Good Scan is as Good as half of the Penetration on the machineYou sit down and connect to the network, you get connected and have access, you smile verifying that all the tools are updated, get the notes ready, encrypted directory and fire up the nmap scanner. The client wants a full detailed report and packet dump for further analysis by their forensic team, so you turn on tcpdump and let it record. The client approaches and the conversation goes like this:

• “So how is the engagement going? Any prob-lems?”

• “No sir, no problem, right now I’m just doing a network discovery scan”

• “What is that?”• “I’m just looking for ‘live’ hosts and open ports”• “… explain to me, what is this program doing?

How does it work?”

Scanning is one of the first steps enabling to ob-tain valuable information about the network. Scanning is the most used and most detected part of an attack since it gives the attacker vital in-formation, such as: machines that are reachable, services each machine has turned on or is offer-ing to the reach of the attacker.

Scanning is often underrated and is not real-ly taken care of properly, scanning is an art and should be taken accordingly, there are basic and advanced techniques some of which will be cov-ered within this article.

Some introduction into TCP/IP and UDP will be covered to give background on the techniques covered.

tCP/IPThe Transfer Control Protocol (or TCP as a short name) is a transfer protocol (I’m sure the name gave it away); the name TCP/IP refers to an entire suit of data communication protocols; the name comes from adding the Transfer Control Protocol and the Internet Protocol.

TCP is a connection-oriented protocol. When-ever a packet arrives, it gets checked and an ac-knowledged packet is send (ACK) to refer to the particular packet and tells the sender that it ar-rived. Each packet has a specific number. The ID

Network Scanning: the Basic toolsScanning is one of the first steps to obtain information about a network, services and hosts. While there are numerous tools, most of them fail to do a complete explanation on what is going “under the hood”. This article will try to explain the basic techniques used under the hood of great scanners such as nmap and so forth.


Listing 1. Basic connecting program written in C for Linux

/* * connect-scan.c * * Fast connect scanner written for demonstration only, this is for educational purposes only * * Copyright 2003(C) Enrique Alfonso Sanchez Montellano * <[email protected]> * */#include <stdio.h>#include <netinet/in.h>#include <netdb.h>#include <sys/socket.h>#include <sys/types.h>#include <getopt.h>uint32_t resolve (char *serv) { struct sockaddr_in sinn; struct hostent *hent;

hent = gethostbyname (serv); if(!hent) return 0; bzero ((char *) &sinn, sizeof (sinn)); memcpy ((char *) &sinn.sin_addr, hent->h_addr, hent->h_length); return sinn.sin_addr.s_addr;}

int connect_2_port(uint32_t victim, u_long port) { int sockfd; struct sockaddr_in hostaddr; fprintf(stderr, "Trying port %d\t\t", port);

if((sockfd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) { fprintf(stderr, "Cannot allocate socket\n"); return -1; }

hostaddr.sin_port = htons(port); hostaddr.sin_addr.s_addr = victim; hostaddr.sin_family = AF_INET;

if((connect(sockfd, (struct sockaddr *)&hostaddr, sizeof(hostaddr))) != 0) { fprintf(stderr, "Closed port\n"); } else { fprintf(stderr, "Open port\n"); }

close(sockfd); return 0;



}

void usage(char *name) { fprintf(stderr, "Usage: %s -h <host> -s <start port> -e <end port>\n", name); fprintf(stderr, "\th: Host to scan\n"); fprintf(stderr, "\ts: start port (default is 1)\n"); fprintf(stderr, "\te: end port (default is 6000)\n"); fprintf(stderr, "Bugs and comments to [email protected]\n\n"); exit(0);}

int main(int argc, char **argv) { int start_port = 1, end_port = 6000; int option, i; char *victim; uint32_t resolved_addie;

if(argc < 2) { usage(argv[0]); }

while((option = getopt(argc, argv, "h:s:e:")) != EOF) { switch(option){ case 'h': victim = optarg; break; case 's': start_port = atoi(optarg); if((start_port < 0) || (start_port > 65535)) { fprintf(stderr, "Negative or bigger than actual ports detected setting to 1\n"); start_port = 1; } break; case 'e': end_port = atoi(optarg); if((end_port < 0) || (end_port > 65535) || (end_port < start_port)) { fprintf(stderr, "Weird stuff going on, either end port negative, over 65535 or lower than

start port ... setting to port 2\n"); end_port = 2; } break; } } resolved_addie = resolve(victim);

for(i = start_port; i <= end_port; i++) { connect_2_port(resolved_addie, i); }

return 0;}


number of it, is the number the host will refer to, it enable to tell from which connection it comes and if it’s on the order or is missing.

An example of a TCP connection is the next: A client (C) sends a synchronize packet to the serv-er (S) to initiate a connection, this packet contains a number to synchronize with (C(syn)), then the Server replies with the number the server will use to start the connection and an acknowledge of the first packet being received with the number the client send + 1 (S(syn/C(ack + 1))), at the end the client sends an acknowledge packet with the number the server send + 1 (C(S(ack + 1))). This is to synchronize and have the number straight, this way if packet 3 arrives before packet 2 the receiver waits for packet 2 and if times out it can send a packet asking for packet 2 again to be able to have the connection in the right order and complete.

This is called the “3 way handshake”. This is a very important process to understand, since some techniques are based on the way TCP handles connections and on how different operating sys-tems have implemented this.

The majority of people I encounter do not real-ize that being able to sniff a network is not a good thing, not only because you can see passwords all over the place, but because you can take over connections. After after the connection is done, the only thing is that packets increment by 1 to be able to refer to them, so when you see passing packet 1 and 2, you know that packet 3 is coming. And, if the attacker manages to send packet 3 before the real connection, it can take over the connec-tion due to the fact that it is not synchronized. The receiver sees that packet 3 has already been re-ceived and thinks it is a delay or a repeat and si-lently drops it.

A lot of things can be done with badly implement-ed TCP/IP Stacks on operating systems and we will see some of them on this article.

types of ScansConnectivity ScanThis type of scan requires that the whole 3-way TCP connection is established and uses normal sockets; this means you don’t need super user privileges to be able to run this scan and that any user can do it, this is usually logged even on the host due to the fact that you have to complete the whole connection.Writing a socket scanner is very easy, we are re-inventing the wheel right now, but for sake of tech-nicality, we are going to write our own fast socket scanner (Listing 1).

The function resolve() executes a gethostby-name and stores it into a sockaddr_in structure for further use and connections, this is a fairly generic function that can be reused in other programs, so is a good idea to either have it in a separate C file in case of multiple projects or in case of a bigger project by just design to be able to maintain it. But our scanner is fairly small and for readability we have it within our code (Listing 2).

Nextly, the function connect_2_port() does the actual connection, this is done by taking the result of the resolve function and the port and creating a socket, filling the correct information (Listing 3).

As you can see, writing a fast scanner based on sockets and pure connection is easy, you can also use “canned tools” such as nmap (great scanner and the industry standard): Listing 4.

As the reader can see, nmap gathers and shows more information than our scanner, if you want to add the services you can parse the /etc/services file and add it up, but if you are writing your own

Listing 2. Function to resolve into a sockaddr_in structure the IP Address or hostname given

uint32_t resolve (char *serv) { struct sockaddr_in sinn; //structure to fill out with the result of gethostbyname() struct hostent *hent;

hent = gethostbyname (serv); // We execute gethostbyname() if(!hent) return 0; // If we could not resolve we return 0 bzero ((char *) &sinn, sizeof (sinn)); memcpy ((char *) &sinn.sin_addr, hent->h_addr, hent->h_length); return sinn.sin_addr.s_addr; // Else we return the resolved address as a unsigned int

}



scanner, you probably know a couple of most used ports don’t you? This type of scan as it was said before, is usually really dirty and even the host logs it sometimes (in the case of using wrappers) so expect your IDS to go bananas as soon as you run the port scanners with this option.

SYN ScanIn this type of scan, the connection is not finished, rather a RST is sent instead of sending the last

part of the 3 way handshake, this means a SYN gets sent, then a SYN/ACK gets received but a RST is being sent instead of the ACK.

This type of port scan is not logged by the host (unless you have a host based IDS in which case is the IDS that is logging not really the host any-way), this port scan used to be logged on kernel 2.0.X, since there was a bug in which you accept-ed really fast, but the bug was fixed so it doesn’t get logged anymore.

Listing 3. connect_2_port function

int connect_2_port(uint32_t victim, u_long port) { int sockfd; struct sockaddr_in hostaddr;

fprintf(stderr, "Trying port %d\t\t", port);

if((sockfd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) { //Create socket fprintf(stderr, "Cannot allocate socket\n"); return -1; }

hostaddr.sin_port = htons(port); // Fill out the port we are going to connect hostaddr.sin_addr.s_addr = victim; // Fill out the address where is going to connect hostaddr.sin_family = AF_INET;

if((connect(sockfd, (struct sockaddr *)&hostaddr, sizeof(hostaddr))) != 0) { fprintf(stderr, "Closed port\n"); } else { fprintf(stderr, "Open port\n"); }

close(sockfd); return 0;}

Listing 4. nmap output for a Full connect scan

nahual@fscking:~$ nmap -sT -n 127.0.0.1 //We are going to scan ourselves to make it fast

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )Interesting ports on (127.0.0.1):(The 1599 ports scanned but not shown below are in state: closed)Port State Service22/tcp open ssh111/tcp open sunrpc

Nmap run completed -- 1 IP address (1 host up) scanned in 0 secondsnahual@fscking:~$


This is one of the most widely used methods of scanning, it’s faster than the other one, since you don’t really have to wait for the connection to finish to realize that the port is open, as soon as you get a SYN/ACK you know the port is open and add it up on the opened ports. You can use nmap; in this case you would have to use the –sS option instead of the –sT option to gather the information: Listing 5.

What happened? This type of scan requires root, since you have to open raw sockets to be able to close them in a different way or even just not com-plete the connection by spoofing the packets all the way and not having the kernel fill most of the stuff up.

I wouldn’t recommend making nmap suid, since it could potentially have bugs which could be ex-

Listing 5. Nmap execution os SYN scan without root privileges

nahual@fscking:~$ nmap -sS -n 127.0.0.1

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )You requested a scan type which requires r00t privileges, and you do not have them.

QUITTING!nahual@fscking:~$

Listing 6. Nmap output of SYN scan

nahual@fscking:~$ su -Password: //Type root’s password here

If there was in justice in the world, "trust" would be a four-letter word.

root@fscking:~# nmap -sS -n 127.0.0.1


Nmap run completed -- 1 IP address (1 host up) scanned in 2 secondsroot@fscking:~#

Listing 7. hping sending SYN packets to a closed port

root@fscking:~# hping -S -p 130 127.0.0.1HPING 127.0.0.1 (lo 127.0.0.1): S set, 40 headers + 0 data byteslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=130 flags=RA seq=0 win=0 rtt=0.5 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=130 flags=RA seq=1 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=130 flags=RA seq=2 win=0 rtt=0.1 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=130 flags=RA seq=3 win=0 rtt=0.2 ms

--- 127.0.0.1 hping statistic ---4 packets tramitted, 4 packets received, 0% packet lossround-trip min/avg/max = 0.1/0.3/0.5 msroot@fscking:~#



Listing 8. hping sending SYN packets to an open port

root@fscking:~# hping -S -p 22 127.0.0.1HPING 127.0.0.1 (lo 127.0.0.1): S set, 40 headers + 0 data byteslen=44 ip=127.0.0.1 ttl=64 DF id=0 sport=22 flags=SA seq=0 win=32767 rtt=1.7 mslen=44 ip=127.0.0.1 ttl=64 DF id=0 sport=22 flags=SA seq=1 win=32767 rtt=0.3 mslen=44 ip=127.0.0.1 ttl=64 DF id=0 sport=22 flags=SA seq=2 win=32767 rtt=0.3 mslen=44 ip=127.0.0.1 ttl=64 DF id=0 sport=22 flags=SA seq=3 win=32767 rtt=0.2 ms


Listing 9. hping sending one packet to each port and incrementing after each packet

root@fscking:~# hping -S -p ++ 127.0.0.1HPING 127.0.0.1 (lo 127.0.0.1): S set, 40 headers + 0 data byteslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=0 flags=RA seq=0 win=0 rtt=0.4 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=1 flags=RA seq=1 win=0 rtt=0.3 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=2 flags=RA seq=2 win=0 rtt=0.3 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=3 flags=RA seq=3 win=0 rtt=0.1 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=4 flags=RA seq=4 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=5 flags=RA seq=5 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=6 flags=RA seq=6 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=7 flags=RA seq=7 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=8 flags=RA seq=8 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=9 flags=RA seq=9 win=0 rtt=0.1 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=10 flags=RA seq=10 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=11 flags=RA seq=11 win=0 rtt=0.3 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=12 flags=RA seq=12 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=13 flags=RA seq=13 win=0 rtt=0.3 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=14 flags=RA seq=14 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=15 flags=RA seq=15 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=16 flags=RA seq=16 win=0 rtt=0.3 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=17 flags=RA seq=17 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=18 flags=RA seq=18 win=0 rtt=0.3 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=19 flags=RA seq=19 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=20 flags=RA seq=20 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=21 flags=RA seq=21 win=0 rtt=0.1 mslen=44 ip=127.0.0.1 ttl=64 DF id=0 sport=22 flags=SA seq=22 win=32767 rtt=0.7 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=23 flags=RA seq=23 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=24 flags=RA seq=24 win=0 rtt=0.3 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=25 flags=RA seq=25 win=0 rtt=0.2 ms



ploited (In older versions if nmap was suid you could just nmap --interactive then just !/bin/sh your way into root) so su or sudo into root account and try again the scan: Listing 6.

By now, you must be wondering why I’m using the –n option and not saying anything about it, the –n option is to have the program not resolve the IP address or name (even as weird as it sounds) while trying to print it, meaning it will not resolve lo-calhost to 127.0.0.1. Then, try to resolve 127.0.0.1 back to print it out, this would take more time, and we are not going to waste any time on that!

But using canned tools without knowing how they work in the back is not that good, is not fun, and in complex scenarios it might even get you in trouble. We are going to use one of my favorite tools: hping.

Hping is coded by Salvatore Sanfilippo (antirez) and you can find on http://www.kyuzz.org/anti-rez/hping2.html or just apt-get install on a debian based distribution (Kali, formerly known as back-track already contains hping). This tool will let us create packets with options as we wish, without having to code an entire packet creator ourselves, so we port scan the same machine with hping. To run hping, you need to be root, and read some

of the options, this is not as “clean” as nmap that gives you everything already processed, but that would be because hping creates packets, sends them and shows you the response so the inter-pretation is left to the user, this one is more flex-ible and you can read it for yourself. Some options are going to be discussed here and some won’t. Check your man page for more details.

Hping can take a huge amount of options, the most important ones are:

• -S: Tells hping to add the SYN flag into the TCP packet

• -A: Tells hping to add the ACK flag into the TCP packet

• -r: Tells hping to make the increment ID of the packet relative

• -a: Tells hping to spoof the address which is written right after the option as if it was sent from that particular address

• -p: Destination port for the packet• -i: interval in which to send the packets (if we

use u is microsenconds)

Now let’s see how a closed port looks like in hping: Listing 7.

Listing 10. hping sending SYN packets with grep open ports

root@fscking:~# hping -S -p ++ 127.0.0.1 -i u1000 | grep SAlen=44 ip=127.0.0.1 ttl=64 DF id=0 sport=22 flags=SA seq=22 win=32767 rtt=0.2 mslen=44 ip=127.0.0.1 ttl=64 DF id=0 sport=111 flags=SA seq=111 win=32767 rtt=0.1 ms

--- 127.0.0.1 hping statistic ---810 packets tramitted, 810 packets received, 0% packet lossround-trip min/avg/max = 0.1/0.1/0.7 ms

root@fscking:~#

Listing 11. nmap executing a FIN scan

root@fscking:~# nmap -sF -n 127.0.0.1


Nmap run completed -- 1 IP address (1 host up) scanned in 3 secondsroot@fscking:~#

http://www.kyuzz.org/antirez/hping2.html

http://www.kyuzz.org/antirez/hping2.html



If we read on the line and search for flags, we get the flags that the returned packet has which are RA, R for RST and A for ACK, this means that the server got the SYN packet (because of the ACK) but the port is closed (is not offering any services) since we have the R flag turned on. An-other nice indication is the fact that the window size for the port is 0, saying you cannot send a maximum amount of data in that port (since its closed of course!).

If the port is open the result would look like this: Listing 8.

The reader can see how the flags section has changed from RA to SA, this meaning SYN for the S and A for the ACK, meaning the port is open, the window size is also something different

that 0, meaning you can send data trough that port. But doing one line of command each port and reading everything can be trying, how can I send to each port? We use the –p option with ++: Listing 9.

We can see that the sport is giving us the des-tination port for the server. Also, we can see that all ports, apart from port 22 is opened since is the one that has the SA and the window size different than 0.

To make it faster and less complicated to read, we can use grep and the –i option: Listing 10.

We sent 810 packets but used grep to only print the SA flags, meaning we only want the opened ports, we get the same result as the other scans: port 22 and port 111 are opened.

Listing 12. hping used to execute a FIN scan

root@fscking:~# hping -F 127.0.0.1 -p ++HPING 127.0.0.1 (lo 127.0.0.1): F set, 40 headers + 0 data byteslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=0 flags=RA seq=0 win=0 rtt=0.3 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=1 flags=RA seq=1 win=0 rtt=0.4 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=2 flags=RA seq=2 win=0 rtt=0.3 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=3 flags=RA seq=3 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=4 flags=RA seq=4 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=5 flags=RA seq=5 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=6 flags=RA seq=6 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=7 flags=RA seq=7 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=8 flags=RA seq=8 win=0 rtt=0.1 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=9 flags=RA seq=9 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=10 flags=RA seq=10 win=0 rtt=0.1 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=11 flags=RA seq=11 win=0 rtt=0.3 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=12 flags=RA seq=12 win=0 rtt=0.4 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=13 flags=RA seq=13 win=0 rtt=0.3 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=14 flags=RA seq=14 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=15 flags=RA seq=15 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=16 flags=RA seq=16 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=17 flags=RA seq=17 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=18 flags=RA seq=18 win=0 rtt=0.5 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=19 flags=RA seq=19 win=0 rtt=0.3 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=20 flags=RA seq=20 win=0 rtt=0.2 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=21 flags=RA seq=21 win=0 rtt=0.2 ms//Hey port 22 is gone!len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=23 flags=RA seq=23 win=0 rtt=0.5 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=24 flags=RA seq=24 win=0 rtt=0.3 mslen=40 ip=127.0.0.1 ttl=64 DF id=0 sport=25 flags=RA seq=25 win=0 rtt=0.2 ms



FYN ScanFYN Scan is a scan in which you send a packet with FYN, meaning is the end of the connection, in which case the server will not respond to the packet but silently drop the connection, with FYN the con-nection is read with out of band data and terminates nicely, which is different with RST which reads no out of band data just drops the connection.

This type of scan is used to bypass simple SYN filtering firewalls, one of the tricks about this is that open ports do not respond since they have to si-lently read the packet and not answer to it. In which case if the FYN packets are filtered in the firewalls all the ports will look opened! Using nmap we get the same results as the other scans: Listing 11.We cannot discern what is going on in here since everything is done for us by the program, so we use hping to see the results of sending packets to the server: Listing 12.

As you ca see by the comment port 22 is not printed, the packet is lost, this means that port 22 is opened since it has to drop it after processing it silently.

This type of scan is pretty much like SYN scan so this part should be short, just remember that in a FYN scan opened ports do not respond.

Warning Windows does not respond as the RFC requires (what a surprise!) so it replies with RA, showing on the scanners and as you read that all the ports are closed.

Bounce ScanningBy now all the IDS in your network should be screaming hacker all over he place with your IP showing in every log, remember I said this are not really stealth scans, now up to the stealth part of scanning.

Listing 13. hping sending SYN/ACK packets to a host

root@fscking:~# hping -S -A -r -n 192.168.132.1 -p 100HPING 192.168.132.1 (eth1 192.168.132.1): SA set, 40 headers + 0 data byteslen=46 ip=192.168.132.1 ttl=128 id=16133 sport=100 flags=R seq=0 win=0 rtt=17.0 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=100 flags=R seq=1 win=0 rtt=0.4 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=100 flags=R seq=2 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=100 flags=R seq=3 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=100 flags=R seq=4 win=0 rtt=0.3 ms


Listing 14. hping sending SYN/ACK packets to a host

root@fscking:~# hping -S -A -r -p 130 192.168.132.1HPING 192.168.132.1 (eth1 192.168.132.1): SA set, 40 headers + 0 data byteslen=46 ip=192.168.132.1 ttl=128 id=20058 sport=130 flags=R seq=0 win=0 rtt=0.4 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=1 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=2 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=3 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=4 win=0 rtt=0.3 msAnd the count just keeps on going but for the sake of brevity I will not put everything here!

Listing 15. hping sending SYN packets with fake address to a host

root@fscking:~# hping -S -a 192.168.132.1 -p 80 192.168.132.2 -i u1000HPING 192.168.132.2 (eth1 192.168.132.2): S set, 40 headers + 0 data bytesProgram seems to hang in here, look at the other terminal



Some years ago a way to bounce scan trough windows machines and routers was published. Due to the fact that windows TCP/IP stack is so overwhelming in complexity, it can be used to read the RST ID numbers and fake packets from that host to the victim. By using the windows/router host RST ID increment, the real IP address of the attacker is hidden from the victim.

Windows RST id increments by 1 while not be-ing really pushed with traffic, meaning the TCP/IP stack increments by 1 not randomly like the other OS, giving us the opportunity to spoof the connec-tion nicely and getting some nice results:

So when you send a packet and it gets RST, the id increments sequentially: Listing 13.

Using the –r option we can see the increment on the id is +2, meaning the first one was 16133 but the second one was id of that packet minus the id before it (16135 – 16133 = 2), but the increment is sequential giving us the opportunity of spoofing the connection.

Now imagine a network like this: Figure 1.

Figure 1. Steps taken for a bounce scan

If you start pulling the RST id from the spoofed machine, you can see that it increments by 1 each time; now the attacker sends a spoofed SYN pack-et which looks like it’s coming from the spoofed machine and goes to the victim, as soon as the vic-tim responds with the appropriate SYN/ACK pack-et the spoofed machine is going to RST it, why? Because it did not initiate the connection so is not on it’s table, it resets the connection and of course that has a RST id on it. Next time we check send the SYN/ACK packet to pull for the RST id from the spoofed machine the increment is not going to be 1 but 2, since it already sent another RST to the victim, giving us that the port we spoofed to is open.

You cannot RST a RST packet, so it the port is closed the spoofed machine will get a RST packet

by the victim dropping it silently and not increment-ing the RST id. This way if we pull the RST id con-stantly while sending spoofed packets to the victim we can know which ports are opened.

The firewall and the IDS on victim are going to think the scan if coming from the spoofed machine, there goes your very expensive IDS, giving the at-tacker the appearance of coming from different hosts at the same time and of course if the tool is networked right it will look as normal traffic or virus traffic.

For this type of scan you need 2 shells if they are possible next to each other or at least visible at the same time, on the first one we are going to start pul-ing the RST id to a windows machine: Listing 14.

Warning NoteYou do not need that port to be opened since you want the RST not a SYN/ACK. That should make it really hard to find, a non firewalled windows ma-chine in the internet with low traffic, something hard to find huh?

When you are ready, the next command will send a lot of packets to the victim machine spoofing it as the windows machine (you don’t get any output from this command): Listing 15.

If the port is opened, you will notice an increment on the id, in my case port 80 is not opened so noth-ing happens (victim is RST; Listing 16).

Try to guess in which line I typed the command and started to send the spoofed packets to port 22 with the next command: Listing 17.

As you can see, the RST id is incremented to 102 and stayed there. As soon as I hit ctrl-C to stop sending packets, the id went down to +2 again. This tells me that this port is open and is leaving logs as the windows machine, very nice and easy to do, although it is really hard to do it one port at the time right? A bounce scan can be downloaded at http://www.security-dojo.com/code/bscan.c.

uDP ScanSome services run under the User Datagram Protocol since they need bigger data window and they are not oriented to connectivity (such as mountd, nfsd and other). This services have their ports assigned and since it is another pro-tocol, the ports can be the same as TCP but not the service! A very used service that uses UDP is the nameserver service, which runs under port 53 UDP (and TCP) resolving requests go under UDP by default.

http://www.security-dojo.com/code/bscan.c


How do we know the UDP port is open? Because by RFC it should not respond and if its closed it should send an ICMP Port Unreachable if it’s closed, so we can write our own scanner based on that, let’s see an example using hping (Listing 18).

Port 53 (domain) is closed on the machine so it returns ICMP Port Unreachable since the service

is not there, port 111 (sunrpc) is open so it returns nothing, remember UDP is a connectionless proto-col so every packet is assumed to have data that is to be used on the connection. You can use a canned tool such as nmap and the results would be like this: Listing 19. As you can see the results are the same, you could use hping to scan the en-

Listing 16. hping sending SYN/ACK packets to a windows host

root@fscking:~# hping -S -A -r -p 130 192.168.132.1HPING 192.168.132.1 (eth1 192.168.132.1): SA set, 40 headers + 0 data byteslen=46 ip=192.168.132.1 ttl=128 id=21078 sport=130 flags=R seq=0 win=0 rtt=0.5 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=1 win=0 rtt=0.5 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=2 win=0 rtt=0.4 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=3 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=4 win=0 rtt=0.2 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=5 win=0 rtt=0.2 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=6 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=7 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=8 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=9 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=10 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=11 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+3 sport=130 flags=R seq=12 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+3 sport=130 flags=R seq=13 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=14 win=0 rtt=0.4 mslen=46 ip=192.168.132.1 ttl=128 id=+6 sport=130 flags=R seq=15 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+123 sport=130 flags=R seq=16 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+102 sport=130 flags=R seq=17 win=0 rtt=0.2 mslen=46 ip=192.168.132.1 ttl=128 id=+102 sport=130 flags=R seq=18 win=0 rtt=0.2 mslen=46 ip=192.168.132.1 ttl=128 id=+102 sport=130 flags=R seq=19 win=0 rtt=0.2 mslen=46 ip=192.168.132.1 ttl=128 id=+102 sport=130 flags=R seq=20 win=0 rtt=0.2 mslen=46 ip=192.168.132.1 ttl=128 id=+102 sport=130 flags=R seq=21 win=0 rtt=0.2 mslen=46 ip=192.168.132.1 ttl=128 id=+59 sport=130 flags=R seq=22 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=23 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=24 win=0 rtt=0.3 mslen=46 ip=192.168.132.1 ttl=128 id=+2 sport=130 flags=R seq=25 win=0 rtt=0.3 ms


Listing 17. hping sending SYN packets with fake address to a hostroot@fscking:~# hping -S -a 192.168.132.1 -p 22 192.168.132.2 -i u1000HPING 192.168.132.2 (eth1 192.168.132.2): S set, 40 headers + 0 data bytes




tire range using the –p ++ option or even use our own UDP scanner

ConclusionThis article covers a lot of code and not a lot on writ-ing (which was fun for me), there is not a lot new to say on scanning. Having knowledge of what hap-pens behind the network scanners such as nmap helps a lot, if you don’t understand why you get a RST when you send a SYN/ACK instead of a SYN or feel the TCP/IP theory is lacking I recommend reading TCP/IP Illustrated I, II and III by Richard Stevens, they are the best books on the subject.

Scanning is highly underrated, it is the first step to gather information on the network while on a hands on basis, it reports open ports, operating systems, filtered ports, if there are any firewalls, how are they done and which are they own poli-cies, etc.

A good scan is as good as half of the penetration on the machine, having reliable information is ba-sic for analyzing the host and not underestimating it or overestimating it.

ENRIquE SANChEzEnrique Sanchez is a member of the Accuvant LABS Enter-prise Attack and Penetration Testing team. Enrique has over 14 years of experience in Computer Security work-ing with industries including pharmaceutical, healthcare, bank, government, gaming and others. Enrique is a writ-er in various blogs such as question-defense.com and se-curity-dojo.com. His main interests range from reverse engineering, exploit creation, Artificial Intelligence, Neu-ral Networks and robotics to music, horses, video games and writing various technical papers.

Listing 18. hping sending udp packets to port 53 and port 111

root@fscking:~# hping --udp -n 192.168.132.2 -p 53 //We are sending UDP to port 53HPING 192.168.132.2 (eth1 192.168.132.2): udp mode set, 28 headers + 0 data bytesICMP Port Unreachable from ip=192.168.132.2ICMP Port Unreachable from ip=192.168.132.2ICMP Port Unreachable from ip=192.168.132.2ICMP Port Unreachable from ip=192.168.132.2ICMP Port Unreachable from ip=192.168.132.2

--- 192.168.132.2 hping statistic ---5 packets tramitted, 5 packets received, 0% packet lossround-trip min/avg/max = 0.0/0.0/0.0 msroot@fscking:~# hping --udp -n 192.168.132.2 -p 111HPING 192.168.132.2 (eth1 192.168.132.2): udp mode set, 28 headers + 0 data bytes


Listing 19. nmap doing a UDP scan

root@fscking:~# nmap -sU -n 192.168.132.2

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )Interesting ports on (192.168.132.2):(The 1467 ports scanned but not shown below are in state: closed)Port State Service111/udp open sunrpc

Nmap run completed -- 1 IP address (1 host up) scanned in 3 seconds

http://question-defense.com/

http://security-dojo.com/

http://security-dojo.com/

Documents

PENTESTING WITH TOOLS Network Scanning: the Basic t oolsfiles.accuvant.com/web/files/pentest_network_scanning_article.pdf · PENTESTING WITH TOOLS T his will allow the reader to have