不再让 `泄露` 拖你的后腿 [ subversion篇 ]

0x01 关于 svn

1
2
3
同属C/S架构,对于svn服务端来讲,任何一个文件,在任何时刻的变化,都会被svn详细记录,并自动备份修改之前的结果,方便后续回滚
其实,底层也是靠一个独立的`文件系统 FSFS`在维护,更多内部工作细节,大家可以直接去参考百科说明,此处废话不多讲,我们真奔主题...
...

演示环境,注,此处为独立部署svn服务器,并非配合web服务一起使用

1
2
CentOS6.9_x86_64 ip: 192.168.3.59
win7cn ip: 192.168.3.70

0x02 作为一名入侵者,从svn中你都能发掘到什么宝藏

1
2
3
4
5
6
可能最容易拿到的就是数据库的各种连接账号密码,前提是,目标数据库允许外连,这样你才能更优雅的脱裤或者想办法构造上传webshell
一些邮箱账号密码,如果目标有自己的vpn或者owa之类的入口还是很值得尝试的
直接的后端代码,除了能局部审下代码之外,在注释里面也许还能看到一些关于开发人员的敏感信息
其它的各种敏感配置信息,非常多,这里就不一一细说了
注意,有些信息,确实不能让我们一刀毙敌,但高效的渗透往往是对各类敏感信息的相互配合及深度利用,这非常重要
...

0x03 既是说svn,觉得还是非常有必要先来了解下关于svn的详细部署及使用过程,总得先把它玩熟了,懂它是怎么工作的,对后续漏洞的理解才会更深刻,相信做开发的朋友,对这个早都已经非常熟练了,废话到此为止,首先,我们先来安装好 subversion

1
2
3
# rpm -qa subversion
# yum install subversion -y
# svnversion --version 这里用的svn版本为1.6.11,也就是说,目录结构都存在wc.db中

0x04 准备好各种目录,svn为总的svn所有数据存放目录,svndata为代码数据文件存放目录,svnpasswd为密码和权限管理文件存放目录

1
2
3
# mkdir /svn/{svndata,svnpasswd} -p 创建svn所需的各种目录
# svnserve -d -r /svn/svndata 指定svn根目录并后台运行svn服务
# lsof -i :3690 subversion默认工作在3690端口

1
2
3
4
5
# 创建项目目录,一般来讲一个项目对应一个目录
# 另外注意,这里必须要用svnadmin工具来创建,因为它要生成指定格式的数据,符合`FSFS 文件系统`格式的数据
# svnadmin create /svn/svndata/svndoc
# tree /svn/svndata/svndoc
# tree /svn/svndata/svndoc/conf

0x05 开始针对此项目配置svn账户

1
2
3
4
5
6
7
8
9
10
11
12
13
# cd /svn/svndata/svndoc/conf
# cp svnserve.conf svnserve.conf.bak
# vi svnserve.conf
[general] # 公共选项设置区域
anon-access = none # 禁止svn被匿名访问
auth-access = write # 让用户可写,即,能提交
password-db = /svn/svnpasswd/passwd # 指定svn账号密码文件
authz-db = /svn/svnpasswd/authz # 指定svn授权管理文件
[sasl] # 该区域一般会配合域控或ldap一起使用
# mv authz passwd /svn/svnpasswd/
# cd /svn/svnpasswd/

创建svn账号密码,因为svn默认直接存的是明文账号密码,为了防止其他人看到密码,所以要先把权限剔干净

1
2
3
4
5
6
7
8
9
10
# vi passwd
[users] # 实际中的密码,肯定是要严格按照`密码复杂性要求`来给的
web = 654321
webadmin = admin110
admin = 123456
bakuser = admin
guest = svn110
svn = svnadmin
# chmod 600 passwd

对不同的svn用户可以分别进行授权

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# vi authz
[aliases]
[groups] # 对不同业务的用户可以进行分组授权
administrator = web
sec = webadmin,admin
[svndoc:/]
svn = rw
@administrator = rw # 只需要用@即可引用指定的分组用户,如,在此让administrator组的用户可以正常读写
[svndoc:/web01] # 为每个不同的用户创建一个子分支,让指定的用户只能待在指定的分支下
bakuser = rw
[svndoc:/web02]
guest = rw

