前雇員“叛變”,泄露了老東家 44.7 GB 的源碼!
據外媒 BleepingComputer 報道,俄羅斯科技巨頭 Yandex 源代碼存儲庫慘遭泄露,在一個主流的黑客論壇上,該源代碼庫被以 Torrent 磁鏈的方式對外呈現。
不過,Yandex 在一份聲明中表示,自家公司并不是遭到了黑客攻擊,而是一名員工從中作梗,最終這名員工也變成了“前任”。
1、Yandex 所有主要服務的源碼遭泄露
Yandex 這家公司,想必不少人也并不陌生,它是俄羅斯最大的 IT 公司之一。其提供的服務要比國外的 Google、國內的百度或阿里騰訊要多得多,對此,也有人評價道,可以想象一下,一家公司可以取代 Google、Uber、亞馬遜、Netflix 和 Spotify 是什么概念。
在黑客網站上,泄密者標注了一個名為 Yandex git sources 的文件,其中暗藏 Yandex 多款服務的源代碼,具體包括了 2022 年 7 月泄露者從該公司竊取的 44.7GB 的文件,而這些代碼庫覆蓋除了 Yandex 反垃圾郵件規則外的所有源代碼。

對此,國外一位軟件工程師 Arseniy Shestakov 綜合了所有公開信息,進一步分析了 Yandex 服務源代碼內容,最終有了一些新的發現。其表示,“看起來至少 Yandex 所有主要服務的源代碼都被泄露了。”
具體包括:
- Yandex 搜索引擎和索引機器人
- Yandex 地圖
- Alice(AI 語音助手)
- Yandex 出租車服務
- Yandex 定向(廣告服務)
- Yandex 郵件
- Yandex Disk(云存儲服務)
- Yandex 市場服務(有些類似于亞馬遜)
- Yandex 旅行服務(旅游預訂平臺)
- Yandex360(工作空間服務)
- Yandex 云服務
- Yandex Pay(支付處理服務)
- Yandex Metrika(互聯網分析服務)
此次數據泄露的規模有些超乎想象。與此同時,據 Arseniy Shestakov 深挖發現,所有泄露文件的日期都可以追溯到 2022 年 2 月 24 日。
2、代碼解析
稍微值得慶幸的是,這些文件主要是存儲庫的內容,不包含 git 歷史記錄,且大多數軟件沒有預構建的二進制文件,只有少數例外。因此,這次泄露的信息沒有個人數據,此外,沒有內部工具的代碼本身也不太可能完全重現出一些 Yandex 的服務。
不過,有一些開發者倒是從泄露的源碼中發現了一些不同之處。來自加拿大的一名黑客 Aubrey Cottle 注意到,通過 Yandex 泄露的代碼文件顯示,該搜索平臺包容種族主義,通過一些代碼就可以顯而易見。


3、Yandex 緊急回應
據網友統計,Yandex 此次泄露的文件包含了公司 79 個服務和項目的代碼。面對如此大規模的泄露事件,Yandex 也快速地進行了回應,其發言人 Polina Pestova 表示:
Yandex 沒有被黑客入侵。我們的安全服務發現了公開可用的內部存儲代碼片段,但是它們的內容與 Yandex 服務中使用的當前存儲庫版本不同。
存儲庫是用于存儲和處理代碼的工具,大多數公司在內部都是以這種方式使用代碼。存儲庫是處理代碼所必需的方式,而不是用于存儲個人用戶數據。我們正在對向公眾發布源代碼片段的原因進行內部調查,但我們沒有看到對用戶數據或平臺性能的任何威脅。
不過據 BleepingComputer 報道,Yandex 前高級系統管理員、開發副主管兼傳播技術總監 Grigory Bakunov 在探討這一次的泄漏事件時表示,數據泄露的動機是政治性的,好在此次涉及數據泄露的 Yandex 員工并沒有試圖將代碼出售給競爭對手。
這位前高管補充道,泄漏不包含任何客戶數據,因此不會對 Yandex 用戶的隱私或安全構成直接風險,也不會直接威脅泄漏專有技術。
Yandex 使用一種名為為“Arcadia”的單存儲庫結構,但并非所有公司的服務都使用它。此外,即使只是為了構建服務,開發者也需要大量的內部工具和專業知識,因為標準的構建過程不適用。
泄露的存儲庫僅包含代碼;另一個重要部分是數據。關鍵部分,如神經網絡的模型權重等,都不存在,所以它幾乎沒用。
盡管如此,還是有很多有趣的文件,如一個名為“blacklist.txt”的文件,可能會暴露 Yandex 的工作服務。
當然,不容忽視的是,黑客還是可以利用這些源碼來尋找 Yandex 服務的漏洞等。
4、科技公司如何防止內部員工背后的“小動作”?
此次由內部員工引發的泄露事件一經披露,也引發了不少科技公司的警覺。畢竟近幾年來,內部員工“刪庫跑路”早已屢見不鮮,一旦遇上,雖然可以追責,但對公司自身的發展帶來的傷害和損失在一定層面已經無法挽回,因此,如何從內部盡可能地減少此類事件的發生,也成為各家企業頗為關注的問題。
在此,一位開發者 Frank Forte 也從安全性限制方面總結了幾點建議,希望對大家有所裨益:
一、限制工程師、運維等崗位員工對代碼的訪問。
企業可以設置單獨的代碼存儲庫,只允許員工訪問他們需要查看和處理的部分代碼。或許也可以為此使用 Bitbucket(基于 Web 的版本庫托管服務)之類的東西,然后在每個 repo 上設置權限。
然后企業可以編寫腳本將不同的存儲庫組合成最終產品。
這將方便企業便于管理,能夠使敏感代碼遠離新員工或外包人才。
不幸的是,如果公司的代碼是緊密耦合的,這幾乎是不可能的,因為大部分代碼需要成為正在構建或測試的項目的一部分。
分割代碼并不能防止代碼泄露,但它確實在一定程度上起到限制作用。
二、擬定強有力的員工合同
通過一份完善的員工合同,可以阻止員工泄露代碼。因為一旦涉及到泄密,可能會被抓捕、起訴,還可能會限制未來的工作前景,因為沒有公司會希望自己招聘的新員工被波及到一些因專有代碼而被起訴的案件中。
三、有明確的員工政策
讓公司內部員工清楚地了解什么是“泄漏代碼”。在 Stack Overflow 等論壇上發布大量代碼以獲得幫助可能會無意中泄露信息。告訴他們不要這樣做,并對這樣做的處罰。
四、登錄并維護權限和訪問權限
企業內部管理層應該及時了解工程師誰有權訪問以及他們何時有權訪問一些系統。當工程師不再需要相關系統權限時,應立即刪除訪問權限。
當然,以上僅是從一些大的維度來分享一些防御措施,更為關鍵的是還是需要企業自身學會識人、用人,對此,你還有什么樣的防御建議,歡迎留言分享~~