デバッガを利用してWebアプリの脆弱性を分析してみた

11/15に開催されたこちらの勉強会に参加いたしました！

デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう - connpass

こちらの勉強会は、「WordPress本体とプラグインの脆弱性をデバッガで追跡することにより、脆弱性の中身について詳しく追跡し、理解を深める」という内容のものであり、なんとあの徳丸浩さんが講師をされています！
私個人としては、仕事というか半分趣味でゆるゆる脆弱性の検証をしており、今回の勉強会はまさに自分の興味分野にドンピシャな内容だったので、非常に楽しんで参加させていただきましたｗ
私はこちらの勉強会にブログ枠として参加いたしましたので、勉強会の内容について本ブログにてレポートいたします。

分析対象の脆弱性について

今回分析する題材となった脆弱性は以下の二つです。 なお、二つの脆弱性とも徳丸さんが詳細な解説記事をブログにて公開されております。

脆弱性分析のやり方

勉強会の冒頭にて徳丸さんより以下のような脆弱性分析のhow-toに関するお話しがありました。

脆弱性情報はどこにあるのか？

WordPressやCMSの脆弱性であれば米セキュリティ会社Sucuri社のブログがおススメ！
https://blog.sucuri.net/

正し、Sucuri社のブログは、書いてある内容はすごいけど、説明がちょっと不親切である（意図的にぼかしている？）。
そのため、読んだだけでの完全理解は難しいので、自分で検証する必要があるとのことです。

脆弱性分析の手法

脆弱性を分析する方法には以下の3種類がある（複数組み合わせてやっても勿論OK！） 。

  1. 脆弱性の解説記事を読む
  2. ソースコードの差分をとり中身を見る（静的解析）
  3. PoC(Proof of Concept)を試して動作を分析する（動的解析）

2番の手法については、差分に脆弱性だけではなくて他の修正内容も含まれていることもあり、複雑なアプリケーションの場合などでは差分のコードを読んでもよく分からない場合が多いとのこと。
3番の方法は比較的楽な方法である。

今回の勉強会では、上記3番の方法をデバッガを利用して分析してみるという感じです。
勉強会の冒頭にて、徳丸さんが脆弱性の内容を調べるモチベーションやブログとして公開する楽しさについてもお話しされていましたが、自分も非常に共感する部分がありました。
やっぱ脆弱性を検証するのって楽しいですよねｗ

脆弱性分析をするための環境について

WordPressやプラグインはPHPを利用して作成されているので、動作を分析するために、PHPアプリをリモートデバッグできる環境を用意します。
リモートデバッグ可能なIDEは複数ありますが、勉強会ではNetBeans 8.2+ Xdebugを使用していました。

なお、今回の勉強会の参加者には分析対象のVMデータを配布いただきました。
今回の僕の記事もいただいた環境を利用して書かせていただいております。
いただいた環境はUbuntuで構築されており、脆弱なWordPressと脆弱なプラグインデータなどがセットアップされていました。
また、Xdebugもインストールされており、こちらの環境を利用すれば、すぐにリモートデバッグして検証ができるようになっているので非常にありがたかったです。
余談ですが、実は勉強会に参加する前の予習として自分でもリモートデバッグできる環境をCENTOSで作成してみたのですが、ちょっと面倒くさかったです。
Ubuntu等で作成するとapt-get一発でインスコできるみたいなので、後ほど自分でももう一回環境を作ってみようと思います。
なお、Xdebugを利用する際には、php.ini（あるいはconf.d/xdebug.ini 等）に設定情報を記載する必要があり、NetBeansを起動してリモートデバッグを行うホスト側の情報に合わせる必要があります。

リモートデバッグをする準備

NetBeansの初期設定

まずはNetBeansを起動して、VMサーバ側にSSH経由にて、リモートデバッグをできるように設定する必要があります。

1.NetBeansを起動して、メニューから[ファイル][新規プロジェクト]を選択

f:id:tigerszk:20171116210733j:plain

2.プロジェクトを選択において「リモートサーバーからのPHPアプリケーション」を選択して「次＞」を押す

f:id:tigerszk:20171116212212j:plain

3.「プロジェクト名」・「ソースフォルダのパス」・「PHPのバージョン」を適当に設定して「次＞」を押す

f:id:tigerszk:20171116212336j:plain

4.リモート接続が定義されていないので、「管理」のボタンを押す

f:id:tigerszk:20171116211052j:plain

5.新規接続を作成します。接続名は適当に入力して、接続型は「SFTP」に設定して「OK」を押す

f:id:tigerszk:20171116211242j:plain

6.リモート接続の部分については接続したい先のホストに合わせた情報を入力して「OK」を押す
※画像ではいただいたVMデータの情報を設定しています。事前にNetBeansを動作させているホスト側のhostsファイルを編集していたりもしています。

f:id:tigerszk:20171116211424j:plain

7.プロジェクトURL・アップロードディレクトリを適切に設定して「次＞」を押す
※プロジェクトURLはブラウザでアクセス可能なURLを入力、アップロードディレクトリは、検証するコンテンツが配置してある公開ディレクトリのパスとなるように指定する。

f:id:tigerszk:20171116212932j:plain

8.ディレクトリ・ファイルを選んで終了を押すとダウンロードが始まります。
※ここではWordPressのコンテンツを丸ごと選択しています。

