Исследование безопасности камер Swann и FLIR/Lorex

Автор: Andrew Tierney

Некоторое время назад на веб-сайте BBC появилась новость о том, как один из сотрудников этого канала смог посмотреть в мобильном приложении чужое видео, снятое домашней камерой.

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

Вместо эпилога

Мы успешно переключили видеопоток с одной камеры на другую через облачный сервис. Эта тема не связана с первоначальной историей.

Кроме того, мы также обнаружились несколько других интересных проблем.

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

Совсем другая история с провайдером облачных решений Ozvision. Подозреваем, что специалисты этой компании впервые узнали о проблеме около 9 месяцев назад, но удосужились решить вопрос только после того, как в дело вмешались из Swann. Мы уверены, что данная уязвимость была в продукции одного из известных брендов, который пользовался облачными технологиями вышеупомянутой компании. Изначально специалисты Ozvision отфутболивали все вопросы, касающиеся найденной проблемы, обратно в Swann.

Подопытная камера

Рисунок 1: Одна из камер, производимых компанией Swann, которая принимала участие в исследовании

Исследуемая HD-камера работает от батареи и может транслировать видео как через локальную сеть, так и через облачный сервис. Выглядит довольно симпатично, а батарея работает достаточно долго. После исследования аппаратной части и приложения стало понятно, что мы имеем дело с камерой с широким углом обзора и телеобъективом. Облачные технологии предоставляет компания Ozvision.

Рисунок 2: Открытые порты и службы, используемые камерой

После изучения API и APK я быстро понял, что серийный номер (swnxxxxxxxxx) является главным идентификатором в платформе, с которой работает камера. Серийный номер, который легко найти в мобильном приложении, используется как в веб-API компании Swann, так и в P2P-туннеле провайдера OzVision.

Рисунок 3: Модель и серийный номер камеры

При авторизации в системе делается запрос к userListAssets. В ответ приходит список устройств, привязанных к учетной записи. Обычно в перечне находятся камеры подлинных владельцев.

После изменения серийного номера (device id) в ответе от сервера в мобильном приложении стали отображаться детали чужой камеры. Мы использовали утилиту Charles, но Burp и MITMproxy также подойдут.

Рисунок 4: Изменение серийного номера в ответе от сервера

В веб-приложении достаточно нажать «play», после чего формируется запрос к deviceWakeup с использованием модифицированного серифного номера. Затем на базе измененного номера формируется туннель к облачному сервису. Теперь можно смотреть видео в режиме реального времени.

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

Рисунок 5: Снимок с чужой видеокамеры

В общем, обмануть приложение оказалось достаточно просто.

Поиск серийных номеров других камер

Пока что мы работали только со своими камерами, что не так интересно.

Формат серийного номера – строка swn и 9 шестнадцатеричных символов. В принципе, большое количество комбинаций, однако не настолько огромное. Наш коллега Vangelis, получивший лучи славы после нахождения уязвимостей в Tapplock API, поразмыслил над нашей ситуацией и пришел к выводу, что в запросе доступен перебор значений:

1.1/osn/deviceIsOwned

1.1/osn/AccountAddDevice – этот запрос выдает ошибку, если камера уже привязана. Таким образом, мы можем определить, существует серийный номер, как показано в мобильном приложении на рисунке ниже:

Рисунок 6: Ответ на запрос в случае с камерой, уже привязанной к учетной записи

Мы полагаем, что весь массив серийных номеров может быть проверен всего за 3 дня, если перебор сделать распределенным.

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

Раскрытие уязвимости

Поскольку сотрудники BBC уже связывались со специалистами из Swann после предыдущей истории, мы тоже попросили об аудиенции. После непродолжительных терок с PR-агентством нам позвонил главный технический специалист, который оказался очень отзывчивым человеком.

В Swann полагают, что обнаружили некоторые из наших некорректных запросов, после чего были внесены корректировки в API. Мы считаем, что было обнаружено нечто другое: наши запросы к API были на предмет существования серийного номера. По нашему мнению, очень сложно отследить факт переключения видео потока, поскольку наши действия укладывались в рамки обычных операций с API и мобильным приложением.

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

