Atacando IOS

Otra de las charlas tradicionales de CCC es la de FX, sobre los ataques a IOS, el sistema operativo de los router de Cisco.

Realmente Cisco tiene un problema mientras mantenga su IOS tradicional y no la sustituya por la IOS-XR: no tiene un sistema operativo en sus routers, no tiene ninguna separación entre los diferentes procesos, usa multitarea cooperativa... y a medida que añaden código para satisfacer a sus usuarios aumentan las posibilidades de fallo.

Por eso FX ha decidido seguir atacando al sistema, y en este caso muestra dos herramientas:

• Un analizador de coredump que permite analizar los ficheros de memoria que se producen cuando el IOS se cae (y el administrador lo ha configurado para escribirlo, cosa que no suele ocurrir porque de ese modo el router tarda más en rearrancar). La herramienta ahora permite enviar un dump online junto con la imagen de IOS que lo generó (eso es fundamental porque lo que hace, entre otras cosas, es comparar la memoria con la descripción que está en los datos del binario original para ver si ha habido cosas modificadas). Esto fundamentalmente permite que si alguien intenta atacar un router, y el exploit falla, se puede ver el código que estaba siendo atacado. Y si simplemente se estaba usando "fuzzing", se puede ver cuáles son las funciones que podrían tener vulnerabilidades.
• Una manera de ejecutar código binario en las IOS que es independiente de la imagen (cada imagen de IOS -- y FX estima que hay unas 100k ejecutándose por el mundo -- tiene una disposición en memoria diferente, lo que dificulta la programación de los exploits), basada en el uso del código de arranque del equipo (la ROMMON), y programar todo en el stack mediante un estilo de programación llamado "return based programming", que básicamente consiste en elegir puntos de entrada en las funciones que hacen lo que queremos (habitualmente escribir en una zona de memoria) a los que llegamos poniendo las direcciones en el stack y ejecutando return. Y al final de todo, volvemos a la zona del stack que estaba antes del "buffer overflow", y cómo si no hubiese pasado nada.

Lo que es más atemorizante de esta demostración es que permitiría la ejecución transitoria de "exploits" en los router (es decir, que no instalan código en el router), por lo que tras abusar del router inocente, éste sigue funcionando como si no hubiese pasado nada (y no se deja ningún rootkit detrás que se pueda detectar -- la herramienta de análisis una de las primeras cosas fue detectar un rootkit escrito por Topo), y sin dejar rastro... ¿para qué dejar un rootkit si ya se tiene acceso root con el "exploit"?

La charla, por supuesto incluía una demo de un exploit transitorio basado en un ping con opciones de "source routing"... nada tremendamente difícil de hacer, aunque evitable si el router tiene el filtrado de acceso adecuado.