第 14 章 滥用模式

CHAPTER 14 Misuse Patterns

That some good can be derived from every event is a better proposition than that everything happens for the best, which it assuredly does not.

James Kern Feibleman, philosopher and psychiatrist (1904–1987)

The study of error is not only in the highest degree prophylactic, but it serves as a stimulating introduction to the study of truth.

Walter Lippmann, journalist (1889–1974)

14.1 Introduction To design a secure system, we first need to understand the possible threats to the system. We have proposed a systematic approach to threat identification, starting from the analysis of the activities in the use cases of the system, and postulating possible threats [Fer06a]. This method identifies high-level threats such as ‘the customer can be an imposter’, but once the system is designed we need to see how the chosen components could be used by the attacker to reach their objectives. A misuse is an unauthorized use (read, modify, deny use) of information, and our emphasis is in how the misuse is performed. A misuse pattern describes, from the point of view of the attacker, how a type of attack is performed (what units it uses and how), analyzes the ways of stopping the attack by enumerating possible security patterns that can be applied for this purpose, and describes how to trace the attack once it has happened by appropriate collection and observation of forensics data. It also describes precisely the context in which the attack may occur.

Figure 14.1 presents a UML model that describes the sections of a misuse pattern [Fer09d]. The components of the pattern correspond to sections of the template used to describe it in words. Below, we describe each section in detail.

Figure 14.1: UML class model for misuse patterns

An important value of the proposed approach is that the misuse, described dynamically in a sequence or collaboration diagram, makes direct reference to the components of the system, described in turn by the class diagram of the system. The sequence or collaboration diagram uses objects from classes in the class diagram, and we can then relate messages to the components where they are sent (classes represent the components of the system). The parameters in these messages consist of data that can be found in the corresponding component. In other words, the combination of sequence and class diagrams tells us what information we can find in a component after an attack.

Figure 14.2 (a composition of three UML diagrams) shows a global view of a misuse pattern. Objects O1 and O2 are communicating with object O3, as shown in the deployment part of the diagram. Dotted lines show their correspondence with system classes; for example, O1 and O2 belong to A. The collaboration part of the diagram in Figure 14.2 indicates the sequence of messages needed for an attack and the patterns sp1, sp2, sp3 show security patterns that can stop or mitigate the attack. This diagram emphasizes the fact that to stop specific attacks more than one pattern may be needed.

Figure 14.2: A misuse pattern

In [Was09] we introduced the concept of a dimension graph to classify patterns. However, the dimensions needed to classify misuse patterns are different from those used to classify security patterns. Misuse patterns describe specific attacks in a particular environment, such as VoIP, web services and so on. This means that the two main dimensions are the type of generic attack or misuse – for example, denial of service – and the environment where the attack is possible. An additional dimension is the set of attack actions or patterns that are necessary to perform the misuse (An attack pattern is an action leading to a misuse, for example a buffer overflow).

Finally, a solution dimension includes the security patterns needed to stop or mitigate the misuse. As an example, Figure 14.3 shows a pattern for a denial of service attack in VoIP [Pel09]. This pattern describes a generic denial of service attack, and its environment is VoIP networks. To perform it, a hacker first needs to install their malware in unprotected systems (zombies), followed by activation of these systems to make them flood the target with requests. To mitigate this attack we need to filter traffic from specific address ranges using Packet Filter Firewall and Proxy Firewall patterns [Sch06b] and an IDS to detect the attack (see Chapter 10).

Figure 14.3: Classifying the DENIAL-OF-SERVICE IN VOIP misuse pattern

We now enumerate each section of the template of Figure 14.1 and characterize them using graph representations.

NAME The name of the pattern should correspond to the generic name given to the specific type of misuse in standard attack/misuse repositories such as CERT [Cer06] or Symantec [Sym].

THUMBNAIL DESCRIPTION A short description of the intended purpose of the pattern (which problem it solves for an attacker).

CONTEXT The context describes the generic environment, including the conditions under which the misuse may occur. This may include minimal defenses present in the system, as well as typical vulnerabilities of the system. The context is specified using a deployment diagram of the relevant portions of the system, as well as sequence or collaboration diagrams that show the normal use of the system. Figure 14.2 shows an example, where two client objects communicate with a server. A class diagram may show the relevant system structure.

We can list specific preconditions for an attack to happen, as well as other patterns necessary to apply this pattern, such as preparatory actions. The context of the misuse pattern may be defined by a partial dimension graph, describing the classification of the pattern according to the dimensions above except for the solution section. (In the complete pattern description we show the complete dimension graph.)

Pattern hierarchies are important to precisely characterize the architectural environment. For example, Figure 14.4 shows a hierarchy for VoIP misuses. Misuses that apply to distributed or real-time systems may also apply to VoIP systems, because they belong to these two categories. On the other hand, the misuse can only apply to environments that use the SIP protocol.

