Esta semana en seguridad: John Deere, ProxyLogin detallado y tubos neumáticos

Nos hemos ocupado del derecho a arreglar una saga, y una de las empresas que se ha hecho bastante conocida es John Deere. El otro lado del lío vinculado mal gestionado son los problemas de seguridad. Hay una cierta ironía sobre cómo comenzó esta historia: alguien notó que los equipos John Deere no tenían CVE en absoluto. Una persona normal podría pensar que esto debe significar que sus productos son muy seguros, pero un investigador de seguridad sabe que algo más interesante está funcionando. Nuestros viejos amigos [Sick Codes], [John Jackson], y muchos otros vieron esto como una señal segura de que se habían encontrado muchas vulnerabilidades, y parece que eran correctas.

Acceso remoto y código de 2014 ...

Las vulnerabilidades incluían un puñado de ataques de secuencias de comandos de Internet, desvío auténtico por contrabando de solicitudes, seguridad mal configurada, inyecciones de SQL, RCE y más. En conjunto, estas vulnerabilidades permitieron un control total del sistema John Deere, incluida la capacidad de manejar todo el equipo conectado al sistema.

Durante la presentación de Defcon, enlazada a continuación, [Sick Codes] recordó el momento en que se dieron cuenta de que estaban trabajando en un problema importante. En lugar de quejarse de que no se le paga por las vulnerabilidades encontradas, un colaborador simplemente notó que estaba evaluando comer alimentos. Un ataque coordinado al equipo JD podría causar problemas importantes para un conjunto de granjas en un país.

Terminaron contactando a CISA, debido a la falta de una respuesta seria por parte de los proveedores. CISA se tomó en serio la amenaza y los problemas se hicieron cargo. Este no es un problema que se limite a una sola empresa. Case tenía problemas similares que también se solucionaron, y se dio a entender que otros proveedores tienen problemas similares que aún se están abordando.

Octal IP ataca de nuevo

Mientras hablamos de [Sick Codes] y su grupo gay de investigadores, hay algunos casos más de análisis incorrecto de direcciones IP con formato de octetos anunciadas. Estas son las bibliotecas de red Rust std :: net y Golang, las cuales solo eliminan los ceros iniciales de las direcciones IP. De cualquier manera, la solución es simplemente tratar esto como una dirección inválida. Por qué es un problema? Porque puede usar direcciones IP ocultas, como 0127.0.0.1. Una biblioteca con conciencia octal ve esto como 87.0.0.1, mientras que una biblioteca con esta vulnerabilidad la ve como un host local. El problema real surge cuando los distintos servicios web utilizan ambos enfoques. Si puede dominar o parodiar una de estas direcciones mágicas, podría conectarse al servicio y tener privilegios como si estuviera usando una IP interna. Para obtener más información, consulte la charla DEF CON sobre este tema.

Intercambiar RCE

¿Recuerda ProxyLog? Este es el ataque de Microsoft Exchange que hemos estado luchando colectivamente desde principios de este año. Finalmente ha llegado el momento del resto de la historia. Continuando con la cobertura de nuestra conferencia, [Orange Tsai] detalló esta vulnerabilidad y anunció un par de nuevas vulnerabilidades de intercambio en Black Hat, incluida otra cadena que conduce a RCE sobre el puerto 443. Si eso no fuera suficiente, ya hay ataques activos que aprovechan esta nueva falla.

Esta nueva investigación surge de un cambio de arquitectura en Exchange 2013, donde el servicio web se dividió en front-end y back-end. Esto tiene todo tipo de consecuencias extrañas, como el hecho de que el sistema posterior escucha todas las interfaces de forma predeterminada. ¿Otro? El front-end no verifica el host en busca de solicitudes entrantes, por lo que un atacante puede ingresar cualquier texto arbitrario allí. Esto incluye un nombre de host y un puerto completamente diferentes, así como caracteres inesperados. Ponerlos juntos correctamente da como resultado una SSRF arbitraria: el atacante puede especificar cualquier punto final, ya sea en la Internet pública o en el propio servidor. Una vez que el front-end normal al back-flow se ve comprometido, es bastante fácil abusar de un endpoint interno para obtener privilegios de escritura arbitrarios y RCE. Ese es el ataque ProxyLogon en resumen.

El nuevo RCE se conoce como ProxyShell. Hace un mal uso del punto de descubrimiento pre-auténtico, destinado a permitir la configuración automática para los clientes. Agregar el punto final deseado a una solicitud de detección automática válida actúa como una herramienta SSRF. El ataque consiste en utilizar esta SSRF para realizar una solicitud al endpoint / powershell. Combinado con una carga útil basada en la web cargada como borrador, esto da como resultado otro RCE preauténtico. Afortunadamente, estos ataques ya se han reparado, pero todavía hay demasiados sistemas que aún no están actualizados.

Pulse con seguridad derrotado por alquitrán

