![]()
GitHub始終是攻擊者的重點目標,原因在于它處于軟件供應鏈的核心位置,能為威脅行為者提供三樣最渴望的東西:源代碼、密鑰憑證,以及可以肆意利用的自動化流水線。
Datadog安全研究團隊在過去數月中持續追蹤一種被其定義為"持續性規律"的GitHub API濫用行為。這類行為的目的是繪制企業組織及其成員的詳細畫像。單獨來看,這些請求"平淡無奇",但一旦跨越多個環境持續數周,甚至發展為大規模代碼克隆,危險性便急劇上升。最大的挑戰在于,這類行為與正常的API調用模式高度相似,難以區分。
Beauceron Security的David Shipley表示,由于許多開發生命周期存在安全漏洞,GitHub一直是犯罪分子入侵企業的寶庫,攻擊者通常的目標是API密鑰和云端憑證。
"如今,隨著所有人都被要求借助AI智能體編程來更快地完成更多工作,泄露的憑證寶庫很可能比以往更大,"他說,"簡而言之,套用舊時淘金熱的一句話:'那山頭里有黃金。'"
安全與合規公司DataBee的首席技術官Scott Miserendino對此表示認同。"GitHub是開源和企業項目中最受歡迎的源代碼倉庫,"他說,"其龐大的項目體量,加之托管著眾多廣泛使用的熱門軟件,使其成為攻擊者的重點目標。"
他指出,對私有代碼倉庫進行未經授權克隆等知識產權盜竊行為,可被用于獲取專有軟件的使用權,或發現可供利用的安全漏洞。
第二種常見攻擊手法,是搜索包含熱門軟件默認憑證的代碼倉庫。攻擊者利用這些憑證,可以針對生產環境中存在的賬戶或某些設備默認安裝的賬戶,開發并測試攻擊方案。
Datadog高級安全工程師Julie Agnes Sparks在一篇博客文章中寫道:"這些活動并非出自單一攻擊者,而是定制化自動掃描工具、對泄露憑證的機會性濫用,以及由'幽靈'賬號(即一次性賬號)組成的協作網絡的混合體。"
Sparks解釋稱,出于設計考量,GitHub有"相當大比例"的API接口無需身份驗證即可訪問。對這些API的請求通常會返回標準的HTTP 200響應。
這意味著威脅行為者可以詳細繪制出一個組織的公開代碼倉庫、成員信息、關注對象、收藏項目以及互動過的項目。她表示,這類流量與正常API調用混雜在一起,因此不會引發警覺。
此外,GitHub僅在用戶與私有倉庫交互時才會收集地理位置數據,記錄訪問者身份及所用訪問令牌,而與外部資源的交互則不作記錄。這限制了基于地理位置和VPN/代理的溯源能力。
攻擊者通常使用自定義或聽起來合法的用戶代理進行自動化數據抓取,并利用GitHub"幽靈"賬號——這些賬號創建于兩到五年前,此后一直處于休眠狀態。
這種方式極具吸引力,因為正如Sparks所指出的:"一個擁有多年歷史的賬號,看起來比同一周注冊就開始抓取數據的賬號更具可信度。"
這些賬號通常會在同一時期對多家企業發起短暫的"爆發式"活動,持續時間僅為一到三周,隨后便停止使用。研究人員識別出超過50個幽靈賬號,分布于多個用戶代理之下,并按名稱聚類為不同家族,例如user432023、user412023或kobalt*等。
部分攻擊活動還利用了真實GitHub用戶的合法賬號,這些用戶曾無意間將OAuth令牌或個人訪問令牌(PAT)暴露在公開內容中,或其終端設備遭到入侵或以其他方式被泄露。
攻擊者使用的數據滲出工具名稱各異,包括GitHub-Company-Scraper、GitHub-Scraper-Tool/1.0和GitHubAnalytics/1.5等,刻意設計為與正常數據分析流量相混淆。Sparks指出,大量請求指向開源查詢語言/graphql接口,該接口"非常適合"對企業、用戶和代碼倉庫進行批量查詢;而標準REST接口則被用于組織架構映射。
Sparks表示,此類攻擊活動的焦點"集中而一致",真正的隱患"在于累積效應"。單獨來看,這些請求針對的是無需身份驗證的公開代碼倉庫,且能成功返回響應,但這極少能真正"獲取"企業倉庫的實質性訪問權限。
然而,一組賬號在數周內同步活動、使用共享的GitHub賬戶并攜帶版本化定制工具,則代表著一種更為令人警惕的系統性行為。她舉例說明了一個事件:數十個不同的合法但已被入侵的GitHub用戶賬號,在短短幾分鐘內對同一組織發起API請求——盡管該次攻擊因目標指向私有代碼倉庫的提交路徑而最終失敗。
Sparks指出,"如果監控了正確的字段",這些行為是可以被檢測和追蹤的,例如識別用戶代理、令牌類型、自治系統號(ASN)或嘗試執行的操作等字段。
"用戶代理、事件活動和行為者名稱,是發現環境中未授權活動的關鍵線索,"Sparks強調道。她建議重點審查GitHub審計日志中異常的用戶代理行為,尤其是那些延伸至私有代碼倉庫的行為——平臺在此類場景下還會記錄IP地址、行為者名稱和程序化訪問類型。
企業還應啟用GitHub審計日志流式傳輸、建立用戶代理基線,并主動開展威脅狩獵。最重要的是,她表示企業應針對自身GitHub組織建立專屬檢測機制,并指出:"了解自己環境中什么是正常行為,這一點至關重要。"
Miserendino補充說,簡而言之,企業應遵循安全最佳實踐,包括:為所有賬號啟用多因素認證(MFA)、定期審查用戶訪問權限、刪除閑置或不必要的賬號,以及掃描代碼倉庫中以明文存儲而非保存在密鑰管理系統中的憑證。
Q&A
Q1:GitHub API濫用攻擊具體是怎么運作的?
A:攻擊者利用GitHub大量無需身份驗證即可訪問的公共API接口,使用自定義自動化工具對企業組織、成員信息、公開代碼倉庫等進行批量抓取,繪制出詳細的企業畫像。由于這類流量與正常API調用高度相似,很難被察覺。攻擊者通常還會使用創建多年、長期休眠的"幽靈"賬號,使其看起來更像合法用戶,從而降低觸發警報的風險。
Q2:企業如何檢測和防范GitHub API被濫用?
A:Datadog研究人員建議企業重點監控GitHub審計日志中的異常用戶代理行為,尤其關注涉及私有代碼倉庫的訪問記錄。同時應啟用GitHub審計日志流式傳輸、建立正常用戶代理基線,并主動開展威脅狩獵。基礎安全措施同樣不可忽視,包括為所有賬號開啟多因素認證、定期審查用戶權限、刪除閑置賬號,以及掃描代碼倉庫中明文存儲的憑證。
Q3:AI智能體的大量使用會加劇GitHub上的安全風險嗎?
A:會的。安全專家David Shipley指出,隨著越來越多的企業引入AI智能體輔助編碼以提升效率,代碼倉庫中積累的API密鑰、云端憑證等敏感信息只會越來越多。這意味著一旦相關倉庫遭到攻擊或憑證泄露,攻擊者能夠獲取的"戰利品"也將遠超以往,整體安全風險因此進一步上升。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.