Malicious SOAP Requests as Web Service Attacks

Introduction

The recent Application Security Europe conference (www.appseceu.org) was one of the better conferences I have had the pleasure to attend. The talks were interesting and I came in third in a challenging Capture the Flag competition. This article is an overview of one of the more interesting talks given at this conference. Andreas Flakenberg gave a talk How to Become Twitter’s Admin — An Introduction to Modern Web Service Attacks. Any credit for this article should be given to him and his research team.

What are Web Services?

“The term Web services describes a standardized way of integrating Web-based applications using the XML, SOAP, WSDL and UDDI open standards over an Internet protocol backbone. XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available and UDDI is used for listing what services are available. Used primarily as a means for businesses to communicate with each other and with clients, Web services allow organizations to communicate data without intimate knowledge of each other’s IT systems behind the firewall” – (from webopedia.com).

In this article we are specifically going to be looking at SOAP requests and how we can send malicious requests to the business logic so that we (as the attacker) benefit.

What exactly is SOAP?

SOAP is the anagram for Simple Object Access Protocol. This protocol is defined to exchange information in the form of XML using the methods described above. “As an example of how SOAP procedures can be used, a SOAP message could be sent to a web-service-enabled web site such as a real-estate price database, with the parameters needed for a search. The site would then return an XML-formatted document with the resulting data, e.g., prices, location, features. With the data being returned in a standardized machine-parseable format, it can then be integrated directly into a third-party web site or application.” – ( from wikipedia.org).

The theory

The idea behind the talk was to give a hypothetical proof of concept on how you could become Twitter.com’s admin. Now when saying hypothetical, this method can actually be used to become Twitter.com’s admin but the likelihood of fulfilling the parameters is highly unlikely as one of the prerequisites for a successful attack is to have an arbitrary valid signed SOAP message from the victim. The reason a signed SOAP message is needed is because SOAP can use digital signing to authenticate the user before submitting and reading the request, however, this talk also mentioned that there are specific web services attacks that are available (and can be found here: www.ws-attacks.org) and this whole idea was based upon the attack vector called “signature wrapping”.

SOAP requests can use a security mechanism where a part of the message is signed and if any of that particular part of the message is changed it will not allow the request to be accepted. To understand more about this you need to have an in depth knowledge of what is in the SOAP request, so:

Slide used with permission of Andreas Falkenberg

Every SOAP message has this envelope feature. In this case the request also has a header (that is empty) and a body with the ID of “theBody” and the action of Login. Because SOAP uses XML we can display the requests using both plain XML and as an XML tree.

The idea behind the signature wrapping attack is that you are tricking the business logic into accepting a malformed request. Let’s take a look at a signed request:

Slide used with permission of Andreas Falkenberg

In the SOAP header we now have new blocks that are referencing the type of security to use in the request and where to secure for example the ds:reference block is referencing theBody mean that that is signed in the request that is sent through to the business logic.

How does the Security Work?

When a request is sent it is passed through a number of different hypothetical blocks as shown below:

Slide used with permission of Andreas Falkenberg

The security block checks to see that the request has not been tampered with in anyway and then sends it on through the chain until it gets to the business logic.

In the case of XML signature security, the signature is checked at the security block against what is chosen in SOAP header. Another form of security that can be used is XML encryption, this (as the name suggests) encrypts the request before it is sent and then it is decrypted by the security block.

According to Falkenberg, HTTPS is hardly ever used when these methods of securing the data in transit are in place. It is also not very common for the whole request to be encrypted or signed because it can have an effect on performance.

An example attack

Now that we know how SOAP works, and the security mechanisms that can be used, we can look into an example of an attack. The example from the talk is fictional. But the theory behind the attack can be used in all signature wrapping attacks you wish to carry out.

If we take the request that I showed you right at the beginning, the one which uses a signature to secure the data in transit, we can assume that if we were to change any of theBody the security block would not allow this and the request would be dropped. This attack allows a malicious user to change what is being signed and allow an attacker to change the information being sent. In the example we are setting the delivery address of an item that has been bought on an online store. The signature wrapping attack will allow a malicious attack to change the delivery address to an address of their choice and in turn receive the item themselves.

The way that this works is by using a wrapper block in the SOAP request. By repositioning theBody into a wrapper and placing this into the header the security block still reads theBody as being present. The request is then passed onto the Business Logic which because the security block has already accepted the request doesn’t check to make sure what it is applying to itself is “good” and not malicious. Below is the malformed request that would allow an attacker to change the address:

Slide used with permission of Andreas Falkenberg

The business logic checks what to do by viewing the inside of the envelope. The envelope has no security mechanism on it and therefore it accepts it as a “known good” and adds the address into the application. The security is fulfilled because there is an element in the request that is being checked and it is correct.

Now to be able to do this, the malicious user must be on the same network or exfiltrating the request to themselves first. The prerequisite is that you have a signed request without any errors. The impact of this type of attack is that the malicious user can perform any operation on behalf of the victim.

Ways to fix this problem

There are a number of ways to fix this issue. The first would be to apply W3C’s “XML Signature Best Practices”, these guidelines will help create a strict policy on what to do when applying signatures with XML. Other countermeasures that Andreas mentioned in his talk were to use strict server side security policies, XML Schema validation and to use a “see what is signed” approach.

Out in the wild

Examples of this type of attack have been seen. The popular cloud based provider eucalyptus has fallen to this attack: http://open.eucalyptus.com/wiki/esa-02. As stated above too, Twitter would have been vulnerable to this attack in the past but have now taken measures to secure against it.

Web Services are vulnerable to all types of web application attacks but have specific attack vectors too, these can be found — as stated at the beginning — at www.ws-attacks.org.

This project is very much continuing and a research paper will be released in the next few months.