“ ROBOTATTACK是一个寿命十分长久的漏洞,至今已有19年的历史。ROBOTATTACK允许攻击者使用服务器上的私钥对传输数据进行解密操作以及使用服务器上的私钥进行签名操作。”
0x01. 简介
在1998年的时候,Daniel Bleichenbacher发现了一些 SSL服务器上给出的关于 PKCS #1 1.5的错误信息可被进行选择密文攻击(adaptive-chosen ciphertext attack,后续用CCA表示)。在这种情况下,服务器如果选择使用RSA进行加密的时候,将会完整的破坏TLS的机密性。
注意:ROBOTATTACK 不会泄露私钥,它只允许攻击者使用服务器的私钥进行解密或签名。
而现在,仅仅需要通过一些小小的技巧进行探测,即可发现这个漏洞仍在当今许多HTTPS服务器中存在。
需要注意的是,ROBOTATTACK 不仅仅针对TLS,同时还在 XML Encryption,PKCS#11 interfaces,Javascript Object Signing and Encryption (JOSE)以及 Cryptographic Message Syntax / S/MIME 发现了类 Bleichenbacher的攻击方式。
0x02. 漏洞原理分析
PKCS 是什么
The Public-Key Cryptography Standards (PKCS)是由美国RSA数据安全公司及其合作伙伴制定的一组公钥密码学标准,其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议
PKCS #1 1.5简单介绍
PKCS #1 RSA Encryption Version 1.5
在进行RSA运算时需要将源数据D转化为加密的信息块。其中 pkcs1padding V1.5的填充模式安装以下方式进行
EB = 00+ BT+PS +00 + D
EB:为转化后Hex进制表示的数据块,密钥1024位的情况下长度为128个字节
00:开头为00。
BT:用一个字节表示,在目前的版本上,有三个值
00,01,02,如果使用公钥操作,BT永远为02,如果用私钥操作则可能为00或01。为填充位PS由
k-3-D这么多个字节构成,k表示密钥的字节长度,D表示明文数据D的字节长度 对于BT为00的,则这些字节全部为00,对于BT为01的这些值全部为FF,对于BT为02的,这些字节的值随机产生但不能是0。00:在源数据D前一个字节用00表示
D:实际源数据
PKCS #1 1.5 Bleichenbacher CCA
在使用PKCS#1 v1.5 RSA 加密某些内容的时候,首先要填充加密的数据,然后将填充的数值转换为整数的形式,随后使用后公共指数进行RSA模幂运算。在利用私有指数进行模幂运算进行解密后,删除填充部分。在 Daniel Bleichenbacher的CCA攻击中,核心是依赖 oracle进行的,即系统中存在一个方法,能够通过给一个特定的加密消息长度的序列,对其解密后将生成有一定填充格式的内容或空内容的一个方法。
一个正常提供SSL/TLS服务的服务器在进行初始化信息的时候,客户端应该生成一个随机密钥(pre-master secret,预主密钥),用服务器的公钥对其进行加密并发送。服务器解密该值,获得 pre-master secret,然后根据该 pre-master secret计算用于连接的其余部分的对称加密的密钥。根据RFC标准的要求,客户端发送 ClientKeyExchange(其中包含加密的pre-master secret)进行交换,然后进行加密算法协商 ChangeCipherSpec,然后Finished`,这个最后的消息用派生的对称密钥加密,并且其内容由服务器验证。 示例图:

如果客户端向服务器发送一个随机的正确长度的字节序列,而不是正确加密的预主密钥,那么服务器在大多数情况下会响应一条错误消息,告诉客户端:“我试图解密你的 ClientKeyExchange内容,但是这个失败了,没有一个适当的填充”。然而在偶然的情况下,应用模幂运算后随机字符串可能会产生一些真正看起来像是正确填充的 pre-master secret的东西,这时候服务器不会抱怨 ClientKeyExchange,而是反馈关于 Finished将被错误加密的消息。而这个正是攻击者想要拿到的信息———发送的字节序列在进行解密的时候的填充状态(正确填充/不填充)。
在 PKCS#1 1.5中,填充的相关公式已经在上面一个小节进行了简单的阐述了,下面将描述如何利用 PKCS#1 1.5的填充特性进行CCA,不过在说攻击要点前先说一下简单定义,n为公共模数,M为用 n加密的消息(通常来说,M为 pre-master secret)PKCS#1 1.5为了方便填充后的总长度等于 n,会在真实数据左边填充一些非零数据,即上述的 PS段。在密钥长度为2048位的情况下经过填充的 M数值应该为256 bytes。 一条附带正确的完成填充的消息的是这样的:
00 02 PS 00 M
其中 PS所填充的字段应该为随机并且非0的字节,并且总长度应该等于 n。既得出一下公式:
PS = n - len(M) - 3
SSL服务器再对其进行解密查看时,会首先查看前两个字节,查看他们是否为 00 02,而后识别下一位为0的字节(即跳过PS段)。
攻击的时候需要以下基本要素:
ssl服务器根据是否正确找到
PKCS#1的填充来回复不同情况下的错误信息,或能根据相关信息泄露判断对应的错误信息。攻击者需要通过监听
ClientKeyExchange来发现经过加密的信息c:

攻击者通过生成大量特殊链接去链接服务器。其中每个链接在处于 ClientKeyExchange阶段时,都会生成一个值 s,这个值符合以下条件:

服务器处理这一段信息时候,就会误认为这个就是看是正确的信息,当作真正的 pre-master secret进行解密。然而在很多情况下,这个所发出去的值经过解密后并不符合 00 02这个要求。但是尽管如此,还是有小概率事件,能够在服务器进行解密后符合 PKCS#1 1.5的标准格式。一旦这种情况发生,攻击者就能缩小器猜测范围,在经过数百万次的尝试购机者就有了足够多的信息去计算得出 pre-master secret,从而让ssl服务器在选择使用RSA的相关算法进行加密时的机密性崩溃。
ROBOTATTACK
ROBOT的攻击手法与 Bleichenbacher的CCA手法类似,但是 ROBOT的攻击的地方不仅仅局限于 ClientKeyExchange,由于TLS在升级的时候采用的修补方式更加偏向于保持现有的加密方案增加对应的对策,但是这些对策仍然时不完善的,尤其是在实现上。
同时需要注意的是,ROBOTATTACK不仅仅针对TLS,同时还在 XML Encryption,PKCS#11 interfaces,Javascript Object Signing and Encryption (JOSE)以及 Cryptographic Message Syntax / S/MIME发现了类 Bleichenbacher的攻击方式。其实总的来说,就是只要存在类似 PKCS#1 1.5的加密填充方式,都有可能遭受到危害。
0x03. POC分析
下面简单对 robotattack中所提供的python tools(即是所谓的POC) 进行一个简单的分析。
https://github.com/robotattackorg/robot-detect
此poc通过校验SSL服务器是否存在RSA加密套件,如果存在则校验在此SSL服务器内是否存在 oracle特征,如存在则受影响。
这里提供在ubuntu下poc使用环境的快速使用方式:
sudo apt update
sudo apt install python3-dev python3-openssl python3-gmpy2 -y
git clone https://github.com/robotattackorg/robot-detect.git
cd robot-detect
python3 robot-detect [host]
0x04. 已公布的受影响厂商
F5 -- CVE-2017-6168
Citrix -- CVE-2017-17382
Radware -- CVE-2017-17427
Cisco ACE -- CVE-2017-17428
Cisco ASA -- CVE-2017-12373
Bouncy Castle -- CVE-2017-13098
Erlang -- CVE-2017-1000385
WolfSSL -- CVE-2017-13099
MatrixSSL -- CVE-2016-6883
Java / JSSE -- CVE-2012-5081
0x05. 更进一步的影响范围
Bleichenbacher这种攻击方式不仅仅适用于SSL服务器上,在很多地方都有类似的漏洞,如:
XML Encrypt
PKCS#11 interfaces
Javascript Object Signing and Encryption (JOSE)
Cryptographic Message Syntax / S/MIME.
QUIC
ACME
...
说到 ACME,可能大多数人想到的就是 let's encrypt用来做证书校验的 ACME,没错,就是那个 ACME。如果RSA私钥在服务器的其他地方做了引用,攻击者就有可能利用 ROBOT这种攻击方式,撤销证书的信息,从而影响到服务器的运作,当然了,这里并不会破坏TLS的机密性。
0x06. 建议修复方案
在正常情况下,大多数SSL服务商是不受影响的,大家不必过分惊慌。修复方案如下:
停止使用RSA加密套件,更换成国密系列或DH系列。
0x06. 相关资料
https://robotattack.org
https://en.wikipedia.org/wiki/PKCS
http://archiv.infsec.ethz.ch/education/fs08/secsem/bleichenbacher98.pdf
https://crypto.stackexchange.com/questions/12688/can-you-explain-bleichenbachers-cca-attack-on-pkcs1-v1-5
https://eprint.iacr.org/2017/1189.pdf
https://www.cnblogs.com/1024Planet/p/5265425.html
0x06. 其他信息
如对上述信息有什么疑问或不对的地方,可在底部评论区留言,欢迎探讨交流,共同进步。

