Types of Security-Related Risks

‚  < ‚  Free Open Study ‚  > ‚  

Types of Security- Related Risks

This section provides details concerning specific types of security-related risks that occur today, their impact, and how to obtain data concerning their probability of occurrence.

Risk Categories

As expected, the specific categories of security-related risks that occur today are very diverse. Here are the most common ones.

Break-ins

Break-ins are unauthorized access to one or more systems in which the attacker masquerades as a legitimate user, usually (but not always) by entering the correct username and password. When authenticated as a user , the attacker can do virtually anything that the legitimate user can do, including read email messages in the user's email queue, send messages, access the home directory and any subdirectories and files therein, and so on. In most break-ins, however, the intruder's goal is not simply to reach another user's account. The goal instead is often to gain shell access, meaning access to a command shell such as /bin/sh or /bin/tsh in UNIX or cmd.exe in Windows systems. With access to a shell, intruders can run programs or scripts that can expand the intruder's access to the system and/or network, usually by escalating the privilege level, as you will see shortly.

Too often, unfortunately , senior-level managers trivialize break-ins, thinking they are caused by pimply-faced teenagers who cannot really cause any damage. Sometimes this preconception is true, but a large body of evidence strongly indicates that break-ins are performed by a wide range of perpetrators, often even by members of an organized crime ring or a country's intelligence agency. Break-ins can result in theft of valuable data and/or software. Break-ins to systems of several vendors , for example, have resulted in theft of source code for operating systems and other products. Additionally, a break-in can result in compromise of integrity. Consider, for example, the break-in to a U.S. government laboratory once in which the intruders changed the value of pi in a critical scientific application to 3.8!

Even if data or programs are not stolen or altered , break-ins can result in sizeable loss. A break-in into a single system in a National Aeronautics and Space Administration (NASA) site once disrupted space flight operations for several weeks. The victim machine, operated by the Missions Operation Directorate (MOD), was critical in controlling functions for manned space flights . This machine had to be carefully inspected, restored, and tested before NASA officials approved it for use in operations again. The financial cost was high; the delay substantially ran up the cost of the launch.

Unauthorized Execution of Programs or Commands

It is not necessary to actually break into a system to accomplish an intruder's goals. A perpetrator can also exploit a vulnerability in a victim system that enables the perpetrator to run one or more rogue commands on that system. A clever perpetrator can then do almost anything on the compromised system. One of the most common ways to run rogue commands is to create a buffer overflow condition. A buffer overflow condition results from more input being received than there is available memory, often causing the excess input to overwrite commands in memory that are waiting to be executed. Not only can existing commands be overwritten, if done correctly, the attacker's commands will be positioned in the buffer so that they are actually executed.

One of the most common methods of running unauthorized commands on victim systems is exploiting the Berkeley Internet Name Domain server (BIND). BIND is the most commonly deployed implementation of the domain name system (DNS). DNS is an essential Internet service in that it enables systems to locate other systems simply by using hostnames (for example, system.domain.co), converting each hostname to an IP address such as 131.243.2.3 (or vice versa). Functions within certain versions of BIND, including nxt, qinv, in.named, and others, have a number of exploitable bugs that can result in outcomes such as a buffer overflow, resulting in the capability to execute commands with root (superuser) privileges. For example, some versions of BIND do not correctly validate NXT records. An attacker can consequently send a huge amount of input in these records to cause a buffer overflow and then run a rogue program at the same privilege level that the name server has.

Attackers who initiate BIND attacks seldom stop after exploiting one or more vulnerabilities. They also frequently purge system logs to cover their tracks and then (if they have not already gained root access) download and run tools to obtain a root shell. Next they run network-scanning tools to locate other systems with the same BIND vulnerabilities, and then they attack these systems in the same manner. The toll in terms of number of machines compromised within a short period of time is often very high.

BIND attacks pose a very serious risk factor because of the prevalence of BIND on the Internet. In fact, a consensus effort to determine the exploited vulnerabilities identified BIND-based attacks as the most frequent (see the next sidebar). Both Linux and UNIX systems are vulnerable to BIND attacks.

