Security

Adobe Reader X on Windows 7 disabled UAC

ちゃっぴ (tyappi@wankuma.com) — Sun, 21 Nov 2010 21:35:00 GMT

Adobe Reader X, Restricting SID, Adobe Reader X on Windows XP の続き。

Windows 7 で UAC を無効化した場合どのように access token が filter されるか確認してみました。

まずは親の方。

Windows XP 同様全く filter がかかっていません。この process に脆弱性が存在した場合、死亡確定です。

次に子の方。

Windows XP 同様 Restricted Token を利用した制限が加えられています。

結論としては、Windows Vista 以降で UAC を無効化している場合、Windows XP と同様の security level しか確保できないことになります。

Adobe Reader X on Windows XP

ちゃっぴ (tyappi@wankuma.com) — Sun, 21 Nov 2010 18:53:00 GMT

Adobe Reader X, Restricting SID の続き。

Windows XP 上での Adobe Reader X はどのように access token を制限しているか実際に確認してみましょう。

Process tree の構造は Windows 7 と変わりませんね。では access token はどうなっているか？まずは親の方。

Administrators に所属する user での結果ですが、全く filter されていません。つまり、この process の実行 account が有する権利が制限なく利用可能です。この process で動く code に脆弱性が存在した場合、死亡決定ですね。

次に子 process。

かなり厳しく filter されていますね。Filter された token がどのように機能するかについては Restricting SID を参照していただくとして、結論としては下表のような token になります。

SIDｓ	Enable
Logon SID (S-1-5-5-0-71174)	Disabled
Everyone	Enabled
Local	Disabled
NT AUTHORITY\Authenticated Users	Disabled
NT AUTHORITY\REMOTE INTERACTIVE LOGON	Disabled
VIRTUALXP-17110\Debugger Users	Disabled
VIRTUALXP-17110\なし	Disabled
BUILTIN\Users	Enabled
NT AUTHORITY\INTERACTIVE	Disabled
BUILTIN\Administrators	Disabled
VIRTUALXP-17110\XPMUser	Disabled

要するに Everyone と BUILTIN\Users のみが有効な SID ということですね。

つまり、対象 rewouces の ACL で Everyone および BUILTIN\Users に対する許可の権利が与えられていないと access できないということです。

Windows XP の既定の ACL で Everyone および BUILTIN\Users が access 可能な resources の概要を下記に示します。

Type	Path	Rights
File/Folder	Drive root C:\ 等	Read & Create New
File/Folder	%SystemRoot%	Read only
File/Folder	%ProgramFiles%	Read only
File/Folder	%UserProfile%	None
File/Folder	All Users Profile Ｃ:\Documents and Settings\All Users\	Read only
File/Folder	All Users Application Data Ｃ:\Documents and Settings\All Users\Application Data	Read & Create new
File/Folder	共有ドキュメントＣ:\Documents and Settings\All Users\Documents	Read & Create new
Registry	HKCR	Read only
Registry	HKLM	Read only
Registry	HKCU	Read only

%UserProfile% への権限は制限されているものの drive root に独自に作成した folder や共有ドキュメントに置いた file 等は保護されないことになります。また、ACL を変更して Everyone や BUILTIN\Users を付け加えるなんてこともよく行われており、当然その resources も保護されません。

これに対し、Windows Vista 以降では Low IL を利用しており、これは resources SACL に Low mandatory level が存在するものしか access できません。

参考) Low integrity level、Integrity level を ACE として folder へ設定可能

Low mandatory level が設定されている場所は %UserProile%\AppData\LocalLow 等の非常に限定的な場所にのみ付与されているため、Windows XP で Adobe Reader が利用している Restricted Token とは格段に制限が厳しいです。

Windows XP でも Restricted Token を利用することにより、かなりの security 向上が見込めますが、Windows Vista 以降では IL のおかげで遥かに高い保護が行えます。どうしようもない理由で Windows XP を使い続けなければならないならともかく、さっさと Windows Vista 以降の OS に乗り換えましょう。それから、UAC は絶対に無効化しない。これ重要。

