Raspberry Robin distribuido a través de archivos de script de Windows

Los actores de amenazas que distribuyen Raspberry Robin ahora utilizan Windows Script Files (WSF) para propagar el gusano junto con otros métodos, como unidades USB.

HP Threat Research identificó nuevas campañas a partir de marzo de 2024 en las que Raspberry Robin se propagaba a través de archivos de script de Windows altamente ofuscados, utilizando técnicas antianálisis.

Raspberry Robin es un gusano de Windows descubierto por primera vez en 2021. Inicialmente, los actores de amenazas que dependían del gusano lo propagaban a hosts objetivo utilizando medios extraíbles como unidades USB.

A lo largo de los años, los actores de amenazas han utilizado otros vectores de ataque, incluidos archivos comprimidos (.rar, .zip) y anuncios maliciosos, para distribuir el gusano.

En marzo, los piratas informáticos comenzaron a difundirlo a través de Windows Script Files, un tipo de archivo utilizado generalmente por administradores y software legítimo para automatizar tareas dentro de Windows.

Compartieron sus hallazgos en un informe publicado el 10 de abril de 2024.

Decodificando la distribución FSM de Raspberry Robin  

El formato de archivo .wsf admite lenguajes de secuencias de comandos, como JScript y VBScript, que son interpretados por el componente Windows Script Host integrado en el sistema operativo Windows.

Los archivos de script de Windows se ofrecen para descargar a través de varios dominios y subdominios maliciosos controlados por los atacantes.

Aunque no está claro cómo los actores de amenazas atraen a los usuarios a las URL maliciosas, los investigadores de amenazas de HP creen que esto podría deberse a través de spam o campañas de publicidad maliciosa.

El archivo de script actúa como un descargador y utiliza varias técnicas de detección de máquinas virtuales (VM) y antianálisis.

La carga útil final solo se descarga y ejecuta cuando todos estos pasos de evaluación indican que el malware se está ejecutando en un dispositivo real, en lugar de en una zona de pruebas.

El malware también busca los siguientes proveedores de software de seguridad:

• Kaspersky
• ESET
• avast
• Avira
• Punto de control
• Bitdefender

Los investigadores evaluaron que, en el momento del análisis, ningún escáner antivirus de VirusTotal clasificaba esos archivos como maliciosos, lo que demuestra la evasión del malware.

Descargador Raspberry Robin WSF con una tasa de detección del 0% en VirusTotal. Fuente: Investigación de amenazas de HP

“El descargador de WSF está muy ofuscado y utiliza muchas técnicas anti-análisis y anti-VM, lo que permite que el malware evada la detección y ralentice el análisis. Esto es particularmente preocupante dado que Raspberry Robin se ha utilizado como precursor del ransomware operado por humanos. Contrarrestar este malware en las primeras etapas de su cadena de infección debería ser una alta prioridad para los equipos de seguridad”, concluyeron los investigadores.

Fuente: https://www.infosecurity-magazine.com/news/raspberry-robin-windows-script/

Por qué los MLBOM son útiles para proteger la cadena de suministro de IA/ML

 Por qué los MLBOM son útiles para proteger la cadena de suministro de IA/ML

Un marco de lista de materiales de aprendizaje automático (MLBOM) puede aportar transparencia, auditabilidad, control y conocimiento forense de las cadenas de suministro de IA y ML.

Los días de las aplicaciones grandes y monolíticas se están desvaneciendo. Las aplicaciones actuales dependen de microservicios y reutilización de código, lo que facilita el desarrollo pero crea complejidad cuando se trata de rastrear y administrar los componentes que utilizan. 

Es por eso que la  lista de materiales de software (SBOM)  se ha convertido en una herramienta indispensable para identificar lo que hay en una aplicación de software, incluidos los componentes, las versiones y las dependencias que residen dentro de los sistemas. Los SBOM también brindan información detallada sobre las dependencias, vulnerabilidades y riesgos que influyen en la ciberseguridad.

Un SBOM permite a los CISO y otros líderes empresariales centrarse en lo que realmente importa al proporcionar un inventario actualizado de componentes de software. Esto hace que sea más fácil establecer y hacer cumplir una gobernanza sólida y detectar problemas potenciales antes de que se salgan de control.