Unauthenticated remote users might also be able to run rogue code on systems that run unpatched versions of LPRng. LPRng is a frequently used software package in FreeBSD UNIX and certain versions of Linux, and it replaces the Berkeley Standard Distribution (BSD) lpd printing service. This software has a format string vulnerability, a problem caused by missing format strings in function calls. Format strings help ensure that received input is processed properly. This vulnerability enables user-supplied arguments to be passed to a susceptible function call.

Privilege Escalation

Privilege escalation means gaining privileges without being authorized to do so. If attackers are not able to gain privileges immediately when they access a system, they next usually attempt to escalate privileges by running programs that exploit vulnerabilities. When the intruder becomes a superuser, that person has complete control of the victim system (in most operating systems). Worse yet, if trusted access mechanisms between hosts are in place, the intruder might now be able to easily gain superuser access to other systems that trust the original victim system.

A good example is recent attacks involving the Remote Procedure Call (RPC) in certain flavors of UNIX and Linux systems. Attackers have been exploiting RPC weaknesses in functions such as rpc.ttdbserverd (ToolTalk), rpc.cmsd (Calendar Manager), and rpc.statd. Successful exploitation (by running carefully constructed programs) results in unauthorized root access.

An intruder toolkit called "Ramen" is also frequently used in victim hosts. This publicly available toolkit exploits vulnerabilities in FTPD, rpc.statd, and LPRng. Ramen not only gives unauthorized root access, it also contains a mechanism for self-propagation.

The SANS Top 10 Vulnerabilities

Vendors keep coming out with new patches, yet security breaches continue to occur at accelerating rates. Why? A group of experts determined that the overwhelming majority of known incidents occur through exploitation of a limited number of vulnerabilities. These include (in order of frequency of successful exploits) the following:

  1. Vulnerabilities in BIND, particularly in nxt, qinv, and in.named, that can lead to root access in any system that runs BIND.

  2. Vulnerabilities in CGI programs and application extensions in web servers that can allow unauthorized access to files and directories, execution of rogue commands, and a variety of other outcomes.

  3. Remote Procedure Call (RPC) security bugs, particularly in rpc.ttdbserverd (ToolTalk), rpc.cmsd (Calendar Manager), and rpc.statd, that can enable attackers to remotely reach network services and then run commands as root in UNIX and Linux systems.

  4. A Remote Data Service (RDS) security flaw in the Microsoft Internet Information Server (IIS) that can allow attackers to remotely run rogue commands with Administrator privileges on Windows NT and Windows 2000 hosts.

  5. Buffer overflow problems, pipe attacks (which allow unauthorized users to execute rogue commands), and multipurpose Internet mail extension (MIME) exploits that result in root compromise in UNIX and Linux systems.

  6. Buffer overflows in the sadmind and mountd programs in Solaris that can be exploited to allow attackers to gain root access.

  7. File sharing through network file system (NFS) mounts and Windows shares that allows anyone to gain access to file systems and that allows too much access (in other words, write access) once access is achieved.

  8. Easy-to-guess or nonexistent passwords, especially for superuser accounts.

  9. Buffer overflow conditions in Internet Mail Application Protocol (IMAP) and Post Office Protocol (POP) configuration that result in unauthorized root access in Unix and Linux systems.

  10. Default SNMP community strings that allow perpetrators to remotely access (and then reconfigure or take down) devices or gain access to SNMP traffic that contains sensitive network configuration and other data.

One of the single most important things an information security effort can accomplish is to ensure that at least these 10 vulnerabilities are patched whenever possible.

Exploitation of Common Gateway Interface (CGI) Programs

The majority of today's web servers have common gateway interface (CGI) programs that allow users to interact with web pages. The fact that these programs are typically so easy to find and execute at the same privilege level as the web server on which they run makes CGI programs a favorite target of attackers. Some CGI programs even allow users to start up programs by entering the name of the program or routine to invoke. Flaws in the design and/or implementation of these programs can allow attackers to breach security in a number of ways, including executing rogue commands or programs (including back door programs), defacing web pages, accessing files and directories (sometimes including system files and directories) not intended for web user access, and escalating the level of privilege.

Additionally, web servers frequently have sample CGI programs installed by default. These sample programs are usually included for demonstration purposes. Too many webmasters fail to remove these programs; weaknesses in these programs can also be exploited.

The cost incurred by organizations that experience web attacks, regardless of whether a CGI or another exploit has been used, is generally much higher than people think. Because web servers are now the foundation of e-business, CGI and other exploits can, for example, result in one or more web servers becoming nonfunctional for extended periods of time, causing a substantial loss of business.

