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

来源:知乎 | 发布: | 发布时间:2014-04-17,星期四 | 阅读:1,141

【余弦的回答(348票)】:

最后更新时间:2014/4/13 21:47。来自知道创宇ZoomEye团队的特殊视角!

写在前面

一切权威看爆这次漏洞的官方动态:Heartbleed Bug(Heartbleed这个命名不错,载入史册)。

@知道创宇安全研究团队 实测可以Dump出淘宝、微信、陌陌、某些支付类接口、某些比特币平台、12306等各大使用OpenSSL服务的一些内存信息,里面有用户等的敏感内容(有些重要网站含明文密码)。

OpenSSL这次被比做「心脏出血」。可见影响。一个安全套件不安全了……

下图的科普可以让大众明白这个OpenSSL漏洞是怎么回事:

权威统计

而且还不知是否有更进一步影响(小道八卦影响比想象的严重)。来自Heartbleed的官方说明(大概翻译下):

OpenSSL在Web容器如Apache/Nginx中使用,这两的全球份额超过66%。还在邮件服务如SMTP/POP/IMAP协议中使用,聊天服务如XMPP协议,VPN服务等多种网络服务中广泛使用。幸运的是,这些服务很多比较古老,没更新到新的OpenSSL,所以不受影响,不过还是有很多用的是新的OpenSSL,都受影响!

特别说明下:现在大家的聚焦都在HTTPS网站(443端口),实际上还有更多敏感服务受影响,我们的研究也是在不断持续推进!不可草率判断!!

1. HTTPS服务(443端口)

来自@ZoomEye 的统计(4.8号):

全国443端口:1601250,有33303个受本次OpenSSL漏洞影响!注意这只是443端口。

全球443端口,至少受影响有71万量级(实际应该大于这个,待修正)。ZoomEye OpenSSL漏洞国内的趋势监控(随时更新,仅是443端口):

第一天:33303 台服务器(说明:国内是4.8号爆发的,当天的影响服务器情况!)

第二天:22611 台服务器(说明:辛苦一线白帽子与运维人员等的辛苦熬夜,减了1/3!而且都是知名业务,如百度、360、微信、陌陌、淘宝等,这点非常赞!)

第三天:17850 台服务器(说明:又减少了近500台服务器,我估计剩下的都不那么大,不过不排除有很重要的!)

第四天:15661 台服务器(说明:相比第一天减少了1/2!不过减少趋势慢了……)

第五天:14401 台服务器(说明:减少趋势持续缓慢……)

第六天:13854 台服务器(说明:减少趋势持续缓慢……)

老外有个基于全球TOP1000的粗暴根域OpenSSL探测列表,仅供参考:

heartbleed-masstest/top1000.txt at master 路 musalbas/heartbleed-masstest 路 GitHub

说这个粗暴是因为:仅对「根域」。

2. 邮件服务

来自@ZoomEye 的统计(4.11号):

最新全球受影响服务及主机 SMTP Over SSL:147292台;POP3 over SSL:329747台;IMAP over SSL:353310台。

实测可以获取某些邮件服务的敏感数据。

3. 可视化

大家可以关注ZoomEye专门针对OpenSSL漏洞制作的全球监控页面(在Chrome或基于Webkit内核的浏览器下,效果最佳,目前仅是443端口):

OpenSSL Heartbleed Worldwide Vulnerable Distribution

我们未来会持续完善这个页面,给大家一个专业、公正的评判结果,辛苦ZoomEye团队的几个小伙伴辛苦突击!截图两张:

 

这个漏洞的全球趋势图,会在一周后数据量足够的情况下给出。

疯掉

今晚(4.8号)不知道有多少团队要熬夜:

  • 甲方,加急升级OpenSSL(如果升级真的可以的话,目前来看是可以);
  • 乙方,像我们这样的安全公司,在给我们全线产品+客户提供安全应急,并给社会输出有价值的参考信息;
  • 地下黑客,刷库,各种刷!!!
  • 每次这种大事,乌云都是被各路白帽子刷分的:

