從雲AK洩露利用看企業特權管理
從雲AK洩露利用看企業特權管理
|
目錄 |
|
- 緣起 |
如果你是一名駭客，你是試圖直接攻擊一個層層加固、佈滿各種檢測技術、24小時人員職守的系統並竊取資料。還是選擇通過社會工程學的方式獲取系統賬號後，如入無人之境地檢視、下載資料。
大多數情況從外部發起攻擊都需要經歷建立據點、搜尋目標、獲取許可權、拿到資料的幾個階段。對於一個基礎安全牢固且運營良好的系統而言，直接攻擊將耗費大量的時間和精力，而通過社工等方式獲取系統特權賬號則成了一條捷徑。
緣起
雲環境相比傳統環境，新增的一大風險即使用者Access key的洩露風險。AK是應用程式呼叫雲平臺API時使用的認證憑據。一個使用者的AK洩露往往代表使用者在雲平臺最高許可權的洩露，雲環境中所有計算、儲存資源對入侵者門洞大開。非法利用者甚至不需要為此單獨開發工具，直接使用現成的產品就能直接獲取使用者在雲內的所有資源列表。
將AK匯入商用的產品後可輕鬆獲取使用者雲上資源
入侵者實際能做的還遠不止這些。包括輕易檢視當前使用者所有的資料資產，在主機資產上執行任意命令，修改儲存存取許可權，資料庫賬號建立、提權，增加高許可權使用者，刪除紀錄檔等等，可謂是無所不能。所以不能簡單地將雲平臺的AK當作單個系統的頂級許可權，而是雲上所有資源的頂級許可權。這也註定了使用者在雲上的AK將成為攻擊者的重點目標。
AK功能強大，基本上管理員賬號能做的AK都能做
當前主流AK洩露檢測方式
從Gartner預言至少90%的雲安全事故是因為使用者的錯誤設定導致，到CSPM成為熱門。AK洩露的檢測其實並不是一個全新的領域。但是現有對於雲平臺AK洩露的手段主要還集中在檢測程式碼洩露這一個途徑上。
將倉庫克隆到本地後就可以通過正規表示式來搜尋，當時實際的掃描會更復雜一點，github承載的程式碼已經非常龐大了。
這種檢測方式主要思想為：每次使用者commit程式碼，新增新的檔案或修改現有的檔案時，金鑰洩漏檢測模組就會被啟動。掃描被寫死到程式碼中的Access Key和Access Secret字串，將疑似AK的字串傳送給對應合作伙伴處進行確認，一旦合作伙伴匹配上真實的AK，即認為發生了AK明文洩露。隨後對AK的擁有者傳送郵件告警。
按照這位老哥在這裡的測試，他故意提交包含AWS明文AK的程式碼到github平臺測試惡意攻擊者利用的時間。從提交程式碼到收到AWS 平臺發出的AK洩露告警郵件，中間時間間隔不到1分鐘。
而需要注意的是程式碼提交6分鐘後，故意洩露的AK已經被3個攻擊者利用，而且產生了查詢S3儲存桶的紀錄檔記錄。
之所以有6分鐘的延遲，還是因為github平臺 commit 的事件訂閱流有5分鐘延遲。也就是說扣掉這5分鐘延遲，攻擊者和git平臺幾乎同時發現使用者洩露的明文AK（扣除發郵件的時間，可能github平臺稍快一點？不過重點還是在於攻擊手段之普遍）。
這種通過掃描程式設計師程式碼中寫死AK的檢測技術，有點類似於密碼撞庫，其優點在於：
1、能在AK洩露的第一時間儘早發現，運氣好的話AK此時還未被真正利用，給AK擁有者留了一定的反應時間。但是鑑於惡意使用者的掃描速度，以及從收到通知到完全禁用AK中間的操作時間，這個時間還是不容樂觀，最好能通過SOAR工具進行自動化響應。
2、可檢測的AK種類不侷限於單個平臺。目前國內的阿里雲、騰訊雲、京東雲的AK都在github官方支援的範圍內。https://docs.github.com/en/code-security/secret-scanning/secret-scanning-patterns#supported-secrets-for-partner-patterns
但是，這種方案的問題也很明顯：
- 對於非git平臺上傳的程式碼無法檢測。程式碼管理平臺那麼多，不是每個都整合了AK明文檢查。而且git平臺的合作伙伴數量也很有限，並沒有覆蓋企業使用者的核心供應商，這是非常致命的問題。而且在越來越多的企業資訊管理趨嚴，禁止員工將程式碼上傳公共平臺的情況下，這個方案的效果將比較有限。
- 內部人員被網路釣魚、社會工程後洩露的AK無法及時發現。極有可能發一個免費領雲平臺代金券的釣魚郵件就能收穫到一堆的AK，參照某學校發郵件領月餅的測試。
- 這種檢測方式無法檢測通過第三方系統暴露的AK，雲平臺AK應用範圍極為廣闊，雲廠家在努力構建生態的同時，各種生態的合作伙伴水平參差不齊，容易成為整個環節的短板，一旦發生從第三方洩露的事件，極有可能又會產生對雲平臺的信任危機，以及最終責任難以追溯。
- 最後還是跟第三方有關，使用者在開放AK給第三方時，如果沒有做到良好的存取控制，不受監控的第三方可能濫用AK許可權讀取和儲存過多原本它不應該讀取的資料。
當然除了程式碼庫掃描以外，還有其他的檢測方式，比如通過瀏覽器外掛來掃描隱藏在跨源http請求中的AK，但這些方案目前都還不是企業級方案。
防止AK濫用的關鍵要素？
AK濫用的問題需要從平臺方和使用者方兩邊共同解決。平臺方需要提供足夠多的安全措施，而使用者則需要做好特權的管理。
1、預設安全：安全與開放和便利天然就是對立的，從雲平臺的角度來說對於開放API的範圍以及開放的形式需要更加謹慎。高危的功能以什麼形式開放，執行許可權和編輯許可權是否同時對外開放等。應該經過充分的安全評估後，再決定對外開放的範圍。
2、分權。避免許可權濫用最重要的就是做分權，這是API設計思想層面的改造。在給子賬號分配許可權時，將API分為讀、寫操作能達到及格的水平。按API業務屬性和管理屬性區分會更適合。參照三權分立的思想，建立金鑰、重置主機密碼這類授權類的讀寫API，與資源列表、彈性設定等業務資料類的讀寫API分開。上傳任意自定義指令碼與執行已經上傳指令碼的許可權分開。最安全的方式也是雲平臺推薦的方式即刪除主AK，只保留子AK。
3、審計和檢測。對於AK的利用行為進行審計，記錄下請求發起方的角色、呼叫的記錄、讀取的範例範圍等內容。用以評估是否有AK在使用者不知情的情況下被呼叫。在這基礎上可以進一步基於行為進行呼叫風險的檢測，對於某些特定的API呼叫序列進行告警，高風險API的呼叫告警。這一點似乎還沒有哪一個雲平臺做到足夠的重視。
4、存取控制。平臺方有義務提供足夠多的存取控制手段，包括不限於單獨限制每一個AK存取源IP、存取時間段、可以存取的資源集/資源id、可以呼叫的API的範圍。儘量從API許可權層面縮減暴露面，減少不必要的存取風險。不過這麼基礎的能力，目前卻只有華為雲做了，而且不能單獨對AK進行設定。限制key的使用範圍是非常有必要的，但是存取控制不能解決所有的問題。因為高許可權的key始終存在洩露的風險，除非高許可權的key不存在。
這些都是在git平臺洩露檢測以外，出於安全的主觀視角去考慮應該如何防止最高許可權被濫用。當前主流雲平臺可提供的檢測方案與理想還存在不小的差距，更別提還有很多雲平臺連AK洩露檢測都還沒有。
對於企業使用者而言問題要更棘手一點，AK只是特權賬號的一種，分散在各級系統、產品、控制檯中的特權賬號依舊無法得到有效管理。使用者也無法被動指望自己的所有供應商都提供足夠的特權管理手段。站在使用者的角度來看，特權賬號的管理必須是一個統一的產品，而不是鬆散的產品集合。但是目前並沒有一個產品能夠提供所有的保護手段。
哪些算特權賬號管理？
特權賬號廣泛分佈在企業內部的各個作業系統、應用程式中，而一旦發生雲平臺AK這種頂級許可權的洩露將危害無窮。按照許可權級別，大致可以分為以下3類。
根據賬號的屬性分，大致可以分為4類。
對於特權賬號的管理，重點則在於對這4類賬號中的高特權的管理員賬號進行識別和管理。
如何做特權賬號管理？
特權管理的思路本質上與管理其他的資產沒有太大的區別。為了達到最佳效果，特權管理解決方案應該至少接入ATT&CK框架中常用到的本地賬號、域賬號、雲賬號。並且能夠做到：
- 能夠協助企業管理人員識別分散在內部各種系統中的特權賬號-包括root賬號、公用賬號、高許可權管理員、SSH金鑰、證書、API key等等。
- 持續監控賬號狀態，包括賬號的許可權變更、輪換記錄、使用範圍等資訊。
- 根據賬號的許可權等級和用途，將特權賬號的使用監控起來，審計特權賬號的所有使用記錄，包括特權賬號的登陸裝置、存取源、存取目的、存取時間、存取資料範圍等資訊，及時發發現對關鍵檔案和目錄的未授權存取和/或更改。
- 最好能根據賬號的使用記錄自動學習生成每個賬號的安全策略。再通過人的運營來補齊管理策略。
- 能對特權賬號的可疑行為進行告警。必要時並可以聯動其他裝置，阻斷惡意的存取行為。對可疑的活動進行阻斷或放行後，能持續更新賬號安全策略。
特權管理與堡壘機、IAM、零信任的關係？
堡壘機、IAM、零信任都屬於特權管理的一部分，在特權管理的實施層面提供支援。這些產品在各自領域都能發揮特權存取控制的能力，應該利用他們自身的認證、審計和管控能力，保證特權管理策略落地。
而零信任平臺則是在將來最有希望能夠成為統一大PAM的平臺。只是目前的階段還掙扎在許可權控制的大坑裡。
特權管理是否應該侵入到業務流程中？
對於特權管理平臺的建設，是否應該做一個大而全的系統，不僅僅是監控特權賬號的濫用，還要深入到特權賬號的整個生命週期中，將特權賬號建立、使用、刪除、審計全部管理起來？
我個人認為在初期沒有必要，不要過度追求一個完美的系統。不同型別的賬號管理方式差異很大，包括認證方式、密碼輪換策略、存取控制策略等都不相同。如果在一開始就將所有的東西整合在一個大的平臺內，會導致這一個平臺的工程量和建設週期被無限拉長，且變得過於依賴執行層面的裝置，然後面臨大量客製化開發。
相反通過採集這些特權賬號的使用紀錄檔，通過巨量資料的方式檢測特權賬號的生成、使用、洩露。以及特權賬號，會更容易落地。並且可以與惡意行為關聯起來。
這個世界總會有新的變化，你無法阻止它們。安全不是阻止未知的事物或做一些很酷的新事物。決定你能做什麼不能做什麼，並集中精力把基本的事情做好。
參考資料：
1、Privileged Attack Vectors
2、Detecting and Mitigating Secret-Key Leaks in Source Code Repositories
3、 https://www.anquanke.com/post/id/275261 雲主機AK/SK洩露利用
4、 https://docs.github.com/en/developers/overview/secret-scanning-partner-program Secret scanning partner program