Denial-of-Service Attacks

Denial-of-service (DoS) attacks are reported to incident response teams more than any other type of attack. Misconceptions about denial-of-service attacks abound, however. One widely held misconception is that denial-of-service attacks invariably crash applications or hosts. Although the majority of reported DoS attacks do indeed cause applications or hosts to crash, a DoS attack can also cause a system or function to slow down or not run properly. A poorly written CGI program, for example, can crash a web server through a buffer overflow or other condition, but it can also cause CPU overutilization, making the victim host unresponsive .

Several types of DoS attacks are now almost legendary because they have occurred so many times:

  • SYN flooding. In a SYN flooding attack, a hostile host sends a flood of SYN packets to a victim host. SYN packets are sent by a host that wants to start a TCP connection with another host (which we will also call the "receiving host"). The receiving host monitors the status of the connection attempt as well as the connection itself, if a connection is established. Monitoring the status requires resources. When a connection is closed, the resources used in monitoring the connection no longer are needed. As more connections occur, more resources are allocated to monitor the state of the connections. Under normal conditions in which a normal number of connections are in place, the receiving host has more than enough resources to monitor all the connections to it.

    But what if a flood of SYN packets is sent, and the receiving host gets no subsequent packets that are part of the normal process of completing the connection? Simply put, the receiving host runs out of resources, making the victim host unresponsive in the case of moderate resource exhaustion or causing it to crash in the case of more severe resource exhaustion. Because SYN flooding attacks are easy to initiate, they occur frequently. Fortunately, most vendors of operating systems have addressed the problem by having the operating system drop partially open connections.

  • Teardrop attack. A teardrop attack is another type of DoS attack.The IP protocol is a robust protocol designed to deal with a wide range of devices, systems, and types of networking. If a system is going to send packets that are, say, 1 kilo-byte (1,024 bytes) in size, network devices such as routers might not be able to handle packets that are this large. They might instead be able to handle packets that are only half this size . In this case, IP automatically divides the original packet into tinier parts that are able to make their way through network devices that cannot handle larger packets, a process called fragmentation.

    When the fragmented packets arrive at the receiving host, this host reassembles them into the packet that the sending host originally created. Fragmenting packets is useful because it provides a practical and reasonably efficient way to transport data across a network while still preserving the accuracy of the data. An attacker can abuse the fragmentation process, however, by causing the receiving host to receive values in packets it is not programmed to process. In a teardrop attack, one packet fragment is placed within another so that when the receiving host receives this set of packet fragments , the resulting values (in terms of offsets) are out of range. The receiving machine goes out of control and crashes.

    There are many variations of the classic teardrop attack as well as many other types of packet fragmentation attacks. An attacker can, for example, write a program that divides packets into fragments in a manner that causes subsequent packets to overwrite portions of the initial fragment.

  • Smurf attack. Still another kind of denial-of-service attack is a smurf attack. In this kind of attack, a target host is victimized when an attacker falsifies ("spoofs") the origination or source address to be the target host's address. The attacker (or, more properly, a program that runs on behalf of the attacker) releases a flood of ping packets or ICMP echo requests destined for all the hosts on the local network. This is accomplished by having the broadcast address as the destination. A network broadcast address of a network has a particular IP address that is used for sending packets to every host within the local network.

    When the ping or ICMP echo request packets reach the broadcast address, these packets also are sent to the other hosts. They respond by replying to the source address, the address of the targeted host. The flood of replies can have several effects, the most likely of which is causing the target host to crash or, with a little luck, perhaps slowing it down to a crawl instead due to having to process such a barrage of packets. Most operating system vendors have developed patches that correct this problem, although network filtering that limits broadcast traffic is another viable solution.

Ping

Ping, the "packet Internet groper," is a protocol designed to determine whether or not a host is alive on the network (that is, whether it is running and responsive ). Ping transmits a group of characters , usually a reasonably small group (typically fewer than 100 bytes), and then waits for the host that has been pinged to respond. One of the primary uses of ping is determining whether a particular host has crashed.

  • Ping-of-death attack. Still another classic type of DoS attack is the ping-of-death attack. This attack creates a buffer overflow condition, something that results from having too little memory available for incoming data to be processed. The exact way in which a buffer overflow condition is handled depends on a number of factors, but one possible outcome is exhaustion of memory that causes an application or system to crash.

    The trick to a successful ping-of-death attack is to send ping packets that exceed the maximum size, namely 64KB in TCP/IP. The receiving host might not be programmed to reject the oversized packets and might consequently go into a buffer overflow condition. This problem has mainly (but not exclusively) affected Microsoft operating system products, most of which crash with the notorious blue screen of death (BSOD) appearing. Fortunately, patches that fix this problem are now routinely available and are usually incorporated into operating system products that were vulnerable only a few years ago.

  • Land attack. A land attack capitalizes on the fact that properties of packets usually adhere to certain constraints. Normally, for example, SYN packets do not have the same source and destination IP addresses, nor are the source and destination ports normally the same. If an attacker sends SYN packets that have these or other characteristics in a land attack, the receiving host might go into some kind of abnormal state, causing it to crash.

  • WinNuke attack. A WinNuke attack capitalizes on a weakness in the TCP/IP implementation in certain versions of Windows NT. In this attack, a perpetrator sends out of range input (that is, input with parameters that are not within the range the receiving host expects) to a victim host through a connection established on TCP port 139. Massive over-allocation of CPU in dealing with this abnormal condition causes the victim host to crash. The problem, which is fixed in Windows NT 4.0 Service Pack 3 and higher, is due to a failure to check whether input is within an expected range.

  • Distributed denial-of-service (DDoS) attacks. Although similar in many respects to conventional denial-of-service attacks, DDoS attacks are different primarily in that they require taking over hosts that are then assigned various roles in the impending DDoS attack(s) through installation of special, malicious software. Note also, however, that DDoS attacks can be initiated from one's own systems, too. DDoS attacks involve master, handler, and zombie hosts:

    • Zombies are agents that actually release a flood of packets that bring down hosts and also being the network to a standstill. Zombies do not act on their own, however; they release a packet flood only if instructed to do so by another host, namely a handler (see next bullet).

    • Handlers are really nothing more than intermediate machines that neither initiate an attack nor release the packets that flood the victim network. They instead perform tasks such as confirming that agent software has been installed in hosts (zombies) throughout the network and that it is ready to work. Handlers thus query the zombies at designated intervals. Handlers also receive a signal from the master, another host typically not placed within the network in which the DDoS attack is to occur, to initiate a DDoS attack to the agents, as shown in Figure 2.1. (See step 1 in this figure; the handler is the host with the circle around it). The handler in turn then sends a signal (see step 2 in Figure 2.1) to the zombies (all other hosts shown in the left side of Figure 2.1) to release a barrage of packets.

      Figure 2.1. Initiating a DDoS attack to the agents.

    • The third accomplice in a DDoS attack is the master. The master is the host that is usually directly under the attacker's control. It is used to direct any handlers to send the command to release a flood of packets to the zombies.

      DDoS attacks in 1999 and 2000 caused major financial loss and/or disruption for a number of institutions, including the University of Minnesota, ZDnet, eBay, E-Trust, Amazon.com, and others. The major threat is of a prolonged outage , although the cost of investigating hosts for evidence of compromise by DDoS tools and restoring the integrity of these systems can also be very high. Many types of DDoS attack tools have been identified. One, Shaft, even builds in its own detection mechanisms, enabling it to avoid being detected by intrusion-detection programs. Additional DDoS tools that have been identified include Trin00,Tribe Flood Network (TFN),TFN2K, Slice3, Stacheldracht, and others.

Web Defacement

Web defacement refers to unauthorized altering of the content of one or more web pages at a web site. Web defacement, in and of itself, is a significant threat in that an altered web page can lead to the following consequences:

  • Embarrassment [1] for the organization that has experienced the web page defacement.

    [1] See www.alldas.org or www.antionline.org for reports of web defacements. The sheer number of such reports is likely to startle anyone who has not visited these sites before.

  • Denial of service. Customers cannot connect to an organization's web site to order products, services, and so forth during times when systems and network devices are down or network routes are flooded.

  • Dissemination of erroneous information (including pricing information, information about corporate policies, and so on) that can result in one or more negative outcomes (such as lawsuits, a negative image, and so on).

