German researchers, Juraj Somorovsky, Mario Heiderich, Meiko Jensen, Jörg Schwenk, Nils Gruschka and Luigi Lo Iacono, in a paper titled All Your Clouds are Belong to us – Security Analysis of Cloud Management Interfaces discuss security vulnerabilities in Amazon AWS and Eucalyptus offerings that potentially could grant the attacker complete control of the victim's account and it's associated stored data. The paper focuses on a XML signature attack through the SOAP interface but it also exposes two additional cross scripting (XSS) techniques that could be utilized to hack into user accounts from the web management interface. These vulnerabilities have been fixed by both Amazon and Eucalyptus before they could be exploited.
In the classic XML signature attack:
The original SOAP body element is moved to a newly added bogus wrapper element in the SOAP security header. Note that the moved body is still referenced by the signature using its identifier attribute Id="body". The signature is still cryptographically valid, as the body element in question has not been modified (but simply relocated). Subsequently, in order to make the SOAP message XML schema compliant, the attacker changes the identifier of the cogently placed SOAP body (in this example he uses Id="attack"). The filling of the empty SOAP body with bogus content can now begin, as any of the operations denied by the attacker can be effectively executed due to the successful signature verification.
The classic XML signature attack can be used in at least 2 ways, one of which is not time sensitive, to exploit AWS and Eucalyptus. The prerequisite for such an attack, especially in the timestamp insensitive case, is very low since all the attacker needs is a valid signed SOAP request message which are publicly available through posts by AWS developers requesting assistance on the AWS support forums . The authors blame the separation of task modules in SOAP processing frameworks for such security holes. As a result of task modularity, the same XML document is accessed in different ways in different modules as a result of which the integrity of the entire message is never checked. The authors recommend:
the best countermeasure approach would be to enhance the interface between the signature verification function and the business logic. In this approach the signature verification returns some sort of position description of the signed data, next to a Boolean value. The business logic may then decide if the data about to be processed has been signed or not.
The authors also uncover two script injection attacks, one which targets only the AWS management console users and the second one exploits the shared credentials between the amazon shop interface and AWS. The first vulnerability is exploits the GET parameters in the download link users utilize for downloading their X.509 certificates issued by Amazon. However the preconditions for the attack are rather high including use of UTF-7 encoding for the injected script to bypass server logic to encode standard HTML characters as well as the exploitation of features in specific IE versions. The second script injection attack uses a persistent cross site scripting attack by exploiting the login session that is initiated with AWS the first time a user logs into the Amazons hop interface. The attack is simple and effective:
The attacker has to create a new discussion topic on either a shop item, a user-generated tag or other entities. Upon creation of the topic, the headline for the discussion topic will be rejected without proper encoding, thus allowing the injection of arbitrary HTML code. This has allowed us to include script tags or other active markup forcing the user agent to execute JavaScript on the www.amazon.com domain.
The researchers worked with security personnel from Eucalyptus and Amazon and fixes were created before the paper was released. However in the case of Eucalyptus deployments or any private cloud deployment, there still exists a downside:
The problem in utilizing fixes of this vulnerability lies in the fact that Eucalyptus is deployed on various and numerous privately hosted servers. Therefore, each Eucalyptus administrator has to manually update his server version. Assuming a large number of installations (according to Eucalyptus there are more than 25,000 customers), we are doubtful that this attack will be mended on each server within a short period of time. This is arguably one of the largest downsides of relying on a private cloud infrastructure.
The concluding statements reveal the scale of impact of such vulnerability exploits that could be present in any existing cloud service offerings and hence at the least necessitates "black box" methodologies as described in the paper before signing up:
It shows that the complexity of such systems creates a large seedbed of potential vulnerabilities. Hence, cloud control interfaces are very likely to become one of the most attractive targets for organized crime in the nearby future ahead. The most important threat pertains to every vulnerability we found as impacting not just a single server or company, but all of the associated cloud users at once. Additionally, Cross Site Scripting attacks against Web-based cloud control interfaces have severe repercussions for the overall cloud security.
