大厂来的水货CTO：低级bug被敲诈50万美元，事后删代码隐藏证据，最后收到死亡威胁
点击上方“程序员大白”，选择“星标”公众号
重磅干货，第一时间送达
杨净 子豪 发自 凹非寺
量子位 报道 | 公众号 QbitAI
堂堂一家公司的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。
不过目前，提交代码已经被删除。
但还是被有心人找出了当时的网站快照。
快照上显示，代码中存在明显的低级错误，第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。（手动狗头）
参考链接：
[1]https://arstechnica.com/gadgets/2021/03/rookie-coding-mistake-prior-to-gab-hack-came-from-sites-cto/
[2]https://www.wired.com/story/gab-hack-data-breach-ddosecrets/
[3]https://news.ycombinator.com/item?id=26319649
[4]https://www.breitbart.com/tech/2020/11/18/free-speech-platform-gab-announces-facebook-vet-as-technical-chief/
[5]https://developers.slashdot.org/story/21/03/02/2230235/rookie-coding-mistake-prior-to-gab-hack-came-from-sites-cto
[6]https://news.gab.com/2021/02/26/alleged-data-breach-26-february-2021/
[7]https://news.gab.com/2021/03/01/gab-does-not-negotiate-with-criminal-demons/
[8]https://news.gab.com/2021/03/03/an-update-on-the-gab-breach/
Github资源地址：
https://github.com/kuchin/awesome-cto
推荐阅读
关于程序员大白
程序员大白是一群哈工大，东北大学，西湖大学和上海交通大学的硕士博士运营维护的号，大家乐于分享高质量文章，喜欢总结知识，欢迎关注[程序员大白]，大家一起学习进步！