Как я взломал миллионы умных весов через уязвимости в API и железе

Зачем взламывать устройства по одному, если можно хакнуть сразу все?

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

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

Весы с подключением к интернету… Серьезно? 

Находясь в отпуске, я заметил на экране весов в спортзале отеля любопытную иконку. Это был значок Wi-Fi. Да, кто-то решил, что подключить к интернету весы — это хорошая идея 🙂

Я пошарился по Amazon и нашел множество аналогичных устройств с подключением по Wi-Fi или Bluetooth. Некоторые из них имели подозрительно схожие мобильные приложения.

Оказалось, что многие из них были изготовлены одним и тем же OEM-производителем. Даже если они создавались разными OEM с разными кодовыми базами, беглый анализ связанных Android-приложений показал, что во многих из них использовались одни и те же библиотеки — например, com.qingniu.heightscale. Вероятно, это связано с тем, что написать совместимую библиотеку с нуля труднее.

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

Мы должны идти глубже

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

Этот процесс сложно защитить. Еще начиная с завода, у каждого девайса должен быть уникальный идентификатор/секрет устройства, чтобы вы не могли случайно связаться с весами X при сканировании QR-кода на весах Y. Самый ненадежный способ защиты — применение статической строки, например, UUID, MAC-адреса или серийного номера. Хотя такая строка вполне может использоваться в качестве идентификатора, она плохо работает как секрет аутентификации. Даже если они сгенерированы случайно и слабо поддаются перебору, их будет сложно отозвать в случае утечки.

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

То есть типичный процесс привязки будет выглядеть так:

1. Пользователь устанавливает мобильное приложение и создает аккаунт.

2. Через приложение пользователь подключается к устройству.

3. Секрет устройства передается мобильному приложению.

4. Мобильное приложение передает серверу секрет пользователя (например, токен сессии) и секрет устройства.

5. Сервер подтверждает подлинность секретов и привязывает аккаунт пользователя к устройству.

6. Теперь пользователь может управлять устройством и получать от него данные удаленно через интернет.

Звучит вполне разумно. Что же может пойти не так?

Инъекция SQL в OEM (обход BT-WAF) 

OEM-производитель допустил ошибку буквально на старте. Мне даже не пришлось покупать само устройство — достаточно было проанализировать мобильное приложение и перебрать доступные API-эндпоинты. 

Среди прочего мне попался любопытный эндпоинт api/ota/update, через который, как я предположил, можно было бы вытащить прошивку, чтобы еще лучше разобраться в устройстве. Благодаря декомпиляции Java-кода Android-приложения я без особого труда восстановил структуру необходимых JSON-параметров в теле запроса. Увы, даже с корректными запросами оказалось, что производитель не собирался делиться чем-то интересным.

Куда интереснее оказались другие API. Во время их изучения я наткнулся на несколько эндпоинтов, уязвимых к SQL-инъекциям. Что любопытно, сервер прикрывался китайским файрволом Baota Cloud WAF (BT-WAF). Он оказался куда суровее большинства файрволов, с которыми мне доводилось иметь дело. 

Особенно выделился эндпоинт /api/device/getDeviceInfo: он позволял запрашивать серийные номера устройств. Ошибка производителя заключалась в том, что этот номер одновременно выступал и идентификатором, и секретом аутентификации. Более того, тот же серийный номер использовался в запросе к /api/device/bindv2 — и этот запрос привязывал (или перепривязывал) устройство к аккаунту отправителя! Под «серийным номером» же скрывалось не что иное, как случайно сгенерированный MAC-адрес, записанный прямо в памяти устройства.

Вот исходное тело запроса для уязвимого эндпоинта:

{   "serialnumber":"'001122334455" }

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

{   "serialnumber":"'or\n@@version\nlimit 1\noffset 123#" }

Разберем, что здесь происходит. Если эта инъекция вставляется в SQL-запрос вроде:

SELECT * FROM devices WHERE serial = 'INJECTION'

то мы получим такой инъецированный SQL: 

SELECT * FROM devices WHERE serial = 'INJECTION'or\n@@version\nlimit 1\noffset 123#'

Здесь присутствует два ключевых механизма обхода:

