5 Prácticas recomendadas para proteger los sistemas de gestión de acceso e identidad (IAM)

El término “gestión de identidad y acceso” o “IAM” se refiere a un marco de procedimientos corporativos, regulaciones y tecnología que respaldan la gestión de identidades digitales para garantizar que los usuarios solo obtengan acceso a los datos cuando tengan las credenciales correctas. La gestión de acceso e identidad se abrevia como “IAM”. Además de los usuarios reales, IAM también cubre cuentas de servicio y cuentas del sistema, las cuales son muy importantes para IAM administradores para manejar dentro de sus respectivos negocios. Es esencial realizar un inventario, una auditoría y un control frecuentes de todas estas identidades y el acceso que tienen para garantizar que se lleva a cabo una gestión eficaz de la identidad y el acceso, incluidos los permisos y el estado activo. Manejar la complejidad cada vez mayor de las identidades digitales puede ser una tarea difícil, particularmente considerando el impulso de los negocios hacia la nube y los entornos informáticos híbridos. A pesar de esto, la necesidad de gestión de acceso e identidad es más vital ahora que nunca. Durante los últimos años,

Los ataques pueden provenir de una amplia variedad de fuentes, incluidos estados-nación, organizaciones terroristas, delincuentes organizados, hacktivistas y personas con la intención de dañar o robar información. Las organizaciones son vulnerables a este tipo de ataques y causan vergüenza a una empresa o grupo. Además, las empresas pueden ser objeto de ataques cuando un usuario de confianza es el responsable de poner en peligro los datos confidenciales (por ejemplo, una amenaza interna). Las habilidades, los objetivos y las estrategias utilizadas por la amplia gama de actores de amenazas son bastante diversas. Por ejemplo, los actores del estado-nación tienen enormes recursos a su disposición y pueden idear estrategias plurianuales para adquirir acceso a los recursos esenciales. Los enfoques indirectos, como aprovechar la cadena de suministro, son otra opción abierta para ellos.
Al hacer uso de fallas conocidas en IAM, un actor malintencionado puede obtener el mismo nivel de acceso a los recursos que los usuarios normales al imitar el comportamiento normal, lo que dificulta la identificación del actor malintencionado. Debido a esto, el actor malicioso tiene más tiempo para obtener acceso a los recursos y aumentar los privilegios para lograr un acceso permanente.
Por ejemplo, una advertencia CISA reciente (AA21-321A)4 reveló que los actores de amenazas persistentes avanzadas (APT) patrocinados por el gobierno iraní están persiguiendo agresivamente una amplia variedad de objetivos en varios sectores de infraestructura crítica de EE. UU. aprovechando las vulnerabilidades de IAM para comprometer las credenciales, eleve los privilegios y cree nuevas cuentas de usuario en controladores de dominio, servidores, estaciones de trabajo y en directorios responsables de autenticar y autorizar usuarios y dispositivos. Estos actores pueden usar este acceso para lanzar más ataques, como la exfiltración o el cifrado de datos confidenciales, la instalación de ransomware o la extorsión.

Las siguientes mejores prácticas y estrategias de mitigación de riesgos sugeridas por CISA brindan sugerencias que ayudan a combatir los peligros potenciales para el IAM al desalentarlo, prevenirlo, detectarlo, limitar el daño que causa y responder a él.

GOBERNANZA DE IDENTIDADES

El gobierno de la identidad puede definirse como el proceso mediante el cual una organización centraliza y orquesta la administración de sus cuentas de usuario y servicio de acuerdo con las reglas que ha establecido. El gobierno de la identidad ofrece a las empresas más información sobre las identidades de los usuarios y las credenciales de acceso que tienen, así como controles mejorados para identificar y evitar el acceso ilegal. Se compone de una colección de procedimientos y regulaciones que abordan la división de responsabilidades, la gestión de roles, el registro, la revisión de acceso, el análisis y la generación de informes.

ENDURECIMIENTO AMBIENTAL

Para fortalecer el entorno operativo de la empresa, primero se debe garantizar que las bases y las implementaciones de IAM se hayan protegido, garantizado y confiable de manera adecuada. El grado de endurecimiento requerido variará dependiendo de lo que se proteja. Por ejemplo, los sistemas de emisión de credenciales que proporcionan certificados digitales criptográficos o almacenes de contraseñas son más importantes, ya que garantizan la autenticación de toda una organización. La implementación de técnicas criptográficas también debe ser adecuada para garantizar el grado de seguridad que requiere el sistema y que se presume que existe.

