無論是網銀頁面、開源軟體，還是作業系統本身，現代社會對技術的依賴使得科技從業者和普通大眾都不得不依賴他人編寫的代碼。出於保持一致性與實際可行性的需要，代碼庫等工具應運而生——畢竟從零開始編寫每段代碼，這種做法完全不具備可擴展性。

環境越是複雜，就越需要尋找能實現自動化操作以及複用現有工具的場景。

但當開發者將這些現成的代碼庫作為自己所開發的程式的基礎時，就會產生“信任問題”——這種信任層級在安全專家眼中往往意味著風險。漏洞在原始程式碼中隱藏得越深，就越難被發現，更何況前提是你得知道要在浩如煙海的代碼堆裡尋找這根“數位銀針”。

Akamai自己的開發過程中就曾遇到過這類“信任問題”所造成的典型案例：某次對外部服務的常規調用，最終竟暴露出多個高危攻擊入口。在向供應商披露相關資訊後，這些已發現的漏洞已被妥善修復。本文將分享Akamai的發現過程，詳細剖析漏洞機理，並探討攻擊者可能的利用手段。

發現問題

Akamai的一名DevOps工程師，在執行例行優化測試時，為一款第三方測試工具部署了一個新的容器實例。為此他執行了再熟悉不過的命令：apt get update && apt get install XXXX -y。

輸入該命令，本是為了查看在部署過程中，運行時終端上正在執行的內容。為此，我們在終端上運行了一個簡單的列出進程的命令ps，然後發現了這行非常有趣的內容：

我們成功使用識別出的憑證驗證登錄了一個網站，裡面包含了數百個客戶的構建內容。

明文金鑰的存在令人震驚，但如果有恰當的用戶控制措施（例如權杖是在每次使用應用時生成的），倒也可以解釋或加以控制。可惜，本例顯然不是這種情況。提供的用戶名中包含了“default”字樣，而這從來都不是一個好兆頭。

我們決定再深入一點，嘗試使用這些憑證去驗證API的存取權限，結果發現我們可以查詢大量可能包含敏感資訊的資料。事實證明，這個“default”用戶確實名副其實——它並不是專門為Akamai使用所設，而是被整個應用的所有客戶共用的。

掌握了這個明文金鑰後，任何攻擊者都可以利用它來獲取敏感性資料，比如內部測試運行結果、視頻錄製、螢幕截圖，以及內部腳本的執行流程，該應用的大部分客戶都會受到影響（圖1）。

圖1：被不當訪問的敏感客戶資料示例

如此大量的資料被暴露，再加上這個漏洞幾乎明晃晃地擺在人們眼前，Akamai決定進一步深入研究，看看還能發現些什麼。

分享並不總是好事

在發現該應用嚴重濫用一個共用金鑰後，我們決定嘗試找出是否還存在其他類似金鑰。通過在應用原始程式碼中進行幾次有針對性的搜索（以及大量格式調整工作），我們又發現了三個額外的金鑰：

• 一個Coralogix私密金鑰

• 一個Google API金鑰

• 一個ngrok權杖

接下來，我們將逐一分析這些金鑰及其可能被濫用的風險。

Coralogix：一個（極為廣泛公開的）私密金鑰

我們在應用程式的代碼庫中發現的金鑰之一是一個私密金鑰，這引起了我們的興趣，於是開始搜索是否有與該私密金鑰相關聯的用戶名。最終在金鑰下方幾行的日誌記錄函數中找到了一個用戶名。通過進一步調查，我們發現這個私密金鑰屬於Coralogix日誌記錄框架。

這些憑證是硬編碼在代碼中的，這意味著它們可能被不同客戶共用。這可能導致另一個潛在的資料洩露問題，所幸的是，該用戶/攻擊者的許可權較低，僅被允許向日誌框架中寫入日誌資訊。

儘管這類寫入許可權不像之前發現的訪問原語那樣強大，但仍可能為攻擊者提供一些有趣的攻擊路徑：攻擊者可以向軟體供應商的環境中插入偽造的日誌消息，或者嘗試注入惡意日誌內容，從而發起諸如跨站腳本攻擊（XSS）或結構化查詢語言注入（SQL注入）等攻擊手段。

