SAFE. Guía para proteger tu vida digital y tu privacidad
Showing posts with label cloud computing. Show all posts
Showing posts with label cloud computing. Show all posts

Jul 17, 2026

Suplantación de ID de cliente de OAuth

Al menos dos grupos de ciberdelincuentes están utilizando una novedosa técnica de evasión llamada suplantación de ID de cliente OAuth en campañas en la nube, eludiendo la telemetría.

Esta actividad permite a los usuarios enumerar cuentas de usuario y validar credenciales robadas en entornos Microsoft Entra ID, sin generar un inicio de sesión exitoso que alertaría a los sistemas de seguridad. Los ciberdelincuentes han comenzado a explotar esta vulnerabilidad para obtener acceso no autorizado a los servicios en la nube de las organizaciones.

"Un punto ciego en la telemetría de inicio de sesión en la nube: Entra ID devuelve diferentes respuestas de error según la validez del ID de cliente OAuth proporcionado", declaró Proofpoint. "Los atacantes aprovechan esto para inferir nombres de usuario y contraseñas válidas a gran escala, comprobando así listas de credenciales robadas sin registrar un inicio de sesión exitoso".

En otras palabras, los ataques utilizan el ID de cliente OAuth, un identificador único global (GUID) asignado a las aplicaciones al solicitar acceso a los datos de usuario, que se transmite como "client_id" en las solicitudes de autenticación. Al proporcionar identificadores de cliente falsificados, permite la enumeración de cuentas sin una aplicación OAuth registrada y permite a los atacantes inferir la validez de la contraseña y la cuenta sin generar un inicio de sesión exitoso.

"Los registros de inicio de sesión de Entra son una fuente principal de telemetría para identificar actividades de autenticación maliciosas, incluyendo la enumeración de usuarios, el ataque de fuerza bruta contra contraseñas y los intentos de acceso iniciales", afirmó Rachel Rabin, investigadora de Proofpoint.

Se ha observado que grupos de amenazas como UNK_CustomCloak falsifican cadenas de agente de usuario para orquestar campañas de fuerza bruta dirigidas a entornos de Microsoft Entra ID, explotando una aplicación obsoleta de Microsoft llamada Windows Live Custom Domains para eludir las restricciones de inicio de sesión estándar y sondear las contraseñas de los usuarios en más de 4.000 inquilinos.

Sin embargo, los últimos esfuerzos representan una evolución de esta técnica al falsificar los identificadores de cliente de OAuth mediante solicitudes HTTP POST al punto final de token OAuth 2.0 de Microsoft utilizando el flujo de Credenciales de Contraseña del Propietario del Recurso (ROPC). En concreto, esto implica proporcionar un ID de cliente sintácticamente válido, pero que no corresponde a una aplicación real.

En estos casos, solo se registra el ID de la aplicación en el registro de inicio de sesión de Entra, sin el nombre de la aplicación correspondiente. La respuesta, que contiene un código de error del Servicio de tokens de seguridad de Azure Active Directory (AADSTS), puede utilizarse para deducir si la cuenta existe y si la contraseña es correcta, incluso sin una aplicación registrada.

"Si el ID de cliente falsificado no es un UUIDv4 válido, Entra no rechaza la solicitud directamente", explicó Proofpoint. "Por lo tanto, los atacantes pueden analizar esta respuesta de error para identificar cuentas y contraseñas válidas, a pesar de utilizar ID de cliente mal formados. Cuando se utiliza un ID de cliente falsificado, no se registra el nombre de la aplicación correspondiente en el registro de inicio de sesión. Esto significa que las detecciones que buscan picos de actividad asociados a un nombre de aplicación específico pueden pasar por alto esta actividad por completo, ya que el campo aparece en blanco".

Con esta información, los atacantes podrían identificar cuentas susceptibles de ser explotadas para obtener acceso sigiloso, dificultando a los defensores la detección de actividades sospechosas.

Proofpoint ha identificado dos grandes campañas que adoptaron esta técnica de forma independiente a finales de diciembre de 2025, lo que indica que este método se está incorporando cada vez más a las tácticas de los atacantes, en lugar de ser un incidente aislado:

  • UNK_pyreq2323 (de enero a marzo de 2026), que utilizó más de 700.000 ID de cliente falsificados de la infraestructura de Amazon Web Services (AWS) para atacar a más de un millón de cuentas en casi 4.000 clientes, provocando el bloqueo de aproximadamente el 28% de los usuarios afectados debido a intentos fallidos.
  • UNK_OutFlareAZ (a partir de diciembre de 2025), que aprovechó la infraestructura de Cloudflare para atacar a más de dos millones de usuarios con 3,7 millones de ID de aplicación falsificados generados aleatoriamente. Se ha observado que ambas campañas utilizan UUID válidos en lugar de identificadores mal formados y demuestran patrones que coinciden con listas de nombres de usuario precompiladas. Sin embargo, mientras que UNK_OutFlareAZ enumeraba a los usuarios alfabéticamente, UNK_pyreq2323 no lo hacía. Otra diferencia radicaba en cómo se falsificaban los ID de cliente.

Se dice que UNK_pyreq2323 modificaba los últimos dígitos de un ID de aplicación conocido y luego reutilizaba los ID falsificados para hasta 12 usuarios. En cambio, UNK_OutFlareAZ generaba un ID de cliente único por solicitud.

"Al fragmentar los intentos de autenticación en múltiples aplicaciones ficticias, la actividad se vuelve más difícil de correlacionar y puede eludir las detecciones y limitaciones de velocidad por aplicación. Las organizaciones pueden intentar mitigar los ataques de enumeración tradicionales aplicando políticas de acceso condicional (CA) dirigidas a las aplicaciones que suelen ser objetivo de la enumeración. Los ID de cliente falsificados no activarán las políticas CA dirigidas a una aplicación específica.

Fuente: THN

Mar 4, 2026

Amazon: Ataques con drones dañan centros de datos de AWS en Oriente Medio

Amazon confirmó que tres centros de datos de Amazon Web Services (AWS) en Emiratos Árabes Unidos (EAU) y uno en Bahréin fueron dañados por ataques con drones, provocando una interrupción prolongada que aún afecta a decenas de servicios de computación en la nube.

Aunque la compañía no dio más detalles, se cree que los ataques forman parte de la respuesta de Irán a las operaciones militares de EE.UU. ("Epic Fury") e Israel ("Roaring Lion") en territorio iraní durante el fin de semana.

Los ataques afectaron a la región AWS Middle East (UAE) Region (ME-CENTRAL-1) y a la AWS Middle East (Bahrain) Region (ME-SOUTH-1). Debido al conflicto en curso en Oriente Medio, ambas regiones afectadas han sufrido impactos físicos en la infraestructura como resultado de ataques con drones. En los EAU, dos de nuestras instalaciones fueron alcanzadas directamente, mientras que en Bahréin un ataque cercano a una de nuestras instalaciones causó daños físicos", informó Amazon en una actualización de estado.

Los ataques provocaron daños estructurales, interrupciones en el suministro eléctrico y, en algunos casos, la necesidad de activar sistemas de supresión de incendios que ocasionaron daños adicionales por agua. Amazon aseguró que trabaja con las autoridades locales y que la seguridad de su personal es la prioridad durante las tareas de recuperación.

Actualmente, tres zonas de disponibilidad en los EAU (mec1-az2 y mec1-az3) siguen “gravemente afectadas”, mientras que una tercera en Bahréin (mes1-az2) continúa con problemas de energía localizados.

La compañía está restaurando la infraestructura física y desarrollando "múltiples rutas de recuperación basadas en software" que no requieren que las instalaciones estén completamente operativas. También prioriza la restauración de servicios y herramientas que permitan a los clientes respaldar y migrar datos y aplicaciones fuera de las regiones impactadas.

