VDOOがQNX Slingerのディレクトリトラバーサルの未知の脆弱性を発見

August 11, 2020

まず、ディレクトリトラデバイスセキュリティ分析により、IoTデバイスで使用されるオープンソースおよび非オープンソース両分野のコンポーネントにおいて、VDOOは度々新たな未知の脆弱性を発見し、そして責任ある公表をしています。本ブログは、BlackBerry QNXベースのデバイスに実装されているファームウェアの分析によってVDOOが最近発見したディレクトリトラバーサル脆弱性について記述します。

まず、ディレクトリトラバーサル脆弱性の背景から説明します。ディレクトリトラバーサルは、デバイスのファイルシステムへの正当なアクセスプロセスを攻撃する手法です。アクセスのリクエスト時に攻撃者がファイルパスの指定文字を操作できるのであれば、それは脆弱性が存在することを意味し、機密ファイルやディレクトリへの設計者の意図しないアクセス権を攻撃者が得ることができます。このような攻撃により、機密アプリケーションやデータが操作されたり盗まれたりします。あるいはデバイスに悪意コードを加えられ、デバイスの振る舞いが操作されることを許してしまいます。

まず、ディレクトリトラバーサル脆弱性の背景から説明します。ディレクトリトラバーサルは、デバイスのファイルシステムへの正当なアクセスプロセスを攻撃する手法です。アクセスのリクエスト時に攻撃者がファイルパスの指定文字を操作できるのであれば、それは脆弱性が存在することを意味し、機密ファイルやディレクトリへの設計者の意図しないアクセス権を攻撃者が得ることができます。このような攻撃により、機密アプリケーションやデータが操作されたり盗まれたりします。あるいはデバイスに悪意コードを加えられ、デバイスの振る舞いが操作されることを許してしまいます。

シンプルなHTTP サーバーや FTP サーバーに代表されるような、IoT組込デバイスで一般的な一部のネットワークサービスでは、受信パケットをファイルアクセス操作に「翻訳」するという動作が想定されます(図1)。 この場合、ネットワークからデバイスに送信されたデータの一部 (これには悪意がある可能性があります) がファイル操作コードに渡り、そこで読み込みファイルパスとして解釈されます。

このようなサービスに存在するディレクトリトラバーサル脆弱性を発見するために、VDOOは、ネットワークより受信したパケット内データに施される処理のパスを追跡し、それらを論理セクションに分割して分析を行います。このパスの中では、入力データをサニタイズし、読み込みファイルの存在位置を正当なものに強制するコードセクションがセキュリティ上必須です。VDOOはこのようなコードセクションの特定を自動的に試

 

Image
qnx-slinger-jp-1

VDOO製品の検査対象OSとしてBlackBerry QNXをサポートする予定です。QNXはマイクロカーネルベースのPOSIXリアルタイムOSで、自動車業界で広く採用されています。VDOOでのQNXサポート準備中に、SlingerというシンプルなHTTPサーバーがバージョン6.6までのQNXに含まれていることが判明しました。上記プロセスによってSlingerを分析したところ、データフローが期待される安全なパターンとは幾分異なっていることが判明しました(図2)。ネットワークから受信したアクセスファイルのファイル名に、文字列 "/../" を除去するよう実際にサニタイズされ、HTMLコンテンツファルダ以外の場所をアクセスすることができないように保護はされていました。しかし、ファイル名がサニタイズされた後、さらに別の処理が行われます。

 

Image
qnx-jp-2

このサニタイズとデコードという二つの処理の順序はそれ程重要でないように思えるかもしれません。また誤って順番が変更されてしまうこともあるかもしれません。しかしこの順番はセキュリティ上重要な意味を持ちます。Slingerに実装されているフローでは、パーセントエンコードを用いることで(例えば、"/.%2e/")、実行時の対象ファイル名に "/../" を挿入することを許してしまいます。このエンコードを用いるとサニタイズ時点では文字列 "/../" ではないのでサニタイズされず、後に "/../" とデコードされることでディレクトリトラバーサルが実施されてしまい、HTMLディレクトリの外部にある他のファイルに攻撃者がアクセスすることが可能となります(図3)。

 

Image
Figure-3-QNX
 図3:  "/../" の代わりに "/.%2e/"  を使用した単純なディレクトリトラバーサルによって、ファイルシステムから任意のファイル取得を許してしまう

さらに、SlingerにはCGI機能があるため、この脆弱性によってシステム上の任意のプログラムをリモート実行することも可能となります。スクリプト名にパーセントエンコーディング "/.%2e" を用いることで、SGIスクリプトディレクトリ制限を逃れることが可能となるわけです。この例で、ファイル名中の文字 "/" が例えばスクリプト名とそのパラメータのセパレータとして解釈されるとすると、ディレクトリツリーを跨ぐ攻撃を阻害することにはなるでしょう。しかし、このセパレータを処理するコードもまたデコードステージ前にあります。すなわち攻撃者が "/" の代わりに パーセントエンコードを行った "%2f" を使用すればセパレータと解釈されることを回避でき、システムの任意の場所に到達できます。

Slingerは特権で実行される必要がありますが、幸いなことにリスニングソケットのオープン後、最小限の権限(ユーザーID -2) に自ら降格するので、この脆弱性の影響はある程度限定されます。ただし、一部の操作は引き続き実行可能です。以下の実行例にて、"/usr/sbin/logger" を一つのパラメータを付与して実行することに成功しており、その結果としてシステムのsyslogが実際に更新されていることが確認できます (図4)。

 

Image
Figure 4a QNX Slinger
Image
Demonstrating remote code execution QNX Slinger

図4: リモートコード実行のデモンストレーション

上:ディレクトリトラバーサルを含むTCPパケットにて、"~/cgi-bin"以下ではない"/usr /sbin/logger/logger"を実行する。"/" の代わりに "%2f" を、"." の代わりに "%2e" を使用している

下:Slingerの設定と上記攻撃の結果。loggerコマンドが実際に実行されていることが示されている
 

この脆弱性は、文字列検証処理とファイルアクセス処理が隣接しておらず途中別の処理が挿入されてしまっていることに起因します。この種の論理的な脆弱性は微妙なコード変更で容易に生じ得ます。それがたとえ経験豊富なソフトウェアエンジニアによる実装・変更であってもです。このような脆弱性はコードの局所毎の分析では検知できないために、対象とするデータ フローパスを念頭に置いた上で、コードの様々な部分と機能を検証するアプローチが必要です。VDOOでは、ファームウェアイメージ全体のセキュリティ評価のための包括的ソリューションを提供するために、バイナリレベルの自動詳細分析の複数アプローチを実施します。

この脆弱性の完全なる除去にはSlingerのアップデートが必要です。しかしながら、Slingerの設定ドキュメントの「Security precautions」に従うことで、多くのケースにおいて影響を軽減することは可能です。使用システムに存在するすべてのコンポーネントのセキュリティガイドラインを完全に遵守することは現実世界の攻撃シナリオに大きく影響し、セキュリティガイドラインとセキュリティ標準の正確な自動検証は、組込デバイスの開発サイクル上不可欠であるとVDOOは考えます。

上記 の脆弱性は、BlackBerry社へ責任をもって公開され、同社は迅速かつ専門的にこの問題に対処しました。VDOOは、同社の協力と最適なベンダー責任履行に対してBlackBerry PSIRTチームに感謝の意を表します。この脆弱性は、CVSSv3 10 CVE-2020-6932 として発行されました。詳細については、BlackBerry社のアドバイザリページ を参照ください。

 

 

 

Our latest updates