Google API金鑰

OAuth是一種授權機制，被Google的所有服務廣泛使用。應用程式和網站可通過OAuth，讓用戶使用自己的Google帳戶登錄這些應用或網站。要通過代碼啟用這種登錄方式，開發者需要從自己的Google帳戶中獲取幾個參數，也就是他們的API金鑰：包括google_name和google_secret。

在流覽代碼時，我們發現了對Google API的引用。通常當看到“google
api”相關內容時，只有一個API金鑰而已。但這次不一樣。這次我們不僅看到了“google
api”金鑰，還看到了google_client唯一識別碼，甚至（最令人震驚的是！）還找到了google_secret識別字。擁有這三項資訊，攻擊者就可以偽裝成該廠商，向Google請求一個認證連結。這個連結可被用在釣魚攻擊中，引誘受害者授權攻擊者訪問自己的Google
Workspace。

潛在的釣魚攻擊利用方式

攻擊者可以建立一封釣魚郵件，郵件中包含一個指向與廠商官網幾乎一模一樣的網站連結，唯一的關鍵區別在於“使用Google登錄”連結，其實這是攻擊者利用廠商洩漏的Google
API憑證生成的釣魚連結（圖2）。

圖2：惡意的Google登錄頁面看起來十分逼真

一旦受害者登錄，就等於將自己整個Google
Workspace帳戶的存取權限授權給了攻擊者。憑藉對如此敏感身份的存取權限，攻擊者的可操作空間將非常廣泛。成功利用這一點後，攻擊者可以操控受害者Google
Workspace帳戶的任何內容，包括篡改郵箱、下載檔案，甚至其他更危險的操作。在對企業發動社會工程學攻擊時，這將成為一種非常有力的工具。

ngrok

網路隧道幾乎是實現安全資料傳輸的萬能解決方案，可這樣的隧道一旦被攻破，就可能為攻擊者帶來大量可利用的作惡機會。在受感染應用的安裝過程中，我們發現了許多與隧道相關的配置參數，包括一個ngrok設定檔，這促使我們進一步展開調查。正是這些有助於提升開發者協作效率的功能，也讓它對威脅行為者充滿吸引力。

Ngrok是一個專門提供資訊隧道傳輸平臺的服務。它可以非常輕鬆地將本機服務公開到互聯網上，從而加快調試流程、提高開發回饋效率。不幸的是，如果攻擊者掌控了這個隧道，那麼這種“簡便性”同樣會為他們所用。

通過執行一個簡單的ps命令，攻擊者可以查看企業的唯一ID和認證權杖。這個唯一ID是不可更改的，在其他終端上使用該應用時也將保持不變。攻擊者可以利用這些參數，將ID和權杖發送到廠商的線上伺服器，從而獲取目標企業的ngrok配置資訊（圖3）。

圖3：從廠商伺服器收到的ngrok權杖

這意味著，在初步訪問後，攻擊者就可以從受害者那裡複製唯一ID和權杖，並利用這些資訊讀取受害者應用程式發送/接收的其他資料（圖4）。

圖4：從ngrok隧道讀取數據的示例

總結

威脅並不僅僅來自外部。實際上，我們有時也會主動接受一些內部威脅。許多人認為開源軟體是最大的危險，因為我們對其很信任，但實際上，協力廠商工具可能會比開源軟體對企業構成更大的挑戰。

在發現這些問題後，我們就將本文提到的漏洞披露給了相關廠商，並且問題現已被修復。儘管如此，新的安全性漏洞可能依然潛伏在不遠處。

Akamai認為，面對這種（以及很多其他）情況，需要樹立足夠的安全意識，而在這方面，安全監督與開發者培訓都是很重要的工作。只有這兩者相結合，才能保證託管服務不會給企業帶來安全隱患。

歡迎關注Akamai，通過定期更新的文章瞭解更多與Web、安全、雲計算、邊緣計算有關的資訊和見解。