Strategic Scanning and Assessments of Remote Hosts (SSARH)
Strategic Scanning and Assessments of Remote Hosts (SSARH)
Born on: 06.14.99
[Unix File]
INTRODUCTION:
This paper is being written for security administrators in hopes that they
will be able to notice security flaws in their networks and systems. Be it known that
this paper is NOT a hacking text and we will not go into the topic of compromise, but
this will show our target audience how to begin a strategic attack on a remote host.
We will cover basic assessment techniques involving open ports, RPC Services, open mount points,
and various ways to 'gain' information on your target before the actual attempt at compromise.
WHY:
I guess we need to get the obvious out of the way. Why attack a remote host is the first question you
should ask yourself (out of boredom is not a valid reason). I could probably go on and on about this but what
im trying to get you to ask yourself is 'IS IT WORTH COMPROMISING'? You need to look at the long term not the
short term affect. Gaining remote access to a government box or a 'high profile site' will carry some heavy penalties
if you are caught. So lets all think before we compromise.... ok? Be intelligent about your decisions please.
All examples given in this paper should be tested on a local network with permission from the powers that be.
BRIEFING:
Once you have found a remote host (target) that you would like to learn more about you are ready to move on.
Before we proceed with any technical information first let me define two types of attacks. A Passive attack is an
attack that does not 'touch' a targets network directly so you are not committed to follow through with the compromise
at that time. The next definition is the Active attack which does 'touch' the system and there is a very good
possibility that your tracks will be left in the logs therefore, you are then commited to following through with the
compromise to ensure that you are not found. Now lets move on to the more technical side of this file. First, I would
suggest checking out their webpage and snoop around to see if you can find any of the following:
1. Email addresses usually found at the bottom of a webpage as a contact.
2. Look for the 'OS' stamp on a webpage. Many admins/owners like to
display their love for their Operating System with little graphics such as 'Run on Linux',
'FreeBsd', 'Apache', 'IIS'..etc..etc
3. Does their website look 'professional'?
4. Do they provide any information about their network setup? (Yes, some are stupid enough
to provide network maps online.. duh!)
5. Do they provide an online X.500 query gateway online? This is where you can look up
email address's, phone numbers, and other various information about the users/employees of
the company, organization, and the server.
6. Do they provide an online telephone directory in which you type in
names of people and get phone numbers and locations (which is great for Social Engineering) or
visa-versa.
7. Anything else that would benefit in learning more about the remote host.
-Now that we have scanned over the web pages of a potential target we can then proceed
into the next phase of information gathering. Write down all of your notes on a piece of paper
or print them from file but I encourage you to never save these files to disk. If you do intend
to save these files to disk please make sure that you use the proper means to keep this
information secure (encryption). Now, lets take a look at the finger command.
The finger displays information about the system users. You can use this information for
login names for the system which is of great value when gathering information.
Here is an example of some output displayed when the finger command is envoked.
$ finger root@target.com (Active Attack)
[target.com]
Login Name TTY Idle When Where
root Super-User pts/0
$ finger -l root@target.com
[target.com]
Login name: root In real life: Super-User
Directory: / Shell: /bin/csh
Last login Mon Jul 19 13:42 on pts/0
No unread mail
No Plan.
-We see that including the '-l' flag will give us additional information about the users on
the target host.
-Now lets try placing a number before the '@' sign
$ finger 4@target.com
[target.com]
Login Name TTY Idle When Where
daemon ??? 04:51
bin ??? 05:45
sys ??? 08:54
RDoe ??? 04:34
$ finger -l 4@target.com
[target.com]
Login name: daemon
Directory: /
Never logged in.
No unread mail
No Plan.
Login name: bin
Directory: /usr/bin
Never logged in.
No unread mail
No Plan.
Login name: sys
Directory: /
Never logged in.
No unread mail
No Plan.
Login name: RDoe
Directory: /export/home/RDoe Shell: /bin/csh
Never logged in.
No unread mail
No Plan.
-Again, we see that adding the '-l' flag returns more data about the particular users of
the target host. Note that finger attempts may be logged in /var/log/messages (in Linux) and especially
if they have an IDS installed. A sample log would look similiar to the following:
Aug 2 05:21:25 erudite tcplog: finger connection attempt from 127.0.0.1
Also, finger runs on port 79/TCP and if the target host is not running the finger daemon then you will
not be able to use the finger query remotely to gather the information discussed above.
-We now have an easier account to compromise if we wish to do so. A users password will usually
be easier to compromise than a root password because many users do not know the importance of
an obscure password. The reason we obtain this information is because the finger command does
a pattern match on the number '4' and by process of elimination I would tend to guess that the
number '4' appears in the time field. You could also do the same thing with characters such as
the letter 'a' for example. So now that we have built up even more information about our target
host, lets dig deeper into the system and gather even more data.
-Next, lets look at the nslookup command and see if we can dig up even further information
on our target host. Nslookup is a program to query Internet domain name servers. Nslookup
has two modes: interactive and non-interactive. Interactive mode allows the user to query
name servers for information about various hosts and domains or to print a list of hosts in a
domain. Non-interactive mode is used to print just the name and requested information for a
host or domain. Here we will show examples of interactive and non-interactive modes.
$ nslookup target.com (Passive Attack)
Server: blah.yourhost.com
Address: 127.0.0.1
Non-authoritative answer:
Name: target.com
Address: 127.0.0.2
-In Non-interactive mode we simply do [nslookup [target host]] and are returned with the name
of the host and its designated IP address. The following is a demonstration of Interactive
mode and its associated flags.
A the host's Internet address.
CNAME the canonical name for an alias.
HINFO the host CPU and operating system type.
MINFO the mailbox or mail list information.
MX the mail exchanger.
NS the name server for the named zone.
PTR the host name if the query is an Internet ad-
dress; otherwise, the pointer to other infor-
mation.
SOA the domain's ``start-of-authority'' informa-
tion.
TXT the text information.
UINFO the user information.
WKS the supported well-known services.
-To execute nslookup in Interactive mode using the above flags, do the following:
1. Type the command nslookup
$ nslookup
Default Server: blah.yourhost.com
Address: 127.0.0.1
>
2. Set your flags by using [set type=[flag]]
> set type=mx [Here we are using the 'MX' flag or the 'Mail Exchanger' flag]
>
3. Type in the target hostname [i.e. target.com]
> target.com
Server: blah.yourhost.com
Address: 127.0.0.1
Non-authoritative answer:
target.com preference = 10, mail exchanger = mail.target.com
Authoritative answers can be found from:
target.com nameserver = ns1.upstream.com
target.com nameserver = ns2.upstream.com
mail.target.com internet address = 127.0.0.2
ns1.upstream.com internet address = 127.0.0.3
ns2.upstream.com internet address = 127.0.0.4
-Look at all this information we receive! We now know the nameserver this target uses, their
upstream provider, and the name of their mail server. As an exercise, try setting the type to
'any' by using the following syntax [set type=any]. See how much 'more' information you can
extract from each and every flag.
-We can now move on to the DiG command or Domain Information Groper. The DiG command is used similarly
to the nslookup command as both send domain name query packets to nameservers. Here we will show you an
example of simple interactive mode which may give you similar data that you had obtained using the nslookup
command, but DiG may return the slightly different data in a slightly different format. To use DiG, issue the
command as follows [dig [target.com]]:
$ dig target.com (Passive Attack)
; <<>> DiG 8.1 <<>> target.com
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;; target.com, type = A, class = IN
;; ANSWER SECTION:
target.com. 9h51m25s IN A 127.0.0.2
;; AUTHORITY SECTION:
target.com. 8h53m50s IN NS dns.upstream.com.
target.com. 8h53m50s IN NS www.upstream.com.
;; ADDITIONAL SECTION:
dns.upstream.com. 9h51m25s IN A 127.0.0.3
www.upstream.com. 9h51m25s IN A 127.0.0.60
;; Total query time: 37 msec
;; FROM: yourmachinename to SERVER: default -- 127.0.0.3
;; WHEN: Mon Aug 2 05:25:16 1999
;; MSG SIZE sent: 28 rcvd: 119
-The only new information we get is the web URL for the upstream provider of this particular target machine.
Also, if you look closer you will see that various times are reported also as is the indication that the target
is an internet domain class. I am partial to nslookup due to the functionality and ease of use.
[man dig for more options regarding the DiG command]
-We will now move on to the whois command which is the TCP/IP Internet user name directory service.
whois searches for an TCP/IP directory entry for an identifier. You can obtain a considerable amount of
information using this simple command. For this command, use the following syntax [whois [target host]]:
$ whois target.com (Passive Attack)
TARGET.COM (TARGET5-DOM)
0000 Junk Street
Lost Wages, WA 00000
US
Domain Name: TARGET.COM
Administrative Contact, Technical Contact, Zone Contact:
wah, chung (LC0000) somepoorsoul@TARGET.COM
000-000-0000 (FAX) private
Billing Contact:
wah, chung (LC0000) somepoorsoul@TARGET.COM
000-000-0000 (FAX) private
Record last updated on 12-Apr-99.
Record created on 12-Feb-99.
Database last updated on 2-Aug-99 04:09:46 EDT.
Domain servers in listed order:
DNS.UPSTREAM.COM 127.0.0.3
DNS2.UPSTREAM.COM 127.0.0.4
-We now have a technical contact with name, email address, phone number, and sometimes fax number when it is not
marked 'private'. The technical contact and number can be of great use when social engineering. Take this time
to put all of the information we have thus far on a sheet of paper and you will see that we know a lot about this
target host now, but in a few moments we will learn a great deal more as we now lead you into the rpcinfo command.
-The rpcinfo command reports RPC information on a particular host. rpcinfo makes an RPC call to an RPC server and
reports what it finds. Many RPC services are vulnerable to a number of different attacks. Take the ttdbserver exploit
for instance, due to a bug in the source we could write and manipulate any file on the server it is running on remotely
because this particular program is run as 'root'. If the portmapper is not running on the remote target host then we
should receive something along the lines of 'rpcinfo: can't contact portmapper: RPC: Remote system error - Connection refused'. The
reason we receive this error is because we are trying to get a listing of RPC services via the portmapper which isn't running
on this particular host. If we do successfully contact the portmapper we should get an output as follows. To use the
rpcinfo command we would use the following syntax [rpcinfo -p [target host]]:
$ rpcinfo -p www.target.com (Active Attack)
program vers proto port
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100024 1 udp 808 status
100024 1 tcp 810 status
100021 1 udp 2049 nlockmgr
100021 3 udp 2049 nlockmgr
100021 4 udp 2049 nlockmgr
100021 1 tcp 2049 nlockmgr
100021 3 tcp 2049 nlockmgr
100021 4 tcp 2049 nlockmgr
100005 1 tcp 1058 mountd
100005 1 udp 1036 mountd
391004 1 tcp 1063
391004 1 udp 1037
100001 1 udp 1038 rstatd
100001 2 udp 1038 rstatd
100001 3 udp 1038 rstatd
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100024 1 udp 808 status
100024 1 tcp 810 status
100021 1 udp 2049 nlockmgr
100021 3 udp 2049 nlockmgr
100021 4 udp 2049 nlockmgr
100021 1 tcp 2049 nlockmgr
100021 3 tcp 2049 nlockmgr
100021 4 tcp 2049 nlockmgr
100005 1 tcp 1058 mountd
100005 1 udp 1036 mountd
391004 1 tcp 1063
391004 1 udp 1037
100001 1 udp 1038 rstatd
100001 2 udp 1038 rstatd
100001 3 udp 1038 rstatd
391002 1 tcp 1070
100083 1 tcp 1073
-I won't go into all the technical details here, but the listing shown here would be a goldmine for any hacker.
We see above that program '100083' is running, but the service isn't listed. The ttdbserver runs as program
'100083' so we could have a vulnerable system on our hands. There are several other things to check here such as
nfs, nlock, mountd, and rstatd. We will not go into how to exploit these services, but we want to teach you how to
compile information on a remote target for a well-thought-out, calculated, time-sensitive audit.
-We will now move on to open mount points or better known as an exported list. Showmount shows mount information for
an NFS server. showmount queries the mount daemon on a remote host for information about the state of
the NFS server on that machine. If you do not include an option with the showmount command you will receive a list
of clients who are mounting from that host. We usually use the '-e' option which is the 'export option' and is a great
way to find 'anonymous' mounting permissions on remote hosts. To use the showmount command with the 'export option' use the
following syntax [showmount -e [target host]]. Note that if the mountd daemon is not listed in the RPC services we will not
be able to use showmount on that particular target host:
$ showmount -e www.target.com (Active Attack)
Export list for www.target.com:
/ (anonymous)
-As you can see that the root directory or '/' is allowed to be mounted by anybody with a connection to the internet and
a *NIX box. This is probably due to a misconfigured NFS server. All we would need to do is mount this system and we would
have full control to edit the /etc/passwd and /etc/shadow files not to mention any other file on this particular target
host. As an exercise, on your own system, try mounting an anonymous exported listing by using the following command:
$ mount -t nfs www.yourhost.com:/ /mnt
-This will give you full control over your own box anonymously. Now perform the command [cd /mnt] and you should be in
your boxs' root directory. Now perform the following command [ls -al]. If all went according to plan you should see a
listing of the files and directories in the root directory. There are several other tasks we could accomplish once inside
but, we will leave that up to the imagination of the reader.
-Now lets take a look at a traceroute to the target host. Traceroute prints the route packets take to a network host.
This will also alert us to any firewalls that stand in our way to the target host (usually indicated with a '*').
Note that the only mandatory parameter is the destination host name or IP number. The default probe datagram length
is 38 bytes, but this may be increased by specifying a packet size (in bytes) after the destination host name.
To initialize a traceroute use the following syntax as well as the man pages [traceroute [target host]]
$ traceroute www.target.com (Active Attack)
traceroute to www.target.com (127.0.0.2), 30 hops max, 40 byte packets
1 rsm1.yourhost.com (127.0.0.8) 0.791 ms 0.703 ms 0.704 ms
2 bigdog-gw.yourhost.com (127.0.0.9) 0.592 ms 0.551 ms 0.405 ms
3 1.atm8-0-0.umab-gw.net.ums.edu (131.118.255.129) 1.422 ms 1.020 ms 1.349
ms
4 206.181.226.97 (206.181.226.97) 51.923 ms 52.127 ms 69.832 ms
5 dca1-core3-h4-0.atlas.digex.net (165.117.51.70) 75.446 ms 66.744 ms 71.79
1 ms
6 dca1-core7-fa6-0-0.atlas.digex.net (165.117.16.7) 79.978 ms 79.756 ms 77.
974 ms
7 dca1-core9-pos1-1.atlas.digex.net (165.117.59.89) 69.804 ms 82.369 ms 81.
144 ms
8 atl1-core5-pos1-3.atlas.digex.net (165.117.51.145) 86.819 ms 78.657 ms 52
.745 ms
9 atl1-core3-pos4-0-0.atlas.digex.net (165.117.59.74) 40.033 ms 63.228 ms 6
8.938 ms
10 atl1-core1-fa3-0-0.atlas.digex.net (165.117.61.21) 78.620 ms 86.860 ms 98
.448 ms
11 500.Hssi11-1-0.GW1.ATL1.ALTER.NET (137.39.140.21) 105.357 ms 89.566 ms 11
6.460 ms
12 104.ATM3-0.XR2.ATL1.ALTER.NET (146.188.232.54) 121.399 ms 106.549 ms 139.
801 ms
13 294.ATM3-0.TR2.ATL1.ALTER.NET (146.188.232.110) 124.997 ms 129.528 ms 110
.989 ms
14 109.ATM6-0.TR2.LAX2.ALTER.NET (146.188.136.54) 201.188 ms 159.915 ms 215.
266 ms
15 198.ATM7-0.XR2.LAX2.ALTER.NET (146.188.248.133) 185.642 ms 142.192 ms 140
.496 ms
16 194.ATM9-0-0.GW1.PHX1.ALTER.NET (146.188.249.125) 158.889 ms 148.169 ms 1
37.867 ms
17 yourtargetsupstream-gw.customer.ALTER.NET (157.130.224.94) 153.436 ms 94.951 ms 140.0
85 ms
18 * * *
19 * * *
-As you can see from this traceroute data that we are looking at a box that resides somewhere in the Phoenix
Arizona area and most likely has some sort of packet filtering device before we reach our remote target indicated
by the '* * *'(hops 18 & 19). We also get information of what 'path' we take to get to our desired target host along with
the hop number for each path taken. Sometimes it may be easier to compromise an upstream and sniff the traffic to compromise
the target host. We can get away with a 'full' traceroute by using a technique known as 'Firewalking' (http://www.packetfactory.net/firewalk).
Firewalking is a technique developed by MDS and DHG that employs traceroute-like techniques to analyze IP packet responses to
determine gateway ACL filters and map networks. Firewalk the tool employs the technique to determine the filter rules
in place on a packet forwarding device. Also, we will be discussing spoofed packets to 'pierce' firewalls as a means to
portscan a machine on an internal network.
-For the remainder of this file we will be discussing portscanning. Portscanning has become one of the key auditing and
recon techniques amongst hackers today. There are a variety of portscanning utilities on the internet ranging from your
basic sequential portscanner to scanners that will bounce scans off of other hosts as an attempt to hide the origination of the scan.
The scanner that will be used in this file is a very versitile scanner called Nmap (http://www.insecure.org/nmap). Nmap is a utility
for network exploration or security auditing. It supports ping scanning (determine which hosts are up), many port scanning
techniques (determine what services the hosts are offering), and TCP/IP fingerprinting (remote host operating system
identification). Nmap also offers flexible target and port specification, decoy scanning, determination of TCP sequence
predictability characteristics, reverse-identd scanning, and more (try [man nmap] for more details). Lets take a look
at some of the flags we can use with Nmap along with the data that we obtain with each flag. First try just typing in the
command 'nmap' so you can see how to use the application.
nmap V. 2.12 usage: nmap [Scan Type(s)] [Options] [host or net #1 ... [#N]]
-Here we have version number of the program and its usage.
-sT TCP connect() scan: This is the most basic form of
TCP scanning. Establishes a full TCP connection with each port.
Considered to be a "noisy" scan because it leaves a lot of evidence
in the logs.
$ nmap -sT target.com (Active Attack)
Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on target.com (127.0.0.2):
Port State Protocol Service
1 open tcp tcpmux
11 open tcp systat
15 open tcp netstat
22 open tcp ssh
25 open tcp smtp
79 open tcp finger
80 open tcp http
110 open tcp pop-3
113 open tcp auth
119 open tcp nntp
143 open tcp imap2
443 open tcp https
515 open tcp printer
540 open tcp uucp
2000 open tcp callbook
6667 open tcp irc
12345 open tcp NetBus
Nmap run completed -- 1 IP address (1 host up) scanned in 15 seconds
-The output that we receive from the TCP scan is very interesting yet, will be very noisey in the logs. Any clued admin
will see this as an attempt to gather information for a future attempt at compromise. Seeing that we are doing an assessment,
this method will suffice and does a wonderful job at identifying open ports. We also receive a confirmation that Nmap has
completed its run along with how many IP address's it scanned and how fast it scanned them. Before we continue on to the other
features of Nmap lets assess this situation and make some sense of what we have here as far as data is concerned. There are
several services that could be vulnerable to outside attack but, it is up to you to determine which services are vulnerable
and how to compromise each particular service. Lets take smtp (port 25) for instance, we need to determine what mail service
this target host is running and which version of that particular package they are running. To do this, simply telnet to that
port and read its header using the following command [telnet [target host] [port]]:
$ telnet www.target.com 25 (Active Attack)
220 target.com ESMTP Sendmail 9.1.12a/9.1.12a/punk-beta; Tue, 10 Aug 1999 08:44:03 -0700
-As you can see here this admin was clever enough to 'spoof' the version of Sendmail he is running. He did this by editing
the config file for Sendmail which (when done properly) can hide the version number which is a key element for attacking this
particular service for many versions of Sendmail are exploitable remotely to gain root access. Again, remember to make note
of each header and its respected data for they are valuble parts that make up this entire 'puzzle'. While we are on the
smtp service try out the help command by simply typing 'help'.
help
214-This is Sendmail version 9.1.12a
214-Topics:
214- HELO EHLO MAIL RCPT DATA
214- RSET NOOP QUIT HELP VRFY
214- EXPN VERB ETRN DSN
214-For more info use "HELP ".
214-To report bugs in the implementation send email to
214- sendmail-bugs@sendmail.org.
214-For local information send email to Postmaster at your site.
214 End of HELP info
-You can now try different commands listed in the topics area. Try [HELP [topic]] to see further help on a particular topic.
For an exercise, try doing a 'verify' (VRFY) on one of the users on the system, try root. We will let you figure the command out
on your own so that you get into the 'learn it on your own' frame of mind. Remember, when you are trying these exercises out
please do them on your own system or have the permission of the owner before you try any of these commands out.
-Now that we have gone over a brief description of the TCP scan lets move on to a more 'stealthy' way of scanning a remote
host.
-sS TCP SYN scan: This technique is often referred to
as "half-open" scanning, because you don't open a
full TCP connection.
1. Sends SYN packet as if establishing a 3-way handshake
2. Waits for SYN/ACK from destination
If SYN/ACK is received then the port is open
If RST (reset) is received then the port is closed
3. Rather than send ACK to establish connection, immediatley RST (reset) to
close connection.
$ nmap -sS www.target.com
Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on target.com (127.0.0.2):
Port State Protocol Service
1 open tcp tcpmux
11 open tcp systat
15 open tcp netstat
22 open tcp ssh
25 open tcp smtp
79 open tcp finger
80 open tcp http
110 open tcp pop-3
113 open tcp auth
119 open tcp nntp
143 open tcp imap2
443 open tcp https
515 open tcp printer
540 open tcp uucp
2000 open tcp callbook
6667 open tcp irc
12345 open tcp NetBus
Nmap run completed -- 1 IP address (1 host up) scanned in 17 seconds
-Here we have the same ports open as before but, this time the identity of the account scanning this host is not given away.
The reason this happens is because we never establish a full connection or 'Three-way handshake'. As soon as the SYN/ACK
is received from the destination, rather than send an ACK to establish a connection we immediatley send a RST or 'reset' to
close the connection therefore, the identity is never known (this is assuming that the target host is not running any
extended logging features).
-Now we have a pretty good understanding of what services are running on this particular target host. Now, lets take a look
at OS detection and the concepts of OS Fingerprinting. There is a great paper on OS Fingerprinting by Fyodor at
http://www.insecure.org/nmap/nmap-fingerprinting-article.html. In this example we will show you how to use Nmap
to detect the OS of our remote target.
-O This option activates remote host identification
via TCP/IP fingerprinting.
1) Takes advantage of nuances found in each OS's TCP/IP stack to determine what OS
that remote host is running.
2) Sends specifically crafted packets to a host.
3) This information is used to generate a "fingerprint" which is then used to match
from a database of known OS fingerprints.
$ nmap -O www.target.com
Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on localhost (127.0.0.1):
Port State Protocol Service
1 open tcp tcpmux
11 open tcp systat
15 open tcp netstat
21 open tcp ftp
22 open tcp ssh
25 open tcp smtp
79 open tcp finger
80 open tcp http
110 open tcp pop-3
113 open tcp auth
119 open tcp nntp
143 open tcp imap2
443 open tcp https
515 open tcp printer
540 open tcp uucp
2000 open tcp callbook
6667 open tcp irc
12345 open tcp NetBus
TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)
Remote operating system guess: Linux 2.0.32-34
Nmap run completed -- 1 IP address (1 host up) scanned in 15 seconds
-The output of data that we see here are the same services as the previous examples except that we now know the OS of
the remote target. This target is running Linux 2.0.32-34 and the TCP Sequence Prediction for Trusted Relationship
Exploitation or any other HiJacking method is truly random and would be VERY difficult to predict the sequence. Now if
we must use a script to compromise we now know what operating system we are looking at.
-The final two scans we will discuss briefly are Ping Scanning and UDP Scanning. TCP Ping Scanning is used to determine
which hosts are up on a network. UDP scanning is a method used to determine which UDP (User Datagram Protocol, RFC 768) ports
are open on a host. UDP scanning takes longer due to RFC 1812 section 4.3.2.8 and its limiting the ICMP error message rate.
-PT Use TCP "ping" to determine what hosts are up.
Instead of sending ICMP echo request packets and
waiting for a response, we send out TCP ACK packets
throughout the target network (or to a single
machine) and then wait for responses to return
Hosts that are up should respond with a RST.
* To set the destination port:
-PT
* The default port is 80
-sU UDP scans: This method is used to determine which
UDP (User Datagram Protocol, RFC 768) ports are
open on a host. Sends a 0 byte UDP packet to each port on the
target machine. If we receive an ICMP port unreachable message, then
the port is closed.
Some services that may be found with UDP scanning:
*BO cDc's backdoor program that hides on a configurable UDP port on Win machines
*snmp
*tftp
*NFS
*and others...
-We won't be showing output from these scans. Rather, we ask you to perform the above flags
as an exercise for yourself. Now that you have completed this basic auditing paper you should
take all the information learned here and apply it to one conclusive paper and then begin your
compromise.
CONCLUSION:
In conclusion, we have discussed the basics to auditing a remote host or target host.
Knowing the security of your own network is key to being able to defend your network from
malicious intent. The techniques described here are basic techniques used to gather information
on the remote target before compromise. Look for further papers from the ATTRITION staff on
Penetration and Auditing of systems.
GENERAL INFORMATION:
ATTRITION Security: http://www.attrition.org/security/newbie
Nmap Security Scanner: http://www.insecure.org/nmap
Whitepapers & Publications: http://www.enteract.com/~lspitz/pubs.html
Security Focus: http://www.securityfocus.com/
Packet Factory (Firewalk): http://www.packetfactory.net/
CONTRIBUTIONS:
Email all Contributions/Suggestions/Feedback to modify@attrition.org
ACKNOWLEDGMENTS:
The following individuals helped in either review, technical input, or in some other fashion.
Brian Martin, Dale Coddington, Jay D. Dyson, and Jeremy Rauch
modify@attrition.org
(c) copyright 1998, 1999 Karl Lynn
reference : http://www.unixgeeks.org/security/newbie/pen/ssarh.html
Born on: 06.14.99
[Unix File]
INTRODUCTION:
This paper is being written for security administrators in hopes that they
will be able to notice security flaws in their networks and systems. Be it known that
this paper is NOT a hacking text and we will not go into the topic of compromise, but
this will show our target audience how to begin a strategic attack on a remote host.
We will cover basic assessment techniques involving open ports, RPC Services, open mount points,
and various ways to 'gain' information on your target before the actual attempt at compromise.
WHY:
I guess we need to get the obvious out of the way. Why attack a remote host is the first question you
should ask yourself (out of boredom is not a valid reason). I could probably go on and on about this but what
im trying to get you to ask yourself is 'IS IT WORTH COMPROMISING'? You need to look at the long term not the
short term affect. Gaining remote access to a government box or a 'high profile site' will carry some heavy penalties
if you are caught. So lets all think before we compromise.... ok? Be intelligent about your decisions please.
All examples given in this paper should be tested on a local network with permission from the powers that be.
BRIEFING:
Once you have found a remote host (target) that you would like to learn more about you are ready to move on.
Before we proceed with any technical information first let me define two types of attacks. A Passive attack is an
attack that does not 'touch' a targets network directly so you are not committed to follow through with the compromise
at that time. The next definition is the Active attack which does 'touch' the system and there is a very good
possibility that your tracks will be left in the logs therefore, you are then commited to following through with the
compromise to ensure that you are not found. Now lets move on to the more technical side of this file. First, I would
suggest checking out their webpage and snoop around to see if you can find any of the following:
1. Email addresses usually found at the bottom of a webpage as a contact.
2. Look for the 'OS' stamp on a webpage. Many admins/owners like to
display their love for their Operating System with little graphics such as 'Run on Linux',
'FreeBsd', 'Apache', 'IIS'..etc..etc
3. Does their website look 'professional'?
4. Do they provide any information about their network setup? (Yes, some are stupid enough
to provide network maps online.. duh!)
5. Do they provide an online X.500 query gateway online? This is where you can look up
email address's, phone numbers, and other various information about the users/employees of
the company, organization, and the server.
6. Do they provide an online telephone directory in which you type in
names of people and get phone numbers and locations (which is great for Social Engineering) or
visa-versa.
7. Anything else that would benefit in learning more about the remote host.
-Now that we have scanned over the web pages of a potential target we can then proceed
into the next phase of information gathering. Write down all of your notes on a piece of paper
or print them from file but I encourage you to never save these files to disk. If you do intend
to save these files to disk please make sure that you use the proper means to keep this
information secure (encryption). Now, lets take a look at the finger command.
The finger displays information about the system users. You can use this information for
login names for the system which is of great value when gathering information.
Here is an example of some output displayed when the finger command is envoked.
$ finger root@target.com (Active Attack)
[target.com]
Login Name TTY Idle When Where
root Super-User pts/0
$ finger -l root@target.com
[target.com]
Login name: root In real life: Super-User
Directory: / Shell: /bin/csh
Last login Mon Jul 19 13:42 on pts/0
No unread mail
No Plan.
-We see that including the '-l' flag will give us additional information about the users on
the target host.
-Now lets try placing a number before the '@' sign
$ finger 4@target.com
[target.com]
Login Name TTY Idle When Where
daemon ??? 04:51
bin ??? 05:45
sys ??? 08:54
RDoe ??? 04:34
$ finger -l 4@target.com
[target.com]
Login name: daemon
Directory: /
Never logged in.
No unread mail
No Plan.
Login name: bin
Directory: /usr/bin
Never logged in.
No unread mail
No Plan.
Login name: sys
Directory: /
Never logged in.
No unread mail
No Plan.
Login name: RDoe
Directory: /export/home/RDoe Shell: /bin/csh
Never logged in.
No unread mail
No Plan.
-Again, we see that adding the '-l' flag returns more data about the particular users of
the target host. Note that finger attempts may be logged in /var/log/messages (in Linux) and especially
if they have an IDS installed. A sample log would look similiar to the following:
Aug 2 05:21:25 erudite tcplog: finger connection attempt from 127.0.0.1
Also, finger runs on port 79/TCP and if the target host is not running the finger daemon then you will
not be able to use the finger query remotely to gather the information discussed above.
-We now have an easier account to compromise if we wish to do so. A users password will usually
be easier to compromise than a root password because many users do not know the importance of
an obscure password. The reason we obtain this information is because the finger command does
a pattern match on the number '4' and by process of elimination I would tend to guess that the
number '4' appears in the time field. You could also do the same thing with characters such as
the letter 'a' for example. So now that we have built up even more information about our target
host, lets dig deeper into the system and gather even more data.
-Next, lets look at the nslookup command and see if we can dig up even further information
on our target host. Nslookup is a program to query Internet domain name servers. Nslookup
has two modes: interactive and non-interactive. Interactive mode allows the user to query
name servers for information about various hosts and domains or to print a list of hosts in a
domain. Non-interactive mode is used to print just the name and requested information for a
host or domain. Here we will show examples of interactive and non-interactive modes.
$ nslookup target.com (Passive Attack)
Server: blah.yourhost.com
Address: 127.0.0.1
Non-authoritative answer:
Name: target.com
Address: 127.0.0.2
-In Non-interactive mode we simply do [nslookup [target host]] and are returned with the name
of the host and its designated IP address. The following is a demonstration of Interactive
mode and its associated flags.
A the host's Internet address.
CNAME the canonical name for an alias.
HINFO the host CPU and operating system type.
MINFO the mailbox or mail list information.
MX the mail exchanger.
NS the name server for the named zone.
PTR the host name if the query is an Internet ad-
dress; otherwise, the pointer to other infor-
mation.
SOA the domain's ``start-of-authority'' informa-
tion.
TXT the text information.
UINFO the user information.
WKS the supported well-known services.
-To execute nslookup in Interactive mode using the above flags, do the following:
1. Type the command nslookup
$ nslookup
Default Server: blah.yourhost.com
Address: 127.0.0.1
>
2. Set your flags by using [set type=[flag]]
> set type=mx [Here we are using the 'MX' flag or the 'Mail Exchanger' flag]
>
3. Type in the target hostname [i.e. target.com]
> target.com
Server: blah.yourhost.com
Address: 127.0.0.1
Non-authoritative answer:
target.com preference = 10, mail exchanger = mail.target.com
Authoritative answers can be found from:
target.com nameserver = ns1.upstream.com
target.com nameserver = ns2.upstream.com
mail.target.com internet address = 127.0.0.2
ns1.upstream.com internet address = 127.0.0.3
ns2.upstream.com internet address = 127.0.0.4
-Look at all this information we receive! We now know the nameserver this target uses, their
upstream provider, and the name of their mail server. As an exercise, try setting the type to
'any' by using the following syntax [set type=any]. See how much 'more' information you can
extract from each and every flag.
-We can now move on to the DiG command or Domain Information Groper. The DiG command is used similarly
to the nslookup command as both send domain name query packets to nameservers. Here we will show you an
example of simple interactive mode which may give you similar data that you had obtained using the nslookup
command, but DiG may return the slightly different data in a slightly different format. To use DiG, issue the
command as follows [dig [target.com]]:
$ dig target.com (Passive Attack)
; <<>> DiG 8.1 <<>> target.com
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;; target.com, type = A, class = IN
;; ANSWER SECTION:
target.com. 9h51m25s IN A 127.0.0.2
;; AUTHORITY SECTION:
target.com. 8h53m50s IN NS dns.upstream.com.
target.com. 8h53m50s IN NS www.upstream.com.
;; ADDITIONAL SECTION:
dns.upstream.com. 9h51m25s IN A 127.0.0.3
www.upstream.com. 9h51m25s IN A 127.0.0.60
;; Total query time: 37 msec
;; FROM: yourmachinename to SERVER: default -- 127.0.0.3
;; WHEN: Mon Aug 2 05:25:16 1999
;; MSG SIZE sent: 28 rcvd: 119
-The only new information we get is the web URL for the upstream provider of this particular target machine.
Also, if you look closer you will see that various times are reported also as is the indication that the target
is an internet domain class. I am partial to nslookup due to the functionality and ease of use.
[man dig for more options regarding the DiG command]
-We will now move on to the whois command which is the TCP/IP Internet user name directory service.
whois searches for an TCP/IP directory entry for an identifier. You can obtain a considerable amount of
information using this simple command. For this command, use the following syntax [whois [target host]]:
$ whois target.com (Passive Attack)
TARGET.COM (TARGET5-DOM)
0000 Junk Street
Lost Wages, WA 00000
US
Domain Name: TARGET.COM
Administrative Contact, Technical Contact, Zone Contact:
wah, chung (LC0000) somepoorsoul@TARGET.COM
000-000-0000 (FAX) private
Billing Contact:
wah, chung (LC0000) somepoorsoul@TARGET.COM
000-000-0000 (FAX) private
Record last updated on 12-Apr-99.
Record created on 12-Feb-99.
Database last updated on 2-Aug-99 04:09:46 EDT.
Domain servers in listed order:
DNS.UPSTREAM.COM 127.0.0.3
DNS2.UPSTREAM.COM 127.0.0.4
-We now have a technical contact with name, email address, phone number, and sometimes fax number when it is not
marked 'private'. The technical contact and number can be of great use when social engineering. Take this time
to put all of the information we have thus far on a sheet of paper and you will see that we know a lot about this
target host now, but in a few moments we will learn a great deal more as we now lead you into the rpcinfo command.
-The rpcinfo command reports RPC information on a particular host. rpcinfo makes an RPC call to an RPC server and
reports what it finds. Many RPC services are vulnerable to a number of different attacks. Take the ttdbserver exploit
for instance, due to a bug in the source we could write and manipulate any file on the server it is running on remotely
because this particular program is run as 'root'. If the portmapper is not running on the remote target host then we
should receive something along the lines of 'rpcinfo: can't contact portmapper: RPC: Remote system error - Connection refused'. The
reason we receive this error is because we are trying to get a listing of RPC services via the portmapper which isn't running
on this particular host. If we do successfully contact the portmapper we should get an output as follows. To use the
rpcinfo command we would use the following syntax [rpcinfo -p [target host]]:
$ rpcinfo -p www.target.com (Active Attack)
program vers proto port
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100024 1 udp 808 status
100024 1 tcp 810 status
100021 1 udp 2049 nlockmgr
100021 3 udp 2049 nlockmgr
100021 4 udp 2049 nlockmgr
100021 1 tcp 2049 nlockmgr
100021 3 tcp 2049 nlockmgr
100021 4 tcp 2049 nlockmgr
100005 1 tcp 1058 mountd
100005 1 udp 1036 mountd
391004 1 tcp 1063
391004 1 udp 1037
100001 1 udp 1038 rstatd
100001 2 udp 1038 rstatd
100001 3 udp 1038 rstatd
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100024 1 udp 808 status
100024 1 tcp 810 status
100021 1 udp 2049 nlockmgr
100021 3 udp 2049 nlockmgr
100021 4 udp 2049 nlockmgr
100021 1 tcp 2049 nlockmgr
100021 3 tcp 2049 nlockmgr
100021 4 tcp 2049 nlockmgr
100005 1 tcp 1058 mountd
100005 1 udp 1036 mountd
391004 1 tcp 1063
391004 1 udp 1037
100001 1 udp 1038 rstatd
100001 2 udp 1038 rstatd
100001 3 udp 1038 rstatd
391002 1 tcp 1070
100083 1 tcp 1073
-I won't go into all the technical details here, but the listing shown here would be a goldmine for any hacker.
We see above that program '100083' is running, but the service isn't listed. The ttdbserver runs as program
'100083' so we could have a vulnerable system on our hands. There are several other things to check here such as
nfs, nlock, mountd, and rstatd. We will not go into how to exploit these services, but we want to teach you how to
compile information on a remote target for a well-thought-out, calculated, time-sensitive audit.
-We will now move on to open mount points or better known as an exported list. Showmount shows mount information for
an NFS server. showmount queries the mount daemon on a remote host for information about the state of
the NFS server on that machine. If you do not include an option with the showmount command you will receive a list
of clients who are mounting from that host. We usually use the '-e' option which is the 'export option' and is a great
way to find 'anonymous' mounting permissions on remote hosts. To use the showmount command with the 'export option' use the
following syntax [showmount -e [target host]]. Note that if the mountd daemon is not listed in the RPC services we will not
be able to use showmount on that particular target host:
$ showmount -e www.target.com (Active Attack)
Export list for www.target.com:
/ (anonymous)
-As you can see that the root directory or '/' is allowed to be mounted by anybody with a connection to the internet and
a *NIX box. This is probably due to a misconfigured NFS server. All we would need to do is mount this system and we would
have full control to edit the /etc/passwd and /etc/shadow files not to mention any other file on this particular target
host. As an exercise, on your own system, try mounting an anonymous exported listing by using the following command:
$ mount -t nfs www.yourhost.com:/ /mnt
-This will give you full control over your own box anonymously. Now perform the command [cd /mnt] and you should be in
your boxs' root directory. Now perform the following command [ls -al]. If all went according to plan you should see a
listing of the files and directories in the root directory. There are several other tasks we could accomplish once inside
but, we will leave that up to the imagination of the reader.
-Now lets take a look at a traceroute to the target host. Traceroute prints the route packets take to a network host.
This will also alert us to any firewalls that stand in our way to the target host (usually indicated with a '*').
Note that the only mandatory parameter is the destination host name or IP number. The default probe datagram length
is 38 bytes, but this may be increased by specifying a packet size (in bytes) after the destination host name.
To initialize a traceroute use the following syntax as well as the man pages [traceroute [target host]]
$ traceroute www.target.com (Active Attack)
traceroute to www.target.com (127.0.0.2), 30 hops max, 40 byte packets
1 rsm1.yourhost.com (127.0.0.8) 0.791 ms 0.703 ms 0.704 ms
2 bigdog-gw.yourhost.com (127.0.0.9) 0.592 ms 0.551 ms 0.405 ms
3 1.atm8-0-0.umab-gw.net.ums.edu (131.118.255.129) 1.422 ms 1.020 ms 1.349
ms
4 206.181.226.97 (206.181.226.97) 51.923 ms 52.127 ms 69.832 ms
5 dca1-core3-h4-0.atlas.digex.net (165.117.51.70) 75.446 ms 66.744 ms 71.79
1 ms
6 dca1-core7-fa6-0-0.atlas.digex.net (165.117.16.7) 79.978 ms 79.756 ms 77.
974 ms
7 dca1-core9-pos1-1.atlas.digex.net (165.117.59.89) 69.804 ms 82.369 ms 81.
144 ms
8 atl1-core5-pos1-3.atlas.digex.net (165.117.51.145) 86.819 ms 78.657 ms 52
.745 ms
9 atl1-core3-pos4-0-0.atlas.digex.net (165.117.59.74) 40.033 ms 63.228 ms 6
8.938 ms
10 atl1-core1-fa3-0-0.atlas.digex.net (165.117.61.21) 78.620 ms 86.860 ms 98
.448 ms
11 500.Hssi11-1-0.GW1.ATL1.ALTER.NET (137.39.140.21) 105.357 ms 89.566 ms 11
6.460 ms
12 104.ATM3-0.XR2.ATL1.ALTER.NET (146.188.232.54) 121.399 ms 106.549 ms 139.
801 ms
13 294.ATM3-0.TR2.ATL1.ALTER.NET (146.188.232.110) 124.997 ms 129.528 ms 110
.989 ms
14 109.ATM6-0.TR2.LAX2.ALTER.NET (146.188.136.54) 201.188 ms 159.915 ms 215.
266 ms
15 198.ATM7-0.XR2.LAX2.ALTER.NET (146.188.248.133) 185.642 ms 142.192 ms 140
.496 ms
16 194.ATM9-0-0.GW1.PHX1.ALTER.NET (146.188.249.125) 158.889 ms 148.169 ms 1
37.867 ms
17 yourtargetsupstream-gw.customer.ALTER.NET (157.130.224.94) 153.436 ms 94.951 ms 140.0
85 ms
18 * * *
19 * * *
-As you can see from this traceroute data that we are looking at a box that resides somewhere in the Phoenix
Arizona area and most likely has some sort of packet filtering device before we reach our remote target indicated
by the '* * *'(hops 18 & 19). We also get information of what 'path' we take to get to our desired target host along with
the hop number for each path taken. Sometimes it may be easier to compromise an upstream and sniff the traffic to compromise
the target host. We can get away with a 'full' traceroute by using a technique known as 'Firewalking' (http://www.packetfactory.net/firewalk).
Firewalking is a technique developed by MDS and DHG that employs traceroute-like techniques to analyze IP packet responses to
determine gateway ACL filters and map networks. Firewalk the tool employs the technique to determine the filter rules
in place on a packet forwarding device. Also, we will be discussing spoofed packets to 'pierce' firewalls as a means to
portscan a machine on an internal network.
-For the remainder of this file we will be discussing portscanning. Portscanning has become one of the key auditing and
recon techniques amongst hackers today. There are a variety of portscanning utilities on the internet ranging from your
basic sequential portscanner to scanners that will bounce scans off of other hosts as an attempt to hide the origination of the scan.
The scanner that will be used in this file is a very versitile scanner called Nmap (http://www.insecure.org/nmap). Nmap is a utility
for network exploration or security auditing. It supports ping scanning (determine which hosts are up), many port scanning
techniques (determine what services the hosts are offering), and TCP/IP fingerprinting (remote host operating system
identification). Nmap also offers flexible target and port specification, decoy scanning, determination of TCP sequence
predictability characteristics, reverse-identd scanning, and more (try [man nmap] for more details). Lets take a look
at some of the flags we can use with Nmap along with the data that we obtain with each flag. First try just typing in the
command 'nmap' so you can see how to use the application.
nmap V. 2.12 usage: nmap [Scan Type(s)] [Options] [host or net #1 ... [#N]]
-Here we have version number of the program and its usage.
-sT TCP connect() scan: This is the most basic form of
TCP scanning. Establishes a full TCP connection with each port.
Considered to be a "noisy" scan because it leaves a lot of evidence
in the logs.
$ nmap -sT target.com (Active Attack)
Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on target.com (127.0.0.2):
Port State Protocol Service
1 open tcp tcpmux
11 open tcp systat
15 open tcp netstat
22 open tcp ssh
25 open tcp smtp
79 open tcp finger
80 open tcp http
110 open tcp pop-3
113 open tcp auth
119 open tcp nntp
143 open tcp imap2
443 open tcp https
515 open tcp printer
540 open tcp uucp
2000 open tcp callbook
6667 open tcp irc
12345 open tcp NetBus
Nmap run completed -- 1 IP address (1 host up) scanned in 15 seconds
-The output that we receive from the TCP scan is very interesting yet, will be very noisey in the logs. Any clued admin
will see this as an attempt to gather information for a future attempt at compromise. Seeing that we are doing an assessment,
this method will suffice and does a wonderful job at identifying open ports. We also receive a confirmation that Nmap has
completed its run along with how many IP address's it scanned and how fast it scanned them. Before we continue on to the other
features of Nmap lets assess this situation and make some sense of what we have here as far as data is concerned. There are
several services that could be vulnerable to outside attack but, it is up to you to determine which services are vulnerable
and how to compromise each particular service. Lets take smtp (port 25) for instance, we need to determine what mail service
this target host is running and which version of that particular package they are running. To do this, simply telnet to that
port and read its header using the following command [telnet [target host] [port]]:
$ telnet www.target.com 25 (Active Attack)
220 target.com ESMTP Sendmail 9.1.12a/9.1.12a/punk-beta; Tue, 10 Aug 1999 08:44:03 -0700
-As you can see here this admin was clever enough to 'spoof' the version of Sendmail he is running. He did this by editing
the config file for Sendmail which (when done properly) can hide the version number which is a key element for attacking this
particular service for many versions of Sendmail are exploitable remotely to gain root access. Again, remember to make note
of each header and its respected data for they are valuble parts that make up this entire 'puzzle'. While we are on the
smtp service try out the help command by simply typing 'help'.
help
214-This is Sendmail version 9.1.12a
214-Topics:
214- HELO EHLO MAIL RCPT DATA
214- RSET NOOP QUIT HELP VRFY
214- EXPN VERB ETRN DSN
214-For more info use "HELP ".
214-To report bugs in the implementation send email to
214- sendmail-bugs@sendmail.org.
214-For local information send email to Postmaster at your site.
214 End of HELP info
-You can now try different commands listed in the topics area. Try [HELP [topic]] to see further help on a particular topic.
For an exercise, try doing a 'verify' (VRFY) on one of the users on the system, try root. We will let you figure the command out
on your own so that you get into the 'learn it on your own' frame of mind. Remember, when you are trying these exercises out
please do them on your own system or have the permission of the owner before you try any of these commands out.
-Now that we have gone over a brief description of the TCP scan lets move on to a more 'stealthy' way of scanning a remote
host.
-sS TCP SYN scan: This technique is often referred to
as "half-open" scanning, because you don't open a
full TCP connection.
1. Sends SYN packet as if establishing a 3-way handshake
2. Waits for SYN/ACK from destination
If SYN/ACK is received then the port is open
If RST (reset) is received then the port is closed
3. Rather than send ACK to establish connection, immediatley RST (reset) to
close connection.
$ nmap -sS www.target.com
Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on target.com (127.0.0.2):
Port State Protocol Service
1 open tcp tcpmux
11 open tcp systat
15 open tcp netstat
22 open tcp ssh
25 open tcp smtp
79 open tcp finger
80 open tcp http
110 open tcp pop-3
113 open tcp auth
119 open tcp nntp
143 open tcp imap2
443 open tcp https
515 open tcp printer
540 open tcp uucp
2000 open tcp callbook
6667 open tcp irc
12345 open tcp NetBus
Nmap run completed -- 1 IP address (1 host up) scanned in 17 seconds
-Here we have the same ports open as before but, this time the identity of the account scanning this host is not given away.
The reason this happens is because we never establish a full connection or 'Three-way handshake'. As soon as the SYN/ACK
is received from the destination, rather than send an ACK to establish a connection we immediatley send a RST or 'reset' to
close the connection therefore, the identity is never known (this is assuming that the target host is not running any
extended logging features).
-Now we have a pretty good understanding of what services are running on this particular target host. Now, lets take a look
at OS detection and the concepts of OS Fingerprinting. There is a great paper on OS Fingerprinting by Fyodor at
http://www.insecure.org/nmap/nmap-fingerprinting-article.html. In this example we will show you how to use Nmap
to detect the OS of our remote target.
-O This option activates remote host identification
via TCP/IP fingerprinting.
1) Takes advantage of nuances found in each OS's TCP/IP stack to determine what OS
that remote host is running.
2) Sends specifically crafted packets to a host.
3) This information is used to generate a "fingerprint" which is then used to match
from a database of known OS fingerprints.
$ nmap -O www.target.com
Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on localhost (127.0.0.1):
Port State Protocol Service
1 open tcp tcpmux
11 open tcp systat
15 open tcp netstat
21 open tcp ftp
22 open tcp ssh
25 open tcp smtp
79 open tcp finger
80 open tcp http
110 open tcp pop-3
113 open tcp auth
119 open tcp nntp
143 open tcp imap2
443 open tcp https
515 open tcp printer
540 open tcp uucp
2000 open tcp callbook
6667 open tcp irc
12345 open tcp NetBus
TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)
Remote operating system guess: Linux 2.0.32-34
Nmap run completed -- 1 IP address (1 host up) scanned in 15 seconds
-The output of data that we see here are the same services as the previous examples except that we now know the OS of
the remote target. This target is running Linux 2.0.32-34 and the TCP Sequence Prediction for Trusted Relationship
Exploitation or any other HiJacking method is truly random and would be VERY difficult to predict the sequence. Now if
we must use a script to compromise we now know what operating system we are looking at.
-The final two scans we will discuss briefly are Ping Scanning and UDP Scanning. TCP Ping Scanning is used to determine
which hosts are up on a network. UDP scanning is a method used to determine which UDP (User Datagram Protocol, RFC 768) ports
are open on a host. UDP scanning takes longer due to RFC 1812 section 4.3.2.8 and its limiting the ICMP error message rate.
-PT Use TCP "ping" to determine what hosts are up.
Instead of sending ICMP echo request packets and
waiting for a response, we send out TCP ACK packets
throughout the target network (or to a single
machine) and then wait for responses to return
Hosts that are up should respond with a RST.
* To set the destination port:
-PT
* The default port is 80
-sU UDP scans: This method is used to determine which
UDP (User Datagram Protocol, RFC 768) ports are
open on a host. Sends a 0 byte UDP packet to each port on the
target machine. If we receive an ICMP port unreachable message, then
the port is closed.
Some services that may be found with UDP scanning:
*BO cDc's backdoor program that hides on a configurable UDP port on Win machines
*snmp
*tftp
*NFS
*and others...
-We won't be showing output from these scans. Rather, we ask you to perform the above flags
as an exercise for yourself. Now that you have completed this basic auditing paper you should
take all the information learned here and apply it to one conclusive paper and then begin your
compromise.
CONCLUSION:
In conclusion, we have discussed the basics to auditing a remote host or target host.
Knowing the security of your own network is key to being able to defend your network from
malicious intent. The techniques described here are basic techniques used to gather information
on the remote target before compromise. Look for further papers from the ATTRITION staff on
Penetration and Auditing of systems.
GENERAL INFORMATION:
ATTRITION Security: http://www.attrition.org/security/newbie
Nmap Security Scanner: http://www.insecure.org/nmap
Whitepapers & Publications: http://www.enteract.com/~lspitz/pubs.html
Security Focus: http://www.securityfocus.com/
Packet Factory (Firewalk): http://www.packetfactory.net/
CONTRIBUTIONS:
Email all Contributions/Suggestions/Feedback to modify@attrition.org
ACKNOWLEDGMENTS:
The following individuals helped in either review, technical input, or in some other fashion.
Brian Martin, Dale Coddington, Jay D. Dyson, and Jeremy Rauch
modify@attrition.org
(c) copyright 1998, 1999 Karl Lynn
reference : http://www.unixgeeks.org/security/newbie/pen/ssarh.html