Amazon aconsejó a los clientes afectados que respalden sus datos y migren cargas de trabajo a regiones de AWS no afectadas. Recomendó activar planes de recuperación ante desastres, restaurar desde copias remotas y redirigir el tráfico lejos de las regiones dañadas. Como alternativas, sugirió considerar regiones en Estados Unidos, Europa o Asia-Pacífico, según las necesidades de latencia y residencia de datos.

El Centro Nacional de Ciberseguridad del Reino Unido (NCSC) también advirtió a las organizaciones británicas sobre un mayor riesgo de ciberataques iraníes en el contexto del conflicto en Oriente Medio.

Fuente: BC

Feb 22, 2026

Las caídas de AWS involucraron agentes IA con "demasiados permisos"

La unidad de nube de Amazon ha sufrido al menos dos interrupciones debido a errores relacionados con sus propias herramientas de IA, lo que ha llevado a algunos empleados a cuestionar la iniciativa del gigante tecnológico estadounidense para implementar estos asistentes de programación.

Amazon Web Services sufrió una interrupción de 13 horas en un sistema utilizado por sus clientes a mediados de diciembre después de que los ingenieros permitieran que su herramienta de programación de IA Kiro realizara ciertos cambios, según cuatro personas familiarizadas con el asunto.

Estas personas afirmaron que la herramienta de agencia, que puede realizar acciones autónomas en nombre de los usuarios, determinó que la mejor medida era "eliminar y recrear el entorno".

Amazon publicó un análisis interno sobre la "interrupción" del sistema de AWS, que permite a los clientes analizar los costos de sus servicios.

Varios empleados de Amazon declararon que esta era la segunda ocasión en los últimos meses en que una de las herramientas de IA del grupo había sido el centro de una interrupción del servicio. "Ya hemos visto al menos dos interrupciones de producción [en los últimos meses]", declaró un empleado sénior de AWS. Los ingenieros permitieron que el agente de IA resolviera un problema sin intervención. Las interrupciones fueron pequeñas, pero totalmente previsibles.

AWS, que representa el 60% de las ganancias operativas de Amazon, busca desarrollar e implementar herramientas de IA, incluyendo "agentes" capaces de actuar de forma independiente según instrucciones humanas.

Al igual que muchas grandes tecnológicas, busca vender esta tecnología a clientes externos. Los incidentes ponen de relieve el riesgo de que estas incipientes herramientas de IA puedan funcionar mal y causar interrupciones.

Amazon afirmó que fue una "coincidencia que las herramientas de IA estuvieran involucradas. El mismo problema podría ocurrir con cualquier herramienta de desarrollo o acción manual. En ambos casos, se trató de un error del usuario, no de un error de IA", declaró Amazon, añadiendo que no había constatado que los errores fueran más comunes con las herramientas de IA.

La compañía afirmó que "el incidente de diciembre fue un evento extremadamente limitado" que afectó únicamente a un servicio en algunas zonas de China continental. Amazon añadió que el segundo incidente no afectó a ningún servicio de AWS de cara al cliente.

Ninguna interrupción fue tan grave como la interrupción de 15 horas de AWS en octubre de 2025, que obligó a desconectar las aplicaciones y sitios web de varios clientes, incluido ChatGPT de OpenAI.

Los empleados afirmaron que las herramientas de IA del grupo se consideraban una extensión de un operador y se les otorgaron los mismos permisos. En estos dos casos, los ingenieros involucrados no necesitaron la aprobación de una segunda persona antes de realizar cambios, como sería habitual.

Amazon afirmó que, por defecto, su herramienta Kiro "solicita autorización antes de realizar cualquier acción", pero indicó que el ingeniero involucrado en el incidente de diciembre tenía "permisos más amplios de lo esperado: un problema de control de acceso del usuario, no de autonomía de la IA".

AWS lanzó Kiro en julio, para escribir código basándose en un conjunto de especificaciones. Anteriormente, el grupo había utilizado su producto Amazon Q Developer, un chatbot con IA, para ayudar a los ingenieros a escribir código. Este estuvo involucrado en la interrupción anterior, según tres de los empleados.

Algunos empleados de Amazon manifestaron su escepticismo sobre la utilidad de las herramientas de IA para la mayor parte de su trabajo, dado el riesgo de error. Añadieron que la compañía se había fijado el objetivo de que el 80% de los desarrolladores utilizaran IA para tareas de programación al menos una vez a la semana y que estaba monitoreando de cerca su adopción.

Amazon afirmó que estaba experimentando un fuerte crecimiento de clientes de Kiro y que quería que tanto clientes como empleados se beneficiaran de las mejoras de eficiencia.

Tras el incidente de diciembre, AWS implementó numerosas medidas de seguridad, incluyendo la revisión obligatoria por pares y la capacitación del personal, añadió Amazon.

Fuente: Arstechnica

Jan 20, 2026

Vulnerabilidad en Cloudflare permitía acceso a cualquier host eludiendo las protecciones

Una vulnerabilidad Zero-Day crítica en el firewall de aplicaciones web (WAF) de Cloudflare permitía (fue solucionado en octubre pasado) a los atacantes eludir los controles de seguridad y acceder directamente a servidores de origen protegidos a través de una ruta de validación de certificados.

Investigadores de seguridad de FearsOff descubrieron que las solicitudes dirigidas al directorio /.well-known/acme-challenge/ podían alcanzar los orígenes incluso cuando las reglas del WAF configuradas por el cliente bloqueaban explícitamente el resto del tráfico.

El protocolo ACME (Automatic Certificate Management Environment) automatiza la validación de certificados SSL/TLS al exigir a las autoridades de certificación (CA) que verifiquen la propiedad del dominio. ACME es un protocolo de comunicaciones (RFC 8555) que facilita la emisión, renovación y revocación automáticas de certificados SSL/TLS. Cada certificado proporcionado a un sitio web por una autoridad de certificación (CA) se valida mediante desafíos para demostrar la propiedad del dominio.

El servidor de la CA realiza una solicitud HTTP GET a una URL exacta para recuperar el archivo. Una vez verificada, se emite el certificado y la CA marca la cuenta ACME (es decir, la entidad registrada en su servidor) como autorizada para administrar ese dominio específico.

Si el desafío se realiza mediante una orden de certificado administrada por Cloudflare, Cloudflare responderá por la ruta mencionada y proporcionará el token proporcionado por la CA al solicitante. Sin embargo, si no se corresponde con una orden administrada por Cloudflare, la solicitud se enruta al origen del cliente, que podría estar utilizando un sistema diferente para la validación del dominio.

En el método de validación HTTP-01 (o DNS-01), las CA esperan que los sitios web proporcionen un token de un solo uso en /.well-known/acme-challenge/{token}. Esta ruta existe en casi todos los sitios web modernos como una ruta de mantenimiento silenciosa para la emisión automatizada de certificados.

El diseño limita este acceso a un único bot de validación que revisa un archivo específico, no como una puerta de enlace abierta al servidor de origen.

Vulnerabilidad de día cero en Cloudflare

La vulnerabilidad, descubierta y reportada por FearsOff en octubre de 2025, se relaciona con una implementación defectuosa del proceso de validación ACME que provoca que ciertas solicitudes de desafío a la URL deshabiliten las reglas del firewall de aplicaciones web (WAF) y le permitan acceder al servidor de origen cuando, idealmente, debería haber sido bloqueada.

En otras palabras, la lógica no podía verificar si el token en la solicitud coincidía realmente con un desafío activo para ese nombre de host específico, lo que permitía a un atacante enviar solicitudes arbitrarias a la ruta ACME, eludir por completo las protecciones del WAF, y acceder al servidor de origen.

Las pruebas revelaron que las solicitudes dirigidas a la ruta de desafío ACME eludían por completo las reglas del WAF, lo que permitía al servidor de origen responder directamente en lugar de devolver la página de bloqueo de Cloudflare.

