Coinapult 被盗事件自查报告

未知来源 阅读 61 2015-3-19 02:20
分享至
微信扫一扫,打开网页后点击屏幕右上角分享按钮

Coinapult 被盗事件自查报告

报告摘要

2015 年 3 月 17 日 09:27 UTC,一个未经授权的提现请求将 150 个比特币从 Coinapult 的热钱包送到这个地址:12LszeXACdj9bdETzv8BkXyWeabZ1151aA

其交易 ID 是: a050ffade5baac2c58dc17db27a1b1a12f7efcdafc3c41f559f0e1bb7177f474

截至至当前时刻,这些比特币并没有被另移他用。

译者点评:清晰明了,简单易懂。毕竟这份文档也不算对客户的公告,道歉神马的不提也罢。

涉及人员

Ira – CEO,有服务器的物理访问权限和 SSH 访问权限

Zach – IT 管理员,有服务器的物理访问权限和 SSH 访问权限

GP – CTO,有服务器的 SSH 访问权限

Cindy – 程序员兼取证专家,有服务器的 SSH 访问权限

Justin – COO,无服务器的访问权限

Robinson – 客服,无服务器的访问权限

其中有两个人可以直接接触到受影响的服务器,这些服务器安置在有物理安全层的三级数据中心里面。

其中有四个人能通过 SSH 密钥访问存有热钱包的生产财务服务器。要想连接到财务服务器,这些人需要先登陆到公司的 VPN,然后在命令行里通过 SSH 登陆到服务器。

上述几个密钥持有者的笔记本电脑在事件发生后都进行了网络活动检查,但没发现存在可疑的迹象,除了 Zach 的笔记本电脑里有些不太正常的行为让人想到了中间人(MITM)攻击。虽然我们使用相同的本地网络,但他的 IP 地址却有一些异样。我们在发现这一点后,Zach 马上将电脑关机并取下硬盘方便取证。

译者点评:拥有访问权限的人全部罗列出来,包括 CEO 也不例外。这一点值得点赞,毕竟说不定这是内部人员所为。关机取下硬盘这也是个保护证据的好做法。

作案时间

上周五 3 月 13 日里发生了两件事,这可能与此事件有关。

一,财务服务器所托管在的数据中心经历了一整天的中断。受此影响,巴拿马政府网站和其他许多本土企业也停机了,而数据中心的电话也无法接通。为了恢复服务,Zach 那天几乎登陆了该数据中心的所有服务器。

二,GP 写了一个将所有服务从该数据中心迁出的计划并通过电子邮件发送给Justin, Ira 和 Zach,这可能是给攻击者的最后提醒的机会,因为他们的渗透工作将在数据迁移后功亏一篑。

除了以上两件事之外,最近的两周里系统的稳定性也经常出现问题。我们遇到了硬盘驱动器的问题,CPU 的问题,以及其它所带来的影响。虽然大多数的这些原因是已知的,但这也可能预示着背后有一些是恶意或隐蔽的活动。

译者点评:服务器里面硬盘集体崩溃的事情虽然会让运维人员很抓狂,不过这事也不算太少见。CPU 问题就不知道是不是集体烧 CPU 的极小概率事件了。但如果真是外人所为,上面两件事的确很有嫌疑。

线索之一:财务服务器

/var/log/auth.log 看起来被修改过,在 10:24 至 10.27 UTC 时间里这一条空行,而 auth.log.1 文件是空的。auth.log.1应该饱含最近几天的数据。

/root/.bash_history 最后修改于 3 月 14 日 19:38 UTC,最后的 4 项是:

nano auth.log nano syslog nano ufw.log ls

这些命令看起来应该是攻击者运行的,因为这不符合 Coinapult 组员的使用模式。看起来像是攻击者在离开后又重新返回,试图打开这些重要的日志文件进行掩盖,由于没有输入其它的命令,这预示着其很可能拥有根用户(管理员)权限,针对该硬盘的取证分析可能会证明这一点。此外,利用“nano”的做法也很奇怪,因为大多数黑客会选择不同的文本编辑器。

译者点评:Nano! 居然用的是 Nano!在这一刻 Vi 党和 Emacs 党都将不得不停止争纷。如果黑客不是为了避免留下线索而用的 nano 编辑器的话,这还真有一些不同寻常了。

线索之二:API 和数据服务器

在受到攻击的时候,API 服务器将消息发送到事务处理引擎(在数据服务器上)花了 30 分钟,这使得顾客 A 在 09:15UTC 时联系了 Robinson。造成这情况的原因暂未查明,不过这些服务器中有一台被攻陷后都将不允许直接访问热钱包或财务服务器。

