Способ обойти экран блокировки Windows на сеансах RDP

    На днях исследователь безопасности раскрыл детали новой уязвимости в протоколе удаленного рабочего стола Microsoft Windows (RDP).



    Уязвимость CVE-2019-9510 позволяет злоумышленникам на стороне клиента обойти экран блокировки в сеансах удаленного рабочего стола.

    Джо Таммариелло (Joe Tammariello) из Института разработки программного обеспечения Университета Карнеги-Меллона обнаружил данную уязвимость. Для использования уязвимости необходимо, чтобы для аутентификации RDP использовался Network Level Authentication (NLA). Кстати, именно NLA недавно сами Microsoft рекомендовали для защиты от уязвимости BlueKeep RDP (CVE-2019-0708).

    Как подтверждает Уилл Дорманн (Will Dormann), аналитик из CERT / CC, если аномалия сети вызывает временное разъединение RDP, когда клиент уже был подключен к серверу, но экран входа в систему заблокирован, то «после переподключения сеанс RDP будет восстановлен до предыдущего состояния (с разблокированным окном), независимо от того, как удаленная система была оставлена".

    «Начиная с Windows 10 1803 и Windows Server 2019, обработка RDP сеансов на основе NLA изменилась таким образом, что это может привести к неожиданному поведению в отношении блокировки сеансов», — объясняет Дорманн в своей статье.

    «Системы двухфакторной аутентификации, которые интегрируются с экраном входа Windows, такие как Duo Security MFA, также могут обходиться с помощью этого механизма. Любые баннеры входа в систему, применяемые организацией, также будут обойдены».

    Proof of Concept


    Видео от Леандро Веласко из исследовательской группы KPN Security, демонстрирующее, как легко использовать эту уязвимость.


    CERT описывает сценарий атаки следующим образом:

    • Пользователь подключается к системе Windows 10 или Server 2019 через RDS.
    • Пользователь блокирует удаленный сеанс и оставляет клиентское устройство без присмотра.
    • На этом этапе злоумышленник, имеющий доступ к клиентскому устройству, может прервать подключение к сети и получить доступ к удаленной системе без необходимости каких-либо учетных данных.

    Это означает, что использование этой уязвимости очень тривиально, поскольку злоумышленнику просто нужно прервать сетевое подключение целевой системы.
    Однако, поскольку злоумышленнику требуется физический доступ к такой целевой системе (то есть активному сеансу с заблокированным экраном), сам сценарий подходит к очень ограниченному числу кейсов.

    Таммариелло уведомил Microsoft об этой уязвимости 19 апреля, но компания ответила, что «поведение не соответствует Microsoft Security Servicing Criteria для Windows», что означает, что технический гигант не планирует исправлять проблему в ближайшее время.

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

    Подробнее
    Реклама

    Комментарии 26

      +7

      На mac OS найдена огромная уязвимость! Оказывается в систему можно войти без пароля! Вы ждете пока жертва залогинится и выйдет в туалет, потом садитесь с рабочий стол жертвы и о ужас! ОС не понимает чюжеродного вмешательства и не спрашивает у вас пароль!

        +4

        И… Закрытие этой уязвимости приведёт к падению производительности устройств на 40%!

          +1

          И необходимости в конце рабочего дня чистить за собой стул.

          0
          Надо всего лишь докупить AppleWatch и вы будете защищены от этой уязвимости :)
            +1

            О! А это хорошая идея для статьи "Для закрытия критических уязвимостей в ОС Apple требует от пользователей покупки новых девайсов"

          +5
          Если учесть, что подавляющее большинство людей сохраняют параметры подключения по RDP в Диспетчере учетных данных Windows, то критичность данной проблемы надумана чуть более чем полностью.
            0
            Тут больше применимо для обхода всяких там двухфакторных методов типа Duo Security.
              +1
              Вот читаешь, вроде страшно, ибо двухфакторка получается уязвима. Но стоит чуть чуть подумать — двухфакторку используют не для того, что бы оставлять систему не залоченной, когда от нее отходят. Двухфакторка административно обязывает, отрывая задницу от стула, блокировать систему. В итоге опять приходим к тому, что критичность данной проблемы надумана чуть более чем полностью.
                +1
                Ну… Кейсов есть немного. Например, когда RDP на фулскрин развернут. Ты локнул его и пошел себе. Или у тебя куча рдп к разным сервакам и они автолочатся по идл тайму (хотя странный кейс, лучше по идл обрывать Коннект и закрывать сессию). Ну и вообще, культура лочить комп и двухфакторка, как по мне, не очень коррелирующие события. Даже наоборот, не буду лочить, а то потом долго логиниться.
                  +5
                  Win+L — глобальная комбинация и относится к консоли пользователя. В RDP не транслируется.

                  Культура лочить сеанс появляется не из-за строгости Сбшников, а из-за привычки коллег шутить, меняя десктопные картинки на с двумя парнями с надписью «Мы поражены твоим расп#здяйством».

                  Так что кейсов ничтожно мало, а требование физического доступа к оборудованию, плюс время на захват системы там внутри RDP подключения делают эту «атаку» мягко говоря турднореализуемой, и почти наверняка с 100% определением виновного.
                    0
                    Ой да лдно, в любом фильме про хакеров, это покажут.
                    Пока юзверь растяпа ходит в туалет, злобный хакер вылезет из под натяжного потолка, войдёт на удаленный сервер и скачает все секреты.
                    И конечно когда юзверь растяпа вернётся, хакер будет прятаться под столом и только чудом спасётся от обнаружения.
                      +3
                      Проще устроиться админом на 15к рублей и брать работы побольше, за всех работать, все коллеги будут на тебя работу скидывать радостно. Так добираешься до нужного сервера и сливаешь инфу. А потом такой, ой, мне тут на 16к работу предложили, все поцаны, я в другую контору. Никто даже не поймет.
                        0
                        Пока юзверь растяпа ходит в туалет, злобный хакер вылезет из под натяжного потолка, войдёт на удаленный сервер и скачает все секреты.

                        Ну, если уж серьезно говорить, «хакером» — могут быть вполне ваши коллеги по работе.
                        Очень наивно предполагать что все сотрудники фирмы априори неподкупны только потому что они договор подписали о секретных данных

                        Именно по этому нельзя давать свои учетки и пароли другим людям, нельзя пускать коллег по одному пропуску в помещение и т.п. Эти правила прридуманы отнюдь не из-за соображений — помучить персонал
                0
                Вход по сохраненному паролю можно запретить на стороне сервера
                  0
                  Точно? Я не помню что-то такой настройки. Да и откуда сервер должен знать сохранённый это пароль или введённый вручную?
                  Но вот на стороне клиента сохранение паролей RDP можно (и нужно) отключить через групповую политику. Через доменную, если машина в домене, или локальную, если не в домене (gpedit.msc).
                    0
                    Можно с сервера запретить сохраненный пароль.
                    В политиках узел сеансов -> безопасность -> всегда запрашивать пароль при подключении -> включить
                      0
                      Да, действительно, спасибо. В гуе эта галочка так же есть, другое дело что без описания не очень понятно что она значит (в описании политики конечно всё расписано подробнее).
                      0
                      Да и откуда сервер должен знать сохранённый это пароль или введённый вручную?
                      Догадываюсь, что стандартный виндовый клиент это ему сам сообщает при входе.
                        0
                        Похоже на то. Соответственно это и будет иметь влияние только на виндовые клиенты. Оно и понятно, если мы возьмём тот же freerdp под Linux, то там и понятия такого нет как «сохранённый пароль». А Remmina хоть и умеет сохранять учётные данные, но вряд ли будет сообщать об этом серверу.
                        0
                        Сервер и не знает — он просто запрашивает пароль в уже открытом RDP-окне. Своим стандартным логоном, не предусматривающим сохранение.
                        А клиент достаточно умный, чтобы не запрашивать пароль который всё равно не примут.
                    0
                    Всё больше и больше уязвимостей требуют прав администратора.
                      0
                      Имхо какая-то «детская» проблема. В том смысле, что обнаруживается на раз-два и всё равно не исправлена.
                        0
                        Проблема в том, что это не совсем проблема. RDP-клиент может переподключиться к машине, даже если она была целиком перезагружена.
                        0
                        А вот для автоматизации — пригодится ;)
                          0
                          Чаще всего пользователи RDP не имеют никаких прав, кроме открытия одной программы
                            0
                            Но чаще всего это программа содержит критически важные данные.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое