CyberSecurityPulse (by Telefónica TECH)

2022-05-17 16:45:12 En la industria, está estandarizado (y los usuarios acostumbrados a) que las herramientas de cracking o parches para aplicaciones de pago sean detectadas por los antivirus. ¿Supone esto una verdadera ventaja? Los atacantes ya le han encontrado utilidad para pasar desapercibidos.

En la práctica, los usuarios que desean activar sin pagar (o parchear) un programa desactivan su antivirus durante la instalación, o lo activan como excepción. Hay casos como los del conocido KMSauto, que necesitan permanecer el Windows tras el parcheo. El usuario se habitúa a esa detección del antivirus o lo activa como excepción.
Los atacantes Lazarus aprovecharon precisamente esto para esconder su ataque bajo el directorio y la apariencia de KMSAuto que usaba la víctima en una investigación de ESET. No es que el parche fuera malicioso, sino que disfrazaron su ataque de KMSAuto introduciendo un payload malicioso en él. El antivirus lo detectaba, pero todos (incluida la propia ESET) deducían que ocurría por tratarse de una herramienta de parcheo o crack.

A ESET casi se le escapa esta forma de disfrazarse en el sistema. Siempre se ha afirmado que los cracks son un peligro porque pueden venir con algún malware asociado. Pero en este caso los atacantes han usado la detección (o la excepción creada permanente), como elemento de distracción o evasión… precisamente por ser siempre clasificadas este tipo de muestras como malware.

Es cierto que algunas casas antivirus distinguen entren “hacktools”, “crakctools”… en su nomenclatura, pero en la práctica los usuarios no prestan atención estas sutilezas y como en este caso, la detección puede tener un efecto contrario al deseado.

Más información: https://twitter.com/ESETresearch/status/1526183746524876802 Abrir / Cómo

2022-05-11 14:20:24 75 vulnerabilidades corregidas este martes por Microsoft. 8 críticas, tres previamente conocidas y una ya siendo explotada en el Local Security Authority: CVE-2022-26925. Permite elevar privilegios, especialmente en entornos de directorio activo. Un atacante podría forzar a un controlador de dominio a que se autentique contra él con un NTLM, y aprovechando este token reenviarlo (ataque de relay) para ejecutar código en el servidor. Resulta muy parecida al fallo PetitPotam de agosto de 2021 y es necesario priorizar los controladores a la hora de parchear.

Hablando de controladores de dominio…CVE-2022-26923 es otro fallo grave en Active Directory Domain Services y afecta si en el domino está activo el Active Directory Certificate Service.

Otro fallo grave es el que afecta al sistema de ficheros remoto NFS, también muy parecida a un fallo corregido el mes pasado y descubierto por los mismos autores.

Más información: https://msrc.microsoft.com/update-guide/vulnerability/ Abrir / Cómo

2022-05-09 13:50:27 La Unión Europea tiene sobre la mesa una iniciativa para permitir la libre competencia respecto a los denominados mercados digitales. Algo que inmediatamente parece apuntar (leyendo las consideraciones de la normativa) al Apple Store, la tienda exclusiva de aplicaciones para dispositivos iPhone, iPad y similares.
La plataforma móvil de Apple solo permite instalar aplicaciones a través de su propia tienda de aplicaciones, sin posibilidad de que un tercero ofrezca un canal alternativo de manera oficial. Al contrario de lo que ocurre en Android, donde ya es posible acceder a alternativas a Google Play.

Previsiblemente, el próximo año podría activarse el “Digital Markets Act”. Obligaría a diversos proveedores que poseen la exclusiva sobre un servicio a abrirse a que terceros puedan ofrecer servicios en igualdad de condiciones. Afectaría también a Facebook, WhatsApp y servicios similares donde solo existe un proveedor designado, para facilitar la interoperabilidad.

Esta directiva supondría una apertura que permitiría una mayor oferta. Pero desde el punto de vista de la ciberseguridad, la apertura de mercados a terceros conllevaría un riesgo implícito si no se emplean filtros adecuados para detectar aplicaciones maliciosas.

De hecho, ya tenemos la experiencia de Android con los mercados de terceros (e incluso a la propia Apple se le cuela malware de vez en cuando). Tendremos que estar vigilantes si esta apertura se materializa y en ese caso cómo se organiza el cibercrimen para abrir brecha a estas nuevas capacidades.

Más información: https://www.theverge.com/2022/5/8/23062666/eu-start-enforcing-the-dma-digital-markets-act-spring-2023-big-tech-regulation Abrir / Cómo

2022-04-29 13:20:47 La Cybersecurity & Infraestructure Security Agency (CISA) de EEUU acaba de publicar las 15 vulnerabilidades más comúnmente explotadas por atacantes durante 2021. No hay sorpresas en cuáles son las sospechosas habituales. Lo que no sorprendería es que, después de identificarlas tan claramente y disponiendo todas de parche, encontrasen objetivos jugosos con ellas.

Aunque sean 15, en realidad 8 corresponden a Exchange. Cuatro relacionadas con el fallo ProxyLogon, tres con ProxyShell y una ejecución de código adicional. También está el conocido fallo ZeroLogon en Windows.

Luego tenemos por supuesto a Log4Shell, un fallo de ejecución en Zoho ManageEngine (CVE-2021-40539) y una ejecución de código en VMware vSphere Client (CVE-2021-21972). El resto:

* Atlassian Confluence Server and Data Center (CVE-2021-26084). No es exactamente ejecución remota, sino ejecución arbitraria (comandos del propio sistema en principio no autorizados).
* Fortinet FortiOS and FortiProxy (CVE-2018-13379) (path traversal).
* Pulse Secure Pulse Connect Secure (CVE-2019-11510). Lectura arbitraria de ficheros.

Como dato curioso, para la mayoría de estos fallos, en dos semanas ya había una prueba de concepto para explotarlas después de que se conociera y solucionase la vulnerabilidad. Por último: tres de ellas ya estaban en el top 15 de 2020.

Más información: https://twitter.com/TelefonicaTech/status/1519976679266992128 Abrir / Cómo

2022-04-28 16:09:17 Después de muchos años hablando de ello, security.txt ya es un estándar con un RFC propio, el 9116. Este sencillo mecanismo permitirá estandarizar la fórmula de contacto con una compañía cuando alguien encuentre un fallo de ciberseguridad.

En la práctica, es tan sencillo como que una web cuelgue en su página un security.txt que describa qué política prefiere seguir cuando alguien quiere reportarle un fallo en ciberseguridad. El estándar permite que el formato sea totalmente legible, inequívoco y completo.
Un ejemplo sencillo de este recurso podría ser:

# Our security address
Contact: mailto:security@example.com
# Our OpenPGP key
Encryption: https://example.com/pgp-key.txt
# Our security policy
Policy: https://example.com/security-policy.html
# Our security acknowledgments page
Acknowledgments: https://example.com/hall-of-fame.html
Expires: 2021-12-31T18:37:07z

Aunque por herencia puede ser encontrado en la raíz, el archivo security.txt debe ser colocado en la ruta /.well-known/

Más información: https://www.rfc-editor.org/rfc/rfc9116 Abrir / Cómo

2022-04-22 13:41:59 El Project Zero de Google intenta encontrar y difundir 0days. Importante de nuevo: no los descubren directamente, sino que los “detectan” en cualquier fabricante mientras están siendo aprovechados por atacantes (esta es la definición de 0day). Así pueden analizar, alertar y corregir para cerrar esa puerta a los atacantes. Abogan por catalogarlos adecuadamente y ser transparentes para mejorar la comunidad.

Acaba de publicar sus conclusiones de 2021, con 58 0days encontrados mientras son aprovechados por atacantes, récord desde 2014 cuando comenzó su actividad. La plusmarca anterior fueron 28 en 2015.¿A qué se debe? Según la propia Google, no al mayor uso de 0days por parte de atacantes, sino a una actividad de detección y difusión mayor por su parte. Nunca se sabrá qué parte no se conoce o qué porción representa esos 58 del total.

Otra de las conclusiones es que la mayoría de esos 58 0days siguen prácticas muy similares a las de siempre: se basan en exploits y vulnerabilidades ya conocidas para desarrollar nuevos y exploits derivados. Solo dos constituían una novedad sus técnicas y sofisticación. Y esto es relevante. Porque siempre que se usen métodos, técnicas o procedimientos conocidos, en teoría es más fácil detectarlos de forma más sencilla por “esperables”. Aquí debería mejorar la industria.

Por cierto, de los 58, se han detectado solo 5 exploits funcionales. El resto, solo la vulnerabilidad.

Y para 2022, lo que esperan es que todos los fabricantes sean transparentes con los 0days encontrados, que sean compartidos y difundidos. O sea, etiquetar los fallos públicamente como “in the wild” cuando toque. Por ejemplo, es muy extraño que en programas tan golosos como los de mensajería instantánea, desde 2014 solo se conozca uno en WhatsApp y otro en iMessage.

Más información:
https://googleprojectzero.blogspot.com/2022/04/the-more-you-know-more-you-know-you.html Abrir / Cómo

2022-04-20 13:02:01 Ya tenemos el fallo criptográfico del año, justo 12 meses después del problema en la implementación de curvas elípticas de Microsoft descubierto por la NSA (CVE-2020–0601), llega CVE-2022-21449, un problema de implementación de ECDSA (DSA en curvas elípticas) en Java desde su versión 15. Convierte la verificación criptográfica de firmas en una farsa en cualquier entorno que se utilice.

ECDSA se basa en dos valores, r y s. La verificación criptográfica se basa en comprobar las dos partes de una ecuación en la que se introduce r por un lado y por el otro, r multiplicado por un valor derivado de s. Si ambos son cero, la verificación siempre sería válida independientemente del resto de valores… que en la práctica implican que da igual el mensaje y la clave. Todo se daría por válido.

El algoritmo de verificación explícitamente establece que es necesario comprobar que ambos valores son enteros mayores o igual a uno antes de la verificación de firma. Java 15, de 2020, omitió esa comprobación en el momento en el que se reescribió de C++ a Java el código relacionado con las curvas elípticas. Seguro que se evitaron fallos relacionados con el manejo de memoria… pero se les olvidó un paso y ningún criptógrafo lo comprobó.

El fallo se notificó en noviembre de 2021. Oracle ha publicado la corrección en abril de 2022.

Más información:
https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/ Abrir / Cómo

2022-04-13 11:58:00 145 vulnerabilidades corregidas un martes de Microsoft es mucho (contando las de Chromium). Y peor aun cuando 10 son críticas. Al menos solo una era conocida con anterioridad y solo otra aprovechada activamente por atacantes. En este último caso, por supuesto, como suele ser habitual, una elevación de privilegios a través de Common Log File System Driver (CVE-2022-24521). La razón es que las suelen encontrar casas antivirus en malware específico, aunque en este caso, aparece la NSA como descubridora también.

Uno de los fallos más graves podría ser la ejecución de código a través del Windows Network File System (CVE-2022-24497). Al menos, solo aplica a sistemas con el protocolo activo.

Pero sin duda el crítico afecta al RPC, activo por defecto, sin necesidad de contraseña y explotable en remoto (CVE-2022-26809). Por tanto, fácilmente gusanable. De nuevo, a través del puerto 445.

Más información: https://msrc.microsoft.com/update-guide/vulnerability/ Abrir / Cómo

2022-04-08 14:48:21 El malware de Android sigue su evolución, ahora innovando con algo aparentemente superado en el escritorio: los troyanos bancarios. Desde el legendario Marcher se evolucionó a Exobot en 2016, de ahí a ExobotCompact. Ahora con nuevas funcionalidades, esta familia parece llamarse Octo. La capacidad más llamativa (entre las clásicas para robar todo lo posible) es la de acceder al smartphone directamente a través de una especie de VNC y por tanto, realizar el fraude sobre el propio dispositivo, controlándolo casi en tiempo real.

Esto aporta enormes ventajas para el atacante. Virtualmente actúa como el usuario, levantando menos sospechas ante el banco, como hacían los tradicionales troyanos bancarios de Windows que a mediados de los 2000, irrumpieron inyectándose en los navegadores.

Para conseguir ese acceso en tiempo real, se basan en la funcionalidad nativa de Android MediaProjection (para proyectar en pantallas) y AccessibilityService (para la accesibilidad, algo que ya es abusado abiertamente por los atacantes). El atacante envía el comando start_vnc al sistema y consigue proyectar la pantalla del dispositivo en el command and control. A continuación pone una pantalla en negro en el sistema para no ser descubierto, quita notificaciones y el brillo a cero.

Con toda la información recogida y la proyección, puede enviar comandos como “click_at”, “paste”, “long_click”, “set_text”… mientras controla a un ratio de 1 frame por segundo en el command and control, el efecto de sus actos. Los descubridores apuntan a que esta puede ser la versión manual. Porque con este nivel de control en realidad podrían simplemente automatizar un envío de comandos en lote a través de un archivo que ejecutar. Así el ataque ganaría en escalabilidad.

Por supuesto, han colado en Google Play aplicaciones maliciosas que servían de dropper para este malware.

Más información: https://threatfabric.com/blogs/octo-new-odf-banking-trojan.html Abrir / Cómo

2022-04-05 12:45:59 Abrir / Cómo