区块链中“鸡肋”的RPC漏洞 – 作者:kmsrussian-安全小百科

*本文原创作者：kmsrussian，本文属于FreeBuf原创奖励计划，未经许可禁止转载

一、前言——NEO RPC漏洞之争

12月1日下午16:34，腾讯湛卢实验室宣布发现NEO的RPC漏洞。官微发文如下：

而NEO官方微博，在四个小时之后迅速回应腾讯，回应如下。

谁对谁错？公链RPC模块安全情况到底如何？

二、RPC和RPC漏洞介绍

首先介绍下RPC。远程过程调用（Remote Procedure Call）是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。如果涉及的软件采用面向对象编程，那么远程过程调用亦可称作远程调用或远程方法调用。

古老的如微软的一些RPC漏洞，通过畸形的RPC请求，触发C/C++的字符串拷贝连接之类的问题，造成内存覆盖，引发安全漏洞。因为漏洞的表现方式是与编程语言密切相关的。微软的很多问题组件基本都是使用C/C++语言开发，所以存在内存覆盖这样的安全问题。并且伴随着SDL的推广，类似当年的MS08-067的“盛况”很难再现。

2.1 公链和代币使用的编程语言多样

在区块链上面，由于代币和公链的开发语言多样，如比特币、EOS、XRP、XLM、DASH、XMR的主流客户端使用C/C++开发，ethereum、bytom等的主流客户端使用的是内存安全的Go语言实现。而很多志在构建基于分片、并行、分布式区块链网络的公链，从一开始就选择的是函数式编程语言。如Rchain使用Scala语言开发，Aeternity使用Erlang语言开发。使用函数式语言开发的公链，除去逻辑类漏洞，语言层面就杜绝了过程式语言存在的一些安全隐患。

2.2 同一条公链存在不同语言的客户端实现

一条公链存在各种语言实现的不同版本。比特币节点的主流客户端使用C/C++开发，如satoshi客户端，但是同时还存在对开发者友好的客户端。如javascript语言开发的bcoin，go语言开发的btcd。以太坊方面，主流的以太坊客户端Geth使用Go语言实现，大概占所有节点的80%。基于Rust语言实现的Parity-ethereum占所有节点的20%，剩下的CPP-ethereum、Python-ethereum、Java-ethereum一般只存在研究价值，即使存在漏洞也不容易引发实际的安全问题。而此次腾讯号称“存在问题”的Neo主流客户端是.Net的实现，一般运行在windows系统上。

以上几点造成了RPC漏洞在区块链上的表现方式差异极大。

三、区块链上的RPC和鸡肋的区块链RPC漏洞

首先介绍下区块链中RPC接口使用的流程和场景。以比特币举例，交易所如何判断用户的比特币的确充值成功了呢？一般会在内网中做网段和环境隔离，然后使用docker部署一个对应的全节点客户端，如比特币可以部署bcoin的全节点客户端。然后对RPC接口调用权限进行设置，一般来说公链都会使用username和password的方式来确认调用者有权限调用RPC接口。此时程序鉴权成功后，通过调用bcoin客户端提供的rpc api接口Getblock by height，轮询新区块中是否有用户充值的交易，然后等待对应的确认数后，返回给用户成功充值的消息。

在这个RPC调用的过程中，重要的一点是鉴权，鉴权成功后才有权限调用对应的RPC接口。一般公链的都会提供CLI工具给使用者，用来配置RPC是否开放和开放后的鉴权方式，默认RPC接口在被本地调用的时候是不需要鉴权的，在被远程IP调用的时候，即使对应的RPC接口存在漏洞，由于鉴权无法通过或者该RPC接口根本没有配置开放，攻击者也是没有办法触发RPC漏洞的。

BTC/DASH/XMR等Coin一般存在2个模块，RPC模块和P2P模块。公链由于需要执行合约、通常图灵完备，一般比Coin多两个模块，虚拟机和编译器。而不管在Coin还是公链中都存在的RPC漏洞都很鸡肋，原因就是RPC需要鉴权后才可调用，很难在真实环境中产生安全影响。

