В середине июня 2018 года известный ИБ-специалист Кевин Бомонт (Kevin Beaumont) в очередной раз обратил внимание на то, что многие производители смартфонов на Android оставляют функциональность Android Debug Bridge (ADB) включенной по умолчанию, что подвергает устройства опасности, в том числе и удаленной. Дело в том, что опция ADB over WiFi позволяет разработчикам так же подключаться к гаджету через Wi-Fi, без использования USB-кабеля.

В целом эту проблему нельзя назвать новой. Еще в феврале 2018 года аналитики Qihoo 360 Netlab обнаруживали малварь ADB.miner, которая сканировала сеть в поисках устройств с открытыми отладочными портами ADB (чаще всего это порт 5555). Так как под управлением Android работают не только смартфоны и планшеты, заражению также подвергались, к примеру, «умные» телевизоры и различные приставки для ТВ.

Немногим больше месяца назад Бомонд обнаружил, что во многих гаджетах прямо «из коробки» активна функциональность ADB over WiFi, о чем их владельцы, как правило, даже не догадываются. Так как поисковик Shodan недавно добавил возможность поиска устройств с доступным интерфейсом Android Debug Bridge, теперь индекс таких гаджетов стремительно растет с каждым днем. В июне Бомонд обнаружил более 80 000 проблемных устройств в одном только Китае.

Теперь о новой волне атак на уязвимые гаджеты с открытыми портами ADB сообщили аналитики компании Trend Micro. По информации специалистов, новая волна сканирований началась 9-10 июля 2018 года, и большая часть трафика исходила из Китая и США. Начиная с 15 июля, к атакам также присоединились и корейские IP-адреса.

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

После успешного заражения устройства, малварь ликвидирует ряд опасных для себя процессов и запускает собственные дочерние процессы, один из которых позволяет ей распространяться далее, подобно червю. Также вредонос связывается с управляющим сервером, расположенным по адресу 95[.]215[.]62[.]169. Ранее этот адрес уже встречался экспертам, так как был связан с работой ботнета Satori.

По данным аналитиков Trend Micro, пейлоад малвари предназначается для организации DDoS-атак (может использовать UDP, TCP SYN, TCP ACK и так далее). Учитывая связь, обнаруженную между этой вредоносной кампанией и ботнетом Satori, эксперты полагают, что за всем этим стоит один и тот же хакер или хакерская группа, и кто-то строит таким образом новый ботнет.

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

Согласно подсчетам Trend Micro, в настоящее время перед атаками на порты ADB уязвимы не менее 48 000 устройств. Среди них различные мультимедийные гаджеты, «умные» ТВ, смартфоны и так далее. Исследователи напоминают, что от подобных атак не защитит никакой пароль, поэтому рекомендуют не «светить» такие устройства в интернете напрямую, располагая их за роутерами и файерволами.

3 комментария

  1. GingerBeard

    26.07.2018 at 17:13

    Любопытно посмотреть на возможности этого ботнета в большой публичной wifi сети, например, в сети московского метрополитена)

  2. AseN

    27.07.2018 at 01:58

    Ерунда какая-то — даже при включенной удаленной отладке(5555) по умолчанию(!) при сопряжении с устройством первый раз происходит acknowledgement, при котором устройство запоминает отпечаток удаленного устройства, а владельцу показывает вполне заметный алерт. Данная «фича» предусмотрена на уровне ядра безопасности Android, и если какие-то производители умышленно выпилили эту проверку из своих сборок Android, то это уже бэкдор, а не уязвимость.

    • r0uly

      04.08.2018 at 19:04

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

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

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

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

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

      Такое может быть вызвано простейшей ошибкой в архитектуре кода, где перед началом проверки наличия отпечатка в базе, есть проверка на наличие значения у переменной с отпечатком. Там вместо использования блока «if … else» может использоваться только «if» с вызовом «return», если отпечатка в базе нет. В таком случае, если переменная с отпечатком не имеет установленного значения, т.к. отпечаток не удалось сгенерировать, то блок «if» с вызовом «return» будет пропущен и код пойдет выполнятся дальше, где будет вызван код, который отработал бы, если бы идентификатор был валидный и находился в базе известных.

Оставить мнение