LinuxParty

Básicamente existen dos líneas de acción para comprometer un sistema Linux. Usar un ataque de día-cero (0-day) o modificar un binario del sistema para instalar una puerta trasera (backdoor). Normalmente los ataques 0-day de un cracker suelen ir seguidos de la instalación de una puerta trasera.

En esta entrada se verán algunos métodos para comprometer un sistema Linux mediante la instalación de una puerta trasera o backdoor. Tabla de contenidos

• 1.- Antecedentes
• 2.- Bits de permisos especiales
• 3.- Instalar una puerta trasera en PAM
• 3.1.- Descargar las fuentes de PAM
• 3.2.- Modificar el código fuente
• 3.3.- Reemplazar la biblioteca pam_unix.so del sistema
• 3.4.- Ocultando el rastro

1.- Antecedentes
Ningún sistema está exento de ser comprometido, y existen multitud de antecedentes. En el mundo Linux uno de los más destacado fue el intento de instalar una puerta trasera en el kernel Linux en noviembre de 2003.

El 6 de noviembre de 2003 Larry McVoy anunciaba que se había producido una intrusión en el CVS del kernel Linux. Los crackers introdujeron dos líneas de código extra en la llamada al sistema wait4(), de tal forma que ejecutando un pequeño binario se activaba la puerta trasera y se abría una root shell. Afortunadamente se detecto la intrusión y los cambios introducidos por los crackers nunca fueron intregrados en ningún kernel Linux, es decir, no se llego a distribuir ningún kernel con la backdoor.

Otro suceso similar ocurrió el 28 de noviembre del 2010 con el servidor de FTP ProFTPD. Los crackers insertaron una puerta trasera en la versión 1.3.3c de ProFTP. Esta puerta trasera se conectaba a una dirección ip y llevaba a cabo una petición, de esta forma los crackers sabían los servidores que corrían la versión con el backdoor. Posteriormente tan solo debían conectarse al FTP y ejecutar el comando HELP ACIDBITCHEZ para obtener acceso root. Tres días más tarde el suceso fue detectado y solucionado por Jeroen Geilman.

Recientemente fue crackeada la versión v2.3.4 del servidor de FTP Vsftpd, a la cual introdujeron una puerta trasera para obtener una root shell. Podéis leer más en Security: Alert: vsftpd download backdoored

Por último citaremos un hack a un peso pesado de internet: el famoso hackeo a twitter llevado a cabo por Security By Default. En este caso pusieron a prueba la seguridad de twitter, publicando en otra cuenta. Como victima eligieron a Enrique Dans, a quien informaron del hackeo y quien se tomo el asunto a bien. Si estais interesado, podéis leer la historia en Hackeos memorables: El Twitter de Enrique Dans.

Si esta interesado en conocer más sobre hacks, cracks o exploits utilizados para vulnerar los sistemas, puede consultar The Exploits Database.


2.- Bits de permisos especiales
Los bits de permisos especiales tales como setuid y setgid indican al kernel que el programa ha de ejecutarse con los permisos del usuario propietario del archivo en lugar de con los permisos del usuario que ejecuta el programa.

Tan solo bastará que asigne el bit setuid al ejecutable de una shell. Puede llevar a cabo esta tarea apagando el servidor, iniciando desde un LiveCD y haciendo las modificaciones oportunas. O si tiene acceso como usuario root, podrá montar un entorno chroot y asignar el bit setuid desde él. Obviamente también existe la posibilidad de explotar una vulnerabilidad 0-day aun no parcheada para irrumpir en el servidor y hacer los cambios oportunos.

En cualquier caso, en este tipo de técnicas lo normal es no asignar el bit setuid a la consola por defecto del sistema, normalmente /bin/bash. Para no ser descubiertos lo mejor es copiar el ejecutable a otra ruta, donde no levante sospecha, como por ejemplo /usr/local/bin.

Además en lugar de usar la consola bash, que es la más extendida en el mundo Linux, puede probar con otras consolas. Esto no engañará al administrador, pero es probable que si algún jefecillo con acceso al sistema investigando ejecuta por error nuestra consola con acceso root, una consola poco conocida lo desoriente. Para esta tarea nada mejor que Z shell. Al ejecutar zsh en un sistema en la que no está configurada, muestra un mensaje ([+/-] Ver mensaje) para su configuración. Con suerte el jefecillo se sentirá intimidado por el mensaje y saldrá pensando que rompió algo.

Tal vez piense que modificar /etc/passwd para crear un usuario y asignar-le id 0 sea más rápido. Pero debe tener en cuenta que cuanto más escondido este el backdoor, más difícil será detectarlo y por ende más tiempo podrá usarlo. Por ello los backdoors más efectivos son los que se insertan en el propio código fuente de los programas. La probabilidad de detectar un backdoor en un binario es nula.


3.- Instalar una puerta trasera en PAM
Como ya se vio anteriormente en la entrada ¿Qué es Pluggable Authentication Modules (PAM)?, PAM se encarga de todo el proceso de autenticación, autorización y control de recursos en un sistema Linux. Si logra introducir una puerta trasera en PAM, podrá acceder a cualquier cuenta del sistema (incluido root) usando una contraseña maestra.

Para esta tarea necesitará descargar el código fuente de PAM, agregar una pequeña línea de código y compilar-lo. Por último tan solo deberá sustituir una de las bibliotecas de PAM del sistema de la victima por la biblioteca compilada con la puerta trasera. A continuación veremos todo esto detenidamente:


3.1.- Descargar las fuentes de PAM
Puede obtener el código fuente de PAM en A Linux-PAM page. Antes de continuar compruebe la versión de PAM instalada en el sistema. En cualquier caso no debería tener problemas si descarga una versión distinta a la instalada en el sistema donde se instalará la backdoor
Descomprima el código fuente y localice el archivo modules/pam_unix/pam_unix_auth.c En el deberá insertar el código para la puerta trasera.


3.2.- Modificar el código fuente
Edite el archivo modules/pam_unix/pam_unix_auth.c y busque la cadena retval = _unix_verify_password(pamh, name, p, ctrl);, justo debajo coloque la cadena if (strcmp(p,"makeinstall")==0 ){retval = PAM_SUCCESS;}. Sustituya makeinstall por la contraseña que desee. El código deberá quedar así:

Una vez modificado, tan solo debe de compilar el código con ./configure y make. Si al finalizar la compilación observa algunas errores del tipo make[]: se sale del directorio, ignore-los.


3.3.- Reemplazar la biblioteca pam_unix.so del sistema
Una vez compilado PAM con la puerta trasera, tan solo deberá reemplazar la biblioteca pam_unix.so del sistema atacado. Normalmente dicha biblioteca se aloja en /lib/security/ aunque puede variar ligeramente de un sistema a otro; en ubuntu, por ejemplo, se localiza en /lib/i386-linux-gnu/security/.

Para sustituir dicha biblioteca precisará privilegios de root, por lo que deberá de explotar una vulnerabilidad 0-day o si tiene acceso físico al sistema arrancar desde un LiveCD para sustituir la biblioteca.


3.4.- Ocultar el rastro
La fecha de creación de la biblioteca modificada podrías dar indicios de una modificación, por ello deberá modificar la fecha de creación haciendo uso del comando touch.

Por último deberá revisar los logs el sistema para borrar todo indicio de las actividades. Si desea saber más sobre sistemas de registros en Linux, puede leer la entrada Gestión de archivos de registro del sistema.