Security Week 36: Telnet должен быть закрыт

Telnet — это очень старый протокол. Википедия сообщает ^[1], что он был разработан в 1969 году, много лет активно использовался для удаленного доступа к компьютерам и серверам, причем как под управлением Unix/Linux, так и для систем под Windows (telnet можно было включить в Windows NT и в Windows 2000). Та же Википедия сообщает, что использование Telnet постепенно сошло на нет в пользу более защищенного протокола SSH. Так и вышло, не считая миллионов автономных сетевых устройств — в основном роутеров и IP-камер, которые «отвечают» по этому протоколу, зачастую без ведома владельца.

Две недели назад мы обсуждали уязвимости в роутерах Mikrotik ^[2]. Но то уязвимость — все же есть что взламывать. Опубликованное на прошлой неделе исследование ^[3] «Лаборатории Касперского» показывает, что большинство (три четверти) всех атак на IoT устройства — это атаки на протокол Telnet. Если ваше устройство отвечает по этому протоколу, тем более если он доступен из Интернета — подумайте, не пора ли это прекратить. Исключение только одно: если вы транслируете по Telnet «Звездные войны ^[4]».

Эксперты «Лаборатории Касперского» собирали статистику традиционным способом — при помощи ханипотов. Собственно, если собрать из любого подручного железа систему, отвечающую на 23 порте по протоколу Telnet, подключить ее к Интернету напрямую и подождать пару минут, вы увидите в логе попытки логина с использованием распространенных дефолтных паролей. Это зараженные ранее системы пытаются расширить ботнет, постоянно сканируя Интернет на наличие новых уязвимых устройств. Ханипоты, использованные для исследования, чуть сложнее: они не только регистрируют попытку залогиниться, но и фиксируют, что именно злоумышленники пытаются сделать после «успешного» проникновения.

Вот немного общих цифр. Количество вариантов вредоносного ПО для IoT-устройств постоянно растет: за 7 месяцев этого года зафиксировано почти в три раза больше модификаций, чем в 2017-м. Чаще всего пытаются атаковать протокол Telnet (75,40% всех атак), на втором месте SSH (11,59% — на нем тоже желательно как минимум отключить вход по паролю, а еще лучше — переназначить порт). Остальное (13,01%) — атака по иным протоколам, таким как кастомный интерфейс управления тех же роутеров Mikrotik.

Каждая пятая атака приводила к загрузке одного из вариантов вредоносного ПО для ботнета Mirai. Создателей ботнета уже поймали ^[5], но его исходный код был выложен в открытый доступ, так что поимка ответственных за начало эпидемии в 2016 году не смогла предотвратить дальнейшие атаки. Подробнее про Mirai можно почитать тут ^[6], но картинка ниже наглядно показывает, какими именно наборами логин —пароль ботнет пытается расширяться.

По этим парам вполне можно идентифицировать уязвимое устройство: IP-камера, телеприставка, цифровой видеорекордер, сетевой принтер и так далее. Между создателями ботнетов происходит определенная конкуренция: отсюда и большое количество запросов к любым устройствам, принимающим их по протоколам Telnet или SSH, и склонность менять пароль после успешной атаки — иначе следующий же попробует установить на устройство свое контролирующее ПО.

По странам «атакующие» распределяются вот так. На первом месте Бразилия, страна, которая уже не раз упоминалась в новостях про IoT-ботнеты. Всего «ханипоты» зафиксировали 12 миллионов атак с 86 560 уникальных IP-адресов, еще 27 тысяч IP участвовали в раздаче вредоносного ПО. Интересно, что количество атакующих IP оказалось гораздо меньше, чем общее количество зараженных устройств. Объяснений тут может быть несколько: нахождение зараженных устройств за NAT, использование для атак только малой части ботнета или что-то еще. Как это обычно бывает, отслеживание действий киберпреступников дает лишь часть общей картины.

Оценить мощность ботнета можно в том случае, когда он применяется по назначению. В 2016 году мощность атаки на DNS-провайдер Dyn превысила ^[7] 1 терабит в секунду, она производилась более чем со 100 тысяч контролируемых ботнетом Mirai устройств. Впрочем, специалисты «Лаборатории Касперского» справедливо отмечают, что «райская жизнь» с миллионами устройств, закрытых только дефолтным паролем, со временем закончится. Следующий этап — это все же эксплуатация уязвимостей в IoT-устройствах, не требующая наличия дефолтного пароля. Такие более сложные атаки умеет проводить ботнет Reaper.

Вот какие примеры уязвимостей приводятся: получение полного контроля ^[8] над роутерами D-Link 850L; IP-камеры с фичей «прямого доступа ^[9]» извне по серийному номеру с дальнейшим брутфорсом пароля; система видеонаблюдения с доступом по простейшему ^[10] и легко подделываемому Cookie.

Но это все в будущем, а пока табличка выше дает понять, что больше 90% атак на IoT — это банальный брутфорс. Уязвимости пока не требуются. Про специализированные интерфейсы администрирования я даже говорить не буду, но в отчете и про них немало написано ^[3].

Это какое-то полное отсутствие элементарных средств защиты. Двадцать лет назад было в порядке вещей подключаться к почтовому серверу по незащищенному протоколу POP3, передавать пароли на сервер мессенджера в открытом виде. Интернет был молод и наивен. Сейчас производить устройства с таким отношением к безопасности — ну, если выражаться совсем мягко, недальновидно. Что делать? Прежде всего не делать IoT-устройства доступными из сети. VPN всем в помощь. Конечно, этот совет бесполезен для тех, у кого IP-камера есть, а представления о том, что такое Telnet и VPN, не имеется.

Стоит ли надеяться, что производители будут постепенно улучшать безопасность IoT-устройств? Это не отменит доступности в сети миллионов заведомо уязвимых изделий, которые, в отличие от смартфонов и ноутбуков, не обновляются годами. И все настолько плохо, что известный криптограф Брюс Шнайер призвал к госрегулированию отрасли — ну, к тому, что в отношении собственно криптографии воспринимается в штыки. Есть ли другие способы? Не очень понятно.

Вот вам напоследок свежая новость ^[11]. Уязвимость обнаружили в роутерах WD My Cloud. Цитирую: «Поскольку реализация CGI-интерфейса сетевых накопителей Western Digital позволяет для аутентификации использовать куки, автор атаки может в ходе сессии подать HTTP-запрос на выполнение любой команды, включив в него строку Cookie: username=admin».

Disclaimer: Мнения, изложенные в этом дайджесте, могут не всегда совпадать с официальной позицией «Лаборатории Касперского». Дорогая редакция вообще рекомендует относиться к любым мнениям со здоровым скептицизмом.

Автор: Kaspersky_Lab

Источник ^[12]