淺談寫死密碼及其掃描工具

// 文丨喬丹

美團安全研究員，碩士畢業于複旦大學，目前在美團緻力于雲原生安全建設。

密碼是對服務、系統和資料的通路權限進行授權的數字身份憑證，常見的密碼有API密鑰、非對稱私鑰、通路Token等。寫死密碼（Hardcoded Secret），或稱嵌入式密碼（Embedded Secret），是指将密碼以明文方式直接寫入代碼中。這種處理方式極大地提高了攻擊者命中密碼的機率，使服務或系統暴露在風險中，容易造成嚴重損失。針對此問題，本文詳細讨論了寫死密碼的成因、危害及治理方法；另外，本文從安全人員角度出發，對現有的寫死密碼檢測工具的算法進行了深入調研，并提出了我們的自動化檢測工具。

01

寫死密碼的成因及類型

随着網際網路組織轉向雲架構、SaaS 平台和微服務，密碼等數字身份驗證憑證的數量和多樣性正在快速增長。與此同時，企業也不斷推動更短的釋出周期，開發人員面臨巨大時間壓力的同時，需要處理的密碼量比以往任何時候都多。許多開發人員采取捷徑，選擇使用寫死的方式處理密碼。

在企業的代碼倉庫中普遍存在大量的寫死密碼問題。據GitGuardian統計，在公共Git存儲庫上每天會洩露數以千計的密碼，其中僅2020年就有超過200萬個密碼被上傳至Git存儲庫中[1]，而2021年該組織發現的密碼數量超過600萬，同比增長近2倍[2]，而私人存儲庫的密碼洩露事件存在可能性比公共庫高4倍。

根據統計[1][2][6]，寫死密碼包括API密鑰、通路Token、非對稱私鑰、認證ID、安全證書、密碼、特權使用者賬戶等類型。寫死密碼所涉及的平台十分廣泛，包括如下領域：開發工具，如Django、Rapid API；資料存儲，如MySQL、Mongo；金融服務，如PayPal、Amazon MWS；消息通訊系統，如Gmail、Telegram；雲提供商，如AWS、Azure、Google；私鑰；社交媒體，如Twitter、Facebook；版本控制平台，如Github、Gitlab；等等。

除了程式代碼中，這些寫死還容易出現在基礎設施配置檔案、監控日志、運作日志、堆棧調試track記錄、git曆史中。所有類别的寫死密碼都使企業暴露在攻擊之下。

02

寫死密碼的危害

寫死密碼主要對安全和研發兩方面具有危害：

1. 削弱系統安全性

攻擊者常通過公共代碼庫或反編譯分析獲得寫死密碼字元串，利用密碼通路敏感資料或擷取敏感操作權限。攻擊者還可以進一步擴大攻擊範圍，進行資料勒索、帳戶操縱、帳戶建立、通過使用者資料進行利用等，使得企業和使用者都遭受嚴重損失。在以下案例中，攻擊均是從密碼的洩露開始的：2014年，Uber資料庫被未經授權通路，導緻數千名Uber司機私人資訊的資料被洩露[7]；2016年，Uber又因外部的未授權通路導緻5700萬使用者的個人資訊被洩露；2018年，Github和Twitter[10]在内部日志系統中以明文方式存儲密碼，分别涉及2700萬和3.3億使用者資料洩露；2020年，使用者在Github倉庫中發現了星巴克的API密鑰，涉及重大資訊洩露[8]；2021年，黑客組織 Sakura Samurai 在一次重大資料洩露事件中獲得了通路聯合國 (UN) 員工私人資料和系統的權限[9]……由寫死密碼導緻的安全事故層出不窮，也不斷有相關CVE和CWE被披露。

寫死密碼對特定裝置、固件、服務、應用程式本身，對其連接配接的IT生态系統其他部分，甚至使用服務的第三方都存在風險，使其同樣暴露在風險中。

2. 不易于程式維護

