Cisco Japan Blog / 脅威リサーチ / 脆弱性ディープ ダイブ：TP-Link TL-R600VPN におけるリモートでのコード実行の脆弱性

はじめに

TP-Link 社はこのほど、同社の TL-R600VPNギガビット ブロードバンド VPN ルータ（ファームウェア バージョン 1.3.0）の 3 つの脆弱性に対してパッチを適用しました。Cisco Talos は、TP-Link 社と連携してその脆弱性に取り組み、パッチを利用できるようにした上で問題を公開 しました。修正プログラムの提供を機に、ここではこれらの脆弱性の内部構造を詳細に分析し、コンセプト実証コードを使用した手法について説明します。

背景

TP-Link TL-R600VPN は、5 ポートの小規模オフィス/ホーム オフィス（SOHO）用ルータです。このデバイスのチップには、Realtek RTL8198 統合システムが搭載されています。そのチップでは、Lexra 社が開発した、MIPS-1 から派生したアーキテクチャが採用されています。ロード操作と保存操作の違いによって、その処理に対する命令が一部異なっていますが、これら 2 つの命令セットは基本的に同じものです。Lexra 社のアーキテクチャに含まれていない命令は、LWL、SWL、LWR、SWR です。こうした独自の命令は、多くの場合、一般的な MIPS-1 アーキテクチャに対応するプログラムのコンパイル時に使用されますが、Lexra アーキテクチャではセグメンテーション違反の原因になります。目的に応じて有効なコードをアセンブルするには、この重要な違いを理解する必要があります。

Lexra MIPS の詳細と、MIPS-1 アーキテクチャとの違いについては、「The Lexra Story」と MIPS-1 の特許出願書類をご覧ください。

調査

脆弱性について

このデバイスには、HTTP サーバが /fs/ ディレクトリに対するリクエストを処理する方法に脆弱性があるため、認証済みの攻撃者がリモートからコードを実行できます。

/fs/ ディレクトリの次のページにアクセスする際に、渡された HTTP ヘッダーをアプリケーションが正しく解析していません。

• http://<router_ip>/fs/help
• http://<router_ip>/fs/images
• http://<router_ip>/fs/frames
• http://<router_ip>/fs/dynaform
• http://<router_ip>/fs/localiztion（注：「localiztion」はスペルミスではありません）

httpGetMimeTypeByFileName 関数では、リクエストされたページのファイル拡張子を Web サーバが解析し、MIME タイプを識別しようとします。この処理中に、サーバは strlen() をコールし、リクエストされたページ名の長さを取得して、ヒープ割り当て済み文字列の末尾を特定します。そこから、ピリオド（0x2e）を見つけるまで逆方向に読み取り、ファイル拡張子を識別します。

## calculates the length of the uri and seeks to the end#LOAD:00425CDC
loc_425CDC:LOAD:00425CDC                 la $t9, strlenLOAD:00425CE0
            sw $zero, 0x38+var_20($sp)LOAD:00425CE4                 jalr
$t9 ; strlenLOAD:00425CE8                 sh $zero,
0x38+var_1C($sp)LOAD:00425CEC                 addu $s0, $v0
# looks for a period at the current index and break out when foundLOAD:00425CF0
           li $v0, 0x2E            LOAD:00425CF4
           lbu $v1, 0($s0)LOAD:00425CF8     &nnbsp;           lw $gp,
0x38+var_28($sp)LOAD:00425CFC                 beq $v1, $v0,
loc_425D14LOAD:00425D00                 li $v1, 0b101110LOAD:00425D04
# loop backwards until a period is found, loading the character into
$s0LOAD:00425D04 loc_425D04:
            LOAD:00425D04                 addiu
$s0, -1LOAD:00425D08                 lbu $v0, 0($s0)
            LOAD:00425D0C                 bne $v0, $v1, loc_425D04LOAD:00425D10
nop

脆弱性による問題を防止するため、リクエストされるページには拡張子が必要です。これは、次に示す悪意がないページ /web/dynaform/css_main.css に対する GDB の出力文字列で確認できます。ファイル拡張子「css」が解析されています。