Figure 14.4: A hierarchy of architectural contexts

PROBLEM From a hacker’s perspective, the problem is how to find a way to attack the system. An additional problem occurs whenever a system is protected by defense mechanisms. The forces indicate what factors may be required in order to accomplish the attack and in what way; for example, which vulnerabilities can be exploited. They also include which factors may obstruct or delay accomplishing the attack.

SOLUTION This section describes the solution of the hacker’s problem – that is, how the misuse can be accomplished and the expected results of the attack. UML class diagrams show the system under attack. Sequence or collaboration diagrams show the exchange of messages needed to accomplish the attack. State or activity diagrams may add further detail. Attack patterns that are necessary for the misuse are also listed here. For example, to perform DoS in VoIp, we need to infect zombies (Figure 14.3).

The UML class model should not be a comprehensive representation of all components and relationships involved in an attack. Rather, the pattern solution should represent all components that are important to perform or prevent the attack and are essential to the forensics examination. This can be represented by a class diagram that is a subset or superset of the architectural class diagram of the context.

In cases in which primary sources of forensic data (firewalls, IDSs and network forensic analysis tools) don’t contain enough evidence, investigators need to look for secondary sources. The most obvious and common secondary sources of data are terminal devices, servers and network storage devices. Many wireless devices may also contain forensic data. This may require refining the class diagrams to show more details of the system structure.

The section may include a diagram with only the selected classes and associations relevant to the forensic examination (Figure 14.5). Forensic information can be collected into forensic objects, f1 to f4 in the diagram. All forensic objects that collect information from different objects of the same class are collected into forensic classes; f2, f3, and f4 are part of forensic class forB. A collaboration diagram shows which objects interact during the misuse; this can be obtained directly from the sequence diagram of the misuse.

Figure 14.5: Forensic objects and classes

CONSEQUENCES This section discusses the benefits and drawbacks of a misuse pattern from the attacker’s viewpoint. Is the effort and cost of the attack commensurate with the results obtained? This is an evaluation that must be made by the attacker when deciding to perform the attack; the designers should evaluate their assets using some risk analysis approach. The enumeration includes good and bad aspects and should match the forces, but there may be consequences that do not correspond to any forces.

COUNTERMEASURES AND FORENSICS This section describes the security measures necessary to stop, mitigate or trace this type of attack. This implies an enumeration of which security patterns are effective against the attack. From a forensic viewpoint, it describes what information can be obtained at each stage of tracing back the attack and what can be deduced from this data in order to identify this specific attack. Finally, it may indicate what additional information should be collected at the system components through which the attack was propagated to improve forensic analysis, using the model of Figure 14.5 as a reference. Each pattern may also carry information about the time it takes to apply its solution [Yos04].

KNOWN USES This section describes specific incidents when the attack has been used. For new vulnerabilities, where an attack has not yet occurred, specific contexts where the potential attack may occur are enough.

SEE ALSO This section discusses other misuse patterns with different objectives but performed in a similar way, or with similar objectives but performed in a different way. It also considers patterns of complementary misuses or patterns of attacks that support the misuse. These patterns can be related using a misuse pattern diagram, analogous to the pattern diagrams used in [Bus96] and many pattern papers.

We have applied this approach to the construction of a small catalog of the most typical attack patterns in VoIP [Pel09]. We are also integrating this method with our methodologies to build secure systems [Fer06b]. We need to expand this catalog to make it of more practical value. Note that as usual, patterns provide only guidelines, not plug-in solutions; that is, for each new application, the patterns provide guidelines about what to expect, where to look and how to start, but their solutions must be tailored to the specific environment.

A catalog of misuse patterns can be organized using contexts as the main classification dimension; for example, misuse patterns for VoIP, for client/server architectures, for component structures and so on. More detailed patterns are possible depending on finer architectural aspects, for example DoS in VoIP in a SIP environment. While security patterns have been used in many practical projects, there is no practical experience with misuse patterns; we will have to wait until they are used to get a realistic appraisal of their value.

The misuse patterns described above are used to describe attacks against an existing system. Misuse patterns can also be defined in the analysis stage of a new system. As we have shown in [Fer06c], we can enumerate threats from activity diagrams for use cases or sequences of use cases. Using the classes in the conceptual model, we can describe misuse patterns as part of the lifecycle of systems under development.

We show here three misuse patterns:

A WORM pattern [Fer10c]. Malicious software propagates itself to as many places as possible (or to specific systems), usually indicating its presence, and maybe performing some damage. DENIAL-OF-SERVICE IN VOIP [Pel09]. A VoIP DoS attack overwhelms limited resources in order to disrupt VoIP operations, typically through a flood of messages. This leads to degradation of response time, preventing subscribers from effectively using the service. SPOOFING WEB SERVICES [Mun11]. A web service spoofing misuse tries to impersonate the identity of a user by stealing their credentials, and then makes requests in their name with these credentials, with the intention of accessing a victim’s web service. More VoIP misuse patterns can be found in [Pel09]. A misuse pattern for stealing data through SQL injection is shown in [Fer12f]. Failure patterns, their counterpart for dependability, were defined in [Buc12].