寫死密碼的修複較為困難，密碼一旦被利用無法輕易被修正。對于正線上上運作的服務或系統，修複寫死密碼問題需要停服重新釋出。大型企業的服務流量較大，服務間還存在依賴，則需要灰階釋出，修複流程更長，其間可能持續受到攻擊者威脅。

密碼的蔓延也使維護變得困難。與傳統憑證不同，密碼旨在分發給開發人員、應用程式和基礎設施系統，這将不可避免地使開發中使用的密碼數量增加，一個密碼可能出現在代碼中多處位置，這進一步增加了修複的難度。

此外，開源的代碼造成密碼洩露，即使在源碼中删除寫死密碼，也會殘留在git曆史裡。

03

如何治理寫死密碼

企業代碼中的寫死密碼問題日益嚴重，隻有通過安全人員和研發人員的共同協作才能解決。源代碼中的密碼洩露很難徹底避免，但與其他漏洞一樣，它完全由内生因素決定：開發人員需要通路更多的資源，以更快的速度建構和部署。這意味着隻要有足夠的紀律和教育，再加上正确的工具，就有可能大幅改善這種情況。

從開發人員角度，需要注意盡量避免将密碼以明文形式寫入代碼中。代碼中需要對密碼進行校驗時，對入站身份驗證可使用強單向散列函數進行密碼模糊化，并将這些散列結果存儲在具有适當通路控制的配置檔案或資料庫中；對出站身份驗證，可将密碼存儲在代碼之外的一個經過嚴格保護的、加密的配置檔案或資料庫中，該配置檔案或資料庫不會被所有外部人員通路，包括同一系統上的其他本地使用者[13]；大型企業可以使用KMS服務進行一站式密碼管理。

從安全人員角度，應盡量做到風險左移，盡早發現密碼洩露，幫助開發人員降低修複成本。可通過代碼檢測掃描，将寫死密碼檢測內建到開發工作流程中，提前發現寫死密碼問題。

04

寫死密碼檢測算法

由于寫死密碼有如此的危險性，學術界和工業界都有許多組織針對此問題研發了代碼掃描工具。我們對開源工具和學術文章進行了一系列調研，總結了目前的寫死密碼掃描工具常用的檢測算法，并對其優缺點進行了讨論。

4.1 正規表達式比對

正規表達式通常被用來檢索符合某種模式的字元串。對于檢測具有固定結構或特征的密碼，正規表達式可能很有效。常用于密碼檢測的正規表達式可分為（1）針對各種特定平台密碼的表達式和（2）不針對任何平台的通用表達式。

（1）針對各種特定平台密碼的表達式

許多平台的API密鑰、通路Token、認證ID等具有平台獨有的特征，例如亞馬遜AWS密鑰均以“AKIA”字元串開頭；常用于非對稱加密的私鑰如RSA、EC、PGP及通用私鑰等，常由ssh-keygen、openssl等工具生成，多數情況下私鑰以單獨的PEM等檔案格式存儲，其内容也具有一定特征，例如RSA私鑰檔案由"-----BEGIN RSA PRIVATE KEY-----"字元串作為開頭。對于這類密碼，可以通過比對具有其特征的正規表達式進行檢測。

下表列舉了部分常用平台密碼的類型以及正規表達式。本文僅以此表舉例，實際上特定平台的密碼種類十分豐富，此處不便一一列舉。

平台	密碼類型	正規表達式
Amazon AWS	API密鑰	AKIA[0-9A-Z]{16}
Google	API密鑰	AIza[0-9A-Za-z\-_]{35}
Azure	API密鑰	AccountKey=[a-zA-Z0-9+\/=]{88}
Google	認證ID	[0-9]+-[0-9A-Za-z_]{32}\.apps\.google
PayPal	通路Token	access_token\$production\$[0-9a-z]{16}\$[0-9a-f]{32}
Facebook	通路Token	[1-9][0-9]+-[0-9a-zA-Z]{40}
RSA私鑰	非對稱私鑰	-----BEGIN RSA PRIVATE KEY----- [\r\n]+(?:\w+:.+)*[\s]* (?:[0-9a-zA-Z+\/=]{64,76}[\r\n]+)+ [0-9a-zA-Z+\/=]+[\r\n]+ -----END RSA PRIVATE KEY----