Para confirmar que no se trataba de una configuración incorrecta específica del inquilino, los investigadores crearon hosts de demostración controlados por ellos. Las solicitudes normales a estos hosts encontraron páginas de bloqueo como se esperaba, pero las solicitudes de la ruta ACME devolvieron respuestas generadas por el origen, generalmente errores 404 del framework.

La vulnerabilidad se originaba en la lógica de procesamiento de la red perimetral de Cloudflare para las rutas de desafío ACME HTTP-01. Cuando Cloudflare proporcionaba tokens de desafío para sus propios pedidos de certificados administrados, el sistema desactivaba las funciones del WAF para evitar interferencias con la validación de la CA.

Una falla crítica: si el token solicitado no coincidía con un pedido de certificado administrado por Cloudflare, la solicitud omitía por completo la evaluación del WAF y se dirigía directamente al origen del cliente. Este error lógico transformaba una excepción de validación de certificado limitada en una omisión de seguridad amplia que afectaba a todos los hosts protegidos por Cloudflare.

Esta omisión permitió a los investigadores demostrar múltiples vectores de ataque contra frameworks web comunes. En aplicaciones Spring/Tomcat, las técnicas de cruce de rutas de servlets mediante ..;/ accedieron a puntos finales sensibles de actuadores que expusieron entornos de proceso, credenciales de base de datos, tokens de API y claves de nube.

Las aplicaciones de renderizado del lado del servidor de Next.js filtraron datos operativos a través de respuestas directas al origen que nunca estuvieron destinadas al acceso público a internet.

Las aplicaciones PHP con vulnerabilidades de inclusión de archivos locales se volvieron explotables, lo que permitió a los atacantes acceder al sistema de archivos mediante parámetros de ruta maliciosos. Más allá de los ataques específicos del framework, las reglas del WAF a nivel de cuenta configuradas para bloquear solicitudes basadas en encabezados personalizados se ignoraron por completo para el tráfico de rutas ACME.

FearsOff reportó la vulnerabilidad a través del programa de recompensas por errores HackerOne de Cloudflare el 9 de octubre de 2025. Cloudflare inició la validación el 13 de octubre de 2025 y HackerOne evaluó el problema el 14 de octubre de 2025.

La compañía implementó una solución permanente el 27 de octubre de 2025, modificando el código para deshabilitar las funciones de seguridad solo cuando las solicitudes coincidan con tokens de desafío ACME HTTP-01 válidos para el nombre de host específico.

Las pruebas posteriores a la solución confirmaron que las reglas del WAF ahora se aplican uniformemente en todas las rutas, incluida la ruta de desafío ACME, anteriormente vulnerable. Cloudflare declaró que no se requiere ninguna acción por parte del cliente y confirmó que no se ha encontrado evidencia de explotación maliciosa.

Fuente: CyberSecurityNews

Oct 20, 2025

AWS se cayó... sí, es lo poco que sabemos (Actualizado)

Una interrupción de AWS ha paralizado millones de sitios web, incluyendo Amazon.com, Prime Video, Perplexity AI, Canva y más.

La caída comenzó durante la madrugada del lunes y se concentró en servidores de la región de Virginia del Norte (Estados Unidos), una de las más críticas dentro del ecosistema de AWS. El suministro se restableció en horas de la tarde.

La interrupción ha afectado a consumidores de todas las regiones, incluyendo Estados Unidos y Europa y Latinoamérica y, en la página de AWS Health, Amazon está informando sobre el estado de situación que afecta a múltiples servicios. "Podemos confirmar un aumento en las tasas de error y latencia para múltiples servicios de AWS en la región US-EAST-1. Este problema también podría estar afectando la creación de casos a través del Centro de Soporte de AWS o la API de Soporte. Estamos trabajando activamente para mitigar el problema y comprender la causa raíz", señaló AWS.

Si bien Amazon (aún) no ha compartido la causa específica de la interrupción, las actualizaciones de estado indican que está relacionada con un problema de resolución de DNS para el punto final de la API de DynamoDB en la región US-EAST-1 de AWS en Virginia. VER ABAJO.

Según investigaciones en curso, el fallo se originó en la red interna de Elastic Compute Cloud (EC2), que permite a los usuarios crear aplicaciones basadas en la nube y gestionar los recursos informáticos pertinentes para hacerlas funcionar.

La interrupción tuvo un alcance global. Servicios como Netflix, Microsoft 365, YouTube, Facebook, Snapchat y Fortnite registraron fallas generalizadas. En algunos casos, los usuarios no podían iniciar sesión; en otros, se interrumpía la reproducción de videos o el funcionamiento de videollamadas.

En una publicación en X, Fortnite de Epic Games confirmó una importante interrupción del servicio, así como Perplexity cuya aplicación de chat está fuera de línea debido. La empresa de diseño gráfico Canva reconoció una interrupción del servicio que afectó la edición de imágenes y otras funciones.

Según Downdetector, 15 servicios importantes, incluyendo plataformas de entretenimiento como Roblox y Hulu, están o estuvieron fuera de línea debido a problemas con AWS.

El impacto también se sintió en América Latina, donde miles de usuarios reportaron dificultades para realizar pagos electrónicos o acceder a apps de uso cotidiano. 

Tras casi 12 horas en la interrupción del servicio, el problema "fue mitigado por completo y la mayoría de las operaciones del servicio AWS funcionan con normalidad ahora en todo el mundo" indicó en una actualización la página web de mantenimiento y añadió que algunas operaciones, aún tienen inconvenientes que se irán recuperando en el transcurso de la jornada.

Punto único de fallo

ACTUALIZACIÓN 20/10. Resolución oficial de AWS: era el DNS.

Un único punto de fallo provocó la interrupción de Amazon que afectó a millones de personas. El incidente fue provocado por un defecto latente dentro del sistema automatizado de administración de DNS que provocó fallas en la resolución de puntos finales para DynamoDB.

Un administrador de DNS en una sola región de la extensa red de Amazon desencadenó un desastre de 16 horas. A su vez, el retraso en la propagación del estado de la red se extendió a un balanceador de carga de red del que dependen los servicios de AWS para su estabilidad.

Como resultado, los clientes de AWS experimentaron errores de conexión desde la región US-East-1. Las funciones de red de AWS afectadas incluyeron la creación y modificación de clústeres de Redshift, las invocaciones de Lambda y el lanzamiento de tareas de Fargate, como los flujos de trabajo administrados para Apache Airflow, las operaciones del ciclo de vida de Outposts y el Centro de soporte de AWS.

Por el momento, Amazon ha deshabilitado el Planificador de DNS de DynamoDB y la automatización del DNS en todo el mundo mientras trabaja para corregir la condición de carrera y añadir protecciones para evitar la aplicación de planes de DNS incorrectos. Los ingenieros también están realizando cambios en EC2 y su balanceador de carga de red.

Ookla describió un factor contribuyente que Amazon no mencionó: la concentración de clientes que enrutan su conectividad a través del punto final US-East-1 y la imposibilidad de enrutar dentro de la región: "El punto final US-EAST-1 afectado es el más antiguo y más utilizado de AWS. La concentración regional implica que incluso las aplicaciones globales suelen anclar allí los flujos de identidad, estado o metadatos. Cuando falla una dependencia regional, como ocurrió en este caso, los impactos se propagan a nivel mundial porque muchas pilas "globales" enrutan a través de Virginia en algún momento".

Las aplicaciones modernas encadenan servicios gestionados como almacenamiento, colas y funciones sin servidor. Si el DNS no puede resolver de forma fiable un punto final crítico (por ejemplo, la API de DynamoDB involucrada en este caso), los errores se propagan en cascada a través de las API ascendentes y causan fallos visibles en aplicaciones que los usuarios no asocian con AWS.

El evento sirve como advertencia para todos los servicios en la nube: más importante que prevenir condiciones de carrera y errores similares es eliminar los puntos únicos de fallo en el diseño de la red.

