AWS での Capital One ハッキングの技術的詳細

19 年 2019 月 106 日、Capital One は、現代のすべての企業が恐れている、データ侵害が発生したというメッセージを受け取りました。 140億000万人以上が影響を受けた。 米国の社会保障番号は 80 件、カナダの社会保障番号は 000 万件。 XNUMX の銀行口座。 不快ですね、そう思いませんか？

残念ながら、ハッキングは 19 月 XNUMX 日に発生しませんでした。 結局のところ、ペイジ・トンプソン、別名： 不規則、22年23月2019日からXNUMX月XNUMX日までの間に犯されました。 あれは ほぼXNUMXか月前。 実際、Capital One が何かが起こったことを発見できたのは、外部コンサルタントの助けがあったからです。

元Amazon従業員が逮捕され、250万ドルの罰金とXNUMX年の懲役刑が言い渡される…しかし、依然として多くのネガティブな感情が残っている。 なぜ？ なぜなら、ハッキング被害に遭った多くの企業は、サイバー犯罪が増加する中、自社のインフラやアプリケーションを強化する責任を逃れようとしているからだ。

とにかく、この話は簡単にグーグルで検索できます。 ドラマの話には入りませんが、次のことについて話します。 テクニカル 問題の側面。

まず、何が起こったのでしょうか？

Capital One では約 700 個の S3 バケットが実行されており、Paige Thompson がそれをコピーして吸い上げました。

次に、これも S3 バケット ポリシーの設定が間違っているケースなのでしょうか?

いいえ、今回は違います。 ここで彼女は、ファイアウォールが正しく構成されていないサーバーにアクセスし、そこから操作全体を実行しました。

待って、どうしてそんなことができるの?

さて、詳細はあまりありませんが、サーバーにログインすることから始めましょう。 私たちが知らされたのは、それが「誤って設定されたファイアウォール」を通じて起こったということだけでした。 つまり、Web アプリケーション ファイアウォール (Imperva) またはネットワーク ファイアウォール (iptables、ufw、shorewall など) のセキュリティ グループ設定や構成が間違っているという単純な問題です。 キャピタル・ワンは自らの罪を認め、穴を塞いだだけだと述べた。

ストーン氏は、Capital Oneは当初ファイアウォールの脆弱性に気付かなかったが、認識するとすぐに行動したと述べた。 ストーン氏は、ハッカーが重要な個人情報をパブリックドメインに残したと言われているという事実によって確実に助けられたと述べた。

なぜこの部分について詳しく説明しないのかと疑問に思われた場合は、情報が限られているため、推測することしかできないことをご理解ください。 ハッキングがCapital Oneによって残された穴に依存していたことを考えると、これは意味がありません。 そして、彼らがさらに詳しく教えてくれない限り、Capital One がサーバーを開いたままにした考えられるすべての方法と、誰かがこれらのさまざまなオプションの XNUMX つを使用する可能性のあるすべての方法を組み合わせてリストします。 これらの欠陥や手法は、非常に愚かな見落としから信じられないほど複雑なパターンまで多岐にわたります。 さまざまな可能性を考慮すると、これは本当の結論のない長い物語になるでしょう。 したがって、事実がある部分を重点的に分析しましょう。

最初のポイントは、ファイアウォールで何が許可されているかを知ることです。

ポリシーまたは適切なプロセスを確立して、開く必要があるものだけが開かれるようにします。 セキュリティ グループやネットワーク ACL などの AWS リソースを使用している場合、明らかに監査するためのチェックリストは長くなる可能性があります...しかし、多くのリソースが自動的に作成されるのと同様 (つまり、CloudFormation)、監査を自動化することも可能です。 新しいオブジェクトの欠陥をスキャンする自家製スクリプトであれ、CI/CD プロセスのセキュリティ監査のようなものであれ、これを回避する簡単なオプションがたくさんあります。

この話の「面白い」部分は、キャピタル・ワンが最初からその穴を塞いでいたら…何も起こらなかっただろうということです。 だから、率直に言って、何かが実際にどのように起こっているかを見るのはいつも衝撃的です ものすごく単純 企業がハッキングされる唯一の理由になります。 特にCapital Oneと同じくらい大きいもの。

