程序员大本营GitHub遭黑客劫持,是时候认真聊聊开源代码安全了

图片来源@视觉中国

文 | 脑极体

著名的“交友网站”GitHub是程序员的“大本营”,很多人都将源代码托管在上面,并不断利用社区开源资源开发新的算法、软件、应用。

这样一个极客云集的平台,居然被黑客给一窝端了,委实有点玄幻。

5月2日开始,GitHub遭到了黑客的攻击勒索,有370多名用户的源代码和信息被名为“gitb ackup”的账号删除。

黑客下载了那些代码,并存储到了自己的服务器上。要求他们往特定账户上支付0.1比特币。并进行了恶狠狠发威胁——“如果我们在未来10天内未收到您的付款,会将您的代码公开或以其他方式使用。”

花开两朵各表一枝,这边GitHub程序员忙着找代码, 隔壁微软的开源开发平台也不幸被黑客选中了。黑客擦除了其392个代码储存库,要求微软支付一定的款项才会归还窃取的数百个源代码。

对此,许多受害者认为,开源平台遭受攻击是其上开发的应用程序有漏洞,被黑客利用了。

那么,有什么解决办法么?GitLab建议是,使用强密码降低被破解的风险,开启双重身份验证,使用SSH密钥等……

什么??全球顶尖程序员汇聚的平台,安全措施也这么原始吗?富土康流水线工人、村头王大爷的交友账号也都是这么提示的好吗?

不得不说,GitHub程序员被劫持事件给业界上了生动一课,提醒人们,开源软件和组件的先天不足,可能给普通网民和企业安全带来巨大的风险,尤其是建造着数字网络的“工程师”也可能“打盹儿”的时候。

从GitHub说起:开源社区集体缺了一节“安全行驶课”

1998年,“开源”这一概念被首次提出,到2019年已经度过了20个春秋。凭借着开放、共享、自由等特性,开源平台在软件开发中扮演着越来越重要的角色。Gartner的一项调查显示,有99%的组织在其IT系统中使用了开源软件。

很多我们熟悉的日常软件功能,比如支付账单、娱乐社交、工作效率等等,有60-80%的代码库都来自开源社区。

前不久Snyk 公司发布的2019年开源安全现状调查报告也说明,开源项目的采用率正在以惊人的速度增长。仅是2018年,Java 工具包翻了一番,而 npm 增加了大约 250000 个新的工具包。

(每种语言其生态系统的新漏洞增长情况)

数字时代的进度条,因为开源而飞快加载。但步子迈得太大,也容易摔着。说到影响网络安全的最大掣肘,恐怕也要追溯到开源社区。

Snyk报告中提到,有37% 的开源开发者在持续集成(CI)期间没有实施任何类型的安全测试,54% 的开发者没有对 Docker 镜像进行任何安全测试。这也导致两年时间内,各大平台的应用程序漏洞数量增长了 88%。 GitHub上排名前40万的公共代码库中,仅2.4%有安全文档。而npm 和 Maven 中央仓库的安全隐患尤其严重,因为二者也是工具包数量增长最多的平台。

搞了半天开发者们都是在不系“安全带”的前提下超速飙车啊??话又说回来,漏洞的存在会带来多大的影响呢?

原本不需要这么紧张的,但在开源的情况下,事情就变得很不一样了。

因为当一个开源组件存在漏洞(通常称为CVE)时,这个漏洞会迅速公布。原本,开源可以让更多人及时发现漏洞,并对其执行必要的修复。不幸的是,一些图谋不轨的人也同样可以看到这些信息。

他们几乎不需要付出太多努力,就能了解哪些组件更容易受到攻击以及如何做。然后,找到哪些平台和公司可能会反应迟钝,在被修复之前黑掉他们的系统。

2018年4月,黑客就暴力破解了流行开源Magento电子商务平台的口令,利用拿到的访问权大肆搜刮信用卡记录并安装加密货币挖矿恶意软件。另外诸如著名的OpenSSL水牢漏洞事件、心脏滴血事件、Equifax数据泄露事件、Gmail、yahoo和Hotmail账号泄露等等,都是被黑客抢占了先机。