1. @@version всегда равно true и может использоваться вместо более очевидного 1=1.

2. \n (символ новой строки) позволяет разбить SQL-инструкцию на строки вместо использования пробелов — еще один способ обойти фильтрацию.

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

Получение доступа к отладочной консоли по UART на весах Withings WBS06

Когда я начал изучать другие модели устройств, мне попались весы Withings Body. Как и другие подобные гаджеты, они поддерживали подключение по Wi-Fi и Bluetooth и использовали собственное мобильное приложение. При этом Withings — довольно уважаемый бренд, и, что любопытно, устройство также продавалось под маркой Nokia Body.

Извлечь через API приложения прошивку для дальнейшего анализа оказалось несложно. Однако в отличие от более «тяжелых» прошивок (например, у роутеров), где обычно используется полноценная файловая система и Linux, здесь была низкоуровневая прошивка для ARM без ОС — так называемый baremetal.

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

Тем не менее, я взялся за задачу и пошел по пути, описанному в статье о реверсе baremetal-прошивок в Ghidra. В итоге мне удалось определить модель микроконтроллера, установленного в WBS06 (здесь помогли фотографии из документации FCC) и настроить распределение памяти.

Но больше всего меня зацепили пара подозрительных строк в прошивке, которые намекали на… наличие шелла. Зачем умным весам оболочка? 

Connection Manager Shell Command Usage:   wifi <wifi_sync_flags>             Попытка синхронизации по Wi-Fi с указанными флагами.             wifi_sync_flags - это комбинация следующих флагов:                 0x01 (разрешить обновления), 0x02 (сохранить DbLib),                  0x04 (отправить DbLib), 0x08 (отправить сырые данные),                 0x10 (отправить wlog), 0x20 (отправить события),                  0x40 (отправить дополнительные данные)   wifi_no_update <wifi_sync_flags>             Попытка синхронизироваться по Wi-Fi, обновления не разрешены              (даже если указаны во флагах).   wifi_update <wifi_sync_flags>               Попытка синхронизации, разрешает обновление,                если доступно (даже если не указано во флагах).   bt    Попытка синхронизации по Bluetooth   do    Попытка синхронизации по Wi-Fi/мобильной связи и откат к Bluetooth в случае неудачи.

Порыскав по вебу, я обнаружил пост другого исследователя на Reddit о том, что он разобрался с контактами UART на более старой модели WBS05.

Объяснение оказалось довольно простым, поэтому я нетерпеливо приступил к попытке воспроизведения на WBS06. Самой важной подсказкой стало наличие на нижней поверхности WBS06 тех же трех отверстий, соответствующих контактам UART Tx, Rx и GND; сравнив их с фотографиями внутренностей из документации FCC, я убедился в этом наверняка.

Первые заходы не увенчались успехом. Несмотря на то, что с помощью логического анализатора мне удалось правильно определить скорость передачи данных (baud rate), последовательное соединение выдавало абракадабру. После нескольких часов мучений я понял, что проблема была в моем дешевом USB-TTL-конвертере CP2102. Замена его на более надежный FT232 наконец дала нужный результат.

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

Поломанная логика привязки пользователя к устройству

Чтобы всерьез протестировать удаленные векторы атаки, мне нужно было досконально разобраться, как устройство аутентифицируется на API-сервере и как именно происходит привязка пользователя к конкретному устройству.

Например, команда connection_manager wifi пыталась установить соединение с API-серверами, при этом выводя подробные отладочные логи. 