Restricting SID

ちゃっぴ (tyappi@wankuma.com) — Sun, 21 Nov 2010 17:26:00 GMT

Adobe Reader X に関して NyaRuRu さんから突っ込みをいただいたので、Windows XP 上での Adobe Reader X について書こうと思ったのですが、その前に restrictied token について説明する必要があるため先に説明します。

CreateRestrictedToken 関数で作成する Restricted Token (制限トークン) での SID 制限の方法には deny-only SID (SID の無効化) と restricting SID (制限付き SID) の 2 種類が存在します。

まずは簡単な deny-only SID の方から。Deny-only SID とは、対象の SID を無効化します。無効化なので ACL に該当する SID が存在したとしても、無かったものとして扱われます。例えば、管理者権限を無効化するために BUILTIN\Administrators group SID を消しこむといった用途で使われますね。UAC の medium IL での管理者権限削除はこれを利用することによって実現されています。CreateRestrictedToken 関数では第 3 引数 DisableSidCount、第 4 引数 SidToDisable に対応します。

次にちょっとわかりにくい restricting SID の方。こちらはなんなのかというと Restrited と mark された SID のみが利用可能であるということです。

上は Windows XP mode でメモ帳 (notepad.exe) を「別のユーザーとして実行」→「許可されていないプログラムの動作からコンピュータとデータを保護する」を有効化して「現在のユーザー」で起動した aceess token です。

BUILTIN\Administrators が Deny されており、ほとんどの SIDs に Restricted flag がついているのが確認できます。それから NT AUTHORITY\RESTRICTED という見慣れない SID が存在しますね。

この状況では下記のように access check が行われます。

ACL に BUILTIN\Administrators が含まれていても deny-only であるため無視される
restricting SIDs 以外の SIDs を確認し、ACL に含まれる SID に対応した許可の ACE が含まれる場合のみ次に進む
NT AUTHORITY\RESTRICTED SID が付与されている Restricted Token であるため、restricting SIDs を照合して restricting SIDs が存在するもののみ access が許可される

How Access Tokens Work

ここで注意してほしいのは、この process の実行 user である VIRTUALXP-17110\XPMUser の restircting SID が含まれていないことです。つまり、VIRTUALXP-17110\XPMUser の権限が無効化されているということになります。

わかり易く整理すると下表のような感じです。

SIDｓ	Enable
Logon SID (S-1-5-5-0-71174)	Enabled
Everyone	Enabled
Local	Enabled
NT AUTHORITY\Authenticated Users	Enabled
NT AUTHORITY\REMOTE INTERACTIVE LOGON	Enabled
VIRTUALXP-17110\Debugger Users	Enabled
VIRTUALXP-17110\なし	Enabled
BUILTIN\Users	Enabled
NT AUTHORITY\INTERACTIVE	Enabled
BUILTIN\Administrators	Disabled
VIRTUALXP-17110\XPMUser	Disabled

実行 user である VIRTUALXP-17110\XPMUser の SID が利用できないのがミソですね。この影響により、この SID で許可されている %UserProfile% や HKCU 配下のすべての権限が消滅します。

なお、restricting SID は CreateRestrictedToken 関数の第 7 引数 RestrictedSidCount、第 8 引数 SidsToRestrict を利用して作成します。

"RunAs" basic (and intermediate) topics
Running restricted -- What does the "protect my computer" option mean?

Adobe Reader X

ちゃっぴ (tyappi@wankuma.com) — Sat, 20 Nov 2010 14:47:00 GMT

Adobe Reader の新しい version が公開されたようです。

Adobe Reader X

新しく追加された機能としては下記。

様々な PDF ファイルを閲覧
進化した注釈ツール
高度なセキュリティ
オンラインサービス

