yohgaki's blog

Flash Playerのバージョンアップがなかなか進まないようです。

先月末にあったSymantec社の0Day攻撃の誤報のおかげでかなりバージョンアップが進んだのですが、残念ながらまだまだのようです。例えば、先週1週間のこのブログへのアクセス集計では既知の脆弱性が無い9.0.124を利用していたのはたったの40%です。

バージョンアップが進まない原因にはAdobeのサポート方針にも大きな原因があると言えます。

Read more »

コンピュータワールドの記事によると普通のサイトがかなり危ないようです。

「およそ1,000分の1の割合で、悪意あるWebページが存在することになる」と、Googleのシニア・スタッフ・ソフトウェア・エンジニア、ニールス・プロボス（Neils Provos）氏は述べている。

Linux/Apacheを狙った攻撃 - 確認方法はmkdir 1で紹介している自動化された攻撃では1月の時点で少なくとも1万サイト以上のごく一般的なサイトがマルウェア配布に利用されていると報道されています。

ある程度予想は出来ましたが、

GoogleのProvos氏が驚いたのは、一般のWebサイトがポルノ・サイトよりも安全とは必ずしも言い切れないという調査結果が出たことだ。「調査を始めた当初は、低俗なWebサイトほど危険だと考えていた。実際、アダルト系のページにアクセスしたときは、悪意あるソフトウェアを仕込まれる危険が若干高くなることがわかった。しかし、ほかのページと大きな差があるわけではなかった」（Provos氏）

には私も驚きました。もやは「怪しげなサイトにアクセスしない」といったセキュリティ教育は意味がなくなってきたと言えると思います。

ある程度予想はしていたので、最近エンドユーザ向けに書いたインターネットを安全に利用するTipsには「怪しげななサイトにアクセスしない」は入れていませんでしたが、実際数値として同じレベル、かつ1000に1つ割合で悪意のあるWebページが存在するのはかなりの脅威です。

Adobe Readerのセキュリティフィックスは2008/2/7にリリースされました。

http://www.adobe.com/support/security/advisories/apsa08-01.html

APSA08-01 Adobe RreaderとAcrobat8のセキュリティアップデート公開 02/07/2008

しかし、次の記事によるとこの脆弱性を利用した攻撃は1月から始まっていたとしています。

http://www.cio.com/article/182055/Attacks_Aimed_At_Adobe_Reader_Acrobat_Flaws_Intensify

In January, iDefense noticed that the malicious PDF document was being delivered through malicious banner advertisements.

この攻撃は悪意のあるバナー広告を利用し、バナーにアクセスしてPDFファイルをダウンロードし開いてしまうと、Zonebac（Symantecの名称）と呼ばれるトロイの木馬がダウンロードされるとしています。
# プラグインで自動的に開いてしまう設定のブラウザは少なくない

2006年から既知のプログラムであり、通常のアンチウィルスソフトで検出可能と思われます。トロイの木馬は実行しなければ被害は発生しないので実際に被害が発生したケースは少ないと考えられます。

追記：
整数オーバフローで任意コード実行だそうです。かなり危険度は高いと考えた方が良いようです。上記の記事では観測された攻撃はダウンローダーでダウンロードしただけだった、考えるべきでしょう。少なくともバナーをクリックしたらPDFが表示されたり、表示されかけた方は念入りにシステムをチェックするべきだと思います。もしステルス型のルートキットなら見つけるのはかなり難しいとは思います... 管理者権限で利用していなければルートキットのインストールやシステム関連設定の変更は難しいのですけどね...

一般的なユーザはインターネットを利用する場合のリスクを十分理解していない場合が多いと思います。コンピュータに詳しくない方が、より安全に利用する為のTipsを考えてみました。

• 常に最新バージョンのブラウザを利用する
• 常に最新バージョンのブラグインを利用する
• JavaScript/プラグインを無効にする
• ブラウザにインストールする拡張機能（プラグイン）は最小限にする
• 仮想環境でブラウザを利用する
• ログアウトする
• ブラウザを終了させる
• 管理者権限を持たないユーザでログインする
• ブラウザとプラグイン以外のアプリケーションも最新版を利用する
• 信用できそうなサイトもできるだけ信用しない
• インターネットからダウンロードしたアプリ、プラグイン、コーデック、ドライバ等をインストールしない
• サイト毎に別のパスワードを設定する
• 文字エンコーディングの自動認識を無効化する
• インターネットからダウンロードした出所が不明なドキュメントは開かない

