CTO写代码弄出低级BUG:惨遭敲诈后掩盖证据 收到死亡威胁
  • 杨净 子豪
  • 2021年03月07日 16:29
  • 0

堂堂一家公司的CTO,到底能水到什么程度?

因为一个低级错误,70GB大小的信息数据被泄露,公司还被黑客敲诈了50万美元。

而被发现后,他为了隐藏证据,竟还删掉了代码…

这就是最近在一个社交媒体网站Gab上发生的真实事件。

上周末,黑客通过SQL注入漏洞入侵他们的官网,并窃取了15000位用户的数据。

后经媒体调查发现,关键漏洞竟是由该公司的CTO造成的。

而这位CTO是一位入职不到半年,但有着23年开发经验的工程师。

其前东家更是名牌“大厂”——Facebook。

于是就有网友质疑,这是公司眼瞎了?还是CTO太水了?

大厂“毕业”CTO,犯下致命低级错误

而事件的起因,是一位黑客利用SQL注入漏洞入侵了公司后台,窃取了数据。

这其中包含用户公开、私人的帖子、哈希密码以及私人资料,共涉及70000条信息。

不光如此,黑客还将此事透露给了一个爆料网站DDoSecrets,与维基解密类似,从事披露黑客窃取的数据和机密信息等工作。

在事件公开之前,该网站的记者还在社交网络上挑衅Gab的CEOAndrew Torba:

DDoSecrets甚至都没有宣布任何消息,Gab就已经害怕了。

随后,不少媒体、专家在调查了这家公司的git commit记录之后发现,是一个名叫“Fosco Marotto”账户,更改了后台的代码,才让黑客有机可乘。

而Fosco Marotto,正是公司的CTO。

CTO写代码弄出低级BUG:惨遭敲诈后掩盖证据 收到死亡威胁

不过目前,提交代码已经被删除。

但还是被有心人找出了当时的网站快照。

快照上显示,代码中存在明显的低级错误,第23行中的“reject”和“filter”被删除了。

这两个API函数,原本用于拦截SQL注入漏洞的攻击。

具体而言,就是当SQL指令传送到后端数据库服务器时,确保其中的恶意命令已经被清除。

但他们没有采取这种做法,而是在Rails函数中,添加了一个包含 “find_by_sql”方法的调用,导致查询字符串中的输入未经过滤,而被直接接受。

(Rails是一个网站开发工具包)

一位Facebook 的前产品工程师Dmitry Borodaenko表示:

如果对SQL数据库有任何了解的话,就应该听说过SQL注入攻击。

虽然现在还不能百分百确定是由这个漏洞所引起的,但也是极有可能的。

还有不少专家批评了公司事后删除git commit的行为。

这种删除违反了“分支源代码必须公开透明”的条款。

讽刺的是,早在2012年,这位CTO还在StackOverFlow上警告过其他程序员别犯这样的错误:

应该使用参数化查询,防止被SQL注入攻击。

因此就不免让部分网友怀疑,这次他是故意泄露数据的。

CTO:生平第一次受到死亡威胁

事情还没有公开报道的时候,Gab就立刻回应了此事,应该是因为一些记者收到了该公司的泄露数据。

2月26日,Gab CEOAndrew Torba就发表官方声明,否认了这一入侵行为。

我们发现了这一漏洞,并在上周已经进行了修补,还将着手进行全面的安全审核。

并表示就个人信息而言,Gab从用户那里收集的信息非常少。因此一旦发生泄漏,对用户的影响也会降至最低。

但这件事被ArsTechnica报道、事态更加严重之后,Gab选择了与CTO站在一起一致对外。

CEOAndrew Torba连发两条声明,承认了官网被入侵这一事实。

他还表示公司正受到黑客的勒索,赎金为近500000美元的比特币,并且此事已经向执法部门报告。

而当事人——CTOFosco Marotto,也在HackerNews发表了个人声明。

当中显示“自己生平第一次受到了死亡威胁”,“目前没有任何证据显示,那次代码提交与这次黑客入侵有任何直接联系”,“向ArsTechnica提供消息的那个人,跟我有个人恩怨”。

还给出了一些辩驳的理由:

我过去写了很多年的SQL,当然清楚用户输入的重要性。我还曾用各种语言写过很多用户输入的代码。

我并不是一个Rails开发者,我对Rails和ActiveRecord是持否定态度的。

网友:CTO还自己写代码?

事件一出,不少网友直接将矛头指向CTO:为什么C级高管还要亲自写代码?

有人认为,CTO应该有更重要的职责,比如战略制定和决策,而不是关注细节,更不会亲自写代码。

对此,也有人提出不同观点:

这并不是通用法则,在不同的公司,CTO的工作内容可能会大不相同。

在Gab这样的小型初创公司,CTO作为技术水准最高的人,亲自写代码,并非是不可能的。即便不是亲自写代码,也需要为项目的交付流程负责。

不过,让黑客利用SQL注入攻击,还发生在一位前Facebook工程师身上,这实在让很多网友感到难以置信。

一位网友直言道:如果CTO审查后还出现这种错误,他就是个白痴,要么就是工程师们在欺骗白痴。

也有网友为他鸣不平

部分网友表示:任何人都可能犯菜鸟错误,这就是为什么即使是老板,也要进行代码审查的原因。

曾在Facebook担任高级软件工程师的一名网友,对此一点都不觉得惊讶:“没有听说过快速行动并解决问题吗?重点是代码速度,而不是质量。”

也有网友认为,前Facebook工程师不会犯菜鸟编码错误,帐户可能是被盗了。

不过随即被网友回复:“被盗也只是另一个新手错误。”

还有网友指出,Gab也许没有静态分析安全测试工具(SAST),要么就是故意忽略了系统反馈。

现有的任何一个代码静态分析工具都会告诉你,这样编写SQL是一个非常糟糕的做法。CI管道甚至会直接拒绝代码,拒绝合并代码。

也就是说,即使开发人员忽略了这个明显的漏洞,系统本身也能阻止它。

毫无疑问的是,无论过程如何,作为CTO的Fosco都要为这次事件承担责任。

CTO们请注意!

那么问题来了:如何避免重蹈Fosco的覆辙?

这里有一份5.6K星的免费清单。

几乎关于CTO的一切,都能在里面找到,简直是CTO培养的保姆级指南。

不过这份指南,将重点针对初创公司和高速增长型企业的CTO和研发副总裁。

内容涵盖了从录用到管理、技术、营销等方面。

大致包括:角色定位、录用流程、管理方法、员工手册、开发过程、软件架构、技术学习、初创企业、产品、营销,以及其他相关资源的链接。

好了,就剩最后一个问题了。

首先你得是一个CTO。(手动狗头)

CTO写代码弄出低级BUG:惨遭敲诈后掩盖证据 收到死亡威胁


文章出处:量子位

文章纠错

  • 好文点赞
  • 水文反对
观点发布 网站评论、账号管理说明
热门评论
查看全部评论
相关报道

最热文章排行查看排行详情

邮件订阅

评论0 | 点赞0| 分享0 | 收藏0