Exim CVE-2020-28018 漏洞分析
测试debian和ubuntu的exp相差还是比较大的，不过后续研究发现是版本问题，如果不嫌麻烦，可以研究研究通杀的方法。Github公开的那个EXP不太行，我测试的两个版本都没戏，离能用的exp还相差比较多，当成探测的PoC还差不多
其中crt和key的生成脚本如图
测试debian和ubuntu的exp相差还是比较大的，不过后续研究发现是版本问题，如果不嫌麻烦，可以研究研究通杀的方法。Github公开的那个EXP不太行，我测试的两个版本都没戏，离能用的exp还相差比较多，当成探测的PoC还差不多
其中crt和key的生成脚本如图
被标记后再次访问主页就会被拦截器拦下。
这个方法原理很简单，使用成本很低，且检测时不容易被注意到。
第二种方式是直接删除 burpsuite jar包里的favicon.ico文件，不过需要注意的是这种方法只能防 img 标签访问 favicon.ico，script 标签不行的。第三种是在代理配置选关闭web接口选项
zip -d burpsuite_pro.jar "resources/Media/favicon.ico"
这个方法原理很简单，使用成本很低，且检测时不容易被注意到。
第二种方式是直接删除 burpsuite jar包里的favicon.ico文件，不过需要注意的是这种方法只能防 img 标签访问 favicon.ico，script 标签不行的。第三种是在代理配置选关闭web接口选项
zip -d burpsuite_pro.jar "resources/Media/favicon.ico"
堆的unlink利用
我们知道link有链的意思，那unlink同理有解链的意思，unlink实际上就是在free堆块时把双向链表中的空闲堆块取出与和它地址相连已经释放的堆块进行合并，虽然malloc也会解链但没有使用unlink宏。以small bin为例（fast bin因为是单链表不会发生unlink，small bin和large bin是双链表可以发生unlink），当small bin中有一个已经释放的堆块时，假如现在要free一个和small bin中已经释放的堆块地址相连的堆块，不管要free的堆块在释放的堆块前面还是后面，都会触发堆块合并，而small bin因为是双链表以fd和bk连接堆块会触发unlink。
以wiki上的这张图为例先对unlink有个大致了解：最初small bin中的堆块应该像上图最上面那样连接，p是我们刚才free的堆块，此时p->fd=FD，FD->bk=p，p->bk=BK，BK->=fd=p，等unlink完后到了上图最下面，FD->bk=BK，BK->fd=FD，如果学过数据结构应该能够知道，这时的p已经被解了下来，在unlink合并堆块这个过程中，如果p与FD地址相连，则合并后的p应该在FD的data中，然后BK和FD直接相连，这就是free触发的unlink。
我们知道link有链的意思，那unlink同理有解链的意思，unlink实际上就是在free堆块时把双向链表中的空闲堆块取出与和它地址相连已经释放的堆块进行合并，虽然malloc也会解链但没有使用unlink宏。以small bin为例（fast bin因为是单链表不会发生unlink，small bin和large bin是双链表可以发生unlink），当small bin中有一个已经释放的堆块时，假如现在要free一个和small bin中已经释放的堆块地址相连的堆块，不管要free的堆块在释放的堆块前面还是后面，都会触发堆块合并，而small bin因为是双链表以fd和bk连接堆块会触发unlink。
以wiki上的这张图为例先对unlink有个大致了解：最初small bin中的堆块应该像上图最上面那样连接，p是我们刚才free的堆块，此时p->fd=FD，FD->bk=p，p->bk=BK，BK->=fd=p，等unlink完后到了上图最下面，FD->bk=BK，BK->fd=FD，如果学过数据结构应该能够知道，这时的p已经被解了下来，在unlink合并堆块这个过程中，如果p与FD地址相连，则合并后的p应该在FD的data中，然后BK和FD直接相连，这就是free触发的unlink。
通过入侵官方 Cask 存储库在 Homebrew 中实现远程代码执行
在Homebrew/homebrew-cask存储库中，可以通过混淆 Homebrew 项目开发的自动拉取请求审查脚本中使用的库来合并恶意拉取请求。
通过滥用它，攻击者可以在使用 的用户机器上执行任意 Ruby 代码brew。
一天下午，在下一个约会1之前我还有一点时间，所以我决定在 HackerOne 上寻找一个有趣的程序。
因为我想在我使用的软件/服务中找到一个漏洞，所以我在电脑上四处张望，这个brew命令引起了我的注意。
然后，我记得我在 HackerOne 上看到了一个名为 Homebrew 的程序，所以我决定在其中找到漏洞。
为了选择目标，我查看了漏洞披露计划的政策页面。我注意到Homebrew/homebrew-*存储库在范围内。
由于我不擅长阅读复杂的 Ruby 代码，我决定在 中查找漏洞Homebrew/homebrew-
在Homebrew/homebrew-cask存储库中，可以通过混淆 Homebrew 项目开发的自动拉取请求审查脚本中使用的库来合并恶意拉取请求。
通过滥用它，攻击者可以在使用 的用户机器上执行任意 Ruby 代码brew。
一天下午，在下一个约会1之前我还有一点时间，所以我决定在 HackerOne 上寻找一个有趣的程序。
因为我想在我使用的软件/服务中找到一个漏洞，所以我在电脑上四处张望，这个brew命令引起了我的注意。
然后，我记得我在 HackerOne 上看到了一个名为 Homebrew 的程序，所以我决定在其中找到漏洞。
为了选择目标，我查看了漏洞披露计划的政策页面。我注意到Homebrew/homebrew-*存储库在范围内。
由于我不擅长阅读复杂的 Ruby 代码，我决定在 中查找漏洞Homebrew/homebrew-
Skywalking远程代码执行漏洞预警
Skywalking历史上存在两次sql注入漏洞，CVE-2020-9483、CVE-2020-13921。经过源码分析，发现两次sql注入漏洞修复并不完善，仍存在一处sql注入漏洞。(该请求无页面入口，需要根据graphql配置文件手动进行请求构造，或许这就是官方遗漏该注入点的原因)
Skywalking默认配置下使用的数据库为h2，且使用sa权限启动。
另一个LINK_SCHEMA函数可以指定并发起一次jdbc或者jndi请求，但由于目标环境中无tomcat和springboot依赖，所以在高版本jdk中也无法进行通用的jndi利用，需要在本地依赖中寻找reference链。
于是我们可以先利用任意文件写入函数在classpath中写一个恶意类，然后再使用LINK_SCHEMA函数来加载这个恶意类，实现远程代码执行。
Skywalking历史上存在两次sql注入漏洞，CVE-2020-9483、CVE-2020-13921。经过源码分析，发现两次sql注入漏洞修复并不完善，仍存在一处sql注入漏洞。(该请求无页面入口，需要根据graphql配置文件手动进行请求构造，或许这就是官方遗漏该注入点的原因)
Skywalking默认配置下使用的数据库为h2，且使用sa权限启动。
另一个LINK_SCHEMA函数可以指定并发起一次jdbc或者jndi请求，但由于目标环境中无tomcat和springboot依赖，所以在高版本jdk中也无法进行通用的jndi利用，需要在本地依赖中寻找reference链。
于是我们可以先利用任意文件写入函数在classpath中写一个恶意类，然后再使用LINK_SCHEMA函数来加载这个恶意类，实现远程代码执行。
UNION 注入
和其他类型的数据库一样，基本没什么差别
先通过 order by 查当前表的 column 数量,13 返回正常，14报错，说明 column 有 13 个。注入出数据库账号密码
和其他类型的数据库一样，基本没什么差别
先通过 order by 查当前表的 column 数量,13 返回正常，14报错，说明 column 有 13 个。注入出数据库账号密码
报错注入
主流的报错注入方式主要分为两类。
一类是 mysql、Oracle 这种使用自带函数使错误抛出的信息中携带参数值。另一类是 sqlserver 这种转型报错。
因为转型在这里并不适用，所以开始看一些函数的源码。
其中我关注到了 LOAD_FILE函数，发现它会把参数当做文件去读取，一旦遇到文件无法读取的情况就会把文件路径带入到报错信息中输出。
从源码中来看就是文件没读到，抛出了一个异常，在message中把这个路径给带了出来。
主流的报错注入方式主要分为两类。
一类是 mysql、Oracle 这种使用自带函数使错误抛出的信息中携带参数值。另一类是 sqlserver 这种转型报错。
因为转型在这里并不适用，所以开始看一些函数的源码。
其中我关注到了 LOAD_FILE函数，发现它会把参数当做文件去读取，一旦遇到文件无法读取的情况就会把文件路径带入到报错信息中输出。
从源码中来看就是文件没读到，抛出了一个异常，在message中把这个路径给带了出来。