Network

PGM (Pragmatic General Multicast)

ちゃっぴ (tyappi@wankuma.com) — Wed, 11 Jun 2008 13:06:00 GMT

Pragmatic General Multicast (PGM) の脆弱性により、サービス拒否が起こる (950762)

で出てきた PGM これ何なの？ってことでちょっと調査してみる。

へぇ～、multicast で再送とかできるようにする protocol なんだ。

で、KB950762 で置き換えられる "rmcast.sys" を調べてみたら Windows Server 2003 はともかくとして、MSMQ install されていない場合には脆弱性の影響を受けないと書いてある Windows XP でもこの driver いるんですけど。いる場所は下記。

%systemroot%\system32\drivers\

OS	Service Pack	Version
Windows XP	SP2	5.1.2600.2951
Windows XP	SP3	5.1.2600.5512

MSMQ install しないと使われないから問題ないということですかねぇ。。。

[追記]

Windows XP SP2 で検出されたよ！

Domain name syntax

ちゃっぴ (tyappi@wankuma.com) — Sun, 25 May 2008 18:34:00 GMT

ネタ元: URL の hostname 末尾に "." を付けると。。。

Domain name の仕様どうなっているか？ちょっと調査してみる。

とりあえず、今回は URI で使われる仕様が知りたかったので RFC 3986 から。

「3.2.2. Host」の section に下記のように書かれています。

The rightmost domain label of a fully qualified domain name in DNS may be followed by a single "." and should be if it is necessary to distinguish between the complete domain name and some local domain.

FQDN の一番右端の "." は完全 domain と local domain を区別するために付ける。（ちょー意訳）

なお、その前の行で参照しろと書いてある RFC 1034 「3.1. Name space specifications and terminology」にもちゃんと書いてはありますね。

When a user needs to type a domain name, the length of each label is omitted and the labels are separated by dots ("."). Since a complete domain name ends with the root label, this leads to a printed form which ends in a dot.

"." で区切られる label は省略可能で、domain name の最後の "." は完全修飾 domain name (FQDN) を表すと。

ただ、「3.5. Preferred name syntax」では domain name は下記のように定義されています。

<DOMAIN> ::= <SUBDOMAIN> | " "
<SUBDOMAIN> ::= <LABEL> | <SUBDOMAIN> "." <LABEL>
<LABEL> ::= <LETTER> [ [ <LDH-STR> ] <LET-DIG> ]
<LDH-STR> ::= <LET-DIG-HYP> | <LET-DIG-HYP> <LDH-STR>
<LET-DIG-HYP> ::= <LET-DIG> | "-"
<LET-DIG> ::= <LETTER> | <DIGIT>
<LETTER> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case
<DIGIT> ::= any one of the ten digits 0 through 9

最後の "." についてふれられていないですね。できれば、直して欲しいな～。

どちらにしろ、最後の "." を誤って解釈するのは Web server の問題だと思います。仕様違反だなこりゃ。

URL の hostname 末尾に "." を付けると。。。

ちゃっぴ (tyappi@wankuma.com) — Sun, 25 May 2008 15:39:00 GMT

ネタ元: ホスト名末尾にドットを付けるとわんくまトップページに飛ばされる件について

これどうなんでしょうね？なんとなく実装依存のような気が。。。

とはいえ、Internet Explorer と Firefox で検証してみましたが browser 依存ではないみたい。どちらも top page へ飛ばされます。

ただ、Squid (proxy server) かますと変わるんですよね。

これは HTTP request parameters が違っていることが原因だと思われます。

With proxy server
Request URI	http://hcm.wankuma.com./
Request Version	HTTP/1.0
Host	hcm.wankuma.com.

With no proxy server
Request URI	/
Host	hcm.wankuma.com.
Request Version	HTTP/1.1

こんな感じ。

ちなみに http://hcm.wankuma.com/ へ request を送った場合は

Request URI	/
Host	hcm.wankuma.com
Request Version	HTTP/1.1

IIS は host までみて判断している？

DB への接続 user を共用した場合の client-server 構成での問題点

ちゃっぴ (tyappi@wankuma.com) — Sun, 11 May 2008 04:37:00 GMT

随分前の話ですが、SQL injection は Web application に限った話ではない。Client-server systemでも深刻な事態をもたらすといった意見が上がっていましたね。

