DevSecOps：古いセキュリティバグが仕掛ける新たな罠

初出：DevOps.com。

サイバーセキュリティの世界で、私たちはしばしばハンターに例えられます。常に地平線の先を見つめ、次に現れる脆弱性（およびそれを阻止するための適切な設計ツール、技術、戦術）を探し求めているからです。しかし、こうした先を見据える姿勢は、皮肉にも全体的なセキュリティ意識を低下させ、身の回りに潜む根深い危険に対して盲目になり、攻撃者に格好の隙を与える結果を招きかねません。

私はよく、現代のサイバーセキュリティをケブラー製の防弾チョッキに例えます。ケブラーは、その一見不思議な特性によって高速の弾丸やあらゆる強力な現代兵器を防ぐことができ、着用者に無敵のような感覚を与えることさえあります。しかし、紀元前1000年頃に発明された弓矢のような古代の武器システムでさえ、その防御を貫通することがあります。岩石に次いで世界で2番目に古い武器とされる鋭利なナイフなら、ケブラーを綿のシャツのように簡単に切り裂くことさえ可能です。さらに、ケブラーは人体のあらゆるミリ単位を保護できるわけではありません。攻撃者は、ソフトウェアの小さな脆弱性と同様に、わずかな隙を見つけては致命的な打撃を与えてくるのです。

サイバーセキュリティにおいても、多くの組織が8年や10年前のシステムに存在する脆弱性を抱えています。現代のコンピューティングの世界では、それらは引退してもおかしくない「老兵」です。しかし、こうした古いシステムの欠陥を無害だと考えているなら、近い将来、ブルースクリーンに直面することになるでしょう。

ベテランに潜む脆弱性

最も古く、広く使われているJavaScriptライブラリの一つにjQueryがあります。これはイベント処理からDOMツールのトラバースや操作、アニメーション生成まで、あらゆることを支援するオープンソースのリソースです。長年愛用されてきた非常に頼もしい存在ですが、これほど定着したライブラリであれば、すでに完全に精査され、脆弱性はすべて取り除かれているはずだと人々は思い込んでいます。

残念ながら、現実はそうではありません。デフォルトでは、jQueryに依存するほとんどのアプリケーションは、認証にライブラリ内部の命令を使用します。例えばApacheサーバーの場合、これは.htaccessファイルの確認を意味します。Apacheを使用するプログラムを設計する開発者のうち、Apacheサーバーのアップデートに.htaccessが含まれているかを確認しようと考えた人はほとんどいないでしょう。そもそも、長年セキュリティの要であった重要なコンポーネントを、なぜApacheが削除するのかと考えるからです。

奇妙に思えるかもしれませんが、Apacheはバージョン2.3.9でまさにそれを行いました。プログラムを実行するたびに.htaccess設定ファイルをチェックすることが、処理速度を低下させていたためです。これを削除することでApacheのパフォーマンスは向上しましたが、同時に多くの人が気づかない脆弱性が生まれました。開発者が自分のアプリがまだ.htaccessファイルにアクセスできるかを確認しなければ、ほとんどのリクエストは精査されることなく受け入れられてしまいます。

最近、専門家がこの欠陥を発見し、これを利用すれば権限のないユーザーがシェルをアップロードして実行したり、安全とされるシステム上でほぼあらゆる種類のコードを実行したりできることを指摘しました。これにより、10月にCVE-2018-9206という脆弱性アラートが作成されました。しかし、セキュリティ研究者がいとも簡単にこの欠陥を発見できたということは、脆弱性を専門に探すプロのハッカーたちは、おそらくすでにこれを発見していたはずです。実際、公表やその後のパッチ適用にもかかわらず、わずか数週間後には同様の大きな被害をもたらす攻撃が発生し、ビットコインを盗むマルウェアが、毎週何百万人ものユーザーにダウンロードされる人気のNPMライブラリに仕込まれました。

犯人は執事

jQueryと同様に、Jenkinsも非常に人気のあるオープンソースの自動化サーバーです。執事のような親しみやすい名前の通り、多くの業界の開発チームで活用されています。正常に機能している時のJenkinsは非常に便利なツールですが、最近発見された欠陥や、極めて大規模な暗号資産マイニングの事例は、Jenkinsが悪意ある攻撃者のためにも多くの「仕事」をさせられていたことを示唆しています。

Jenkinsの最も危険な脆弱性の一つに、Javaデシリアライゼーション（CVE-2017-1000353）があります。これは複雑な攻撃ですが、以前から存在していました。攻撃者は2つのリクエストを送信します。最初のリクエストでダウンロード用の双方向チャネルを開始しますが、これはサーバーによって拒否されます。しかし、2番目のリクエストでアップロードチャネルを追加し、攻撃者が望むコマンドを含むペイロードをpayload.jarスクリプト経由で実行させます。2番目のリクエストが送信されると、パッチが適用されていないJenkinsサーバーでは通信が許可されてしまうのです。

パッチを適用したサーバーであっても、エクスプロイトは存在します。例えば、Windows環境でJenkinsを実行する場合、デフォルトではユーザー認証にNT AUTHORITY\SYSTEMアカウントが使用されます。これは、SYSTEMアカウントがWindowsサーバー上で完全な権限を持つため非常に危険です。開発者は権限アカウントを変更できますが、そうしないことがよくあります。Jenkinsは昔からあるツールだから、脆弱性はとうの昔に修正されているはずだという思い込みが、その判断の根拠になっています。

最近では、ハッカーがこうした古いJenkinsの脆弱性を利用して複数のサーバーを侵害しました。目的は、見つけたすべての脆弱なJenkinsインスタンスに暗号資産マイニングプログラムを追加することでした。マイナーは、暗号資産を絶えず探索するために貴重なコンピューティングリソースを消費しました。これまでに彼らは約10,800モネロ（約350万ドル相当）を獲得しています。

古くて新しい脅威

これら両方の例において、多くの人が安全だと考えているプラットフォーム上で、日和見的な攻撃者が脆弱性を悪用しています。防御側では、セキュリティ意識の低い開発が、ハッカーたちに古い手法を再利用させる余地を与えています。古い脆弱性を利用した攻撃が再び成功を収めているにもかかわらず、多くの組織にはこの悪循環を断ち切るための計画がありません。

古いからといって無害とは限りません。また、一般的なライブラリやリソースが長年使われているからといって、完全に安全とは限りません（例えば、現在のOWASP Top 10の9位は「既知の脆弱性を持つコンポーネントの使用」に割かれています）。絶え間ないセキュリティトレーニングと勤勉さがあって初めて、地平線の彼方から忍び寄る脅威だけでなく、すでに私たちの足元に潜り込んでいる脅威からも身を守ることができるのです。