Etiqueta: noticias de seguridad cibernética hoy Página 1 de 17

La moderna cadena de destrucción está eludiendo a las empresas porque no protegen la infraestructura de los negocios modernos: SaaS. SaaS sigue dominando la adopción de software y representa la mayor parte del gasto en la nube pública. Pero tanto las empresas como las PYMES no han revisado sus programas de seguridad ni han adoptado herramientas de seguridad creadas para SaaS. Los equipos de seguridad siguen insertando clavijas locales en los agujeros de seguridad de SaaS. Los controles de seguridad maduros de los que dependían los CISO y sus equipos en la era del dominio local han desaparecido. Los firewalls ahora protegen un perímetro pequeño, la visibilidad es limitada e incluso si los proveedores de SaaS ofrecen registros, los equipos de seguridad necesitan un middleware local para digerirlos e insertarlos en su SIEM. Los proveedores de SaaS tienen alcances de seguridad bien definidos para sus productos, pero sus clientes deben gestionar el cumplimiento de SaaS y el gobierno de datos, la gestión de identidad y acceso (IAM) y los controles de aplicaciones, las áreas donde ocurren la mayoría de los incidentes. Si bien este modelo de responsabilidad compartida de SaaS es universal entre las aplicaciones SaaS, no hay dos aplicaciones SaaS que tengan configuraciones de seguridad idénticas. Figura 1. En el contexto de las preocupaciones de seguridad de SaaS, el proveedor de la aplicación es responsable de toda la infraestructura física, así como de la red, el sistema operativo y la aplicación. El cliente es responsable de la seguridad de los datos y la gestión de la identidad. El modelo de responsabilidad compartida de SaaS requiere que los clientes de SaaS asuman la propiedad de los componentes que los actores de amenazas atacan con mayor frecuencia. Ilustración cortesía de AppOmni. La investigación de AppOmni informa que, en promedio, una sola instancia de SaaS tiene 256 conexiones de SaaS a SaaS, muchas de las cuales ya no están en uso, pero aún tienen permisos excesivos en aplicaciones comerciales principales como Salesforce, Okta y GitHub, entre otras. .Entre la multitud de diferentes configuraciones de seguridad de SaaS y las constantes actualizaciones que las modifican, los equipos de seguridad no pueden monitorear estas conexiones de manera efectiva. La cantidad de puntos de entrada se multiplica exponencialmente cuando los empleados habilitan conexiones de SaaS a SaaS (también llamadas «terceros» o «máquinas»). Las identidades de las máquinas pueden utilizar claves API, secretos, sesiones, certificados digitales, claves de acceso a la nube y otras credenciales para permitir que las máquinas se comuniquen entre sí. A medida que la superficie de ataque migraba fuera del perímetro de la red, también lo hacía la cadena de destrucción, es decir, la forma en que los actores de amenazas orquestan las distintas fases de sus ataques. Mire el informe y análisis de amenazas SaaS de AppOmni SaaS es el nuevo campo de batalla de la ciberseguridad. Vea a los expertos en seguridad de AppOmni analizar ejemplos del mundo real de la cadena de eliminación de SaaS moderna y TTP comunes, y le mostrarán cómo reducir la probabilidad de éxito de los actores de amenazas. La cadena de eliminación de SaaS moderna generalmente implica: comprometer una identidad en el IdP a través de una campaña de phishing exitosa, comprar credenciales robadas de la web oscura, cadenas de credenciales, relleno de credenciales, aprovechar inquilinos de SaaS mal configurados o métodos similares. Realización de una fase de reconocimiento posterior a la autenticación. Este paso recuerda a los atacantes que irrumpían en las redes corporativas de antaño. Pero ahora están revisando repositorios de documentos, repositorios de código fuente, bóvedas de contraseñas, Slack, Teams y entornos similares para encontrar puntos de entrada de escalada privilegiados. Aprovechar sus hallazgos para avanzar lateralmente hacia otros inquilinos de SaaS, PaaS o IaaS y, a veces, hacia la infraestructura corporativa, dondequiera que puedan encontrar los datos más valiosos para la organización objetivo. Cifrar las joyas de la corona o entregar su nota de rescate e intentar evadir la detección. Figura 2. Las cadenas de eliminación exitosas de SaaS generalmente implican cuatro pasos generales: acceso inicial, reconocimiento, movimiento lateral y persistencia, y ejecución de ransomware y evasión de seguridad. Ilustración cortesía de AppOmni. Rompiendo una cadena de muerte de SaaS del mundo real: el último seminario web informativo sobre inteligencia de amenazas de AppOmni, líder en seguridad de SaaS de Scattered Spider/Starfraud, delineó la cadena de muerte del ataque exitoso de los grupos de actores de amenazas Scattered Spider/Starfraud (afiliados de ALPHV) a un objetivo no revelado en septiembre 2023: un usuario abrió un correo electrónico de phishing que contenía enlaces a una página de inicio de sesión de IdP falsa y, sin saberlo, inició sesión en la página de IdP falsa. Los grupos de actores de amenazas llamaron inmediatamente a ese usuario y lo convencieron, mediante ingeniería social, para que le proporcionara su token de contraseña de un solo uso basado en el tiempo (TOTP). Después de obtener las credenciales de inicio de sesión del usuario y el token TOTP, los actores de amenazas engañaron al protocolo MFA haciéndoles creer que eran el usuario legítimo. Mientras estaban en modo de reconocimiento, los actores de amenazas tenían acceso a una escalada privilegiada, lo que les permitía obtener credenciales en Amazon S3, luego en Azure AD y finalmente en Citrix VDI (infraestructura de escritorio virtual). Luego, los actores de amenazas implementaron su propio servidor malicioso en el entorno IaaS, en el que ejecutaron un ataque de escalada privilegiado de Azure AD. Los atacantes cifraron todos los datos a su alcance y entregaron una nota de rescate. Figura 3. La cadena de destrucción utilizada por los grupos de actores de amenazas Scattered Spider/Starfraud. Ilustración cortesía de AppOmni. Scattered Spider/Starfraud probablemente logró esta serie de eventos durante varios días. Cuando SaaS sirve como punto de entrada, un ataque grave puede incluir la red y la infraestructura corporativa. Esta conectividad SaaS/local es común en las superficies de ataque empresariales actuales. La actividad de ataques SaaS por parte de actores de amenazas conocidos y desconocidos está aumentando. La mayoría de las infracciones de SaaS no dominan los titulares, pero las consecuencias son significativas. IBM informa que las violaciones de datos en 2023 promediaron 4,45 millones de dólares por instancia, lo que representa un aumento del 15% en tres años. Los actores de amenazas dependen continuamente de los mismos TTP y el mismo manual de estrategias de la cadena de destrucción de Scattered Spider/Starfraud para obtener acceso no autorizado y escanear a los inquilinos de SaaS, incluidos Salesforce y M365, donde los problemas de configuración podrían manipularse para proporcionar acceso más adelante. Otros atacantes obtienen acceso inicial con secuestro de sesión y viajes imposibles. Una vez que han transferido la sesión secuestrada a un host diferente, su movimiento lateral a menudo involucra plataformas de comunicaciones como SharePoint, JIRA, DocuSign y Slack, así como repositorios de documentos como Confluence. Si pueden acceder a GitHub u otros repositorios de código fuente, los actores de amenazas extraerán ese código fuente y lo analizarán en busca de vulnerabilidades dentro de una aplicación de destino. Intentarán explotar estas vulnerabilidades para extraer los datos de la aplicación de destino. El informe de inteligencia de amenazas de AppOmni también informa que la filtración de datos mediante el intercambio de permisos sigue siendo un grave problema de seguridad de SaaS. Esto ocurre, por ejemplo, en Google Workspace cuando el usuario no autorizado cambia de directorio a un nivel de permisos muy abierto. El atacante puede compartirlos con otra entidad externa mediante el reenvío de correo electrónico o cambiando reglas condicionales para que los atacantes se incluyan como destinatarios BCC en una lista de distribución. ¿Cómo protege sus entornos SaaS? 1. Centrarse en la higiene de los sistemas SaaS Establezca un proceso de admisión y revisión de SaaS para determinar qué SaaS permitirá en su empresa. Este proceso debería requerir respuestas a preguntas de seguridad como: ¿Todos los SaaS deben tener certificación SOC 2 Tipo 2? ¿Cuál es la configuración de seguridad óptima para cada inquilino? ¿Cómo evitará su empresa la desviación de la configuración? ¿Cómo determinará si las actualizaciones automáticas de SaaS requerirán modificar la configuración de control de seguridad? Asegúrese de poder detectar Shadow IT SaaS (o aplicaciones SaaS no autorizadas) y tener un programa de respuesta para que las alertas no se creen en vano. Si no supervisa a sus inquilinos de SaaS y no incorpora todos sus registros con algún método unificado, nunca podrá detectar comportamientos sospechosos ni recibir alertas basadas en ellos. 2. Realizar un inventario y monitorear continuamente las cuentas/identidades de las máquinas. Los actores de amenazas apuntan a las identidades de las máquinas por su acceso privilegiado y estándares de autenticación laxos, y a menudo rara vez requieren MFA. En 2023, los actores de amenazas atacaron y violaron con éxito las principales herramientas de CI/CD, Travis CI, CircleCI y Heroku. , robando tokens de OAuth para todos los clientes de estos proveedores. En estas situaciones, el radio de la explosión se amplía considerablemente. Dado que una empresa promedio contiene 256 identidades de máquinas, a menudo falta higiene. Muchos de ellos se utilizan una o dos veces y luego permanecen estancados durante años. Haga un inventario de todas las identidades de sus máquinas y clasifique estos riesgos críticos. Una vez que los haya mitigado, cree políticas que prescriban: A qué tipo de cuentas se les otorgarán identidades de máquina y los requisitos que estos proveedores deben cumplir para obtener acceso. El período de tiempo durante el cual sus accesos/tokens están activos antes de que sean revocados, actualizados o concedidos nuevamente. Cómo supervisará el uso de estas cuentas y se asegurará de que sigan siendo necesarias si experimentan períodos de inactividad. 3. Cree una verdadera arquitectura Zero Trust en su patrimonio SaaS. La arquitectura Zero Trust se basa en el principio de privilegio mínimo (PLP) con un enfoque de «nunca confiar, siempre verificar». Si bien Zero Trust se ha establecido en redes tradicionales, rara vez se logra en entornos SaaS. El enfoque centrado en la red de Zero Trust Network Access (ZTNA) no puede detectar configuraciones erróneas, integraciones de máquinas o derechos de acceso de usuarios no deseados dentro y hacia las plataformas SaaS, que pueden tener miles o incluso millones de usuarios externos accediendo a los datos. Zero Trust Posture Management (ZTPM), una herramienta de seguridad SaaS emergente, extiende Zero Trust a su patrimonio SaaS. Cierra la brecha de seguridad de SaaS que crea SASE al: Prevenir la omisión no autorizada de ZTNA. Permitir decisiones de acceso afinadas. Hacer cumplir sus políticas de seguridad con ciclos de retroalimentación continuos. Extender Zero Trust a integraciones de máquinas y conexiones en la nube. Con SSPM, ZTPM y un programa de seguridad SaaS en En este lugar, su equipo obtendrá la visibilidad y la inteligencia que necesita para identificar intrusos en las etapas de bajo riesgo de su cadena de destrucción y detenerlos antes de que una infracción se vuelva devastadora. ¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en Twitter  y LinkedIn para leer más contenido exclusivo que publicamos.

