Hacking Linux: Aprovechando los Wildcards I

El otro día leí un artículo de Leon Juranic que me descubrió un nuevo mundo de posibilidades. El artículo se llama “Back To The Future: Unix Wildcards Gone Wild“, y fue publicado en 2014. Ya que quería probarlo por mí mismo, me pareció una buena oportunidad de mostrártelo en este blog.

En él se expone una técnica de hacking de la old school, que a día de hoy sigue funcionando, y a mi personalmente me parece una maravilla. Y lo que más me ha sorprendido es que hasta ahora no había leído sobre esta técnica en ningún libro o foro de seguridad. 

Así que empecemos explicando qué son los wildcards. 

Introducción a los Wildcards

Los wildcards son caracteres que representan un conjunto o rango.  Con ellos se construyen las expresiones regulares. Suelen denominarse también caracteres comodín.

Algunos de los wildcards más utilizados son:

*      El asterisco representa cualquier conjunto de caracteres de un nombre de archivo.

?      La interrogación representa un solo caracter (sea el que sea),

[  ]   Los corchetes representan clases de caracteres. Por ejemplo para buscar cualquier caracter que                 represente un dígito pondríamos [0-9]

–      Como hemos visto en el ejemplo anterior, un guión indica un rango de caracteres.

~      La virguilla (sí, se llama así) al principio de una palabra se traduce como el nombre de tu directorio               home. Si le añades el nombre de un usuario, se traduce como la ruta del directorio home de ese user.

De esa forma, si en la terminal escribimos 

# ls *.php   Lista todos los archivos php.

# rm *.gz   Elimina todos los archivos GZIP.

# cat backup* Muestra el contenido de todos los archivos que empiecen por “backup”.

# ls test?   Lista todos los archivos que empiecen por test y tengan un solo caracter adicional (mostraría test4 pero no test15).

Trucos con Wildcards

El problema de los wildcards es que se puede abusar de los argumentos como nombre de archivo. Esto es, podemos hacer pensar al sistema que uno de los argumentos que recibe un comando es en realidad el nombre de un archivo.

Borrado recursivo

Veamos el siguiente ejemplo. He creado un directorio llamado “dir1“. un archivo de texto llamado “text1” y un archivo llamado “-rf“.

Fíjate que para crear este archivo -rf no he podido hacerlo con un simple “touch -rf, ya que me daba un error. Pero bastó con introducir la ruta completa (“touch /root/wildcards/-rf”) para que se creara correctamente:

Ahora ejecutamos el comando rm * , con lo que en principio debería borrar todos los archivos del directorio:

¡Vaya! El archivo “-rf” continúa ahí. Esto es debido a que al ejecutar rm *, todos los  nombres han pasado como argumento (el comando se ha traducido a “rm dir1 -rf text1”). Dado que “-rf” es una de las opciones del comando rm que indica que los archivos se eliminen recursivamente, el sistema ha interpretado que había que borrar recursivamente los archivos dir1 y text1, en vez de interpretar que “-rf” es también un archivo que se debe borrar.

Hijacking de archivos propios

Supongamos el siguiente caso: tenemos una carpeta con varios archivos poseídos por el usuario user.  Supongamos que el administrador va a asignar todos los archivos txt al usuario “resu“.  Sin embargo, el usuario malicioso “toor” desea hacerse con esos archivos, así que crea dos archivos llamados “cake.txt” y “–reference=cake.txt“:

A continuación, el usuario root ejecuta el comando “chown -R resu:resu *.txt”, dandole la posesión de estos archivos al usuario resu. Veamos qué ha pasado.

Todos los archivos han pasado a ser del usuario toor!

Esto es debido a que el comando chown tiene la opción –reference=RFILE, que asigna los archivos al usuario que posea el archivo RFILE. Por tanto, en realidad root lo que ha ejecutado ha sido “chown -R resu:resu admin.txt cake.txt confidential.txt flag.txt passwords.txt –reference=cake.txt thecakeisalie.txt veryimportantfile.txt”, y al indicar un archivo con el parámetro –reference, el sistema ignora que root se los haya asignado a resu:resu.

Pero esto va más allá: no solo es posible hacernos con los archivos de esa misma carpeta. Si creamos un symlink, podemos hacernos con la propiedad de cualquier archivo o directorio del sistema, como el shadow donde se encuentran las contraseñas.

 

Si el administrador asigna los documentos de esa carpeta al usuario user, al igual que antes, todos los documentos pasan a ser de toor. 

Sin embargo, el usuario toor no solo se ha hecho con los permisos de esos archivos. La ruta del symbolic link ahora también es suya…

Y por tanto, el usuario toor tiene acceso al archivo shadow.

En el RFC hay aún más ejemplos de esta técnica aplicados a chmod, tar y rsync, así que dentro de unos días haré una segunda parte explicándolas, porque me ha parecido realmente interesante que no haya ninguna contramedida que evite esta clase de ataques.

 

Lethani.

Deja una respuesta