14.2 Worm The WORM pattern describes how a worm can propagate itself to as many places as possible (or to specific systems), usually indicating its presence, and maybe performing some damage.

CONTEXT Sites connected through the Internet or another type of network. The Internet provides a variety of services such as e-mail, file transfer and web services. Any of these services can be used for propagation. Both fixed and wireless networks can be used by a worm. Portable storage devices such as memory sticks can also propagate worms.

PROBLEM A worm tries to take advantage of any input to invade a system. Users might open attachments carrying worms and some ports of a system may be unprotected or have vulnerabilities; all of these give the worm a chance to invade. Mail systems and file transfer systems for example, include lists of addresses that can be used by the worm to find places to which to propagate. Many systems do not control access to their system directories and do not restrict Internet traffic, which facilitates a worm invasion.

The solution to this problem must resolve the following forces:

Objectives. A worm’s objectives may be political, monetary or vandalism. A political or terrorist worm typically tries to produce damage to an antagonist; a monetary worm tries to reach many places to collect information or drop spyware; a vandal worm tries to destroy or damage information. Reach. To try to reach as many places as possible or to specific sites. For most worms, reaching many places is a basic objective. Presence manifestation. To try to show its presence in the system, so that victims know about it. Exceptions to this are cases in which the objective is to drop spyware. Credit. To embed an identification or mark so that the worm’s creator can take credit for it. Misuse. Perform some destruction and/or other misuses (confidentiality, integrity, or availability). The misuse may be delayed (time bomb). Obfuscation. To try to hide its structure to make its detection and removal harder. Collateral damage. In addition to specific misuses, the worm may require costly operations for its removal, stopping or disrupting business activities. Its propagation may affect the normal traffic in the network. Latency. A worm’s propagation must be as fast as possible to avoid detection and countermeasures. Activation. This can be done by enticing offers which may tempt users to open e-mail attachments or download procedures (social engineering). Other possibilities are invading through unprotected ports or taking advantage of vulnerabilities. SOLUTION Attach a core portion of the worm to e-mail messages or to files. When the user opens the message attachments or executes the file, the core of the worm starts executing. Alternatively, invade through an unprotected or flawed port. Download remaining portions from complementary network sites. Use some procedure to hide the structure of the worm. Perform its mission and propagate. Figure 14.6 shows the propagation of a typical worm; speed comes from a tree-like propagation.

Figure 14.6: Worm propagation

STRUCTURE Figure 14.7 shows a class diagram of the units involved. Node represents any node in the network, defined by its address (URL on the Internet). Any node can be the origin of a worm and any node can be its target (and be invaded). Some nodes are complementary sites from which commands or other parts of the worm may be retrieved. The class Worm represents the worm itself, including procedures for initial setup, to bring complementary parts, to hide the worm, to perform its mission and to propagate.

Figure 14.7: Class diagram for the WORM pattern

DYNAMICS Use cases for a worm may include ‘Create a worm’, ‘Remove a worm’, and ‘Activate a worm’. Create and remove are specific to the type of worm (see Variants). We describe the use case ‘Activate a worm’ here because it is the most important for defenders. Its scenario (Figure 14.8) includes:

Figure 14.8: Sequence diagram for the use case ‘Activate a worm’

Triggering. After the attacker (Hacker) sends a message, a Target (user) may activate an executable procedure with a core part of the worm. Assembly. The core of the worm downloads its remaining parts via the Internet (optional). Obfuscation. The worm uses some procedure to hide parts of itself, for example encryption or dispersion. Address search. The worm finds destination addresses as new targets for propagation. Addresses may also be generated randomly. Manifestation. The worm displays some messages (optional). Propagation. The worm sends its core via the connection to another node in the address list. This operation is repeated for all the addresses found or generated. IMPLEMENTATION We show a typical implementation of the Bagle worm. It follows the sequence diagram of Figure 14.8 very closely. A typical scenario in a Microsoft environment would follow this sequence:

1 A user invokes executable code by opening an infected Microsoft Word file, which starts execution of a VBA macro. 2 The VBA macro downloads its remaining parts from a web server via the Internet. 3 The worm finds target addresses in the Microsoft Office address book using VBA code and an SMTP server name extracted from Outlook settings. 4 The worm displays some messages using a VBA function. 5 The worm opens an SMTP connection to mail its core to the next target. This operation is repeated for all addresses found. Active worms take advantage of vulnerabilities such as buffer overflows and can get in through port 80, or through other, unprotected ports. In the case of worms such as Code Red the core of the worm was sent to the input buffer of port 80 in Microsoft’s IIS server [Ber01]. A virus or worm may send a web address link as an instant message to all the contacts of the invaded site, and if the recipients answer, they bring the virus to their sites.

