Con la que se lió hace ya unas cuantas semanas con WannaCry y, más recientemente, con NotPetya, se está empezando a oír de nuevo  aquella famosa letanía de que los sistemas con Windows son mucho más inseguros que los que disponen de un kernel Linux/UNIX.

Sin mucho ánimo de meterme en el debate -dado que habría que realizar un análisis bastante pormenorizado del asunto-, quería exponer un par de ejemplos por los que esa aseveración no debería ser tan contundente.

En primer lugar, me gustaría apuntar que a los pocos días de lanzarse la campaña de WannaCry que tantos estragos hizo a nivel global, se publicó la vulnerabilidad CVE-2017-7494 (24 de mayo de 2017) la cual algunos pasaron a denominar SambaCry o EternalRed. Esta vulnerabilidad permite ejecución remota de código en sistemas que corran una muy larga lista de versiones de Samba empezando por la 3.5.0. A pesar de ser muy crítica, he de decir que esta vulnerabilidad es algo más restrictiva que la MS17-010 dado que requiere de algunas casuísticas previas para la explotación, las cuales están relacionadas con los usuarios y la capacidad de escritura en el sistema de ficheros compartido.

En segundo lugar quería hablar de Stack Clash (CVE-2017-1000367) una vulnerabilidad publicada a primeros de junio que permitiría un escalado de privilegios. La gravedad de este asunto es, que debido a que el origen de la vulnerabilidad se encuentra en algo tan básico como la gestión de la memoria (concretamente de la región de la pila, por eso lo de stack en el nombre), esta vulnerabilidad es explotable en multitud de sistemas tanto Linux como Unix, OpenBSD o FreeBSD.

Si queréis información detallada podéis acudir a esta página de Qualys donde encontraréis referencias técnicas asi como un alcance de la vulnerabilidad. Mucho más recientemente, el 19 de junio, la misma gente de Qualys ha publicado en su web un listado de exploits que hacen uso de esta vulnerabilidad (aquí tenéis su funcionamiento en versión -vvv).

stackclash1

No me podía resistir a hacer algunas pruebas, así que me entretuve una tarde configurando un pequeño entorno con varias VMs y tirando exploits.

En primer lugar, traté de probarlo con un sistema operativo al que le tengo un cierto cariño: Solaris. Tras echarle un vistazo al script de la gente de Qualys, observé que el exploit estaba orientado a dos targets específicos. Solaris 11.3 y Solaris 11.1. Curiosamente Solaris 11.3 es la última version disponible para descarga en la web de Oracle, así que probamos sobre ella. Para ser sinceros lo más difícil es familiarizarse con el gestor de paquetes para poder instalar ‘gcc’ ya que no viene por defecto. En mi caso instalé la versión 4.5 con estos dos comandos:

Una vez descargado el exploit lo compilamos y lo ejecutamos. Tras unos minutos el resultado no puede ser más claro…

stackclash2

En el caso de Ubuntu tuve algunos problemillas debido a que todas las VMs que tenía instaladas eran sistemas de 64bits, y a pesar de lo que la gente de Qualys comenta en su web yo fui incapaz de lograr el escalado, es probable que es Debian sea mas sencillo. En cualquier caso, una vez descubierto el problema en el tamaño de direccionamiento de memoria, simplemente tuve que buscar una distribución de 32bits (opté por Ubuntu 16.04.2) y utilizar el exploit ‘linux_ldso_dynamic.c‘. Al contrario que en Solaris, el escalado de privilegios llevó algo más de tiempo (aproximadamente una hora y media), sin embargo el resultado fue el mismo 🙂

stackclash4

Como podéis comprobar, los resultados son bastante elocuentes y vienen a demostrar que en esto de la seguridad no hay ningún SO del que se pueda decir que no nos va a dar quebraderos de cabeza.