继上一次大规模数据泄漏事件爆发之后,又有一家酒店集团被证实发生数据库被入侵的消息,可能波及近5亿用户的信息安全,不同的是,这一次酒店自己公示了这一消息。

starwood+w.JPG

2018年11月30日晚,万豪酒店集团在其官网、微博等多个社交平台发布其旗下酒店《喜达屋宾客预订数据库安全事件相关信息 ​​​​》:

2018年9月8日,万豪国际收到一条内部安全工具发出的关于第三方试图访问喜达屋宾客预订数据库的警报。万豪国际迅速聘请了权威安全专家帮助确定已发生的情况。万豪国际在调查过程中了解到,自2014年起,即存在第三方对喜达屋网络未经授权的访问。万豪国际最近发现未经授权的第三方已复制并加密了某些信息,并采取措施试图将该等信息移出。2018年11月19日,万豪国际成功解密该等信息,并确定信息的内容来自喜达屋宾客预订数据库。

目前,万豪国际尚未完成对数据库中重复信息的识别,但相信数据库中包含在2018年9月10日或之前曾在喜达屋酒店预订的最多约5亿名客人的信息。这些客人中约有3.27亿人的信息包括如下信息的组合:姓名、邮寄地址、电话号码、电子邮件地址、护照号码、SPG俱乐部账户信息、出生日期、性别、到达与离开信息、预订日期和通信偏好。

对于某些客人而言,信息还包括支付卡号和支付卡有效期,但支付卡号已通过高级加密标准(AES-128)加密。解密支付卡号码需要解锁两项密钥,目前万豪国际无法排除该第三方是否已经掌握这两项密钥。对于其他客人而言,信息仅限于姓名,但有时也包括如下数据:邮寄地址、电子邮件地址或其他信息等。

从11月30日开始,万豪酒店将会通过邮件告知所有受影响的用户本次数据安全事件的消息,同时提供一年免费注册WebWatcher监控工具的机会。一旦发现涉及宾客个人信息的证据,就会发出警告。不过需要注意的是,由于各国法律规定及政策原因,WebWatcher只向英国、美国、加拿大三个国家的用户提供,中国并不在此范围内。

mobile-keycard1215.jpg

此外,鉴于此次数据库安全事件波及范围过大,万豪酒店将会逐步淘汰们目前的喜达屋系统,尽快改善网络安全工作。

几个月的时间里,已经有两次超大规模的数据泄露事件发生,影响用户规模过亿,波及范围之大可谓非常惊人。而在暗网上还有众多大大小小酒店的订房信息交易,虽难辩真假,但也让人十分忧心。

只希望这几次血的教训能够让全球的酒店集团以及各行业对于数据安全、保护用户隐私等问题上有更积极的意识,尽到足够的保护责任。

*本文作者:Andy.i,转载请注明来自FreeBuf.COM

基因编辑,对于人类来说,可谓是“潘多拉魔盒”,是悬在人类头顶的“达摩克利斯之剑”。毕竟这祖传的基因,不是你想改造就改造,想加buff就加buff的。

然鹅,对于撒旦(Satan)这样的勒索病毒来说,编辑“基因”,算不上什么神仙操作。过去几天,360互联网安全中心监测到Satan勒索病毒进行了一次更新。

图片1.png

 

(代码即病毒的基因,黑客可不是什么上帝)

很显然,黑客为了“勒索事业”的年底冲刺,又双叒叕对Satan进行了新一轮“魔改”。卫士君总结一下Satan这一波基因升级,希望大家能躲开这只超级病毒的攻击。

基因组A—升级加密密钥

上一版本看似硬核,实则羸弱,竟然佛系到直接把加密密钥明文写在文件末尾,可谓求生欲低迷。此次黑客将加密密钥用RSA加密之后经过base64编码写入被加密文件末尾,防止之前的解密工具对其进行解密。

图片2.png

 

基因组B—更新后缀.lucky

所谓行不改名坐不改姓,江湖里的坦荡规则,Satan这类鼠雀之辈必然不从。从本名“.satan”,到后来“.dbger”,再到最新发现的“.lucky”,行走江湖,躲过杀软,延续种族,Satan靠的就是不断改名换姓。

 

图片3.png

(被加密的文件后缀名为.lucky)

基因组C—Linux服务器

黑客心里很清楚,勒索企业比个人电脑更有利可图,所以Satan从攻击windows服务器,到增加了针对linux服务器的加密勒索。通过【弱口令爆破+漏洞】的方式植入服务器,严重时还会使整个企业的系统陷入瘫痪。

基因组D—永恒之蓝

作为2017年全球勒索风暴“WannaCry”的最大助推,“永恒之蓝”漏洞具备的核武级攻击效能一直广受黑客好评。这次的Satan同样免不了俗,依旧沿用了搭载“永恒之蓝”进行内网传播的手法。

 

图片4.png

 

(新的Satan病毒传播量达到峰值)

黑客会向中毒用户索要1个比特币的赎金,不过360“解密大师”已经率先支持解密“撒旦”及其变种。安全专家提醒广大用户,下载安装360安全卫士,及时拦截危险链接,查杀病毒木马;一旦中招,可以使用360“解密大师”功能,无需交付赎金,便可恢复被加密文件。

图片5.png

 

目前,360“解密大师”可破解勒索病毒达近百种,是全球最大最有效的勒索病毒恢复工具。PC端复制下方链接,https://dl.360safe.com/inst.exe下载360“解密大师”,给电脑佩戴“护身符”,“撒旦”退散保平安!

前言:

2018 年 6月 9 日至 10 日,上海合作组织青岛峰会在山东青岛举办,这是今年我国重要的主场外交活动,这同时也是上海合作组织扩员后举行的首次峰会。与历届上合组织会议相比,青岛峰会规模最大、级别最高、成果最多、成为上海合作组织发展进程一座新的里程碑。

电力.jpg

而这次峰会顺利举办的背后,离不开多家政企单位为此付出的努力。
作为国网山东省电力公司青岛供电公司的网络安全保障工作的技术支持单位,锦行科技凭借自身网络安全防护的技术资源 ,成功助力青岛供电公司,护卫上海合作组织青岛峰会的电力保障工作的正常运行,从而使峰会各项活动顺利进行。

近日,锦行科技收到了来自国网山东省电力公司青岛供电公司的感谢信。

国网山东省电力公司青岛供电公司感谢信.jpg

锦行科技在峰会电力供应期间的工作态度以及在网络与信息安全保卫领域做出的贡献获得了山东省电力公司青岛供电公司的认可和衷心的感谢。
目前,锦行科技已为多个行业提供信息安全服务,服务的行业涵盖政府、金融、基础设施、证券等等。在未来,锦行科技将努力继续为各政企用户的网络安全保障做贡献。

1542091784390.png

FIT 2019大会即将在上海举办,届时,中国首席信息安全官(CSO)高峰论坛也将于2018年12月13日(周四)下午举行,我们诚挚的邀请广大企业的信息安全负责人参与交流,共同探讨企业信息安全的现状与未来!

FIT中国首席信息安全官高峰论坛是FreeBuf互联网安全创新大会(FIT 2019)的闭门高峰论坛。今年将以「智慧赋能·安全变革为主题,聚焦企业安全建设、物联网安全、人工智能安全、网络安全法等年度热点话题,深入探讨企业信息安全技术与实践应用,致力于推进企业信息安全体系建设,加强企业信息安全管理助推企业安全生态圈的健康发展。

「浅谈企业入侵应对就绪」

主讲人:

思科大中华区安全业务技术总监 徐洪涛

议题内容:

思科的前CEO钱伯斯先生曾经讲过,这个世界上有两种公司,一种公司是曾经被黑客攻击过,另外一种公司是他并不知道自己被别人攻击过。

在这个数字化的时代,我们的企业必须为随时可能到来的攻击做好准备。我们无法依赖当今的安全技术,100%的防御攻击。企业在做好网络防御手段的同时,还需要在人员上,流程和技术上都能够作到攻击应对就绪。

思科拥有业界最为完整的整体安全解决方案和相应的技术实现,我们将基于思科企业自身的最佳实践,结合威胁情报,网络可视化平台以及事件分析平台,来探讨一种切实可用的事件响应模型。在优化响应流程,培训安全人员的同时,也拥有应对最新攻击的技术能力,帮助我们企业最快速度的发现进入网络的威胁,并且做出响应,最大化减少因为攻击造成的损失。

