透过F5获取服务器真实内网IP

前言

渗透测试过程中,经常会遇到目标服务器使用F5 LTM做负载均衡。

如果能获取到目标服务器的真实IP地址,会给后续渗透带来一定便利。

本文既是最近渗透遇到的一点点经验分享。

F5修改cookie机制

F5 LTM做负载均衡时,有多种机制实现会话保持。

其中用到很多的一种是通过修改cookie来实现的。

具体说来,F5在获取到客户端第一次请求时,会使用set cookie头,给客户端埋入一个特定的cookie。

比如:

Set-Cookie: BIGipServerpool_8.29_8030=487098378.24095.0000

后续再接到客户端请求时,F5会查看cookie里面的字段,判断应该交给后续哪台服务器。

作为传统大厂,F5当然不会傻到直接把服务器IP address写入到cookie里面。

F5很巧妙的把server的真实IP address做了两次编码,然后再插入cookie。

所以,只要依据解码流畅,解开487098378.24095.0000的内容,就拿到了server的真实IP address。

解码思路

  • 首先,把第一小节的十进制数取出来,也即,487098378
  • 第二,将其转为十六进制数1d08880a
  • 第三,从后至前,以此取四位数出来,也即,0a88081d
  • 第四,依次把他们转为十进制数:10136829
  • 最后,得到真实内网IP:10.136.8.29

总结

严格意义上说,只有内网的私有IP,对正面突破目标防线的帮助并不明显。但是,当需要做内网渗透和漫游的时候,这一点信息还是有价值的。再不济,写report的时候,如果实在没的可写的时候,还可以拿这点作为一个issue作为丰富report的素材。

抵现券一券多用问题原理与总结

背景

支付H5预计2015-12-31上线,故在2015-12-21日提测了一个服务端的安全测试单(单号:1632363),由安全测试人员bit4帮忙跟进测试。bit4于2015-12-26日于redmine系统提交了一个安全bug(单号:266626 【安全】【支付】抵现券高并发处理不当,可一券多用)。

