公告 由于 OSS 私钥外流,导致 Ruby China 备份泄漏...

huacnlee for Ruby China · 2016年06月13日 · 最后由 xieguanliang 回复于 2016年06月19日 · 10694 次阅读

今天收到 WooYun 的通知,说 Ruby China 的数据库泄漏了... 😰

这件事情是我的疏忽,Ruby China 有个每日备份(包涵数据库,私密配置文件),定时往 Aliyun OSS 上存放备份的打包文件。

泄漏原因

曾经在 carrierwave-aliyun 的测试里面有个测试用了一个 OSS access_key,当初是用于一个用于开发测试的 Bucket 空间,但不知道什么时候开始,这个 key 有了访问 Ruby China 那个 Bucket 的权限(可能是久了无意中加上了...)

而这个泄漏的 key 是在 2013 年就有了,最初的时候没有太注意,权限过大,而那个 Bucket 几乎没怎么用,也就用于备份,已经都很久没访问过那个 Bucket 的账号了。

于是拿到那个 Key 以后就能下载到 Ruby China 历史上的所有备份文件了。

处理方案

在收到 WooYun 的通知以后,已经在第一时间删除了泄漏的 access_key 对 OSS 空间访问权限,同时清理了历史的备份文件。

接着更换了服务器上的各种私钥文件,包涵:

  • config/secrets.yml
  • config/config.yml [UpYun, PostMark, GitHub 等私钥]

所幸的是,备份里面没有包含 SSL 证书之类的东西。😓

重要!

  • 关于网站密码,由于账号密码是加密了,问题不大,但存在暴力破解的风险。
  • 如果你又在记事本里面存放重要信息,比如密码什么的,请尽快修改。

反思

这件事情的发生,源于私钥访问权限过大而导致的,看似 Ruby China 本身备份用的是另外一个 Key,但泄漏那个 Key 却有足够的权限访问关键的 Bucket。未来应该更细致的管理好这些私钥,不要混用。

刚才确认了一下,早期阿里云 AccessKey 是没有单独管理的,一个 AccessKey 权限是很大的:

云账号 AccessKey 有所有 API 访问权限

好严重,现在网络环境太复杂,天天有人在爬 github 上误传的各种邮箱和密码。 阿里云新出了个 RAM 访问控制,可以限制每个 key 的详细权限

难怪,就说为啥无缘无故,需要登录

aliyun 和度娘普遍实现的都是 STS 鉴权。但另外带一个 Token 没啥必要性,有低权限的 Accesskey/Secret 对就应该足够了。上面说的 RAM 控制还没有普及,但 AWS 最初实现的就是这种,差距就在这里了。

哇晒,我在 note 里珍藏的小黄文都被脱了么?还好是 devise,密码无碍。

#4 楼 @huobazi 忽然对被脱的数据有兴趣了

"关于网站密码,由于账号密码是加密了," 这句话没写完?

#6 楼 @peter 没说啥算法和循环次数...

早就泄漏了是么?😱

玩脱了。。。

不用 ENV 是万恶之源。在教训中学习了。

#1 楼 @embbnux 我们就天天在爬,主要是担心公司内有人把代码上传到 github,同时里面还带有密码。。。

@ashchan 你们的 ENV 如何管理?

#13 楼 @tumayun 本地由 developer 自己决定怎么管理。我个人使用 direnv,每个项目下有个 .envrc 文件来保存 ENV 的键值(切记要 gitignore 掉)。

服务端也有不同的方式,不管用哪种,主要要做到:1)千万别入代码库,2)访问权限隔离到 deploy 或 web server 的用户组。

我自己大部分项目都 host 在 Heroku 上,直接用它的 ENV 管理。

#13 楼 @tumayun rbenv 有个插件,我用那个,不过和楼上一比看起来好 low 的样子

#15 楼 @numbcoder dotenv 是侵入性的。我的意思是,管理 ENV 不该是代码依赖的某个 gem 的责任。当然这仅仅是我个人看法 ;-)

我的数据库备份文件都是加密了再放上 OSS 的,加密密码超过 64 位的随机字符串,密码存在 1Password 上

密码的加密方式是 bcrypt 还是什么?

#20 楼 @huacnlee 大致每个用多少 CPU 时间?

huacnlee [该话题已被删除] 提及了此话题。 08月31日 20:22
需要 登录 后方可回复, 如果你还没有账号请 注册新账号