Рисунок 7: Снимок с чужой видеокамеры после «исправления» уязвимости

Хотя уже следующим утром наш метод перестал работать. По крайней мере, теперь проблема была окончательно решена.

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

Другие находки

Мы обнаружили очень странную проблему в одной из камер. Периодически после отключения от Wi-Fi настройки сбрасывались, и камера переводилась в режим точки доступа. Теперь каждый, находящийся вне вашего дома, может восстановить ключ PSK и подключиться к сети Wi-Fi.

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

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

В руководстве на камеру говорится, что после сброса настроек, конфигурация подключения беспроводной сети также сбрасывается. Мы заметили, что файл wpa_supplicant.conf перезаписывается, как и утверждалось в мануле, однако в логах устройства хранится SSIDи PSK! Проблема исправлена в более поздних версиях прошивки.

После сброса настроек камера переходит в так называемый мягкий режим, когда каждый может подключиться к устройству без PSK. Далее злоумышленник по логам может восстановить PSK и подключиться к домашней сети Wi-Fi:

Рисунок 8: Участок логов, где хранится ключ

FTP-шелл с правами суперпользователя

После подключения к «мягкой» точке доступа мы обнаружили открытый FTP и архив обновлений прошивки «electra_upgrade.7z», внутри которого был файл squashfs.

Рисунок 9: Содержимое архива electra_upgrade.7z

Эта файловая система содержала файл /etc/shadow, в котором пароль суперпользователя был зашифрован при помощи алгоритма MD5Crypt (самый слабый алгоритм хеширования). В течение нескольких минут при помощи утилиты John the Ripper был обнаружен пароль «twipc». Теперь у нас появился FTP-шелл с правами суперпользователя.

Рисунок 10: Содержимое файла shadow

Далее злоумышленник может заменить прошивку и организовать более надежный шелл.

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

Во время последующих исследований после наших первоначальных находок мы обнаружили статью, где описывалась схожая атака на облачный сервис провайдера Ozvision для камер FLIR-FX. Сей факт наталкивает нас на мысль, что в компании Ozvision знали или, по крайней мере, должны были знать об этой уязвимости в течение года. В результате поискового запроса в Гугле по фразе «Lorex» + «Ozvision» ссылка на ту заметку оказалась первой в списке!

Более серьезные проблемы в облачном сервисе

В нашем распоряжении также были камеры FLIR-FX / Lorex, и мы смогли протестировать проблемы, найденные командой Depth Security.

К сожалению, в этих камерах тоже оказалась уязвимость, связанная с заменой серийного номера.

То есть несмотря на то, что статья в блоге появилась в октябре 2017 года, и в компании FLIR знали об уязвимости (можете ознакомиться с окончанием заметки), ни Ozvision, ни Lorex не выпустили никаких обновлений. Важно заметить, что FLIR продала Lorex компании Dahua в феврале 2018 года, и, возможно, уязвимость потерялась во время продажи? Хотя подобные оправдания в пользу бедных.

Итоги

Проблема с подменой серифного номера исправлена.

В более новых прошивка будет (или уже решена) проблема со сбросом настроек и хранением ключа в логах.

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

Совет

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

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

Заключение

Производители IoT-устройств при интеграции сторонних сервисов должны убедиться, что уровень безопасности этих сервисов на должном уровне.

Представьте, что произойдет, если хакер обнаружил бы эту уязвимость и не стал рассказывать общественности о своих находках? Информация ваших покупателей и видеопотоки оказались бы доступны по всему интернету. Как минимум, пострадала бы ваша репутация, или даже, возможно, возникли бы проблемы в рамках регламента GDPR.

Не доверяйте провайдерам сторонних служб на слово, а проверяйте все самостоятельно и вдумчиво.

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

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

Рекомендую обновить мобильное приложение и прошивку для камер Swann. Тогда ваша безопасность станет чуточку лучше.