概述近日，有reddit用户反映，拥有100k+安装的Google Chrome扩展程序 User-Agent Switcher存在恶意点赞facebook/instagram照片的行为。 除User-Agent Switcher以外，还有另外两个扩展程序也被标记为恶意的，并从Chrome商店中下架。 目前已知受影响的扩展程序以及版本： User-Agent Switcher 2.0.0.9 2.0.1.0 Nano Defender 15.0.0.206 Nano Adblocker 疑为 1.0.0.154 目前，Google已将相关扩展程序从 Web Store 中删除。Firefox插件则不受影响。 影响范围Chrome Webstore显示的各扩展程序的安装量如下： User-Agent Switcher: 100 000+ Nano Defender:…
背景Hacking Team 是为数不多在全球范围内出售网络武器的公司之一，从 2003 年成立以来便因向政府机构出售监视工具而臭名昭著。 2015年7月，Hacking Team 遭受黑客攻击，其 400GB 的内部数据，包括曾经保密的客户列表，内部邮件以及工程化的漏洞和后门代码被全部公开。随后，有关 hacking team 的活动突然销声匿迹。 2018年3月 ESET 的报告指出：Hacking Team 一直处于活跃状态，其后门版本也一直保持着稳定的更新。 2018年12月360高级威胁应对团队的报告披露了 Hacking Team 使用 Flash 0day 的”毒针”行动。 2019年11月360高级威胁应对团队的报告披露了 APT-C-34 组织使用 Hacking Team 网络武器进行攻击。 2020年4月360诺亚实验室的报告披露出 Hacking Team 新的攻击活动。 以上信息表明，Hacking Team 依旧处于活跃状态，…
在此前跟进CVE-2020-0796的过程中，我们发现公开代码的利用稳定性比较差，经常出现蓝屏的情况，通过研究，本文分享了CVE-2020-0796漏洞实现在realworld使用过程中遇到的一些问题以及相应的解决方法。 Takeaways我们分析了exp导致系统蓝屏的原因，并尝试对其进行了改进；相对于重构前exp，重构后的exp执行效率与稳定性都有显著提高；关于漏洞原理阐述，Ricerca Security在2020年4月份发布的一篇blog中已非常清晰，有兴趣的读者可以移步阅读，本文不再赘述。初步选择和测试公开exp可用性测试环境：VMWare，Win10专业版1903，2G内存，2处理核心 为了测试和说明方便，我们可以将exp的执行分为3个阶段： 漏洞利用到内核shellcode代码开始执行内核shellcode代码执行用户层shellcode执行根据实际情况，我们测试了chompie1337和ZecOps的漏洞利用代码。根据各自项目的说明文档，两份代码初步情况如下： ZecOpsZecOps的利用代码是在单个处理器的目标计算机系统上测试的；在后续的实际测试中，发现其代码对多处理器系统的支持不足，虽然在测试环境中进行了多次测试中，系统不会产生BSOD，但漏洞无法成功利用（即exp执行第一阶段失败）。 chompie1337chompie1337的代码在漏洞利用阶段则表现得十分稳定，但在内核shellcode执行时会造成系统崩溃。 因此，我们决定将chompie1337的利用代码作为主要测试对象。 内核shellcode问题定位我们在win10 1903中测试了chompie1337的exp代码，绝大部分的崩溃原因是在漏洞利用成功后、内核shellcode代码执行（即exp执行的第二阶段）时，申请用户空间内存的API zwAllocateVirtualMemory调用失败。在我们的多次测试中，崩溃现场主要包括以下两种： Crash_A backtraceCrash_B…
F5 Networks官方在7月1日公布了BIG-IP系统的TMUI接口中存在一个严重的远程代码执行漏洞（CVE-2020-5902）。利用此漏洞的攻击层出不穷，我们对这些事件进行了总结，以期对近日来的事件进行完整阐述。 漏洞简述该漏洞允许未授权的远程攻击者通过向漏洞页面发送特殊构造的数据包，在系统上执行任意系统命令、创建或删除文件、禁用服务等。 根据360安全大脑测绘云(QUAKE网络空间测绘系统)数据，截至2020年7月10日，全球至少有80000台存在此漏洞的资产，具体分布如下图所示： CVE-2020-5902漏洞分布通过对该漏洞活跃情况研判，得到其全球态势和漏洞生命周期： 从360安全大脑的全网视野里可以看出，在7月2日漏洞利用细节公布，7月4日开始传播后，7月6日全网受影响设备居于峰值，此后由于缓解措施发布实施，漏洞活跃状态逐步回落。 时间线2020-7-1：F5 Networks官方发布通告，缓解措施为在配置文件中添加以下内容：<LocationMatch ".*\.\.;.*"> Redirect 404 / </LocationMatch>2020-7-2：漏洞相关技术细节公布2020-7-3：漏洞扫描流量被监测到2020-7-5：@x4ce在推特上公开披露漏洞利用PoC2020-7-6：metasploit集成exp2020-7-7：研究人员发现F5官方发布的缓解措施能够被绕过；而监测发现，在推特发布6小时前，野外即有bypass的利用payload；同日，F5官方更新通告，修复后的配置内容为：<LocationMatch…
3月23日，微软公司发布了一份编号ADV200006的紧急漏洞通告，通告表示有在野攻击行动使用了位于Adobe Type Manager Library中的两个远程代码执行0Day漏洞，由于漏洞严重，发布该通告指导用户在补丁发布前规避风险。 4月15日的补丁日中，微软发布了针对此风险通告的补丁外，还对一个字体库漏洞CVE-2020-0687进行修复，诺亚实验室第一时间对补丁进行了比对分析，并确认了漏洞的利用性，两个漏洞均属于高危远程代码执行漏洞，由于CVE-2020-0938/CVE2020-1020已有安全团队验证并形成POC，本文将会着笔于vincss报告的CVE-2020-0687进行简要技术分析。 根本原因漏洞产生于字体处理库fontsub.dll的ReadTableIntoStructure中，由于循环逻辑中读取数据赋值检查不严格，在数据拷贝到目的堆后超过原申请的堆内存大小，形成堆溢出漏洞。 补丁细节分析通过补丁比对，我们很快确认了问题函数 __int64 __fastcall ReadTableIntoStructure(__int16 *a1, _WORD *a2, unsigned __int16 *a3) 通过前后差异判别，可以看出补丁代码将while循环的一个返回条件放到了循环入口处，其目的是为了防止当变量v5中的变量大于v3[4]中保存的的变量时，会执行一次while循环的第一句赋值代码。 故原始漏洞代码中存在判断不严谨的情况，将会导致ReadGeneric中读取到的4字节数据，放入至一个结构体数组中： 通过跟踪v3和v5返回上层调用函数可知，v3在上层函数MergeEblcEbdtTables中，是作为一个从新申请的堆内存的大小参数进行传递的；而v5则是作为ReadTableIntoStructure中第三个参数，可以理解为一个类似Table大小的变量。 而此处的堆空间大小则是由v92来决定，根据跟踪的情况，…
背景HackingTeam是全世界知名的网络军火商，在2015年遭遇攻击后近400G的内部数据和工程化武器几乎被完全公开，在此之后一家名为Tablem的公司并购了"被破产"的HackingTeam，此后HackingTeam陷入沉寂。 360安全大脑在2018年"刻赤海峡"事件中捕获的一起针对俄罗斯的APT事件中，使用的后门疑似来自HackingTeam，在2019年一起影响中亚地区的APT事件中，同样发现了HackingTeam后门的身影，诸多信息表明HackingTeam依旧在全球恶意网络活动中活跃。 2020年1月，360安全大脑下诺亚实验室在日常的狩猎运营工作中，发现了一例高度模块化的RAT，并认定为HackingTeam RCS框架中的Soldier木马程序，在3月前夕，我们再次关联到该次活动使用Soldier的前置片段，并将其认定为HackingTeam RCS框架中的Scout木马程序，自此形成较为完整的活动拼图。 攻击流程及特点从目前掌握的情况，本次HackingTeam RCS重现主要分为两个阶段 第一阶段 通过伪装网络电视软件LiveNetTV，释放RCS框架中的Scout木马，进行系统基础信息收集，并具有一定ANTI机制第二阶段 通过伪装Java程序并执行RCS框架中Soldier木马，进行系统信息获取并窃取浏览器密码和cookie，窃取Facebook，Gmail，Twitter等信息两个阶段的木马程序均使用了VMProtect加壳，通过历史HackingTeam泄露资料研究可知，两个木马具备创建共享内存空间联动的特性，这也是二者经常伴生出现的原因。 在本次捕获的样本中，我们发现样本具备以下特点： 使用了此前未知的有效证书签名与此前泄露的RCS相比，现活跃的攻击样本均做了一定程度订制和变种活动集中出现于2019年10月-2020年3月依旧使用VMP壳保护Unpack VMP此处我们用到两种脱壳VMP的方式，一种用于提取关键信息，另一种则是进行完全脱壳。 方法一 通过运行样本，当样本开始解包自身时可以进行内存dump，一些关键信息可以在这个阶段dump拿到，…
背景在恶意网络活动研究领域，针对个人终端的攻击Windows总是独占鳌头，但近年来MacOS的终端数上涨，让很多攻击团伙也开始聚焦针对MacOS的恶意软件利用，但即便针对MacOS的攻击，对手也倾向使用python/shell类脚本，恶意文档扩展一类的控制方案或入口利用。而AppleScript这一MacOS的内置脚本语言至今已沿用接近27年，却在安全研究领域鲜有人提及。我们在日常的研究工作中对基于AppleScript的恶意软件利用技术进行了适当总结和狩猎回顾，并提出一个依托AppleScript独有特性的攻击方法。 AppleScript特点AppleScript是MacOS的特有脚本语言，甚至在iOS或者iPadOS上都不能使用，且作为一门脚本语言AppleScript花里胡哨的"自然语言"古怪设计思路也常被开发者诟病，AppleScript试图以humanized的方式书写但又强硬规定了语法，导致代码及其冗长且背离自然语言书写思路。 如在当前目录下创建文件test，AppleScript基础语法书写应为： tell application "Finder" set selection to make new file at (get insertion location) with properties {name:"test"} end tell此外，由于AppleScript底层需要通过事件管理器(Apple Event Manager)进行构造和发送Apple事件，他的执行效率也极低，所以在实际场景中无论是用户还是管理员，都极少使用AppleScript。 从AppleScript调用Apple Event…