upload-lab靶场(国光)

cvestone 发布于 2024-12-24 147 次阅读 3019 字 预计阅读时间: 14 分钟


v1(前端校验bypass)

抓包监听,如果上传文件的时候还没有抓取到数据包,但是浏览器就提示文件类型不正确的话,那么这个多半就是前端校验了。

方法一:浏览器禁用js

image.png
然后直接上传php一句话木马即可,拦截的返回包返回了上传的路径:
image.png

方法二:抓包

上传前让文件后缀合法通过前端校验,上传时抓包改后缀让其能被后端服务器解析执行:
image.png
image.png

方法三:js动态调试

选择上传文件,校验后缀前下断点:
image.png
然后点上传,会自动中断,单步调试在Scope中找到白名单变量定义,修改其值:
image.png
修改后点击resume按钮重新执行js即可上传成功。

v2(滥用htaccess)

htaccess 文件是 Apache 服务器中的一个配置文件,它负责相关目录下的网页配置。通过 htaccess 文件,可以帮我们实现:网页301重定向、自定义 404 错误页面、改变文件扩展名、允许/阻止特定的用户或者目录的访问、禁止目录列表、配置默认文档等功能。

上传php后提示不允许,发现前端虽能找到对应提示语句,但对应具体函数的实现并不包含在<script>中:
image.png
说明此时很有可能此时不再是前端校验,而校验逻辑是定义在后端php中,前端只是负责调用后端的校验逻辑函数。查看后端源码印证了这一事实:
image.png
可以发现.htaccess文件不包含在黑名单内,故可以尝试滥用该文件,自定义文件类型解析的映射配置,上传到后端使其指令生效,并且根据配置文件(主配置文件/虚拟主机配置文件)中对AllowOverride开关的设定,决定着.htaccess当与配置文件/虚拟主机配置文件中相冲突的指令中,以谁的为准,即决定着是否可以覆盖(同时包括是否容许.htaccess指令生效)。比如查看目标的配置文件,发现AllowOverride开关定义在虚拟主机配置文件中:
image.png
对应值为All,说明.htaccess定义的指令可覆盖主配置文件/虚拟主机配置文件中定义的相应指令,并且该.htaccess指令生效目标目录正好就是该网站根路径。

因此,本地写入.htaccess并上传至目标,其语法规则和其他apache2的配置文件是一样的,大部分语法都可用。我们虽无法控制黑名单,但可以通过该目录级配置文件控制类型映射解析规则,让符合校验的合法文件后缀被解析时执行恶意指令,因此写入内容如下:

AddType application/x-httpd-php .jpg .png .gif

表示将合法的图片类型文件解析为php,所以实际可上传图片马。
【更多关于该配置文件的说明和利用可参考该文章
mac无法直接选择并上传.开头的文件,可以上传时抓包修改文件名:
image.png
上传后还可以通过检查网页出现的图标元素来判断上传路径:
image.png
尝试访问:
image.png
说明文件存在,上传成功,只是无权限访问。接着再上传修改为图片后缀的php脚本或图片马,上传后发现页面回显就是之前访问木马路径时的空白页,而不是下载图片或回显图片图标,说明php马解析成功,再尝试连接马读取flag即可。

v3(MIME bypass)

媒体类型(通常称为 Multipurpose Internet Mail Extensions 或 MIME 类型 )是一种标准,用来表示文档、文件或字节流的性质和格式。
MIME的组成结构非常简单;由类型与子类型两个字符串中间用 '/' 分隔而组成。不允许空格存在。type 表示可以被分多个子类的独立类别。subtype 表示细分后的每个类型。

MIME类型校验很多时候本质是直接通过获取请求包中的Content-Type头对应MIME类型值来判断,因此上传php马后,直接修改该请求头的值为合法图片类型的即可bypass,注意文件名没必要改,改了在后端就无法成功解析php了:
image.png
从源码中寻找相应校验逻辑:
image.png
发现是通过php全局变量$_FILES来实现的。

v4(文件头bypass)

只校验文件头的话,了解misc方向的显然很容易就绕过了,即然上传的要是图片类型,只需要在图片马上传时先拦截,在请求体中加入合法图片类型的文件头即可,和用010editor这类编辑器是等效的,因为这些文件在传输过程中无非都是一连串的字节流。这一过程就相当于隐写出题人给选手出题时的场景。

先用hexdump确认下马本身的文件头,且能看出单纯修改后缀对文件头无影响:
image.png
由于在尝试各个图片类型过程中,发现大部分的hex文件头转换为ascii解码后的字符串后,许多特殊字符都会默认被.代替,只有gif格式的大部分是字母和数字,解析时相对不容易出问题。

上传马,抓包:
image.png
请求体中添加了GIF格式的文件头,达到bypass,但是上传后依然被检测出,查看源码发现还同时校验了MIME:
image.png
因此还要改:Content-Type: image/png,只要是符合校验的图片类型即可。

v5(黑名单后缀替换为空bypass)

image.png