Another important but often overlooked facet of web defacements is that they are often only the beginning of things to come. Many web defacements are followed by full-scale attacks on hosts within an organization. Web defacements should thus also be viewed as a kind of advance warning about impending attacks.

Virus and Worm Attacks

Viruses are self-reproducing programs that typically spread through user actions (such as attaching infected macros, sharing infected disks, and so forth). Worms are similar to viruses in that they are self-reproducing, but worms typically are transmitted over networks independently of user actions. Here is some more information about each:

  • Viruses. Viruses generally infect system files, applications, or macro executables in programs such as Microsoft Excel or Word. Viruses use a variety of mechanisms to cause themselves to become executed as well as to reproduce themselves . For example, many macro viruses cause the application that uses macro routines to execute a rogue Save As that results in the virus becoming executed. All things considered , viruses are not very glamorous, but they constitute one of the greatest security-related threats in today's computing environments. Antivirus vendors such as Symantec, Network Associates, and Finjan have estimated that there are currently more than 50,000 viruses in the wild today. Virus infections can rapidly become widespread, causing catastrophic consequences such as loss of hard drives and corruption of system or data files.

  • Worms. Worms are like viruses in that they are self-reproducing programs, but unlike viruses, worms can spread independently of user actions. In one sense, worms can be viewed as programmed cracker attacks. The best-known worm is probably the Internet Worm, which in 1988 infected thousands of UNIX systems that were connected to the Internet. Many worms with far more destructive and disruptive effects have surfaced since then, however. The Adore Worm, for example, has infected tens of thousands of Linux systems. Worms constitute a special level of threat because they work independently of human intervention. By the time people realize that worms have been reproducing over a network, hundreds of systems might be infected, causing data deletion, the need to restore systems, and many other undesirable outcomes.

Viruses and Worms

The distinction between viruses and worms, while still useful to some degree, is becoming less meaningful. This is because self-reproducing codes now often use a variety of mechanisms to spread themselves. Consider, for example, the W32FunLove.4099 worm, malicious code that infects systems such as Windows 98, Windows NT, and Windows 2000. This worm can spread when a user hits a web site, something that is dependent on user actions (like a virus) but that can also spread independently (like a worm) by finding unprotected shares. Shares are mechanisms for remotely reaching file systems in Windows systems.

Malicious Active Content

Another serious and ever-growing threat is the threat of malicious active content (also called mobile code and executable content languages). Active content comes in many flavors: ActiveX, Java applets, JavaScript (not to be confused with Java), VBScript, and others. Active content was developed with the intent of expanding web functionality; animation, sound effects, and so forth are all the product of active content.

Active content is downloaded into a machine that has connected to a web site and then is executed on that machine. Most of the existing implementations of active content are safe, but some are malicious, causing outcomes such as system crashes, halting of the execution of other active content executables running at the same time, a proliferation of windows on the desktop, capturing sensitive data and sending it to the address of a perpetrator, and so forth (see the following sidebar). The problem is especially serious with ActiveX. ActiveX controls, unfortunately, have almost no built-in execution constraints, enabling them to reach files on the system on which they run and even to initiate network connections after they are downloaded into a system. The only real security constraints in ActiveX are as follows :

  • The creation of zones (sites from which ActiveX controls are allowed to be downloaded) within browsers such as Internet Explorer.

  • Authenticode, a feature that allows the recipient of an ActiveX control to examine a certificate that accompanies the control to determine who the author of the control is. Authenticode might sound desirable from a security perspective, but in reality, it is less than desirable in that it is entirely post-hoc in nature. In an extreme scenario, a user could download a malicious ActiveX control that causes all kinds of mischief, only to find that the alleged author's identity is spoofed. In fact, at the time this chapter was written, a Microsoft employee's identity was spoofed in a Verisign certificate; this attests to the potential problem of tracing a user's identity.

Malicious Active Content Executables

Malicious active content executables are not just some theory or "proof of concept." Here are some examples of some of the many types of malicious Java applets:

  • Applet Killer. Kills any other applets that might be running in the same browser

  • AttackThread. Fills up the screen with more and more black windows

  • DemonDialer. Initiates an outgoing phone call

  • DiskHog. Fills up the hard drive with garbage

  • Known file. Copies any file on a target system

  • Pickpocket. Steals information from the Java Wallet

  • Wasteful. Causes excessive CPU consumption

