Portswigger OAuth 2.0 Authentication Vulnerabilities 🥶

Hi, dưới đây là writeup của 6/6 bài lab về tấn công OAuth 2.0 authentication mình đã solve trong quá trình ôn tập thi chứng chỉ của Portswigger.

Authorization code grant type

Implicit grant type

1. Authentication bypass via OAuth implicit flow

Description

This lab uses an OAuth service to allow users to log in with their social media account. Flawed validation by the client application makes it possible for an attacker to log in to other users' accounts without knowing their password.

To solve the lab, log in to Carlos's account. His email address is [e-mail].

You can log in with your own social media account using the following credentials: wiener:peter.

Writeup

Đây là dạng OAuth Implicit grant type. Đầu tiên, sau khi truy cập app và authen thì lập tức được redirect về 1 trang login theo social media với các request như sau:

Client App: 
--> GET /social-login
--> GET /auth?client_id=pnulrnn7d8b6dudj7m5mh&redirect_uri=https://0a60006c04f2123881fa5ce200a100db.web-security-academy.net/oauth-callback&response_type=token&nonce=1677942221&scope=openid%20profile%20email

Tại đây đăng nhập với account wiener:peter

OAuth server sẽ redirect về đường dẫn đã định nghĩa ở tham số redirect_uri ở trên kèm theo access_token ở fragment.

OAuth server:
<--  GET /oauth-callback#access_token=_UUmuaiY5pjAx9jLQ0FkeFNgKIwXWVWw_d4nbcSVGEb&amp;expires_in=3600&amp;token_type=Bearer&amp;scope=openid%20profile%20email

Khi đó app truy cập đường dẫn trên.

Client App: 
--> GET /oauth-callback

Tại đây là 1 đoạn script thực hiện các bước như sau:

• GET /me với token từ fragment để lấy thông tin user.
• POST /authenticate với email, username và token có được từ request trên để login.

<script>
const urlSearchParams = new URLSearchParams(window.location.hash.substr(1));
const token = urlSearchParams.get('access_token');
fetch('https://oauth-0aeb00f50465120a813b5a44027e0084.oauth-server.net/me', {
    method: 'GET',
    headers: {
        'Authorization': 'Bearer ' + token,
        'Content-Type': 'application/json'
    }
})
.then(r => r.json())
.then(j => 
    fetch('/authenticate', {
        method: 'POST',
        headers: {
            'Accept': 'application/json',
            'Content-Type': 'application/json'
        },
        body: JSON.stringify({
            email: j.email,
            username: j.sub,
            token: token
        })
    }).then(r => document.location = '/'))
</script>

Cụ thể, GET /me trả về username, email. Có vẻ như email sẽ được dùng để identify user.

Thực hiện authen bằng POST /authenticate.

Sau khi hiểu được rõ flow trên, ta thay email của nạn nhân carlos để authen.

Kết quả authen thành công do không có cơ chế kiểm tra access_token có match với data gửi lên hay không. Ta solve challenge.

2. Forced OAuth profile linking

Description

This lab gives you the option to attach a social media profile to your account so that you can log in via OAuth instead of using the normal username and password. Due to the insecure implementation of the OAuth flow by the client application, an attacker can manipulate this functionality to obtain access to other users' accounts.

To solve the lab, use a CSRF attack to attach your own social media profile to the admin user's account on the blog website, then access the admin panel and delete Carlos.

The admin user will open anything you send from the exploit server and they always have an active session on the blog website.

You can log in to your own accounts using the following credentials:

Blog website account: wiener:peter
Social media profile: peter.wiener:hotdog

Writeup

Sau khi đăng nhập bằng wiener:peter, ứng dụng cho phép attach social profile.

Bằng cách đăng nhập bằng account social media,

Mình có thể đăng nhập lại mà không cần username password mà chỉ cần Login with social media.

Tuy nhiên khi để ý kĩ request khi attach social profile thì không có tham số state → có thể CSRF.

Khi OAuth server trả về code thì mình có thể sử dụng nó để khiến nạn nhân attach profile của nó vào account của mình. Miễn là code đó chưa được sử dụng.

Tạo CSRF payload bằng iframe load request chứa code trên.

Login with social media lúc này ta vào được account admin.

Xóa user carlos và ta solve challenge.

3. OAuth account hijacking via redirect_uri

Description

This lab uses an OAuth service to allow users to log in with their social media account. A misconfiguration by the OAuth provider makes it possible for an attacker to steal authorization codes associated with other users' accounts.

To solve the lab, steal an authorization code associated with the admin user, then use it to access their account and delete Carlos.

The admin user will open anything you send from the exploit server and they always have an active session with the OAuth service.

You can log in with your own social media account using the following credentials: wiener:peter

Writeup

Mình có thể chỉnh redirect_uri tùy ý tại authorization request.

Authorization code được gửi về đúng redirect_uri đã gửi.

Bây giờ chỉ việc gửi cho admin authorization request chứa redirect_uri là exploit-server.

Ta sẽ nhận được authorization code của admin.