CONSEQUENCES The WORM pattern offers the following benefits for the attacker:

Objectives. Its economic objectives can be achieved if the worm has a long ‘reach’ and clever social engineering. Its political objectives can be achieved if the worm reaches its intended audience and manifests its presence and reasons. Its vandalism objectives can be achieved if the worm does considerable damage. Reach. If the system has easily accessible address lists, the worm can find many new targets. Random address generation is not so effective. Manifestation of its presence. A good procedure for display can make its presence well noticed. This may intimidate its victims, which brings satisfaction to the attacker. Credit. The worm may include a distinctive tag or icon which should not identify the attacker. The creator can get recognition for their efforts. Misuse. A worm can perform destruction and/or other misuses (confidentiality, integrity, denial of service, dropping spyware or spam). Obfuscation. Encryption and dispersion can make its detection and removal harder. Some worms mutate, that is, they change their structure when they propagate. Side effects. A fast-propagating worm can produce a lot of traffic and, if it is hard to detect, its cost increases. Latency. A fast-propagating worm can do much damage before being stopped. Activation. Good ways to activate the worm are necessary, since all its objectives depend on this step. A worm can also have some liabilities for the attacker:

A worm can be used to detect infected nodes or to destroy viruses or other worms. COUNTERMEASURES The following policies and their corresponding mechanisms (realized as patterns), can stop or mitigate the worm:

Policy about attachments. Users should be trained to recognize trustable attachments and should be forbidden from opening unknown or suspicious attachments. Need-to-know policy. This should be established to define access by system processes to resources. For example, address lists should use authorization to control access to their contents. Control of network communications. Connections should be established only with trusted addresses (control through the firewalls). This policy may avoid downloads from complementary sites. Intrusion detection. An intrusion detection system can detect some attacks in real time and alert the firewall to stop them. Use of antivirus software. This can help detect and clean worms after an attack. Backups. Checkpointing files and keeping backup images of them is a fundamental precaution against data destruction or unauthorized modification. Specialized hardware. Process communication controls in the operating system can be enforced through specialized hardware [Shi00]. It is possible to define partitions in the operating system that can be enforced by hardware that will prevent a worm from performing its actions. FORENSICS The pieces of the worm may be scattered across different components within a site. The specific places to look for worm components depend on the specific variant or type of worm. The places where worms normally penetrate include e-mail attachments, files and unprotected ports, and these must be inspected. One should also look for the specific parts of the worm, such as core procedure, obfuscation procedure and so on.

Web logs can help in finding worm parts that might have been downloaded. GUIs may have log records of the use of procedures to display the worm’s announcements. Units that contain addresses may contain indications of search.

VARIANTS A passive worm requires a user to activate an executable program, and usually propagates through e-mail. Melissa, ILOVEYOU, Anna Kournikova, and Bagle are examples of this type of worm. An active worm takes advantage of some system flaw to provoke a buffer overflow or another attack to get access to a system through some port. It may scan ports looking for unprotected ones. Code Red is an active worm; Storm can be active or passive [Smi08]. A virus attaches itself to a program (infects an executable file) and, when the user executes the program, is activated. Jerusalem, Christmas and Chernobyl are examples of viruses. Some worms have several versions with different purposes; for example, Storm has variants that perform different types of misuses, including targeted spam and DDoS (distributed denial-of-service) attacks [Smi08]. Some worms are multimode (multivector) worms, which can use a variety of methods to invade their targets; for example, Storm infects computers using multiple payloads [Smi08]. KNOWN USES Typical examples of worms include:

ILOVEYOU [ILO] [wor09]. An e-mail attachment worm that appeared in 2000. It relied on social engineering to entice users to open the attachment. It also used specific weaknesses of Microsoft Windows. It propagated using the addresses in the address book of the e-mail system. Bagle. A mass-mailing worm written in assembly language [bag] and affecting all versions of Windows. After activation, it copied itself to the Windows system directory and downloaded an SMTP engine to e-mail its core to other nodes as an attachment (see the Implementation section for its typical behavior). Code Red [Ber01]. This worm appeared in July 2001. It propagated through port 80, indicated its presence by defacing web pages, propagated using a random IP address generator, and later activated a denial of service attack from infected sites. Nimda [Nima]. Nimda is a multivector worm that can use several methods to propagate: e-mail, visiting an infected site, seeking out vulnerable servers to upload files, or through the network. Slapper [Arc03]. This worm can launch denial of service attacks. It propagates by finding addresses in files. The nodes invaded by the worm communicate using a P2P protocol to collaborate in their misuses. Conficker [Conb] [wor09]. This is a multivector worm with an auto-update facility (signed updates) and encrypted communications. It downloads parts of itself from some Internet sites. These worms are really worm types, from which many variants can be derived. It is possible to define separate patterns for each type of the generic WORM pattern. For example, the Slapper worm and the Apache Scalper operate in a similar way, while Conficker is really a series of worms [wor09].