译者点评:从这点来看,该团队本身在安全方面还是花了些功夫的。从后边的时间轴来看的话,反应也还算是迅速。如果有加上热钱包的余额监视邮件提醒功能的话,或许还能更早察觉。

线索之三:SaaS 服务器

Coinapult 还有在租用的 SaaS 服务器上运行第二组的生产服务器。这些 SaaS 的服务器具有相同的访问权限与 Coinapult 自家的服务器相同(2 物理访问,4 个 SSH 访问)。在被盗窃的时候,SaaS 上的的财务服务器有超过 500BTC 在里面,它们都没有触及,这表明黑客不知道那个钱包。当然,这笔资金现在已经被转移,现在都很安全。

译者点评:采用了双生产服务器分别部署使得此次事件没有被一锅端掉,算是不幸之中的万幸了。

事件回放

下面的时间是 UTC-5。

1:49 – Ira 请求从 Bitfinex 提取了 100BTC 放到热钱包 2:36 – Ira 登上 VPN 2:36 – Ira 登上财务服务器 2:37 – Ira 使用了发送多方的功能。这其实没有必要,因为这 100BTC 还没有出现。不过 Ira 没注意到这点。交易 ID 为:3b7e8ac67bf9597fb38a41d1b1354a3d06e9078dd0c191191bae344dc419ec1d 3:55 – Bitfinex 发出 100BTC,交易 ID 为: 4691cf88a74cc752c3777ec9952500cc04bd02ea6f979e326d3550b1581723c3 4:15 - 客户 A 通知 Robinson 关于不正常取消的交易 4:27 – 黑客提款,交易 ID:a050ffade5baac2c58dc17db27a1b1a12f7efcdafc3c41f559f0e1bb7177f474 4:54 – Robinson 给客户 A 发邮件说交易被挂起了,而热钱包的余额出奇的低 4:58 – Robinson 打电话给 Zach, Zach 开始连接 VPN 5:17 – Zach 成功登录上 VPN 5:22 - Zach 登陆到财务服务器 5:31 – Zach 发邮件说程序正在运行,但是他无法评估热钱包的情况 8:42 - Ira 已经做了足够的调查,确定已有 150BTC 被盗,并发邮件告诉了大家。 9:12 - 大部分热钱包里的资金被移到安全的地方。向客户发送通知,并将公告放在我们的网站。团队调查并确定了本报告中的内容。

译者点评:时间地点人物事件四要素全齐了。欲知后续如何,就请继续关注吧。

未来计划

一,我们已经断电,并隔离所有在数据中心的硬件。我们的计划是拆开他们,然后试着从硬盘取证,看看我们是否可以恢复操作日志或其他地方的数据。

二,Zach 正在拆卸他的笔记本电脑硬盘以取证。

三,虽然我们正在将硬件从数据中心中移出,我们会向数据中心要求获取访问日志及有关我们的情况的监控录像。另外,我们将收集有关 3 月 13 日停运的更多信息。

译者点评:关机保护好证据,为了抓取黑客而努力!

译者总结

比特币圈里的黑客事件已经屡见不鲜了,而且相比国内不久前声称丢了几千币的事件,150BTC 似乎实在也不算是什么大不了的事情了。但是对于一个刚起步的创业团队,这可能会是一个灭顶之灾。所幸的是,这个团队没有选择隐藏事实,而是在第一时间内积极应对,并及时地开诚布公。要知道,之前 Bitstamp 也曾经说过要公布详情,结果至今还没有更新。

另外一点,对于个人来说掌握好自己的比特币密钥就好,而对于一个企业而言,如何管理比特币着实是一个痛点。虽然 Coinapult 团队的报告很让人同情,但没有及时引入多重签名来管理公司资金,还是免不了有内部人员作案的可能。希望这次事件,对其也是一个契机。在这一点上,比太钱包之前的公开课《您的企业会管理比特币吗?》,很值得大家认真温习。

March 17 2015 Incidence Report

btcfans公众号

微信扫描关注公众号,及时掌握新动向

来自互联网
免责声明:
2.本文版权归属原作所有,仅代表作者本人观点,不代表比特范的观点或立场
2.本文版权归属原作所有,仅代表作者本人观点,不代表比特范的观点或立场
上一篇:英国财政部计划监管数字货币,增加1000万英镑研究经费 下一篇:苹果下架SaruTobi比特币游戏,理由让人大跌眼镜

相关资讯