LA COMBINACIÓN DE IDENTITY FEDERATION Y SINGLE SIGN-ON

La federación de identidades que emplea SSO dentro y/o entre empresas, incluido el empleo de proveedores de identidad, reduce los riesgos mediante la gestión centralizada de las variaciones en las políticas y los niveles de riesgo en las organizaciones y elimina la adopción generalizada y la dependencia de las identidades locales. Sin especificar oficialmente las reglas y los grados de confianza y seguridad entre organizaciones o entre diferentes proveedores de identidad dentro de una organización, una organización es vulnerable a ataques que se basan en fallas en cada sistema de administración de acceso de identidad federado. Al centralizar la administración y el control de la autenticación y el acceso a través de muchos sistemas y de numerosos proveedores de identidad, el inicio de sesión único (SSO) ofrece una capacidad para mitigar los riesgos. Si se implementa de manera efectiva,

UN SISTEMA DE AUTENTICACIÓN MULTIFACTOR

Los nombres de usuario y las contraseñas han sido los pilares principales de la autenticación de usuarios desde que surgieron los sistemas informáticos multiusuario. MFA significa autenticación de múltiples factores, y es un método que se utiliza para reforzar la seguridad del procedimiento de autenticación al obligar al usuario a proporcionar una serie de “factores” que se clasifican en una variedad de categorías. Los autenticadores para la autenticación multifactor (MFA) pueden implementarse como software que se instala en un teléfono móvil u otro dispositivo, o pueden implementarse como tokens de hardware especializados. Algunas soluciones de autenticación multifactor (MFA) están destinadas a fortalecer la seguridad de las contraseñas agregando un segundo elemento, mientras que otras, denominadas soluciones “sin contraseña”, tienen como objetivo eliminar por completo la necesidad de usar contraseñas. Las soluciones de autenticación multifactor (MFA) sin contraseña a menudo requieren el uso de dos factores en conjunto. Por ejemplo, una credencial criptográfica se puede almacenar en un token de hardware y el token se puede desbloquear usando un PIN memorizado.

SUPERVISIÓN Y AUDITORÍA DE IAM

La auditoría y el monitoreo de IAM no solo deben verificar el cumplimiento, sino que también deben observar indicadores de amenazas y acciones inusuales. Esto incluye el desarrollo, la recopilación y el análisis de registros, eventos y otra información para brindar los mejores métodos para descubrir transgresiones relacionadas con el cumplimiento y actividades sospechosas. Sin un programa eficiente de auditoría y monitoreo de IAM, las amenazas como la explotación del acceso privilegiado por parte de personas internas y el uso de credenciales robadas no se descubrirían de manera oportuna, si es que se descubrieron. Estas capacidades de auditoría y monitoreo pueden combinarse con herramientas automatizadas que coordinan las actividades de reacción para contrarrestar las amenazas contra el IAM.

Nueva campaña de phishing 0ktapus apunta a las credenciales de identidad de Okta y así funciona

El objetivo de este artículo fue ofrecer un conocimiento claro de cómo las diferentes mitigaciones combaten los riesgos y brindar consejos prácticos sobre lo que las empresas deben hacer ahora. Además, el estudio tuvo como objetivo proporcionar una comprensión clara de cómo varias mitigaciones contrarrestan las amenazas. Esto cubre lo siguiente:

• Realice una evaluación de sus capacidades IAM existentes y su posición frente al riesgo.
• Para aquellas partes del sistema que puedan necesitar algo de trabajo, elija, superponga, integre y configure adecuadamente soluciones seguras de acuerdo con los procedimientos recomendados descritos en este documento y en las recomendaciones citadas en él.
• Garantizar que se mantenga un grado adecuado de seguridad en todo momento para gestionar eficazmente el riesgo a lo largo de las operaciones en curso.
• Sea siempre consciente de la forma correcta de usar IAM y cualquier peligro potencial.

El cargo 5 Prácticas recomendadas para proteger los sistemas de gestión de acceso e identidad (IAM) apareció primero en Noticias de seguridad informática, ciberseguridad y hacking.

Ver Fuente

Vulnerabilidad de Apache Tomcat revela las cookies de sesión de aplicación a los atacantes

Uno de los servidores web más populares y ampliamente utilizados para Java es Apache Tomcat . Es pequeño, simple de instalar y muy agradable para construir aplicaciones web Java. También se puede usar para crear aplicaciones un poco más sofisticadas que la aplicación JSP convencional en línea, ya que puede incluir implementaciones JSF como MyFaces, Primefaces, RichFaces y otras (biblioteca estándar, definida en J2EE para el desarrollo de aplicaciones web dinámicas usando Java).

