反-反蜜罐：以三个反蜜罐插件的缺陷为例

0x00 关于本文

当时想保研，想搞篇论文，就捣鼓了个XSS平台并研究了反蜜罐插件的缺陷，缝在一起投某中文期刊，然后这种乱缝合果不其然被拒，之后我就把这事丢在一边了。

最近上t00ls看到某公司某蜜罐，发现其中已经采用了某些绕过反蜜罐插件的措施，一下子勾起了我的回忆。尽管过去了那么久，事后证明保研没有看起来的那么难，而且我也准备退学跑路了，但这些研究依然在那里并且还没过时，因此我决定去掉里面吹水的部分，整理下后发出来。

本文以三个反蜜罐插件为例（anti-honeypot、AntiHoneypot-Chrome-simple、antiHoneypot），分析蜜罐插件的工作原理及导致其被反向检测以及绕过的缺陷。尽管本文会对具有反制能力的蜜罐做一定的介绍，但读者需要对XSS、Jsonp劫持有一定的了解才能更好地理解本文。

0x01 会咬人的蜜罐&反蜜罐插件

有网络安全基础的读者应该都知道蜜罐是什么。防御者搞一个外表诱人但监控严密的系统来引诱黑客进攻，将黑客的一举一动记录下来，以对其分析和追踪。据说当年大名鼎鼎的黑客凯文米特尼克就栽在蜜罐上，结果惨遭溯源。

在2013年BlackHat Eu上，有研究者提出通过Jsonp/CSRF/XSS的方法攻击黑客的浏览器，以定位黑客的身份。随着护网行动的普及，默安幻阵和长亭谛听这样具有反制能力的蜜罐在各个攻防演练中大放异彩，这些蜜罐内置了大量的Jsonp和XSS接口，一旦访问，运行在浏览器前端的js脚本就通过这些接口拿到大黑客的QQ/CSDN/微博/爱奇艺/优酷等等的账号名，再通过社工库等办法拿到大黑客的更多信息，让大黑客率先响应国家实名上网的号召。

当然大黑客也不是吃素的，黑客们开发了各式各样的蜜罐阻拦插件，这些插件可以通过检查网页的Dom和请求的URL来判断当前访问的的网站是否是蜜罐，并实时阻断浏览器发出的可疑请求，阻止恶意js脚本拿到敏感信息。

0x02 AntiHoneypot-Chrome-simple 插件原理&缺陷分析

原理分析

AntiHoneypot-Chrome-simple插件通过简单的预置的蜜罐特征来检测蜜罐，它在插件的background.js中定义了一组规则，分别是文件名和内容的对应。

插件通过chrome.webRequest.onBeforeRequest监听了所有的网络请求，过滤出对js的请求并进行检查。