Esta historia comienza con CVE-2020-8260, una vulnerabilidad de escritura de archivo arbitraria en dispositivos Pulse Connect Secure donde no se verificó la configuración cargada para el cruce de ruta durante la extracción. Un archivo tar malicioso podría insertar archivos en cualquier lugar a través de ./../ carreteras. Esto se corrigió en 2020, pero algunas ediciones más tarde, se reveló y se corrigió CVE-2021-22900. Era un problema extrañamente similar, y [Rich Warren] del Grupo NCC decidió investigar. Se agregó la solución original validateTarFile una función que parece estar muy bien hecha algún trabajo. Controla ../ patrones, simuladores o enlaces duros. Además de eso, tiene una lista blanca de archivos permitidos. Sería la solución perfecta si solo se usara cada vez que se carga un archivo. Desafortunadamente, esta sólida solución solo se usó al cargar un archivo de configuración. La segunda solución fue agregar la llamada a validateTarFile a todas las demás funciones de carga.

Armado con este entendimiento, la pregunta natural era si todas las circunstancias de carga de archivos se habían solucionado adecuadamente. Mientras lo discutimos, probablemente habrá adivinado que algo salió mal. Cuando se carga un archivo de configuración, los parámetros del mensaje POST definen el tipo de carga. Una base de datos de creación de perfiles se trata de manera diferente y esta ruta de código no incluye la función de validación, lo que conduce a CVE-2021-22937. Parece que esta ruta de código es inaccesible para el uso normal, pero modificar los parámetros de la solicitud es trivial. Esta serie de vulnerabilidades se limita a un atacante con acceso administrativo al dispositivo, mitigando en gran medida su gravedad. Dicho esto, el acceso al sistema de archivos subyacente abre un mundo completamente nuevo de amenazas persistentes. Dependiendo de cómo se implemente, dicho enraizamiento podría sobrevivir al restablecimiento de fábrica.

Pruebas API 101

Los buenos de Detectify han lanzado una divertida introducción a las pruebas de API en línea. La primera mitad del póster está dedicada al uso de Postman para esa investigación. Parece una herramienta útil, pero parece estar cerrada, desafortunadamente. La segunda mitad del artículo aborda algunos problemas comunes en las API en línea y los pensamientos de mitigación. Se discuten algunas deficiencias obvias, como las API privadas expuestas accidentalmente al público. Por otro lado, hay algunos buenos consejos para buscar fallas más oscuras, como la inyección XXE (entidad externa XML). En total, vale la pena leerlo rápidamente, especialmente si no le importa ejecutar una herramienta de código cerrado como parte de su equipo.

Serie de tubos neumáticos

Es posible que esté mejor familiarizado con un sistema de tubo neumático (PTS) de un banco o farmacia escuchando (o viendo Futurama), pero también se utilizan ampliamente en hospitales, entre otros lugares. Los investigadores de Armis anunciaron recientemente PwnedPiper, un conjunto de problemas con la implementación del PTS de Swisslog Healthcare. ¿Uno de los peores problemas? Sus paneles de control son sistemas Linux, con un kernel 2.6.35. Ese es un núcleo de 10 años. ¿Recuerdas ese blog de seguridad de Google de la semana pasada? Ese es el tipo de tonterías que pensaban.

El resto del sistema es igual de malo, con conexiones de escucha abiertas del servicio Telnet y una contraseña codificada común a todos los dispositivos. Todos los errores de corrupción de memoria múltiples permiten RCE, y el protocolo de comunicación principal no está encriptado ni autenticado, sin mencionar que se basa en UDP. Y finalmente, el proceso de actualización del firmware se basa en este mismo protocolo, completamente sin una función de firma firme. En pocas palabras, si puede acceder a la red Ethernet que administra este PTS, puede poseer trivialmente todo el sistema.

¿Qué tan malo podría ser eso si realmente fuera explotado? Solo tenga en cuenta que las muestras biológicas no solo se envían a través de este sistema, al igual que los medicamentos. Uno solo puede imaginar cuántos problemas podría causar la aceleración de los destinos. Un atacante más malintencionado podría utilizar razonablemente un ataque de este tipo para robar o reemplazar medicamentos. Parece la trama de un episodio de Misión Imposible, pero la verdad a veces es mucho más extraña que la ficción.

Titulares de última hora

El lector de PDF Foxit lanzó recientemente 11.0.1, solucionando una gran cantidad de problemas, incluidos 8 CVE separados que podrían conducir a RCE. Si eres uno de los usuarios de esta popular alternativa a Adobe, ¡asegúrate de estar actualizado!

Como si necesitáramos algo más para interrumpir la cadena de suministro electrónico, Gigabyte se ha visto afectado por el ransomware, con la amenaza adicional de que se filtrarán 112 GB de datos. Para exacerbar esa amenaza, muchos de los datos están sujetos a un acuerdo de confidencialidad, lo que puede causar consecuencias adicionales para Gigabyte si se hacen públicos. Hasta ahora no se sabe cuánto sería el rescate.

Ha resurgido otra historia que creíamos muerta. Hay otra cola de impresión de 0 días. Esta es otra vulnerabilidad en términos de apuntar e imprimir, pero esta vez va en contra de la máquina que está intentando usar una impresora remota maliciosa. La vulnerabilidad anterior de este tipo era inalcanzable siempre que el apuntar y la impresión estuvieran deshabilitados, que era la configuración predeterminada. La junta de Microsoft no incluye esto como una solución para esto. Esto parece funcionar en una configuración estándar. Para colmo de males, el investigador del informe reveló esta falla en diciembre de 2020.

América Aguilar
América Aguilar

Deja una respuesta

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