「智慧运营·纵深监测与响应」

主讲人:

斗象科技高级技术安全总监 张志鹏

议题内容:

随着信息化技术的发展,应接不暇的攻击手段给企业安全运营造成了重大挑战,传统安全设备在对抗各类不对等的攻击(如APT、数据窃取)更是见效甚微。企业安全建设者一方面困惑如何有效解决这类问题,一方面又要思考ROI,提升投入产出比。

斗象科技能力中心持续致力于安全能力创新,关注企业安全痛点,从企业安全纵深监测与响应的视角出发,结合大数据分析、机器学习等技术,通过对应用数据的可视计算,提出安全解决方案,帮助企业构建安全智慧运营。

「现实世界的安全运维」

主讲人:

央视网网络安全部技术负责人 黄乐

议题内容:

著名经济学些薛兆丰曾经说,经济学是研究“事与愿违”的规律的。本次分享就安全运维工作的那些“事与愿违”的事和破解思路做些分享。

「中小银行互联网安全防护的一些新姿势」

主讲人:

江苏银行安全部经理 王心玉

议题内容:

介绍中小银行在人员较少、事务繁杂的情况下如何实现自动化资产与威胁发现、从原理上怼自动化攻击进行动态防护、通过多维度分线关联分析发现潜在威胁并实时响应、利用欺骗防御技术进行精准攻击识别和追踪溯源。

「可信众测在金融行业的落地与实践」

主讲人:

国家信息技术安全研究中心

议题内容:

漏洞是绝大部分网络安全问题的根源,而众测,即是一种从“根”上防患于未然的安全手段,自出现起就成为网络安全解决方案中一道亮眼的风景。

金融业与信息技术的联系愈发紧密,金融行业的网络安全也逐渐受到重视。金融业往往存储着大量的个人和业务数据,是维持社会运转的重要基石,也同时支撑着相关行业或领域的重要业务。随着金融行业对信息系统的依赖性日益增强,使得金融行业信息的安全保护成为了当前网络安全的重点业务之一。本次分享将对可信众测这一网络新兴方案在金融领域中的应用做出分析与解读。

FreeBuf 2018金融行业应用安全报告解读

主讲人:

斗象科技安全总监 徐钟豪

议题内容:

2018年,全球互联网数据进一步呈现指数级增长之势,传统金融行业数字化转型基本完成。金融机构面对人工智能、区块链等新一轮信息技术,需要建立系统开发、IT技术、产品、客户关系等多方面的能力,面临的威胁呈现出更加多元化、复杂化的趋势。与金融机构自身研发和投资并购相比,寻求安全合作的资金投入和风险相对较小,可以有效降低不确定性。

FreeBuf安全研究院与合作伙伴一起,通过大量调研与分析,借由《金融行业应用安全态势报告》来反映该行业在应用安全方面的年度真实现状与趋势。从银行、证券、保险、互联网金融四个金融行业大分类,针对应用安全问题及安全漏洞态势进行综合分析和评定。

圆桌论坛

主题:

企业安全运营最佳实践与探索

主持人:

斗象科技CEO 谢忱

主题:

企业安全建设既是工程科学也是艺术创作,对于企业安全建设运营,如何分层设计或架构?

是否存在一套独特的安全理论见解或最佳实践体系来支撑安全体系?

近几年“智慧”、“智能”这些词在网络安全领域中已经司空见惯。在日常企业安全运营工作中,AI技术能够在安全领域实际落地应用的技术,例如网络威胁检测、业务风控等领域具体有哪些?实际效果又如何?以及如何有效评估ROI?

多位行业安全领袖汇聚一堂,开放头脑,放眼未来。共同探索在企业安全运营领域中未知的、值得探索的部分。

微信图片_20181130141159.jpg

参会报名

峰会形式:闭门会议

报名人数:150人

适宜参加对象:CSO、企业信息安全负责人、信息安全专家

联系邮件:[email protected]

报名网址:

1、http://www.huodongxing.com/event/3466519948000

2、扫描下方二维码即可报名

3466519948000_wechat (1).png

FIT 2019互联网安全创新大会

FreeBuf互联网安全创新大会(FIT)是由国内领先的互联网安全新媒体平台FreeBuf.COM主办的年度互联网安全盛会,WitAwards互联网安全颁奖盛典也将同期举行。

FIT 2019大会会期为2018年12月12日~13日,会议将在上海宝华万豪酒店举行。本次大会主论坛议程<聚焦「全球高峰会」、「前沿安全神盾局」、「WitAwards颁奖盛典」、「WIT安全创新者联盟」「X-TECH技术派对」、「HACK DEMO」六大板块,独立分设「白帽LIVE」及  「企业安全俱乐部」两大分论坛,与来自全球的安全从业者、优秀技术专家、企业安全建设者、白帽安全专家、研究机构等共同展开演讲与探讨。同时「中国首席信息安全官高峰论坛」、「漏洞马拉松线下邀请赛」也将在特色分会场同期举行。此次盛会致力于分享2018年度安全行业创新硕果,共同探索与展望未来安全新边界。

15423500902577.png

前言

在近期的一项渗透测试实践中,我们在最新版本赛门铁克Management Agent(Altiris)中发现了一个安全漏洞,而这个安全漏洞将允许攻击者实现提权。

概述

当Altiris代理执行任务扫描时(例如软件扫描),SYSTEM级服务会在扫描任务执行完毕之后向NSI和OutBox目录重新申请权限。即:

C:\ProgramFiles\Altiris\Inventory\Outbox

C:\ProgramFiles\Altiris\Inventory\NSI

申请到的权限会给‘Everyone’组成员提供这两个文件目录的完整控制权,并允许任何一名标准用户创建其他代替目录的链接。因此,‘Everyone’权限将会赋予给其他代替目录,从而该目录下的任何一份文件或文件夹都会继承这种完全控制权限。

这也就意味着,任何一名低权限用户都可以在安装了Symantec Management Agent v7.6, v8.0或v8.1RU7的终端设备上实现权限提升。

分析&发现

在执行渗透测试的过程中,我们经常会遇到各种各样安装了不同类型终端软件的主机设备。这些软件很可能就是我们的切入点,因为我们可以利用它们来实现提权,或者实现横向渗透。

在这些终端管理软件中,我们经常会见到的就是赛门铁克的Altiris。这个软件是一款终端管理框架,它不仅可以帮助组织或管理员确保设备及时安装了最新版本的操作系统补丁或软件更新,还可以检查用户或组权限。

我们这一次测试的版本是v7.6,不过赛门铁克方面也证实了,在最新补丁发布之前的所有Altiris版本都会受到这个问题的影响。

分析&发现

我们发现,Altiris文件架构中的目录都应用了‘Everyone-完整控制’权限。这些目录看起来存储的是合法内容,例如扫描配置文件和XML文件等等。但是这些目录和文件的权限都使用了一行简单的PowerShell代码,并允许我们查看任意Windows主机的ACL权限:

Get-ChildItemC:\ -Recurse -ErrorAction SilentlyContinue | ForEach-Object {try {Get-Acl -Path$_.FullName | Select-Object pschildname,pspath,accesstostring}catch{}}|Export-Csv C:\temp\acl.csv -NoTypeInformation

在查看这些文件目录的时间戳时,我们发现这些目录中的文件时间戳每天都会发生变化。深入研究之后,我们发现这些文件会在Altiris执行完系统或软件扫描之后被修改。现在,根据不同组织对配置和扫描任务的需求,这样的情况每天还有可能发生若干次。

接下来的事情就非常有趣了,当我们发现了这种特性之后,我们打算看看Cylance近期披露的攻击方式在这里是否有效【参考资料】。

下面给出的是NSI文件夹的目录权限,这个目录的权限跟Outbox目录是相同的:

Outbox目录

接下来,我们可以尝试使用James Forshaw的符号连接测试工具来将该目录重定向到其他位置,然后创建一个其他目录的挂载点,看看这个目录下的文件是否会被改写,而事实是我们成功了。当然了,我们还可以使用sysinternals的链接工具,但是这个工具要求源目录不存在,但是我们这里的目录已经存在并拥有‘Everyone’权限了。比如说:

拥有‘Everyone’权限

