现有软件系统中的密码学误用综述

1、移动智能终端应用

现今,随着移动通信技术的发展,移动终端发送了巨大的变化,朝着智能化的方向不断迈进。智能手机、平板电脑等智能设备在人们的日常生活中扮演着不可或缺的角色。据市场研究机构Strategy Analytics最新调查显示,2015年底前全球72亿人口中就会有约34.7%使用智能手机。该机构此前的调查指出,2012年全球智能手机用户已超过10亿大关。由于移动终端涉及大量商业秘密和个人隐私如账户密码、地理位置、社交网络数据等敏感信息,运行在智能终端上的应用安全引起了人们的广泛关注。目前,最新的数据显示Google Play上的应用数量已达136.8万[12],苹果的Apple store里应用的数量也已经超过120万[13]。其中,很多应用是由一些没有受过信息安全培训缺乏足够密码学知识的开发者开发的,他们在调用密码学API进行基本的密码学操作时常常会出现误用的情况,给智能终端带来安全隐患。

加密时使用ECB模式

Android平台中,应用主要使用Java语言来开发,Java的密码学API默认在AES加密时使用ECB模式[14]。我们知道,使用ECB模式进行加密时,会导致相同明文块的对应密文块也相同,不能够抵抗CPA(选择明文攻击)[15]。这种默认使用ECB模式的行为是不合理的,开发者很可能因为缺乏密码学知识而不去改变加密模式,从而在应用中使用了有缺陷的加密模式,带来了安全问题。2012年美国卡内基梅陇大学的研究团队对Google Play上11,748个应用进行了分析,发现有7,656个app在加密时使用ECB模式。

CBC加密时使用非随机IV

在移动应用中,CBC加密时使用不随机IV的现象也很常见。我们知道,在CBC模式中,IV在加密时必须是无法预测的,重用IV会导致泄漏明文首个块的某些信息,也包括两个不同消息中的相同前缀。但遗憾的是,很多时候IV会被设置成一个固定的值,比如全零。例如在SSL v3.0和TLS 1.0中使用CBC模式时,采用上一个消息的最后一块密文作为下一个消息的IV,导致可以被进行“BEAST”攻击,是不安全的。在Android应用开发时,如果使用的是CBC模式,需要开发者去指定所使用的key和iv,通常由IvParameterSpec()函数来生成所需的iv,但开发者常常在这个函数中使用恒定的参数,也就导致每次生成的iv都相同,即在CBC模式中使用了恒定的iv,这就带来了安全问题。

没有进行实体认证的密钥交换

移动应用中存在的另一类严重的密码学误用问题是没有进行实体认证的密钥交换行为,具体表现为应用在使用https通信时,建立SSL链接的过程中没有或者不能正确校验服务器证书。这种问题产生的部分原因是因为X.509证书结构非常复杂,证书校验的过程对缺乏足够密码学知识的应用开发者来说难以正确实现,出现不校验主机名、不检查证书有效期等各种问题,以遭致中间人攻击[18,19];也有部分原因是开发者用来开发程序时所使用的开源密码学库存在问题,它们没有给出正确的示例程序告诉开发者应该如何使用它们的密码学API实现完整的证书校验过程,开发者按照这些开源密码学库给出的官方文档或示例程序去实现的证书校验过程依然存在漏洞,常见的密码学库如OpenSSL、PolarSSL、GnuTLS等都存在这样的问题[16];或者就是密码学库本身存在问题,比如今年苹果iOS 7.0.6版本中著名的“goto fail”漏洞[17],导致应用程序不能检查证书签名也就不能验证SSL通信中服务器的身份了。由于移动平台中许多非浏览器应用使用webview控件来实现内置浏览器功能,在应用中看不到地址栏,用户不知道当前是否使用了https通信或者访问的是否是合法的网址,因此应用本身实现正确的证书校验过程去认证服务器身份显得尤为重要。

SecureRandom()随机数问题