Todo esto es muy beneficioso y, de hecho, muchos desarrolladores de aplicaciones web lo utilizan en sus equipos para poder desarrollar rápidamente y poder centrarse en lo que realmente les interesa: asegurarse de que la lógica de sus páginas y clases Java funciona como debería. Todo esto es muy beneficioso. Realmente es así de sencillo… un desarrollador de software normalmente no se preocupa por la seguridad del servidor Tomcat que ha instalado en la computadora que su empleador le ha proporcionado. De hecho, el concepto de seguridad le resulta tan extraño que ni siquiera se le pasa por la cabeza muy a menudo. Los entornos de servidor web HTTP “Java puro” están disponibles mediante el servidor Apache Tomcat, que incorpora las tecnologías de Jakarta Servlet, Jakarta Expression Language y WebSocket. Estas tecnologías permiten ejecutar código Java en estos entornos. Debido a esto, es una opción elegida con frecuencia entre los desarrolladores que desean usar Java para crear aplicaciones en línea.

Falla en Apache Tomcat obliga al servidor a realizar ataques DoS contra sí mismo y contra la red

Se ha determinado que hasta las versiones 8.5.85/9.0.71/10.1.5/11.0.0-M2 inclusive de Apache Tomcat tienen una vulnerabilidad que se ha calificado como problemática (software de servidor de aplicaciones). Una característica no identificada del componente conocido como RemoteIpFilter Handler está rota como resultado de este error. La manipulación con una entrada desconocida da como resultado una vulnerabilidad que implica la transmisión no segura de credenciales. El nombre de usuario y la contraseña no están adecuadamente protegidos cuando se envían desde el cliente al servidor a través de las páginas de inicio de sesión, que no utilizan las medidas de seguridad adecuadas.

Las cookies de sesión generadas por Apache Tomcat versiones 11.0.0-M1 a 11.0.0.-M2, 10.1.0-M1 a 10.1.5, 9.0.0-M1 a 9.0.71 y 8.5.0 a 8.5.85 no se incluyen el atributo seguro cuando se usa junto con las solicitudes recibidas de un proxy inverso a través de HTTP y que tenían el encabezado X-Forwarded-Proto establecido en https. Debido a esto, el agente de usuario podría enviar la cookie de sesión a través de una conexión no segura. Por lo tanto, esto podría ser peligroso.

La vulnerabilidad se reveló el 22 de marzo de 2023. El aviso ahora está disponible para descargar enlists.apache.org, donde también se comparte. Desde el 21 de marzo de 2023, esta vulnerabilidad tiene asignado el identificador CVE-2023-28708. No hay una descripción técnica ni un exploit que sea de fácil acceso para el público. El método de ataque recibió la designación de T1557 por el proyecto MITRE ATT&CK.

Esta vulnerabilidad puede solucionarse actualizando a la versión 8.5.86, 9.0.72, 10.1.6 o 11.0.0-M3, respectivamente.

El cargo Vulnerabilidad de Apache Tomcat revela las cookies de sesión de aplicación a los atacantes apareció primero en Noticias de seguridad informática, ciberseguridad y hacking.

Ver Fuente

¿Cómo fue hackeado el fabricante lider de cajeros automáticos de criptomonedas y se robaron millones de fondos?

General Bytes, un fabricante líder de cajeros automáticos (ATM) de criptomonedas, fue víctima de una brecha de seguridad que resultó en la pérdida de más de $1.5 millones en Bitcoin. General Bytes informó originalmente del evento en su cuenta oficial de Twitter. Según la empresa, los atacantes explotaron una vulnerabilidad en la interfaz de servicio principal que utilizan los cajeros automáticos de Bitcoin para enviar videos, lo que les permitió cargar un script de JavaScript y ejecutarlo con derechos de usuario de batm.

Según la firma, “el atacante buscó en el espacio de direcciones IP de alojamiento en la nube de Digital Ocean y descubrió servicios CAS operativos en los puertos 7741, incluido el servicio General Bytes Cloud y otros operadores de cajeros automáticos de GB que ejecutan sus servidores en Digital Ocean”.