（2）不針對特定平台的通用的表達式

由于特定平台表達式和平台的一一對應性質，其覆寫範圍有限，此時需要用覆寫範圍較廣的通用表達式來補充。許多平台的密碼具有一些通用的特征，例如密碼字元串以api_key、access_token等關鍵字為開頭。

此外，根據開發人員的程式設計命名習慣規範，也可以根據變量名中的關鍵字進行比對，例如變量名中含有Secret、Token等關鍵字的字元串很可能是密碼。

• 優點

1. 配置簡單。
2. 自定義擴充友善。

• 缺點

1. 正規表達式覆寫範圍不夠廣則容易漏報。
2. 使用一組不準确的正規表達式容易出現大量誤報。
3. 即使是正确的正規表達式也有一定程度的誤報，例如“AKIAXXXEXAMPLEKEYXXX”雖然符合亞馬遜AWS的正規表達式，但并不是有效的密碼。
4. 通用表達式中使用變量名關鍵字比對的檢測方法容易被對抗。

4.2 熵字元串編碼檢測

在資訊論概念中，熵是對不确定性的量度，越随機的資料的熵越高。大多數API密鑰、通路Token等密碼字元串具有高度熵的特性，是以可以通過搜尋高熵字元串來檢測密碼。這種算法被以TruffleHog[14]為代表的工具所采用。現有的工具一般采用香農熵算法來計算字元串熵值，對字元串A的香農熵值計算公式如下圖所示，其中pi表示第i個字元出現的頻率[15]。

• 優點

1. 能夠檢測出無明顯特征的密碼，對于正規表達式未覆寫到的範圍有補充效果。
2. 可用于對正規表達式檢測結果的驗證，如上文提到的正規表達式誤報字元串“AKIAXXXEXAMPLEKEYXXX”，其熵值較低，可通過驗證篩除。

• 缺點

1. 字元串被判定為密碼的熵門檻值難以确定，門檻值過高容易漏報，門檻值過低又容易誤報。即使是學術論文中的門檻值也全憑實驗經驗确定，缺乏堅實的理論支撐。
2. 一些高熵值的SHA、MD5等字元串容易被誤報為密碼。對于這一問題，可通過過濾SHA、MD5值出現較密集的檔案擴充名來降低誤報，例如.lock, .inc檔案。
3. 容易将具有明顯升降序的字元串誤報為密碼。香農熵隻對出現頻率進行計算，不考慮字元順序，具有明顯升降序的字元串同樣會表現出較高熵值，例如Hex編碼的“123456789abcdef”和“d9b41a72f683ce5”兩字元串香農熵相等，但前者一般不會是一個有效的密碼。對于這一問題，需要通過一些啟發式處理方式降低升降序字元串的熵值，或通過後期過濾篩除。

05

寫死密碼檢測工具研發實踐：Gold-digger

為了保障美團整體研發環境安全，同時節約安全人員的審計成本，我們研發了針對寫死密碼的代碼掃描工具。我們認為在衆多字元串中尋找密碼如同在沙裡淘金，是以将工具命名為Gold-digger。

5.1 工具設計

為服務于全公司研發環境，Gold-digger工具有如下需求

1. 程式設計語言無關：公司各業務使用的程式設計語言不同，Gold-digger需要無障礙地應用于所有程式設計語言代碼中。
2. 子產品化，友善擴充疊代：為了根據測試回報結果不斷提高效果，Gold-digger需要長期不斷疊代。
3. 能夠內建到軟體開發生命周期中：Gold-digger側重預防，需要工具內建在CI/CD管道中，從源頭遏制密碼洩露風險。
4. 高精确率召回率：Gold-digger的設計初衷之一是節約人力成本，為降低審計、維護和營運壓力，必需盡可能準确、全面地檢測密碼。

