以前の記事をなんとなく読み返していたんだけど。


いろいろ書いたなーと思ってみたり。


そういえばこんなん書いたなーと思ってみたり。


うわっ、よくこんなんシラフで書いてたなー(恥と思ってみたり。


(いや、きっとアレは酒が入っていたに違いない。笑)


まぁそれは置いといて。



ちょっと気付いたんだ。


以前の記事を見てみるとなんとつまらないグチが多いことか


まぁ一時期精神的余裕がなかったりしたからなー(切実。笑



最近はおかげさまで好き勝手やらしてもらってますよ(笑


つーかまぁ納得できる仕事っつーのかな。


以前は納得しないままの仕事が多くて正直ウンザリしてたのね。


んで、納得できない仕事ってやっぱり顧客満足度も低いのよ。


でも最近はホントに提案したい仕事ができて。


いろんな人に感謝しなくちゃいけないな。


酒が入ってるからこんなことマジメに書いちゃうんだけどさ(笑



あと、以前からすると考え方が変わったかなと思ったり。


以前はいろんなものと戦ってばかりいた。


顧客と戦ったり、周りの技術者と戦ったり。


でも、ホントに優れた技術者なら、お互いを尊敬しあい、高めあうものなんじゃないか


顧客と協力しあい、サービスの品質を高めていくものなんじゃないか


ってね。


少し時間がかかったけど、やっとそう思えるようになった。



技術に対するアプローチもちょっと変わったのかもしれない。


以前は「○○を使ったことがある」というのが一種のステータスみたいな気がしていたけど、そんなものは上辺だけなんだと思うようになった。


問題を解決する時にKB(Knowledge Base)を探して見つからない時は諦めていたけど、仕組みを理解すれば必ず分かる時が来るんだと思うようになった。


それが正しいことなのかは分からないけどね。


なんてったって酒入ってるし(笑



だもんだから、ブログ情報フリースペースのところはちょっと書き直そうと思う。


ぶっちゃけそれが言いたかっただけなんだ。

前回までのあらすじ


セキュリティ監査を任されることとなったオレは、とりあえず外部(インターネット)からの攻撃を試みた。


しかし、これといった脆弱性は存在しなかったため、内部(イントラネット)からの攻撃にシフトすることにした。



まず、カンタンにその企業の当時の環境を説明しておこう。


その企業のイントラネットは大きく分けて3つのセグメントに分かれていた。


内訳は、第1フロアのネットワーク、第2フロアのネットワーク、そしてサーバルームのネットワークだ。


第1フロア・第2フロアのネットワークには社員のPCが接続され、サーバルームにはサーバ類が接続されていた。


アカウントとコンピュータはActive Directoryによって管理されていた。



まず最初に目をつけたのは社員のPCに関するある共通点だった。


それはローカルマシンのAdministratorに、統一された周知のパスワードを使用していることだ。


オレに渡されていたThinkPadも例に漏れず、小文字のアルファベット6文字の統一パスワードだった。


そこでオレはまず「runas /user:thinkpad\administrator cmd」を実行し、そのパスワードを入力してみた。
(thinkpadはホスト名)


Audit01

(クリックで拡大)


すると、狙いどおりコマンドプロンプトがローカルのAdministrator権限で立ち上がった。


Audit02

(クリックで拡大)



ここですかさずコマンドプロンプトから「compmgmt.msc」を実行し、[コンピュータの管理] をローカルのAdministrator権限で起動した。
(ちなみに、Administrator権限で実行されていることは [タスクマネージャ] の [プロセス] タブで確認できる)


ここでコンピュータの管理を起動したのには2つの理由があった。


1つは自分のドメインアカウントをローカルのAdministratorsグループに所属させること。


Audit02

(クリックで拡大)


これでこのマシンに自由にツールをインストールし、実行できるようになる。


そしてもう1つは [別のコンピュータへ接続] の機能を使って、他のマシンの設定を変更すること。


Audit03
(クリックで拡大)


これを使えば、他のマシンのサービスを起動したり、新しいユーザや共有フォルダを作成することもできる。


いくつかのマシンでtelnetサービスを起動し、先程のコマンドプロンプトでtelnetを実行してログインしてみた。


しかし、もちろん気付いている人は一人もいなかった



-つづく-



か・い・せ・つ。


まずいただけないのは、ローカルのAdministratorのパスワードが一般社員に知られてしまっていること。


これではいつでも権限を昇格し、マシンを意のままに使用されてしまうことになる。


そして、すべてのPCでローカルのAdministratorが同じパスワードを設定されているのもマズい。


2台のマシンに同じ名前で同じパスワードのローカルユーザが存在する場合、その権限を使用すれば認証を抜けて相互にアクセス出来てしまう
(これはUNIX系OSも同じ)


環境が許すならローカルのAdministratorは無効にしてしまうべきだろう。


ちなみにrunasコマンドを使わずにローカルのAdministratorでログインして同じことをしても結果は変わらない。


が、NetEnumのようにログインしているユーザを検知できるツールも存在する為、当時は攻撃者の観点であえてこの手法をとった。

(効果があったかは疑問だが)




※あ、勝手に監査の真似事とかやると犯罪者になります。この件は合意の元でやってたんだから勘違いしないでよねっ

前回までのあらすじ


オレは某IT企業のセキュリティ監査を任されることとなった。(空いてる時間で)



というわけでセキュリティ監査を始めることとなったのだが、実は当時のオレはそんなにセキュリティに詳しいわけでもなかった。


はてどうしたものかと思ったオレは、アタッカー(攻撃者)の視点に立つことから始めた。


そして、それと同時にシステム管理者として何をされるのが一番怖いのかを考えてみた。



やはり、一番怖いのはインターネット側から不特定の人間に不正侵入されることだ。


その企業にはDMZに置かれているサーバが3台ほどあった。


つまり、これらはWebページの改竄やDNSポイズニングによる被害を受ける可能性がある。


さらに最悪の場合、イントラネットに侵入する際の踏み台に利用される危険性がある。



オレはまず、アタッカー(攻撃者)が侵入に利用する手口について考えた。


それにはやはり設定上の脆弱性を突くか、既知のセキュリティバグを利用するのが手っ取り早いだろう。


そこで、とっかかりとしてセキュリティスキャンをかけてみた。



ここで登場するのが以前紹介したNessusだ。(過去記事参照


しかし、インターネットからアクセスできるマシンにはNessusで検知できる脆弱性は存在しなかった


なので、ここから目標を切り替えて内部(イントラネット)からの監査を行うことにした。

(捕捉すると、今思えばこれだけでは不十分だった。これらにはファイルサーバやメールサーバも含まれていたため、辞書攻撃によるログインを試してみなければならなかったからだ。)



-つづく-

たまには思ったことをつらつら綴るのもいいんじゃない?


自分に言い訳して、本記事はだらだら書くことに決めた。



まず、はじめに。


読者登録感謝です。


同郷の方(鹿児島出身者)や同胞の方(IT業界で働いてる人)が登録してくれるのは嬉しい。


・・・ふざけたブログばっか書いてるけど、たまにはマジメなことも言えるんだぜ(笑



次。


「せっかく見てやってんのにカンジンなことが書いてねーんだよ(怒」とか「その記事の内容はちょっと違うんじゃない?」という方。


この場(ひいてはアメブロ)をひとつのKB(Knowledge Base)とすることは、オレのやりたいことでもあり、このブログの隠れた目的でもあります。


質を高めていくためにも、コメント欄でどんどんツッコミ入れてください。


書くべきことや書き忘れてることなんてゴマンとあるハズなんで。

(隠れた目的とかいって公表してんじゃんとかそんな野暮なツッコミはNGで。笑)



最後。


ちょっと偉そうな言い分かもしれないけど、物の価値は自分の目で見て自分で考えて判断してください。


インフラ技術者はWindowsを明確な理由もなく非難したりしないでください。


システム開発者は仕事を貰うために安易に見積もり額を下げたりしないでください。


管理職は学歴なんてクダラナイもので給料を決めたりしないでください。


新人は誰かに声をかけられるまで待ったりしないでください。


オレがココに書いたことも、鵜呑みにしないで自分で判断してください。



そして、お客様も自分たちも納得のいく素晴らしいシステムを作ってください。



あー、書きたいこと書いたらスーッとしたけど、恥ずかしくて変な汗が出てきた(汗

最近なんか忘れてると思ったら更新忘れてたことに気がついた(笑


さーて、ナニを書こうかなと思ったけどいいネタがあったのでこの際書いちゃうことにする。



それは某IT企業のセキュリティ監査のお話。


ちなみにちょっと長編になりそうなんだが、最後までお付き合い頂けるもんだろうか。


・・・なーんて危惧するオレじゃねーぜ!!


つーワケでそのお話やっちゃうよー。


※この話には諸事情により一部正確ではない表現も含まれています。



それは某IT企業の部長とのやりとりから始まった。


オレはそのときそのIT企業にパートナー(平たく言えば派遣)として出向いていた。



部長さん「おぅ、ちょっとタバコ行こっか」


オレ「あ、うっス」


オレはいつものようにPCにロックをかけて後を追った。



コンビニでコーヒーを買って、喫煙者の溜まり場に向かう部長とオレ。


二人無言でタバコをふかしていると、部長が話を持ちかけてきた。


部長さん「S(オレの本名ね)ちゃんさぁ、セキュリティ詳しい?」

(その人はオレのことをちゃんづけで呼んでた)


オレ「まぁその辺の技術者には負けない自信がありますけど」

(オレは基本強気だから。笑)


部長さん「じゃあちょっと頼まれてほしいんだけどさぁ、ウチのセキュリティ監査やってくんない?空いてる時間とかでいいから



空いてる時間でいいからってなんだ。


このオヤジもマジメに考えとんのか適当なのかよくワカラン人だ。



オレ「なんかあったんスか?」


部長さん「いやさぁ、最近セキュリティセキュリティってうるさいじゃん。変な話、信用問題にも関わってくるでしょ」



それを他社の人間であるオレに相談してくるのは変な話じゃないのか。


まぁその企業にはネットワークセキュリティに強そうな人材はいなかったような気もする。

(一応システム管理者がいたことはいたけど)

オレ「ちゃんとした所に依頼したほうがいいんじゃないスか?」

部長さん「ホントはその方がいいんだけどねぇ。どうしても予算が厳しくてさぁ」



そすか・・・。



んでまぁ、そんなこんなな話の末にオレはセキュリティ監査を任されることになってしまった。



-つづく-

「テーマ「???」久しぶりに更新ですってよ。(ヒソヒソ」


「あらやだ。また更新停止か思っちゃったわ。(ヒソヒソ」



いや、あのね?


別にサボってたワケじゃないんだよ?


Vistaで動くツールが少なくて二の足踏んでただけだかんね?


まぁ実はVirtual PC 2007 RCを落としてあったからWindowsXPでやろうと思えばできたんだけど。


メンドくさかったなんて言えないよね。



んでまぁネットをガサゴソあさってたらよさげなツールを発見。


IE'en (SecurityFriday)
http://www.securityfriday.com/tools/ieen_sla.html


このツールは恐ろしいコトに遠隔でInternet Explorer(以下IE)を操作することができるらしい。



まず、ieen_s.exeを実行すると接続の画面が表示される。


ie'en01

(クリックで拡大)


今回は [Connect to local] で自分のマシンに接続してみる。


ie'en02

(クリックで拡大)


接続すると画面が開く。


ie'en03

(クリックで拡大)


ここで試しに [New Window] をクリックしてみると、IEが起動する
(Googleに接続されているのはIEの既定のページに設定している為)


ie'en04

(クリックで拡大)


で、 [URL] のトコロに別のサイトのURLを入力して [Go] をクリックするとそのページに移動する
(今回はYahoo!のページに移動させてみた)


ie'en05

(クリックで拡大)


怖いのはコレがリモートのマシンに対しても有効ということだ。


知らないウチに誰かが自分のマシンのIEで何かやっているのを想像すると気味が悪いだろう。



んで、さらに気味が悪いのが今開いているIEにもIE'enから接続できる点だ。


今開いているIEに接続するにはプルダウンメニューを使用する。
(Vistaでは何故かこの機能は利用できなかった)


ie'en06

(クリックで拡大)


これで一度接続しておくとあとはIEで移動した履歴が表示されるというワケだ。


IE'en10

(クリックで拡大)


今回はGoogleからamebaと検索してアメブロに移動してみたのだが、移動した履歴はしっかり表示されている


それどころかQUERY STRINGには検索キーワードまで表示されてしまっている


そしてもっと怖いのはSSLで暗号化する前のデータが表示されるので、やり取りしている個人情報などは丸見えになってしまう
(今回はメンドクサイので実演はナシ)



なぜこんなことが出来てしまうかというと、135番ポートに秘密があるようだ。


このポートはDCOM(分散COM)というサービスが利用しているのだが、コレがいけないらしい。


しかもコレはWindowsでデフォルトで有効になっているのだ。
(もっともWindowsXP SP2以降はWindows Firewallで守られてはいる)



じゃあ、コレを回避する策をば。


これはまず、[ファイル名を指定して実行] に「dcomcnfg」と入力して [OK] をクリックする。


ie'en07

(クリックで拡大)


すると [コンポーネントサービス] というウィンドウが開くので、[マイ コンピュータ] を右クリックして [プロパティ] をクリックする。


ie'en08

(クリックで拡大)


[プロパティ] が開いたら [既定のプロパティ] タブで [このコンピュータ上で分散COMを有効にする] のチェックを外して [OK] をクリックする。


ie'en09

(クリックで拡大)


これでDCOMが無効になり、IE'enなどによる悪用はできなくなる。


ウチの仕事場のPCはこの方法でDCOMを無効にしてあるが、今のところ不具合は出ていないっぽい。




あ、悪用すると犯罪者になります。


こと135番ポートについては中国や韓国から大規模なスキャンが実行されているというウワサもあったりする。

(昔の話なのかもしれんが)

~あらすじ~


設定内容と事象を確認できた為、擬似環境を構築して検証を行うこととなった。



第1節 検証 -Verification-


擬似環境の構築の結果、事象は見事に再現した。

つまり、この問題は論理的な切り崩しが可能になったというわけだ。



第2節 原因 -Cause-


検証の結果、原因はProcmailの動作によるものだということが分かった。


以下は前回記したprocmailrcの一行である。


! "$ACCOUNT"@"$EXCHANGE"


!(エクスクラメーションマーク)はこの後に指定される全てのメールアドレスにメールを転送するという意味を持つ。
(これはManpage of PROCMAILRC に記載されている。)


しかし、この一行を突き詰めていくとその実際の動作は以下のようになる。


| /usr/sbin/sendmail -oi "$ACCOUNT"@"$EXCHANGE"


つまりProcmail自身は送信機能を持たず、レシピに従ってsendmailコマンドを再発行しているのだ。


これが為にメールの送信元はtyuukei.bou-kaisha.co.jpになり、配達不能通知(NDR)はSendmailサーバのrootに向けて送信されることになっていたわけだ。



最終節 解決 -Solution-


原因さえ分かってしまえば解決はそう難しいことではない。


要はsendmailコマンドが再発行される際に送信元のアドレスをオリジナルと同じになるように指定しなおしてやればいい。


そこで設定ファイルの内容を以下のように修正した。


が修正した部分、が追記した部分


・procmailrcの内容(修正後)
----------------------------------------------------------
FROM=$1
# 送信元アドレスを変数に格納する。


TO=$2
# 宛先アドレスを変数に格納する。


ACCOUNT=`echo $TO | sed 's/@.*//g' `
# 宛先アドレスからアカウント部だけを取り出して変数に格納する。


EXCHANGE=[172.16.1.1]
# Exchange ServerのIPアドレスを変数に格納する。


:0
* ^From.*@tokutei.com
| /usr/sbin/sendmail -i -f $FROM $ACCOUNT@$EXCHANGE , dareka@$EXCHANGE
# 特定のドメイン部を持つメールをExchangeの本来の宛先アカウントとdarekaに送信する。


:0
| /usr/sbin/sendmail -i -f $FROM $ACCOUNT@$EXCHANGE
# 上記の条件にあてはまらないメールはExchangeの本来の宛先アカウントにだけ送信する。
----------------------------------------------------------


まず、引数として渡された送信元アドレスである$1を「FROM=$1」によって変数に格納する。


次に、「!」を使う代わりに「| /usr/sbin/sendmail」を直に実行し、-fパラメータを使用して送信元アドレスをオリジナルと同じになるように指定しなおす

(ちなみに-i -fは短縮して-ifにしてもいい)


これでReturn-Path:オリジナルの送り元のままExchangeサーバに届くようになり、配達不能通知(NDR)は正常に返信されるようになった。


またひとつ世界の平和が保たれたのだ。



あとがき


このNDR返信不能事件はホントはもうちょっと推理小説風味にしたかったんだが、まぁ結果は見てもらえばわかるとおりだよキミィ。


しかも3編に分けたかったが為にムリヤリ分割したのもまた裏目に出てるワケだよキミィ。


でも、この一件であるプログラムの動作を見たときの仕組みの部分の大切さを再認識することができたので、関われて非常に良かったと思う。


原因が分かるまでは気が気じゃなかったんだけどな。

Windows Vistaは高いという人々に朗報(?)だ。


詳しくは以下の記事を参照してほしい。


アップグレード版Windows Vistaをクリーンインストールするトリック (engadget japanese)

http://japanese.engadget.com/2007/02/01/windows-vista-upgrade/



オイオイ、ずいぶん壮大な自爆ネタですね(笑


どんなギャグだよ。


笑えねーよ(笑



Microsoftはぜひ通常版を買っちゃった購入したユーザにキャッシュバックしてもらいたい。


なんせオレもその中の一人なんだよ。


ホントはXPのライセンス持ってたからアップグレード版でよかったんだけど、アップグレードだとパフォーマンスが上がんないっていうから通常版買ったのに。


チキショー!


グレてやる!!

(死語?)



ま、とかいってココでごねても仕方のないことなんだよな。


仕方ないからXPタンはXenの上でGuestOSとして働いてもらうとするか。

~あらすじ~


C社の請け負っている案件にて配達不能通知(NDR)が返信されないという本末転倒とも言える事件が発覚し、私が解決を依頼される運びとなった。



第1節 構成 -Configuration-


C社から送られてきた設定内容を記す。


一部企業情報を特定できる内容が含まれていたので、その部分に関しては修正した。


内容の本質は以下のとおりである。


・mailertableの内容
----------------------------------------------------------

bou-kaisha.co.jp procmail:/etc/procmailrc
# bou-kaisha.co.jp宛に送られたメールをprocmailに渡す。
# レシピは/etc/procmailrcを使用する。
----------------------------------------------------------


・procmailrcの内容
----------------------------------------------------------
TO=$2
# 宛先アドレスを変数に格納する。


ACCOUNT=`echo $TO | sed 's/@.*//g' `
# 宛先アドレスからアカウント部だけを取り出して変数に格納する。


EXCHANGE=[172.16.1.1]
# Exchange ServerのIPアドレスを変数に格納する。


:0
* ^From.*@tokutei.com
! $ACCOUNT@$EXCHANGE , dareka@$EXCHANGE
# 特定のドメイン部を持つメールをExchangeの本来の宛先アカウントとdarekaに送信する。


:0
! $ACCOUNT@$EXCHANGE
# 上記の条件にあてはまらないメールはExchangeの本来の宛先アカウントにだけ送信する。
----------------------------------------------------------



第2節 調査 -Investigation-


調査の過程で配達不能通知(NDR)が返信されないのはメールヘッダのReturn-Path:がroot@tyuukei.bou-kaisha.co.jpに変わっている為だということが分かった。

(ドメイン部のtyuukeiは中継させているメールサーバのホスト名)



第3節 推理 -Reasoning-


通常、Return-Path:には送信者のアドレスか送信元のメールサーバのアドレスが入っていなければおかしい。


つまり、このReturn-Path:書き換えている(またはそのように見えるような動作をしている)部分を特定し、修正してやればいいはずだ。


ログを見る限り、Exchangeサーバが受信した時点でReturn-Path:は変わっていた。


このことからExchangeサーバの可能性は除外できる為、残りはSendmailかProcmailかということになる。


とりあえず擬似環境を構築し、検証を行ってみることとする。


再現性がないと厄介なことになるのだが。



次回はいよいよ解決編。(の予定。すべては解決できるかどうかにかかっている。)

第1節 発端 -The beginning-


この事件はC社が請け負っている案件のメールサーバにまつわる問題の解決を依頼されたことから始まった。


なお、事件は1ヶ月後を期限としており、時間的余裕は無いに等しい。


また、この問題はC社で解決することが極めて困難であった為にこちらに依頼されたという経緯がある。


それを1ヶ月で解決してほしいというのだから正気の沙汰ではないということが理解していただけるであろう。



第2節 環境 -Environment-


メールサーバの構成はオーソドックスな二段構え。


まずDMZにSendmailサーバが存在し、これが中継サーバになっている。


Sendmailサーバがメールを受け取ると、イントラネットのExchangeサーバに転送するという仕組みだ。


ただし、リレーする際にある要件があり、その為に転送にはProcmailを利用していた。


そのある要件とは、特定のドメインから送信されたメールを別のアカウントにも複製して送信するというものだった。



第3節 問題 -Problem-


ここで起こっている事件の全貌を明らかにする。


それはSendmailサーバにて転送したメールの宛先がExchangeサーバに存在しなかった場合に、メールの送り主に配達不能通知(NDR)が返信されないというものだ。


また配達不能通知(NDR)はSendmailサーバのrootアカウントに向けて返信されているという話だった。


ただ、このご時世にわざわざ配達不能通知(NDR)を返信するということはSPAM業者を呼び寄せることになりうるのだが、まぁその辺は黙っておこう。



次回は推理編。(の予定)