2004年09月29日 - WindowsXPがパスワード情報を送信する話

 ワードのdocファイルを含むURLにブラウザで接続させ、NTLM authentication(NTLM認証)でドカンらしい。
 うちはパスワードは大文字小文字混ぜて20文字だから、とりあえずは被害は無さそうだ(笑
 長いパスワードは歌の歌詞、これを熱く推奨する。それも単語をそのまま使わず、「離れていても」なら「hnrtitm」
 (このような方法を、Phrase Acronymと呼ぶらしい。)
 大体、忘れたら困るのだ。


 ファイル共有が有効になっているWindows ServerのIIS(Internet Infomation Services)に対して,Windows XPマシンからHTTPで接続し,IIS上で公開されているWordファイル(拡張子Doc)を直接開くと,Windows XPマシンがこのWindows Serverに対してNTLM認証を試みようとする。
 NTLM認証を実行する際に,クライアントはハッシュ化されたパスワード情報をサーバーに送信する。関氏によれば,「悪意のあるユーザーの立てたサーバーにNTLM認証を試みた場合,パスワードのハッシュは数分で解読されることがある」。
Windows XPに「勝手にパスワード情報を送信する危険性」が見つかる


[マイコンピュータ]?と瑣末なことは置いておいて(後日修正された)、じっくり読み直した。
元記事はこれ。


I would recommend to read a Robert Hensing article. Why you shouldn't be using passwords of any kind on your Windows networks . . . http://blogs.msdn.com/robert_hensing/archive/2004/07/28/199610.aspx
And, I don't recommend to rely on NoLMHash. http://www.securityfriday.com/Topics/winxp1.html
Rainbow tables for LM/NTLMv1 authentication


関連記事1
Why you shouldn't be using passwords of any kind on your Windows networks . . .
http://blogs.msdn.com/robert_hensing/archive/2004/07/28/199610.aspx
パスワードなんていずれ破られてしまうものだって話らしい。
猫とネズミの喩えがあった、そんなものなんだろう。

関連記事2
 NoLMHashの設定でも抜け道があるとのこと。


However, the registry NoLMHash does not affect LM authentication. Even if NoLMHash has been set to one, Windows XP automatically transmits your local log-on password to the NT4.0 machine using LM authentication when "My Network Places" is clicked.
(以下は勝手に和訳)
 しかしながら、レジストリのNoLMHashはLM認証に影響を与えない。 たとえNoLMHashが1に設定されていても、マイネットワークをクリックされた時にWindows XPはNT4.0マシンにLM認証を使って自動的にあなたのローカルログオンパスワードを伝達する。
Hazard of My Network Places on Windows XP


これまでを4行に要約する。
強度はLM認証<NTLM認証(NTLMv1)<NTLMv2の順番で、ハッキングに対する強度が高い。
LM認証は最弱で、あっけなくパスワードをハッシュから抜かれる可能性がある。
そしてNTLM認証(NTLMv1)、NTLMv2であってもハッシュからパスワードを取られる可能性は(場合により、または将来の事も考えると)皆無ではない。
とりあえず対策しろ。

 最初はLM認証かと読み違えたが、SecurityFridayの記事では確かに[NTLM authentication(NTLM認証)]と書かれている。
 Automatically passing NTLM authentication credentials on Windows XP (SecurityFriday)
 数分間でLM認証ではなくNTLM認証のハッシュから、パスワードが簡単に解析できるんだろうか。

 知人に聞いたら、SecurityFridayに関するこんな記事を紹介された。なかなかの力技なのだ。これはそうそう簡単にはできない技術のようだ。


 解析対象となる認証方式はNTLMv1と新NTLM。 今回のシステムでは,既存の辞書攻撃を使ってパスワードを割り出すのに7日かかる場合で5秒,30日かかる場合で20秒で解析できる。 それぞれの場合で,1.4テラバイト,5.7テラバイトのハードディスク容量が必要になる。
セキュリティフライデー,脆弱なパスワードを数秒で解読するシステムを開発(IT Pro)


 このようなパスワードを解析する技術があったとしても、長くて推測されづらい適切なパスワードを設定していれば、当面は心配は無いのだろう。
(技術として今後解析が可能かどうかは別として、悪意を持った解析者があきらめるだけの時間を稼げれば、それはそれだけの効果がある)


弱いパスワード(例:1ヶ月程度で暗号が解析されてしまうパスワード)のリストをコンピュータで演算処理した特殊なデータベースを大容量ハードディスクドライブに保有し、
社内のWindows ネットワークを監視し弱いパスワードをハッカーより先に見つける監査技術を開発(SecurityFriday)


 下らない話と聞き流されるだけだけど。
 個人利用が多いWindowsXP HomeEditionはパスワードを設定していないユーザーが大多数だろうけど、リモートからはパスワード無しでは接続できないんで、逆にノーガード戦法的効果が期待できるのではないか。
 下手なパスワードを設定するよりは無い方がいいってのは、変な話だが。
 (1とかaaaを設定している知人がいる、これは論外だろう)

 覚え書き代わりに俺メモを書いておく。
(どこかに残しておかないと、すぐまた忘れそうな鳥頭なのだ)。

 LM(LAN Manager)認証はWindows95などでも使われ、パスワードは全て大文字に変換される。7文字以上のパスワードであっても7文字ごとに扱われるため、「7文字チャンクの攻撃」を受ける。
 LMハッシュからのパスワード推測は容易らしい。

 NTLM認証はWindowsNT系で使われ、パスワードの大文字と小文字はそれぞれ区別される。
 Windows XPではNTLM認証だけではなく、LM認証も利用される。
 文字数が14文字までならLM認証も利用されてしまうため、15文字以上のパスワードでNTLM認証を使うようにするべき。
 例えばXPデフォルトでは、ローカルセキュリティポリシーのLAN Manager認証レベルの設定は「LMとNTLM応答を送信する」になっている。これは下互換性、つまり古いOSとやりとりするのを助ける目的らしい。
 (Windows Server2003では「NTLM応答のみを送信する」にデフォルトの設定が変わっている。)


とか色々考えてたら、memoにこんな追記があった。

 セキュリティフライデーの関さんから (ありがとうございます):
 ”Windows XPに「勝手にパスワード情報を送信する危険性」が見つかる”に関してですが、一つ補足させていただきますと、NTLMv1でも単純でない15文字以上のパスワードを使えばそれなりに安全だと思います。
Windows XPに「勝手にパスワード情報を送信する危険性」が見つかる(セキュリティホールmemo)



下らない謎。
NoLMHashが1でパスワードが15文字以上なら、NT4と絡むとLM認証になるんだろうか。
いや、違うと思うんだが。
(自分で試せ、って言われるだけかな)

下らない謎2
ローカルセキュリティポリシーから「NTLM応答のみを送信する」にしたら、NT4と絡むとLM認証になるんだろうか。
いや、違うと思うんだが。
(やっぱり自分で試せ、って言われるだけかな。)

用語解説 - ハッシュとは


 ハッシュ:一方向関数。ある文字列や数字から得たハッシュがあったとする。このハッシュから元の文字列・数字へは簡単には戻せない。「1+1=2だが、2から元の式を推測するのは困難」との喩えを教わったことがある。パスワードはSAM(Security Account Manager)ファイルにハッシュの形で保存される。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

このブログは、Lucablog 2004-09-29 XPが勝手にパスワード情報を誰かに送信する話(http://d.hatena.ne.jp/LucaLuca/20040929)を修正・加筆し移転したものです。  

2004年09月19日 - 添付ファイルがBase64のデコードに失敗した(備忘録)

本文に変な文字列があるメールが来たと相談された。
 受信したメールに添付されていたzipファイルのデコードがうまくいかなかったらしい。


Content-Type: application/x-zip-compressed; name="***.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="***.zip"
(12行の文字列)


 12行の文字列は添付ファイル本体?76文字ごとに改行されている。
 base64でエンコードされたzipらしい。

 「MIME Base64 エンコード/デコード」をダウンロード。
 notepadを起動してデコードに失敗した部分を貼り付け、mimのエクステンションで保存。
 「MIME Base64 エンコード/デコード」を起動し、デコードさせ、zipのエクステンションで保存。
 zipファイルができました。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 このブログは、Lucablog 2004-09-19 添付ファイルがBase64のデコードに失敗した(備忘録)(http://d.hatena.ne.jp/LucaLuca/20040919)を修正・加筆し移転したものです。


  

2004年09月18日 - MS04-028とマルウェア・スパイウェアの予感

 JPEG 処理 (GDI+) のバッファ オーバーランにより、コードが実行される (833987) (MS04-028) なる中々印象的な脆弱性が発表されたんですが。

 過去にも画像ファイルに何かを埋め込むウイルスは幾つかはあったんですが。
 しかし画像に埋め込まれた何かを別個に呼び出す必要があった。つまり何かに感染中でなければ、それは利用されなかった。つまりステガノグラフィー(画像埋め込み、みたいな)のような。
 例としてPerrunなどである。

 このMS04-028のExploitは、これらとは考えられうる感染経路なりが全く違う。
 これまでの常識では、画像や音楽関連のファイルはウイルスとは無縁との解釈がまかり通っている。
 (例外としてTrojan.Linux.JBellz、ただこれは被害範囲があまりにも狭いので、ここでは論じない)
 つまりMS04-028、未感染ユーザーがjpg画像ファイルをダブルクリックしただけで、何らかの被害を受ける可能性がある。
 想定される被害の範囲は、Windowsユーザーほぼ無限。

 現実の話として、この対策を完全に行うのは極めて困難である。
 Windows Updateは知名度が高いが、Office Updateの存在をどれだけの人が知っているのか。恐らく数パーセント以下であろう。

 これは一見するとWindows 2000/XP/Server 2003以前のOSでは直接の危険性はないように思えるんだろうか。しかしその他のアプリケーションをインストールしている環境では、リスクは残ったままである。
 またWindows上で動作するサードパーティ(Microfoft以外が製造した)製品も、この脆弱性の影響を受ける可能性がある。これらが存在する限り、今後完全に対応するのは難しい。
 開発者やメーカーがリリース済みの製品に対してどこまで修正してくれるのか、またユーザーはそれだけ頻繁にアップデートをしているのかという点で疑問がある。

 メール経由でこのExploitを含む画像を送りつけられるケースを除けば、大量感染はあまり心配されていないようだが。
 コメントスパムや画像掲示板への自動投稿経由で、CWSなどに感染する事例が多い現状この危険な画像ファイルを画像貼り付け掲示板に自動的に貼り付ける業者が出現した場合、その被害はどれだけの規模になるのだろう。
 これらは悪質なアダルトサイト運営者などが頻繁に使う手口だからだ。そして彼らはIEのExploitを頻繁に利用する傾向がある。

A. 脆弱性が存在するモジュールは gdiplus.dll です。このモジュールのバージョン番号が 5.1.3102.1355 未満の場合、脆弱性が存在します。

GDI+ を利用している製品のセキュリティ対策方法についてよく寄せられる質問 (FAQ)


 Q. 脆弱性のあるモジュールはなんですか?また、バージョン番号はいくつですか?
 A. 脆弱性が存在するモジュールは gdiplus.dll です。このモジュールのバージョン番号が 5.1.3102.1355 未満の場合、脆弱性が存在します。
GDI+ を利用している製品のセキュリティ対策方法についてよく寄せられる質問 (FAQ)


2004-9-22追記
 セキュリティホールmemoでKJMさんが解説していた。

 %windir%\WinSxS というのが「Side-by-Side アセンブリキャッシュ」と呼ばれるフォルダなのだそうです。ちなみに MS04-028 の場合、5.1.3102.1355 以前のバージョンの gdiplus.dll で影響が発生するそうです。  Side-by-Side は、「DLL 地獄」を避けるために複数のバージョンの DLL をアプリ毎に別々に利用するための機構のようです。しかしこれを利用してしまうと、セキュリティホールが残っている DLL を使い続けることにつながってしまう場合があるのでなるべく使わないようにしてね、ということのようです。
セキュリティホールmemo 2004-9-20


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

このブログは、Lucablog 2004-09-18 MS04-028とスパム・スパイウェアの予感(http://d.hatena.ne.jp/LucaLuca/20040918)を修正・加筆し移転したものです。