数据表明,如今开源平台漏洞出现到修复的时间,中位数几乎长达2年之久。这意味着,所有使用了那些漏洞代码或组件的软件用户,只是在黑客们的阴影还没来得及动手的“慈悲”下盲目而快乐地冲浪在网络。

那么问题来了,究竟是什么导致了程序员们如此“心大”,甚至不停地给黑客们“送人头”呢?

自欺欺人的“众人之眼”,与软件开发的三重门

显然,开源代码所谓的“众人之眼”,并不能有效地杜绝安全漏洞,至少不能保证在黑客降临之前消灭隐患。

如今,开源代码爆出安全漏洞的事件还在不停发生,而很多项目并没有查找和修复问题的机制。这么一想,GitHub的程序员用户算是幸运多了,至少他们还能掏赎金把自己的代码买回来。而那些被盗走了信息的普通用户,也许只能成为黑客们的“肉鸡”了。

但问题是,如果我们吃了一家餐厅的食物而中毒了,那么可以起诉这家餐厅。但同样的逻辑在数字世界却不成立了。如果用户因为一个软件而中毒/被盗窃个人信息,他几乎没有办法找平台负责(参考Facebook隐私门)。而且软件开发商还会在用户许可协议中进行“免责”,要求用户同意不因为安全漏洞而起诉它。

为此,剑桥大学安全研究员Richard Clayton博士曾提出,要让软件开发商为可避免的安全漏洞带来的损失负起责任。欧盟官员也一度考虑,试图将开发人员的草率编码行为导致的恶意漏洞引入法律。但最终都不了了之。

微软是这么反驳的:软件公司也是(黑客/罪犯)入室抢劫的受害者,大众不能起诉门和窗户的制造商。

听起来是不是快要被说服了呢?打脸的是,在一个针对500多名开源项目维护者的调查中,清晰地展示了,只有30%不到三分之一的开源工程师具有较高的安全意识。这意味着,程序员和软件开发商并没有如大众期望的那样,将门和窗户建造的更牢固一点。

导致这一现象的,是一种蔓延在整个软件开发产业链上的“迷之自信”:

首先,开源社区顾此失彼的安全审查。一般情况下,为了让开源项目免于灾难,社区会依据Linux的Linus Torvalds,用他们的“千眼”不断地审查代码。运维人员必须十分小心,筛选代码,检查潜在的漏洞,并将其报告给安全数据库。

但是,由于开源资源分布散而广泛,很多漏洞软件会在GitHub,nowhere.net等网站上肆意流通,因此因此持续监控、赶在黑客前面发现漏洞也就成了一项艰巨的任务。

其次,日益消弭的开发门槛和随性的开发者。以往,能够开发开源组件的开发者本身素质相对较高,代码质量较高,也使开源组件出漏洞的可能性较小。但随着许多界面友好的平台出现,像是GitHub,即使是新手编程也可以利用Git;任何人都可以免费注册和托管公共代码存储库,还有人利用GitHub来进行其他类型的项目,比如写书。

缺乏安全基础的开发者增多,许多潜在的组件安全特性被忽略,而这些特性往往是造成漏洞的罪魁祸首。

而且,即使是成熟的开发人员,也需要不断在应用更新过程中解决新漏洞。但很少有程序员会审查旧工程中用到的库,一般就是到开源项目页面下载下来,集成到自己的应用中,然后就再也不管它了。这些软件自然也就像凤梨罐头一样,很快就过期。

在此基础上,企业利用开源软件或组件来进行开发,就像在一个摇摇欲坠的积木塔上盖楼一样,全靠运气。

绝大多数企业的开发团队,对开源软件的使用都非常随意,这就给应用的安全风险管控带来了极大的挑战,运维人员也无法知晓软件系统中是否包含了开源软件,包含了哪些开源软件,以及这些软件中是否存在安全漏洞。

而大多数云供应商在将企业数据上传到集群之前都不会加密数据,比如OpenStack就不提供任何数据加密方法。这就需要企业和用户自己先加密数据,再上传加密后的数据和管理密钥本身。

