パブリック クラウドで公開されているホストと構成不備の探索

This post is also available in: English (英語)

概要

この調査では、Amazon AWS、Microsoft Azure、およびGoogle Cloud Platformでホストされていて、インターネットに接続しているサービスのセキュリティの現状について説明します。パブリック クラウドはますます広く使用されるようになり、2018年にはクラウド インフラストラクチャにかける総費用が45.6%増加したことが報告されています。クラウド サービス プロバイダ(CSP)の市場シェアは、Amazon AWS(31.3%)がトップを維持し、その後にMicrosoft Azure(16.5%)、Google Cloud Platform(9.5%)が続きます。企業は、CSPで提供されているさまざまな「as a service」モデルを利用することで、ITインフラストラクチャについて心配することなく、業務の規模を俊敏かつ柔軟に拡張できます。しかし、安全でない構成が1つ存在するだけで、インフラストラクチャ全体がリスクにさらされます。

パロアルトネットワークスの脅威インテリジェンスチームUnit 42は、一般に公開されているホストに注目してパブリック クラウドを評価することに焦点を当てました。公開されているサービス、サービスのバージョン、およびサービスの脆弱性などの情報を収集して、ホストごとのセキュリティ体制を判断しました。また、パブリック クラウド内の悪意のあるIPと過去の既知の脆弱性の間の相関関係を調査しました。分析の結果、以下のことが明らかになりました。

• 47%: AzureのSSHサーバーのうち「use password-login (パスワードによるログインを使用)」オプションを使用しているために総当たり攻撃に対する脆弱性が存在する割合
• 32%: 公開されているパブリック クラウドのホストのうちSSHサーバーをオープンにしている割合
• 24%: 公開されているパブリック クラウドのホストのうち既知の脆弱性が存在する割合
• 50%: 公開されているパブリック クラウドの脆弱性が少なくとも2年前から既知である割合
• 61%: 公開されているパブリック クラウドのホストのうちTLSv1.1以前のバージョンをいまだに使用している割合(v1.2とv1.3はそれぞれ2008年と2018年にリリースされた)

さらに、攻撃者がパブリック クラウドを足がかりにして攻撃を開始している証拠を発見しました。クラウド インフラストラクチャは依然として、オンプレミス インフラストラクチャより安全であると考えられています。これは、CSPがインフラストラクチャの保守とアップグレードに膨大なリソースを費やしているという理由からです。NISTの脆弱性情報データベース(NVD)によれば、WindowsまたはLinuxでは毎年数千件の脆弱性が見つかっているのに対して、2018年にAWS、Azure、およびGCPで識別されたCVEの数はそれぞれ20件未満です。しかし、CSP全体では、クラウド セキュリティ インシデントが途切れることがありません。たとえば、自動投票機のパスワードの漏洩、インド国民の記録の漏洩、ユーザー ジョブ プロファイルの漏洩が発生しています。RedLock、NetSkope、およびMcAfeeによる以前の調査では、ほとんどのクラウド セキュリティ インシデントは、CSPではなく、クラウド利用者の構成不備に起因していることがわかっています。セキュリティに関する責任の一部はユーザーからCSPへと徐々に移行していますが、その一方でユーザーは常にセキュリティの設計と決定に責任を負います。安全なクラウド インフラストラクチャは、CSPとユーザーの両者がそれぞれの責任を果たした場合にのみ実現できます。

このブログでは、パブリック クラウド サービス プロバイダの現状についてレビューし、公開されているサービス、公開されている脆弱性、および悪意のあるIPについて詳しく説明します。最後に、ユーザーがパブリック クラウド インフラストラクチャを保護するのに役立つ、一連のオープンソース ツールを紹介します。

パブリック クラウドの概要

CSPは、ユーザーがインフラストラクチャ、オペレーティング システム、ソフトウェア プラットフォーム、さらには機能さえもクラウドに委任できるようにする、さまざまなサービスを提供します。図1は、ユーザーとクラウド サービス プロバイダの間で共有する責任を示しています。インフラストラクチャをクラウドに委任した場合(Infrastructure as a serviceまたはIaaS)、システムを管理するための最高レベルの制御機能がユーザーに与えられます。一方で、機能をクラウドに委任した場合(Functions as a serviceまたはFaaS)、ユーザーはプラットフォーム、復元力、および拡張性を気にすることなく、最も簡単な手順でコードを実行できます。この調査では、クラウド プロバイダの責任範囲が広がれば、ユーザーによるセキュリティ上の間違いが減ることを示します。

図1.「as a service」運用モデル

