在七年前开发人员发现GitHub存在一个灾难性的漏洞之后，GitHub已经关闭了数量不明的通过密钥访问的账户。

Github允许授权用户登录到隶属于Spotify、Yandex和英国政府的公共仓库账户中，而这些公共仓库账户却使用了由当时存在缺陷的Linux发行版本Debian生成的SSH密钥，而这部分密钥是不安全的——其密钥的位数太少以至于可以枚举导致暴力破解，分分钟登录这些存在威胁的账户中。

七年后，Debian社区的朋友们修复了bug并且提醒用户取消旧的密钥而重新生成一个。伦敦的开发人员Ben Cartwright-cox说，他发现了这一漏洞仍然存在于海量密钥中，而这些密钥因位数不足比较容易被人攻击利用。

Cartwright-cox在周一发表的博文中称：

“如果你刚刚或者正收到一封关于密钥被撤销的邮件，那请你务必仔细浏览并且确保确实没有人攻击你。如果你使用了存在问题的密钥，你可能已经遭到了黑客的攻击。”

密钥数量有限？

Cartwright-Cox在GitHub上发现了大约94个包括Debian衍生缺陷的密钥。3月份他向GitHub官方报告之后，才发现实际用户数量要高得多。GitHub于上月撤销了这些密钥，目前GitHub官方没有作出其他回应。

此外，Cartwright-cox发现了九个GitHub SSH密钥bits数量存在严重不足。其中有两个只包含256位，导致他能够在不到一小时内克隆出密钥，而剩余的其他7个密钥都只有512位。

漏洞描述

下面我们看一下这个Debian的漏洞是如何导致枚举的。

该漏洞可谓是十分亮眼。因为漏洞的存在，使得生成的SSH密钥长度非常短。当生成OpenSSH密钥的位数不足时，对于一个给定体系结构、密钥大小和密钥类型而言只有32767种输出结果。攻击者能够使用相同方法找到弱密钥，然后使用一些技术来获取密钥保护的账户。这一任务会在不安全Debian SSH 密钥的帮助下获得一个或者更多公共网站，比如这一个：

“如果我想折腾得动静大一些，我大可去做我在博客中提到的那些事情，然后或许可以给GitHub他们一些警示（我已经给了他们机会的）。
想要制造这样的问题可以如下进行：
获取问题密钥列表。其中包含了所有SSH密钥的公共和私密部分，如果用户有一个存在Debien RNG 漏洞的OpenSSH版本，然后得到列表中的每个密钥，并尝试登录带有密钥的GitHub ssh。你使用密钥最终会告诉你与之匹配用户姓名是什么然后进行配对，比如加载我的密钥便时会显示"Hi benjojo! You've successfully authenticated, but GitHub does not provide shell access."，但如果我使用的是另一个存在缺陷的密钥，则会显示"Hi {user}! You've successfully authenticated, but GitHub does not provide shell access." ，这样我就知道轻松知道我的目标用户是谁了。”

用户：快去更新密钥和操作系统

Rapid7 的高级研究员及Metasploit框架的联合创始人HD Moore表示:

"从技术上讲，攻击者甚至不需要私钥来查看网站接受的用户身份验证。仅仅是公共密钥和Metasploit模块就能够完成了。"

这个漏洞于2006年被发现，当时鉴于一些用户提交的漏洞报告，Debian维护人员最终去掉了OpenSSL代码库的两行代码。而Debian的维护人员仅仅是去掉了Debian对于OpenSSH的依赖，因此这个存在于OpenSSH中的位数缺陷并没有被修复，接下来的故事更戏剧化，Ubuntu在不知情的情况下也打包了这个存在缺陷的OpenSSH版本，所以这个漏洞又跑到了Linux的另一发行版本Ubuntu中，而在此后的20个月中，并没有人发现这个从Debian跑过来的重大问题，而就在这20个月里，有一批数量不明的密钥已经生成。

这个问题并不是一个小问题，因为这批数量不明的SSH弱密钥还大量存在于Github中，补丁也只能保证从此刻开始新生成的SSH密钥的安全性，想要完全解决问题，还需要用户主动去撤销那些在20个月内生成的存在缺陷的密钥，并使用新的操作系统以生成新的密钥。由此看来，想要彻底解决这个问题，任务量不可小觑。

[注意]APP应用上架合规检测服务，协助应用顺利上架！