Se ha identificado una vulnerabilidad en el administrador de paquetes de APT (CVE-2019-3462), que permite a un atacante iniciar una falsificación del paquete instalado si el atacante tiene el control del espejo del repositorio o puede interrumpir el tráfico de tránsito entre el usuario y el repositorio (ataque MITM).
El problema fue identificado por el investigador de seguridad Max Justicz, conocido por detectar vulnerabilidades en el gestor de paquetes APK (Alpine) y en los repositorios Packagist, NPM y RubyGems.
El problema se debe a una verificación incorrecta de los campos en el código de procesamiento de redireccionamiento HTTP.
¿En que consiste el problema?
Esta vulnerabilidad permite a un atacante sustituir su propio contenido en los datos transmitidos dentro de la sesión HTTP (Debian y Ubuntu usan HTTP y no HTTPS para acceder al repositorio, asumiendo que la firma digital es suficiente con la coincidencia de metadatos y el tamaño de paquete).
La vulnerabilidad identificada le permite al atacante poder reemplazar el paquete transmitido, después de lo cual APT lo percibirá como recibido del espejo oficial e iniciará el proceso de instalación.
A través de la inclusión en el paquete malicioso de scripts lanzados durante la instalación, un atacante puede lograr la ejecución de su código en un sistema con privilegios de root.
Para descargar datos del repositorio, APT inicia un proceso secundario con la implementación de un transporte específico y organiza la interacción con este proceso mediante un protocolo de texto simple con la división de comandos por una línea vacía.
¿Como detecto el problema?
La esencia del problema es que el manejador de HTTP transport, al recibir una respuesta del servidor HTTP con el encabezado «Location:», solicita confirmación de la redirección del proceso principal.
Transfiriendo completamente el contenido de este encabezado. Debido a la falta de limpieza de los caracteres especiales transmitidos, un atacante puede especificar un salto de línea en el campo «Location:»
Dado que este valor se decodificará y transmitirá a través del canal de comunicación con el proceso principal, el atacante puede simular una respuesta diferente del manejador de HTTP transport y sustituir el bloque simulado 201 URI.
Por ejemplo, si, al solicitar un paquete, el atacante sustituirá la respuesta, esta sustitución dará lugar a la transferencia del siguiente bloque de datos al proceso principal.
El cálculo de hashes para los archivos descargados es manejado y el proceso principal simplemente verifica estos datos con hashes de la base de datos de paquetes firmados.
Entre los metadatos, un atacante puede especificar cualquier valor de hashes de prueba vinculado en la base de datos a paquetes firmados reales, pero en realidad no corresponde a los hashes del archivo transferido.
El proceso principal aceptará el código de respuesta sustituido por el ataque, buscará el hash en la base de datos y considerará que el paquete para el que hay una firma digital correcta está cargado, aunque en realidad el valor del campo con el hash se sustituye en el canal de comunicación con el proceso principal mediante el ataque y el archivo especificado en los metadatos sustituidos.
La descarga de un paquete malicioso se realiza adjuntando el paquete al archivo Release.gpg, durante su transferencia.
Este archivo tiene una ubicación predecible en el sistema de archivos y adjuntar un paquete a su inicio no afecta la extracción de la firma digital del repositorio.
Al obtener datos, apt desactiva los procesos de trabajo que se especializan en los distintos protocolos que se utilizarán para la transferencia de datos.
El proceso principal luego se comunica con estos trabajadores a través de stdin / stdout para decirles qué descargar y dónde colocarlo en el sistema de archivos mediante un protocolo que se parece un poco a HTTP.
El proceso principal luego enviará su configuración y solicitará un recurso y el proceso de trabajo responderá.
Cuando el servidor HTTP responde con una redirección, el proceso de trabajo devuelve a en 103 Redirectlugar de a 201 URI Done, y el proceso principal utiliza esta respuesta para averiguar qué recurso debe solicitar a continuación.