文件泄露, 根据泄漏的信息敏感程度, 在WEB漏洞中可以算是中危甚至高危的漏洞, 本篇文章就来
介绍下一些常见的泄漏, 主要分为由版本管理软件导致的泄露, 文件包含导致的泄露和配置错误导致的泄露.

版本管理软件造成的泄露

git

git可以说是当今最受欢迎的版本控制/版本管理软件了, 很多基于git的云端托管仓库都提供了
免费的托管服务, 甚至有不少还支持免费私有仓库, 如bitbucket和国内的gitosc(开源中国)等.

关键文件

git在初始化项目的时候, 会在项目的根目录(可用git rev-parse --show-toplevel查看)创建一个名为
.git的隐藏文件夹, 里面包含了本地所有commit的历史记录. 如果无意间将这个目录置于WEB的路径下让用户可以访问,
那么也就泄露了几乎所有的源代码和其他其他敏感信息.

泄露内容

  • 所有该项目的源代码

  • 私有仓库的地址

  • 私密的配置信息

  • 所有commiter的邮箱帐号信息

  • (可能)内部的帐号和密码

  • ...

利用方法

常规的利用方法就是下载整个目录, 然后用git命令回滚整个项目:

wget -r --no-parent --mirror http://www.example.com/.gitcd www.example.com && git reset --hard

当然也有一些自动化利用的脚本:

  • dvcs-ripper: 基于perl的工具,除了git还支持很多版本管理系统

  • GitHack

修复建议

一般基于MVC的现代WEB框架都不会直接挂载文件, 但如果是基于PHP,ASP等语言的项目, 还是会存在安全隐患,
虽然可以通过配置WEB服务器(apache/nginx等)来拒绝对.git路径的访问, 但也会出现被意外绕过的风险.
最好的办法就是在项目新建一个www目录来存放源代码文件.

hg/Mercurial

Mercurial的意思是水银, 所以缩写成hg(汞), 也是一个版本管理软件. 用法和git有点类似, 但也保留了svn命令简明的特点,
而且原生地支持Windows/MacOS/Linux三大平台, 不像git需要MinGW才得以运行, 所以当今也有不少人偏向于用hg做版本控制.
关于他们有一些讨论, 如为什么要用hg,
为什么选hg而不是git等等, 我认为也是值得了解的.

关键文件

与git类似, hg在初始化项目时, 会在项目的根目录下创建一个名为.hg的隐藏文件夹,
里面包含了代码和分支的修改记录和开发人员的相关信息.

泄露内容

  • 项目源代码

  • 项目仓库地址

  • (可能)仓库的用户名

  • 其他

利用方法

手动利用, 下载+回滚:

wget -r --no-parent --mirror http://www.example.com/.hgcd www.example.com && hg revert

也可以用上面提到的dvcs-ripper工具来利用

修复建议

同git

svn/Subversion

svn, 即Subversion, 在github之前曾经也是炙手可热的版本管理工具, 虽然已经日渐式微, 但在很多国企,
研究院等地方依然是作为版本管理的主要工具. 对于一些历史悠久的项目, 比如LLVM, 出于历史原因,
也是主要使用svn管理源代码.

关键文件

svn同样在项目根目录下会创建一个名为.svn的隐藏文件夹, 包含了所有分支commit信息和代码记录.

泄露内容

  • 所有该项目的源代码

  • svn仓库的地址

  • svn仓库所属用户的用户名

  • ...

利用方法

同样是先下载目录, 然后回滚:

wget -r --no-parent --mirror http://www.example.com/.svncd www.example.com && svn revert --recursive .

工具&脚本:

  • dvcs-ripper: 支持旧版和新版的svn

  • Seay-Svn: 法师的工具,基于Windows平台

修复建议

同git

bzr/Bazaar

bzr也是个版本控制工具, 虽然不是很热门, 但它也是多平台支持, 并且有不错的图形界面,
所以也有一些人认为bzr比git要好用,
只是对于***测试人员来说, 其实都无所谓就是了.

关键文件

bzr在初始化项目时(bzr init/init-repo), 会在项目根目录产生名为.bzr的隐藏目录, 同样暴露了源代码和用户信息.

泄露内容

  • 源代码

  • 仓库地址

  • 开发者的信息

  • ...

利用方法

没用过bzr工具, 不过查询文档得知可用bzr revert命令来进行回滚:

wget -r --no-parent --mirror http://www.example.com/.bzrcd www.example.com && bzr revert

当然dvcs-ripper工具也是可以的.

修复建议

同git

cvs

CVS是一个年代比较久远的版本控制系统, 通过它可以追踪源代码的历史变化记录.
但是因为功能比较简单, 而且不支持分支, 所以很早前就被上面提到的svn替代了.

关键文件

cvs项目在初始化(cvs checkout project)的时候, 会在project目录下创建一个名为CVS的目录,
其中保存了各个文件的修改和commit记录. 通过此目录可以获取代码的历史版本. 其中两个关键文件为:
CVS/Root和CVS/Entries, 分别记录了项目的根信息和所有文件的结构

泄露内容

因为是纯客户端的工具, 所以只会泄露源代码

利用方法

下载CVS文件夹然后通过cvs命令获取源码信息, 不过似乎没有直接的回滚操作, 需要做点额外的处理.

wget -r --no-parent --mirror http://www.example.com/CVScd www.example.com && cvs diff *

或者直接用工具dvcs-ripper

修复建议

如果你还在用CVS, 没准你还在用perl写cgi吧? ...

其他

版本管理工具有很多, 除了上面提到的这些, 还有曾经比较知名的如BitKeeper, 现在已经很少用了,
不过偶尔还是会在CTF比赛中炸尸.

