久しぶりになかのひと(ベータ版)を見てみた。
そしたら結構いろんなトコロから来て貰ってるようで、ありがたい限りでおます。
(上は北海道から下は京都まで)
んで、ついでにアクセス解析見てみたら、以前より平均順位が上がってた。
更新サボってた出来てなかったのに・・・（；ﾟﾛﾟ）
なんかホント、いろいろ申し訳ない。
(といいつつも更新頻度はたぶん改善しないと思う)
あと、検索ワード見てると結構ナレッジを求めて来る人が多いことに気がついた。
しかも「コレなら答えられそうなのに、記事としては書いてない（･ω･`）」っていうのがわりとある。
コメント欄ででも質問してくれれば、できる限り答えるので。
あ、それと。
冷やし中華自社研修はじめました。
第1回目はそこそこの評判だった、・・・らいいなと思う。
なんせ自主性第一でやってるから、結果がどうなるかもワカラン。
んで、研修では講義もやってるんだけど、その内容をこのブログでも公開しようかなと。
読んでくれる人がいるかも分からんし、何の役に立つかはもっと分からんけど。
というワケで、お楽しみに。
なんかね、知ってる人に
「あ、そういやさぁ。はやくセキュリティ監査のヤツの続き読みたいんだけど」
的なことを言われたのね。
なんでおれのぶろぐしってるのorz
（すいません。バレてないつもりでした。思い上がりでした。）
まぁ別にバレて困るようなこと書いてないんだけど。
その人いわく
「別に周りには言ってないけど。あ、言ってほしい？」
らしい。
言ってほしいワケあるか（#・ω・）凸
まぁ別にバレて（以下略
でもネットって案外狭いなぁと思わされた一件だった。
まぁあんだけやったことガンガン書いてたらバレもするか。
しかし、バレて困らんとはいえ知人が見てると思うとちと恥ずかしい気もする。
なかのひと(ベータ版)を試験導入してみた。
なかのひと.jp
これは自分のWebサイトとかブログにどこの法人の人が来ているかを解析し、地図とタグクラウドで表示してくれるサービスだ。
（このブログの左下に出てる地図がソレ）
技術的には目新しいことはしていないんだけど、その発想は新しい。
このブログでも、ここ数日で首都圏のIT企業からのアクセスをいくらか確認できた。
（ありがたい話ですよ、いやホント）
ちなみにアメブロでの導入手順はというと。
まず、なかのひと.jpでユーザ登録をする。
次に、[サイドバーの設定] に移動し、[プラグインの追加] をクリックする。
そして、[フリープラグイン] を選択し、解析用HTMLタグを貼り付けたら [設定] をクリックする。
（フリープラグインは1つだけしか使えないっぽい）
最後に、[サイドバーの配置] を決めて、[保存] をクリックする。
これでサイドバーとして地図が表示されているハズ。
これが結構ワクワクして楽しいし、今後機能拡張もあるようなのでオススメかも。
今日は Vista + IE7 で話題の保護モードについて。
Vistaでは整合性機構というものが実装された。
一時期話題になった（？）「いちいち確認のプロンプトうぜー」のアレもそうだな。
これは、プロセスの整合性レベルを高・中・低に分け、そのプロセスより整合性レベルの高いファイル・レジストリへのアクセスを制限する機構だ。
管理者の確認が必要なプロセスは「高」で、一般ユーザの確認が必要なプロセスは「中」で、確認が不要なプロセスは「低」で、それぞれ実行される。
(ちなみに「低」はAnonymous LogonではなくEveryoneの権限)
で、保護モードはIE7を整合性レベル「低」で実行する機能だ。
これによってIEを利用した悪意のあるコードの実行などを（ほぼ）防ぐことができる。
しかし、ここで問題になるのが正規の手順としてIEでコードの実行やファイル・レジストリへのアクセスを行ないたい場合だ。
これを実現する為に、整合性レベル「中」で動作するIEUser.exeや「高」で動作するIEInstal.exeが用意されている。
これらはブローカープロセスと定義され、レベルの昇格には確認画面による入力が必須となっている。
え？どうやって使うのかって？
知らんよ、そんなこと（･ω･`）
オレ、アプリは本当にムリだから。
（ゴメンよ、一番知りたいこと書いてなくて。）
でも、「信頼済みのサイト」に登録することでもこの問題は回避できるらしい。
他にも、IE7のアイコンを右クリックして「管理者権限で実行」したり、「保護モードを無効」に設定すれば暫定的には対処できる。
（これはセキュリティ上問題があるけど）
とりあえず、詳しくは下記URLを参照。
保護モードの Internet Explorer の理解と機能 (Micorosft)
http://www.microsoft.com/japan/msdn/ie/general/protectedmode.aspx
※この資料は暫定的なものであり、変更されることがあります。だそうで。
大層なタイトルつけてみたけど、他意はないんだぜ？
オレの仕事場で（そしてオレの仕事用ノートPCでも）Windows Updateの失敗が続出した。
そして失敗が起きていたのがこのKB905474、つまりWGA(Windows Genuine Advantage)だったってワケだ。
なので解決方法を処方箋的な意味合いで載せとこうと思う。
（役に立つかはおいといて）
まず軽いケースの場合。
下記URLから実行ファイルをダウンロード、保存して実行する。
http://download.windowsupdate.com/msdownload/update/v3-19990518/cabpool/windowsxp-kb905474-enu-x86_4bafa8793e8cdcaf4ba4ffc494df32d496154544.exe
そんだけ。
（いや、手抜きじゃなくてホントに）
次にちょっと面倒なケースの場合。
「Windows XP を更新する権限がありません。」みたいなカンジでXPタンに冷たく突き放された人はこっち。
ちなみにオレもこっちだった。
「オレとXPタンの信頼関係もその程度のもんだったんだな。」と思わされた。
（ただいま妄想中です。しばらくお待ちください。）
途方に暮れたオレは昔のXPタンを取り戻すために旅に出た。
そしてとうとうMr.Googleに一つの答えを授かることができた。
（Google Japanでは答えは得られなかった）
というワケで手順を記そう。
ちなみにコレをやると、システムドライブの所有権とレジストリのアクセス権限にローカルのAdministratorsとSystemが追加し直されるので、自己責任でやって欲しいと先に言っとく。
まず、下記URLからSubInACLのインストーラをダウンロード、保存して実行する。
次に、インストールしたディレクトリをPATHに追加するか、もしくは実行ファイルをPATHの通った場所に移動する。
・インストールしたディレクトリをPATHに追加する場合
set path=%path%;"%SystemDrive%\Program Files\Windows Resource Kits\Tools
・実行ファイルをPATHの通った場所に移動する場合
move "%SystemDrive%\Program Files\Windows Resource Kits\Tools\subinacl.exe" %SystemRoot%\System32\.
そして、メモ帳に以下の内容を貼り付け、.bat拡張子で保存して実行する。
rem -----ここから-----
@echo off
subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=administrators=f
subinacl /subkeyreg HKEY_CURRENT_USER /grant=administrators=f
subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=administrators=f
subinacl /subdirectories %SystemDrive% /grant=administrators=f
subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=systems=f
subinacl /subkeyreg HKEY_CURRENT_USER /grant=system=f
subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=system=f
subinacl /subdirectories %SystemDrive% /grant=system=f
@Echo =========================
@Echo Finished.
@Echo =========================
@pause
rem -----ここまで-----
最後に、仕上げの再起動をしたら、Windows Updateを実行する。
コレでうまくいくハズ。
でも、うまくいって良かったんだが、同時に何か大切なものを失ってしまった気がする。
もう、昨日までのXPタンはいないんだね。
（ただいま妄想中です。しばらくお待ちください。）
あれ、ヘンだな。目から水が出てくるや。
（ただいま妄想中です。しつこいですか、そうですか。）
新年度になってからいろいろ忙しいオレ。
ブログの更新もままならねぇぜ！
いや、自分で研修やろうとか言い出したんだけどさ（汗
あ、息抜きはそこそこにしてるからご心配なく（笑
あと、もしかして、もしかすると、もしかしたら、セキュリティ関係の記事を楽しみにしてる人とかいるかもしれないけど、
そんなん全然無視。
今日は最近知った軽い話題でお茶を濁すことにする。
最近ますます便利になったGoogle先生の話題。
オレ知らなかったんだけど、Googleって検索に*(アスタリスク)使えるのな。
いやー、便利だわ。
以上。
ゴメンな、今日はこんなんで(･ω･`)
～前回までのあらすじ～
セキュリティ監査を続けていたオレは、基幹系のサーバに侵入する為にドメインコントローラの攻略を試みる。
しかしActive Directoryの堅牢な設計を前に、攻略の道は半ば閉ざされかけていた。
なんとかドメインコントローラを掌握したいオレだったが、その想いとは裏腹になかなか足取りを掴むことはできなかった。
オレは諦めかけながらも調査結果を洗い直すことにした。
洗い直しの一環としてNessusのスキャン結果を眺めていたオレは、ふとあることに気がついた。
Domain Adminsグループにいくつかの不自然なアカウントが含まれていたのだ。
以前はセキュリティリスクの低い情報として見落としてしまっていたらしい。
どうやら管理者が普段の業務で使用しているアカウントのようだった。
これらはドメインのAdministratorアカウントより脆弱なパスワードを使用している可能性が十分にある。
望みはつながった。
あとはどう料理するかだ。
まず管理者が使用しているPCにソフトウェアキーロガーをインストールすることを考えた。
が、コレはAntiVirusなどで検出される恐れがあったため見送った。
（それ以前に倫理的な問題があるような気もするが）
思案の結果、自分のマシンにDomain Adminsのアクセスのみが許可された共有フォルダを作成し、辞書攻撃を仕掛けることにした。
この手法では自身のマシンに攻撃を仕掛ける為、検知される可能性は低い。
（ただしパスワードの問い合わせはドメインコントローラに対して行われる為、可能性は0ではない）
ツールにはNetwork Share Brute Forcerを使用することにした。
Network Share Brute Forcer (dfg-crew.com)
http://www.dfg-crew.com/files/netbrute-3.1.zip
また、辞書には日本語を標的にしたpassword.lstファイルを用意した。
攻撃を開始してから30分も経たずして、先程のアカウントのパスワードクラックに成功した。
このアカウントのパスワードにはその管理者の苗字が使用されていた。
オレはすぐさまこのアカウントを使用し、ドメインコントローラにAbelをインストールした。（過去記事参照 ）
そして全ユーザのアカウントとそのLANMANハッシュを取得し、パスワードクラックをかけた。（過去記事参照 ）
オレはようやくドメインを制圧することに成功した。
-つづく-
いつものように解説いくよーん。
まず、ユーザに与える権限についてだが、アカウントに不用意に権限を与えるのはオススメできない。
特にDomain Adminsにはドメインにおける完全なアクセス権限が与えられるので、アカウントはAdministratorのみに絞るべきだ。
可能ならAdministratorという名前も変更することが望ましい。
次に、パスワードの設定についてだが、これは以前に触れたとおりだ。（過去記事参照 ）
推測されやすい言葉や辞書に載っている単語は、クラッカーの格好の餌食になる。
特に強い権限を持つユーザにはなるべく強固なパスワードを設定するべきだろう。
最後に、ドメインのグループポリシーについて。
今回の攻撃が成功した背景には、アカウントロックアウトのポリシーが設定されていなかったことが大きい。
これは認証に一定回数の失敗があった場合に、そのアカウントを一時的に使用不能にする設定だ。
これを有効にしていれば、辞書攻撃やブルートフォースアタックといった手法は通用しなくなる。
また、これ以外にもグループポリシーにはセキュリティ強化に有効な設定項目が多数含まれているので、合わせて参照しておくといいだろう。
※あ、勝手に監査の真似事とかやると犯罪者になります。この件は合意の元でやってたんだから勘違いしないでよねっ。
前回までのあらすじ
セキュリティ監査を任されることになったオレは、社員の全PCといくつかのサーバの掌握に成功する。
しかし、基幹系のサーバには未だ侵入することができずにいた。
てっとりばやくドメインを攻略するには、やはりドメインコントローラに侵入することが肝要だ。
しかし既知の脆弱性を検知できない以上、何か他の手を打つしかない。
そこでオレは少し思案を巡らせてみた。
PCはドメインコントローラに問い合わせられない場合でも、ドメインアカウントでログインすることができる。
（場合によっては不可）
ということはドメインアカウントのパスワードはローカルにもキャッシュされるのではないか。
この予想は大当たりで、暗号化されたパスワードは確かにローカルにもキャッシュされていた。
これはMSCACHEと呼ばれるものだ。
さっそくMSCACHEについて調べてみたが、これが一筋縄ではいかないことが分かった。
なぜならこれを効果的にクラックする方法がなかったからだ。
MSCACHE自体を取り出すのは造作もないことなのだが、暗号化にはsaltが使われていた。
このsaltはまさに料理における塩のようなもので、"ひとつまみ"（ランダム）という分量が非常に厄介なのだ。
正確な塩（salt）の分量が分からなければ、残りのレシピ（パスワード）を割り出すことはできない。
調査の結果、どうやらsaltにはユーザ名とドメイン名が使われているらしかった。
（間違ってたらスマン。なんせ情報が少なくて）
つまり、同じパスワードでもアカウントやドメインによってこのMSCACHEの値は変化することになる。
これは、Rainbow Tableを自分で生成するか、ブルートフォースまたは辞書攻撃を行なわなければならないことを意味していた。
要するに、どれを選ぶにせよ時間がかかるということだ。
（オレはドメインのAdministratorのパスワードが13文字だということを以前聞いた覚えがあったので、どの方法も現実的ではないと判断した。）
結局オレはMSCACHEによるクラックを諦め、別の方法を考えるしかなかった。
-つづく-
ほんのちょっと解説。
まぁ、今回はひとつの失敗談でしたとさ（笑
ちなみにMSCACHEではそのPCに一度でもログインしたアカウントの最後にログインした時のパスワードしかキャッシュされない。
実はMSCACHEはローカルに保存しない設定にすることもでき、この場合はドメインコントローラに問い合わせできない状況ではドメインアカウントではログインできない。
あと、Rainbow Tableは必ずしも自分で生成する必要はない。
偶然同じドメイン名とユーザ名をsaltにしたRainbow Tableがあれば、それをダウンロードすればいい。
（ユーザ名はAdministratorでいいとして、ドメイン名が一致する確率ってどんなもんだろな。笑）
それでなくても生成を代行してくれるような心優しい（？）方々もネット上にはいるので、必要があれば依頼してみるのも手なのかもしれない。
保証はできないけど。
※あ、勝手に監査の真似事とかやると犯罪者になります。この件は合意の元でやってたんだから勘違いしないでよねっ。
拝啓、パトラッシュ様
オレもう疲れたよ・・・。
最近派遣先の社内ネットワークで一部問題が発生していた。
時にはネットワークがダウンし、4時間ほどまったく仕事にならない日もあった。
しかし今日やっとその問題の元凶が発覚した。
（といってもオレが解決したわけじゃないんだが）
えー、イメージしてみてください。
まず、同じネットワーク内に何の変哲もない2つのスイッチがあります。
これを仮にスイッチ1・スイッチ2とします。
そしてこれらのスイッチは何の変哲もない2本のLANケーブルで相互に接続されています。
これらのスイッチにはPCが接続され、スイッチ1はゲートウェイに接続されています。
さらにイメージしてみてください。
今、1台のPCからARPリクエストが送信されました。
そのARPリクエストを受け取ったスイッチ1は、受信したポート以外のすべてのポートからARPリクエストを送信しました。
そのARPリクエストを受け取ったスイッチ2は、受信したポート以外のすべてのポートからARPリクエストを送信しました。
そのARPリクエストを受け取ったスイッチ1は、受信したポート以外のすべてのポートからARPリクエストを送信しました。
そのARPリクエストを受け取ったスイッチ2は、受信したポート以外のすべてのポートからARPリクエストを送信しました。
（・・・以下永久に続く）
(((；ﾟдﾟ)))
「時には初心に戻ることも大切だね」って、そういうお話でしたとさ。
まぁ、もうお分かりの方も多いと思うが一応解説。
見てのとおりだがブロードキャストストームが発生している。
ARPリクエストはブロードキャストであり、スイッチはブロードキャストアドレスに向けて送信されたフレームを受信したポート以外のすべてのポートから送信する。
よって2本のLANケーブルによって接続されたスイッチではARPリクエストのブロードキャストが永久にループし続ける。
さらに、それらのブロードキャストはネットワーク全体に送信されるため、ゆくゆくはネットワーク全体の帯域を食い尽くす。
（メルトダウンって言ったかしら）
ネットワークトポロジをループ状に構成するなというのはこういう話が背景にある。
ただしこれには例外があり、STP（Spanning Tree Protocol）またはRSTP（Rapid Spanning Tree Protocol）という技術によってこの問題を回避することができる。
これらが実装されていた場合は、通常使用する接続を1本に制限し、その接続に障害が発生した場合は自動的に別の接続を利用するといった冗長構成を実現できる。
まぁ今回問題になったスイッチには実装されていなかったので、片方のLANケーブルを抜いて対処完了だったワケなんだが。
前回までのあらすじ
セキュリティ監査を任されることになったオレは、手始めにインターネット側からの攻撃を試みるが失敗する。
（まぁそれがあるべき姿なのだが）
しかし社内ポリシーの脆弱性を利用し、イントラネット内から社員の全PCの管理者権限を奪取することに成功した。
勢いに乗ったオレは、次にサーバルーム内のサーバに対する攻撃を開始することにした。
第1フロア・第2フロアのネットワークとサーバルームのネットワークはセグメントこそ分かれていたが、特にルータやファイアウォールで通信を制限されているワケではなかった。
そこで、オレはまずNessusをダウンロードし、数台のサーバに対してスキャンをかけてみることにした。
結果はまずまずといったところで、数件の脆弱性を確認することができた。
もっともそのほとんどはDoS攻撃の脆弱性だったのだが・・・。
しかしめげずにスキャンをかけていたところに、リモートから任意のコードを実行できる脆弱性が見つかった。
これを利用しない手はないだろうというわけで、milw0rmさんのところから実証コードを取り寄せてみた。
（ちなみにmilw0rmにはたまにアクセスできないことがあるけど、DoS攻撃の標的にでもされているんだろうか？笑）
milw0rm
http://www.milw0rm.com/
ソースを整形して実行してみたところ、見事にVNCのセッションを確立することに成功した。
（ちなみに普段インフラ業務のオレはソースコードを見ることなど滅多にないが、こういう時だけ読めるようになる。笑）
どうやら修正パッチの適用ポリシーが存在しなかった為、修正パッチの適用状況は導入時点での最新の状態にとどまっていたらしい。
こうしていくつかのサーバを手中に収めることに成功したが、ドメインコントローラやファイルサーバを攻略することはできなかった。
これらのサーバは移行したばかりで、既知の脆弱性が存在しなかったのだ。
-つづく-
か・い・か・ん
・・・んじゃなくて（汗
か・い・せ・つ。
な。
というわけで解説に入るんだが、今回は書くべきこともそんなに多くないんだなコレが。
まず、不要と思われるパケットはなるべく遮断するが吉。
特に基幹系のサーバがあるセグメントに対する通信には制限を設けておかないと、いろいろ厄介なことになりかねない。
「気付いたら機密情報が全て盗まれていました」じゃ笑い話にもならないじゃんねぇ（笑
できることならWindows Firewallの機能も有効にして、不要なパケットを通過させないようにしておくべきだろう。
これは、セグメント間の通信を制限しただけでは同じセグメントにある他の脆弱なサーバを踏み台にされた場合に危険にさらされてしまうことになる為だ。
そして、以前の記事でも書いたとおり、修正パッチはASAPで適用するべし。
（ASAP： As soon as possible、可及的速やかに）ただし、サービス停止が許されないサーバの場合は擬似環境による検証を踏まえた上で適用するということをお忘れなく。
万が一不具合が出た場合に、業務に支障をきたしたら元も子もないもんね。
（まぁオレがここに書くまでもないことかもしれないんだけど一応書いとく）
ちなみにWindows環境のパッチの適用を統合管理したいならWSUSが非常に便利。
Windows Server Update Services (Microsoft)
http://www.microsoft.com/japan/windowsserversystem/updateservices/default.mspx
そういやWindows Server 2003もSP2が出たし、ぼつぼつ検証しなくちゃいかんなー。
めんどくせぇ。
※あ、勝手に監査の真似事とかやると犯罪者になります。この件は合意の元でやってたんだから勘違いしないでよねっ。