Como resultado de la ejecución del código, los atacantes obtuvieron acceso a la base de datos, así como a las claves API para acceder al dinero en las carteras calientes y los intercambios. El atacante aprovechó la interfaz de servicio maestro para cargar de forma remota un programa Java, obteniendo acceso a los derechos de usuario de BATM, la base de datos y las claves API necesarias para acceder al dinero en las carteras e intercambios activos.

On March 17-18th, 2023, GENERAL BYTES experienced a security incident.

We released a statement urging customers to take immediate action to protect their personal information.

We urge all our customers to take immediate action to protect their funds and https://t.co/fajc61lcwR…

— GENERAL BYTES (@generalbytes) March 18, 2023

Como consecuencia, el pirata informático obtuvo acceso a los usuarios, hash de contraseñas, desactivó la verificación de dos factores y envió fondos desde billeteras calientes.

El pirata informático logró robar 56,28 bitcoins, con un valor de alrededor de $ 1,5 millones, así como liquidar otras criptomonedas, incluidas ETH, USDT, BUSD, ADA, DAI, DOGE, SHIB y TRX. Los activos robados no se han movido de la dirección de bitcoin desde el 18 de marzo y ciertas monedas digitales se han transferido a otros destinos, incluida una plataforma comercial descentralizada.

Además, los atacantes obtuvieron la “capacidad de acceder a los registros de eventos de la terminal y buscar cada ocurrencia cuando los usuarios escanearon la clave privada en el cajero automático”, información que registraron las versiones anteriores del software del cajero automático.

En venta datos personales de 350 mil pacientes de COVID-19 de México, Perú, Colombia y Argentina. A las empresas de desinfección o seguros médicos le interesará esta base de datos

“El 18 de marzo, recomendamos a todos nuestros clientes que tomen medidas rápidas para salvaguardar sus finanzas e información personal”, tuiteó General Bytes.

La firma ha revelado las direcciones de billetera y tres direcciones IP utilizadas por el atacante en la violación. Sin embargo, según ciertas fuentes, el nodo completo de la empresa es lo suficientemente seguro como para evitar el acceso no deseado al efectivo.

La empresa publicó información sobre las acciones que los clientes deben tomar para proteger sus servidores GB ATM (CAS) en un aviso de seguridad que documenta el evento, enfatizando que incluso aquellos que no se vieron afectados por el incidente deben adoptar las medidas de seguridad sugeridas.

“Por favor, mantenga su CAS protegido por un firewall y una VPN”. Los terminales también deben usar VPN para conectarse a CAS. Con una VPN/Firewall, los atacantes del Internet abierto no pueden acceder y explotar su servidor. Si su servidor se vio comprometido, reinstale todo el servidor, incluido el sistema operativo”, aconseja la empresa.

El fabricante de cajeros automáticos criptográficos emitió un parche de seguridad CAS y aconsejó a los consumidores que consideren todas las contraseñas de usuario y las claves API para los intercambios y las billeteras calientes como comprometidas y que las reemplacen. “Aún no tenemos las estadísticas finales”, dijo General Bytes. Actualmente estamos recopilando información de los operadores. Todavía estamos lidiando con daños de aproximadamente 56 BTC a partir de hoy.

El cargo ¿Cómo fue hackeado el fabricante lider de cajeros automáticos de criptomonedas y se robaron millones de fondos? apareció primero en Noticias de seguridad informática, ciberseguridad y hacking.

Ver Fuente

La nueva versión black del ransomware Lockbit es aún más destructiva y difícil de detectar

Un aviso conjunto de la Oficina Federal de Investigaciones (FBI), la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) y el Centro de Análisis e Intercambio de Información Multiestatal (MS-ISAC) tiene como objetivo distribuir información sobre indicadores conocidos de compromiso del ransomware LockBit 3.0. (IOC) y técnicas (TTP) que se descubrieron durante las investigaciones del FBI en marzo de 2023.

El ransomware LockBit 3.0 es una continuación de los programas de ransomware LockBit 2.0 y LockBit. Utiliza un modelo de Ransomware-as-a-Service (RaaS) para llevar a cabo sus actividades y funciones como un modelo RaaS. LockBit ha estado funcionando como una variante de ransomware basada en afiliados desde enero de 2020; los afiliados que implementan LockBit RaaS utilizan una amplia variedad de TTP para dirigirse a una amplia variedad de empresas y organizaciones de infraestructura crítica, lo que puede dificultar la defensa efectiva de las redes informáticas o mitigar sus efectos.

California golpeada por ciberataque de ransomware LockBit

