Pikachu漏洞靶场系列之暴力破解

前言

这是Pikachu漏洞靶场系列的第一篇（应该会连载吧），先简单介绍一下Pikachu这个靶场。该靶场由国人开发，纯中文，且练习时遇到难点还可以查看提示，另外还有配套的学习视频。Windows下可直接在Wamp/phpStudy等集成环境下安装。相比之下，很多人都推荐的DVWA，由于其纯英文的环境，对于刚入门的小白十分不友好，可能部署完之后不知从何下手，容易劝退。所以这里推荐的Pikachu更适合刚入门Web渗透且正在寻找靶场的小伙伴。

概述

从来没有哪个时代的黑客像今天一样热衷于猜解密码 —— 奥斯特洛夫斯基

“暴力破解”是一种攻击手段，在web攻击中，一般会使用这种手段对应用系统的认证信息进行获取。 其过程就是使用大量的认证信息在认证接口进行尝试登录，直到得到正确的结果。 为了提高效率，暴力破解一般会使用带有字典的工具来进行自动化操作。

理论上来说，大多数系统都是可以被暴力破解的，只要攻击者有足够强大的计算能力和时间，所以断定一个系统是否存在暴力破解漏洞，其条件也不是绝对的。 我们说一个web应用系统存在暴力破解漏洞，一般是指该web应用系统没有采用或者采用了比较弱的认证安全策略，导致其被暴力破解的“可能性”变的比较高。 这里的认证安全策略, 包括：

1. 是否要求用户设置复杂的密码；
2. 是否每次认证都使用安全的验证码（想想你买火车票时输的验证码～）或者手机otp；
3. 是否对尝试登录的行为进行判断和限制（如：连续5次错误登录，进行账号锁定或IP地址锁定等）；
4. 是否采用了双因素认证；

千万不要小看暴力破解漏洞,往往这种简单粗暴的攻击方式带来的效果是超出预期的!

前期准备

• 抓包工具：Burp Suite
• 浏览器代理插件：SwitchOmega或FoxyProxy
• 字典：users.txt和pwd.txt。由于是实验环境，故字典随意填写即可。注意其中需要包含任意一组正确的账号密码：admin/123456、pikachu/000000、test/abc123

# users.txt
test
root
admin

# pwd.txt
88888888
password
123456

基于表单的暴力破解

这里没有验证码，直接抓包爆破即可。

• 任意填写表单后提交，使用Burp抓下数据包，并将数据包发到Intruder模块
• 爆破类型选择Clusterbomb，清除多余的变量，只选择账号密码即可
• Payload类型选择Runtime file，并在下面选择对应的字典，开始攻击

bf-1

验证码绕过（on server）

填写表单及正确的验证码后提交并抓包，将数据包发送到Repeater模块，多次发包发现只提示 username or password is not exists，而不提示验证码出错，得知验证码可以重复利用。因此只需要手动填写正确的验证码即可爆破

• 手动填写一次表单，需要输入正确的验证码，账号密码可任意
• 抓包，设置变量和Payload，开始攻击即可

验证码绕过（on client）

这里验证码只在本地做了校验，跟上面一样手动输入正确的验证码并抓包即可。

token防爆破

token是由服务端生成的一串字符串，作为客户端向服务端请求的一个标识。在前端使用用户名/密码向服务端发送请求认证，服务端认证成功，那么在服务端会返回token给前端，前端在每次请求时会带上服务端发来的token来证明自己的合法性。

这一关比前面的难一点

• 前面的步骤和前面差不多，先手动填写表单提交并抓包，然后发送到Intruder模块
• 设置变量。这里为了减少攻击次数，可以把账号修改为admin，只将密码和token设置成变量，攻击类型选择Pitchfork，因为每次的密码和token需要同时替换，而不能组合使用。

bf-2

• 设置宏定义。点击option选项，下拉找到Grep Extract栏，点击Add，在弹出的窗口中点击Refetch response发一次包并获得返回数据，在下面输入栏处输入token，找到返回的token值

bf-3

• 选中token值并复制，同时在选中的情况下点击OK。然后将线程数设置为1，并在最下方Redirections重定向栏，选择Always

bf-4

bf-5

• 最后设置Payload，这里第1个Payload依然和前面一样选择对应的字典即可。第2个即token变量则选择Recursive grep递归搜索，最后将前面复制的token值粘贴在下方文本框

bf-6

• 最后开始攻击，并根据返回长度判断是否爆破成功即可

bf-7

总结

Burp爆破类型

暴力破解一般使用BurpSuite中的Intruder模块，该模块可以通过对HTTP Request的数据包以变量的方式自定义参数，然后根据对应策略进行自动化重放。

• Sniper：只设置一个Payload，每个变量依次使用Payload进行测试。假设设置了2个变量，先将第1个变量使用Payload进行测试，全部测试完成后，再将第2个变量使用Payload进行测试。

username=user&password=222&submit=Login
username=root&password=222&submit=Login
username=admin&password=222&submit=Login

username=111&password=user&submit=Login
username=111&password=root&submit=Login
username=111&password=admin&submit=Login

• Battering ram：只设置一个Payload，所有变量同时被Payload替换，然后一起尝试

username=user&password=user&submit=Login
username=root&password=root&submit=Login
username=admin&password=admin&submit=Login

• Pickfork：每个变量设置一个Payload，分别使用Payload对变量同时替换

username=user&password=111111&submit=Login
username=root&password=888888&submit=Login
username=admin&password=123456&submit=Login

• Clusterbomb：每个变量设置一个Payload，分别使用Payload组合对变量进行替换

username=user&password=111111&submit=Login
username=root&password=111111&submit=Login
username=admin&password=111111&submit=Login

username=user&password=888888&submit=Login
username=root&password=888888&submit=Login
username=admin&password=888888&submit=Login

username=user&password=123456&submit=Login
username=root&password=123456&submit=Login
username=admin&password=123456&submit=Login

验证码绕过

• 验证码认证流程
  • 客户端Request登陆页面，后台生成验证码
    • 后台使用算法生成图片，并将图片Response到客户端
    • 同时将算法生成的值全局复制到Session中
  • 校验验证码
    • 客户端将认证信息和验证码一起提交
    • 后台对提交的验证码和Session中的值进行比较
  • 客户端刷新页面，再次生成验证码
    • 验证码算法一般包含随机函数，每次刷新都会改变
• 客户端验证常见问题
  • 使用前端JS实现验证码。如果后台没有二次验证，则可以直接在Burp中改包绕过
  • 验证码存放在Cookie中。可被获取
  • 验证码存放在前端源码中。可被获取
• 服务端验证常见问题
  • 验证码在后台不过期。可被重复使用，应做到一次一用
  • 验证码设计的太过简单和有规律，容易被猜解
  • 验证码校验不严格，逻辑出现问题

关于防爆破

• 设计安全的验证码：安全的流程+复杂可用的图形
• 对认证错误的提交进行计数并给出限制，如5次连续密码错误时锁定该IP一定时间
• 必要情况下使用双因素认证
• token防爆破：一般做法是将token以type="hidden"的形式输出在表单中，在提交认证时一起提交，并在后台对其进行校验。但由于token值输出在了前端源码中，容易被获取，因此也就失去了防暴力破解的意义。