Larry W. Cashdollar
Rev 1.73   1/18/2000

What you don't know will hurt you.

 Sections of this document are works in
progress and is far from complete.
 

I. Overview



   The first stage to a successful network attack is the information gathering stage.  The attacker will collect as much information possible on the target host in order to generate a vulnerability list.  Relivant to this list will be OS type, OS version, services, service daemon versions, network topology*,network equipment, firewalls, intrusion detection sensors etc..  The purpose of this document is to outline two models of information gathering .  The first model is "noisy" where the attacker uses all known resources with little reguard for what footprints* might be left on the target.   The second is "stealthy". Wherein the attacker uses methods and packages designed to subvert logging facilities on the target.  This approach minimizes administrator awareness and accountability.   I will examine a few systems, ranging from Solaris 2.x Sparc systems to Linux/i386 architectures. I will then discuss how we can harden a system to minimize information leakage.
 

II. Utilities and Packages


    The utilities we will use can can range from some common system commands to network information gathering packages like nmap. I will list a few below and give a brief description of each.  In the resources section you will find sites and security indexes where search engines can dig up a myriad of network security tools.  These are just a few.
 

            System Utilities. 

 
Utility
Description
finger Displays user information or current users logged into specified host
rusers Same as finger but in more detail
showmount Displays directories available for mounting via NFS.
rpcinfo Makes a call to rpc server and displays information gathered.
dig DNS information gathering tool. Very useful.
whois internic database lookup program.
snmpwalk Gather network information using the SNMP protocol.
traceroute Show packet path to target host.
nslookup Convert ip address to conical and visa versa
mail bounce Use a bogus recipient to gain information on a target host.

            Tool packages

 
Tool
Description
brscan Broad scan scans an ip range for one specific port.
sscan Scans multiple vulnerabilities and also uses host gathering techniques.
nmap Stealth port scanner with stack fingerprinting ability and source spoofing techniques, does xmas,syn,fin and UDP scans.
mscan older version of sscan, still kind of fun.
NSS Narrow Security scanner its a perl script which makes it nice and portable.  Searches for common vulnerabilities like msadc.pl and showcode.asp.  I found it works very well.
CIS Cerebrus internet scanner
nessus Nessus is a security auditing program that can scan an entire class A subnet for multiple DoS attacks,exploits and mis-configurations.  It runs in to parts a client and server type application is used where all scanning functions are done by the server which are controlled by the client. Nessus scans for many modern security issues such as Windows vulnerabilities and various Unix exploits. 

 

            Common services.


Service
Description
SSH Secure Shell an interactive encrypted shell session like telnet.
NFS Network File System allow file systems to be exported across the network and mounted on a remote system.
rlogin/rsh/rexec Remote login / Remote shell / Remote execute
finger Display remote user information and current users logged in.
FTP File transfer protocol, transfer binary and ASCII files between hosts.
sendmail Mail delivery system between hosts.
WWW World Wide Web a.k.a Hyper Text Tranport Protocol. You are looking at it now.
netbios Protocol that allows MS networked machines to share resources.
DNS Domain Name Service, used to resolve IP addresses to conical names and vise versa.
telnet Start an interactive shell on a remote host using the TELNET protocol.
QPOP Pop your email off the server to read off-line.
portmap Maps sun rpc services to their respective ports (UDP)

 

III. Information

    Just about any information on a target host is useful in creating a database of applicable vulnerabilities. What we are attempting to do is determine what services the target offers and if any of them can be exploited to leverage access to the system. For example knowing the version of the OS that your target host is using can help you find information on exploits or bugs specific to that OS.  By limiting what services we are running and what information is available we decrease the window of opportunity for the cracker.

IV. Information Gathering (Noisy)

    Just about all of the utilities mentioned above will disclose information about the target host. You can piece together parts of a targets network topology by bouncing a bad email off of the server. This can disclose a weather the mail is relayed internally on another host and the type and version of software used to handle internet/exchanged mail.  Using traceroute you can discover network equipment like routers and switches.  Portsan will give you a list of services available on the target host.  These are all common methods adopted by system crackers to gain access to their target.  Their are many packages out there that automate this process of poking, gathering, logging and sorting.  For example Sscan is a utility for crackers and system admins to gather information on target hosts machines also. It scans the host or network for various security problems and checks for vulnerabilities. Nessus is another package that scans a network for problems as it also checks for DoS attacks and poorly configured network equipment like routers and manageable hubs.

     Just grabbing banners with telnet or netcat will divulge important information on your target. All of this is fine, but what about more sinister methods of information gathering? What about using information you meant to provide being used against you?  What about the stuff your logs don't catch?