shell>connection_manager wifi  [info][CM] Connection manager request, action = 3, wifi sync flags = 0xffffffff [VAS] t:15 [info][CM] Start with cnlib action = 3 [VAS] t:15 [CNLIB] Recovered LastCnx from DbLib [AM] Defuse id 4 [TIME] Current time (timestamp) 0 , 8h 0min 0sec [TIME] Waking up in 16h 90min 60sec [TIME] Add random time 0 [AM] Set id 3 at 63060 [AM] Set id 1 at 600 [CNLIB] Try to connect via wifi (1) [DBLIB][ERASEBANK] Bank 1 [info][DBLIB][SUBSADD] 14 0 [info][CM] Initializ[VAS] t:15 e Wifi [WIFIM] Request [WIFIM] init [VAS] t:15 wifi_chip_enable bcm43438_request == Set dcdc_sync == bcm43438_request: pwron module [WIFIMFW] current_fw == FW_2 1 version 1 size 80 [WIFIMFW] wifi_crc: 0 [WIFIMFW] Take current bank [WIFIMFW] Firmware block 1a8000 : OK [WIFIMFW] Wifi Offset 21a370, lenght 58d1d [WWD] HT Clock available in 31 ms [WWD] mac: a4:7e:fa:19:2c:f6 supported channels: 13 [WIFIM] init OK [info][CM] Wifi initialized [WIFIM] join_configured_ap [VAS] t:15 [WIFIM] ssid = ... [WIFIM] key  = ... [WIFIM] WPA key already saved [WWD] join: ssid=<...>, sec=0x00400004, key=<...> [WDM] wwdm_join_event_handler: state=1, wifim_err=9, stopped=0 [WDM] wwdm_join_event_handler: state=2, wifim_err=9, stopped=0 [WDM] wwdm_join_event_handler: state=2, wifim_err=0, stopped=1 [WDM] wwdm_join_event_handler: stopped [WWD] join: wiced_res=0, wifim_res=0 [info][WIFIM] join: attempt #0, rc=0 [info][WIFIM] join: SSID <...> join rc=0 after 1 attempts [VAS] t:15 [VAS] t:15 [info][WIFIM] join: RSSI=-64 [VAS] t:15 [WIFIM] connect: use static ip [WIFIM] Interface UP (Status : 0xf) [WIFIM] netif_up: use DHCP [WIFIM] Interface UP (Status : 0xf) [WIFIM] netif_up: [WIFIM] IP=192.168.0.9 [WIFIM] Mask=255.255.255.0 [WIFIM] Gw=192.168.0.1 [WIFIM] DNS[0]=192.168.0.1 [WIFIM] DNS[1]=0.0.0.0 [WIFIM] connect_cfg_ap: success [info][CM] Joined configured AP successfully [VAS] t:15 [info][CM] Store DbLib... [VAS] t:15 [DBLIB][ERASEBANK] Bank 2 [info][CM] Store DbLib done [HTT[VAS] t:15  S_CLIENT] Init [HTTPS_CLIENT] Init [info][CM] Wslib init successful, carry on [VAS] t:15  [WS] WsLib_StartSession  [WS] __WsLib_Once [WS] Https_client browsing <https://wbs06-ws.withings.net/once?appliver=1181&appname=WBS06&apppfm=device> [HTTPS_CLIENT] New connection or Adress/Security Changed [HTTPS_CLIENT] Close [HTTPS_CLIENT] Init [HTTPS_CLIENT] Handshake started {"status":0,"body":{"user":[{"userid":...,"screens":[{"id":66,"deactivable_status":6,"src":1,"embid":11,"rk":1}]},...]}} > [DBLIB][ERASEBANK] Bank 1 [WS] WSLIB_OK [WS] Https_client browsing <https://wbs06-ws.withings.net/v2/summary?appliver=1181&appname=WBS06&apppfm=device> [HTTPS_CLIENT] Socket already opened [WS] Params <action=getforscale&sessionid=...> {"status":0,"body":[{...}]} > [WS] WSLIB_OK [USLIB] FLUSH STORED MEASURE [USLIB] 0 measure(s) flushed [WS] Https_client browsing <https://wbs06-ws.withings.net/v2/weather?appliver=1181&appname=WBS06&apppfm=device> [HTTPS_CLIENT] Socket already opened [WS] Params <action=getforecast&sessionid=...short=1&enrich=t> ...

Я также попытался заменить хранящиеся в устройстве mTLS-сертификаты, чтобы упростить перехват трафика по Wi-Fi. Однако сервер отклонил подписанные мной сертификаты, как и положено.

Тем не менее, благодаря отладочным логам и различным данным о состоянии из памяти, мне удалось восстановить основную схему аутентификации:

1. Получив учетные данные Wi-Fi по Bluetooth от мобильного приложения, устройство может самостоятельно подключиться к API-серверу.

2. Устройство предъявляет свой сертификат и устанавливает соединение с API-сервером при помощи mTLS.