负责检查的代码给了很清晰的注释，首先如果检查过那就直接用缓存结果，否则通过ajax请求一次js的内容，然后用checkForRule函数检查url和内容。如果URL和内容命中规则，举个例子，如果请求了record.js并且内容还包括document[__Ox3f21b[0xd]](__Ox3f21b，那就判定为蜜罐。

如果判定为蜜罐，那除了写缓存之外，那就再网络请求的监听函数里面返回{cancel:true}，阻拦这个请求，并且展示一个吓人的框框

缺陷分析：反向检测&与绕过。

像这种插件，直接匹配几个知名蜜罐的规则，其实是很容易被绕过去的，因为只要随便混淆下脚本或者改个文件名，它就无法识别了。

除此之外，这个插件还有个致命弱点。它为了检测加载的js的内容，预先用ajax去请求了一次，这样的话本来只该被请求一次的js被请求了两次，这给防御者留了很多的机会。

首先，多出来的一次请求在服务端上就非常的明显，正常浏览器不可能干这事，所以只需要在服务端检测同一个用户是否莫名其妙地多请求了js脚本，就可以确定该插件的存在性。
此外，在这两个请求中，第一个是插件发出来用于检查的，第二次是浏览器为了加载js而真正发出来的，因此只需要在第一个请求里面返回正常的内容，在第二个请求里面加载真正的恶意代码即可绕过检查。

0x03 antiHoneypot 插件原理&缺陷分析

原理分析

antiHoneypot插件就要复杂很多，从Github上看它包含了很多检测手段，因此我们就看的粗略一些。

首先在插件的manifest.json中，我们可以看到该插件首先通过在前端注入js的形式来抵御多种浏览器指纹识别手段。

反映到前端上就是好好的一个网页会被它插入许多js

这些插入的js可以通过替换函数的方法记录对敏感函数的调用，并且一旦发现了某些信息就通过postMessage发送给窗口

窗口上会监听postMessage发来的东西，将其发至运行在background的js，这些js处理后就会向用户产生告警

告警长这样

此外它还能通过运行在background的js监听并检查所有的请求，多种方式去检测请求的URL，阻止Jsonp请求

缺陷分析：反向检测&与绕过。

想要检测该插件的存在性是极其容易的，只需要检查前端是否被注入了额外的Dom即可。

针对注入到了前端的代码，不难发现其依赖window.postMessage的通信方式很容易被劫持，前端只需要把window.postMessage覆盖掉（比如直接window.postMessage=console.log），前端的代码就算检测到了敏感函数的调用也无法和后端通信。当然这种绕过依然有缺陷，尽管我们能隐蔽地调用一些敏感函数了，但因为该反蜜罐插件通过函数替换实现伪造Canvas指纹，而我们无法绕过它调用真正的函数获取Cavas指纹。无论如何，至少这种绕过已经不会让黑客感到警觉。当然我们也可以反其道而行之，主动发起postMessage来调戏大黑客。

而该插件对Jsonp/XSS的检测也有个致命的弱点：

在检测代码的开头，会对url进行检查，一旦包含chrome-extension://那就直接放行。这导致了只需要在URL里面的参数中加一个chrome-extension://就可以绕过检测。这个缺陷已经被部分蜜罐厂商发现并用了起来，额外加一个叫做ooxx的参数，内容是chrome-extension://，实现绕过蜜罐插件继续用Jsonp溯源。

当然除了这种加法外，还可以在URL后面加一个#chrome-extension://，这样URL里既包含了chrome-extension://，又能不在流量中显现出来（稍有常识的人都会看出，#后面的东西是浏览器处理的，不会发到服务器那里去的）

0x04 anti-honeypot 插件原理&缺陷分析

原理分析

anti-honeypot插件是相对简单的插件，首先它判断当前请求发起的域是否在白名单中，如果是则正常，如果不是则匹配发起域名是否与请求域名相同，相同则正常，否则匹配目标的path中是否包含jsonp或者callback这样的关键字，如果有则告警。

缺陷分析：反向检测&与绕过。
该插件貌似不存在明显的特征可供反向检测。但manifest.json中有玄机，其中的web_accessible_resources使得扩展中的所有资源都可以被访问，因此可以构造形如chrome-extension://[id]/[resource_path]的链接，通过探测资源的型式探测其存在性。

很遗憾的是，由于该扩展并未上架Chrome商店，因此使用者只能下载源码解压后安装，而id则和解压路径相关，因此这种办法很难在实际场景中使用。

幸运的是我还发现了一种侧信道的手段可以通用地检测反蜜罐插件的存在，我将在后文详细叙述。

要绕过这个插件是很容易的，尽管看上去有严密的规则，但它的域名提取算法存在缺陷，攻击者只需要让这个正则表达式匹配不到东西，使得domain[0]无法取到而报错，即可让整个检查因为报错而直接放行。这个正则表达式只匹配了部分域名的结尾，并且不支持IP地址，因此最简单的情况，只需要让蜜罐的域名为一个IP地址就可以迫使它报错

0x05 一种具有一定通用性的侧信道检测反蜜罐插件的方法

在研究的过程中，我发现了一种侧信道的手段可以通用地检测反蜜罐插件，这种方法不一定稳，但是还是有一些研究的价值的。

上述所有的插件都会在URL请求的时候事先进行并匹配，而这个匹配过程会有一定时间的耗时，该耗时在正常情况下是不应存在的，因此可以通过分析这个耗时来分析来判断插件的存在性。经测试，当域名的长度大于等于64，浏览器看到这么长的诡异域名时会直接放弃而产生错误，因此这中间的时间就是插件处理时产生的耗时。

我们可以很轻易地构造js代码，测试给定URL请求时所需的耗时

        function testTime(urllength)
        {
        url="http://"+'a'.repeat(urllength)
        starttime=new Date().getTime()
        let ajax = new XMLHttpRequest()
        ajax.open('GET',url,false)
        try{
            ajax.send() 
        }
        catch(e){
            interval=new Date().getTime()-starttime
            return interval;
        }
        }

为了排除机器的干扰，采用增长倍数进行计算，即以域名长度为100为基准值，计算更长的域名的增长倍数。经测试，anti-honeypot的增长与无插件情况的增长较接近，没有明显到可以作为判断条件。但是AntiHoneypot-Chrome-simple和antiHoneypot就与无插件情况下有较大的区别（为了偷懒直接拿当时做的图来表示），在无插件的情况下耗时增长倍数相对缓慢，而有插件情况下则增长迅速。