SQL injection を防ぐもうひとつの方法で簡単に説明しましたが、 SQL injection が深刻な事態をもたらす根本的原因は、扱う data に十分な access control がなされていないことにあります。DB への接続 user を共用していれば、その user ですべての data を扱うことができるので、当然 SQL injection 攻撃を受けると大問題ですね。

でも、client-server system では構成によりもっと問題がある場合があるんです。では、ちょっと client-server system について考えてみましょう。

Client-server 構成は基本的に intranet で利用されているので network 構成はこんな感じが多いと思います。

もしくは、Application server もなく client から直接 DB 叩いているかもしれません。

さて、今回は DB への接続 user を共用した場合の話です。DB に接続する場合の認証情報はどこに保存されているか考えてみましょう。

Application server を利用している場合には application server に、application server を利用していない場合には client に保存されていると思います。

Application server を利用している場合では、Web application の場合と同様に application server に対する攻撃を封じてやるよう対策を行えばいいです。Web application を host する secure な network 構成で書いたような直接 DB server へ全く access できないような network 構成にして、cient 側には必要な service しか提供できないように firewall を構成する。もちろん application は全く脆弱性が存在しないように作成する必要があります。

ところが、application server が無い状態ではどうなるでしょうか？

認証情報は client に保存されます。こちらの場合、基本的に DB 接続用の認証情報が漏えいすると考えたほうがよいでしょう。Application に暗号化して埋め込んでもその暗号化 logic まで client に存在するため、一定の skill を持っている人であれば解析されます。

このような構成は基本的に取るべきではないでしょう。どうしても application server を利用できない場合には、共通の user など用意せず DBMS 側の access control を利用すべきです。この構成では must といっても問題ないでしょう。

なお、application server を利用しない場合でも、DB へ access する application を通常利用している OS account とは別のaccount で起動した process で扱うことにより一応保護することはできます。原理としては Windows Service にみる別の資格情報で process を起動する安全な方法な感じです。ただ、この方法をとったとしても application server を利用する場合ほどの security を確保することはできません。また、user の account が "BUILTIN\Administrators" なんかに所属している場合には当然全く意味をなしません。

XP で IPv6

ちゃっぴ (tyappi@wankuma.com) — Mon, 01 Oct 2007 01:03:00 GMT

うちの XP 環境 (x31) では IPv6 使えるようにすると起動後しばらくやたら重い。

別の端末 (X60) では OK なものもあるのでどうやら環境依存ぽい。

となると NIC の違い? Intel Pro100 VE って対応してるって書いてあるけどなぁ。。。

Web application を host する secure な network 構成での攻撃方法を考える

ちゃっぴ (tyappi@wankuma.com) — Mon, 10 Sep 2007 00:11:00 GMT

Web application を host する secure な network 構成の続き

前回では secure な基盤を構築することを説明しましたが、その環境でももちろん攻撃方法は存在します。全部説明するのは厳しいので、ここでは Web, AP, DB に実装された custom application にはまったく脆弱性が存在しない前提で話を進めます。前回も登場した下記 network (図1) を題材にしましょうか。

図1 Web, AP, DB Management の network をそれぞれ分離した sample

通常重要な data は DB に格納されるため、今回の攻撃の最終目標は DB から情報を引き出すこととします。

さて、client から DB の情報を引き出すためにはどうしたらよいでしょうか？

Client が直接通信できるのは、client - Web segment に存在する router, firewall, Web server のみです。したがって、攻撃をする場合必然的に router, firewall, Web server へまず攻撃を行うことになります。

さて、この router, firewall, Web server に設定上の不備があった場合どうなるでしょうか？

Web server の設定がまずかった場合なんかは特に悲惨です。乗っ取った Web server を踏み台にして AP server へ攻撃を仕掛けます。また、構成によっては Management segment を通じて Web server から直接攻撃を仕掛けるでしょう。また、server は network 機器に比べてより多くの機能を持っているため、network 機器を乗っ取るよりも簡単に攻撃を仕掛けることが可能というのももちろんありますね。

Network 機器の場合でも、それを乗っ取ることにより攻撃は可能ですね。Network 機器に搭載されている telnet や SSH 等を利用可能な状況であれば攻撃は server 同様非常に容易です。
# こんな状態あったら、アホ過ぎて目も当てられん。。。

