Security – ページ 32 – yohgaki's blog

セーフガードは「問題が発生しても問題を最小限に留める仕組み」であるのでセーフガードの話をしているのに「本来セキュリティは …」と議論をすりかえられては議論になりません。セーフガードが必要無いならJavaやC#なんて使わなくてもC++を使ってポインタをバリバリ操作すれば良いです。JavaにもSandboxなんて必要ないです。PHPのopen_basedir設定も無用です。OSでNXビットをサポートする必要もないし、アンチウィルスソフトも必要無いです。

基本を解ってない人と話をするのは骨が折れます…

Computer, Security

やはり、まだある単純リモートスクリプト実行バグ..　どころか

1月 4, 2006 #PHP 投稿者 yohgaki

少し前に「やはり、まだある単純リモートスクリプト実行バグ..」と書いていますが、まだあるどころか「まだまだ出てくる」という感じですです。

まず、phpDocumentator、これのテスト用スクリプトにはリモートファイルを実行できるバグがあります。それから、onBoardこれも全く同じくリモートコードを実行できるバグがあります。

onBoardはよく知りませんが、phpDocumentatorは広く使われていると思います。クラックされる可能性が高いのでテスト用コードは削除しておきましょう。（と言うより普通はphpDocumentatorを公開する必要がないので、非公開にしましょう。これ以外にテスト用スクリプトにはリモートスクリプト実行以外にもXSS問題も指摘されています。）

前のブログで当然直っていると思っていたphp://input問題が修正されていない旨のコメントを頂きました。驚いたことに本当に修正されていません。ですからallow_url_fopen=offすればリモートコードの実行は防げますが、リモートからのコードインジェクションは防げません。

php://inputは生のPOSTデータ扱うときに使えるから、などと言っている場合ではないのですが… php://inputを導入した事により今まで無かった脆弱性を作っているは明らかなのですけどね… 新しい脆弱性が仕様です（しかも簡単に直せる）と言うのは受け入れがたいですね。

Security

ログオン時にインストールできるWMF Hotfix

1月 3, 2006 投稿者 yohgaki

アンオフィシャルなWMF Hotfixがありますが、ダイアログ、メッセージなどが一切出ずにインストールできるHotfixもあるそうです。ログオンスクリプトでインストールする事も可能になります。

私はこのHotfixをインストールしていません。とりあえずMSサイトに記載されていたdllの登録を解除しただけです。
http://blog.ohgaki.net/index.php/yohgaki/2005/12/30/wmfe_afpa_sa_lamfa_a_a_ra

アンオフィシャルなHotfixは、一部で全てのケースに対応できないなどとも言われているようです。
ところでWindows 3.0にもこの脆弱性があるそうです。古い問題だったのですね。

関連エントリ：
http://blog.ohgaki.net/index.php/yohgaki/2006/01/02/spama_ia_fa_la_sa_rwmfa_ra

Security

RFID防止財布の作り方

1月 3, 2006 投稿者 yohgaki

RFIDでトラッキングされる事が気になる方は是非どうぞ。
# これなら缶にカードを入れたほうがまし?!

追記：ブログ移行でリンク先が消えたので補足します。RFIDは強い規定以上の強い電磁波を使えば読み取り距離が数ミリのRFIDでも、10メートル以上離れた場所から読み取りが可能だったりします。RFID情報を読み取ることにより誰が入店したのか？などの情報をどんどん集めることが可能になります。RFID情報と所有者の個人情報を結びつけられると詳細な利用情報を得られます。

こういったRFIDカード情報の収集を防ぐにはRFIDカードに対する余計な電磁波を遮断する必要があります。元々付けていたリンク先にはRFID情報の不正読み取りを防ぐ財布の作り方が記載されていたと思います。

「エネミー・オブ・アメリカ」でジーンハックマンがやっていたように、アルミで出来ているポテトチップスの袋でも代用可能ですが、現在だとAmazonなどで「RFID 保護財布」などをキーワードに検索すると、色々な製品を売っています。

Security

タイムビジネス認定センター

1月 3, 2006 投稿者 yohgaki

やっている事は知っていましたが初めてホームページを見ました。
現時点で2、3社の認定があるようですね。

Security

サニタイズと言わない

1月 2, 2006 投稿者 yohgaki

珍しくサニタイズという考え方自体が間違っているという意見を見ました。

私もサニタイズと言う考え方はNagative Security（禁止事項を定義する考え方）からの発想なので、Positive Security（許可する事項を定義する考え方）でプログラムを作るべきと考えていますし、あちらこちらで言っています。この高木さんのブログのでは、デフォルトのコーディングスタイルではサニタイズを考えなくても良いようにする事、と意見されているだと思います。いちいち意識しなくても良いようなスタイルの方が間違いが少なくなるので良いことだと思います。

