Service-oriented systems are currently all the rage, and rightfully so. It seems like only yesterday that service-oriented architecture (SOA) was the new buzzword, making us wonder whether this was just more marketing hype or a technology that would actually become useful -- similar to the thoughts we may have had about previous buzzword technologies, like Extensible Markup Language (XML) or, more recently, Web services.
As with XML and Web services, SOA architectures are now bearing fruit across the corporate IT landscape, thanks to useful enabling technologies, such as the Service Integration Bus in IBM® WebSphere® Application Server V6, and its product-ized big brother, the IBM WebSphere Enterprise Service Bus. As new technologies often do, however, these technologies have invited a whole new class of attacks on systems that implement them. IT specialists who take security and systems hardening seriously need to be constantly vigilant about the holes that new technologies can open into their systems. Hackers have moved their attention past traditional targets, perhaps due to the inevitable maturity of those platforms, or perhaps because they are now simply passe.
The new frontier for hackers is systems built on Web services and XML, seen as inviting due to their popularity and immaturity. One class of such attacks is defined as XML threats, where an XML document that has been structured to do harm is sent to your system. If a system can be accessed by outsiders (such as through the Internet), someone could send messages to your system in order to damage it, or even just to consume resources. It is possible that the offending client could even be authorized to use your system, but is trying to exploit that authorization in some inappropriate way. When XML and SOAP were described as the new IT "miracle drug," due to their ability to "pass through the firewall," some savvy computer specialists immediately saw the implications of this from a security perspective. Those firewalls were put there for a reason, no? Hackers view this "feature" as a free ride on the XMLmobile, waving at the firewall sentries as they happily pass by.
Often, programmers will leave the door open to attacks by using poor technique, like not strictly defining the types of data they expect as input to Web services. One example of this would be the use of the xml:any data type, as opposed to restricting input to an integer or string. This lets attackers send harmful XML for this attribute -- and as a perfectly legitimate input!
There are four broad classifications of XML threats:
- XML Denial of Service (xDoS) -- Slowing down or disabling a Web service so that valid service requests are hampered or denied.
- Unauthorized access -- Gaining unauthorized access to a Web service or its data.
- Data integrity/Confidentiality -- Attacks that strike at the data integrity of Web service responses, requests, or underlying databases.
- System compromise -- Corrupting the Web service itself or the servers that host it.
There are several types of attacks within these four broad classifications, which we will look at in a minute. Also, be aware that these can be single-message or multiple-message attacks.
Software-based application servers used to host Web services are generally quite vulnerable to these attacks; they are often run with XML validation off for performance reasons, and may not be looking out for most XML attack types. As we will see, once the XML hits the parser, it is too late. Worse, if your system accepts native XML documents without the complexity of Web services or SOAP, it is even easier to attack.
Specific types of attacks within the four broad categories are listed below. Several of these attack types are familiar; these same types of attack occur with any remotely accessible service (for example, message tampering). Other attacks, though not really unique to XML-based services, are much more likely to occur with such services given the nature of XML.
- Jumbo payloads -- Sending a very large XML message to exhaust memory and CPU on the target system.
- Recursive elements -- XML messages that can be used to force recursive entity expansion (or other repeated processing) to exhaust server resources. An example of this type of attack would be the billion laughs attack that is widely available through the Internet.
- MegaTags -- Otherwise valid XML messages containing excessively long element names, or an excessive number of tags. This attack may also lead to buffer overruns.
- Coercive parsing -- XML messages specially constructed to be difficult to parse to consume the resources of the machine.
- Public key DoS -- Utilizing the asymmetric nature of public key operations to force resource exhaustion on the recipient by transmitting a message with a large number of long-key-length, computationally expensive digital signatures.
- XML flood -- Sending thousands of otherwise benign messages per second to tie up a Web service. This attack can be combined with Replay attack to bypass authentication, and with Single message XDoS to increase its impact.
- Resource hijack -- Sending messages that lock or reserve resources on the target server as part of a never-completed transaction.
- Dictionary attack -- Guessing the password of a valid user using a brute force search through dictionary words.
- Falsified message -- Faking that a message is from a valid user, such as by using Man in the Middle to gain a valid message, and then modifying it to send a different message.
- Replay attack -- Re-sending a previously valid message for malicious effect, possibly where only parts of the message (such as the security token) are replayed.
- Message tampering -- Modifying parts of a request or response in-flight; most dangerous when undetected (less commonly known as Message alteration).
- Data tampering -- Exploiting weakness in the access control mechanism that permits the attacker to make unauthorized calls to the Web service to alter data.
- Message snooping -- A direct attack on data privacy by examining all or part of the content of a message. This can happen to messages being transmitted in the clear, transmitted encrypted but stored in the clear, or decryption of messages due to stolen key or cryptoanalysis.
- XPath/XSLT injection -- Injection of expressions into the application logic. Newer modifications include Blind XPath injection, which reduces the knowledge required to mount the attack.
- SQL injection -- Inserting SQL in XML to obtain additional data than what the service was designed to return.
- WSDL enumeration -- Examining the services listed in WSDL to guess and gain access to unlisted services.
- Message snooping -- Using SOAP routing header for access to internal Web services.
- Malicious include -- Causing a Web service to include invalid external data in output or return privileged files from the server file system. For example, using embedded file: URLs to return UNIX password files or other privileged data to the attacker.
- Memory space breach -- Accomplished via stack overflow, buffer overrun, or heap error, enables execution of arbitrary code supplied by the attacker with the permissions of the host process.
- XML encapsulation -- Embedding system command in the XML payload, such as through the CDATA tag.
- XML virus (X-Virus) -- Using SOAP with attachments or other attachment mechanisms to transmit malicious executables, such as viruses or worms.
Now that I've scared you (hopefully), let's talk about how to protect systems from these attacks. The solution is to use a hardened Web services-aware gateway. This new type of high performance appliance can process incoming XML messages with validation turned on, while looking for XML threats. Because these devices run at wire speeds and are hardened, they are appropriate for usage in the DMZ as a front-line of attack, whereas software-based proxies or gateways are not due to the complexity of their underlying platforms and slow parsing/processing.
IBM recently acquired a company called DataPower® that offers such products and can protect against these types of threats. These products are hardware appliances that are completely hardened "out of the box" in many ways; for example, they contain no true operating system or hard drive.
The primary DataPower front end configuration objects (Multi-protocol gateway, XML firewall, application firewall, and Web services proxy) all contain a configuration page for XML threats that can be used to protect against the specific types of threats listed above. In fact, some of these threats are protected by DataPower without any configuration at all, as shown in Figure 1.
Figure 1. Threat protection configuration
Another section of the XML threats configuration page, specific to single-message attack types, offers the ability to limit message, attachment and node sizes, attribute counts, and element depths -- precisely the kinds of things used in the single-message attacks we have discussed.
A third section of the same page, specific to multiple-message attacks, provides the particularly useful ability to define specific interval sizes, during which only a certain number of requests will be allowed -- if you wish, this can be specific to a particular IP address or subnet.
Finally, the XML threats pane can also provide against unwanted protocols (or lower versions of certain protocols reaching your Web services hosting servers), as well as protection against XML viruses, which is provided by either removing or limiting circumstances where attachments can be included in messages. There are also exits available so that the viruses can be scanned by an external virus scanner. Protection against more elaborate attacks such as SQL injection and Dictionary attacks require more customized configuration, such as user-defined dictionaries containing allowable syntax. XML threat protection is only a small part of what these amazing devices can do.
To truly harden a system using Web services, you need to perform several important security steps (recommended by Gartner and others), including:
- inspect messages for well-formedness.
- validate schema.
- verify digital signatures.
- sign messages.
- implement service virtualization to mask internal resources via XML transformation and routing.
- encrypt data at the field level.
Other types of monitoring for the types of attacks mentioned above are also needed, as well as configurations to ensure compliance with service-level agreements. These intensive actions can be performed by gateway devices, such as DataPower, at the front-end - at a significant savings in back-end resource consumption and configuration. Systems hosting Web services, particularly public Internet-facing ones, should seriously consider the case for hardened gateway devices acting as XML firewalls to protect your systems from XML threats.
Protect yourself -- the threats are out there, and they want to do you harm.
DataPower product information
developerWorks SOA and Web services zone
developerWorks XML zone
Bill Hines is a Senior Certified Consulting IT Specialist with IBM Software Services for WebSphere. His expertise includes installation, configuration, tuning, security, troubleshooting, and design/architecture of IBM WebSphere DataPower SOA Appliances. He is the co-author of the IBM Press book IBM WebSphere DataPower SOA Appliance Handbook with John Rasmussen, Jaime Ryan, Simon Kapadia, and Jim Brennan, and the book IBM WebSphere: Deployment and Advanced Configuration with Keys Botzum, Tom Alcott, and Roland Barcia.