個人的な目玉は sandbox 実行ですね。というこで早速確認してみました。検証環境は Windows 7 Ulimate x64 Edition です。

Adobe Reader の process AcroRd32.exe が 2 つ立ち上がっているのが確認できます。まず親の access token を確認してみましょう。

Medium Mandatory Level です。次は子の access token。

Low Mandatory Level を使っています。

万年 zero day 脆弱性が出回っている Adobe Reader ですが、この Windows の IL (Integrity Level) を利用した sandbox によって脆弱性が存在しても深刻な状況になることが大幅に減るでしょうね。

ただ、Windows Vista 以前より前では IL なんて無いですからこの sandbox による恩恵は受けられないでしょうね。ちゃんと調査していないですが、仮に Google Chrome のようなしくみを利用しても、ザルなので。Windows Vista 以降の OS 使いましょ。あと UAC 無効化したら恩恵受けられないので絶対にやってはダメです！！！

この件に関しては新たに Restricting SID, Adobe Reader X on Windows XP, Adobe Reader X on Windows 7 disabled UAC といった entry を書きましたのでそちらを参照願います。

なお、一時期 Adobe Reader の脆弱性と言えば PDF に含まれる JavaScript からの攻撃でした。そのため、JavaScript を無効化することが有効な対策であったわけですが、この sandbox 導入により今後はそこまで求められないことが増えてくるんじゃないかと思います。

JavaScript の無効化手順はいつもと同じです。ただし、設定を保存している registry key に vestion が含まれていて、upgrade の際にその設定が引き継がれないので再度同じ操作を行う必要があります。

Adobe Reader 9.x の Java Script を無効化する方法

Adobe Reader X での registry key は下記です。

HKCU\Software\Adobe\Acrobat Reader\10.0\JSPrefs

ASP.NET 情報漏えいの脆弱性

ちゃっぴ (tyappi@wankuma.com) — Mon, 20 Sep 2010 11:55:00 GMT

ASP.NET に情報漏えいの脆弱性が発見されました。

Microsoft Security Advisory (2416728) Vulnerability in ASP.NET Could Allow Information Disclosure

この脆弱性を突かれると ViewState の内容や、Web 公開 directory におかれた source code 等が外部より取得可能である可能性があります。

回避策は Web.config の system.web/customErrors による error page の置き換えです。具体的な方法は Microsoft Security Advisory (2416728) の workarounds を参考にしてください。おそらく規定の error page で利用されている assembly に脆弱性があるのでしょう。

一般的に Internet 等を使って不特定多数に Web appplication を公開する場合、error page を置き換えることが推奨されていますので既に対策済みであることも多いかと思います。もし、対策済みでない場合には、それほど手間がかかる作業でもないため早急に対策を行いましょう。

安全でないライブラリのロードにより、リモートでコードが実行される

ちゃっぴ (tyappi@wankuma.com) — Wed, 25 Aug 2010 05:28:00 GMT

安全でないライブラリのロードにより、リモートでコードが実行されるという seurity advisory が出ています。まあ、ここ読んでいるような人にとってはすでに知っていることだと思いますが。

ちょっと興味があったので、いろいろ情報あさっていましたが、正確なところはわかりませんがどうやら下記のようなことじゃないかと。

LoadLibrary や LoadLibraryEx 等を利用して DLL を動的に load する場合、絶対 path を指定しないと Dynamic-Link Library Search Order の順序に従って DLL が検索されます。

この検索先の中に current directory が含まれるのがミソで、load する予定の DLL と名前が完全に一致する DLL が存在するとそいつが読み込まれてしまう。

直接呼ばれる関数に攻撃 code を仕込んでおけばいいわけですが、Win32 DLL には DllMain という DLL を load されるときに自動的に実行される entry point があるので、こいつを使えばもっとお手軽。

ここまでは全然新しくない話なんですが、今回出てきたのは current directory が remote (SMB や WebDav) 上だった場合、remote に file を配置しておくだけで攻撃が可能ということ。