如果我们把这个目录删除,我们就没有权限去实现这种攻击了。而James Forshaw的工具允许覆盖已存在的目录:

没有权限去实现这种攻击

在这种攻击技术中还可以使用另一个名叫mklink.exe的Windows工具,但是该工具需要高级权限,这里就不适用了,因为我们要做的就是提权。

攻击分析

我们应该如何实现攻击呢?别担心,我们有很多种方法来利用这个漏洞,但是最简单的方法就是去尝试覆盖整个Altiris根目录(“C:\Program Files\Altiris\AlritisAgent\”)权限,这样我们就可以修改SYSTEM账号下运行的服务代码了,也就是AeNXSAgent.exe。

下面的截图显示的是在挂载点修改权限之前Altiris Agent目录以及AsNXSAgent.exe服务代码的权限:

AsNXSAgent.exe服务代码的权限

AsNXSAgent.exe服务代码的权限

接下来,我们创建一个指向Altiris Agent目录的挂载点,运行之后我们就可以让每一个文件拥有完整权限了,实现起来非常简单。这里我们可以使用James Forshaw的符号链接测试工具来创建和验证挂载点。

创建和验证挂载点

接下来,我们只需要目标主机再次执行扫描任务,下面的截图显示的就是我们的成果:

成果

当我们拿到了AeXNSAgent.exe的完整控制权之后,我们就可以替换服务代码,然后重启主机来获取SYSTEM权限了。

总结

Altiris Management Agent v7.6, v8.0和8.1 RU7均会受到该漏洞的影响,我们强烈建议大家尽快升级更新自己的软件。

如果大家还有利用该漏洞的新姿势,欢迎大家在下方评论区踊跃讨论。

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

前言

在当今严峻的网络安全形势下,相信各类企事业机关对与网络安全重要性的认识已经不用多说了,但是网络安全文化构建还极度缺失。

来自ISACA研究所的《2018年网络安全文化报告》指出,95%的全球受访者认为他们当前的网络安全文化建设与期望的最终状态存在巨大差距,在网络安全领域的资源投入需要优先考虑网络安全文化的培训和体系构建,同时还要建立年度网络安全文化评估以提高员工意识。

report

本文就来对《2018年网络安全文化报告》进行一个解读,权当为相关人士抛砖引玉~

概述

对于一个组织而言,每一个活生生的人才是网络安全态势战略管理的核心。然而,大多数网络安全防御体系的构建还是基于传统的战争模式,核心理念是确保所有边界的安全,御敌于外。ISACA研究所的安全专家指出,传统理念在迅速变异的网络犯罪形式和手段面前早已不堪一击,传统的网络安全长城已经千疮百孔。

来自世界经济论坛的分析师表示,想要成功应对激增的网络攻击,协调一致的团队努力是必要条件。在商业环境中,高绩效团队的特征是公开交流、信任、合作和清晰的责任划分。对于网络安全这一块也是一样的,企业从上至下能够拿出积极的态度和持之以恒的行动,效果远远比国家层面通过技术打击或通过警方介入好得多。

但是并非每个组织、每家企业都能建立这样的工作文化,让安全意识和行为无缝融入到到每个人的日常工作中。ISACA研究所就是在这样的背景下进行了一次全球范围内的网络安全文化调查,力求探明能够做到这一点的组织有哪些文化特征和做法,如何管理和维护数字资产、网络、知识产权、雇员的行为。

网络安全文化的特征

在企业的数字化转型中,员工对于数据的获取、流转、处理等日常操作构成了一个组织的“网络文化”的一部分。要审视企业的网络安全文化,需要深入研究个人信仰、刻板印象和习惯等因素,这些内容可为分析整个企业的安全相关行为提供信息基础。除了与信息技术有关的安全措施外,这些数据还能体现出一个组织的风险框架。

什么是有效的网络安全文化?

研究显示,成功的网络安全文化需要员工具备以下特质:

清楚了解保障终端安全需要做什么;

能够参与常规的安全培训;

积极尝试网络安全项目规定的操作方法和习惯。

如果全体员工都能具备以上特质,企业能够获得以下好处:

能够看到潜在的风险点;

减少网络安全事件的发生;

在遭到网络攻击后能够快速恢复业务;

开展全新业务的能力大大增强;

客户对于其品牌的信任度不断上升。

本次调查得到的数据显示,只有5%的受访者认为,他们当前的网络安全文化建设符合预期,也就是,高达95%的受访者认为,员工不具备或者仅具备以上特质中的几项,网络安全文化建设的现实和理想状态间存在严重的脱节,企业运营、品牌忠诚度和竞争优势等方面均已看到负面影响。

虽然受访者或多或少都认识到了这一差距,但他们不知道该怎么做,最关键的问题是缺乏一个有凝聚力的管理计划,一个全员投入的抓手。《2018年网络安全文化报告》为网络安全管理和转型能力比较薄弱的企业提供一个可以操作的路线图,均是从成功实践的企业身上得出的共性。

方法一:健康的网络安全文化的标志

参与这项全球研究的4815名受访者中,近90%的认为建立一种更强大的网络安全文化可提高企业的业务拓展能力和生存能力:网络安全不再仅仅是成本中心该管的事了,而是一个企业业务的推动力。

标志一、良性循环

在企业内部,雇员明确了解自己的角色和责任后可形成一种良性循环。当网络攻击发生时,企业能够以非常灵活的方式进行响应,通过动态的防御手段加快业务恢复。清晰的架构能够加强各部门之间的交互和理解,实现网络安全保障方案的全面协调,在法律法规不断变化的情况下快速合规,或者在新技术、新战略推出时能够更快地落地。

标志二、明确KPI

在尚未建立有效网络安全文化的组织中,缺乏明确的管理计划或关键绩效指标是一个共同的特点。员工并不觉得维护网络安全与自己的利益存在多大关联,导致企业更容易暴露在数据泄露、商业机会流失、客户忠诚度下降、监管机构处罚等风险之中。

组织需要建立KPI以实现用于行为追踪和改进的衡量基准和手段,然后根据KPI制定政策,将风险意识转化为员工的日常行为,构建有意识的安全文化。

方法二:全民参与

高层管理者从各个角度的推动非常关键,受访者中只有58%表示有全盘的网络安全文化管理计划和政策,绝大多认为是CISO(60%)或CIO(47%)责任,只有6%的受访者邀请人力资源部门介入以全面推动计划的实现。

成功的沟通往往是双向的,通常从倾听员工的想法开始。 大约46%的组织在过去一年内采取过措施来评估员工对组织的网络安全文化或指导方针的看法或理解。专家表示,员工对网络安全的假设或印象对于形成对个人责任的理解至关重要。

如何构建有组织、有纪律的网络安全文化

构建一个跨团队的核心网络安全文化团队可唤起全民参与的热情,可以这么做:

1. 高级管理层将网络安全添加到董事会的常设议题中,确保始终有充足的资源支持计划推进,并在安全问题和业务目标不一致时解决冲突。

2. 信息安全教育业务部门研究和推广最有效的安全流程。

3. IT部门负责维护基础设施和最新技术的部署,并收集网络安全分析数据。

4. 人力资源部分通过培训、研讨会等形式了解员工对于自身责任、安全流程和操作规范的理解。

5. 法务部提供有关国际和国家法规的快速反馈,推进公司上下行为准测的合规。

6. 市场/内部协调部门提供技能支持,通过内部渠道、电子邮件、提示列表、海报、网络研讨会和公司内部网络来教育员工和推动政策落地。

跨部门的网络安全团队可以快速推进网络安全试点计划和培训,有助于信息共享、分析以及调整未来的计划。

方法三:赢得员工和管理层的支持

在企业内部成功营造网络安全文化,与全体员工和管理层的支持密不可分。根据ISACA研究所的调查,近半数成绩斐然的组织采取的一项关键做法就是每年衡量和评估员工的意见。结果表明,在这方面企业还存在很多提到的空间:34%的受访者认为他们的员工清楚了解在贯彻组织所需的网络安全文化方面的作用; 47%的受访者表示他们的员工只是“有点”了解它; 19%的受访者认为他们的员工根本没有概念或不理解。

那么该如何获得自上而下的全面支持?

网络安全专家Ross提出了一些沟通机制的建议:

1. 在新员工的入职流程中加入安全协议内容。

2. 在部署新硬件或进行软件升级后,每哥季度为员工提供额外培训。

