パブリック・クラウド・インフラは、ハチがハチの巣に集まるように、暗号化されたマイナーを引き寄せる

facebookで共有
twitterで共有
linkedinで共有
emailで共有
printで共有
whatsappで共有
クラウド戦略を確立している多くのお客様、見込み客、パートナーと話をしていると、共通のパターンが見えてきます。その多くは、IAMアクセスキーが侵害された結果、クラウドのインフラが暗号化されたマイニング活動に悪用されるという問題を抱えています。侵害が発見されるまでの期間、指数関数的なクラウドコストを支払うことになることを考えると、これは恐ろしいことです。

Crypto Miningとは?なぜそれが脅威なのか?

"暗号通貨の採掘(クリプトマイニング)は、コンピュータの処理能力を使って複雑な数学的問題を解決したり、デジタル取引を検証したりするもので、採掘者は少量のサイバー通貨で報酬を得ることができます。"

ソース : サイバー.gov.au

違法なクリプトマイニング=クリプトジャッキング

ハッカーは顧客のクラウドに侵入し、マイニング用に大容量のCPUを搭載したサーバーを大量に稼働させ、不幸な顧客が侵入に気づくまで(ほとんどの場合、クラウド事業者から驚くべき請求書を受け取った後に)収益を上げ続けることができるからです。

最近の多くの調査では、クラウドにおける設定ミスの99%が気づかれていないことが指摘されています。

これらの一般的に普及している誤設定も パブリック・クラウドがCrypto minerの金鉱となる理由.このような設定ミスを利用して、採掘者は 無制限のCPU とコンピューティングパワーを駆使しています。

クラウド・クレデンシャル侵害の概要

先日、Google Cloudでサービスアカウントキーが侵害され、暗号化されたマイニング活動が行われたお客様にインタビューを行いました。

この事件を複数のステップに分け、攻撃者が流出した認証情報をどのように利用するか、そして最も重要なことは、このような事態が発生した場合に組織がどのように対処するかを理解することです。

事件の概要

クラウドプロバイダー

  従業員が誤ってGCPサービスアカウントのユーザー名/キーを個人のGITレポに保存してしまいました。

その後まもなく、Googleからサービスアカウントの侵害が検出されたというメールが届きました。そのメールには、次のような内容が書かれていた(検知時間を大幅に短縮してくれる救世主のようなサービスと言わざるを得ない)。

このメールでは、問題となっているサービスアカウントと、公開されているGithubレポのURLが明確に示されていました。また、サービスアカウントの廃止を含む2つのステップを推奨しており、これは必ず実行しなければなりません。

しかし、REMEMBER。 善人(クラウドサービスプロバイダ)と同様に、悪人もGITリポジトリを継続的にスキャンして、IAMアクセスキーを公開しているコードのコミットを探しています。あなたがミスをした瞬間、数秒後に誰かがそれを悪用することは間違いありません。

調査

お客様が当該従業員に連絡を取り、個人のGITHub Repoを隔離しました。 そのGitレポをさらに調査したところ、すぐにはIOC(Indicators Of Compromise)は見つかりませんでした。 ありがたいことに、クラウド管理者の一人が、そのサービスアカウントがアクセスしていたGCPプロジェクトを調べ始めました。なんと、そのプロジェクトには、各地域に大容量のサーバーが多数設置されていたのです。

  これらのVMを放置しておくと、数万ドルのクラウド費用が発生する可能性がありました。

鉱夫が狙うのはこれこれは、ほとんどの組織が、これらの侵入を検知して対処する手段やメカニズムを持っていない可能性が高いということです。

それはテーブルの上に残されたお金です。

もしこれが私や私の組織に起こったら、どうすればいいのでしょうか?