ここに書いている対策は実際に自分も行っている対策なので、コンピュータに詳しくない方が全て実行するのは難しいとは思います。できる部分だけでも実行すると良いでしょう。

他にもコレ、といった対策／注意点があったら教えてください。

Read more »

Pages: 1 · 2 · 3 · 4 · 5

前回のエントリでFirefoxの利用をお勧めしているので未パッチのFirefoxの脆弱性を紹介しておきます。

Firefox chrome: URL Handling Directory Traversalにchromeがディレクトリ遷移攻撃に脆弱だとレポートされています。

この脆弱性を用いるとシステム内のファイルを盗まれる可能性があります。（追記に書きましたが、正確にはJavaScriptとして読み取れる必要があります。コードを見ると判りますが、JSON形式のデータファイル, prefs.js等が読みとられる可能性があります。）PoCとしてWindows上のThunderbirdのall.jsを取得するコードが公開されています。

<script>pref = function(x, y){document.write(x + ' -> ' + y + '<br>');};</script>
<scriptsrc='chrome://downbar/content/%2e%2e%2f%2e%2e%2f
%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%
2e%2f%2e%2e%2f%2e%2e%2fProgram%20Files
%2fMozilla%20Thunderbird%2fgreprefs%2fall.js'>
</script>

悪意のあるメール、ページには注意が必要です。この種の例は多数あります。Firefoxの脆弱性だけでなくFlash, Adobe Reader, QuickTime, RealPlayerが代表例です。NoScriptは必須の拡張だと言えると思います。

ところで、このようなクライアント側の脆弱性はWeb開発者には関係ない、と考えた方はいないでしょうか?このFirefoxの脆弱性ではセッションIDを盗む事はできませんが、セッションIDを盗める脆弱性もあるのです。昨年末見つかったFlashのUnversal XSS脆弱性などは最悪の部類です。

セッションIDは神経質過ぎるくらいに管理した方が良いと考えています。セミナーなどで「セッション管理は必ずセッションクッキーを使うこと」と繰り返し説明しています。もし有効期限を設定したクッキーを利用している場合、簡単にセッションIDが盗めます。セキュアなWebアプリ作りには定石があります。「セッション管理は必ずセッションクッキーを使う」は基本の中の基本です。しかし、この基本に従っていないアプリケーションも多数あります。この様なアプリケーションの場合、ユーザのセッションIDを盗まれ成りすましによる攻撃を受ける可能性があります。

フレームワークを使っているから安全、などと言うことはありません。普通のフレームワークはセッション管理に利用するクッキーの有効期限は設定可能になっているからです。Webアプリ構築はサーバ側だけでなくクライアント側の問題も考えて作らなければ安全性を維持できません。

追記：
ITMediaに関連記事が載っていました。
http://www.itmedia.co.jp/news/articles/0801/24/news014.html

PoCの見ると関数をオーバーライドして情報を取得しているのでJavaScript形式で書かれた設定ファイルでないと読み取れない。JSONのデータをCSRFで盗むのと同じ要領です。データがJavaScriptとして読み出せるファイルだけしか読みこむ事ができません。FirefoxもThunderbirdもパスワードはDBだったかな? grepしてみた限りでは特に読まれて直ぐに危険、というjsファイルはありませんでした。

一般ユーザは拡張がjarなのかそうでないのか等、気にしていないし気づく事はまずありません。jarにして問題解決ならjarにしないと読めない仕様に変更すれば良いと思います。

ちょっとづつ編集していたら結構いい加減な事を書いていたので修正しました。

Hack Attack Hits 10,000 Web Sitesによると自動化された攻撃で10000以上のサイトがブラウザやブラウザプラグインの脆弱性を攻撃するコードをホスティングさせられているそうです。

この攻撃はFTPとCPanelのパスワードをブルートフォース方式で解析、ログインできたサイトに自動的に攻撃コードを埋め込むようになっているそうです。攻撃を受けマルウェア配布に利用されているサイト管理者の多くは攻撃自体に気づいていないとしています。