V. Information Gathering (Stealth)

    This method uses the common public ports and specially designed utilities to gather host, user and system information. When I talk about common public ports I am referring to ports that are  expected to be accessed by the everyday internet user (53*, 80, 25 , 21*). These services can be queried with little or no suspicion of the administrator. Some ports have varying degrees of noticeably, for example if you do a zone transfer of the target systems dns records. This may set off alarms that suspicious activity is at hand, perhaps more so then an anonymous ftp connection depending on the site and administrators awareness.

    These stealth utilities like nmap are designed to take advantage of the tcp protocol in order to circumvent logging.  This can also be combined with protocols that are less common like snmp. An SNMP query can yield information like OS type, uptime and machine name*.  Quite a few vendors enable SNMP by default and most administrators are unaware of the dangers. More common services for example anonymous ftp can be mined for information. It is amazing what one can find dumped in /pub on some sites, password files, old sensitive emails, product information, system information and user lists.  I once found a Netscape Enterprise Digital Certificate for the site I was auditing sitting in /pub waiting for its owner to pick it up*.  In cases like this attacker simply downloads every readable file hoping to find something interesting.

    Probably the number one reason to drive system admins to place closed networks on to the internet is the desire to implement a web site. In some cases the mad dash to get a web page up shoves proper security techniques aside. The old saying don't put all of your eggs in one basket applies to security as well, anyway back to the mad dash. This usually means that the hosting company will go through great lengths to provide a myriad of information to the WWW community. This can be a bad thing however, sometimes more information is too much information.

VI. Procedures


        This is an overview of how to use each package.  For more information see the man pages or the package documentation.
 
 

Package
Description
brscan Broadscan is very simple to use, I plan to add more options to it later.  The following will search the given ip range for port 80.

$ ./brscan 192.168.2.1 192.168.3.254 80 

smbclient List all shares on WWW,  type smbclient for more information on options and usage.

$lab-1> smbclient -L WWW -I 192.168.2.3

whois $ whois  whitehouse.gov@whois.arin.net
traceroute $ traceroute www.freebsd.org
dig $ dig maine.edu @192.168.172.123 axfr
snmpwalk Use snmpwalk to query the snmp server on a remote host.  This protocol is probably less commonly thought of as an information gathering tool.  It is a powerful one however.

$lab-1> snmpwalk 192.168.2.3 public system

nss Narrow Security Scanner.

hostfiles is file containing a list of ip addresses that you are scanning.

./scanner  hostfiles vulnerable-log

Nessus Nessus is a security auditing program that can scan an entire class A subnet for multiple DoS attacks, exploits and mis-configurations.  It runs in to parts a client and server type application is used where all scanning functions are done by the server which are controlled by the client. Nessus scans for many modern security issues such as Windows vulnerabilities and various Unix exploits.  The command is as follows: 

# ./nessusd & 
# ./nessus & 

must issue an xhost command on connecting host.

rpcinfo Display information on remote procedures being offered. 

$ rpcinfo -p hostname

showmount Display information on remote NFS mounts. 

$ showmount -e hostname

mail bounce An attempt to gather information on a remote host by bouncing a bad email off of the server and examining the header information. 

$ mail -s"test" jkhshjkd@hostname.com 
test message please ignore 

 

nmap This is a network mapping package that is capable of stealth scanning and OS finger printing.  I will attempt to explain these concepts to those of you who are unfamiliar with them. 

Stealth scanning: A normal TCP connection consists of a 3 way hand shake in order to connect to the other host, this software doesn't complete that 3 way hand shake in order to hide its attempts at information gathering. 

OS finger printing: Mangled packets are sent in different sequences at the target host and depending on the target hosts reaction a guess is made as to what that host is running for an OS based on a table of known reactions. 

# ./nmap -O -sS  192.168.0.*
 

sscan Sscan is a rewrite of mscan. They are vulerability scanning tools that are capable of scanning a large block of ip addresses searching for known vulnerabilities like, Qpop, IMAP, DNS, cgi-bin/phf etc.

# ./sscan -o 192.168.3.28

