今天随意查询了下codeql官方有不有对log4j2的扫描规则,发现了一个最新的提交
https://github.com/github/codeql/pull/7354/commits/43a10457dd465a0253f4b1e7316ff17091263cd2
但是这个不是最有趣的。
有趣的是,2020年jul 3 ,就有人提交了一个一模一样的pr。
https://github.com/github/codeql/pull/3882
但是这个是纯粹的log注入,但是碰巧的是。卧槽 这条规则可以识别到这次的jndi注入。。震惊。。。
换句话说,如果你用codeql扫下 可能完全可以发现这个0day
这次的这个漏洞的调用链是真特么的长,像fortify之类的 扫描为了速度 可能会把调用链控制在一定范围 可能导致扫不到,而且这个lookup是一个在第三方jar里的方法,我不知道logger.error之类的有不有列到sink里。
其实大部分0day 都可以扫出来。。。。。写个codeql规则 没那么难 只是阅读和理解这个工具 以及背后的原理比较要花点时间。
原文始发于微信公众号(xsser的博客):log4j2的codeql规则
免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论