3. 根据个人认识、技术难度或部门风险态势制定安全培训。举个例子,财务部门在面对个人数据时该怎么做。

4. 通过小组活动和个别指导深入推进安全培训。

5. 选择积极提问并提供反馈的监察员。

6. 选取网络攻击相关新闻来来讨论当前的网络安全态势。

7. 建立联络点并进行模拟演练,让员工在实际的网络攻击中掌握方法和技能。

方法四:制定相应的基准测试

业务目标和相应的基准测试是任何战略计划的基本要素。对于网络安全文化计划而言,组织应考虑先行记录员工的行为、合规性和参与网络安全风险预防的态度来构建一个基准,然后努力帮助改进。根据调查结果,有近三分之一的企业虽然制定了目标或KPI,但是没有制定员工针对网络安全文化的理解程度的基准测试。通过基准测试,组织还可以衡量员工在日常运营中是否能够遵循指南或主动报告可疑电子邮件、行为或事件。这些信息可以作为相关培训的出发点或者是针对性的干预措施。

将IT转型作为制定测试的抓手

网络安全专家Grindstaff建议将网络安全规则融入到员工的设备申请和软件更新流程中。 网络安全团队可以借助后续电子邮件来推进网络安全文化,比如员工在进行如下操作时:

1. 更新密码或使用新的加密方式。

2. 在工作场所携带或要求使用个人设备,如笔记本电脑、平板电脑、手机和USB驱动器。

3. 开始涉及到共享、存储、下载或传输数据的新工作职责时。

4. 登录VPN或未知网络时。

方法五:组织培训,提供实践渠道

网络犯罪的形态正在迅速变异,主要原因是社会生活方式的变化。比如喜欢在社交媒体上公开个人信息或使用不安全设备(BYOD)的员工,往往会被作为网络攻击的切入点,通过他们的渠道安装未经批准的软件或者提供凭证盗窃的新途径等。企业网络安全团队必须将培养员工意识作为重点方向。

调查显示,近四成的组织已经加强了以风险意识、隐私政策和数据保护为主的培训。 但是,依然有半数组织处于网络社区或社交媒体互动带来的潜在威胁之中。实际上,上述培训还远远不够。例如,调查结果中83%的员工培训计划是在线(基于计算机的培训)而不是通过实践或面对面培训进行的。

使用一些被动约束制度是有用的。 例如,通过人工方式提示员工进行密码更新,将合规性要求嵌入到工作流程中,或者强制设置系统更新周期以求通过软件和技术获得保护。

受访的部分组织做得更好。它们积极开展试点计划,根据不同部门的特定流程或数据访问需求量身定制。此外,当员工收到可能包含恶意代码的网络钓鱼电子邮件或附件时,安全团队能够通过主动防御系统及时监测并进行干预。

将游戏纳入培训研讨会还可增加接受度、加深印象、提高学习效率,比如员工可扮演不同的角色来展示网络犯罪时如何发生的并应该怎么预防,建立共同的目标和社区意识。个性化的培训研讨会包括Q&A等互动元素,可通过专属T恤、帽子或礼品证书等方式激励安全意识得到提升的员工。

方法六:加强董事会的参与度

网络安全威胁将带给企业看得到的财务、运营、法律和市场风险。处理任何威胁(无论是与技术有关还是其他方面)都是董事会的责任范畴。

在认识到网络安全文化的现实状态和理想目标存在显着差距的组织中,三分之一的受访者认为缺乏高管支持是主要的绊脚石。将网络安全文化充分融入到内部时遇到的障碍还包括资金不足、组织目标冲突以及员工/团队风格、文化或地理分割造成的影响。这些受访者都遇到过业务问题和竞争劣势,例如数据泄露、法律/监管处罚、品牌信任度下降、员工敬业度变低以及客户流失率高等。

成功构建网络安全文化的组织在高层推动上有着共同点,比如高层管理人员以身作则加强自身行为规范,亲自担任网络安全团队领导,参加在各类网络安全讨论活动,优先分配预算支持,聘请顾问,并进行研究以评估企业风险和能力等。

为了获得这种支持,专家建议CISO和CIO通过抛出一些引人注目的商业案例来阐述对网络安全问题的理解和担忧。他们应该详细说明安全问题将如何影响企业资产、新产品开发、市场战略以及企业使命等方面。

参考链接

http://www.isaca.org/info/cybersecurity-culture-report/index.html

*本文作者:Freddy,转载请注明来自FreeBuf.COM

