カテゴリー: Security

DoDへのクラッキング

中国がDoDをクラックした、と話題ですがSecurityForcusの記事が詳しいのでメモとして。

サーバシグニチャは隠すのが当たり前

私も何年も前からセミナーではサーバ、モジュールバージョンは隠すようにと言っています。何故こんな事で賛否両論になるのか全く理解できません。犯罪者がどのように攻撃するか？を考えればなぜ隠す必要があるのか理由は明白です。サーバのバージョン情報が詳しく公開されていれば、その情報を使うに決まっています。攻撃に使える情報は全て使わない訳がありません。

最新版を使っているから安全ではない事も明白です。サーバに0day攻撃の脆弱性が発見された場合どの情報を使います？公開または推測できるバージョン情報に決まっています。

フィンガープリンティングでかなりの確率で推測可能、という議論もあるとは思います。しかし、適切に運用／設定されているシステムなら細かいバージョン番号までは推測できない場合が多いと考えられます。

犯罪者が攻撃に利用している、利用する可能性が高いと分かっている情報を　わざわざ広く一般に公開しない方が良いに決まっていると思います。

近所で空き巣が多発しているにも関わらず「ただいま留守です」「鍵もかかっていません」とわざわざ正直に張り紙をする人がいるでしょうか？

「家を留守にする前に戸締まりをしてから出かけましょう」というアドバイスに対して「窓ガラスを割れば..」「ピッキングをすれば…」と「留守の戸締まりはあまり意味ない」と反論しているような議論は必要ないと思います。

BIND8もメンテナンス終了

また別のDNSキャッシュ汚染脆弱性が見つかったBIND8ですが、2007/8/27でメンテナンス終了と宣言しています。

ISC is announcing BIND 8 to be End of Life as of today, 27 August 2007.

ISC strongly encourages users who depend on BIND 8 to migrate to BIND 9 as soon as possible.

djbdnsを使っているので影響ないですがBIND8が残っているシステム管理者の方、ご苦労さまです…

どうせアップグレードするなら別のDNSサーバも検討してみるのも良いかも知れません。

DJBDNS
http://djbdns.qmail.jp/

PowerDNS
http://www.powerdns.com/

MaraDNS
http://www.maradns.org/

Name Server Deamon
http://www.nlnetlabs.nl/nsd/

dents
http://sourceforge.net/projects/dents/

pdnsd
http://www.phys.uu.nl/~rombouts/pdnsd/index.html

Dual DHCP DNS Server
http://sourceforge.net/projects/dhcp-dns-server/

Oak DNS Server
http://www.digitallumber.com/oak/

Zero Calorie DNS Server
http://www.datazygte.com/downloads.html

dnsjava
http://www.dnsjava.org/index.html

Posadis DNS Server
http://sourceforge.net/projects/posadis/

RB DNS
http://sourceforge.net/projects/rbdns/

JDNSS
http://sourceforge.net/projects/jdnss/

CustomDNS
http://sourceforge.net/projects/customdns/

MyDNS
http://sourceforge.net/projects/mydns/

探してみるとたくさんありますね。

バグが少ないブラウザがより安全とは限らない

Honeypotプロジェクトの調査の結果、興味深いというか、予想通りの結果になったようです。

Older versions of the three major browsers for Windows — Microsoft’s Internet Explorer 6 SP2, Mozilla’s Firefox 1.5.0, and Opera’s Opera 8.0.0 — were each used to browse the same subset, about 10 percent, of the sites. While researchers have disclosed about twice as many vulnerabilities for Firefox 1.5.0 as for Internet Explorer 6 SP2, the Honeynet Project found no attacks against the browser. Microsoft’s Web software, however, was compromised nearly 200 times.

攻撃する人も効率良く攻撃するためにシェアの多いのIEは200回攻撃されたにも関わらず、バグの多い古いFirefox、Operaは攻撃されなかったそうです。

The survey used a large list of 300,000 URLs belonging to about 150,000 hosts, finding that pornographic sites have the highest incidence — about 0.6 percent — of malicious sites, but that all categories included some sites that could lead to compromise.

これも予想どおりですがアダルトサイトが最もリスクが高いようです。しかし、全てのタイプのサイトから攻撃される可能性があるとしています。

A fully-patched version of Internet Explorer 6 visited 2,289 malicious sites, none of which managed to compromise the system.

2289の悪意のあるサイトは全てパッチ済みのIEに対して攻撃を成功させることはなかったそうです。

http://blogs.zdnet.com/security/?p=474

にはリモートコード実行脆弱性数のグラフが載っています。Firefoxが断トツです。

SkypeがLinuxユーザデータも収集?

「No spyware, adware, malware」としているSkypeですが

Much to his horror he found that Skype kept asking to see all the details of his Firefox software and its plug-ins.

とLinux版ではFirefoxとプラグインの情報を収集している疑いがあるようです。別の情報

