CVE-2022-32157 – Splunk Enterprise deployment servers allow unauthenticated forwarder bundle downloads
https://notcve.org/view.php?id=CVE-2022-32157
Splunk Enterprise deployment servers in versions before 9.0 allow unauthenticated downloading of forwarder bundles. Remediation requires you to update the deployment server to version 9.0 and Configure authentication for deployment servers and clients (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/ConfigDSDCAuthEnhancements#Configure_authentication_for_deployment_servers_and_clients). Once enabled, deployment servers can manage only Universal Forwarder versions 9.0 and higher. Though the vulnerability does not directly affect Universal Forwarders, remediation requires updating all Universal Forwarders that the deployment server manages to version 9.0 or higher prior to enabling the remediation. Los servidores de implementación de Splunk Enterprise en versiones anteriores a 9.0, permiten una descarga no autenticada de paquetes de reenvío. • https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/ConfigDSDCAuthEnhancements#Configure_authentication_for_deployment_servers_and_clients https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates https://research.splunk.com/application/splunk_process_injection_forwarder_bundle_downloads https://www.splunk.com/en_us/product-security/announcements/svd-2022-0607.html • CWE-306: Missing Authentication for Critical Function •
CVE-2022-32155 – Universal Forwarder management services allows remote login by default
https://notcve.org/view.php?id=CVE-2022-32155
In universal forwarder versions before 9.0, management services are available remotely by default. When not required, it introduces a potential exposure, but it is not a vulnerability. If exposed, we recommend each customer assess the potential severity specific to your environment. In 9.0, the universal forwarder now binds the management port to localhost preventing remote logins by default. If management services are not required in versions before 9.0, set disableDefaultPort = true in server.conf OR allowRemoteLogin = never in server.conf OR mgmtHostPort = localhost in web.conf. • https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation#Configure_universal_forwarder_management_security https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates https://www.splunk.com/en_us/product-security/announcements/svd-2022-0605.html • CWE-732: Incorrect Permission Assignment for Critical Resource •
CVE-2022-32154 – Risky commands warnings in Splunk Enterprise Dashboards
https://notcve.org/view.php?id=CVE-2022-32154
Dashboards in Splunk Enterprise versions before 9.0 might let an attacker inject risky search commands into a form token when the token is used in a query in a cross-origin request. The result bypasses SPL safeguards for risky commands. See New capabilities can limit access to some custom and potentially risky commands (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/SPLsafeguards#New_capabilities_can_limit_access_to_some_custom_and_potentially_risky_commands) for more information. Note that the attack is browser-based and an attacker cannot exploit it at will. Los cuadros de mando en Splunk Enterprise versiones anteriores a 9.0, podrían permitir a un atacante inyectar comandos de búsqueda arriesgados en un token de formulario cuando el token es usado en una consulta en una petición de origen cruzado. • https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/SPLsafeguards#New_capabilities_can_limit_access_to_some_custom_and_potentially_risky_commands https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates https://research.splunk.com/application/splunk_command_and_scripting_interpreter_delete_usage https://research.splunk.com/application/splunk_command_and_scripting_interpreter_risky_commands https://research.splunk.com/application/splunk_command_and_scripting_interpreter_risky_spl_mltk https://www.splunk.c • CWE-20: Improper Input Validation CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection') •
CVE-2022-32153 – Splunk Enterprise lacked TLS host name validation
https://notcve.org/view.php?id=CVE-2022-32153
Splunk Enterprise peers in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203 did not validate the TLS certificates during Splunk-to-Splunk communications by default. Splunk peer communications configured properly with valid certificates were not vulnerable. However, an attacker with administrator credentials could add a peer without a valid certificate and connections from misconfigured nodes without valid certificates did not fail by default. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation. Los peers de Splunk Enterprise en las versiones de Splunk Enterprise anteriores a la 9.0 y las versiones de Splunk Cloud Platform anteriores a la 8.2.2203 no comprueban los certificados TLS durante las comunicaciones de Splunk a Splunk por defecto. • https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates https://research.splunk.com/application/splunk_digital_certificates_infrastructure_version https://research.splunk.com/application/splunk_digital_certificates_lack_of_encryption https://research.splunk.com/application/splunk_protocol_impersonation_weak_encryption_selfsigned https://research.splunk.com/network/splunk_identified_ssl_tls_certificates https://www.splunk.com/en_ • CWE-295: Improper Certificate Validation CWE-297: Improper Validation of Certificate with Host Mismatch •
CVE-2022-32152 – Splunk Enterprise lacked TLS cert validation for Splunk-to-Splunk communication by default
https://notcve.org/view.php?id=CVE-2022-32152
Splunk Enterprise peers in Splunk Enterprise versions before 9.0 and Splunk Cloud Platform versions before 8.2.2203 did not validate the TLS certificates during Splunk-to-Splunk communications by default. Splunk peer communications configured properly with valid certificates were not vulnerable. However, an attacker with administrator credentials could add a peer without a valid certificate and connections from misconfigured nodes without valid certificates did not fail by default. For Splunk Enterprise, update to Splunk Enterprise version 9.0 and Configure TLS host name validation for Splunk-to-Splunk communications (https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation) to enable the remediation. Los peers de Splunk Enterprise en Splunk Enterprise versiones anteriores a 9.0 y Splunk Cloud Platform versiones anteriores a 8.2.2203 no comprueban los certificados TLS durante las comunicaciones de Splunk a Splunk por defecto. • https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Updates https://research.splunk.com/application/splunk_digital_certificates_infrastructure_version https://research.splunk.com/application/splunk_digital_certificates_lack_of_encryption https://research.splunk.com/application/splunk_protocol_impersonation_weak_encryption_selfsigned https://research.splunk.com/network/splunk_identified_ssl_tls_certificates https://www.splunk.com/en_ • CWE-295: Improper Certificate Validation •