测试步骤

  1. 通过PaySdk客户端,生成业务订单,并点击支付生成支付订单,但不进行购买,如此反复生成多个初始化的购买订单
  2. 通过抵现券查询接口(有三个,都可以),直接进行支付流程就会有这个接口的的返回信息,抓包查看即可,选取一个抵现券记录下它的code值,比如:d2404ac1b2a54a1aadad752b536fxxxx
  3. 截获支付流程中的购买接口(https://pay.xxx.com/pay/oauth/voucher/deal/buy),真正进行支付订单支付的接口,替换其中的code值为刚记录的值,并替换订单值为第一步骤中所记录的初始化订单的值。
  4. 同时发起订单号不同而抵现券值相同的多个请求,构成并发请求。之后查看结果。发现有两个请求均获得支付成功。

注:以上环境中,设置的订单金额和使用的抵现券的金额都是一元,以保证请求是有效的,不受其他逻辑的干扰。而且测试的时候资金账号基本余额也做了检查,余额未变动。而抵现券也只是少了一个。

现象

同一个抵现券在高并发请求下出现被多次使用成功,多个订单可以使用同一个抵现券购买成功。

核实问题

根据安全测试人员提供的订单号及抵现券code, 分析日志及DB中的订单状态,抵现券状态,确实发现两个不同的购买订单使用同一个抵现券code购买成功,且可重现。

分析问题出现原因

经分析代码AccountServiceImpl.decrVoucherFirst()方法发现调用消费抵现券方法VoucherServiceImpl.consumeVoucherCode()时未对方法是否消费抵现券成功做处理,而该方法本身也没有对是否成功消费抵现券做处理。

故导致,同一个抵现券在高并发请求下,有多个请求同时满足消费抵现券的前置条件,到达如下图二所标识部分,则多个请求都可以执行完该方法,只是返回值不同, 上层调用者如图一所示, 并未对返回结果做判断。

1.png

2.png

验证问题

修改VoucherServiceImpl.consumeVoucherCode()方法,不更改程序原有逻辑,仅添加详细日志来验证分析出的原因是否正确, 修改如下。

3.png

重新打包,提交到测试环境,请安全测试人员重新测试, 日志如下:

4-1.png

日志与预期结果相符,验证了猜测。
 
于2015-12-27日,修复了该bug, 修改如下图所未, 调用到更新DB时,更改失败时,抛出消费抵现券失败异常, 阻止程序继续执行。

5.png

重新打包,部署到测试环境,测试结果如下:

测试时发现有三个请求在同时尝试修改券的状态,其中两个返回了“消费抵现券失败”,只有一个成功。确认修复有效。

总结

Mysql处理高并发,防止库存超卖的问题,大部分人一般想到的都是事务,但是事务是控制库存超卖的必要条件,但不是充分必要条件。

举例:

  • 商品总库存:4个商品
  • 并发请求人:a、1个商品 b、2个商品 c、3个商品

假如产品表名为:t_store, 商品id为:12345, 商品库存字符为: amount, 请求减掉的库存数量: quantity

程序如下:

BeginTransaction(开启事务)
try{
    $result = $dbca->query('select amount from t_store where product_id = 12345');
    if(result->amount > 0){
        $dbca->query('update t_store set amount = amount - quantity where product_id = 12345');
    }
}catch($e Exception){
    rollBack(回滚);
}
commit(提交事务);
EndTransaction(结束事务)

以上代码就是我们平时控制库存写的代码了,大多数人都会这么写,看似问题不大,其实隐藏着巨大的漏洞。

数据库的访问其实就是对磁盘文件的访问,数据库中的表其实就是保存在磁盘上的一个个文件,甚至一个文件包含了多张表。
例如由于高并发,当前有三个用户a、b、c三个用户进入到了这个事务中,这个时候会产生一个共享锁(读锁,允许多个事务读,但是不允许修改),

---me:为什么这里加的是共享锁而不是排他锁呢?因为是先query,也就是读取,所以加共享锁。而下边的update是修改,只能是排它锁。

所以在select的时候,这三个用户查到的库存数量都是4个,同时还要注意,mysql innodb查到的结果是有版本控制(MVCC,有兴趣的同学可以自己百度)的,在其他用户更新没有commit之前(也就是没有产生新版本之前),当前用户查到的结果依然是旧版本。

然后是update,假如这三个用户同时到达update这里,这个时候Mysql会把update更新语句并发串行化,也就是给同时到达这里的是三个用户排个序,一个一个执行,并生成排他锁(可读可写,独占资源),在当前这个update语句commit之前,其他用户等待执行,commit后,生成新的版本;

这样执行完后,库存肯定为负数了。但是根据以上描述,我们修改一下代码就不会出现超买现象了,代码如下:

BeginTransaction(开启事务)
try{
    $dbca->query('update t_store set amount = amount - quantity where amount>= quantity and product_id = 12345');
}catch($e Exception){
    rollBack(回滚);
}
commit(提交事务);
EndTransaction(结束事务)

这样就可以控制库存超卖的情况了, 但是还需要处理一点,就是执行这个update事务究竟是否更新成功(即更新成功的records是否大于0)呢 , 上面的update更新成功才能够接着处理用户扣钱,等一系列的操作。

再来看看此次我们所犯的错误:

很明显所犯的正是没有关心update执行是否成功亦即更新成功的records是否大于0,在没有做任何的判断的情况下让程序继续向下执行。故而导致此bug的出现。

本内容选自小密圈:

20180613075812.jpg

验证码安全那些事

前言

最近在研究验证码安全,本文主要分析四种流行的验证码(图形,短信,语音和滑动)进行分析,写这篇文章的出发点并非是绕过或破解验证码,而是根据自身业务情况来选择对应的验证码类型,在用户体验和安全性中找到属于自己的平衡点。

有问题可与我联系Wechat:atiger77

目录

0×01. 图形验证码  
0×02. 短信验证码
0×03. 语音验证码
0×04. 滑动验证码
0×05. 总结

备注:无论使用哪种验证码,只要开发不当都可能存在安全漏洞,为了减少文章重复内容,只在短信验证码中讲解漏洞以及对应加固方案,在语音验证码中讲解风控预防措施。

0×01 图形验证码

图形验证码是出现最早也是使用最为广泛的验证码没有之一,从最早的简单验证码到现在各种五花八门的验证码,为了防止被识别有加噪点的,有加干扰线的,有加各种背景的,有加逻辑题的…

之所以会有越来越恶心的验证码主要是防止验证码被机器识别,所设计的验证码难度也在不断上升,相比较来看下面两张图就知道为什么会这么设计了。

一般识别流程:

14917152134767.png

一般验证码加固方法:

14917152549751.png

随着验证码难度的提高识别的成本也随即提高,为了进行识别测试,我分别收集了四家不同类型互联网公司的验证码,情况如下:

某招聘网站验证码 – 字母周围有噪点,字体扭曲

20170424112448.png

某电商网站验证码 – 不同样式,字母阴影,字母粘连,背景色干扰

20170424112458.png

某社交网站验证码 – 主体干扰线,背景色干扰,背景字母干扰,字体扭曲,字母粘连

20170424112509.png

某生活类网站验证码 – 背景干扰线,背景色干扰,背景字母干扰,字体扭曲,字母粘连,字体镂空

20170424112522.png

首先针对某招聘网站的验证码进行识别,这里基于tesseract写的一个OCR程序,测试样本10张,最后准确率在50%,反溯以下发现对识别相近字时会比较吃力比如”z”和”2″,”0″和”O”等等,因为验证码做了反识别部分验证码人眼也比较难识别,如果继续优化识别率达到70%左右应该问题不大。

14917154289847.png

接着对某电商网站的验证码进行识别,最后准备率在40%,由于该网站验证码难度各不相同对于这种类型的验证码比较难做统一处理,即使使用机器学习的方法一个模型也很难去识别所有的验证码。

后面两个网站的验证码使用图像识别去做难度就很高了,为了不被识别分别做了大量的反识别工作,那么对于这类验证码一般使用的是人工打码平台,之前有文章已经介绍过了这里就不重复描述了。

这是某打码平台的价格,网上可以找到很多类似的网站。

14917154282029.png

那么对于企业来说,怎么防止验证码被人工打码呢,从安全角度来说是比较难做到防止的,为了不失去用户体验每张验证码的失效时间并不会很短,对于一个熟练的人工打码人员来说完全不在话下,那么我们从验证码本身出发去提高攻击的一个成本,举一个例子,可以使用DataURI scheme的方法把验证码图片直接写到HTML文件中去增加识别的时间和成本,当然还会有很多方法可以去增加攻击成本。

如果想从根本去除打码平台的困扰,这里可以参考支付宝和微信这两个产品的验证码机制,在某些地方所弹出的图形验证码是和使用者有关,比如选择联系人头像,选择购买过的物品,对于人工打码的人来说是完全不知道答案的,但是用了这种类型的验证码也会出现问题,比如“好友”足够了解你的情况下(个人信息泄露太多)可能会成功的进入。

现在有很多文章会用到神经网络CNN的方法用来识别验证码,相比传统的识别用机器学习有了样本的学习,识别率会更加的准确,对一些人眼可能判断错误的字母机器或许能判断准确,不过学习成本也是很高的。

0×02 短信验证码

短信验证码常见于注册,忘记密码,确认下单等阶段,特别是一些涉及到用户个人敏感行为时候,为了确认操作是用户本人执行的通常会使用短信验证码进行二次认证。同时,短信验证码也是最为常见的验证码类型之一,这里总结一些验证码逻辑漏洞。

a. 接口没设频次上限导致短信轰炸

起因:短信轰炸问题往往出现在一些小站或者子站,这几年很少看到通过GET请求发送短信验证码了,基本都是使用POST请求,使用抓包软件可以重放请求对于后端没有做限制的网站就可以达到短信轰炸的效果。

危害:对用户来说个人生活受到骚扰,对企业来说造成一定的负面影响,很多小公司因为短信接口被大量调用出现运营问题,对于公司没有安全工程师的情况下,一般都是业务方发现了数据异常向上汇报,最后和开发一起反溯才会找到这个问题,那么在这段时间中对企业所损失的钱也是无法挽回的。

预防:这里主要是针对两种攻击场景来进行防御,第一种是对单用户的短信轰炸,即重放发送请求且phonenum为一个值。第二种是对多用户发送短信骚扰的场景,即将phonenum参数设置为字典,重放短信接口。

设置发送间隔,即单一用户发送请求后,与下次发送请求时间需要间隔60秒。

设置单用户发送上限,即设置每个用户单位时间内发送短信数的上限,如果超过阈值就不允许今天再次调用短信接口(阈值根据业务情况设置)。

设置单IP发送上限,这种情况是预防第二种攻击场景的,由于IP的特殊性可能存在所处IP是大出口,一旦误杀后果会很验证,所以这个限制根据自身情况酌情考虑,对于有风控的团队来说,当发现发送IP存在异常可以对该IP增加二次认证来防止机器操作,也可以降低误杀情况。

备注:b和c两个漏洞场景一般截图说明下开发就知道问题所在了,这里修复建议的内容写的就比较少。

b. 验证码内容包含在返回包中

起因:因为开发不严谨导致通过抓包可以看到验证码在回显中显示。

14917155261248.png

危害:由于验证码直接返回,通过该漏洞可以注册任意用户,重置已注册用户密码,修改绑定信息等高危操作,对用户造成一定影响。

修复建议:不要将短信验证码在回显中显示,验证码只存于服务端中并不能通过任何api直接获取。

c. 修改返回包内容绕过验证

起因:前端校验导致下列问题。

14917155974535.png

14917155573802.png

危害:可跳过正常校验逻辑。

修复建议:服务端严格做检验,和开发谈谈心。

假设网站验证码接口没有以上说的任何漏洞,那么短信认证是否安全呢?

在用户手机没有被种木马,用户手机没被强制降频到GSM等情况下,当攻击者无法获取短信验证码则某些关键操作是无法继续的,在一定程度上起到了拦截的作用。特别针对盗号的场景,由于设备或常用地发生了变化,在用户登录时候弹出验证码进行校验防止被盗号的情况。短信验证码只对部分场景可以起到防护作用,单一的认证对于企业来说无法阻止以下的场景。

14917155587746.png

这张图在我上一篇文章中出现过,这是在某打码平台注册了一个帐号的截图,从图上就可以看出虽然用了短信验证码,但是可以通过打码平台来自动获取并完成注册流程。

针对打码平台的垃圾注册场景也可以通过一些手段去增加批量自动化的注册成本,防御手法有相同之处,在语音验证码中会简单讲解。

0×03 语音验证码

相比短信验证码,语音验证码存在以下的优势:

a.语音验证对防刷单效果更显著;
b.语音验证码到达率更高;
c.用户体验更加友好;

为什么说语音验证码对防刷单更有效,这里贴一张某打码平台的收费情况,可以看到语音验证的价格是短信的十倍。很多公司是不会对17开头的虚拟号段进行发送的,为此卡商提供的卡号基本是实名认证的且没有停机的正常号段,所以收语音验证的成本就会比短信高很多。

14917156829962.png

这家打码平台对语音识别有两种方式,一个是系统识别,另一个是自己听取,对于系统识别平台解释是由听码团队负责听取验证码后传输文字回来,自己听取则是自己下载语音验证码录音自己听候识别。

跟公司研究移动端安全的小伙伴讨论了下,根据目前的技术要做到全自动也并非不可能,这里简单画了一个流程,从触发语音认证开始到最后的填入完成验证一条龙。

14917156821814.png

首先要获取语音认证,等语音验证码说完以后自动保存录音,进行语音分析,国内有几家厂商有语音识别的服务并都提供SDK,所涉及的服务可以用来进行识别,将语音转换成文字并提取验证码部分,完成最后验证。

对于企业来说我们如何防止这种垃圾注册的场景呢,说几种通用的思路供参考,这里主要可以分事前和事后基于规则和行为做判断。

对于事前,可以借助反欺诈接口检测请求的号码是否存在风险,WEB端判断用户UserAgent是否存在异常,APP端判断用户DeviceID是否存在异常,由于事前可以拿到的信息并不多,可以围绕可以拿到的参数做规则,对触发规则的用户进行阻断操作,可以在发送短信或者语音前让其先填写一次图形验证码,多一步校验。当然,也有公司会将部分手机号进行拉黑操作,在源头上禁止某些手机号进行注册。

对于事后,服务端校验以后就可以拿到状态等信息,围绕这些信息又可以制定一些规则,这里可以举一个通用的规则,比如单位时间内单IP登录失败超过阈值的对这个IP进行某某处理,这也是最基本的频次规则。对于不同的业务有着自己不同的策略,比如金融公司的APP会索取用户通讯录的权限,根据用户的好友做用户画像,某些公司也会做二度关系画像来判断用户是否存在风险。

这里不会说太多的规则和策略,由于公司的业务都不尽相同,当日志接入以后针对目前场景存在的问题去设计不同的规则即可。

0×04 滑动验证码

现在有不少的互联网公司开始使用滑动验证码进行校验,看似一个简单的滑动操作,背后都有风控引擎和相应的规则作为保障,首先讲一下滑动验证码的整个流程。

1491715758468.png

我们说一下正常的逻辑,首先用户滑动验证码到指定位置,完成后会给服务端回传各种加密信息,为了做风控规则来判断是否异常,个人猜测其规则会包含用户IP,操作行为路径,UA,COOKIE,设备指纹等等,如果没有命中规则,就会放行校验通过,如果命中规则就会弹出二次校验,只有通过校验后才可以放行。

那么如何破解滑动验证码呢,第一种是模拟正常用户操作,并让风控不要命中风控规则。第二种是尝试破解第二阶段的验证,对于图片可以使用OCR技术进行识别(针对类ReCAPTCHA验证码)。第二种的难度比较高,网上的文章也是针对第一种来进行破解,这里简单讲一下破解方法。

我对某商业滑动验证码进行了测试,整体流程梳理如下:

14917157589764.png

全部过程可以用自动化来实现,整体成功率要分为两个部分来看,第一是验证码自身风控能发现多少问题,我所测试的接口破解成功率在76%左右。第二是企业自身的风控规则能发现和阻断多少异常情况。两者结合最后的成功率就会有所下降,虽然有接口破解但是价格昂贵,已经提高了攻击成本,如果账户不涉及到金钱也不会考虑这么高的攻击成本,其实说到底还是成本和收益的一个衡量。

这里聊一下商业化滑动验证码厂商的优势和弊端。首先说优势,滑动验证码肯定会成为一种流行趋势,对于企业来说自研的成本比较大,无非也就是几个工程师参考已有的进行模仿,先不说效果开发流程上就会耽误人力,这点钱宁愿使用商业化的,现在的产品都已经相对成熟也有专门的团队进行升级维护,安全和体验性上来说都还不错。弊端到也谈不上,这里主要说几点使用前要考虑的地方,一个是响应延迟,当大量并发过来的时候是不是撑得住,最高响应时间是否有上限,如果超过是否会降级,如何降级等等,万一碰到不可预计的问题,比如碰到光缆被挖断,服务是否能即使切换,灾备是否完善等等,在购买前这些问题最好都要进行测试并有应急方案。

0×05 总结

前面也总结了很多验证码,我认为一个好的验证码首先不能有逻辑上的漏洞能绕过,否则再复杂的验证码都是形同虚设。其次,不能为了增加破解难度而抛弃用户体验,不要把验证码做的极其复杂人眼都识别不了,这种也会失去验证码的意义(用户都没了还给谁验证…)

目前来说大部分的企业还是偏向使用图形验证码,在测试过程中只有极少数的公司会动态升级自己的图片验证码,随着输错次数的上升验证码难度也随机上升。统一验证码的设计初衷是好的,即使攻击者使用了OCR技术进行破解,一旦失败数触发到阈值即自动上升图形验证码难度,增加破解成本。

为了防止验证码被爬虫获取后专门进行分析,针对性的破解攻击,需要准备多套图形验证码定期进行替换。

统一验证码体系如果只用单纯的规则去匹配所弹出的验证码,那么这种情况会出现不少的误杀,会让某些正常用户操作频次超过设定阈值,用户在尝试输入密码的过程中验证码越来越难,最后导致用户投诉。所以我认为一个完善的统一验证码体系应该由风控来判断是否触发规则,对触发规则的请求进行相应的验证升级,而不是设定一个死的阈值,对关键操作可以用多种验证码组合的形式来进行校验,常见的组合有,滑动+图形,图形+语音等。

就我个人而言,比较喜欢点触式和滑动式的验证码,通过采集用户当前各种的参数行为(行为轨距,操作时间,当前环境等等)来判断是否为机器行为。在用户体验上,手机端不是很建议使用选字类型的验证码,对于非大屏的手机不是很友好。在安全性上,这类验证码要比其他验证码破解成本高。我相信验证码的趋势也会逐渐向这种类型的靠拢。

下面的图片引用了google的ReCAPTCHA,分别截取图片和语音验证,ReCAPTCHA在安全性和用户体验做的都很好,即使这样还是被安全研究者破解过,所以不要完全依赖一种验证码,对敏感操作可以使用多种验证码。下面是官网的DEMO:

图片类:

14917158615511.png

声音类:

14917158896397.png

无论哪种验证码都有自己的适用场景,也没有一种绝对安全的验证码,根据自身业务情况来选择对应的验证码类型,在用户体验和安全性中找到属于自己的平衡点。最后,有做业务安全的同学可以一起学习交流。

Hacking Docker:Registry API 未授权访问

前言

docker pull HOST:PORT/IMAGE_NAME

image001.png

Exploit

环境

  • local.example.com (127.0.0.1)
  • port 30000

GET 请求/v1 /v2确认 Registry API 版本:

image003.png

确定版本后查看 repos 列表,/_catalog:

image005.png

例如 testrepo1,/REPO_NAME/tags/list查看标签:

image007.png

确定标签 (v1v2) 后使用/manifests/v2下载文件:

image009.png

使用终端下载文件v2//blobs/sha256:/:

https://localhost:30000/v2/testrepo1/blobs/sha256:4b981f68920b27d3a35992f3e0343acfc90f52dff050328f38d03f16ba984d34

image011.png

解压文件发现敏感信息:

image013.png

image015.png

自动化脚本:https://github.com/NotSoSecure/docker_fetch/

image017.png

脚本会将所有 gzip 压缩的 blob 保存在用户设定的目录中, 可以使用以下命令一次性解压:

for i in *.tar.gz; do tar -xzvf $i; done

网络空间调查

20170319171846.png

修复

  • 添加身份验证
  • 启用签名和验证
  • 使用 TLS

参考

一个半自动化命令注入漏洞Fuzz工具

1. OCIFT是什么

一个半自动化命令注入漏洞Fuzz工具(One Semi-automation command injection vulnerability Fuzz tool)简写为:OCIFT

2. OCIFT有什么用

这是一种半自动化的黑盒测试工具,它可以帮助渗透测试人员或代码审计人员在愉快的上网的同时,深度挖掘目标应用系统存在的命令注入漏洞。

OCIFT有什么特点

  • Payload基于Commix生成方式修改而来(需要持续完善).
  • 基于浏览器代理的半自动化Fuzz.
  • 多线程Fuzz速度快,不影响正常浏览器访问使用.
  • 支持设置白名单限制Fuzz范围.
  • 支持设置黑名单避免带来不必要的麻烦.
  • 支持DNSLog辅助验证

4. 实现思路

基于Tornado的实现一个代理服务器,解析GET/POST请求提取Fuzz点,带入payload进行Fuzz测试。

文件结构说明
         |____run.py 主程序入口
         |____dnslog.py DNSLog SDK
         |____fuzz.conf 配置文件
         |____fuzz.py Fuzz线程
         |____make_payload.py Payload生成器
         |____readme.md 说明文档

5.配置文件说明

  • 配置各个参数,以逗号分隔

    [initconfig]

  • 黑名单HOST-为了避免带来不必要的麻烦

    black_hosts =.gov,localhost,127.0.0.1,google,gstatic,cnzz.com,doubleclick,police,mil.cn,gov.cn,gov.com

  • 静态文件黑名单-这些不做Fuzz

    url_ext_black =.ico,.flv,.css,.jpg,.png,.jpeg,.gif,.pdf,.ss3,.txt,.rar,.zip,.avi,.mp4,.swf,.wmi,.exe,.mpeg

  • 白名单HOST-为了限制Fuzz的范围, 默认为空-表示对除黑名单范围外的所有地址进行Fuzz.

    white_site =qunar

  • 请求超时-限制每次Fuzz请求超时时间

    timeout =10

  • 我的DnsLog地址

    my_cloudeye =ano1qu2j.xfkxfk.com

  • 判断是够注入命令执行成功的关键字

    checkkeys =110586256,/bin/bash,nameserver,IPv4,Windows IP

  • 用于测试命令注入的基本命令

    base_command =cat /etc/resolv.conf,echo 110586256,cat /etc/passwd,ipconfig,ping CommandInj.{my_cloudeye},echo 110586256<nul

  • Fuzz线程数

    fuzz_count =20

  • fuzz的payload类型, 默认False-表示使用自定义的规则

    commix_payload_type = False

  • DnsLog登录会话ID,我用的xfkxfk牛的dnslog.xfkxfk.com

    dnslog_sessionid =q6wva2e3skg79vkdegra2bygft0d1

  • Your Domain

    custom_domain =a2fta2j

  • 记录成功结果的Log文件

    Logfile =rce_success_results.txt

6.如何使用

1.安装模块

pip install tornado pip install requests

2.根据自己需要完成文件fuzz.conf的配置

3.启用主程序

python run.py 8089 如下图:

687474703a2f2f7777772e636f6666656568622e636e2f7a625f75736572732f75706c6f61642f323031372f30342f32303137303430393030333434313134393136363932383136393639342e6a7067.jpg

4.设置浏览器代理 然后会自动开始Fuzz

687474703a2f2f7777772e636f6666656568622e636e2f7a625f75736572732f75706c6f61642f323031372f30342f32303137303430393030333332343134393136363932303432313932372e6a7067.jpg

7.总结

  • 基本实现了想要的半自动化Fuzz功能
  • payload还需要不断优化

Github地址:https://github.com/coffeehb/OCIFT