任意文件读取漏洞学习

0x00 前言

本篇文章参考Nu1l战队编写的从0到1 CTFER成长之路,算是记录一下学习复习知识点~

0x01 背景介绍

很多网站由于业务需求,往往需要提供文件(附件)下载的功能块,但是如果对下载的文件没有做限制,直接通过绝对路径对其文件进行下载,那么,恶意用户就可以利用这种方式下载服务器的敏感文件,对服务器进行进一步的威胁和攻击

0x02 文件读取漏洞常见触发点

PHP

PHP标准函数中存在许多与文件读相关的函数,这些函数包括但不限于:file_get_contents()、file()、fopen() 等函数,以及与文件包含相关的函数include()、require()、include_once()、require_once() 等,这些是我们在审计代码时需要重点关注的函数

  • 另外,与其他语言不同,PHP向用户提供的指定待打开文件的方式不是简简单单的一个路径,而是一个文件流。我们可以将其简单理解为PHP提供的一套协议,在PHP中存在有很多功能不同但形式类似的协议,统称为Wrapper
  • 除了Wrapper,PHP中另一个具有特色的机制是Filter,其目的是对目前的Wrapper进行一定的处理(如把当前文件流的内容全部变为大写)

PHP的Filter给我们进行文件读取提供了许多便利。假如服务端的include函数路径参数可控,正常情况下它会把目标文件当做PHP去解析,如果文件中有”<?PHP”等PHP的标签,文件内容会被当做PHP代码执行。

如果我们之间将这种带有PHP代码的文件通过include函数传入,那么由于PHP代码被执行,我们就无法通过可视文本的形式泄露源代码,这时我们就可以通过使用base64的Filter将代码编码为Base64,就不存在代码被执行的情况了。

当然,Wrapper和Filter都可以通过php.int文件禁用,所以遇到具体情况还需要具体分析。

在遇到有关PHP文件包含的实际问题中,我们通常可能会遇到三种情况:

  • 文件路径前面可控,后面不可控
  • 文件路径后面可控,前面不可控
  • 文件路径中间可控

对于第一种情况,在较低的PHP版本或容器版本中,可以尝试使用”\x00″截断,对应的url编码为”%00″。当服务器存在上传文件功能时,也可以尝试zip或者phar协议直接进行文件包含进而执行php代码。

对于第二种情况,我们可以尝试通过符号”../”进行目录穿越来直接读取文件,但这种情况无法使用Wrapper。如果服务端使用include等文件包含类函数,我们将无法读取PHP文件中的PHP代码。

第三种情况与第一种类似,但是无法通过Wrapper进行文件包含。

Python

与PHP不同的是,Python的Web应用更多地倾向于通过其自身的模块启动服务,同时搭配中间件、代理服务将整个Web应用呈现给用户。用户和Web应用交互的过程本身就是含有对服务器资源文件的请求,所以容易出现非预期读取文件的情况。因此我们看到的层出不穷的Python某框架任意文件读取漏洞也是因为缺乏统一的资源文件交互的标准。

漏洞经常出现在框架请求静态资源文件部分,也就是最后读取文件内容的open函数,但直接导致漏洞的成因往往是开发者忽略了python函数的feature,如os.path.join()函数

>>> os.path.join("/a","/b")
'/b'

很多开发者通过过滤”.”来保证用户请求资源时不会发生目录穿越,然后将用户的输入代入os.path.join的第二个参数,但是如果用户传入”/”,则依然可以穿越到根目录,进而导致任意文件读取

除了Python框架容易出现这种问题,很多涉及文件读取的操作也可能因为滥用open函数、模板的渲染不当等导致任意文件读取。比如将用户的某些输入数据当做文件名的一部分(常见于认证服务或日志服务)。

此外,Python的模板注入、反序列化等漏洞都可能造成一定程度的任意文件读取,当然,其最大危害仍然是导致任意命令执行。

Java

除了Java本身的文件读取函数FileInputStream,XXE导致的文件读取,Java的一些模块也支持”file://”协议,如SpringCloudConfigServer路径穿越与任意文件读取漏洞(CVE-2019-3799)、Jenkins任意文件读取漏洞(CVE-2018-1999002)

Ruby

Ruby的任意文件读取漏洞通常与Rails框架相关。目前已知的通用漏洞为Ruby On Rails远程代码执行漏洞(CVE-2016-0752)、Ruby On Rails路径穿越与任意文件读取漏洞(CVE-2018-3760,CVE-2019-5418)

