Shikata Ga Nai

Private? There is no such things.

Hatalı Yapılandırılmış AWS S3 Bucket Üzerinde Bulunan Güvenlik Açığının Yarattığı Etkiler を訳してみた

Hello there, ('ω')ノ

 

AWS S3 バケットの設定ミスによる脆弱性で情報漏えいとサブドメインの乗っ取りを。

 

脆弱性

 AWS の設定ミス

 

記事:

 https://medium.com/@gguzelkokar.mdbf15/hatal%C4%B1-yap%C4%B1land%C4%B1r%C4%B1lm%C4%B1%C5%9F-aws-s3-bucket-%C3%BCzerinde-bulunan-g%C3%BCvenlik-a%C3%A7%C4%B1%C4%9F%C4%B1n%C4%B1n-yaratt%C4%B1%C4%9F%C4%B1-etkiler-cb073179360d

 

今回は、HackerOne プラットフォームに接続されている民間企業で。

発見したセキュリティの脆弱性について。

まずは、攻撃側と防御側の両方を調べて。

会社名を XYZ とすると。


1.発見と悪用

XYZ 社では、xyz.com (*.xyz.com) のすべてのサブドメインを含むように。

カバレッジが追加され。

ここで最初のステップは、すべてのサブドメインを見つけることで。

これに使用できるツールはたくさんあり。

subfinder ツールを使用して、約 250 のサブドメインを見つけて。

 

次のステップは、これらのサイトをあらゆる角度から 1 つずつ調べることで。

見つけたすべてのドメインを一度に開く Chrome 拡張機能を使用し。

すべてのサブドメインを開いて検索を開始して。

 

https://chrome.google.com/webstore/detail/open-multiple-urls/oifijhaokejakekmnjmphonojcfkpbbh

 

次に、AWS S3 バケットサブドメイン abc.xyz.com で実行されていることがわかり。

ここで読み取り権限が制限されていない、つまり公開されていることがわかったとき。

機密情報が漏洩している可能性があると考えて。

すぐに内部のファイルを調べ始めて。

AWS cli で次のコマンドを実行した後、バケットが公開されていることを確認して。

 

 aws s3 ls abc.xyz.com

 

 

次に、サンプルを調べたところ、20 近くのサンプル テスト プロジェクトがあり。

これらは、ログインといくつかのトークンが試行された別の。

Web アプリケーションで。

 

 aws s3 ls abc.xyz.com/samples/

 

それらすべてを 1 つずつ参照し始めた後、プロジェクトのページ ソースの。

js コード内のコード ブロックが注意を引いて。

 

 

Bucket 内の別のBucketが。

開発者はここでBucket を使用していましたが、js コードで自分の名前を忘れており。

コードでも使用していて。

Bucket の名前を def とすると、このバケット、つまり def.s3.amazonaws.com に。

アクセスしたときの反応は興味深いもので。

 

 The specified bucket does not exist

 指定されたバケットは存在しません

 

つまり、このBucket を自分で取ることができ。

このタイプの脆弱性サブドメインの乗っ取りを呼んでいて。

こちらのプロジェクト https://github.com/EdOverflow/can-i-take-over-xyz から。

この脆弱性をホストしている製品と、それが悪用される可能性がある状況を。

確認でき。

つまり、当社の管理下にある会社に属するサブドメインを取得して。

 

https://github.com/EdOverflow/can-i-take-over-xyz

 

実際、コード内のBucket は使用されて削除されましたが、これには問題はなく。

外から見るとセキュリティ ホールのようには見えませんが。

Bucket を取るところからすべてが始まり。

突然、コード ブロックを発見したページにアクセスしたときに。

ログが自分たちで取ったコードのBucket に落ち始めていることを発見して。

これらのログには IP アドレスと http リクエストに関する情報が含まれているため。

ログは続行されず、エクスプロイト フェーズは終了して。

ここでは、この例で見たように、はるかに重要な情報が。

背後の API またはクラウドに安全に送信されない可能性があって。

 


2.イベントで気をつけたいこと

・機密情報を含む可能性のあるストレージ領域は、決して公開しないで。

・使用されているアプリケーションが削除された場合、作業コードが。

 残されることはなく。

 たとえば、Rest API の 3 番目のバージョンを作成している場合。

 必要でない限り v1 を使用しないように。

・S3 Bucket を使用する場合、読み取り、アップロード、および。

 削除のアクセス許可を適切に構成する必要があり。

 この例では、アップロード機能が機能していませんでしたが。

 機能していれば効果ははるかに大きかったでしょう。

・機密情報は、Javascript コードにハードコーディングしないように。

 

Best regrads, (^^ゞ