28 de junio de 2024Sala de prensaSeguridad industrial / Infraestructura crítica Se han revelado múltiples fallas de seguridad en los cromatógrafos de gases Emerson Rosemount que podrían ser explotadas por actores maliciosos para obtener información confidencial, inducir una condición de denegación de servicio (DoS) e incluso ejecutar comandos arbitrarios. Las fallas afectan a GC370XA, GC700XA y GC1500XA y residen en las versiones 4.1.5 y anteriores. Según la empresa de seguridad de tecnología operativa (OT) Claroty, las vulnerabilidades incluyen dos fallas de inyección de comandos y dos vulnerabilidades de autenticación y autorización independientes que podrían ser utilizadas por atacantes no autenticados para realizar una amplia gama de acciones maliciosas que van desde la omisión de la autenticación hasta la inyección de comandos. «La explotación exitosa de estas vulnerabilidades podría permitir que un atacante no autenticado con acceso a la red ejecute comandos arbitrarios, acceda a información confidencial, provoque una condición de denegación de servicio y evite la autenticación para adquirir capacidades de administrador», dijo la Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos (CISA) en un aviso publicado en enero. El cromatógrafo, que se utiliza para realizar mediciones críticas de gases, se puede configurar y administrar mediante un software llamado MON. El software también se puede utilizar para almacenar datos críticos y generar informes como cromatogramas, historial de alarmas, registros de eventos y registros de mantenimiento. El análisis de Claroty del firmware y el protocolo propietario utilizado para las comunicaciones entre el dispositivo y el cliente de Windows llamado MON2020 ha revelado las siguientes deficiencias: CVE-2023-46687 (puntuación CVSS: 9,8): un usuario no autenticado con acceso a la red podría ejecutar comandos arbitrarios en el contexto raíz desde una computadora remota CVE-2023-49716 (puntuación CVSS: 6,9): un usuario autenticado con acceso a la red podría ejecutar comandos arbitrarios desde una computadora remota CVE-2023-51761 (puntuación CVSS: 8,3): un usuario no autenticado con acceso a la red podría eludir la autenticación y adquirir capacidades de administrador restableciendo la contraseña asociada CVE-2023-43609 (puntuación CVSS: 6,9): un usuario no autenticado con acceso a la red podría obtener acceso a información confidencial o provocar una condición de denegación de servicio Tras una divulgación responsable, Emerson ha publicado [PDF] una versión actualizada del firmware que soluciona las vulnerabilidades. La empresa también recomienda a los usuarios finales que sigan las mejores prácticas de ciberseguridad y se aseguren de que los productos afectados no estén expuestos directamente a Internet. La revelación se produce cuando Nozomi Networks detalló varias fallas en AiLux RTU62351B que podrían usarse para acceder a recursos confidenciales en el dispositivo, alterar su configuración e incluso lograr la ejecución de comandos arbitrarios como root. Las vulnerabilidades se han denominado colectivamente I11USION. También se han identificado fallas en los dispositivos de monitoreo de temperatura Proges Plus y su software asociado, a saber, Sensor Net Connect y Thermoscan IP, que podrían permitir privilegios de administrador sobre sistemas médicos críticos, lo que hace posible que un actor malintencionado manipule la configuración del sistema, instale malware y exfiltre datos. Estas vulnerabilidades, que siguen sin parchearse, también podrían resultar en una condición de DoS de la infraestructura de monitoreo médico, lo que lleva al deterioro de medicamentos y vacunas sensibles a la temperatura. ¿Te resultó interesante este artículo? Síguenos en Twitter  y LinkedIn para leer más contenido exclusivo que publicamos.

