Single Sign-On security issue in Cloud Computing

By: Rahul Roshan
IIT-KGP(M.Tech)
1

 What is Cloud Computing ?
 Service Models
 Single Sign-On
 ACS Spoofing
 Countermeasures
 References
2

 Cloud Computing is the practice of using a network of remote
servers hosted on the Internet to store, manage, and process
data, rather than a local server or a personal computer.
 Advantages of Cloud Computing:
 Pay as you go
 Cost effective
 Location independent
3

4
INTERNET
USER
ORGANIZATION
PROGRAMMER
CLOUD COPUTING
CLOUD SERVIECE PROVIDER

 Software as a Service (SaaS)
 Access services via browser
 Examples: Google Docs, DropBox, Gmail
5

 Platform as a Service (PaaS)
 Provides development environment
 Examples: Microsoft Azure, Google AppEngine
 Infrastructure as a Service (IaaS)
 Provides virtual machines, storages
 Examples: AmazonWeb Services
7

DDoSAttack
60%
DNS Cache
Poisioning
6%
MITM Attack
12%
Password
Based Attacks
22%
Network Security Attacks
8

999
Website: www.xyz.com
Web Server
DatabaseUser

1010
Adversary’sWebsite:
www.attacker.com
Web Server
DatabaseUser
Website: www.xyz.com

11
Phishing Attack Report
Reference: Kaspersky Lab

 Single sign-on (SSO) property allows a user logs in once and gains access
to all systems without being prompted to log in again at each of them.
 SSO works among three parties:
 User (represented as browser)
 Identity Provider (IdP) e.g. Facebook, Gmail
 Relying Party or Service Provider
 No trust relationship between IdP and relying party or service provider.
 Famous Single Sign-On Systems:
 Facebook Connect
 OpenIDConnect
 OAuth
12

13
www.codechef.com
www.topcoder.com
www.slideshare.com

 Benefits
 Reducing time spent re-entering passwords for the same identity
 Reducing overhead to maintain different passwords for different
services
14

 Identity Provider (IdP) is used to provide identifiers for users
looking to interact with a system.
 Security Assertion Markup Language(SAML) is used to exchange
authentication and authorization data between Identity Provider
and Service Provider.
15

 SAML statements are contained in security tokens called assertions.
 SAML consist of three building blocks:
 Protocols: defines how assertions are exchanged between actors.
 Bindings: specify how to embed assertions into transport protocols (e.g., HTTP or
SOAP)
 Profiles: define the interplay of assertions, protocols, and bindings that are necessary
for the needs of a specific use case to be met.
16

 Authentication Request
17
<AuthnRequest IDVersion IssueInstant AssertionConsumerServiceURL?>
<Issuer>?
<Subject>?
<NameIDPolicy>?
<Extensions>?
<Signature>?
<Conditions>?
<RequestedAuthnContext>?
<Scoping>?
</AuthnRequest>

 The optional AssertionConsumerServiceURL (ACSURL) attribute
specifies the endpoint URL to which the IdP must deliver the issued
assertion.
 The authentication request may be protected by a digital signature
(<Signature>)
 The <Issuer> element specifies the SAML authority (the IdP) that
certifies the claim(s).
18

19
FacebookUserwww.codechef.com (RP)

 Adversary is a client in an SSO and attempts to convince the RP
that his browser represents Legitimate user, assuming that he
knows legitimate user’s username through a prior communication.
2020
Legitimate User
Adversary (Malicious User)
IdP (e.g. Gmail) Relying Party

 Adversary leaves malicious web content in user’s browser during
her visiting of his website, which can perform SSO operations
through sending requests to the IdP and the RP.
21
Legitimate User

 When Legitimate user visits adversary's website, adversary acts as
an RP to the IdP, in an attempt to get user’s credential for the
target RP.
2222
Legitimate User

 ACS (Assertion Consumer Service) Spoofing allows the adversary
to redirect the security token issued by the IdP to himself, and thus
to impersonate the victim to every federated SP.
 The only prerequisite for this attack is that the victim has to visit a
webpage controlled by the adversary.
 ACS Scanner
 An automated penetration test tool developed to scan ACS vulnerability
 Platform Independent
23

24
IdP
http://IdP.com
U --->UA A
http://ssoattack.org
SP
http://sp.com
1. HTTPGET URL
2. HTTPGET URLsp
3. HTTP 302 IdP,
(<AuthRequest(ID,SP,ACSurl)>, URLsp)
No security context.
User not identifiable
4. HTTP 302 IdP,
<AuthRequest(ID,SP,Badurl)>
,URLsp)
5. HTTP GET IdP,
(<AuthRequest(ID,SP,Badurl)>
,URLsp)
6. User authentication
7. HTTP 200
Form(<Response(AA)>,URLsp,
Badurl)
8. HTTP POST
Badurl,(<Response(AA)>,URLsp)
9. HTTP POST
ACSurl,(<Response(AA)>,URLsp)
Verify and evaluate
assertion
10. HTTP 302 URLsp
Generate
Assertion:
AA=(ID,IdP,SP,U)

SSO System Website Affected SPs ACS Spoofing Common
Vulnerability
Exposure (CVE)
One Login www.onelogin.com 3600+ Yes CVE-2012-
4962
WSO2 Stratos www.wso2.org 3000+ Yes CVE-2012-
4961
SSOCircle www.ssocircle.com 2600+ Yes CVE-2013-0115
Bitium www.bitium.com 1750+ Yes Direct comm.
25

 Whitelisting. One way to mitigate ACS Spoofing is to use a
whitelist of allowed ACSURL values for each and every SP, stored
at IdP.This may induce a significant management overhead for
large IdPs.
 Signing Authentication Request: In theory, signing authentication
requests would make the injection of a malicious ACSURL
impossible.
26

 Preferred mitigation is cookie binding combining the ease of SSO with a
cryptographically strengthened client authentication.
 Solution provided by Andreas Mayer hardens both the SSO protocol and
the session cookies by establishing mutually authenticated channels
between the browser and the other participating entities (i.e. IdP and
SP).
 This builds a holistic authentication layer that prevents a wide range of
attacks, including MITM,ACS Spoofing, and XSS/UI redressing
vulnerabilities.
27

 Rui Wang, Shuo Chen, and XiaoFeng Wang. 2012. Signing Me ontoYour Accounts through
Facebook and Google: ATraffic-Guided Security Study of Commercially Deployed Single-
Sign-On Web Services. In Proceedings of the 2012 IEEE Symposium on Security and
Privacy (SP '12). IEEE Computer Society, Washington, DC, USA, 365-379.
DOI=10.1109/SP.2012.30 http://dx.doi.org/10.1109/SP.2012.30
 Andreas Mayer, Marcus Niemietz,Vladislav Mladenov, and Jörg Schwenk. 2014. Guardians
of the Clouds: When Identity Providers Fail. In Proceedings of the 6th edition of the ACM
Workshop on Cloud Computing Security (CCSW '14). ACM, NewYork, NY, USA, 105-116.
DOI=10.1145/2664168.2664171 http://doi.acm.org/10.1145/2664168.2664171
 A. Armando, R. Carbone, L. Compagna, J. Cuellar, G. Pellegrino, and A. Sorniotti. From
Multiple Credentials to Browser-Based Single Sign-On: Are We More Secure? In SEC,
volume 354 of IFIP Advances in Information and Communication Technology, pages 68{79.
Springer, 2011.
28

 Yuen-Yan Chan. 2006. Weakest link attack on single sign-on and its case in SAML v2.0 web
SSO. In Proceedings of the 2006 international conference on Computational Science and Its
Applications -Volume Part III (ICCSA'06), Marina Gavrilova, Osvaldo Gervasi, Vipin Kumar, C.
Kenneth Tan, and David Taniar (Eds.), Vol. Part III. Springer-Verlag, Berlin, Heidelberg, 507-
516. DOI=10.1007/11751595_54 http://dx.doi.org/10.1007/11751595_54
 Hsin-Yi Tsai; Siebenhaar, M.; Miede, A.;Yu-Lun Huang; Steinmetz, R., "Threat as a Service?:
Virtualization's Impact on Cloud Security," IT Professional , vol.14, no.1, pp.32,37, Jan.-Feb.
2012
doi: 10.1109/MITP.2011.117
29

Single Sign-On security issue in Cloud Computing

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Single Sign-On security issue in Cloud Computing (20)

Recently uploaded (20)

Single Sign-On security issue in Cloud Computing