我们已经联合国家有关单位进行应急响应,我相信这次风波会很快平息。

用户防御建议

对于普通用户来说只要发现浏览器地址栏的网址是https开头的都应该警惕,因为这次OpenSSL漏洞影响的正是https网站,本来是安全传输的却也不安全了。可惜的是普通用户来说,有时候很难发现所使用的服务背后是https,比如:

有的仅在登录过程会https,之后都是http,典型的如百度的登录;

如果是手机上的APP等,普通用户就更不知道背后是不是https链接;

4.8号:和某银行朋友交流,他们更新这个漏洞,需要2天时间!!这段时间,用户谨慎吧,不登录就不登录(因为你登录了你的相关明文信息,如用户名密码会在那万恶的64K内存中,这段内存是可以被OpenSSL这个漏洞刷出来的……),等过3天或这些网站说修复了,大家再继续使用服务……

如果已经登录过,你紧张的话,就修改密码吧。

4.10号:最新的消息是「腾讯电脑管家」联合「安全联盟」发布了针对用户的解决方案:

做了两件事情:

一方面对50万个热门的网站扫描是否存在漏洞;

一方面会在管家用户访问https站点时,云端确认这个站点是否存在漏洞。如果用户访问有漏洞的站点,就出拦截页面提示用户,建议不要登录。这个非常赞!

4.12号:那些知名的大网站,现在去修改密码会靠谱很多,因为这些大网站几乎修复完全了。

厂家防御建议

首先,这类攻击日志据Heartbleed官方说,无日志记录,追查不到。不过IDS/IPS等可以检测/防御(我们的加速乐也可以)。

别犹豫了!!尽快升级OpenSSL吧!!

如果厂家负责的话,可以学国外知名云平台厂家Heroku的做法:

Heroku | OpenSSL Heartbleed Security Update

升级后,提醒用户更改密码、提醒云服务使用者更新SSL密钥重复证书。不过不太指望国内厂家这样做,因为我相信用户绝对会疯掉。

附录参考

0. Heartbleed Bug(爆这次漏洞的官方)

1. ZoomEye团队的:OpenSSL Heartbleed Worldwide Vulnerable Distribution

2. 关于OpenSSL“心脏出血”漏洞的分析 – 乌云知识库 – 知乎专栏

3. @Evilm0 OpenSSL漏洞爆发后 – 微信公众号:Evil-say – 知乎专栏

———————-

这事的影响超乎想象,随时更新。

By 知道创宇 余弦,微信公众号「Lazy-Thought」。

【RixTox的回答(152票)】:

既然大家都这么关注,那么我就再爆点猛料好了。

我一骇客界的朋友Lwqn跟我说他们一年前就已经在利用这个漏洞了,获取到了不少大网站的敏感数据,这个消息让我彻夜难眠。

他发了一个exploit的demo给我,原链接已经撤掉了,所以我放到了gist上:http://gist.github.com/RixTox/10222402 Pyhton3版的在这里OpenSSL heartbeat PoC with STARTTLS support

下图是对DEF CON进行的Heartbleed测试

DEF CON在我测试完一个小时后已修复此漏洞。DEF CON在我测试完一个小时后已修复此漏洞。

事实证明此漏洞的确会造成严重的memory dump,因为与所有OpenSSL数据共享同一块内存,dump出来的有可能是任何内容:用户请求、密码,甚至是服务器的私钥!只要不断进行攻击就很有可能拿到关键的数据。

这是一个很严重的漏洞,涉及开启了Heartbeat扩展的OpenSSL版本1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1

OpenSSL: OpenSSL vulnerabilities

刚才在我们的服务器(Gentoo)上看了一下,用的正是1.0.1c的受威胁版本,不过我们并没有开启Heartbeat,所以并不会受到实际威胁,但还是打上了补丁,以备不时之需。

Add heartbeat extension bounds check. 路 7e84016 路 openssl/openssl 路 GitHub

如果你只是想检测一下你的服务器受不受威胁,现在有一款现成的工具可以用

titanous/heartbleeder 路 GitHub