なので、Web segment に存在する機器は細心の注意を払って、絶対に脆弱とならないように設定を行わなければなりません。

では、設定がまったく問題なく構成されていれば安全でしょうか？

もちろん違いますね。自分のところで作成した application に脆弱性が無くても、OS, middleware 等の脆弱性は頻繁に発見されています。したがって、脆弱性情報を日頃から check し、適宜対策を行うことが必須です。

また、OS 自体の security 機能を有効活用することもまた重要です。一般的な server OS では、user 毎に異なる権限を与えることが出来ます。Client から直接攻撃の受ける可能性のある service をより低い権限で実行させることにより、その service 自体に脆弱性が存在しても影響を受けにくくすることが出来ます。
# これに関してはまた別の機会に解説します。

Web application を host する secure な network 構成

ちゃっぴ (tyappi@wankuma.com) — Sun, 09 Sep 2007 19:43:00 GMT

Web application を host する環境を構築する場合、Web, AP, DB をそれぞれ別の network として設計する方法が有名ですね。

図1 Web, AP, DB の network をそれぞれ分離した sample

Web server および AP server からは network の足が2つ伸びていますが、これは network interface が複数存在し、それぞれ別の network につながっていることを示します。

Network をつないでいるのは router ではなく server なので server を router として構成 (つまり IP routing 有効) していない限り、異なる network へ packet を転送しないためその server を踏み台にでもしない限り別の network へ接続することができません。たとえば、図1 の場合 Web server から DB server へ接続することはできませんし、当然 clinet から DB server へ接続することもできません。

図1 では Client segment と Web segment との間に router のみが存在する構成になっていますが、ここは Internet や WAN だったりいろいろな構成があるでしょう。また、firewall の後ろに load balancer がいることも多いですね。ただ、今回説明する部分に関してはこの部分がどうなっていようと関係ないので、適宜置き換えてください。

また、図1 の構成では監視はどうするのと思われる方がいるかもしれません。が、実際に構築する場合には、server および各種 network 機器にもうひとつ network interface を用意して、management 専用の network を切ります。

図2 Web, AP, DB Management の network をそれぞれ分離した sample

Web server, AP server は 3つ、DB server は 2つ netwrok interface が必要になります。すでに説明したように、server を router として構成していないため server が境界となっている部分を通り越しての通信は出来ません。

Web server と client 間の router は access-list とかを使って、Client - Management 間の通信ができないように制限します。また、server 側での各 interface に対しても各機器で必要とされる最低限の service のみ提供するように制限を掛けます。これで、network 的には非常に secure な環境が出来上がります。

以降の構成図ではわかりにくくなるため、Management segment は省略します。

図1 の環境は J2EE とかを動かす環境では一般的ですね。ASP.NET application を動作させる場合には、図3 のように Web と AP を同じ server で稼動させることが多いでしょうか。

図3 Web, DB の network をそれぞれ分離した sample

AP の一層が無くなったことにより若干 security が弱くなっていると思うかも知れませんが、大差ありません。この状況でも各機器がちゃんと secure に構成されていれば十分な環境です。

絶対に使わないだろう component

ちゃっぴ (tyappi@wankuma.com) — Tue, 20 Mar 2007 19:06:00 GMT

Windows component のなかにひとつ、絶対に使わないだろうものが。

それは、「簡易 TCP/IP サービス」

簡易 TCP/IP サービスをインストールする

上記に書かれていますけど、これを install すると下記 protocol が有効になります。

たぶん見たこと無いのがかなり並んでいると思いますが、そのとおり普通は利用しないものです。

それどころか、これを install することによって、Fraggle や CharGen/Echo 等の DoS 攻撃される危険性があります。

[参考] 昔の Cisco の router は default で有効になっていたのでつぶす必要がありました。

{Ctrl} + [c] でおかしくなる？

ちゃっぴ (tyappi@wankuma.com) — Fri, 23 Feb 2007 23:22:00 GMT

某 network 機器の話。

Web の UI が異常に遅くなるという現象が発生するんで、support になげたところ、その結果。

1. SSL での利用はしないでください。

2. Terminal で接続したとき、{Ctrl} + [c] を送らないでください。

なんじゃそれ。。。