El camino a seguir no es cero fallos, sino fallos contenidos, logrados mediante diseños multirregionales, diversidad de dependencias y una preparación rigurosa ante incidentes, con una supervisión regulatoria que avance hacia el tratamiento de la nube como un componente sistémico de la resiliencia nacional y económica.

Jun 13, 2025

Ataques de password-spraying a 80.000 cuentas de Microsoft Entra

Investigadores de seguridad Proofpoint han descubierto una nueva campaña de adquisición de cuentas (Account TakeOver - ATO) que aprovecha un framework para realizar pentesting de código abierto,   llamado TeamFiltration, para violar las cuentas de usuario de Microsoft Entra ID (anteriormente Azure Active Directory).

Bautizado como Unk_sneakystrike por Proofpoint, la campaña se ha dirigido a más de 80.000 cuentas de usuarios en cientos de clientes en la nube y, desde su inicio en diciembre de 2024, ha logrado acceder a cientos de organizaciones. "Los atacantes aprovechan a los servidores de API y Amazon Web Services (AWS) de Microsoft Teams ubicados en varias regiones geográficas para lanzar intentos de enumeración de cuentas y password-spraying. Los atacantes explotaron el acceso a recursos específicos y aplicaciones nativas, como equipos de Microsoft, OneDrive, Outlook y otros".

TeamFiltration, publicado públicamente por el investigador Melvin "Flangvik" Langvik, en agosto de 2022 en la Conferencia de Seguridad DefCon 30, se describe como un marco multiplataforma para "enumerating, spraying, exfiltrating, and backdooring cuentas de Entra ID".

La herramienta ofrece amplias capacidades para facilitar la adquisición de la cuenta utilizando ataques de password-spraying, exfiltración de datos y acceso persistente al cargar archivos maliciosos a la cuenta de Microsoft OneDrive del objetivo.

Si bien la herramienta requiere una cuenta de Amazon Web Services (AWS) y una cuenta desechable de Microsoft 365 para facilitar el spraying de contraseñas y las funciones de enumeración de la cuenta, Proofpoint dijo que observó evidencia de actividad maliciosa que aprovechó la filtración de equipo para realizar estas actividades de manera que cada onda de spray se origina de un servidor diferente en una nueva ubicación geográfica.

En su punto máximo, la campaña dirigió a 16.500 cuentas en un solo día a principios de enero de 2025. Las tres geografías de fuentes principales vinculadas a la actividad maliciosa en función del número de direcciones IP incluyen Estados Unidos (42%), Irlanda (11%) y Gran Bretaña (8%).

La actividad Unk_Sneakystrike se ha descrito como "intentos de enumeración de usuarios a gran escala en ráfagas altamente concentradas dirigidas a varios usuarios dentro de un entorno de una sola nube". Esto es seguido por una pausa que dura de cuatro a cinco días.

Los hallazgos resaltan una vez más cómo las herramientas diseñadas para ayudar a los profesionales de seguridad pueden ser mal utilizados por los actores de amenazas para llevar a cabo una amplia gama de acciones nefastas que les permiten violar las cuentas de los usuarios, cosechar datos confidenciales y establecer puntos de apoyo persistentes.

Fuente: THN

Nov 1, 2024

EMERALDWHALE: credenciales robadas de archivos de configuración de Git expuestos

Investigadores de ciberseguridad han detectado una campaña "masiva" que tiene como objetivo configuraciones Git expuestas para robar credenciales, clonar repositorios privados e incluso extraer credenciales de la nube del código fuente.

Se estima que la actividad, cuyo nombre en código es EMERALDWHALE, recopiló más de 10.000 repositorios privados y los almacenó en un almacenamiento de Amazon S3 que pertenecía a una víctima anterior. El depósito, que constaba de no menos de 15.000 credenciales robadas, fue eliminado por Amazon.

"Las credenciales robadas pertenecen a proveedores de servicios en la nube (CSP), proveedores de correo electrónico y otros servicios. El phishing y el spam parecen ser el objetivo principal del robo de credenciales", dijo Sysdig en un informe.

Se ha descubierto que la operación criminal multifacética, aunque no es sofisticada, aprovecha un arsenal de herramientas privadas para robar credenciales, así como para extraer archivos de configuración de Git, archivos .env de Laravel y datos web sin procesar. No se ha atribuido a ningún actor o grupo de amenazas conocido.

El conjunto de herramientas adoptado por EMERALDWHALE, que se dirige a servidores con archivos de configuración de repositorios Git expuestos mediante amplios rangos de direcciones IP, permite el descubrimiento de hosts relevantes y la extracción y validación de credenciales.

Estos tokens robados se utilizan posteriormente para clonar repositorios públicos y privados y obtener más credenciales integradas en el código fuente. La información capturada se carga finalmente en el depósito S3.

Dos programas destacados que el actor de amenazas utiliza para lograr sus objetivos son MZR V2 (MIZARU) by @kosov2 y Seyzo-v2, que se venden en mercados clandestinos y son capaces de aceptar una lista de direcciones IP como entradas para escanear y explotar repositorios Git expuestos. Estas listas se compilan normalmente utilizando motores de búsqueda legítimos como Google Dorks y Shodan y utilidades de escaneo como MASSCAN.

La herramienta descubierta incluía un README con instrucciones para seguir todo el proceso. Este es el único archivo escrito en inglés; los comentarios en scripts y otros archivos están en francés. MZR V2 está compuesto por una colección de scripts de Python y scripts de shell. El primer script, gitfinder.sh, utiliza la herramienta httpx para escanear la lista de IPs de destino. Httpx, que también fue utilizado por CRYSTALRAY, una herramienta OSS que puede escanear servidores web de una manera altamente paralelizada, lo que la hace muy eficiente.

Además, el análisis de Sysdig descubrió que una lista que comprende más de 67.000 URL con la ruta "/.git/config" expuesta se ofrece a la venta a través de Telegram por $100, lo que indica que existe un mercado para los archivos de configuración de Git.

"EMERALDWHALE, además de apuntar a los archivos de configuración de Git, también apuntó a los archivos de entorno de Laravel expuestos", dijo el investigador de Sysdig Miguel Hernández. "Los archivos .env contienen una gran cantidad de credenciales, incluidos proveedores de servicios en la nube y bases de datos".

"El mercado clandestino de credenciales está en auge, especialmente para los servicios en la nube. Este ataque demuestra que la gestión de secretos por sí sola no es suficiente para proteger un entorno".

Fuente: THN

Dec 28, 2023

Monkey365: herramienta para revisiones de Microsoft 365, Azure y Microsoft Entra ID

Monkey365 es una herramienta de seguridad de código abierto que permite realizar revisiones de configuración de seguridad Microsoft 365, Azure y Microsoft Entra ID sin el peso significativo de las API de herramientas de aprendizaje o paneles de administración complejos.

Monkey365 también ofrece más de 160 pruebas y distintas maneras de identificar brechas de seguridad en la configuración y configuración del tenant deseado. Monkey365 ofrece recomendaciones valiosas sobre cómo configurar mejor esos ajustes para sacar el máximo provecho de Microsoft 365 o de la suscripción de Azure.

Monkey365 es un módulo PowerShell basado en colector que se puede utilizar para revisar la postura de seguridad de su entorno en la nube. Con Monkey365 puedes escanear posibles configuraciones erróneas y problemas de seguridad en las cuentas públicas de acuerdo con las mejores prácticas de seguridad y las normas de cumplimiento, en aplicaciones básicas de Azure, Microsoft Entra ID y Microsoft 365.

Por defecto, el informe se basa en los estándares CIS (Center for Internet Security), aunque posiblemente se extienda a otros. Los parámetros CIS para Azure y Microsoft 365 son directrices para las mejores prácticas de seguridad y cumplimiento.

  • CIS Microsoft Azure Foundations Benchmark v1.4.0
  • CIS Microsoft 365 Foundations Benchmark v1.4.0
  • CIS Microsoft Azure Foundations Benchmark v1.5.0
  • CIS Microsoft 365 Foundations Benchmark v1.5.0

