Grave falla en equipos Avaya y Aruba podría permitir control total
Grave falla en equipos Avaya y Aruba podría permitir control total
Se detectaron Vulnerabilidades en equipo Avaya y Aruba, enseguida describimos estas vulnerabilidades y como le afectan.
Si usted tiene estos equipos y quisiera un escaneo de vulnerabilidades totalmente gratis, póngase en contacto a través de info@imagenti.mx
Los investigadores de la firma de inteligencia de dispositivos Armis encontraron cinco vulnerabilidades (dos fallas en los switches de Aruba y tres fallas en los switches de Avaya) que podrían usarse para comprometer las redes que permiten el acceso de personas externas. Las fallas pueden ser explotadas por un usuario de un portal cautivo o un servidor de autenticación, explicaron los investigadores.
De manera preocupante, al observar los detalles de los errores, los tres errores de Avaya son de cero clic, y no requieren autenticación ni interacción del usuario para explotarlos. Uno de ellos afecta a un dispositivo al final de su vida útil y no recibirá un parche.
Tres de las vulnerabilidades se originan con el manejo inadecuado de errores producidos por una biblioteca de terceros para implementar TLS producido por la firma de ciberseguridad Mocana de Internet de las cosas (IoT).
Los detalles de la vulnerabilidad son los siguientes:
Aruba:
- CVE-2022-23677 (puntuación CVSS de 9,0): uso indebido de NanoSSL en múltiples interfaces (RCE)*
- CVE-2022-23676 (puntuación CVSS de 9,1): vulnerabilidades de corrupción de la memoria del cliente RADIUS.
Avaya:
- CVE-2022-29860 (CVSS 9.8): desbordamiento del montón de reensamblaje de TLS*-
- CVE-2022-29861 (CVSS 9.8): desbordamiento de pila de análisis de encabezado HTTP
- Solicitud HTTP POST que maneja el desbordamiento del montón (sin CVE porque está en una versión anterior)
Estos son causados por la interacción entre Mocana NanoSSL y los productos.
Las vulnerabilidades subrayan los riesgos de la cadena de suministro de software y los peligros potenciales que conlleva el uso de componentes de terceros. Las fallas de seguridad en las bibliotecas de las que depende el software, o en este caso, en la forma en que interactúan el software y la biblioteca, pueden crear o propagar vulnerabilidades. En promedio, el 78% de las bases de código de software consisten en bibliotecas y componentes de código abierto.
En marzo, los investigadores descubrieron un conjunto similar de fallas que causaron vulnerabilidades de seguridad en más de 150 productos IoT, también causadas por otro componente de terceros.
“Si bien el uso de bibliotecas externas tiene muchas ventajas, también genera una incertidumbre inherente”, afirmó Armis en su aviso de seguridad publicado el 3 de mayo. los problemas que se originan en la biblioteca externa están integrados en ella y automáticamente se convierten en problemas de seguridad sobre los que el proveedor tiene menos control”.
TLStorm, Parte 2
En el corazón de las vulnerabilidades relacionadas con Mocana se encuentran estados de error inestables en la biblioteca Mocana NanoSSL que maneja la seguridad de la capa de transporte (TLS) para la interfaz de administración de los productos.
Los problemas se producen porque el atacante puede crear paquetes de red que provocan errores en la biblioteca Mocana NanoSSL, y los desarrolladores que producen software para los proveedores no gestionan los errores correctamente.
El resultado son dos clases de vulnerabilidades: corrupción de memoria y confusión de estado.
Si inicias un handshake TLS y el otro lado envía un mensaje incorrecto, si no compruebas el código de error correctamente, ese escenario puede ser aprovechado para obtener la ejecución remota de código en algunos casos”, dice Hadad de Armis. “El manual dice claramente que el desarrollador debe comprobar el error, pero como sabemos, no es habitual que los desarrolladores lean todo el manual”.
Armis ha trabajado con Mocana, Aruba y Avaya para remediar los problemas cuando sea necesario. Los clientes de las empresas han sido notificados y cada una de ellas ha lanzado un software actualizado. En el caso de Mocana, aunque las vulnerabilidades no son técnicamente causadas por el software, la compañía ha creado una actualización de todos modos para evitar futuras implementaciones defectuosas.
“No se trata de una vulnerabilidad de Mocana, pero, no obstante, han publicado un nuevo software que hace que no te encuentres en una situación de vulnerabilidad sólo por no haber comprobado el código de error”, afirma Hadad.
Las vulnerabilidades, denominadas TLStorm 2.0 por Armis, son similares a otras anunciadas en marzo que afectan a los sistemas de alimentación ininterrumpida (SAI) conectados de forma inteligente.
No es la primera implementación defectuosa
Anteriormente, los investigadores de Armis mostraron las mismas vulnerabilidades utilizadas contra varios modelos de SAI de APC, ahora propiedad de Schneider Electric. Los ataques, que tenían como objetivo los SAI que se conectaban a la nube de Schneider Electric para permitir la gestión, podían permitir a los atacantes comprometer remotamente los dispositivos sin ninguna interacción del usuario ni dejar ningún rastro del ataque.
Dado que se podía cargar un nuevo firmware en los dispositivos de forma remota, los atacantes podían cambiar la forma de onda y el voltaje de la corriente alterna suministrada a los dispositivos conectados e incluso hacer que el SAI se sobrecalentara.
“El hecho de que los dispositivos UPS regulen la energía de alto voltaje, combinado con su conectividad a Internet, los convierte en un objetivo ciberfísico de alto valor”, declaró Armis en su aviso de marzo sobre las vulnerabilidades, que denominó TLStorm. “Dado que el vector de ataque TLS puede originarse en Internet, estas vulnerabilidades pueden actuar como una puerta de entrada a la red corporativa interna. Los actores malos pueden utilizar la confusión del estado de TLS para identificarse como la nube de Schneider Electric y recopilar información sobre el SAI detrás del firewall corporativo.”
referencia: https://www.darkreading.com/vulnerabilities-threats/tls-flaws-leave-avaya-aruba-switches-open-to-complete-takeover
