Mochis NoticiasTecnologíaEsta semana en seguridad: Kaspersky Ban, Project Naptime y más
Mochis NoticiasTecnologíaEsta semana en seguridad: Kaspersky Ban, Project Naptime y más
Tecnología

Esta semana en seguridad: Kaspersky Ban, Project Naptime y más

La noticia candente de esta semana es que Kaspersky está prohibido en Estados Unidos. Más específicamente, se prohibirá la venta de productos Kaspersky en los Estados Unidos a partir del 29 de septiembre. Esta prohibición se extenderá al bloqueo de actualizaciones de software, aunque no está claro cómo se llevará a cabo realmente. Es razonable suponer que los procesadores de pagos bloquearán los pagos a Kaspersky, pero ¿se exigirá a los ISP que bloqueen el tráfico que pueda contener actualizaciones de antivirus?

Puerta trasera del complemento de WordPress

Recientemente se ha descubierto que un cuarteto de complementos de WordPress incluyen código de puerta trasera. Es una colección de cinco complementos de código abierto, aparentemente desarrollados por personas no relacionadas. Las actualizaciones maliciosas aparecieron por primera vez el 21 de junio y parece que los cinco complementos envían el mismo código malicioso.

API de IA de conejo

El Rabbit R1 fue lanzado con un aplauso poco estruendoso. La idea es un dispositivo personal de inteligencia artificial, pero la ejecución ha sido decepcionante, hasta el punto de que los revisores sugieren que algunas de las afirmaciones anteriores han sido inventadas. Ahora parece haber un problema de seguridad grave, en forma de claves API expuestas que tienen *mucho* demasiados privilegios.

La investigación parece haber sido realizada por el grupo Rabbitude, que encontró las claves en mayo. De las cosas que permitía el acceso a las claves API, la más preocupante para la privacidad del usuario era el acceso a cada llamada de texto a voz. Rabbitude afirma en su publicación del 25 de junio que «rabbit inc sabía que teníamos su clave API de elenlabs (tts) durante un mes, pero no tomó ninguna medida para entregar las claves API». Por otro lado, el conejo hizo un comunicado el día 26, afirmando que ese día se habían dado cuenta del problema e hicieron la rotación de llaves necesaria de inmediato.

MOVEit ha vuelto

El año pasado, una vulnerabilidad grave en el servidor de transferencia de archivos MOVEit provocó algunos compromisos importantes en 2023 y 2024. MOVEit ha vuelto, esta vez revelando una omisión de autenticación. El viaje para encontrar esta vulnerabilidad comienza con una excepción, que se produce cada vez que se intenta una conexión SSH con una clave pública.

… el servidor está intentando abrir los datos binarios que representan nuestro material de autenticación, como una ruta de archivo, en el servidor.

UH oh. No hay manera de que eso sea correcto. Lo que es peor, esa ruta puede ser una ruta SMB externa. Eso es aun peor. Este comportamiento depende de que la conexión entrante haga referencia a un nombre de usuario válido, pero esto tiene el potencial de permitir el robo de contraseñas, ataques de paso de hash y mapeo de nombres de usuario. Entonces, ¿qué está pasando realmente aquí? El servidor SSH utilizado aquí es IPWorks SSH, que tiene algunas adiciones útiles a SSH. Una de estas adiciones parece ser un extraño esquema de autenticación delegada que en este caso sale terriblemente mal.

El flujo de ataque es el siguiente: cargue una clave pública SSH en cualquier ubicación del servidor MOVEit, inicie sesión con cualquier nombre de usuario válido que firme la conexión con la clave cargada y envíe la ubicación del archivo de clave cargado en lugar de la clave real. Un servidor extrae la clave, se asegura de que coincida y te deja entrar. Lo único molesto es cómo cargar una clave sin una cuenta. Resulta que el servidor admite claves PPK, y éstas sobreviven cuando se escriben y se leen en los registros del sistema. Ay.