VII. Locking down the house

  1.  Shut down all unneeded services.
  2. Remove all unwanted packages.  Web server? don't need X, GCC, Sendmail etc... Mail server? don't need apache, GNOME, GCC etc...
  3. Look through vulnerability archives like packetstorm for existing exploits.  Search for your OS/Software/Services/Packages etc.. Patch accordingly.
  4. Audit your setuid binaries. find / -perm -4000 > setuid-DATESTAMP  store this off-line somewhere.
  5. Install tripwire but don't rely on this alone.  Watch your logs keep a close eye on the system as a whole.
  6. Mount certain partitions Read only like /usr.  Under linux you can do a mount /dev/hda2 /usr remount,ro see the man page for more details.
  7. Join Email lists like CERT, CIAC,Bugtraq and lists specific to your vendors.
  8. Limit local accounts to root and a manager account.
  9. Passwords  really secure passwords.  Something you can pronounce so you can remember it, but with no real words. minimum of 7 characters. Rudi^b@1  -->>> Rudy Carrot bat one.
  10. Limit services, don't run tons of plugs and proxies on your firewall.  It soon becomes a proxy server once you add that AOL IM Proxy, Real audio and NNTP.
  11. Use filtering either tcp wrappers or like linux and freeBSD you can use ipchains and ipfw to drop unwanted packets.
  12. try to break into your own network.  BUT make sure you have permission in writing, and notify networking personnel and management.  This could even cause them to secure the boxes before hand.  Which will not give an accurate security assessment but at least it moved you in the right direction.
  13. Always maintain patch levels and version levels of your services, like bind and sendmail.
  14. Only allow zone transfers and queries by your network and its trusted hosts (i.e. secondary DNS).

VIII. Interpretation and Sorting

This section is still being completed.  In this section I have examples of output from various packages and I will point out significant tid bits of information.

These are actual logs of what information I was able to find on some test systems.  My comments are in red.
 

# ./nmap -sT  192.168.18.6

Starting nmap V. 2.3BETA5 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on 192.168.18.6
Port    State       Protocol  Service
7       filtered    tcp       echo
19      filtered    tcp       chargen
25      open        tcp       smtp
111     open        tcp       sunrpc
800     open        tcp       mdbs_daemon
844     open        tcp       unknown
1030    open        tcp       iad1
1521    open        tcp       ncube-lm
2001    open        tcp       dc
12345   filtered    tcp       NetBus
12346   filtered    tcp       NetBus

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

Looks like a database (port 800), so why run all of these other services?  If you dont need them shut them down.
 

$> snmpwalk 192.168.18.6 public system

Timeout: No Response from 192.168.18.6

No snmp daemons running.
 

[bewhaw ~]  $ rpcinfo -p 192.168.18.6

   program vers proto   port  service
    100000    3   udp    111  rpcbind
    100000    2   udp    111  rpcbind
    100000    3   tcp    111  rpcbind
    100000    2   tcp    111  rpcbind
    100024    1   udp    842  status
    100024    1   tcp    844  status
    100021    1   udp   2049  nlockmgr
    100021    3   udp   2049  nlockmgr
    100021    4   udp   2049  nlockmgr
    391004    1   tcp   1025
    391004    1   udp   1025
    100001    1   udp   1026  rstatd
    100001    2   udp   1026  rstatd
    100001    3   udp   1026  rstatd
    100008    1   udp   1027  walld
    100002    1   udp   1028  rusersd
    100011    1   udp   1029  rquotad
    100012    1   udp   1030  sprayd
    100026    1   udp   1031  bootparam
    391011    1   tcp   1026
    391002    1   tcp   1027
    100083    1   tcp   1028
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    150001    1   udp    797  pcnfsd
    150001    2   udp    797  pcnfsd
    150001    1   tcp    800  pcnfsd
    150001    2   tcp    800  pcnfsd
 

Hmm lets check for nfs, I dont see mountd though.

[brewhaw ~] lwcashd $ showmount -e 192.168.18.6

showmount: 192.168.18.6: RPC: Program not registered

Nope, no exported file systems.
Fix: Again shutdown all uneeded services.
 

[muffin ~] $ telnet 192.168.18.6 25

Trying 192.168.18.6...
Connected to 192.168.18.6.
Escape character is '^]'.
220- mail Sendmail 950413.SGI.8.6.12/950213.SGI.AUTOCF ready at Tue, 7 Dec 1999 13:52:49 -0500
220 ESMTP spoken here
vrfy root
250 Super-User <root@mail>
expn root
250 Super-User <root@mail>
 

