Otros ataques usando Delorean

Pégale un vistazo a otros posts de esta serie:

[1] NTP MitM con Delorean

[2] Sincronización de tiempos en Mac OS X

[3] Sincronización de tiempos en Fedora / Ubuntu

[4] Sincronización de tiempos en Microsoft

[5] Atacando HTTP Strict Transport Security

[6] Atacando la Infraestructura de Clave Pública (PKI)

[7] Otros ataques
[8] Herramientas de ayuda

Descargo de responsabilidad: Toda la información se ha obtenido de una forma empirica, realizando pruebas, y en un periodo de tiempo concreto, con lo que puede haber cambiado en el momento de leer este artículo.

Los ataques que hemos estado viendo en los artículos anteriores son los que considero que son más probables y que tienen un mayor impacto. Sin embargo, también estuve probando otras opciones utilizando ataques de sincronización. Algunos de ellos funcionaros,  pesar de ser poco probables, y otros de ellos no funcionaron en absoluto.

Uno de los ataques que funcionó fue un ataque contra el planificador de taras de Windows. Como probablemente sepáis, hay un servicio que corre en las máquinas Windows que se encarga de ejecutar ciertas tareas de mantenimiento en segundo plano, como por ejemplo la propia tareas de sincronización de hora.

El planificador de tareas guarda la información de la última vez que una tarea se ejecutó, y la siguiente vez que lo hará. Estos campos son importantes porque, depende de como se haya configurado la tarea, el "Next Run Time" a veces se calcula en base al "Last Run Time", lo cual nos da la oportunidad de manipular la siguiente ejecución de la tarea si conseguimos manipular al reloj usando Delorean.

No todas las tareas calculan la hora de la siguiente ejecución de esta manera, pero hay algunas tareas interesantes que sí que lo hacen, como por ejemplo el servicio de actualizaciones automáticas de Windows.

¿Qué ocurre entonces si manipulamos el reloj usando Delorean, tal y como vimos en anteriores artículos, y la tarea de actualizaciones automáticas es ejecutada? Pues que el "Last Run Time" se ejecutará con la fecha manipulada (por ejemplo, 2020), así que la siguiente ejecución de la tarea se calculará en base a esta fecha, es decir, ocurrirá en algún momento de 2020. Esto no debería ser un problema siempre y cuando el equipo se mantenga con la fecha manipulada para siempre, pero si en algún momento el equipo vuelve a la fecha original... la siguiente ejecución del servicio de actualizaciones automáticas no se ejecutará en los próximos 4 años, con lo que el usuario no será advertido de la existencia de nuevas actualizaciones y parches de seguridad si no lo comprueba manualmente.

En realidad, este es un ataque poco problema, ya que Windows es la plataforma en la que es más complicado realizar un ataque con Delorean, y porque al menos yo no encontré una manera de devolver el reloj a su hora original sin la intervención del usuario. Sin embargo, otras tareas y otras plataformas (como cron en Linux, por ejemplo) podrían también ser manipuladas de una manera similar.