同时,移动应用开发者还常常在使用SecureRandom()生成随机数的时候使用相同的种子,我们知道,PRNG(伪随机数发生器)使用相同的种子时会产生可预测的输出,而它又常常被用来进行密钥生成等操作,随机性不足会直接导致密钥不安全。一个好的避免这样问题发生的办法是不要把随机数种子选取的操作留给应用开发者实现,当然这样的工作还需要密码学API开发者去完成。

PBE问题

由于用户选择的密码通常不能抵抗基于字典的暴力攻击,因此实际应用中常常使用PBE(Password-based Encryption)方案来提高暴力破解的代价,使得用户的密码相对来说更难被破解。PBE方案使用密码和salt来加密信息,一个随机的salt能够有效的阻止暴力攻击。在PBE中,密钥推导算法是一个密码学安全的哈希函数的c轮迭代,对于一个没有使用salt的PBE,借助一个大小为N的字典暴力破解需要哈希函数的额外cN次迭代,而对于一个有salt的PBE,如果s=|sa|足够大且每个盐都不同,那么暴力破解的复杂性就上升到了scN,会显著提高暴力破解的代价。RFC2898中建议至少使用1000次以上的迭代,同时使用一个64-bit的salt。苹果的iOS系统在数据保护时使用了PBE,从密码计算出一个key只需要80ms,时间很短几乎不会被用户察觉,但是却能有效降低暴力攻击的效率。2012年CMU的科研团队在对Google Play上下载的11,748个app进行分析,发现有1,574个app使用了固定的salt,1,636个app迭代次数不超过1000次[14],这种做法违背了PBE最佳实践的,存在安全隐患。

2、Web服务器

我们知道信息安全有三大要素:机密性、可靠性和完整性。密码学密钥是保证数据机密性的关键。然后,在Web服务器中,不安全的密钥管理却普遍存在。在Web服务器中,不安全的密钥管理主要包括不安全的密钥存储、不同加密用途的密钥重用以及把密钥管理留给开发者和用户操作这三个问题。

不安全的密钥管理

不安全的密钥存储

不安全的密钥存储常常是由于Web应用开发者或服务器管理员缺乏安全意识导致的。在ASP.NET v4框架中,使用ASP.NET v4框架开发的web应用会把所使用的密码学密钥以明文形式存储在应用根目录的web.config配置文件里,一旦攻击者能够访问应用根目录,他们可以很容易获取到应用所使用的密钥,从而轻松解密加密的数据[1]。使用RDP 5.2(远程桌面协议)的微软终端服务器会把自己的RSA私钥存储在mstlsapi.dll文件中并用它来给证书签名,能够访问mstlsapi.dll文件的远程攻击者就可以获取到RSA私钥,然后对这个服务器进行中间人攻击,解密通信中的加密流量了[2]。类似的情况还有Red Hat Network Satellite 服务器,RHN Satellite服务器5.1.1之前的版本验证都是基于XML-RPC脚本manzier.pxt源代码中的一个硬编码的密钥,能够连接Satellite的远程攻击者可以得到这个密钥,然后或者RHN Satellite的用户信息(包括登录名,相关Email地址和内核用户ID等)[3]。

多种用途重用一种key

Web服务器中还常常出现使用相同密钥加密不同安全级别数据的现象。同样在ASP.NET v4框架中,表单验证数据、视图状态、web资源和脚本资源等都需要加密,其中forms authentication ticket和view state是非常重要的信息,而web资源和脚本资源则对于ASP.NET的安全来说没那么重要,但是,在这个框架里,使用了相同的密钥加密这些重要程度不同的数据。一旦攻击者能够获取到密钥,那么就可以轻松访问所有资源了,这是非常危险的[1]。

密钥管理留给用户实现