SEE ALSO Authorization and Reference Monitor. These patterns together can prevent access to address lists, stopping the worm propagation [Sch06b]. Firewall. A firewall can filter attempts to download further pieces of the worm [Sch06b]. Intrusion detection. An intrusion detection system can detect a worm invasion in real time and collaborate with the firewall to block its traffic [Fer05d]. 14.3 Denial-of-Service in VoIP A VoIP DoS attack overwhelms limited resources in order to disrupt VoIP operations, typically through a flood of messages. This leads to degradation of response time, preventing subscribers from effectively using the service.

CONTEXT There are two targets for DoS attacks: those in which end systems are targets, and those that target gateways or gatekeepers. In the former, subscribers try to establish a call over a VoIP channel (VoIP services should be available to subscribers when requested). In the latter, some VoIP systems use control protocols (for example MGCP and Megaco/H.248) and security mechanisms to manage the Media gateways deployed across the infrastructure. In general, the VoIP system should have adequate capacity (bandwidth) to meet the peak communication load. The system may have a minimum set of perimeter defenses, such as firewalls. More complex VoIP implementations may have an intrusion detection system (IDS) and firewall on the phone itself to check the media packet flow, or perform authentication. All Internet building blocks – and thus VoIP – are vulnerable to DoS attacks, which have not previously been a security issue with circuit-switched telephony systems because of their inherent bandwidth limitations. In particular, this pattern assumes the use of the H.323 protocol.

PROBLEM How can we trigger a DoS attack on a VoIP system? IP telephony subscribers need to be blocked from using VoIP services. The attack can be carried out by taking advantage of the following conditions:

VoIP security is in an incipient phase at the moment: there is lack of expertise and security standards. Users might inadvertently expose the system. While some basic countermeasures exist, such as IDSs and firewalls, administrators may not configure them appropriately due to a lack of training and time. Until now VoIP has been developed and deployed focusing on functionality with less thought for security [Wie06b]. That means that the defenses that are in place are not very advanced. For example, strong authentication is not common in VoIP. With the rush to implement new VoIP systems, features and standards, implementation flaws are common. IP PBXs include many layers of software that may contain vulnerabilities. Programming mistakes, such as not properly checking the size of the parameters of a protocol request, when exploited, can result in the following issues: Remote access. An attacker obtaining remote (often administrator level) access. Malformed request DoS. A carefully crafted protocol request (a packet) exploiting a vulnerability that results in a partial or complete loss of function (in this case a single malformed packet may lead to a DoS). Load-based DoS. A flood of legitimate requests overwhelming a system [Col04]. As with any network-based service, enterprise VoIP must communicate with other components on a LAN and possibly over an untrusted network such as the Internet, where packets are easy to intercept. Because RTP (real-time transport protocol) carries media that must be delivered in real time to be usable for an acceptable conversation, VoIP is vulnerable to DoS attacks that impact the quality delivery of audio, such as those that affect jitter and delay. VoIP traffic can offer very good cover for DoS attacks, because VoIP runs continuous media over IP packets [CRN06]. SOLUTION One method to launch a DoS attack is to flood a VoIP server (for example Gatekeeper) with repeated requests for legitimate service in an attempt to overload it. This may cause severe degradation or complete unavailability of the voice service. A flooding attack can also be launched against IP phones, Gateways or any VoIP network components that accept signaling. With this form of DoS attack, the target system is so busy processing packets from the attack that it will be unable to process legitimate packets, which will either be ignored or processed so slowly that the VoIP service is unusable. Attackers can also use the TCP SYN flood attack (also known as resource starvation attack) to obtain similar results. This attack floods the port with synchronization packets, which are normally used to start a connection.

In a distributed denial-of-service (DDoS) attack, multiple systems are used to generate a massive flood of packets. To launch a massive DDoS attack, the hacker previously installs malicious software on compromised terminal devices (infected with a Trojan) that can be triggered at a later time (‘zombies’) to send fake traffic to targeted VoIP components. Targeted DoS attacks are also possible, in which the attacker disrupts specific connections.

The class diagram of Figure 14.9 shows the structure for a DDoS attack in an H.323 architecture where any VoIP component can be a target for DoS. Classes AttackControlMechanism and Zombie represent the software introduced by the attacker. Note that the zombie is just a terminal device in a different role.

Figure 14.9 Class diagram for DoS attacks in H323

The sequence diagram of Figure 14.10 shows the sequence of steps necessary to perform an instance of an end-system DoS attack. An attacker (internal or remote), with knowledge of a valid user name on a VoIP system could generate enough call requests to overwhelm the IP-PBX server. An attacker may disrupt a subscriber’s call attempt by sending specially crafted messages to their ISP server or IP PBX component, causing it to over-allocate resources, so that the caller receives a ‘service not available’ (busy tone) message. This is an example of a targeted attack.