LockBit 3.0, también conocido como “LockBit Black”, es una versión actualizada del ransomware que es más modular y escurridizo que sus versiones anteriores. También tiene características con el malware conocido como Blackmatter y Blackcat.

Durante el proceso de compilación, LockBit 3.0 se personaliza con una amplia variedad de variables, cada una de las cuales influye en la forma en que opera el ransomware. Durante el proceso de puesta en acción del ransomware dentro de un entorno que pertenece a una víctima, se pueden dar numerosos argumentos para ajustar aún más el comportamiento del malware. Por ejemplo, LockBit 3.0 permite la aceptación de argumentos adicionales para algunas acciones, como el movimiento lateral y el reinicio en modo seguro (consulte los parámetros de la línea de comandos de LockBit en Indicadores de compromiso). Si un afiliado de LockBit no tiene acceso al ransomware LockBit 3.0 sin contraseña, entonces la ejecución del ransomware necesitará el ingreso de un argumento de contraseña. Aquellos que están afiliados a LockBit 3.0 pero no ingresan la contraseña correcta no podrán llevar a cabo el ransomware. Una clave criptográfica, la contraseña se utiliza para decodificar el ejecutable LockBit 3.0. LockBit 3.0 puede evitar la detección y el análisis de malware cifrando el código de tal manera que sea indescifrable y no se pueda ejecutar. Esto hace que el código sea inútil para detectar y analizar malware. Dado que la poción cifrada del ejecutable de LockBit 3.0 cambiará según la clave criptográfica que se utilizó para el cifrado y, al mismo tiempo, se crea un hash único, es posible que las detecciones basadas en firmas no puedan identificar el ejecutable de LockBit 3.0. LockBit 3.0 descifrará el componente principal cuando se le proporcione la contraseña adecuada, luego continuará descifrando o descomprimiendo su código y finalmente ejecutará el ransomware. 0 es capaz de evitar la detección y el análisis de malware cifrando el código de tal manera que sea indescifrable y no se pueda ejecutar. Esto hace que el código sea inútil para detectar y analizar malware. Dado que la poción cifrada del ejecutable de LockBit 3.0 cambiará según la clave criptográfica que se utilizó para el cifrado y, al mismo tiempo, se crea un hash único, es posible que las detecciones basadas en firmas no puedan identificar el ejecutable de LockBit 3.0. LockBit 3.0 descifrará el componente principal cuando se le proporcione la contraseña adecuada, luego continuará descifrando o descomprimiendo su código y finalmente ejecutará el ransomware. 0 es capaz de evitar la detección y el análisis de malware cifrando el código de tal manera que sea indescifrable y no se pueda ejecutar. Esto hace que el código sea inútil para detectar y analizar malware. Dado que la poción cifrada del ejecutable de LockBit 3.0 cambiará según la clave criptográfica que se utilizó para el cifrado y, al mismo tiempo, se crea un hash único, es posible que las detecciones basadas en firmas no puedan identificar el ejecutable de LockBit 3.0. LockBit 3.0 descifrará el componente principal cuando se le proporcione la contraseña adecuada, luego continuará descifrando o descomprimiendo su código y finalmente ejecutará el ransomware. 0 cambiará dependiendo de la clave criptográfica que se usó para el cifrado mientras se crea simultáneamente un hash único, es posible que las detecciones basadas en firmas no puedan identificar el ejecutable LockBit 3.0. LockBit 3.0 descifrará el componente principal cuando se le proporcione la contraseña adecuada, luego continuará descifrando o descomprimiendo su código y finalmente ejecutará el ransomware. 0 cambiará dependiendo de la clave criptográfica que se usó para el cifrado mientras se crea simultáneamente un hash único, es posible que las detecciones basadas en firmas no puedan identificar el ejecutable LockBit 3.0. LockBit 3.0 descifrará el componente principal cuando se le proporcione la contraseña adecuada, luego continuará descifrando o descomprimiendo su código y finalmente ejecutará el ransomware.

LockBit 3.0 solo infectará equipos que no tengan una configuración de idioma que sea compatible con una lista de exclusión que se haya especificado. Un indicador de configuración que se estableció por primera vez en el momento de la compilación decidirá en última instancia si un idioma del sistema se verifica o no cuando realmente se usa en tiempo de ejecución. En la lista de idiomas que no se pueden usar no se limitan, pero incluyen, rumano (hablado en Moldavia), árabe (hablado en Siria) y tártaro (Rusia). LockBit 3.0 detendrá la ejecución si se encuentra un idioma de la lista de exclusión [T1614.001], pero no infectará el sistema.