也可以直接使用下面的OpenSSL命令来判断

/usr/local/bin/openssl s_client -connect $website:443 -tlsextdebug 2>&1| grep’TLS server extension “heartbeat” (id=15), len=1′

这个命令只告诉你是否有启用Heartbeat,但并不能说明是否受到威胁,还需要结合OpenSSL的版本进行判断。

Hacker News上面有人给出了这段脚本,能检测Alexa Top Million网站开启Heartbeat的服务器

INPUT=websites.csvOLDIFS=$IFSIFS=,[ ! -f $INPUT ] && { echo “$INPUT file not found”; exit 99; }while read rank websitedo echo “checking $website for heartbeat…”echo -e “quit” | /usr/local/bin/openssl s_client -connect $website:443 -tlsextdebug 2>&1| grep ‘TLS server extension “heartbeat” (id=15), len=1’done <$INPUTIFS=$OLDIFSDownload Alexa Top 1,000,000 Websites for Free

I wrote a bash script to check the top 1000 websites and huge percentage of them…

跑了一小会儿,但好像并没发现什么有价值的信息。其实Heartbeat作为CRM在OpenSSL中用到的机会本就不多,再加上大网站的反应都很迅速,不容易出现大的纰漏。至于0Day发布之前有没有被人利用就不得而知了。

现在各大发行版都已经打上补丁,请各位尽快更新。

=====这个部分是写给非专业人士的,技术控们请直接跳=====

今天接到中国之声的采访邀请,就硬着头皮对这个攻击的技术原理做了点简单通俗的讲解,希望有助于大众正确理解并认识到这个漏洞的原理和影响。这里把采访的具体内容放上来作为这个答案的补充。先吐槽一下央广硬要把我名字Rix念成“雷克萨”,发个英文就那么难么?

先介绍一下这个漏洞是什么时候产生的,有多大影响?

这个漏洞从2012年5月14日OpenSSL发布1.0.1版本时开始产生威胁(如果追踪代码更新的话应该是2011年11月份),至今已经有两年的威胁周期,只是最近才被人发现并做出修正。在威胁期间,我们无法得知有多少黑客发现并利用这个漏洞进行大范围的网络攻击活动,因为这种攻击方式是非常难以被察觉到的。因此如果做最坏的估计,也许所有大网站的用户数据都已泄漏,影响与危害直接涉及个人利益和安全。

黑客是如何利用这个漏洞窃取用户的个人信息的?

举一个不太恰当但是很形象的例子来解释,如果我们把网络服务器比作一个邮局,每个用户是写信人和收信人,用户从服务器上接受数据就相当于收取信件,得自己拿一个袋子到邮局去取,然而这个漏洞就发生在邮局将信件装入袋子的这个过程中。邮局的装袋机器(节目上我说的是工作人员)出于某种原因用户提供多大的袋子就装多少信件,因为一般人都会提供与自己信件数量等同大小的袋子,所以正常状态下并不会发生问题;然而如果攻击者属于自己的信件本就很少,却给了邮局一个很大的袋子,装袋机器就会鬼使神差地把别人的信件也装入袋子里,直到袋子被装满。所以攻击者可以通过这个方法看到随机的他人信件,实际上也就是窃听到其他用户的敏感数据,其中可能包括了用户名、密码、银行账号等等。更严重的是,这个装袋机器还有可能把自己邮局的大门钥匙,也就是我们密码学中所说的私钥,也装进袋子里,攻击者一旦获得这把钥匙,就相当于能随意进出邮局内部,查阅任何人的信件等等。(实际上是以服务器的名义读取和发送任何人的任何数据)当然私钥并不是那么容易获取到的,要进行相当多次的攻击才有机会得到。

用户数据会一次性都泄漏掉吗?

不是的。在实践中,袋子的大小是有最大限制的,所以即使攻击者提供一个无穷大的袋子,每次装回来的数据也是有固定最大数量的,详细来说黑客每次攻击所获得的数据仅有64KB,所以小量的攻击是不会泄漏所有用户的数据的。但是由于平均一台计算机一秒钟可以执行一到两次这样的攻击,黑客还是可以很轻松地大面积抓取用户的敏感信息。

