Contrast AssessによりSpring-Kafkaのデシリアライゼーションのゼロデイが明らかに

2023年8月初めにContrast Securityのユーザから、過検知と思われるSpring-Kafkaでのデシリアライゼーションの脆弱性が報告されました。

VMwareとPivotal Softwareによって開発されたSpringは、エンタープライズJavaアプリケーションを構築するためのオープンソースのフレームワークであり、Spring for Apache Kafka(Spring-Kafka)プロジェクトは、Kafkaベースのメッセージングソリューションの開発にSpringのコアコンセプトが適用されています。

Contrastユーザが過検知と間違えてしまった理由は、ユーザ自身のコードではなくSpringフレームワーク自体の中で脆弱性が見つかったことと、Springがデシリアライゼーションの保護を追加しているように見えたからです。

しかし、この脆弱性は誤検知ではなく、実際にはSpring-Kafkaでのデシリアライゼーションのゼロデイ脆弱性であることが判明しました。

Contrast Securityがこの脆弱性を検出できたのは、2023年4月に弊社のランタイム・セキュリティ・ソリューションである「Contrast Assess」にSpring-Kafkaのサポートを追加していたからです。脆弱性を継続的に検出して優先順位を付け、ユーザのリスクを排除してくれる「Contrast Assess」によって、脆弱性が実際に存在して正しく検出されていることが判明したのです。VMwareのセキュリティチームはゼロデイ脆弱性を確認後、8月23日に修正プログラムを公開しました。本脆弱性にCVE(Common Vulnerability and Exposure)番号 CVE-2023-34040が割り当てられています。

安全でないデシリアライゼーションとは？  

安全でないデシリアライゼーションは、2017年にOWASP(Open Worldwide Application Security Project)トップ10に加えられ、その後「ソフトウェアとデータの整合性の不具合」に分類されていますが、脆弱性によって信頼されていないデータや未知のデータが渡され、サービス拒否(DoS)攻撃、コード実行、認証バイパス、またはアプリケーションのロジックに対するその他の種類の悪用が可能になる場合に発生します。

脆弱性のトレースは、以下のメソッドで終了していました。ListenerUtils.byteArrayToDeserializationException(): 

resolveClass()が使用されていることに注意：これはJEP-290でJavaに追加されたメカニズムで、「アプリケーションで利用可能なあらゆるクラスからデシリアライズできるクラスをコンテキストに応じてクラスセットに絞り込む」ように設計されており、デシリアライズされるクラスが予期されたものであることを呼び出し元がチェックできるようになっていました。

デシリアライズチェックの重大な欠陥

しかし、このチェックにはいくつかの重大な問題があります。

1. チェックされるのは最上位のクラスのみ。 ( resolveClass() ) は、入れ子になったオブジェクトに対して再度呼び出されますが、チェックが行われのは最初の呼び出しの時だけです。
2. チェックは文字列としてのクラス名に対して行われる。 本ケースの場合は、以下に対してになります。

org.springframework.kafka.support.serializer.DeserializationException

しかし、もし攻撃者がルートのクラス名と一致するように見えるオブジェクトを生成し、そのオブジェクトに危険なペイロードも含めていたらどうでしょう？ それを実現する方法についての詳細をGithubに掲載しています。

そうすると、Serialized DeserializationExceptions がKafkaキューに追加されたメッセージのヘッダーとして追加され、コンシューマアプリケーション(つまり、共有データ構造からデータを削除するプロセス)によって読み取られることになります。

デフォルトでは、コンシューマアプリケーションはこれを読み取ることはできません。

この機能を有効にするには、以下のどちらかまたは両方を設定する必要があります。

checkDeserExWhenKeyNull

checkDeserExWhenValueNull

これらのいずれかが有効になっていると、そのコンシューマアプリケーションは脆弱になります。

注：上記スクリーンショットには顧客データは含まれていません。  

検出結果は、下記のPOC(概念実証)からのものです。

POC

このPOCには2つの個別のJavaアプリケーションが含まれています。

1. シリアライズされたペイロードをヘッダーとして含むメッセージを生成するProducerアプリケーション
2. そのペイロードをデシリアライズするConsumerアプリケーション

2つのペイロードを利用できます。リモートコード実行(RCE)ガジェットの例とDoSペイロードがあります。DoSペイロードには、コンシューマのクラスパス上に特別なガジェットクラスが存在する必要はありません。

また、この攻撃が実行されると、Consumerアプリケーションは読み取り操作を完了できず、メッセージはKafkaキューに残ります。Consumer(または同じクラスタ内の別のConsumer)が再起動されると、メッセージの読み取りが試行され、再度DoS攻撃されます。これに対処するには、手動で介入してキューからメッセージを削除するか、保持期間が終了してキューからメッセージが自動削除されるまで待つしかありません。

対応策

VMwareよりCVE-2023-34040の修正プログラム Private Header Type for DeserializationExceptions がリリースさています。

さらにContrast Assessについて

Contrast Assessがこのゼロデイにフラグを立てた後、2社のContrastユーザがこのゼロデイについてContrastに連絡してきました。両社とも脆弱な設定を有効にしていました。 他にも同様の現象を確認しているユーザがいるかもしれませんが、それを誤検知の可能性があるとしてContrastでフラグを立てていません。

Contrast Assessによって、アプリケーションのライフサイクル全体を通じて継続的かつリアルタイムにセキュリティ検査が実施され、脆弱性が検出されたらすぐに特定・対処できるようになります。脆弱性を理解して修正をする必要のある担当者は、Contrastプラットフォームでコードレベルの詳細な修正・対策方法を知ることができます。 この技術はContrastの革新的なセキュリティ追跡方式を使用しており、コード内のどこに脆弱性が存在しそれがどのように動作するかを正確に特定します。これにより、開発者はセキュリティに関する知識がなくても脆弱性を簡単に修正することができます。

アプリケーションのコードとデータフローをリアルタイムに解析することで、Contrast Assessは誤検知を最小限に抑えながら非常に正確に脆弱性を検出できます。

Contrast Assessでリアルタイムに脆弱性を見つけ、修正しましょう。デモのご予約や無償トライアルをお申し込みください。