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!