個人的には application が file を開くときに current directory を変更して開くなんて考えずらいと思っていましたが、この攻撃が可能な application は 40 以上存在するとのことなので。

Update: 40 Windows apps contain critical bug, says researcher

この問題への対応としては、Dynamic-Link Library Security にまとめられています。

LoadLibrary, LoadLibraryEx, CreateProcess, ShellExecute を呼び出すときは可能な限り fully qualified path を利用する。
Dynamic-Link Library Redirection, Manifests を利用し正しい DLL を呼び出すことを強制する。
Registry HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode を変更し DLL の検索順序を変更する。
DLL を呼び出す前に SetDllDirectory に "" を指定して current directory の path を除去する。 (Multi thread, process 間での競合注意)
Safe process search mode が有効になっていないときは SearchPath を利用しない。SearchPath をどうしても利用する必要があるときは先に SetSearchPathMode に BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE を指定して呼び出した後に利用する。Current directory は最後に回されるが除去はされないので注意が必要。
LoadLibrary?が検索する DLL の検索順序は OS によって異なるので、推測だけで行わない。ちゃんと OS version 確認しましょう。

基本的な対応としては application code の修正です。ということで、DLL を dynamic load している application の開発者はについて既存の code に問題が無いかご確認ください。

なお、DLL の検索対象から current directory を除去する方法については WebDav や SMB のみ除去するといった設定が可能になる patch が提供されています。

DLL 検索パスアルゴリズムを制御する新しい CWDIllegalInDllSearch レジストリエントリについて

WebDav のみ SMB のみ不可といった制限も可能なので patch を適用した上で設定を変更しておいたほうがよいでしょう。WebDav, SMB 不可程度であればほぼ影響は無いでしょうから。

Internet Explorer で TLS 1.2 を使用してみる

ちゃっぴ (tyappi@wankuma.com) — Sun, 01 Aug 2010 11:50:00 GMT

Web browser の TLS cipher suites を比較してみる
 Windows の TLS chipher suites の順序を変更する方法

上記の続き。

Windows 7 以降の OS では TLS 1.2 が利用できるようになりました。

TLS v1.2 の概要

Internet Explorer の [インターネットオプション] の [詳細設定] - [セキュリティ] - [TLS 1.2 の使用] がその設定です。既定では無効になっています。

ただ、上記で [TLS 1.2 の使用] を有効化しても、それだけでは TLS 1.2 は利用されません。TLS 1.2 を利用するためには [システム暗号化: 暗号化、ハッシュ、署名のための FIPS 140 準拠暗号化アルゴリズムを使う] policy を有効化する必要があります。こちらも既定では無効です。

[グループポリシーエディター] で [Windows の設定] - [セキュリティの設定] - [ローカルポリシー] - [セキュリティオプション] で [システム暗号化: 暗号化、ハッシュ、署名のための FIPS 140 準拠暗号化アルゴリズムを使う] を有効化します。

有効化したら gpupdate.exe を利用し policy を即時適用します。

>gpupdate.exe /force
ポリシーを最新の情報に更新しています...

ユーザー ポリシーの更新が正常に完了しました。
コンピューター ポリシーの更新が正常に完了しました。

これで適用されました。IE の設定も含めて再起動は一切必要ありません。

以上の設定を施すと Client Hello で送信される Version が TLS 1.2 に cipher suites は下記のように変わります。

