大廠來的水貨CTO：低級bug被敲詐50萬美元，事后刪代碼
本文經AI新媒體量子位（公眾號ID: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。（手動狗頭）