Several malicious ActiveX controls are out in the wild, too, although they are outnumbered by malicious Java applets. The following are some malicious ActiveX controls:

  • RadioActiveX. Tricks Quicken into sending a check from a user's banking account

  • Exploder. A fully signed control that causes the W9X system that downloads it to shut down

The good news is that, to date, not too many incidents have resulted from downloading malicious active content executables. Many organizations block active content at their external gateways, greatly reducing the risk that active content can introduce. The bad news is that we are probably only at the tip of the iceberg as far as malicious active content executables go. Because of the immense popularity of the Web, perpetrators know that web browsers provide one of the best ways to introduce malicious code into a remote network.

Back Doors or Remote Control Programs

Back doors (sometimes also referred to as trap doors ) are methods (often in the form of programs, although not necessarily ) set up in victim systems that allow attackers to readily regain access to those systems when the attackers want to do so. A simple type of back door is an illegitimate account that an attacker creates. This account often is given an innocuous name that system administrators are not likely to notice as they look through the names of user accounts. An example of a back-door program is the previously discussed Ramen toolkit. Another is /tmp/bob in UNIX and Linux, which is functionally nothing more than an inetd [2] configuration file that contains one line that opens up a remote root shell when the line is sent to inetd. This allows anyone to log in via the telnet program by connecting to a predesignated port. Especially dangerous back-door programs that give an attacker superuser access (using encrypted sessions) to compromised systems also exist in Windows 9X,Windows NT, and (to a lesser degree) Windows 2000. The names of some of these programs include BackOrifice, BackOrifice2000 (BO2K), SubSeven, and NetBus.

[2] The inet (Internet) daemon. In UNIX and Linux, a daemon is a program that runs in the background and "wakes up" when it receives network input through designated ports.

Spoofing Attacks