Figure 14.10 Sequence diagram for DoS attacks in H323

Similarly, out-of-sequence voice packets (such as receiving media packets before a session is accepted) or a very large phone number could open the way to application layer attacks (aka ‘attacks against network services’). Buffer overflow attacks might paralyze a VoIP number using repeated calling. For example, an attacker intermittently sends garbage (that is, both the header and the payload are filled with random bytes, corrupting the callee’s jitter buffer voice packets) to the callee’s phone between those of the caller’s voice packets. The callee’s phone is then so busy trying to process the increased packet flow that the jitter (delay variation) causes any conversation to be incomprehensible [Anw06].

DoS attacks against gateways are analyzed from the supporting Megaco/H.248 protocol viewpoint. Figure 14.11 shows the class diagram of the media gateway control protocol structure. Megaco/H.248 is a master-slave, transaction-oriented protocol in which media gateway controllers (MGC) control the operation of MediaGateways (MG) [Ell03]. VoIP media gateways are vulnerable to DoS attack because they accept signaling messages.

Figure 14.11 Class diagram for a Megaco/H.248 environment

In this setting, a DoS attack would occur at an MGC when the attacker sends a large volume of UDP packets to the protocol’s default port 2944 or 2945, which keeps the MGC busy handling illegal messages, and finally blocks the normal service. An attacker can keep sending ‘service change’ or ‘audit capabilities’ commands to an MG, and thereby bring down the MediaGateway [Vuo04]. Therefore, VoIP gateways will not be able to initiate calls or maintain a voice call during a DoS attack. The audio quality will be affected as well. An alternative way to launch DoS attacks happens when an attacker redirects media sessions to a media gateway: the attack will overwhelm this voice component and prevent it from processing legitimate requests.

Signaling DoS attacks on media gateways can consume all available TDM channels, preventing other outbound and inbound calls and affecting other sites that use TDM. On the other hand, since VoIP media sessions are very sensitive to latency and jitter, DoS on media is a serious problem. VoIP media, which is normally carried with RTP, is vulnerable to any attack that congests the network or slows the ability of an end device (phone or gateway) to process the packets in real time. An attacker with access to the portion of the network where media is present simply needs to inject large numbers of either RTP packets or high QoS packets, which will contend with the legitimate RTP packets [Col04].

CONSEQUENCES The DENIAL-OF-SERVICE IN VOIP misuse pattern has the following benefits for the attacker:

DoS can be especially damaging if key resources are targeted (for example media gateways), which may lead to cascading effects if a server is impacted. Flooding of the firewall can prevent it from properly managing ports for legitimate calls. VoIP QoS can be degraded by jitter and delay and may become totally unusable. The zombies in the targeted network can also be used as DoS launching points to perform attacks on another network. It can also have some liabilities for the attacker:

Some defenses can stop this attack – see the next section. COUNTERMEASURES AND FORENSICS The attack can be stopped or mitigated by the following countermeasures:

DoS is mitigated by disabling and removing unnecessary network services, reinforcing the operating system, and using host-based intrusion detection systems (the IDS pattern [Fer05d]). This makes it harder to introduce Trojan horses that may make terminal devices become zombies. IDSs and firewalls can ensure that packets with very large sequence numbers and garbage packets are discarded. Again, the IDS pattern is relevant, as well as the Firewall patterns [Sch06b]. Use of Proxy and Stateful Firewalls [Sch06b], which can look inside the voice packet and analyze its contents, as well as the headers, to decide if the information is safe or not. Use of the Authenticated Call pattern [Fer07a], which performs both device and user authentication before allowing access to VoIP services. Although this takes longer, it can protect against targeted attacks from devices that do not possess authentication tokens. Likewise, the following network forensics mechanisms can be used to collect evidence of the attack:

Logs in the terminal devices not only provide VoIP-specific details (for example, start/end times and dates of each call), but they can also reveal the presence of malware. As we indicated, some attacks come from compromised devices that become zombies. Network analysis procedures such as the examination of router logs (for example denied connection attempts, connectionless packets) and firewall logs, provide information about the location (that is, where the attack entered the network) and the way that attackers performed their exploits. Selective use of events sent to the ISP or IP PBX has been shown to produce another range of attacks. Those could be traced through logs on these devices. Network forensic analysis techniques such as IP traceback and packet marking are useful for attack attribution. During a denial of service attack the victim will receive sufficient traceback packets to reconstruct the attack path [Sha03]. Locating attackers with IP traceback technology is also a potential security mechanism to counter DoS attacks. The deployment of a traceback mechanism on a single router would provide minimal benefit: this process requires the cooperation of all network operators along the attack path in order to trace it back to the source. IP traceback works even when criminals conceal their geographic locations by spoofing source addresses. Comparing traffic patterns against predefined signatures (as is done by some IDSs) is an effective method of detecting DDoS attacks. Such a method can produce an alert, helping network examiners to detect malicious traffic (for example observing congestion in a router’s buffer) from entering or leaving their networks. Event logging allows network administrators to collect important information (for example date, time and result of each action) during the set up and execution of the attack. For example, logs may identify the type of DDoS attack used against a targeted system. The use of ‘honeypots’ placed on selected VoIP components (see Figure 14.9) and other network forensics tools can help in the event of a successful attack. Honey-pots can attract attackers and provide investigators with useful information about new types of intrusions. In VoIP, the attack pattern technique may be complemented with the use of a network forensics analysis tool to offer a better view (interpretation) of the collected voice packets. WHERE TO LOOK FOR EVIDENCE Based on Figure 14.2 (page 385), the following may be considered secondary sources of forensic information in a VoIP environment:

