Pull to refresh
83.99

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

Reading time 8 min
Views 20K
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, срабатываний антивирусов и прочие. А лучше всего — сразу обратиться к специалистам по компьютерной криминалистике.
Tags:
Hubs:
-5
Comments 11
Comments Comments 11

Articles

Information

Website
bi.zone
Registered
Employees
501–1,000 employees
Location
Россия