それで、内部のハッカー - 次に何が起こったでしょうか?

さて、EC2 インスタンスに侵入した後は...多くの問題が発生する可能性があります。 誰かをそこまで行かせると、事実上ナイフの刃の上を歩いているようなものです。 しかし、どうやって S3 バケットに侵入したのでしょうか? これを理解するために、IAM ロールについて説明します。

したがって、AWS のサービスにアクセスする 3 つの方法は、ユーザーになることです。 さて、これは非常に明白です。 しかし、アプリケーションサーバーなどの他の AWS サービスに SXNUMX バケットへのアクセスを許可したい場合はどうすればよいでしょうか? それが IAM ロールの目的です。 これらは XNUMX つのコンポーネントで構成されます。

1. 信頼ポリシー - このロールを使用できるサービスまたはユーザーは何ですか?
2. アクセス許可ポリシー - このロールでは何が許可されますか?

たとえば、EC2 インスタンスが S3 バケットにアクセスできるようにする IAM ロールを作成するとします。まず、EC2 (サービス全体) または特定のインスタンスがロールを「引き継ぐ」ことができる信頼ポリシーを持つようにロールを設定します。 ロールを受け入れるということは、ロールの権限を使用してアクションを実行できることを意味します。 次に、アクセス許可ポリシーにより、「役割を引き受けた」サービス/人/リソースは、特定の 3 つのバケットにアクセスする場合でも、Capital One の場合のように 700 以上のバケットにアクセスする場合でも、SXNUMX 上であらゆる操作を行うことができます。

IAM ロールを持つ EC2 インスタンスに入ったら、いくつかの方法で認証情報を取得できます。

1. インスタンスのメタデータは次の場所でリクエストできます。 http://169.254.169.254/latest/meta-data

   このアドレスでは、任意のアクセス キーを使用して IAM ロールを見つけることができます。 もちろん、インスタンス内にいる場合に限ります。

2. AWS CLIを使用して...

   AWS CLI がインストールされている場合、IAM ロール (存在する場合) からの認証情報がロードされます。 残っているのは、インスタンスを介して作業することだけです。 もちろん、信頼ポリシーがオープンであれば、ペイジはすべてを直接行うことができます。

したがって、IAM ロールの本質は、一部のリソースが他のリソースに対してユーザーに代わって動作できるようにすることです。

IAM の役割を理解したところで、ペイジ・トンプソンが何をしたかについて話しましょう。

1. 彼女はファイアウォールの穴を通ってサーバー (EC2 インスタンス) にアクセスしました。

   公式記録に記載されているように、それがセキュリティ グループ/ACL であっても、独自の Web アプリケーション ファイアウォールであっても、この穴を塞ぐのはおそらく非常に簡単でした。

2. サーバーにアクセスすると、彼女は自分自身がサーバーであるかのように振る舞うことができました。
3. IAM サーバー ロールにより、これらの 3 以上のバケットへの S700 アクセスが許可されていたため、これらのバケットにアクセスできました。

その瞬間から、彼女がしなければならなかったのは、コマンドを実行することだけでした List Bucketsそしてコマンド Sync AWS CLI から...

Capital One Bank は、ハッキングによる被害額を 100 億ドルから 150 億 XNUMX 万ドルと見積もっています。 このような被害を防ぐために、企業はクラウド インフラストラクチャの保護、DevOps、セキュリティの専門家に多大な投資を行っています。 そして、クラウドへの移行はどれほど価値があり、費用対効果が高いのでしょうか? サイバーセキュリティの課題がますます増えているにもかかわらず、 パブリック クラウド市場全体は、42 年第 2019 四半期に XNUMX% 成長しました!

この話の教訓: 安全を確認してください。 定期的な監査を実施します。 セキュリティ ポリシーに対する最小特権の原則を尊重します。

(それは 法的報告書の全文をご覧いただけます)。

出所： habr.com