pikachu 暴力破解
暴力破解:
"暴力破解"是一攻击手段,在web攻击中,一般会使用这种手段对应用系统的认证信息进行获取。其过程就是使用大量的认证信息在认证接口进行尝试登录,直到得到正确的结果。为了提高效率,暴力破解一般会使用带有字典的工具来进行自动化操作。这里用的是burp suit抓包,在kali上有自带的密码字典,也可自行解压使用。
如何防止暴力破解?
0x01:要求用户设置复杂的密码
0x02:使用安全的验证码
0x03:对尝试登录或者改密服务进行判断和次数限制
0x04:采用多重机制验证 比如token
如何优化字典?
0x01:对目标站点尝试自行注册,观察账户密码设置的限制
基于表单的暴力破解模块:
设置代理,随便输入一个用户名密码用burp suite抓包发送到Intruder模块
(操作基本与DVWA上的 Brute Force一致,我这里略去步骤,不懂步骤的可以翻看我以前的blog)
这里注意proxy下还有个模块
HTTP history 可以抓到我们的GEY和POST请求:
在Proxy的HTTP History下可以看到这个POST请求:
可以观察到登录验证只有username和password两个参数,没有token和验证码等参数,是一种
最基本简单的暴力破解。
抓包:可以右键选择Send to Intruder或者Ctrl+I发送到Intruder模块
关于Burp Intruder主要有四个模块组成:
1:Target 用于配置目标服务器进行攻击的详细信息(也就是目标地址和端口)。
2:Positions 设置Payloads的插入点以及攻击类型(攻击模式)。
3:Payloads 设置payload,配置字典
4:Opetions 此选项卡包含了request headers,request engine,attack results ,grep
match,grep_extrack,grep
payloads和redirections。你可以发动攻击之前,在主要Intruder的UI上编辑这些选项,大部分设置也可以在攻击时对已在运行的窗口进行修改。
先进入Payload Positions(有效载荷位置)模块:
0x01:先点击右边clear清除所有变量
0x02:将username和password后面的参数值选中,点击右边的Add$使它们变为我们需要破解的参数
0x03:在Attack type中选择攻击模式,我选择的cluster bomb。
攻击类型设置有四种:
sniper:对变量进行依次破解,多个标记依次进行(比如先破解账号,密码不变,等遍历完账号后账号不变再去遍历一遍密码,同时只能对一个payload进行操作)。
选择这个模式时,payloads set处只有一个参数,默认的payload type是simple list
一般会把payload type 改成Runtime file并select一个字典。
battering ram:对变量同时进行破解,多个标记同时进行(根据字典对于多个变量进行同时替换值)。
pitchfork:每一个变量标记对应一个字典,取每个字典的对应项。
cluster bomb:每个变量对应一个字典,并且进行交集破解,尝试各种适合用户名和密码的组合
为每一个变量添加对应的字典:
在payload set处选择对应的参数(你上面Add的第一个对于payload set处的值就是1)
load浏览本机文件并添加字典
如果突然想到一些密码组合可以直接在这里Add加进密码字典中去。
在payload Encoding里可以设置字典中关于特殊的字符是否需要URL编码。
进入options选项卡,更改线程并发数为50,这样可以提高效率
参数为2000那里是并发的间隔时间(每次并发请求的间隔),有些网站会对这种多并发去做限制。
之后在左上角Intruder处选择start attack
找到length长度与其他不一样的一行,这个就是对应的账号密码。
也可以在Grep Match中设置一个Flag来标记错误的账号密码组合,以便于字典过大再进行爆破
的时候难以找到正确的账号密码组合。添加好后再attack就会在上图中多一列Flag状态栏,可以
点击这个Flag的列名,可以进行排序,而没有Flag标记的就会被排到第1行。
解释一下为什么会出现这个结果 ,因为登录成功和失败返回的提示长度是不一样的,
那么造成的回应包长度也是不一样的,比如这个网页就是
登陆失败:
登陆成功:
So :length短的那个包是被验证登录成功了 。
验证码绕过 on server:
验证码的流程:
客户端request登录页面,后台生成验证码,验证码图片响应到前端页面,同时将算法生成的
值全局复制保存到SESSION中。校验时,客户端将认证信息和验证码一块提交,也就是确认
此时执行操作的是一个人而不是机器脚本,客户端刷新页面再次生成新的验证码。
一般漏洞产生原因:
验证码在后台可长期使用(经常)
验证码校验不严格
而on server模块这里问题就在于验证码长期有效了(指的是只点击login抓包的情况下,这样
我们可以无限制次数的进行暴力破解)。
同样还是输入错误的用户名密码以及正确的验证码,先把包发送到Repeater中观察:
我这里应该是显示问题,这里应该是会出现验证码不能为空的提示了。证明在后台做了验证验证码的操作
而后将验证码改为正确的验证码(忘记的话可以重新刷新前端页面),并Go两次错误的账号密码
之后发现不会爆出验证码过期或者错误的提示,说明验证码没有时间限制而是长期有效。
之后和之前的操作就都一样了。
SESSION默认的时限是24分钟,可以去php.ini中设置,而本模块的源代码没有设置验证完验证码
就销毁掉SESSION的操作,那么导致了验证码长期有效
验证码绕过 on client
前端的验证码可以作为一种辅助,但不能仅靠这个。还需要后台验证才可以。而且验证码不可以以文本的
形式输出到前端,否则可以先提前准备脚本来获取验证码字符串,这样设置验证码就毫无意义了。
这里就是逻辑问题,验证逻辑是在客户端实现的,后台对于验证码没有校验过程,不管我们在改包时
验证码是什么都无所谓,后台不会对验证码进行验证。每次login都会提交验证码并刷新一个新的验证码
首先用错误的用户名密码进行尝试:
看一下POST请求内容:可以看到多了一个验证码
观察源码可以发现验证码实在javascript中写的,验证码的生成和验证都是在前端做的,
把数据包发送到Repeater模块(数据包重放模块):
在这里可以对前端抓到的包进行修改然后点Go会自动发送修改的包给后台
下面确认后台是否进行了验证码的验证:换一个错误的验证码。
返回提示为上图所示,明显后台没有进行验证码的验证。
防范措施:
1.使用安全的验证码(图形验证码)
2.多次认证错误就进行尝试次数限制
token防爆破:
观察源码:有一个隐藏的token
当每次打开页面,后台生成一个token放在SESSION里面并放在前端的表单里
验证时会加上token这个值进行验证,每次刷新页面时它的值是不一样的。
那么问题来了,token能防暴力破解吗?
不可以。
因为在生成token的同时也已经发送到了前端的form表单里了,攻击者可以提前获取token的值。
但是token用在CSRF中会比较多。
参考文章:关于burp suite Intruder模块使用