Token Recipient Confusion and Category:Attack Categorisation By Attacked Single Sign-On Component: Difference between pages

From Single Sign-On Attacks
(Difference between pages)
Jump to navigation Jump to search
 
No edit summary
 
Line 1: Line 1:
=Introduction=
Using authentication via ''Single Sign-On (SSO)'' has many advantages over simple Username/Password mechanisms. Whereas for the former, the user has to remember multiple different Username/Password combinations, this overhead can be significantly reduced with ''SSO''. Also, the security of Username/Password relies solely on the strength of the password provided by the user, but ''SSO'' allows for the adoption of several technical measures to further enhance the security of the login procedure. <br>
In real-life SSO, there exist multiple ''Software-as-a-Service Cloud Provider (SaaS-CP)'' federating with the same ''Identity Provider (IdP)''. In order to distinguish the authentication tokens generated
In general, authentication using ''SSO'' is done utilizing a trusted third party called '''Identity Provider (IdP)'''. When a user uses his user agent (UA), e.g., a web browser, to request a login to the '''Service Provider (SP)''', instead of asking for Username/Password, the service issues a Token Request and redirects the client to the '''IdP'''. After proper authentication, the '''IdP''' issues a signed authentication '''token (Token)''' and redirects the client back to the '''SP''', where the token will be validated and the user logged in. <br>
for different ''SaaS-CPs'', each token contains information ''D'' about its recipient. In most cases this is the URL of the ''SaaS-CP'' for which the token was generated.
As can be seen in ''Figure 1'', the '''SP''' contains the different security-related components:
The goal of ''Token Recipient Confusion (TRC)'' is to use an authentication token '''t_A''' generated for a service '''S_A''' on a second service '''S_target'''. The attack is considered successful if '''S_target''' becomes “confused” by the recipient of the token and accepts '''t_A''' as valid.
*''Client'' is a user communicating with an '''SP''' via his UA, for example, a web browser. The communication takes place via the HTTP Protocol.)
According to [http://www.cvedetails.com/cve/CVE-2008-3891], this type of attacks is classified as critical, since information disclosure or privilege escalation is possible. A dishonest user can redeem his tokens on different services and get unauthorized access to restricted resources. Furthermore, a malicious ''SaaS-CP'' could collect authentication tokens and forward them to other SPs in order to get login in arbitrary accounts.
*''Web Frontend''(for example, a web server listening on a specific port and forwarding the traffic to the according handlers)
 
*''Username/Password'' module manages the corresponding authentication and the password-recovery mechanism
This attack also targets the SSO Verificator, which is responsible for checking the restrictions regarding the destination of the token, ''D''. In the SAML context, specifically the ''AudienceRestricton'' and ''Recipient'' elements are relevant for this attack type.
*''Session Management (SM)'' module resolves the received Session Cookies by the ''Web Frontend'' to a user identity and forwards this information to ''Authorization & Access Management (AAM)''
 
*''SSO module'' carries out the verification of the received authentication
=Attack subtypes=
tokens and contains three internal modules:
There are no attack subtypes for this attack.
    '''The Parser''' (converts an input string into data objects, which can then be further processed by following components)
 
    '''Verificator''' (validation of all security-relevant parameters within the authentication token)
=Prerequisites=
    '''Processor''' (after the verification, the information regarding the authenticated user will be extracted from the token and forwarded to the business logic)
The attacker has access to a valid token. An additional requirement is that both services ('''S_A''' and '''S_target''') have to be federating with the same ''IdP''. This is a realistic assumption since an IdP usually offers authentication services for multiple ''SaaS-CPs''.
'''These internal modules are considered as potentially violated targets'''.
 
*''Authorization & Access Management (AAM)'' controls the access to the restricted resources
=Target=
*''User Database'' stores information about users and their credentials
[[File:Target_Application_Logic.jpg|centre|750px]]
*''Resources'' include the entirety of data accessible to registered users
The attacked Single Sign-On component is marked in red colour.
[[File:Authentication_Process_Saas-SP.jpg|centre]]
 
=Description=
There are two different approaches for a ''TRC'' exploit: <br>
'''Exploit 1:''' Suppose, that ''SaaS-CPs'' '''S_A''' and '''S_target''' are accepting tokens from the same ''IdP'', and the attacker does not have access to '''S_target'''. The attacker does, however, have legitimate account on '''S_A''', thus, he can request a token '''t_A = (..., D_A, ...)''' from the ''IdP''. By sending '''t_A''' to '''S_target''' (instead of '''S_A'''), the attack is performed. It is considered successful if '''t_A''' is accepted by '''S_target'''; the attacker is thus logged in with the same account name as he has for '''S_A''' and gets access to '''S_target'''’s corresponding resources.
 
'''Exploit 2:''' Alternatively, the attacker can set up his own ''SaaS-CP'' ('''S_bad''') offering some service for registered users (e.g., a weather
forecast). To authenticate to '''S_bad''', SSO is used and the attacker specifically federates it with the same ''IdP'' used by '''S_target'''. After
that, the attacker lures his victim (a legitimate user of '''S_target''') to register with and authenticate to '''S_bad'''. Instead of or in addition
to its usual service (weather forecast), '''S_bad''' stores all tokens in a database so that the attacker can access them. The attacker can then
try to use the tokens to log in on '''S_target''' as the victim. The attack is considered successful if an authentication token '''t_bad''' issued for the victim for service '''S_bad''' is successfully verified on '''S_target'''.
 
[[File:Token_Recipient_Confusion.jpg|centre]] <br>
SAML token addressed for service '''S_A''' will be sent to '''S_target'''.
 
=Mitigation / Countermeasures=
To mitigate the TRC attack, the SP should verify whether the '''D_A'''. SP parameter contained in '''t_A''' matches its own '''D_A'''. In terms of SAML this means, that '''S_target''' needs to verify the URL in the conditions ''AudienceRestricton'' and ''Recipient'' elements to match its own URL.
 
=Practical Examples=
In 2014, Mainka et al. analyzed 22 Software as a Service cloud providers and found out, that different frameworks were vulnerable to this attack: Zendesk, Clarizen, SAManage, Shiftplanning, Panorama9, UserVoice (Marketing), Instructure, The Resumator, BambooHR, AppDynamics, Panopto, TimeOffManager, HappyFox, ScreenSteps Live, LiveHive, Howlr and CA Service Management.
 
 
[[Category:Attack_Categorisation_By_Attacker_Model:_Access_to_Valid_Token]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Confidentiality]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Availability]]
[[Category:Attack_Categorisation_By_Violated_Security_Objective_Integrity]]
[[Category:Attack_Categorisation_By_Attack_on_IdP/_SP:_Attack_on_SP]]
[[Category:Attack_Categorisation_By_Attacked_Web_Service_Component:_Application_Logic]]
[[Category:Attack_Categorisation_By_Attack_Spreading:Conceptual_Flaws]]
[[Category:Attack_Categorisation_By_Attack_on_SAML]]
 
=References=
C. Mainka, V. Mladenov, F. Feldmann, J. Krautwald, J. Schwenk (2014): Your Software at my Service: Security Analysis of SaaS Single Sign-On Solutions in the Cloud. In The ACM Cloud Computing Security Workshop (CCSW).<br>
[http://www.cvedetails.com/cve/CVE-2008-3891 CVE-2008-3891] <br>
[https://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf Security Assertion Markup Language (SAML) V2.0 Technical Overview]

Latest revision as of 16:46, 2 February 2016

Using authentication via Single Sign-On (SSO) has many advantages over simple Username/Password mechanisms. Whereas for the former, the user has to remember multiple different Username/Password combinations, this overhead can be significantly reduced with SSO. Also, the security of Username/Password relies solely on the strength of the password provided by the user, but SSO allows for the adoption of several technical measures to further enhance the security of the login procedure.
In general, authentication using SSO is done utilizing a trusted third party called Identity Provider (IdP). When a user uses his user agent (UA), e.g., a web browser, to request a login to the Service Provider (SP), instead of asking for Username/Password, the service issues a Token Request and redirects the client to the IdP. After proper authentication, the IdP issues a signed authentication token (Token) and redirects the client back to the SP, where the token will be validated and the user logged in.
As can be seen in Figure 1, the SP contains the different security-related components:

  • Client is a user communicating with an SP via his UA, for example, a web browser. The communication takes place via the HTTP Protocol.)
  • Web Frontend(for example, a web server listening on a specific port and forwarding the traffic to the according handlers)
  • Username/Password module manages the corresponding authentication and the password-recovery mechanism
  • Session Management (SM) module resolves the received Session Cookies by the Web Frontend to a user identity and forwards this information to Authorization & Access Management (AAM)
  • SSO module carries out the verification of the received authentication

tokens and contains three internal modules: 

   The Parser (converts an input string into data objects, which can then be further processed by following components)
   Verificator (validation of all security-relevant parameters within the authentication token)
   Processor (after the verification, the information regarding the authenticated user will be extracted from the token and forwarded to the business logic)

These internal modules are considered as potentially violated targets.

  • Authorization & Access Management (AAM) controls the access to the restricted resources
  • User Database stores information about users and their credentials
  • Resources include the entirety of data accessible to registered users
Retrieved from "http://www.ws-attacker.de/index.php?title=Token_Recipient_Confusion&oldid=334"