長期致力傳承高強度資安攻防知識的果核數位,於日前舉辦2023首發Hacker Talk論壇,探討企業藍隊在面對駭客破壞時,如何提升戰鬥值並全面補強防禦,及企業開發與資安團隊如何獲得共識,鞏固企業資安。
掌握關鍵撇步,高效處理入侵事件
詮睿科技資安處Zero Chen率先開講,從藍隊角度探討入侵事件處理議題。他擅長挖掘惡意程式,曾舉報KMPlayer SCA、Operation DRBControl等著名資安事件。
Zero Chen說,綜觀攻擊者入侵流程,通常先滲透,再依序佈置中繼站連線、執行內部攻擊與橫向提權,最終入侵成功造成商業損失。但事件處理順序通常是反過來的,先察覺到異常,再設法探索根因。企業應儘可能保留現場以利事件調查,並以日誌作為調查依據,避免與攻擊者龜兔賽跑、先確認所有可用的入侵指標(IoC)再一次處理,且盡可能找出事件根源並改善,最後找專業資安顧問協助。
他強調「眼見不一定為真」,因惡意程式藏在系統的方法很多,如直接寫成新服務、掛在TaskScheduler裡面、Payload分段混淆後寫在機碼表裡面分段載入…等,族繁不及備載,共通點是現今大部份Loader,皆用正常程序做掛載。
再者不要期待惡意程式這麼容易辨識,要用防毒軟體抓更困難:因為惡意程式大部份都做程式碼簽章(Code Signing),攻擊者會偷憑證來使用,也常見以DLL Side Loading來種後門,例如你執行一個EXE檔,攻擊者需找尋所需函式庫,先從根目錄找起,若沒有再去System32、SysWow64…等任何與環境變數有關的路徑找,接著進行「狸換換太子」置入被竄改的惡意DLL檔,藉此發動DLL Side Loading攻擊。
顯見攻擊者會利用正常程式、被簽署過的檔案,看起來是合法的,故能躲過防毒軟體偵測。例如曾有駭客鎖定Windows Defender的主要執行程序,以遭竄改的mpsvc.dll接受呼叫,達到DLL Side Loading目的。
藍隊能從何處看出端倪?首先可觀察DLL檔所在的Path,通常攻擊者會把惡意程式藏在一些奇怪路徑。如防毒軟體不可能把主要程式裝在System32裡,若你發現有此現象,即便有簽章仍應視為異常;此外一般而言經常遭到注入的svchost 的,其「父母」Parent Process只會是 services.exe,若你看到一支獨立的 svchost ,就應提高警覺。
「其實我們有一些方法可以主動出擊,」Zero Chen指出,要想在第一時間知道資料被他人撈走,可考慮在會員資料庫或Transaction Table插入特定假資料,再監控這些假資料有無被讀取,若有,便是異常現象。
至於其他小撇步,包括偵測疑似惡意程式,例如拉出Event ID 7040/7045做成Index List,經由每日比對找出差異項目做檢查,或針對特定常用於橫向攻擊的字串做檢查(如PsExec、PSEXESVC)。再者觀察防毒軟體偵測到的可疑檔案路徑,是否為隱藏目錄如/ProgramData/、/windows/、或/windows/system32/,若是就不要把它當成單一事件,應懷疑是存在許久的後門,立即找專家分析鑑識。
最後建議企業須設立CSIRT、即第一線資安事件處理單位,成員應涵蓋各技術單位、資安單位、稽核風控單位、公關單位、領導者、第三方資安顧問。CSIRT主管應是上位領導者,對各單位有高度話語權方能針對發生的事件進行妥善有效的處理。
扁平化溝通,使開發與資安順暢合作
果核數位軟體開發安全部主任Lung-Yu Tsai(Tygr)表示,軟體開發工程師的主要任務是寫程式。然而,企業管理層是否曾思考過如何定義程式能力的優劣,以及如何評估產出軟體的品質好壞?現今企業經常要求工程師在有限的時間內開發眾多功能,但卻沒有給予足夠的時間針對軟體品質和軟體安全性的相關項目進行妥善的管控與強化,因此,企業往往會埋下資安隱患。
在管理面議題,現今企業認為購置網通設備就可以保障企業的安全性。然而,任何設備都可能存在零日漏洞,而企業花費了龐大資源購買安全防護設備可能未能有足夠的成效,同時企業可能因維護與管理設備而耗盡極其有限的資安資源。與其如此,應該強化應用程式的安全性,方能從根本解決問題。例如,開發團隊認為企業存在WAF(Web 應用程式防火牆),因而未進行妥善的輸入驗證,當網路駭客成功繞過WAF的保護後,就能輕易攻擊防禦應用程式,並有機會進一步入侵到企業內部網路環境。
至於資安治理方面,資安單位是否為組織做好資安藍圖的規畫?能否正確且深入了解到管理規範或資安標準的條文本質,並透過設計正確且有效的控制措施以及進行妥善的檢核作業。譬如導入SIEM系統除了可以幫助資安人員及時檢測和回應異常事件,並對事件進行深入調查,並且統一收容日誌的機制可以確保日誌不被刪除,以規避重要日誌遺失的風險,並且在未來可供事件調查和追蹤。除了仰賴資安解決方案,同時可以要求軟體工程師根據特定規範或標準撰寫的日誌,此要求可以強化系統異常的分析的同時,對於資安事件調查也能有正向的影響,因為此舉可以提供有關應用程式的運行情況和異常事件的詳細信息,供調查人員更準確的鎖定問題的原因。
最後討論應用程式開發的常見安全性議題,以SQL Injection為例,它長期穩居OWASP Top 10,顯見始終是值得留意的威脅;為了防範它,各大資安網站皆已經有標準的程式撰寫範本以達到防禦的效用,且目前主流的原碼掃描檢測工具皆應已具備一定程度的偵測能力,然而Stored Procedure可能是安全檢查的漏網之魚,因企業進行原碼掃描時通常僅針對應用程式的原始碼,而Stored Procedure卻通常不在其檢測範圍之內;其餘諸如Insecure Randomness乃至JNDI等更多議題亦有類似情節,往往由於開發端不認為是問題、而資安端又缺乏足夠判斷力之下,埋下未爆彈。並且,若資安單位未闡明相應的安全議題的情況要求開發人員修補,開發人員可能因專案時程的壓力與人員溝通成本,選擇將存在弱點的程式碼寫進非原始碼檢測範圍內(例如:Stored Procedure、dll、jar…等),心想偵測機制找不到即代表無資安風險,大家像吃了蜜糖一樣開心過日子。然而此現象,肯定不是企業管理層樂見的結果。
當前企業解決資安問題的首要之策是建立扁平化的溝通機制。由於資安和開發兩端的技術專長有所侷限,必須透過溝通來達成共識。只有彼此合作,才能真正落實軟體開發安全框架規範(SSDF)。此外,透過教育訓練,開發人員和資安人員可以互相了解對方的專業知識,使溝通更加容易,並有助於企業有更多資源進行安全配置。除了基礎的資安防禦外,這些措施還能夠有助於企業持續強化其資安防禦措施。
熱門新聞
2024-11-12
2024-11-18
2024-11-15
2024-11-15
2024-11-18