Los defectos se solucionaron hace meses y se hizo un gran esfuerzo para alertar a los clientes de MOVEit y solucionarlos. Por otro lado, ahora está disponible una prueba de concepto (PoC) completa y los grupos de monitoreo de Internet están comenzando a ver que el ataque se intenta en la naturaleza.

Archivo de gato: Pop Calc

Todos sabemos que no debemos confiar en los archivos de Internet. No ejecute el script, no cargue la hoja de cálculo y definitivamente no instale el paquete. Pero ¿qué pasa con el liderazgo? cat o strings en un archivo que no es de confianza? Aparentemente, la magia de las cuerdas de escape también las hace peligrosas. La terminal iTerm2 se configuró accidentalmente para permitir «informar el título de la ventana» o copiar el título de la ventana a la línea de comando. Otro código de escape puede establecer ese valor, lo que hace que sea una manera fácil de poner un comando arbitrario en la línea de comando. Una peculiaridad más en forma de integración tmux permitió la inyección de una nueva línea: la ejecución del comando arbitrario. Ups. Las versiones 3.5.0 y 3.5.1 son las únicas versiones de iterm2 que son vulnerables, y la versión 3.5.2 contiene la solución.

Poner LLM a trabajar durante la siesta

Ha habido una plaga de informes de vulnerabilidad falsos, en los que alguien le pidió a ChatGPT que encontrara una vulnerabilidad en un proyecto con una recompensa por errores. Primero que nada, hazlo. Pero en segundo lugar, sería realmente útil si LLM realmente encontrara vulnerabilidades. Esta idea intrigó a los investigadores del Proyecto Cero de Google, por lo que investigaron un poco y lo llamaron «Proyecto Naptime», con una referencia divertida a tomar una siesta mientras se trabaja en el LLM.

La salsa secreta parece estar en extender LLM para ver código real, ejecutar scripts de Python en una zona de pruebas y tener acceso a un depurador. Los resultados fueron realmente alentadores: el LLM podría llegar a ser una herramienta útil. No reemplazará al investigador, pero no me sorprenderá cubrir las vulnerabilidades encontradas por LLM en lugar de una herramienta de fuzzing. ¿O tal vez sea un fuzzer guiado por LLM?

Platos de Github en Chrome RCE

de github [Man Yue Mo] descubrió e informó CVE-2024-3833 en Chrome en marzo, se lanzó una solución en abril y ahora es el momento de obtener los detalles. Se trata de cómo interactúan la clonación de objetos y el almacenamiento en caché de código. La clonación de un objeto en una circunstancia dada termina con un objeto que existe en una superposición entre campos de propiedades no utilizados y, sin embargo, un rango de propiedades completo. O simplemente, el estado del objeto interno indica incorrectamente que hay memoria asignada no utilizada. Intente escribir una nueva propiedad y está fuera de los límites de escritura.

Se trata de una explotación total, pero todo incluye también un escape de la zona de pruebas, utilizando funciones WebAssembly sobrescritas. Cosas impresionantes.

Bits y Bytes

[Works By Design] estás dando un segundo intento para construir una cerradura que no se pueda abrir. Tiene algunas características interesantes, como un sistema de resorte con rodamiento de bolas que debería significar que al hacer palanca en un pasador en su lugar, el resto se mueve fuera de su posición. Un cerrajero local no pudo recogerlo, le dieron poco más de media hora. La verdadera prueba será lo que suceda cuando [LockPickingLawyer] él le pone las manos encima, lo que aún está por llegar.

Gitlab acaba de solucionar un problema crítico que amenazaba con permitir a los atacantes ejecutar canalizaciones de CI como usuarios arbitrarios. Los detalles completos aún no están disponibles, pero CVE-2024-5655 afecta a CVSS 9.6 y Gitlab «recomienda encarecidamente» actualizaciones inmediatas.

Source link

Hi, I’m Corina Guzman

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *