Slide 1

Slide 1 text

SSO and SAML Pentesting Breaking ‘secure’ authentication systems

Slide 2

Slide 2 text

Who Are We ? Abhinav Sharma aka @0xint3 > Bug Hunter > Web and API Pentesting > Docker and Cloud Naveen Ramesh aka @ipanda915 >Bug Hunter >Web Pentesting > ML and Cloud

Slide 3

Slide 3 text

What is SSO? Single Sign-On is a feature that allows users to access multiple services without logging in multiple times. For example, if you are logged into facebook.com, you wouldn’t have to re-enter your credentials to use messenger.com. If you login into www.google.com, then you are automatically logged-in to all services offered by Google such as mail.google.com, www.youtube.com, play.google.com etc which saves time and effort to re-login.

Slide 4

Slide 4 text

1. Cookie Sharing 2. SAML (Security Assertion Markup Language) 3. OAuth (Open Authorization) Ways of implementing SSO

Slide 5

Slide 5 text

What is SAML? Security Assertion Markup Language (SAML) is an open standard that allows identity providers (IdP) to pass authorization credentials to service providers (SP). What that jargon means is that you can use one set of credentials to log into many different websites.

Slide 6

Slide 6 text

SAML (Security Assertion Markup Language)

Slide 7

Slide 7 text

1. The User-Agent (browser) tries to access the resource 2. The Service Provider (SP) sends a redirect to the Identity Provider (IDP) 3. The User-Agent follows the redirect an access the IDP. The request contains a SAMLRequest parameter. 4. The IDP sends back a response with a SAMLResponse. 5. The SAMLResponse is submitted by the User-Agent to the SP. 6. The user is now logged in for the Service Provider and can access the resource. How SAML Authentication works?

Slide 8

Slide 8 text

SAML Response example

Slide 9

Slide 9 text

What does a typical SAML Login look like? Example: https://jira.gtie.dell.com/

Slide 10

Slide 10 text

Scenario - 1 : Simple Account Takeover by manipulating SAMLResponse The SAMLResponse that is sent by the IdP to the User-agent or the browser is sent by the browser to the SP (Service Provider). That request could be intercepted and an attacker can change the in order to change the user, say from [email protected] to [email protected] giving him admin access to the website.

Slide 11

Slide 11 text

SAMLResponse editing with SAML Raider BurpSuite Extension

Slide 12

Slide 12 text

Scenario - 2 : Account Takeover by SAML Signature Stripping If the XML signature logic incorrectly handles signature validation, an attacker can just exclude a signature to create a XML document that passes signature validation. If we remove the contents of SignatureValue and send an empty value, the server sometimes doesn’t verify it and that could be used to bypass the validation.

Slide 13

Slide 13 text

While pen-testing an application, came across jira.target.com

Slide 14

Slide 14 text

Scenario - 2

Slide 15

Slide 15 text

NEPTUNE SATURN

Slide 16

Slide 16 text

Other attack scenarios 1. XXE via SAML

Slide 17

Slide 17 text

Other attack scenarios 2. SSRF via SAML Application https://medium.com/@th3g3nt3l/how-i-found-an-ssrf-in-yahoo-guestho use-recon-wins-8722672e41d4

Slide 18

Slide 18 text

Other attack scenarios 3. Comment Injection in SAMLReponse Most SAML libraries will parse the saml:NameID element out of the XML tree, extracting the last text element inside of it and will use that value to identify the user logging in. But… What happens if you break the saml:NameID element up such that it contains an XML comment? [email protected] In this scenario, the XML tree, when parsed, will look like so: NameID |_ Text: adm |_ Comment: this is a comment |_ Text: [email protected] And depending on the XML parsing logic used in the SAML library, you can probably see where this is headed: depending on where you insert a comment you can dramatically impact that identity of the user that’s being logged in! More info at: https://developer.okta.com/blog/2018/02/27/a-breakdown-of-the-new-saml-authentication-bypass-vulnerability

Slide 19

Slide 19 text

PREVENTIONS 1 3 2 4 The SAML Assertion should be encrypted if this feature is supported by the SP. The AuthnRequest can be signed to help ensure the request is being sent by a trusted SP Use only SHA-2 certificates when designing new SAML workflows TLS v1.2 is the preferred protocol to use when establishing a connection to the SP – it is the only version providing modern authenticated encryption

Slide 20

Slide 20 text

Thank You!