公司，包括 GitHub。他們最近在他們的博客上發(fā)布了關(guān)于 SSH 私鑰暴露的公告：

[上周，GitHub] 發(fā)現(xiàn) GitHub.com 的 RSA SSH 私鑰在公共 GitHub 存儲(chǔ)庫(kù)中被短暫暴露。

該公司向公眾保證，該密鑰僅用于保護(hù)“使用 RSA 通過(guò) SSH 進(jìn)行的 Git 操作”，這意味著沒(méi)有內(nèi)部系統(tǒng)、客戶(hù)數(shù)據(jù)或安全 TLS 連接處于風(fēng)險(xiǎn)之中。他們通過(guò)檢測(cè)事件并更改密鑰立即做出反應(yīng)：

“在世界標(biāo)準(zhǔn)時(shí)間 3 月 24 日 05:00 左右，出于謹(jǐn)慎考慮，我們更換了用于保護(hù) GitHub.com 的 Git 操作的 RSA SSH 主機(jī)密鑰?！?/p>

因此，影響在時(shí)間和范圍上都受到限制：“此更改僅影響使用 RSA 通過(guò) SSH 的 Git 操作。如果您使用 ECDSA 或 Ed25519 加密，那么您不會(huì)受到影響。 ”，據(jù)他們說(shuō)。

這進(jìn)一步證明，秘密蔓延不僅僅是由缺乏經(jīng)驗(yàn)的開(kāi)發(fā)人員或新團(tuán)隊(duì)推動(dòng)的。在我們的State of Secrets Sprawl 2023 報(bào)告中，我們發(fā)現(xiàn)了超過(guò) 10,000,000 個(gè)被推送到公共 GitHub 存儲(chǔ)庫(kù)的新秘密。與去年的報(bào)告相比，我們檢測(cè)到的秘密數(shù)量增加了 67%，而 GitHub 本身的新帳戶(hù)只增加了 27%。

檢測(cè)到的硬編碼憑據(jù)的增加是由許多因素驅(qū)動(dòng)的，但很明顯，參與事件的開(kāi)發(fā)人員的資歷從新手到專(zhuān)家，以及來(lái)自各種成熟度級(jí)別的組織。從我們的報(bào)告中，我們發(fā)現(xiàn)十分之一的提交者在 2022 年泄露了一個(gè)秘密。如果您公開(kāi)揭露了秘密，那么您肯定不是孤軍奮戰(zhàn)。GitHub 很好地提醒我們，無(wú)論我們的團(tuán)隊(duì)有多大，我們都必須在安全實(shí)踐中保持警惕。

讓我們來(lái)看看這種情況下的風(fēng)險(xiǎn)是什么，GitHub 如何處理補(bǔ)救過(guò)程，以及一些避免公開(kāi)私鑰的簡(jiǎn)單步驟。

SSH 私鑰泄露的風(fēng)險(xiǎn)

GitHub 在他們的帖子后面說(shuō)：“我們 [替換了我們的 RSA SSH 主機(jī)密鑰] 以保護(hù)我們的用戶(hù)免受任何攻擊者冒充 GitHub 或通過(guò) SSH 竊聽(tīng)他們的 Git 操作的機(jī)會(huì)。該密鑰不授予對(duì) GitHub 基礎(chǔ)設(shè)施或客戶(hù)的訪問(wèn)權(quán)限數(shù)據(jù)?！?/p>

雖然我們可以對(duì)最后一部分感到放心，但不會(huì)暴露任何客戶(hù)數(shù)據(jù)。還好沒(méi)有接管他們的基礎(chǔ)設(shè)施的已知風(fēng)險(xiǎn)，特別是考慮到有多少開(kāi)發(fā)人員和如此多的互聯(lián)網(wǎng)每天都依賴(lài)它。

但“對(duì)手冒充 GitHub 或竊聽(tīng)他們的 Git 操作”存在嚴(yán)重風(fēng)險(xiǎn)。這就是所謂的“中間人攻擊”，最終用戶(hù)無(wú)法區(qū)分合法的另一方和攻擊者。