すべてのクラウド事業者は、このような事態が発生した場合に組織がとるべき2つの緊急措置を推奨しています(上の写真を参照)。
以下、2つのステップをご紹介します。
ステップ1
ステップ#1は、クラウドインフラへのさらなるダメージを最小限に抑えるための安全対策です。すべての認証情報を無効にすることで、ハッカーやボットが不正なリソースを起動したり、さらなるダメージを与えたりすることを防ぎます。
ステップ#2は難しい - なぜ?

複数の要因があります。パブリック・クラウドは動的であるため、ベースラインで固められた環境を持つことは非常に困難です。

すべてのクラウドプロバイダーには複数のリージョンが存在します。漏洩したサービスアカウントは、それらのすべての地域でインフラストラクチャ/リソースを作成する権限を持っている場合があります。クラウドプロバイダーのウェブコンソール画面では、リソースの地域別表示が常に行われています。そのため、どの地域にも新しいコンピュートリソースや請求可能なリソースが作成されているかどうかを確認するには、地域を切り替える必要があります。

漏洩したサービスアカウントがクロスアカウントのパーミッションを持っていたとしたら?もしあなたがクラウド管理チームの一員であれば、悪夢のようなシナリオです。何百、何千ものアカウントやプロジェクトを抱えている場合は容易ではありません。

どのようにしてリスクをトリアージし、抑制するのか。

まず、侵害されたサービスアカウントのすべての(または一覧の)認証情報を確実にREVOKEします。

次に、パニックになるのではなく、クラウドサービスプロバイダーのIAMログを利用して、侵害されたサービスアカウントで実行されたアクティビティを把握します。

GCPを使用している場合(この例のように)、StackdriverのIAM監査ログを確認します。問題のサービスアカウントでフィルタリングし、最近のすべてのアクティビティを探します。その後のフィルタリングされたリストには、新しく起動されたEC2インスタンス(ある場合)や、そのサービスアカウントによるその他のリソースの作成/削除/変更アクティビティが表示されます。

不正な起動を発見した場合は、直ちにシャットダウンし、クラウド事業者にチケットを発行して報告してください。クラウドプロバイダーは、このような侵入行為を適時に開示すれば、通常、発生したコストを免除してくれます。

複雑になることはありますか?

絶対に - すべてのクラウド・アカウントのログを一元管理していない場合、クラウド管理者にとっては悪夢となります。そうなると、クラウド管理者にとっては、異なるクラウド・アカウントのすべてのログ・ファイルをかき分けて、侵害を検知することは悪夢のような作業になります。

AWSの場合、攻撃者は通常ロールチェイニングを使用してクラウドを横に移動するため、非常に厄介なことになります。クラウドアカウントでのロールチェイニングを検出してトリアージし、ルートイベントを絞り込むのは複雑で時間がかかります。

この記事では、「クリプトジャッキング」の例を挙げ、クリプトマイナーが一般的なクラウドの誤設定を利用して、パブリッククラウドのコンピュートリソースを悪用する様子を紹介しました。

  しかしサービスアカウントの侵害は、決してクリプトジャッキングの活動に限ったことではありません。ひとたび侵入者が現れれば、クラウド・インフラに壊滅的なダメージを与えることができます。サービスアカウントに管理者権限が与えられている場合、彼らはあなたの大切なデータを探し出して流出させたり、稼働中の本番サーバーを停止させたりすることができます。

クラウドをクリプトジャッキングから守るために

お客様のクラウドをクリプトジャッキング行為から守るために、以下の手順をお勧めします。

C3Mはどのようにクラウドのリスクを軽減することができるのでしょうか?

C3Mがお手伝いできるのは、以下の4つの分野です。
視認性-。
セキュリティガバナンス
報告
オートメーション

パブリック・クラウドは本質的に安全に設計されています。 安全に設定するだけ.クラウドを正しく設定する方法についてご質問がありますか?- ご質問があれば、下記までご連絡ください。 info@c3m.io 当社のクラウドセキュリティSMEが、お客様のチームに30分間の無料セッションを提供します。コミットメントは必要ありません。

関連記事