还有一些公司由于兼容性问题、合规问题等原因,无法迁移到最新版本的开源代码,只能继续使用包含漏洞的旧代码。据Snyk称,只有16%的漏洞补丁是向后兼容其他版本的。这也给黑客们创造了不少机会。

总而言之,在这样从源代码创造、分享、开发等一系列产业链上的“不着调”,造成了“涟漪效应”,最终缔造了令人头痛的安全事故。

那么,除了改密码、打补丁之外,产业端有没有一些更“治本”的办法来杜绝此类隐患呢?

开源代码的安全战役,有没有另一种打开方式?

无论从哪个角度看,开源代码的安全战都是一场十分必要、不容退却的全民战争。当然了,普通用户只能打call,冲锋陷阵的还得是软件公司和程序员们。

对此,产业界也开始拿出了一些试图从根源上解决问题的办法。简单说几个:

1. 漏洞奖励

2012年,谷歌推出了Chrome奖励计划和漏洞奖励计划,鼓励程序员找出其浏览器及在线服务中的具体弱点,使得广泛使用的开源软件尽可能不那么容易遭受攻击,并为此支付500到3133美元不等的报酬。2013年,美国国家安全局也拨出了2510万美元,用于“额外秘密购买软件弱点”。

如今,漏洞赏金计划已成为许多互联网公司的重要安全策略之一,微软推出了迄今为止最高的Windows Bug奖励计划,达到250000美金。苹果、美国国防部、Facebook、腾讯、阿里ASRC、百度等为其漏洞支付的总金额也非常的惊人。

重赏之下,安全漏洞的时间差也有望有效减少。

2. 新技术工具

无论是防止源代码中的信息泄露,还是要寻找恶意文件、阻止恶意进程、保证端点安全,都有越来越多的技术工具可供使用,许多云安全公司和运营商等也都开始参与安全工具的开发。

比如最近的开源领导者峰会上,Linux基金会就宣布了Red Team(红队)项目。新项目将孵化开源网络安全工具,以帮助提高开源软件的安全性。

作为开源安全工具的孵化器,Red Team支持网络范围自动化,容器化渗透测试工具,二进制风险量化和标准验证程序等。并且能够在云上模拟黑客攻击,用户可以部署黑客脚本,并对现实中的团队进行安全培训。

诸如Commit Watcher等种种开源工具的出现,帮助程序员查找潜在危险失误,也正在使软件开发过程变得大不相同。

3. 加密算法

如果我们将数据信息看做是网络世界最宝贵的财富,那么加密机制就是一个可以保护数据的保险箱。除了将箱体打造的更加水火不侵,“锁芯”这道防线也需要不断迭代。

尤其是现在越来越多的机构与企业选择云计算技术作为复杂业务的解决方案,开源云平台的安全问题也更加速咋,因此,数据加密算法的解决方案就显得尤为重要了。

像是可以对企业数据进行安全分级,对等级高的数据先采用对称算法进行加密,并将对称算法产生的秘钥进行非对称加密存储,从而兼顾数据和安全性,以及系统运行效率。

在硬件端,谷歌也刚刚推出了针对低端手机的新加密标准Adiantum,在没有足够计算能力芯片的前提下,也能实现高速计算来进行哈希算法加密及解密,从而提升终端设备的安全性能。

从长远来看,开源社区更加灵活和开放的构建方式,会令它继续成为开发江湖的“根据地”。但当开放与自由成为双刃剑,又成为一个流着“奶与蜜”的数据丰饶之地,就很容易被不法之徒虎视眈眈。至少从GitHub这件事上看,开源代码的安全问题,应该已经来到了一个危险的临界点,也给一直以来“违规飙车”的业界敲响了警钟。

用开源软件的倡导者Eric S. Raymond的话来说——高质量的代码,就是对程序自己最好的注释。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,128评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,316评论 3 388
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 159,737评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,283评论 1 287
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,384评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,458评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,467评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,251评论 0 269
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,688评论 1 306
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,980评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,155评论 1 342
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,818评论 4 337
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,492评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,142评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,382评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,020评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,044评论 2 352

推荐阅读更多精彩内容