El atacante está intentando que un shell se ejecute como usuario DavidGilmour
. Sobre la base de sus exploraciones, la decisión es intentar explotar una vulnerabilidad en el binario shineon
porque ese binario está configurado en DavidGilmour
:
$ ls -lah /usr/local/bin/shineon
-rwsr-s--- 1 DavidGilmour RichardWright 7.3K Oct 25 07:58 /usr/local/bin/shineon
Note el s
en los permisos. Eso indica que cuando se ejecuta shineon
, se ejecutará como DavidGilmour
. Pero como shineon
es un programa de funcionalidad limitada, no tiene un comando start shell
. En su lugar, el atacante observa la funcionalidad que proporciona el shell:
1. Calendar
2. Who
3. Check Internet
4. Check Mail
5. Exit
y luego mira las cadenas dentro del binario. Las cadenas relevantes son:
/usr/bin/cal
/usr/bin/who
/sbin/ping -c 3 www.google.com
mail
El atacante adivina que esas son las cadenas de comandos utilizadas para ejecutar la funcionalidad de la aplicación: Calendar
corresponde a /usr/bin/cal
, etc ... El atacante nota inteligentemente que mail
no tiene una ruta completa. Esto significa que el script ejecutará el primer comando mail
que encuentra en el PATH
. Así que el atacante crea un comando llamado mail
en algún directorio aleatorio. Eligieron /tmp
, pero esa elección no es importante. El comando es un enlace simbólico a /bin/sh
. Un enlace simbólico crea un alias entre dos archivos. En este caso, cuando el sistema operativo ejecuta /tmp/mail
, en realidad ejecutará /bin/sh
. Podrían haber copiado /bin/sh
a /tmp/mail
también, pero ¿por qué molestarse? La copia lleva tiempo y utiliza espacio en disco. La vinculación simbólica es igual de efectiva y rápida.
El paso final es configurar la variable de entorno PATH
para que comience con /tmp
para que cuando el sistema operativo ejecute el comando mail
, encuentre /tmp/mail
. Y, dado que esto es solo un enlace simbólico a /bin/sh
, ejecutará /bin/sh
como DavidGilmour
(recuerde que el programa es setuid, por lo que siempre se ejecuta como DavidGilmour
).
Objetivo logrado!