
Instituto de Tecnología de la Información de Sri Lanka
Asignación 1
M. P. D. M. Dias
IT19165530
MLB_WD_Y2S1_13.1
Vulnerabilidad RCE del demonio del Protocolo
Punto a Punto (CVE-2020-8597)
Programación de Sistemas y Redes – IE2012
Contenido
Introducción
El Protocolo Punto a Punto (PPP) es un protocolo full-duplex que permite encapsular y distribuir datos simples a través de la capa 2 o de la infraestructura de enlace de datos, abarcando desde la conectividad por acceso telefónico (dial-up) hasta la banda ancha DSL y las redes privadas virtuales (VPN) que incorporan cifrado SSL. Como estos protocolos no permiten comunicaciones punto a punto, PPP también se utiliza para hacer cumplir IP y TCP sobre dos nodos directamente conectados. Pppd es un demonio utilizado en sistemas operativos tipo Unix para gestionar el establecimiento de sesiones PPP y la terminación de sesiones entre dos nodos.
PPP es el protocolo utilizado para crear conexiones a Internet a través de módems de acceso telefónico, conexiones DSL y varias otras formas de conexiones punto a punto mediante redes privadas virtuales (VPN), como el Protocolo de túnel punto a punto (PPTP). El programa pppd también puede autenticar a un peer (par) que se conecta a la red y/o proporcionar al peer detalles de autenticación utilizando diversos protocolos de autenticación como EAP.
Debido a una falla en el manejo del paquete del Protocolo de Autenticación Extensible (EAP) por parte del demonio del Protocolo Punto a Punto (pppd), un atacante remoto no autenticado puede provocar un desbordamiento de búfer en la pila (stack buffer overflow) que puede permitir la ejecución arbitraria de código en el sistema objetivo. Esta debilidad se desencadena por un error en la validación del tamaño de la entrada antes de copiar los datos proporcionados a la memoria. Dado que la validación del tamaño de los datos es incorrecta, se pueden copiar datos aleatorios en la memoria, lo que puede provocar una fuga de archivos que contribuya a la ejecución no intencionada de código.
La debilidad reside en la lógica del código de análisis de eap, específicamente en las funciones eap request) (y eap response) (en eap.c, que son llamadas por un manejador de entrada de red. Estas funciones, que utilizan el primer byte como tipo, toman un puntero y una longitud como entrada. Si el formato es EAPT MD5CHAP(4), entonces observa un área incrustada de 1 byte de longitud. La lógica de este código pretende asegurar que la duración incrustada sea menor que la longitud total del paquete. Tras esta verificación, intenta copiar los datos proporcionados (hostname), que se encuentran en un búfer de pila local después del campo de longitud incrustado. Esta comprobación de límites es incorrecta y permite que la copia de memoria se realice con una longitud de datos arbitraria.
Un error lógico adicional hace que la función eap input) (no compruebe si EAP se ha resuelto durante el proceso del Protocolo de Control de Línea (LCP). Esto permite que un atacante no autenticado envíe un paquete EAP incluso si ppp se negó a negociar la autenticación debido a la falta de soporte para EAP o por un incumplimiento de una frase de contraseña precompartida acordada en la etapa LCP. En eap input, el código inseguro de pppd debe procesar el paquete EAP y provocar el desbordamiento del búfer de la pila. Estos datos no verificados y de tamaño desconocido pueden utilizarse para comprometer la memoria del dispositivo objetivo. Además, pppd se ejecuta con privilegios elevados (sistema o root) y opera en conjunto con los controladores del kernel.
El programa pppd también se utiliza con el proyecto LWIP (lightweight IP) para proporcionar capacidad pppd a computadoras pequeñas. La instalación predeterminada de lwIP y sus instalaciones no son susceptibles a esta sobrecarga de búfer. Sin embargo, si se utiliza el código fuente de lwIP y se modifica explícitamente para permitir EAP en tiempo de compilación, el programa puede ser susceptible al desbordamiento de búfer.
CVE-2020-8597 es un error de desbordamiento de búfer en pppd debido a un defecto conceptual en el procesador de paquetes del Protocolo de Autenticación Extensible (EAP). Un atacante remoto no autorizado que envíe un paquete EAP especialmente diseñado a un cliente o servidor PPP vulnerable puede provocar una condición de denegación de servicio o una ejecución arbitraria de código. Dado que pppd opera en conjunto con los controladores del kernel y también tiene privilegios elevados, como dispositivo o incluso core, cualquier ejecución de código también puede realizarse con los mismos privilegios.
Referencia sobre quién encontró la vulnerabilidad
Descubierto por el investigador de seguridad de IOActive Ilja Van Sprundel, el problema crucial es una falla de desbordamiento de búfer en la pila que ocurre debido a un error lógico en el analizador del módulo del Protocolo de Autenticación Extensible (EAP) de las aplicaciones pppd, una mejora que ofrece soporte para métodos de autenticación adicionales en conexiones PPP.
La debilidad, registrada como CVE-2020-8597 con una puntuación CVSS de 9.8, puede ser aprovechada por atacantes no autorizados para ejecutar código arbitrario de forma remota en los dispositivos afectados y obtener el control total de ellos.
Cómo se encontró
Esta debilidad se atribuye a un error en la validación del tamaño de la entrada antes de transferir los datos a la memoria. Debido a que la validación del tamaño de los datos es incorrecta, se pueden copiar datos aleatorios a la memoria y provocar una fragmentación de la base de datos, lo que probablemente contribuya a la ejecución de código no autorizado.
La vulnerabilidad se encuentra en la lógica del código de análisis de eap, específicamente en las funciones eap request) (y eap response) (en eap.c, que son llamadas por el manejador de entrada de red.
Es incorrecto concluir que pppd no es inseguro si EAP no está permitido o si EAP no ha sido iniciado por un peer remoto mediante una contraseña o frase de contraseña. Esto se debe a que un intruso autenticado siempre podría enviar un paquete EAP no solicitado para inducir un desbordamiento de búfer.
La vulnerabilidad ha sido identificada en el demonio del Protocolo Punto a Punto (PPP), o pppd. PPP es un protocolo de la capa 2 utilizado para establecer conexiones a través de módems de acceso telefónico, conexiones DSL y muchas otras redes físicas, incluidas las redes móviles. PPP se ha incluido y ampliado para incorporar protocolos adicionales, como el Protocolo de túnel punto a punto (PPTP), que se utiliza en redes privadas virtuales (VPN) para proporcionar conexiones cifradas.
A lo largo de esta situación, el equipo de colaboración de SEI CERT se asoció con el analista de seguridad Ilja Van Sprundel (IOActive), quien encontró esta falla, y con el desarrollador de software Paul Mackerras (OZlabs), quien gestiona el código fuente, para examinar fácilmente el problema y encontrar una solución. El problema implicaba un desbordamiento de búfer en el código fuente de pppd debido a un desbordamiento de búfer básico en la expresión booleana y en la implementación de las declaraciones condicionales resultantes. La sentencia siguiente puede ser engañada para permitir una entrada de duración desconocida y copiarla a un búfer de la pila. Esto se conoce comúnmente como sobrecarga de trama o desbordamiento de búfer de la pila.
if (vallen >= len + sizeof(rhostname)) { // Copy to buffer rhostname
La solución para la vulnerabilidad fue simplemente cambiar la declaración anterior por la lógica booleana siguiente.
if (len-vallen >= sizeof(rhostname)) { // Copy to buffer rhostname
Paul emitió CVE-2020-8597 para esta falla y continuó reparándola en el código fuente que gestiona. La actualización del sistema necesaria para corregir el error es menor y requiere solo unas pocas líneas de código. No obstante, esta tecnología insegura reside en miles de bibliotecas de proyectos de software. Ha sido adoptada por más de 100 empresas que ofrecen dispositivos de acceso a la red, desde enrutadores domésticos hasta hardware de red empresarial. Como esta debilidad afecta a todos los clientes y servidores PPP, también afecta a los proveedores de servicios de Internet (ISP).
Cuándo se encontró
El 4 de marzo de 2020, los investigadores del Centro de Coordinación CERT (CERT / CC) publicaron la nota de vulnerabilidad n.º 782301 para una vulnerabilidad crítica en el demonio del Protocolo Punto a Punto (pppd) versiones 2.4.2 a 2.4.8, con la divulgación acreditada a Ilja van Sprundel de IOActive.
Qué daño puede causar
Al enviar un paquete EAP no solicitado a un cliente o servidor ppp vulnerable, un intruso remoto no autorizado puede provocar la corrupción de memoria en el mecanismo de pppd, lo que puede permitir la ejecución arbitraria de código.
Según el investigador, el demonio del Protocolo Punto a Punto versiones 2.4.2 a 2.4.8 —todas las versiones publicadas en los últimos 17 años— es susceptible a este nuevo error de ejecución remota de código. Cualquiera de las distribuciones de Linux de uso común y exitosas que se mencionan a continuación ya ha sido reportada como afectada, y es muy probable que varios otros proyectos también estén afectados.
Debian Ubuntu SUSE Linux Fedora NetBSD Red Hat Enterprise Linux
Además, es probable que la cantidad de otras aplicaciones y dispositivos susceptibles (algunos de los cuales se mencionan a continuación) que incluyen aplicaciones pppd también sea vasta, lo que proporciona una amplia superficie de ataque para los hackers.
Cisco CallManager Productos TP-LINK Sistema operativo embebido OpenWRT Productos Synology
Debido a una falla en el procesamiento de paquetes del Protocolo de Autenticación Extensible (EAP) en el demonio del Protocolo Punto a Punto (pppd), un atacante remoto no autenticado puede provocar un desbordamiento de búfer en la pila, lo que puede permitir la ejecución arbitraria de código en el sistema objetivo. Esta vulnerabilidad se debe a un error en la validación del tamaño de la entrada antes de copiar los datos proporcionados en la memoria. Como la validación del tamaño de los datos es incorrecta, se pueden copiar datos arbitrarios en la memoria y causar corrupción de memoria, lo que posiblemente conduzca a la ejecución de código no deseado.
Cuáles son las técnicas de explotación
El problema crítico es una vulnerabilidad de desbordamiento de búfer en la pila que existe debido a un error lógico en el analizador de paquetes del Protocolo de Autenticación Extensible (EAP) del software pppd, una extensión que proporciona soporte para métodos de autenticación adicionales en conexiones PPP.
Para ello, todo lo que un atacante necesita hacer es enviar un paquete EAP malformado no solicitado a un cliente ppp vulnerable o a un servidor a través de un enlace serie directo, ISDN, Ethernet, SSH, socket CAT, PPTP, GPRS o redes ATM. Además, dado que pppd a menudo se ejecuta con privilegios elevados y funciona en conjunto con los controladores del kernel, la falla podría permitir a los atacantes ejecutar potencialmente código malicioso con privilegios de sistema o de nivel root. Qué método de explotación elegí
Se utilizó el método de ejecución remota de código para explotar el cliente vulnerable. La ejecución remota de código (RCE) se relaciona con la capacidad de un intruso cibernético de entrar y realizar modificaciones en un dispositivo controlado por otra persona, sin permiso y sin que esta sepa dónde se encuentra la máquina. RCE permite a un atacante tomar el control de una computadora o servidor ejecutando software malicioso (malware) arbitrario.
Utilicé dos máquinas virtuales para probar en la misma computadora. Una como servidor y otra como cliente. Para conectar las máquinas virtuales instalé ssh. Usando sus direcciones IP, conecté la máquina virtual Fedora 29 como lado del servidor y la máquina virtual Kali Linux como lado del cliente vulnerable. Siguiendo las instrucciones, configuré un pppoe-server. Después abrí el modo de depuración, configuré el archivo de registro y añadí lo siguiente al archivo de registro ‘/etc/ppp/pppoe-server-options’. Luego configuré un pppoe-client ejecutando ‘sudo pppoeconf’. Finalmente, usando el código python se puede explotar el cliente vulnerable. Además, al enviar un paquete EAP no solicitado a un cliente ppp vulnerable, un atacante remoto podría causar corrupción de memoria en el proceso pppd, lo que puede permitir la ejecución arbitraria de código.
Capturas de pantalla de la explotación
Ping con el cliente vulnerable
Instalar SSH en el servidor
Obtener acceso root en el lado del cliente
Después de obtener el acceso root del cliente
Habilitar SSH en el lado del cliente
Bloqueo (Crash)
Resultado
Conclusión
GitHub Security Lab al rescate
Mientras Vijay Sarvepalli investigaba la última iniciativa de protección de GitHub, quiso identificar oportunidades para aprovechar las soluciones de la API de GitHub y CodeQL para abordar el problema, y utilizó código para proponer la solución a los usuarios de los repositorios de software. Se puso en contacto con nuestro líder de protección gubernamental, Allan Friedman (Director de Iniciativas de Ciberseguridad en la Administración Nacional de Telecomunicaciones e Información (NTIA) del Departamento de Comercio de los Estados Unidos), quien ha reunido a una serie de organizaciones, incluida GitHub, para crear una Lista de Materiales de Software (SBOM). Allan presentó a Vijay Sarvepalli a las personas de GitHub dedicadas a la confidencialidad, y ellos me pusieron en contacto con el jefe del GitHub Security Lab, Nico Waisman.
Nico y su equipo internacional en GitHub Security Lab encontraron rápidamente una forma de adaptar su mecanismo de parcheo de seguridad a este problema. Activaron una tecnología automática de "robot" que se comunicó con los propietarios de todos los repositorios afectados por este error. Los propietarios de los repositorios solo tuvieron que tomar algunas medidas rápidas para corregir y asegurar su versión copiada o bifurcada (fork) del programa pppd, solucionando el error. Esta iniciativa comunitaria nos llevó a la etapa en la que la tecnología se estaba corrigiendo. Esto ofreció un enfoque modular y oportuno para implementar mejoras en el código fuente con el fin de mejorar la protección. A los cuatro días de las actualizaciones automáticas del GitHub Security Lab, 1.896 propietarios de repositorios proporcionaron detalles del error y se les otorgó la opción de corregirlo con unos pocos clics. Al menos 42 de estos propietarios de repositorios aprobaron un parche automático; 13 más confirmaron que el problema ya había sido corregido. Sin automatización, se necesitarían varios días para contactar a los propietarios de los repositorios afectados y corregir sus aplicaciones.
El desafío del DoD y el papel del CERT en el futuro del software
Como centro de investigación y desarrollo financiado con fondos federales (FFRDC), el Instituto de Ingeniería de Software (SEI) de la Universidad Carnegie Mellon y su División CERT se enfrentan constantemente a los desafíos que el Departamento de Defensa de los EE. UU. (DoD) enfrenta en el ciberespacio. El CIO del DoD, Terry Halvorsen, un reconocido evangelista de la ciberseguridad, dijo que "las acciones y contramedidas defensivas cibernéticas ocurrirán en milisegundos" en su discurso en la conferencia AFCEA. Estas acciones defensivas cibernéticas deseadas no pueden realizarse manualmente ni mediante procesos de comunicación engorrosos. Deben entregarse a través de software y automatizarse tanto como sea posible para limitar los problemas con los modelos de parcheo actuales con intervención humana en el ciclo.
A lo largo de las actividades potenciales de gestión de amenazas, esperamos identificar situaciones en las que podamos aprovechar los incentivos (como esta asociación con GitHub Security Lab) para acelerar el parcheo del código fuente contra vulnerabilidades de seguridad de la información. Aunque entendemos que esto no solucionará ningún problema de protección de la información y no sustituye las buenas prácticas de codificación, sí nos damos cuenta de que los errores tienden a encontrarse en la información después de que ha sido publicada. Cuando la información es omnipresente en nuestra vida cotidiana, solo puede protegerse mediante la identificación rápida de vulnerabilidades y, si es posible, automatizando tanto la identificación como la respuesta.
Referencias
• https://www.kb.cert.org/vuls/id/782301/ • https://thehackernews.com/2020/03/ppp-daemon-vulnerability.html • https://www.tenable.com/blog/cve-2020-8597-buffer-overflow-vulnerability-in-point-to-point-protocol-daemon-pppd • https://insights.sei.cmu.edu/cert/2020/03/security-automation-should-begin-at-the-source.html • https://packetstormsecurity.com/files/156802/pppd-2.4.8-Buffer-Overflow.html • https://www.drizgroup.com/driz_group_blog/what-is-remote-code-execution-attack-how-to-prevent-this-type-of-cyberattack • https://github.com/WinMin/CVE-2020-8597 • http://www.howtodoityourself.org/pppoe-server-how-to-do-it-yourself.html