f:id:tigerszk:20171116212958j:plain

9.ダウンロードが完了すれば、リモートデバッグできる状態となります。

f:id:tigerszk:20171116213213j:plain

リモートデバッグのやり方

NetBeansの上部の「プロジェクトをデバッグ」のボタンを押すと、デバッグ・セッションが実行され、以下のようなボタンが表示されます。

f:id:tigerszk:20171116221725p:plain

後はお好みの場所にブレークポイント（実行中のプログラムを意図的に一時停止させる箇所）を設定して、こちらのボタンを操作すれば、デバッグをすることができます。
NetBeansでは、エディタにて設定したい行の左マージンをクリックすれば、簡単にブレークポイントを設定できます。
なお、NetBeansでのデバッグについて、ちょっと調べてみたら以下などに細かく解説がありました。

PHP向けのNetBeans IDEのエディタでのPHPソース・コードのデバッグ

脆弱性の分析について

脆弱性の分析については以下の手順で行います。

  1. まず、ブログなどの一次情報などを元に、脆弱性に関係がありそうな関数などにブレークポイントを設定する
  2. デバッガを動かしている状態で、WebアプリケーションにPoCを打ちこんでみる
  3. ブレークポイントを設定した箇所やその周辺にて、関連するような変数の値が内部でどのように処理されているのかをひたすら追って挙動をみていく。

ものすごいザックリとした説明ですが、上記の手順で追跡をしていくわけです。
正常に機能を利用した場合の処理内容と、PoCを打ち込んだ場合の処理結果に、どのような差分があるのかなどを比較したりするのも有効なのかなと思いました。

WordPress REST APIの脆弱性の検証

こちらは分析初級編というお話しでした。

本脆弱性については非常に話題になったので、ご記憶にある方も多いのではないでしょうか。
IPAやJPCERTなどからも注意喚起されていましたね。

WordPress の脆弱性対策について：IPA 独立行政法人 情報処理推進機構

再度リンクを張りますが、脆弱性に関する要因の詳細につきましては、まずこちらの徳丸さんの記事を良く読み込むのが一番良いと思います。

WordPress 4.7.1 の権限昇格脆弱性について検証した | 徳丸浩の日記

上記のブログにて脆弱性の要因について以下二点をご指摘されています。

  • 権限チェックの際に、存在しないid に対して、権限ありを返していた
  • 権限チェックの際はid キャストなし、データ更新の際はid を整数にキャストしていた

デバッガを利用してPoCを実行してやれば、上記のブログにて解説されている流れをそのまま体験できます。
update_item_permissions_checkメソッドとupdate_itemメソッドにブレークポイントを設定してステップ・オーバーなどで進めていけば、どのように値が処理されているのか良く分かります。

存在しないidなのに、返り値がtrueとなる f:id:tigerszk:20171117135927j:plain

整数にキャストされているためid=1xだったのがid=1として処理されている f:id:tigerszk:20171117140021j:plain

自分で試してみた感想としてですが、PoCのリクエストをid=1としてブン投げると正常処理の流れとなるので、そちらと比べるとより分かりやすいかもなと思いました。

WordPress NextGEN GalleryのSQLインジェクション脆弱性の検証

こちらは分析上級編という位置づけでした。

本脆弱性はWordPressのフォトギャラリープラグインにSQLインジェクションの脆弱性が存在するというものです。
WordPressがフレームワークとして提供するwpdbクラスのprepareメソッドが、プレースホルダに用いている「%s」という値を外部由来文字列から内部のSQL文に受け渡してやるとそのままプレースホルダとして解釈されることを利用して、細工した値を送りこんでSQLインジェクションを発生させるという脆弱性だと認識しています。
こちらの脆弱性は上級編だけあってかなりトリッキーなものですね。

こちらについても、脆弱性に関する要因の詳細につきましても、まず徳丸さんの記事を良く読み込むのが一番良いと思います。

WordPressのプラグインNextGEN GalleryのSQLインジェクション脆弱性について検証した | 徳丸浩の日記

デバッガを利用すれば、ブログに書いてある「aaa%1$%s)) or 1=1#」という細工された値を受け渡した際に、内部にてどのように処理されるか確認することができます。

f:id:tigerszk:20171117163352j:plain

まとめ

自分は、今までWebアプリケーションの脆弱性を検証する際に、デバッガを利用したことがなかったので今回非常に勉強になりました。
脆弱性検証でもいくつかのフェーズがあり、脆弱性の再現確認は環境作るのがちょっと面倒くさいというのを除けば割と誰でもできるかなと思いますが、脆弱性が起こる原理解析などの部分がやっぱりなかなか難しいよなあと個人的に思います。
デバッガを用いた動的解析を利用すれば、原理解析の部分などが色々捗りそうだなという印象をもちました。
今回の環境を利用すれば、WordPressだけじゃなくて、Joomla!やDrupalなどの検証もできそうなので次回の検証からは早速使ってみようかなと思っています。
後は、他の言語でのこういったリモートデバッグのやり方なども調べてみたいですね。

また、こちらの勉強会は同じ内容で追加開催されるとのことですので、ご興味がある方は参加されてみてはいかがでしょうか？
※好評につき追加開催※ デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう - connpass