同时,许多Web应用框架会把密钥管理操作如密钥生成、密钥更改、密钥吊销等操作留给用户和开发者去完成。而由于大部分用户和开发者缺乏足够的密码学知识,他们没有能力去正确的生成密钥更改密钥,于是很多用户会直接使用从网络上下载的或者由第三方安装的应用中的默认密钥,而这个行为是存在安全隐患的。因为从网络上下载的应用里的默认密钥可能都是相同的,攻击者只需要拿到一个应用的密钥就可以攻击其他用户的相同应用了。Webmin是目前功能最强大的基于Web的Unix系统管理工具,它在0.2.1到1.0版本中所有的安装包都使用了相同的内置SSL密钥,远程攻击者获得密钥后就可以窃听或者劫持SSL会话了。密钥管理这样需要专业知识的操作不应该交由用户或者开发者去完成。 以上的这些密钥管理问题,大多是因为Web应用开发者或者服务器管理员安全意识缺乏造成的,这样的问题很容易修复,而且只要加强对开发者和管理员的安全知识培训,这样的问题也很难出现。但是,有的问题,确是Web应用框架本身的设计问题,常见的比如使用不正确的填充方案、存在Padding Oracle、加密数据时没有使用认证加密或者错误的使用了认证加密方式等。

分组填充

错误的填充方案

常用的对称加密算法,如AES、3DES在加密时一般使用分组密码(Block Cipher),将明文以等长数据块(Block)为单位进行加密,比如RC2,DES或者3DES算法的数据块长度为64bit,AES算法这个长度是128bit。但是,由于输入数据长度的不确定性,数据的长度未必是数据块长度的整数倍,就需要进行“填充”来形成完整的数据块。填充方案有很多中,比如常见的PKCS#5,在最后一个block中将不足的bit位数以bit为值填充。使用错误的填充方案会存在安全隐患。比如Bleichenbacher曾提出一种针对使用RSA加密标准PKCS#1填充方案的协议的CCA攻击。(若需展开则请谢天忆补充这部分)

Padding Oracle Attack

将数据块填充完之后,再用分组密码加密模式进行加密。然后由应用程序对提交的加密数据进行解密,当加密后的数据中出现错误的填充信息时,有的应用程序解密时会报错,抛出“填充错误”等异常信息。这种应用程序的异常处理就会被攻击者用来进行Padding Oracle 攻击。这里,Padding的含义是“填充”,即对数据块的填充,Oracle的含义是“提示”,即解密程序发现错误的填充信息后会抛出异常,提示Padding不正确。攻击者给出的异常其实就是一种提示,攻击者可以不断地提供密文,让解密程序给出提示,然后不断修正,最后得到所需要的结果。这里的提示不一定要是“填充错误”这种形式,只需要给出与成功解密不同的相应结果即可。比如一个Web程序中接受一个加密后的字符串作为参数,参数中包含用户名等信息,如果参数是正确的密文,用户名、分组、填充都是对的,解密成功的反馈是HTTP 200,如果参数是正确的密文,但是用户名是错的,服务器反馈可能还是HTTP 200或者HTTP 302,如果参数是一串错误的密文,包含不正确的填充方式,则服务端解密会抛出异常,返回HTTP 500这样的表现形式。那么攻击者不需要其他任何详细信息,无需关心用户名是否正确,只需要提交错误的密文,根据HTTP code就能够进行Padding Oracle 攻击。

ASP.NET实例

恶意用户能够使用Padding Oracle攻击来解密cookie,加密状态以及认证密码等关键信息。常见的Web应用程序框架如JavaServer Faces[4]、ASP.NET[1,4]和Ruby on Rails[4]中都存在各种Padding Oracle。2011年Thai Duong和Juliano Rizzo曾对ASP.NET v4中的Padding Oracle做过分类[1],分为认证加密Padding Oracle和未认证加密Padding Oracle。ASP.NET v4中使用MAC-then-Encrypt模式来保护表单验证数据和角色cookies,这种模式对于选择密文攻击是脆弱的,这里可以被用作Padding Oracle。同时,在ASP.NET v4中,它在加密脚本和web资源时没有使用一个认证码来保护密文,这就在框架中引入了Padding Oracle,这个Padding Oracle可以结合CBC-R技术来对ASP.NET框架进行攻击。CBC-R技术是由Rizzo和Duong[4]首先提出的一种能够将解密语言机转变为加密语言机的技术,从而使攻击者能够伪造可以被目标信任的合法密文。CBC-R的工作原理如图1所示:

