简介
Wi-Fi 摄像头是家庭、企业和其他公共场所中最常见的物联网设备之一。它们往往价格相当实惠，并且让用户可以从全球任何地方通过移动设备轻松访问实时视频流。与物联网设备的情况一样，这些摄像头往往会忽略安全性，使其容易受到严重漏洞的影响。如果这些漏洞被利用，可能会对摄像头及其部署的网络造成毁灭性影响。它们可能会导致用户的敏感 PII 信息泄露。
最近的 Elastic ON Week 为我们提供了一个机会，来探索这些类型设备的攻击面，从而更深入地了解它们是如何被攻破的。我们主要专注于对 Wansview Q5（以及几乎相同的 Q6）进行漏洞研究，这是亚马逊上最受欢迎且价格实惠的摄像头之一。Wansview 是一家总部位于中国深圳的安全产品供应商，也是亚马逊 Wi-Fi 摄像头的主要分销商之一。
Q5 提供大多数摄像头中看到的相同基本功能集
- 平移/倾斜/变焦
- 夜视
- 双向音频
- 将视频录制到 SD 卡
- 与智能家居 AI 助手（例如 Alexa）集成
- ONVIF 与其他安全产品互操作
- RTSP 直接访问 LAN 中的视频源
- 从云端自动更新固件
- 远程技术支持
- 与其他帐户共享设备访问权限
- 云存储和运动检测的可选每月订阅
与大多数其他 Wi-Fi 摄像头一样，这些型号需要与供应商的云基础设施建立活动连接才能进行基本操作；如果没有互联网访问，它们根本无法运行。在摄像头上线之前，必须通过 Wansview 的官方移动应用程序和标准的 基于 QR 码的设置流程，将其与 注册用户帐户配对。完成此过程后，摄像头将完全在线并可操作。
AJCloud：简要介绍
尽管 Wansview 自 2009 年就开始运营，但目前他们似乎主要是转售由一家位于中国南京的独立公司：AJCloud 制造的摄像头产品。
AJCloud 为供应商提供对已制造的安全设备、必要的固件、移动和桌面用户应用程序、云管理平台以及将所有内容连接在一起的服务的访问权限。自 2018 年 AJCloud 成立以来，他们已与多家大型和小型供应商合作，包括但不限于以下公司
对 AJCloud 在 Google Play、Apple App Store 和 Microsoft Store 上开发和发布的移动和桌面应用程序进行粗略审查，可以发现它们与这些供应商的联系。除了表面上的公司品牌之外，这些应用程序在形式和功能上都相同，并且它们都需要与 AJCloud 管理平台连接。
至于摄像头，很明显，这些供应商销售的型号相似，只是对摄像头外壳和底层硬件进行了少量修改。
Faleemi 886 和 Wansview Q6 (1080p) 之间的相似之处显而易见
重用硬件制造和软件开发资源可能有助于控制成本并简化 AJCloud 及其经销商的物流。然而，这种资产的精简也意味着在一个摄像头型号中发现的安全漏洞很可能会渗透到与 AJCloud 相关的所有产品中。
尽管 AJCloud 在将这些设备推向消费者方面发挥着关键作用，但其公开形象相对较低。然而，IPVM 研究人员最近在 AJCloud 的 GitLab 存储库中 发布了一项关于重大漏洞的研究（该漏洞此后已得到解决）。此漏洞将允许任何用户在无需身份验证的情况下访问源代码、凭据、证书和其他敏感数据。
尽管 Wansview 和 Wi-Fi 摄像头领域的其他供应商的总销量难以确定，但 IPVM 估计，在其报告发布时，至少有一百万台设备连接到 AJCloud 平台。随着摄像头销量持续飙升至数亿，可以肯定的是，未来几年，全球各地的家庭将连接更多 AJCloud 的设备。
初步漏洞研究工作
为了更深入地了解 Wansview Q5 的安全状况，我们从多个角度对其进行了攻击
最初，我们的工作主要集中于对摄像头和 Wansview 官方移动应用程序 Android 版本的活动和被动网络侦察。我们扫描了开放端口，通过中间人 (MitM) 攻击窃听网络通信，尝试通过应用程序中的有意错误配置来诱使摄像头产生不可预测的行为，并通过滥用 QR 码格式和与摄像头进行物理交互来中断摄像头的运行。这些设备及其基础设施对这些类型的表面级攻击具有惊人的弹性，我们最初的努力几乎没有取得任何值得注意的成功。
我们尤其对我们未能成功拦截摄像头和应用程序上的网络通信感到惊讶。我们反复遇到了强大的安全功能（例如，证书固定、应用程序和操作系统版本限制以及正确保护的 TLS 连接），这些功能破坏了我们的尝试。
逆向工程工具使我们能够更仔细地分析 APK，尽管在反编译的 Java 源代码中观察到的代码混淆的复杂性将需要较长时间才能完全拼凑起来。
我们有限的初步成功将需要我们探索其他选择，以便更细致地了解 Q5 及其运行方式。
初步硬件破解
为了更深入地了解摄像头的功能，我们决定仔细研究摄像头固件。虽然一些固件包可以在网上找到，但我们想直接查看代码，并能够在摄像头运行时监控它和生成的日志。为此，我们首先查看了片上系统 (SoC) 的硬件图，看看是否有任何可以利用的硬件途径。Wansview Q5 使用 Ingenic Xburst T31 SoC，其系统框图如下所示。
我们注意到的一个途径是 I2Cx3/UARTx2/SPIx2 SPI I/O 块。如果可以访问，这些 I/O 块通常提供日志输出接口和/或 shell 接口，可用于调试和与 SoC 交互。看起来很有希望，然后我们对摄像头进行了硬件拆解，发现了似乎是 SoC 的 UART 串行接口，如下所示。
接下来，我们连接了一个逻辑分析仪，看看这些引脚上使用了什么协议，解码后，信号确实是 UART。
现在我们能够访问暴露的 UART 接口，接下来我们尝试通过 UART 建立到 SoC 的 shell 连接。有许多不同的软件机制可以做到这一点，但出于我们的目的，我们使用了 Unix 实用程序 screen，并使用了逻辑分析仪检测到的波特率。
在打开并监控启动序列后，我们发现尽管 SoC 支持安全启动，但它并未启用。然后，我们继续修改配置，以单用户模式启动，从而提供一个 root shell，供我们在初始化过程执行之前检查固件，如下所示。
一旦进入单用户模式，我们就可以使用 binwalk 实用程序提取固件文件进行静态分析，如下所示。
在这个阶段，文件系统通常是只读的；但是，我们希望能够进行编辑并根据需要实例化固件初始化的特定部分，因此我们做了一些快速设置，以便在单用户模式访问之外实现额外的持久性。这可以通过多种方式完成，但主要有两种方法可以选择。一般来说，在这两种方法中，人们都希望尽可能少地修改现有配置。如果可能的话，在运行动态分析时，通常首选这种方法，因为我们对运行时环境的影响最小。我们用于此方法的一种方法是创建一个 tmpfs 分区，用于内存中的读/写访问，并通过 fstab 挂载它。在我们的案例中，fstab 已经以支持这种方式考虑，因此使其成为非常小的更改。请参阅下面此方法的命令和结果。
另一种方法是提取现有的用户凭据并尝试使用这些凭据登录。这种方法也取得了成功。root 用户的密码哈希可以在 etc/passwd 文件中找到，并使用像 John the Ripper 这样的工具解密。在上面的示例中，我们完全通过串行连接传输数据和文件。该摄像头还有一个可用的 SD 卡插槽，可以挂载并用于传输文件。今后，我们将使用 SD 卡或本地网络来移动文件，因为带宽可以实现更快、更轻松的传输；但是，如果需要，串行仍然可以用于硬件设置和调试的所有通信。
现在，我们拥有对摄像头的 root 级访问权限，可以在软件运行时访问固件和 dmesg 日志。以固件和日志为参考，我们随后开始进一步检查摄像头的用户界面，看看是否有好的入口点可以用来获得更深入的了解。
Wansview Windows 云应用
在移动应用程序被证明比我们最初预期的更安全之后，我们将重点转移到了为 Windows 7 构建的旧版本的 Wansview Cloud 应用程序。这款应用程序仍然可以下载，它将为我们提供对连接到 AJCloud 平台的摄像头的网络通信的直接了解。
很大程度上归功于开发人员过于放纵的调试日志记录，Windows 应用程序以商业软件中罕见的鲁莽态度泄露了其机密信息。第一个表明事情不对劲的迹象是，用户登录凭据以明文形式记录。
由于频繁使用包含唯一字符串的详细日志消息，因此对主可执行文件和 DLL（与 Wansview Cloud APK 不同，它们没有打包）进行逆向工程得以加速。识别其底层代码库中特定文件和行的引用，有助于我们快速绘制出应用程序的核心组件并建立高级控制流。
网络通信，我们很难在 Android 上拦截，仍然通过 TLS 传输，尽管它们以明文形式方便地记录到磁盘。通过完全访问所有 HTTP POST 请求和响应数据（打包为 JSON 对象），无需进一步在应用程序端进行 MitM 攻击。
在 POST 响应中，我们发现了敏感的元数据，包括指向可公开访问的屏幕截图的链接，以及有关摄像头位置、网络配置和固件版本的信息。
在记录了日志数据中发现的所有 POST 请求和响应之后，我们开始尝试操纵每个请求中的不同字段，以尝试访问与我们的摄像头或帐户无关的数据。我们最终将使用调试器将 deviceId 更改为未与当前登录帐户配对的目标摄像头的 deviceId。摄像头 deviceId 兼作其序列号，可以在摄像头背面或底部的贴纸标签上找到。
我们在一个代码部分中找到了最合适的攻击目标，其中 deviceId 首先在 POST 请求中传输到 https://sdc-us.ajcloud.net/api/v1/dev-config
我们的计划是在上面屏幕截图中突出显示的指令处设置断点，交换内存中的 deviceId，然后允许应用程序恢复执行。
令人惊讶的是，这种幼稚的方法不仅可以检索存储在 AJCloud 平台中与目标摄像头及其绑定的帐户相关的敏感数据，还可以将我们连接到摄像头本身。这使我们可以访问其视频和音频流，并通过该应用程序远程控制它，就像它是我们自己的摄像头一样。
通过利用此漏洞并针对来自不同供应商的多种型号进行测试，我们确定以这种方式可以远程访问和控制连接到 AJCloud 平台的所有设备。我们编写了一个 PoC 漏洞利用脚本来自动化此过程，并有效地演示了 AJCloud 基础设施中这种访问控制漏洞可以被轻而易举地利用。
探索网络通信
尽管我们能够构建并可靠地触发针对 AJCloud 平台中一个关键漏洞的漏洞利用，但我们需要进一步挖掘，以便更好地了解应用程序、摄像头固件和云基础设施的内部工作原理。
当我们探索登录过程中观察到的 POST 请求和响应之外的内容时，我们注意到来自各种 IP 的大量 UDP 请求和响应。在这些通信中，几乎找不到任何可辨别的明文数据，并且出站请求的目标 UDP 端口号似乎各不相同。进一步的调查后来显示，这种 UDP 活动是指示 PPPP 的，这是一种 IoT 对等 (P2P) 协议，Paul Marrapesse 在他的 DEF CON 28 演讲中对其进行了广泛的分析和演示。我们后来得出结论，我们利用发现的漏洞的方式是通过修改后的 P2P 请求来实现的，这导致我们进一步探索 P2P 在 AJCloud 平台中发挥的关键作用。
P2P 的主要目的是促进应用程序和 IoT 设备之间的通信，无论涉及哪些网络配置。P2P 主要采用基于 UDP 打洞 的方法来创建临时通信路径，允许请求直接或通过位于更易于访问的网络环境中的中继服务器到达其目标。集成到 AJCloud 应用程序中的核心 P2P 命令集提供对视频和音频流的访问，以及麦克风和云台/俯仰/变焦的访问。
高级硬件破解
通过我们对 P2P 通信的进一步了解，现在是时候在这些 P2P 对话期间更仔细地检查摄像头本身了，包括在调试器中运行摄像头软件。首先，我们通过之前建立的 UART 串行连接设置了摄像头的实时日志输出，如下所示。
这提供了对应用程序的日志消息以及我们需要的任何其他日志源的实时查看。从这些信息中，我们确定了用于在摄像头和云之间建立通信的主要二进制文件，以及提供通过 P2P 访问摄像头的接口的二进制文件。
这个二进制文件在本地被称为 initApp，它在摄像头完全初始化并且启动序列完成后运行。鉴于此，我们着手使用调试器运行这个二进制文件，以更好地评估本地函数。在尝试这样做时，我们遇到了一个内核看门狗，它检测到 initApp 何时没有运行，并且如果检测到问题，会强制重启摄像头。此看门狗检查对 /dev/watchdog 的写入，如果这些写入停止，将触发一个计时器，如果写入没有恢复，该计时器将重启摄像头。这使得调试更加困难，因为当暂停 initApp 的执行时，对看门狗的写入也会暂停。下面显示了此停止行为的示例
为避免这种情况，可以在 initApp 停止时尝试写入看门狗以防止重启。但是，另一种更简洁的选择是利用 Linux 内核看门狗驱动程序 API 的魔术关闭功能。简而言之，如果写入特定的魔术字符“V” /dev/watchdog，看门狗将被禁用。还有其他方法可以禁用看门狗，但这是我们为研究选择的方法，因为它使您可以随意启用和禁用看门狗。
禁用看门狗后，设置调试 initApp 就相当简单了。我们希望尽可能直接在摄像头上运行代码，而不是使用模拟器。摄像头的架构是小端 MIPS (MIPSEL)。我们很幸运，预先构建的 GDB 和 GDBServer 二进制文件能够正常运行而无需修改；但是，我们最初并不知道这一点，因此我们还设置了一个工具链来专门为摄像头编译 GDBServer。如果您发现自己处于类似的情况，一种可能有效的方法是使用像 gcc 这样的编译工具将一些源代码编译到您怀疑的目标架构，看看它是否运行；请参阅下面的示例。
在我们的案例中，由于我们知道我们的 SoC，我们对目标架构相当确定；但是，在某些情况下，这可能没有那么容易发现，从 hello world 二进制文件开始工作有助于建立初步的理解。一旦我们能够编译二进制文件，我们随后为我们的摄像头编译了 GDBServer，然后使用它来附加和启动 initApp。然后，我们从与摄像头位于同一本地网络的另一台计算机连接到它。下面显示了一个示例
作为上述示例的说明，我们为了方便起见使用了 -x 参数来传递一些命令，但它们对于调试来说不是必需的。有关任何文件或命令的更多信息，请参阅我们的 elastic/camera-hacks GitHub 仓库。为了使 initApp 正常加载，我们还需要确保二进制文件使用的库可以通过 PATH 和 LD_LIBARY_PATH 环境变量访问。完成此设置后，我们便可以根据需要调试二进制文件。由于我们之前还使用了魔术字符方法来绕过看门狗，因此我们还需要确保控制看门狗可以重新启用的情况。在大多数情况下，我们不希望发生这种情况。因此，我们覆盖了 initApp 中的看门狗调用，以便在调试时不会重新启用看门狗，如下所示。
以下视频显示了从启动到运行 GDBServer 的完整设置过程。在视频中，我们还启动了一个新的 initApp 进程，因此我们需要杀死原始进程和 daemon.sh shell 脚本，如果它被杀死，该脚本将生成一个新的 initApp 进程。
构建 P2P 客户端
为了进一步探索 P2P 为 AJCloud IoT 设备提供的全部功能，以及攻击者如何滥用这些功能，我们着手构建我们自己的独立客户端。这种方法将消除操作 Wansview Cloud Windows 应用程序的开销，同时允许我们更快地连接到摄像头并测试我们从固件逆向工程中获得的命令。
从我们之前从 Windows 应用程序日志中获取的配置数据中，我们知道客户端会向最多三个不同的服务器发出请求，作为连接过程的一部分。这些服务器向客户端提供有关流量应如何路由以访问给定摄像头的说明。如果您想在公开场合发现更多这些服务器，您可以使用以下四字节 UDP 有效负载在端口 60722 上扫描互联网。Paul Marrapese 在他的研究中非常有效地使用了这项技术。
为了正确建立 P2P 连接，客户端必须首先发送一个简单的 hello 消息（MSG_HELLO），这需要由对等服务器进行确认（MSG_HELLO_ACK）。然后，客户端会向服务器查询（MSG_P2P_REQ）特定的 deviceId。如果服务器知道该设备，则它将向客户端响应（MSG_PUNCH_TO）目标 IP 地址和 UDP 端口号对。然后，客户端将尝试连接（MSG_PUNCH_PKT）到 IP 和端口对，以及 预定范围内的其他端口，作为 UDP 打孔例程的一部分。如果成功，目标将向客户端发送一条消息（MSG_PUNCH_PKT），以及一条最终消息（MSG_P2P_RDY）以确认连接已建立。
连接到摄像头后，我们主要感兴趣的是发送不同的 MSG_DRW 数据包并观察它们的行为。这些数据包包含允许我们物理操作摄像头、查看和收听其视频和音频流、访问其中存储的数据或更改其配置的命令。我们首先开始使用的最简单的命令是逆时针平移摄像头，我们可以很容易地将其识别为单条消息传输。
摄像头上的调试日志消息使我们能够轻松定位固件中处理此命令的位置。
定位此特定消息的来源使我们进入了处理 MSG_DRW 消息的主例程，这为我们提供了关于如何调用此命令以及固件支持的其他命令的关键见解。
广泛的逆向工程和测试使我们能够构建一个 PoC P2P 客户端，该客户端允许用户连接到 AJCloud 平台上的任何摄像头，前提是他们可以访问其 deviceId。客户端支持的基本命令包括摄像头平移和倾斜、重启、重置、播放音频剪辑，甚至使固件崩溃。
我们能够实现的最危险的功能是通过修改核心设备配置文件实现的：/var/syscfg/config_default/app_ajy_sn.ini。在我们的测试摄像头上，该文件的内容最初如下：
[common]
product_name=Q5
model=NAV
vendor=WVC
serialnum=WVCD7HUJWJNXEKXF
macaddress=
wifimacaddress=虽然这看起来包含基本的设备元数据，但此文件是摄像头知道如何识别自己的唯一手段。启动时，摄像头会读取此文件的内容，然后尝试通过一系列 curl 请求连接到 AJCloud 平台，以访问各种 API 端点。这些 curl 请求会传递从 INI 文件中提取的产品名称、摄像头型号、供应商代码和序列号值作为查询字符串参数。我们使用我们的客户端来传递一条消息，该消息会覆盖如下内容
[common]
product_name=
model=OPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~HH01
vendor=YZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~HH01
serialnum=defghijklmnopqrstuvwxyz{|}~HH01
macaddress=
wifimacaddress=重置摄像头后，由于 INI 文件中包含的格式错误的数据，所有作为启动例程一部分发出的到 AJCloud 平台 API 端点的 curl 请求都将失败。这些请求将继续定期发送，但它们永远不会成功，摄像头将保持不活动状态，并且无法通过任何应用程序访问。不幸的是，没有简单的方法可以通过重置摄像头、更新其固件或恢复出厂设置来恢复以前的文件内容。通过此命令进行的文件修改将有效地使摄像头变砖并使其无法使用。
仔细查看反编译的函数（syscfg_setAjySnParams），该函数覆盖 app_ajy_sn.ini 中存储的值，我们可以看到从 MSG_DRW 命令中提取的输入参数用于传递字符串数据，这些数据将用于覆盖文件中的型号、供应商和序列号字段。memset 用于将三个全局变量（旨在存储这些输入字符串）覆盖为 null 字节。然后，strcpy 用于将输入参数传输到这些全局变量中。在每种情况下，这都会导致字节直接从 MSG_DRW 命令缓冲区复制，直到遇到空字符。
由于对从命令中提取的这些输入参数的长度没有强制执行验证，因此构造足够长度的消息来触发缓冲区溢出是微不足道的。虽然我们没有利用此漏洞作为攻击的一部分来使摄像头变砖，但这似乎是一个可以开发利用程序以允许攻击者在摄像头上实现远程代码执行的实例。
影响
我们已确认，隶属于 AJCloud 的多家供应商和多个不同固件版本的各种设备都受到这些漏洞和缺陷的影响。总的来说，我们成功地对 Wansview、Galayou、Cinnado 和 Faleemi 的十五种不同的摄像头产品进行了攻击。根据我们的发现，可以安全地假设所有运行 AJCloud 固件并连接到 AJCloud 平台的设备都会受到影响。
所有联系 AJCloud 和 Wansview 以披露这些漏洞和缺陷的尝试均未成功。
供应商做对了什么？
尽管我们之前发现并讨论了漏洞，但 AJCloud 和摄像头供应商实施的许多安全控制措施都做得很好。对于如此低成本的设备，实施了许多最佳实践。首先，网络通信使用基于证书的 WebSocket 身份验证进行安全保护。除了添加加密之外，将许多 API 端点置于证书身份验证之后，使得中间人攻击的难度大大增加。此外，移动应用程序的 APK 已签名和混淆，使得操作这些应用程序非常耗时。
此外，供应商在摄像头硬件和固件方面也做出了一些明智的决定。摄像头的本地操作系统实际上是有限的，仅专注于其产品所需的功能。文件系统配置为只读，除了日志记录，并且内核看门狗是一种确保正常运行时间并降低陷入故障状态风险的有效方法。Ingenic Xburst T31 SoC 提供了一个功能强大的平台，具有广泛的支持，包括安全启动、上电复位 (POR) 看门狗和一个单独的 RISC-V 处理器，该处理器能够在摄像头输入上运行一些基本的机器学习。
供应商做错了什么？
不幸的是，这些可用功能存在许多错失的机会。可能最严重的错误是未经身份验证的云访问。鉴于为许多端点建立的 API 访问控制，让摄像头用户通过序列号访问端点而无需身份验证是一个巨大且可以避免的失误。P2P 协议也存在漏洞，正如我们所展示的那样，但与应立即修复的 API 访问相比，这可能需要更多的时间来修复协议。这是一个非常危险的漏洞，但它更容易理解一些，因为它需要投入更多的时间来发现和修复。
从应用方面来看，主要问题在于 Windows 应用程序，它具有大量的调试日志，这些日志本应在公开发布前删除。至于硬件方面，通过物理访问（例如，暴露的复位按钮等）可以很容易地进行操控。考虑到目标消费受众，这并不是什么大问题。预期会倾向于可用性而不是安全性，特别是考虑到可以物理访问设备的情况。类似地，应该启用安全启动，特别是考虑到 T31 SoC 支持它。虽然不是绝对必要，但这会使直接调试设备的源代码和固件变得更加困难，从而更难发现可能存在的漏洞。理想情况下，它的实现方式应允许引导加载程序仍然加载未签名的操作系统，以便于进行修改和开发，但会阻止已签名的操作系统加载，直到恢复引导加载程序配置。然而，当前固件的一个重大缺陷是依赖于原始序列号，该序列号在系统运行时未存储在只读挂载点中。篡改序列号不应使设备永久报废。它应该具有请求新序列号（或恢复其原始序列号）的机制，如果其序列号被覆盖，或者序列号应该是不可变的。
缓解措施
可以采取某些步骤来减少攻击面，并限制在发生攻击事件时可能产生的不利影响，尽管它们的有效性各不相同。
将 Wi-Fi 摄像头和其他物联网设备与网络的其余部分隔离是一个强烈建议的对策，这将阻止攻击者横向渗透到更关键的系统。但是，这种方法并不能阻止攻击者通过利用我们在 AJCloud 平台中发现的访问控制漏洞来获取敏感的用户数据。此外，考虑到我们能够轻松演示如何通过 P2P 远程访问和操纵摄像头，无论其本地网络配置如何，任何连接到 AJCloud 平台的设备仍然面临严重的泄露风险。
由于连接到 AJCloud 平台对于这些摄像头的运行至关重要，因此限制进出这些摄像头的任何网络通信是不可行的。如前所述，如果设备无法在启动时连接到各种 API 端点，则它们将无法运行。
一种可行的方法可以是限制超出初始启动例程的通信。但是，这将阻止通过移动和桌面应用程序进行远程访问和控制，这将完全违背这些摄像头的初衷。有关此领域的进一步研究，请参阅“在不破坏的情况下进行阻止：识别和缓解非必要的物联网流量”，其中更深入地探讨了跨各种物联网设备和供应商的这种方法。
在保持核心功能的同时，保护任何 Wi-Fi 摄像头的最佳方法（无论供应商如何）是将其刷新为替代的开源固件，例如 OpenIPC 或 thingino。切换到开源固件避免了被迫连接到供应商云平台的麻烦，因为它为用户提供了对设备配置和远程网络可访问性的细粒度控制。开放访问固件源代码有助于确保关键缺陷和漏洞能够被勤奋的项目贡献者快速识别和修补。
要点
我们的研究揭示了操作 AJCloud 固件并连接到其平台的所有摄像头方面的几个关键漏洞。其平台上访问控制管理的重大缺陷和 PPPP 对等协议提供了广阔的攻击面，影响着全球数百万个活动设备。利用这些缺陷和漏洞会导致敏感用户数据泄露，并为攻击者提供对任何连接到 AJCloud 平台的摄像头的完全远程控制。此外，一个内置的 P2P 命令，故意提供对关键配置文件的任意写入访问权限，可以用来永久禁用摄像头或通过触发缓冲区溢出来促进远程代码执行。
请访问我们的 GitHub 存储库，获取我们构建的自定义工具和脚本，以及我们捕获的数据和注释，我们认为这些数据和注释将为安全研究社区提供最大的好处。