0X01 前言
怎么衡量一個掃描器的好壞，掃描覆寫率高、掃描快、掃描程序安全
而最直接的效果就是掃描覆寫率高（掃的全）
怎么掃描全面，1 流量全面 2 規則漏報低
流量方面上篇已經講過，這篇主要講掃描規則，
掃描規則漏報率低，從整體考慮，一方面是規則全，廣度上有保證；一方面是檢測手段有深度，可以跨能力聯動檢測，有能力解決主要和旁枝末節處的漏報場景
0X02 規則來源
掃描器的規則主要有兩種型別
針對介面的web漏洞，通常是通用型漏洞，OWASP TOP 10，sql注入、xss、ssrf、xxe等，以下簡稱web規則
針對主機(包括整個站點)的漏洞，通常是特定框架/應用/組件的0day/nday漏洞，以下簡稱主機規則，
2.1 主機規則
2.1.1 覆寫nday
針對nday，主要考慮的是企業內資產，
在資產方面獲取到企業內所有IP與埠后，進行埠指紋識別（服務指紋識別/WEB應用指紋識別），根據每種指紋的數量排序，優先解決TOP100 / TOP 200 / TOP 500 的服務的歷史高危漏洞，
2.1.2 覆寫新出的漏洞
針對0day漏洞，我們要解決的是新曝光的影響面較大的0day（很多情況下，新漏洞都是靠朋友圈/公眾號，這部分是隨人的，可能隨著人員流動、發現的敏銳度會變化，所以盡量做成自動化運營流程），
這里主要通過漏洞預警功能(或類似叫法)，
周期獲取cve漏洞串列，匹配內網資產，再檢測其他平臺是否有對應cve編號，優先判斷又有資產又有poc或exp的漏洞是否有影響，有較多資產代表影響范圍較大，有poc或exp代表外部大概率已經有人在掃描與利用了，
然后再判斷有資產的但沒有poc與exp的是否影響范圍較大，是否需要投入人力對漏洞進行研究（個人認為這是甲方的研究的一個需求，但是往往投入產出較低，所以需求較低），
對應的功能是各家乙方的漏洞預警公告
阿里云漏洞庫
騰訊云漏洞掃描服務情報中心
如果短期無法進行流程建設，定期由運營人員去看一下這些串列，判斷資產匹配程度，有資產的漏洞撰寫成插件進行掃描，也可以有較好的收斂效果，
另外說一下資產指紋識別，理想情況下通過指紋識別打標，可以知道企業所有服務，但指紋識別有一個難點在于不知道有什么資產，就寫不出對應的指紋規則，
所以需要有對應的打標流程，上文提過指紋打標，通過多特征組合成規則的形式，完成一個打標功能建設，
打標的需求源頭，主要一方面就是漏洞預警，針對0day快速檢測對應服務的資產數量，否則內網幾十萬的機器量級，每次都花費數小時全部掃描一遍來判斷服務數量，影響漏洞回應時間（MTTR），同時完善資產指紋，對資產較多的服務，歷史漏洞也處理一遍，
2.2 web規則
2.2.2 覆寫場景全
web規則主要是針對通用型漏洞，
首先把場景保存下來，以靶場的形式，可以周期進行驗證，驗證每個漏洞型別是否每個場景都能檢出，
靶場作為裁判員，安全產品作為運動員，
怎么能找出所有的web通用型漏洞呢？
a. 漏洞型別
尋找各種同類安全產品支持檢測的掃描型別，從中排除掉危害較低的或者不存在于公司場景的
b. 每種型別的漏洞場景
常常有這樣的情況，有檢測sql注入、存盤xss的插件，但是有些場景沒有顧及到，比如header里的注入、post json中的注入等，
場景考慮齊全，需要針對每種漏洞抽取出維度，有一部分是公共維度，有一部分是私有維度，再進行維度相乘，得到最終各種場景，
舉個例子：比如注入有哪些型別和場景？
維度可以是 不同來源/不同過濾與防御條件/不同執行方式/不同輸出方式等，而這些是公共維度，類比到其他漏洞型別也可以按這樣劃分；私有維度比如資料庫版本、資料庫報錯是否開啟等（單獨影響該漏洞場景），
將每個維度的種種可能乘起來，得到各種場景，其中之一例如 來源于cookie+過濾了單引號+jdbc執行+無回顯+mysql5.7，
2.2.2 覆寫新場景
主要是漏洞召回，來源如應急回應中心、等保測評、紅藍對抗等，
召回時排查全流程問題，流量有沒有進入引擎、是否系結了對應的檢測規則、掃描程序的結果是什么、最后結果有沒有入庫等，如果是規則問題，需要新增靶場
召回會有一部分原因是固定的無法快速解決的，比如流量缺失(post/cookie等)、檢測能力不足，召回一段時間后再重點推動解決導致漏報的大頭問題，
2.3 準確率保障：靶場
另外說靶場，這里靶場是一個比較重要的安全產品
作為檢測能力的裁判員，主要的作用是
a. 將各種漏洞場景持久化沉淀下來，隨著召回不斷進行，場景也會越來越多
隨著人員流動，當初某個規則所用到的測驗環境，可能會消失，交接人員對規則進行優化時，又需要重復測驗環境搭建程序，成本較大，而把場景轉換成web代碼場景、或者docker file沉淀下來，極大減小了優化程序的成本，
b. 衡量各種漏洞檢測安全產品的能力，給出準確率、漏報率等資料
規則的準確率，是提高且穩定漏洞產出的一個重要環節，在規則數達到幾百上千的情況下，每個規則是否有效，往往是撰寫時候臨時做了驗證，
后期可能因為某些原因（比如造成了業務影響、導致引擎性能問題）下掉或者減少檢出場景，而忘了加回來丟在記憶角落里，次數多了，整體場景檢出率可能很低，只有內網滲透召回時才發現那么多漏報，所以準確率驗證十分有必要
c. 測驗安全防護代碼的可用性、有效性
安全防護代碼是否有效，能防護住所有認知里的場景，是否在壓測情況下對業務性能沒有過多影響，這是靶場的驗證效果，
整體來說，輔助功能比較大，極大的保證了每個規則的準確率，但直接產出可能不是很明顯，屬于發展到較為成熟時的能力，
0X03 檢測方式
3.1 跨能力聯動檢測
結合各種側信道功能，增強掃描能力
比如最常見的dnslog，命令執行時在服務器上執行dns查詢，dns請求經過dns服務器層層穿透到外網，再傳回給掃描器；根據dns標識，判斷具體的掃描任務觸發了，dns的特點在于可穿透不通網但不禁dns的場景，但無法鎖定觸發IP（一般為dns服務器IP），
再比如http log，curl/wget發起http請求，根據http請求中的標識判斷漏洞，無法檢測不出網的環境，但是可以鎖定訪問IP，部署在公網的http log，主要面對于存盤型xss這類請求可能是在外網觸發的，
針對命令執行類的，最好是用部署在內網的http log，dnslog偶爾會出現觸發了、但是和流量關系不大的問題，比如路由器不定時觸發、某業務收集鏡像流量并做了異步流量處理的定時任務、某個測驗收到請求后好奇請求了一次，會有溯源難的問題，http log剛好把內網IP鎖定，且ssrf也得使用內網http log，
java agent 探針，獲取執行層的函式與引數，像注入/任意檔案讀寫(寫crontab等命令執行來檢測有危害)這種也可以檢測出來，
或者是主機agent (HIDS) 監控主機特定檔案內容來判斷檔案操作
或者是sql日志聚合匯總來判斷sql注入
另外檢測時避免造成業務影響，比如log4J的ldap鏈接不斷開可能導致業務hang住，
3.2 單一漏洞檢測能力深入
比如針對XSS，現有很多場景都是前后端分離，單純的 requests.get獲取頁面內容再正則匹配已經有點古老的，
使用headless瀏覽器決議JS，
監聽彈框事件，針對所有引數插入payload；或者作預處理，針對所有payload出現的位置構造特定的payload等，
3.3 豐富檢測所需流量資源
3.3.1 登錄態
大多數檢測所需要的登錄態，鏡像流量方案，無法使用用戶的cookie、header（業務自定義header可能帶有用戶登錄憑證），所以得構造測驗cookie，
在有所有業務統一接入passport的情況下（一個cookie或者token對所有業務生效），和passport申請介面更新cookie就好了，
有的業務接入passport會將passport認證映射到自己的用戶體系，登錄passport后根據獲取到的token，在后端自己驗證所屬用戶后、賦予業務自己的賬號權限，這種情況最好能找到passport下游接入呼叫方，統一更新對應業務的登錄憑證，
而業務比較復雜、存在多種認證場景的情況下，比較麻煩，不同的域名或者子域名，需要定期的更新cookie，
這種情況需要一套自動登錄程式，填寫賬號密碼，加上驗證碼自動填寫，獲取到cookie后到每個單位的驗證地址去驗證cookie有效性，通過不斷召回運營，豐富登錄態，
3.3.2 后綴
正常情況下，流量過濾的步驟會過濾掉 js/css/zip/jpg/png等靜態資源后綴，
但是有部分漏洞需要這些后綴，得通過召回豐富待檢測資源，
比如 xxx.jpg?height=100&width=100，可能后端會根據引數構造回傳包，會有dos的風險，
有的js檔案會泄露未授權的介面，WADL檔案存在介面泄露等
召回程序，會遇到很多流量缺胳膊短腿、任務丟失、核心請求函式不支持、檢測手段不足、檢測ROI低所以放棄等情況，路漫漫
0X04 總結
通過覆寫現有的漏洞場景，建立未知場景運營流程，深入檢測手法、檢測資源，并使用靶場確保每個漏洞場景都可以有效檢出，可以做到保證整體覆寫率，
且自研DAST在規則檢測上更貼合企業自身業務，更細、更全、更快，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/498785.html
標籤：訊息安全
上一篇：CVE-2020-13945