RDP: слабые места протокола и эксперимент с развертыванием ханипота

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




    Когда бизнес переходил на удаленку, выбор компаний пал на протокол RDP из-за простоты его настройки и использования. Но переход был экстренным и далеко не все уделили необходимое внимание безопасности. В результате организации оказались под прицелом злоумышленников.

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

    ▍Слабости RDP


    Почти 4 миллиона RDP-серверов по всему миру сегодня доступны из внешней сети. Не меньшее их количество, скорее всего, доступно лишь из внутренних сетей.

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

    Брутфорс-атаки


    Самые распространенные атаки на RDP — атаки типа брутфорс. Их можно условно разделить на несколько групп.

    1. Простейшие атаки, которые заключаются в подборе элементарных паролей без использования каких-либо инструментов автоматизации.
    2. Атаки по словарю, во время которых запускается перебор всевозможных паролей для предполагаемого имени пользователя.
    3. Гибридные атаки, которые включают использование словарей, но каждый пароль проверяется не только в словарной форме, но и после ряда простых модификаций.
    4. Password spraying, во время которых для известного пароля перебираются миллионы имен пользователей, пока не найдется совпадение.
    5. Credential stuffing, при которых для перебора злоумышленники используют список скомпрометированных учетных данных пользователей.

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

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

    В то же время про атаки password spraying и credential stuffing зачастую забывают. Однако подобные атаки сейчас не редкость, а, напротив, скорее стали обыденностью. Бороться с ними помогает блокировка IP-адресов, с которых производятся множественные неудачные попытки входа по RDP. Также не станет лишним запрет на повторное использование паролей. Кроме того, не стоит использовать один и тот же пароль на нескольких ресурсах.

    Уязвимости


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

    Уязвимость CVE-2019-0708, получившую название BlueKeep, обнаружили не в самом протоколе RDP, а в реализации службы удаленных рабочих столов (Remote Desktop Service). Данная уязвимость позволяет неаутентифицированному пользователю удаленно исполнить произвольный код на целевой системе. Уязвимости подвержены старые версии Windows: начиная с Windows XP (Windows Server 2003) и заканчивая Windows 7 (Windows Server 2008 R2). Для ее успешной эксплуатации необходимы лишь сетевой доступ к компьютеру с уязвимой версией Windows и запущенная служба RDP. Для этого злоумышленник отправляет специально сформированный запрос к службе по RDP, что позволяет атакующему удаленно выполнить произвольный код на целевой системе. Информация о BlueKeep была опубликована в мае 2019 года, но уязвимыми до сих пор остаются более 289 тысяч RDP-серверов.

    Уязвимости CVE-2019-1181/1182/1222/1226 практически аналогичны BlueKeep. Однако если предыдущей уязвимости были подвержены лишь старые версии Windows, то теперь под угрозой оказались и все новые версии ОС. Для эксплуатации уязвимостей злоумышленнику также достаточно отправить специально сформированный запрос к службе удаленных рабочих столов целевых систем, используя протокол RDP, что позволит выполнить произвольный код. Эти уязвимости были опубликованы в августе 2019 года.

    Еще одна уязвимость — BlueGate (CVE-2020-0609/0610) — была найдена в компоненте Windows Remote Desktop Gateway в Windows Server (2012, 2012 R2, 2016 и 2019). Она также позволяет злоумышленникам посредством RDP и специально созданных запросов осуществлять удаленное выполнение кода на целевой системе. BlueGate была опубликована в начале 2020 года.

    ▍Вредоносные программы и RDP


    Слабости RDP не остаются вне поля зрения операторов вредоносных программ. Злоумышленники нередко используют ставшие известными учетные данные RDP при проведении целевых атак.

    После получения доступа по RDP к целевой системе атакующие вручную отключают средства антивирусной защиты и запускают вредоносные программы. В подобных атаках на зараженной системе зачастую запускаются программы-вымогатели, такие как Dharma (aka Crysis).

    ▍Приманка для злоумышленников, или как мы развернули ханипот


    Мы решили провести эксперимент и проверить, что будет происходить с RDP-сервером, доступным из внешней сети. Для этого было развернуто два ханипота. Мы воспользовались реализацией протокола RDP на Python — RDPY, который можно найти в открытом доступе.

    Один ханипот был развернут на публичном сервере DigitalOcean, другой — на сервере в сети нашей организации. Из интернета были доступны три порта:

    • стандартный порт — 3389;
    • два нестандартных порта — 36 и 25300.

    Окно, отображаемое при подключении, приведено на скриншоте ниже.



    Максимальное внимание в сети привлек стандартный порт 3389. За те полтора месяца, что работали ханипоты, в общей сложности зафиксировано 15 попыток брутфорса и 237 попыток записи невалидных данных в сокет на публичном сервере; и, соответственно, 16 и 135 попыток — на сервере в сети организации.

    Также, как и следовало ожидать, стандартный порт 3389 подвергался многочисленным сканированиям из сети. При этом публичный сервер сканировался в среднем в 2,5 раза чаще, чем сервер в сети организации.

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


    По горизонтали — дни работы ханипотов, по вертикали — количество коннектов.
    Синяя кривая — публичный север, оранжевая — сервер в сети организации.
    Вертикальные линии — сб и вс
    .


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

    ▍Безопасность


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

    1. Выбирайте нестандартный порт для предоставления подключения по RDP. Как показывает практика, стандартный порт чаще других подвергается сканированиям и попыткам входа со стороны нежелательных пользователей. Тем не менее один только нестандартный порт не может полностью защитить от проведения атак.
    2. Организуйте удаленное подключение к корпоративным ресурсам через VPN. Это обеспечит дополнительный уровень защиты, поскольку без доступа к VPN будет невозможно провести брутфорс-атаки.
    3. Применяйте строгие парольные политики, которые накладывают ограничение на длину пароля, его содержание, повторное использование, а также количество неудачных попыток входа, после которых производится блокировка учетной записи. Это поможет защититься от атак перебором. Запрет же повторного использования пароля снизит риск реализации атак password spraying и credential stuffing.
    4. Блокируйте IP-адреса, с которых производятся множественные неудачные попытки входа по RDP. Это позволит защититься от атак password spraying и credential stuffing.
    5. Используйте двухфакторную аутентификацию. Это сведет к минимуму реализацию всех типов брутфорс-атак.
    6. Настройте аудит событий RDP и проводите регулярный просмотр журналов подключений, чтобы вовремя регистрировать подозрительную активность.




    ▏Где искать следы подключения по RDP▕


    Если у вас возникли подозрения о компрометации системы по RDP, можно попробовать самостоятельно выполнить несколько шагов.

    1. Логи. В первую очередь следует немедленно проверить логи событий:
      • %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx

        Событие 1149 для успешного подключения до аутентификации с использованием логина и пароля, но после аутентификации IP-адреса источника подключения. Важно искать подключения с необычных IP-адресов, сюда же может попасть перебор паролей.
      • %SystemRoot%\System32\Winevt\Logs\Security.evtx

        Событие 4624 — для успешного входа, 4625 — для неудачного входа, 4778 — для переподключения, 4634 — для отключения. Стоит обратить внимание на «LogonType». Для удаленных подключений оно будет равно 3, 10 или 7. Здесь необходимо искать успешные события входа с необычных IP-адресов, обращать внимание на неуспешные события входа — это может быть атака перебором.
      • %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx

        События 21, 22 и 25 — для успешного входа или переподключения, 23 — для отключения. Следует искать события с необычных IP-адресов.

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

      Нередко злоумышленники чистят логи. При этом чаще всего чистят только Security.evtx, чуть реже — Security.evtx и Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx сразу. По этой причине крайне желательно просматривать все три лога, а лучше заранее настроить перенаправление событий в SIEM-систему.
    2. Сессии легитимных пользователей. Практически всегда злоумышленники, которые занимаются распространением шифровальщиков, начинают изучение внутренней сети своей жертвы почти сразу после проникновения. Иногда им удается переподключиться к уже имеющимся сессиям RDP-серверов, доступных из внутренней сети. Это может произойти, когда подключение легитимного пользователя уже установлено, но на уровне TCP оно разорвано (например, было закрыто окно RDP). В этом случае при повторном подключении сессия восстанавливается и злоумышленник входит на сервер. Это означает, что в логе можно увидеть, что подключение инициировано легитимным пользователем в день X, а в день X+N с той же машины уже переподключится атакующий. Поэтому следует смотреть не только на события установки подключений, но и на события переподключений и отключений.

    Если следы обнаружены


    В случае обнаружения следов успешного проникновения через RDP необходимо в первую очередь:

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

    Есть существенная вероятность, что заражение уже распространилось по внутренним ресурсам. Если это произошло, нужно проверять события запуска PowerShell, срабатываний антивирусов и прочие. А лучше всего — сразу обратиться к специалистам по компьютерной криминалистике.
    BI.ZONE
    Компания

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

      +2
      Вся статья тянет на школьный реферат.

      Подобрав пару логин-пароль, злоумышленники получают полный доступ к скомпрометированной системе.
      Ну у Вас там видимо все под локальными админами работают.

      Например, часто предусматривают блокировку учетной записи после нескольких безуспешных попыток входа.
      Передаю привет вашим административным учетным записям находящимися под целенаправленной атакой.

      Событие 4624 — для успешного входа, 4625 — для неудачного входа
      Понимаю, в Security лог зайти зашли, почитали что первое попалось, и зафигачили в статью. Смотреть удачные события в входу и выходу из системы нужно по событиям
      Get-WinEvent -ComputerName $Computer -FilterHashTable @{LogName="Security";id=4801,4800,4778,4779}
      так что попали только в одно событие из четырех.
        0
        В статье описаны ситуации из реальных расследований хакерских атак, которые зачастую заканчивались запуском шифровальщиков из под имени доменного администратора на множестве систем во внутренней сети. И вы правы, не всегда похищенные учетные данные сразу давали локального администратора на системе, но получить эти привилегии для злоумышленников не составляло проблемы.

        По поводу событий входа. Перечисленные вами события — это частные случаи, покрывающие не все сценарии. Лучше ориентироваться именно на перечисленные нами — они покрывают все описанные случаи. Про события 4624, 4625, 4778, 4634 в контексте RDP хорошо написано тут:
        ponderthebits.com/2018/02/windows-rdp-related-event-logs-identification-tracking-and-investigation
        www.andreafortuna.org/2020/06/04/windows-forensic-analysis-some-thoughts-on-rdp-related-event-ids
          0
          Если бы я не занимался этим вопросом достаточно плотно, особенно глубоко с началом ковидной эпидемии, я бы с Вами наверняка согласился. Но дьявол кроется в нюансах, и события 4624-4625 это как проверка насколько глубоко специалист копал тему. Если Вы цепляетесь за 4624-4625 то это не очень глубоко, эти события просто пыль закрывающая истинную цель. Это уже не говоря о том, что отслеживание неудачных попыток входа через RDP в Get-WinEvent для ОС Windows 2008R2 / 2012R2 / 2016 + 2019 довольно ощутимо различается. Код показывающий подлецов в 2008R2 слеп на 2019, и это правило взаимообратно. Но Вы не копали настолько глубоко.

          А ругаюсь, потому что Вы отправляете людей грызть гранит не с той стороны.
        0
        Так в чём эксперимент-то? В том, что машину в выставленным наружу RDP начинают пячить? Тоже мне бином Ньютона. Кроме того, смена порта не панацея, а лишь отсрочка катастрофы.
          0
          Согласны с вами, и в статье мы отметили, что «тем не менее один только нестандартный порт не может полностью защитить от проведения атак».
          0
          Я предлагаю подходить к этой проблеме со стороны 2FA, но при этом второй фактор делать порткнокингом или его развитием.
          Это довольно просто со стороны пользователя — он перед подключением просто открывает урл в браузере, который и активирует порткнокинг. Часть маршрутизаторов уже умеют это из коробки (у микротика, кажется, есть такая функция), но в целом это не так уж сложно в реализации и самостоятельно.
          А также к достоинствам можно отнести, что это будет работать везде в отличие от впн, когда встречаются провайдеры, его блокирующие (особенно смешно, когда провы объясняют блокировку впн заботой о нашей безопасности).
            0
            Не так сложно?

            Я искал варианты решений. Есть много сайтов, которые предлагают сделать это за $$$, но например как прикрутить 2FA к Windows я так и не нашёл.

            С порт-кнокингом тоже было бы зачётно, но и тут: простых и понятный решений не нашёл.

            Так что, реквестирую статью на Хабре на этим темам.

            Своим опытом с RDP я уже делился вот тут:
            habr.com/ru/post/487056
            0

            Способ защиты от брутфорса на уровне вышеупомянутого реферата: перенести всё на нестандартные порты, и прямо на входе блокировать сразу все ІР которые лезут на 22,3389, и что там у вас ещё.

              0
              Почему нет совета выпускать rdp в интернет только через шлюз удаленных рабочих столов?
                0
                шлюз добавляет еще одну потенциально дырявую службу, тем более 443 порт будут искать еще чаще. в итоге получим бОльший геморой чем с обычным RDP
                0
                Какие риски возникают, когда пользователь запускает rdp сессию с домашнего ПК, на котором нелицензионная Windows и нет антивируса?

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

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