初めて、2000年代半ばにsmbrelayに出会い、私の知り合いは失敗しました。 その時点では、その時点でもとにかく機能するいくつかのエクスプロイトしかありませんでした。 これは、プロトコルの脆弱性が90年代後半に発見されたという事実にもかかわらずです。 期待した結果が得られず、すべての関心が完全に失われました。
しかし、ほんの数週間前に、この問題を再度調査したいという要望がありました。 全般的に状況は変わらないことが判明しましたが、新しいエクスプロイトが登場し、そのパフォーマンスを確認しました。
SMBの脆弱性に精通していない人のために、その本質を思い出しましょう。 被害者を攻撃者のsmbリソースにログインさせることにより、攻撃者は認証データを被害者自身にリダイレクトし、それによりディスクにアクセスし、プロセス間通信サービスを介して任意のコードを実行できます。
元の形式のこのような深刻な脆弱性は、2008年の終わりまで、まともな正常動作のエクスプロイトが登場するまで持続したことは注目に値します。
パッチは、同じチャレンジで着信接続を受け入れることを禁止しています。これは、発信接続ですでに使用されています。 つまり 被害者の中継自体がカバーされました。
しかし、攻撃を受けた被害者がアクセスできる3番目のリソースに許可をリダイレクトすることを妨げるパッチはありません。
Tarasco Security smbrelay3は、この脆弱性に対する一連の高度な悪用方法を導入しました。 従来のsmb-> smbスキームに加えて、HTTP \ IMAP \ POP3 \ SMTPなどのサービスからの認証リダイレクト方法が追加されました。 それらはすべて、NTLMによる認証をサポートしています。
パッチが適用されていないWindows XP SP3では、犠牲者を自分自身にリダイレクトする場合でも、cmd.exeは問題なく実行できました（MS08-068の修正は後で発表されました）。
XPからWindows 2003への承認のリダイレクトも成功しました（適切なアクセスを使用）。
しかし、Windows XPはすでに過去の一部であり、Windows 7がクライアントOSとして使用される現代のネットワークでsmbrelayを操作することに興味がありました。
このテキストが書かれたために、ここで多くの質問と多くのニュアンスが生じました。
最初の問題は、Windows 7では、デフォルトで「LAN Manager認証レベル」が「NTLMv2応答のみを送信する」に設定されていることでした。 そのため、既存のsmbrelay実装（smbrelay3およびMetasploitの対応するモジュールを含む）はすべて、NTLMv2承認の中継をサポートしていないことが判明しました。 明らかに、これは以前は必要ありませんでしたが、後でこのサポートを追加することを誰も気にしませんでした。
smbrelay3ソースコードに必要な変更を加えることにより、NTLMv2はWindows 7からWindows XPに正常にパッチされました。 しかし、次の警告が出ました。
IEが更新されたWindows 7では、イントラネットの概念の意味が変わりました。 以前は単純でしたが、ワークグループで「some_host」という形式のネットワーク名がローカルセグメントのIPアドレスに解決される場合、イントラネットに配置され、アクティブなセッションのデータを使用して自動的に認証できます。 IE 7のプロパティには、「イントラネットネットワークを自動的に検出する」というデフォルトオプションがあるため、このイントラネットネットワーク検出モードでは、通常のワークグループは内部の信頼できるネットワークに属しておらず、したがって信頼できないゾーンであるため、自動認証はありません起こります。 しかし、Windows 7はドメイン内にあるため、ローカルネットワークから任意のコンピューターに必要なすべてのデータを喜んで提供します。
したがって、イントラネット検出オプションが有効になっている場合、ワークグループ内のWin7はsmbrelay攻撃の影響を受けませんが、ドメイン内で脆弱になります。
3番目のホストへのデータのリダイレクトにより、多くの場合、ドメイン内の状況を想像できます。たとえば、管理者のコンピューターへの攻撃後にドメインコントローラーをキャプチャすることが可能です。
残念ながら、少なくともデフォルトのコントローラー構成では、これは不可能です。 smbrelay攻撃をブロックする非常に簡単な手段-SMB署名があり、ドメインコントローラーはクライアントにパケット署名の使用を要求します。 この場合、コントローラー自体へのリダイレクトされたセッションは拒否されます。 パスワードを知らずに署名を偽造することは不可能です。
場合によっては、管理者が意図的にSMB署名を無効にします。これは、 強制暗号化はより多くのリソースを必要とし、共有ファイルへのアクセスの帯域幅を削減します。
攻撃を成功させるための前提条件は、IPC $およびADMIN $の管理リソースへのアクセスが可能であることです。これらがないと、他のリソース（C $ ...）を「いじり回す」機能は残りますが、リモートでコードを実行する可能性はありません。
概して、このレビューは完了することができます。各ステップを詳細に検討しても意味がありません。 多くはすでに数年前に説明されています。 Windowsファミリの最新のOSに関する情報を更新しました。
この調査の結果、Intercepter-NGの一部としてsmbrelay攻撃を実行するための安定したモジュールが実装されました。 ポート445で実行されているサーバーサービスに関連する問題を回避するために、攻撃はHTTP-> SMBの方向で行われます。 つまり 接続が着信すると、ブラウザにNTLM認証が提供され、後で同じホストまたは他のホストにリダイレクトされます。
攻撃を実行する際の主な問題は、常に被害者を私たちのリソースに誘い込むタスクでした。これは主に、ettercapの使用やWebトラフィックのなりすましを介して、電子メールを送信するか、悪意のあるリンクを含むファイルを共有リソースにアップロードすることによって行われました。
私たちの場合、最後のオプションが最速かつ最も効果的なものとして選択されました。 ターゲットが選択された後、Arp Poisonが実行され、リクエストに応じてsmbrelay攻撃が実行されるWebトラフィックにリンクが挿入されます。 プロセス全体が自動化されており、介入は不要です。 安定した静かな注入のために、追加ではなく置換方法が選択されたため、<！DOCTYPE ...>、<meta name = "keywords" ...>および<meta name = "などの「不要な」HTMLコードセクションが置換されます。説明»...>。 ほとんどのサイトには少なくともそれらの1つが含まれているので、長く待つ必要はありません。
さらに、IE \ ChromeのみがNTLMを介した自動認証をサポートしているため、FireFox \ Operaへの攻撃は失敗します。
以下のビデオデモをご覧ください。
結果。 SMBRelayは今でも緊急の問題であり、攻撃者がローカルネットワークに侵入するための深刻なツールになる可能性があります。
クライアントコンピューターへの攻撃を防ぐには、適切なレジストリキー「EnableSecuritySignature、RequireSecuritySignature」を使用してSMB署名を有効にします。
提供される情報は、情報提供のみを目的としています。 著者は、この記事の資料によって引き起こされる可能性のある損害について責任を負いません。
更新：承認をリダイレクトしようとしたときに、条件の1つが満たされなかった場合（リソースへの管理リソースまたはアカウントアクセスが直接ない場合）、NTLMSSPハッシュと攻撃されたユーザーのチャレンジがあり、ブルートフォースになる可能性があるかどうかを明確にするのを完全に忘れました。
現代のWindowsネットワークにおけるSMBRelay攻撃の関連性
All Articles