2008年03月28日
先日、とある飲み会でこんな話になりました。
そこはITとはあまり関係ない普通の（？）方々が来ていました。
Aさん「知合いの会社が、IT系でもなく小規模なのにサーバを自社で管理しているんですよ」
Aさん「そこの社長さんがそういうのが好きらしくて。」
私「なるほど、ちゃんと管理とかされてるんですかね？」
Aさん「きちんとした管理とかセキュリティ対策とかは全然してないですね。」
私「それはいけませんねぇ」
Aさん「でも、WindowsではなくMacだから、大丈夫みたい。」
Macを使っているから安全という話。
某CMのせいで、まだ意外とあるんですね。
それに関連して今日、面白い記事を見つけたので紹介しておきます。
Win/Mac/Linux侵入コンテストはMacBook Air陥落で終了、所要時間2分[via Engadget jp]
コンテストのルールなどはリンク先を読んでもらうとして、
結果的にはSafariに存在する未公開の脆弱性によって侵入されたそうです。
（iPhoneのjail breakのきっかけとなる脆弱性を見つけた人と同一人物だそうで）
一般的には、「どれが安全？」という答えは「管理など状況による」ですが、
今回はMacの一人負けのようです。
"WindowsとMacとLinuxはどれが安全？"の詳細へ»
2008年03月14日
IEEE1394（FireWire）の仕様上の問題点を突いた、
PoC（Proof of Concept code：実証プログラム）が公開されています。
（公開先はリンクしません。もし見付けても、悪用厳禁ですよ！）
最近のPCにはUSBポートとともにFireWireポートが付いているものが多いですが、
このFireWireを使うことで認証を迂回して管理者権限でログインできたり、
データを盗んだり、不正にプログラムをインストールしたり、ということができてしまいます。
# ちなみに、このPoCは対Windows用で、administrator権限が簡単に取れます。
これは、FireWireのDMA機能に問題があるためであるので、仕様上の問題であり、
対策としてはFireWireを無効にする他ありません。
（ちなみに、私自身詳細仕様を追っていませんが、USBのDMA機能は問題ないとか。）
ちょっと離席する時はスクリーンをロックしましょう、というのは常識ですが、
今すぐFireWireポートをBIOSで無効にしておきましょう。
私のiPodはFireWire用なんですが…（泣）
"FireWireには注意"の詳細へ»
2008年03月05日
前回のつづき。
クラックされたサーバを調査するにはどうするのか、簡単に紹介しましょう。
・LANケーブルを抜くこと
これは被害拡大を抑えるために必要です。ソフトウェアでネットワークを停止させてはいけません。
クラックされた環境内では全てがデタラメだと思うべきです。
・クリーンなバイナリを用意する
クラックされていないクリーンな環境からOSの管理コマンドなどをコピーします。
コピーの際はネットワークは使えませんので、外部メディアへコピーし実行します。
CD-Rなどの読み込み専用メディアだとベストです。
・クリーンなバイナリはスタティックリンクでビルドする
単純に他の環境からコマンドをコピーした場合だと共有ライブラリを使用している物があります。
クラックされた環境ではもちろん共有ライブラリも信用できませんので、
スタティックリンクなバイナリが必要になります。（無ければ自分でビルドするしかありません）
・ルートキット検出ツールを使用する
もちろん、検出ツールもクリーンなバイナリである必要があります。
・ログインユーザ、実行プロセス一覧、ログインヒストリなどを取得する
外部メディアに記録しましょう。ひとまず取得が先で解析は後です。
・メモリダンプやリングバッファ、ディスクイメージを取得する
外部メディアに記録しましょう。HDDであれば丸ごとが好ましいです。
・調査のために実行したコマンド、実行時刻などを逐次詳細に記録する
別途紙媒体などに作業に併せて書くべきです。
証拠保全が目的ですが、調査する人間が証拠隠滅を行っていないことを証明するためには必要です。
状況にも依りますが、立会人なども必要かもしれません。
・取得したデータを閉じた環境で解析する
元のクラックされたサーバはそのままにしましょう（LANは外す）。
解析結果が出るまで、電源を落としても再起動してもいけません。
解析までは流れ作業的に行いますが、解析作業は「エンジニアの感」が全てです。
やはり、こういうのは専門家に任せるべきでしょう。
"それでもサーバがクラックされたら…？"の詳細へ»
2008年03月04日
日本ではとりわけメジャーなRDBMSであるPostgreSQL、
その日本PostgreSQLユーザ会のWebサイトがクラックされたそうです。
まだ詳細はわかりませんが、root権限は奪取されていない様子とのこと。
Webアプリケーションの脆弱性を突かれたのかもしれません。
（しばらくユーザ会のサイトを見ていませんが、そんな凝った作りだったのでしょうか？）
実際にサーバがクラックされたとなると、その対応が大変です。
クラックされたサーバの技術的な調査はもちろん、関係者への通知・注意喚起、
それに伴う対策や現況の公表、信頼回復に向けた何らかのアクションなど、
規模の大小にも依りますが、テクニカルではない作業も数多く発生します。
また、サードパーティ製品の脆弱性だったりする場合にはベンダーや開発元を
巻き込んでの話になりますし、金銭が絡む場合には警察に通報する必要もあるでしょう。
関係者を巻き込んで原因の究明とその対策が急務となるため、
他の作業や業務などに確実に支障をきたしてしまいます。
リスクに対する解決策は「予防」と「事後対応」の2つしかありません。
事後対応の負担の大きさを考えるに、普段から「予防」を講じましょう。
この季節、風邪や花粉にやられるまえにマスクをするといった具合に。
"もしサーバがクラックされたら…"の詳細へ»
