Взлом умного дома
Какие риски мы берем на себя, устанавливая систему «умный дом»? Ту, что рулит лампочками и чайником с приложения на смартфоне, внутри локальной сети и удаленно. Если на умную систему завязана безопасность и управление замками (как в случае Amazon Key) — то понятно какие. Если нет, то теоретически можно представить опасность программного вывода из строя какой-нибудь кофеварки с последующим пожаром. Но лучше не фантазировать, а знать наверняка.
Специалисты команды ICS CERT из «Лаборатории Касперского» решили провести натурный тест на умном доме одного из сотрудников компании (новость, пост в блоге, техническая статья). Взлом произошел успешно: кофеварка не пострадала, но контроль над системой получить удалось, пусть и с парой (вполне реалистичных) допущений в ходе эксперимента. Одним из неприятных последствий этой атаки стала утечка персональных данных: координаты дома и, что самое печальное, геолокация смартфона. Впрочем, эксперимент закончился на позитивной ноте: производитель системы умного дома успешно закрыл уязвимости.
В технической статье довольно много места отведено относительно скучным, но важным моментам: что НЕ удалось взломать, и как проходил анализ системы умного дома на наличие потенциальных уязвимостей. Перед началом эксперимента исследователи уже знали производителя системы. Им оказалась компания Fibaro, выпускающая ассортимент собственных устройств для современного умного дома, а также обеспечивающая интеграцию с устройствами сторонних производителей. Более того, владелец дал важную подсказку — постоянный IP для входа в админку. Кстати, сама Fibaro не рекомендует открывать доступ к контроллеру по IP — только через облачную систему. В данном эксперименте эта сознательно оставленная владельцем лазейка сыграла свою роль.
Теоретически такую систему можно атаковать по трем основным направлениям: попытаться так или иначе взломать управляющее устройство, поискать уязвимости в облачной части сервиса либо атаковать сами подключенные к контроллеру IoT-устройства. В последнем случае требуется находиться в непосредственной близости от них, поэтому первые два варианта выглядят перспективнее.
Следующий шаг — анализ прошивки устройства и WebAPI. Обычно на таком анализе все заканчивается, и выходит новость в стиле «в устройстве обнаружен вшитый пароль». Но в случае Fibaro очевидных прорех в безопасности не было. Зато была получена полезная информация о реализации части управляющей логики на PHP. Без авторизации контроллер отдает только серийный номер устройства, и для взлома железки эта информация бесполезна. Зато, как выяснилось, она позволяет взломать облачную часть сервиса.
Доступ к облаку, в свою очередь, позволяет без авторизации получать резервные копии базы данных SQLite, содержащие все настройки устройства, и загружать свои. Теоретически обход авторизации давал возможность (до исправления уязвимости) загрузить резервные копии всех пользователей облачной системы. Анализ реальной базы атакуемого устройства обеспечил доступ к приватной информации, включая координаты дома и смартфона, на котором установлено управляющее приложение. Уже это — серьезная проблема, так как (с некоторыми ограничениями) она позволяет определить, когда владельца системы нет дома.
Помимо этого, в базе была полная информация о подключенных IoT-устройствах, а также пароль для доступа к настройкам, но захешированный с добавлением «соли». Анализ прошивки показал, что «соль» не рандомная, а прочно зашита в устройство. Теоретически очень простой пароль может быть взломан, но в данном случае не вышло. База SQLite также содержала открытые пароли для подключения к другим устройствам внутри сети: если бы эти пароли совпадали с основным, контроллер также можно было бы легко взломать.
Но опять не получилось: владелец системы оказался знаком с базовыми рекомендациями по безопасности и не использовал один и тот же пароль для разных устройств. Поэтому пришлось применить социальную инженерию. Уязвимость в облачной системе, позволяющая проводить ряд действий без авторизации, зная только серийный номер устройства (который отдается «бесплатно», если есть доступ к админке извне), сделала возможным следующий сценарий. В «облако» была загружена подготовленная резервная копия устройства, в которую был внедрен вредоносный скрипт. Сообщение о необходимости «обновить» устройство через штатные возможности облачной системы было отправлено владельцу (по электронной почте и SMS).
Так как владелец системы знал об эксперименте, он сразу понял, что это не настоящий патч. Но в целом это вполне реальный сценарий, когда пользователю через привычный канал связи приходит правдоподобное сообщение, поэтому резервная копия была установлена. Вредоносный код был выполнен с системными правами благодаря недосмотру в PHP-коде, вызывающему выполнение bash-скрипта:
Здесь параметр, задающийся пользователем (в нормальных условиях даже администратор системы не имеет прав суперпользователя на устройстве), попадает в аргумент для командной строки. Недостаточная проверка аргументов позволила выполнить с правами «рута» произвольный код и наконец-то получить полный контроль над устройством. Параллельно была найдена, но не использована возможность проведения SQL-инъекции:
Взламывать кофеварку в реальном доме исследователи не планировали, поэтому в качестве «привета» поменяли мелодию будильника. Упомянутые уязвимости и в облачной системе, и в коде контроллера были закрыты. По понятным причинам конкретные методы обхода защиты в технической статье не раскрываются — во избежание использования их настоящими злоумышленниками на устройствах, которые еще не обновились. Зато в этом эксперименте хорошо показано то, что обычно остается за рамками новостных заголовков: множество путей исследования защиты устройства, большинство из которых оканчивается ничем. В реальном опыте и производитель устройства, и его владелец смогли избежать простейших ошибок безопасности, таких как вшитые и повторно используемые пароли. Тем не менее, было выявлено достаточное количество проблем, способное привести как минимум к утечке приватных данных, а в худшем случае — к обходу систем безопасности.
Источник: habr.com