Hmm IRIX 6.2 I'd guess as 8.6.12 is pretty old sendmail. It also is running with vrfy and expn functional they can be used to guess valid user accounts.
Fix: Upgrade sendmail.

Lets try another system, this time we will try to be sneaky.

[pangea ]$ snmpwalk test-03 public system

system.sysDescr.0 = Sun SNMP Agent, Ultra-Enterprise
system.sysObjectID.0 = OID: enterprises.42.2.1.1
system.sysUpTime.0 = Timeticks: (13902714) 1 day, 14:37:07.14
system.sysContact.0 = System administrator
system.sysName.0 = test-03
system.sysLocation.0 = System administrators office
system.sysServices.0 = 72
 

#./nmap -sF 192.168.1.1
 
 

This snmp call was successful, sometimes we can discover the OS version and patch level this way.
Fix: Disable snmp by removing the snmp daemon from your startup scripts.

[pangea ~] lwcashd $ finger @192.168.7.21
[192.168.7.21] connect: Connection refused

Hmm, finger is not running so we cant get a user list that way.. lets try another method.

[pangea ~] lwcashd $ rpcinfo -p 192.168.7.21
   program vers proto   port  service
    100000    4   tcp    111  rpcbind
    100000    3   tcp    111  rpcbind
    100000    2   tcp    111  rpcbind
    100000    4   udp    111  rpcbind
    100000    3   udp    111  rpcbind
    100000    2   udp    111  rpcbind
    100002    1   udp  32770  rusersd
    100002    2   udp  32770  rusersd
    100021    1   udp  32776  nlockmgr
    100021    2   udp  32776  nlockmgr
    100021    3   udp  32776  nlockmgr
    100021    4   udp  32776  nlockmgr
    100021    1   tcp  32772  nlockmgr
    100021    2   tcp  32772  nlockmgr
    100021    3   tcp  32772  nlockmgr
    100021    4   tcp  32772  nlockmgr
1342177279    3   tcp  35567
1342177279    1   tcp  35567
1342177280    3   tcp  36146
1342177280    1   tcp  36146

Hmm rusers is running lets see what that gives us.

[pangea ~] lwcashd $ rusers -l 192.168.7.21
www         192.168.7.21:tty0        Jan 18 11:22    5:54
www         192.168.7.21:tty0        Jan 18 15:09    5:54
 

We know know of one login on our target www which sometimes has easy to guess passwords for web maintenance.

    If a service is vital to your server be sure and get information on pervious bugs and patches.  Getting the latest version isnt always the answer as new features might introduce new bugs its better to keep track of the latest modifications to the new version and upgrade accordingly.  For example if their are no known vulnerabilies and the latest version adds more bells and whistles you might want to wait a while before upgrading.  This way the software package has time to be poked and prodded by system administrators and security personnel.

    Enough dry reading already lets see how much information we can gather on our target with these tools. Our target is a High School web server. The box is hosted by the school off of a state edu connection. The box is actually one of my lab machines that I configured in the same exact way the server I audited was. All of the examples in this paper will be lab machines setup to depict examples as I have seen them in the wild.

Nmap Scan:
For usage see the tools section.

[root@Diabolic nmap-2.3BETA6]# ./nmap -O -sX 24.93.145.219

Starting nmap V. 2.3BETA6 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on dt065ndb.maine.rr.com (24.93.145.219):

Port    State       Protocol  Service
23      open        tcp       telnet
25      open        tcp       smtp
80      open        tcp       http
TCP Sequence Prediction: Class=truly random

Difficulty=9999999 (Good luck!) Remote operating system guess: Linux 2.0.35-37

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

Our target host is running a web server and telnet for remote administration. They probably feel that the server is somewhat secure because they have shutdown most of the services. The next step is to fire up a web browser and see what they have for site content. <sceen dump?>

What I am looking for is any information that will get me what accounts exist on the target and whom they belong to. I find to be what I consider half of the password file HTMLized and up for display, a contact page. I don't really know if the accounts on the contact page are local or alias to a mail server internally. I assume its all local accounts as most school admins aren't ready to setup a split horizon DNS with a smart relaying sendmail configuration.

The contact page is generally a list of email addresses for that site of about ten to fifteen teachers, staff and even the webmaster. I guess that the principals secretary might be a good candidate for a password guessing attack and try the following.

Trying 24.93.145.219...
Connected to 24.93.145.219.
Escape character is '^]'.