自動化されているので日本語のサイトであることなど関係無しに攻撃される可能性があります。予測しやすいパスワードを利用されている方はすぐに予測できないパスワードに変更されることをお勧めします。

記事には常に変わるJavaScriptを生成するファイルが埋め込まれる、

Those servers have been infected with a pair of files that generate constantly-changing malicious JavaScript.

と書いてありますがさすがに攻撃コード自体を変更するのは難しいと思います。恐らくダウンローダーへアクセスするJavaScriptが動的に生成されているのだと思います。

どのような攻撃が考えられるか参考になるリンク

Death by iFrame
http://www.cio.com/article/135452

これを読むとマルウェアをホスティングさせられたサイトがどのように利用されるか解ると思います。
# 予想なので違っているかも知れません。
# 間違っていたら教えてください。

関連記事
Legitimate sites serving up stealthy attacks
http://www.securityfocus.com/news/11501
Attackers favor compromise over creation
http://www.securityfocus.com/brief/667
Most malware comes from legit sites, says researcher - 51% of sites spreading malicious code have been hacked
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9058599&intsrc=hm_list

攻撃に成功するとPCはボットネットに組み込まれます。この攻撃から自分（ブラウザのユーザ）を守るには

• ブラウザとプラグインを最新版にする（脆弱性がないバージョンを利用する）
• FirefoxにNoScript拡張をインストールして利用する（信頼しないサイトではiframeを無効にする）

の両方を併用することが望ましいと思います。Flash, QuickTime, RealPlayer, Adobe Readerは最低限チェックすべきプラグインです。アプリケーションが勝手にプラグイン（プロトコルハンドラも）をインストールしている場合もあるので要注意です。

上記の対策だけでは心配なので以下のチェックもする方が良いと思います。

• Windowsを安全な状態にする（Microsoft Updateで最新版の状態にする)
• 無闇にサイトを信頼しない（特に個人運営サイト）
• その他のアプリケーションも脆弱性があるバージョンはすべて更新する

個人運営サイトでなくてもホスティングサービスを利用しているサイト等ではリスクはあります。似たような攻撃ならガジェットを利用しているWebサイトでも可能です。したがってガジェットを利用しているサイトにも注意が必要です。

セキュリティアップデートに敏感なユーザでも脆弱性があるプログラムの更新を忘れている事は非常に多いようです。脆弱性情報サイトとして有名なSecuniaのPSI(Personal Security Inspector)のベータテスト、100万ユーザから得られたデータによると、95%のPCに既知の脆弱性があるプログラムがインストールされていたそうです。PSIをインストールするユーザはセキュリティアップデートには敏感なユーザと考えられますが、95%つまり100万PCのうち95万のPCには何らかの既知の脆弱性があるプログラムがインストールされていた事になります。これには驚きです。

Flash Playerに深刻な脆弱性（簡単に他所のサイトのアカウントが乗っ取れる脆弱性と他の脆弱性）がありアップデートがリリースされています。

悪意のあるSWFファイルを読み込ませることによって脆弱性を悪用することができ、攻撃が成功すればシステムを乗っ取ることも可能だという。

http://internet.watch.impress.co.jp/cda/news/2007/12/20/17964.html

ここまでしか読まなければかなり控えめな表現であることが分かります。後半の方まで読むとエンジニアであれば理解できる書き方になっています。

Flash Playerにはクロスドメインポリシーファイルの扱いに関する脆弱性が存在しているという。その結果、細工を施されたWebページによって、サイトのクロスドメインポリシーが迂回される可能性があり、サイト管理者の意図に反してデータがアクセスされる可能性があるとしている。このほか、任意のHTTP ヘッダが送信可能な脆弱性も存在するという。

あまり素人向けの解説とは言えないかも知れません。Watchなのでこれでも良いのかも知れませんが。

Securiteamの記事は最初の方に重要な事が書いてあるので分かりやすいです。

This vulnerability allows remote attackers to run arbitrary JavaScript code in the security context of other domains,

http://www.securiteam.com/securitynews/6E00L00KKC.html

Universal Cross Site Scriptingと呼ばれるタイプの非常に危険な脆弱性です。別の言い方をすると他所のドメインのクッキーを自由に盗める脆弱性です。悪意のあるフラッシュを実行するとログイン状態にあるサイトのアカウントを乗っ取られる可能性があります。