图1

图1 CBC-R工作原理示意图

在ASP.NET中,Web资源和脚本资源分别依赖特别的处理器WebResource.axd 和 ScriptResource.axd来向Web浏览器提供资源。客户端向这两个处理器发送请求来获取资源。请求格式为:WebResource.axd?d=encrypted_id&t=timestamp,由于ScriptResource.axd的一项特性,攻击者若能伪造一个合法的d参数,那么他就能从ASP.NET应用根目录下下载任何文件,比如web.config文件。利用ASP.NET的这个特性,借助于WebResource.axd中的Padding Oracle和CBC-R技术,攻击者可以构造出合法的d参数来下载web.config文件,又由于之前讲不安全的密钥管理时提到ASP.NET会把密钥以明文形式存储在web.config文件中,且应用中的不同数据均以相同密钥加密,攻击者可以轻松获得加密数据信息。类似的Padding Oracle 攻击也存在于JSF和ROR框架中。

未使用认证加密

ASP.NET框架之所以存在这样的安全漏洞,一个很重要的原因是没有正确使用认证加密。它使用了不安全的认证加密模式MAC-then-Encrypt或者直接没有使用认证加密,从而引入了可被利用的Padding Oracle。未认证加密不仅在ASP.NET中带来安全漏洞,在其他系统中也没有使用认证加密也会引入攻击。比如XML加密时如果没有使用认证加密,那么XML加密可以被破解[5,6]。XML加密协议常被用来确保电子商务和金融机构所使用的在线服务器间数据传输的安全性。它的加密算法基于块加密的连缀。在XML加密协议标准里规定加密时使用CBC模式,而CBC模式不能保障消息的完整性,利用CBC模式的这个缺陷,可以对XML加密协议进行选择密文攻击恢复出给定密文对应的全部明文。

RSA小e问题

除了Web应用程序框架的问题以外,从近年来多次针对TLS和SSH服务器全网扫描的数据集分析结果来看,TLS和SSH服务器所使用的证书也存在着一些安全隐患。下表[7]是分析2010年至2012年收集的数据得到的最常见RSA公开指数的情况:

图2

图2 最常见RSA公开指数

从表中可以看出有很多很小的公开指数如3、5、7、11等等仍被大量使用,而在RSA中使用这种小公开指数可能会遭到Hastad 广播攻击[8,9]、Franklin-Reiter相关消息攻击[8,10]、Coppersmith短填充攻击[8,11]等等,是一种不安全的做法。

RSA密钥长度不足

同时,调查发现还有很多512-bit和768-bit的RSA模数被使用[7]。图3是不同大小模数的累积数量。分析的集合中共有6,386,984个不同的RSA模数,其中1.6%的模数是512-bit(甚至有0.01%使用的是384-bit的公钥),0.8%的模数是768-bit。这些模数都是很脆弱的,容易被分解(如图3所示)。

图3

图3 不同大小RSA公钥的累积数量

3、桌面操作系统 桌面操作系统被人们使用了很长时间,相对而言存在的由于密码学误用而导致的漏洞较少,但是少数这样的漏洞往往能够带来很大的危害。

Debian随机数问题

OpenSSL是被广泛使用的密码学库。2006年,在Debian版本的Linux中OpenSSL在发布补丁修复一个bug时,不慎禁用了OpenSSL的熵收集功能,导致OpenSSL在生成随机数时不能够收集到足够的熵,产生的随机数随机性不足,从而会生成可预测的随机数和公私钥对。这个漏洞直到2008年才被Luciano Bello[21]发现,在漏洞被公布后,加州大学圣地亚哥分析的研究团队对互联网中50000个TLS/SSL服务器进行了调查,发现751个服务器使用有漏洞的证书。由于有漏洞的证书都需要被更好,涉及到服务器向CA重新申请新证书并吊销有问题证书的过程,这个漏洞修复速度很慢,在漏洞被公布6个月后仍然有30%的有问题服务器依然存在漏洞。

