pikachu靶场题解-暴力破解

暴力破解

1. 基于表单的暴力破解

题干

解题过程

打开bp开启拦截，先随便输入Username和Password，例如：fufu和123。使用Burp Suite拦截请求：

可见抓到的包中包含刚刚输入的Username和Password，将该包发送给Intruder。

Burp各种攻击模式的区别

1. **Sniper：**一个变量设置一个payload进行攻击
2. **Battering ram：**可以设置两个变量，把payload同时给两个变量
3. **Pitchfork：**两个变量分别设置payload，然后按顺序一一对应进行破解
4. **Cluster bomb：**两个变量分别设置payload，然后交叉列所有情况进行破解（常用）

由于本题中有两个输入，选择集束炸弹模式来爆破，手动设置Username和Password为两个有效载荷：

根据题目的tips，设置包含已知用户的有效载荷：

准备就绪，开始攻击：

由于密码正确的请求返回长度上会有区别，采用按长度排序来查看成功的请求：

可见已经找到给定的三个用户。

2. 验证码绕过（on server）

题干

解题过程

由题干可得，本题的验证码是放在服务器（后端）验证的，f12查看也证实了这一点：

服务器验证码常见的漏洞：

1. 验证码设计的太过简单和有规律，容易被猜解
2. 验证码校验不严格，逻辑出现问题
3. 验证码在后台不过期，导致长期可以使用

首先第一种，不断刷新验证码，发现验证码应该是随机生成的，没有啥规律，第一种不得行；

第二种的话，模拟多种提交情况来验证：

可见不同的情况都有考虑到，说明该验证码会经过后台校验的，第二种也不行；

第三种的话，先正常输入，使用bp抓包，将抓到的包发送到Repeater，利用Repeater重发请求：

可见当前输入返回为username or password is not exists～，尝试更改账号密码重发请求：

可见此时的返回仍是username or password is not exists～，说明之前的验证码是可以重复使用的，至此可以确定存在本题第三种漏洞

后面就是利用当前的验证码，像上一题一样进行爆破：

爆破结果如下图：

3. 验证码绕过（on client）

题干

解题过程

同样由题干得本题的验证码是放在客户端（前端）进行验证的，f12也证实了这一点：

客户端的验证码常见的漏洞：

1. 使用前端JavaScript实现验证码(纸老虎)
2. 将验证码在cookie中泄露,容易被获取
3. 将验证码在前端源代码中泄露,容易被获取

由上面f12的结果可得，本题符合第一种；

看似需要先让前端进行验证，实际就是纸老虎，只要过了前端这关，之后在bp中可以直接忽略掉。

先正确输入验证码，使用bp进行抓包并发送给Repeater：

由上面三张图片可见，只要过了前端验证，后续无论使用什么验证码（第二张图），甚至没有验证码（第三张图）都可以正常返回。

还是老一套：发送到Intruder，集束炸弹，设置payload，开始攻击！

4. token防爆破？

题干

解题过程

本题只有两个输入框，直接输入使用bp抓包分析：

发现本题的提交除了显示出来的username和password，还有一个隐藏的token需要提交，f12也证实了这个结论：

什么是token:

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

token的特性:

• token 完全由应用管理，所以它可以避开同源策略
• token防止重复提交和CSRF
• token 可以是无状态的，可以在多个服务间共享
• token无法防止暴力破解

现在根据源码看看整个过程中token是怎么工作的：

1. 根据f12的指引，我们找到pikachu/vul/burteforce/bf_token.php文件：

   

   该文件内容可以分为后端代码（1-67行）和前端代码（70-131行）两部分

2. 可以看到，在进入页面时，后端代码会先进行一次判断，检查是否有POST传参（其实就是输入）的账号密码，然后执行set_token()函数：

   

   至于判断语句里内部的东西，主要就是在验证传入的username、password和toke是否与数据库中存储的数据一致来决定该请求的返回：

   

   从第36行我们得知在验证时会将传入的token与$_SESSION['token']进行比较；

3. 由于初次进入页面，不存在POST传参，所以直接执行set_token()，跟进到pikachu/inc/function.php查看该函数内容：

   

   发现了token的生成方式，但这个也不重要，只需要知道生成的token存储在$_SESSION['token']中即可；

4. 回到pikachu/vul/burteforce/bf_token.php文件，知道了$_SESSION['token']变量的来源，我们来找找它的“去处”，可见在前端部分第115行$_SESSION['token']变量再次出现：

   

   此处是破解的关键点：

   <?php echo $_SESSION['token'];?>
   

   该语句会将$_SESSION['token']不经任何处理显示在表单中，因此可以通过bp抓包来获得当前token，实践后，果然如此：

   

通过上面的分析，可知该token无法防爆破，只需要在发送每条请求前获取表单中当前的token并一并发送即可：

此处由于token和每次提交的账号密码是一一对应的关系，故选择交叉（Pitchfork）模式来爆破，由于该模式的一一对应性，所以本题需要先知道账号和密码其中之一。假设已知某用户的密码是000000，尝试破解出该用户的账号，payload设置如下：

账号的爆破字典依然是之前那个，token则不采用字典，根据上面的分析，每次要提交的token都是从来自前一个请求的响应（即当前表单）中提取的，所以利用bp中的递归匹配：

此时需要设置一下爆破选项（Options）中的Grep - Extract，按照下面的步骤找到并设置每次提取的部分：

在下面的重定向（Redirections）中勾选总是（Always），以此来实现对每次更新的token都进行提取：

之后再回到payload设置，可见已经自动设置好了Payload选项，我们需要输入“第一个请求的初始payload”，将刚刚抓到的包中的token复制过来即可：

由于每次获得的token都只能用于一次提交请求，所以去到资源池（Resource Pool）中将线程设置成1，若之前没有设置过，则按照下图红色提示创建一个线程为1的资源池：

至此准备工作就完成了，开始攻击！

倒是破解成功了，但是发现有三种返回结果，经查证分别是登录成功、token错误和账号密码不匹配。

token错误猜测是由于第一次提交的token已经过期所以验证失败（这点存疑），所以假如正确的账号排在字典的第一位则会爆破失败，解决方法是将字典前两位设置成一样的，这样就能避免第一位的账号未经爆破o的情况：