Esta semana en seguridad: Dan Kaminsky, excluido del desarrollo principal, el ransomware y las direcciones IPv4 del Pentágono

Esta semana comenzamos con una nota triste, ya que Dan Kaminsky tenía solo 42 años, sobre la cetoacidosis diabética. Dan se dio a conocer al notar una debilidad en la verificación de la respuesta de DNS que podría permitir a los atacantes envenenar el caché de un solucionador de DNS objetivo. Se conocía un ataque teórico en el que las respuestas de DNS paródicas podían colisionar con las solicitudes, pero los valores de tiempo de vida significaban que las solicitudes de DNS salían solo una vez cada ocho horas. El avance indicó que la restricción TTL podría eludirse solicitando subdominios falsos y dirigiendo las respuestas de parodia a esas solicitudes. Esta simple técnica transformó un ataque teórico que tomaría 87 años en un ataque muy real de 10 segundos. Mire el video periódico después de la pausa donde Dan habló sobre sus esfuerzos para resolver el problema.

Lo que quizás sea el trabajo más impresionante es la cantidad de vendedores y cuidadores diferentes a los que convenció para que colaboraran, silenciando la vulnerabilidad. Debido a la gravedad del problema, se decidió esperar para publicar detalles otros 30 días después del parche coordinado. Se necesitaron 13 días para filtrar la vulnerabilidad, pero eso le dio al mundo suficiente tiempo para evitar problemas importantes.

A lo largo de su vida, Dan siempre tuvo la mentalidad de "salir y arreglarlo", lo que inspiró a otros. La mitad de la razón por la que tenemos DNSSEC hoy en día se debe al tenaz cabildeo consecutivo de Dan. Fue una fuerza para siempre y un hacker.

Universidad de Minnesota prohibida por Linux

Una historia se desarrolla durante algún tiempo y, en última instancia, resultó en una prohibición total de los parches básicos enviados por cualquier persona de la Universidad de Minnesota. Este paso extremo es el resultado de parches defectuosos conocidos enviados para su inclusión en el kernel. La idea original era probar si el núcleo sería sensible a un mal actor que enviara un parche malicioso disfrazado de solución. Se escribió un artículo sobre la prueba. Las soluciones propuestas no inspiran confianza, especialmente porque comienzan recomendando una adición al Código de Conducta del proyecto, agregando la promesa de no enviar código malicioso.

El periódico se publicó en 2020, pero la prohibición se produjo hace más de una semana. ¿Por qué? Meses después de que se atendió el incidente inicial, vuelven a llegar bits sospechosos de la misma universidad. La explicación fue que estos nuevos parches fueron generados por una nueva herramienta de análisis de código, pero parecían introducir nuevos errores en lugar de corregirlos. Greg KH dijo que el cuidador desperdició suficiente tiempo tratando con los parches y anunció la prohibición. Mis opiniones se mezclan. Hay una cierta utilidad en probar la comunidad central contra este tipo de ataque, pero también parece ser la decisión apropiada para lanzar el martillo debido al mal comportamiento repetido.

El fin de Emoteto

Europol ha descrito a Emotet como "el malware más peligroso del mundo". El Departamento de Justicia de EE. UU. Estima que 1,6 millones de máquinas formaban parte de esta red de bots, pero gracias a la acción policial global, ya no existe. Para comprender el tamaño de la operación para eliminar Emotet, tenga en cuenta que la cantidad de servidores de Comando y Control (C2) que tuvieron que estar fuera de línea se cuentan por cientos. La acción policial neutralizó la red de bots, pero aún existía el problema de que el malware aún se estaba instalando y ejecutándose en máquinas de todo el mundo.

La solución fue alojar un conjunto de servidores C2 que enviaban un nuevo módulo a todos los infectados. El 25 de abril, este módulo de desinstalación eliminaría la ejecución automática y cerraría cualquier proceso de Emotet en cada máquina infectada. Ese proceso parece haber explotado sin problemas, pero todavía hay una limpieza. Es decir, se obtuvieron 4,3 millones de direcciones de correo electrónico de las máquinas infectadas y se encontraron en los servidores capturados. La policía colaboró ​​con nuestro viejo amigo, [Troy Hunt] de HIBP, y esos correos electrónicos ahora forman parte de la base de datos de ese servicio.