基于上述需求，Gold-digger的架構主要分為四個子產品：核心引擎、轉換器、檢測器、過濾器。

Gold-digger工作流程如下圖，箭頭表示資料流向。核心引擎依次讀取代碼倉庫中檔案，經過預驗證和輸入處理後将代碼以行為機關傳輸給檢測器，其中部分特殊格式由轉換器處理後再傳輸給檢測器；檢測器在代碼中檢測密碼候選值；過濾器對密碼候選值進行後過濾，将過濾後的密碼傳回核心引擎；最後核心引擎将代碼倉庫中所有密碼進行收集後，将密碼相關資訊輸出為可讀性較強的JSON檔案報告。

核心引擎：該子產品為Gold-digger賦能，負責排程其他子產品，也是負責輸入輸出處理、資料收集存儲等。輸入處理部分負責讀取代碼檔案，先調用過濾器對檔案字尾進行全局預驗證，再通過引号辨別比對或調用轉換器識别代碼中的字元串及其指派變量；然後核心引擎調用調用檢測器和過濾器進行密碼收集，将檢測到的密碼資料以檔案為機關存入不同集合，能夠友善地對集合進行合并、删減等操作；輸出處理部分将倉庫中所有密碼關鍵資訊，如密碼值、檔案位置、檢測算法等，輸出為JSON格式。

轉換器：該子產品是專為部分特殊格式檔案進行格式轉換的處理器。盡管核心引擎能處理大部分代碼格式，但無法處理.yaml、.ini、.properties等不使用引号作為字元串特征辨別的格式。為保證語言無關性，我們使用轉換器處理上述特殊格式，将其轉換為用引号辨別字元串的代碼。這種解析方式無需為不同語言分析抽象文法樹，能夠有效節省算力。

檢測器：該子產品是Gold-digger的密碼檢測算法子產品。我們在綜合調研同類型檢測工具後，汲取了各方優點，采用了正規表達式比對和熵字元串檢測兩類算法。Gold-digger的檢測器包含數十種特定平台正規表達式、通用正規表達式以及Hex編碼、Base64編碼的熵字元串檢測算法。檢測器中每種算法以插件方式各自獨立，友善擴充、啟用或禁用，同時Gold-digger也允許使用者自定義檢測算法插件。代碼将周遊所有檢測算法，任一算法命中便記錄為密碼候選值。

過濾器：該子產品為Gold-digger的驗證、過濾子產品。預驗證部分在檢測器運作前對檔案格式進行驗證，篩除壓縮檔案、多媒體檔案等非文本類型；後過濾部分在檢測器運作後對所有密碼候選值進行啟發式過濾，并将過濾後的密碼傳回核心引擎。後過濾過程中每項密碼候選值将周遊所有過濾規則，所有規則都未能篩除的候選值會被記錄在密碼集合中（檢測器和過濾器的主要處理流程如下圖所示）。過濾規則主要為開發測試人員憑經驗總結的啟發式規則，例如：過濾升降序字元串、過濾高度重複字元串、過濾uuid、過濾間接引用指派等。

CI/CD內建：Gold-digger的最終目标是消除代碼中的密碼洩露問題，是以檢測到密碼并不是最後一步，修複才是最後一步。我們把Gold-digger內建到公司研發環境CI/CD管道中，友善開發人員根據密碼報告及時修複漏洞，從源頭遏制風險。當開發人員向公共存儲庫送出代碼後，Gold-digger會進行on-push掃描，對包含密碼的送出進行攔截和告警。此外，我們還允許開發人員在本地使用Gold-digger，進行pre-commit或pre-push檢查，整體風險左移。

5.2 資料對比

我們使用Gold-digger與最先進的開源工具進行了對比。