Sin embargo, en la era de la inteligencia artificial (IA), el SBOM clásico tiene algunas limitaciones. Los marcos emergentes de aprendizaje automático (ML) presentan oportunidades notables, pero también amplían los límites del riesgo e introducen un nuevo activo para las organizaciones: el modelo de aprendizaje automático. Sin una supervisión y controles estrictos sobre estos modelos,   pueden surgir  una serie de problemas prácticos, técnicos y legales.

Ahí es donde las listas de materiales de aprendizaje automático (MLBOM) entran en escena. El marco rastrea nombres, ubicaciones, versiones y licencias de los activos que componen un modelo de ML. También incluye información general sobre la naturaleza del modelo, configuraciones de entrenamiento integradas en los metadatos, quién es el propietario, varios conjuntos de características, requisitos de hardware y más.

Por qué son importantes las MLBOM

Los CISO se están dando cuenta de que la IA y el ML requieren un modelo de seguridad diferente, y los datos de entrenamiento subyacentes y los modelos que los ejecutan con frecuencia no son rastreados ni gobernados. Un MLBOM puede ayudar a una organización a evitar riesgos y fallas de seguridad. Aborda factores críticos como la procedencia del modelo y los datos, las calificaciones de seguridad y los cambios dinámicos que se extienden más allá del alcance de SBOM.

Debido a que los entornos de aprendizaje automático están en un estado de cambio constante y los cambios pueden ocurrir con poca o ninguna interacción humana, los problemas relacionados con la coherencia de los datos (incluido dónde se originaron, cómo se limpiaron y cómo se etiquetaron) son una preocupación constante.

Por ejemplo, si un analista de negocios o un científico de datos determina que un conjunto de datos está envenenado, MLBOM simplifica la tarea de encontrar todos los puntos de contacto y modelos que se entrenaron con esos datos. 

Los MLBOM pueden elevar la protección

La transparencia, la auditabilidad, el control y el conocimiento forense son características distintivas de una MLBOM. Con una visión integral de los "ingredientes" que forman parte de un modelo de ML, una organización está equipada para gestionar sus modelos de ML de forma segura.

A continuación se muestran algunas formas de crear un marco de mejores prácticas en torno a un MLBOM:

• Reconocer la necesidad de un MLBOM:  no es ningún secreto que el aprendizaje automático impulsa la innovación empresarial e incluso la disrupción. Sin embargo, también introduce riesgos importantes que pueden extenderse a la reputación, el cumplimiento normativo y cuestiones legales. Tener visibilidad de los modelos de ML es de vital importancia.

• Llevar a cabo la debida diligencia esencial:  una MLBOM debe integrarse con el proceso de CI/CD y ofrecer un alto nivel de claridad. La compatibilidad con marcos estándar como JSON o  CycloneDX de OWASP  puede unificar los procesos SBOM y MLBOM.

• Analice políticas, procesos y gobernanza:  es esencial sincronizar un MLBOM con los flujos de trabajo y los procesos comerciales de una organización. Esto aumenta las probabilidades de que los canales de ML funcionen según lo previsto, al tiempo que minimiza los riesgos relacionados con la ciberseguridad, la privacidad de los datos, el cumplimiento y otras áreas asociadas a los riesgos.

• Utilice un MLBOM con puertas de aprendizaje automático:  controles y puertas de enlace rigurosos conducen a barreras de seguridad esenciales para IA y aprendizaje automático. De esta manera, la empresa y el CSO pueden aprovechar los éxitos y aprovechar el aprendizaje automático para desbloquear mayores ahorros de costos, ganancias de rendimiento y valor comercial.

El aprendizaje automático está cambiando radicalmente el panorama empresarial y de TI. Al extender las metodologías SBOM probadas al ML a través de MLBOM, es posible dar un paso de gigante hacia impulsar el rendimiento del aprendizaje automático y proteger los datos y los activos.

Fuente: https://www.darkreading.com/vulnerabilities-threats/mlboms-are-useful-for-securing-ai-ml-supply-chain

PALO ALTO NETWORKS CORRIGIÓ MÚLTIPLES ERRORES DOS EN SUS FIREWALLS

 

