Boletín semanal ciberseguridad 8-14 de eneroTelefónica Tech 14 enero, 2022 Boletín de seguridad de Microsoft Microsoft ha publicado su boletín de seguridad de enero donde ha corregido un total de 97 fallos entre los que se encontraban 6 vulnerabilidades 0-day y 9 errores clasificados como críticos. Atendiendo a los 0-day, no se habría detectado explotación activa de estos, pero cabe destacar que varios disponen de pruebas de concepto públicos, por lo que es probable su explotación se produzca a corto plazo. En referencia a los fallos de seguridad clasificados como críticos destaca la CVE-2022-21907 (CVSS 9.8), que afecta a las últimas versiones de Windows en sus versiones de escritorio y servidor. Se trata de una vulnerabilidad en la pila de protocolo HTTP, cuya explotación resultaría en ejecución remota de código y que ha sido etiquetado como “wormable”. El otro fallo que reseñar es otra ejecución remota de código en este caso en Microsoft Office (CVE-2022-21840 CVSS 8.8), parcheado para las versiones de Windows, pero aún no para dispositivos macOS. Como ocurría con los 0-days, según Microsoft tampoco se ha detectado explotación para estas dos vulnerabilidades. Más info: https://msrc.microsoft.com/update-guide/releaseNote/2022-Jan Nueva vulnerabilidad en JNDI en la consola de la base de datos H2 Investigadores de JFrog han descubierto una vulnerabilidad crítica de ejecución remota de código no autenticada en la consola de la base de datos H2, que comparte su origen con la vulnerabilidad Log4Shell (JNDI remote class loading) y que ha recibido el identificador CVE-2021-42392. H2 es una base de datos Java SQL de código abierto muy popular y ampliamente utilizada en distintos proyectos. A pesar de tratarse de una vulnerabilidad crítica y de compartir características con Log4Shell, los investigadores indican que su impacto es menor por varios motivos. En primer lugar, este fallo tiene un impacto directo ya que el servidor que procesa la solicitud inicial es el mismo que se ve afectado por el fallo, por lo que es más sencillo detectar los servidores vulnerables. En segundo lugar, la configuración predeterminada de H2 es segura, a diferencia de lo que ocurría con Log4Shell donde las configuraciones predeterminadas eran vulnerables. Y finalmente, muchos proveedores emplean la base de datos H2 pero no la consola, de forma que, aunque existen vectores para explotar el fallo más allá de la consola, estos otros vectores dependen del contexto y es menos posible que se expongan a ataques remotos. A pesar de que se atribuye un menor riesgo a este nuevo fallo que a Log4Shell, los investigadores advierten que para todos aquellos que ejecuten una consola H2 expuesta a la LAN, el fallo es crítico y deben actualizar a la versión 2.0.206 de forma urgente. Asimismo, desde la firma han compartido indicaciones a los administradores de red para que puedan comprobar si son vulnerables a este nuevo fallo. Todos los detalles: https://jfrog.com/blog/the-jndi-strikes-back-unauthenticated-rce-in-h2-database-console/ Cinco nuevos fallos de tipo URL parsing confusión Investigadores de Team82 y Snyk han publicado un artículo de investigación en el que han estudiado en profundidad cómo distintas librerías analizan las URLs, y cómo estas diferencias en la forma de analizarlas pueden ser aprovechadas por los atacantes; es decir, han analizado fallos de tipo URL parsing confusion. En total han analizado 16 librerías de análisis de URL (Uniform Resource Locator) distintas y se han detectado cinco clases de inconsistencia presentes en algunas de ellas, que podrían ser explotadas para provocar condiciones de denegación de servicio, exposición de información o incluso, bajo ciertas circunstancias, ejecución remota de código. Las cinco inconsistencias observadas son: confusión de esquemas (scheme confusion), confusión de barras (slashes confusion), confusión de barras invertidas (backslash confusion), confusión de datos codificados en URL (URL encoded data confusion) y combinación de esquemas (scheme mixup). Además de la identificación de estas inconsistencias, apuntan a la detección de ocho vulnerabilidades que afectan directamente a distintos frameworks o incluso lenguajes de programación y que ya han sido parcheadas excepto en algunas versiones fuera de soporte de Flask: Flask-security (Python, CVE-2021-23385), Flask-security-too (Python, CVE-2021-32618), Flask-User (Python, CVE-2021-23401), Flask-unchained (Python, CVE-2021-23393), Belledonne’s SIP Stack (C, CVE-2021-33056), Video.js (JavaScript, CVE-2021-23414), Nagios XI (PHP, CVE-2021-37352) y Clearance (Ruby, CVE-2021-23435). En su estudio, otorgan una alta relevancia a este tipo de errores en el análisis de las URLs utilizando Log4Shell como ejemplo para ello, puesto que el bypass a la corrección inicial de Apache del fallo se logró conseguir gracias a la presencia de dos analizadores distintos de URL dentro del proceso de búsqueda JNDI, cada uno de los cuales analizaba de una forma. Para saber más: https://claroty.com/2022/01/10/blog-research-exploiting-url-parsing-confusion/ MuddyWater: vinculación a Irán y aspectos técnicos La Cyber National Mission Force (CNMF) del comando de ciberseguridad de Estados Unidos, ha publicado una nota donde vincula a la APT conocida como MuddyWater con el Ministerio de Inteligencia y Seguridad de Irán (MOIS) y detalla algunos aspectos técnicos que se han podido asociar al grupo. MuddyWater fue identificado por primera vez en el año 2017, con objetivos localizados, principalmente, en las regiones de Oriente Medio, Europa y Norte América, y en los sectores de telecomunicaciones, gubernamentales e industria petrolera. En su publicación, se identifican algunas herramientas de código abierto utilizadas por este actor malicioso, entre las que se encuentran variantes de PowGoop, muestras de la puerta trasera Mori o archivos DLL de carga lateral para engañar a los programas legítimos con el fin de que ejecuten malware. Toda la info: https://www.cybercom.mil/Media/News/Article/2897570/iranian-intel-cyber-suite-of-malware-uses-open-source-tools/ Vulnerabilidades 0-day detectadas en AWS CloudFormation y AWS Glue Los investigadores de seguridad de Orca Security han detectado dos vulnerabilidades 0-day en diferentes servicios de Amazon Web Services (AWS). El primero de los fallos se encontraba en el servicio AWS CloudFormation y consistía en una vulnerabilidad XXE (XML External Entity), la cual permitía a los agentes amenaza divulgar archivos confidenciales ubicados en la máquina de servicio vulnerable, así como la divulgación de credenciales de servicios internos de la infraestructura de AWS. La segunda vulnerabilidad descubierta, afectaba al servicio AWS Glue, la cual procedía de una característica explotable que permitía la obtención de las credenciales necesarias para tener acceso a la API del servicio interno, pudiendo obtener permisos de administrador. El portavoz de AWS aseguró que no se han visto afectados los datos de ninguno de los clientes debido a las vulnerabilidades de ambos servicios. Cabe destacar que ambas vulnerabilidades fueron corregidas por el equipo de seguridad de AWS tras su comunicación por parte de los investigadores. Fuente: https://orca.security/resources/blog/aws-glue-vulnerability/ Riesgos de no tener una exposición de información controlada (I)Boletín semanal ciberseguridad 15-21 de enero
Roberto García Esteban ChatGPT y Cloud Computing: un matrimonio bien avenido ChatGPT (quizá no sepas que son las siglas de Chat Generative Pre-Trained Transformer) está en boca de todos por su impresionante habilidad para generar textos que parecen escritos por...
David Prieto Marqués La importancia del control de acceso: ¿está tu empresa protegida? Por David Prieto y Rodrigo Rojas En un mundo cada vez más digitalizado y complejo, la seguridad de la información es fundamental para las empresas. A medida que las empresas...
Telefónica Tech Boletín semanal de Ciberseguridad, 22 – 26 de mayo GitLab parchea una vulnerabilidad crítica GitLab ha abordado una vulnerabilidad crítica que afecta a GitLab Community Edition (CE) y Enterprise Edition (EE) en la versión 16.0.0. En concreto, dicho fallo...
David García ¿Salvará Rust el mundo? (II) Segunda entrega en la que descubrimos cómo Rust, el lenguaje de programación de código abierto centrado en la seguridad, mejora el panorama en cuanto a vulnerabilidades basadas en errores...
Olivia Brookhouse ¿Puede la Inteligencia Artificial entender las emociones? Cuando John McCarthy y Marvin Minsky iniciaron la Inteligencia Artificial en 1956, se sorprendieron de cómo una máquina podía resolver rompecabezas increíblemente difíciles en menos tiempo que los humanos. Sin...
Sergio de los Santos Cuatro hitos en Ciberseguridad que marcaron el futuro del malware Un recorrido por los 15 años que ha dedicado Microsoft para consolidar una estrategia que ha repercutido en la Ciberseguridad a nivel global