我們對内部服務代碼進行了分析，将人工安全審計發現的密碼作為測試基準，使用工具對代碼進行測試并統計結果。下表結果顯示，我們的工具準确率和召回率高于其他所有開源工具，誤報率和漏報率低于其他所有開源工具。

工具	準确率	召回率	誤報率	漏報率
Gitleaks	45.45%	7.75%	54.55%	92.25%
Git-Secrets	NAN	0.00%	NAN	100%
Whispers	40.00%	26.36%	60%	73.64%
Gittyleaks	4.43%	34.11%	95.57%	65.89%
Detect-secrets	87.36%	58.91%	12.64%	41.09%
TruffleHog	25.93%	5.43%	74.07%	94.57%
Gold-digger	98.84%	65.89%	1.16%	34.11%

分析顯示，Gold-digger檢測的密碼中大部分是通過通用正規表達式和熵字元串檢測獲得的。這是由于内部代碼中包含的密碼大多無明顯字首字尾特征，特定平台表達式檢測不到。正因如此，大部分工具盡管定義了大量的特定平台的正規表達式但漏報率仍很高，例如trufflehog定義了700多種特定平台正規表達式，但通用正規表達式種類較少，故對特定平台表達式未覆寫到部分的檢測能力較弱。Gold-digger可以利用通用正規表達式和熵字元串檢測進行彌補，有效降低漏報。

密碼檢測的一大難點是避免來自非密碼字元串的誤報。Gold-digger通過多種啟發式規則的過濾得到了較低的誤報率。其他工具大量誤報的主要原因則是正規表達式的比對範圍太寬泛又缺乏有效過濾手段，例如Gitleaks通過通用正規表達式識别到大量密碼候選值，但其中既有真正的密碼，又有appkey name、間接引用等，但未進行篩除。

06

總結

随着網際網路組織架構的高速發展和軟體釋出周期的不斷縮短，寫死密碼問題在企業代碼倉庫中日益嚴重，其危害已認證多起嚴重安全事故顯示出來。寫死密碼的大規模治理必需由安全人員和研發人員共同合作。美團為保障研發安全，設計了具有程式設計語言無關、子產品化架構、內建在CI/CD管道等特點的寫死密碼的掃描工具Gold-digger。該工具的效果優于目前所有開源工具，能夠有效幫助開發人員盡早發現并修複密碼洩露，從源頭保障研發安全。

參考文獻

[1] https://www.securitymagazine.com/articles/94776-over-two-million-corporate-secrets-detected-on-public-github-in-2020

[2]https://www.gitguardian.com/state-of-secrets-sprawl-report-2022

[3]https://blog.gitguardian.com/a-practical-guide-to-prioritize-and-remediate-thousands-of-secrets-leaks-incidents/

[4]https://blog.gitguardian.com/codecov-supply-chain-breach/?utm_medium=pdf&utm_campaign=the-state-of-secrets-sprawl-2022

[5]https://docs.shiftleft.io/ngsast/analyzing-applications/secrets

[6]https://www.ndss-symposium.org/wp-content/uploads/2019/02/ndss2019_04B-3_Meli_paper.pdf

[7]https://www.uber.com/newsroom/statement-update/

[8]https://hackerone.com/reports/716292

[9]https://blog.gitguardian.com/united-nations-databreach-jan/

[10]https://blog.twitter.com/official/en_us/topics/company/2018/keeping-your-account-secure.html

[11]https://www.zdnet.com/article/github-says-bug-exposed-account-passwords/

[12]https://www.uber.com/newsroom/2016-data-incident/

[13]https://www.secpulse.com/archives/172585.html

[14]https://github.com/trufflesecurity/trufflehog

[15]http://www.ueltschi.org/teaching/chapShannon.pdf

作者:喬丹

來源:微信公衆号:美團安全應急響應中心

出處:https://mp.weixin.qq.com/s/QDc-SyOYtCAx_G-4jWbLKg