投稿者：Aleksandar Nikolich、David Maynor
執筆協力：Nick Biasini
MEMCACHED：安全性についての問題、進まないパッチの適用
最近、システムに存在する明らかな脆弱性を利用して、組織に大きな影響を与えるランサムウェア攻撃が、世界的な規模で複数実行されるという事件が発生しました。このようなタイプの脆弱性に対しては、攻撃が実行される前にパッチを適用して、組織による対処を行うことができたはずです。ここでご紹介するのは、パッチの適用がタイムリーかつ適切な方法で行われなかったことが主な原因で、一連の大規模な攻撃が成功してしまった最新の例です。2016 年の後半、Talos は、Memcached というソフトウェア プラットフォームに存在する一連の脆弱性についての情報を開示しました。この脆弱性の公開後、Talos は脆弱なシステムの数に加えて、パッチが適用されたシステムの比率についてのモニタリングを行ってきました。このブログでは、この脆弱性の概要を簡単に説明し、この 6 ヵ月の間に Talos がインターネット全体を対象に実行してきたスキャンによって判明した問題について紹介します。
Memcached とは何か
Memcached は動的な Web アプリケーションを高速化することを目的とした高性能なオブジェクト キャッシング サーバです。一部の非常によく利用されているインターネットの Web サイトでも使用されています。Memcached では、任意のデータの保存と取得を行うために ASCII ベースとバイナリ ベースの 2 つのバージョンのプロトコルが使用されています。バイナリ プロトコルは規模を考慮して最適化されています。
Memcached は Web アプリケーション サーバのアクセスを前提として使用されるものであり、どのような状況であっても信頼できない環境で公開されるべきものではありません。このサーバの新しいバージョンでは SASL を基にした基本認証がサポートされています。私たちの調査では、SASL が使用されていることはごくまれです。
検証と脆弱性
昨年の 10 月、私たちは Memcached サーバのソース コードの検証を行い、3 つの脆弱性を確認しました。これらの脆弱性にはいずれも類似点があります。3 つの脆弱性はすべて、バイナリ プロトコルの実装に存在しています。2 つの脆弱性の原因は、キャッシュされたオブジェクトの追加とアップデートを処理するコードに関係しており、もう 1 つの脆弱性は、前述した SASL 認証のメカニズムに原因があります。3 つの脆弱性はすべて、整数オーバーフローによるものです。これらの脆弱性は、制御されたヒープ バッファ オーバーフローを引き起こします。また、プロトコルの性質が悪用され、機密性のあるメモリが開示されることから、直接的かつ確実にデータを奪われる可能性があります。
この結果の通知を受けたベンダーはすぐにパッチを発行しました。パッチの内容が十分であることは私たちが検証しています。新しいパッチは 10 月 31 日に公開されました。この脆弱性に割り当てられた CVE ID は CVE-2016-8704 であり、Talos では TALOS-2016-0219 として追跡されました。このパッチの公開後すぐに、複数のメジャーな Linux ディストリビューションで、パッチと独自のアドバイザリが公開されました。注目すべき事項の 1 つは、これらのメジャー ディストリビューション（Ubuntu や Fedora など）が、サーバのバージョンを新しいものにせずにパッチをバックポートしたことです。参考資料：
- http://www.talosintelligence.com/reports/TALOS-2016-0219/ [英語]
- http://www.talosintelligence.com/reports/TALOS-2016-0220/ [英語]
- http://www.talosintelligence.com/reports/TALOS-2016-0221/ [英語]
- https://access.redhat.com/security/cve/cve-2016-8704 [英語]
- https://www.ubuntu.com/usn/usn-3120-1/ [英語]
2017 年 1 月の MongoDB への攻撃
ここで、別の事例について少し見てみましょう。12 月下旬または 1 月上旬ごろ、MongoDB サーバに対する大規模な攻撃が表面化しました。
MongoDB は、メモリ常駐の NoSQL データベースです。Memcached と同様に、MongoDB は信頼されない環境には公開されないことを前提としていますが、このことを開発者が見落としてしまい、実稼動サーバがインターネット経由で自由にアクセスできる状態になっていることがあります。
非常に多くの MongoDB サーバがインターネット上で無防備な状態になっていることはよく知られており、この事実を悪用して利益を得ようとする犯罪グループが現れました。認証手順やアクセス制御が存在しないことも、こうした犯罪者たちにとっては好都合でした。数日のうちに、アクセス可能な多数の MongoDB ホストが、ランサムウェアによる攻撃を受けることになりました。
こうした犯罪者たちの基本的な手口は、対象となるサーバに接続し、サーバからあらゆるデータを盗み出して、データの身代金として一定額のビットコインを要求するメッセージを残すというものです。間もなく、目的を同じくする複数のグループが同じサーバに攻撃を仕掛けていることが明らかになりました。これで、攻撃当初は可能性があったかもしれないデータの復旧が絶望的になりました
こうした攻撃がメディアで広く取り上げられたたため、この問題についての認識が高まりました。これで無防備な状態のサーバの数が減ることが期待されました。
Memcached も同じ道をたどるのか
MongoDB を巡る一連の騒動から、Memcached にも似たような攻撃の影響があるのではないかということが懸念されました。確かに Memcached は MongoDB とは異なりデータベースではありませんが、やはり機密情報が含まれています。また、サービスが停止することで、そのサービスに依存するサービスがさらに停止するという状況を招く可能性があります。私たちは、Memcached の脆弱性に関して、Talos で把握した潜在的な攻撃対象領域を評価すると同時に、パッチの適用状況についても調査することにしました。
そのためにインターネットのスキャンを行った結果をご紹介します。
スキャン
必要なデータを正確に取得するために、特別なスキャンが実行されました。必要とされたデータ ポイントは以下のとおりです。
- インターネット経由で直接アクセス可能なサーバの数
- 脆弱なままの状態になっているサーバの数
- 認証が使用されているサーバの数
- 認証が有効になっているが脆弱なままであるサーバの数
サーバから返されるバージョンを利用することはできませんでした。先ほど述べたとおり、多数のディストリビューションがセキュリティ パッチをバックポートしているため、バージョン文字列がパッチ レベルを反映しているとは限らないためです。そのため、私たちは対象のサーバに 1 つのパケットを送信し、応答からサーバが脆弱であるかどうかを判断するという特別なテストを考案しました。
まず、2 月の下旬に数回のスキャンが実施されました。この最初のデータセットの結果を経て、私たちは認証が有効になっているサーバのみを対象とした別のスキャンを行いました。このスキャンは 3 月の上旬に実施されました。
スキャンの結果
収集されたすべてのデータから、ほぼ予想どおりの結果が明らかになりました。100,000 を超えるアクセス可能なサーバのうち、約 80 % がまだ脆弱な状態であり、認証が有効になっているサーバは 22 % にすぎませんでした。興味深いことに、特別なテストを実行したところ、認証が有効になっているサーバのほぼすべてが、CVE-2016-8706 に対して引き続き脆弱であるということが明らかになりました。具体的な数字は以下のとおりです。
- 有効な応答があったサーバ：107,786
- まだ脆弱であったサーバの合計：85,121（～ 79 %）
- 脆弱ではなかったサーバの合計：22,665（～ 21 %）
- 認証が要求されるサーバの合計：23,907（～ 22 %）
- 認証が要求されるサーバのうち、脆弱なものの合計：23,707（～ 99%）
国別の数字も下記のとおり、予想されたものでした。
すべてのサーバ
- 36,937 – 米国
- 18,878 – 中国
- 5,452 – 英国
- 5,314 – フランス
- 3,901 – ロシア
- 3,698 – ドイツ
- 3,607 – 日本
- 3,464 – インド
- 3,287 – オランダ
- 2,443 – カナダ
脆弱なサーバ
- 29,660 – 米国
- 16,917 – 中国
- 4,713 – 英国
- 3,209 – フランス
- 3,047 – ドイツ
- 3,003 – 日本
- 2,556 – オランダ
- 2,460 – インド
- 2,266 – ロシア
- 1,820 – 香港
この結果から、いくつかの結論を導き出すことができます。まず、インターネット上には多数の Memcached サーバが簡単にアクセスできる状態で存在しているということです。2 番目の結論は、認証が有効化されているのは 4 分の 1 未満であり、認証が有効になっていないサーバはリモート コード実行の脆弱性がなかったとしても悪用に対して完全にオープンな状態であるということです。3 番目は、既存のサーバへのパッチ適用がなかなか行われないことから、私たちが報告した脆弱性によって、多数のサーバが侵害のリスクに対して完全に無防備な状態になっているということです。そして 4 番目は、認証が有効になっているサーバでもパッチが適用されているものはわずかであるということです。つまり、システム管理者たちは、認証を有効にしていれば十分と考えており、パッチが更新される保証はないということが分かります。これらの 4 つの結論のどれもが問題です。
通知
スキャンが完了し、分析結果が出た後、私たちはすべての IP アドレスに対してクエリを実行し、当該の組織に連絡するための電子メール アドレスを取得しました。そして、これらのアドレスに対して問題についての簡単な説明と、修正の提案を記載した通知を送信しました。送信の結果、約 31,000 件の固有の電子メールについて、通知が保留となりました。
スキャンの再実施
通知を送信してから 6 ヵ月後、私たちはこの通知に着実な効果があったかを把握するために、再度スキャンを実施しました。全体的な結果は残念なものでした。どうやら通知の大部分は無視されてしまったようです。以下の結果から分かるように、パッチが適用されたシステムはごくわずかで、全体の 10 % 以下でした。加えて、今でも大量のサーバが脆弱なままになっている上に、認証の要求も行われていません。さらに残念だったのは、最初に検出されたサーバの 26 % がすでにオンライン上に存在しなかったにもかかわらず、検出されたシステムの数がほとんど以前と同じままだった点です。つまり、システムの IP アドレスだけが変更されたか、依然として多くの新しいシステムが脆弱なバージョンの Memcached を使用して導入されているということになります。
結果：6 ヵ月後
有効な応答があったサーバ：106,001
引き続き脆弱であるサーバの合計：73,403（～ 69 %）
脆弱ではないサーバの合計：32,598（～ 30 %）
認証が要求されるサーバの合計：18,173（～ 17 %）
認証が要求されるサーバのうち、脆弱なものの合計：18,012（～ 99 %）
結果：元のサーバ（107,786）の更新された結果
合計：85,121
引き続き脆弱なもの：53,621
脆弱ではなくなったもの：2,958
オンライン上に存在しないもの：28,542（～ 26 %）
まとめ
今回のようなタイプの脆弱性は、その重大性が軽視されています。こうした脆弱性は、企業の規模を問わず、インターネット全体に導入されているプラットフォームに影響を与える可能性があります。脆弱性を悪用したワームによる攻撃が、最近頻繁に見られるようになったことを考慮すれば、全世界の管理者がこのような攻撃を警戒するべきです。脆弱性を放置することによって、こうした脆弱性が悪用されることで組織全体に影響がおよび、ビジネスに重大な悪影響を及ぼす可能性があります。組織に対する影響を最小化するために、脆弱性のあるシステムには今すぐパッチを適用することを強くお勧めします。
本稿は 2017年7月17日に Talos Group
Authors