开篇
上一篇文章log4j2的codeql规则我看了codeql官方的规则，然后发现了一个2020年的规则，从而推出很可能是codeql挖到的(现在哪个大佬还一个个代码看idea挖洞啊，那都是廉价安服小弟干的事情)
随着科学技术的发展和摩尔定律的规律，我们现在挖洞已经不是一个个看代码的php时代的时候了，其实这些0day难挖吗？我和你说 一点都不
我们现在挖掘漏洞有各种办法，一个是人经验上的阅读代码，一个是扫描，包括iast扫描，但是我看来，iast的挖掘0day和静态代码里的call graph差不多，没啥区别，只是iast动态的，静态代码遇到一些动态的场景会嗝屁。不过随着各种静态代码扫描的方式的改进，人们不断去研究安全方面的编译问题，使得未来这些问题都可以有办法迎刃而解。
lgtm
阿里的作者首先关注了codeql，并且关注了codeql的前身：lgtm。
https://lgtm.com/ 这个是他的官方网站，这个网站支持在线扫描一个github上的项目，当然是用codeql，这个codeql和我们去下载的codeql有啥区别？这个我还真的不知道。
我们来看一个有趣的页面
https://lgtm.com/projects/g/apache/logging-log4j2/alerts/?mode=list
打开这个url 你会看到一个commit为50979af的扫描结果，这个扫描是codeql扫描的。
我直接上结果
可以很明显看到codeql扫到了这次我们的0day，并且和我推测的一样，作者是用了已经别人写好的规则扫到的，这个规则在codeql的security目录下并且编号是cwe-074
CWE-074
我们来看下这个规则的具体逻辑，这个CWE-074规则之前一直处于试验状态，对应的编号是CWE-117，今年转正过了试用期，变成正式的规则了。
首先，这个规则是一个非常保守和常规的开局布局。里面写了2个数据流逻辑，我们看第一个，
source是remoteflowsource，这个类在广大安全工程师的迭代下已经相当完善了，这个source几乎是一个不用改的地方了，然后过滤也是很简单，java基础类型的都干掉，因为long什么的不可能jndi注入，最后是sink，sink里写了一大堆的可能点，这个和SQL注入里的jdbc.execute之类是一样的。
这个看着像是字节码，但是可能是codeql自己生成的一种ir。把大量的lookup之类的列入了sink。这种写法是比较原生的，我们拿到未解析之前的一个node就是这样的，作者比较懒。。。
第二条数据流进不说了，暂时和这个应该没关系。
结论
所以到这里，我们可以看到开源的东西，规则的确也是开源的，正如作者所说的，一切都是公开的，为什么你们没发现？
其实可能有些人发现了有些人没有，有的开发把lookup当作一个功能。但是我觉得不是，只是大家都在上班，没人工作就是挖这种0day，要么就是挖0day的人知道，不想公开而已。毕竟规则开源，这种的确很好挖的。真的没难度！！！！你以为组件的0day很难吗？可能你缺的是不知道如何编译原生jdk到codeql数据库 不知道如何写ql查询，不知道在什么情况下数据流断了，断了怎么连，xml怎么编译进去，怎么写ql的代码去识别自定义的框架等等。
我是不知道他们怎么想的，因为这个规则的诞生明显就说明一件事情：有安全人员知道sink是lookup的就是危险的，并且有那么多组件，咋就没人去扫下。。理论上挖hackerone的小伙子 如饥似渴。。。
总结
1.把你要扫描开源代码的git地址粘贴到lgtm网站里
2.等待扫描
3.等待阅读漏洞
4.拿0day去做法律范围内合法的事情，或者报告给官方，或者去刷hackerone都行。
当然真正的 用好codeql工具比上面这4个步骤更麻烦点。
题外话
1)fortify可以扫吗？
其实理论上是可以的，但是fortify就一言难尽，不是很友好的规则编写，在一些情况下难以编写扫描。
2)真的这么简单吗？codeql扫扫就挖到漏洞了？
是的，真的是扫扫就挖到了……
3)codeql怎么学啊?
看官方文档，或者国内一些同学的资料，我以前也写过，不过被我删了。有缘再放出来吧。
其实0day挖多了也就这样，时间久了你会和我一样觉得无聊，不就天天写写规则而已，无趣，有些apache项目，千疮百孔，我学codeql的时候，还以为自己遇到了一个靶场…，然后你就会一起来重新学习编译原理，然后一步步找资料，然后加各种编译原理的微信群，然后去听北大熊英飞老师的课，南大谭添老师的课等。那才是正确的方向，我们要自主可控这些东西，这方面的人才还是太少了，安全圈懂这些的也太少了，希望大家一起来卷南大谭添老师的课，哔哩哔哩地址是https://www.bilibili.com/read/cv14416770(碰巧今天谭老师刚公开他的全部课程，以前都是要走私下各种南大学生的渠道想办法搞到，很难的！)
谭老师和我差不多大 哎 真是年少有为啊！太强了 膜拜下。
好了，希望大家好好学习 不要挖无意义的0day，反正挖了也没啥用，我怀疑美国jun方早就把github用超算跑着，毕竟很多大厂都在做这个事情，武器库的0day级别不是一个等级的。log4j可能只是usa 棱镜计划里的冰山一角里的一角，小的可怜。
所以一起来看这个编译原理课程吧～ 为真正的国家安全做一份力。
原文始发于微信公众号（xsser的博客）：log4j2 的0day是如何被作者发现的