# Googleで調べるとNagative/Positive Securityの方がよく利用され
# ていることが分かりますが、個人的にはNagative/Positive Security
# と言っても分かりづらい気がします。Reactive/Proactive Security
# と (受動的/能動的セキュリティ）言った方が分かりやすい気がする
# のでこっちを使っています。

Reactive/Proactiveなセキュリティと考えるとコーディングスタイルの変更によるセキュリティ確保はProactiveなセキュリティ対策なので実践していきたいものです。

ところで、常々感じているのは多くのプログラムで「サニタイズ」という概念のおかげで入力値の確認が疎かになっているのではないでしょうか?セキュアなコードでは入力値が

-期待する形式であるか?
-期待する範囲であるか?

確認することが重要です。期待する形式である、ということは文字の種類等だけではなく、selectやradioフィールドの値であるならプログラムで設定した入力値であるか照合する事も含めてチェックします。selectやradioでなくてもプログラムが設定する値であるなら必ずプログラムkが設定している値であるかも確認自由形式の文字列であれば文字数やエンコーディング、数値であれば最小、最大値の範囲内であるかチェックします。もし、おかしなデータがあれば適切はログを取り、適切なエラー画面を表示します。ライブラリ化していれば別に難しい事でも手間がかかる事ではありません。手製のHTMLフォームクラスではJavaScriptとサーバサイドの両方で自動的にチェックするようになっています。
# JavaScriptでチェックしているのはフォームPOST後に
# 「形式が違います」等とエラーになるのが自分が嫌い
# だからです。

多くのプログラムで「サニタイズしようと考えた結果、セキュリティホールを作ってしまった」のは今までのセキュリティホールを見てみれば明らかです。サニタイズには語源のSanitize -（真実を曲げたりして）無害にする、と定義されている通り間違った使用例が多く見受けられます。よくあるサニタイズコードの悪い所は「ダメな部分を取り除く」だけのコードになっている事が多い点です。これでは攻撃されていても攻撃があった事さえ分かりません。攻撃者は不正な入力値を含むデータを送信してもエラーも無く処理が終了する事で、システムはReactive Securityを使用している事が分かります。ReactiveなセキュリティモデルのシステムはProactiveなセキュリティモデルより脆弱である事が多く（現実的にはReactiveセキュリティモデルのみでセキュリティを確保することは無理）、攻撃者のターゲットとして選ばれる確立も高くなります。

念のために、Reactiveなセキュリティモデルが役立たずか、という事ではありません。Reactiveなセキュリティモデルも非常に有用です。その典型的な例はIPSです。本来セキュリティホールがある場合、IPSで対処するのではなくセキュリティホール自体を修正するべきです。しかし、コードがない製品の脆弱性でベンダーがなかなか対応してくれない場合、アプリケーションの修正とテストに多くに時間が必要な場合も多くあります。こういった場合、IPSが無いとセキュリティを確保できません。最終的にはIPSでチェックしなくても良いようにシステムを変更するべきですがIPSは「つなぎ」に欠かせません。

Sanitizeという概念が混乱（？）を起こすのは入力・出力両方に同じ用語が使われていることも原因の一つではないかと考えています。「不正な入力がないようSanitizeし、….」とか「不正な文字列が無いようSanitizeを行ってからHTMLを出力し、…..」等と入力確認と適切な出力形式への変換を同じ用語で説明しています。同じ用語で2つ以上の事柄を意味すると混乱の元です。この意味でもサニタイズとは言わないようにと言う意見には賛成です。

Javaの場合は適切なタグを利用すれば自動的にHTML出力に適した形式で出力してくれますがPHPにはシステムが提供する関数にはそのような関数がありません。つい最近、webappsec MLでやりとりをしている中でOWASP Guideを書いている人（？）のメールにも書いてあったのですが「どうせPHP6はUTF-8対応で互換性の多くを失うのだから

-eche, print, printf: 自動的にHTML用に出力
-echo_raw, print_raw, printf_raw: ダイレクトに出力

のように変えた方が良い」とありました。最初は「どうかな」と思いましたがこれくらいの変更をしないと安全でないコードを駆逐することは難しいかも知れません。この変更を行えばXSS脆弱性を持つPHPコードが激減することは確かだと思います。

Computer, Security

Mambo, Coppermine, PHPBBが攻撃対象に(2)

12月 30, 2005 #PHP, #脆弱性投稿者 yohgaki

/.Jの投稿で気が付いたのですが前に書いた「Mambo, Coppermine, PHPBBが攻撃対象に」でワームが活動している記載しましたが、日本のサーバでも感染しているらしいです。

http://www.merit.edu/mail.archives/nanog/msg14612.html

ネットワークブロックが記載されています。対象のアプリケーションを使っている方は確認された方がよいと思います。
# XMLRPCの対策をされていない方も直ぐに対策が必要です。

