Security Week 34: Бунт промышленных роботов, зачистка Google Play от зловредов и древняя уязвимость в OS X

«Докажи, что не робот: причини вред человеку или своим бездействием допусти, чтобы человек пострадал» — так могла бы выглядеть капча в оживших мирах Айзека Азимова с некоторой примесью позднего киберпанка. Пока же создатели трудящихся бок о бок с человеком роботов (co-bots, или «коботы») о трех законах не задумываются. И совершенно напрасно — в эпоху IoT машины с мозгами набекрень могут здорово насолить своим владельцам. Скажем, остановить конвейер крупного производства или оставить хозяина ночевать за порогом умного дома.

Исследователи из IOActive насчитали почти 50 уязвимостей ^[1] в промышленных роботах производителей Rethink Robotics, Baxter/Sawyer и Universal Robots. Если верить опубликованному документу ^[2], многие модели можно перепрограммировать удаленно, заставив их шпионить или даже пакостить человеку (нападать из-за угла или обижать любимых котиков). Ведь речь не просто о каких-нибудь стационарных манипуляторах — коботы умнее, самостоятельно передвигаются, оснащены камерами, микрофонами и прочим обвесом, добавить в который вредоносного кода по вкусу не составит никакого труда ^[3].

Исследователи хорошенько покопались в публичных прошивках и другом встраиваемом ПО, чтобы узнать, как машины работают, как подключаются к локальным сетям и к другим роботам, а также как взаимодействуют с сервисами производителей (скажем, для получения обновлений). В итоге им удалось обнаружить дыры в системах аутентификации, криптографические уязвимости и прочие милые сердцу каждого хакера вещи. Некоторые из этих уязвимостей оказалось довольно легко использовать ^[4].

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

Однако проблема существует, ведь вендоры пока не особенно задумываются о вопросах безопасности, что может выйти боком, когда полку умных устройств в человеческом окружении прибудет. Это подтверждают и эксперты IOActive: они связались с шестью основными поставщиками решений, и только некоторые признали наличие уязвимостей, пообещав их исправить. К тому же в этой области ведется множество различных исследований, результаты которых (включая код) общедоступны — со временем они перемещаются в коммерческие продукты без аудита безопасности, что опять же упрощает задачу хакерам. И хотя до Скайнета нам еще далеко, кажется, где-то на тайваньских заводах уже перемигиваются роутеры-повстанцы…

Китайский SDK как инструмент загрузки вредоносного кода в Android

Более 500 приложений, созданных с использованием вредоносных версий китайского Igexin SDK, были удалены из Google Play. Обнаружилос ^[5]ь, что эти софтины позволяют устанавливать шпионское ПО на мобильные устройства.

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

По данным исследователей из Lookout, потенциально уязвимые программы были скачаны из онлайн-магазина Google более 100 млн раз. И хотя далеко не все из них использовались в незаконных целях, проблема вырисовывается серьезная, ведь под подозрением оказались разработанные для подростков игры, погодные информеры, интернет-радио, фоторедакторы, образовательные приложения, программы для занятий спортом и множество других аппов. Впрочем, пользователям Android не привыкать к подобным сюрпризам — масштабные зачистки Google Play проводятся не впервые, а количество зловредов для этой мобильной ОС год от года растет.

Надо отметить и ударную работу китайских товарищей: это не первый случай, когда созданные с использованием зараженных версий SDK из Поднебесной программы попадали в официальные магазины. Достаточно вспомнить сторонний рекламный SDK Youmi, из-за которого компании Apple пришлось два года назад удалить из App Store более 250 программ — они собирали конфиденциальные данные пользователей, включая Apple ID и серийный номер устройства.

Установщик Apple может загружать в OS X вредоносный код с правами root

Последняя новость дайджеста вовсе не нова — проблеме уже не один год, но ее снова обсудили на последнем DEF CON ^[6]. Для установки и обновления стороннего ПО в OS X часто применяется ^[7] устаревший AuthorizationExecuteWithPrivileges API, позволяющий злоумышленнику получить права суперпользователя с небольшой помощью владельца компьютера.

На первый взгляд тут ничего серьезного — подумаешь, злодей может подменить инсталлятор, нужно смотреть, что запускаешь на своей машине, и не тащить софт откуда попало. Интересно другое: установщики огромного количества популярных продуктов (Slack, Google Chrome, Google-owned Dropcam, VMware Fusion и т.д.) для OS X используют небезопасный метод вместо давно созданной Apple альтернативы. Еще с 2013 года компания рекомендует ^[8] применять SMJobBless, позволяющий проверить подлинность исполняемого кода. Однако разработчики, включая софтверных гигантов, не торопятся переходить на новый метод, требующий наличия платного сертификата для подписи своих продуктов. Дело в том, что помимо денег придется потратить еще и много времени, чтобы заставить работать такое безопасное решение, в то время как устаревший API — это буквально три строчки кода.

Древности

«Stone-Dinamo»

Сохраняет старый Boot-сектор дискет в последний сектор корневого каталога вне зависимости от объема диска. Если при инсталляции вируса происходит ошибка, то он расшифровывает и выводит текст «Dinamo(Kiev)-champion !!!».

Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 97.

Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.

Автор: Kaspersky_Lab

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