所有配置完成后,记得重启svn服务才能生效,此处是都直接是用root来运行svn的,如果你觉得权限过高,完全可以单独创建一个普通系统用户来搞,个人暂时觉得,这关系并不大

1
2
3
# pkill svnserve
# svnserve -d -r /svn/svndata
# lsof -i :3690

0x06 关于linux下svn客户端工具的基本使用说明

如果你想直接在svn服务器上查看指定项目下的所有文件,如下,只需按照目录层级,一级一级往下看即可

1
2
# svn list file:///svn/svndata/svndoc --verbose
# svn list file:///svn/svndata/svndoc/web01/vsftp --verbose

checkout 导出所有数据

1
2
# mkdir ./svndata
# svn co svn://192.168.3.59/svndoc ./svndata/ --username=svn --password=svnadmin


update 更新数据

1
# svn up ./svndata/ --username=svn --password=svnadmin


commit 提交代码,务必记得,要先加入,后提交

1
2
# svn add *
# svn ci -m "test" 带更新说明提交

0x07 在win下则可使用tortoisesvn svn客户端,想必做开发朋友,对此工具都已经熟的不能再熟了,只需要指定项目地址,提交正确的svn账号密码update一下就可以滋润的写代码了 ^_^

1
svn://192.168.3.59/svndoc




如果你不小心用tortoisesvn保存了密码,此时又想切换到不同的svn用户来测试权限,密码文件默认保存路径如下,直接去把该目录下的所有文件全部干掉即可

1
C:\Users\klion\AppData\Roaming\Subversion\auth\svn.simple

0x08 关于svn泄露利用工具的底层实现细节,其实,个人觉得此类工具的技术含量并不高,除了msf自身提供的利用模块,关于此类的工具早已多如牛毛,使用也基本全程傻瓜化,此处就不具体演示了

1
2
svn版本 < 1.6 时,会先去读取entries文件的中的目录结构,因为默认文件名都是直接明文存的
所以直接通过逐个拼接遍历访问即可读取entries中所有的文件内容

1
2
在svn版本 >= 1.6 时,文件名会先被hash下,然后再按照文件名对应hash的方式存到wc.db中,就是个sqlite数据库
而我们之后要做的事情也非常简单,只要拿着指定的hash去wc.db中查到对应的文件名,再逐个进行拼接遍历访问读取即可
1
2
另外,针对.git泄露的利用,其实跟上面的原理基本是一模一样的,只是找文件名的地方不同而已,换汤不换药,这里就不细说了
当然,专门针对github的更多信息搜集技巧,后续抽空也会单独拿出来说明,这里就先不多啰嗦了 ^_^

0x09 针对svn的绝大部分安全问题可能都在泄露上,所以,为了更好的解决这些问题,下面给出了一些针对性的防护策略

1
2
3
4
5
6
禁止各类搜索引擎对.svn,.git以及其它的一些敏感目录进行爬取,一般可在robots.txt文件中定义
如果是配合web一起使用,则可利用apache或者nginx自身配置,对.svn,.git,.ds_store...之类的敏感目录禁止访问
删除svn服务器上所有的.svn...等不必要的敏感目录
禁止开发人员在使用svn时,直接复制代码,务必严格使用导出功能
至于爆破svn,本人还从来没成功过,如果有哪位朋友成功了,也非常期待能一起交流……^_^
...

0x10 关于其它的各种web泄露,防御方法都非常简单,对所有的这些敏感目录直接在web服务器配置中禁止对其访问即可,实在没用的就直接删掉,不然留那儿,别人扫目录很可能就随随便便扫到了,或者你也可以想办法直接不让他扫,如下,是我们常见的一些泄露,有时候实在搞不懂为什么会犯这么低级的错误

1
2
3
4
5
网站各种备份泄露,如,数据库,后端代码文件...
svn及git泄露,如,各类账号密码,敏感配置...
WEB-INF/web.xml敏感配置泄露
DS_store 文件泄露
等,等,等...



小结:
    大家也看到了,这其实跟技术关系并不大,意识到了,自然就防住了,实在没什么好说的,因为侧重主要还是在防入侵上,关于svn涉及到的其它的一些边缘性的安全问题这里就没细说了,最后,如果大家还有更多更刁钻的手法,也非常期待能一起交流 ^_^