Computer, Security

NSAがメールを盗聴しているか確認する方法

12月 30, 2005 投稿者 yohgaki

NSAがメールを盗聴（メールのみではなくエシュロンでありとあらゆる通信を傍受している）している事は有名ですが、盗聴されているか確認する手法の紹介です。

秘密のURLを使って盗聴を検知する手法です。

フリーメールサービス（Google/Yahoo/Microsoftなど）にアカウントを作成する
米国以外の国のISPアカウントを作成する（日本のアカウントではダメ?かも）
自分だけが知っているURLを作成する
NSAが関心を持ちそうなメール（英語?アラブ語?）を1、2で作成したアカウントでメールのやり取りをする。メールの中には3で作成したURLを含める
NSAらしきコンピュータから3のURLへのアクセスログがあるか確認する

この方法だとNSAが盗聴を実行しているか確認できます。会社のシステム管理者が従業員を監視しているか確認する方法に応用されそうな気がします。

しかし、テロリストは暗号化しないでメールでやり取りしているのでしょうか?案外テキトーに平文で通信しているのでしょうか? 現状では暗号化しているだけで目立つので暗号化したメールの方がテロリストには危険なのかも知れません。

Security

WMF脆弱性に対する攻撃

12月 30, 2005 投稿者 yohgaki

マイクロソフトの以下のサイトでは画像とFAXビューアを(Shimgvw.dll) を登録抹消するよう推奨しています。

http://www.microsoft.com/japan/technet/security/advisory/912840.mspx

登録抹消

1.[スタート] メニューの [ファイル名を指定して実行] に “regsvr32 -u %windir%\system32\shimgvw.dll” （二重引用符は必要ありません）と入力し、次に [OK] をクリックします。

2.ダイアログボックスに、登録を解除するプロセスが正常に完了したことを確認するメッセージが表示されます。[OK] をクリックして、ダイアログボックスを閉じます。

回避策の影響: Windows 画像と Fax ビューアは、ユーザーが Windows 画像と Fax ビューアに関連するイメージの種類へのリンクをクリックしても起動されません。

再登録

この変更を取り消すためには、上のステップに従って Shimgvw.dll を再登録してください。ステップ 1 のテキストを “regsvr32 %windir%\system32\shimgvw.dll” に変更してください (二重引用符は必要ありません)。

Explorerで参照するだけで感染する可能性があるようなので念のためにMS推奨の回避策も実行しておきました。この変更を行うとExplorerで縮小版を表示しなくなります。自動的にアクセスしなくなるのでとりあえずは大丈夫、と言うことなのでしょう。

ところで、この脆弱性を利用した攻撃、私のところにも幾つかメールで来ていました。ClamAVはすり抜けていましたがNorton AntiVirus2006はBloodhound.Exploit.56として検知しました。アンチウィルスソフトをインストールしていてもタイミングが悪く感染してしまった人も多いのではないかと思います。

セキュリティメモにいろいろリンクが載っています。
http://www.st.ryukoku.ac.jp/%7Ekjm/security/memo/2005/12.html#20051230_tuiki
http://www.st.ryukoku.ac.jp/%7Ekjm/security/memo/2005/12.html#20051228_WMF

Security

httprintの新バージョン

12月 25, 2005 投稿者 yohgaki

Webサーバのフィンガープリンティングツールのhttprintの新バージョンがリリースされてるようです。

# [new] Multi-threaded engine. httprint v301 is a complete re-write, featuring a multi-threaded scanner, to process multiple hosts in parallel. This greatly saves scanning time. *multi-threading is not yet supported in the FreeBSD version.

# [new] SSL information gathering. httprint now gathers SSL certificate information, which helps you identify expired SSL certificates, ciphers used, certificate issuer, and other such SSL related details.

# [new] Automatic SSL detection. httprint can detect if a port is SSL enabled or not, and can automatically switch to SSL connections when needed.

パフォーマンスとSSLサポートが向上しています。

ちなみに手元のLinux/Apache2に対して57.23%の確立でApache2であると判定しました。本気で隠そう、とまでは思っていないですが単純なスキャンでは分かりづらいくらいには隠そうとしていてこの結果です。まずまずの検知性能と思います。

OSもそうですが、隠しているつもりでも隠れていない場合も結構あるので気になる方は試してみてはいかがでしょうか?
# OSならnmapが定番のフィンガープリンティングツールです。念の為。

試しに実行してみたhttprintのアクセスログは次の通りです。