La forma de instalación y uso se puede ver en el repositorio de su autor Juan Garrido (aka tr1ana)

Fuente: SilverHack

Nov 27, 2023

Fallas críticas en ownCloud

El software de código abierto para compartir archivos ownCloud advierte sobre tres vulnerabilidades de seguridad de gravedad crítica, incluida una que puede exponer las contraseñas de administrador y las credenciales del servidor de correo.

ownCloud es utilizado por empresas, institutos educativos, agencias gubernamentales y personas preocupadas por la privacidad que prefieren mantener el control sobre sus datos en lugar de alojarlos en proveedores de almacenamiento en la nube de terceros. El sitio de OwnCloud informa 200.000 instalaciones, 600 clientes empresariales y 200 millones de usuarios.

El software consta de múltiples bibliotecas y componentes que trabajan juntos para proporcionar una variedad de funcionalidades para la plataforma de almacenamiento en la nube.

Riesgos graves de violación de datos

El equipo de desarrollo detrás del proyecto emitió tres boletines de seguridad a principios de esta semana, advirtiendo sobre tres fallas diferentes en los componentes de ownCloud que podrían afectar gravemente su integridad.

La primera falla se rastrea como CVE-2023-49103 y recibió una puntuación CVSS v3 máxima de 10. La falla se puede usar para robar credenciales e información de configuración en implementaciones en contenedores, lo que afecta todas las variables de entorno del servidor web.

Al afectar a Graphapi 0.2.0 a 0.3.0, el problema surge de la dependencia de la aplicación de una biblioteca de terceros que expone los detalles del entorno PHP a través de una URL, exponiendo las contraseñas de administrador de ownCloud, las credenciales del servidor de correo y las claves de licencia.

La solución recomendada es eliminar el archivo "owncloud/apps/graphapi/vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php", desactivar la función "phpinfo" en los contenedores Docker y cambiar secretos potencialmente expuestos como la contraseña de administrador de ownCloud, el servidor de correo, credenciales de base de datos y claves de acceso a Object-Store/S3.

"Es importante enfatizar que simplemente deshabilitar la aplicación Graphapi no elimina la vulnerabilidad", advierte el boletín de seguridad.

"Además, phpinfo expone varios otros detalles de configuración potencialmente sensibles que podrían ser explotados por un atacante para recopilar información sobre el sistema. Por lo tanto, incluso si ownCloud no se ejecuta en un entorno contenedorizado, esta vulnerabilidad debería seguir siendo motivo de preocupación".

El segundo problema, con una puntuación CVSS v3 de 9,8, afecta a las versiones 10.6.0 a 10.13.0 de la biblioteca principal de ownCloud y es un problema de omisión de autenticación. La falla hace posible que los atacantes accedan, modifiquen o eliminen cualquier archivo sin autenticación si se conoce el nombre de usuario del usuario y no han configurado una clave de firma (configuración predeterminada).

La solución publicada es negar el uso de URL prefirmadas si no se configura ninguna clave de firma para el propietario de los archivos.

La tercera falla, menos grave (puntuación CVSS v3: 9) es un problema de omisión de validación de subdominio que afecta a todas las versiones de la biblioteca Oauth2 inferiores a 0.6.1. En la aplicación Oauth2, un atacante puede ingresar una URL de redireccionamiento especialmente diseñada que omite el código de validación, permitiendo la redirección de devoluciones de llamada a un dominio controlado por el atacante.

La mitigación recomendada es reforzar el código de validación en la aplicación Oauth2. Una solución temporal compartida en el boletín es desactivar la opción "Permitir subdominios".

Las tres fallas de seguridad descritas en los boletines impactan significativamente la seguridad y la integridad del entorno ownCloud, lo que podría provocar la exposición de información confidencial, robo de datos sigiloso, ataques de phishing y más.

Debido a esto, es fundamental que los administradores de ownCloud apliquen inmediatamente las correcciones recomendadas y realicen las actualizaciones de la biblioteca lo antes posible para mitigar estos riesgos.

Fuente: BC

Nov 13, 2023

CloudMiner: técnica de criptominería indetectable en Azure Automation

Investigadores de ciberseguridad han desarrollado lo que es el primer minero de criptomonedas basado en la nube totalmente indetectable que aprovecha el servicio Microsoft Azure Automation sin acumular ningún cargo.

La empresa de ciberseguridad SafeBreach dijo que descubrió tres métodos diferentes para ejecutar el minero, incluido uno que puede ejecutarse en el entorno de la víctima sin llamar la atención.

"Si bien esta investigación es importante debido a su impacto potencial en la minería de criptomonedas, también creemos que tiene serias implicaciones para otras áreas, ya que las técnicas podrían usarse para lograr cualquier tarea que requiera la ejecución de código en Azure", dijo el investigador de seguridad Ariel Gamrian.

El estudio se propuso principalmente identificar un "criptominero definitivo" que ofrezca acceso ilimitado a recursos computacionales, al mismo tiempo que requiera poco o ningún mantenimiento, sea gratuito e indetectable.

Ahí es donde entra en juego Azure Automation. Desarrollado por Microsoft, es un servicio de automatización basado en la nube que permite a los usuarios automatizar la creación, implementación, monitoreo y mantenimiento de recursos en Azure.

SafeBreach dijo que encontró un error en la calculadora de precios de Azure que permitía ejecutar una cantidad infinita de trabajos de forma totalmente gratuita, aunque se relaciona con el entorno del atacante en sí. Desde entonces, Microsoft ha publicado una solución para el problema.

Un método alternativo implica crear un trabajo de prueba para minería, luego establecer su estado como "Error" y luego crear otro trabajo de prueba ficticio aprovechando el hecho de que solo se puede ejecutar una prueba al mismo tiempo. El resultado final de este flujo es que oculta completamente la ejecución de código dentro del entorno de Azure.

Un actor de amenazas podría aprovechar estos métodos estableciendo un shell inverso hacia un servidor externo y autenticándose en el punto final de automatización para lograr sus objetivos.

Además, se descubrió que la ejecución del código se podría lograr aprovechando la función de Azure Automation que permite a los usuarios cargar paquetes Python personalizados. "Podríamos crear un paquete malicioso llamado 'pip' y cargarlo en la cuenta de automatización", explicó Gamrian. "El flujo de carga reemplazaría el pip actual en la cuenta de Automatización. Después de guardar nuestro pip personalizado en la cuenta de Automatización, el servicio lo usó cada vez que se cargó un paquete".

SafeBreach también ha puesto a disposición una prueba de concepto denominada CloudMiner que está diseñada para obtener potencia informática gratuita dentro del servicio Azure Automation mediante el uso del mecanismo de carga de paquetes Python. La herramienta CloudMiner permite a cualquiera ejecutar código de forma gratuita en Azure utilizando esta técnica. Una vez que proporcione el script Python/Powershell que desea ejecutar y acceda a su cuenta de automatización, la herramienta se encargará del resto por usted.

Microsoft, en respuesta a las revelaciones, ha caracterizado el comportamiento como "por diseño", lo que significa que el método aún puede explotarse sin que se le cobre.

Si bien el alcance de la investigación se limita al abuso de Azure Automation para la minería de criptomonedas, la firma de ciberseguridad advirtió que los actores de amenazas podrían reutilizar las mismas técnicas para lograr cualquier tarea que requiera la ejecución de código en Azure.

"Como clientes proveedores de nube, las organizaciones individuales deben monitorear proactivamente cada recurso y cada acción que se realiza dentro de su entorno", afirmó Gamrian. "Recomendamos encarecidamente que las organizaciones se informen sobre los métodos y flujos que los actores maliciosos pueden utilizar para crear recursos indetectables y monitorear proactivamente la ejecución de código indicativo de dicho comportamiento".