文件包含导致的泄露

除了上述版本管理工具所导致的泄露外, 配置不当也是导致信息泄露的重要原因之一.

.DS_Store文件泄露

.DS_Store(Desktop Services Store)是macOS目录下的隐藏文件, 包含了当前目录结构和一些的自定义信息,
如背景和图标位置等, 在windows下类似的文件为desktop.ini. 暴露了.DS_Store文件也就相当于暴露了该目录下的所有内容.
可以说是比较严重的泄露.

利用方法

.DS_Store的格式为二进制, 内部数据结构为Proprietary格式,
可以自行解析并递归下载所有文件, 参考lijiejie的ds_store_exp.

修复建议

使用macOS开发的同学, 可以把.DS_Store加入忽略列表中(如.gitignore), 但本质上其只是泄露目录结构, 就算删掉.DS_Store,
文件也依然存在于web服务器可以访问得到的地方, 所以治本的方法还是不要将敏感信息放在web路径中.

WEB-INF泄露

在Java的Servlet 文档中,
说到WEB-INF目录"包含了所有web应用会用到但是不处于web路径中的资源", 也就是说, WEB-INF目录下的内容是不属于公开页面的.
web应用可以通过getResource等API在servlet的上下文中访问到这些资源.

通常开发者会把许多JSP文件,Jar包,Java的类文件放在该目录下. 一般目录的内容都是可以预测的:

WEB-INF/web.xml : Web应用程序配置文件, 描述了servlet和其他的应用组件配置及命名规则.
WEB-INF/database.properties : 数据库配置文件
WEB-INF/classes/ : 一般用来存放Java类文件(.class)
WEB-INF/lib/ : 用来存放打包好的库(.jar)
WEB-INF/src/ : 用来放源代码(.asp和.php等)

利用方法

通过web.xml文件推测应用组件相关类的名字, 然后在src目录下查找代码, 如果没有源代码可以直接下载class文件反编译即可.

修复建议

发布前确认WEB-INF目录是禁止访问的, 或者在server设置好对于的过滤规则.

备份文件泄露

备份文件泄露又分为两种情况, 一种是运维人员偷懒地直接在网站根目录用类似tar -czvf bakup.tgz *的命令将网站进行备份,
这样整站的源代码都能直接被用户打包下载了； 另一种是开发或者运维人员使用的编辑器修改文件时自动备份了所编辑的网页内容,
如vim的.swp, 从而泄露了该网页的源代码.

利用方法

对于打包文件而言, ***测试人员可以用{常用文件名}+{常用压缩包后缀}的方式扫描网站, 说不定会有意外惊喜.
对于网页的临时备份文件, 可以扫描对应页面的.swp或者.bak等后缀, 说不定也能找到有用的信息.

修复建议

做好版本管理, 并利用版本管理工具过滤掉这些类型的文件, 同时不要直接在生产环境中修改或者添加文件.

配置文件泄露

现代WEB开发往往不会重新造轮子, 而是基于成熟的框架进行配置, 如果***测试人员知道该网站是基于什么类型的框架,
就可能通过该框架的文档获得重要配置文件的路径, 如果是开源框架, 同时也能获得源代码, 因此配置文件泄露的严重性也是不言而喻的.

利用方法

通过识别网站指纹得知其框架类型, 然后手工测试重要的配置文件是否可以获取. 如果是批量测试, 则可以事先准备好
常见的配置文件路径, 如wordpress的/wp-config.php等, 组织成字典然后用脚本进行批量测试. 可以参考猪猪侠的字典.

修复建议

修改配置文件的默认路径, 同时在服务器端阻止对这些路径的访问.

配置错误导致的泄露

Windows IIS / Apache 目录穿越

目录穿越漏洞原理比较简单, 程序在实现上没有充分过滤用户输入的../之类的目录跳转符, 导致恶意用户可以访问web根目录的上级从而遍历服务器上的任意文件.
虽然web服务器本身会禁止访问web文件夹以外的地方, 但如果是智障开发引入的动态页面, 又没有过滤好用户输入, 就可能会出现穿越甚至目录遍历.
甚至web服务器本身也曾经有类似的漏洞, 比如Apache Tomcat的UTF-8解析漏洞, 具体利用和绕过可以参考其他网上的文章, 这里限于篇幅就不展开了.

Nginx配置安全

Nginx的配置选项之多,并不是所有人都能熟悉,但不表示随便百度一下复制粘贴就配置了,最好还是先看下官方文档对应选项的作用和用法,
可以避免许多致命的错误. 例如Nginx在代理静态文件时, 如果不小心在配置文件中写错了一个字符:

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

就会导致访问http://example.com/static../时可以访问上级目录, 从而访问到敏感的信息.
关于nginx配置安全, 离别歌的这篇文章其实写得很不错, 值得每个开发和运维人员仔细了解.

后记

敏感信息泄露时有发生, 而且通常会造成不可预知的危害. 本文讨论了一些文件泄露的例子, 可以说是信息泄露的一个子集.
文件泄露很大程度上是由于人的粗心导致, 因此最好的预防办法就是规范开发部署流程, 尽量减少人为操作引入的失误.
引用猪猪侠的一句话:"我们面对的对手都是信息挖掘和资源整合的高手,他们只要赢一次,我们就永远输了."

参考文章:

  • git官方文档

  • svn官方文档

  • hg官方文档

  • bzr官方文档

  • cvs官方文档

  • .git泄露的利用

  • 文件泄露-知乎专栏

  • WEB-INF

  • 三个案例看Nginx配置安全

欢迎交流, 转载请保留出处.
博客地址: pppan.net