Para disminuir el riesgo de ataques de ransomware y disminuir su gravedad cuando ocurren, el FBI, CISA y MS-ISAC aconsejan a las empresas que pongan en práctica las mitigaciones.

El cargo La nueva versión black del ransomware Lockbit es aún más destructiva y difícil de detectar apareció primero en Noticias de seguridad informática, ciberseguridad y hacking.

Ver Fuente

Vulnerabilidades de día cero permiten hackear teléfonos Samsung, Vivo y Pixel remotamente, solo con el número de la víctima

Se descubrió que los módems Exynos fabricados por Samsung Semiconductor tenían dieciocho vulnerabilidades de día cero, según lo revelado por Project Zero. La ejecución remota de código de Internet a banda base fue posible debido a las cuatro vulnerabilidades que se consideraron las más graves entre estas dieciocho fallas (CVE-2023-24033 y otras tres vulnerabilidades a las que aún no se les han asignado CVE-ID). Pruebas realizadas por Project Zero han demostrado que las cuatro vulnerabilidades antes mencionadas hacen posible que un atacante comprometa remotamente un teléfono a nivel de banda base sin ninguna interacción por parte del usuario; todo lo que se requiere es que el atacante conozca el número de teléfono de la víctima. Anticipamos que los adversarios altamente competentes podrían diseñar rápidamente un exploit operativo para comprometer los dispositivos afectados de manera sigilosa y remota si solo tuvieran acceso a modestos recursos adicionales de investigación y desarrollo.

Las otras catorce vulnerabilidades similares (CVE-2023-26072, CVE-2023-26073, CVE-2023-26074, CVE-2023-26075, CVE-2023-26076 y nueve vulnerabilidades adicionales a las que aún no se les han otorgado CVE-ID) no eran tan graves ya que necesitaban un operador de red móvil hostil o un atacante con acceso local al dispositivo.

La lista de conjuntos de chips Exynos que son susceptibles a estas vulnerabilidades se puede encontrar en el aviso publicado por Samsung Semiconductor. Según la información obtenida de fuentes públicas que proporcionan una asignación de chipsets a dispositivos, es probable que los siguientes dispositivos se vean afectados:

Dispositivos de las series S22, M33, M13, M12, A71, A53, A33, A21, A13, A12 y A04 de Samsung;

Dispositivos de las series S16, S15, S6, X70, X60 y X30 de Vivo

Dispositivos de las series Pixel 6 y Pixel 7 de Google

Cualquier dispositivo portátil que use el chipset Exynos W920 y vehículos que usen el chipset Exynos Auto T5123.

Los plazos para que los parches aborden estas vulnerabilidades diferirán según el fabricante. Mientras tanto, aquellos que tienen dispositivos que son vulnerables pueden protegerse de las vulnerabilidades de ejecución remota de código de banda base desactivando las llamadas Wi-Fi y Voice-over-LTE (VoLTE) en la configuración de sus dispositivos.

Debido a la combinación inusual del nivel de acceso que brindan estas vulnerabilidades y la velocidad a la que creen que se podría crear un exploit operativo confiable, el equipo de seguridad de Google decidió hacer una excepción a su política de divulgación estándar y retrasar la divulgación de la cuatro vulnerabilidades más severas. Esta decisión se tomó porque el equipo de seguridad de Google cree que se podría crear un exploit operativo confiable con relativa rapidez.

Sin embargo, mantendrán su tradición de apertura al publicar públicamente las exclusiones de la política de divulgación y, una vez que se hayan identificado todas las inquietudes, agregarán estos problemas a la lista. Cinco de las catorce vulnerabilidades restantes (CVE-2023-24072, CVE-2023-24073, CVE-2023-24074, CVE-2023-24075 y CVE-2023-24076) han superado el límite normal de 90 días de Project Zero y han sido revelado públicamente en su rastreador de problemas. Las otras nueve vulnerabilidades se divulgarán públicamente en ese momento si aún no se han solucionado.

Hackers descubren vulnerabilidades de día cero en el Samsung Galaxy S22

El equipo de seguridad de Google recomienda encarecidamente a los usuarios finales que actualicen sus dispositivos tan pronto como sea posible para garantizar que estén utilizando las versiones más recientes, que corrigen las fallas de seguridad que se han hecho públicas, así como las que no se han hecho públicas. hecho público. Es muy importante mantener la vigilancia y adoptar las medidas de seguridad adecuadas para salvaguardar la información personal y los dispositivos eléctricos de posibles riesgos de seguridad.