http://www.heise-security.co.uk/news/94975

によると

One possible reason to read the Firefox directory is in order to retrieve from there proxy settings as it is done by Skype for Windows with Internet Explorer. This is supported by tests performed by heise Security, in which Skype opened only directories. The only real file it opened in the Firefox directory was prefs.js which does indeed contain the proxy settings. Another reason for Skype to access the user’s directory might simply be to check if the user has installed the vendor’s Firefox extension.

好意的に見ればプロキシ設定などを参照するためにpref.jsを読み取り、SkypeのFirefox拡張がインストールされているか確認している、とも考えられます。

試しに自分のLinuxのSkpyeでstraceしてみたところ通常の起動時にはfirefoxのファイルを読みにいかないようです。

今のところSkypeからのコメントは無いようですが「No spyware, adware, malware」と宣言するのであれば収集している情報がどのように利用されているか説明すべきでしょう。

ところで、PC版ではBIOS情報を収集している疑いがあるようです。

http://www.theinquirer.net/default.aspx?article=37489

Bugzillaのセキュリティホール

Bugzillaに結構重要なセキュリティホールがレポートされています。

CVE-2007-4538

email_in.pl in Bugzilla 2.23.4 through 3.0.0 allows remote attackers to execute arbitrary commands via the -f (From address) option to the Email::Send::Sendmail function, probably involving shell metacharacters.

CVE-2007-4539

The WebService (XML-RPC) interface in Bugzilla 2.23.3 through 3.0.0 does not enforce permissions for the time-tracking fields of bugs, which allows remote attackers to obtain sensitive information via certain XML-RPC requests, as demonstrated by the (1) Deadline and (2) Estimated Time fields.

http://www.bugzilla.org/security/2.20.4/

によると8/23には修正版が公開されたようです。コマンドインジェクションなので早くアップグレードする必要があります。

URLも右から左に書ける、と言う話

右から左に書く機能を使ってファイルの拡張子をごまかす方法は有名です。タイトルのリンク先はUTF-8テキストをアドレスバーにコピー&ペーストするとURLでさえ逆向きに表示される、と言う話。私は知らなかったのですがその系に詳しい方には常識だったのかな？？

コメントに書いてありますがOSXのFirefoxでは逆向きにならないようです。今私もOSXで書いているので後でWindows/Linuxで試してみます。

見え方にもよりますが、URLでも使えてしまうと「釣ってください」と言っているのと同じ状態なっているかもしれません… どう見えるか後で試してみよう…

追記：
リンク先のブログ本文のテキスト先頭に制御文字らしきものもあるなぁ、とソースを見ると英文を反対方向（右から左）に書いているのですね（笑

アドレスバーに制御文字を入れてから入力するとOSXのFirefoxでもLinuxのFirefoxでも反対方向にタイプされていきます。つまり、testと入力するとtsetになります。ステータスに表示されるURLを反対方向から表示するブラウザがあると困りますが、当たり前に反対から表示しそうな気がします… 後で試そう…

データバインディングを利用したXSS対策

少し前にクライアントサイドでXSS対策（Failsafe対策）をする方法を紹介しましたが
http://blog.ohgaki.net/index.php/yohgaki/2007/08/01/a_ma_ca_ca_ca_sa_a_ma_ca_a_sa_rxssamfcs

こちらはサーバサイド（データをバインディングする方法）も使ってXSS対策する方法です。
http://www.wisec.it/ph/test.php

一般的にお勧めできる方法とは言えませんが、XSS対策としては面白い方法です。この手法の良い所はもれなく対策でき、対策が行われている事を簡単に検証できる点です。悪い所はXSS対策にJavaScriptを使っている、検索エンジンに不親切、NoScriptユーザに不親切などがあります。

テストページのコメントにも書いてありますが、クライアント側での対策であり対策の有効性はクライアントの実装に影響されます。このため完全に防御できないケースもあります。

メモリを解析して脆弱性を自動的に検出、攻撃コードを作成するツール

オープンソースのセキュリティツールで有名(?)なImmunityのDebuggerが結構話題になっている。他にもいろいろ紹介されているようですがeWeekの記事が分かりやすい。

http://www.eweek.com/article2/0,1895,2166829,00.asp

Debuggerはヒープやスタックメモリを自動的に解析して脆弱性を検出し、ほぼ自動的に攻撃コードを作成することもできるようです。攻撃コードの作成時間を50%削減できるとしています。

http://www.immunitysec.com/products-immdbg.shtml

一時的には0day攻撃が増える事が予想されますが脆弱性検査が容易になる、特に機械的検出できるような脆弱性検査が容易になる、のは良い事だと思います。

クライアントサイドでのXSS対策

詳しくはリンク先を見て頂くとして、XSSは

• クライアントサイドで発生する
• 通常JavaScriptで発生する

