Jump to content
Nytro

Taking down the SSO, Account Takeover in the Websites of Kolesa due to Insecure JSONP Call

Recommended Posts

Taking down the SSO, Account Takeover in the Websites of Kolesa due to Insecure JSONP Call

Yasho
Yasho
 

Hello, this post is about how I could take-over any account of Kolesa’s websites using Single Sign-On. There was an insecure JSONP call which could break the security of the entire SSO mechanism.

What is JSONP?

JSONP is a method for sending JSON data to other domain.

  • Can load an external JavaScript object
  • Does not use the XMLHttpRequest object
  • Less secure
  • Bypassed SOP in browsers
Image for post
Image for post
Example of JSONP request/response

Single Sign-On

Information gathering revealed that Kolesa websites use SSO, the authentication server was:

https://id.kolesa.kz
Image for post
Image for post

The websites used SSO were:

  1. https://market.kz
  2. https://krisha.kz
  3. https://kolesa.kz

The general workflow of how SSO works:

Image for post
Image for post

In this authentication model since a domain can not set an authentication cookie for the others, an authentication token should be transferred between the authentication server and other domains. Considering the orange box in the image above, each site should save a cookie after verifying the authentication token. In addition, authentication server also saves its cookie, so after a couple of HTTP requests I found the authentication cookie name for each Kolesa website:

Image for post
Image for post

JSONP Call to Handle SSO

The JSONP call is used for further authentications. If a user has already logged-in in any of three websites, a JSONP call is made to authenticate the user in. The reason for this action is the ease of implementation. Since the origins of domains are different, the Kolesa websites should have implemented the Cross Origin Resource Sharing to transfer the authentication, but they’ve decided to use JSONP to avoid CORS setup.

Image for post
Image for post

The point is, once a user is logged in for examplekosela.kz, they have a ccid cookie in id.kolesa.kz, an authentication token to transfer the authentication, and a ssid cookie in kosela.kz. After that, if the user wants to log-in in the other websites, it happens by just a click, since id.kosela.kz has authentication cookie, it immediately generates authentication token and the user will have the corresponded authentication cookie on the website.

Based on the picture above, phase 4 shows how the JSONP call is made and how the authentication token can be turned into authentication cookie in a domain. The cause of JSONP call:

Image for post
Image for post

If the user has already been authenticated by id.kolesa.kz, the following response is expected:

HTTP/1.1 200 OK
Server: openresty/1.13.6.2
Date: Mon, 19 Aug 2019 16:43:26 GMT
Content-Type: text/javascript;charset=UTF-8
Connection: close
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Backend-Server: auth-be3.alaps.kz.prod.bash.kz
X-Bug-Bounty: Please report bugs and vulnerabilities to bugs@kolesa.kz
Content-Security-Policy: frame-ancestors 'self' http://webvisor.com https://webvisor.com
Strict-Transport-Security: max-age=31536000
Content-Length: 627window.xdm = {
    sess: {
        is_authenticated: 1,
        token: 'xG3ROFWcb7pnXSnMr8MkaBvH01pLlCHqn0sPt0PVL6BBWYdQPdvA31tBi6dLB5njv5jhMW3y/cGBMRB9LC/69zv867wweaDhkxX6arGVzYDy2q+J52nkOQJ+62rR9wLPYJGyEpNGWeOBSp12vugXZUPq2RA6FMptbNkGQpJFjAclXSzduj7wJJgAUONMj3mkkElM1nWmIllrl5zDEz6s7077E4ibx//BvnfZ9AIC/9b2PB+QzVKOnSzzcr9wSXqta9TEDHvjopqbUd4UE2xSMRSj/zxPQlCba5632hcIXnzZB3A8fvahvf2Hm5ssuC+cwuKU8pAdE/qcGQSJKdhpYXxntGkQiLdEAliyCq+fahS4itb6HlFH/+H20RsZA+cjyaF7ntnW5tYY31vxJXovrR3oinaj9YDSzoCZYMDYPJMdk+HuZhRuxxEl8abuNlGD0aCt2GCPV7GY0J9Ma7AcPw=='
    }
};(function ($) {
    "use strict";$.xdm = window.xdm;
}(jQuery));

As it’s been seen there is an object named sess containing the two properties named is_authenticated and token. This object is responsible to transfer authentication. At this moment the user has authentication token but not authentication cookie of the current website, so the second call is made:

Image for post
Image for post

The JavaScript code:

Image for post
Image for post
Image for post
Image for post

Vulnerable External JavaScript Object

The question is, an arbitrary origin can extract the authentication token? of course, it can because the JSONP call bypasses the Same Origin Policy.

Image for post
Image for post

The vulnerability found, account takeover by a single click :)

The Exploitation Phase

The scenario is simple:

  1. Setting up a page calling JSONP on behalf of any user
  2. Tricking authenticated user to visit our malicious website
  3. Sending authentication token by the user to our website
  4. logging-in as the victim and doing bad stuff

The exploit code (client-side + server-side call):

Here is the video POC:

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...