Red Hat Linux release 5.2 (Apollo)
Kernel 2.0.36 on an i486
login: jsmith
Password:jsmith<enter>
[jsmith@dt065ndb jsmith]$

Woops, they are local accounts and poorly passworded as I suspected. As nmap revealed this is a linux box. Redhat 5.2 to be specific and trivial to locate an exploit to get root. At this stage the game is all over. With minimal information gathering, nmap scan and web mining we were able to gain access to our target. If they had mail handled elsewhere, limited local accounts to root and 1 admin user with good passwords this wouldn't have happened. (entries in hosts.allow/deny wouldn't have killed them either)

More electronic dumpster diving with ftp.

[pangea /tmp]  $ ftp 192.168.41.29

Connected to zig.internal.net.
220 zig FTP server (UNIX(r) System V Release 4.0) ready.
Name (zig.internal.net:security): anonymous
331 Guest login ok, send ident as password.
Password:
230 Guest login ok, access restrictions apply.
ftp>  cd etc
250 CWD command successful.
ftp> get passwd
200 PORT command successful.
150 ASCII data connection for passwd (192.168.12.2,33793) (523 bytes).
226 ASCII Transfer complete.
local: passwd remote: passwd
538 bytes received in 0.0059 seconds (89 Kbytes/s)

Ok, grabbing the password file isnt so steathly.  But I want to check to see if they screwed up at all.

$> tail -n1 passwd
ftpadm:x:1113:1000::/home/ftpadm:/bin/csh

Yes, they have screwed up this is possibly (if the passwd file is not out of date) a local user account with a vaild shell.

[muffin /tmp] $ ftp 192.168.41.29

Connected to zig.internal.net.
220 zig FTP server (UNIX(r) System V Release 4.0) ready.
Name (zig.internal.net:security): ftpadm
331 Password required for ftpadm.
Password: (ftpadm1)
230 User ftpadm logged in.
ftp>

First try.  Probably the second worst password you could have besides ftpadm.

       

            Dangerous combinations

           Sorting / Organization

                Logs are normally kept in flat text files, this make them easy to manage and sort. Depending on how savvy you are you might want to create  database
                 or store them in comma delimited format. I organize log files using the following directory structure.

                Network
                                  ----->  Hostname
                                                                    -----> nmap_output
                                                                    -----> showmount -e output
                                                                    -----> snmpwalk_output
                                                                      ..etc..
 

                I suggest logging problems by network, OS, Vulnerability, hostname.

                                                    192.168.0
                                                                    ------> IRIX
                                                                                             ------> open_lp_account
                                                                                                                192.168.0.23
                                                                                                                192.168.0.64
                                                                                                                192.168.0.203

                  This way with each directory change you get more detail.
 
 

X. Resources

Web.

Security mailing list and announcements http://www.cert.org
Massive security site, hosts bugtraq and other security forums.  http://www.securityfocus.com
Probably the biggest security archive out there. http://packetstorm.securify.com
Underground news and information http://www.hackernews.com
A searchable index of RFCs, FAQs and electronic books. http://www.faqs.org/
IBM Bookmanager Book server. http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/print?book=bk8p7001
The nessus project (free network security scanning tool ) http://www.nessus.org
nmap OS detecting scanner. http://www.insecure.org

 

Papers

Holbrook. P, (1991). Site Security Handbook [Online], Available: http://www.cis.ohio-state.edu/htbin/rfc/rfc1244.html [1997, December 20].

Pethia. R, (1991). Guidelines for the Secure Operation of the Internet [Online], Available: http://www.cis.ohio-state.edu/htbin/rfc/rfc1281.html [1997, December 20].

Farmer. D and Venema. W, (No Date). Improving  the security of your site by breaking into it [Online], Available:http://www.deter.com/unix/papers/improve_by_breakin.html [1998, January].

Bellovin. S. M, (1993). Packets found on an internet [Online],Available: http://www.deter.com/unix/papers/packets_found_bellovin.ps.gz [1998, January].

Bacic. E. M, (No Date). UNIX & Security [Online], Available: http://manitou.cse.dnd.ca/papers/Unix_Sec.html [1998, January].

Smith. N. P, (1997). Stack Smashing Vulnerabilities in the UNIX operating system [Online], Available: http://millcomm.com/~nate/machines/security/stack-smashing/[1998, Febuary]. 

Fydor, (1998) Remote OS detection via TCP/IP Stack Finger Printing [Online], Available: http://www.insecure.org/nmap/nmap-fingerprinting-article.html