Microsoft Office Word&Excel中的RC4误用

在Windows系统中同样存在密码学误用的情况。在微软Office的Word 2002和Excel 2002中都存在RC4误用的情况.在微软的Word和Excel软件中,都使用128-bit的RC4密钥来保护文档,但是当一个加密了的文档被修改和保存后,初始向量仍然保持不变,于是会生成和之前相同的密钥流去加密修改后的文档,这个后果是很严重的,攻击者如果能得到两份不同的本文使用了相同的密钥流加密,很多信息都可以被恢复出来[22]。

4、MISC 近年来,人们常用的嵌入式设备中,比如家用路由器、闭路电视监控系统等等嵌入式设备频频被曝出安全漏洞。嵌入式设备的安全问题引起了人们的广泛关注。这些设备的安全漏洞很多是因为密码学误用导致的。嵌入式设备中的密码学误用主要包括硬编码证书私钥、使用脆弱的hash函数、硬编码帐户凭据、密钥生成随机性不足等问题。

Entropy Problem

嵌入式设备中存在的比较严重的问题是密钥生成随机性不足的问题。嵌入式设备与传统PC相比生成随机数的熵源有限,由于很多设备是在第一次开机后自动生成key的,这个时候生成key,由于熵源有限就会出现熵不足的现象,生成随机数需要从熵池(Entropy pool)里选取种子,熵不足可能种子是固定的,就会导致生成的随机数随机性不够。比如生成RSA密钥时需要两个随机的素数p和q,如果第一个素数是在熵不足的时候生成的,那么可能其他相同类型的设备这个时候生成的素数也是这个p,也就意味着两个不同设备上的RSA模数N1和N2有一个公共素因子p,如果能获取到这两个模数,求它们的素因子就可以把这两个模数分解了,从而进一步计算出对应的RSA私钥。如果p和q都是在熵不足的情况下产生的随机数,即有可能两台设备上的RSA模数是相同的,假设设备有A和B,那么这个时候B可以根据他的公开指数和私有指数分解模数N[8],当他能分解N后,再结合A的公开指数就可以恢复出A的私有指数了,即B获得了A的私钥,这种情况显然是不安全的。相同密钥的情况如果发生在DSA签名方案中,即有两条不同的消息使用了相同的短期密钥签名,那么也很容易可以计算出长期私钥,破坏了DSA签名的安全性。 嵌入式设备最常使用的操作系统是Linux。2014年法国的一个研究团队对32,356个嵌入式设备固件镜像进行了分析,发现86%的设备使用的操作系统都是Linux[20]。Linux系统在生成随机数时,可以从/dev/urandom 和/dev/random中选取种子,流行的安全密码库OpenSSL和开源软件Dropbear都是默认使用/dev/urandom。然而,在Linux文档[21]里,明确说明“urandom不应该被用来生成长期GPG/SSL/SSH密钥”。事实上,在大多数开源实现中,都是默认使用urandom来生成密钥的。对开发者的邮件和论坛调查显示,这种情况是由于大家认为使用random太保守了,他们认为urandom的输出已经足够安全,这是一种误解,同时这种做法也是不安全的。 由于熵不足的问题或者使用urandom生成的有问题的密钥广泛分布在互联网中的各种嵌入式设备上。2012年的一次调查显示[7],分析了收集到的660万个不同的X.509证书中,有27万的证书共享了它们的RSA模数。分析数据还发现12934个RSA模数存在很大安全风险,可以直接获取私钥,这些模数影响到21419个X.509证书和PGP 密钥,主要是因为模数之间含有公共素因子导致了这样的安全风险。

硬编码密钥或认证凭据等

