WindowsのSCFファイルをGoogle Chromeでダウンロードさせ、SMB認証情報を取得する攻撃 29
ストーリー by headless
認証 部門より
認証 部門より
Windowsのシェルコマンドファイル(.scf、SCFファイル)とGoogle Chromeの組み合わせにより、SMB認証情報を取得する攻撃手法をセキュリティ企業のDefenseCodeが公開している(DefenseCodeの記事、
Threatpostの記事、
The Registerの記事、
Softpediaの記事)。
SCFファイルはWindows 98で導入され、主にクイック起動ツールバーの「デスクトップの表示」で使われていた。SCFファイルの内容はINIファイルと同様のテキストファイルで、セクションごとに値の名前と値のデータの組み合わせが記述されている。ファイルのアイコンは「Shell」セクションの「IconFile」で指定するのだが、アイコンをUNCパスで指定した場合、アイコンの保存されたフォルダーをエクスプローラーで開く際に、指定されたリモートサーバーへSMB認証情報が送られる。そのため、攻撃者が自分の支配下にあるサーバーのIPアドレスを指定すれば、ターゲットのユーザー名とNTLMv2パスワードハッシュを取得することが可能となる。パスワードハッシュはオフラインでクラックするほか、SMBリレー攻撃に使用することも可能だ。
一方、Google Chrome側の問題は、デフォルトでファイルのダウンロード先を確認せずにダウンロードが実行される点だ。そのため、攻撃用に細工したSCFファイルのリンクをChrome上でクリックさせれば、ファイルがユーザーの「ダウンロード」フォルダーに保存される。このフォルダーをユーザーが開いた時点で、攻撃者はSMB認証情報を取得できることになる。Windowsのショートカットファイル(.lnk、LNKファイル)もSCFファイルと同様の動作をするが、ChromeではStuxnetの感染が問題になった際にLNKファイルをサニタイズする仕組みが導入されているとのこと。
SCFファイルはWindows 98で導入され、主にクイック起動ツールバーの「デスクトップの表示」で使われていた。SCFファイルの内容はINIファイルと同様のテキストファイルで、セクションごとに値の名前と値のデータの組み合わせが記述されている。ファイルのアイコンは「Shell」セクションの「IconFile」で指定するのだが、アイコンをUNCパスで指定した場合、アイコンの保存されたフォルダーをエクスプローラーで開く際に、指定されたリモートサーバーへSMB認証情報が送られる。そのため、攻撃者が自分の支配下にあるサーバーのIPアドレスを指定すれば、ターゲットのユーザー名とNTLMv2パスワードハッシュを取得することが可能となる。パスワードハッシュはオフラインでクラックするほか、SMBリレー攻撃に使用することも可能だ。
一方、Google Chrome側の問題は、デフォルトでファイルのダウンロード先を確認せずにダウンロードが実行される点だ。そのため、攻撃用に細工したSCFファイルのリンクをChrome上でクリックさせれば、ファイルがユーザーの「ダウンロード」フォルダーに保存される。このフォルダーをユーザーが開いた時点で、攻撃者はSMB認証情報を取得できることになる。Windowsのショートカットファイル(.lnk、LNKファイル)もSCFファイルと同様の動作をするが、ChromeではStuxnetの感染が問題になった際にLNKファイルをサニタイズする仕組みが導入されているとのこと。
SCFファイルを攻撃用Webサイトでホストしている場合、用心深いユーザーにクリックさせることは難しいが、Reflected File Download(RFD)攻撃を使用すれば信頼されるWebサイトのレスポンスに「Shell」セクションと「IconFile」を含め、SCFファイルとしてダウンロードさせることも可能だ。例では世界銀行のJSONデータを出力するWeb APIを利用している。通常は出力内容がテキストとしてブラウザーに表示されるのだが、表示できない文字(%0B)を含めることでChromeではファイルとしてダウンロードされる。なお、Internet ExplorerやMicrosoft Edge、Mozilla Firefoxではテキストとして表示され、ファイルが直接ダウンロードされることはなかった。
対策として、Chromeの自動ダウンロードを無効にする(「設定→詳細設定を表示→ダウンロード→ダウンロード前に各ファイルの保存場所を確認する」にチェックを入れる)ことや、インターネット上のSMBサーバーへのアクセスを禁止することなどが推奨されている。Windows 7以降ではSCFファイルがほとんど使われていないため、レジストリからSCFファイルの登録(HKCR\.scf)を削除しても問題ないかもしれない。DefenseCodeは本件をGoogleに通知していないそうだが、Googleはこの問題を認識しており、対応を進めているとThreatpostに回答したとのことだ。
不思議で仕方ない (スコア:1)
これがChromeの脆弱性なの？
そもそも最近流行りのSMB云々に関する脆弱性攻撃の根本的原因は、ほぼ100％がMicrosoftの責任だろう。
具体的にいうと、これ系の脆弱性は10年以上前から、それも各所/各人から何度も何度も指摘されていて、
それに対して「Windowsファイル共有はLAN内に対して提供するサービスなので、この脆弱性による影響力は極めて低い」
などと称してMSは特になにもせず、セキュリティfixを長年怠ってきた結果だろ。
こんなもん仮に全てのChromeが次のアップデートか何かで「自動ダウンロード機能削除」に変更されたとしても、当の脆弱性は残り続けるんだから無意味だろ。
ChromeでなくMicrosoftに抜本的な解決を依頼しろよ。それ以外ではどうにもならん。
Re: (スコア:0)
で、自動ダウンロード機能が削除されてどうやって攻撃すんの？
Re: (スコア:0)
「頭の悪い人は文脈から読み取れない。だから単語の議論をする」
Re: (スコア:0)
答えずにごまかそうとした文脈から理解しろってことだね。
一方、頭の良い人はそもそもWindowsを使わない (スコア:0)
こんな地雷だらけのOSの上で生活できるやつって頭おかしい
Re:一方、頭の良い人はそもそもWindowsを使わない (スコア:1)
毎日３億人以上が地雷の上で生活してると考えたら安全だと思わない？
Re: (スコア:0)
こんな地雷だらけのブラウザの上で生活できるやつって頭おかしい
Re: (スコア:0)
獣姦画像.zipみたいなファイルを公開する。獣姦画像.zip/icon.scfのような構造にしておく。
何も知らずに解凍してフォルダを開いたアホが引っかかる。
現状でもセキュリティに配慮している人はクロームでもダウンロードする前にファイル名などを確認できるようにしているので問題ないだろう。セキュリティへの配慮が足りない人は何やっても無駄。 そのうちセキュリティソフトが対応するだろうしセキュリティソフトの対応もかんたんだからまあもんだいないだろう。
Re: (スコア:0)
https://srad.jp/comment/3212343 [srad.jp]
https://srad.jp/comment/3212395 [srad.jp]
https://srad.jp/comment/3212425 [srad.jp]
ユーザに無断で実行ファイルだろうがDLLだろうが勝手にダウンロードするってのは脆弱性と呼ぶに充分だと思う。
Re: (スコア:0)
うるせぇな、Googleに文句いうんじゃねぇよ
Googleは何があっても正しいから全部MSが悪いに決まってるだろ
って言いたかっただけでしょうから真面目に答えてもしゃーないですよ
自分なりに整理 (スコア:1)
①Chrome はデフォルトで保存先を指定させずにダウンロードする
（これは別に他のブラウザでもそうだし、設定次第ですね）
②レスポンスのテキストに %0B が含まれるとファイルとしてダウンロードしてしまう
（これは Chrome だけの動き）
③細工した SCF ファイルを実行させることで攻撃者にユーザ名とパスワードハッシュが知られる
（これは意図した動作ながら、Windows の問題）
今回問題なのは②で、これだけは Chrome の問題だと思います（何故こんな実装になってるんだろう……）
ただ根本的には③で、グローバルにアクセスするならその前に確認メッセージの表示とかあってもいいかもしれませんね。
Re: (スコア:0)
>③細工した SCF ファイルを実行させることで攻撃者にユーザ名とパスワードハッシュが知られる
実行せずとも保存先フォルダを表示させるだけで情報送信されるってことじゃない？
Re: (スコア:0)
ご指摘ありがとうございます。
再度読み直しましたが、ご指摘の通りです。
> 実行せずとも保存先フォルダを表示させるだけで情報送信されるってことじゃない？
フォルダを開いた時点でアウトということで、やはり根本的には Windows 側での対応が必須ですね。
ZoneID ぐらいは見てくれているのだろうか……
Re: (スコア:0)
②と③の間に入るはずの決定的かつ致命的な欠陥が抜けている。③も間違ってるがそっちについては他の人が指摘しているので省く。
①と②は正しい。レスポンスのテキストに %0B が含まれるとファイルとしてダウンロードしてしまうという使用に加えてデフォルトだとダウンロードスべきと判断したファイルを自動的にダウンロードする。一般的なブラウザならダウンロードスべきと判断したファイルをダウンロードするか確認してくる(どこにダウンロードするかは聞かないでダウンロード先を勝手に決めるが)。これがクロームの場合確認せずに自動的にダウンロードダウンロードする。
そして細工されたSCFファイルをエクスプローラーが読み込んだ段階でSMB認証情報が漏洩する。
つまりクロームのダウンロード関連の設定をデフォルトの設定で利用している一般人が細工されたSCFファイルへのリンクを開いた瞬間手遅れ。ダウンロードしてしまった場合はエクスプローラー以外のソフトでファイルを削除するしかない。エクスプローラーで削除するなら多分ユーザフォルダのダウンロードごと消すしかないな。
Re: (スコア:0)
まあ, エクスプローラーを使ったまわりくどい方法もあるにはあるかな．
ネットワークを切断した状態でエクスプローラーで該当ファイルを消す．
このとき，認証情報は送られそうになるが，ネットワークが切れているのでとりあえず防げる．
そして，そのまま接続を回復すると良くない可能性がある(認証情報を送るのは windows だろうけど，繋がるまで再送を待ってる？)ので，いったんシャットダウン．
こんなところでどうだろう？
Re: (スコア:0)
もうちょっとtypoなんとかして欲しいがw重大なリスクはそこか。
Chrome以外のブラウザはデフォルト状態では、意図しないファイルのダウンロード前にユーザーが止めさせることができる。
ダウンロードが完了してしまうと、この脆弱性を突かれていることに気付いていないユーザーは高確率で次のステップをクリアする。
こりゃ自分もやられるな。
Chrome的には、下部のダウンロードバーから要らないファイルはキャンセルしろなのかな…と思ったがダウンロード済みファイルを削除とかはできないのか。
Re: (スコア:0)
ふと思ったんだけどIEやEdgeのキャッシュフォルダとか大丈夫だろうか？
拡張子をそのまま保持してファイル保存されていると思うのだが。
Re:自分なりに整理 (スコア:1)
ただ、Explorerで開いては駄目なフォルダの意味が全然違う。
■Chromeの場合
%USERPROFILE%\downloads
■IEの場合
%USERPROFILE%\AppData\Local\Microsoft\Windows\INetCache
■Edgeの場合
%USERPROFILE%\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AC\MicrosoftEdge\Cache
%USERPROFILE%\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AC\#!001\MicrosoftEdge\Cache
%USERPROFILE%\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AC\#!002\MicrosoftEdge\Cache
Chromeの場合日常的に開く可能性があるパス。
IEの場合はインターネットオプションからパスが見えているがExplorerではそうそう開かない。
Edgeに至っては設定画面ではパスの変更どころかどこに保存されているかの表示さえない。
まあ要するにこのパスを調べた私みたいなのしか影響しない。
ルーター (スコア:1)
WannaCryの時もちょっと話題になったけれど、ルーター挟んでインターネットに接続している環境なら
137-139とか445はアウトバウンドも大抵閉じられているから実害は無いのかな？
Re: (スコア:0)
どうせ社内だけの話だからなんでもいいやと思って、他のと同じパスワードにしているという可能性は？
Re: (スコア:0)
「パスワードはユーザー名と同じです」
Re: (スコア:0)
> どうせ社内だけの話だからなんでもいいやと思って、他のと同じパスワードにしているという可能性は？
そんな可能性は考えなくてよい
137-139とかが閉じられていればそもそもSMB認証情報が外部に送信できない。つまりSMB認証情報は漏れない。
漏れないのに、漏れた場合とか、それが他のと同じパスワードだとか、そんな話は今回はオフトピックそのもの
もう少し考えてからコメントしたほうがいいよ
Re: (スコア:0)
漏れそうな気がするけれど。
Re: (スコア:0)
問題になるのは、PC に直接モデムつないで通信するような奴だね。
スマホの WiFi テザリングは問題なくとも、USBの 3G/LTE モデムで通信してる人は危ない。
まぁ、そういう環境の人は、今回の件関係なく侵入されるリスクが高いのはわかりきってる事なのだから、対策はとってるはず。
Re: (スコア:0)
業務用だと Active Directory(135)をふくめて、開いているんじゃないかな。
ちゃんとした企業だとVPNやSSLを利用するだろうけど。
いろいろ微妙 (スコア:1)
SMBの認証情報の漏洩は他にもいくつか発見されててて今さら感があるが、攻撃事例も聞かない。
チャレンジ-レスポンス認証の情報は通常覗き見られる前提で設計されるものだし。気持ち悪いけどね。
この攻撃はSMB認証情報を組織ネットワークの外部から取得できることに意味があるが、
それをするにはルータでSMBのポートを開いてないといけないので、これが通用するのはだいぶ間抜けな組織だろう。
元サイトのRecommendationsで以下のように記載されているのがまさにそれで、通常の組織ではすでにやっていることだ。
With the first two the goal is to prevent SMB traffic from leaving the corporate environment by blocking ports that can be used to initiate
a connection with a potentially malicious Internet-based SMB server. When possible, SMB traffic should always be restricted to private networks.
Windowsは牧歌的な時代に設計された機能が知らないうちに動いていて、いろいろ危なっかしいところもあるけども、これに関しては大したことはなさそう。
Re: (スコア:0)
> これが通用するのはだいぶ間抜けな組織だろう。
その間抜けな組織でなければWannaCryにも感染しなかったはずだが
Re:いろいろ微妙 (スコア:1)
逆にこれ、パスワードハッシュ取り出しに使えませんか？ (スコア:0)
AnnivarsaryからNTLMハッシュを取り出す手順がまた少しややこしくなった。それ用のツールはあるにはあるけど、ウィルス対策ソフトが動いていると使えないし。ハッシュを受け取るサーバを用意するか、パケットキャプチャーをすればいいだけならずっと楽。皆どうしてるんだろ？
しかしハッシュ関数がMD4のままなのに、暗号化だけ強化するってなんなんだろう。SYSTEMとSAMが同じフォルダにあるのに片方しか読み出さないとか、レジストリエディタが起動できるのに片方しかダンプしないなんてことあるのだろうか。