All Posts

电车的高速之行

上周末回了一趟老家,高速来回行驶了800多公里。所以我很想结合这一次的高速的经验分享一下电车的高速形式经验,或许也能帮助一些鹏友解答电车在高速形式上面的问题。我的车之前的文章也提到过,小鹏 P7,长续航智尊版,选配了 NGP 辅助驾驶功能。当然,这篇文章的经验也主要是我本身这次的高速之行的感受,并不一定适用于所有的情况。 续航,谁先倒下? 新能源车的续航一直是很多人对于其望而却步的主要原因,电车的续航缩水一直为人所诟病。我这辆车的官方续航标准是 NEDC 586公里,当然这个续航一般是达不到的,实际用车的话,一般都是使用 WLTP 标准。充满电,长续航版本的里程显示是504公里(WLTP标准)。如果按照120的限速跑,开空调,开音乐,驾驶能耗是16多一点。基本上500公里的续航应该能跑到将近450公里左右。这对于我回家来说,基本上够用了。 说实话,我是真实体验到人的续航和车的续航,就我而言,基本都是我先倒下。基本上开了两个小时左右,我就已经觉得很累了。所以,停下来,休息一下吃个饭什么的,还是比较合适的。只不过去程的时候我那个服务器使用的桩功率有一点低,电流只有69A,一般在城市里基本上都是200A左右。当时,也没有换桩,不知道是不是仅仅只是那一个桩的问题。不过返程的时候另外一个服务区的充电桩就还可以,电流差不多有 120 多,基本上就够用了.当然,这是在高速不是特别拥堵的情况下,我的确也没有跑过那种特别极端的情况下,那种情况可能会是另外一种情景。 辅助驾驶好不好用 这段时间辅助驾驶闹得沸沸扬扬。其实,我是觉得现在很多媒体把辅助驾驶和自动驾驶混淆了。目前国内已经上市的车,是没有车已经达到了自动驾驶的级别。自动驾驶的级别一般划分L1-L5 5个级别,小鹏宣称自己是L2.5,我们暂且也认为其是L2级别。所以,一定要分清辅助驾驶和自动驾驶,目前人还是要时刻保持关注,随时做好接管的准备,千万不要做那种毫无意义的尝试,在危险边缘疯狂试探。 小鹏的 NGP 目前支持在封闭路段使用,包括城市高架和高速。在拥堵的路段,NGP 的使用体验不是很好,因为它反应比较慢,刹车偏急,起步偏慢,所以拥堵高架体验一般。但是高速上是非常适合 NGP 使用的,800 多公里的路程基本上差不多600多是通过NGP行驶的,这极大减轻了驾驶负担。NGP 基本上在自适应巡航,跟车方面都做的比较完善。因为 NGP 结合了高精度地图,所以可以完美地通过高精度地图来辅助驾驶。所以这个方案和特斯拉的视觉方案不同,这两种方案也是各有千秋。不过依赖于高精度地图的缺点就是有的地图高精度的缺失,辅助驾驶的降级不是很完美。NGP 不能很完美地降级到 LCC。当然,其实在我看来人为接管率并没有很大影响。另外一点,如果长时间使用辅助驾驶的话也会比较疲劳,所以有时接管开一下也是蛮好的。 NGP 最值得诟病的就是双车道的高速超车逻辑。经常遇到的情况就是在左车道行驶,如果前车行驶速度变慢,就会向右变道超车。但是这种情形一般都是因为右边不远处有一辆慢速行驶的火车。如果变道到右边的车道,马上就会被那辆火车堵住,然后左边就会一直有车经过,这种情形就比较尴尬了。所以,一般双车道的超车行为都会被我立马扼杀在摇篮中。 综合来说,这次的高速之行对于我来说总体体验还是不错的。如果满分10分的话,应该可以打个7.5分。当然,这一切的体验都是基于这次的高速之行得出的。小鹏 P7 目前来看还是一个综合素质比较出色的新能源汽车,如果有朋友感兴趣的话可以使用我的试驾链接试驾。 https://events.xiaopeng.com/r18f95.html?token=2cf68377

富文本场景下的 XSS