下面介绍下区块链中曾经的或者还是“0day”的RPC漏洞

3.1 RPC鉴权设计引发的安全漏洞

目前来看，该类漏洞危害最大，但几乎没有。暂时也还没有发生类似于路由器后门万能密码的漏洞。目前只在bitcoind and Bitcoin-Qt早期版本有一个可以猜密码的漏洞，CVE-2013-4165(注意此漏洞只影响这两个版本的比特币实现，并不影响go版本的btcd和javascript版本的bcoin)。

bitcoind 0.8.1中bitcoinrpc.cpp中的HTTPAuthorized函数在检测到密码的第一个错误字节时提供有关身份验证失败的信息，这使远程攻击者更容易通过猜测爆破攻击来确定密码。

3.2 Post过程中，触发特定语言版本公链的RPC漏洞

表现的比较典型的就是cppethereum的CVE-2017-12119。前面已经说过，cppethereum是以太坊一个研究性版本，实际中几无影响，并且rpc类漏洞，攻击者必须鉴权后才能调用，更加大大削弱了该漏洞的实际影响。该漏洞由思科的talos团队上报发现。https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0471

在调用cppethereum的rpc接口的时候，攻击者可以Post传递一个畸形类型的参数，使得类型检查不通过,可以直接导致cpp ethereum崩溃。

注意此类漏洞完全不影响以太坊主流客户端geth和Parity-ethereum。

3.3 RPC设计引发的逻辑类盗币漏洞

目前来看以太坊和EOS都有类似问题。以以太坊举例。

以太坊对于账户的RPC调用支持unlockaccount api。

https://github.com/ethereum/go-ethereum/wiki/Managing-your-accounts

可以看到，需要提供地址，密码和解锁时间。问题就出在解锁时间上面，一旦解锁，该钱包若还暴露在公网上，在duration期间的钱包，任何人在duration这段期间都有权限将钱包中的eth转走。

整个攻击流程如下：攻击者预先扫描 8545 端口（HTTP JSON RPC API）、8546 端口（WebSocket JSON RPC API）等开放的以太坊节点，遍历区块高度、钱包地址及余额，一旦有余额的地址处于unlock duration，重复调用 eth_sendTransaction 将余额转空。

EOS也支持账户解锁函数，见https://developers.eos.io/eosio-nodeos/v1.1.0/reference#wallet_unlock。逻辑和攻击手法相同，不再分析。

3.4 配置安全引发的问题

前面已经说过RPC调用是要鉴权的。如比特币的bcoin客户端，要远程调用rpc接口必须提供用户名和密码。很多公链，如bytom，默认配置文件即是127.0.0.1，也即本地发起的rpc调用是不需要认证的，通过远程IP发起的rpc调用必须提供用户名和密码，否则无法进行rpc调用。但是如果用户错误配置rpc，如弱密码或者取消鉴权此时就会带来安全隐患。

3.5 接口实现逻辑不严谨引发的漏洞

这里我们以Go语言实现的bytom举例，其他公链若有类似逻辑请自行查证。

一般来说公链中都会支持钱包配置文件的备份和恢复，备份一般不会产生问题，但是此时的恢复，恢复本质上是接收外界的post参数，然后公链的进程要往所在的操作系统或者docker中的系统写入一个文件，如果在post传递参数上传递的是跨目录覆盖掉系统关键文件的参数，结果如何呢？Bytom的早期的版本就存在这样的一个漏洞，调用restore-wallet，传递畸形的post参数，在恢复钱包文件的时候可以引发系统关键文件被覆盖，造成远程代码执行。但是注意，攻击者想利用该漏洞也得通过RPC的鉴权，才有权限调用该接口。

修复起来就相对简单。敏感性接口，逻辑实现上一定要禁止跨目录的操作。