攻防启示：Chromium组件风险剖析与收敛
数月前我们在攻防两个方向经历了一场“真枪实弹”的考验，期间团队的目光曾一度聚焦到Chromium组件上。
其实，早在 Microsoft 2018年宣布 Windows的新浏览器Microsoft Edge将基于Chromium内核进行构建之前，伴随互联网发展至今的浏览器之争其实早就已经有了定论，Chromium已然成为现代浏览器的事实标准，市场占有率也一骑绝尘。在服务端、桌面还是移动端，甚至据传SpaceX火箭亦搭载了基于Chromium开发的控制面板。
Chromium主要包含两大核心组成部分：渲染引擎和浏览器内核。
2.1.1 渲染引擎
Chromium目前使用Blink作为渲染引擎，它是基于webkit定制而来的，核心逻辑位于项目仓库的third_party/blink/目录下。渲染引擎做的事情主要有：
1) 解析并构建DOM树。Blink引擎会把DOM树转化成C++表示的结构，以供V8操作。
2) 调用V8引擎处理JavaScript和Web Assembly代码，并对HTML文档做特定操作。
3) 处理HTML文档定义的CSS样式
4) 调用Chrome Compositor，将HTML对应的元素绘制出来。这个阶段会调用OpenGL，未来还会支持Vulkan。在Windows平台上，该阶段还会调用DirectX库处理；在处理过程中，OpenGL还会调用到Skia，DirectX还会调用到ANGLE。
数月前我们在攻防两个方向经历了一场“真枪实弹”的考验，期间团队的目光曾一度聚焦到Chromium组件上。
其实，早在 Microsoft 2018年宣布 Windows的新浏览器Microsoft Edge将基于Chromium内核进行构建之前，伴随互联网发展至今的浏览器之争其实早就已经有了定论，Chromium已然成为现代浏览器的事实标准，市场占有率也一骑绝尘。在服务端、桌面还是移动端，甚至据传SpaceX火箭亦搭载了基于Chromium开发的控制面板。
Chromium主要包含两大核心组成部分：渲染引擎和浏览器内核。
2.1.1 渲染引擎
Chromium目前使用Blink作为渲染引擎，它是基于webkit定制而来的，核心逻辑位于项目仓库的third_party/blink/目录下。渲染引擎做的事情主要有：
1) 解析并构建DOM树。Blink引擎会把DOM树转化成C++表示的结构，以供V8操作。
2) 调用V8引擎处理JavaScript和Web Assembly代码，并对HTML文档做特定操作。
3) 处理HTML文档定义的CSS样式
4) 调用Chrome Compositor，将HTML对应的元素绘制出来。这个阶段会调用OpenGL，未来还会支持Vulkan。在Windows平台上，该阶段还会调用DirectX库处理；在处理过程中，OpenGL还会调用到Skia，DirectX还会调用到ANGLE。
其中 10.10.10.209 还是一个 Outlook Web App（微软的邮件组件）Exchange
知道了两个用户邮箱：moonsec@cncat.cc、test@cncat.cc
然后把文件都下载到本地，进行后续利用
知道了两个用户邮箱：moonsec@cncat.cc、test@cncat.cc
然后把文件都下载到本地，进行后续利用
数据查询数量可控
想必如下这类接口大家都见多了吧：
/api/getInfo?page=1&page_size=10 ...
/api/viewData?startTime=&endTime=1591258015173 ...
...
而这类接口通常都是调用数据的，当一个系统数据量十分大（这也是拒绝服务的前提）的时候就需要分页功能去优化性能，那我们尝试将这个可控的数据查询量的参数数值进行修改会怎么样？比如page_size=10000，再去请求会发现服务器明显有返回延迟（大量数据的查询展示）
那如果是page_size=100000000000呢？想象一下，从查询到数据格式的处理返回展示，要占用巨大的服务器资源，我们如果尝试去多次重放此类请求，服务器终究还是无法承受这样的“力量”，最后导致宕机…
时间参数startTime也是如此，我们可以置空或设为0让其查询数据的时间范围为最大…以此类推、举一反三。
想必如下这类接口大家都见多了吧：
/api/getInfo?page=1&page_size=10 ...
/api/viewData?startTime=&endTime=1591258015173 ...
...
而这类接口通常都是调用数据的，当一个系统数据量十分大（这也是拒绝服务的前提）的时候就需要分页功能去优化性能，那我们尝试将这个可控的数据查询量的参数数值进行修改会怎么样？比如page_size=10000，再去请求会发现服务器明显有返回延迟（大量数据的查询展示）
那如果是page_size=100000000000呢？想象一下，从查询到数据格式的处理返回展示，要占用巨大的服务器资源，我们如果尝试去多次重放此类请求，服务器终究还是无法承受这样的“力量”，最后导致宕机…
时间参数startTime也是如此，我们可以置空或设为0让其查询数据的时间范围为最大…以此类推、举一反三。
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-