En los sistemas basados en Linux, que utilizan el estándar ELF  como formato binario, la imagen del proceso se crea cargando e interpretando los segmentos especificados en las cabeceras. Pero antes de hablar sobre el proceso de carga es necesario saber que al crear un ejecutable que utiliza dynamic linking (que son la mayoría de los programas), las bibliotecas compartidas necesarias se ubican y se enlazan en tiempo de ejecución, por lo que el linker añade un campo a las cabeceras del programa del ejecutable de tipo PT_INTERP, indicando al sistema la identidad del linker dinámico (a veces también llamado intérprete) que típicamente es /lib64/ld-linux-x86-64.so.2.  Por otra parte, en el periodo conocido como link-time, el programa (o biblioteca) se construye combinando secciones con atributos similares en segmentos. Normalmente, todas las secciones ejecutables y de datos de sólo-lectura se juntan en un mismo segmento, mientras que el resto de secciones de datos y BSS (variables no inicializadas) se combinan en otro segmento. Estos segmentos típicamente se conocen como segmentos de carga porque es necesario cargarlos en memoria en el momento de la creación del proceso, al contrario que otras secciones como la tabla de símbolos (.symtab) o la información de debugging (.debug_info).

A grandes rasgos, el proceso de carga de un binario ELF se descompone en las siguientes tareas:

• 1. En primer lugar, se examinan las cabeceras para verificar que el fichero en cuestión tiene un formato ELF compatible.
• 2. Se recorren las entradas de las cabeceras del programa comprobando si se ha especificado un intérprete (PT_INTERP).
• 3. Para establecer la memoria virtual, se recorren todos los segmentos de tipo PT_LOAD en el fichero y se mapean dentro del espacio de direcciones del proceso. Después se configuran las páginas inicializadas con ceros correspondientes al segmento BSS. También se configuran otras páginas especiales como las páginas de objetos compartidos dinámicos virtuales (vDSO).
• 4. Una vez que el código del programa se ha cargado en memoria y como en este caso suponemos que utiliza dynamic linking, el ELF handler también carga el intérprete en memoria. El proceso es prácticamente el mismo que el seguido para cargar el programa original y que hemos explicado en el punto anterior.
• 5. Por último, la dirección de inicio del programa se configura como el punto de entrada del intérprete en lugar del programa en sí mismo. Esto implica que la ejecución empieza con el intérprete, que se encarga de satisfacer los requisitos de enlace del programa desde el espacio de usuario, es decir, busca y carga las bibliotecas compartidas de las que depende el programa y trata de resolver los símbolos no definidos a las definiciones correctas en dichas bibliotecas. Una vez se ha finalizado este proceso el intérprete puede iniciar la ejecución.

Para una explicación más detallada de este proceso con referencias al código del kernel por favor visitar el arituclo de LWN.net.

The post La carga de binarios en Linux appeared first on S3lab.

Lo primero que se debe de mirar son los logs del sistema situados en /var/www. Estos nos pueden indicar si ha habido alguna actividad inusual en muchos servicios que podemos tener en nuestro ordenador. Si tenemos un servidor apache y salida directamente a internet podemos ver que nuestro log tendrá entradas de todo tipo intentando conseguir acceso (algo digno de ver la verdad). Otro detalle que es importante mirar es que no haya nuevos usuarios en el /etc/shadows que no deberían estar ahí.

Luego ya podemos pasar a mirar alguna otra cosilla, como por ejemplo ver si actualmente existe un usuario extraño conectado con el comando who, mirar los procesos del sistema con el comando ps y ver si hay alguno extraño, el comando lsof  o netstat para ver cuales son los procesos que tienen abiertos puertos a internet, incluso un nmap puede ayudarnos mucho en esta tarea. No creo que haya que decir que no estaría mal mirar si tenemos la tarjeta de red en modo promiscuo con ifconfig.

Algo muy típico es que si os han entrado hayan intentando dejar una puerta de acceso para volver a pillar privilegios otra vez, sin volver a hacer lo que sea que hayan hecho. Para ello es muy típico buscar ficheros con más permisos de la cuenta mediante el comando find, como el archiconocido «find / -user root -perm -4000 -print«. Si creemos que el atacante puede haber ido más lejos podemos mirar los módulos que tiene cargados el kernel, con un «ls -R /lib/modules/$(uname -r)» o buscando rootkits con el la herramienta chkrootkit.

Tampoco estaría de más si comprobais los /etc/hosts.allow y /etc/hosts.deny, para comprobar que no hay ninguna ip rara (normalmente no suelen contener nada). Estos dos fichero son consultados por utilidades como el rlogin para saber si pueden permitir hacer login remoto.

También estaría bien revisar la configuración del ssh, si es que tenéis este servicio en vuestro ordenador. Son muchas las opciones que pueden hacer que un usuario entre por un ssh legítimo pero mal configurado, por no decir que con solo añadir una en authorized_keys podría entrar en el sistema sin falta de contraseña.

Y por último no dejéis de mirar las tareas que hay en el cron de usuarios con muchos privilegios. Quizá no se esté ejecutando algo en todo momento pero cada cierto tiempo puede estar mandando vuestra información o ejecutando tareas de limpieza para no ser cazado.

Bueno, siento no haber sido muy especifico y me he dejado muchas cosas en el tintero, pero como siempre, espero haber despertado vuestra curiosidad y hacer que miréis un poco más este tema.

The post Sobreviviendo en la consola (Parte III) appeared first on S3lab.