AWS、Azure、GCPの3つがクラウド市場シェアの60%を占めることから、この調査ではこの3つのCSPのみに焦点を当てています。AWS、Azure、GCPが公開しているIP範囲を確認したところ、それぞれ4,180万個、1,400万個、および700万個のIPv4アドレスを所有しています。これらのアドレスは、表1に示すように、複数のクラウド サービスに分散しています。GCPはサービスごとのIPブロック サイズを公開していないので、この表ではAWSとAzureのみを示しています。この調査の大部分は、これらのIPブロック内で公開されているホストを探して、そこで実行されているサービスを分析するという方法で行いました。

表1. AWSとAzureがクラウド サービスごとに割り当てているパブリックIPの数

パブリック クラウドで公開されているサービス

アプリケーション サービスがインターネット全体に公開されている場合、そのサービスがどれだけ安全であってもリスクがなくなることはありません。HTTP、POP3、VPNなどの一部のサービスは、ユーザーがどこからでも利用できるように、インターネットに対してオープンになるように設計されています。しかし、多くのアプリケーション サービスは、インターネットに対して広くオープンである必要はありません。たとえば、データベースは、通常は特定のネットワークの少数のアプリケーション サーバーだけが利用します。また、SMBサーバーは、単一ローカル エリア ネットワーク内でファイルを共有するように設計されています。これらのアプリケーション サービスをインターネットに対してオープンにすると、システムへの攻撃ベクトルが簡単に作成されてしまいます。CSPは、インターネットへのサービスの展開を容易にしますが、構成に不備のあるサービスや脆弱なサービスもすぐに公開されてしまいます。

パブリック クラウドで公開されているホストとサービスを検索するために、弊社はShodanとCensysで、AWS、Azure、およびGCPが所有しているIPブロックについて問い合わせました。その結果、930万台のAWSホスト、150万台のAzureホスト、および250万台のGCPホストが見つかりました。この調査では、インターネット全体に対して公開できるほど安全ではない8つのサービスに注目しました。表2に、これらの検索結果を示します。パブリック クラウドで公開されているホストのうち32%がSSHサービスをオープンにしているという結果は衝撃的です。SSHは最も安全なプロトコルの1つではありますが、それでもこの強力なサービスをインターネット全体に公開することは危険すぎます。どのようなものであれ、構成不備や弱い/漏洩した資格情報があれば、ホストの侵害につながる可能性があります。CISベンチマークは、SSHサービスへのインバウンド トラフィックは少数のホストに制限する必要があることを示唆しています。これらのSSHサーバーがどれだけ安全なのか興味があったので、弊社はパブリック クラウドでホストされている米国ベースのSSHサーバー280万台をすべてスキャンしました。

強固なセキュリティを構築するには、SSHサーバーの認証を、総当たり攻撃に対して脆弱なパスワードベースの認証ではなく、公開/秘密キーのペアによる認証にする必要があります。驚いたことに、AzureにあるSSHサーバーのうち約50%が、パスワードによるログインを有効にしていました。これは、AWSとGCPではどちらも5%未満でした(表3)。あまりに差が大きいことから、これは偶然ではないと考え、Azureクラウドを詳しく調査して、これらのSSHサービスの作成方法を確認しました。原因はすぐにわかりました。Azure Virtual Machinesでは、ほとんどのSSHサービスがVM作成プロセス中に構成されます。図2に、AzureのSSH構成のスクリーンショットを示します。Azureでは、パスワード認証と公開キー認証の2つのオプションが提示されています。この場合、おそらく公開キー認証の仕組みやキーの作成方法がわからないという理由でユーザーの半数がパスワード認証を選択するだろうという考えには合理性があります。そうは言っても、パスワードは思い付くのも再利用するのも簡単ですが、公開キーを作成するにはこのAzureのドキュメントで説明されている多くの手順を別途実行する必要があります。

AWS環境とGCP環境の場合、どちらもパスワード ログインがオプションとして提示されないので、これと同じ挙動は見られませんでした。AWSは、新しいキーのペアを作成して、ユーザーにVMを起動する前に秘密キーをダウンロードするように指示します(図3)。GCPも、VMを作成する際に自動的にキーのペアを作成して、Compute Engineの内部でキーを管理します(図4)。この発見は、UI設計がユーザーの挙動にどれほどの影響を与えて、システムを安全でない状態に誘導する可能性があるのかを示しています。

パブリック クラウドの脆弱性

