Multipart PortScanning Tutorial Part 7

Multipart PortScanning Tutorial Part 7

In this edition we will be looking at the results of some Xmas Tree scans.

Disclaimer: This information is for educational purposes only and not to commit a crime!
If you do something that causes you to hose your box don't come kicking and screaming on the forums!
All IP Address' MAC Address' etc. have been munged!

[b]
OK so first things first If you are not up to speed here are the other tutorials I have done on nmap.[/B]
[url="http://forums.remote-exploit.org/showthread.php?t=11001"]Part1[/url]
[URL="http://forums.remote-exploit.org/showthread.php?t=11003"]Part2[/URL]
[URL="http://forums.remote-exploit.org/showthread.php?t=11010"]Part3[/URL]
[URL="http://forums.remote-exploit.org/showthread.php?t=11025"]Part4[/URL]
[url="http://forums.remote-exploit.org/showthread.php?t=11216"]Part5[/url]
[url="http://forums.remote-exploit.org/showthread.php?t=14195]Part6[/url]

OK so let's look at what a Xmas Tree scan is.
[quote]Xmas scan (-sX)

Sets the FIN, PSH, and URG flags, lighting the packet up like a Christmas tree.
[b]From the nmap online documentation. [/b] [/quote]

So what does this mean?
Well for starters we know about the three-way handshake with TCP/IP. So what we are doing is sending packets out that have the "FIN", "PSH" and "URG" flags set.
So let's look at these flags. The first one "FIN" tells the target that we are finished with our connection. And normally it would send back and "ACK" Packet.
The second is the "PSH" or push packet. TCP designates data being sent to an application by using the "PSH" flag. To ensure that data sent from a node has been received TCP uses an "ACK" flag that specifies which "PSH" packets have been received. "ACK"s are sent in response to "PSH" data grams in two different scenarios:
1. When data has been received by a node.
2. When the "ACK" delay has been reached.
The third flag is the "URG" flag. The "URG" flag is used to tell a node that information needing immediate attention is present within a packet.
A "URG" also tells a receiving node that the sender requests all buffered data to be passed to the application. Normally TCP holds data in a memory buffer until enough is collected then it is passed to the application needing said data. With the "URG" flag TCP sends the data immediately. Ok so now might be a good idea to take a break!

Now that we know what the packets mean let's take a look at why this can be important to the pen-tester.

First when we do a Xmas tree scan and the target sends us a "RST" or reset packet then we know that a target port is closed. But if the target port is open then there will be silence. This is the same thing when doing a "FIN" scan. All of this takes place due to RFC 793 Transmission Control Protocol.
During a Xmas tree scan nmap categorizes the response as either closed or open|filtered. The open|filtered result is combined because firewalls often drop these packets. Because it's impossible to determine if a missing response was due to an open port or a filtered network connection, there's no way to tell the difference between an open or filtered port. Different implementations of the TCP/IP stack will handle these scans in different ways. Windows for example will reply with a "RST" regardless of the status of the port. If an open|filtered port is picked up then the node is not windows based. Special attention must be given when the results show all ports as closed as this may not be true.
Ok so now if you are still with me let's take a look at some scans.
First in the default mode with a look at the flags.
[code]
#nmap -sX -v -v 192.168.1.5 [/code]
-sX xmas tree scan
-v verbosity
[b] And our results. [/b]
[code]

Starting Nmap 4.62 ( http://nmap.org ) at 2008-05-01 13:30 EDT
Initiating ARP Ping Scan at 13:30
Scanning 192.168.1.5 [1 port]
Completed ARP Ping Scan at 13:30, 0.02s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 13:30
Completed Parallel DNS resolution of 1 host. at 13:30, 0.05s elapsed
Initiating XMAS Scan at 13:30
Scanning 192.168.1.5 [1715 ports]
Increasing send delay for 192.168.1.5 from 0 to 5 due to 21 out of 70 dropped probes since last increase.
Completed XMAS Scan at 13:30, 16.56s elapsed (1715 total ports)
Host 192.168.1.5 appears to be up ... good.
All 1715 scanned ports on 192.168.1.5 are closed
MAC Address: 00:12:34:56:AA:FF (Cisco-Linksys)
Read data files from: /usr/local/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 17.024 seconds
Raw packets sent: 1821 (72.842KB) | Rcvd: 1718 (79.024KB)
[/code]
As you can see we really didn't learn much about our target. The only thing that we learned is that the ports all appear to be closed.
But this is not really the case. I know that there are open ports because the target is actually a print server.

[b]This time lets look more in depth at our target.[/b]
[code]
#nmap -sV -v -v -F -sX -O 192.168.1.5
[/code]
-sV service version
-O Operating system
-F Only scan ports listed on services.

[b] Now the relevant results[/b]
[code] Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: storage-misc|printer
Running: Hotway embedded, IBM embedded, Packard Bell embedded
OS details: Hotway HDC-U2LA NAS device, IBM 6400 Printer (software version 7.0.9.6), Packard Bell NetStore 3500
OS Fingerprint:
Purposely removed [/code]
This time we can see that nmap returned us a print server. The device type is still incorrect. This can mean the difference between accessing the network and being shut out.
This print server like most usually have TCP ports 515, 631 open. There is usually one or two more like http or telnet open as well.

So we see that even though the two scans are not 100% accurate we did gain some valuable information about our target. Again a lot of devices will not respond to this type of scanning but there are some that will. Using the Xmas tree scan we can also help mask our intentions from a IDS. But remember most system administrators worth their weight in salt will ensure that there IDS's pick up this type of scan. There are ways around this as well.
Try playing with this type of scan and see what kind of results you get.

Drop a line if this has helped or hindered you.