Truy cập tài khoản admin bằng cách truy cập /oauth-callback?code=<CODE> với code lấy được.

Ta vào được trang admin và xóa user carlos. Ta solve được challenge.

4. Stealing OAuth access tokens via an open redirect

Description

This lab uses an OAuth service to allow users to log in with their social media account. Flawed validation by the OAuth service makes it possible for an attacker to leak access tokens to arbitrary pages on the client application.

To solve the lab, identify an open redirect on the blog website and use this to steal an access token for the admin user's account. Use the access token to obtain the admin's API key and submit the solution using the button provided in the lab banner.
The admin user will open anything you send from the exploit server and they always have an active session with the OAuth service.

You can log in via your own social media account using the following credentials: wiener:peter.

Writeup

Tại Authorization request, thử thay thế redirect_uri thành 1 URI khác thì bị báo không khớp trong whitelist.

Tương tự khi xóa đường dẫn /oauth-callback.

Như vậy redirect_uri phải chứa https://<LAB-ID>.web-security-academy.net/oauth-callback. Thử path traversal thì lại thấy thành công. Như vậy mình có thể lợi dụng để redirect về 1 URL mà tại đó có chức năng open redirect về domain attacker.

Ta tìm được endpoint có chức năng open redirect đó là chức năng load next post có tham số path là URL nó sẽ redirect đến.

Như vậy ta sẽ chỉnh redirect_uri thành như sau với path là exploit-server.

Lúc này, oauth server sẽ request đến exploit-server để trả về access_token.

Bây giờ chỉ việc tạo payload. Đoạn script có chức năng khiến nạn nhân load authorization request → access_token trả ngược về exploit-server qua query string (vì URL fragment không xem được trong log).

Deliver exploit to victim, ta thấy nạn nhân đã thực hiện oauth thành công và ta lấy được access_token log.

Sử dụng access_token trên request đến /me để lấy user data. Ta lấy được APIKey của admin.

Submit và solve challege.

5. SSRF via OpenID dynamic client registration

Description

This lab allows client applications to dynamically register themselves with the OAuth service via a dedicated registration endpoint. Some client-specific data is used in an unsafe way by the OAuth service, which exposes a potential vector for SSRF.

To solve the lab, craft an SSRF attack to access http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/ and steal the secret access key for the OAuth provider's cloud environment.

You can log in to your own account using the following credentials: wiener:peter

Writeup

Ta xem được openid config tại <OAuth-server>/.well_known/openid-configuration.

Để ý thấy endpoint client app registration tại /reg. Thực hiện đăng kí client application thử với redirect_uris bất kì, ta thấy server trả về tạo thành công và có client_id.

Mặt khác quan sát ta thấy, bước confirm về thông tin có thể truy cập có xuất hiện request đến /client/<CLIENT_ID>/logo để hiển thị logo.

Và theo docs, thì nó lấy logo từ đường dẫn được định nghĩa tại logo_uri tương ứng với client_id. Ta kiểm tra out bound request đến collaborator không khi đăng kí new client app với logo_uri là collaborator URL.

Sử dụng client_id tương ứng và load logo, ta thấy đã có request đến collaborator → có thể SSRF.

Làm lại các bước tương tự với logo_uri chính là đường dẫn đã cho http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/.

Truy cập logo với client_id tương ứng, ta lấy được secret access key của OAuth server trên cloud.

Submit key đó và ta solve được challenge.

6. Stealing OAuth access tokens via a proxy page

Description

This lab uses an OAuth service to allow users to log in with their social media account. Flawed validation by the OAuth service makes it possible for an attacker to leak access tokens to arbitrary pages on the client application.

To solve the lab, identify a secondary vulnerability in the client application and use this as a proxy to steal an access token for the admin user's account. Use the access token to obtain the admin's API key and submit the solution using the button provided in the lab banner.

The admin user will open anything you send from the exploit server and they always have an active session with the OAuth service.

You can log in via your own social media account using the following credentials: wiener:peter

Writeup

Tương tự bài 4, ta có thể path traversal tại redirect_uri.

Tại mỗi post của blog, form comment được load bằng frame từ /post/comment/comment-form.

Tại đó, xuất hiện một postMessage() đến parent có origin bất kì *, tức là trang đang dùng frame của comment form này, với message là window.location.href. Như vậy nếu trang exploit-server frame chứa comment-form này thì nó sẽ nhận được message chứa window.location.href. Và nếu redirect_uri của oauth là /post/comment/comment-form thì window.location.href sẽ chứa access_token.

Kết hợp các điều đó, ta xây dựng payload như sau:

Theo đó sẽ có iframe chứa authorization request với redirect_uri được sửa thành /oauth-callback/../post/comment/comment-form. Và khi nhận được message từ /post/comment/comment-form, thực hiện fetch đến exploit-server để có thể xem access_token qua log.

Gửi cho nạn nhân, và ta lấy được access_token qua log.

Sử dụng access_token và gửi request đến /me, ta xem được API key của admin.

Submit API key đó và ta solve challenge.

tags: portswigger, oauth, advanced