硬编码密钥、密码hash或者登陆凭据的现象在嵌入式设备中也十分突出,2014年Andrei Costin和Jonas Zaddach等人对互联网上可下载的嵌入式设备固件镜像进行了大规模分析,发现一些镜像中可以直接提取出它们的自签名证书和对应的RSA私钥,同时,这些证书被大约35000个在线设备使用,大多和监控摄像机有关。同时,固件镜像中还能提取出硬编码的密码hash,这些密码在hash时使用了脆弱的hash函数,可以很容易的获取hash前的原始密码。部分嵌入式设备中还硬编码了远程登录凭证或者web登录凭证,影响成千上万的设备,这些硬编码的信息能够很容易被攻击者获取到,进而发起攻击。由于很多的设备是监控摄像机,家用路由这样的设备,被攻击者控制后,大量用户隐私会被泄露。

Reference

  • [1] Duong T, Rizzo J. Cryptography in the web: The case of cryptographic design flaws in asp. net[C]//Security and Privacy (SP), 2011 IEEE Symposium on. IEEE, 2011: 481-489.
  • [2] CVE-2005-1794. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1794
  • [3] CVE-2008-2369. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2369
  • [4] Rizzo J, Duong T. Practical Padding Oracle Attacks[C]//WOOT. 2010.
  • [5] Jager T, Somorovsky J. How to break XML encryption[C] Proceedings of the 18th ACM conference on Computer and communications security. ACM, 2011: 413-422.
  • [6] Somorovsky J, Schwenk J. Technical Analysis of Countermeasures against Attack on XML Encryption—or—Just Another Motivation for Authenticated Encryption[C]//Services (SERVICES), 2012 IEEE Eighth World Congress on. IEEE, 2012: 171-178.
  • [7] Lenstra A K, Hughes J P, Augier M, et al. Ron was wrong, Whit is right[J]. IACR Cryptology ePrint Archive, 2012, 2012: 64.
  • [8] Boneh D. Twenty years of attacks on the RSA cryptosystem[J]. Notices of the AMS, 1999, 46(2): 203-213.
  • [9] J. HASTAD, Solving simultaneous modular equations of low degree, SIAM J. Comput. 17 (1988), 336–341.
  • [10] D. COPPERSMITH, M. FRANKLIN, J. PATARIN, and M. REITER, Low-exponent RSA with related messages, EUROCRYPT ’96, Lecture Notes in Computer Science, vol.1070, Springer-Verlag, Berlin and New York, 1996,pp. 1–9
  • [11] D. COPPERSMITH, Small solutions to polynomial equations, and low exponent RSA vulnerabilities, J. Cryptology 10 (1997), 233–260.
  • [12] http://www.appbrain.com/stats/number-of-android-apps
  • [13]http://techcrunch.com/2014/06/02/itunes-app-store-now-has-1-2-million-apps-has-seen-75-billion-downloads-to-date/
  • [14] Egele M, Brumley D, Fratantonio Y, et al. An empirical study of cryptographic misuse in android applications[C] Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security. ACM, 2013: 73-84.
  • [15] M. Bellare and P. Rogaway. Course notes forintroduction to modern cryptography. cseweb.ucsd.edu/users/mihir/cse207/classnotes.html.
  • [16] Brubaker C, Jana S, Ray B, et al. Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations[J].
  • [17] https://www.imperialviolet.org/2014/02/22/applebug.html
  • [18] Fahl S, Harbach M, Muders T, et al. Why Eve and Mallory love Android: An analysis of Android SSL (in) security[C]//Proceedings of the 2012 ACM conference on Computer and communications security. ACM, 2012: 50-61.
  • [19] Georgiev M, Iyengar S, Jana S, et al. The most dangerous code in the world: validating SSL certificates in non-browser software[C]//Proceedings of the 2012 ACM conference on Computer and communications security. ACM, 2012: 38-49.
  • [20] Costin A, Zaddach J, Francillon A, et al. A Large-Scale Analysis of the Security of Embedded Firmwares[C]//USENIX Security Symposium. 2014.
  • [21] random(4) Linux manual page. http://www.kernel.org/doc/manpages/online/pages/man4/ran- dom.4.html
  • [22] Wu H. The Misuse of RC4 in Microsoft Word and Excel[J]. IACR Cryptology ePrint Archive, 2005, 2005: 7.

转载自:http://cryptomisuse.org/blog/2049/10/01/About-us/