25K AWS S3バケットの探索

AWS S3バケットのアクセス許可の問題は、サービス自体と同じくらい古いものです。この問題に関する最もよく知られた研究は、S3バケットの7%が開いているとSkyhighが指摘し、17%が開いているとRapid7が指摘した2つだと思います。今日は2018年で、問題の現在の状態を確認することにしました。さらに、このような研究を行うためのテクニックを紹介したいと思います。賢いものを逃した場合は、コメントでお知らせください。

いくつかの理論から始めましょう

次のURLを使用して、すべてのAWS S3バケットにアクセスできます。

https:// [bucket_name] .s3.amazonaws.com /
https:// [aws_endpoint] .amazonaws.com / [bucket_name] /

またはAWS CLIを使用:

$ aws s3 ls --region [region_name] s3:// [bucket_name]

多くの場合、地域パラメーターを使用する必要性を指摘することはありません。ただし、一部のバケットは地域を指定しないと機能しません。機能するときとそうでないときはパターンが表示されないので、常にこのパラメーターを追加することをお勧めします:)

したがって、一般的に言えば、有効なバケットを見つけることは、s3.amazonaws.comor [aws_endpoint] .amazonaws.comのサブドメインを見つけることと同じです。以下では、このタスクに役立つ4つの方法を説明します。

ブルートフォーシング

各バケット名は一意である必要があり、少数の例外を除いて3〜63文字の英数字のみを含めることができます(「-」または「。」を含めることができますが、開始または終了はできません)。そうは言っても、私たちはすべてのS3バケットを見つけるのに十分な知識を武器にしていますが、正直に言うと、それはむしろ短い名前で機能します。それでも、人々はネーミングにいくつかのパターンを使用する傾向があります。 [company_name] -dev、または[company_name] .backups。特定の会社のバケットを検索したら、LazyS3やaws-s3-bruteforceなどのツールを使用して、このようなよく知られているパターンを検証するプロセスを簡単に自動化できます。 Rzepskyという会社があるとします。単純なコマンド:$ ruby​​ lazys3.rb rzepskyはrzepsky-devバケットを明らかにします:

しかし、特定の名前を付けずにできるだけ多くのバケットを収穫したい場合はどうでしょうか?この投稿を読み続けてください;)

ウェイバックマシン

Wayback Machineについて聞いたことがありますか?ウィキペディアの引用:

Wayback Machineは、World Wide Webのデジタルアーカイブと、インターネットアーカイブによって作成されたインターネット上のその他の情報です。

このデジタルアーカイブの一部のリソースは、Amazonインフラストラクチャに保存されます。つまり、Wayback MachineがS3バケットの写真を1つだけインデックス付けした場合、この情報を取得して、このバケットにパブリックリソースが含まれているかどうかを確認できます。インデックス付きの写真が既に削除されている(またはアクセスが拒否されている)場合でも、バケットの名前が残っているため、興味深いファイルを見つけることができます。 Wayback MachineのAPIを確認するには、enum_waybackというMetasploitモジュールを使用できます。

この投稿の最初から覚えているように、地域指定のURLを使用してバケットのコンテンツを参照することもできます。したがって、さらに良い結果を得るために、単純なbashワンライナーで、可能なすべてのAmazon S3エンドポイントのサブドメインをチェックできます。

読み取り中-rリージョン; do msfconsole -x "use \ auxiliary / scanner / http / enum_wayback; set DOMAIN $ region; \
OUTFILE $ region.txtを設定します。走る; exit "; done 

多くの場合、Wayback Machineは1つのバケットに数千枚の写真を返します。そのため、有効で一意のバケット名のみを引き出すために、いくつかの操作を行う必要があります。カットやawkなどのプログラムは、ここで素晴らしい友人です。

Wayback Machineは、398,7 MBのtxtファイルの形式で23498個の潜在的なバケットを提供しました。これらのバケットのうち4863個が公開されていました。

サードパーティのクエリ

私が紹介したい別の手法は、Google、Bing、VirusTotalなどのサードパーティにクエリを送信することです。外部サービスから興味深い情報を収集するプロセスを自動化できるツールは多数あります。それらの1つはSublist3rです。

繰り返しますが、各地域のサブドメインを検索し、一意のバケット名のみを抽出する必要があります。簡単なbashワンライナー:

読み取り中-rリージョン; python3 sublist3r.py -d $ region \を実行します
> $ region.txt;完了

結果として756が得られます。収集できるバケットは1つだけです。管理者向けのビール!

証明書の透過性ログを検索する

最後に紹介するテクニックは、証明書の透過性ログを見てバケット名を検索することです。証明書の透明性に詳しくない場合は、このプレゼンテーションをご覧になることをお勧めします。基本的に、発行されたすべてのTLS証明書はログに記録され、それらのログはすべて公開されています。このアイデアの主な目的は、証明書が誤ってまたは悪意を持って使用されていないことを確認することです。ただし、パブリックログの概念は、S3バケットも含めてすべてのドメインを明らかにします。幸いなことに、検索を実行している既に利用可能なツールであるバケットストリームがあります。さらに良いニュースは、このツールが見つけたバケットへのアクセス許可も検証していることです。それでは、試してみましょう。

$ python3 bucket-stream.py --threads 100 --log

571134の可能性を確認した後、バケットスキャナーは398の有効なバケットを返しました。それらの377が開いていました。

バケットのコンテンツを確認する

さて、何千ものバケット名を見つけましたが、次は何ですか?たとえば、これらのバケットのいずれかがパブリックアクセスまたは認証されたAWSユーザー(基本的にパブリックと同じ)アクセスを許可しているかどうかを確認できます。そのために、私のスクリプトBucketScannerを使用できます。これは、アクセス可能なすべてのファイルをリストするだけでなく、バ​​ケットへのWRITEパーミッションも検証します。ただし、この調査のために、次のようにbucket_readerメソッドを変更しました。

def bucket_reader(bucket_name):
    region = get_region(bucket_name)
    地域== 'なし'の場合:
        パス
    その他:
        バケット= get_bucket(bucket_name)
        結果= ""
        試してください:
            bucket.objects.all()のs3_objectの場合:
                s3_object.keyの場合:
                    「{0}は収集可能です」と出力します。format(bucket_name)
                    結果= "{0} \ n" .format(bucket_name)
                    append_output(結果)
                    ブレーク

それが最もエレガントな方法ではありませんが、バケット内に1つのファイルしか収集できない場合、変更されたスキャナーはこのバケットを収集可能として報告します。

リスク

一般公開されているファイルの中には、本当に面白いものがあります。しかし、機密データの漏洩が唯一のリスクではありません。

一部のバケットは公的に書き込み可能です。確かに、攻撃者はそのようなバケットをマルウェア配布ポイントとして使用できます。従業員に合法的なソフトウェアを配布するためにそのようなバケットを使用している場合はさらに恐ろしいです。そのようなシナリオを想像してください。感染したインストーラー。このシナリオの他のバリエーションは、S3研究者のトローリングです。 「Salary report — 2017.pdf」のような魅力的な名前の感染ファイルをアップロードします(もちろん、すべての責任ある研究者は、常に信頼できないファイルをサンドボックス環境にダウンロードしますよね?)

パブリックに書き込み可能なバケットのもう1つのリスクは、すべてのデータを失う可能性があることです。バケットのオブジェクトに対するDELETEパーミッションがなくても、WRITEパーミッションだけでも、ファイルを上書きできます。つまり、空のファイルでファイルを上書きすると、このファイルは誰にも利用できなくなります。この例を見てみましょう。

このようなシナリオでデータを保存できる唯一のメカニズムは、バージョン管理を有効にすることです。ただし、このメカニズムは高価な場合があり(バケット内の使用済みスペースのサイズが2倍になります)、多くの人が使用することを決めません。

私も議論を聞いた:

ああ、それはテスト目的の単なるバケツです。

さて、「テスト」バケットが違法コンテンツのストレージになった場合、…すみませんが、このアカウントに固定されたクレジットカードです。

明るい未来はありますか?

S3バケットのアクセス許可に関する問題はまだ存在しており、近い将来に劇的な変化が起こるとは思わない。 IMHOの人々は常にアクセスできるため、パブリックアクセスを許可します。S3サービスが他のサービスと連携する際にアクセス許可を指定することを心配する必要はありません。もう1つの理由は、アクセス許可の設定の単純な間違い(バケットポリシーの間違った場所に「*」文字を置くなど)または定義済みのグループを理解しない(例:「認証されたAWSアカウント」グループはAWS CLI)。

別の問題は、そのような問題を報告する方法です。バケットに固定されたメールはありませんので、誰に連絡すればよいかわかりません。バケットの名前は、それらが会社Xに属していることを示す場合がありますが、だれでも大まかに名前を付けることができることを覚えておいてください。だから、トローラーに気をつけて!

概要

24652個のスキャンされたバケットの場合、5241バケット(21%)からファイルを収集し、任意のファイルを1365バケット(6%)にアップロードできました。その結果に基づいて、問題がまだ存在していることは間違いなく言うことができます。一部のバケットは意図的に開かれていますが(たとえば、いくつかの写真、会社のパンフレットなどを提供します)、どちらも公開してはいけません。さらに多くのバケットを見つける他のクールな方法があると確信しているので、合理的な唯一の対策は...バケットに適切な権限を設定することです

また、AWS KingdomのSecuRingに関する7ステップガイドも参照してください。