La Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA), la Oficina Federal de Investigaciones (FBI) y el Centro de Análisis e Intercambio de Información Multiestatal (MS-ISAC) han publicado una guía conjunta para responder a la denegación de servicio distribuida (DDoS) ataques
Un tipo de ataque cibernético dirigido a aplicaciones o sitios web, los ataques de denegación de servicio (DoS) tienen como objetivo agotar los recursos del sistema de destino para volverlo inaccesible a los usuarios legítimos.
Los ataques DDoS pueden tener como objetivo las vulnerabilidades del servidor para sobrecargar los recursos de la red o consumir estos recursos a través del reflejo de un gran volumen de tráfico de red hacia el objetivo, o pueden intentar sobrecargar los recursos de conexión (protocolo) o aplicación (cómputo o almacenamiento) del objetivo.
Cuando el tráfico de sobrecarga se origina en más de una fuente que opera en conjunto, el ataque se considera DDoS. Las botnets, que son redes de dispositivos comprometidos, incluidas computadoras, dispositivos IoT y servidores, son la fuente más común de ataques DDoS.
Es difícil responder y recuperarse de los ataques DDoS que producen grandes volúmenes de tráfico, señalan CISA, el FBI y MS-ISAC en su aviso . Dichos ataques pueden conducir a la degradación del servicio, pérdida de productividad, costos de remediación extensos y daños a la reputación.
“Las organizaciones deben incluir pasos para abordar estos efectos potenciales en su respuesta a incidentes y en sus libros de jugadas de continuidad de operaciones”, dicen las tres agencias.
Los ataques DDoS, las notas de aviso, generalmente no afectan la confidencialidad y la integridad de los sistemas y los datos, pero dichos ataques pueden usarse para desviar la atención de otros tipos de ataques, incluida la implementación de malware y la exfiltración de datos.
“En un mundo cada vez más interconectado con requisitos adicionales de conectividad remota pospandemia, mantener la disponibilidad de los recursos externos esenciales para el negocio puede ser un desafío incluso para los equipos de TI y de respuesta a incidentes más maduros. Es imposible evitar por completo convertirse en objetivo de un ataque DDoS”, señalan las tres agencias.
Para mitigar el riesgo de un ataque DDoS, las organizaciones deben conocer todos los activos de Internet y las vulnerabilidades que pueden afectarlos, identificar cómo se conectan los usuarios a la red corporativa, inscribirse en un servicio de protección DDoS, asegurarse de que comprenden las defensas existentes y implementar un plan de respuesta DDoS, dicen las tres agencias.
La guía conjunta, que se aplica tanto a las agencias federales como a las organizaciones privadas, proporciona recomendaciones adicionales sobre cómo las organizaciones pueden prepararse para los ataques DDoS y detalla los pasos que deben seguir al responder a un ataque en curso.
Una solución para un problema crítico en OpenSSL está en camino, anunciada antes de su lanzamiento el 1 de noviembre de 2022
El 25 de octubre, el equipo del proyecto OpenSSL anunció el próximo lanzamiento de la versión 3.0.7 de OpenSSL. El equipo no ha compartido muchos detalles, pero menciona que la actualización llegará el 1 de noviembre e incluirá un parche para un nuevo CVE crítico.
Esta es una de las actualizaciones importantes y críticas, ya que el Proyecto OpenSSL anunció una vulnerabilidad “crítica” en las versiones 3.0 y superiores de la biblioteca criptográfica muy popular para cifrar las comunicaciones en Internet.OpenSSL es un proyecto de código abierto que proporciona funciones criptográficas fáciles de usar y se utiliza para proteger las comunicaciones en todo el mundo.
OpenSSL califica sus problemas de seguridad y podemos ver que para que se emita un crítico, la vulnerabilidad debe afectar la configuración común y conducir a la divulgación de la clave privada o se puede explotar fácilmente de forma remota. Esta combinación de elementos para un desarrollador de exploits definitivamente apunta a que es un objetivo de interés.
OpenSSL califica sus problemas de seguridad y podemos ver que para que se emita un crítico, la vulnerabilidad debe afectar la configuración común y conducir a la divulgación de la clave privada o se puede explotar fácilmente de forma remota. Esta combinación de elementos para un desarrollador de exploits definitivamente apunta a que es un objetivo de interés.
¿Por qué esta vulnerabilidad de OpenSSL es importante?
Como señalamos anteriormente, “Internet funciona con OpenSSL” y todos dependen de OpenSSL. Puede que no lo sepa, pero OpenSSL es lo que hace posible el uso seguro de Transport Layer Security (TLS) en Linux, Unix, Windows y muchos otros sistemas operativos.
El investigador advierte que esta vulnerabilidad de OpenSSL podría ser otra situación de Log4Shell porque es más omnipresente que Log4j, la biblioteca de registro de Java.
Log4j (versión 2) se vio afectado por la vulnerabilidad Log4Shell (CVE-2021-44228) revelada hace casi un año. la naturaleza omnipresente de esta biblioteca, la gravedad del exploit (control total del servidor) y lo fácil que es explotar, el impacto de esta vulnerabilidad es bastante grave.
Según la política de seguridad del equipo de OpenSSL , una vulnerabilidad de Gravedad Crítica “ afecta a configuraciones comunes y que también son susceptibles de ser explotables. Los ejemplos incluyen la divulgación significativa del contenido de la memoria del servidor (potencialmente revelando detalles del usuario), vulnerabilidades que pueden explotarse fácilmente de forma remota para comprometer las claves privadas del servidor o donde la ejecución remota de código se considera probable en situaciones comunes.
¿Quiénes están afectados?
Según el aviso inicial, esta vulnerabilidad solo afecta a las versiones de OpenSSL 3.0.0 a 3.0.6 . Esto significa que es probable que los sistemas operativos y dispositivos más antiguos no se vean afectados por el problema.
Sin embargo, Red Hat Enterprise Linux (RHEL) 8.x y anteriores y Ubuntu 20.04 no se ven afectados. RHEL 9.x y Ubuntu 22.04 pueden ser vulnerables ya que usan OpenSSL 3.x.
Aquí hay una lista de las distribuciones o productos que pueden verse afectados:
¿Qué hacer para la mitigación?
Como no hay mucha información disponible sobre la vulnerabilidad ni se ha asignado ningún CVE y la actualización también llegará el 1 de noviembre, hasta entonces tenemos que esperar.
Si desea confirmar que su sistema está afectado o no, consulte la lista anterior o verifique la versión de OpenSSL en su sistema simplemente escribiendo openssl version el comando en la terminal.
Historia de la vulnerabilidad OpenSSL popular
OpenSSL es una versión de código abierto de los protocolos de seguridad SSL y TLS, que proporcionan cifrado y autenticación de servidor a través de Internet. Cualquier vulnerabilidad de seguridad significativa en la tecnología OpenSSL tiene el potencial de un impacto masivo, debido a la naturaleza ubicua.
Hubo múltiples vulnerabilidades que afectan a OpenSSL, pero dos de ellas son las más populares, que son:
Vulnerabilidad Heartbleed (CVE-2014-0160) : la vulnerabilidad Heartbleed en OpenSSL podría permitir que un atacante remoto exponga datos confidenciales, posiblemente incluidas las credenciales de autenticación del usuario y las claves secretas, a través del manejo incorrecto de la memoria en la extensión TLS heartbeat.
Las versiones de OpenSSL 1.0.1 a 1.0.1f contienen una vulnerabilidad en su implementación de la funcionalidad de latido TLS/DTLS. Esta vulnerabilidad permite que un atacante recupere la memoria privada de una aplicación que usa la biblioteca OpenSSL vulnerable en fragmentos de 64k a la vez. Tenga en cuenta que un atacante puede aprovechar repetidamente la vulnerabilidad para recuperar tantos fragmentos de memoria de 64k como sean necesarios para recuperar los secretos deseados.
Vulnerabilidad de OpenSSL 1.1.0a CVE-2016-6309 : CVE-2016-6309 era una vulnerabilidad Use-After-Free (UAF) que afecta a la versión 1.1.0a de OpenSSL, se activó al procesar mensajes grandes y solo afectó a una única versión de lanzamiento. Los atacantes remotos pueden hacer que el servidor OpenSSL se bloquee o ejecutar código arbitrario en él, simplemente enviando un paquete de protocolo de enlace con un mensaje de más de 16 KB.
Las siguientes versiones de software se han actualizado para resolver estos problemas específicos: Junos OS 19.1R3-S9, 19.2R3-S6, 19.3R3-S7, 19.4R3-S9, 20.1R3-S5, 20.2R3-S5, 20.3R3-S5, 20.4R3-S4, 21.1R3-S2, 21.2R3-S1, 21.3R2-S2, 21.3R3, 21.4R1-S2, 21.4R3, 22.1R1-S1, 22.1R2, 22.2R1 y todas las versiones posteriores. El aviso de Juniper se puede encontrar aquí.
SOLUCIÓN ALTERNATIVA :
Deshabilite J-Web o limite el acceso solo a hosts confiables.
Detalles de vulnerabilidad
1. CVE-2022-22241 : deserialización remota de Phar preautenticada para RCE.
Los archivos Phar (Archivo PHP) contienen metadatos en formato serializado, que cuando se analizan mediante una función de operación de archivos PHP conduce a que los metadatos se deserialicen. Un atacante puede abusar de este comportamiento para explotar una vulnerabilidad de creación de instancias de objetos dentro del código base de Juniper.
La característica única de los archivos phar es que esta deserialización ocurrirá incluso usando funciones PHP que no evalúan el código PHP como file_get_contents(), fopen(), file() o file_exists(), md5_file(), filemtime() o tamaño del archivo() , is_dir(), si la entrada del usuario se pasa a las funciones.
Impacto : esta vulnerabilidad puede ser aprovechada por un atacante remoto no autenticado para deserializar archivos phar remotos, lo que lleva a la escritura arbitraria de archivos, lo que genera una vulnerabilidad de ejecución remota de código (RCE). No lanzaremos un PoC completo sobre la deserialización que abusamos para obtener RCE hasta que se parcheen más servidores, pero el dispositivo de deserialización es muy fácil de detectar si está mirando el código base de JunOS. Esta es la única razón por la que esta vulnerabilidad no tiene una calificación crítica de 9.8: un atacante deberá encontrar un dispositivo de deserialización que hayamos encontrado u otro diferente para obtener RCE.
La vulnerabilidad es causada por el siguiente código en /jsdm/ajax/logging_browse.php:
Aunque hay $usuario = nuevo usuario(verdadero); en la línea 1, aún se puede acceder al controlador sin autenticación porque la verificación del usuario no se cierra si no es verdadera. Enviar una solicitud POST simple con el parámetro de ruta de archivo apuntando al archivo Phar obliga a que ocurra la deserialización.
Un ejemplo de solicitud para llegar a la deserialización parece tan simple como esto:
El archivo phar puede ser un archivo de imagen local cargado a través del portal de carga de imágenes, un archivo de caché o un archivo remoto cargado a través de la página de carga no autenticada.
2. CVE-2022-2224 2 : XSS reflejado preautenticado en la página de error.
Impacto : esta vulnerabilidad puede ser aprovechada por un atacante remoto no autenticado para robar sesiones de administración de JunOS o usarse en combinación con otras vulnerabilidades que requieren autenticación. Por ejemplo, esta vulnerabilidad se puede usar junto con el error de escritura del archivo posterior a la autenticación que forma parte del informe.
La vulnerabilidad es causada por el siguiente código en /error.php:
SERVER_NAME es una variable global que se construye con REQUEST_URI
3. CVE-2022-2224 3 : Inyección XPATH en jsdm/ajax/wizards/setup/setup.php
Impacto : esta vulnerabilidad puede ser aprovechada por un atacante remoto autenticado para manipular las sesiones de administración de JunOS o manipular el flujo XPATH que usa el servidor para hablar con sus analizadores XML.
La vulnerabilidad es creada por el siguiente código en /jsdm/ajax/wizards/setup/setup.php:
3. CVE-2022-2224 3 : Inyección XPATH en jsdm/ajax/wizards/setup/setup.php
Impacto : esta vulnerabilidad puede ser aprovechada por un atacante remoto autenticado para manipular las sesiones de administración de JunOS o manipular el flujo XPATH que usa el servidor para hablar con sus analizadores XML.
La vulnerabilidad es creada por el siguiente código en /jsdm/ajax/wizards/setup/setup.php:
JNX_STATE_AUTHENTICATED es una variable global que se activa si existe una sesión de usuario activa. Este ataque no es posible de realizar si JNX_STATE_AUTHENTICATED no está activado, por lo que solo es posible que lo exploten atacantes autenticados de bajo nivel.
La entrada controlada por el atacante se envía al método setDate. El método command() verifica contra JNX_STATE_AUTHENTICATED . Un atacante también puede explotar esta vulnerabilidad a través de un vector CSRF.
4. CVE-2022-2224 4 : Inyección de XPATH en el método send_raw()
Impacto : esta vulnerabilidad puede ser aprovechada por un atacante remoto autenticado para manipular las sesiones de administración de JunOS o manipular el flujo XPATH que usa el servidor para hablar con sus analizadores XML.
Esta vulnerabilidad es causada por el siguiente código en /modules/monitor/interfaces/interface.php:
podemos llegar a la función send_raw() con la siguiente entrada
Esto hará que send_raw() se comunique con el analizador XPath a través de interface.php
5. CVE-2022-2224 5 : El recorrido de ruta durante la carga de archivos conduce a RCE
Impacto : esta vulnerabilidad puede ser aprovechada por un atacante remoto autenticado para ejecutar código PHP cargando un archivo con un nombre especial. Esta vulnerabilidad también puede ser aprovechada con XSS por un atacante no autenticado.
Esta vulnerabilidad es causada por el siguiente código en /Upload.php:
Si el parámetro de fragmento no se envía y en su lugar se envía un parámetro XSRF válido, el archivo cargado por el atacante se construye en el siguiente destino: /var/tmp/$filename
Además, hay una función llamada check_filename que intenta desinfectar la carga pero tiene el siguiente aspecto:
El método check_filename() se puede omitir con \..\..\filename . Esto funciona porque Apache en Linux normaliza las barras invertidas en barras diagonales.
lo que permite que un atacante que envíe fileName=\..\..\..\..\www\dir\new\shell.php cree el siguiente archivo:
Esta vulnerabilidad permite que un atacante pueda crear cualquier archivo en cualquier destino del dispositivo.
6. CVE-2022-2224 6 : el archivo PHP incluye /jrest.php
Impacto : esta vulnerabilidad puede ser aprovechada por un atacante remoto autenticado para ejecutar código PHP mediante la inclusión de archivos locales. Esta vulnerabilidad también se puede utilizar para ejecutar un archivo PHP cargado por la vulnerabilidad de carga arbitraria.
La vulnerabilidad es causada por el siguiente código en /jrest.php:
que se puede manipular con la siguiente consulta:
lo que llevará al servidor a ejecutar la siguiente consulta:
Esto permite que un atacante incluya cualquier archivo PHP almacenado en el servidor. Si esta vulnerabilidad se explota junto con la vulnerabilidad de carga de archivos, puede conducir a la ejecución remota de código.
Si tiene algún dispositivo JunOS, actualícelo a la última versión para mitigar estas vulnerabilidades.
The New York Post concedió el jueves por la mañana que había sido hackeo después de que la cuenta de Twitter y el sitio web del periódico se inundaron con publicaciones ofensivas sobre políticos como la representante Alexandria Ocasio-Cortez, el presidente estadounidense Joe Biden y el alcalde de Nueva York Eric Adams.
El periódico no respondió a las solicitudes de comentarios, pero eliminó rápidamente las publicaciones y escribió en Twitter que había sido hackeado y que estaba investigando el incidente.
El popular tabloide es propiedad de News Corp y tiene 2,8 millones de seguidores en Twitter. A las 10:30 a. m., hora del este, las publicaciones ofensivas se eliminaron del sitio web y del feed de Twitter de la empresa.
Si bien muchos de los enlaces eran solo titulares ofensivos que no conducían a páginas de noticias reales, algunos tenían artículos completos, pero falsos, lo que llevó a algunos expertos a cuestionar si los hackers informáticos tenían acceso al sistema de administración de contenido del New York Post.
The New York Post es solo el último medio de comunicación que se enfrenta a una situación como esta en las últimas semanas después de que Fast Company fuera hackeada hace casi exactamente un mes .
En ese incidente, los hackers violaron los sistemas internos de administración de contenido del medio de noticias y enviaron dos notificaciones automáticas ofensivas a través de Apple News a miles de personas. El sitio web de la revista se cerró temporalmente, así como el de Inc. Magazine, que es propiedad del mismo editor.
Recientemente, Apache Linkis corrigió una vulnerabilidad de deserialización . El bug existe en el módulo JDBC EngineConn, un atacante podría aprovechar esta vulnerabilidad para deserializar y así lograr la ejecución remota de código. Seguimiento como CVE-2022-39944, la gravedad de la vulnerabilidad es importante.
“En Apache Linkis <= 1.2.0 cuando se usa con MySQL Connector/J, existe una vulnerabilidad de deserialización con un posible impacto de ejecución remota de código cuando un atacante tiene que escribir acceso a una base de datos y configura un JDBC EC con una fuente de datos MySQL y malicioso. parámetros Por lo tanto, los parámetros en la URL de jdbc deben estar en la lista negra ”, se lee en la lista de correo.
Al investigador de seguridad 4ra1n y zac del equipo de seguridad de ZAC se les atribuye la notificación de la vulnerabilidad CVE-2022-39944.
Versión afectada
Apache Link es anterior a 1.3.0
Versión no afectada
Apache Linkis 1.3.0
Solución
Actualmente, Apache Linkis ha corregido la vulnerabilidad en la última versión. Se recomienda a los usuarios que instalen la versión no afectada lo antes posible o actualicen los materiales de JDBC EngineConn por separado .
GitHub ha abordado una vulnerabilidad que permite a los atacantes tomar el control de uno de sus repositorios e infectar todas las aplicaciones y otros códigos que dependen de él.
Los investigadores de la empresa de seguridad Checkmarx se acercaron a la plataforma el 13 de junio y GitHub reconocieron la vulnerabilidad, la clasificó como de gravedad “alta” y les pagó una recompensa por vulnerabilidades no reveladas. GitHub no respondió a las solicitudes de comentarios, pero Checkmarx dijo que trabajaron con la plataforma para solucionar el vulnerabilidad.
El vulnerabilidad se centra en la función ” Retiro del espacio de nombres del repositorio popular ” de GitHub. Miles de usuarios de GitHub, incluidos los que controlan repositorios y paquetes populares, optan por cambiar sus nombres de usuario, dejando espacios de nombres que incluyen sus nombres de usuario anteriores abiertos a la explotación.
La vulnerabilidad, según Checkmarx, dejó numerosos paquetes susceptibles de ser secuestrados para servir código malicioso a millones de usuarios y muchas aplicaciones.
Aviad Gershon, investigador de seguridad de Checkmarx, le dijo que los intentos de explotar la función de retiro del espacio de nombres siguen siendo puntos de ataque atractivos para los hackers de la cadena de suministro .
“Esta vulnerabilidad golpea uno de los eslabones de la cadena de suministro. Una vez que esta cadena se vea comprometida, podemos esperar incidentes tan grandes como el incidente de SolarWinds y más grandes”, dijo Gershon.
“Esto posiblemente puede conducir a la infección de millones de usuarios finales con código malicioso que va desde ladrones de información hasta criptomineros y prácticamente cualquier otra cosa que el atacante decida emplear. Una posibilidad aún más preocupante es el código malicioso dentro de los equipos de salud o energía, por ejemplo”.
Gershon explicó que su investigación sobre la vulnerabilidad comenzó cuando su arquitecto jefe, Elad Rapoport, encontró el primer desvío relacionado con esta vulnerabilidad a fines del año pasado. La vulnerabilidad se solucionó en mayo de 2022, pero no antes de que se abusara de él . Rapoport comenzó a buscar formas similares de eludir esta misma protección.
Varios administradores de paquetes extraen el código de sus paquetes directamente de GitHub, según Gershon, quien agregó que si un atacante pudiera tomar el control de un repositorio popular que contiene el código de un paquete popular, podría agregarle su propio código.
“No es raro que un paquete de código abierto se convierta en uno de los componentes básicos de una aplicación ampliamente utilizada, que en este escenario también será envenenada”, dijo Gershon a The Record.
Citó una vulnerabilidad “similar” utilizada para secuestrar e infectar dos paquetes PHP populares en mayo, uno de los cuales se había descargado más de 2,5 millones de veces en el momento de la infracción.
“En este caso, el atacante (que luego afirmó que es un investigador de seguridad) intentó robar información confidencial de las víctimas. Entonces, este es un escenario totalmente realista y un riesgo del mundo real”, dijo Gershon.
En su informe sobre la vulnerabilidad, los investigadores de Checkmarx dijeron que los actores de amenazas podrían explotarla utilizando la técnica “Repojacking”, donde un atacante secuestra un espacio de nombres legítimo, a menudo popular, en GitHub.
El espacio de nombres típico en GitHub es la combinación del nombre de usuario y el nombre del repositorio. Un ejemplo sería: ejemplo-usuario/ejemplo-repositorio.
“Un espacio de nombres es vulnerable al Repojacking en caso de que el nombre original del usuario se haya cambiado utilizando la función de ‘cambio de nombre de usuario’ que ofrece GitHub”, explicaron los investigadores. “El proceso de cambio de nombre de usuario es rápido y sencillo. Una advertencia le informa que todo el tráfico de la URL del repositorio anterior se redirigirá a la nueva”.
Una vez que cambie su nombre de usuario, su antiguo nombre de usuario estará disponible para que cualquiera lo reclame. Un atacante puede abrir un repositorio con el mismo nombre y secuestrar el espacio de nombres.
Para abordar la vulnerabilidad, GitHub creó una función en la que cualquier repositorio que cumpla con ciertos criterios se considera “retirado” y no puede ser utilizado por otros.
Checkmarx dijo que todos los nombres de usuario renombrados en GitHub eran vulnerables a esta vulnerabilidad, incluidos más de 10,000 paquetes en los administradores de paquetes Go, Swift y Packagist.
Si bien la vulnerabilidad se solucionó, Checkmarx recomendó que los usuarios de GitHub eviten usar espacios de nombres retirados para minimizar la superficie de ataque porque “aún pueden existir otras vulnerabilidades en este mecanismo”.
A pesar de su trabajo con la empresa sobre el tema, su informe sobre la vulnerabilidad decía que la protección proporcionada por la plataforma para abordar la vulnerabilidad “se activa en función de métricas internas y no da a los usuarios ninguna indicación de si un espacio de nombres en particular está protegido o no. ”
Esto puede dejar en riesgo a algunos repositorios y paquetes sin saberlo, según los investigadores.
Varios expertos en seguridad cibernética confirmaron los hallazgos de Checkmarx y dijeron que la vulnerabilidad era significativa porque miles de herramientas se basan en bibliotecas de código abierto y repositorios de código, lo que hace que los ataques sean potencialmente catastróficos.
Casi todo usa SQLite, incluidos los teléfonos móviles, otros lenguajes informáticos y los acorazados de la marina. Hay una larga historia de que el motor de base de datos de código abierto es particularmente seguro. Debido a su licencia extremadamente indulgente y su naturaleza portátil y multiplataforma, SQLite es el motor de base de datos más utilizado. Está construido en C y puede convertirse en una biblioteca que expone las API para que las utilicen los programadores de aplicaciones o una aplicación independiente.
La vulnerabilidad de la API de la biblioteca SQLite, CVE-2022-35737, está siendo publicada por expertos de Trail of Bits . La versión 3.39.2 de SQLite, que estuvo disponible el 17 de octubre de 2000, se dirigió a CVE-2022-35737 (lanzada el 21 de julio de 2022).
En los sistemas de 64 bits, CVE-2022-35737 es explotable y la explotabilidad depende de cómo se compile el software. Cuando la biblioteca se compila sin valores controlados de pila, se confirma la ejecución de código arbitrario; cuando los canarios de pila están presentes, no está confirmado. La denegación de servicio se confirma en todas las circunstancias.
Cuando se proporcionan entradas de cadena grandes a las implementaciones de SQLite de los métodos printf y cuando la cadena de formato contiene los tipos de reemplazo de formato %Q, %q o %w, CVE-2022-35737 puede explotarse en sistemas susceptibles. Esto es suficiente para provocar el fracaso del programa. El equipo también demuestra cómo, en el peor de los casos, la ejecución de código arbitrario o el bloqueo y el bucle del programa son concebibles si la cadena de formato contiene el ! carácter especial para permitir el escaneo de caracteres Unicode (casi).
El 100 % de las pruebas de rama se han ejecutado en SQLite. Los expertos encontraron esta vulnerabilidad a pesar de las pruebas, lo que plantea la cuestión de cómo las pruebas no la detectaron.
La vulnerabilidad no se puede explotar en la aplicación SQLite ya que tiene un límite de memoria interna de 1 GB. La idea de que SQLite no maneja cadenas grandes, que son esenciales para explotar esta vulnerabilidad, “define” el problema. Las aplicaciones pueden contactar directamente con las rutinas vulnerables porque las API de C que ofrece SQLite no requieren que las entradas cumplan con el límite de memoria. Los desarrolladores de aplicaciones no pueden imponer restricciones de tamaño de entrada en estos métodos porque SQLite no se comunica con la API de que no se permiten cadenas grandes. Asignar cadenas de 1 GB como entrada era imposible cuando este código se creó inicialmente, ya que la mayoría de las CPU solo tenían registros de 32 bits y 4 GB de memoria accesible. La asignación de cadenas tan grandes es posible y las circunstancias susceptibles se pueden lograr ahora que las computadoras de 64 bits se usan ampliamente.
El 14 de julio de 2022, se notificó una vulnerabilidad al Centro de Coordinación del Equipo de Respuesta a Emergencias Informáticas (CERT).
El 15 de julio de 2022, CERT/CC notificó a los mantenedores de SQLite sobre una vulnerabilidad.
La vulnerabilidad se confirmó el 18 de julio de 2022 y se actualizó el código fuente.
El 21 de julio de 2022, los desarrolladores de SQLite publicaron la versión 3.39.2 con un parche.
El algoritmo de RealPage arruinó a los inquilinos al inflar los costos, se afirmo.
El fabricante de un algoritmo que calcula el alquiler óptimo a cobrar por las viviendas ha sido acusado de provocar un aumento injusto y artificial de los costes para los inquilinos.
RealPage, con sede en Texas y nueve gigantes inmobiliarios se han visto afectados por una demanda que afirma que el desarrollador de software formó un “cártel” con los propietarios para aumentar los alquileres en ciudades donde la vivienda tiene una gran demanda en los EE. UU.
Fuera de cosas como el control de alquileres, establecer el alquiler es un acto de equilibrio que involucra la oferta y la demanda. Si lo establece demasiado bajo, es posible que no cubra la hipoteca y otros costos (si corresponde), así como también perderá ganancias. Si lo establece demasiado alto, se quedará fuera del mercado. ¿No sería útil si hubiera algún tipo de aplicación que pudiera identificar automáticamente un punto ideal para alquilar por hogar?
La demanda, presentada por cinco inquilinos este mes, afirma que los nueve gigantes de la administración de propiedades compitieron entre sí antes de 2016, pero encontraron una manera de coludirse entre sí a través de un tercero: RealPage. Se afirma que el grupo utilizó el software de RealPage para establecer colectivamente el alquiler y asegurarse de que ninguno de ellos se socavara entre sí, inflando así los costos para los inquilinos.
Los demandantes en el caso presentado en San Diego, California son: Sherry Bason, Lois Winn, Georges Emmanuel Njong Diboki, Julia Sims y Sophia Woodland. Juntos están demandando, en lo que podría convertirse en una demanda colectiva, a los administradores de cientos de miles de apartamentos: Greystar, Lincoln Property Co, FPI Management, Mid-America Apartment Communities, Avenue5 Residential, Equity Residential, Essex Property Trust, Thrive Gestión de Comunidades y Valores de Propiedades.
“A partir de aproximadamente 2016 y posiblemente antes los 11 arrendadores reemplazaron sus decisiones independientes de precios y suministro con colusión”, según la demanda del tribunal federal de distrito [ PDF ].
“Los arrendadores acordaron utilizar un tercero común que recopiló precios y niveles de suministro en tiempo real y luego usaron esos datos para hacer recomendaciones de suministro y precios específicos de la unidad. Los arrendadores también acordaron seguir estas recomendaciones, con la expectativa de que los arrendadores competidores harían lo mismo.”
El algoritmo de RealPage, denominado YieldStar, calculó el precio de los apartamentos según varios factores, incluida la ubicación y la demanda. Los administradores de propiedades que usan el software son libres de aceptar o rechazar las sugerencias del algoritmo, aunque se les recomienda encarecidamente en llamadas regulares con RealPage que sigan su precio, se afirma. Luego de una investigación que provocó la demanda anterior, ProPublica informó que el código ingiere datos que incluyen el alquiler de las casas circundantes para determinar un precio óptimo.
“Las máquinas aprenden rápidamente que la única forma de ganar es empujar los precios por encima de los niveles competitivos”, dijo a la publicación Maurice Stucke, profesor de derecho de la Universidad de Tennessee y exfiscal de la división antimonopolio del Departamento de Justicia.
YieldStar por lo tanto aumenta los precios de alquiler, se afirma. De hecho, según la demanda, RealPage se jactó de que su software genera “mejoras en las tasas de alquiler, año tras año, entre el 5 y el 12 por ciento en todos los mercados”.
Si numerosos dueños de propiedades usan el mismo software para fijar el precio de los apartamentos, sofoca la competencia y aumenta los costos promedio de alquiler en una ciudad, afirma la demanda. Los inquilinos sufren al tener que pagar más, mientras que los propietarios se benefician ayudándose mutuamente a aumentar los precios del mercado, alegaron los demandantes. Acusaron a RealPage de violar la Sección 1 de la Ley Sherman, que establece que los acuerdos que restringen razonablemente el comercio son ilegales; se afirma que RealPage y los gigantes de bienes raíces estaban todos conscientemente en la misma página cuando se trataba de usar el software.
Un portavoz de RealPage negó las acusaciones de la demanda y, en una declaración afirmó que los informes de ProPublica eran inexactos y engañosos.
“El software de administración de ingresos de RealPage está diseñado específicamente para cumplir con la ley”, nos dijo un representante.
“RealPage está al tanto de la demanda. Negamos rotundamente las acusaciones y nos defenderemos enérgicamente contra la demanda. Más allá de eso, no comentamos sobre litigios pendientes”.
Se puede encontrar una declaración completa de la empresa aquí , en la que argumenta que su código “elimina” el riesgo de colusión al recomendar tarifas justas para el mercado.
NubeSEK La plataforma de riesgo digital de IA contextual deXVvigiliaha analizado varias vulnerabilidades críticas y de alta gravedad que afectan a Veeam Backup & Replication.
Se vio a varios actores de amenazas anunciando la herramienta completamente armada para la ejecución remota de código para explotar las siguientes vulnerabilidades que afectan a Veeam Backup & Replication:
CVE-2022-26500 y CVE-2022-26501 con una puntuación CVSS V3 de 9,8
CVE-2022-26504 con una puntuación CVSS V3 de 8,8
Una explotación exitosa de los CVE mencionados anteriormente puede conducir a:
Copia de archivos dentro de los límites de la configuración regional o desde una red SMB remota
RCE sin autorización (derechos de ‘Servicio de red’)
RCE/LPE sin autorización (derechos de ‘Sistema Local’)
¿Qué es Veeam Backup & Replication?
Veeam Backup & Replication es una aplicación de respaldo patentada para entornos virtuales basada en hipervisores VMware vSphere, Nutanix AHV y Microsoft Hyper-V.
Además de respaldar y recuperar máquinas virtuales, puede proteger y restaurar archivos y aplicaciones individuales para entornos como Exchange y SharePoint.
CVE explotados por actores de amenazas
CVE-2022-26500, CVE-2022-26501
Vulnerabilidad de ejecución remota de código en el servicio de distribución de Veeam
El servicio de distribución de Veeam, que utiliza TCP 9380 con la configuración predeterminada, permite que los actores de amenazas que no están autenticados accedan a las funciones internas de la API.
Este componente permite a los actores de amenazas ejecutar código malicioso de forma remota sin autenticación.
CVE-2022-26504
Vulnerabilidad de ejecución remota de código en Veeam Backup PSManager
El proceso de Veeam.Backup.PSManager.exe que usa TCP 8732 con la configuración predeterminada, permite a los actores de amenazas que no son administradores autenticarse usando credenciales de dominio.
Esta vulnerabilidad permite a los atacantes del dominio ejecutar código malicioso de forma remota al atacar componentes vulnerables que conducen a obtener el control del sistema.
Información de OSINT
Los investigadores de CloudSEK pudieron encontrar un repositorio de GitHub llamado “veeam-creds” con las siguientes especificaciones:
Contenía scripts para recuperar contraseñas del administrador de credenciales de Veeam Backup and Replication.
El repositorio tenía los siguientes 3 archivos:
Veeam-Get-Creds.ps1: script de PowerShell para obtener y descifrar cuentas directamente desde la base de datos de Veeam.
VeeamGetCreds.yaml: módulo PowerShell Empire con script Veeam-Get-Creds.ps1 adaptado.
Veampot.py: secuencia de comandos de Python para emular las respuestas de vSphere para recuperar las credenciales almacenadas de Veeam.
Posibles afiliaciones de ransomware
Se encontró un malware llamado “Veeamp” en la naturaleza que se usaba siguiendo a dos grupos de ransomware para volcar las credenciales de una base de datos SQL para el software de administración de copias de seguridad de Veeam.
Monti ransomware
Yanluowang Ransomware
El archivo de malware es un binario .NET de 32 bits que intenta conectarse con una base de datos SQL llamada VeeamBackup al iniciarse y ejecuta el siguiente comando: select ,, FROM ..
El volcador de credenciales llamado “Veeamp.exe” después de descifrados exitosos, imprime lo siguiente en orden:
Nombre de usuario
Contraseña cifrada
Contraseña descifrada
Descripción
Indicadores de compromiso (IoC)
Según los resultados de VirusTotal, los siguientes son los IOC para Veeamp.
Australia propuso el sábado penas más duras para las empresas que no protegen los datos personales de los clientes después de que dos importantes infracciones de seguridad cibernética dejaran a millones vulnerables a los delincuentes.
Las sanciones por infracciones graves de la Ley de Privacidad aumentarían de 2,2 millones de dólares australianos (1,4 millones de dólares) ahora a 50 millones de dólares australianos (32 millones de dólares) según las enmiendas que se presentarán al Parlamento la próxima semana, dijo el fiscal general Mark Dreyfus.
Una empresa también podría recibir una multa del valor del 30 % de sus ingresos durante un período definido si esa cantidad supera los 50 millones de dólares australianos (32 millones de dólares).
Dreyfus dijo que “las grandes empresas podrían enfrentar sanciones de hasta cientos de millones de dólares” según la nueva ley.
“Es un aumento muy, muy sustancial en las sanciones”, dijo Dreyfus a los periodistas.
“Está diseñado para hacer pensar a las empresas. Está diseñado para ser un elemento disuasorio para que las empresas protejan los datos de los australianos”, agregó.
El Parlamento se reanuda el martes por primera vez desde mediados de septiembre.
Esta semana, ciberdelincuentes desconocidos exigieron un rescate de la aseguradora de salud más grande de Australia , Medibank, luego de afirmar haber robado 200 gigabytes de datos de clientes, incluidos diagnósticos y tratamientos médicos. Medibank tiene 3,7 millones de clientes. La compañía dijo que los hackers habían demostrado que tenían los registros personales de al menos 100.
Según los informes, los ladrones han amenazado con hacer públicas las condiciones médicas de los clientes de Medibank de alto perfil.
Dreyfus dijo que ambas infracciones habían demostrado que “las salvaguardas existentes son inadecuadas”.
Además de no proteger la información personal, al gobierno le preocupa que las empresas retengan innecesariamente demasiados datos de clientes durante demasiado tiempo con la esperanza de monetizar esa información.
“Necesitamos asegurarnos de que cuando se produce una filtración de datos, la sanción sea lo suficientemente grande, que sea una sanción realmente grave para la empresa y que no pueda ignorarse o ignorarse o simplemente pagarse como parte del costo de hacer negocios”. dijo Dreyfus.
Dreyfus espera que las enmiendas propuestas se conviertan en ley en las últimas cuatro semanas que el Parlamento sesionará este año.
Cualquier sanción nueva no será retroactiva y no afectará a Optus o Medibank.
Leer sobre la industria de la web3, es decir, el movimiento de la próxima generación de Internet, que incluye la tecnología de cadena de bloques y las criptomonedas, puede ser algo curioso. Por un lado, los defensores de la web3 hablan mucho de cómo la tecnología que utilizan representa el futuro de la seguridad en línea. Y, hasta cierto punto, puede que tengan razón. Después de todo, es comúnmente considerado como cierto que una cadena de bloques no puede ser pirateada, al menos no en el sentido tradicional de la piratería.
Por otra parte, el espacio de la web3 está lleno de estafas y fraudes que cuestan a las empresas y a los usuarios millones de dólares en pérdidas. De hecho, parece que cada día nos levantamos para ver una nueva historia sobre una estafa de criptomonedas que afecta a una organización importante del sector. Lo importante es que no se trata de hacks tradicionales como el ransomware o el spyware, sino de estafas centradas específicamente en los aspectos únicos de las aplicaciones de blockchain. Binance, que es una de las mayores bolsas de criptomonedas del mundo, fue hackeada recientemente. Y no es la primera vez.
La normativa puede ayudar a los usuarios
Ha quedado demostrado que las estafas y los hackeos cuestan al sector varios miles de millones de dólares al año. No obstante, hay que preguntarse si esto sería posible si el sector no operara a menudo en zonas grises legales. El espacio de la web3 representa una nueva tecnología, gran parte de la cual no está cubierta por los reguladores. Esto deja a las empresas de web3, pero sobre todo a los clientes, en situación de riesgo. Si pierdes tu dinero en un intercambio de criptomonedas, las autoridades no intervendrán para ayudarte de la misma manera que si te piratean la cuenta bancaria.
Podríamos decir que la regulación funciona. La industria de las apuestas deportivas y los juegos de casino es una de las más reguladas en Internet. Hasta la fecha, no se ha producido ningún hackeo de gran repercusión de un gran casino o plataforma de apuestas deportivas con licencia. Hay muchas razones para ello, como los procedimientos reguladores que siguen las plataformas. Esto significa que los jugadores pueden hacer apuestas, jugar a juegos virtuales e incluso jugar a juegos como la ruleta y el blackjack online en un casino en vivo sin preocuparse. Dichas plataformas adoptan medidas sencillas, incluyendo políticas sobre cómo se almacenan los fondos de los jugadores, gran parte de las cuales se establecen en la normativa.
La protección de los usuarios
Sin embargo, el espacio de la web3 está todavía en su fase de desarrollo. Pueden pasar años hasta que los reguladores se pongan al día con la tecnología y entiendan el sector lo suficientemente bien como para establecer una normativa coherente y lógica que proteja a quienes interactúan con él. Ess algo que falta en el sector de la web3. Uno de los mantras más importantes del movimiento es la “descentralización”. Significa que esta iteración de Internet está libre -o pretende estarlo- del control central: gobiernos, bancos, Big Tech (Google, etc.) y reguladores. No obstante, en ausencia de esos organismos, estarás solo si caes en la trampa de las estafas.
Es poco probable que los reguladores permitan que esto ocurra siempre. En todas partes, desde España hasta Singapur y Arabia Saudí, los gobiernos están buscando formas de frenar el salvaje movimiento de la web3. No faltará la resistencia de quienes creen que la regulación ahogará la innovación, pero la regulación, si se hace correctamente, ayudará, no obstaculizará, el crecimiento de la web3. Además, protegerá a millones -quizá miles de millones- de usuarios.
La Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA, por sus siglas en inglés) agregó el jueves una falla del kernel de Linux a su Catálogo de Vulnerabilidades Explotadas Conocidas e instruyó a las agencias federales para que la aborden dentro de tres semanas.
La vulnerabilidad se rastrea como CVE-2021-3493 y está relacionada con la implementación del sistema de archivos OverlayFS en el kernel de Linux. Permite que un usuario local sin privilegios obtenga privilegios de root, pero solo parece afectar a Ubuntu.
CVE-2021-3493 ha sido explotado de forma salvaje por un malware sigiloso de Linux llamado Shikitega , que los investigadores de AT&T Alien Labs detallaron a principios de septiembre. Shikitega está diseñado para apuntar a puntos finales y dispositivos IoT que ejecutan Linux, lo que permite al atacante obtener el control total del sistema. También se ha utilizado para descargar un minero de criptomonedas en el dispositivo infectado.
Como parte de la cadena de infección del malware, se explotan dos vulnerabilidades de Linux para escalar privilegios: CVE-2021-3493 y CVE-2021-4034.
CVE-2021-4034 se llama PwnKit y afecta a Pkexec de Polkit, un programa raíz SUID que se encuentra en todas las distribuciones de Linux. CISA advirtió sobre esta vulnerabilidad siendo explotada en ataques en junio. Cisco mencionó la explotación en un informe reciente que describe un marco de ataque chino y su RAT asociado, que apunta a los sistemas Windows, Linux y macOS.
Los informes de noticias publicados cuando salió a la luz la existencia de Shikitega se centraron en el malware en sí y no destacaron el hecho de que este parecía ser el primer caso conocido de CVE-2021-3493 explotado con fines maliciosos.
Los detalles técnicos y los exploits de prueba de concepto (PoC) para esta vulnerabilidad están disponibles públicamente.
CISA ahora ha agregado la falla a su Catálogo de Vulnerabilidades Explotadas Conocidas y ha dado instrucciones a las agencias federales para que parcheen sus sistemas hasta el 10 de noviembre. Si bien una directiva operativa vinculante requiere que las agencias federales corrijan estas fallas, CISA insta encarecidamente a todas las organizaciones a que prioricen la corrección de vulnerabilidades. figura en su catálogo.
La Policía Federal de Brasil dijo que arrestó a un presunto miembro del notorio grupo de hackers Lapsus$ el miércoles.
En un comunicado, los agentes policiales explicaron que arrestaron a una persona en la ciudad brasileña de Feira de Santana.
Se compartió poca información sobre el sospechoso, pero la policía insinuó que está preparada para acusar a la persona de delitos relacionados con operar una organización criminal, invasión de dispositivos informáticos, perturbaciones tecnológicas y más.
“También se constató la práctica de la corrupción de menores, delito previsto en el Estatuto del Niño y del Adolescente, y el blanqueo de capitales, según la Ley N° 9.613/1998”, dijo la policía.
El arresto fue parte de la Operación Nube Oscura, un esfuerzo anunciado en agosto que buscaba investigar las supuestas operaciones del grupo dentro de Brasil. La Policía Federal de Brasil ejecutó ocho órdenes de allanamiento e incautación como parte de la operación.
Los oficiales de policía señalaron que además de los ataques del grupo contra Microsoft , Cisco , Samsung , Nvidia y Okta , entre otros , que acapararon los titulares, los miembros también atacaron al Ministerio de Salud de Brasil y a “docenas de otros organismos y entidades del Gobierno Federal, incluido el Ministerio de Economía, Contraloría General de la Unión y Policía Federal de Caminos”.
Si bien la Operación Nube Oscura comenzó en agosto, el grupo ha estado bajo investigación desde diciembre, cuando se atacó inicialmente el entorno de nube del Ministerio de Salud.
“En ese momento, los atacantes eliminaron archivos, datos e instancias de la carpeta atacada, lo que incluso comprometió el sitio web.Conectusus.saude.gov.br, responsable del Certificado Nacional de Vacunación”, explicó la Policía Federal.
“Después del ataque, al intentar acceder a la página web del Ministerio de Salud (www.saude.gov.br), los usuarios encontraron un mensaje que decía que los datos del sistema habían sido copiados y eliminados y estaban en manos del grupo invasor”.
La policía agregó que el grupo ha atacado a varias empresas en Brasil, así como a otras en Estados Unidos y Europa.
Los ataques a instituciones brasileñas fueron los primeros del grupo antes de expandirse a más víctimas de alto perfil en Europa y EE. UU.
El Proyecto Metasploit es un proyecto de seguridad informática que proporciona información sobre vulnerabilidades de seguridad y ayuda en las pruebas de penetración y el desarrollo de firmas IDS . Es una plataforma de pruebas de penetración que le permite encontrar, explotar y validar vulnerabilidades. La plataforma incluye Metasploit Framework y sus contrapartes comerciales, como Metasploit Pro.
registro de cambios
v6.2.22
Land #17143 , módulo agregado para CVE-2022-40684
Land #17157 , verifique LHOST global antes de generarlo desde RHOSTS
actualice el escáner de inicio de sesión de idrac para que funcione con v8 y v9
v6.0
Las características iniciales de Metasploit 6.0 incluyen el cifrado de extremo a extremo de las comunicaciones de Meterpreter en las cinco implementaciones (Windows, Python, Java, Mettle y PHP), soporte de cliente SMBv3 para habilitar aún más los flujos de trabajo de explotación modernos y una nueva rutina de generación de carga útil polimórfica para Windows. shellcode que mejora las capacidades evasivas frente a los antivirus comunes y los productos del sistema de detección de intrusos (IDS).
Este conjunto de funciones inicial marca una transición hacia comunicaciones seguras y cifrado de forma predeterminada en los componentes clave de Metasploit Framework. Las funciones iniciales de Metasploit 6 también aumentan la complejidad para la creación de detecciones basadas en firmas para ciertas operaciones de red y los principales archivos binarios de carga útil de Metasploit. Los usuarios y desarrolladores de Metasploit pueden esperar más adiciones y refinamientos de las funciones de la versión 6 en los próximos meses.
Nota importante: Metasploit 6 incorpora cambios incompatibles con versiones anteriores para la comunicación de carga útil, lo que significa que las cargas útiles generadas con versiones anteriores de Metasploit no podrán conectarse a Metasploit 6 y viceversa. Debido a esta incompatibilidad, los usuarios no deberían actualizar a Metasploit 6 durante las operaciones activas a menos que estén preparados para perder sus sesiones.
Cifrado ampliado
A partir de Metasploit 6, todos los Meterpreters utilizarán AES para cifrar sus comunicaciones con Framework. El cifrado de extremo a extremo ofrece a los operadores dos ventajas notables: en primer lugar, el cifrado ofusca el tráfico, lo que dificulta mucho más las detecciones basadas en firmas de los canales de comunicación establecidos. En segundo lugar, la información confidencial (como las contraseñas) transferida desde el host comprometido al Framework ahora está protegida en tránsito.
Metasploit 6 también mejora el cliente SMB de Framework para admitir la versión 3 de SMB . SMBv3 agregó compatibilidad con el cifrado, que Metasploit ahora usará de forma predeterminada cuando esté disponible y que, al igual que con el cifrado Meterpreter, aumentará la complejidad de las detecciones basadas en firmas que se utilizan para identificar las operaciones clave realizadas en SMB. Hemos actualizado una serie de módulos Metasploit populares para usar el nuevo cliente SMB para que puedan usarse en entornos donde SMBv3 es la única versión disponible; algunos módulos más antiguos pueden actualizarse en un momento posterior (o no actualizarse en absoluto). Algunos módulos notables que ahora son compatibles con las versiones 1, 2 y 3 de SMB incluyen:
explotar/ventanas/smb/psexec
explotar/windows/smb/webexec
auxiliar/admin/smb/psexec_ntdsgrab
auxiliar/escáner/smb/smb_version
auxiliar/escáner/smb/smb_login
Artefactos de carga útil más limpios
Meterpreter, la carga útil principal de Metasploit, incluye algunas mejoras adicionales además de los canales de comunicación encriptados. Las DLL utilizadas por Windows Meterpreter ahora resuelven las funciones necesarias por ordinal en lugar de por nombre. Esto significa que la exportación estándar ReflectiveLoader utilizada por los archivos DLL cargables de manera reflexiva ya no está presente en los archivos binarios de carga útil como datos de texto. Además, los comandos que Meterpreter expone al Framework ahora están codificados como números enteros en lugar de cadenas. Esto beneficia particularmente a los Meterpreters sin etapas en arquitecturas nativas (como Windows y Linux) ya que estas cadenas ya no están en los archivos binarios.
La antigua extensión Mimikatz Meterpreter ha sido eliminada a favor de su sucesor, Kiwi. Los intentos de load mimikatz cargar Kiwi en el futuro previsible.
Por último, la gran mayoría de las cargas útiles de shellcode de Windows (como windows/meterpreter/reverse_tcp) utilizan un código auxiliar común para invocar los métodos de la API de Windows. Este código auxiliar se conoce como API de bloque y representa casi la mitad del tamaño (130 bytes para x86 y 200 bytes para x64) de algunas de las cargas útiles más pequeñas. Este stub estático (anteriormente) era una fruta fácil de alcanzar para la detección de shellcode basada en firmas: dos firmas, una para x86 y otra para AMD64, podían coincidir con casi todas las cargas útiles de Windows no codificadas de Metasploit. Para abordar esto, Metasploit ha reemplazado la rutina de generación estática con una rutina de aleatorización que agrega propiedades polimórficas a este trozo crítico mezclando instrucciones cada vez. Esto proporciona los beneficios anti-firma otorgados históricamente por la codificación sin requerir que la carga útil se automodifique (y, por lo tanto, exista dentro de un segmento RWX que a menudo se identifica como un comportamiento malicioso en sí mismo).
Los investigadores de seguridad cibernética publicaron detalles técnicos sobre una vulnerabilidad de FabriXss ahora parcheada que afecta a Azure Fabric Explorer.
Los investigadores de Orca Security han publicado detalles técnicos sobre una vulnerabilidad FabriXss ahora parcheada, rastreada como CVE-2022-35829 (CVSS 6.2), que afecta a Azure Fabric Explorer.
Un atacante puede aprovechar la vulnerabilidad para obtener privilegios de administrador en el clúster. Para explotar esta vulnerabilidad, un atacante debe tener el permiso CreateComposeDeployment.
Orca Security informó sobre la vulnerabilidad a Microsoft en agosto de 2022 y la compañía la abordó con el lanzamiento de las actualizaciones Patch Tuesday de octubre de 2022 .
La vulnerabilidad afecta a Azure Fabric Explorer versión 8.1.316 y anteriores.
La herramienta de código abierto SFX permite administrar clústeres de Azure Service Fabric.
La herramienta SFX proporciona un tablero compartido a muchos grupos de usuarios, como clientes y clientes. Los expertos descubrieron que un usuario con un perfil de “Implementador” con un solo permiso para “Crear nuevas aplicaciones” puede crear un nombre de aplicación malicioso y abusar de los permisos de Administrador para realizar una amplia gama de actividades maliciosas.
“SFX puede “alojar” muchos tipos de usuarios en un tablero compartido. Por ejemplo, un Fabric Cluster que es mantenido y controlado por un Administrador de la Organización X, también puede ofrecer servicios a sus clientes desde la misma organización”. lee la publicación publicada por Orca Security. “Descubrimos que un usuario de tipo Implementador con un permiso único para ‘Crear nuevas aplicaciones’ a través del tablero, puede usar este permiso único para crear un nombre de aplicación malicioso y abusar de los permisos de Administrador para realizar varias llamadas y acciones”.
El atacante puede restablecer un nodo de clúster borrando todas las configuraciones personalizadas, como contraseñas y configuraciones de seguridad, y creando nuevas contraseñas y obteniendo permisos completos de administrador.
Un atacante puede desencadenar la vulnerabilidad XSS enviando la entrada especialmente diseñada durante el paso de creación de la aplicación.
Los expertos describen un procedimiento paso a paso para activar la vulnerabilidad junto con una grabación de pantalla:
Se reveló la ejecución de código arbitrario en Apache Commons Text (CVE-2022-42889) con una puntuación CVSS de 9,8 sobre 10.
Apache Software Foundation (ASF) ha publicado una corrección para una vulnerabilidad de gravedad crítica en la biblioteca Apache Commons Text que conduce a la ejecución remota de código.
La vulnerabilidad CVE-2022-42889 , descubierta por Álvaro Muñoz, apareció por primera vez el 13 de octubre de 2022 en la lista de desarrolladores de Apache . Sin embargo, aún están surgiendo detalles sobre la gravedad y el alcance de la vulnerabilidad, incluida la detección de cualquier ejemplo de aplicaciones del mundo real que utilicen configuraciones vulnerables de la biblioteca afectada.
Esta vulnerabilidad se compara con la de Log4Shell , vulnerabilidad en Apache Log4j 2, una popular biblioteca de Java para registrar mensajes de error en las aplicaciones. Sin embargo, según el análisis realizado por muchos investigadores de seguridad (hasta el momento de escribir este artículo), no parece tener el mismo impacto que la vulnerabilidad de Log4Shell.
Acerca de la vulnerabilidad CVE-2022-42889
CVE-2022-42889 surge de la implementación insegura de la funcionalidad de interpolación variable de Commons Text.
El método StringSubstitutor.createInterpolator() crea un interpolador y permitirá búsquedas de cadenas como se define en StringLookupFactory. Esto se puede usar pasando una cadena “ ${prefix:name} ” donde el prefijo es la búsqueda mencionada anteriormente. El uso de las búsquedas de “script”, “dns” o “url” permitiría que una cadena diseñada ejecute scripts arbitrarios cuando se pasa al objeto interpolador.
Esto es algo similar a la PoC para la vulnerabilidad Log4Shell .
CVE-2022-42889 afecta las versiones 1.5 a 1.9 de Apache Commons Text. El equipo de Apache corrigió la vulnerabilidad y lanzó el parche a partir de la versión 1.10 de Commons Text.
El equipo de rapid7 probó su prueba de concepto en la siguiente versión de JDK:
JDK 1.8.0_341 – PoC funciona
JDK 9.0.4 – PoC funciona
JDK 10.0.2 – PoC funciona
JDK 11.0.16.1 – advertencia pero funciona
JDK 12.0.2 – advertencia pero funciona
JDK 13.0.2 – advertencia pero funciona
JDK 14.0.2 – advertencia pero funciona
JDK 15.0.2 – Vulnerabilidad
JDK 16.0.2 – Vulnerabilidad
JDK 17.0.4.1 – Vulnerabilidad
JDK 18.0.2.1 – Vulnerabilidad
JDK 19 – Vulnerabilidad
Sin embargo, el equipo de seguridad de JFrog señaló que los usuarios de Java 15+ están a salvo de la ejecución de código ya que el motor Nashorn estaba deshabilitado, por lo que la interpolación ${script} no funcionará. Sin embargo, otros vectores (DNS, URL) seguirán funcionando.
El código PoC es similar al Log4Shell:${script:javascript:java.lang.Run.Runtime.getRuntime().exec("cat /etc/shadow");}
El equipo de Rapid7 señaló que,
es poco probable que el fragmento de código específico exista en aplicaciones de producción, la preocupación es que en algunas aplicaciones, la variable `pocstring` puede estar controlada por un atacante. En este sentido, la vulnerabilidad se hace eco de Log4Shell.
Sin embargo, el interpolador StringSubstitutor se usa considerablemente menos que la sustitución de cadena vulnerable en Log4j y la naturaleza de dicho interpolador significa que es menos probable obtener una entrada manipulada para el objeto vulnerable que simplemente interactuar con una cadena tan manipulada como en Log4Shell.
Llamándolo Text4Shell o Text2Shell
Hemos visto a muchos llamando a esta vulnerabilidad como Text4Shell o Text2Shell, ya que tiene el mismo tipo de código de explotación que Log4Shell. Apache Commons Text es una biblioteca ampliamente utilizada, pero en una escala mucho más pequeña que Log4J.
La vulnerabilidad CVE-2022-42889 (Text4Shell / Text2Shell) consiste en inyectar una carga maliciosa en el software vulnerable, que le pedirá a Apache Commons Text que obtenga un valor de una fuente de terceros, con DNS o ejecutando un script.
Sin embargo, en este caso, Apache Commons Text no verifica los datos a procesar por defecto, lo que significa que se puede ejecutar código malicioso si no se ha implementado ningún filtro en el código de la aplicación vulnerable.
Recomendación
Como no es probable que la vulnerabilidad se vea muy afectada como Log4Shell, también recomendamos encarecidamente actualizar la versión Apache Commons Text a la versión fija 1.10.0.
Se descubrió una vulnerabilidad de ejecución remota de código (RCE) en el software Cobalt Strike , lo que podría permitir que los actores de amenazas tomen el control de los sistemas objetivo.
En un nivel básico, Cobalt Strike es un marco de equipo rojo que se utiliza principalmente para la simulación de adversarios. Comprende un servidor de equipo que funciona como un componente de comando y control (C2) y una baliza (herramienta de malware) para crear una conexión con el servidor de equipo y soltar las cargas útiles de la siguiente etapa.
La nueva vulnerabilidad (con seguimiento CVE-2022-42948) afecta a Cobalt Strike versión 4.7.1 y se deriva de un parche incompleto publicado por HelpSystems el 20 de septiembre de 2022 para corregir una vulnerabilidad de secuencias de comandos entre sitios (XSS) (CVE-2022-39197). ) que podría dar lugar a ataques RCE.
Según un nuevo aviso del equipo de inteligencia de seguridad patrocinado por IBM , la vulnerabilidad XSS podría activarse de una de tres maneras: manipulando los campos de entrada de la interfaz de usuario del lado del cliente, simulando un registro de implante Cobalt Strike o conectando un implante Cobalt Strike en ejecución. en un anfitrión.
A pesar del parche lanzado por HelpSystems el mes pasado, el primero de estos tres métodos no se ha parcheado por completo, como se describe en el aviso de IBM.
Al abordar la nueva vulnerabilidad en una publicación de blog publicada el lunes, Greg Darwin, gerente de desarrollo de software de HelpSystems, aclaró que RCE podría activarse en casos específicos utilizando el marco Java Swing, el conjunto de herramientas de interfaz gráfica de usuario (GUI) detrás de Cobalt Strike.
“Ciertos componentes dentro de Java Swing interpretarán automáticamente cualquier texto como contenido HTML si comienza con <html>”, explicó Darwin . “Deshabilitar el análisis automático de etiquetas HTML en todo el cliente fue suficiente para mitigar este comportamiento”.
Al mismo tiempo, el experto en seguridad aclaró que la vulnerabilidad no es específica de Cobalt Strike, por lo que la empresa no ha presentado un nuevo CVE para cubrirla.
“La vulnerabilidad subyacente se puede encontrar en Java Swing y se puede explotar en cualquier GUI de Java Swing que represente HTML, no solo Cobalt Strike”.
Dicho esto, Darwin también se disculpó por lanzar dos actualizaciones fuera de banda en cuestión de semanas.