the devil is in the (implementation) details: an empirical analysis of oauth sso systems san-tsai...
TRANSCRIPT
1
THE DEVIL IS IN THE (IMPLEMENTATION) DETAILS: AN EMPIRICAL ANALYSIS OF OAUTH SSO SYSTEMS
SAN-TSAI SUN & KONSTANTIN BEZNOSOV
PRESENTED BY: NAZISH KHAN
COMPSCI 726 SEMINAR
2
MOTIVATION
• Contribution: Uncover several critical vulnerabilities in OAuth SSO systems and relate them to a set of design decisions
• Problem:
• Previous research suggests that the protocol is secure
• BUT some implementation details could be inadvertently left out
• Sometimes developer may trade security for implementation simplicity and create some vulnerabilities
• Attacker can gain unauthorized access to victim user’s personal data on RP or IdP websites
3
WHAT IS SINGLE SIGN-ON?
• Session/user authentication process
• SSO credentials – token and authorization code
• Identity providers
• Relying parties
• Identity providers provide a token, which represents an user, to relying party for accessing resources as the logged in user
4
OAUTH 2.0: SERVER-FLOW
Intended for web applications that receive access tokens from their server-side program logic
5
OAUTH 2.0: CLIENT-FLOW
Intended for Javascript applications running in a web browser as they can’t embed a secret key
6
METHODOLOGY
• Authors treated RPs and IdPs as black-boxes and analysed HTTP messages
• Exploratory study vs. Confirmatory study
• Examined implementations of:
• 3 major IdPs• Google
• Microsoft
• Adversary Model – Web Attacker or Passive Network Attacker
• 96 Facebook RPs listed on Google Top 1,000 websites
7
DESIGN DECISIONS
• OAuth 2.0 offers support for public clients that cannot keep their client secret secure
• Drops digital signatures in favour of SSL for RP-to-IdP communication
• IdPs offer an automatic authorization granting feature and SDK library
8
RESULTS - OVERALL
• Results uncover several critical vulnerabilities
• Confidentiality of temporary secret key can be compromised
9
ACCESS TOKEN EAVESDROPPING
• Access tokens can be eavesdropped by sniffing on unencrypted communication between browser and RP server
• In contrast to OAuth specification, 32% of RPs’ access tokens can be eavesdropped
• RPs store access token into a HTTP cookie on RP domain by default – no secured or HTTP-only attributes
10
ACCESS TOKEN THEFT VIA XSS
• Automatic authorization granting feature
• Theft possible by injecting a malicious script into any page of RP website
• Two exploits were designed to evaluate this vulnerability Exploit 1 uses current page as the redirect URI
88% of RPs are vulnerable to this exploit
Exploit 2 dynamically loads the SDK
Successful on all RPs except those that use different HTTP domain for receiving authorization responses
11
IMPERSONATION
• This vulnerability works by sending a stolen or guessed SSO credential to RP’s sign-in endpoint through an attacker-controller user agent
• 9% of RPs use user’s IdP profile as an SSO credential
• Successfully carried out if:
• Attacker can obtain or guess a copy of victim’s SSO credentials
• SSO credentials are not limited to one-time use
• RP in question does not do proper checking
12
SESSION SWAPPING
• Exploiting the lack of contextual binding vulnerability
• A successful exploit allows an attacker to stealthily log victim user into RP as the attacker to spoof victim’s personal data or mount an XSS attack
• Intercepts SSO credential from IdP, embedding it in an HTML construct
13
FORCE-LOGIN CSRF
• Allows an attacker to stealthily force a victim user to sign into the RP
• Attack URL is usually embossed in an HTML construct causing automatic issue of malicious request
• After a successful attack, an adversary can use CSRF attacks to alter user’s profile information of 21% of evaluated RPs
• It can also actively carry out subsequent attacks without waiting for the user due to the automatic authorization granting feature
15
CRITICISM
• Restriction to systems using English
• Study concentrates on specific attacks
• OAuth protocol concerning mobile devices?
• Only examined high profile IdPs and RPs found in 1,000 most-visited websites
• Realistic vulnerabilities?
• Who takes the responsibility? IdPs or RPs or both?
16
REALISTIC VULNERABILITIES?
• Study does not explore the root causes of these vulnerabilities in depth
• The extent to which these vulnerabilities exist in the wild has not been shown
• As a result, authors advise mitigations that may be ineffective in practice
17
TRUSTING RPS?
• Authors recommend a range of mitigation techniques for RPs to implement secure systems
• Can we trust RPs with correctly managing their implementations? No
• Instead, IdPs should force proper implementations through:
• Providing correct and complete developer tools
• Forcing correct RP implementations
• Mandating the use of state parameter
• Providing proper documentation
18
SUMMARY
• OAuth 2.0 favours simplicity over security
• Authors believe that OAuth 2.0 at the hand of most developers is likely to produce insecure implementations
• Critical vulnerabilities discussed are caused by a set of design decisions
19
Questions?