しかもこの脆弱性の攻撃は非常に簡単です。元ネタのStanford大のページ、Securiteamのサイトには攻撃方法が記載されています。

Exploit:
package {
  import flash.display.Sprite;
  import flash.net.*;
  import flash.utils.*;

  public class uxssdemo extends Sprite {
    public function uxssdemo() {
      setTimeout(DoAttack, 1000);
    }

    public function DoAttack():void {
      var request:URLRequest =
          new URLRequest('javascript:alert("Cookie: "+document.cookie+"\\n\\nContent: \\n\\n" + document.lastChild.innerHTML);window.close();');
      navigateToURL(request, 'tg');
    }
  }
}

Flashをよく知らない人でも簡単に攻撃できます。もしまだアップグレードしていない方は即刻Flash Playerをアップグレードした方がよいです。

Adobeのセキュリティ情報
http://www.adobe.com/support/security/bulletins/apsb07-20.html

Flashのダウンロードページ
http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash

Flashのバージョンチェック
http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_15507

言いたいことのほとんどが書いてある素晴らしいブログ記事です。

ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。
http://neta.ywcafe.net/000799.html

ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。の続きと補足
http://neta.ywcafe.net/000803.html

AuはMNPを機会にDoCoMoの独自仕様メールアドレスと同じにしたと記憶しています。いい加減にしてほしい、と強く感じたのでよく覚えています。KDDIに至ってはDion等でも他のメールサーバやクライアントで受信できないメールアドレスを作成できるようにしているようです。まさに嘘を隠すためにまた嘘をついている状態です... しばらくすれば事態は良くなると思っていたのですが悪くなっているようです...

ルールを守りたくないなら中国のように独自TLDでも作って（そういった計画があったと聞いていますがその後どうなったかは不明）その中でやれば良いでしょう。ユニバーサルに使えない自爆メールアドレスを作ってしまうのはエンドユーザの問題ではなく、サービス提供者の姿勢の問題だと思います。

いくら技術が分からない人間でも「他のキャリアの電話をかけようとした時に電話できなかったら困りますよね?同じよう他のメールサーバ宛にメール送信しようとしたときにメールが送信ができなかったら困りますよね?」といった単純な議論も通用し無いのでしょうか? すでに作ってしまったメールアドレスを強制的に変えるのは難しくても、新しいアドレスは標準に則ったアドレスのみ許可するのは簡単です...

RFCが絶対か、というとRFC通りに作ると動かなくなるものもあるのでそこは適当に対処しなければならない場合もあります。しかし、わざわざ動かなくなる（メールの送受信に問題発生する可能性がある）メールアドレスを作れるようにするのは責任ある企業として適当な対応とは言えないと思います。

備考：かなり古いブログですが公開し忘れしていた分です。

次のようなメールが来ました。一瞬、Yahoo!のメールかと思いました。

From: (profile_page_mail)@yahoo.com <profile_page_mail@yahoo.com>
To: (yohgaki)@ohgaki.net <yohgaki@ohgaki.net>
Subject: プロフィールが未設定となっております。

プロフィールが未設定となっておりますので、プロフィールを作成下さいませ。
すべてが無料となっておりますので、ご自由にご利用出来ます。

↓のURLからプロフィール作成が簡単に行えます。
(http)://www.profile-page.com/?member&mail=yohgaki@ohgaki.net

From:はyhoo.comドメインに偽装しています。
「120% SPAMメールだな」と思いましたがリンク先を確認してみる為にクリック。
やはり出会い系サイトのプロフィールを入力するページが表示されました。一目見てYahooとは関係ないと分かるサイトです。ページには

会員の方々のプライバシーの保護、および個人情報のセキュリティには万全を期しています。
あなたが当会の会員であることをはじめ、あなたの個人情報が外部に漏れることはありませんので、ご安心ください。

と書いてありますが、Phishingメールに載っているようなサイトが信頼できるはずがありません。

このメールはFromアドレスを偽造しているのでSPAMというよりPhishingと言った方が適切と思います。送信元を偽ったメールを送っても罪にはならないかな?

Phishingの危険性はサービス開始当事にあまり認識されていなかったとは言え、Yahoo!メールはgmail.comやhotmail.comの様に一目でフリーメールだと分かるドメイン名の方が良かったですよね。

