近日，360手机卫士发布了《2016年安卓恶意软件专题报告》，就2016年恶意软件总体态势、流行木马、开发技术、传播技术、移动黑产进行了研究探讨。

这两天阿里云经典网络安全性的讨论得到了IT圈广泛关注，对此事还未或略有耳闻的吃瓜群众，不妨随扒爷一起全程围观一下吧。

阿里云不同租户不隔离？

2月24日，微博@一乐在微博中提到了阿里云的安全隐患：

Cloudflare搞了个大事，这里顺便也提醒大家。千万不要单独评估一个安全漏洞的危害，只要它能干不应该干的事情，就要警惕。 我们前几天也上了一课，一个比特币挖矿程序利用Redis本地提权的漏洞，把我们一个小集群的缓存机器都搞掉了。虽然漏洞刚出的时候，大家还都在说跟自己没关系，我们的Redis都限制内网访问，但是架不住安全组设置错误，这些机器暴露给了其他阿里云用户，也就是说主要某个阿里云邻居用户被黑，他都可以通过扫描进入我们的系统。 问题发现的也很奇葩，这个病毒程序太霸道，它会直接把受影响的Redis权限改掉，导致前端无法访问，这触发了我们的主从自动切换，然后被管理员发现了。他要是偷偷运行，估计还可以潜伏好久（我可不是给他出主意[二哈]） 大家要是感兴趣，这里有个人写过一个类似遭遇 

知名技术博主@左耳朵耗子在其微博下进行了简单的回复，不晓引发了热议。

直到2月26日，@左耳朵耗子 又针对这个话题发表文章《科普一下公有云的网络》质疑阿里云的安全策略。 文中称，阿里云的内网使用的是经典网络，在这种环境下，不同的租户是可以互通的，这会带来严重的安全隐患。为了应对这一问题，阿里云采用了安全组。安全组是AWS的Security Group概念，通过制定规则来达到类似防火墙的效果。但安全组存在诸多问题，这些问题让设置变得异常困难和繁琐：

1. 新主机加入或变更后需要频繁更改设置（如IP地址） 2. 如果将安全组配置到网段上，则会涉及IP地址段的分配管理 3. 在公有云上不可能分配专用IP

因此，左耳朵耗子提出，应该使用VPC进行管理。VPC是一种解决内网多租户互相隔离的方案，全称叫VirtualPrivate Cloud。

“一般来说，VPC是通过hack底层的虚拟化系统完成的，也就是说，在Hypervisor层虚拟交换机中实现了一个类似路由器的东西——通过一个用户自定义的虚拟IP和实际IP的关系做packetforwarding或是overlay的机制等。Anyway，实现细节不重要。”

左耳朵耗子希望阿里云能够默认部署VPC：VPC这个事应该是默认为用户开启的，是在VPC上配置安全组，而不是提供VPC和安全组两套可以相互独立网络方案。

安全组究竟安不安全？

处于风暴中心的阿里云自然不能置身事外，阿里云官方发表了一篇有关“安全组功能”的技术博客，并援引2月20日发布的一篇文章，引众多IT圈微博转载。 2月27日，@左耳朵耗子发表文章《关于阿里云经典网络的问题》表示收到了阿里云官方的回复，点燃了新一波热议。 作为曾在阿里巴巴任职的技术专家，左耳朵耗子称，他2013年在阿里商家业务部做聚石塔期间发现阿里云的内网多个租户居然是通的。最后的方案是给聚石塔的租户设置安全组。由于设置的很死，但用户又需要在自己的集群中相互通信，所以，当时的解决方案是，需要用户申请，才开3000-3100的端口范围。

注：当时的阿里云是不让用户编辑安全组的，内网是全互通的。如果我没有记错，到了我快要离开阿里的时候（2015年）才让用户可以编辑安全组的。

也就是说，按左耳朵耗子的说法，在早期阶段阿里云的内网是存在一段时间能够互通的。 另外，经典网络本身存在安全问题：

1）这种网络结构从设计上不可避免的把多个租户放在同一个内网网段！所以，物理层面上来说就是通的！ 2）动用安全组来隔离用户是一种相当复杂的事，复杂的东西就容易出错！因为，网络隔离的手段只有配置安全组。所谓安全组就是iptables的配置！而且是在每台宿组机上配置，大家可以想一下，一台机器可以配置多少这样的规则？这是有限制的！而且是在管理上的很复杂的，不但对用户来说很复杂，我相信对阿里云的开发和运维来说也非常复杂！

