RDP в Windows позволяет использовать для входа старые пароли, и Microsoft не видит в этом проблемы

[WWW]

Исследователи обнаружили, что протокол RDP (Remote Desktop Protocol) в Windows позволяет использовать уже отозванные пароли для входа в систему. В ответ на это представители Microsoft сообщили, что такое поведение не является уязвимостью, в компании не планируют что-либо менять.



Хотя смена пароля — один из первых шагов, которые следует предпринять в случае утечки пароля или взлома учетной записи, в случае с RDP все может быть не так просто.



Как сообщает издание ArsTechnica, независимый ИБ-исследователь Дэниел Уэйд (Daniel Wade) обнаружил, что во многих случаях RDP будет продолжать доверять паролю даже после того, как пользователь его изменил. Эксперт уведомил о проблеме представителей Microsoft и составил пошаговую инструкцию для воспроизведения такого поведения.



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

«Это не просто ошибка. Это полный подрыв доверия, — пишет эксперт в своем отчете. — Люди верят, что смена пароля отсечет несанкционированный доступ. Это первое, что делает человек, заподозривший компрометацию. И все же:

• старые учетные данные продолжают работать в RDP даже с совершенно новых машин;

• Defender, Entra ID и Azure не отображают никаких предупреждений;

• у конечных пользователей нет никакого способа для обнаружения и устранения проблемы;

• нет документации или руководств Microsoft, которые напрямую рассматривали бы подобные сценарии;

• даже более новые пароли могут игнорироваться, тогда как старые продолжают работать.

Результат? Миллионы пользователей (дома, на малых предприятиях или в гибридных средах) неосознанно подвергаются риску».

Возможность использования отозванного пароля для входа через RDP возникает в том случае, если Windows-машина, подключенная к учетной записи Microsoft или Azure, разрешает удаленный доступ к рабочему столу. В этом случае пользователи могут входить в систему через RDP, с помощью специального пароля, который сверяется с локально хранящимися учетными данными. Также пользователи могут войти в систему, используя данные онлайновой учетной записи, которая использовалась для входа на машину.







Проблема заключается в том, что даже после смены пароля тот остается действительным для входа через RDP на неопределенный срок. По словам Уэйда, встречаются случаи, когда некоторые старые пароли продолжают работать, а новые — нет. В результате можно иметь постоянный доступ к RDP в обход облачной верификации, многофакторной аутентификации и политик Conditional Access.



Исследователь поясняет, что такое поведение может обернуться большими потерями в случае, если учетная запись Microsoft или Azure скомпрометирована, и пароли стали достоянием общественности. В такой ситуации первым делом нужно сменить пароль, чтобы не дать злоумышленникам возможности использовать его для доступа к важным ресурсам. Однако если смена пароля не позволит атакующим войти в учетную запись Microsoft и Azure, то старый пароль все равно будет предоставлять доступ к машине через RDP.

«Это создает незаметный удаленный бэкдор к любой системе, где когда-либо был кеширован пароль, — пишет Уэйд. — Даже если у злоумышленника никогда не было доступа к этой системе, Windows все равно будет доверять паролю».

Корень этой проблемы кроется в механизме кеширования учетных данных на жестком диске локальной машины. Так, при первом входе пользователя в систему с использованием учетных данных Microsoft или Azure RDP подтверждает действительность пароля в режиме онлайн. Затем Windows сохраняет учетные данные в криптографически защищенном формате на локальной машине.



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



В ответ на это представители Microsoft заявили, что описанное Уэйдом поведение является «конструктивным решением, призванным гарантировать, что хотя бы одна учетная запись пользователя всегда имеет возможность войти в систему, независимо от того, как долго она находилась в автономном режиме».



При этом исследователю сообщили, что он не первый, кто сообщил об этой проблеме, и Microsoft знает о ней уже около двух лет.

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

При этом подчеркивается, что такое поведение не является уязвимостью, и инженеры Microsoft не планируют ничего менять. Однако компания все же обновила онлайн-документацию, чтобы пользователи были лучше осведомлены о таком поведении. В обновлении говорится:

«Когда пользователь выполняет локальный вход в систему, его учетные данные проверяются локально с помощью кешированной копии, прежде чем пройти аутентификацию в онлайне, с помощью провайдера идентификации. Если проверка кеша прошла успешно, пользователь получает доступ к рабочему столу, даже если устройство работает в автономном режиме. Однако если пользователь меняет пароль в облаке, кешированный верификатор не обновляется, а значит, он все равно может получить доступ к локальной машине, используя старый пароль».

Как сообщил изданию известный ИБ-эксперт Уилл Дорманн (Will Dormann), большинство администраторов могут попросту не заметить это обновление. К тому же Microsoft не указывает, какие действия следует предпринять для блокировки RDP в случае взлома учетной записи Microsoft или Azure. По словам специалиста, единственным вариантом является настройка RDP на аутентификацию только по локально хранящимся учетным данным.

«С точки зрения безопасности это просто бессмыслица, — говорит Дорманн. — Если бы я был системным администратором, я бы ожидал, что как только я изменю пароль для учетной записи, старые учетные данные для нее больше нельзя будет использовать нигде. Однако это не так».

@ xakep.ru