192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET / HTTP/1.0” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET / HTTP/1.0” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “OPTIONS * HTTP/1.0” 200 – “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “OPTIONS / HTTP/1.0” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET /antidisestablishmentarianism HTTP/1.0” 404 7556 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “PUT / HTTP/1.0” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “JUNKMETHOD / HTTP/1.0” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET / JUNK/1.0” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “get / http/1.0” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “POST / HTTP/1.0” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET /cgi-bin/ HTTP/1.0” 403 7556 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET /scripts/ HTTP/1.0” 404 7556 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET / HTTP/1.1” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET / HTTP/1.2” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET / HTTP/3.0” 200 15036 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET /.asmx HTTP/1.1” 404 7556 “-” “-”
192.168.100.210 – – [25/Dec/2005:05:43:29 +0900] “GET /../../ HTTP/1.0” 400 226 “-” “-“

Computer, Development, Security

Strict Session管理パッチ

12月 24, 2005 #PHP, #セッション管理, #脆弱性投稿者 yohgaki

Hardedned PHPプロジェクトのStefan EsserさんがPHP SESSIONをより安全に運用するパッチを公開しています。

このパッチはPHPのセッション管理の問題に対応します。PHPのSESSIONモジュールがSession Fixation（セッションIDの固定化）に対して脆弱であることは随分前から広く（？）知られていました。このパッチを適用すればSession Fixation問題も随分改善します。

例えば、PHP SESSIONを利用しているサイトで

http://example.jp/index.php

と言うURLがクッキーを利用したセッション管理行っているとします。セッションデータが初期化されサーバに保存されているか、されていないかに関わらず、ブラウザが送信したクッキーによって指定されたセッションIDがそのまま使われます。このパッチはセッションIDのデータが無ければ、セッションIDを再生成してセッションを開始するよう動作が変わります。（通常のPHPのセッション管理はpermissiveなセッション管理と呼ばれています。パッチ適用後はstrictなセッション管理も選択できるようになります。）クッキーだけを使ったセッション管理では、セッションIDが固定化する問題はあまり深刻な問題ではありませんが、好ましい動作とは言いがたいです。

session.use_only_cookiesがoffの場合、問題は深刻です。

http://example.jp/index.php?PHPSESSID=123456

とすると、セッションデータが無い場合、セッションIDが123456になってしまいます。session.use_cookies=on設定（デフォルト値）でクッキーを利用するセッション管理でも、PHPSESSID=123456をクッキーに設定されます。つまり、デフォルトの状態のPHPのセッション管理はsession.use_only_cookiesがoffである為、普通にSession Fixationに脆弱になってしまいます。一応、サイト外のURLに埋め込まれたセッションIDを受け付けないようにするsession.referer_check設定もあるのですが、REFERERを使っているので十分な対策とはいえません。許可するドメインなどを記載する設定項目なので、当然ですが、デフォルトでは何も設定されていません。何も設定されていない時はREFERERチェックは行われません。

追記：色々書いていますが、要するにデフォルト設定のPHPだとSession Fixationに脆弱である、と言うことです。

より厳格なセッションID管理を行うには、パッチを適用後、

session.use_strict_mode = on

と設定するだけです。

このパッチを適用するとユーザ定義セッションセーブハンドラで以下の2つの関数が利用（定義）できるようになります。

string create_sid()
bool validate_sid($key)

create_sid関数は新しいセッションIDを作成します。
validate_sid関数は$keyが正しいかチェックします。

ところで、デフォルトではsession.use_only_cookiesはoffに設定されています。しかし、普通のサイトはsession.use_only_cookiesはONで運用するべきです。もし、offで運用されている場合、強くONに変更して運用することをお勧めします。先ほども書きましたが、session.use_only_cookies=onであればSession Fixation問題はそれほど重大な問題とは言えません。パッチを適用していない場合でもsession.use_only_cookies=onであればそれほど心配する必要はありません。

# 随分古いInternet ExplorerではXMLHttpRequestで他のサイトにリクエスト
# を送信できたりしました。しかし、今は出来ないのでクッキーを利用した
# セッション管理に対して効果的なSession Fixation攻撃は出来ないと思い
# ます。

Security

狙い撃ちフィッシング – スピアフィッシング

12月 22, 2005 投稿者 yohgaki

特定のターゲットのみ狙い撃ちするスピアフィッシング（スピアーフィッシングとは中銃や銛を使い魚を突く事）前からあるのですが、ITMediaの翻訳記事にあったので。困った物ですよね。見ないとならないようなメールで来ると開かざるを得ないですから。この記事以外にもネットショップ経営者にクレームメールを装ったフィシングも話題になっていました。（これは日本の話）

VMwarePlayer等を使ってWebとメールは仮想ホスト上で実行するくらいの用心が必要になってきてます… ちなみに私はそこまでしてません…

Security

VLAN、PVLANのセキュリティホール

12月 21, 2005 投稿者 yohgaki

VLANにも色々セキュリティホールがあるのですが、これは”802.1q, various PVLAN implementations”でプロトコル設計の問題だそうです。ローカルネットワークのユーザが信頼できない場合は困る方もいるかも。

カテゴリー: Security