Secuestro de datos

Pasé algunas semanas ocupado con noticias sobre ransomware. Apple está lidiando con una demanda de ransomware de 50 millones de dólares. Acer también enfrenta una demanda similar del mismo grupo, REvil. En el caso de Apple, la infracción real aparentemente se produjo en sistemas propiedad de Quanta, uno de los proveedores de Apple. Se ha sugerido que REvil utiliza las vulnerabilidades recientes de Microsoft Exchange para acceder a las redes de destino.

Los dispositivos de QNAP también impactan con fuerza. Hemos cubierto algunas de las vulnerabilidades, pero los esquemas de ransomware están afectando activamente a los dispositivos NAS sin chip expuestos a Internet. Qlocker es un ataque que se destaca por su simplicidad. Los atacantes simplemente administraron un comando remoto a través de 7zip para generar archivos protegidos con contraseña, y parece que ganaron casi $ 300,000 en solo una semana de operaciones maliciosas. Un héroe emergió de la historia cuando [Jack Cable] intentó ayudar a un amigo a recuperar datos y descubrió una vulnerabilidad en el sistema de pago criminal. El uso de la ID de transacción, pero con un carácter cambiado a mayúsculas, fue suficiente para confundir al sistema y ceder la clave de descifrado. Aproximadamente 50 víctimas recuperaron sus datos utilizando este truco antes de que fueran capturados y reparados.

Las direcciones IPv4 de El misterio del Pentágono

The Washington Post comenzó a cubrir una historia en evolución única. Millones de direcciones IPv4 no utilizadas asignadas al Departamento de Defensa de EE. UU. Se enviaron repentinamente por primera vez. (Tenga cuidado con el muro de pago, aunque deshabilitar JavaScript podría ayudarlo temporalmente a leer la historia vinculada). La historia ocurre la mayor parte del tiempo, ya que la ruta parecía liberarse en los pocos minutos entre el juramento de un presidente y el final real. de la administración anterior. Mi primera respuesta fue molestia porque una política estaba incrustada en lo que probablemente era una simple historia de seguridad. Parecía que el Post estaba tratando de encontrar una historia sensacional para poner en acción. Pero el clima era realmente extraño. Entonces, ¿qué está pasando aquí?

Así que primero revisemos algo de contexto. El mundo se está quedando sin direcciones IPv4; ya se está acabando, dependiendo de cómo las calcule. Si bien todos fueron asignados técnicamente, en los primeros días de Internet, se recibieron algunas direcciones muy grandes y nunca se utilizaron por completo. Una red de Clase A contiene 16 millones de direcciones, y se dieron como un regalo en los primeros días, y el Departamento de Defensa tiene varias. Luego, vale la pena señalar que al Congreso le divirtió la idea de obligar al Departamento de Defensa a vender sus direcciones IP no utilizadas. Una vez que se agota el suministro, las direcciones IPv4 no utilizadas pueden obtener un precio bastante alto en el mercado libre. La última cosa notable es que solo porque nada usa activamente una dirección IP, todavía hay tráfico de red hacia y desde allí. Varios gusanos y escáneres web recorren constantemente todo Internet, y los ataques DDoS suelen utilizar paquetes UDP con direcciones de origen aleatorias. Las encuestas y el tráfico correspondiente pueden ser una fuente valiosa de información en tiempo real sobre lo que está sucediendo en Internet.

Ahora hubo cobertura de voces más experimentadas e incluso una respuesta críptica del Departamento de Defensa. El creciente consenso parece ser un trío de explicaciones de lo que está sucediendo. El primero es el más simple. Se sabe que ocurre ocupación de IP, y si nadie anuncia las rutas del Border Gateway Protocol (BGP) para el espacio de IP, es mucho más fácil usar direcciones ilegalmente. Al requerir las direcciones IP sobre BGP, el Departamento de Defensa protege esas direcciones IP. En segundo lugar, es mucho más fácil defenderse de un congreso que quiere eliminar recursos si puede hacer una afirmación válida de que está utilizando esos recursos. Y finalmente, parece que una parte del Departamento de Defensa está haciendo análisis del ruido de fondo de Internet y la propagación de la reacción recibida del espacio de red que de otro modo no se utilizaría.