对那些抱有“我账户里又没几个钱,黑客不会有兴趣来攻击我,就算攻击了也得不到什么好处”想法的人有什么建议?(这问题没问,我自己拟的)

当你理解了这个攻击背后的原理之后,你就会明白,由于黑客获取到的是完全随机的内存数据,他们是无法通过这个漏洞针对特定目标进行定位的攻击的,所以他们只能采取撒网式的捕捞攻击,捞到什么是什么,不求质却求量,因此每一个用户都是他们的目标,所有人被攻击的概率都是一样的,不存在“感兴趣的目标”一说。我们有绝对的必要遏止事态的恶化,因为就算每个用户损失得很少,但是积少成多,会给社会造成严重的负面影响。

普通用户该如何保障自己的信息安全呢?

有很多人问我是不是改了密码就没事了呢,我回答是不一定。首先用户是无法自行修补这一漏洞的,只要网站一天不修补漏洞,你的新密码就依然会受到威胁。所以最好的办法就是不要尝试登录甚至用保存了密码的浏览器访问你的服务账户,只要在威胁期间你以账号登录产生数据就可能会有隐私泄漏。然后请关注网站官方的新闻,如果有权威人士正式宣布此网站不受威胁或已经修补漏洞,再登录账户,并切记要修改密码,因为你无法确定在这两年的威胁周期内你的密码是否有泄露。

感谢 @亞首 下面的建议,我觉得非常重要,请各位务必相互提醒!

由于这次漏洞可能造成许多网站的证书泄露,近期内会有非常多网站甚至是CA的证书需要吊销换新,所以请务必在浏览器中开启“检查服务器证书吊销状态”的选项!!

还有什么要补充的观点吗?

我觉得有必要再唠两句关于人们对的网络安全的误解。

首先,我希望不要再有人说“SSL协议有漏洞”之类的话。这次的漏洞是因为OpenSSL这款软件在实现上的纰漏造成的,并不代表SSL这一安全协议标准出现漏洞。这样的误解是对SSL设计者们以及广大密码学界研究人员的一种不敬。

其次,我见到有人因为这次的漏洞就对开源安全软件甚至安全协议标准产生了怀疑和不信任,有人甚至觉得使用闭源软件甚至自主研发的加密算法会更安全。这是很多对密码学不了解的技术从业者非常容易犯下的错误。从理论角度上来说,已经有非常多的例子证明了看似聪明的算法实际拥有的脆弱的安全性,比如WEP、CSS、古老的OTP等等。就算你的算法实现过程不为人知,也有可能仅从密文上就分析出漏洞,直接进行破译,类似的案例也有不少。今日被标准化、模块化的加密算法和开源安全软件都是经过无数研究人员多年探索分析做出来的,没有什么商业公司能拥有如此强大的研究实力。从开发的角度来说,开源就意味着源代码时刻接受所有人的审查,所以出现漏洞的几率相当少。闭源软件虽然阻挡了大部分人对内部原理的透析,却无法阻挡黑客们通过逆向工程的分析,反而给黑客提供了垄断漏洞信息,拉长威胁周期的条件。所以请不要抵触开源软件,相反,越是遇到类似今日的情况就越是要给予开源社区鼓励和帮助,你的一分捐助能为你换来下一个十年、二十年的安全网络。

======以下纯粹是技术吐槽,不喜请绕行=======

英文版漏洞分析请看existential type crisis : Diagnosis of the OpenSSL Heartbleed Bug

漏洞出现在ssl/d1_both.c中,对用户传入的payload长度没有检查就进行内存拷贝。