PALO ALTO NETWORKS CORRIGIÓ MÚLTIPLES ERRORES DOS EN SUS FIREWALLS

Palo Alto Networks solucionó varias vulnerabilidades en su sistema operativo PAN-OS, incluidos tres problemas que pueden desencadenar una condición DoS en sus firewalls.

Palo Alto Networks lanzó actualizaciones de seguridad para abordar varias vulnerabilidades de alta gravedad en su sistema operativo PAN-OS.

La empresa solucionó las siguientes vulnerabilidades DoS:

CVE-2024-3385 : la compañía informó que un mecanismo de procesamiento de paquetes en el software PAN-OS de Palo Alto Networks permite a un atacante remoto reiniciar los firewalls basados ​​en hardware. Los ataques repetidos pueden eventualmente desencadenar una condición DoS al forzar al firewall a entrar en modo de mantenimiento, lo que requiere intervención manual para restaurar la funcionalidad en línea. Este problema afecta a los modelos de firewall de hardware de la serie PA-5400 y a los firewalls de la serie PA-7000 cuando la seguridad GTP está deshabilitada. 

“Palo Alto Networks no tiene conocimiento de ninguna explotación maliciosa de este problema. Esto lo encontraron dos clientes en un uso de producción normal”. lee el aviso.

Otra vulnerabilidad DoS en PAN-OS abordada por el proveedor se rastrea como CVE-2024-3384.

Un atacante remoto puede desencadenar la falla al reiniciar los firewalls PAN-OS al recibir paquetes de Windows New Technology LAN Manager (NTLM) desde servidores Windows. Los ataques repetidos pueden eventualmente desencadenar una condición DoS al forzar al firewall a entrar en modo de mantenimiento, lo que requiere intervención manual para restaurar la funcionalidad en línea.

La falla afecta solo a las configuraciones PAN-OS con la autenticación NTLM habilitada.

La tercera vulnerabilidad DoS abordada por el proveedor se rastrea como CVE-2024-3382 .

“Existe una fuga de memoria en el software PAN-OS de Palo Alto Networks que permite a un atacante enviar una ráfaga de paquetes manipulados a través del firewall que eventualmente impide que el firewall procese el tráfico. Este problema se aplica sólo a los dispositivos de la serie PA-5400 que ejecutan el software PAN-OS con la función SSL Forward Proxy habilitada”. lee el aviso .

Palo Alto Networks también solucionó una vulnerabilidad de cambio de membresía de grupo incorrecto en Cloud Identity Engine (CIE). El problema de PAN-OS rastreado como CVE-2024-3383 "afecta el acceso de los usuarios a los recursos de la red donde a los usuarios se les puede negar o permitir de manera inapropiada el acceso a los recursos según las reglas de su política de seguridad existente".

El proveedor no tiene conocimiento de ataques en la naturaleza que aprovechen cualquiera de estas vulnerabilidades.

Fuente: https://securityaffairs.com/161724/security/palo-alto-networks-pan-os-dos-2.html

 

PyPI de Python revela sus secretos

GitGuardian es famoso por su informe anual State of Secrets Sprawl . En su informe de 2023, encontraron más de 10 millones de contraseñas, claves API y otras credenciales expuestas en confirmaciones públicas de GitHub. Las conclusiones de su informe de 2024 no solo destacaron 12,8 millones de nuevos secretos expuestos en GitHub, sino también una cantidad en el popular repositorio de paquetes Python PyPI .

PyPI, abreviatura de Python Package Index, alberga más de 20 terabytes de archivos que están disponibles gratuitamente para su uso en proyectos de Python. Si alguna vez escribió pip install [nombre del paquete], probablemente extrajo ese paquete de PyPI. Mucha gente también lo usa. Ya sea GitHub, PyPI u otros, el informe afirma que "los paquetes de código abierto representan aproximadamente el 90% del código que se ejecuta en producción hoy en día " . Es fácil ver por qué es entonces cuando estos paquetes ayudan a los desarrolladores a evitar la reinvención de millones. de ruedas todos los días.

En el informe de 2024, GitGuardian informó haber encontrado más de 11.000 secretos únicos expuestos , de los cuales 1.000 se agregaron a PyPI en 2023. Eso no es mucho en comparación con los 12,8 millones de nuevos secretos agregados a GitHub en 2023, pero GitHub es órdenes de magnitud mayor.