ただし、脆弱性があるページをリクエストすると、解析対象の URI にピリオド（0x2e）がないことがわかります。ピリオドがないため、アプリケーションは末尾からの検索を続けます。この場合、解析対象の URI と、ヒープに保存されていた未処理の GET リクエスト データ（以下に示すアドレス 0x679960）との間にピリオドがないため、逆方向に検索するとペイロードにたどり着きます。これは、以下に示す悪意のあるページ /fs/help に対する GDB の出力文字列のアドレス 0x67a170 で確認できます。ファイル拡張子が解析されていません。

ピリオドが見つかると、正常なファイル拡張子の場合でも脆弱性がある場合でも、抽出された文字列が toUpper() 関数によってループ内で 1 文字ずつ処理されます。この処理結果は、store byte 命令によってスタックベースのバッファに書き込まれます。これは次に示すように、前述のループ内で実行された命令で行われています。

プログラムは、httpGetMimeTypeByFileName 関数のエピローグに達するまで継続して実行されます。エピローグでは、スタックに保存された値からリターン アドレスと 5 つのレジスタがロードされます。脆弱性がエクスプロイトされている場合は、これらの保存された通常の値が上書きされ、後述するガジェットのアドレスが追加されています。

関数のエピローグのこの部分で、設定されたバッファにデータをコピーするループによって、スタック上の元のデータが上書きされます。変更されないことを前提にプログラムされているデータをスタックから取り出すことで、ユーザはリターン アドレスを制御できるようになります。これは、HTTPD プロセスのコンテキストで、ユーザがリモートからコードを実行できることを意味します。

toUpper() フィルタ

HTTP ヘッダーの初回の解析中に、デバイスは、バイト単位でピリオド（0x2e）を検索してバッファを構築することを繰り返します。ピリオドが見つかると、バッファが toUpper() コールに渡され、バッファ内の各 ASCII 文字が大文字に変換されます。

toUpper() コールを回避する方法はなく、小文字が使用できないため、HTTP ヘッダーを介してシェルコードを送信する際に問題が生じます。次の GET リクエストの例を見てください。

httpGetMimeTypeByFileName 関数のエピローグで最終ジャンプが実行される直前にあるレジスタを見ると、ヘッダー内の「a」の文字（0x61）が大文字（0x41）に変換されていることがわかります。

ここで行われていること

上記のレジスタをさらに調べると、元のヘッダー データの近くを指しているはずのポインタが、toUpper() コールの後にもそのまま残っています。

httpGetMimeTypeByFileName 関数エピローグの最終ジャンプでブレークしてスタックのデータを調べると、大文字に変換されたヘッダー データ（ペイロードを含む）の一部が保存されていることがわかります。

一方、レジスタ $s5 によってポイントされた位置に続くデータを調べると、未処理のヘッダー データにまだアクセスできることがわかります。

メモリの該当するセクションの権限を調べると、その範囲が実行可能であるため、一見すると未処理のヘッダーに直接ジャンプできるようにも思われます。

しかし、toUpper() とその前の strcmp() による制限があるため、結局意味がありません。toUpper() を使用することで、小文字がすべて不正な文字とされる条件が作成され、データが strcmp() コールで処理されるため、null バイトを使用することはできませんでした。これらの関数コールにより、0x00 と 0x61 ～ 0x7a の範囲のバイトが使用できなくなりました。

エクスプロイト

toUpper() のバイパス

toUpper() によって生じる問題を回避するために、memcpy() という小さなコードを作成しました。このコードでは、$ra の制御が可能になれば、実行時に小文字や null バイトは使用されません。このコードにより、ヘッダー データを元の形式でスタックにコピーし、そのデータにジャンプして実行できました。

この手法を使用するには、memcpy() コードを実行する方法を見つける必要がありました。このデバイスの場合は実行可能なスタックを利用できましたが、コードの最終的な結果が明確ではありませんでした。結局、ret2libc 手法を修正して使用することで uClibc のガジェットを活用し、スタックに対するポインタを取得して、このコードに関するレジスタを設定することができました。