int dtls1_process_heartbeat(SSL *s) { unsigned char *p = &s->s3->rrec.data[0], *pl;unsigned short hbtype; unsigned int payload; unsigned int padding = 16; /* Use minimum padding */p指向一条SSLv3的记录,结构如下

typedef struct ssl3_record_st { int type; /* type of record */ unsigned int length; /* How many bytes available */ unsigned int off; /* read/write offset into ‘buf’ */ unsignedchar *data; /* pointer to the record data */ unsigned char *input; /* where the decode bytes are */ unsigned char *comp; /* only used with decompression – malloc()ed */unsigned long epoch; /* epoch number, needed by DTLS1 */ unsigned charseq_num[8]; /* sequence number, needed by DTLS1 */ } SSL3_RECORD;

回到上面的程序,接下来对指针进行一些操作

/* Read type and payload length first */hbtype = *p++;n2s(p, payload);pl = p;

这里先读取个type,然后n2s把下一个length的两个字节放到payload里面,作为后面内存拷贝的长度。

unsigned char *buffer, *bp;int r;/* Allocate memory for the response, size is 1 byte* message type, plus 2 bytes payload length, plus * payload, plus padding */buffer =OPENSSL_malloc(1 + 2 + payload + padding);bp = buffer;/* … *//* Enter response type, length and copy payload */*bp++ = TLS1_HB_RESPONSE;s2n(payload,bp);memcpy(bp, pl, payload);

注意这个payload长度是用户请求的,而在分配的时候完全没有对于实际的SSL记录长度进行审查,bp会直接返回给用户,所以攻击者可以dump出任意长度(最大为65535(payload)+1+2+16(padding)=64k)的数据,而pl也是用户传入的,只要把pl设置的很小,dump出来的数据就会包含更多别的敏感数据。具体的利用方法见exploit demo,就不详细分析了。

【WuHao的回答(49票)】:

把内存想象成一条纸带,所有用户的数据都一维地排列在这条纸带上。

Bug重现的场景:

当前纸带上的这一段要被处理的数据是:

[数据长度+数据内容]

这段程序要做的具体的事情是:

读取数据长度,根据长度读取数据内容,然后原封不动地把数据内容发回给用户。

Bug利用的过程:

如果黑客服务器发一段“恶意数据”:

[64K, 数据内容只有1byte] //也就是说声称自己有64K(最大64K,可以小于),但是其实没有这么多

这种情况下,server就会把纸带上后续的[64K-1]长度的数据“原封不动”地发回给黑客

Bug的严重性:

那个纸带上包含server跟所有用户打交道的所有的数据,所以黑客能“随机”读取这些数据中的64k是很致命的。而且他可以不停重复这个过程。

常见的一种情况是,如果你在黑客攻击的同时登陆网站,你的用户名密码就有几率落在被窃取的内存块里。

可以肯定已经有很多人抓了一大堆来自各大网站的热腾腾的内存块,但是还没有开始分析和利用。至于可以恶劣到什么程度,自己想象吧。

更新:

好吧看起来有扩大恐慌的嫌疑,进一步解释一下:

1.首先如果你在漏洞出来之后修复之前没有登录的话,应该是安全的。

2.如果你在危险期那个(登录)了的话,有可能中奖,但是中奖的几率多大不好说,但是各种资金相关的敏感帐号,的确改下密码为好。

3.对于支持并开通了双重验证的网站,因为有一组动态密码,所以理论上是安全的。

【redrainroot的回答(37票)】:

几个hint,dump就不说了,sslvpn,libssl,除去web还可能影响软件,数据,手机app,僵尸网络,甚至是内网进一步渗透(小伙伴已经打到了3个大企业的内网我会乱说?)

没图没jb

这还是小的了,还有敏感的不方便放,这个洞在小黑客手里可能就dump下,在有经验的攻击者手里可以威力倍增这还是小的了,还有敏感的不方便放,这个洞在小黑客手里可能就dump下,在有经验的攻击者手里可以威力倍增

随便开脑洞脑补一下,sslvpn进内网漫游,手机app植入后门控制手机做僵尸网络,dump下来的数据做处理后撞库,拿下域名商后泛解析做菠菜,外贸,拿下主机商后瞬间收获成百上千肉鸡,呵呵~

顺便吐槽一下,知其然不知其所以然,玩个毛线,让我想起去年s2,麻痹一群人不懂java不懂linux跟着瞎jb起哄,黑帽子地下收钱,“白帽子”傻逼逼刷rank,呵呵

【阳淼的回答(35票)】:

把我采写楼上余弦的内容发在这里吧,基本是一个对整个事件的梳理过程加应对建议,专业人士读余弦的,不明觉厉的读这个版本入入门……

昨晚(4月8日)是黑客和白帽们的不眠之夜。他们有的在狂欢,逐个进入戒备森严的网站,耐心地收集泄漏数据,拼凑出用户的明文密码;有的在艰苦升级系统,统计漏洞信息,还要准备说服客户的说辞,让他们意识到问题的严重性;当然还有淼叔这样看热闹不嫌事大的,拼命恶补安全常识、寻找专家采访,试图记录这历史性的一夜。

这一夜,互联网门户洞开。

基础安全协议“心脏出血”

北京知道创宇公司的余弦守在电脑屏幕前彻夜未眠。作为一家高速发展的安全企业研究部总监,余弦在国内黑客圈资历颇深。他向淼叔介绍了这次事件的起源。该漏洞是由安全公司Codenomicon和谷歌安全工程师发现的,并提交给相关管理机构,随后官方很快发布了漏洞的修复方案。4月7号,程序员Sean Cassidy则在自己的博客上详细描述了这个漏洞的机制。

他披露,OpenSSL的源代码中存在一个漏洞,可以让攻击者获得服务器上64K内存中的数据内容。这部分数据中,可能存有安全证书、用户名与密码、聊天工具的消息、电子邮件以及重要的商业文档等数据。

OpenSSL是目前互联网上应用最广泛的安全传输方法(基于SSL即安全套接层协议)。可以近似地说,它是互联网上销量最大的门锁。而Sean爆出的这个漏洞,则让特定版本的OpenSSL成为无需钥匙即可开启的废锁;入侵者每次可以翻检户主的64K信息,只要有足够的耐心和时间,他可以翻检足够多的数据,拼凑出户主的银行密码、私信等敏感数据;假如户主不幸是一个开商店的或开银行的,那么在他这里买东西、存钱的用户,其个人最敏感的数据也可能被入侵者获取。

一位安全行业人士在知乎上透露,他在某著名电商网站上用这个漏洞尝试读取数据,在读取200次后,获得了40多个用户名、7个密码,用这些密码,他成功地登录了该网站。

发现者们给这个漏洞起了个形象的名字:heartbleed,心脏出血。这一夜,互联网的安全核心,开始滴血。

中国有至少三万台机器“带病”

一些安全研究者认为,这个漏洞影响可能没有那么大,因为受漏洞影响的OpenSSL 1.01系列版本,在互联网上部署并不广泛。

国内老资格的安全工作者、安天实验室首席架构师江海客不认同这种说法。他在微博上预警:“这一次,狼真的来了”。

余弦则以对问题进行了精确的定量分析。4月8日的不眠之夜中,他除了在Twitter和各大论坛中实时跟踪事态的最新进展,更重要的精力放在了ZoomEye系统的扫描上。根据该系统扫描,中国全境有1601250台机器使用443端口,其中有33303个受本次OpenSSL漏洞影响!443端口仅仅是OpenSSL的一个常用端口,用以进行加密网页访问;其他还有邮件、即时通讯等服务所使用的端口,因时间关系,尚未来得及扫描。

ZoomEye是一套安全分析系统,其工作原理类似Google,会持续抓取全球互联网中的各种服务器,并记录服务器的硬件配置、软件环境等各类指标,生成指纹,定期对比,以此确定该服务器是否存在漏洞或被入侵。在此次“心脏出血”漏洞检测中,余弦给该系统后面加上一个“体检”系统,过滤出使用问题OPenSSL的服务器,即可得出存在安全隐患的服务器规模。

从该系统“体检”结果看,比三万台问题服务器更令人惊心的,是这些服务器的分布:它们有的在银行网银系统中,有的被部署在第三方支付里,有的在大型电商网站,还有的在邮箱、即时通讯系统中。

自这个漏洞被爆出后,全球的骇客与安全专家们展开了竞赛。前者在不停地试探各类服务器,试图从漏洞中抓取到尽量多的用户敏感数据;后者则在争分夺秒地升级系统、弥补漏洞,实在来不及实施的则暂时关闭某些服务。余弦说,这是目前最危险的地方:骇客们已经纷纷出动,一些公司的负责人却还在睡觉。而如果骇客入侵了服务器,受损的远不止公司一个个体,还包括存放于公司数据库的大量用户敏感资料。更为麻烦的是,这个漏洞实际上出现于2012年,至今两年多,谁也不知道是否已经 有骇客利用漏洞获取了用户资料;而且由于该漏洞即使被入侵也不会在服务器日志中留下痕迹,所以目前还没有办法确认哪些服务器被入侵,也就没法定位损失、确认泄漏信息,从而通知用户进行补救。

问题的应对与新的问题

目前,ZoomEye仍在持续不断地给全球服务器”体检“,这个过程需要20小时左右。相比之下,仅仅给国内服务器体检需要的时间短得多,仅仅需要22分钟;而给那三万多台”带病“服务器重复体检,则只需两分钟。目前,余弦已经将这份名单提交给CNCERT/CC(国家互联网应急中心),由后者进行全国预警。但是,除了移动、联通等这些大型企业外,CNCERT也没有强制力确保其他公司看到预警内容,最后可能还是需要媒体持续曝光一些“带病”服务器,以此倒逼相关公司重视该漏洞。

而在漏洞修补期间,普通消费者与公司均应该采取相关措施规避风险。对于普通用户来说,余弦建议在确认有关网站安全之前,不要使用网银、电子支付和电商购物等功能,以避免用户密码被钻了漏洞的骇客捕获。“一位银行朋友告诉我,他们补上这个漏洞需要两天时间。这两天大家最好就别登录网银了,确认安全后再登。如果已经登录过了,那就考虑换一下密码吧。”

与用户的消极避险不同,相关互联网企业则应该尽快进行主动升级。升级到最新的OpenSSL版本,可以消除掉这一漏洞,这是目前企业最便捷的做法。但在升级后,理论上还应该通知用户更换安全证书(因为漏洞的存在,证书的密钥可能已泄漏),并通知用户尽可能地修改密码。后面这两个措施,企业实施起来会面临很大的代价,也只能通过媒体尽量曝光,让意识到的用户重新下载证书并自行修改密码了。

由于“心脏出血”漏洞的广泛性和隐蔽性,未来几天可能还将会陆续有问题爆出。在互联网飞速发展的今天,一些协议级、基础设施级漏洞的出现,可能会打击人们使用互联网的信心,但客观上也使得问题及时暴露,在发生更大的损失前及时得到弥补。作为身处其中的个人,主动应变、加强自我保护,可能比把安全和未来全部托付出去要负责任一些。

【王音的回答(25票)】:

乌云平台已经有白帽子研究出新的进展,任何使用OPENSSL库的程序都可能受到攻击

任何平台任何使用openssl库的程序都可能受到攻击(非https)

这个问题不会这么简单,应该还有后续的发展!

漏洞的作者来自老牌黑客组织TESO Security(2002年就世界有名),此人专门找OPENSSL漏洞,之前还写过OPENSSH溢出那位(这里就是伏笔了!!!)。

分析了一下外界放出来的POC,作者有所隐藏,漏洞影响可以dump 64KB内存,但POC只遍历16KB。

hb = h2bin(”’ 18 03 02 00 03 01 40 00 ”’) for b in xrange(0, len(s), 16):

# SMTPS 受影响的截图

【Ivony的回答(19票)】:

可以用十年一遇来形容了,

OpenSSL在Linux和开源领域应用极为广泛,这个漏洞出在SSL这种核心组件上,Dump出来的数据包含身份验证信息的可能性极大,远不是其他漏洞可以比的。

这个漏洞的影响将会极其深远,从短期来看及时更新版本避开有漏洞的OpenSSL版本可以解决问题。但是在这期间泄露的身份验证信息是无法追踪得知的,换言之任何可能曾经存在这个漏洞的系统的所有身份验证信息都有可能已经被泄露。这使得漏洞被修复后将造成严重的安全假象,很可能很多系统的管理员权限和身份验证已经被窃取而不所知。甚至有些密码是无法被简单修改的。

仅仅是修改自己的密码并不能保证绝对的安全,因为谁也不知道你面对的是不是CSDN那种没有节操的用明文保存密码的网站,对于这种网站而言,利用之前因为漏洞流出的系统管理员密码登陆则可以轻松地获取你最新的密码。

这次爆出的这个漏洞的几个特性应该完全可以称之为十年一遇:

广泛性:OpenSSL组件应用范围极其广泛。

核心性:OpenSSL组件主要提供SSL服务,该服务经常用于传输敏感信息例如密码。

不可追踪性:黑客利用此漏洞后不会留下任何痕迹,永远无法知道黑客通过该漏洞获取了什么信息。

易攻击性:HTTPS协议是外层公开协议,没有防火墙或者其他保护措施,任何人都可以随意发动攻击。

【丁鹏的回答(25票)】:

实在是看不过去了,晒张图吧。

小白表示不明白

【知道创宇】为何没有提一下自己的产品

【加速乐】也出现此漏洞了呢?

加速乐修复很快,但是不保证没有人对其攻击过,加速乐修复后就开始宣传并宣称各大厂商有漏洞,需要修复请使用加速乐,这样攻击他人来提高自己形象的回答还是少发为妙!

Openssl的漏洞既然早有了,那你们之前在干嘛?

看图吧,加速乐的服务器同样存在Openssl漏洞,别到处贬低别人鼓吹自己了!

 

【朱欣愚的回答(12票)】:

这个漏洞的实际影响非常大。

比较大型的网站,登录认证这种事情,往往是一个独立的应用,使用https协议单独部署。所以运行一段时间之后,应用的内存中都是跟认证相关的数据,其中就会有大量的用户名和密码。在小型网站上利用这个漏洞反而比较困难,一般小型网站就那么几台Web服务器,所有业务都在上面跑,Web服务器的内存里面什么都有,有效信息的比重会很低。

实际测试了一下,以某宝为例,用4k大小的包读取,尝试200次,大约拿到40个用户名,7个密码。随便试了一对用户名密码,可以登录成功。

这个事其实也暴露出http服务的安全有多脆弱。

http服务有完善的链路层安全协议,反而导致设计应用协议的人偷懒,不在协议上作任何安全考虑,这样在应用的两端还是存在明文密码。明文密码或者说不过期的密码,存在的地方多一个就危险一分。像登录这种事情,如果客户端发给服务器的是密码加时间的hash值,这个漏洞的危害就小很多。

一个有趣的事情是,设计原生tcp应用协议的人,反而会更多的在协议上考虑安全,因为他们没有非常好用的ssl库。

【知乎用户的回答(7票)】:

这个漏洞最大的问题是对自身网络没有足够实时多层次监控能力的网站被人攻击了也不知道。因为根本就不会有Apache日志产生,光靠事后审计Apache日志什么的是看不出问题的。漏洞是很容易利用的,主要是能读到什么看运气,不过因为很难被发现,攻击者只要有耐心,总有一次会运气好可以读走点有利用价值的东西。影响可能很大,也可能很小,你有1/(2**267709)的概率没被攻击过,DON’T PANIC。

就是这样

———————–

重要补充:其他回答都只盯着服务端。其实,所有客户端也可以被攻击的,而且更隐蔽,问题更严重。不仅仅是恶意服务端,恶意中间人也可以在正常的TLS连接里插入一个heartbeat。所以,所有人都应该立刻更新受影响版本的OpenSSL。



 

版权声明

文章编辑: ( 点击名字查看他发布的更多文章 )
文章标题:OpenSSL 的 Heartbleed 漏洞的影响到底有多大?
文章链接:http://ccdigs.com/53882.html

分类: IT观察, 多向思维, 科技视野.
标签:

发表评论