XML Security Gateway plugging holes for Public Clouds

Recently, there has been a flurry of news emanating from the XML security world related to researchers demonstrating an attack on Amazon's AWS cloud management interface. The attack takes advantage of a well known exploit known as XML signature wrapping or XML signature manipulation.

Amazon since the publication of this paper has plugged the security hole in its interface. It is a labor intensive effort to plug these holes that requires constant monitoring especially when cloud service interfaces are public facing. Risk can be more easily mitigated by a deployment of an XML security gateway without requiring custom code changes.

An XML security gateway prevents exploit like these in several ways. The XML gateway primary defense against this type of signature manipulation is via signed element verification. In the Amazon scenario, an XML gateway would verify that the soap:Body and wsu:Timestamp elements were processed during signature verification. A secure XML gateway verifies by checking the actual elements, not the Id attributes. This type of secure verification is the default behavior for XML gateways such as Forum Sentry.

XML security gateway's WSDL validation would also prevent the duplicate soap:Body and wsu:Timestamp elements used in this exploit. Such schema validation is important, but it is not a substitute for signed element verification, because there are alternate places to hide arbitrary content in most schema.

Amazon mistakenly assumed that ID attributes mapped to only one element without enforcing the ID uniqueness constraint. When Amazon verified that the soap:Body and wsu:Timestamp were signed, they only checked whether a matching ID was referenced in a signature, not whether signature verification actually processed all the intended elements, a subtle but important distinction. Amazon's use of signed ID verification instead of signed element verification could also allow additional exploits not mentioned here. Amazon also neglected to check for multiple soap:Body and wsu:Timestamp elements, but that is a lesser security flaw. These flaws could be the result of a misguided attempt to optimize performance by inspecting only initial portions of the document during certain security processing phases.

This specific signature exploit and other critical flaws are well-known and common in do-it-yourself security implementations, so it's essential for companies like Amazon to leverage proven security solutions and partners. These exploits indicate an apparent lack of gateway protection that could make Amazon a popular target for new exploits. Perhaps Amazon has already been the target of other undisclosed exploits. And just imagine how many other companies are hosting sensitive services without adequate gateway protection. Amazon and other web service providers need a viable commercial security strategy, and customers should expect real protection for their sensitive data and infrastructure.