Internet Explorer 8 (TLS 1.2, TLS 1.1, TLS 1.0, SSL 3.0 有効）
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

FIPS 140 準拠 policy を有効化したことにより RC4 が使えなくなっていますね。この状況では SSL で接続できない Web site が出てくるかもしれないですね。また、FIPS 140 準拠 policy は SSL / TLS に限らず、Windows CNG (Crypto Next Generatin) API の動作に影響するため、適用にあたっては最新の注意が必要になるでしょう。

同じ API を利用している Chrome, Opera は TLS 1.2 を有効化する設定項目が見当たらないため、Version は常に TLS 1.0 を送信し、TLS 1.1 および TLS 1.2 で追加された cipher suites は利用できません。ただ、FIPS 140 準拠 policy の影響は受けるので RC4 が利用できなくなります。

Windows の TLS chipher suites の順序を変更する方法

ちゃっぴ (tyappi@wankuma.com) — Sat, 31 Jul 2010 17:56:00 GMT

Web browser の TLS cipher suites を比較してみるのつづき。

Internet Explorer で AES 256 bit を使いたいのに順番が低いため使えね～。とお怒りの方ももしかするといらっしゃるかも知れませんが、これは Windows Vista 以降であれば group policy で変更できます。

[ファイル名を指定して実行] で「gpedit.msc」と入力。

[コンピューターの構成] - [管理用テンプレート] - [SSL 構成設定] と node を展開し、[SSL 暗号の順位] を double click。

Policy を有効化し、"," comma で区切ったcipher suites list を入力する。途中 space を含めることができないので注意。

普通の group policy であれば、gpupdate.exe /force で反映がかかるのですが、試してみた感じでは Windows を再起動するまで設定が反映されませんでした。

なお、この group policy を変更すると Chrome, Safari の cipher suites も IE と全く同じになります。Chrome, Opera の TLS (SSL) は IE と同じ API 使っているのは間違いないですね。Firefox や Opera は影響を受けません。こちらは独自のものを利用している模様。

<参考>

Web browser の TLS cipher suites を比較してみる

ちゃっぴ (tyappi@wankuma.com) — Sat, 31 Jul 2010 17:49:00 GMT

TLS (SSL) は Client Hello で client が利用可能な cipher suites (公開鍵暗号、共通鍵暗号、hash algorithm) を提示し、Server Hello で実際に利用する cipher suite を決定します。

Client Hello で送信される cipher suites は Web browser によりまちまちです。各 Web browser の default 設定で送信される cipher suites の調査結果は下記です。Client OS は Windows 7 です。

Internet Explorer 8
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5

Firefox 3.6.8
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_SEED_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

Opera 10.60
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_RSA_WITH_AES_128_CBC_SHA256
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

Chrome と Safari は Internet Explorer 8 と全く一緒です。

Internet Explorer は AES 128 bit を使いたがりますが、Firefox は AES 128 bit よりも RC4 128 bit を使いたがります。Firefox は CAMELLIA や SEED にも対応していますね。

Cipher suites は RFC で管理されているようなんですが、その documents が散らばっているので下記にまとめておきます。

Cipher suites 関連の RFC
RFC No.	Title
2246	The TLS Protocol Version 1.0.
4346	The Transport Layer Security (TLS) Protocol Version 1.1.
5246	The Transport Layer Security (TLS) Protocol Version 1.2.
2712	Addition of Kerberos Cipher Suites to Transport Layer Security (TLS).
3268	Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS).
4132	Addition of Camellia Cipher Suites to Transport Layer Security (TLS).
4162	Addition of SEED Cipher Suites to Transport Layer Security (TLS).
4279	Pre-Shared Key Ciphersuites for Transport Layer Security (TLS).
4492	Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS).
4785	Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS).
5288	AES Galois Counter Mode (GCM) Cipher Suites for TLS.
5289	TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM).
5469	DES and IDEA Cipher Suites for Transport Layer Security (TLS).
5487	Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode.
5489	ECDHE_PSK Cipher Suites for Transport Layer Security (TLS).
5932	Camellia Cipher Suites for TLS.

Firewall profile

ちゃっぴ (tyappi@wankuma.com) — Sun, 25 Jul 2010 23:24:00 GMT

Windows Vista 以降の Windows Firewall では firewall を profile 毎に個別管理できるようになりました。

セキュリティが強化された Windows ファイアウォールファーストステップガイド