El cargo Vulnerabilidades de día cero permiten hackear teléfonos Samsung, Vivo y Pixel remotamente, solo con el número de la víctima apareció primero en Noticias de seguridad informática, ciberseguridad y hacking.

Ver Fuente

El nuevo malware de cryptojacking puede hackear clústeres de Kubernetes usando este sencillo truco

Dero es una criptomoneda relativamente nueva que pone un fuerte énfasis en la privacidad. Utiliza tecnología de gráficos acíclicos dirigidos (DAG), lo que le permite afirmar que sus transacciones son completamente anónimas. La combinación de anonimato y una mayor relación de recompensas lo hace potencialmente atractivo para las organizaciones de cryptojacking en comparación con Monero, que es la moneda que utilizan con mayor frecuencia los atacantes o grupos que realizan operaciones mineras. CrowdStrike ha descubierto la primera operación de cryptojacking de Dero dirigida a la infraestructura de Kubernetes . 

También se descubrió una operación de cryptojacking usando Monero; esta operación está al tanto del esfuerzo de Dero y está compitiendo activamente con él. La campaña de Monero extrae XMR en el host elevando sus privilegios mediante el uso de DaemonSets y montando el host como usuario raíz.

Los atacantes se dirigieron específicamente a los clústeres de Kubernetes que se ejecutan en puertos no estándar al escanear y ubicar los clústeres de Kubernetes vulnerables expuestos que tenían la configuración de autenticación —anonymous-auth=true. Esta configuración permite el acceso anónimo a la API de Kubernetes y fue el objetivo de la atención de los atacantes. Es posible que un usuario con acceso adecuado exponga por error una API segura de Kubernetes en el host donde opera kubectl ejecutando el comando “Proxy de Kubectl”. Este es un enfoque menos aparente para exponer el clúster seguro de Kubernetes sin autenticación. La interfaz de programación de aplicaciones del plano de control de Kubernetes no proporciona acceso anónimo listo para usar en Kubernetes. Sin embargo, dado que la elección de hacer seguro por defecto el valor predeterminado se retrasó,

LAS 8 MEJORES HERRAMIENTAS GRATUITAS PARA PRUEBAS DE SEGURIDAD Y AUDITORÍA DE SU CLUSTER DE KUBERNETES EN 2022

Después del primer compromiso con la API de Kubernetes, el atacante instalará a continuación un DaemonSet de Kubernetes con el nombre “proxy-api”. En cada nodo del clúster de Kubernetes, el DaemonSet instala un pod que contiene código malicioso. Esto facilita que los atacantes realicen una operación de cryptojacking utilizando simultáneamente los recursos de todos los nodos de la red. Los esfuerzos de minería que realizan las cápsulas se donan a un fondo comunitario. Este grupo luego divide la recompensa (en forma de moneda Dero) entre todos sus contribuyentes de manera equitativa a través de sus propias billeteras digitales.

Una vez que el grupo vulnerable de Kubernetes se vio comprometido, los atacantes no intentaron pivotar, ya sea moviéndose lateralmente para atacar recursos adicionales o escaneando Internet en busca de descubrimiento. Este es un patrón que es común entre muchas campañas de cryptojacking que se han observado en la naturaleza.

Además, los atacantes no intentaron eliminar ni interferir en el funcionamiento del clúster. En cambio, usaron un DaemonSet para minar Dero. El nombre del DaemonSet se disfrazó como “proxy-api”, y el nombre del minero fue “pausa”, las cuales son frases que se ven a menudo en los registros de Kubernetes.

Estos comportamientos dirigidos parecen definir el objetivo de esta campaña, que es que los atacantes solo buscan minar para Dero. Esta es la conclusión que se puede extraer de las acciones que se han llevado a cabo. Como resultado, tenemos razones para creer que un actor de cryptojacking impulsado por ganancias financieras es el responsable de esta iniciativa.

Los atacantes se han aprovechado del hecho de que Kubernetes se ha convertido en el orquestador de contenedores más popular del mundo para centrar su atención en configuraciones erróneas, fallas de diseño y vulnerabilidades de día cero dentro de Kubernetes y Docker.

El cargo El nuevo malware de cryptojacking puede hackear clústeres de Kubernetes usando este sencillo truco apareció primero en Noticias de seguridad informática, ciberseguridad y hacking.

Ver Fuente

Vulnerabilidades críticas en SAP con puntaje CVSS > 9.5