備考：かなり古いブログですが公開し忘れしていた分です。

この話題はどちらかというとWebブラウザとプラグインの問題と言えるので書いていませんでした。Web開発者としては早く直してほしい問題ですがサーバのコードを書く側としては対策をできません。なぜかこの話題の日本語リソースがあまり無いようです。とりあえず私のブログにも書いておくことにします。

WebブラウザとプラグインはSame Originポリシーで守られています。基本的にはXMLHttpRequest、Javaアプレット、Flashはそのコードを送ったサーバにのみリクエストが送信できるようになっています。クッキーもコードを送ったサーバ（ドメイン）のクッキーにのみアクセスできるようになっています。

Same Originポリシーが無いと悪意があるサイトにアクセスするだけでいくらでもクッキーに保存されたセッションIDなどを盗めます。これを防ぐ為にブラウザはDNS Pinning(IPアドレスを固定するセキュリティ対策）と呼ばれる手法を利用しています。

DNS Pinningが無いとファイアーウォールで保護されている内部のコンピュータにアクセスしたり、IPアドレスベースでの認証の回避が可能になります。DNS Pinningが無い場合にどのように攻撃されるか簡単に解説します。

DNS Pinningの必要性

ブラウザがURLを解釈する際、ホスト名をIPアドレスに変換するためにDNSサーバに問い合わせを行います。サーバ名はDNSによって管理されサーバのIPアドレスは必要に応じて自由に変更できるようになっています。

攻撃者がドメインを管理して、悪意があるDNSサーバを運用している場合、ブラウザからの最初の問い合わせには実際に存在する攻撃用のページをホストしているサーバのIPアドレス（通常のグローバルIPアドレス）を返します。

仮に攻撃用のURLは次のURLだとします。
http://www.example.jp/attack.html

被害者がURLにアクセスさせる攻撃用attack.htmlのコンテンツにはXMLHttpRequestを利用してwww.example.jpサーバにリクエストを送信するJavaScriptを記述します。ページが記述してあるwww.example.comとXMLHttpRequestの送信先であるサーバ(www.example.com）は同じサーバであるのでブラウザはアクセスを許可します。

DNS Pinningが無い場合、ブラウザはサーバ名を解決するためにDNSで再度名前の解決を行います。攻撃者がホストしている悪意のあるDNSサーバはwww.example.comの名前解決リクエストがきた場合は内部のIPアドレス、例えば192.168.0.1、192.168.0.2、192.168.0.3等を返させます。この様なDNSサーバを用意することにより攻撃者は簡単に本来アクセスできてはならない内部ネットワークのコンピュータにアクセス可能になります。

例えば、IPアドレスが192.168.0.1のコンピュータはSOHOルータでCSRFに脆弱な場合、Firewallを無効にしたり、VoIP対応ルータの場合通話を盗聴されたりVoIPサービスを不正利用される可能性があります。さらなる攻撃を行うために内部ネットワーク構成のスキャン等を行う事も可能になります。

この様にDNSによって名前の解決を毎回行っていると内部ネットワークへの不正アクセスを許してしまいます。これを防ぐためにブラウザやブラウザの拡張はDNS Pinning(DNSリクエストのキャッシング)を行います。同じサーバ名にリクエストを送信する場合、DNSによって名前の解決を行わず既に解決済みの結果を利用します。

このように解説すると、悪意のあるDNSサーバを用いた攻撃は明白で全ての実装が最初からこのような攻撃を考慮していたはず、と思われる方もいるかも知れません。しかし、実際にJava AppletがDNS Pinningを実装していなかったり、XMLHttpRequestオブジェクトがDNS Pinningを実装していかったりしたケースがありました。

攻撃例としてFirewall設定の変更やVoIPの不正利用を取り上げていますが、実際にAnti DNS Pinning/DNS Rebidingを利用したFirewall設定の改竄やVoIPの不正利用などの攻撃は行われています。

Anti DNS Pinning/DNS Rebinding

Anti DNS Pinningは名前が示すとおりDNS Pinningを回避する手法の名前です。Stanford大学の論文でより直感的に分かりやすい名前としてDNS Rebindingが利用されています。DNS RebidingはAnti DNS Pinningの別名と考えても差し支えありません。

書きかけです。近日中に再編集します。