CVE-2023-31413

Este es un problema de secretos en los logs, no una intrusión. La entrada httpjson de Filebeat, cuando el registro de depuración está activado, escribe la cabecera saliente Authorization o Proxy-Authorization en sus propios logs, de modo que la misma credencial que Filebeat usa para llegar a una API acaba en texto plano allí donde vayan a parar esos logs. Nada se ejecuta y nada es accesible remotamente; el fallo es que un token que pretendías mantener en secreto se filtra a un destino de menor confianza.

La puntuación es un 3.3 genuino y las precondiciones se lo ganan: un atacante necesita acceso local a los logs, el registro de depuración tiene que estar habilitado y la entrada httpjson tiene que estar en uso con solicitudes autenticadas. Esa es una pila específica de condiciones, y el registro de depuración suele ser un estado temporal de resolución de problemas, no uno permanente. El daño realista es una credencial capturada que amplía silenciosamente un punto de apoyo que alguien ya tiene.

Mantenemos esto en un nivel bajo y lo tratamos como una cuestión de higiene más que como una emergencia de parcheo. El ángulo que importa es adónde se envían los logs de Filebeat —a menudo a la misma plataforma de registro centralizada que muchos equipos pueden leer—, así que un token de API filtrado puede viajar mucho más lejos que el host que lo registró. Nuestro seguimiento es acotado: encontrar despliegues de Filebeat hasta 7.17.9 y 8.6.2 que usen httpjson con depuración habilitada, y rotar cualquier credencial que haya podido quedar registrada.