En su Security Patch Day de marzo de 2023 , el fabricante alemán de software corporativo SAP anunció un total de 19 nuevas notas de seguridad, cinco de las cuales fueron designadas como “críticas”. Las vulnerabilidades de seguridad en los productos de SAP son grandes objetivos para los actores de amenazas, ya que estos productos son ampliamente utilizados por grandes empresas de todo el mundo y pueden servir como puntos de entrada a sistemas increíblemente valiosos.

Con un total de 425.000 clientes en 180 países, SAP es, con mucho, el proveedor de software de planificación de recursos empresariales (ERP) más exitoso del mundo. Productos como ERP, SCM, PLM y CRM son utilizados por más del 90 por ciento de las empresas de Forbes Global 2000.

Para evitar el robo de datos, los ataques de ransomware y la interrupción de procesos y operaciones de misión crítica, la Agencia de Seguridad de Infraestructura y Ciberseguridad de los Estados Unidos (CISA) recomendó a los administradores en febrero de 2022 que corrigieran una serie de vulnerabilidades graves que afectan a las aplicaciones comerciales de SAP.

Una vulnerabilidad de corrupción de memoria en SAPOSCOL es una de las vulnerabilidades de alta gravedad que SAP ha parcheado. Otras vulnerabilidades de alta gravedad incluyen una vulnerabilidad de cruce de directorios en SAP NetWeaver AS para ABAP y ABAP Platform, un problema de falsificación de solicitud del lado del servidor (SSRF) en SAP NetWeaver AS para ABAP y ABAP Platform, y un problema con SAP NetWeaver AS para ABAP y Plataforma ABAP.

Una de las principales vulnerabilidades se llama CVE-2023-25616 y es una vulnerabilidad de inyección de código en SAP Business. El puntaje CVSS para este problema es 9.9.

Business Intelligence Platform (CMC) de objetos, que afecta a las versiones 420 y 430. La ejecución de un objeto de programa puede provocar una vulnerabilidad conocida como inyección de código, que le da al atacante la posibilidad de obtener acceso a recursos a los que solo se puede acceder con privilegios adicionales.

14 vulnerabilidades críticas corregidas en diferentes productos de SAP: Actualice pronto

El control de acceso incorrecto en SAP NetWeaver AS para Java ha sido citado como la causa de la segunda falla de seguridad grave, a la que se le asignó el identificador CVE-2023-23857 y recibió una puntuación CVSS de 9,9. Un atacante no autenticado puede aprovechar la vulnerabilidad conectándose a una interfaz abierta y utilizando una API abierta de nombres y directorios para obtener acceso a los servicios. Estos servicios se pueden usar para llevar a cabo operaciones no autorizadas que tienen un impacto en los usuarios y servicios en múltiples sistemas. En caso de que el exploit tenga éxito, el atacante tiene la capacidad de acceder y alterar cierta información confidencial. Pero, el exploit también puede usarse para bloquear cualquier componente u operación del sistema, dejándolo inutilizable o no disponible.

La tercera vulnerabilidad grave es un problema de cruce de directorios en SAP NetWeaver AS para ABAP y ABAP Platform. Esta vulnerabilidad tiene una puntuación CVSS de 9,6. Un adversario que no tiene autorizaciones administrativas puede explotar la debilidad mediante el uso de una falla de cruce de directorios en un servicio que está expuesto a ellos para reescribir los archivos del sistema.

Con SAP ERP y S4HANA, la vulnerabilidad de cruce de directorios conocida como CVE-2023-27500 ha sido calificada como la cuarta vulnerabilidad más grave, con una puntuación CVSS de 9,6. (Programa SAPRSBRO).

CVE-2023-25617 es una vulnerabilidad de ejecución de comandos del sistema operativo que existe en SAP Business Objects Business Intelligence Platform. Tiene una puntuación CVSS de 9,0 y está clasificada como la quinta vulnerabilidad más importante (Adaptive Job Server). Cuando la ejecución de objetos de programa está habilitada, el error habilita la ejecución remota de comandos arbitrarios en Unix. Los usuarios autenticados con derechos de programación pueden aprovechar esta vulnerabilidad mediante el uso de Business Intelligence Launchpad, la Consola de administración central o una aplicación personalizada basada en el SDK público de Java.

El cargo Vulnerabilidades críticas en SAP con puntaje CVSS > 9.5 apareció primero en Noticias de seguridad informática, ciberseguridad y hacking.

Ver Fuente