Роботы пылесосы, нападающие на домашних животных и терроризирующие жильцов. Сюжет одного из эпизодов «Черного зеркала», который стал реальностью. Такое поведение бытовой техники может не только испортить жизнь потребителям, но и способно нанести огромный финансовый и репутационный ущерб производителям. Комментируя этот случай, эксперты KasperskyOS подчеркивают, что к таким последствиям приводят низкая культура безопасной разработки и стремление к удешевлению производства. Причем, проблема стоит шире, чем просто уязвимость роботов-пылесосов или другой бытовой техники: в современном мире любое подключенное устройство может стать целью хакеров.
На конференции DEFCON 32 два исследователя продемонстрировали способ взлома роботов-пылесосов Ecovacs. Уязвимости позволяли хакерам удаленно управлять роботами, запускать видеотрансляции с камер, а также получать root-доступ через Bluetooth, используя общий для всех устройств статический ключ. Эти пробелы в безопасности открыли дорогу для различных сценариев атак, от банального запугивания владельцев до потенциального создания сетевого червя, способного заражать другие устройства.
Реальные примеры из США подтверждают, что атаки на роботов Ecovacs происходят не только в теории. Пользователи сталкивались с самопроизвольным движением роботов, непристойными звуками и даже прямыми трансляциями их личной жизни. Эти инциденты подчеркнули ключевую проблему — отсутствие у многих производителей IoT-устройств системного подхода к безопасности. В ответ на запросы исследователей компания Ecovacs лишь частично закрыла выявленные уязвимости, игнорируя самые серьезные из них, что оставляет пользователей беззащитными перед возможными атаками.
Большинство IoT-устройств и решений для умного дома сегодня страдают от проблем с информационной безопасностью и низкого качества исполнения. Производителям необходимо регулярно радовать пользователей новыми устройствами со всё более продвинутой функциональностью. При этом приходится стремиться к удешевлению производства и сокращать time to market. Таким образом, безопасности подобных домашних помощников уделяется недостаточно внимания, ей занимаются по остаточному принципу. Это хорошо видно, поскольку устройства страдают от довольно детских болезней. Проблемы, найденные исследователями, конечно, широко встречаются в живой природе, но их вполне можно было избежать, если бы в компании-производителе минимально выстроили процессы безопасной разработки и наняли несколько опытных специалистов по информационной безопасности. Вероятно, этого не произойдет, пока пользователи будут голосовать своими деньгами за status quo.
Отсутствующая аутентификация и авторизация на сервере, нарушение приватности. Разнообразные данные, собираемые роботом-пылесосом (включая фото с камеры и карты местности), отправляются в облако производителя, где сохраняются в NoSQL базе данных. При этом, доступ к объектам в ней не ограничивается, достаточно знать идентификатор объекта, чтобы получить данные пользователя. Сброс самого устройства и удаление аккаунта из облака не удаляют приватные данные, т.е., попав единожды в облако, они потенциально оказываются надолго доступными злоумышленникам.
Множественные проблемы сетевой безопасности. Устройство применяет TLS для большинства соединений, но это не спасает от угроз, поскольку: используются самоподписанные сертификаты, некоторые скрипты в прошивке робота отключают проверку сертификатов, устройство раскрывает токены аутентификации, а время их устаревания — неделя. Это открывает множество способов напакостить хозяевам устройства, в т.ч. полностью захватить управление устройством.
Некорректная схема аутентификации для видеотрансляций. Доступ к возможностям трансляции видео выдается по PIN-коду, корректность которого проверяется на стороне клиента. Т.е. проверку можно обойти.
Низкая культура работы с криптографией. Коммуникации с устройством через BLE по GATT-протоколу используют шифрование для чувствительных данных, но на всех устройствах применяется единственный AES-ключ, который, к тому же, просто подобрать.
Отсутствие валидации передаваемых устройству строк, приводящее к RCE. Устройство может выполнять различные команды, например, проигрывать разные звуки через вызов соответствующего скрипта, которому в качестве параметра передается имя файла для проигрывания. Текст параметра никак не валидируется, что позволяет выполнить произвольную команду, в т.ч. запустить удаленный шелл.
Большинство описанных проблем скорее всего связано с низкой культурой безопасной разработки. AppSec-специалист при правильных процессах разработки заметил бы большинство из них, и предложил адекватные меры по их устранению. Вероятно, компания-разработчик инвестирует в это направление недостаточно внимания и средств. В «Лаборатории Касперского» применяются процессы безопасной разработки, схожие с Microsoft SDL, смысл которых — снизить вероятность появления подобных проблем в продуктах компании. Разработчики KasperskyOS и продуктов на её основе дополняют этот процесс набором требований, касающихся архитектуры системы, что позволяет поддерживать целостность её критических компонентов и повышать гарантии относительно избранных свойств системы (процесс разработки кибериммунных решений).
Эффективная защита IoT-инфраструктуры кроется в использовании кибериммунного подхода к разработке, заложенного в архитектуру KasperskyOS. Принципы минимизации доверенной кодовой базы, изоляции компонентов и контроля взаимодействия между ними значительно повышают устойчивость к угрозам. Таким образом, уязвимости не затрагивают критические компоненты системы, обеспечивая защиту даже в условиях существования потенциальных эксплойтов.
Представим, что взлом робота-пылесоса может привести к серьезным последствиям, и заказчик ставит перед нами задачу: «обеспечить, чтобы при любых обстоятельствах выполнялись только авторизованные команды от подлинных пользователей». Для достижения этой цели на этапе архитектурного проектирования необходимо предусмотреть механизмы строгого контроля аутентичности пользователей и авторизации команд. Код, отвечающий за эти проверки, изолируется от остального функционального кода, подвергается тщательному тестированию и поддерживается средствами KasperskyOS, которые обеспечивают надежное разделение компонентов. Итог такого подхода? В устройстве все еще могут оставаться уязвимости, но они не затронут критически важные области, отвечающие за выполнение целей безопасности. Эксплуатация подобных уязвимостей станет либо невозможной извне, либо не причинит вреда заказчику и пользователю.
Можно ли было избежать каких-то из перечисленных в предыдущей главе проблем, если бы система была построена на основе KasperskyOS? Отчасти. Например, в решениях на базе нашей системы произвольные процессы не могут запускать новые задачи самостоятельно, у них просто отсутствует доступ к соответствующим интерфейсам ядра. Такое право есть только у процесса первичного запуска EInit и сервиса Execution Manager. Политика Kaspersky Security System контролирует доступ и к другим системным сервисам, несущим потенциальную опасность. RCE, подобная описанной выше уязвимости, окажется невозможной.
В работе над архитектурой системы KasperskyOS находят широкое применение принципы из работ Джерома Зальцера и Майкла Шредера, а также международного стандарта ISO/IEC TS 19249:2017. Их применение значительно снижает вероятность появления типовых проблем с безопасностью, и усложняет распространение атаки, если злоумышленнику удалось найти эксплуатируемую уязвимость. Например, сложно структурированные данные из ввода не попадут в необработанном виде в компоненты, наделенные высокими привилегиями.
Тем не менее, не существует серебряной пули, нет технического решения: программного обеспечения или протокола, которые магическим образом решат все проблемы безопасности. Даже используя хорошие инструменты можно наделать детских ошибок. Улучшить ситуацию возможно только через системную организацию труда разработчиков, архитекторов, тестировщиков, аналитиков и других ролей, вовлеченных в создание новых продуктов.Важно также обучать всех перечисленных специалистов, проводить регулярный контроль качества, выбирать правильные решения при разработке архитектуры и проектирования ипостоянно совершенствовать процессы и инструменты.
Роботы пылесосы, нападающие на домашних животных и терроризирующие жильцов. Сюжет одного из эпизодов «Черного зеркала», который стал реальностью. Такое поведение бытовой техники может не только испортить жизнь потребителям, но и способно нанести огромный финансовый и репутационный ущерб производителям. Комментируя этот случай, эксперты KasperskyOS подчеркивают, что к таким последствиям приводят низкая культура безопасной разработки и стремление к удешевлению производства. Причем, проблема стоит шире, чем просто уязвимость роботов-пылесосов или другой бытовой техники: в современном мире любое подключенное устройство может стать целью хакеров.
На конференции DEFCON 32 два исследователя продемонстрировали способ взлома роботов-пылесосов Ecovacs. Уязвимости позволяли хакерам удаленно управлять роботами, запускать видеотрансляции с камер, а также получать root-доступ через Bluetooth, используя общий для всех устройств статический ключ. Эти пробелы в безопасности открыли дорогу для различных сценариев атак, от банального запугивания владельцев до потенциального создания сетевого червя, способного заражать другие устройства.
Реальные примеры из США подтверждают, что атаки на роботов Ecovacs происходят не только в теории. Пользователи сталкивались с самопроизвольным движением роботов, непристойными звуками и даже прямыми трансляциями их личной жизни. Эти инциденты подчеркнули ключевую проблему — отсутствие у многих производителей IoT-устройств системного подхода к безопасности. В ответ на запросы исследователей компания Ecovacs лишь частично закрыла выявленные уязвимости, игнорируя самые серьезные из них, что оставляет пользователей беззащитными перед возможными атаками.
Большинство IoT-устройств и решений для умного дома сегодня страдают от проблем с информационной безопасностью и низкого качества исполнения. Производителям необходимо регулярно радовать пользователей новыми устройствами со всё более продвинутой функциональностью. При этом приходится стремиться к удешевлению производства и сокращать time to market. Таким образом, безопасности подобных домашних помощников уделяется недостаточно внимания, ей занимаются по остаточному принципу. Это хорошо видно, поскольку устройства страдают от довольно детских болезней. Проблемы, найденные исследователями, конечно, широко встречаются в живой природе, но их вполне можно было избежать, если бы в компании-производителе минимально выстроили процессы безопасной разработки и наняли несколько опытных специалистов по информационной безопасности. Вероятно, этого не произойдет, пока пользователи будут голосовать своими деньгами за status quo.
Отсутствующая аутентификация и авторизация на сервере, нарушение приватности. Разнообразные данные, собираемые роботом-пылесосом (включая фото с камеры и карты местности), отправляются в облако производителя, где сохраняются в NoSQL базе данных. При этом, доступ к объектам в ней не ограничивается, достаточно знать идентификатор объекта, чтобы получить данные пользователя. Сброс самого устройства и удаление аккаунта из облака не удаляют приватные данные, т.е., попав единожды в облако, они потенциально оказываются надолго доступными злоумышленникам.
Множественные проблемы сетевой безопасности. Устройство применяет TLS для большинства соединений, но это не спасает от угроз, поскольку: используются самоподписанные сертификаты, некоторые скрипты в прошивке робота отключают проверку сертификатов, устройство раскрывает токены аутентификации, а время их устаревания — неделя. Это открывает множество способов напакостить хозяевам устройства, в т.ч. полностью захватить управление устройством.
Некорректная схема аутентификации для видеотрансляций. Доступ к возможностям трансляции видео выдается по PIN-коду, корректность которого проверяется на стороне клиента. Т.е. проверку можно обойти.
Низкая культура работы с криптографией. Коммуникации с устройством через BLE по GATT-протоколу используют шифрование для чувствительных данных, но на всех устройствах применяется единственный AES-ключ, который, к тому же, просто подобрать.
Отсутствие валидации передаваемых устройству строк, приводящее к RCE. Устройство может выполнять различные команды, например, проигрывать разные звуки через вызов соответствующего скрипта, которому в качестве параметра передается имя файла для проигрывания. Текст параметра никак не валидируется, что позволяет выполнить произвольную команду, в т.ч. запустить удаленный шелл.
Большинство описанных проблем скорее всего связано с низкой культурой безопасной разработки. AppSec-специалист при правильных процессах разработки заметил бы большинство из них, и предложил адекватные меры по их устранению. Вероятно, компания-разработчик инвестирует в это направление недостаточно внимания и средств. В «Лаборатории Касперского» применяются процессы безопасной разработки, схожие с Microsoft SDL, смысл которых — снизить вероятность появления подобных проблем в продуктах компании. Разработчики KasperskyOS и продуктов на её основе дополняют этот процесс набором требований, касающихся архитектуры системы, что позволяет поддерживать целостность её критических компонентов и повышать гарантии относительно избранных свойств системы (процесс разработки кибериммунных решений).
Эффективная защита IoT-инфраструктуры кроется в использовании кибериммунного подхода к разработке, заложенного в архитектуру KasperskyOS. Принципы минимизации доверенной кодовой базы, изоляции компонентов и контроля взаимодействия между ними значительно повышают устойчивость к угрозам. Таким образом, уязвимости не затрагивают критические компоненты системы, обеспечивая защиту даже в условиях существования потенциальных эксплойтов.
Представим, что взлом робота-пылесоса может привести к серьезным последствиям, и заказчик ставит перед нами задачу: «обеспечить, чтобы при любых обстоятельствах выполнялись только авторизованные команды от подлинных пользователей». Для достижения этой цели на этапе архитектурного проектирования необходимо предусмотреть механизмы строгого контроля аутентичности пользователей и авторизации команд. Код, отвечающий за эти проверки, изолируется от остального функционального кода, подвергается тщательному тестированию и поддерживается средствами KasperskyOS, которые обеспечивают надежное разделение компонентов. Итог такого подхода? В устройстве все еще могут оставаться уязвимости, но они не затронут критически важные области, отвечающие за выполнение целей безопасности. Эксплуатация подобных уязвимостей станет либо невозможной извне, либо не причинит вреда заказчику и пользователю.
Можно ли было избежать каких-то из перечисленных в предыдущей главе проблем, если бы система была построена на основе KasperskyOS? Отчасти. Например, в решениях на базе нашей системы произвольные процессы не могут запускать новые задачи самостоятельно, у них просто отсутствует доступ к соответствующим интерфейсам ядра. Такое право есть только у процесса первичного запуска EInit и сервиса Execution Manager. Политика Kaspersky Security System контролирует доступ и к другим системным сервисам, несущим потенциальную опасность. RCE, подобная описанной выше уязвимости, окажется невозможной.
В работе над архитектурой системы KasperskyOS находят широкое применение принципы из работ Джерома Зальцера и Майкла Шредера, а также международного стандарта ISO/IEC TS 19249:2017. Их применение значительно снижает вероятность появления типовых проблем с безопасностью, и усложняет распространение атаки, если злоумышленнику удалось найти эксплуатируемую уязвимость. Например, сложно структурированные данные из ввода не попадут в необработанном виде в компоненты, наделенные высокими привилегиями.
Тем не менее, не существует серебряной пули, нет технического решения: программного обеспечения или протокола, которые магическим образом решат все проблемы безопасности. Даже используя хорошие инструменты можно наделать детских ошибок. Улучшить ситуацию возможно только через системную организацию труда разработчиков, архитекторов, тестировщиков, аналитиков и других ролей, вовлеченных в создание новых продуктов.Важно также обучать всех перечисленных специалистов, проводить регулярный контроль качества, выбирать правильные решения при разработке архитектуры и проектирования ипостоянно совершенствовать процессы и инструменты.