​Fuente: THN

Mar 30, 2023

XSS solucionado en Azure Cloud Service (Fabric)

Microsoft corrigió una "falla peligrosa" en su componente Azure Service Fabric de la infraestructura de alojamiento en la nube de la compañía. Si se hubiera explotado, habría permitido que un actor malicioso no autenticado ejecutara código en un contenedor alojado en la plataforma.

Investigadores de Orca Security descubrieron la falla de Cross-site Scripting (XSS), a la que llamaron Super FabriXSS, en diciembre y se la informaron a Microsoft, que emitió una solución en la ronda de actualizaciones de marzo.

Los investigadores revelaron los detalles técnicos del error y demostraron cómo los atacantes pueden aprovechar la falla, que hace que las versiones de Azure Service Fabric Explorer anteriores a 9.1.1583.9590 sean vulnerables a la explotación, en una presentación en el BlueHat IL 2023 de Microsoft en Tel Aviv.

Super FabriXSS, identificado como CVE-2023-23383, con una calificación CVSS de 8.2, es la segunda falla XSS que, hasta ahora, los investigadores de Orca descubrieron en Azure Service Fabric Explorer. Como parte de la plataforma en la nube Azure de Microsoft, Azure Service permite el empaquetado, la implementación y la gestión de microservicios y contenedores sin estado y con estado en sistemas distribuidos a gran escala.

La primera vulnerabilidad XSS, denominada FabriXSS y detallada por los investigadores de Orca en octubre, no representaba un riesgo tan grave como su sucesor.

Explotando Super FabriXSS

Con Super FabriXSS, un atacante remoto no autenticado puede ejecutar código en un contenedor alojado en uno de los nodos de Service Fabric, lo que "significa que un atacante podría obtener el control de sistemas críticos y causar daños significativos", dijo Lidor Ben Shitrit, investigador de seguridad en la nube de Orca Security.

Usando Super FabriXSS, un atacante podría crear una URL maliciosa que, cuando se hace clic, inicia un proceso de varios pasos que eventualmente conduce a la creación y despliegue de un contenedor dañino en uno de los nodos del clúster.

Específicamente, los investigadores demostraron en BlueHat cómo podían escalar una vulnerabilidad XSS reflejada en Azure Service Fabric Explorer a un RCE no autenticado abusando de la pestaña de métricas y habilitando una opción específica en la consola.

La vulnerabilidad en sí surge de un parámetro vulnerable de "Node name", que puede explotarse para incrustar un iframe en el contexto del usuario, dijo Shitrit en la publicación. Este iframe luego recupera archivos remotos de un servidor controlado por el atacante, lo que finalmente conduce a la ejecución de un shell inverso malicioso de PowerShell.

"Esta cadena de ataque puede resultar en última instancia en la ejecución remota de código en el contenedor [que] se implementa en el clúster, lo que podría permitir que un atacante tome el control de los sistemas críticos", escribió.

Mitigación e implicaciones para los usuarios de Azure

Orca informó la vulnerabilidad al Microsoft Security Response Center (MSRC) el 20 de diciembre, y comenzó una investigación sobre el problema.

Si bien no es necesaria ninguna otra acción por parte de los usuarios de Azure Service Fabric, la falla resalta el peligro inherente de las vulnerabilidades sin parchear en las arquitecturas basadas en la nube, en comparación con las soluciones locales.

"Con los sistemas basados en la nube, las organizaciones a menudo dependen de proveedores externos, lo que genera una mayor superficie de ataque y menos control sobre las medidas de seguridad", agrega. "Además, es importante tener en cuenta la naturaleza multiinquilino de los entornos de nube y la importancia de mantener un aislamiento adecuado entre los inquilinos".

Fuente: Dark Reading

Feb 6, 2023

Internxt: almacenamiento gratis en la nube con E2E

Desde hace unos años, la costumbre de guardar una copia de los archivos en el portátil o en una unidad USB externa ha sido sustituida por el almacenamiento en la nube. Por lo que no tiene sentido guardar los documentos en el ordenador, ya que almacenarlos en la nube permite acceder fácilmente a estos archivos desde cualquier dispositivo de forma online.

Actualmente, existen muchas plataformas en las que se pueden almacenar los archivos en la nube, pero también hay demasiados casos de hackeos que provocan inseguridad a la hora de usar estos servicios de almacenamiento. Aunque la mayoría de las webs de almacenamiento tienen la misma función, no todas son igual de seguras. A continuación, te explicamos cuál es la más segura y aconsejable de usar.

Internxt es un servicio de almacenamiento en la nube de código abierto y está construido sobre una cadena de bloques, por lo que cada parte de código que creamos es accesible para su verificación y cada acción en nuestra plataforma se registra en la cadena de bloques o blockchain. Su objetivo principal es ofrecer la máxima privacidad al usuario para evitar que los archivos sean accesibles por un ciberdelincuente. La ventaja de este servicio de almacenamiento en la nube es que funciona en base al cifrado Extremo a Extremo (E2E) de los datos, esto quiere decir, que solamente podrá acceder a los archivos el usuario.

Cada vez que se registra una cuenta en la plataforma Internxt, se genera una frase de contraseña y se coloca en el cliente. Esta frase de contraseña se llama mnemónica. A continuación, se cifra el mnemónico antes de enviarlo a los sistemas de Internxt. La contraseña en texto plano sólo se utiliza como clave para cifrar el mnemónico antes de que salga del dispositivo. A partir de entonces, cada vez que se accede a la cuenta, la contraseña se utilizará para descifrar el mnemónico, que a su vez se utilizará para obtener cada clave de cifrado única para cada archivo.

Otra de las ventajas de esta web de almacenamiento es que los archivos que compartas al estar cifrados se fragmentan y se distribuyen para que en ningún caso se pueda acceder si no se tiene la clave de acceso. En caso de querer compartir algún documento, vídeo o fotografía puedes hacerlo a través de un enlace o un e-mail que tendrás que enviarle y permitirle el acceso.

Este servicio tiene su propia sección de fotos que se suben automáticamente a la nube. Además, si tienes varios dispositivos y quieres tener todos los archivos en cada uno de ellos, no te preocupes porque podrás tenerlo gracias a la sincronización.Los archivos encriptados se envían a través de una amplia red de pares y no en servidores de datos centralizada. Internxt no opera un centro de datos masivo, a diferencia de Amazon y Google.

Todas estas transacciones y movimientos de datos se rastrean y organizan en la Blockchain, un registro digital que guarda todas las transacciones a perpetuidad.

Este servicio ofrece 10 gigas de almacenamiento gratuito, por lo que una vez que superes esta cantidad, tendrás que suscribirte a las opciones de pago. Si estás buscando un proveedor de almacenamiento esta es una buena opción.

Fuente: Internxt

Oct 17, 2022

Pentesting AWS "Awesome"

Esta guía "AWSome Pentesting Cheatsheet" fue creada para ayudar a los pentesters a aprender más sobre las configuraciones incorrectas de AWS y las formas de abusar de ellas.

Esta otra lista "Awesome AWS Security" y esta otra "Awesome-Cloud-PenTest" son similares y tienen los mismos objetivos.

Las guías fueron creada en base a apuntes recopilados por los autores e incontables horas de estudio, videos y anotaciones de varios lugares.

NOTA: Se supone que, para ejecutar las pruebas, el analista tiene las claves de acceso a la cuenta de AWS a analizar.


Jul 18, 2022

Vulnerabilidad de autenticación en el servicio de Kubernetes de AWS

Un investigador de seguridad reportó recientemente un problema en AWS IAM Authenticator de Kubernetes, usado por el servicio Amazon Elastic Kubernetes Service (EKS). El investigador identificó un problema en la validación de parámetros en el plugin de autenticación cuando éste se configura para hacer uso de parámetro de plantilla "AccessKeyID" en el contenido de la string de la petición.

