解析OpenSSL程序概念及震惊业界的“心脏出血”漏洞
60人参与 • 2015-11-10 • 漏洞分析
openssl的各种概念解析：
公钥/私钥/签名/验证签名/加密/解密/非对称加密
我们一般的加密是用一个密码加密文件,然后解密也用同样的密码.这很好理解,这个是对称加密.而有些加密时,加密用的一个密码,而解密用另外一组密码,这个叫非对称加密,意思就是加密解密的密码不一样.初次接触的人恐怕无论如何都理解不了.其实这是数学上的一个素数积求因子的原理的应用,如果你一定要搞懂,百度有大把大把的资料可以看,其结果就是用这一组密钥中的一个来加密数据,可以用另一个解开.是的没错,公钥和私钥都可以用来加密数据,相反用另一个解开,公钥加密数据,然后私钥解密的情况被称为加密解密,私钥加密数据,公钥解密一般被称为签名和验证签名.
因为公钥加密的数据只有它相对应的私钥可以解开,所以你可以把公钥给人和人,让他加密他想要传送给你的数据,这个数据只有到了有私钥的你这里,才可以解开成有用的数据,其他人就是得到了,也看懂内容.同理,如果你用你的私钥对数据进行签名,那这个数据就只有配对的公钥可以解开,有这个私钥的只有你,所以如果配对的公钥解开了数据,就说明这数据是你发的,相反,则不是.这个被称为签名.
实际应用中,一般都是和对方交换公钥,然后你要发给对方的数据,用他的公钥加密,他得到后用他的私钥解密,他要发给你的数据,用你的公钥加密,你得到后用你的私钥解密,这样最大程度保证了安全性.
rsa/dsa/sha/md5
非对称加密的算法有很多,比较著名的有rsa/dsa ,不同的是rsa可以用于加/解密,也可以用于签名验签,dsa则只能用于签名.至于sha则是一种和md5相同的算法,它不是用于加密解密或者签名的,它被称为摘要算法.就是通过一种算法,依据数据内容生成一种固定长度的摘要,这串摘要值与原数据存在对应关系,就是原数据会生成这个摘要,但是,这个摘要是不能还原成原数据的,嗯....,正常情况下是这样的,这个算法起的作用就是,如果你把原数据修改一点点,那么生成的摘要都会不同,传输过程中把原数据给你再给你一个摘要,你把得到的原数据同样做一次摘要算法,与给你的摘要相比较就可以知道这个数据有没有在传输过程中被修改了.
实际应用过程中,因为需要加密的数据可能会很大,进行加密费时费力,所以一般都会把原数据先进行摘要,然后对这个摘要值进行加密,将原数据的明文和加密后的摘要值一起传给你.这样你解开加密后的摘要值,再和你得到的数据进行的摘要值对应一下就可以知道数据有没有被修改了,而且,因为私钥只有你有,只有你能解密摘要值,所以别人就算把原数据做了修改,然后生成一个假的摘要给你也是不行的,你这边用密钥也根本解不开.
ca/pem/der/x509/pkcs
一般的公钥不会用明文传输给别人的,正常情况下都会生成一个文件,这个文件就是公钥文件,然后这个文件可以交给其他人用于加密,但是传输过程中如果有人恶意破坏,将你的公钥换成了他的公钥,然后得到公钥的一方加密数据,不是他就可以用他自己的密钥解密看到数据了吗,为了解决这个问题,需要一个公证方来做这个事,任何人都可以找它来确认公钥是谁发的.这就是ca,ca确认公钥的原理也很简单,它将它自己的公钥发布给所有人,然后一个想要发布自己公钥的人可以将自己的公钥和一些身份信息发给ca,ca用自己的密钥进行加密,这里也可以称为签名.然后这个包含了你的公钥和你的信息的文件就可以称为证书文件了.这样一来所有得到一些公钥文件的人,通过ca的公钥解密了文件,如果正常解密那么机密后里面的信息一定是真的,因为加密方只可能是ca,其他人没它的密钥啊.这样你解开公钥文件,看看里面的信息就知道这个是不是那个你需要用来加密的公钥了.
实际应用中,一般人都不会找ca去签名,因为那是收钱的,所以可以自己做一个自签名的证书文件,就是自己生成一对密钥,然后再用自己生成的另外一对密钥对这对密钥进行签名,这个只用于真正需要签名证书的人,普通的加密解密数据,直接用公钥和私钥来做就可以了.
密钥文件的格式用openssl生成的就只有pem和der两种格式,pem的是将密钥用base64编码表示出来的,直接打开你能看到一串的英文字母,der格式是二进制的密钥文件,直接打开,你可以看到........你什么也看不懂!.x509是通用的证书文件格式定义.pkcs的一系列标准是指定的存放密钥的文件标准,你只要知道pem der x509 pkcs这几种格式是可以互相转化的.
心脏出血的openssl
去年，openssl爆出史上最严重的安全漏洞，此漏洞在黑客社区中被命名为“心脏出血”漏洞。360网站卫士安全团队对该漏洞分析发现，该漏洞不仅是涉及到https开头的网址，还包含间接使用了openssl代码的产品和服务，比如，vpn、邮件系统、ftp工具等产品和服务，甚至可能会涉及到其他一些安全设施的源代码。
受影响版本
openssl1.0.1、1.0.1a 、1.0.1b 、1.0.1c 、1.0.1d 、1.0.1e、1.0.1f、beta 1 of openssl 1.0.2等版本。
漏洞描述
openssl在实现tls和dtls的心跳处理逻辑时，存在编码缺陷。openssl的心跳处理逻辑没有检测心跳包中的长度字段是否和后续的数据字段相符合，攻击者可以利用这点，构造异常的数据包，来获取心跳数据所在的内存区域的后续数据。这些数据中可能包含了证书私钥、用户名、用户密码、用户邮箱等敏感信息。该漏洞允许攻击者，从内存中读取多达64kb的数据。
前几日的漏洞分析文章主要聚焦在开启https的网站上，普通网民可能认为只有网站自身业务会受到这个漏洞的影响。从360网站卫士openssl心血漏洞在线检测平台(wangzhan.360.cn/heartbleed)的监控数据得知，心血漏洞的辐射范围已经从开启https的网站延伸到了vpn系统和邮件系统，目前共发现国内共有251个vpn系统和725个邮件系统同样存在漏洞，其中不乏很多政府网站、重点高校和相关安全厂商。
为了更好让大家明白，openssl心血漏洞到底是哪个环节出了问题，我们利用openssl lib库编写了一个不依赖与任何业务的独立server程序，来一步步实际调试一遍代码，以此证明不仅是https的网站有问题，只要使用了存在该漏洞的openssl libssl.so库的应用程序都存在安全漏洞！
测试环境
os：centos release 6.4 (final)
openssl: version 1.0.1f（没有打开openssl_no_heartbeats编译选项）
编写server程序：监听端口9876
漏洞测试
利用网上python验证脚本（https://gist.github.com/rixtox/10222402）进行测试
构造异常heartbeat数据包，主要添加异常的length字段值。
测试一：
蓝色的01表示的是心跳包的类型为request方向。对应源代码中就是#define tls1_hb_request 1
红色的20 00表示的心跳请求包的length字段，占两个字节，对应的长度值为8192。
heartbeat response包
复制代码
代码如下:[root@server test]# python ssltest.py 127.0.0.1 -p 9876 > 1</p>
<p>sending heartbeat request…</p>
<p>… received message: type = 24, ver = 0302, length = 8211</p>
<p>received heartbeat response:</p>
<p>warning: server returned more data than it should – server is vulnerable!</p>
<p>received heartbeat response:
蓝色的02表示的是心跳包的类型为response方向。
对应源代码中就是#define tls1_hb_response 2
红色的20 00表示的心跳响应包的length字段，占两个字节，对应的长度值为8192。和request包的length值一样。
绿色部分就是非法获取到的越界数据(可能包含用户名、密码、邮件、内网ip等敏感信息)。
测试二：
在测试一的基础上，修改了request心跳包的length字段的值，从20 00 修改到 30 00
heartbeat requst包
30 00两个字节对应的长度为12288（8192+4096）
heartbeat response包
复制代码
代码如下:[root@server test]# python ssltest.py 127.0.0.1 -p 9876 > 1</p> <p>sending heartbeat request…</p> <p>… received message: type = 24, ver = 0302, length = 12307</p> <p>received heartbeat response:</p> <p>warning: server returned more data than it should – server is vulnerable!</p> <p>received heartbeat response:</p> <p>0000: 02 30 00 d8 03 02 53 43 5b 90 9d 9b 72 0b bc 0c .0….sc[...r...</p> <p>0010: bc 2b 92 a8 48 97 cf bd 39 04 cc 16 0a 85 03 90 .+..h...9.......</p> <p>0020: 9f 77 04 33 d4 de 00 00 66 c0 14 c0 0a c0 22 c0 .w.3....f.....".</p> <p>0030: 21 00 39 00 38 00 88 00 87 c0 0f c0 05 00 35 00 !.9.8.........5.
两个测试用例中，response的length长度值总是比request的长度多出来了19个byte，为什么？
因为，tls和dtls在处理类型为tls1_hb_request的心跳请求包逻辑中，在从堆空间上申请内存大小时，有4部分决定type+length+request的数据长度+pad，其中type,length,pad字段分为占1byte，2byte，16byte，所以response的数据总是比request的多出来19byte。
源码分析
概要说明
该漏洞主要是内存泄露问题，而根本上是因为openssl在处理心跳请求包时，没有对length字段（占2byte，可以标识的数据长度为64kb）和后续的data字段做合规检测。生成心跳响应包时，直接用了length对应的长度，从堆空间申请了内存，既便是真正的请求data数据远远小于length标识的长度。
相关解析源码说明
存在该漏洞的源文件有两个ssl/d1_both.c和ssl/t1_lib.c。
心跳处理逻辑分别是dtls1_process_heartbeat和tls1_process_heartbeat两个函数。
dtls1_process_heartbeat函数处理逻辑：
step1.获取心跳请求包对应的sslv3记录中数据指针字段，指向request的请求数据部分。
复制代码
代码如下:unsigned char *p = &s->s3->rrec.data[0];
record记录的数据格式应该包含了三个字段：type， length， data；分别占1byte，2byte，length的实际值。
step2.
复制代码
代码如下:/* read type and payload length first */
hbtype = *p++;
n2s(p, payload);
pl = p;
做了两件事，获取了type类型以及length字段的值（存放到payload中），然后将pl指向真正的data数据。
step3.
复制代码
代码如下:/* 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;
悲剧开始上演了。没有判断请求记录中的真正数据长度，直接用length字段的值来申请空间。对应于测试一中的异常数据包的话，buffer申请的内存大小就是8211byte。但是实际应该申请的大小仅仅就几个字节。
step4.
复制代码
代码如下:/* enter response type, length and copy payload */
*bp++ = tls1_hb_response;
s2n(payload, bp);
memcpy(bp, pl, payload);
bp += payload;
悲剧形成了。填充响应记录，第一个字节填充类型，第二、三个字节填充request记录中length的值，紧接着，将request的data填充为响应的data数据。异常情况下，payload对应的长度远远大于真正应该使用的合法的data数据长度，这样，就导致了非法越界访问相邻内存空间的数据。
tls1_process_heartbeat函数的处理逻辑和dtls1_process_heartbeat一样，此处就不再做详细分析了。
附：ssl_server.c
编译方式(请根据实际环境自行修改相关路径)
复制代码
代码如下:gcc -g -o ssl_server ssl_server.c -i/root/openssl_101f_prex/include/ -l/root/openssl_101f_prex/lib/ -lssl
该代码是文中用于调试存在漏洞的libssl.so库的server端，供对该漏洞感兴趣的安全研究人员、安全爱好者们自行后续调试。希望这段独立的代码能让大家意识到这个漏洞持续的高等级威胁：截至目前，心血漏洞仅仅是刚开始出血，避免这个漏洞引起互联网业务大血崩此刻就要开始更多的行动了！
赞 (0)
打赏
微信扫一扫
微信扫一扫
您想发表意见！！点此发布评论
发表评论