Chapter 4. Know Your Enemy
Any security-related project starts with an inventory. You need to know what systems are in your environment and what software they are running. You also need to know what business processes exist in your organization so you can tailor your information technology decisions to support these processes.
When starting an IDS project, it’s important to know not just what you’re protecting, but also what the threats to your environment are. If you don’t understand the nature and methods of your enemy, building defenses to protect against their attack is nearly impossible. While you might stumble onto something by accident, a targeted approach to an IDS deployment yields better returns on your time (and budget).
The Bad Guys
It’s unlikely that a maniacal billionaire is hiring some elite hacker to break into your network or that a group of former Spetnatz commandos are trying to steal the secret to how your widgets are manufactured. The threat often comes from people who aren’t targeting you specifically; they are simply scanning huge ranges of Internet-connected systems looking for vulnerable systems that they can use for whatever purpose. No matter the identity of these individuals, they can be the cause of your two real enemies: downtime and data loss.
Opportunists, Thieves, and Vandals
Most often these attackers are not targeting your environment specifically. They scan and probe wide ranges of addresses looking for systems that are vulnerable to the exploits they are familiar with. They range from the classic 15-year-old boy trying to gain notoriety with his peers to a SPAM sender looking for an open mail server to act as a relay for his unsolicited emails. While this group of people represents mainly an annoyance, it is folly to ignore the threat.
Simply connecting your network to the Internet exposes you to this kind of attacker. It’s not a matter of if but when someone will probe and attempt to penetrate your network.
- Opportunists
These individuals are trying to break into systems just for the challenge. They might just look around after getting in, or may become vandals. While not (at least initially) malicious, they can inadvertently do damage or cause service interruptions in the course of their activity.
- Thieves
These people are generally not trying to get your data—they’re after your bandwidth, computing power, or want to use your mail system for their own purposes. Your network bandwidth is probably better than theirs and would make their explorations much easier than their slow dial-up line. Your computers compile programs better, have more disk space for their pirated DVD rips, and are easier to get to than their own systems for their friends.
- Vandals
In the old days, someone would shimmy up a water tower and spray paint his high school’s team name for everyone to see. Now, someone will shimmy into your web server and do the same thing with your main web page. As soon as your web site is defaced, they hop onto their favorite IRC channel and tell their friends to have a look. In the meantime, your company faces reputation damage and you, as the person who’s ultimately responsible for the security of your network, have to explain how it happened without you noticing.
Professionals
There are many stories from the cold war era of spies using computers to steal information or do harm to their opponent. The East Germans broke into the Lawrence Berkeley National Laboratory (chronicled in Clifford Stoll’s “The Cuckoo’s Egg”) and the United States planted faulty designs for software and computer chips that caused a massive explosion of the trans-Siberian pipeline. The attackers of government systems these days are more likely to be terrorist-related groups.
The threat of a professional attack on your environment is relatively small. The payout for the freelancer doing the work is low for days of painstaking work (the work is harder when you have to cover your tracks). The impact of such an attack can be huge, however. Intellectual property can be lost, or systems can be destroyed. I’ve met people who do this for a living—the threat is real.
Disgruntled Current and Former Employees and Contractors
The threat from this group is often underestimated. These folks have been trained by you, are familiar with your environment, and can often bypass your perimeter security measures. They have motive, opportunity, and the skills necessary to do real damage. The existence of this threat inside your network is a strong argument for defense-in-depth. Protecting internal systems from internal users is fairly difficult and requires consideration and vigilance.
Robots and Worms
Once, the only way to get a virus on your system was to use an infected floppy disk. Now, an actual virus is fairly rare. Infections occur from across the network. The newly infected machine, in turn, infects other systems. Many times the inconvenience is not the impact on the infected systems, but the impact on the network. The SQL Slammer worm caused many networks to become completely saturated with the 404-byte UDP packets (the entire worm was contained in a single UDP packet!).
The worms are getting faster, too. The Code Red worm took about 13 hours to infect 90 percent of the hosts it would eventually affect. SQL Slammer took 10 minutes to do the same thing! This speed of propagation is due to the fact the UDP worms have the unfair advantage of not needing to establish a three-way handshake—not all subsequent worms will have this advantage. Increased vigilance is absolutely called for, and the only way to notice is by watching your network traffic.
Simply closing ports on your firewall does not help much, either. The series of worms that exploited the vulnerable RPC services on Windows systems (Blaster, SoBig, Nachi, Welchia, and so on) required access to TCP ports 135-139—not normally open to the Internet. Most organizations were infected across VPN connections, remote dial-up connections, and backend connections to business partners. See Chapter 1 for a discussion of the disappearing perimeters of our networks.
Sometimes the automated attack is not actually a worm, but a script running on the Internet looking for systems that are vulnerable to a particular attack. The results of this scan then acts as a target list for an actual person to attack. This method has been suggested as one way to introduce a worm in a fashion that jumps up the growth curve; e.g., by finding a large number of vulnerable machines in advance, an attacker can start the worm from 5,000 hosts (each scanning the network) at once, instead of, say, 5 hosts.
Anatomy of an Attack: The Five Ps
In a meeting with an engineer (Jonathan Hogue) from a security company called Okena (recently acquired by Cisco), I was introduced to the concept of the five Ps. Hogue graciously gave me the presentation slide and I use it all the time. There are a lot of models of how an attack progresses, but this is the best I’ve seen. These five steps follow an attack’s progression whether the attack is sourced from a person or an automated worm or script. We will concentrate on the Probe and Penetrate phases here, since these are the stages that Snort monitors. Hopefully, the attacker won’t get past these phases without being noticed. The five Ps are Probe, Penetrate, Persist, Propagate, and Paralyze.
Probe
In this phase, the attacker gathers information on a potential target. In a targeted attack, the scanning may be limited to your allocated range of IP addresses. In an untargeted attack (see Section 4.1.1, above), it might be against a wide range of addresses. Often, the initial activities of this information-gathering will not send a single packet to your network. A surprising amount of information can be gathered from information stores on the Internet. The goal of this phase is to map out your network and determine details about the systems on your network, permitting the attacker to tailor an attack to exploit known vulnerabilities in the software version running on your system, or perhaps to a configuration error.
Mining the Web
What follows are methods attackers use to gather information about the network, IP address range, or business assets they wish to attack—without sending a single packet to your network:
WHOIS, ARIN and DNS lookups
Gleaning data from off corporate web sites
Web-based reconnaissance
General reconnaissance using Sam Spade, IP Tools, etc.
Tip
The victimized network is not always purposefully sought out. Drift net scans or blindly probing large subnets for vulnerable devices sometimes brings networks onto radar screens. Such is the importance of staying current with patches and closing susceptible ports.
An initial tactic is to gather information regarding the IP addresses owned or managed by a particular company, the contact people, or even the physical address or location of the company. Here are some sites that give out this type of information:
- http://www.networksolutions.com/en_US/whois/index.jhtml
Performs lookups on the administrative, technical, and billing contacts for a particular domain name.
- http://www.arin.net/
Searches for the registrant and IP address range of a particular IP address. Useful for tracking down offending IP addresses.
- http://www.bankes.com/nslookup.htm
Executes multiple DNS lookups on IP addresses or domain names. This site is used for performing both forward and reverse name resolution. It is comparable to the Linux command line
nslookupordigcommands.
There are several other free WHOIS services available on the Internet. Each one offers nearly the same information that can be gleaned from the main Network Solutions page. Sites such as http://www.hyperwhois.com and http://www.accesswhois.com are also used. Attackers visit these sites to locate domain names pending expiration. Network Solutions and Verisign have proved most accommodating recently by providing alternative misspellings of common domain names. Both of these features are useful when attempting to take over a domain or redirect normal commerce traffic to another site by means of subversion. Check these web pages for information about your own company. If too much data is available on the Internet or if you wish to minimize your company’s exposure, resubmit the correct forms to Network Solutions or to your domain name provider. Also, update the information contained on the ARIN site by modifying RWHOIS records. One tactic is to replace names with titles, or even use bogus names to make it harder for social engineering to succeed.
Another common tactic is to gather data from corporate web sites. Most companies list their physical address and provide maps and directions. Typical business sites often display not only the president or CEO’s name (and all other higher management personnel) but provide an email address and phone number. These are useful to attackers when performing social engineering. In addition, the email address can assist in DNS requests and MX record lookups. Minimize the amount of data you are willing to share with strangers by censoring corporate web pages. Explain this to company managers as well as to the webmaster. Anyone using the corporate web site for marketing or sales purposes should be aware of any inherent security risks.
There are several free tools for Windows-based machines that execute
commands similar to those found on Linux. The two I mention here are
Sam Spade
and
IP-Tools
.
Their URLs are listed at the end of this chapter. The former is free,
while the latter currently requires a $35 registration fee. Both of
these utilities provide Windows users with much the same
functionality as Linux. They offer many like features, including
webcrawling utilities, real-time
blackhole
lists for determining the IP addresses of repeat spam offenders,
ping, whois,
dig, and traceroute. The
IP-Tools application does have some added functionality such as port
and NetBIOS
scanning similar to that of Nmap for Linux, along with a telnet
utility. It also performs netstat
commands that displays open ports listening for connection
requests.
There are several other DNS query tools available for use directly off web pages. I recommend the netcraft.com site for determining version and release numbers of a particular web server. This leads us into the active probing that can be performed to gather information about your network.
Portscans and software version-mapping
One of the most widely used network mappers or port scanners is Nmap . Fyodor, the author, describes his tool in the following manner
Nmap or “Network Mapper” is an open source utility for network exploration or security auditing. It was designed to rapidly scan large networks, although it works fine against single hosts. Nmap uses raw IP packets in novel ways to determine what hosts are available on the network, what services (ports) they offer, what operating system (and OS version) they are running, what type of packet filters/firewalls are in use, and dozens of other characteristics.
Nmap is available for most systems, including nearly all BSD
variants, Solaris and Linux, and Windows. Nmap can be used from the
command line as a console tool or in its graphical release. It is
started from the prompt with the command nmap. The
graphical version is initiated using nmapfe, short
for “nmap frontend.” Nmap is best
run as root so all options are granted to the user. Consult the
Nmap home page at http://www.insecure.org/nmap/ for available
options and latest source code. Nmap comes in source and RPM formats.
It is included as a standard package with most Linux distributions,
including Red Hat. Install it initially or compile it later from
source.
Figure 4-1 shows Nmap run as root with the graphical frontend. Selecting different variables within “Scan options” and “General options” customizes how stealthy or unobtrusive the scans run against target systems. The output as it appears on the command line is displayed directly below the options. By noting the syntax that appears below the main window, a scan can be run from the console or the command line.
After selecting a target IP address, subnet, or domain name, execute the scan. The output displays in the lower box. All detected open ports are shown here with the service name and port number.
The latest release of Nmap shows not only the open ports but performs fingerprinting of the listening ports and displays the software version and release currently running on that port. Not only can I find out if a port is open, but I can see the Apache version and the current PHP release running on my system.
Currently, Nmap is best run from the command line for a detailed report on available services. Here is what a scan showed against a typical machine with a default or “vanilla” configuration.
# nmap -sV -T4 -F localhost
Starting nmap 3.45 ( http://www.insecure.org/nmap/ ) at 2003-09-17 19:36 MDT
Interesting ports on localhost (127.0.0.1):
(The 1203 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE VERSION
21/tcp open ftp vsFTPd 1.1.3
22/tcp open ssh OpenSSH 3.5p1 (protocol 2.0)
25/tcp open smtp Sendmail smtpd Secure/Rabid
80/tcp open http Apache httpd 1.3.28 ((Unix) PHP/4.3.2)
110/tcp open pop3 UW Imap pop3 server 2001.78rh
6000/tcp open X11 (access denied)
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux Kernel 2.4.0 - 2.5.20
Uptime 9.486 days (since Mon Sep 8 07:56:31 2003)
Nmap run completed -- 1 IP address (1 host up) scanned in 16.151 secondsNmap scans are useful for testing Snort installations. By default, Nmap is fairly noisy and easily detectable. Most Nmap scans readily show up in the alerts file or via the ACID web page.[1] Existing signatures that alert administrators to Nmap scans can be customized to suit.
Here is one of several possible alerts that appear in the Snort alert
log when Nmap is run (using Nmap’s
-P0 option prevents the ping from being sent).
[**] [1:469:1] ICMP PING NMAP [**] [Classification: Attempted Information Leak] [Priority: 2] 09/18-02:58:18.144568 64.147.136.144 -> 209.63.147.19 ICMP TTL:22 TOS:0x0 ID:51496 IpLen:20 DgmLen:28 Type:8 Code:0 ID:44209 Seq:8907 ECHO [Xref => arachnids 162]
There are also Nmap-specific scans that show up in the Snort alert log. These range from Nmap web-based attacks to fingerprint attempts (much like the example scan shown above) to TCP scans. To view sample alerts generated by Snort when Nmap is run against it, simply grep the text “nmap” within the Snort rules. There are plenty of occurrences in which Nmap plays a role in generating alerts. Each of these rules can be customized to give alerts on a more specific level.
Once ACID is operational with Snort, consult the logs frequently for network scans and connection attempts. Some Nmap scans may be stealthy connection attempts so also look for SNMP requests and proxy scans, which are fairly typical for Nmap.
Warning
A quick word of caution. Those of you reading this book who think you are now an “elite hacker” or that this and the other outlined tools will assist in cracking other systems, do not be fooled. Simply running Nmap against other computers does no such thing. All Nmap does is show open ports and available software versions. That said, since a portscan is often a precursor to an attack, most people do not take kindly to network portscans. Consider yourself warned. People have been prosecuted for attacking a network after only performing a portscan.
Armed with this information, an attacker can go to a variety of web sites and discover if you are running an operating system or service version with known vulnerabilities. Once this is determined, it is a relatively easy manner to find scripts or programs that can exploit the vulnerable system, leading to a penetration.
Automated vulnerability scanners
Port scanning, fingerprinting, and determining software versions takes a considerable amount of time and some skill at rooting out information on the Internet. To make research easier, a number of tools are available that perform all these tasks automatically. There are expensive commercial solutions and free open source tools. While these tools were designed to make it easier for administrators to evaluate their security posture, they are a boon to the bad guys, too.
One open source tool has risen above the others (arguably including the commercial alternatives): Nessus. It can be downloaded from http://www.nessus.org. Nessus is free, manageable even by novice users, has clients for both Unix-based systems and Windows, and displays the data in an easy-to-understand format. It also suggests what measures to take to fix any listed problems. It should be noted that Nessus works with a client/server model and only a client is available for Windows systems. A server version exists, but it is a commercial solution from Tenable Security (http://www.tenablesecurity.com). Nessus also includes Nmap and provides additional reports on OS detection, what ports are currently open, and so forth. Nessus should not be implicitly trusted. False positives are a frequent occurrence and corroborating evidence is suggested before taking aggressive measures against any system.
Because Nessus is manageable even by new Linux users, it is often abused. As a result, Nessus probes and scans readily show up in Snort alerts. There are a variety of Snort signatures that detect a typical Nessus scan. These are normally classified as attempted-recon and as such fall under a classtype 2 categorization or have a Medium severity. Nessus scans are serious infractions and should be considered a potential threat. Just because they are classtype 2 does not mean the information gathered may not affect you later.
There are currently four different methods of downloading and installing Nessus. You can install directly from the web site, by running a local script, or you can build from source. Some distributions have precompiled binaries available. Refer to the documentation to determine which method suits your environment.
Once the program is installed and a certificate and user are added, start the Nessus daemon on the local server with the command:
# /usr/local/sbin/nessusd -D &You will not need to reboot the machine upon starting this daemon. However, you should automate startup of the Nessus daemon on the local server after a reboot by placing this command on a line in the /etc/rc.d/rc.local file. Remember, the Nessus daemon must be running for the Nessus client to run. The client is typically run locally but can also be run on another system by connecting to the local daemon. Keep the Nessus application current with the latest plug-ins by running the command /usr/local/sbin/nessus-update-plugins. This command can be placed in a cron job and run nightly. Some users prefer doing this manually.
Start the Nessus client from the command line as a regular user (or by executing the Windows binary). You are warned that all dangerous plug-ins, or those that have the ability to crash a system, have been disabled. This is the suggested method of running Nessus initially. These dangerous plug-ins include checks that may cause a service or system to crash and should only be used as when downtime will not adversely affect your environment.
Warning
Be aware that the information obtained from scanning machines on your network can be potentially dangerous. In the hands of a malicious user, the knowledge gained might be used to crash scanned machines. Burn the reports to CD and store them in a safe location. This way the data is not modifiable and can be secured offsite and removed from a mounted drive. It can be referred to later when updates and patches have been completed on affected systems.
There are varying levels of testing available for use with the Nessus client. Before trying anything familiarize yourself with the available plug-ins, preferences, scan options, and target selection possibilities. Security scans can be customized to be extremely nonintrusive and last for several hours, or they can blast away at a network or a single box while employing all the local machine’s available CPU power and memory to run the scan.
Figure 4-2 is a sample screenshot of available plug-ins that can be enabled during a test scan. Note the checkboxes to the far-right of the listed plug-ins.
A typical network scan can include multiple servers or systems at the same time. The more machines you select to scan, however, the higher the CPU load on your system and the slower the results. A typical scan can also be run overnight to reduce the load on the system and minimize the effect on the target systems. When complete, the scan’s final results are displayed in a window much like that shown in Figure 4-3. Here you can burrow down into the findings and view the warnings, notes, or security holes detected by Nessus, along with recommended solutions.
Save the report when it’s done. It can be useful later when running follow-up scans. The report itself is saved in a variety of formats, including NBE (a proprietary Nessus format), NSR (an older deprecated Nessus style), XML, HTML, LaTeX, ASCII text, or even in HTML format with pies and graphs. The last option makes for clean presentations when you are presenting findings to an audience.
Since Nessus attempts hundreds of different checks against the target systems, it generates many alerts with a wide variety of signatures. Here is a sample of the Snort output from a Nessus scan:
[**] [1:1228:3] SCAN nmap XMAS [**] [Classification: Attempted Information Leak] [Priority: 2] 03/21-22:01:41.686864 192.168.1.105:33977 -> 192.168.1.100:134 TCP TTL:38 TOS:0x0 ID:1147 IpLen:20 DgmLen:60 **U*P**F Seq: 0xEB5E3384 Ack: 0x0 Win: 0xC00 TcpLen: 40 UrgPtr: 0x0 TCP Options (5) => WS: 10 NOP MSS: 265 TS: 1061109567 0 EOL [Xref => http://www.whitehats.com/info/IDS30] [**] [1:2385:3] NETBIOS SMB DCE/RPC NTLMSSP invalid mechlistMIC attempt [**] [Classification: Attempted Denial of Service] [Priority: 2] 03/21-22:01:47.771281 192.168.1.105:53857 -> 192.168.1.100:445 TCP TTL:64 TOS:0x0 ID:14271 IpLen:20 DgmLen:269 DF ***AP*** Seq: 0x737329C2 Ack: 0xF9186CC Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 1654636883 34559859 [Xref => http://www.securityfocus.com/bid/9635][Xref => http://www.securityfocus.com/ bid/9633][Xref => http://cgi.nes sus.org/plugins/dump.php3?id=12054] [**] [1:2251:4] NETBIOS DCERPC Remote Activation bind attempt [**] [Classification: Attempted Administrator Privilege Gain] [Priority: 1] 03/21-22:01:48.364347 192.168.1.105:53861 -> 192.168.1.100:135 TCP TTL:64 TOS:0x0 ID:14354 IpLen:20 DgmLen:256 DF ***AP*** Seq: 0x73FB71F0 Ack: 0x957540DC Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 1654637476 0 [Xref => http://www.microsoft.com/technet/security/bulletin/MS03-039.asp][Xref => http://cve.mitre.org/cgi-bin/cvenam e.cgi?name=CAN-2003-0605][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN- 2003-0528][Xref => http://cve.mit re.org/cgi-bin/cvename.cgi?name=CAN-2003-0715]
Web page scanners
Another network scanner of note is nikto, a web CGI probe that performs comprehensive tests against web servers for multiple vulnerabilities. This includes detecting over 2,200 potentially dangerous files or CGIs on over 140 servers and problems on over 210 servers. Written by Sullo, it superseded the Whisker application originally written by Rain Forest Puppy (or RFP), who decided to abandon development of Whisker in favor of nikto. This application uses the LibWhisker libraries from Rain Forest Puppy Labs (rfp.labs) or http://sourceforge.net/projects/whisker/ as a base for all network detection. Nikto is not an overly stealthy tool. It tests a web server in the shortest time span possible and its probes are readily apparent in the web server’s logfiles.
Snort can easily detect a nikto probe. There are entire categories of signatures that define web attack and web CGI rules. Nikto appears plainly in Snort alerts. The name “nikto” may not be obvious, but a flurry of web CGI alerts should show up in the Snort logs when a scan is run against the web servers.
Here are just a few of the possible alerts that can be generated in response to a Whisker- or nikto-based scan. These are all classified as miscellaneous web rules. A URL points to more information on identifying Whisker-based scans. Detecting such a scan almost always indicates that the early stages of an attack are underway.
web-misc.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB- MISC whisker HEAD/./"; flow:to_server,established; content:"HEAD/./"; classtype: attempted-recon; reference:url,www.wiretrip.net/rfp/pages/whitepapers/whiskerids. html; sid:1139; rev:6;) web-misc.rules:# alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-M ISC whisker HEAD with large datagram"; content:"HEAD"; offset: 0; depth: 4; nocase; dsize:>512; flow:to_server,established,no_stream; classtype:attempted-recon; reference:url,www.wiretrip.net/rfp/pages/whitepapers/whiskerids.html; sid:1171; rev: 7;) web-misc.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB- MISC whisker space splice attack"; content:"|20|"; flow:to_server,established; dsize: 1; reference:arachnids,296; classtype:attempted-recon; reference:url,www.wiretrip. net/rfp/pages/whitepapers/whiskerids.html; sid:1104; rev:6;) web-misc.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB- MISC whisker tab splice attack"; dsize: <5; flow:to_server,established; content: "|09|"; reference:arachnids,415; classtype:attempted-recon; reference:url,www. wiretrip.net/rfp/pages/whitepapers/whiskerids.html; sid:1087; rev:6;)
Installing and running
nikto is simple. Download the source
code and uncompress it in a secure directory. Within the new
nikto/ directory, run the
nikto.pl Perl script. Be sure to define the
target host with a -h
<target> option. Here is how a sample
command appears.
# ./nikto.pl -h www.mydomain.comRefer to the help file for additional options you can tailor the scan for your environment to speed things up. Nikto can use an Nmap file as input and can generate output in several formats, including HTML.
Here are some sample results when nikto is run against an older Apache web server on a standard Linux machine. As you can see, there are several items that can and should be cleaned up.
# ./nikto.pl -h www.mydomain.com
-*** SSL support not available (see docs for SSL install instructions) ***
---------------------------------------------------------------------------
- Nikto 1.30/1.06 - www.cirt.net
+ Target IP: 192.168.0.10
+ Target Hostname: www.mydomain.com
+ Target Port: 80
+ Start Time: Sat Oct 11 08:17:36 2003
---------------------------------------------------------------------------
- Scan is dependent on "Server" string which can be faked, use -g to override
+ Server: Apache/1.3.26 (Unix) PHP/4.2.2
+ Allowed HTTP Methods: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND,
PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, TRACE
+ HTTP method 'PUT' method may allow clients to save files on the web server.
+ HTTP method 'CONNECT' may allow server to proxy client requests.
+ HTTP method 'DELETE' may allow clients to remove files on the web server.
+ HTTP method 'PROPFIND' may indicate DAV/WebDAV is installed. This may allow DAV
authorized users to consume system memory via large requests or fill disk quotas.
+ HTTP method 'PROPPATCH' may indicate DAV/WebDAV is installed. This may allow DAV
authorized users to consume system memory via large requests or fill disk quotas.
+ HTTP method 'TRACE' may allow client XSS or credential theft. See http://www.
cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details.
+ Apache/1.3.26 appears to be outdated (current is at least Apache/2.0.46). Apache 1.
3.27 is still widely used and considered secure.
+ PHP/4.2.2 appears to be outdated (current is at least PHP/4.3.0)
+ Apache/1.3.26 - Apache 1.3 below 1.3.27 are vulnerable to a local buffer overflow
which allows attackers to kill any process on the system. CAN-2002-0839.
+ /~root - Enumeration of users is possible by requesting ~username (responds with
Forbidden for real users, not found for non-existent users) (GET).
+ /icons/ - Directory indexing is enabled, it should only be enabled for specific
directories (if required). If indexing is not used all, the /icons directory should
be removed. (GET)
+ /index.html.en - Apache default foreign language file found. All default files
should be removed from the web server as they may give an attacker additional system
information. (GET)
+ /manual/images/ - Apache 2.0 directory indexing is enabled, it should only be
enabled for specific directories (if required). Apache's manual should be removed and
directory indexing disabled. (GET)
+ / - TRACE option appears to allow XSS or credential theft. See http://www.
cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details (TRACE)
+ / - TRACK option ('TRACE' alias) appears to allow XSS or credential theft. See
http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details (TRACK)
+ /manual/ - Web server manual? tsk tsk. (GET)
+ /test/ - This might be interesting... (GET)
+ 1632 items checked - 9 items found on remote host
+ End Time: Sat Oct 11 08:17:59 2003 (23 seconds)
---------------------------------------------------------------------------Some of the more obvious results are that both Apache and PHP should be updated to the latest version. The scan displays the most grievous security concerns and provides some suggested measures. The first line of the scan also indicates that there is no built-in secure socket layer (SSL) support in this version of nikto. Do not enable features you do not understand or that may be unnecessary. If the server your are scanning only supports SSL connections (port 443), consider running the scans through an open-source tool called SSL Proxy. There is also an older, alternative Whisker release that does support SSL at http://www.digitaloffense.net.
Other probe tools
Several useful tools exist that have more esoteric results, duplicate the functionality of the tools we discussed earlier, or are more difficult to use. You are invited to investigate these tools at your leisure.
- Firewalk
This tool enables an attacker to map out the access control lists of your firewall by using a variety of TCP/IP investigation mechanisms.
- Hping
Hping uses a variety of techniques to map networks, discover the configuration of firewalls, perform operating system fingerprinting, and make other configuration mapping. The next version of hping promises even more power.
- SNMPwalk
Part of the UCD-SNMP set of tools, this permits an attacker to enumerate a great deal of configuration information about a system whose SNMP ports are exposed to the Internet. SNMP can be a huge security hole, so the SNMP ports should be blocked.
Penetrate
Once the systems and potentially vulnerable services have been discovered, the next step is an attack. The attack can take a variety of forms. The attack may cause a system to execute code of the attacker’s choice. If the attacker has access as an unprivileged user, the attack may escalate the user account to an administrator-level access. The attack may simply crash a service or entire system (see Section 4.3 later in this chapter).
There are a myriad of penetration methods and the vast bulk of Snort signatures are built to detect them in progress. Automated attacks such as worms or scripts actually combine the Probe and Penetrate phases by simply launching attacks against a range of addresses (which fail against systems that are not vulnerable). If a rule exists that is designed to recognize one of these attacks, Snort will certainly detect these attempts.
Sometimes the attack is hidden in a Trojan horse —usually an attack program hidden in another. The attack sometimes contains a remote control utility that calls back to an attacker, giving the attacker a point of presence inside your network. An entire class of rules exist to watch for Trojan horse traffic.
Some of the most useful Snort signatures do not actually trigger on an attack attempt, but on the traffic generated by a successfully attacked host. For instance, an attack is launched against a Windows web server that attempts to trick it into returning a directory listing of the web root. One Snort rule watches for the string “The Volume in Drive C: has no label” coming from port 80 (or another configured web port). Very rarely will legitimate traffic trigger this rule. The nice thing about the signatures in the attack-responses.rules rule set is that it doesn’t matter what attack generated the traffic that triggered the alert—they are almost always true indicators of a successful attack.
Perhaps the best way to get up to speed on the different attacks is to examine the Snort rules themselves. Keeping an eye on resources like http://www.securityfocus.com and http://www.securiteam.com is a good idea, too. The list below gives some of the penetration methods (it’s by no means comprehensive).
Authentication grinding
If during the Probe phase a username/password prompt for a particular service is discovered, an attacker can use a script (or one of several password grinding tools available) to start guessing passwords. The script can either brute-force the passwords of various lengths by trying all possible combinations or use a dictionary of potential passwords. Usernames are fairly easy to discover since email addresses are very often the same as usernames. Alternatively, many operating systems and services have default usernames that can be guessed. If the authentication mechanism behind the discovered username/password prompt does not lock accounts after a certain number of bad password guesses (Windows does not lock the built-in Administrator account by default), an attacker can take as long as is necessary to discover passwords. Even diligent administrators who enable intruder lockout protections in their environment can be defeated by a web-based interface that does not use the same protection when authenticating users. Even with these measures in place, you are just making it take longer to guess the passwords. A patient attacker will throttle the speed of the guessing so as to not trigger lockout.
Buffer overflows
Buffer overflows represent at least 50% of newly discovered vulnerabilities. Simply put (very simply... it can get complex), when an application is running, it allocates memory for the different information it needs to keep track of—names, addresses, phone numbers, costs, item names, and so on. Very often, applications ask the system or the user of the application for information to insert into these memory locations. If the application blindly accepts whatever the user (or system) provides, problems can result.
Let’s say that an application asks for your name. It allocates 20 characters in memory for this information. If the user provides more than this number of characters and the application does not check for that possibility, memory past the previously allocated 20 characters can be overwritten with the user’s information. If the user is very crafty and provides a character length that forces the application to overwrite portions of memory that the system uses to run other programs, it may be possible to trick the system into running whatever you want it to run. This could be a variety of things: instructions to install remote control software, return the contents of a directory, dump the username and password database, and so on. Anything you can put in a small chunk of code can be run using this technique.
Most buffer overflows result in a service or system crashing. The real art in crafting a successful buffer overflow is determining how many characters to insert before the malicious code to get the code to run. This length is commonly referred to as the offset.
Application behavior boundary flaws
This is a difficult category to define. When a developer designs an application, he does not always anticipate the ways the application may be tricked into doing other things that are not intended. A great example of this are the techniques that tricked Windows IIS web servers into running a command shell from the system directories using Unicode characters to represent a “dot-dot-slash.” In most operating systems, a “../” moves a command shell up a layer in the filesystem. By crafting a URL with these Unicode characters and sending it to a vulnerable web server, it was possible to trick the web server into jumping out of its web root directory and into the system directory. From the there the attacker could execute any of the system applications—including cmd.exe, the command shell. Once a command shell running under the context of the web server is available, anything is possible.
This is just one example and there are many like it that affect a wide range of applications and operating systems. Please don’t think I’m picking on Microsoft. Snort is well equipped to catch most of the known variations of this class of attack.
System configuration errors
When a system is not configured according to industry-accepted best practices, security vulnerabilities can be exposed. If an account has a very poor password, it may be guessed, for example. If a firewall is misconfigured to allow dangerous ports through into the internal network, it may increase the chances of a successful attack against your environment. A fair number of Snort signatures catch some of this “low-hanging fruit.”
User input validation problems
One consequence of not checking what information a user supplies to an application was discussed in Section 4.2.2.2, above. Other, equally dire, consequences can result from not validating a user’s input. A rule of thumb when attempting to write secure code is, “Never trust anything a user or other process tells you.”
One common technique for exploiting careless user input validation is called SQL Injection. Most (really useful) web pages are built from the data contained in a database. If a web page asks the user for input (including things like login credentials), it is possible to replace what the web page is looking for with SQL code that gets passed to the database server on the backend. If this is properly crafted, it can make the database dump data that the user would normally not have access to—sometimes sensitive business data. It is also possible to insert data into the database, thereby poisoning the database and making it impossible to trust. The inserted data could also be used to create a user and password with high privileges if the database is used for authentication.
There are several Snort signatures that watch for this variety of attack, as well.
Persist
Once an attacker goes through the trouble of finding a vulnerable system, locates or builds the attack, and then successfully attacks the machine, it would be a nuisance to have to repeat the process every time he wants to access the system. It may be that between visits, the system gets attention from an administrator and is no longer vulnerable. Launching an attack multiple times against a system increases the chances of being noticed.
As a result, one of the first things an attacker does once a machine has been “owned” is make it easier to get back onto the system. The attacker may create an administrator-level user with a password that only he knows. He may simply acquire the username and password database from the system and crack the passwords using a password cracking utility (like John the Ripper or L0phtcrack ) to decrypt the passwords on their system. Once the passwords are cracked, the attacker can login as whomever he wants.
The attacker may install some remote-control software, too. This makes it easier to work remotely on the system. The most common of these tools is a utility called netcat. Netcat is a very flexible remote command-shell utility that is easy to install remotely and can be configured to run on any network port, making it possible to access through a firewall.
Most serious attackers attempt to hide evidence of their activity at this point by altering or deleting system and firewall logs. They may use utilities that hide the directories that hold their attack tools from the eyes of administrators.
If the attacker was an automated tool or a network worm, it may copy itself to system files, and ensure that it will survive past a reboot. It may go so far as take steps to hide itself, too.
Propagate
Once the attacker has an established presence on a system, the next move is to see what else is available. The attack phases begin anew with the compromised system as the source of the activity. The attacker will try to map the internal network (or the network that contains the compromised system). The newly enumerated machines will then be attacked, if they are interesting to the attacker. If the attack was a worm, this phase is sometimes the most damaging. The worm attempts to infect (probe and penetrate) other systems on the local network (or systems on the public Internet).
There is a concept called implied trust , in which a username and password that works on one system (or group of systems) works on another system. For example, if the system that was compromised is a Linux system, the username and password that works on this system may also work on the organization’s Windows systems, as well. While the concept of “single sign-on” is an administrative aid, it can be a detriment in the event of a successful attack.
The only good news is that, if an attack gets to this point, it may be possible to detect this second round of attacks with your Snort systems.
Paralyze
This is the ultimate goal of a targeted attack, in which the attacker goes after your environment with a goal in mind. The goal may be to steal or destroy data, bring your systems down, or attack another organization from one of your systems, making you look guilty. The attacker looks for what I call the “soft, chewy center” of your network. This is most often a database that hosts your organization’s proprietary data, financial information, inventory, or even email.
If a worm was the source of all your trouble, the result in this phase may be clogged network connections and crashing systems.
Denial-of-Service
Sometimes the goal of an attack is not to steal something from you, but to make your systems or network unavailable either by crashing a system or saturating the resources of the target systems or network connection. This form of attack has consequences beyond inconvience. Imagine a clothing company that does the bulk of their sales through an online catalog. If people can’t log into the web site, they can’t buy sweaters and polo shirts. This loss of business can have significant impact in a short time. (This is what happened to eBay, Yahoo, and other large web services in February of 2000.)
A large number of signatures help detect this category of attack. With a combination of signatures, portscan detection, automated blocking, and the new thresholding and suppression rule types, Snort can be a very good countermeasure against denial-of-service (DoS) attacks.
IDS Evasion
When dealing with networks that use intrusion detection systems such as Snort, you must be aware of any other tools that can bypass security restrictions. If an attacker can disguise his activities from your IDS, you may not be aware of the attack until it is too late. There are a variety of strategies employed by attackers to hide their actions.
Some of the tools we’ve already discussed have components that help hide their traffic from your IDS. Nmap has the ability to throttle the packets it sends when scanning so that packets are sent so slowly that they do not trigger portscan detection mechanisms. Another nmap evasion technique is to generate numerous packets in addition to the actual scan. These packets have forged source addresses and the actual scan gets lost in the noise. This technique does not keep the IDS from noticing the portscans; instead, it generates so many alerts that determining the actual source is more difficult.
The web scanner nikto has an IDS evasion mode, as
well. As of Version 1.10, LibWhisker’s
anti-IDS methods have been enabled in the event you wish to test your
IDS. Depending on how recently you updated your signatures, the
anti-IDS feature may or may not be able to circumvent your IDS. It
may have greater luck bypassing proprietary intrusion detection
systems whose signatures have not been recently updated. Refer to the
help file for additional options. You enable the IDS evasion mode by
appending the -evasion+ option and the preferred
IP address.
Another strategy for evading detection is to encrypt traffic; encrypted packets will not match the signatures and thus won’t trigger alerts. sslproxy is a useful tool for encrypting web scans; it negotiates an SSL connection with an SSL-enabled web server. The proxy then sends the scan across this encrypted tunnel. Any web-based attack activity can be sent across the tunnel, effectively making it invisible to the IDS.
Stick is a program that is still in the works. Its author is considering releasing to the public. It is labeled an “IDS stress tool” and is used to evaluate the bottleneck in a production environment. During testing it caused the ISS Real Secure IDS Version 5.5 to turn itself off due to errors. The ISS Real Secure sensor died two seconds after the attack with Stick began. The same results occur with other IDS solutions, including Snort.
The concept behind Stick is a simple one: overwhelm a network intrusion detection system with so many alerts using valid signatures that the security administrator can no longer distinguish between false positives and legitimate alerts. According to the author, Stick uses a Snort rule set and a C program via lex that, when compiled, produces an IP packet capable of triggering that rule from a spoofed IP range (or all possible IP addresses) into a target IP range. A function is produced for each rule and a loop executes all rules in random order. The tool currently produces 250 alarms per second. A Linux-based Snort IDS will hit 100% CPU and start dropping packets at this level of attack. So far, the author has only released the Stick source code to IDS vendors. More information regarding Stick is available in the author’s “Papers” section. The one titled “Fun with Packets: Designing a Stick” by Coretez Giovanni is particularly useful for explaining how Stick works and how to overwhelm IDS devices.
Two other tools that can be used for stress-testing an IDS machine prior to gaining access or slipping in undetected are Snot and Fragroute . The former is similar to Stick in that it triggers false Snort alerts using a Snort rules file for its input. This both overwhelms and confuses the IDS since the security administrator can no longer tell the difference between the false positives caused by snot or any real alerts triggered by the attacker. Snot is basically an IDS evasion tool. It attempts to randomize the sequence of rules or alerts generated so that a “Snot generation” rule is not triggered by Snort. Snot is easily executed on a Linux or Unix-based system. Here is an example of Snot:
snot -r snort.rules -s www.somerandomhost.org/24 -d somesnortuser.com -l 10Snot first reads in the snort.rules file, sends packets with a source address from anywhere on the CIDR-notated /24 network that www.somerandomhost.org resolves to, and then transmits the packets to somesnortuser.com, sleeping for up to 10 seconds per packet.
Tip
If your CIDR notational skills are lacking, refer to the following URL for a refresher course: http://jodies.de/ipcalc/.
However, there are rules within Snort that do account for these types
of attacks and do alert administrators that a Stick/Snot attack is
underway. Using the -z command-line switch in
concert with the stream4 code, Snort generates
alerts warning the administrator when it sees these types of anti-IDS
attacks. The -z
switch runs
without arguments. If the -z switch is specified,
Snort only sends alerts (for TCP traffic) on streams that have been
established via a three-way handshake or streams where cooperative
bi-directional activity is observed, i.e., where some traffic went
one way and something other than a RST or FIN was seen returning to
the originator. With the -z option enabled, Snort
completely ignores TCP-based Stick/Snot
“attacks” and logs other malicious
packets normally. In other words, Snort operates as usual and is not
confused by an IDS evasion tool.
If you suspect a Snot/Stick attack is underway against your system,
initiate Snort using the correct flags. For example, here is how you
might start the Snort command on machine A with the
-z
option enabled:
# snort -i eth0 -c /etc/snort/snort.conf -l /var/log/snort -zRunning Snot on machine B while targeting machine A appears as follows:
# /usr/local/bin/snot -r snortrules.txt -d 192.168.10.254 -s 192.168.10.0/24 -n 16384The snortrules.txt file is a default snort.conf configuration in which all rules are gathered in one file. The address 192.168.10.254 belongs to machine A, the target of the Snot attack. As such, machine A operating as a Snort sensor continues to see only regular traffic and not a surplus of false positives generated by a Snot attack.
The second application, Fragroute , intercepts, modifies, and rewrites egress traffic to a given host. It complicates normal traffic to such a degree that an IDS does not know what to do with certain packets. It features a simple ruleset language to delay, duplicate, drop, fragment, overlap, print, reorder, segment, source-route, or otherwise monkey with all outbound packets destined for a target host, with minimal support for randomized or probabilistic behavior, unlike Snot, which attempts to randomize the inserted rules. According to the author, Dug Song, this tool was written in good faith to aid in the testing of network intrusion detection systems, firewalls, and basic TCP/IP stack behavior. He, as well as many others, asks that security administrators not abuse this software. It is provided for testing local network security.
The Fragroute application does require additional libraries, specifically the libevent file. This library is also available for download from Dug Song’s site. Once installed, the fragroute application is then compiled. The binary is placed in the /usr/local/sbin/ along with Firewalk and the Nessus daemon. The fragroute program uses the following syntax for execution:
# /usr/local/sbin/fragroute -f <file> <destination>Replace the <file> variable with a
snort.rules file and the
<destination> variable with a valid IP
address, preferably one associated with an IDS monitoring box. There
are additional variables that randomize the rules, change the TCP
packet size, and set other options. Familiarize yourself with this
application’s use on a test machine before
attempting to use it on a production IDS box. The last thing you want
to do is bring down an operating IDS and blind yourself to real
attacks.
Snort can also detect these types of attacks. There is a default fragroute rule included with the standard Snort rules. Here is a sample alert generated by a fragroute attack:
alert ip any any -> 216.80.99.202 any ( sid: 1791; rev: 2; msg: "BACKDOOR fragroute trojan connection attempt"; reference: bugtraq,4 898; classtype: trojan-activity;)
With the current version of Snort, most of these IDS evasion techniques can be detected and countered. Like most aspects of network security, it is a case of the attackers developing new methods and the defenders developing new countermeasures against the attacks. Once these countermeasures become accepted practice, the attackers develop counter-countermeasures, ad infinitum.
Sites of Interest
|
Broadband Reports | |
|
CERT | |
|
Cryptcat | |
|
DoS Help | |
|
Firewalk | |
|
fragroute | |
|
hping | |
|
ID Serve | |
|
IEEE OUI and Company_id Assignments | |
|
IP Calculator / IP Subnetting | |
|
IP-Tools | |
|
ISECOM Security Tools | |
|
John the Ripper | |
|
L0phtCrack LC4 | |
|
libevent | |
|
LibWhisker | |
|
Netcat | |
|
GNU Netcat | |
|
Nessus | |
|
Nikto | |
|
Nmap | |
|
The Packetfactory | |
|
Packetstromsecurity | |
|
Tenable Security | |
|
Razor Security | |
|
Reverse WWW Shell | |
|
Sam Spade | |
|
SANS | |
|
SecurityFocus | |
|
SNMPwalk | |
|
Snot | |
|
SSL Proxy | |
|
Stick | |
|
Virusdot.org |
http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php |
|
Whisker+SSL |
[1] The Analysis Console for Intrusion Detection (ACID) is an open source project developed by Roman Danyliw at the CERT coordination center, as part of the AIRCERT project. It uses a PHP-based web application that can act as the frontend for several tools. See Chapter 10 for more about ACID.
Get Managing Security with Snort & IDS Tools now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
