Jenkins does not implement Authentication challenges.
By default, Jenkins responds with a HTTP 403 FORBIDDEN response, and does not include the `WWW-Authenticate` header.
This causes problems with the underlying http client, as this one expects the challenge to come forward and resend
the request with the auth header.
By changing the code to look for the HTTP 403 response, and setting the default URL to the correct login validation endpoint
Pro will have an easier time to investigate whether Jenkins can be bruteforced or not.
The original code checks for a 401 response only.
Overwriting the behavior for Jenkins allows us to handle this use-case properly and report the correct behavior.
Adding multiple HttpServer services in a module is sometimes complex
since they share the same methods. This usually this causes issues where
on_request_uri needs to be overridden to handle requests coming from
each service. This updates the cmdstager and the Java HTTP ClassLoader
mixins, since these are commonly used in the same module. This also
updates the manageengine_servicedesk_plus_saml_rce_cve_2022_47966 module
to make use of these new changes
This exploit module leverages an arbitrary file write vulnerability
(CVE-2024-25641) in Cacti versions prior to 1.2.27 to achieve RCE. It
abuses the Import Packages feature to upload a specially crafted package
that embeds a PHP file.
- Update the CSRF token logic in the library
- Update cacti_package_import_rce and cacti_pollers_sqli_rce modules
- Update the FETCH_DELETE logic in cacti_package_import_rce to only
regenerate the payload when necessary
A webpage exists that can be reached without authentication that
contains a hash that can be used to determine the approximate version of
gitlab running on the endpoint. This PR adds enhances our current GitLab
fingerprinting capabilities to include the aforementioned technique.
Since I was the one suggesting it in #18716, I kinda volunteered to implement
it. This improvement is based on [Censys's blogpost](https://censys.com/cve-2021-22205-it-was-a-gitlab-smash/)
on the topic, making use of the `/assets/application-….css` files that have
a unique name per gitlab versions.
The fingerprints were acquired with this bash script:
```bash
assetdir="/opt/gitlab/embedded/service/gitlab-rails/public/assets"
tags=$(curl "https://hub.docker.com/v2/repositories/gitlab/gitlab-ce/tags?page_size=100" | jq -r '.results[].name')
for tag in $tags; do
filename=$(docker run --quiet --rm -it --entrypoint "" gitlab/gitlab-ce:$tag ls $assetdir|egrep '^application-.*\.css' | grep -v \.gz | cut -d' ' -f1)
echo $tag,$filename
done
```
Co-authored-by: cgranleese-r7 <69522014+cgranleese-r7@users.noreply.github.com>