RSS Feed
更好更安全的互联网

特性导致的安全问题之github被黑

2012-03-06

余弦(@evilcos)

一些资料

github昨天被黑了(在这:wow how come I commit in master? O_o),讨论的很激烈。这个过程有人分析了(这:Hacking Rails (and GitHub)),这次被黑是因为rails的一个特性导致的安全问题(这里已经分析的很详细了:從Github被Hack,談Rails的安全性(Mass-assignment))。

特性害死人

我对rails不熟悉,不过看他们的分析,是由于外部进来的一组变量直接被map进模型中(变量名与模型的字段一一对应,模型的后面可是对应了数据表,多方便啊),这好像没啥奇怪的,不过由于一组变量名与模型的字段是对应的,在rails这个map机制下,可以提交一些本来没对外暴露的字段对应的变量名,这个可能导致字段原来的变量值被覆盖(整个过程类似PHP的变量覆盖风险)。可以覆盖了,那就可能导致各种安全问题。

github本身是基于rails构建的网站,这次被黑针对的就是rails官方自己的github账号(https://github.com/rails),它的SSH keys管理页面被攻击者提交了一个新的SSH key(一次表单提交过程),这是越权了,本来攻击者只能给自己的账号添加SSH key,但是通过rails这个特性,在提交表单时增加public_key[user_id]变量,值为4223(正是rails的user_id号),这个外部提交的值覆盖了攻击者自己的user_id值,这就导致rails账号增加了一个攻击者设定好的SSH key,于是后面就可以进行各种操作了。

被黑就是这样发生的,rails表示无语,本来这是一个特性,多方便,而且也知道如果使用不当可能导致安全问题,于是rails早就给出了安全建议,在使用这种map机制之前,有个attr_accessible属性可以设置从外部提交的白名单字段。或使用attr_protected属性设置黑名单,这样设置后就可以很好杜绝敏感字段被外部提交任意值的风险。如果程序员不懂这个特性,缺乏安全意识,那就悲剧了。

后话

攻击者发泄了,github也紧急响应了。rails估计还是无动于衷,他们始终认为这是特性,他们把安全让程序员去买单。特性害死人啊!写这篇文章(從Github被Hack,談Rails的安全性(Mass-assignment))的作者最后拿django xss防御作为例子来做类比说明是很有道理的。默认就应该是严格的安全的,符合大众思维,然后才是在这个大前提下进行各种后续处理。

提醒使用rails的同学们注意这个特性,你比我熟:)

针对“特性导致的安全问题”系列文章,下一篇我会分析twitter bootstrap的一个特性可能导致XSS攻击发生,我们汇报给官方,不过人家认为是特性:(

《特性导致的安全问题之twitter bootstrap xss风险》已出!

作者:余弦 | Categories:安全研究漏洞通告 | Tags:

5条评论

  1. sen哥说道:

    如果RSA说 ,某种情况下大素数配对被攻击是特性。。
    如果SSH说,HTTPS可以被中间人仿冒是特性。。
    如果很多应用的弱口令也是特性。。
    如果说堆栈漏洞和WEB漏洞也是特性。。
    那,我们真的被特性了

    • 余弦说道:

      我们真的被特性了,每个框架、模块都有自己的法则,我们都得去了解,否则安全最终还是我们来买单,有些框架或模块会很霸气的告诉你:“这就是我们的法则。你喜不喜欢,反正这就是法则……”
      其实很多时候确实不能怪框架,具体得看实际场景了。

      话说回来:
      特性绝对会导致意识上的差异,意识差异绝对会导致安全问题。比如浏览器之间各种特性导致的差异,然后导致自己特有的安全问题。主机上也是,例子太多了。
      无论如何,我们希望通过我们的经验,写出系列文章出来,让更多人能避免,这样我们的目的就达到了:)

  2. 黑色幽默说道:

    建议给能链向其他地方的文字来个不同的颜色。。

  3. Hysia说道:

    特性都要程序员买单,但是框架本身要至少要强势告诉程序猿可能导致的安全问题啊

发表评论