と言う点着目してスクリプトにサインを付けクライアント側でもXSSを検出しようと言う話です。フェイルセーフ対策としては有用だと思います。Flash, PDF, Javaなどのオブジェクトにもサインすればより良いと思います。サインさえ付けておけばあとは決まったJavaScriptコードを全てのページに追加するだけなのでそれほど難しい対策ではありません。

カラーレザープリンタの印刷物に埋め込まれたコード

コピーすると「COPY」と印刷されてしまう機能は有名です。
コピー機、PhotoShopの紙幣複製を防止する機能も知っていましたが

カラーレーザープリンターで印刷されたものには全てこのように肉眼では判別し難い黄色いピクセルをバーコード（大きさは8×15ピクセル）のように印字することによって、プリンターのメーカー名、機種名、シリアル番号、印刷された日時の4つの情報を合計15バイトの情報としてコード化して埋め込まれているという。

プリンタ、コピー機業界では常識なのかもしれませんが知りませんでした。
# どこかで聞いたことがあるような気もしますが覚えてませんでした。

このバーコード、日本国内で販売されているカラーレーザープリンターでも印刷物にブラックライト（紫外線ランプ）を当てて丹念に調べれば肉眼で確認することができるという。

ブラックライトを持っていないので確認できません…

この機能、全うな目的で印刷する人には何の問題もありませんが不正な目的で印刷しようとする人を思いとどまらせる為に役立つかも知れません。印刷ログを残しておけば時間とプリンタでユーザまで特定できます。すべてのプリンタ、コピー機に入れても良いと思いますがどうでしょう？似たようなセキュリティソリューションを購入する必要もなくなります。

この機能、やはりカラープリンタそれもカラーレーザープリンタ向きの機能だと思うので、問題は全てのプリンタをカラーレーザープリンタにするのは導入とランニングコストがかかり過ぎることくらいでしょうか？

白黒コピー機でコピーしてもこのコードは読めるのかどうか気になります。多分読めないとは思いますが。

BIND9のDNSキャッシュ汚染

BIND9にDNSキャッシュ汚染の脆弱性だそうです。

The paper shows that BIND 9 DNS queries are predictable – i.e. that the source UDP port and DNS transaction ID can be effectively predicted. A predictability algorithm is described that, in optimal conditions, provides very few guesses for the “next” query (10 in the basic attack, and 1 in the advanced attack), thereby overcoming whatever protection offered by the transaction ID mechanism. This enables a much more effective DNS cache poisoning than the currently known attacks against BIND 9. The net effect is that pharming attacks are feasible against BIND 9 caching DNS servers, without the need to directly attack neither DNS servers nor clients (PCs). The results are applicable to all BIND 9 releases [1], when BIND (the named daemon) is in caching DNS server configuration.

まだ中身を見れていないのですが、最適な条件であれば基本的な攻撃で10回、高度な攻撃で1回で次のトランザクションIDを推測できる、としています。最適な条件がどれくらいあるのか？は読んでみないとわからないです。

All stable versions of BIND 9 to date (except the ones released simultaneously with this paper) are vulnerable, i.e. BIND 9 versions 9.4.0-9.4.1, 9.3.0-9.3.4, 9.2.0-9.2.8, 9.1.0-9.1.3 and 9.0.0-9.0.1.

とあるので、BIND9の最新版では問題は修正されているそうです。 http://www.isc.org/index.pl を見ると確かに今月リリースの9.xが紹介されています。

CVEはこれ
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2926

BIND8, BIND4には影響がないとされています。

$intval * 1でサニタイズ…

たまたま見たPHPのコードでSQL文中の整数値を

$intval * 1

として整数型にするサニタイズがありました。この方法をお薦めするわけではありませんが、以前のエントリ

http://blog.ohgaki.net/index.php/yohgaki/2007/07/04/example_1428_a_best_practice_query

でsprintf()の%dを使う方法よりはましです。

$ php -r “echo ‘99999999999999’ * 1;”
99999999999999

実行したマシンは32bitのLinuxシステムですが浮動小数点型に自動変換されるので2^31を越える値でも正しく表示されます。一方、PHPマニュアルの方法だと

$ php -r “printf(‘%d’, ‘99999999999999’ * 1);”
276447231

となってしまいます。最近のDBは大きなモノも珍しくないのでこの程度でオーバーフローするようでは安心できません。もっとも*1方式でもあと一桁増やすと

$ php -r “echo ‘999999999999999’ * 1;”9′ * 1);”
1E+15

と指数表記になるのでこれで十分とは言えません。しかし、マニュアルのベストプラクティスよりは良いです。printf系で処理するなら

$ php -r “printf(‘%1.0f’, ‘99999999999999’ * 1);”
99999999999999

これで十分なDBも多いとは思いますが、ダイナミックにSQL文を生成するのであれば文字列として渡してエスケープしてしまうと確実です。