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