yohgaki's blog

  • Apacheの脆弱性

    まだ確認してませんがこんなのが…

    http://www.infohacking.com/INFOHACKING_RESEARCH/Our_Advisories/apache/index.html

    The Apache web server is prone to several non crítical vulnerabilities -by themselves- that could allow
    by combining them, and on some specific scenarios, to carry out serious attacks, some of them with that impact:

    1) Execution of script code in the client side:

    1a)Web “defacements” (E-graffity)
    2b)Phishing (authentication forms)
    3c)System compromise (script execution on same domain than Admin Panel)

    2) Location header injection -cache poisoning-:

    2a) Denial of service
    2b) Partial URL redirection

    4) And the most innovative and interesting thing: almost arbitrary injections in the server HTTP response stream:

    4a) “on the fly” fake injection of virus.
    4b) In the future, with some additional hack, arbitrary injection of binaries -trojans, etc.-

  • SSL Hell

    10月30日作成のページですが今みました。

    Dan Kaminsky’s SSL Hell

    結構笑えます。（英語のプレゼンテーションビデオです）
    これではどのサイトも信用できないです。

    追記：
    ビデオの見なくても良いように一番重要な点だけ書きます。

    SSLの公開鍵・秘密鍵がデフォルトのまま使っているサイトが多くある、というくだりです。銀行などのサイトでも「ありえない」と思える割合のサイトがデフォルトのキーペアを使っていて暗号化の意味がなくなっている！！！のだそうです。（詳しくはビデオを参照）

    キーはサイト毎に生成するになぜこんな事が起きる？と思われる方もいるかもしれません。ハードウェア系のSSLソリューションには静的に生成されたデフォルトのキーペアが設定されている場合があるのですが、なんとそのキーを使っているサイトが多数存在する、とこのプレゼンで言っています…

    笑うに笑えないですが、不謹慎にも笑ってしまいました。

    教訓 ‐ デフォルトパスワードだけでなくデフォルトの鍵も使わない！
    (当たり前すぎです…)

  • Windows XP -> Vista アップグレード

    Windows XPからVistaへアップグレードする事に懐疑的な意見もありますが、一般ユーザの多くがVistaに乗り換えるだけでもかなりのスパイウェアなどのマルウェア被害を防ぐ事が可能になると思っています。最も効果的な機能はUAC（User Access Control: 権限がたりない場合や管理者権限を必要な操作の際にユーザ認証や確認を行うダイアログを表示する機能)ですがコントロールパネルのユーザアカウントで簡単に無効（一応有効にする事を推奨するコメントはありますが…)できるのはどうかと思います。サポート負荷を考えると仕方ないとは思いますがもう少しわかり辛い方法（レジストリの編集、ポリシーの変更）でも良いような気がします。

    個人的にはUACがVistaを買う一番の理由ですがCNETでは全然相手にされてないですね…

    http://www.cnettv.com/9710-1_53-26068.html?tag=bubbl_1 （英語のビデオ）

    普通のマルチユーザOSでは通常作業は通常ユーザで行います。特別な権限が必要な場合は別コンソールでログインしたりsudoコマンドを使ったりします。Windows XPまではrunasコマンドくらいしか別権限でコマンドを実行できませんでした。このrunasコマンドは使い勝手も悪く、管理者がよく使用するコントロールパネルの実行など、実用的なものではないです。XPのデフォルトユーザのOwnerは管理者権限を持っていて普通のユーザは普通にシステム管理者権限でマルチユーザOSを使っています。この点ではシングルユーザOSと同じレベルという時代遅れな使い方になっていました。Vistaは初めて普通ユーザは普通のユーザ権限で使えるようなったWindowsという点だけで十分にアップグレードに値すると思います。RSA Conferenceでも指摘されていすが最近のマルウェアはカーネルレベルで存在を隠す様になってきています。PCを”普通”は”普通のユーザ”で使うこことが当たり前にならなければならないと思います。

    # コンピュータに詳しい方でも自分のアカウントがAdministratorsに所属
    # している方も多いです…
    # 本来ならUACのようなあって当然の機能はWindows NT/2000で導入される
    # べきだったと思います。UACを追加するXP SP3とかあればよいのですけ
    # どね。

    さて本題(?)のXP->Vistaへのアップグレードですが、さすがに使っているPC環境をアップグレード（新規・別途にインストールではなくアップグレード）をベータ版ではする気にならなかったので試したことがありませんでした。正規版のDVDでいくつかの本当に使っているWindows XPをVistaにアップグレードしてみました。

    実際に使っているPCをVistaにアップグレードして気づいたのはマウントされたボリュームのアクセス権限エラーです。Vistaにアップグレードするとファイルのアクセス権をかなり安全な状態にしてくれますが、マウントされたボリュームには問題があるようです。アクセス権限を非常に緩い設定（ファイルおよびボリュームの両方）に変えてもボリュームをまたぐファイルの移動で「権限がない」とエラーになってしまうようです。

    仕方がないのでファイルをコピーしてコピー元のファイルを消して移動しています。MSのサイトをさっと検索してみましたが同様の問題は登録されていないようでした。何か設定を変えると移動できるようになるのかも知れませんが今のところ解決方法は分かっていません。

    XPでは普通にアクセスできていたマウントしたボリュームは、アップグレード後にはファイルの作成さえできない状態（アクセスが全くできない状態）だったのでNTFSのACLに慣れていないユーザはかなり戸惑う可能性があります。

    いろんな物（ネイティブなVGAカードドライバ、AU Music Port、省電力制御アプリ、ネットワーク設定アプリなど）が使えなかったりありますが普段使用しているアプリケーションはすべて問題なく動作しています。

    追記：
    私はVistaは買いだと思います。一般コンシューマがXPよりマルウェアに感染するリスクはかなり低下すると思います。XPにUACがあれば特にVistaをお勧めすることもなかったと思います。

    Vistaにも悪い部分もあります。以下が参考リンク。

    Wait! Don’t Buy Microsoft Windows Vista
    http://www.pcworld.com/article/id,128669-page,1/article.html

    10 reasons not to get Vista
    http://apcmag.com/5049/10_reasons_not_to_get_vista

    BadVista.org
    http://badvista.fsf.org/

  • PukiwikiからMediawikiに乗り換え

    SPAMMERからのページ改ざんや作成が日を追うごとに増えてきているので、wikiを管理が行いやすいMediawikiに乗り換える事にしました。まとめて移行する時間はないので段階的に移行する事になります。

    「あれ凍結したはずのページが改ざん?」と思ったら大文字を小文字に変えて新しいページを作っていました。
    しかし、SPAMMERも色々考えますね。

    # こんな事に時間を使うより、書きたい事は沢山あるので、
    # コンテンツをマシにしたいのですけどね…
    # タイポをよくするので親切な方から直接直して頂いてい
    # たりしたのですが認証なしで編集は時代遅れですから
    # 仕方ありません…

  • PHP 5.2.1リリース

    情報としては古くなっていますが、念のため書きます。PHP 5.2.1がリリースされています。

    JP-CERTのアドバイザリ（JPCERT/CC REPORT 2007-02-07）にMODxのXSSが記載されていましたがこっちの方が重要性は高いと思われます。次のアドバイザリでは記載されるかもしれませんが、例によってPHP4は置き去りにされているので、記載されない可能性も高いと思います。私が編集者だったらどうするかかなり迷います。
    # MODxはコードをチラッとみただけで試すのを諦めたのですが
    # いろいろあるようですね。

    時間ができたらCode Blogの方にいろいろ書いてみたいと思っています。
    # いつできるか？が問題だったり….

  • SPAMをテーマにしたエントリにSPAM

    皮肉な事にSPAMをテーマにしたエントリにSPAMがありました。

    http://blog.ohgaki.net/index.php/yohgaki/2006/07/14/10a_ya_sa_sa_ia_sa_a_ra_a_ca_a_ma_a_a_ms#c14228
    （ドメイン名にSPAMを付けてページランクに影響しないようにしています）

    既にあるコメントをコピーして張り付ける、といった手口ですが適当にモデレートしていると許可してしまいそうな手口です。この手の手法を使ったSPAMはまだ少ないですが困ったものです。

    このSPAMはコメントでしたがトラックバックにCAPTCHAを付ける訳にはいきません。またトラックバックの妥当性を検証するにはトラックバック先のURLを見て検証する必要がありますが、そのURL自体が罠ページになっていてブラウザのセキュリティホールを攻撃し任意コードを実行されたりリスクもあります。有名サイト、例えばgoogle.com等、をタイポするとブラウザの脆弱性を攻撃しマルウェアをインストールしようとするサイトがあるくらいなのでトラックバックSPAMで誘導するくらいの事はやりかねません…トラックバックは便利な機能ですがセキュリティ的には非常に脆弱な機能と言えると思います。

  • b2evolutionバージョンアップ

    セキュリティ問題の修正を含むアップグレード版がリリースされています。

    http://b2evolution.net/news/2007/01/22/b2evo_1_8_7_and_1_9_2_released

    「意味がある形での攻撃は難しいだろう」と書いてありますがアップグレードしておいた方が良いと思います。

    正規表現がおかしてくリンクが正しく表示されない問題は直っていないですね。

  • Windows税の返金?

    少し古いですがLinux.comに「Windows税の返金をDELLから受けた」といった記事が載っています。

    私はWindowsも使うのでサーバ以外であれば返金して欲しい、と思わないですが日本でも可能なのかと少し気になります。何時間もかけて$52.50の返金だったので著者自身も勧めてはいません。

    Tipsとして

    • 返金してもらう資格がある（日本の法律ではどうなんでしょう?）
    • すべて(やり取りを）記録する
    • (時間の浪費や面倒なやり取りを）覚悟しておく
    • 礼儀正しく
    • 粘り強く
    • 愛想よく

    と記載されています。コールセンター構築に関わっていた事があるので「礼儀正しく」「愛想よく」と書いてある点には好感が持てます。

    しかし、メーカーサイドとしてはこの手のリクエストは厄介ですね。バンドルしたソフトなどの返金を求められても困りますね… しかし、LinuxやBSDが代替OSとして利用可能なのでOS無しでの販売もして欲しいです。個人的に困ったのは欲しいノートPCがWindows XP Homeしかバンドルしてなくて仕方なくWindows XP Homeを買わされたで事した。後でステップアップグレード版でHome->Professionalへアップグレードしました。Vistaでも同じような事で困るかも知れません。

  • SHA1でハッシュ化したパスワードは危険になった

    パスワードを平文で保存するのは論外で、MD5やSHA1でハッシュ化するのは当たり前です。しかし、SHA1を2000倍早くクラックする方法などが発見され「SHA1は脆弱だ」（ちなみにMD5はもっと危険）とされてからしばらく経ちます。アメリカ政府や大手企業はSHA1は使わない、としています。

    Slashdot.orgにまた載っているので更に高速化できた、ということか?

    参考：

    (さらに…)

  • PostgreSQLでSHA1

    MS Access 2003でSHA1を使おうと思ったらどうもうまく動作しませんでした。
    .NETのmbcorlibにMD5,SHA1等のハッシュ関数が定義されていてVBからはMSDNに書いてるサンプルで動作するのですがMS AccessのVBAからはいろいろ試しても動作しませんでした。サンプル通りだとオブジェクトを生成する行でシンタックスエラーになり、多少変更しても動作しませんでした。
    # 普段VBAでプログラミングはしないので私が無知なだけかもしれませんが…
    # Windowsプログラマの方はハッシュはあまり使わない??

    VBAでハッシュが使える方が良かったのですが、しかた無くPL/Pythonでハッシュ値を取得し返す関数を定義することにしました。

    PL/Pythonの場合、

    CREATE OR REPLACE FUNCTION SHA1HASH( TEXT ) RETURNS CHAR(40) AS ‘
    import sha
    hash = sha.new( args[0] )
    return hash.hexdigest()
    ‘ LANGUAGE plpythonu;

    言語を登録していない場合

    CREATE LANGUAGE plpythonu;

    を先に実行しておきます。8.0からplpythonはplpythonuに名前が変更されています。（Untrustedな言語なのでuが付く）

    PL/Perlの場合は多分こんな感じ（こちらは試していません）

    CREATE OR REPLACE FUNCTION SHA1HASH( TEXT ) RETURNS CHAR(40) AS ‘
    use Digest::SHA1 qw(sha1);
    return sha1($args[0]);
    ‘ LANGUAGE plperl;

    同じようなコードでMD5, SHA256, SHA512等が簡単に作れます。

    普通パスワードはハッシュ化したパスワードを保存するのでユーザ情報テーブルのパスワードフィールドはハッシュ値になっています。

    SELECT * FROM user WHERE username = ‘USERNAME’ AND password = sha1hash(‘PASSWORD’);

    といった感じでクエリできるようになります。アプリの言語側でハッシュが使える場合はアプリ側でハッシュ化する方が好ましいのですがVB等でライブラリが制限されている場合には便利かも知れません。

  • なぜPHPアプリにセキュリティホールが多いのか?

    技術評論社の新サイトで「なぜPHPアプリにセキュリティホールが多いのか?」をテーマにブログ風の記事を掲載させていただく事になりました。第一回は「CVEでみるPHPアプリケーションセキュリティ」です。

    http://gihyo.jp/serial/2007/php-security/0001

    CVEをフォローしている方であればPHPアプリケーションの脆弱性レポートの多さが目立っていることはよくご存知と思います。何故CVEエントリが多いのか解説しています。よろしければご覧下さい。

    技術評論社の須藤さんに編集していただいているので私が書いた文章より読みやすいです。

    今、気が付いたのですが、SecurityForcusに次の様な記載がありました。

    The problem is, PHP applications accounted for about 43% of the security issues in 2006, according to the National Institute of Standards and Technology (NIST).

    http://www.securityfocus.com/columnists/427

    数えると凡そ半分と言っても良いくらいPHPアプリの脆弱性レポートがあったのですね。

  • b2evolution 1.8.6にXSS脆弱性

    このブログのb2evolutionは1.9.1なので、1.9.1のコードを確認してみたところ、1.9.1にも厳格な入力チェックが行われていないなど、確かに好ましくない処理が行われていました。XSSと言うよりHTTP Response Splittingに脆弱なコードになっていました。

    攻撃を成功させるには幾つかの条件が必要でした。

    • 普通のクロスサイトスクリプティングであるため、ログインするページを表示する場合に他人が用意した罠ページのログインリンクをクリックしないとならない
    • その後、ログイン操作を実際に行わなければならない
    • PHPのバージョンが古くheader関数が脆弱である

    特に重要なのはPHPのバージョンが古くなければならない点です。PHP 4.4/PHP5.xなら問題ありません。このサーバで利用しているPHPも大丈夫なので対処は行っていません。

    例えばRHEL 4はPHP 4.3なので攻撃が成功するかも知れません。(パッチを確認すれば脆弱性を攻撃できるか直ぐ分かるのですが未確認）いずれにせよ、公開用のPHPスクリプトを書く場合、比較的古いバージョンのPHPも広く利用されている事を前提にコーディングしなければならないです。

    この脆弱性の危険度はCVEでHighになっていますが、SecuniaではLowになっています。どちらに設定するかは微妙なところです。環境が古ければ「非常に危険」と考える事もできますが、現在PHPプロジェクトが正式にサポートしているバージョンは4.4と5.2で両方とも影響を受けません。

    話は変わりますがb2evolution 1.9.1は使わない方が良いかも知れません。正規表現に問題があるらしくアンカータグが正しく処理できない事がよくあります。本家サイト見るとサポートされているバージョンが1.8系と1.9系だけになっているのでバージョンアップを考えている方は1.8系を先に試す事をお勧めします。1.8.6で正しく表示されるかどうかは検証していませんが、少なくとも1.9.1は問題が多いです。

  • クライアントサイドで認証とは… 在りない事が起きるのがWebサイト…

    「Macworldサイトのハッキングでジョブズ氏講演の優待席を無料ゲット 」したハッカーがいるらしい。なんと認証がクライアント側で行われていたそうです。

    ありえない…

  • Adobe Readerは8にバージョンアップ

    1月3日付けでAdobe Readerの脆弱性が報告されています（CVE-2007-0044、CVE-2007-0045、CVE-2007-0046、CVE-2007-0047）

    Name: Adobe Reader Open Parameters XSS
    Date first reported: 1/3/07
    Vulnerable software: Adobe Reader plug-in versions 6 and 7 for Mozilla Firefox, Opera and Microsoft Internet Explorer.
    What it does: Could allow denial of service (crash), remote access and execution of malicious code.
    Recommendations: Upgrade to Adobe Reader 8
    Exploit code available: Yes
    Vendor patch available: Yes

    詳し解説はリンク先を見ていただくとして、次のようなリクエストで任意のJavaScriptが実行できてしまうようです。

    http://www.(domainname).com/file.pdf#whatever_name_you_want=javascript:your_code_here

    としてどこのドメインでもXSSが可能になるようです。
    # PDFが全くないサイトなら大丈夫とは思いますが…

    サイト側では対処の方法がないように思えます。
    # 相変わらず自分で検証する時間がない…

    追記：
    PDFとして処理させない事になりますが.pdf に対して application/octet-stream を指定すると大丈夫なようです。

    プラグインつながりで、ついでに書くと最近色々見つかっています。

    CVE-2007-0015

    Buffer overflow in Apple QuickTime 7.1.3 allows remote attackers to execute arbitrary code via a long rtsp:// URI.

    他にはIE7+FlashでDoS（CVE-2006-6827）、IE7+RealPlayerでDoS（CVE-2006-6847）が可能などが見つかっています。常々、プラグインは危ない、と言っていますが普通のユーザはあまり意識していないですね…

    インストールされたプラグインを使って攻撃する方法は色々ありますが、Flashは結構攻撃使えるプラグインだと思います。本当のサイトをFalshで作り直してフィッシングするケースも見かけられるようになったそうです。フィッシングツールなどでページコンテンツの分析を回避する手法としてFlashで作り直しを行っています。スパムメールと同じですね。

  • JavaScriptのソースに重要なデータを埋め込むなんて….

    GmailでJavaScriptのソースとしてコンタクトリストデータを埋め込んでいたため、第三者がコンタクトリストを盗めてしまう、という問題が話題になっています。

    まだ詳しく調べていませんがsrc属性に指定されたソースは誰でも（どのサイトからでも）取得できるブラウザの仕様を利用したものだと思います。

    比較的早くからsrc属性で他のサイトのJavaScritpが指定できる仕様のリスクは指摘されていました。Gmailでさえ重要なデータをJavaScriptのソースに埋め込んでいるのですからAjaxアプリケーションの多くに同じ脆弱性があるような気がします…

    手っ取り早く不完全な方法で修正するにはリファラチェック、きちんと修正するならJavaScriptのリクエストに鍵を付けてチェックする、といった方法で対策可能です。

    http://example.com/javascript_contains_sensitive_data.js?key=123456789

    と言った感じです。

    # 鍵を付ける場合、セッションIDを鍵にしてはいけません。
    # セッション変数にランダムな鍵を設定してチェックすると良い
    # です。