由于有如此多的開(kāi)發(fā)人員和服務(wù)依賴(lài) GitHub SSH 通信來(lái)實(shí)現(xiàn)真正的安全，因此公司吊銷(xiāo)和替換他們的 SSH 密鑰非常有意義。在同一篇文章中，他們還發(fā)布了如果您受到影響需要做什么以及如何判斷您是否受到影響。如果在通過(guò) SSH 連接到 GitHub 時(shí)收到警告，WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!則需要?jiǎng)h除舊密鑰或手動(dòng)更新~/.ssh/known_hosts文件。

您的 GitHub Actions 也可能會(huì)受到影響。GitHub 輪換他們的 SSH 私鑰將意味著如果他們使用actions/checkoutssh-key 選項(xiàng)，工作流運(yùn)行將失敗。這對(duì)于CircleCI 客戶(hù)來(lái)說(shuō)可能很熟悉，他們因泄漏事件經(jīng)歷過(guò)類(lèi)似的意外工作流程中斷。

大量更換的反應(yīng)和風(fēng)險(xiǎn)

正如預(yù)期的那樣，開(kāi)發(fā)者社區(qū)對(duì)該事件有很多公眾反應(yīng)。似乎沒(méi)有人對(duì)這種情況感到高興。但有些人在沒(méi)有添加太多評(píng)論的情況下幫助傳播信息。其他對(duì)話(huà)推測(cè)這可能是如何發(fā)生的，以及可能發(fā)揮作用的進(jìn)一步潛在安全問(wèn)題。在幾次談話(huà)中出現(xiàn)的一個(gè)問(wèn)題是新的中間人攻擊的可能性。攻擊者知道密鑰將被許多開(kāi)發(fā)人員使用命令替換，而無(wú)需手動(dòng)驗(yàn)證新指紋是否為預(yù)期值。壞人完全有可能在某些情況下插入自己的指紋。ssh-keygen -R github.com這是一個(gè)很好的提醒，我們應(yīng)該擁抱零信任，從“信任，但驗(yàn)證”轉(zhuǎn)變?yōu)椤膀?yàn)證，然后才信任”的立場(chǎng)。

事件補(bǔ)救的教訓(xùn)

雖然不幸的是，GitHub 需要輪換此證書(shū)，影響了如此多的客戶(hù)，并發(fā)布了這樣的通知，但我們想強(qiáng)調(diào)他們用來(lái)響應(yīng)事件的一些最佳實(shí)踐。

雖然我們不知道這個(gè)秘密暴露了多長(zhǎng)時(shí)間，但我們可以假設(shè)它是最近才出現(xiàn)的。

迅速而謹(jǐn)慎地采取行動(dòng)，不要驚慌失措，這對(duì)于秘密整治至關(guān)重要。鑒于他們發(fā)布的時(shí)間戳，我們可以假設(shè)這一事件導(dǎo)致相關(guān)團(tuán)隊(duì)失眠，他們不得不權(quán)衡多種因素。他們似乎認(rèn)為安全風(fēng)險(xiǎn)值得密鑰輪換，即使它可能會(huì)影響大量用戶(hù)。

我們也可以為他們非常迅速和公開(kāi)的溝通鼓掌。雖然大多數(shù)人可能沒(méi)有訂閱 GitHub 博客，但他們將新聞推送到多個(gè)渠道盡可能公開(kāi)。雖然社區(qū)中的一些人覺(jué)得在使用“我們沒(méi)有理由相信”或“非常謹(jǐn)慎”等術(shù)語(yǔ)時(shí)有點(diǎn)過(guò)多的“營(yíng)銷(xiāo)旋轉(zhuǎn)”，但 GitHub 團(tuán)隊(duì)在他們所有的溝通中一直直截了當(dāng)安全事件。我們將采取一些溫和的措施，而不是沒(méi)有得到包括補(bǔ)救步驟的概述。

如何防止憑證泄露

沒(méi)有人是完美的，我們都會(huì)不時(shí)犯錯(cuò)誤。期望人類(lèi)總是完美地交付只會(huì)讓你失望，尤其是在處理像 Git 這樣概念上復(fù)雜的東西時(shí)。雖然我們都喜歡世界上最受歡迎的版本控制系統(tǒng)，但大多數(shù)開(kāi)發(fā)人員會(huì)告訴您，做錯(cuò)事太容易了，例如推送到錯(cuò)誤的遠(yuǎn)程存儲(chǔ)庫(kù)。