El problema habría permitido a un atacante con cierto nivel de conocimientos escalar privilegios dentro de un cluster de Kubernetes.

¿Qué es EKS?

Según la documentación oficial de AWS, Amazon Elastic Kubernetes (EKS) se trata de un servicio administrado (esto es, por AWS, no por el cliente) que se puede utilizar "para ejecutar Kubernetes en AWS sin necesidad de instalar, operar ni mantener" un plano de control propio propio o nodos de Kubernetes.

El fallo causante de la vulnerabilidad se encuentra en una línea de código concreta del mecanismo de autenticación de IAM para Kubernetes:

El funcionamiento esperado del fragmento de código anterior es una validación de la capitalización del parámetro que se recibe, es decir, del uso de mayúsculas y minúsculas. Sin embargo, esta validación no se estaba llevando a cabo de la manera correcta, siendo posible enviar parámetros duplicados.

Este fallo en el proceso de autenticación que podría permitir a un atacante evadir las protecciones existentes frente a ataques en los que una transmisión de datos válidas es repetida de manera fraudulenta (replay attacks).

La vulnerabilidad está presente desde el primer commit de AWS IAM Authenticator realizado el 12 de octubre de 2017, lo que implica que tanto la acción modificable como los tokens de identificación de clusters han sido explotables desde el primer momento.

Concretamente, la explotación del nombre de usuario a través del parámetro "AccessKeyID" habría sido posible desde el pasado 2 de septiembre de 2020, momento en el que AWS introdujo esta característica en el servicio.

No obstante, cabe mencionar que solo aquellos clientes que usan el parámetro "AccessKeyID" se ven afectados por la vulnerabilidad, y Amazon lanzó un parche que la solventaba el pasado 28 de junio, por lo que aquellos usuarios que usen AWS IAM Authenticator para Kubernetes en el servicio Amazon EKS no necesitan tomar ninguna medida de mitigación.

Sin embargo, para aquellos clientes que administren sus propios clusters de Kubernetes y hagan uso de "AccessKeyID", situación en la que se debe actualizar AWS IAM Authenticator a la versión 0.5.9.

Fuentes:

Jun 4, 2022

Base de datos de Elasticsearch son reemplazados con una nota de rescate

Los investigadores de SecureWorks identificaron que múltiples bases de datos de Elasticsearch publicadas en Internet habían sido reemplazadas con una nota de rescate. La nota exige un pago de Bitcoin a cambio de los datos.

Los investigadores identificaron más de 1.200 bases de datos de Elasticsearch que contenían la nota de rescate. Los índices residen de Elasticsearch no requieren autenticación para leer o escribir datos. En cada caso, los datos guardados en las bases de datos se reemplazaron con una nota de rescate almacenada en el campo 'message' de un índice llamado 'read_me_to_recover_database'. Dentro del campo 'email' dejaron una dirección de correo electrónico de contacto. Los investigadores identificaron cuatro direcciones de correo electrónico distintas utilizadas en esta campaña.

No es posible determinar el número real de víctimas porque la gran mayoría de las bases de datos estaban alojadas en redes operadas por proveedores en la nube. Es probable que algunas bases de datos pertenezcan a la misma organización, pero en la mayoría de los casos no fue posible identificar víctimas específicas.

La campaña es amplia, pero el pago del rescate es comparativamente bajo. Los investigadores identificaron más de 450 solicitudes individuales de pagos de rescate, por un total de más de U$S 280.000. La solicitud de rescate promedio fue de aproximadamente U$S 620 a dos billeteras de Bitcoin. En este momento, ambas billeteras están vacías y no parecen haber sido utilizadas para realizar transacciones con fondos relacionados con los rescates.

Si bien esta campaña parece no tener éxito, representa un riesgo para las organizaciones que alojan datos en bases de datos con acceso a Internet. Las instancias de Elasticsearch no seguras son trivialmente fáciles de identificar utilizando el motor de búsqueda de Shodan.

El actor de amenazas probablemente usó un script automatizado para identificar las bases de datos vulnerables, borrar los datos y dejar la nota de rescate. Si bien el actor de amenazas podría haber usado una herramienta como Elasticdump para filtrar los datos, el costo de almacenar datos de 1.200 bases de datos sería prohibitivamente costoso.

Esta actividad maliciosa no es exclusiva de Elasticsearch. En 2020, otros investigadores descubrieron que aproximadamente la mitad de las instancias de MongoDB expuestas se borraron y reemplazaron con una nota de rescate similar. La explotación de bases de datos no seguras no se limita a campañas de extorsión y robo de datos. Los actores de amenazas que buscan información confidencial relacionada con organizaciones específicas podrían crear fácilmente búsquedas que identifiquen datos relevantes en los índices de las bases de datos publicadas en Internet.

Cuando una base de datos requiere acceso remoto, las organizaciones deben implementar la autenticación multifactor (MFA) para proteger los servicios orientados a Internet. Las organizaciones también deben revisar las políticas de seguridad de los proveedores de la nube y no asumir que los datos están protegidos de manera predeterminada.

Para detectar la presencia de esta amenaza, los investigadores de SecureWorks recomiendan que las organizaciones usen los controles disponibles para monitorear los indicadores enumerados en esta tabla.

Fuente: SecureWorks

Nov 29, 2021

Aprovechan Google Cloud 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. Informe PDF.

De las 50 instancias de GCP comprometidas recientemente, el 86% de ellas se utilizaron para realizar minería de criptomonedas, en algunos casos dentro de los 22 segundos posteriores a la infracción exitosa, 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, Brasil y Los Estados unidos naciones 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", dijeron los investigadores. "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".

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: THN

Nov 19, 2021

Cloud Controls Matrix CCMv4 en español

Cloud Controls Matrix (CCM) es un marco de control de ciberseguridad para la computación en la nube que se considera el estándar de facto para la seguridad y privacidad de la nube. En enero de 2021, CSA lanzó la versión 4 de Cloud Controls Matrix (CCM).

La nueva versión asegura la cobertura de los requisitos derivados de las nuevas tecnologías en la nube, nuevos controles y una mayor interoperabilidad y compatibilidad con otros estándares.

Esta versión traducida de esta publicación se realizó a partir de la fuente original del material gracias al esfuerzo de los capítulos y voluntarios, pero el contenido traducido queda fuera del Ciclo de Vida de Investigación de CSA).

Fuente: CSA

Nov 16, 2021

Utilizan instancias de Alibaba ECS para minar criptomonedas

Los actores de amenazas están secuestrando las instancias de Alibaba Elastic Computing Service (ECS) para instalar el malware criptominero y aprovechar los recursos del servidor disponibles para su propio beneficio.

Alibaba es un gigante tecnológico chino con presencia en el mercado global, y sus servicios en la nube se utilizan principalmente en el sudeste asiático.

En particular, el servicio ECS se comercializa como una oferta de memoria rápida, CPU Intel y prometedoras operaciones de baja latencia. Aún mejor, para protegerse contra malware como criptomineros, ECS viene con un agente de seguridad preinstalado.

Los delincuentes informáticos eliminan el agente de seguridad de ECS para instalar mineros

Según un informe de Trend Micro, uno de los problemas con Alibaba ECS es la falta de diferentes niveles de privilegios configurados en una instancia, y todas las instancias ofrecen acceso de root de forma predeterminada.

Esto hace posible que los actores de amenazas que obtienen acceso a las credenciales de inicio de sesión accedan al servidor de destino a través de SSH como root sin ningún trabajo preparatorio oescalamiento de privilegios previo.

"El actor de la amenaza tiene el mayor privilegio posible en caso de compromiso, incluida la explotación de vulnerabilidades, cualquier problema de configuración incorrecta, credenciales débiles o fuga de datos", explica el informe de Trend Micro.

Además, estos privilegios elevados permiten a los actores de amenazas crear reglas de firewall que eliminan los paquetes entrantes de los rangos de IP que pertenecen a los servidores internos de Alibaba para evitar que el agente de seguridad instalado detecte un comportamiento sospechoso.