Node

目前,已知Node.js的express模块曾存在任意文件读取漏洞(CVE-2017-14849),但比赛中的Node文件读取漏洞一般通常为模板注入,代码注入等情况

中间件/服务器相关

Nginx错误配置

Nginx错误配置导致的文件读取漏洞在CTF线上比赛中经常出现,尤其是搭配Python-Web应用一起出现。
例如:

location /static{
    alias /home/myapp/static/;
}

如果配置文件中包含了上述配置,有可能是开发人员想让用户访问到静态资源目录,但是如果用户输入的路径是/static../,拼接到alias上就变成了/home/myapp/static/../,这时就产生了目录穿越漏洞,穿越到了上一级的myapp目录。

数据库

可以进行文件读取操作的数据库很多,以MYSQL为例
MYSQL的load_file()函数可以进行文件读取,但此函数需要数据库配置FILE权限(数据库root用户一般都有),其次需要执行load_file()函数的MYSQL用户/用户组对目标文件具有可读权限。

软链接

bash命令ln -s可以创建一个指向指定文件的软链接文件,然后将这个软链接文件上传至服务器,当我们访问这个软链接文件时,其实是在请求它指向的服务器文件。

FFmpeg

2017年6月,FFmpeg被爆出存在任意文件读取漏洞。同年的全国大学生信息安全竞赛就利用这个出了一道题,详细题解见第十届全国大学生信息安全竞赛-web-writeup

Docker-API

Docker-API可以控制Docker的行为,一般来说,Docker-API通过UNIX Socket通信,但也可以直接通过HTTP通信。当我们遇见SSRF漏洞时,尤其是可以通过SSRF漏洞进行UNIX Socket通信的时候,就可以通过操控Docker-API把本地文件载入Docker新容器进行读取

客户端相关

浏览器/Flash XSS

一般来说,很多浏览器会禁止JavaScript代码读取本地文件的相关操作,如请求一个远程网站,如果它的JavaScript代码中使用了File协议读取本地文件,那么会由于同源策略导致读取失败。但在浏览器的发展过程中存在着一些操作可以绕过这些措施,如Safari浏览器在2017年8月被爆出存在一个客户端的本地文件读取漏洞。

MarkDown语法解析器XSS

与XSS相似,MarkDown解析器也具有一定解析JavaScript的能力。但是这些解析器大多没有像浏览器一样的对本地文件读取进行限制的操作,很少有与同源策略类似的防护能力。

0x03 文件读取漏洞场景路径

Linux

flag名称(相对路径)

比赛中,有时fuzz一下flag名称即可得到答案

../../../../../../../../../flag(.txt|.php|.pyc|.py...)
flag(.txt|.php|.pyc|.py...)
[dir_you_know]/flag(.txt|.php|.pyc|.py...)
../../../../../../../../../etc/flag(.txt|.php|.pyc|.py...)
../flag(.txt|.php|.pyc|.py...)
../../../../../../../../root/flag(.txt|.php|.pyc|.py...)
../../../../../../../../home/flag(.txt|.php|.pyc|.py...)
../../../../../../../../home/[dir_you_know]/flag(.txt|.php|.pyc|.py...)

服务器信息(绝对路径)

下面将列出CTF比赛中常见的部分需知文件和路径

  • 1) /etc目录
    /etc目录下多是各种应用或系统配置文件,所以其下的文件是文件读取的首要目标
  • 2) /etc/passwd
    /etc/passwd文件是Linux系统保存用户信息及其工作目录的文件,权限是所有用户/组可读,一般被用作Linux系统下文件读取漏洞存在性判断的基准。读到这个文件我们就可以知道系统存在哪些用户,它们的组是什么,他们的工作目录是什么。
  • 3) /etc/shadow
    /etc/shadow是Linux系统保存用户信息及(可能存在)密码(hash)的文件,权限是root可读写,shadow组可读。所以一般情况下,这个文件是不可读的。
  • 4) /etc/apache2/*
    /etc/apache2/*是Apache配置文件,可以获知Web目录、服务端口等信息。CTF有些题目需要参赛者确认Web路径。
  • 5) /etc/nginx/*
    /etc/nginx/*是Nginx配置文件,同样可以获知Web目录,服务端口等信息

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