yebo blog: DNS Rebinding攻撃を受けやすいルータは何百万もある
2010/07/19 DNS Rebinding攻撃を受けやすいルータは何百万もある ars technicaによれば、今月末に開始されるBlack Hatで、家庭用ブロードバンドルータを攻撃する古くて新しい方法が発表されるとの事だ。発表者はメリーランドを拠点とするセキュリティ・コンサルタント会社の研究者クレイグ・ヘフナー氏で、発表タイトルは「How to Hack Millions of Routers」。DD-WRTやOpenWrtなどオープンファームウェアを含め、Netgear、Linksys、Belkinなど主要ルータをテストした結果、約半分は被害を受ける事が明らかになったとのこと (このリストでSuccessfulがYESになっていれば、攻撃が成功したルータ)。攻撃には、「DNS rebinding」という手法が使われる。この攻撃法は以前から存在し、DNSの返すIPアドレスを巧妙
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年4月6日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、PROXY経由でWebアクセスしている場合のDNSリバインディング対策について考察する。 PROXY（プロキシ）経由でWebアクセスしている場合、DNSによる名前解決はブラウザではなくPROXYにより行われる。したがって、 ブラウザ側ではDNS Pinningできないので、PROXY側での対策が重要になる。 広く使われているPROXYサーバーであるsquidの場合、DNS Pinningに相当するパラメータは、negative_dns_ttlであり、デフォルト値は1分間である。したがって、最初
Black Hat Japan 2007における金床氏のプレゼンテーションや金床本で、Javaアプレットに対するDNSリバインディングの手法が説明されている。ここしばらく、その追試を行っていた。結論としては、金床氏の方法にはJRE側で対策がとられていたので報告する。 金床氏が報告しているDNSリバインディングの手法とは以下のようなものだ（金床本に説明されている方法）。 被害者のユーザにワナのページをPROXY経由で閲覧させる ワナのドメイン(FQDN)に対するIPアドレスを変更する ワナページ上で数秒～数十秒のちにJavaScriptによりJavaアプレット用のHTMLをレンダリングする JREがアプレットをPROXY経由で*1ダウンロードする アプレットのダウンロード時点で既にDNSレコードは書き換わっているが、PROXYがDNSキャッシュしているため、アプレットは正常にダウンロードされ
Flash Player’s EOL is coming at the end of 2020. See the roadmap for Flash Player and AIR’s EOL: Adobe Flash Player EOL General Information Page The Future of Adobe AIR You can access the archived documents relevant to Flash Runtime even after the Flash EOL date. We are providing access to the archived documents for all the user/developers community to download. These documents are now no longer u
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年03月29日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり DNSリバインディング攻撃により、無線LANアクセスポイント(AP)に設定したWPAのパスフレーズ(PSK)を読み出す実験に成功したので報告する。 先のエントリではDNSリバインディング攻撃によるルータ設定変更の実験を報告したが、エントリでも触れたように設定変更についてはCSRF脆弱性を悪用することによっても可能だ*1。両手法の違いとして、CSRFは攻撃先の情報を読み出すことはできないのに対して、DNSリバインディングでは読み出しも可能だ。DNSリバインディングによるセッションCookieの読み出し例につい
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年03月25日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、DNSリバインディング攻撃によりブロードバンドルーターの設定を外部からの侵入を許すように変更してみたので報告する。 DNSリバインディングに対する関心が高まってきている。本年1月12日には、読売新聞夕刊一面トップで、iモードブラウザ2.0のDNSリバインディングによる不正アクセスが報じられた。3月17日のcomputerworld.jpでは、『2010年に最も警戒すべきセキュリティ脅威は「DNSリバインディング」』という翻訳記事が紹介された。実は「最も警戒すべきセキュリティ脅威」というタイ
computerworld.jpは3月17日に『2010年に最も警戒すべきセキュリティ脅威は「DNSリバインディング」』と題した記事を公開したが、一部誤報があるので訂正する。 米国White Hat Securityの研究者らがまとめた2010年版の深刻なセキュリティ脅威トップ10では、DNSリバインディングが1位となった。同社では、2006年から毎年、脅威トップ10を発表している。 http://www.computerworld.jp/news/sec/177029.html 当初、この記事を読んで違和感を覚えた。DNSリバインディングという攻撃手法そのものは以前から知られているものであるし、この記事で説明されている脅威の内容についても、以前から知られているものと違わない。このタイミングでなぜ、DNSリバインディングがもっとも警戒すべきなのか。このため、この記事の裏を取ってみようと思っ
■「かんたんログイン」DNSリバインディング耐性のチェック方法 このエントリでは、ケータイ向けWebサイトがDNSリバインディング攻撃に対する防御耐性があるかどうかをチェックする方法を説明します。ケータイ向けに「かんたんログイン」機能をもつWebサイトをチェック対象とします。 基本的な前提として、検査対象のWebサイトの管理者が自ら検査することを想定しています。 用意するもの チェック対象のWebアプリケーション(かんたんログイン機能あり) 携帯電話（かんたんログイン可能なもの） インターネット接続されたパソコン ステップ0:IPアドレスの調査 検査対象のWebサーバーのIPアドレスを調べます。一例として、検査対象サーバーのホスト名が mobile.example.com の場合、以下のコマンドでIPアドレスを調べることができます。 C:>nslookup mobile.example.
iモードブラウザ2.0でJavaScriptが本格的に有効になったので、XMLHttpRequestを使ってサーバと通信可能になった（2009年8月辺り？） DNS RebindingでJavaScriptのクロスドメイン制限が突破可能だと判明（2009年11月） iモード専用サイトのhtmlソースの閲覧方法 iモードIDはguid=ONをURLの末尾につけることでサーバへ転送されるため、iモードIDで「かんたんログイン」していると「なりすまし」の可能性あり（2010年2月） iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性 [対策1] DNS RebindingするとHTTPリクエストのHostが本来のホスト名にならないため、バーチャルホストで運用すればＯＫ [対策2] そもそもCGI側でHostを確認して、自ホスト以外なら弾くコードを追加すればＯＫ？
■ 著名優良サイトでもiモード2.0の脆弱性に対応していなかった。なぜか。 今月中旬のこと。私は2テラのハードディスクを買溜めするため秋葉原の街に出た。しかし、どの店が最安か調べずに出たため、やむなく携帯電話で調べることにし、価格.comのサイトを探した。すると、携帯電話用のサイト m.kakaku.com があり、私は初めてそこを使った。 サイトはとても使いやすく、すぐに意中の製品を見つけることができた。が、ここで、画面に「履歴」というリンクがあることに気づいた。「履歴」の画面に入ると、なんと、閲覧した製品が既に記録されていた。ログインしていないのに。いや、アカウントさえないのに。 これはたしかに便利な機能ではあるが、契約者固有IDを用いて実現されていることにギョッとした。同様の機能は普通のPCのインターネットでもcookieを使って実現できるわけだけども、契約者固有IDの取得と保管は、
_ケータイtwitter(twtr.jp)においてDNS Rebinding攻撃に対する脆弱性を発見・通報し、即座に修正された twitterのケータイ版twtr.jpにおいて、DNS Rebindingによるなりすましを許す脆弱性が発見され、1/15に通報したところ、その日のうちに修正された。以下、その経緯について報告する。 経緯 今年の1月12日に読売新聞の記事が出たのを受けて、現実のサイトはどうなのだろうかと改めて気になった。 ＮＴＴドコモの携帯電話のうち、インターネット閲覧ソフト「ｉモードブラウザ２・０」を搭載した最新２９機種を通じて、利用者の個人情報を不正取得される恐れのあることが、専門家の指摘で明らかになった。 同社は携帯サイトの運営者にパスワード認証などの安全対策を呼びかけている。携帯電話の機能が高機能化するにつれ、こうした危険は増しており、利用者も注意が必要になってきた。
_かんたんログイン手法の脆弱性に対する責任は誰にあるのか id:ikepyonの日記経由で、NTTドコモのサイトに以下のセキュリティ・ガイドラインが掲示されていることを知った。 iモードブラウザ機能の多様化により、機種によってiモードサイトにおいてもJavaScriptを組み込んだ多様な表現、CookieやReferer情報を有効に活用したサイト構築が行えるようになりました。 しかし、PC向けインターネットサイト同様に、セキュリティ対策が十分に行われていないサイトでは、そのサーバの脆弱性を突き（クロスサイトスクリプティング、SQLインジェクション、DNSリバインディングなど様々な攻撃手法が存在しています）、これらの機能が悪用される危険性があります。十分にご注意ください。 [作ろうiモード：iモードブラウザ | サービス・機能 | NTTドコモより引用] XSSやSQLインジェクションと並ん
ＮＴＴドコモの携帯電話のうち、インターネット閲覧ソフト「ｉモードブラウザ２・０」を搭載した最新２９機種を通じて、利用者の個人情報を不正取得される恐れのあることが、専門家の指摘で明らかになった。 同社は携帯サイトの運営者にパスワード認証などの安全対策を呼びかけている。携帯電話の機能が高機能化するにつれ、こうした危険は増しており、利用者も注意が必要になってきた。 高機能ソフトを悪用 該当機種は、昨年５月以降に発表されたプロシリーズやスタイルシリーズなど。ｉモードブラウザ２・０は、ジャバスクリプトと呼ばれる機能が組み込まれており、携帯用のインターネットサイトと自動で情報をやりとりできる。 悪意ある携帯用サイトは、接続してきた利用者の携帯のジャバスクリプトを使って、利用者が会員になっている別のサイトに一瞬だけ接続させることができる。その時、この会員サイトに利用者の住所など個人データが登録されている
最近のwebセキュリティ界隈ではCSRFやDNS-Rebindingが話題ですが、Plackでアプリケーションサーバを立ち上げる際にこれらの対策をどのように行うかについてまとめてみました。 まず、CSRF対策ですが、拙作のPlack::Middleware::RefererCheckを使うことにより、RefererのチェックによるCSRF対策が行えます。CSRF対策としては、onetime token方式も存在しますが、個人的にはRefererチェックが導入が楽で好きではあります。Refererを送信しないクライアントを対象にしたサービスを運営される方は別途onetime token方式の対策をおこなってください。 Plack::Middleware::RefererCheckの使い方はこのようになります。(SYNOPSYSからの抜粋) use Plack::Builder; builde
I decided to throw together a video for those of you who are still having trouble wrapping your heads around DNS Rebinding. It’s my first attempt at making a video so there are zero frills, but if and when I make future videos, I may improve that. Most importantly, hopefully this will help explain the details for those of you who aren’t super clear on the problem: And yes, Raf and JJ - I wore the
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
転送中