Un hecho más preocupante es que, de los secretos introducidos en 2017, casi 100 seguían siendo válidos 6 o 7 años después. No tenían la capacidad de comprobar la validez de todos los secretos. Aun así, se descubrieron más de 300 secretos únicos y válidos. Si bien esto es levemente alarmante para el observador casual y no necesariamente una amenaza para los desarrolladores aleatorios de Python (a diferencia de los 116 paquetes maliciosos reportados por ESET a fines de 2023), es una amenaza de magnitud desconocida para los propietarios de esos paquetes.

Si bien GitGuardian tiene cientos de detectores de secretos, que ha desarrollado y perfeccionado a lo largo de los años, algunos de los secretos más comunes que detectó en su estudio general de 2023 fueron las claves API de OpenAI, las claves API de Google y las claves de Google Cloud. No es difícil para un programador competente escribir una expresión regular para encontrar un formato secreto único y común. E incluso si arrojara muchos falsos positivos, automatizar las comprobaciones para determinar si eran válidos podría ayudar al desarrollador a encontrar un pequeño tesoro de secretos explotables.

Ahora es una lógica aceptada que si una clave se ha publicado en un repositorio público como GitHub o PyPI, debe considerarse comprometida. En las pruebas, los robots probaron la validez de los Honeytokens (una especie de clave API "descolgada" sin acceso a ningún recurso) un minuto después de su publicación en GitHub. De hecho, los Honeytokens actúan como un "canario" para un número cada vez mayor de desarrolladores. Dependiendo de dónde haya colocado un token de miel específico, puede ver que alguien ha estado husmeando allí y obtener información sobre ellos en función de los datos de telemetría recopilados cuando se usa el token de miel.

La mayor preocupación cuando se publica accidentalmente un secreto no es sólo que un actor malintencionado pueda aumentar su factura de la nube. Es a donde pueden ir desde allí. Si se filtrara un token de AWS IAM con permisos excesivos, ¿qué podría encontrar ese actor malicioso en los depósitos o bases de datos de S3 a los que otorga acceso? ¿Podría ese actor malicioso obtener acceso a otro código fuente y corromper algo que será entregado a muchos otros?

Ya sea que estés guardando secretos en GitHub, PyPI, NPM o cualquier colección pública de código fuente, el mejor primer paso cuando descubres que se ha filtrado un secreto es revocarlo. Recuerde esa pequeña ventana entre la publicación y la explotación de un token de miel. Una vez que se ha publicado un secreto, es probable que haya sido copiado. Incluso si no ha detectado un uso no autorizado, debe asumir que alguien no autorizado y malicioso ahora lo tiene.

Incluso si su código fuente está en un repositorio privado, abundan las historias de actores maliciosos que obtienen acceso a repositorios privados mediante ingeniería social, phishing y, por supuesto, secretos filtrados. Si hay una lección en todo esto, es que los secretos de texto plano en el código fuente eventualmente se descubren. Ya sea que se publiquen accidentalmente en público o que alguien con acceso que no debería tener los encuentre, los encontrará.

En resumen, dondequiera que almacene o publique su código fuente, ya sea un repositorio privado o un registro público, debe seguir algunas reglas simples:

1. No almacene secretos en texto plano en el código fuente.
2. Evite que aquellos que se apoderan de un secreto vayan a una expedición manteniendo estrictamente los privilegios que esos secretos otorgan.
3. Si descubre que filtró un secreto, revoquelo. Es posible que necesite tomarse un poco de tiempo para asegurarse de que sus sistemas de producción tengan el secreto nuevo y revelado para la continuidad del negocio, pero revocarlo tan pronto como sea posible.
4. Implemente automatizaciones como las que ofrece GitGuardian para asegurarse de no depender de humanos imperfectos para observar perfectamente las mejores prácticas en torno a la gestión de secretos.

Si los sigue, es posible que no tenga que aprender las lecciones que 11.000 propietarios de secretos probablemente hayan aprendido de la manera más difícil al publicarlos en PyPI.

Fuente: https://thehackernews.com/2024/04/gitguardian-report-pypi-secrets.html