-
-
[翻译] 绕过补丁实现欺骗地址栏和恶意软件警告
-
发表于: 2017-3-25 13:39
-
绕过补丁实现欺骗地址栏和恶意软件警告
昨天，微软推送了一个大规模更新。本次更新修复了众多的安全漏洞，包括来自本网站的大部分。这是一个巨大的荣誉，一个属于Edge开发者们及负责该安全的开发者的荣誉。对于那些依然维持IE浏览器策略的开发者，我觉得至少要公开地表态为什么不继续维护IE了。要么让它停更，要么继续维护。
各位读者，如果你还不了解该漏洞，请你们阅读之前的文章，再来了解如何绕过补丁。
快速回顾
微软Edge允许加载一些内部资源包括类似acr_error.htm的html网页，不过不允许BlockSite.htm的加载。为何呢？这是因为后者很容易被用于欺骗内部恶意软件警告和地址栏。前几个月，我们通过把URL中的一个点改为对应的转义来绕过该限制，现在这个被打上补丁了。Edge开发者在检查字符串输入之前解码恶意URL，所以得找其他的方法了。加把劲！关掉那烦人的facebook消息栏，别在其他地方让费时间了。统统都关掉吧，让我们沉浸在有趣的二进制的海洋吧！
没有标记
到目前为止，微软公司并没有上传太多的公开标记，所以我们的分析不可能像上周（当时标记已经公开）一样正当。不过，也别担心，我们只是尝试绕过补丁而已，请在心里铭记攻击者的心态：我们只是想绕过补丁，仅此而已。我想，攻击者难道会说先休息一个星期吧，等微软公开它的标志。
寻找“blocksite.htm”
我们知道，在Edge浏览器的成千上万行代码里，肯定有一个比较字符串来阻止“blocksite.htm”加载，因此我们将依靠Edge定位到该字符串并通过设置内存访问断点来监测它的读取。
下面的Javascript调用ACCESS_DENIED不过并未开启一个新窗口：
这个内部URL被Edge屏蔽，因为，这个特别的错误页面能接收哈希值查询语句，这将使攻击者实现地址栏和页面内容欺骗。
我们的目标是打开那个URL再次欺骗Edge。为此，要实现这个目标，我们将使用下面的URL（末尾处的点和‘faceboook’编码使我们可以在内存中检查我们的字符串）：
window.open("ms-appx-web://microsoft.microsoftedge/assets/errorpages/BlockSite%2ehtm?BlockedDomain=facebook.com");
我们链接到Edge去查找BlockSite.htm。首先，将搜索范围限定在大多数代码汇集的EdgeHtml.dll模块。这仅仅是个猜测，如果我们在这里什么都没找到，那么我们将查找其他模块甚至所有的Edge 文件。
一旦链接到正确的Edge浏览器进程，我们需要了该模块的起始结束地址，这样我们才能确定在内存的搜索范围。
现在我们可以为搜索命令提供地址范围和要搜索的字符串了。WinDbg的语法实在是吓人的，不过我可以告诉你下面的指令是在那些难以阅读的64位地址间搜索‘s’并返回Unicode字符u的【1】地址。
好的，WinDbg迅速返回三个地址，我们看看是否正确的。Du du du，像是Dudú——我的朋友，昵称叫“Dudú”。
我瞬时激动了。我们想找出该字符串的访问者，因此在这三个地址上都设置了断点。
好极了！接着转到Javascript代码试着打开我们的恶意链接。
哇！极速断点，返回到WinDbg，看看返回的结果：
从这看来我们在kernelbase模块，不过我们的目的是找到与字符串相关的EdgeHtml 模块。我们去看一下最近的5次栈跟踪调用。
前两个属于kennelbase模块，接下来的这个来自edgehtml。更清楚规范地讲，一段edgehtml的代码调用了kennelbase模块库的的StrStrIW函数。通过谷歌搜索，我们在MSDN上找到了StrStrIW函数的说明文档：
文档非常讲得非常清楚，多亏了栈跟踪，我们得以知道edgehtml调用的是这个函数。我们在返回地址之前设置断点，这样我们就可以分析在这之前的代码了（顺便提一下，也可以通过两次分步执行达到同样的效果，不妨试试）。
砰！立即到了断点。
我们刚从字符串的比较中返回，因此我们看看稍前时间发生了什么。在WinDbg 下，我们可以很容易地反汇编：
干得真棒！不过，由于字符问题，这些东西有点难看。也别太在意，我们知道，这是从上面的调用（最近的这条）返回，是吧? 而且，在调用之前，传递了两个参数，一个在rdx,另一个在rcx（这两个都是指令）。由于调用已经执行，其中的值可能改变了，所以无法得知其中的具体情况。接下来，我们通过在最后一次的调用（还未执行）之前设置断点来更进一步地检查该值：
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！
