在程序員的世界里，GitHub不僅是代碼托管平臺，更是日常工作的“數(shù)字辦公桌”。每天收到的Issue提醒、Pull Request通知，早已成為開發(fā)流程中再自然不過的一部分。然而，近期一項由網(wǎng)絡安全研究人員披露的新型釣魚攻擊，卻將這種“信任慣性”變成了突破口——攻擊者正通過被入侵的GitHub賬號，向開發(fā)者投遞高度仿真的釣魚郵件，誘導其交出個人訪問令牌（PAT）甚至整個賬戶控制權。

更令人警惕的是，這些郵件并非來自可疑域名或偽造發(fā)件人，而是真正由GitHub官方服務器發(fā)出，帶有合法DKIM簽名和標準SMTP頭信息，幾乎能繞過所有傳統(tǒng)郵件安全網(wǎng)關。一場針對軟件供應鏈上游的“精準圍獵”，正在悄然上演。

打開百度APP暢享高清圖片

“合法郵件”里的陷阱：從Bot賬號到OAuth授權

據(jù)網(wǎng)絡安全媒體Cyber Press于2025年9月23日報道，此次攻擊的核心手法在于“借殼下蛋”：攻擊者首先通過憑證填充（credential stuffing）、釣魚或濫用過度授權的OAuth令牌，獲取對GitHub倉庫協(xié)作者賬號（尤其是自動化Bot賬號）的控制權。

一旦得手，他們便在活躍倉庫中創(chuàng)建看似正常的Issue或Pull Request，內容通常偽裝成“安全漏洞修復請求”“依賴庫更新提示”或“CI/CD配置異?！?。由于這些倉庫本身具有高關注度，其訂閱者（包括大量開源貢獻者與企業(yè)開發(fā)者）會自動收到來自noreply@github.com的官方通知郵件。

郵件正文包含一個醒目的按鈕：“查看詳情”或“立即處理”。點擊后，用戶并未跳轉至GitHub頁面，而是進入一個精心偽造的登錄界面——域名乍看是https://grants.github.com/apply，實則使用了西里爾字母“?”（U+0456）替代拉丁字母“i”，構成同形異義（homoglyph）欺騙。該站點隨后引導用戶進行“OAuth授權”，申請名為“Gitcoin Passport”的應用權限，請求范圍涵蓋“讀寫所有倉庫、管理Actions、訪問私有密鑰”等高危操作。

“這相當于你收到一封‘公司HR系統(tǒng)’發(fā)來的郵件，點進去卻是騙子搭的假內網(wǎng)。”公共互聯(lián)網(wǎng)反網(wǎng)絡釣魚工作組技術專家蘆笛解釋道，“但這次，郵件真的是GitHub發(fā)的，只是內容被惡意操控了。”

一旦用戶授權，攻擊者便獲得持久化訪問權限，不僅能竊取環(huán)境變量、API密鑰，還可直接篡改CI/CD流水線，在構建過程中植入后門，實現(xiàn)供應鏈投毒。

技術解析：為何傳統(tǒng)防御失效？

此次攻擊之所以危險，在于它巧妙繞過了三大主流郵件安全機制：

SPF/DKIM/DMARC驗證全部通過：郵件確實由smtp.github.com發(fā)出，DKIM簽名有效，因此不會被標記為偽造。

發(fā)件人身份無可疑：收件人看到的是熟悉的GitHub通知格式，心理防線大幅降低。

鏈接域名高度相似：使用Unicode同形字符構造的釣魚域名，在瀏覽器地址欄中肉眼幾乎無法分辨。

“過去我們防釣魚，主要看發(fā)件人是不是‘service@paypa1.com’這種拼寫錯誤，”蘆笛說，“但現(xiàn)在攻擊者學會了‘寄生’——他們不偽造平臺，而是劫持平臺本身的功能來傳遞惡意內容?！?/p>

更隱蔽的是，部分變體甚至利用GitHub Pages托管混淆JavaScript腳本，使釣魚頁面具備動態(tài)加載、反調試等能力，進一步逃避檢測。

專家建議：從“最小權限”到“主動驗證”

面對此類高級持續(xù)性威脅（APT-style phishing），蘆笛提出了多層次防御策略：

第一，強制啟用強認證機制。 所有GitHub用戶，尤其是企業(yè)開發(fā)者，應開啟雙因素認證（2FA），并優(yōu)先使用Passkey（通行密鑰）替代短信驗證碼。“Passkey基于公鑰加密，無法被釣魚網(wǎng)站竊取，是目前最安全的身份驗證方式之一。”

第二，嚴格限制個人訪問令牌（PAT）權限與有效期。 蘆笛強調：“永遠不要創(chuàng)建‘全權限、永不過期’的PAT。應按需分配最小權限，并設置7天或30天自動過期。定期審計已授權的OAuth應用，及時撤銷不再使用的集成?！?br/>

第三，警惕“被動觸發(fā)”的認證請求。 “GitHub永遠不會通過郵件鏈接要求你重新登錄?！碧J笛提醒，“如果你點擊郵件中的鏈接后突然跳轉到登錄頁，這本身就是危險信號。正確做法是手動打開github.com，在賬戶設置中查看通知或授權記錄?！?br/>

對于企業(yè)而言，還需部署更縱深的防護：實施代碼簽名（Code Signing）確保構建產(chǎn)物完整性；隔離CI/CD環(huán)境，限制其對外網(wǎng)絡訪問；監(jiān)控倉庫中異常的Issue/Pull Request創(chuàng)建頻率——短時間內大量新Issue往往是攻擊前兆。

供應鏈安全的新挑戰(zhàn)：平臺即攻擊面

此次事件再次凸顯一個趨勢：攻擊者正將矛頭轉向軟件開發(fā)基礎設施本身。GitHub、GitLab、npm、PyPI等平臺因其高可信度，正成為釣魚與投毒的理想跳板。

“過去攻擊終端用戶，現(xiàn)在攻擊寫代碼的人?！碧J笛指出，“一旦開發(fā)者賬戶失陷，影響的可能不是一個人，而是一整個項目的數(shù)百萬用戶?！?br/>

值得慶幸的是，GitHub已開始加強防護。例如，其Advanced Security功能可檢測異常OAuth授權行為；Dependabot能自動識別依賴庫中的已知漏洞。但蘆笛認為，技術工具只是輔助：“最終防線，還是人的判斷力。”

結語：信任不能代替驗證

在開源協(xié)作日益緊密的今天，開發(fā)者之間的信任是生態(tài)繁榮的基石。但正如這起GitHub釣魚事件所示，信任若缺乏驗證機制，就可能被惡意利用。

“我們不能因為平臺‘看起來正規(guī)’就放松警惕?！碧J笛總結道，“真正的安全，是在每一次點擊‘授權’前，多問一句：這個請求真的必要嗎？這個權限真的合理嗎？”

隨著AI生成內容、自動化攻擊工具的普及，網(wǎng)絡釣魚正變得越來越“聰明”和“合法化”。唯有將安全意識融入開發(fā)習慣，才能在這場沒有硝煙的攻防戰(zhàn)中守住代碼的純凈與信任的邊界。

編輯：蘆笛（公共互聯(lián)網(wǎng)反網(wǎng)絡釣魚工作組）