Одна заглавная буква может стоить всей корпоративной сети – древняя проблема Fortinet снова в прицеле хакеров

Fortinet предупредила администраторов о том, что в реальных атаках вновь начали злоупотреблять уязвимостью FG-IR-19-283 (CVE-2020-12812), известной с июля 2020 года: при определённых настройках FortiGate можно обойти двухфакторную аутентификацию и войти «как будто 2FA не существует». Компания описывает механизм обхода и объясняет, как быстро проверить, не попадает ли ваша конфигурация в группу риска.

Суть проблемы в том, что FortiGate по умолчанию считает имена пользователей регистрозависимыми, а LDAP-каталог — нет. Из-за этой разницы устройство может «не узнать» пользователя, если он введёт логин с другой комбинацией заглавных и строчных букв, и тогда начнёт искать альтернативные способы аутентификации по другим правилам, которые администратор включил в политики доступа.

Сценарий, при котором возникает уязвимость, завязан на сочетание локальных учётных записей на FortiGate с включённой 2FA и привязкой к LDAP, а также на использование LDAP-групп в политиках аутентификации (например, для админ-доступа или для SSL/IPsec VPN). Дальше всё упирается в «похожий, но не такой» логин: если пользователь входит в VPN как jsmith, FortiGate находит локальную запись и запрашивает токен.

Но если тот же человек (или злоумышленник с его паролем) вводит Jsmith, jSmith или любую другую комбинацию, которая не совпадает с регистром в локальной записи, FortiGate не сопоставляет логин с локальным пользователем и переключается на другие варианты — например, на аутентификацию через вторую, отдельно настроенную LDAP-группу. При корректных учётных данных вход проходит уже через LDAP, и настройки локального пользователя вроде 2FA или даже отключённой учётки могут быть фактически проигнорированы.

В результате администраторы или пользователи VPN могут аутентифицироваться без второго фактора. Fortinet отдельно подчёркивает: если есть основания полагать, что обход уже использовали, конфигурацию системы следует считать скомпрометированной, а затем сбросить все учётные данные — включая те, что применяются для привязки к LDAP/AD.

Защиту от такого поведения добавили ещё в 2020 году: соответствующие изменения вошли в FortiOS 6.0.10, 6.2.4 и 6.4.1. Если обновиться на эти версии (и новее) по какой-то причине нельзя, Fortinet рекомендует явно отключить регистрозависимость для логинов на локальных учётных записях. В более ранних ветках это делается настройкой username-case-sensitivity в значение disable, а в более поздних версиях (начиная примерно с FortiOS 6.0.13, 6.2.10, 6.4.7, 7.0.1 и выше) используется параметр username-sensitivity со значением disable. После этого FortiGate будет считать jsmith, JSmith и любые варианты написания одним и тем же пользователем, что не даст устройству «провалиться» в альтернативную LDAP-аутентификацию из-за несовпадения регистра.

Отдельно Fortinet указывает на корень проблемы с практической точки зрения: ситуацию часто делает возможной вторичная LDAP-группа, которая подхватывает аутентификацию, когда проверка локального пользователя не срабатывает. Если такая группа не нужна для бизнеса, её лучше убрать из конфигурации. А если LDAP-группы в политиках аутентификации вообще не используются, то и обхода через LDAP-группу не останется — при несовпадении логина с локальной записью аутентификация просто завершится отказом.