Investigadores de ciberseguridad han revelado una falla de seguridad de alta gravedad en la biblioteca Vanna.AI que podría explotarse para lograr una vulnerabilidad de ejecución remota de código mediante técnicas de inyección rápida. La vulnerabilidad, rastreada como CVE-2024-5565 (puntaje CVSS: 8.1), se relaciona con un caso de inyección rápida en la función «preguntar» que podría explotarse para engañar a la biblioteca para que ejecute comandos arbitrarios, dijo la firma de seguridad de la cadena de suministro JFrog. Vanna es una biblioteca de aprendizaje automático basada en Python que permite a los usuarios chatear con su base de datos SQL para obtener información «simplemente haciendo preguntas» (también conocidas como indicaciones) que se traducen a una consulta SQL equivalente utilizando un modelo de lenguaje grande (LLM). La rápida implementación de modelos de inteligencia artificial (IA) generativa en los últimos años ha puesto de relieve los riesgos de explotación por parte de actores maliciosos, que pueden convertir las herramientas en armas proporcionando entradas adversas que eluden los mecanismos de seguridad integrados en ellas. Una de esas clases destacadas de ataques es la inyección rápida, que se refiere a un tipo de jailbreak de IA que puede usarse para ignorar las barreras erigidas por los proveedores de LLM para evitar la producción de contenido ofensivo, dañino o ilegal, o llevar a cabo instrucciones que violen el objetivo previsto. propósito de la aplicación. Dichos ataques pueden ser indirectos, en los que un sistema procesa datos controlados por un tercero (por ejemplo, correos electrónicos entrantes o documentos editables) para lanzar una carga útil maliciosa que conduce a una fuga de IA. También pueden tomar la forma de lo que se llama jailbreak de muchos disparos o jailbreak de múltiples turnos (también conocido como Crescendo) en el que el operador «comienza con un diálogo inofensivo y dirige progresivamente la conversación hacia el objetivo prohibido previsto». Este enfoque se puede ampliar aún más para realizar otro novedoso ataque de jailbreak conocido como Skeleton Key. «Esta técnica de jailbreak de IA funciona mediante el uso de una estrategia de múltiples turnos (o múltiples pasos) para hacer que un modelo ignore sus barreras de seguridad», dijo Mark Russinovich, director de tecnología de Microsoft Azure. «Una vez que se ignoran las barreras de seguridad, un modelo no podrá determinar solicitudes maliciosas o no autorizadas de ningún otro». Skeleton Key también se diferencia de Crescendo en que una vez que el jailbreak es exitoso y se cambian las reglas del sistema, el modelo puede crear respuestas a preguntas que de otro modo estarían prohibidas, independientemente de los riesgos éticos y de seguridad involucrados. «Cuando el jailbreak de Skeleton Key tiene éxito, un modelo reconoce que ha actualizado sus pautas y posteriormente cumplirá con las instrucciones para producir cualquier contenido, sin importar cuánto viole sus pautas originales de IA responsable», dijo Russinovich. «A diferencia de otros jailbreaks como Crescendo, donde se debe preguntar a los modelos sobre las tareas indirectamente o con codificaciones, Skeleton Key pone a los modelos en un modo en el que un usuario puede solicitar tareas directamente. Además, la salida del modelo parece no estar completamente filtrada y revela el alcance de el conocimiento o la capacidad de un modelo para producir el contenido solicitado». Los últimos hallazgos de JFrog –también divulgados de forma independiente por Tong Liu– muestran cómo las inyecciones rápidas podrían tener graves impactos, particularmente cuando están vinculadas a la ejecución de una orden. CVE-2024-5565 aprovecha el hecho de que Vanna facilita la generación de texto a SQL para crear consultas SQL, que luego se ejecutan y se presentan gráficamente a los usuarios utilizando la biblioteca de gráficos Plotly. Esto se logra mediante una función «preguntar», por ejemplo, vn.ask («¿Cuáles son los 10 principales clientes por ventas?»), que es uno de los principales puntos finales de API que permite ejecutar consultas SQL en la base de datos. El comportamiento antes mencionado, junto con la generación dinámica del código Plotly, crea un agujero de seguridad que permite a un actor de amenazas enviar un mensaje especialmente diseñado que incorpora un comando para ejecutarse en el sistema subyacente. «La biblioteca Vanna utiliza una función de aviso para presentar al usuario resultados visualizados, es posible alterar el aviso usando la inyección de aviso y ejecutar código Python arbitrario en lugar del código de visualización deseado», dijo JFrog. «Específicamente, permitir la entrada externa al método ‘preguntar’ de la biblioteca con ‘visualizar’ configurado en Verdadero (comportamiento predeterminado) conduce a la ejecución remota de código». Tras una divulgación responsable, Vanna ha publicado una guía de refuerzo que advierte a los usuarios que la integración de Plotly podría usarse para generar código Python arbitrario y que los usuarios que expongan esta función deben hacerlo en un entorno de espacio aislado. «Este descubrimiento demuestra que los riesgos del uso generalizado de GenAI/LLM sin una gobernanza y seguridad adecuadas pueden tener implicaciones drásticas para las organizaciones», dijo en un comunicado Shachar Menashe, director senior de investigación de seguridad de JFrog. «Los peligros de la inyección rápida todavía no son muy conocidos, pero son fáciles de ejecutar. Las empresas no deberían confiar en la estimulación previa como mecanismo de defensa infalible y deberían emplear mecanismos más sólidos al conectar los LLM con recursos críticos como bases de datos o dinámicas. codigo de GENERACION.» ¿Encontró interesante este artículo? Síguenos en Twitter  y LinkedIn para leer más contenido exclusivo que publicamos.