IP spoofing is a type of network attack that can be directed against any host that deals with IP traffic.The goal of an IP spoofing attack is to establish a connection with a client unknown to a server by making that client appear to be a legitimate client, and then to exploit the relationship between the server and the bogus client to gain unauthorized access. Here is a well-known way to perpetrate an IP spoofing attack:

  1. Make the legitimate client unable to respond to the target server (see step 1 in Figure 2.2). This can be accomplished through limited SYN flooding, making the service or daemon that receives input from each port wait for input that will never come, thereby making the machine unresponsive to other inputs (such as connection request acknowledgements from other servers). This step is necessary because if the legitimate client were able to respond to the target server, the bogus client would not be able to "break in" to their communication.

    Figure 2.2. The sequence of events in an IP spoofing attack (the server's PSN is shown in dark letters ).

  2. Send a SYN packet from the bogus client to the target server to request that a connection be opened (see step 2 in Figure 2.2). This packet must indicate that the connection request is from the legitimate client (for example, it must bear the IP address of the legitimate client), even though in reality the packet must originate from the bogus client. The bogus client's request packet includes the initial packet sequence number (PSN) for that client.

  3. The target server sends a SYN packet to the legitimate client containing data such as the server's PSN and the client's PSN incremented by one (see step 3 in Figure 2.2). The legitimate client has been SYN flooded, however, so the legitimate client will never respond to this packet.

  4. The connection request is allowed if the client increments both PSNs (that is, for both the client and the server) in a manner that the server expects (see step 4 in Figure 2.2). The software running on the bogus client must then send a reply SYN packet containing the source address of the legitimate client with appropriate PSNs (one for the client and one for the server) incremented by one.

Deriving the client's PSN is easy; this PSN is an arbitrary number of which the server is not initially aware. The challenge is guessing the target server's PSN. The best clue concerning the value of the PSN that the server sent to the legitimate client in the first place is within the contents of already captured network traffic; packet dumps can reveal the previous PSNs for the server's connections to other systems. If the target server's PSN for a connection request from an entirely different client began with 24080 a few seconds previously, and if the PSN is always incremented by one for any new connection request, the next PSN for a new connection is likely to be 24081 if the initial PSN is not random. IP spoofing software that returns a PSN of 24082 from the bogus client to the server would therefore be very likely to correctly anticipate the appropriate PSN.

If the bogus client sends the correctly incremented value of both PSNs to the server, the attacker will have established a connection between the two. The attacker can then attempt to exploit the relationship between the two machines to gain unauthorized access to the target server. UNIX and Linux, for example, support the rlogin command that allows trusted access from one host to another. In many flavors of this system, by default, no password needs to be entered to obtain this level of access. For several years, IP spoofing was one of the most frequently observed types of attacks on the Internet. Although not used as frequently today as it was several years ago, IP spoofing still is a potentially serious threat to organizations. The availability of so many automated IP spoofing tools also greatly exacerbates the threat.

In the past, UNIX systems based on Berkeley Standard Distribution (BSD) UNIX and Windows NT systems were more vulnerable to IP spoofing attacks than were other types of operating systems. The solution at the operating system level is to program a server that gets an IP connection attempt to generate a truly random PSN in the SYN packet it returns to the client that has initiated the connection attempt.

Session Tampering Attacks

In session tampering attacks, an attacker (or, more often, a program that runs on behalf of an attacker) does something that allows the attacker to modify the characteristics of an already established session. In this next section, we will consider two types of session tampering attacks: session hijacking and session replay attacks.

Session Hijacking Attacks

In session hijacking attacks, an attacker takes over an already existing session. As discussed earlier, every time a client and server communicate with each other using IP-based communication methods, their packets bear a PSN. In a session hijacking attack, the attacker must gain access to a host that is between the legitimate client and server on the network. The attacker must then capture traffic going over the network to find an existing session and determine the PSN of the packet(s) that the server last sent to the client (as shown in the top part of Figure 2.3).

Figure 2.3. A session hijacking attack (the server's PSN is shown in bold letters).

The attacker must now beat the client in replying back to the server. The attacker (or, again, more properly the program that runs on behalf of the attacker) sends a packet with the correct PSN of the server incremented by one (see the lower part of Figure 2.3). The server continues the session, but this time with the attacking host. The session with the legitimate client is now dropped. The attacker can do anything that the person who was the legitimate client can do. The problem is especially serious if the session is a superuser session because the perpetrator gains the highest possible level of access to the victim system. Encrypted sessions or shared signatures between the client and server help prevent this type of attack.

Session Replay Attacks

Session replay attacks are another way to tamper with existing sessions. The attacker must again gain unauthorized access to a host located between two other hosts. This time, however, the attacker captures the packets sent between both hosts. When a session is established, the attacker can intervene by transmitting packets that have already gone across the network to one of the hosts. One of a number of outcomes can then occur. If one of the original hosts is an authentication server, replaying the original packets might enable the attacker to authenticate to that server. Alternatively, if one of the servers is an e-business server, the attacker might be able to do things such as gain access to databases that hold sensitive information, initiate business transactions, and change data without authorization. Fortunately, session replay attacks are not common-place. The bad news is that many, if not most, applications do not have built-in protections against session replay attacks. Fortunately, session replay attacks are more difficult to accomplish than might be apparent. They depend on factors such as the context of a particular network connection. Additionally, recent versions of protocols such as the Kerberos [3] protocol generally incorporate mechanisms that help prevent these attacks.

[3] Kerberos provides strong network authentication by issuing and using credentials called tickets to users. Version 5 of Kerberos also builds in protection against session replay attacks.

The Ever-Broadening Nature of Security-Related Incidents

"Experts" keep telling us that the goals of information security are CIA: confidentiality, integrity, and availability. You have already seen in Chapter 1, "An Introduction to Incident Response," that other considerations such as nonrepudiation and the need for accountability do not fit into this nice, neat little way of thinking. New, emerging trends in incidents also show how far off the mark it is to think of security purely in terms of CIA. Cyber harassment (using electronic means to scare, intimidate, or embarrass someone else), for example, is growing rapidly as a type of security-related incident. Transporting and storing pornography (including child pornography) is another, as is defamation of character and posting negative characterizations of companies and other organizations. The use of computers in a variety of ways by organized crime also does not fit the nice little CIA mold. In short, the nature of security-related incidents is changing rapidly and now includes types of incidents that few people envisioned even a decade ago. With this change comes the need to characterize the goals of information security less simplistically.

‚  < ‚  Free Open Study ‚  > ‚  


Incident Response. A Strategic Guide to Handling System and Network Security Breaches
Incident Response: A Strategic Guide to Handling System and Network Security Breaches
ISBN: 1578702569
EAN: 2147483647
Year: 2002
Pages: 103

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net