弊社は、AWS、Azure、およびGCPの各パブリック クラウドで公開されているアプリケーション サービスで、それぞれ2,900万件、170万件、および400万件の脆弱性を特定しました。平均して、脆弱なホスト1台につき11件の脆弱性があることになります。興味深いことに、3つのCSPの上位10の脆弱性はほとんど同じであり、表4に示すように、そのリストにはOpenSSHとHttp_Serverの2つの製品しか出現していません。これは、Webアプリケーションがインターネットに対して公開されている最も一般的なサービス(http/https)であり、OpenSSHとHttp_ServerがWebアプリケーションの背後で最も広く使用されているテクノロジだからです。

すべてのクラウド サービスにわたって脆弱性を詳細に分析したところ、AWSの脆弱性のうち99.8%はEC2によるものであり、Azureの脆弱性のうち99.8%はAzure Virtual Machinesによるものでした。AWS EC2とAzure Virtual Machineはどちらも、ユーザーがオペレーティング システム全体を展開して管理できるIaaSです。その結果、残念なことにほとんどのユーザーはセキュリティを優先しておらず、システム内の脆弱性に気付いていません。

図5は、パブリック クラウドにおける脆弱性の数ごとのホストの数を示しています。横軸は脆弱性の数、縦軸はホストの数です。AWSのホストの25%、Azureのホストの8%、およびGCPのホストの27%が脆弱であるとみなされます。脆弱なホストの大部分には、1～10個の脆弱性があります。

図6は、CVEのリリース年ごと、および重大度評価ごとのパブリック クラウドの脆弱性の数を示しています。横軸はCVEの年、縦軸は脆弱性の数であり、色はCVSS v2の重大度を表します。図に示すように、脆弱性のうち70%は重大度が中、17%は重大度が高と評価されています。AWSの脆弱性の18%、Azureの脆弱性の21%、およびGCPの脆弱性の12%は、5年以上前に発生しています。これらの古い脆弱性は、パブリック クラウドで今でも実行されているレガシー アプリケーションまたはサポートが終了したアプリケーションの数を示しています。これらの古い脆弱性にパッチを適用するには、アプリケーションを刷新する必要があるので、開発者は通常、この「パンドラの箱」を開けるのを避けます。

Secure Socket Layer (SSL)とTransport Layer Security (TLS)は、最新のWebアプリケーション セキュリティの基盤となっています。これらは、コンピュータ ネットワークに通信のプライバシーとデータ整合性をもたらします。多くの脆弱性はプロトコルの古いバージョンで発見されており、いくつかの重大な脆弱性は中間者攻撃を可能にします。SSL/TLSが構成されているすべての公開されているホストを調査したところ、図7に示すように、61%を超えるホストがいまだにTLS v1.2より古いプロトコルを使用していることが判明しました。

TLS v1.2がリリースされてから約10年が経過しており、TLSv1.0とTLSv1.1はどちらも2020年に使用中止になる予定なので、この数字は気にかかります。また、これらの古いプロトコルのほとんどがパッチ適用とアップデートのサイクルに従っていないIaaS所有者によって管理されているのも驚くことではありません。

パブリック クラウドからの攻撃者

パブリック クラウドは、開発者とIT部門の業務を簡素化するだけでなく、悪意のある攻撃者にも攻撃を開始または方向転換するための基盤を提供します。パブリック クラウドの脆弱なアプリケーション サービスは、クラウド インフラストラクチャに対する攻撃ベクトルを作成します。攻撃者から見ると、パブリック クラウド インスタンスの侵害は、オンプレミス サーバーの侵害とそれほど違いません。しかし、インスタンスが特定のCSPでホストされていることがわかると、攻撃者はそのエクスプロイトを巧みに兵器化して、監視を回避できます。また、クリプトジャッキング攻撃の場合は、侵害されたパブリック クラウド インスタンスが高い計算能力を持っている可能性も高くなります。Unit 42は、悪意のある攻撃者がパブリック クラウド インフラストラクチャを標的とするマルウェアを開発している証拠を発見しました。リサーチャーは、この問題を理解するために、FacebookのThreat Exchangeを通じて2018年の悪意のあるIPを分析しました。16,764個の悪意のあるIPのうち、AWSからのものが985個、Azureからのものが109個、GCPからのものが34個ありました。報告されているIPのうち合計7%が、この3つのCSPからのものでした。

