您能破解文档吗？
对于这个挑战，我们提供了一个名为“CrackDoc.doc”的文件，当我们打开它时，我们会看到一个“UsersForm1”提示，要求输入“Key”值。
输入错误的键会显示一条消息“你能做到。再努力一点...”，并附上一张可爱的狗狗图片。
对于这个挑战，我们提供了一个名为“CrackDoc.doc”的文件，当我们打开它时，我们会看到一个“UsersForm1”提示，要求输入“Key”值。
输入错误的键会显示一条消息“你能做到。再努力一点...”，并附上一张可爱的狗狗图片。
忘记密码？以 Kaminsky 风格接管用户账户
总结
在分析了 146 个 Web 应用程序的 DNS 名称解析漏洞后，Timo Longin（SEC Consult Vienna）发现，一些 Web 应用程序至今仍存在漏洞。Kaminsky 以及 IP 碎片攻击可能允许通过“忘记密码？”功能接管这些 Web 应用程序的用户帐户。为了识别存在漏洞的 Web 应用程序，提供了DNS 重置检查器。
这个攻击媒介会影响我吗？
我该如何保护自己？
我应该警惕这个攻击媒介吗？
问答部分涵盖了这些问题以及更多问题。
忘记密码？
很难想象登录表单没有这个问题。
指定电子邮件地址
接收密码重置 URL
更改密码
简单！但是“忘记密码？”功能与 DNS 漏洞有何关系？
以下场景更接近这一点：
假设攻击者可以将任意 DNS 记录注入 Web 应用程序使用的 DNS 解析器的缓存中（DNS 缓存中毒），那么他就可以操纵电子邮件域名到 IP 地址的映射。因此，“gmail.com”的 DNS 名称解析不再必然指向 Google 电子邮件服务器的 IP 地址，而是指向攻击者电子邮件服务器的 IP 地址。
这样，攻击者就可以收到所有发往“gmail.com”的电子邮件。包括密码重置电子邮件。
图说明了这一点：因此，如果攻击者可以操纵 Web 应用程序的 DNS 名称解析，则“忘记密码？”功能可能会被滥用来接管用户帐户。
Dan Kaminsky 早在 2008 年的 Black Hat 大会上就展示了这种攻击媒介[1]。Timo Longin 在毕业论文《Web 应用程序中的 DNS 漏洞》[14] 中对 146 个 Web 应用程序进行了以下分析，结果表明，这种攻击媒介至今仍然存在。
总结
在分析了 146 个 Web 应用程序的 DNS 名称解析漏洞后，Timo Longin（SEC Consult Vienna）发现，一些 Web 应用程序至今仍存在漏洞。Kaminsky 以及 IP 碎片攻击可能允许通过“忘记密码？”功能接管这些 Web 应用程序的用户帐户。为了识别存在漏洞的 Web 应用程序，提供了DNS 重置检查器。
这个攻击媒介会影响我吗？
我该如何保护自己？
我应该警惕这个攻击媒介吗？
问答部分涵盖了这些问题以及更多问题。
忘记密码？
很难想象登录表单没有这个问题。
指定电子邮件地址
接收密码重置 URL
更改密码
简单！但是“忘记密码？”功能与 DNS 漏洞有何关系？
以下场景更接近这一点：
假设攻击者可以将任意 DNS 记录注入 Web 应用程序使用的 DNS 解析器的缓存中（DNS 缓存中毒），那么他就可以操纵电子邮件域名到 IP 地址的映射。因此，“gmail.com”的 DNS 名称解析不再必然指向 Google 电子邮件服务器的 IP 地址，而是指向攻击者电子邮件服务器的 IP 地址。
这样，攻击者就可以收到所有发往“gmail.com”的电子邮件。包括密码重置电子邮件。
图说明了这一点：因此，如果攻击者可以操纵 Web 应用程序的 DNS 名称解析，则“忘记密码？”功能可能会被滥用来接管用户帐户。
Dan Kaminsky 早在 2008 年的 Black Hat 大会上就展示了这种攻击媒介[1]。Timo Longin 在毕业论文《Web 应用程序中的 DNS 漏洞》[14] 中对 146 个 Web 应用程序进行了以下分析，结果表明，这种攻击媒介至今仍然存在。
攻防启示：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。