审计审计审计

首先需要明白的是, 审计不是单纯的阅读代码, 而是结合具体的程序, 溯源到代码段来理解程序的作用机理, 必要的时候通过断点调试来追踪变量的传递过程, 从而从代码层找到程序的漏洞和利用方法

审计的最终目的是全面理解应用程序并挖掘出所有可能的漏洞, 而在不同的情境下侧重点会有所不同, 针对企业内部和开源程序的审计, 更倾向于”全”, 在有限的时间内尽可能的找到更多的漏洞, 而针对CTF下的代码审计, 更倾向于”快”, 更快速的找到并利用漏洞会带来极大的优势

0x01 工具

自动审计工具

seay的代码审计工具和rips, rips用于找一些比较简单的漏洞, 而seay的自动审计更倾向于寻找潜在可控的敏感函数, 以及整体的代码结构和开发者的编码习惯

阅读代码

JetBrains的IDE, 提供了强大的全局搜索和函数追踪, 配合xdebug可以比较方便的在浏览器下断点调试

0x02 思路

针对每种漏洞的具体思路放在后面说, 这里只说一下整体的思路

首先是面向”全”的审计, 比如审计一个cms, 首先应该把他安装上, 查看安装每一步的参数和url变化, 安装完之后大体的试用一下, 查看页面的路由规则和基本功能, 再打开源码进行审计, 有闲心的话可以放进自动审计里跑下, 可以看到一些开发者对危险函数的过滤函数名字和开发者的编码习惯, 例如喜欢用$query这个变量来存储sql查询语句, 就可以全局搜索$query来寻找可能的注入点, 对代码基本框架的阅读可以让你对整体的编码结构和习惯有初步的了解, 以及在找到漏洞之后更好的追溯漏洞的触发过程,

对于CTF中面向”快”的审计,

0x03 敏感函数

参考之前发的代码审计cookbook

0x04 漏洞类型

sql注入

现在的cms框架中都会有控制整体数据库查询的函数或者类, 在审计sql注入的时候首先要看的是所有的查询构造函数, 如果在构造函数处找到了漏洞那么就可以直接追溯到使用它的地方, 比如之前看的textpattern cms, 在textpattern/lib/txplib_db.php中273行有一个函数是这样的:

预处理传递的表名, 但是这个正则没有过滤反引号所以可以直接用反引号闭合进行注入, 同样的错误也发生在1045行的fetch函数中

对传递进来的列名的过滤也可以绕过, 但是可惜的是这两个地方处理的是表名和列名, 并没有找到用户可控的地方, 而整个框架对用户输入的字符查询都用引号包裹并且转义了输入中的引号, 对int类型的查询做了强制int转换, 所以基本没有可控的注入点, 然而这样的处理方法有一定的局限性, 开发者要对所有可能的输入都手动转义一次, 这极有可能会出现疏忽

如果在整体的数据库查询函数中没有找到明显的漏洞的话, 那就只能找开发者在函数利用中的疏忽, 例如之前的CVE-2017-1000006 EyesofNetwork中的sql注入, 开发者不恰当的使用了数据库查询函数导致拼接造成注入:

还有之前看的pragyan cms, 对传入sql查询的参数用了htmlspecialchars来处理, 导致完全没用:

当然还会出现许多更加难以利用的注入方式,

命令执行

命令执行的发现较为线性, 只需要追溯所有敏感函数的参数传递过程, 找到可控的即可, 比如之前学弟看的codiad

敏感函数shell_exec里传入了用户可控的参数,

文件上传

文件包含

xss

xxe

参考文献

EyesofNetwork SQL注入和代码执行CVE分析

WordPress 由格式化字符串引发的后台SQL注入漏洞

Codiad在线IDE框架远程命令执行漏洞分析