¿Recuerda el Dieselgate, el escándalo en el que ciertos vehículos diésel detectaban una prueba de emisiones y funcionaban de manera más limpia, “haciendo trampa” en la prueba? Traingate puede poner eso en perspectiva. Contaremos la historia desde el principio, pero prepárate para un viaje salvaje y sorprendente. Todo comienza con la revisión de mantenimiento de los trenes polacos. Estos trenes fueron construidos por Newag, que licitó por el contrato de mantenimiento, pero el contrato lo ganó otra empresa, SPS. Este tipo de revisión implica dividir cada tren en sus componentes, inspeccionarlo, lubricarlo, etc., y volver a armarlo todo. El primer tren pasó por este proceso, fue completamente reensamblado y luego se negó a moverse. Después de agotar todas las medidas convencionales de solución de problemas, SPS trajo a los piratas informáticos.
Dragon Sector es un grupo de investigación polaco que ganó atención mundial por trabajar en la seguridad del BIOS de la computadora portátil Toshiba. Y resulta que éste era el grupo perfecto para el trabajo. Desde improvisar hardware hasta mejorar el soporte de Ghidra para la arquitectura Infineon TriCore, se trabajó mucho para incluso lograr un punto de apoyo en los sistemas del tren. Pero finalmente pudieron hacer volcados de memoria y comparar el tren averiado con los que funcionaban. Había un conjunto de indicadores de configuración que parecían contener la clave. Pero este tren en particular era muy necesario en servicio. Así que finalmente se contactó a Newag, el fabricante original, para completar el mantenimiento y hacer que el tren volviera a funcionar. Sin embargo, los hackers no son más que persistentes. Después de pasar toda la noche y literalmente con minutos de sobra, Dragon Sector pudo sobrescribir la memoria del tren averiado con una configuración válida, y una vez más volvió a la vida.
Hasta el momento nada aquí parece sospechoso. Las comprobaciones de inicio después del mantenimiento podrían fallar fácilmente y provocar este tipo de situaciones. Pero Dragon Sector siguió cavando, refinando sus herramientas y descubriendo más secretos del firmware del tren. Y lo que encontraron fue sorprendente. Lo primero que aparecieron fueron las coordenadas GPS, correspondientes a cada estación de trenes en Polonia capaz de realizar este tipo de revisión de mantenimiento. Si un tren estuviera estacionado dentro de cualquier patio de mantenimiento que no fuera el de Newag durante más de 10 días, la bandera se activaría y el tren quedaría inutilizado. Es difícil ver esa “característica” como algo más que un intento descarado de bloquear cualquier tren que no regrese a Newag para su mantenimiento. Pero espera hay mas.
Reemplazar ciertos componentes provocaría una rotura similar, hasta que se introdujo un código de trampa no documentado en la consola de la computadora principal del tren. En otro caso, un tren se averiaría tras recorrer un millón de kilómetros. Otro tren más estaba programado para averiarse por un compresor defectuoso en una fecha determinada, y un error de programación retrasó esa avería hasta un año después. En total, Dragon Sector examinó 29 trenes en Polonia y encontró estas pequeñas sorpresas maravillosas en 24 de ellos. A través del CERT Polska de Polonia, se ha notificado este caso a las autoridades encargadas de hacer cumplir la ley.
En respuesta, Newag ha acusado a Dragon Sector de difamación y delitos informáticos, además de ser amenazas para la seguridad ferroviaria. Todo lo que podemos decir es que esperamos que una investigación exhaustiva establezca la verdad del caso y haga rendir cuentas a los verdaderos criminales.
Siempre es DNS
¿Alguna vez se preguntó cómo obtiene un servidor DNS actualizaciones sobre los nombres DNS? Resulta que hay un par de maneras. Una es que los clientes envíen actualizaciones directamente, anunciando su nombre DNS y dirección IP. Las actualizaciones dinámicas de DNS son compatibles con múltiples servidores DNS, incluido Active Directory (AD), y en casi todas las implementaciones esto tiene una implementación de seguridad razonable. Por otro lado, también se envían actualizaciones de DNS como parte de una solicitud de DHCP. Y esos… tener problemas.
Este artículo está muy centrado en Active Directory, pero no nos sorprendería encontrar un problema similar en otros servidores DHCP. Es decir, la actualización de DNS no está autenticada. Cualquier dispositivo al que se le proporcione una dirección IP puede solicitar un nombre DNS al mismo tiempo. La forma en que esto funciona en un entorno de servidor de Microsoft es que el servicio DNS utiliza sus propias credenciales para reenviar la actualización de DNS al servidor DNS. Si se trata de dos servidores separados y el nombre ya está registrado directamente en otro host, la actualización fallará. Pero un nombre no reclamado, o incluso el nombre del servidor DHCP, están en juego. Y en el caso de los servicios DNS y DHCP que se ejecutan en el mismo servidor, prácticamente cualquier nombre DNS está en juego. Y en un entorno AD, eso permite todo tipo de ataques adicionales a la autenticación.
Estos problemas se han informado a Microsoft, quien los considera problemas conocidos que no merecen una solución de seguridad. Vale la pena conocerlos al construir una red AD. Para ayudarnos a evitar problemas, Akamai ha escrito Invocar-DHCPCheckup como herramienta de PowerShell para comprobar si hay problemas.
Haz la diapositiva JMP
Hay una técnica que se utiliza al escribir exploits, la diapositiva NOP. Es una serie de comandos sin operación seguidos del código shell de destino. La idea es que una vulnerabilidad salte a algún lugar de esta área de memoria controlada por el atacante, pero el destino exacto puede variar. Esto se usa con tanta frecuencia que los bloques de 0x90 en los datos son uno de los indicios de que puede ser malicioso. Hay un problema con la diapositiva NOP, ya que puede tomar más tiempo del deseado completar todas las instrucciones NOP para llegar al jugoso código shell. Y ahí es donde la diapositiva JMP entra en juego.
La base es que sabemos cuántos bytes quedan en la diapositiva, por lo que podemos usar instrucciones JMP para ir directamente a la carga útil. Eso es genial, excepto por la alineación. Es decir, el código de máquina x86 mezcla libremente instrucciones y argumentos. Si no sabe exactamente dónde aterrizará la instrucción en su búfer, ¿cómo sabe si está a punto de ejecutar un jmp o ejecutar el desplazamiento como una instrucción? Hay un par de formas obvias de abordar esto, como usar valores 0x90 como argumento para JMP, seguido de una zona de deslizamiento NOP mucho más pequeña para capturar el JMP.
Ése también es un desafío, porque el comando JMP se basa en compensaciones que pueden ser positivas o negativas, y 0x90 resulta ser una compensación negativa. Eso puede funcionar, pero toda la carga útil del código shell debe construirse al revés para administrarla. Hay otra opción, los códigos de operación JCC de salto condicional. Estos son 0x70-0x7F en código de máquina, que logra ser compensaciones positivas. El único problema es que estos saltos están condicionados a un valor de registro que se desconoce. La solución final es utilizar el código de operación Jump if Greater dos veces, seguido del código de operación Jump if Less o Equal dos veces. Ambas son compensaciones positivas, y ambas hacen un progreso constante a través de la diapositiva JMP para eventualmente aterrizar en una pequeña diapositiva NOP para finalmente ejecutar shellcode. ¡Inteligente!
Bits y Bytes
Después de ser despedido, puede resultar tentador quemar los puentes al salir. Si eso incluye borrar repositorios de códigos, eliminar archivos de registro, llevarse a casa código propietario, robar una computadora portátil del trabajo y hacerse pasar por colegas... tal vez no. Un ingeniero de software del First Republic Bank simplemente no pudo resistir la tentación y cumplirá dos años de prisión, tres años de libertad condicional y pagará 529,000 dólares en restitución por daños y perjuicios. Definitivamente no vale la pena.
Y para recordar por qué no es necesario que todo esté conectado a la red o a Internet, consulte Las consecuencias del ciberataque a Kyivstar en Ucrania. Este proveedor de telefonía e Internet fue eliminado el martes, en lo que parece ser un devastador ataque de borrado de datos. Los bancos y tiendas están cerrados debido a que el procesamiento de pagos no funciona, y al menos una ciudad tuvo que desconectar manualmente las luces de sus calles de la red eléctrica, porque el controlador de software fue desactivado como subproducto del ataque. Quizás, después de todo, los viejos cronómetros mecánicos eran mejores.
- Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
- PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
- PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
- PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
- PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
- Fuente: https://hackaday.com/2023/12/15/this-week-in-security-traingate-dns-and-jmp-slides/