因此，即便使用了安全组，也无法避免地存在问题。 左耳朵耗子称，使用nmap就能在内网扫到大量主机，可以 ping 通，可以telnet，甚至可以登录，这为黑客留下非常方便的入口：

1） 我本来在公网上扫端口，我分不清哪些IP地址是服务器的，现在好了，上阿里云内网里扫一下，100%都是服务器，效率提高很多啊。 2）另外，经典网络的IP还都是连续的，这太TMD的爽了！ 3）我再打个 route 命令看一下路由表，原来还有好多别的内网网段哦。 4）最爽的是，在内网发起攻击，带宽好快啊，而且可能还没安全监控哦…… 5）要是运气好，说不定我还能搞定阿里云的控制系统……

我是说，在座的各位……

昨日，前阿里云高级安全专家、知名云安全研究者 @安全_云舒愤然表示——你们都错了！《租户隔离科普文，阿里云经典网络问题续》： 先说结论：从2009年至今，阿里云不同租户一直默认是隔离的。

我的安全哲学是在安全这个专业领域用户是sb（这里的sb用户也包括资深的开发人员在内，区别在于小白知道自己不懂，资深的开发人员则以为自己懂），安全得由我这种专业人士保护。所以可以看见，我设置的策略是不人性化的，是死规矩是一刀切。在安全领域，用户的资产也得由我说了算。

文中提及为了用户的方便，原本相互隔离的租户在2015年之后允许用户设置允许一切IP访问自己的安全组，现在的策略是合适的，但却不能保证绝对的安全。这也就是为什么有些网友觉得自己找到了漏洞所在。 接下来云舒对耗子的第一篇文章表达了强烈的不满，他认为耗子作为一个知名技术博主，说出“anyway实现细节不重要”这样的话是有失水准的。就算不提细节，耗子“VPC是通过hack底层的虚拟化系统完成的”的说法也欠考虑的，明显耗子在这场辩论中已完全落败。 而关于VPC，云舒给出了自己的理解。

首先云计算VM是讲究漂移的，有因为故障发生的漂移，也有因为用户主动发起的跨区域的漂移。漂移过程中要求保证业务尽量不中断，则需要保证vm的ip地址、mac地址不变，这就意味着需要一个巨大的二层网络，甚至是跨区域的。而二层网络越大，交换设备的cam表压力也越大，甚至爆掉，arp之类的广播风暴也越严重，所以要把vm层面的一些东西对物理交换机屏蔽掉，分层处理。 其次，VPC给用户一种很好的体验，延续传统网络时代自己组网自己规划的那种感觉，当然也可以更灵活的设计自己想要的东西，甚至形成service chain。

随后云舒对于耗子的第二篇文章中的论点进行了“解答”和“挑战”。

“当时有一个很大的安全问题是——阿里云的内网多个租户居然是通的。”

不知道耗子知道不知道，因为一些我不方便说的原因，聚石塔是由淘宝维护负责的电商云，其实是属于同一个租户的！同一个租户，当然是互通的啊。我不知道耗子是知道那个原因不说，因为知道我不可能说，还是真不知道——按说你当时也P9，应该知道吧。不说这个，但是至少，聚石塔所有的vm是属于同一个租户的，你也不知道么？那你负责聚石塔是怎么负责的？也是“anyway，细节不重要”？

也许事情到这里也差不多告一段落了，耗子昨日下午在微博也做出了言和回应——初衷也是好的，只是没有深入研究，还不小心踢到了钢板……

*本文作者：安全深扒，转载请注明来自Freebuf.COM

经火绒安全实验室截获、分析、追踪并验证，当用户从百度旗下的http://www.skycn.net/和 http://soft.hao123.com/这两个网站下载任何软件时，都会被植入恶意代码。

本月初我们曾报道过去年12月卡巴斯基实验室的顶级安全研究人员Ruslan Stoyanov与两名FSB（俄罗斯联邦安全局）官员：Sergei Mikhailov和Dmitry Dokuchayev因涉嫌叛国罪遭俄罗斯当局逮捕的事件。如今此事进一步发酵——这件事可能与一名俄罗斯商人在7年前提交的指控有关，且另有一名前FSB官员Georgy Fomchenkov也因此事遭到逮捕。

7年前的陈年往事