Hay una pregunta final: ¿Por qué el proyecto comenzó literalmente en los últimos minutos de administración? ¿Era una especie de trama sucia? No es probable. Un proyecto de esta magnitud necesitaría algo de tiempo para pasar de la idea inicial a la implementación, y probablemente sería necesario firmarlo con gerencia avanzada. Aunque no estoy seguro de por qué se inició el cambio tan tarde, creo que es muy probable que si hubiera sucedido más tarde, gran parte de la burocracia tendría que ser reconsiderada por segunda vez, y la nueva administración lo haría. Necesito firmarlo.

Daño del núcleo de Drupal

Cubrimos lagunas en extensiones de Drupal, complementos de WordPress y complementos de Joomla. Lo que es bastante raro es una vulnerabilidad importante en el código central de uno de estos proyectos. Eso no significa que no suceda. Por ejemplo, Drupal tiene una vulnerabilidad a Cross Site Scripting en su código central. XSS generalmente aparece como una forma para que un usuario inyecte javascript en un comentario que se ejecuta cuando otros usuarios visitan el sitio. Esto puede ser tan benigno como que un usuario se convierta repentinamente en la cuenta más amigable en myspace, o tan malicioso como un comentario que convierte al comentarista en administrador cuando el propietario del sitio intenta moderar el comentario capturado. Todavía no hay muchos detalles disponibles sobre esto, pero asegúrese de que sus instalaciones de Drupal estén actualizadas.

Nuevo y antiguo backdoor de Linux

La semana pasada, se descubrió algo de malware de Linux y luego se encontró en un cargador de archivos de 2018. Llamada RotaJakiro, esta puerta trasera usa un puñado de técnicas para evitar la detección, como rotar usando métodos de cifrado al contactar servidores de comando y control. Es un poco preocupante saber que ha existido durante tanto tiempo sin darme cuenta hasta ahora. Afortunadamente, existen algunos indicadores de compromiso (IoC) simples, como un par de nombres de archivo y cuatro posibles sumas md5 para esos archivos. Pensé que sería interesante documentar el proceso de verificación de un sistema para estos archivos.

Mi primer pensamiento fue una simple combinación de find para enumerar todos los archivos en el sistema, y ​​luego grep busque el nombre del archivo.
sudo find / | grep systemd-daemon

Podemos mejorar esto eliminando el grep orden, ya que find construido en el discurso del nombre. Para los puntos de bonificación, utilizamos xargs continúe y calcule el md5sum cuando se encuentre un archivo compatible.

sudo find / -name "gvfsd-helper" -o -name "systemd-daemon" | xargs md5sum

Puede haber un problema si los nombres de los directorios contienen espacios u otros caracteres especiales, xargs vería los caracteres especiales como una pausa entre entradas. Afortunadamente, ambos find y xargs tiene un modo delimitado por cero donde se conservan los caracteres especiales. El corchete de escape es necesario para especificar que el -print0 La bandera se aplica a ambos patrones específicamente nombrados.

sudo find / ( -name "gvfsd-helper" -o -name "systemd-daemon" ) -print0 | xargs -0 md5sum

Mostré este delineador e inmediatamente me acordé de eso find también tiene -exec bandera que se usa xargs superfluo.

sudo find / ( -name "gvfsd-helper" -o -name "systemd-daemon" ) -exec md5sum {} ;

Así que esto nos da una línea simple de una línea que contará el md5sum de cualquier archivo con un nombre de archivo sospechoso. Si obtiene una coincidencia, compare los valores resultantes con los IoC conocidos. Con suerte, ninguno de nosotros encontrará esta mierda en particular en nuestros sistemas, pero es mejor saberlo.

  • Ostraco dice:

    “Hemos cubierto algunas de las vulnerabilidades, pero los esquemas de ransomware están afectando activamente a los dispositivos NAS sin chip expuestos a Internet. "

    Creo que veo el problema.

Nora Prieto
Nora Prieto

Deja una respuesta

Tu dirección de correo electrónico no será publicada.