3. API-сервер возвращает одноразовый код (nonce).

4. Устройство подписывает nonce локальным приватным ключом и отправляет его серверу.

5. Сервер проверяет подпись, и если всё в порядке — возвращает токен сессии устройства.

6. Теперь устройство может обращаться к API-серверу, используя этот токен в качестве аутентификации.

Особый интерес представляет схема привязки пользователя к устройству. Ее можно реализовать двумя способами.

Первый способ (инициируется мобильным приложением пользователя):

1. Приложение уже обладает токеном сессии пользователя.

2. Оно получает токен сессии устройства по Bluetooth.

3. Приложение выполняет аутентификацию перед API-сервером с Session-Id: USER_SESSION_TOKEN и отправляет полезную нагрузку запроса userid=USER_ID& sessionidtoken=DEVICE_SESSION_TOKEN. userid — это простое инкрементируемое число.

4. API-сервер подтверждает валидность Session-Id и sessionidtoken, а затем привязывает userid к ID устройства, которому принадлежит DEVICE_SESSION_TOKEN.

Второй способ (инициируется самим устройством):

1. Устройство уже имеет свой токен сессии.

2. Оно получает токен сессии пользователя от приложения по Bluetooth.

3. Устройство выполняет аутентификацию перед API-сервером с Session-Id: DEVICE_SESSION_TOKEN и отправляет полезную нагрузку запроса deviceid=DEVICE_ID& sessionidtoken=USER_SESSION_TOKEN. deviceid — это простое инкрементируемое число.

4. API-сервер подтверждает валидность Session-Id и sessionidtoken, а затем привязывает deviceid к ID пользователя, которому принадлежит USER_SESSION_TOKEN.

Оба способа должным образом защищены; попытки заменить userid в первом сценарии или deviceid во втором приводили к сбою, потому что они не соответствовали токену сессии Session-Id.

Однако в логике приложения всё же обнаружилась критическая уязвимость. Возможно, лучше всего ее объяснит приближенная схема валидации на сервере:

if (req.session.isValid) {   if (!validateSession(req.body.sessionidtoken)) {     return error   }    const targetSession = fetchSession(req.body.sessionidtoken)   // инициированный приложением пользователя процесс   if (targetSession.type === 'device') {     associate(req.body.userid, targetSession.id)    // инициированный устройством процесс   } else if (targetSession.type === 'user') {     associate(req.body.deviceid, targetSession.id)   } }

В чем здесь ошибка? Представьте, что атакующий отправляет запрос, где и Session-Id, и sessionidtoken — это его пользовательский токен, но при этом в deviceid подставляется ID устройства, которым он не владеет.

Логика на сервере сочтет, что этот процесс был инициирован устройством — и не потребует подтверждения подлинности deviceid, то есть не проверит, что устройство действительно принадлежит владельцу сессии. Это позволяет перепривязать чужое устройство к своей учетной записи.

Безопасный код должен включать дополнительную проверку:

if (req.session.isValid) {   if (!validateSession(req.body.sessionidtoken)) {     return error   }    const targetSession = fetchSession(req.body.sessionidtoken)    // инициированный приложением пользователя процесс, валидирующий,       что привязываемый пользователь соответствует заголовку токена сессии   if (req.body.userid === req.session.id && targetSession.type === 'device') {     associate(req.body.userid, targetSession.id)    // инициированный устройством процесс, валидирующий,       что привязываемое устройство соответствует заголовку токена сессии   } else if (req.body.deviceid === req.session.id && targetSession.type === 'user') {     associate(req.body.deviceid, targetSession.id)   } }

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

---

Вендор отреагировал на уязвимость молниеносно. 29 декабря 2024 года я отправил вендору отчет, а уже 3 января компания ответила, что уязвимость исправлена.

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

Чему нас учит этот кейс? Когда речь идет о взломе «железа», масштабировать атаку за пределы одного устройства до полностью удаленного эксплойта бывает сложно. Привязка пользователя к устройству — критический участок, который может обходить аппаратные и сетевые средства защиты, ведь уязвимость находится на стороне API, а не на стороне устройства. Это особенно актуально для потребительских IoT-устройств, в которых ставка делается на простоту настройки и удобство.