新しい network に接続したときに下記のような dialog が出てくるのでおなじみですよね。

自宅、もしくは企業内であれば必ず「パブリックネットワーク」を選択してください。また、「パブリックネットワーク」の firewall は絶対に緩めないでください。

実は昨日の勉強会で無線 LAN に接続している端末の firewall の状態を確認するため、ICMP と SMB で接続を試してみました。無線 LAN に接続されている host が 39 台あり、内 9 台は ICMP が通り、8 台は SMB で接続が可能でした。

まあ、勉強会の無線 LAN で攻撃される可能性はほぼ無いと思うので問題は無いと思いますが、気になるのは別の network に接続したときの firewall 設定です。

最近は EMOBILE や UQ WiMAX または公衆無線 LAN とかいろいろ利用している人が多いでしょう。このような network に接続している場合、直接 global IP address が割り当てられる) 場合が多いです。

>ipconfig.exe /all 
PPP アダプター EMOBILE:
 
   接続固有の DNS サフィックス . . . :
   説明. . . . . . . . . . . . . . . : EMOBILE
   物理アドレス. . . . . . . . . . . :
   DHCP 有効 . . . . . . . . . . . . : いいえ
   自動構成有効. . . . . . . . . . . : はい
   IPv4 アドレス . . . . . . . . . . : 114.48.188.112(優先)
   サブネット マスク . . . . . . . . : 255.255.255.255
   デフォルト ゲートウェイ . . . . . : 0.0.0.0
   DNS サーバー. . . . . . . . . . . : 60.254.193.158
                                       117.55.64.152
   プライマリ WINS サーバー. . . . . : 10.11.12.13
   セカンダリ WINS サーバー. . . . . : 10.11.12.14
   NetBIOS over TCP/IP . . . . . . . : 無効

>ipconfig.exe /all
イーサネット アダプター WIMAX0:

  接続固有の DNS サフィックス . . . : uqc.ne.jp
  説明. . . . . . . . . . . . . . . : Intel(R) Centrino(R) WiMAX 6250
  物理アドレス. . . . . . . . . . . : **-**-**-**-**-**
  DHCP 有効 . . . . . . . . . . . . : はい
  自動構成有効. . . . . . . . . . . : はい
  IPv4 アドレス . . . . . . . . . . : 119.107.210.237(優先)
  サブネット マスク . . . . . . . . : 255.255.255.255
  リース取得. . . . . . . . . . . . : 2010年7月25日 22:46:06
  リースの有効期限. . . . . . . . . : 2010年7月26日 22:46:06
  デフォルト ゲートウェイ . . . . . : 119.107.200.135
  DHCP サーバー . . . . . . . . . . : 119.107.200.135
  DNS サーバー. . . . . . . . . . . : 119.107.200.151
                                      119.107.200.23
  NetBIOS over TCP/IP . . . . . . . : 有効

Subnet mask は 255.255.255.255 になっていますが、global IP が割り当てられていて途中で filtering されていないため、listen しているすべての port が攻撃にさらされていますね。

以前 EMOBILE の network で脆弱性を突く network packet を検知できるような firewall を入れてしばらく monitor してみましたが、ほんとアホのように攻撃がきていました。脆弱性が存在したら間違いなくいちころです。めちゃくちゃ危険ですよ！

とはいえ、自宅や企業内で利用する場合には firewall に許可構成を入れないと問題がある場合も多いでしょう。ですから mobile PC では profiling機能を持つ firewall を導入することは必須です。

すでに書きましたが Windows Vista 以降の OS では標準で profile 機能を持つ firewall を持っています。Windows XP 以前にはありません。Third pary 製の fireawall に関してはここ数年調査していませんが、こちらも profiling 機能を持っていないのであれば、mobile PC でそれのみに頼るのは大問題ですね。

思い当たる方はぜひこの機会に firewall の構成を確認してください。非常に危険ですよ！