| 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. 4.2.1 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. 4.2.1.1 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.
 | 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 nslookup or dig commands.
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. 4.2.1.2 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. Figure 4-1. The main interface for the Nmap Front End tool 
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 seconds
Nmap 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. [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.
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.  | 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. 4.2.1.3 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. | 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. Figure 4-2. Enable or disable available plug-ins in Nessus depending on the type of scan 
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. Figure 4-3. Viewing the final Nessus report 
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]
4.2.1.4 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://www.wiretrip.net/rfp/ 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.com
Refer 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. 4.2.1.5 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.
4.2.2 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). 4.2.2.1 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. 4.2.2.2 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. 4.2.2.3 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. 4.2.2.4 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." 4.2.2.5 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. 4.2.3 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. 4.2.4 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. 4.2.5 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. | 