路透社援引知情人士的消息称，7年前发起指控的这名商人名为Pavel Vrublevsky——他是欧洲著名的信用卡支付服务公司ChronoPay的创始人。他曾在2010年向FSB等重要政府部门提供了若干人（包括至少一名FSB官员在内）涉嫌叛国罪的证据。 证据显示，文首提到遭到逮捕的几个人涉嫌曾向Verisign等美国公司出售机密信息，这些公司则将机密信息与美国情报机构共享。

实际上Verisign公司有个iDefence团队，该团队会向包括私营企业，政府机构和情报部门在内的客户提供网络犯罪的相关档案。不过，这家公司表示其中的研究并不包含任何机密信息。该公司前分析师Kimberly Zenz表示：“Vrublevsky所说的事情完全没有发生过。” Verisign副总裁，Joshua Ray也否认了这一说法。他拒绝就Stoyanov专门展开评论，但他表示公司以非保密渠道获取信息，同时不会在提供给政府或企业的报告中包含任何涉及国家机密的内容。

Vrublevsky说：2010年我们给FSB和俄罗斯的其他重要机构提供了至少一名FSB雇员，以及其他多人叛国的相关证据。

为何现在才提起？

有趣的是，Vrublevsky在提交这些证据后不久，即因涉嫌向商业对手发动网络攻击而遭到逮捕（现已获假释）。他本人否认对于他的这一指控，并归咎于Mikhailov和Stoyanov。据他所说，Mikhailov曾在2010年向Stoyanov泄漏了自己的商业机密。此外另有消息显示，Mikhailov之前曾在私人部门任职顾问，他也是籍此接触到了包括Verisign在内的西方公司。 至今俄罗斯当局还没有就此事发表任何评论，但有网络安全专家认为此举可视为克里姆林宫的强硬表态：俄安全专家与美国政府间任何形式的合作都在禁止之列。在这桩指控沉寂7年之后，俄政府选择在去年年末采取措施无疑是耐人寻味的——当时美国指责俄罗斯背后操纵黑客影响总统大选，此举可否视为对美国政府的反制我们尚不得而知。

另据路透社消息，网上有公开的资料显示：莫斯科地区军事法院已于本月15日驳回了Stoyanov和Fomchenkov的上诉。随后Mikhailov的上诉也在17日遭到驳回。

*参考来源：SecurityAffairs，FB小编cxt编译，转载请注明来自FreeBuf.COM

对于Windows 7和8.1，很容易利用Powershell并通过反射PE注入绕过应用程序白名单，但Windows 10就不同了。Windows 10中激活了Powershell受限语言模式，再加上AppLockr，上述方法似乎不再行得通。当然，我们可以将PowerShellEmpire作为攻击框架，并采用HTML应用程序攻击向量，但在Powershell受限语言模式为启用状态下，这种攻击颇费周折。那到底还能否采用反射PE注入攻击方法呢？让我们一探究竟。

HTA攻击

我们先简单说一下HTML应用程序作为攻击向量和Powershell Empire的工作原理。在启动Powershell Empire并创建一个监听器之后，我们创建一个HTA stager，并简单地设置监听器名称和输出文件：

我们把它放在一个可以从受害者机器访问的网络服务器上。 HTA文件包含以下代码：

由于HTA文件在浏览器沙箱外部打开，因此允许ActiveX对象执行。其只是用base64编码的命令（拉取另一个更大的Empire代理并在内存中执行）启动Powershell。受害者浏览链接并看到：

然后看到：

单击运行后发生回调，Empire在受害者机器上启动一个新代理：

AppLocker和Powershell受限语言

本文讨论的是在AppLocker和“Powershell受限语言模式”为启用状态下如何通过HTA文件获得Empire代理。在此之前先强调一下攻击者获得的结果。如果尝试在计算机上运行一个恶意软件，比如名为Malware.exe的恶意软件，将得到以下提示：

如果尝试在Powershell中使用.NET组件运行命令，如下所示其被阻止：

同样，如果像之前一样使用HTA尝试启动相同的攻击，其也将被停止：

因受限语言模式，我们从Powershell获得了相同的错误。 我们现在必须围绕这一点想办法。

不用Powershell的Powershell