Los actores de amenazas pueden ejecutar scripts que detienen al agente de seguridad en el dispositivo comprometido. Dado lo fácil que es plantar rootkits de módulos del kernel y malware de cryptojacking debido a los privilegios elevados, no es de extrañar que múltiples actores de amenazas compitan para hacerse cargo de las instancias de ECS en la nube de Alibaba.

Trend Micro también ha observado scripts que buscan procesos que se ejecutan en puertos específicos comúnmente utilizados por malware y puertas traseras y finalizan los procesos asociados para eliminar el malware de la competencia.

Otra característica de ECS explotada por los actores es un sistema de escalamiento automático que permite al servicio ajustar automáticamente los recursos informáticos en función del volumen de solicitudes de los usuarios.

Esto es para ayudar a prevenir interrupciones del servicio y contratiempos debido a cargas de tráfico repentinas, pero es una oportunidad para los cryptojackers. Al abusar de esto cuando está activo en la cuenta objetivo, los actores pueden aumentar su poder de extracción de Monero e incurrir en costos adicionales para el propietario de la instancia.

Teniendo en cuenta que los ciclos de facturación son mensuales en el mejor de los casos, la víctima tardaría algún tiempo en darse cuenta del problema y tomar medidas.

Cuando el escalamiento automático no está disponible, la minería provocará un efecto de ralentización inmediato y notable a medida que los mineros utilicen la potencia de la CPU disponible.

Si está utilizando el servicio en la nube de Alibaba, asegúrese de que su configuración de seguridad sea correcta y siga las mejores prácticas.

Además, evite ejecutar aplicaciones con privilegios de root, use claves criptográficas para acceder y siga el principio de privilegio mínimo.

En el caso de ECS, su protección integrada contra malware no es suficiente, por lo que agregar una segunda capa de detección de malware y vulnerabilidades en el entorno de la nube debería ser parte de su práctica de seguridad estándar.

Fuente: BC

Oct 4, 2021

Las vulnerabilidades OMIGOD afectan a IBM QRadar en Azure

Expertos advierten que las fallas de OMIGOD CVE-2021-38647 afectan a IBM QRadar Azure y pueden ser explotadas por atacantes remotos para ejecutar código arbitrario.

OMI es un proyecto de código abierto escrito en C que permite a los usuarios administrar configuraciones en todos los entornos, se utiliza en varios servicios de Azure, incluidos Azure Automation y Azure Insights.

OMIGOD es un conjunto de cuatro vulnerabilidades, reportadas por primera vez por el equipo de investigación de Wiz, en el agente de software Open Management Infrastructure (OMI) que podrían exponer a los usuarios de Azure a ataques. Las actualizaciones de seguridad de septiembre de 2021 publicadas recientemente han abordado las cuatro vulnerabilidades, rastreadas colectivamente como OMIGOD, en el agente de software Open Management Infrastructure (OMI) que expone a los usuarios de Azure a ataques. A continuación se muestra la lista de defectos de OMIGOD:

  • CVE-2021-38647: RCE no autenticado como raíz (gravedad: 9,8)
  • CVE-2021-38648: vulnerabilidad de escalamiento de privilegios (gravedad: 7.8)
  • CVE-2021-38645: vulnerabilidad de escalamiento de privilegios (gravedad: 7.8)
  • CVE-2021-38649: vulnerabilidad de escalamiento de privilegios (gravedad: 7.0)
El paquete RPM de Open Management Infrastructure (OMI) en las imágenes del mercado de IBM QRadar Azure se ve afectado por una vulnerabilidad de ejecución remota de código identificada como CVE-2021-38647, la cual recibió una puntuación CVSS de 9.8. En el caso de IBM QRadar Azure, un atacante remoto puede aprovechar la vulnerabilidad para ejecutar código arbitrario en instalaciones vulnerables.

"Las imágenes del mercado de IBM QRadar Azure incluyen el RPM que es vulnerable y se sugiere actualizar por precaución" dice el aviso publicado por IBM. "La infraestructura de administración abierta de Microsoft Azure podría permitir que un atacante remoto ejecute código arbitrario en el sistema. Al ejecutar un programa especialmente diseñado, un atacante podría aprovechar esta vulnerabilidad para ejecutar código arbitrario en el sistema".

La vulnerabilidad puede desencadenarse ejecutando un programa especialmente diseñado en sistemas vulnerables, afecta a las siguientes versiones:

  • IBM QRadar versiones 7.3.0 a 7.3.3 parche 9
  • IBM QRadar versiones 7.4.0 a 7.4.3 parche 2

Un atacante remoto no autenticado podría aprovechar la vulnerabilidad enviando un mensaje especialmente diseñado a través de HTTPS al puerto que escucha OMI en un sistema vulnerable.

Fuente: SecurityAffairs

Sep 16, 2021

Alinear CSA CCMv4 y SOC 2

Con la evolución de CSA CCMv4, la adopción generalizada de SOC 2, el alineamiento de estas dos normas y buenas prácticasa representa una opción sólida para que los proveedores de nube y sus clientes la consideren.

CCM v4, lanzado a principios de este año, es una mejora significativa con respecto a las versiones anteriores. Es más detallado (con 197 especificaciones de control en comparación con 133 en v3.01) y los requisitos son más nítidos. Hay detalles que se ha agregado en áreas clave, tales como:

  • Criptografía, cifrado y gestión de claves
  • Gestión del ciclo de vida de la privacidad y la seguridad de los datos
  • Gestión de incidentes de seguridad, descubrimiento electrónico y análisis forense en la nube
  • Gestión, transparencia y rendición de cuentas de la cadena de suministro
  • Gestión de amenazas y vulnerabilidades
  • Gestión universal de terminales

El Cuestionario de la Iniciativa de Evaluaciones de Consenso (CAIQ), ampliamente utilizado, también se está actualizando actualmente para reflejar CCM v4.

Para los proveedores de nube que ya han establecido marcos de control comunes, alineados con varios estándares y completado una variedad de auditorías y certificaciones SOC 2, ISO, FedRAMP y otras específicas de cada país, agregar SOC 2 + CCM a su programa puede no ser un factor crítico. Además, después de evaluarse a sí mismos con respecto a la versión 4, es posible que la empresa esté bien posicionada para hacerlo de una manera razonablemente eficiente.

SOC 2 se ha convertido en una necesidad para los proveedores de nube que prestan servicios a clientes empresariales. Al trabajar con algunos de los proveedores de nube más grandes del mundo, los informes completos de SOC 2 realmente representa a las mejores prácticas, mostrando de manera efectiva la estrategia del proveedor para satisfacer la evolución de la seguridad y las necesidades de cumplimiento.

La combinación de informes SOC 2 con la matriz de controles en la nube reconocida por la industria representa una buena opción que los proveedores pueden usar para demostrar la efectividad de sus controles, así como para generar una confianza fundamental con sus clientes. Para los proveedores de nube que están desarrollando sus programas de confianza, CCM v4 es un buen punto de referencia y SOC 2 + CCM puede ser una herramienta útil para resaltar las fortalezas de los programas de seguridad.

CSA ha ganando un amplio reconocimiento de la industria en la promoción de la seguridad en la nube. En particular:

  • CSA ha seguido perfeccionando la Matriz de controles en la nube (CCM) y alineándola con otros marcos.
  • Muchas organizaciones utilizan el CAIQ, que se basa en CCM.
  • Muchos proveedores de nube han realizado autoevaluaciones basadas en CCM y algunos han incorporado CCM en sus regímenes de auditoría.
  • CSA mantiene su programa Certificate of Cloud Security Knowledge (CCSK) y recientemente lanzó un nuevo Certificate of Cloud Auditing Knowledge (CCAK) junto con ISACA.

Fuente: CloudSecurityPlus