これらの悪意のあるIPが、攻撃者が侵害または作成したホストかどうかはわかりません。弊社は、脆弱性が多いホストほど侵害される可能性が高くなると仮定しました。この仮定を検証するために、報告されているIPの悪意のある活動期間中の脆弱性をチェックしました。図8は、悪意のあるパブリック クラウドIPの脆弱性統計を示しています。左側の図は、既知の脆弱性があるIPの割合です。右側の図は、各IPで発見された脆弱性の平均数です。1,128個の悪意のあるパブリック クラウドIPのうち60%に既知の脆弱性が存在し、ホストあたりの脆弱性は平均28個でした。公開されているパブリック クラウド ホストのうち脆弱性が存在するのは24%のみで、ホストあたりの脆弱性は平均11個であるという事実と比較すると、これらの数字は統計的に有意です。これらの数字から、高い確率で脆弱なホストは侵害されていて、悪意のある活動に使用されていたと考えられます。最後に、存続期間の短いドメイン名に関連付けられている悪意のあるIPを探しました。存続期間の短いドメイン名は、悪意のあるホストに共通する特徴です。その結果、悪意のあるパブリック クラウドIPのうち20%が、12か月以内に55個を超えるドメイン名に関連付けられていたことがわかりました。これらの数字は、パブリック クラウドが攻撃を開始するための足がかりになっていることを示しています。

結論 - パブリック クラウドは保護が必要

パブリック クラウドが次世代のITで果たす役割はますます重要になり、その普及は加速し続けています。AmazonがAWSの提供を開始したのは13年以上前ですが、CSPがセキュリティを重視し始めたのはここ数年のことです。Amazonの全クラウド セキュリティ製品の約75%は、過去3年以内に提供が開始されたものです。

パブリック クラウドでは、セキュリティに対する責任をCSPとユーザーが共有します。パブリック クラウドでは非常に多くのクラウド サービスが提供されているので、ユーザーのほとんどはセキュリティに対する責任を負っていることにおそらく気付いていません。CSPは、自社のクラウド サービスを保護するだけでなく、ユーザーの安全でない挙動を防止および検出するための防壁を構築する必要があります。今回の調査結果は、「標準提供されるセキュリティ」の重要性を改めて示すものでした。安全でないオプションが1つも存在しなければ、ユーザーが安全でない決定を下すことはありえません。CSPがユーザーの安全でない挙動を事前対処的に監視し、ユーザーに実行可能な修復策を示して警告していれば、これほど多くの公開されたサービスは存在しなかったでしょう。

しかし、それでもなお、ユーザーが責任を負って設計や決定を行う必要がある部分は残っています。ユーザーは、クラウドで作業するためにセキュリティについて最低限の認識を持つ必要があります。FaaS(Function as a service)によってユーザーにかかる保守の負担はかなり減りましたが、開発者はいまだにコードを記述して、機能ごとに適切な権限を割り当てる必要があります。それらの機能が使用するライブラリに新しい脆弱性が見つかった場合、ソース コードにパッチを適用して更新できるのは開発者だけです。CSPが公開されているSSHサービスに対して警告し、インバウンド トラフィックを制限するファイアウォール構成を推奨する場合、ファイアウォールのホワイトリストに追加する必要があるIPを知っているのはシステム管理者だけです。こうしたちょっとした作業は忘れられがちですが、壊滅的な結果を招く可能性があります。貧弱な資格情報や公開されたデータベースによって引き起こされるセキュリティ インシデントの量が莫大なため、セキュリティ コミュニティは何も感じなくなっています。さらに、関連して発生するセキュリティ インシデントのペースが鈍化する兆候はありません。さまざまな組織がさまざまなCSPで単純に同じ過ちを繰り返しています。

完全なセキュリティを実現することはほとんど不可能ですが、各自が適切な注意を払って、侵害される可能性を最小限に抑える必要があります。オープンソース コミュニティのおかげで、複雑なジョブを単純化する無料のツールが大量に提供されています。ユーザーがクラウド インフラストラクチャに存在するセキュリティ ギャップを埋めるために利用できるツールを以下に示します。

脆弱性スキャナー: 開発者は、常にコードをスキャンして、既知の脆弱性の有無を確認する必要があります。Prisma Scan、Clair、OpenSCAP、およびOpenVASは、システム内の脆弱なパッケージを特定できます。

クラウド インフラストラクチャの監査: システム管理者は、常にクラウド インフラストラクチャを監査して、構成不備を検出する必要があります。Prisma IaC Scanner、ScountSuit、およびCloudSploitは、クラウド インフラストラクチャで構成不備が疑われるコンポーネントを特定できます。

公開されたホストとサービスの監視: システム管理者は、インターネットで各自が所有するIPブロックを監視できます。ShodanとCensysは、定期的にインターネット全体をスキャンしているIoT検索エンジンです。