2007
A HACKING ODYSSEY PART 2:
NETWORK SCANNING & NMAP CONTINUED...
4) FIN Scan –sF, Xmas-Tree Scan –sX and Null Scan –sN
So far we have not managed to scan a remote host in a way that is not
likely to leave log entries. We have initiated a connection in the
proper way and two thirds of the way and the ACK scan will not tell us
what ports are open. This is pretty useless to someone who needs to
know what ports are open but does not want to leave log entries, a.k.a.
an attacker.
Nmap includes a range of stealth scans; they are called stealth scans
as they do not open a connection to a remote host in a normal everyday
way. They violate the normal TCP protocol rules by sending unexpected
packets and packets that are meaningless to a remote host that does not
have a valid connection.
The first of these stealth scans is a FIN scan. This sends a packet to
a remote host with the FIN flag set. Normally the FIN flag would signal
the end of a connection and mark it to be reset, however if we have
never setup a valid connection with the remote host we have no need to
send a FIN packet.
The TCP protocol state that if an unexpected FIN packet arrives
destined to a closed port then a RST packet should be returned and if
an unexpected FIN packet arrives on an open port, then nothing should
be returned – the packet should be ignored.
Using these TCP connection rules Nmap is able to determine if a port is
open or closed by looking to see if a RST packet comes back or not – if
it does the port is closed, if it doesn’t the port is open.
It’s important to remember that a FIN scan will not work against a
Windows based hosts, as Microsoft do not follow the TCP rules
completely and their Operating Systems will return a RST packet in
response to a unsolicited FIN packet arriving on a closed or open port.
Hence Nmap will think that all ports are closed – however if you run a
–sT or a –sS scan on the same target and Nmap reports that there are
ports open, it is a safe assumption that you are scanning a Windows box
(this method was used a lot until Nmap OS detection was added and
improved) – it is worthwhile noting that some Cisco, HP and IRIX
equipment also respond to a unsolicited FIN packet in the same way as
Windows – there is also one extra little used use for this; if you are
scanning a web server that is behind a firewall and only permitting
traffic to port 80 and when you scan it with a SYN scan Nmap reports
the port as open but a FIN scan comes back as closed, then you know
there is a high chance of the web server running on a Windows based
machine just from this very quick and easy scan – a fact which can come
in very handy when trying to exploit the web server or perform SQL
injection.
The syntax for a FIN scan is: nmap –sF 80.80.80.80
5) Xmas Tree Scan –sX
The Xmas tree scan works in exactly the same way as the FIN scan except
that is sets the PSH (Push) and URG (urgent) flag in conjunction with
the FIN flag. This may get around some IDS/IPS setups. This scan still
has the same effect on the Windows OS as the FIN scan.
The syntax for a Xmas tree scan is: nmap –sX 80.80.80.80.
6) Null Scan
To follow on from the logical pattern we are using so far the Null scan
does the opposite of the Xmas tree scan and does not set any TCP
control bits at all. The TCP RFC dictates that a RST packet should be
sent from closed ports and an open port should drop the incoming packet
– in exactly the same way as the pervious two scans. Again this may
defeat some IDS/IPS setups and still has the same effect on Windows.
The syntax for a Null scan is: nmap –sN 80.80.80.80
We have run out of options for the TCP control bits now; we have tried
setting the SYN, SYN-ACK, FIN, FIN-URG-PSH TCP control bits and also
tried setting none of them. (You may notice that RST is missing, this
is because the TCP RFC says that a RST packet is responded to with a
RST packet regardless of if the port is open or closed, hence we would
be no more the wiser than before we started.)
Wouldn’t it be good if we could play with these TCP control bit’s
ourselves and create our own scan parameters to try and find miss
configurations in firewalls, IPS’s, Routers and packet filtering
devices? …..Well we can and it is very simple to do.
7) Customise your TCP packet
To customise out own TCP packets we use the ‘--scanflags’ option
followed by the TCP control bit(s) we want to set, such as:
Nmap --scanflags FINACKSYN 80.80.80.80.
This will obviously send TCP probes with the FIN, ACK and SYN flags
set. You can have some god results with poorly configured network
border security devices by using this option. It is an individual trial
and error technique though and one you should practise on your own
equipment so you can get to understand what works with what type of
configuration.
You can specify scan types to tell Nmap how to interpret the responses
it receives. By default it uses a –sS.
8) FTP Bounce scan
In my experience not a lot of people seem to know about the FTP Bounce
capabilities of Nmap. The FTP bounce feature exploits a very old
feature of FTP servers whereby a client that has connected to an FTP
Server can instruct it to send a file to a remote host other than the
machine the client is connecting from.
This feature was very useful in the early days when bandwidth and
connection speeds could be very low. Instead of having the file
transferred to your own machine over a very slow link, you could have
it transfer the file to a different machine you knew was using a faster
link than yourself.
However, with the advances in technology faster links are a lot more
common and bandwidth, or lack of bandwidth to be more exact, is not
sure a problem anymore. Due to this (and probably due to Nmap) more and
more FTP servers disable the File Forwarding feature and some even do
not have the feature available at all.
There are still some FTP server on the Internet that can be used for
this or if you manage to take over a remote FTP server that supports
File Forwarding you could turn it on and use it to commit your terrible
Nmap cyber crimes without bringing the forces of good to your own
doorstep.
It all works by Nmap sending a request to the FTP server and telling it
to send a file to X.X.X.X IP address on port X. If the FTP server comes
back and says that it was unable to establish a connection on that port
then Nmap will show the port as closed. If the FTP server is able to
make a connection on the specified port, it will come back as able to
establish a connection but unable to transfer the file – hence Nmap
will list the port as open.
The benefits of this are that in so far as the target machine (the one
you port scanned) all the connection attempts came from the FTP server.
For anyone to find out that it was in fact you port scanning the target
machine they would have to find the owner of the FTP server and ask him
to look through his logs – and if the admin of the FTP server is slack
enough to allow File Forwarding through his FTP server than chances are
he may not even keep logs..…
It can be time consuming to find an FTP server that allows File
Forwarding but if you do find one be sure to keep the IP Address to
yourself to ensure it stays configured that way for as long as
possible. If half the world starts using it for FTP Bounce scans pretty
soon the admin is going to figure out what is going on and configure it
correctly.
To find one, use the “-p” switch, this is a feature of Nmap which I
will cover later on that allows you to specify which port you want to
scan. Then chose a subnet and scan them all of port 21 (FTP). Once you
find some hosts listening on port 21 try and use them to conduct your
FTP Bounce scan…..if it works your in luck, if it doesn’t then you will
have to keep looking.
Nmap 123.123.123.0-255 –p21 – This will scan all hosts from
123.123.123.0 right through to 123.123.123.255 on port 21 only, looking
for a live FTP Server.
Once you have found an FTP server try connecting to it to see if it
allows Anonymous logons. (Use the user name ‘anonymous’ and anything
for the password). If it does you’re in look and can try an Nmap bounce
scan straight away. If it doesn’t allow anonymous logons you can either
try and find a valid user name and password with a program such as
Brutus or Hydra, or move on to another FTP server. I will cover how to
use Brutus in a separate paper.
Once you have found either a valid logon for an FTP server or one that
allows anonymous logons, use the following command to launch your FTP
Bounce scan:
nmap –b username:password@IP_of_FTP_server IP Address to scan
So:
nmap –b nokia:taz@123.123.123.123 80.80.80.80
Would logon to 123.123.123.123 with the user name of nokia, the
password of taz and then attempt to port scan 80.80.80.80
The following shows the result of a successful logon to an FTP Server
that I use for FTP Bounce scans
Code:
C:\Documents and Settings\Nokia>nmap -v -b
nokia:si£u31@X.X.X.X 81.80.80.80
Hint: if your bounce scan target hosts aren't reachable from here,
remember to u
se -P0 so we don't try and ping them prior to the scan
Starting Nmap 4.03 ( http://www.insecure.org/nmap ) at 2007-02-17 19:11
GMT Stan
dard Time
Resolved ftp bounce attack proxy to X.X.X.X (X.X.X.X).
DNS resolution of 1 IPs took 0.22s. Mode: Async [#: 1, OK: 0, NX: 1,
DR: 0, SF:
0, TR: 1, CN: 0]
Attempting connection to ftp://nokia:si£u31@X.X.X.X
Connected:220 ProFTPD 1.2.5rc1 Server (*******************0
Login credentials accepted by ftp server!
If Nmap manages to successfully logon to an FTP server but you receive
the following:
“Your ftp bounce server doesn't allow privileged ports, skipping them.”
It means the FTP server is configured to not send anything to ports
0-1024 less for port 20 & 21 – this was an early way of preventing
such things as Nmap from connecting to ‘well known’ ports except for 20
& 21 – which is mostly the only ports it will need to connect too
to send a file.
If your FTP Bounce server does not allow it to act as a proxy at all,
eventually you will get the message:
Quote:
Your ftp bounce server sucks, it won't let us feed bogus ports!
You may find more false positives with this type of scan than any other
for obvious reasons, so you should try and verify your results with
another type of scan if possible.
The mort astute of you and those that think for themselves rather than
blindly following a tutorial may have realised another use for this
type of scan.
The FTP server will more than likely be sitting on a LAN with a fully
routable internet IP address…….if we can find out the IP range in use
on the internal LAN we can use this method to port scan internal hosts
by specifying an internal IP at the end of the Nmap command, or even
try scanning 127.0.0.1 (localhost A.K.A itself). If you find port 80,
25 etc open the odds are that this could be acting as an FTP, Web and
Mail server - even though the external IP addresses maybe different for
these three services a firewall can translate them all to the same
internal host.
This method could be used as a long-winded ping seep method also – if
you can find out the internal IP range in use you can try a port scan
each host in that range and see what positives you get back. If you get
a positive back the host must be alive so you have the IP address of a
valid internal machine. The FTP server will usually be on a DMZ so
theoretically you can find the internal hosts of the DMZ, work out what
ports are open and try and tie these in with the external IP’s in use.
As mentioned in the previous paragraph if port 25 is open on an
internal host you know there is a mail server – if you have taken the
time to [url=
http://www.tazforum.thetazzone.com/viewtopic.php?t=5445]conduct a
reconnaissance [/url] then you will know the external IP for the mail
server….chances are you have just found the internal IP of it.
A lot of people write-off FTP bounce scans as being dated and useless
in today’s world, yet I do occasionally come across susceptible servers
during Pen testing and they can be a very good path into a network and
help you understand the topology better. If you happen to stumble upon
a susceptible public FTP server, be sure to keep it as quiet as
possible…..
Original Tutorial
by nokia for TheTAZZone-TAZForum
Originally posted on March 2nd, 2007 here
Do not use, republish, in whole or in part, without the consent of
the Author. TheTAZZone policy is that Authors retain the rights to the
work they submit and/or post...we do not sell, publish, transmit, or
have the right to give permission for such...TheTAZZone merely retains
the right to use, retain, and publish submitted work within it's
Network.