这题有黑名单,但过滤方式只是将黑名单后缀名替换为空,此时绕过依然简单,可抓包修改后缀为图片,MIME不需要改,因为源码中无相应校验:
image.png
另外,还可以利用嵌套后缀名绕过(即“双写绕过”),因为相应替换函数str_ireplace只对目标进行一次性替换,具体来说就是它并不会因为一个替换操作改变了原字符串就重新开始检查新生成的字符串进行再替换,除非代码中该部分写循环逻辑或者用其他功能更丰富的函数来实现多次替换:
image.png

v6(黑名单后缀替换为空格bypass)

这题和上题没太大差别,改成了替换为空格,此时显然双写就失效了,双写后剩余的后缀会多一个空格导致后端无法正常解析php马,此时还可以尝试对后缀名用大小写的绕过方式,使校验失效,实现即使大小写也能被正常解析为.php,注意只对windows起作用,因为linux区分大小写会严格解析:
image.png
注意这题环境是linux,国光师傅只是写了伪造windows让其能够通过校验而已,但后端解析时还是没法成功的,因此连不上马。

v7(GET方式%00截断)

image.png
当作黑盒环境,抓包,修改后缀为png(不行再同时修改Content-Type)。
虽然最后上传成功了,但发现文件名被修改成了随机数,这样就导致实际攻击场景中我们无法找到上传的马,查看源码也能发现这是拼接上了随机时间戳:
image.png
image.png
并且发现校验逻辑改成了用白名单匹配无替换。根据代码逻辑,先判断后缀是否包含在白名单内,是则重新生成新文件名然后拼接到GET请求参数road的路径值中,显然这个新文件名并不是我们想要的,但恰好road是我们的可控参数又没有做过滤,因此可以利用%00截断符在后端解析时将后面拼接的新文件名截断,而将我们自己构造的文件名放在截断符之前,就实现了绕过,其中由于是GET方式,%00默认会进行一次url解码,解码后为空字节所以才会实现截断:
image.png
所以最终上传成功后的文件名就变成了hack2.php,然后就能够解析该木马。

v8(POST方式%00截断)

和上题差不多,只是可控参数的位置变转移到了POST请求体中,注意如果直接像上题一样添加%00后,发现并没有上传成功,因为POST请求体不像GET,不会默认先url解码一次,所以需要在burp中对其手动解码:
image.png

v9(黑名单解析后缀bypass)

image.png
根据图片的暗示,上半部分中,SetHandler指令用于指定Apache如何处理特定类型的请求,后面跟着的是特定用途的处理器;后半部分中,这些设置告诉Apache如何处理不同扩展名的PHP文件,用哪种处理器。综合来看,实际上就是apache会将上述的拓展名都解析为php,这也就意味着,如果是采用黑名单,容易遗漏一些冷门后缀,考虑不全,导致仍能成功被解析为php。本题利用的话就可以配合burp的Intruder,将这些拓展作为字典进行简单fuzz:
image.png
image.png
发现都是能够上传成功的:
image.png
访问木马,同样利用该模块fuzz,发现能够成功被解析的只有部分:
image.png
image.png

v10(条件竞争)

image.png
题目所给的暗示和解释都很清晰了,所以要检查是否条件竞争有效,需要同时抓两个包,分别是上传竞争马和访问竞争马生成的植入服务器的木马的包,然后都采取无限发包的方式,实际上就是在和服务器抢时间,通过这种大量发包,服务器如果没有做好对该场景下的相应措施,来不及将所有的包都及时检测拦截,只要有一个竞争马的包成功抢占时间被解析成功,最终木马就会植入成功。

竞争马:<?php fputs(fopen('hack.php', 'w'),'<?php @eval($_POST["pass"]);?>');?>
image.png
image.png
访问生成的木马的包同理:
image.png

从代码层面来看,首先梳理下具体的逻辑流:

1.文件上传:当用户提交文件时,move_uploaded_file() 函数会将上传的临时文件移动到指定的目标位置。
2.文件类型检查:在文件成功上传后,代码会检查文件扩展名是否在白名单中。
3.文件重命名:如果文件扩展名是允许的,那么它会被赋予一个新的随机名称,并且原文件会被重命名为这个新名称。

存在的安全问题:上述过程中的步骤 1 和步骤 2 之间没有同步机制,这意味着攻击者可以在文件被上传之后但在扩展名被检查之前访问该文件。move_uploaded_file 成功执行后,文件已经被放置在服务器上,但此时还没有进行安全检查(即扩展名检查)。攻击者可以利用这段时间窗口,通过快速发送 HTTP 请求来尝试访问刚刚上传的文件,在文件被重命名或删除之前执行它。为了修复这个问题,应该确保所有安全检查都在文件实际写入磁盘之前完成。例如,可以在调用 move_uploaded_file 之前就检查文件扩展名和其他安全属性,或者使用临时文件和原子操作来保证文件只在所有检查都通过后才变得可访问。最后,扩展名检查远远不够,还应该配合其他检查。

v11()

image.png

  • alipay_img
  • wechat_img
此作者没有提供个人介绍
最后更新于 2024-12-24