对不使用Powershell.exe运行Powershell命令我们已有研究。想法是，Powershell.exe其实只是.NET程序集System.Management.Automation的一个解释器，完全有可能编写我们自己的解释器来调用该程序集。我们面临的问题是应用程序白名单的存在，因此我们需要以某种方式启动我们的自定义解释器。此外，这个解释器必须运行在一些进程空间，最好把它注入一个现有的进程，而不是创建其自己的进程（代理在使用时其必须保持运行）。我们不妨利用PowerPick项目，其中包含一个名为ReflectivePick的模块，这是一个C ++应用程序，被编译为单个DLL并从System.Management.Automation调用自定义运行空间，这样一来就允许执行Powershell命令。 为了开始测试，我们使用一条简单的命令编译ReflectivePick DLL，以便在运行空间中执行，如下所示：

我们然后通过使用来自加入白名单的文件夹的rundll32运行ReflectivePick DLL，获得如下结果：

Powershell命令被执行，更重要的是，虽然AppLocker将Powershell.exe锁定为受限语言，但运行空间的语言模式是FullLanguage。 我们用此更新了argument参数，以包含之前的base64编码的Powershell Empire stager，以及一个解码例程，因为我们不再使用编码参数。我们还将解码的命令记录到了一个文件中，以便能够进行调试。完整命令如下所示：

从命令行运行更新后的DLL可在文本文件中显示解码的Empire stager：

一个Empire代理被启动：

转到其他进程 到目前为止，我们是通过rundll32.exe创建一个新进程，并将DLL加载到其中。这不是一个可行的方法，因为DLL不在白名单中，还有，我们是在创建一个新进程。为了避免这两个问题，我们可以使用Powershell脚本Invoke-ReflectivePEInjection将ReflectivePickDLL加载到另一个进程中。这样无疑会产生在受限语言模式为启用状态下启动Powershell脚本的问题，不过我们稍后再讨论这一点。Invoke-ReflectivePEInjection为我们的用例使用两个参数，即作为字节数组的DLL和要注入的进程的进程ID（PID）。我们想将ReflectivePick DLL注入到explorer进程，所以我们先找到其PID：

然后我们获得ReflectivePick DLL的内容——字节数组，如下所示：

Invoke-ReflectivePEInjection脚本作为一个函数编写，因此我们首先导入模块，确保将其放在白名单文件夹中，以暂时避免“受限语言”。然后使用PID和DLL调用它：

我们注意到，Empire stager创建了调试文本文件，如下所示，我们成功地让代理从explorer进程内运行：

让我们将用于从DLL获取PID和字节的命令嵌入到Powershell脚本中，并调用该函数，这样我们就不需要先导入它。这通过在脚本文件的末尾添加以下内容来实现：

然后我们运行没有任何参数的Powershell脚本文件：

然后我们获得我们的Empire代理回调：

我们仍然面临着ReflectivePick DLL是磁盘上的外部文件的问题，所以我们将它嵌入到Powershell脚本中。这是通过将DLL字节编码为base64来实现的，如下所示：

然后将编码文件的内容复制到Powershell脚本中并分配一个变量：

我们不是从磁盘获取文件的字节，而是通过base64解码变量的内容获得：

我们再一次收到Empire代理：

从InstallUtil.exe调用Powershell

原则上，我们还没有实现任何东西，因为我们现在使用Powershell将DLL加载到调用Powershell的内存中，“受限语言模式”仍将阻止它。但是，我们已经确定，Powershell执行发生在现有进程而不是新进程内。因“受限语言模式”的阻止，我们确实需要克服调用Invoke-ReflectivePEInjection的问题。为实现这一点，我们使用InstallUtil.exe运行自定义EXE，这会创建一个非托管Powershell运行空间。 我们将代码修改为只执行一个预定义的命令，开始只是一些虚设代码，目的是确保其按如下所示有效：

将此编译为名为Bypass.exe的EXE并尝试在受害者机器上运行，其明显被AppLocker阻止。

然后我们运行InstallUtil.exe，以使用命令行参数执行卸载方法：

从上面的图片我们可以看到，命令被执行，且自定义Powershell运行空间没有启用“受限语言模式”。从这里，我们将测试命令更改为整个Invoke-ReflectivePEInjection脚本以及我们之前添加的嵌入式DLL和启动命令。我们面临另一个困难，Powershell在新行或分号处打断命令。Invoke-ReflectivePEInjection是用新行创建的，但是将它嵌入到C＃项目中需要它在一行中，为此我们首先对整个文件进行base64编码，如下所示：

然后将其与base64解码例程一起嵌入到EXE中：