雖然我們不知道究竟是什么導(dǎo)致了這一特定事件，但我們想借此機(jī)會(huì)提醒您一些最佳做法。

永遠(yuǎn)不要將憑據(jù)添加到版本控制

這一點(diǎn)看起來(lái)很明顯，但我們所有接觸代碼的人有時(shí)都會(huì)為此感到內(nèi)疚。有時(shí)，尤其是在調(diào)試某些東西時(shí)，您只需要測(cè)試憑據(jù)是否有效。密碼、API 密鑰以及與之相關(guān)的證書(shū)都是如此。

您可能會(huì)直接在項(xiàng)目中添加一個(gè)新證書(shū)，完全有意將其移動(dòng)到安全的地方或修改您的.gitignore文件，但是生活發(fā)生了，您會(huì)分心。一個(gè)git add -A和git commit以后，您的證書(shū)現(xiàn)在在您的 git 歷史記錄中。一個(gè)'git push'之后，它現(xiàn)在在共享倉(cāng)庫(kù)中。

這就是 git hooks 和ggshield等工具真正派上用場(chǎng)的地方。設(shè)置預(yù)提交掛鉤非常快速和簡(jiǎn)單。設(shè)置完成后，每次提交代碼的嘗試都將觸發(fā)掃描，如果在任何跟蹤文件中發(fā)現(xiàn)秘密，掃描將停止操作。在秘密成為您的 git 歷史的一部分之前捕獲秘密是補(bǔ)救這種情況的最安全和最便宜的地方。

仔細(xì)檢查遙控器是否正確

Git 的優(yōu)勢(shì)之一是能夠輕松地將所有更改推送到您有權(quán)連接的任何遠(yuǎn)程存儲(chǔ)庫(kù)。不幸的是，這很快就會(huì)變得混亂。假設(shè)您有兩個(gè)存儲(chǔ)庫(kù)，一個(gè)是公共的，一個(gè)是私有的，分別具有遠(yuǎn)程名稱(chēng) proj-1-p和proj-1-pr。你只差一個(gè)字母就可能被推到錯(cuò)誤的地方。意外發(fā)生。使這些起源名稱(chēng)更明確是一個(gè)很好的主意。

許多開(kāi)發(fā)人員處理的另一個(gè)因素是他們自己的 shell 別名。例如，通常將別名gpo作為經(jīng)常鍵入的快捷方式git push origin。很容易進(jìn)入自動(dòng)模式并使用可能將錯(cuò)誤分支發(fā)送到錯(cuò)誤位置的快捷方式。如有疑問(wèn)，請(qǐng)輸入。

經(jīng)常輪換秘密

雖然此事件可能不需要輪換 SSH 密鑰，但您知道上次輪換它是什么時(shí)候嗎？是這個(gè)十年嗎？如果您不知道，那么現(xiàn)在是補(bǔ)救的好時(shí)機(jī)。任何有效憑證存在的時(shí)間越長(zhǎng)，該憑證被發(fā)現(xiàn)和濫用的機(jī)會(huì)就越大。

我們發(fā)現(xiàn)，在秘密管理成熟度方面，更頻繁地輪換密鑰的團(tuán)隊(duì)處于金字塔的頂端，即專(zhuān)家級(jí)別。在沒(méi)有緊急情況的情況下定期輪換證書(shū)將使您做好準(zhǔn)備，以便在出現(xiàn)這些額外壓力時(shí)更好地應(yīng)對(duì)。

保持警惕和安全

泄漏有時(shí)會(huì)發(fā)生在我們所有人身上，甚至發(fā)生在像 GitHub 這樣的大型平臺(tái)上。雖然可能有許多工作流程受到影響，并且許多開(kāi)發(fā)人員需要更新他們的known_hosts文件，但由于 GitHub 對(duì)事件進(jìn)行了明確的溝通，因此有明確的補(bǔ)救路徑，而且我們知道事件的總體范圍。

現(xiàn)在也是反思您自己的秘密管理和檢測(cè)策略的好時(shí)機(jī)。