facebook-for-business.jpg这里要分享的是一个关于Facebook商务管理平台网站(https://www.facebook.com/business/)的漏洞,攻击者通过构造特定的POST请求消息,可以向特定商家的后台管理员账户组中,添加任意具备管理员权限的账户,进而实现对Facebook商家后台和相关应用的管理控制。

Facebook Business介绍

Facebook商务管理平台(Facebook Business)是一个免费的 Facebook 平台,旨在帮助广告主集成业务的全部 Facebook 营销活动和外部合作伙伴。商家将能够投放和追踪广告,管理主页和广告帐户等资产,并添加经销商或营销合作伙伴,帮助管理业务。

Facebook Business是一个面向所有人的平台。各种规模的商家均可使用商务管理平台集中管理所有业务资产和信息,从而有条不紊地开展业务。借助商务管理平台等中央商务中心,商家可以全面掌控 Facebook 资产,安全地管理用户访问权限,向合适的用户授予适当额度的权限。Facebook商务管理平台中的商家管理员账户(admin),可管理商家平台和主页中的所有设置、用户和权限。

漏洞原因及测试

在Facebook Business商家主页的管理设置中,存在着一个向商家后台添加管理员账户的调用请求,该请求没有任何权限限制,攻击者可以向任意商家后台添加一个具备管理员权限的用户。大致的POC代码如下:

HTTP POST

/business/aymc_assets/admins/import/

Host: facebook.com

business_id=TARGET_BUSINESS_ID

admin_id=MALICIOUS_USER_ID

session_id=SESSION_ID

其中,business_id代表了目标商家的ID号,admin_id代表了想要添加进入的用户ID号,这两个编号都可以通过抓包形式了解到具体的构造格式。

PoC视频:

漏洞影响

利用该漏洞,攻击者可以在不具备任何身份角色的情况下,向任意商家后台添加一个具备管理员权限的用户,以此获得对商家Facebook业务相关的后台管理、商务主页、广告账户、应用程序和Instagram账户的管理控制权限。

漏洞上报进程

2018.10.9    向Facebook安全团队上报漏洞

2018.10.9    Facebook进一步分析验证

2018.10.10   Facebook把相关存在漏洞的服务端移除

2018.10.15   Facebook再次审计确认

2018.10.15   Facebook修复漏洞

2018.10.17   Facebook向我发放 $27,500 美金的赏金

*参考来源:philip,clouds编译,转载请注明来自FreeBuf.COM 

最近,我们在进行一项安全研究时,需要在任意进程中修改内存空间的保护标志。起初,我们发现这项任务看起来很简单,但在实际操作中,却发现困难重重,还好这些都不是什么大问题。在解决这些问题的过程中,我们还学到了一些新的东西,主要是关于Linux机制和内核开发的。在以下的详解中,我们会介绍我们所采取的三种方法以及每次寻求更好解决方案的原因。

背景介绍

在现代操作系统中,每个进程都有自己的虚拟地址空间(从虚拟地址到物理地址的映射)。此虚拟地址空间由内存页面(某些固定大小的连续内存块)组成,且每个页面都有保护标志,这些保护标志决定了允许对该页面的访问类型(读取、写入和执行)。不过,这种机制依赖于架构页表(architecture page table)。不过要注意的是,在x64的架构中,你不能只进行页面写入,即使你是特意从操作系统请求的,也都同时具有页面写入和可读的功能。

在Windows中,你可以使用API函数VirtualProtect或VirtualProtectEx修改内存空间的保护。VirtualProtectEx使我们的修改任务变得非常简单:因为它的第一个参数hProcess是“要修改其内存保护的进程的句柄”。

不过,在Linux中,修改过程就没有这么简单了,因为修改内存保护的API是系统调用mprotect或pkey_mprotect的结果,并且这两个函数始终在当前进程的地址空间上运行。现在让我们想办法解决一下如何在x64架构上的Linux中解决修改的问题,不过前提条件是,我们具有修改设备的root权限。

方法一:代码注入

如果mprotect总是在当前进程中运行,我们需要让目标进程从它自己的上下文中调用它。这时就要用到代码注入了,该方法可以通过许多不同的方式实现。我们可以选择使用ptrace机制实现它,该机制允许一个进程“观察和控制另一个进程的执行”,包括修改目标进程的内存和寄存器的能力。这种机制用于调试器(如gdb)和跟踪实用程序(如strace),使用ptrace注入代码所需的步骤如下:

1.使用ptrace附加到目标进程,如果进程中有多个线程,那么最好停止所有其他线程;

2.找到一个可执行的内存空间(通过检查/ proc / PID / maps),并在这个空间编写操作码syscall(十六进制:0f05);

3.根据调用约定来修改寄存器,首先,将rax修改为mprotect的系统调用号(即10);然后,前三个参数(即起始地址、长度和所需的保护)分别存储在rdi、rsi和rdx中;最后,将rip修改为步骤2中使用的地址;

4.继续这个过程,直到系统调用返回(ptrace允许你跟踪系统调用的进入和退出);

5.恢复被修改的内存和寄存器,从进程中将其分离并恢复正常执行;

这种方法是我们的采用的第一个也是最直观的方法,并且非常有效。不过在我们发现了Linux中的另一种完全破坏机制:利用seccomp进行破坏之后,该方法就不是我们的最优选择了。基本上,它是Linux内核中的一个安全工具,允许进程输入某种形式的“监狱”,除了read,write,_exit和sigreturn之外,它不能进行任何系统调用。还有一个选项,可以指定任意的系统调用及针对它们的过滤参数。

因此,如果进程启用了seccomp模式并且我们尝试将一个对mprotect的调用注入其中,那么内核将终止进程,因为该进程是不允许使用此系统调用的。因此,要对这些进程进行调用,就要采用方法二。

方法二:在内核模块中模拟mprotect系统调用

seccomp(全称securecomputing mode)是linuxkernel从2.6.23版本开始所支持的一种安全机制。

在Linux系统里,大量的系统调用直接暴露给用户态程序。但是,并不是所有的系统调用都被需要,而且不安全的代码滥用系统调用会对系统造成安全威胁。通过seccomp,我们限制程序使用某些系统调用,这样可以减少系统的暴露面,同时是程序进入一种“安全”的状态。

由于Linux中存在另一种完全破坏机制:利用seccomp进行破坏,因此这个方法肯定要在内核模式中进行。在Linux内核中,每个线程(包括用户线程和内核线程)都由一个名为task_struct的结构表示,并且当前线程(任务)可以通过pointer current访问。内核中mprotect的内部实现使用了pointer current,因此我们的第一个想法是,只要将mprotect的代码复制粘贴到内核模块中,并将每次出现的current替换为指向目标线程task_struct的指针,不就可以了吗?

接下来的事情你可能已经猜到了,就是复制C代码,不过复制过程并不是你想的那么简单,因为其中存在大量使用我们无法访问的未导出的函数、变量和宏。某些函数说明会在标头文件中导出,但是它们的实际地址不是由内核导出的。如果内核是用linux内核符号表kallsyms编译的,那么通过文件/ proc / kallsysm导出所有内部符号,这个特定的问题就可以解决。因为kallsyms在进行源码调试时具有相当重要的作用,它可以描述所有不处在堆栈上的内核符号。linux内核在编译的过程中,将内核中所有的符号(所有的内核函数以及已经装载的模块)及符号的地址以及符号的类型信息都保存在了/proc/kallsyms文件中。

尽管存在这个特定问题,我们仍然试图实现mprotect调用。为此,我们特意编写一个内核模块,利用该模块获取目标PID和参数以进行mprotect,并模仿其调用行为。首先,我们需要获取所需的内存映射对象,用它表示线程的地址空间:

    /* Find the task by the pid */
    pid_struct = find_get_pid(params.pid);
    if (!pid_struct)
        return -ESRCH;

    task = get_pid_task(pid_struct, PIDTYPE_PID);
    if (!task) {
        ret = -ESRCH;
        goto out;
    }

    /* Get the mm of the task */
    mm = get_task_mm(task);
    if (!mm) {
        ret = -ESRCH;
        goto out;
    }

    …
    …

out:
    if (mm) mmput(mm);
    if (task) put_task_struct(task);
    if (pid_struct) put_pid(pid_struct);

现在我们已经获得了内存映射对象,这大大方便了以后的操作。 Linux内核实现了一个抽象层来管理内存空间,每个空间由结构vm_area_struct表示。为了找到正确的内存空间,我们使用函数find_vma,该函数会根据所需地址搜索内存映射。

vm_area_struct包含字段vm_flags,它以独立于架构的方式来表示内存空间的保护标志,vm_page_prot也以独立于架构的方式来表示内存空间的保护标志。单独修改这些字段并不会真正影响页表(但会影响/proc/PID/maps的输出,我们已经尝试过了),详情请点击这里

在对内核代码进行了一些阅读和深入研究之后,我们发现要真正攻破内存空间的保护,最重要的工作是以下3方面:

1.将字段vm_flags修改为所需的保护;

2.调用函数vma_set_page_prot_func,再根据vm_flags字段来更新字段vm_page_prot;

3. 调用change_protection_func函数来实际修改页表中的保护位;

虽然以上的那段代码很有效,但其中也存在着很多问题。首先,我们只实现了mprotect的基本部分,但原始函数的基本功能却比我们能开发的要多得多,例如,通过保护标志分离和连接内存空间。其次,我们使用了两个内核函数(vma_set_page_prot_func和change_protection_func),这些函数不是由内核导出的。此时,我们可以使用kallsyms来调用它们,但是这很容易出现问题,因为将来我们可能会修改它们的名称,或者将内存空间的整个内部实现进行修改。不过,我们想要一个更通用的解决方案,即不考虑内部结构的方案,此时,就有了方法三。

方法三:使用目标进程的内存映射

方法三与第一种方法非常相似,即都要目标进程的上下文中执行代码。虽然,这两个方法都可以在我们自己的线程中执行代码,但在方法三中,我们使用的是目标进程的“内存上下文”,这意味着,我们要使用内存中的地址空间。

我们通过几个API函数就可以在内核模式下修改地址空间,其中就用到了use_mm。正如use_mm的介绍中明确指出的那样“此例程仅会被用于从内核线程上下文中进行调用”。由于这些线程是在内核中创建的,不需要任何用户地址空间,因此可以修改它们的地址空间(地址空间内的内核区域在每个任务中都以相同的方式映射)。

在内核线程中运行代码的一种简单方法就是通过内核的运行队列接口(queue interface),它允许你使用特定例程和特定参数来进行进程调用。我们的工作例程也非常简单,它会获取所需进程的内存映射对象和mprotect的参数,并执行以下操作(do_mprotect_pkey是内核中实现mprotect和pkey_mprotect系统调用的内部函数):

use_mm(suprotect_work->mm);
suprotect_work->ret_value = do_mprotect_pkey(suprotect_work->start,
                                             suprotect_work->len,
                                             suprotect_work->prot, -1);
unuse_mm(suprotect_work->mm);

当我们的内核模块在某个进程(通过一个特殊的IOCTL)获得修改保护的请求时,该请求首先会找到所需的内存映射对象(正如我们在前面的方法中所解释的那样),然后再使用正确的参数来调用进程。

不过这个解决方案仍有一个小问题,即函数do_mprotect_pkey_func不会由内核导出,需要使用kallsyms获取。与第一个解决方案不同,这个解决方案中的内部函数不太容易被修改,因为该函数与系统调用pkey_mprotect有关,而且我们也不用处理内部结构,因此我们只能将其称为“小问题”。

我们希望你在这篇文章中找到一些有趣的信息和技巧,学会如何在任意进程中修改内存保护属性。如果你有兴趣,可以在github中找到这个概念验证内核模块的源代码。

一、概述

在攻击的早期阶段,我们其实很难深入了解攻击者的节奏。通常,在侦查(Reconnaissance)和武器化(Weaponization)阶段,如果研究人员想要确定攻击者大致需要多久才能与目标直接进行交互,他们用于分析的数据少之又少。我们在对2018年8月攻击中东地区政府并投递BONDUPDATER恶意软件的组织进行持续分析的同时,观察到OliRig的一系列测试活动。我们有证据表明,这些测试活动与攻击中所使用的武器化交付文件具有关联性。

由于我们此前已经观察到OilRig在他们的交付文档和TwoFace WebShell上进行测试活动,因此这次也成功发现,OilRig在他们的开发过程中使用了一个测试组件。这一测试组件用于对其交付文档进行部分修改,并将其提交到在线反病毒扫描工具,从而确定所提交文件的被检测情况,从而找出规避检测的方法。利用这些在线扫描程序,攻击者可以迅速了解哪些反病毒引擎能够检测到恶意软件,在侧面为攻击者提供了一个“质量保证服务”。

为了确定OilRig恶意组织的时间线,我们比较了测试文件的创建时间、交付文档的创建时间以及攻击过程中鱼叉式网络钓鱼邮件的发送时间。我们发现,OilRig在对目标发起攻击的6天前就开始进行测试工作,并且在8月20日、21日和26日尝试进行了三次测试。测试人员在交付文档创建的8小时前创建了最终的测试文件,随即在20分钟后将交付文档通过鱼叉式网络钓鱼邮件发出。

二、测试活动

在调查OilRig组织利用最新版本的Boudupdater进行攻击的过程中,研究人员查找了OilRig利用过的其他Microsoft Office文档,从而希望找到在同一时期内用于其他攻击的恶意软件。我们找到OilRig制作的原始Microsoft文档后,重点对其进行了功能性分析。

我们的研究人员共计发现了11个额外的样本,这些样本分别在几个反病毒测试平台提交,如下表所示。这些样本似乎都是OilRig在开发和测试阶段创建的,所有这些文件都与最终的交付文档有众多相似之处。此外,下表中也包含了OilRig最近针对中东政府攻击所使用的文件N56.15.doc(7cbad6b3f505a199d6766a86b41ed23786bbb99dab9cae6c18936afdc2512f00)。在此测试期间,我们发现文档的名称中包含我们在此前攻击中见过的C&C,特别是文档XLS-withyourface.xls和XLS-withyourface – test.xls。由于这些文档在元数据、宏代码和包含C&C域名的文件名中具有高度相似性,因此我们认为,这些文件实际上是OilRig在8月26日发动攻击前的测试文件。有趣的是,尽管所有测试文件都是Microsoft Excel文档,但在实际攻击中使用的是Microsoft Word文档。

1.png

根据上述表格中的元数据,可以看出OilRig开发人员在针对目标发动攻击的6天前(8月20日)就开始创建这些测试文档。OilRig进行的所有测试活动都发生在8月26日的攻击之前。我们通过查看测试活动和攻击活动中相关文件的“上次修改日期”,很容易绘制出完整恶意活动的时间轴,如下图所示。

2.png

8月20日,有22个反病毒引擎检测到XLS-withyourface.xls的第一次迭代版本存在威胁,如下面的图表所示。在接下来的7分钟内,测试人员创建了另外两个样本,其检出数量降低了16,仅有6个反病毒引擎能够成功检出。测试过程中,检测率的最低值出现在测试阶段的早期,也就是8月21日。在上图的时间轴中,展示了测试活动的详细情况。最后一次测试迭代发生在实际攻击所使用的Word文档创建前不到8个小时。

3.png

上图的图表展现了在每次测试迭代期间,测试人员修改Excel文档时检测率的升降趋势。检测率的这些变化,能够让测试人员清楚的了解这些对文件的修改是否能避免被检出。在分析他们的测试活动时,我们将每次迭代中执行的更改数量(基于GitHub文件的修改记录,主要关注插入和删除的行数)与检测率进行比较,从而确定改动的多少是否与检测率的升降有关。结果表明,迭代1和迭代2之间只有很小的变动,然而检测率却发生了大幅下降。而迭代3和迭代4都进行了大量改动,检测率分别小幅下降和大幅增加。

站在一个较高的层面上来看,改动的代码量对于测试者来说并不重要,他们真正关注的是这一改动是否能够带来检测率的降低,以及是否能够提供有关如何规避检测的有用信息。其中的一个例子是,在迭代2中他们删除了使用“wscript”运行已经交付的VBScript的代码行,从而将检测率从16降低到6。最终,测试人员使用了这些测试迭代过程中获得的知识,创建了一个更难检测且能够成功实现攻击的交付文档。

三、测试过程中的迭代分析

我们对该恶意组织测试过程中的每次迭代版本进行了分析。我们进行分析的大致思路如下:

1、文件变化:比较两个文件的SHA256哈希值,以确定恶意组织对文件是否做出了更改。

2、文件名变化:比较两个文件的文件名。

3、时间差:在每个文件的元数据中,找到“已修改”的时间戳,并比较其时间差。

4、检测率变化:比较两个文件的检测率,从而发现测试迭代之间的变化对整体检测所产生的影响。

在每个迭代版本的分析中,重点关注针对交付文档中宏所做的更改。在比较文件代码差异的截图中也能直观的看到这些变化,红色背景的代码是删除的部分,绿色背景的代码是添加部分。

3.1 迭代0

在测试过程中,我们所监测到的第一个文档似乎不是由恶意组织创建的原始文档。因为,该Excel中包含名为__SRP_0的流,该流中似乎包含交付文档早先版本中的工件。__SRP_0流中包含工件,特别是一系列Base 64编码的字符串。将这些字符串进行解码之后,我们发现它几乎就是名为“AppPool.ps1”的Boundupdater PowerShell Payload脚本,该脚本在此前OilRig对中东政府发动攻击时,作为恶意软件((7cbad6b3f505a199d6766a86b41ed23786bbb99dab9cae6c18936afdc2512f00))的交付脚本。我们将__SRP_0中解码后的Base 64字符串与之前分析过的AppPool.ps1文件进行了比较,二者完全相同(包括withyourface[.]com这一C&C域名),唯一的区别是换行符和空格。

4.png

当我们分析这个特定的样本时,我们注意到测试人员已经对PowerShell Payload进行了修改。与之前由宏写入AppPool.ps1文件不同,在这里,恶意Excel文档中的宏只负责写入AppPool.vbs,随后将使用“wscript”运行宏。随后,VBScript负责将AppPool.ps1写入到系统之中。这一点,与我们之前分析的Word文档有很大不同。

此外,测试人员似乎彻底从样本中删除了Boundupdater Payload。AppPool.vbs脚本使用一个名为“mysrc”的空变量,该变量将用于存储Base 64编码后的Payload,该内容将会被解码,随后保存到AppPool.ps1文件中。

如前所述,我们认为这一测试活动先于我们此前分析的Word交付文档。此外,我们还认为这不是恶意组织进行的第一轮测试,因为__SRP_0流中存在的Boundupdater工具表明,测试人员在此之前已经创建了一个包含Payload的恶意文档。测试人员可能对PowerShell Payload进行了测试,并将其删除,从而防止交付文档中的宏被检测。

3.2 迭代1

文件变化:

· 6f522b1be1f2b6642c292bb3fb57f523ebedeb04f0d18efa2a283e79f3689a9f

· 9b6ebc44e4452d8c53c21b0fdd8311bac10dc672309b67d7f214fbd2a08962ce

文件名变化:XLS-withyourface.xls -> XLS-withyourface.xls

时间差:1分钟41秒

检测率变化:22 -> 16

在此迭代中,测试人员进行了一次简单的更改,其中包括删除字符串“powershell.exe”,使其不被写入到AppPool.vbs文件中。这一更改实质上会破坏安装过程,因为VBScript将无法再正确运行AppPool.ps1。测试人员之所以进行这样的更改,是想要测试删去该字符串是否能有效降低检测率。下图没有直观展现出“powershell.exe”字符串的变化,但仔细观察第24行Shell0的位置,可以在左侧看到“powershell.exe -exec bypass”(红色)和“-exec bypass”(绿色)字样。

5.png

3.3 迭代2

1、文件变化:

· 9b6ebc44e4452d8c53c21b0fdd8311bac10dc672309b67d7f214fbd2a08962ce

· a5bec7573b743932329b794042f38571dd91731ae50757317bdaf9e820ec8d5e

2、文件名变化:XLS-withyourface.xls -> XLS-withyourface.xls

3、时间差:6分钟57秒

4、检测率变化:16 –> 6

在这一迭代中,测试人员删除了运行AppPool.vbs脚本的代码,如下图所示。

6.png

3.4 迭代3

1、文件变化:

· a5bec7573b743932329b794042f38571dd91731ae50757317bdaf9e820ec8d5e

· a5bec7573b743932329b794042f38571dd91731ae50757317bdaf9e820ec8d5e

2、文件名变化:XLS-withyourface.xls -> XLS-withyourface.xls

3、时间差:10小时46分钟1秒

4、检测率变化:6 -> 4

在此迭代中,测试人员对宏进行了相当重要的更改。首先,他们加入了一行代码,在创建C:\ProgramData\WindowsAppPool文件夹后、将AppPool.vbs写入该文件夹前将睡眠10秒,这一变动可以在下图的第12行看到。此外,还将Base 64编码后的Boudupdater PowerShell Payload添加到DDDD变量中,而不是先前版本所看到的VBScript。在这里,Base 64编码后的Boudupdater与迭代0中提及的第一个测试样本缓存__SRP_0流中的Boudupdater完全相同。最后,这一版本还删除了设置Shell0变量以包含“wscript.shell”对象的相应行,这一行理论上是用来运行VBScript。

添加了Sleep代码:

7.png

对用于存储VBScript的变量进行更改:

8.png

删除了“wscript.shell”对象:

9.png

3.5 迭代4

1、文件变化:

· 6719e80361950cdb10c4a4fcccc389c2a26eaab761c202870353fe65e8f954a3

· 056ffc13a7a2e944f7ab8c99ea9a2d1b429bbafa280eb2043678aa8b259999aa

2、文件名变化:XLS-withyourface.xls -> sss.xls

3、时间差:1小时33分钟24秒

4、检测率变化:4 -> 18

在此迭代中,测试人员使用上一次迭代中替换的VBScript,来替换宏中Base 64编码后的PowerShell脚本。此外,还删除了一些实例化的Scripting.FileSystemObject以及Wscript.Shell对象(参见下图的第17-18行)。

下图展现了已经将VBScript:

10.png

在这一版本中,似乎测试人员将VBScript重新引入宏,并且略做修改。存储在DDDD变量中的VBScript有两处进行了修改,目的是模糊脚本中两个字符串的出现方式,特别是“powershell”(下图中第24行)和“cmd.exe”(下图中第25行)。这两个字符串使用每个字符的十六进制值,一次只构造一个字符,并且连接在一起。例如:“powershell”字符被替换成如下内容

Chr(CLng("&H70")) & Chr(CLng("&H6f")) & Chr(CLng("&H77")) &
Chr(CLng("&H65")) & Chr(CLng("&H72")) & Chr(CLng("&H73")) &
Chr(CLng("&H68")) & Chr(CLng("&H65")) & Chr(CLng("&H6c")) &
Chr(CLng("&H6c"))

测试人员还添加了一行(下图中第29行),使用内置的Shell函数,利用wscript应用程序运行“AppPool.vbs”脚本。在调用Shell函数时,使用了“vbHide”标志,该函数会在隐藏窗口中运行该命令。

下图展现了字符串混淆和内置Shell函数的使用:

11.png

3.6 迭代5

1、文件变化:

· 056ffc13a7a2e944f7ab8c99ea9a2d1b429bbafa280eb2043678aa8b259999aa

· 216ffed357b5fe4d71848c79f77716e9ecebdd010666cdb9edaadf7a8c9ec576

2、文件名变化:sss.xls -> sss.xls

3、时间差:5分钟6秒

4、检测率变化:18 -> 5

在这一迭代版本中,测试人员使用他们在上一次迭代中引入的wscript,替换对内置Shell函数的调用,该函数运行“AppPool.vbs”脚本。下图展示了新迭代用空行替换了第29行的代码。

12.png

3.7 迭代6

1、文件变化:

· 216ffed357b5fe4d71848c79f77716e9ecebdd010666cdb9edaadf7a8c9ec576

· 687027d966667780ab786635b0d4274b651f27d99717c5ba95e139e94ef114c3

2、文件名变化:sss.xls -> sss.xls

3、时间差:5分钟14秒

4、检测率变化:5 -> 17

在此迭代中,测试人员重新引入对先前迭代中删除的内置Shell函数的调用。但是,这里没有包含运行命令,省略了使用wscript运行“AppPool.vbs”脚本的字符串。下图展示了对Shell函数的调用,使用了空白的命令参数。这样一来,反病毒软件的检测率明显提升,由此说明普遍的检测机制并不是针对命令本身,而是检测对于内置Shell函数的泛型调用。

13.png

3.8 迭代7

1、文件变化:

· 687027d966667780ab786635b0d4274b651f27d99717c5ba95e139e94ef114c3

· 364e2884251c151a29071a5975ca0076405a8cc2bab8da3e784491632ec07f56

2、文件名变化:sss.xls -> sss.xls

3、时间差:10分钟

4、检测率变化:17 -> 9

在此迭代中,重新引入命令wscript来运行“AppPool.vbs”脚本,以调用内置的Shell函数。但是,这次测试人员使用了“vbNormalFocus”标志来替代“vbHide”标志,在可见的命令提示符窗口中运行该命令。这一更改,使检测率降低了8,这表明多个反病毒软件都将Shell函数中使用“vbHide”标志视为恶意。

14.png

3.9 迭代8

1、文件变化:

· 364e2884251c151a29071a5975ca0076405a8cc2bab8da3e784491632ec07f56

· 66d678b097a2245f60f3d95bb608f3958aa0f5f19ca7e5853f38ea79885b9633

2、文件名变化:sss.xls -> sss – Copy.xls

3、时间差:4天21小时24分钟31秒

4、检测率变化:9 -> 11

这一版本的迭代,在上一版本提交的5天之后才进行提交。在此期间,恶意组织可能进行了新一轮的测试活动。然而,这个新文件的文件名为“sss – Copy.xls”,而前一个文件名为“sss.xls”。这表明。测试人员可能复制了上一次迭代中生成的文件,并以此为基础进行本次迭代测试。

在此迭代中,对宏的多个部分进行了更改。首先,删除了宏中休眠10秒的代码行,这一行是在迭代3中首次引入的。这一版本的迭代中删除了这行代码,并使用“Application.Wait”函数来实现10秒的休眠。

下图展示了休眠功能的删除。

15.png

另一个修改是Shell函数内部运行的命令,使用了与此前迭代中相同的字符串混淆技术,对字符串“wscript”进行了混淆,将该字符串替换为连接在一起的十六进制形式的字符组合。

表示“wscript”的字符组合如下:

Chr(CLng(“&H77”)) & Chr(CLng(“&H73”)) & Chr(CLng(“&H63”)) & Chr(CLng(“&H72”)) & Chr(CLng(“&H69”)) & Chr(CLng(“&H70”)) & Chr(CLng(“&H74”)) & Chr(CLng(“&H20”))

下图展现了针对命令和修改后的变量名进行字符串混淆的具体过程:

16.png

3.10 迭代9

1、文件变化:

· 66d678b097a2245f60f3d95bb608f3958aa0f5f19ca7e5853f38ea79885b9633

· 70ff20f2e5c7fd90c6bfe92e28df585f711ee4090fc7669b3a9bd024c4e11702

2、文件名变化:sss – Copy.xls -> sss – Copy.xls

3、时间差:1分钟57秒

4、检测率变化:11 -> 7

在最后一次测试中,删除了用于调用Shell函数的整行代码,该函数用于调用包含混淆的“wscript”字符串的“AppPool.vbs”脚本。下图展示了测试人员直接删除了这一整行,并没有用任何代码替换它,这表明宏永远不会运行它保存到系统的VBScript文件。

17.png

四、恶意组织在测试中学到了什么

在开发过程中,恶意组织不断尝试、学习并调整他们的代码。我们看到,攻击者多次将文件提交到测试平台,并且多次更改并重新提交,从而确保反病毒引擎只检测他们修改的特定内容。OilRig恶意组织利用在这一测试过程中学到的知识,来创建一个可以逃避检测的交付文档,从而增加攻击成功的几率。

在对所有文档进行差异比较之后,我们的研究人员分析了每一次版本迭代,不仅掌握了恶意组织进行测试的方法,还掌握了恶意组织在努力降低检测率过程中所学到的内容。我们可以做出如下总结:

1、反病毒软件对于宏病毒的检测,取决于宏中是否包含内置Shell函数的泛型调用,这一调用用于运行已经交付的VBScript。

2、使用Shell函数在隐藏窗口(vbHide标志)中运行命令的检测率,比使用可见窗口(vbNormalFocus标志)的检测率要高。

3、如果在VBScript中包含宏将写入系统的字符串“powershell”,将会导致检测率的升高。

4、如果对“powershell”字符串以及“wscript”字符串(位于使用Shell函数运行的命令中)进行字符串模糊处理,将会导致检测率的下降。

五、我们学到了什么

借助这一样本,我们学会了一些恶意软件规避检测的方式,这将有助于我们更好的了解恶意软件所使用的技术和能力,从而更好的提升安全防护机制。

我们目前掌握关于OilRig恶意组织的信息如下:

1、对恶意文档进行快速迭代,并不断上传文件到反病毒平台进行测试,文件创建时间和测试时间平均间隔为33秒。

2、在测试过程中,不关注宏的原始功能是否能够保持,因为测试人员在多次迭代中的修改将使得宏无法再按照预期工作。

3、更改用于运行交付的VBScript的函数,特别是在检测率较高的情况下,他们将Shell对象修改为内置的Shell函数。

4、添加休眠函数,以试图逃避沙箱检测,特别是在这种情况下使用了Wait桉树。

5、掌握一个成熟的字符串混淆技术,使用十六进制形式的字符组合替换一个字符串,这些字符组合将连在一起。

在进行此分析后,我们认为OilRig恶意组织将恶意Excel文档中的宏作为恶意Word文档中宏的基础。我们认为,攻击者利用如下特点,创建了实际攻击中使用的交付文档:

1、使用了相同的字符串混淆技术,通过连接在一起的多个十六进制值来代表字符串,这种技术被发现用于测试Excel文档和实际攻击的Word文档中。

2、使用字符串混淆技术,对嵌入式VBScript中的“powershell”和“cmd.exe”字符串进行了模糊处理,该技术已经在测试迭代4中进行了测试。

3、利用字符串混淆技术,对内置Shell函数运行的命令进行模糊处理,该技术已经在测试迭代8中进行了测试。

似乎OilRig恶意组织修改了测试活动中所使用的宏,并利用它来创建武器化的交付文档。其改动包括:添加名为“HGHG”的函数,将混淆的Boundupdater PowerShell脚本保存到文件中。恶意组织还将用于存储VBScript的变量“DDDD”使用在武器化文档中,并将变量命名为“A”。最后,恶意组织从宏中删除了“AA”函数,因为该函数用于显示一个隐藏的表格,其中包含诱导内容,该函数特定于Excel中使用,无法在Word中使用。

六、总结

攻击者和恶意组织通常会利用文件和URL扫描服务来帮助其开发和修改恶意软件,从而逃避检测。目前,我们已经熟悉了OilRig开发技术的变化,深入了解他们的方法,拥有了一个更为完整的恶意组织画像。

只有仔细研究恶意组织的开发方式,研究人员才能拥有更大几率来深刻理解他们所使用的工具、策略和代码。我们将最终恶意活动所使用的软件与开发过程中的恶意软件进行比较,从而能了解每次恶意软件的迭代都进行了哪些调整和修改。此外,见证恶意软件自身的特定功能变化,并尝试在新旧功能之间建立关联,这也有助于我们的分析与理解。通过比较测试期间创建的文件的时间戳,并将其与实际攻击中的文件进行对比,还能够深入了解恶意组织的工作效率。我们已经确定,OilRig恶意组织在攻击前6天开始了他们的测试活动,并在发动正式攻击前8小时结束了测试。

简介

Bot开发人员从开发物联网(IoT)恶意软件中吸取了教训,并将重点转向商用Linux服务器。与许多物联网设备一样,互联网上也存在大量未修补漏洞的Linux服务器,攻击者向可以找到的每个存在漏洞的服务器发起攻击,并大规模滥用。ASERT在自己的蜜罐网络中监控Hadoop YARN漏洞的利用,并发现了一个熟悉但令人惊讶的载荷 – Mirai。这些版本的Mirai与原版非常相像,但可以在Linux服务器上运行,而不是功能不足的物联网设备。虽然ASERT之前已经发布了Windows Mirai的观察报告,但这是我们第一次在野外看到非IoT Mirai。

要点

· 针对Linux服务器的Mirai开发者不再需要为奇怪的架构定制恶意软件,他们假定目标使用x86。

· 攻击者不是依靠bot进行传播,而是转向自己发布漏洞利用。少量攻击者正在使用自定义工具来利用Hadoop YARN漏洞并分发Linux恶意软件。

· 即使Hadoop YARN服务器没有运行telnet服务,Mirai bot也会尝试通过telnet暴力破解默认凭证。

· 数据中心的Linux服务器比家庭网络上的物联网设备的带宽更大,从而使它们成为效率更高的DDoS not。少数资源充足的Linux服务器会产生与大量物联网僵尸网络相匹敌的攻击。

细节

Hadoop YARN漏洞很简单,命令注入漏洞允许攻击者执行任意shell命令。上个月,Radware发现此漏洞被用于安装DemonBot DDoS僵尸程序。在很多方面,这个漏洞与我们在物联网设备中看到的其他漏洞类似。例如,CVE-2014-8361(Realtek的UPnP SOAP接口中的一个漏洞)也可以通过向特殊端口发送具有特定参数的HTTP请求来诱导shell命令的执行来利用。Realtek漏洞用于分发Mirai变体。

我们的全球蜜罐网络一直在跟踪Hadoop YARN漏洞利用的情况。如图1所示,每天有成千上万次的漏洞利用尝试。

图1:Hadoop YARN漏洞尝试次数

令人惊讶的是,如此多的漏洞利用尝试来自极少数的独特源IP。图2显示了在同一时间段内进行Hadoop YARN漏洞利用的唯一源IP地址的数量。

图2:唯一来源的数量

如果查看图3中利用这些漏洞的前5个User-Agent,我们可以看到攻击者使用Python请求库来发送HTTP载荷。

图3:排名前5的 User-Agent

我们看到的所有恶意软件有效载荷都没有以蠕虫方式传播使用Hadoop YARN漏洞,并且没有一个有效载荷是用Python编写,据此我们推测少数攻击者通过手动扫描互联网以利用此漏洞。

我们已经看到的漏洞利用有效载荷,如图4所示,所有功能都相同 – 从URL下载恶意软件二进制文件并执行。

图4:典型的漏洞利用

不同之处在于漏洞利用中分发的恶意软件。在11月份,我们已经看到了225个独特的二进制文件。其中152个,超过一半的二进制文件只由一个源地址提供。我们检查的样本中至少有十几个很明显是Mirai的变体。

图5:“VPNFilter” Mirai 变体

让我们关注一个自称为“VPNFilter”的Mirai变体(2bcca8ac8d4d80f6740ef14d521284c0,图5),尽管它与更高级的物联网bot无关。在我们的蜜罐网络中,看到这个漏洞11月16日来自两个源地址:185.244.25.241和104.248.170.199。此bot的命令和控制站点与托管二进制文件的IP地址相同。

这个特殊的变体与IoT Mirai的重要区别在于它只提供了x86版本的bit。 IoT Mirai变种将根据潜在受害者的实际情况来提供适合其CPU架构的可执行文件 –  x86,x64,ARM,MIPS,ARC等。此版本bot只针对在商用x86 Linux服务器上运行的Hadoop YARN服务。

在沙箱中运行“VPNFilter”变体时,我们立即注意到它仍然尝试通过telnet暴力重置出厂默认用户名和密码。如果成功找到易受攻击的设备,它不会直接在受害者上安装恶意软件,而是向服务器报告IP地址、用户名和密码,攻击者可以自动安装僵尸程序。

总结

Mirai不再仅仅针对物联网设备。虽然向物联网和Linux服务器分发Mirai的技术类似,但攻击单一x86 Linux服务器相比物联网设备更容易。我们看到数量有限的源地址不断扫描Hadoop YARN漏,可能表明此行动是一小群攻击者的工作。他们的目标很明确,就是将恶意软件安装在尽可能多的设备上。一旦获得立足点,在Linux服务器上的Mirai就像IoT机器人一样,开始使用telnet暴力破解用户名和密码。不同之处在于僵尸网络中的小型设备之中潜伏着功能齐全的Linux服务器。