我们还将解码的Powershell命令写入test5.txt文件，以确保其可以正常工作。对更新的代码运行InstallUtil.exe可以得到：

Invoke-ReflectivePEInjection脚本被解码并保留其新行，此外，Empirestager也被写入其调试文件。Empire代理成功启动，如下所示：

调用InstallUtil.exe 到目前为止，我们成功将Powershell受限语言模式的绕过转换为了EXE文件的AppLocker绕过。虽然我们也成功地执行了EXE，但我们仍然需要一些方法调用InstallUtil.exe和下载EXE到磁盘。为实现这一点，我们将使用Regsvr32.exe。 Regsvr32.exe可以用来执行scriptlet——其可以包含任意JavaScript。所以，开始我们先欺骗，仍然让EXE在磁盘上，但从Regsvr32.exe运行的脚本片段执行InstallUtil.exe：

运行后显示如下：

这给了我们一个Empire代理回调：

现在你可能想知道为什么要使用Regsvr32.exe启动InstallUtil.exe，因为这样并没有真正获得什么。不过，关键是Regsvr32.exe也可以用来下载EXE到磁盘，此外，脚本片段文件也可以存储在web服务器上，如下图所示：

下载文件 为测试通过Regsvr32.exe下载，我们base64编码了一些虚设文本：

然后，我们使用另一种滥用certutil.exe以解码并将其写入磁盘的方法。base64编码文本放在BEGIN CERTIFICATE和END CERTIFICATE标签中，以给certutil.exe提供正确的格式。然后我们将base64编码文本写入文件，然后使用certutil.exe解码，如下所示：

按以下方式执行：

文件的内容明显被解码。现在是时候进行一些微调了，现在我们将提供的EXE嵌入InstallUtil.exe。因此，我们在另一台计算机上使用certutil.exe对其进行编码：

为了让base64能覆盖多行，我们在每一行末尾添加一个反斜线：

在测试时，事实证明不能在一个脚本片段中嵌入整个编码的EXE。所以我们将其分成了4部分，并插入到单独的脚本片段中。每个脚本片段获取嵌入的Base64代码，并将其写入一个文件，如下所示：

执行显示正在写入的文件：

我们然后创建第五个脚本片段文件，该文件获取磁盘上的四个文件，并将这四个文件组合为一个文本文件，并继续调用certutil.exe来解码它并将EXE写入磁盘：

按如下方式运行所有的脚本片段：

产生一个Empire代理回调：

要压缩这个I，通过添加以下内容将对四个从脚本片段的调用嵌入主脚本片段：

再次运行时给出Empire代理回调：

回到HTA 现在我们终于有了一个我们可以调用的单一命令，这最终可以创建我们的Empire代理。要启动该命令，我们可以将其嵌入一个HTA文件（就像AppLocker不存在一样）：

指向此文件的链接按通常的方式在钓鱼邮件中发送，最终在用户浏览器中的结果是：

运行后便给予了我们期望的Empire代理——即使AppLocker和“Powershell受限语言模式”为启用状态：

结论 总而言之，该方法提供了一个来自Web服务器的HTA，其调用Regsvr32.exe来执行五个脚本片段，这五个脚本片段下载并嵌入base64编码EXE，对它进行解码并将其写入磁盘。然后执行InstallUtil.exe绕过AppLocker，并依次执行EXE的卸载方法。EXE包含一个base64编码Powershell脚本，该脚本在由EXE创建的自定义Powershell运行空间中被解码并执行。Powershell脚本包含一个嵌入的base64编码DLL，DLL被Powershell脚本解码并反射加载到explorer进程中。反射加载的DLL包含一个嵌入式base64编码的Powershell脚本，该脚本在explorer进程中的自定义Powershell运行空间内被解码并执行。Powershell脚本是Powershell Empire代理的正常stager。 要使该攻击有效，以下二进制文件需要被AppLocker列入白名单：

MSHTA.EXE REGSVR32.EXE CERTUTIL.EXE INSTALLUTIL.EXE

如果使用的是默认AppLocker规则或所有Microsoft签名的二进制文件是受信任的，则这四个文件都会被列入白名单。该攻击可绕过AppLocker、“Powershell受限语言模式”及AMSI，但不能绕过ScriptBlock Logging，因此可以被检测到，如下所示：

单独代码部分的代码见GitHub。 参考网站：https://improsec.com/blog//babushka-dolls-or-how-to-bypass-application-whitelisting-and-constrained-powershell