uClibc オフセット アドレス 0x0002fc84 にある最初のガジェットは、スタック ポインタを 0x20 ずつインクリメントし、memcpy シェルコードを通過させるために使用されました。このガジェットが返された後もプログラム実行を制御し続けるために、以下に要求されているように、2 番目のガジェットのアドレスを 0x20+$sp の位置に指定しました。

uClibc オフセット アドレス 0x000155b0 に位置する 2 番目のガジェットは、インクリメントされたスタック バッファに対するポインタを取得するために使用されました。それにより、目的のポインタがレジスタ $a1 に設定されます。このガジェットが返された後もプログラム実行を制御し続けるために、以下に要求されているように、3 番目のガジェットのアドレスを 0x58+$sp の位置に指定しました。

最後に、uClibc オフセット アドレス 0x000172fc に位置するガジェットを使用してスタック バッファにジャンプしました。

それらのガジェットの正しい場所を計算して適切に使用するには、uClibc のロード アドレスを取得する必要があります。次に示すプロセス メモリ マップを見ると、実行可能なバージョンの uClibc がアドレス 0x2aaee000 にロードされていることがわかります。

uClibc のロード アドレスを、各ガジェット用に取得したオフセット アドレスに追加することで、目的のコードに対する使用可能なアドレスを取得できます。それらのアドレスを戦略的に配置すれば、最初のコードが実行され、その後、ペイロードが実行されます。

Lexra MIPS シェルコード

Lexra MIPS は MIPS 仕様に基づいていますが、標準の MIPS 命令を実行する場合に一致していない部分もあります。そのため、こちらにある GCC ツールチェーンを使用して、Lexra MIPS 専用のシェルコードを開発することにしました。以下に示すコードでは、攻撃者までたどりつく接続を確立し、stdin、stdout、stderr をソケット ファイル記述子に複製して、最終的にシェルを生成する手法をとっています。

まず、デバイス上でソケットを開き、nor を活用して、$t7 レジスタの null バイトを回避します。使用する MIPS $zero レジスタには null バイトは含まれていません。

ソケットを開いた状態で、connect syscall を使用して、デバイスから攻撃者への TCP 接続を確立します。このデバイスのデフォルトのサブネットにゼロが含まれているため、null バイトは、このステップ特有の問題です。この問題を回避するために、用意されたレジスタ値を強制的にオーバーフローさせ、null バイトを使用せずに目的の IP アドレスを得る手法を活用します。

デバイスが入力を受け入れ、出力が適切に表示されるようにするには、stdin, stdout, and stderr ファイル記述子を複製する必要があります。これらの I/O ファイル記述子をソケットに複製することで、先に設定した接続を通じてデバイスに適切に入力し、出力を表示できます。

最後に execve システム コールを使用して、ローカルのデバイスにシェルを生成します。このシェルはソケットから生成されており、また stdin/stdout/stderr に対する制御も可能になっているため、確立した接続を通じて新しいシェルをリモートから制御できます。

デバイスに生成した関数シェルを利用して、エクスプロイト後のデバイスの分析を続行できます。

まとめ

残念ながら、この種の脆弱性は IoT デバイスに広く見られます。攻撃者はこうした問題を見つけ出し、それを悪用して脆弱なデバイスでコードを実行します。重要なのは、IoT デバイスがコンピュータであると認識することです。コンピュータである限り、ソフトウェアのメンテナンスを行い、デバイスのセキュリティをできるだけ高めることが不可欠です。

Talos は今後も脆弱性を検出して責任を持って公開し、ベンダーと連携しながらお客様を保護します。また、必要に応じてさらに詳細な分析情報を提供します。ゼロデイ脆弱性を発見し、製品の開発元と協力した上で開示することは、日常的に使用されるデバイスやソフトウェアの全体的なセキュリティの向上に貢献します。Talos では、攻撃者に悪用され得る問題や脆弱性を特定するためのプログラム的手法を開発することで、こうした取り組みに貢献しています。

Talos が公開した脆弱性情報については、脆弱性報告ポータル をご覧ください。

また、Talos の脆弱性公開ポリシーは、こちらで確認できます。

本稿は 2019年1月15日に Talos Group のブログに投稿された「Vulnerability Deep Dive: TP-Link TL-R600VPN remote code execution vulnerabilities」の抄訳です。

Authors

TALOS Japan