富文本编辑器是一个常见的业务场景,一般来说,通过富文本编辑器编辑的内容最终也会 html 的形式来进行渲染,比如 VUE,一般就会使用 v-html 来承载富文本编辑的内容。因为文本内容需要通过 html 来进行渲染,那么显然普通的编码转义不适合这种场景了,因为这样最终的呈现的效果就不是我们想要的了。针对于这种场景,显然过滤是唯一的解决方案了,不过过滤其实可以在后端和前端都是可以做的,后端做的话,一般是在数据存储在数据库之前。前端做的话,则是在数据最终在页面渲染之前做过滤。 前端的过滤方案,可以尝试使用开源的 [js-xss](https://github.com/leizongmin/js-xss)。先介绍一下这个库的使用方法,这个库可以在 nodejs 中使用,同样也可以在浏览中直接引入使用。 // nodejs 中使用 var xss = require("xss"); var html = xss('<script>alert("xss");</script>'); console.log(html); // 浏览器中使用 <script src="https://rawgit.com/leizongmin/js-xss/master/dist/xss.js"></script> <script> // apply function filterXSS in the same way var html = filterXSS('<script>alert("xss");</scr' + "ipt>"); alert(html); </script> 一般在 vue 的项目中,通过 webpack 也可以直接通过 CommonJS 的方式引入,与 nodejs 的引入方式基本一致。值得注意的一个问题是,默认情况下会去禁用 style 属性,这样会导致富文本的样式展示异常,需要禁用 css 过滤或者使用白名单的方式来进行过滤。 const xssFilter = new xss.FilterXSS({ css: false }); html = xssFilter.

米哈游内推

微信扫描投递即可 社招 校招

提车二月记--小鹏P7

P7 提车也有两个月了,行驶基本上也有 2000 多公里。关于提车的介绍,可以参考我之前的那篇文章。经过这两个月的形势,我不仅加深了对 P7 的了解,同时自己的驾驶技术也提高了。下面,就自己这两个月的行驶感受做进一步总结。 驾驶体验 P7 的驾驶体验总的来说对于我个人来说还是非常优秀的,不过因为可能我也没有开过其它的什么车,发言权不是特别大。不过根据我爸的说法感觉还是不错的,方向盘和刹车都不错,不过刹车在某些情况下会变得很硬,不过可能与 P7 的 AEB 有关系。提到 AEB 还想提一次经历,有一次前面车突然急刹车,然后当时行驶速度比较快,我踩了几脚刹车,最后一脚重踩,可以明显感到 AEB 给刹车加了一把,虽然我自己踩应该也是不会追尾的,不过 AEB 感觉是上了一道双保险。有遇到一些鹏友吐槽 AEB 的,不过目前对于我来说,AEB 没有给我带来任何困扰,反而感觉是多了一份保障。 说完优点,就说说驾驶体验有点不太好的地方。P7 的悬挂实在是太硬了,稍微有点颠簸路面就感觉非常颠,这一点的体验是比较差的。还有就是感觉低速行驶有一些不太平的路面,左摇右摆特别的明显。 外观颜值 P7 的颜值可能是很多人买 P7 的重要原因之一。P7 的轿跑风格,那个大溜背,真的人见人爱。特别是和其它的车放在一起的时候,明显可以感觉 P7 的风格别树一帜,让人越看越喜欢。而且感觉上完牌照的 P7 比没上牌照的要好看多了。关于上牌体验,总体来说小鹏的体验还可以,我是自己在网上选号的,推荐网上选,比较方便,我是在电脑上通过网站选号的。虽然 P7 的车长有4.88米,但是由于其大溜背,所以后排空间也是捉襟见肘,不过因为平常后排也不怎么坐人,所以也还好,家里人感觉也还可以。后备箱的话,虽然是比较深的,但是高速不是很高,所以容量也是比较一般的。虽然前备箱也有,但是空间就要小得多的,而且开启也不是很方便,只能通过机械掰两下主驾旁边的开关,使用频率也非常低。 车机 小鹏的车机可以说的上是目前国内数一数二的,如果自信点,现在说是第一也不是很过分哈。车即真的非常流畅,没有任何延迟。而且车机上面的有个小优点,就是车机上的车模型的 UI 会和车的实际状态联动,比如车机上的车模型会显示你的实际号牌,并且还会同步汽车的车门开关状态以及车灯的状态,何小鹏不愧是做 UI 的。车机上面的功能划分也比较有逻辑性,会分为几个大类,切换不同的大类基本可以找到自己需要的功能。另外有一点可能有很多鹏友不知道,就是屏幕下拉会有一些功能的快捷设置,这点和手机还是比较类似的,毕竟小鹏的车机体验已经非常接近智能手机了。 不过有一点值得说的是,车机的优秀反而衬托了 APP 的薄弱。目前 APP 的功能实在是太少了,很多车机上可以看到的信息,在 APP 上却看不到。还有历史行程信息,感觉这个对于用户还是非常重要的,但是 APP 里面却看不到,甚至看不到仪表盘上面的那些行驶公里数,就只有一个总的历史公里数。感觉,这方面还是需要改进很多。不过,在车机上打开小 P 头像可以看到上一天的形式记录以及能耗方面,信息还是比较齐全的。 辅助驾驶 目前小鹏的辅助驾驶可以算得上是第一梯队,当然目前华为的极狐还没有正式量产上市。小鹏的 NGP (按导航辅助驾驶)目前的体验已经是非常好的,得益于高德高精度地图的加持,在很多地区体验可能比特斯拉的辅助驾驶体验还要好,当然特斯拉的视觉方案也很强。其实很多人对于汽车的自动辅助驾驶有一点误解,很多人以为自动辅助驾驶其实就是一个功能,其实不然。辅助驾驶里面是包含了很多项的,汽车也是通过视觉感知、雷达感知来获取大量的信息,来提升辅助驾驶能够获取的信息。现在新的辅助驾驶技术已经用上了激光雷达,这也是提高了感知的精度和范围。其实目前已有的方案并没有挖掘充分,P7 其实还是有不少算力冗余的。所以依靠现有的硬件条件,未来做到城市道路的自动辅助驾驶也不是不可能的。目前的辅助驾驶其实是一项项进阶形成的,比如车道偏离预警会在车辆偏离车道线的时候产生告警,不过在高速上有遇到过一些之前的车道线没有清除干净,导致告警并且勒安全带,感觉有点不太好。另外一些盲区安全辅助,在开门的时候有帮助,提醒你身边可能有一些突然冒出来的电动车。其它的就是 ACC, LCC, ALC 了,这些内容都是在智享版本上包含的,如果仅仅只是在城市中行驶,可能已经足够了。不过强大的 NGP 可以帮你在高架以及高速上基本上可以实现 0 干预行车,尤其高速上面的使用体验非常优秀。之前去嘉兴的高速上就使用了 NGP,那天雨下得特别大,视线非常不好,使用 NGP 反而感觉更好一些。即使在那么大雨的情况下,NGP 的使用都非常正常,体验也非常好。尤其是这次 2.

技术宅的第一辆车--小鹏P7

写这篇文章的时候,刚刚从撞车的后悔与悲痛中慢慢恢复而来,也借此机会分享一下这段时间买车的经历吧。前段时间突然勾起来想买车的欲望,就一直想买车。因为是在上海,因为牌照的关系,加上我个人的偏好,所以我只考虑新能源汽车,我对新兴事物的接受度还是非常高的。之前其实主要考虑的就是特斯拉,不过特斯拉由于续航问题和外观原因,感觉和小鹏比还是有一些差距,当然也是因为我的一个买了小鹏朋友的安利。 买车 买车之前,几乎所有人都反对我买小鹏或者新能源车。我买车没有试驾过其它的车,只试驾了小鹏 P7,当天就订了车。值得吐槽的是,我的销售除了订车当天催我订车之外,几乎没有给过我任何实质性的建议,基本什么问题问她几乎也都是白搭,给我的承诺也没有做到(这个销售的专业能力应该是非常差的)。当然这个是销售的个人原因,和小鹏也没有太大关系的。因为贷款的原因,配车还延迟了一个礼拜,另外值得吐槽的就是中行的贷款,后面还挺麻烦的,提车当天还不能放款,后面我还是选择了全款,白白浪费了一个多礼拜,当然这里面的弯弯绕绕销售也都没有和我说过。 好像大多数销售在推荐车的时候都会推荐智享版,不过因为我本人和自动驾驶也颇有渊源。当初研究生的时候,一开始的时候搞得就是自动驾驶的方向,当时全世界搞这个的人都不多,当时因为没人交流就上也没有硬件去做,当时读论文真的很苦逼,后来为了毕业后面还是换了方向发论文,但也算是和自动驾驶结下了不解之缘。所以,纠结了一下,最后还是选择了长续航版本的智尊版本。 差不多等了一个多月,终于等到提车的日子。提车还是在军工路,特地请假去提车。整体的提车过程还是比较顺利的,基本就是看下车,因为是新车基本上也没有特别好验的。相对来说,交付比我的销售要靠谱很多。后面就是付钱,办理保险和临牌就可以。不得不说,小鹏整体的造型还是不错的,轿跑风格也是比较喜欢。整个车的风格也是越看越喜欢,提车基本就是送了一个小花篮以及水杯和雨伞,其它的没什么礼物了。 驾驶体验 我本身也是个新手,虽然驾照拿了很多年,但几乎没怎么开过车。小鹏车开起来还是比较简单和舒适的,对于新手来说还是比较友好。小鹏的车机和语音来说,在当前新能源车或者是汽车行业,也都算是数一数二的。语音交互体验比较好,基本上大多数的功能都可以通过语音交互来进行控制,当然语音有时候也有拉跨的时候,不过总体来说还是比较可以的。另外,就是这个车的空间,虽然车长有 4.88 米,但空间感觉还是一般,不过这也很轿跑造型有关系,为了外观,不可避免的牺牲了一些空间。 小鹏最亮眼的当属于 NGP了,这也是我当初为什么还是选了智尊版的原因(智尊版还需要额外2万的软件费用),因为这真的是小鹏的长处。后面也看了很多评测,感觉真的很香,感觉至少和特斯拉比是强一点的,不过如果和华为相比可能还是要差一些。毕竟目前NGP只能在高速或者高架路上开启。后来,我也体验过一两次,在高架上使用 NGP 实在是太香了,尤其是对于我这种新手来说。NGP的驾驶方式优秀,变道技术也比我好很多,所以高架上用NGP开非常的省心,这也让我庆幸当初的选择没有错。下面的这个视频也是我有天晚上全程使用 NGP 行驶的。 https://www.bilibili.com/video/BV1wN411f7hs/ 不幸的事 福兮祸之所伏,祸兮福之所倚。快乐的事没过多久,不幸就随之而来。节前的最后一天,在一个十字路口调头,撞到别人车上,结果小鹏也受了比较大的损伤。当时整个人比较懵的,当天就花了很多时间处理保险和事故,然后亲自跟着拖车把车又送回了提车的地方维修。因为配件的原因,维修可能还需要比较长的时间。这几天一直处在深深地自责和后悔中,都怪自己当时不够小心,但世上没有后悔药了,一切也不能挽回。希望自己吃一堑长一智,以后一定要小心小心再小心。 你好,小P!以后我们好好相处吧。 如果对小鹏感兴趣的话,可以走我的试驾邀请链接试驾。

多平台的敏感信息检测工具-GShark

GShark has beem maintained for alomost two years as an open source sensitive infomation detection tool. This tool is utilized in my own company and sparetime, multi information sensi GShark 作为一款开源的敏感信息监测工具其实差不多维护也有两年多的时间。这款产品其实笔者在自己的公司或者平常都在使用,也通过这个工具发现多多起内部的信息泄露事件以及外部的一些的信息泄露事件。其实这种类似的开源工具数不胜数,大家的核心功能其实就是监控 Github 上面的信息,但是笔者要想把这种产品做得更好一点,就要从功能性、易用性角度来做进一步拓展。最近,对 GShark 做了较大的重构,前后端都完成了比较大的重构,之前老的版本也有写过文章介绍,所以关于这个工具的起源就不多介绍了,主要对这次重构和新的架构做介绍。 架构 目前 GShark 已经是一个前后端分离的项目,之前因为前端通过后端模板直接渲染的,所以在前端的功能性以及美观性都会差很多。新的重构是基于 gin-vue-admin,技术栈是后端通过 gin 实现,前端通过 vue-elemment 来实现。 所以架构主要就分为前端和后端两个部分,而后端则分为 web 服务以及敏感信息的扫描服务。新的架构具有以下特点: 细粒度的权限控制,更好的安全性,包括菜单的权限设置以及 API 的权限设置 丰富的前端功能,CRUD 更简单 搜索源和之前保持一致,支持 github, gitlab 以及 searchcode 部署 之前就有想使用 GShark 的同学来和我反映,其实之前的编译就已经很简单了。但是因为有些人不太熟悉 go,所以觉得编译还是有一些问题。这一次,笔者专门写了一个脚本来发布三个操作系统下的工具包,所以直接使用即可,开箱即用,即使你不安装 go 也无所谓。 rm -rf ./releases/* cd web npm run build cd .

JavaScript能否修改Referer请求头

正如题目,本文的也很直白,主要就是围绕这个问题展开。JavaScript 能否修改 Referer 请求头?现在 JavaScript 的能力越来越强大,JavaScript 似乎无所不能,修改一个小小的 Referer 请求头似乎看来不在话下(本文讨论的 JavaScript 仅限于在浏览器中执行,不包括 Nodejs)。 其实不然,在 web 浏览器中,绝大多数浏览器都禁止了 JavaScript 直接去操作 Referfer 请求头,当然这一方面也是出于安全方面的考虑。当然除了 Referer 请求头之外,还有其它请求头也被禁止通过 JavaScript 操作。 Referer 请求头属于 Forbidden header,这种请求头无法通过程序来修改,浏览器客户端一般会禁止这种行为。以 Proxy- 和 Sec- 开头的请求头都属于 Fobidden header name,还包括以下这些请求头: Accept-Charset Accept-Encoding Access-Control-Request-Headers Access-Control-Request-Method Connection Content-Length Cookie Cookie2 Date DNT Expect Feature-Policy Host Keep-Alive Origin Proxy- Sec- Referer TE Trailer Transfer-Encoding Upgrade Via 可以通过一段简单的 demo 来进行验证。可以通过 Chrome 的开发者工具来进行验证,创建一个 xhr 请求,并且尝试来设置请求头。 可以看出,如果设置 content-type,浏览器没有阻止,但是如果设置 Referer 的话,浏览器则不允许,提示 Refused to set unsafe header "Referer"。

微软开源对于 Solorigate 活动捕获的开源 CodeQL 查询

原文:微软 open sources CodeQL queries used to hunt for Solorigate activity 译者:madneal welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me LICENSE: MIT Solorigate 攻击的一个关键方面是供应链攻击,这使攻击者可以修改 SolarWinds Orion 产品中的二进制文件。这些经过修改的二进制文件是通过以前合法的更新渠道分发的,并允许攻击者远程执行恶意活动,例如窃取凭据,提权和横向移动,以窃取敏感信息。该事件提醒组织不仅要考虑是否准备好应对复杂的攻击,还需要考虑自己代码库的弹性。 微软坚信以透明的方式进行领导并与社区共享情报,从而改善整个行业的安全实践和状况。在此博客中,我们将分享审查代码库的过程,重点介绍一种特定的技术:使用 CodeQL 查询来大规模分析我们的源代码,并排除存在代码级别的危威胁情报(IoCs)和与 Solorigate 相关的代码模式。我们正在将本次本调查中使用的 CodeQL 查询开源,以便其他组织可以执行类似的分析。请注意,我们在此博客中介绍的查询仅可用于查找与 Solorigate 植入程序中的源代码具有相似之处的源代码,无论是在语法元素(名称,字面量等)还是功能上。两者可能在良性代码中同时发生,因此所有发现都需要进行审查以确定它们是否可行。此外,不能保证恶意行为者在其他操作中被约束为相同的功能或编码风格,因此这些查询可能无法检测到与在 Solorigate 植入代码中看到的策略有明显差异的其他植入代码。这些应被视为只针对攻击审计技术的一部分。 长期以来,微软一直采用完整性控制来验证分发给我们的服务器和客户的最终编译二进制文件在开发和发布周期的任何时候都没有被恶意修改。例如,我们验证编译器生成的源文件哈希是否与原始源文件匹配。尽管如此,在微软,我们仍然秉承 “assume breach” 的理念,该理念告诉我们,无论我们的安全实践多么勤奋和广泛,潜在的对手都可以同样地聪明并拥有大量资源。作为 Solorigate 调查的一部分,我们使用了自动和手动技术来验证我们的源代码,构建环境以及生产二进制文件和环境的完整性。 微软在 Solorigate 调查期间的贡献反映了我们对 Githubification of InfoSec 中描述的基于社区的共享愿景的承诺。为了保持我们对防御者知识的了解并加快社区对复杂威胁的响应的愿景,微软团队在此次事件期间公开透明地共享了威胁情报,详细的攻击分析和 MITER ATT&CK 技术,高级狩猎查询,事件响应指南以及风险评估工作簿。微软鼓励其他安全组织开源自己的威胁知识和防御者技术来共享 “Githubification” 愿景,以加速防御者的洞察力和分析。如前所述,我们已在 https://aka.ms/solorigate 上收集了全面的资源,以提供有关攻击的技术详细信息,威胁情报和产品指南。作为微软全面调查 Solorigate 的一部分,我们检查了自己的环境。正如我们之前所分享的那样,这些调查发现有少量内部帐户存在活动,并且一些帐户已用于查看源代码,但是我们没有发现任何对源代码,构建基础结构,已编译的二进制文件或生产环境进行任何修改的证据。

白名单,被谁饶过了?

本文首发于安全客平台,https://www.anquanke.com/post/id/228916 起因 近期在内网发现了有个应用之前的开放重定向漏洞的绕过,通过这个漏洞绕过,我又发现了 apache/dubbo 的一个有意思的问题以及 URL 相关的话题。 之前,给内网应用提交过一个开放重定向漏洞,后面又发现这个开放重定向漏洞存在一个绕过方法。假设一个恶意 URL 为 https://evailhost#@whitehost,那么这个恶意链接依然可以实现跳转。开发说他们已经做过了白名单限制,理论上应该不存在被绕过的可能了。那么我就去看了下代码,对于重定向地址进行验证的代码类似如下。 public static String checkUrlSafety(String url, List<String> domainWhitelistSuffix, String domainWhitelist) { Url url2 = null; try { url2 = UrlUtils.parseURL(url, null); } catch (Exception e) { } String host = url2.getHost(); if (verifyDomain(host, domainWhitelistSuffix, domainWhitelist)) { return url; } else { ... } } private static boolean verifyDomain(String host, List<String> domainWhitelistSuffix, String domainWhitelist) { return domainWhitelist.contains(host) || verifyDomainSuffix(host, domainWhitelistSuffix): } apache/dubbo 的问题 核心代码其实主要就是上面两个函数,主要是通过 verifyDomain 方法来进行白名单的过滤,那么问题就很有可能出现在这里。这里,值得注意的是,host 是通过 UrlUtils.

火眼红队工具遭窃

原文:Unauthorized Access of FireEye Red Team Tools 译者:madneal welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me LICENSE: MIT 概述 一个由国家支撑的顶尖的竞争者窃取了火眼的红队工具。 因为我们认为竞争者已经拥有这些工具,并且我们不知道攻击者是否打算自己使用被盗的工具还是公开披露它们,所以火眼在此博客中发布了数百种对策,以使安全社区能够保护自己免受这些工具的攻击。我们已将防御策略整合到我们的火眼产品中,并与合作伙伴,政府机构共享了这些策略,以显着限制不良行为者利用红队工具的能力。 您可以在这火眼的 GitHub 仓库中找到策略列表。 红队工具和技术 红队是一组经过授权和组织的安全专家,模仿潜在的对手针对企业安全状况的攻击或利用能力。我们的红队的目的是通过演示成功攻击的影响并向防御者(即,蓝队)展示防御方法,以改善企业网络安全。过去15年来,我们一直在为全球客户进行红队评估。截至目前,我们已经建立了一套脚本,工具,扫描器和技术,以帮助改善客户的安全状况。不幸的是,这些工具被顶尖攻击者窃取。 被盗工具的范围从用于自动化侦察的简单脚本到类似于 CobaltStrike和 Metasploit 等公开可用技术的整个框架。许多红队工具已经发布给社区,并已分发到我们的开源虚拟机 CommandoVM 中。 其中一些工具是公开可用的工具,经过修改可以逃避基本的安全检测机制。其它的工具和框架是我们红队内部定制开发。 没有零日漏洞或者未知技术 攻击者窃取的红队工具不包含零日漏洞。这些工具采用了世界各地其他红队所使用的众所周知且有据可查的方法。尽管我们认为这种盗窃不会大大提高攻击者的整体能力,但火眼会尽一切努力防止这种情况的发生。 请务必注意,火眼尚未看到任何对手散布或使用这些工具,我们将继续与安全合作伙伴一起监视任何此类活动。 有益于社区的检测 为了使社区能够检测到这些工具,我们正在发布防御策略,以帮助组织识别这些工具(如果它们在野出现)。为了应对我们的红队工具的盗窃,我们针对 OpenIOC,Yara,Snort 和 ClamAV 等公开可用技术发布了数百种对策。 可在此处找到火眼 GitHub 仓库上的对策列表。我们将发布检测,并将随着我们开发新的或改进现有检测的主机,网络和基于文件的指标的重叠对策而继续更新公共存储库。 此外,我们在 GitHub 页面上发布了需要解决的 CVE 列表,以限制红队工具的有效性。 火眼产品能够帮助客户免于这些工具攻击 火眼的各个团队都在努力制定对策,以保护我们的客户和广大社区。 我们已将这些对策整合到我们的产品中,并与我们的合作伙伴(包括国土安全部)共享了这些对策,这些合作伙伴已将这些对策纳入其产品中,从而为社区提供了广泛的覆盖范围。 有关可用的检测签名的更多信息,可以在GitHub仓库中找到。