Nuclei 進階—深入理解 Workflows、Matchers 和 Extractors
前面的文章中介紹了nuclei的基礎使用方法，可以參考文章：
接下來我重點講解一下nuclei中的三個概念，Workflows、Mathcer和Extractors。這些內容將有助于幫助大家編寫更為復雜和高效的檢測腳本！
workflows
Workflows允許用戶自定義模板的執(zhí)行順序，這是使用nuclei最高效的方式，官方推薦用戶使用自定義Workflows進而縮短掃描時間，提升掃描效率！
- 基礎工作流
例如，定義workflow 掃描files目錄下如下yaml：
workflows:- template: files/git-config.yaml- template: files/svn-config.yaml- template: files/env-file.yaml- template: files/backup-files.yaml- tags: xss,ssrf,cve,lfi
- 條件工作流
首先確認springboot-detect.yaml是否正確執(zhí)行，如果OK，則運行subtemplates下的template，實例如下：
id: springboot-workflowinfo:name: Springboot Security Checksauthor: dwisiswant0workflows:- template: security-misconfiguration/springboot-detect.yamlsubtemplates:- template: cves/CVE-2018-1271.yaml- template: cves/CVE-2018-1271.yaml- template: cves/CVE-2020-5410.yaml- template: vulnerabilities/springboot-actuators-jolokia-xxe.yaml- template: vulnerabilities/springboot-h2-db-rce.yaml
運行workflows。
nuclei -list http_urls.txt -w workflows/my-workflow.yaml。
Matchers
Mathcer顧明思議，就是提供了一些規(guī)則，來對響應結果進行比較匹配！常用有六種類型的。
mathcer，如下所示：
- status Integer Comparisons of Part
- size Content Length of Part
- word Part for a protocol
- regex Part for a protocol
- binary Part for a protocol
- dsl Part for a protocol
例如想對響應碼進行比較匹配，寫法如下：
matchers:# Match the status codes- type: status# Some status codes we want to matchstatus:- 200
想對響應碼進行復雜的匹配時，可以使用dsl。
matchers:- type: dsldsl:- "len(body)<1024 && status_code==200"- "contains(toupper(body), md5(cookie))"
上個實例的含義是匹配響應體長度小于1024 并且狀態(tài)碼是200。
判斷大寫的body中是否包括cookie的md5sum。
使用condition: and\or 可以對多個條件進行匹配，默認多個條件是and的關系。
官方實例如下:
matchers:# Match the body word- type: word# Some words we want to matchwords:- "[core]"- "[config]"# Both words must be found in the response bodycondition: and# We want to match request body (default)part: body
詳情請參考：
https://nuclei.projectdiscovery.io/templating-guide/operators/matchers/。
Extractors
Extractors 也是對結果進行校驗，與matchers相比，它可以把滿足規(guī)則的內容顯示出來，同樣他也有不同類型的Extractors，如下所示：
1. regex - Extract data from response based on a Regular Expression。
2. kval - Extract key: value/key=value formatted data from Response Header/Cookie。
3. json - Extract data from JSON based response in JQ like syntax。
4. xpath - Extract xpath based data from HTML Response。
例如：
extractors:- type: xpath # type of the extractorattribute: href # attribute value to extract (optional)xpath:- "/html/body/div/p[2]/a" # xpath value for extraction
5. dsl - Extract data from the response based on a DSL expressions。
詳情請參考：
https://nuclei.projectdiscovery.io/templating-guide/operators/extractors/。
由于使用nuclei時間尚淺，關于Extractors和Matchers，個人感覺使用差別不是很大！
二者都是對結果的校驗，與matchers相比，Extractors它可以把滿足規(guī)則的內容顯示出來！如果大家需要編寫復雜的響應校驗，那么就需要花時間多研究dsl了。
如何從nuclei中受益
當使用了nuclei一段時間后，個人覺得其實使用nuclei最有價值的就是里面各種template，我們可以查看各個template的腳本來學習攻擊方法，而且還可以根據(jù)里面的reference 來查看漏洞的詳情，這個特別有助于安全知識的相關積累！至于攻擊請求的發(fā)送，這個其實就容易很多了，我們是否使用nuclei其實都無所謂的，舉個簡單的例子，關于CVE-2020-9484的 yaml腳本定義如下：
id: CVE-2020-9484info:name: Apache Tomcat Remote Command Executionauthor: dwisiswant0severity: highdescription: |When using Apache Tomcat versions 10.0.0-M1 to 10.0.0-M4, 9.0.0.M1 to 9.0.34, 8.5.0 to 8.5.54 and 7.0.0 to 7.0.103 ifa) an attacker is able to control the contents and name of a file on the server; andb) the server is configured to use the PersistenceManager with a FileStore; andc) the PersistenceManager is configured with sessionAttributeValueClassNameFilter="null" (the default unless a SecurityManager is used) or a sufficiently lax filter to allow the attacker provided object to be deserialized; andd) the attacker knows the relative file path from the storage location used by FileStore to the file the attacker has control over; then, using a specifically crafted request, the attacker will be able to trigger remote code execution via deserialization of the file under their control.Note that all of conditions a) to d) must be true for the attack to succeed.reference:- http://packetstormsecurity.com/files/157924/Apache-Tomcat-CVE-2020-9484-Proof-Of-Concept.html- https://nvd.nist.gov/vuln/detail/CVE-2020-9484- https://lists.apache.org/thread.html/r77eae567ed829da9012cadb29af17f2df8fa23bf66faf88229857bb1%40%3Cannounce.tomcat.apache.org%3E- https://lists.apache.org/thread.html/rf70f53af27e04869bdac18b1fc14a3ee529e59eb12292c8791a77926@%3Cusers.tomcat.apache.org%3Eclassification:cvss-metrics: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:Hcvss-score: 7cve-id: CVE-2020-9484cwe-id: CWE-502tags: cve,cve2020,apache,tomcat,rcerequests:- method: GETheaders:Cookie: "JSESSIONID=../../../../../usr/local/tomcat/groovy"path:- "{{BaseURL}}/index.jsp"matchers-condition: andmatchers:- type: statusstatus:- 500- type: wordpart: bodywords:- "Exception"- "ObjectInputStream"- "PersistentManagerBase"condition: and
這個腳本中，最容易的可能就是requests:部分攻擊腳本代碼，我們用jmeter 或者自己寫代碼的方式完全可以輕松模擬！而description:部分以及reference:部分才是我們需要重點研究的對象！也是我們深入理解poc攻擊的最佳實例！
