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


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

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

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


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

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


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


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

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

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


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

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

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

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


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

Вы можете помочь и перевести немного средств на развитие сайта

Теги:



Комментарии (16):

  1. maxzhurkin
    /#19152355 / -2

    Бесконечная статья. Ну, в том смысле, что концовки не хватает.
    Короткая памятка как писать статьи:
    1. Напишите вступление;
    2. Напишите основную часть;
    3. Напишите концовку.
    Автор забыл третий пункт

    • ianzag
      /#19153029 / +3

      Несогласная Я. Картинка в качестве концовки вполне подходит.

  2. igrblkv
    /#19152959

    Исключение только одно: если вы транслируете по Telnet «Звездные войны».
    Вот, кстати, а как?
    Ну, то есть, как там что-то транслировать, а не тупо отключить демон и/или запретить порт фаерволлом?

    PS: Сорри за офф-топик.

    • ianzag
      /#19153061 / +1

      Вспоминаем молодость, Maximus BBS, ANSI графику, на выходных берем пивка чайку и в бой :)

      PS: Ну или если совсем лень то у ffmpeg есть ansi output. Но это не спортивно.

  3. saipr
    /#19153297

    Есть простое решение защитить трафик телнета и порт сменить — это stunnel. Более того есть версия stunnel с поддержкой ГОСТ-овой криптографии. И туже SAMBA защитить. Запретить telnet невозможно, а предупредить нужно.

    • ianzag
      /#19153317

      Как вы планируете запустить stunnel на, скажем, DIR300 с торчащим наружу телнетом :-?

      • saipr
        /#19153355

        Виноват, вы правы, без перепрошивки роутера никак.

        • khim
          /#19155081

          А с прошивкой можно его выпилить, что правильнее и надёжнее…

          • saipr
            /#19155867

            Вот и пришли к консенсусу. Здесь о встраивании российской криптографии в ядро Linux.

  4. belyvoron
    /#19153791

    желательно как минимум отключить вход по паролю, а еще лучше — переназначить порт

    вы уверены, что переназначение порта SSH является более эффективной мерой защиты, чем аутентификация только по сертификату?

    • khanid
      /#19154459 / +1

      В количественном выражении, думаю, да, может снизить количество запросов на вход в систему. За 2 недели по ssh на последней моей vps ко мне прилетело примерно 125 тысяч запросов на вход. Банальный уход на другой порт в диапазоне 3000+ привёл к тому, что запросов за месяц прилетело чуть меньше двухсот.
      На rpd виндовом тендеция та же. 80 тысяч на стандартный порт за 3 дня, и окло 600 за 2 месяца. Не сильно-то на меру защиты походит, но количество запросов снижает на порядки, т.к. большинство не занимается сканированием нестандартных портов. Им выгоднее по массе со стандартными пробежаться — цель-то в массовости, а не в проникновении в конкретную систему.

    • Revertis
      /#19154463 / +1

      Автор, наверное, немного неправильно выразился. Скорее надо делать и то и то.
      Смена порта облегчает логи в несколько десятков раз.
      UPD: Надо было обновить комментарии, извиняюсь.

  5. azazar
    /#19155715

    Если поменять telnet на ssh для малвари не изменится ничего. Малвари только будут подбирать пароли по SSH вместно него. Надо просто дефолтные пароли запретить.

    • ianzag
      /#19155779

      > Надо просто дефолтные пароли запретить.

      Желательно за уровне законодательства с внесением в УК. А также баги в целом. За феерические же фейлы типа недавнего MikroTik-а проводить по особо тяжкой.

      • khim
        /#19156675

        Ну тут главное не перегнуть палку и «гайки закручивать» постепенно. То есть по хорошему-то нужно за «серьёзные баги, повлёкщие последствия» уголовку, но если вот прям сейчас такие законы ввести — то все разработчики тут же уволятся.

        Но постепенно, я думаю, мы к этому и придём.