Terminal devices (softphones, hardphones and wireless VoIP phones) Gatekeepers Gateways IP-PBXs KNOWN USES DoS attacks are performed on different systems in the Internet every day on all protocol layers. Some of those attacks affect VoIP systems.

SEE ALSO Several security patterns for defending against these (and related) attacks are listed in [Anw06] [Fer07a]. Some general security patterns such as firewalls [Sch06b], IDSs [Fer05d] and authentication [Sch06b] can be used to control these attacks, as discussed earlier. A misuse pattern can be developed to describe similar attacks on SIP networks.

14.4 Spoofing Web Services Also known as Principal Spoofing in Web Services A web service spoofing misuse tries to impersonate the identity of a user by stealing their credentials, then makes requests in their name with these credentials with the intention of accessing a victim’s web service.

CONTEXT Enterprises can exchange data through the use of web services. In order to let other entities access the web service, they publish a WSDL (Web Services Description Language) file with functionalities and security policies.

The client must create a request which should adapt its methods and policies to those of the web service provider. Security can be implemented at the level of messages: each user is given credentials to access services and the responsibility of protecting their messages from other users. The web service can be protected using standards such as WS-Security [Aja10a] to protect messages and WS-Policy [Bar07] to verify the security requirements of the web service.

PROBLEM How we can effectively perform a principal spoofing attack against web services so that we can access the information of another user?

The attack can take advantage of the following vulnerabilities:

Currently there is no method of verifying identity unequivocally. When a WSDL file is published, the interfaces of the web service are exposed, and thus its entry points. The source address of the request can be altered. There is a tendency to trust presented credentials without a more thorough check. Once the authentication stage is passed, other attacks can be generated more easily: for example, DDoS attacks Maybe the interchanged data items are not encrypted, and it may be possible to steal the credentials using special software. The resulting damage depends on the privileges of the credentials submitted. SOLUTION Security standards such as WS-SECURITY (page 330) use the credentials of the user to protect communication between web services by signing and encrypting messages. If an attacker manages to obtain valid credentials, they can communicate with other web services. This type of vulnerability is mentioned in [Mor06a] and is termed principal spoofing. In this attack, the user does not know that their credentials have been stolen until the damage is done (such as alteration of information, access to their resources, alteration of privilege, even attaching malicious code that could be harmful to the server).

When the attacker has the credentials, they can use the WSDL file to discover the security policies of the web services and create a valid message. This situation is conditional on the attacker obtaining a user’s credentials, the valid user not knowing of the theft and not having reported the theft.

The attack can be carried out by taking advantage of the following vulnerabilities:

If communications between web services are not protected, sniffer software such as WireShark or WebScarab could intercept packages while they travel in the network and obtain the credentials carried in the messages. Using social engineering to obtain the credentials of the user. Inadequate security policies used by the system; it is possible to cheat the system in this way. The system not verifying the origin of the request. The class diagram of Figure 14.12 shows the typical relationships between web services. The WS-User has Credentials to communicate with other web services. The WS-Requester can be a WS-User on another kind of web service. The WS-Provider has several WS-Policies, stored in the WSDL-File. In this way, a WS-Requester can be created based on the WS-Policies shown in the WSDL-File. When the WS-Requester tries to communicate with the WS-Provider, the WS-Provider checks the request with its TrustEngine, which checks the requester’s credentials.

Figure 14.12: Class diagram for the SPOOFING WEB SERVICES pattern

To make this attack possible, the user must have the user’s credentials, as shown in Figure 14.13. This diagram shows the structure of a principal spoofing attack, the classes WS-Attacker and Attacker being the new elements introduced by the attacker.

Figure 14.13: Misuse pattern: principal spoofing

The sequence diagram of Figure 14.14 shows the sequence of steps to perform a principal spoofing attack. An Attacker can obtain credentials of a valid User. When the attacker has the credentials, they can access the WSDL-File of the WS-Provider, where the WS-Policies and methods to access the web service are published. The WSDL-File can be found through the UDDI service, or it can be accessed through techniques such as ‘crawling’. With the information obtained from the WSDL-File and the credentials of the User, the Attacker can create a web service.

Figure 14.14 Sequence diagram for principal spoofing

When the Attacker has the web service, they can make a request to the WS-Provider using the credentials of the user. The WS-Provider receives the request and checks the message against the policies of the web service. If the message is correct, the WS-Provider sends the credentials to the TrustEngine to check the identity of the user. Because the credentials are valid, the request will be authenticated. When security policies are known, the Attacker will be able to develop another web service with a different behavior, according to their intentions. User credentials will be used as identification to access the system’s functionality.

CONSEQUENCES The SPOOFING WEB SERVICES misuse pattern has the following benefits for the attacker:

The attacker can access the sensitive information from a valid user. Malicious code can be attached to the messages to make further attacks on the user or their associates. The attacker can read or modify information or make transactions in the name of the valid user. It can also have some liabilities for the attacker:

Knowing the attacker’s behavior, forensics proofs could be shown in order to verify that the attack was carried out, and by whom. If an attacker does not know about the forensics evidence that they would generate, they might be identified. Some defences, described below, can stop this attack. AFFECTED COMPONENTS When the attack is over several components will be affected:

WSDL-File. This file will no longer be trustable, because it was used by the attacker, and the file may contain vulnerabilities that would allow further attacks to the web service. User credentials. The user’s credentials are compromised, so they are no longer useful and should be revoked. User trust. The user’s trust in the authentication method will be compromised. WS-Requester. When the attack is over, the requests from the authorized web service should be viewed with suspicion. COUNTERMEASURES AND FORENSICS Human behavior cannot be controlled, so we cannot prevent people from be deceived into releasing their credentials. Also, a victim could be robbed of their credentials.

This attack can be mitigated through the following countermeasures:

Encrypting communications between web services. Encryption can be performed by following security standards such as XML Encryption and WS-Security. For each of the web services that are developed: Generating an internal credential, which can be an ID or some kind of token. This credential will be embedded in the code. The web service provider publishing a policy about credential requests for each transaction. If the communication is done using a PKI infrastructure, the credential being sent encrypted using the public key provided by the web services provider. With this countermeasure the attacker will not be able to access the content of the message even if the message is intercepted by sniffer software. The following forensic evidences are possible:

We can identify which user was affected and the actions performed using logs from the web service provider. We can check the origin from the attack (IP address) – although the attacker can spoof its IP address. KNOWN USES Scenario I. Hole [Hol06] describes some online banking security issues identified over a period of two years. During this period, several attacks were identified against a bank system by combining simple brute-force attacks with distributed-denial-of-service (DDoS) attacks that exploited the bank’s login procedure. In the bank, the authentication procedure was based on a web service, which was the only point for access to users’ information at which requests were authenticated. A web service could be deployed in the bank or externally. This web service was attacked using IP spoofing and became a victim of a DDoS attack because it was not well configured; all the requests that it received were sent to the main server, skipping authentication in the web service from the bank. With this attack, the bandwidth and the resources of the bank were affected; in the worst case, the system could go down. This could be achieved if the attacker had the credentials of a user from the bank. Scenario II. In this case a web service from an information service provided information only to authorized personnel. Every user had credentials to use the web service, which were needed because of the sensitive information being handled. The attacker obtained credentials from users and built another web service to try to access the information. The attacker was also able to make several requests to the web service target, using the credentials from a valid user, the requests being generated from several parts of the network. The attacker used techniques from IP spoofing to hide their position. The web service target could first verify the identity from the sender of the message, or check the structure of the message, and finally check the identity of the requester. With this scenario, several attacks could be realized [Jen07]. All of these were DDoS attacks. Scenario III. In October 2010 a Firefox plugin, ‘Firesheep’, was delivered. Through this plugin, an attacker without much technical knowledge could access the information of other users on the same wireless network. In this way, the attacker could see the information exchanged by other sites in their browser, such as Facebook, Twitter or Google. With a small modification to this plugin, it is possible to build a sniffer. When a session was captured, the credentials of the users could be captured without their knowledge. The first of these attacks uses resource exhaustion. This type of attack attempts to compromise a web service’s availability by exhausting the resources of the service’s host system, such as memory, processing resources or network bandwidth. The attack can be performed using a large SOAP message document, a technique called oversize payload.

Another attack type, attack obfuscation, is made using the WS-Security standard. By providing confidentiality to sensitive data, XML encryption can hide the contents of messages. The encrypted message can contain an intended attack, such as oversize payload or XML injection. The advantage of this method is that the defender must decrypt the message to be able to analyze it.

The attacks described above are based on the trust that the system may have for its users, because an important step in the attack is the verification of the identity of the requester.

SEE ALSO WS-TRUST. This pattern helps to establish the relationships that should arise between web services in order to share their credentials (page 272 and [Aja10a]).