Investigar servidores comprometidos

Este artículo enumera las herramientas que están disponibles para realizar un análisis de un servidor comprometido. (La limpieza del servidor comprometido está fuera de su alcance). El uso de estas herramientas lo ayuda a determinar la siguiente información:

• El punto de entrada
• El origen del ataque
• Qué archivos están comprometidos
• El nivel de acceso que obtuvo el atacante
• La pista de auditoría de las huellas del atacante

Muchos tipos diferentes de compromisos pueden explotar un servidor Unix®. Los atacantes pueden lanzar un ataque de fuerza bruta, adivinar una contraseña débil o intentar usar vulnerabilidades de software conocidas con la esperanza de que el servidor no tenga un programa regular de parches. Es importante comprender cómo se vio comprometida la máquina para determinar el alcance del daño a su servidor y otros hosts a los que puede acceder la máquina comprometida.

Para la mayoría de los compromisos a nivel de raíz, el enfoque de recuperación más sencillo es realizar una instalación limpia del servidor y restaurar los datos críticos de las copias de seguridad. Sin embargo, hasta que sepa el punto de entrada del compromiso, este paso podría no ser suficiente porque necesita comprender el compromiso para poder cerrar correctamente la brecha de seguridad.

Documentar el ataque

Cuando se le notifique que un sistema bajo su control podría verse comprometido, asegúrese de obtener la mayor cantidad de información posible del denunciante, incluidos los siguientes elementos:

• Cómo se encontró el problema inicial
• La hora estimada en que ocurrió el compromiso
• Si el servidor se modificó después de que se detectó el compromiso
• Cualquier otra cosa que el reportero diga que sea importante

Importante :Si planea involucrar a las fuerzas del orden, es imperativo que no realice ninguna acción adicional en el servidor. El servidor debe permanecer en su estado actual para fines de recopilación de pruebas.

Si elige continuar con la investigación, documente todo lo que encuentre en el servidor. Este paso puede ser tan simple como copiar y pegar un comando y sus resultados.

Herramientas de investigación

En algunos compromisos, el atacante logra eliminar todos los archivos de registro importantes para ocultar su rastro. Sin embargo, esto no siempre ocurre. Como resultado, los archivos de registro contienen pistas valiosas sobre lo que el atacante le hizo al servidor. Los archivos de registro también pueden ayudarlo a determinar si el ataque fue un ataque web básico o un compromiso a nivel de raíz. Use los comandos en esta sección para encontrar pistas que lo ayuden a desentrañar el alcance del compromiso.

último comando

El last El comando enumera las sesiones de los usuarios que iniciaron sesión recientemente en el sistema. Su salida incluye las marcas de tiempo y los nombres de host e indica si el usuario aún está conectado. Si aparece una dirección de Protocolo de Internet (IP) extraña en la salida, puede compararla con un ataque de fuerza bruta Secure Shell (SSH) en el /var/log/mensajes o /var/log/secure directorio. Este paso podría indicar cómo ingresó el atacante, qué nombre de usuario usó para obtener acceso y si pudo escalar sus privilegios a root .

ls -lart comando

El ls -lart El comando genera una lista ordenada por tiempo de archivos y directorios con los que puede correlacionar cuando ocurrió el compromiso. Esta salida puede ayudarlo a determinar qué agregó o eliminó el ataque del sistema.

netstat -na comando

El netstat -na El comando muestra los sockets de escucha actuales en la máquina. Ejecutar este comando puede revelar puertas traseras que están escuchando o servicios errantes que se están ejecutando.

comando ps-wauxef

Este comando lo ayuda a rastrear cualquier proceso erróneo que esté escuchando y muestra otros procesos extraños (por ejemplo, el usuario www ejecutando un proceso Bash). También puede ejecutar el comando lsof |grep <pid> para encontrar más información sobre los archivos abiertos que utiliza un proceso. Simultáneamente, ejecutando cat /proc/<pid>/cmdline también podría decirle dónde existe el archivo que controla un proceso.

comando bash_history

El archivo de historial es a menudo la piedra de Rosetta para rastrear lo que sucedió durante un compromiso. Usando el bash_history comando para revisar el .bash_history del usuario El archivo a menudo muestra exactamente qué comandos ejecutaron, qué programas maliciosos descargaron y los directorios en los que se concentraron.

comando superior

Los procesos maliciosos a menudo causan problemas de contención de la unidad central de procesamiento (CPU) dentro del entorno y, por lo tanto, aparecen cerca de la parte superior de la lista de procesos. Utilice la top comando para mostrar esta lista. Cuando esté rastreando un compromiso, considere sospechoso cualquier proceso que cause problemas de contención de CPU.

comando de seguimiento

Cuando ejecutas strace -p pid comando en un proceso sospechoso, el strace El comando puede brindar información importante sobre lo que está haciendo el proceso.

Otras herramientas

Es posible que los comandos anteriores no proporcionen muchas pistas sobre lo que ocurrió durante el ataque. Si este es el caso, puede usar herramientas más especializadas.

Importante Nota:antes de utilizar las herramientas de esta sección, debe confirmar que los archivos binarios que está utilizando para investigar no son versiones con troyanos. Las versiones con troyanos pueden realizar tareas en nombre del atacante, como omitir información que podría revelar lo que intentaba lograr el compromiso.

Ejecute el siguiente comando para verificar que tiene un buen conjunto de herramientas:

rpm -Va

La verificación de un paquete compara la información sobre los archivos instalados del paquete con los metadatos del paquete que almacena la base de datos RPM Package Manager (RPM). La verificación compara la información sobre el tamaño, la suma MD5, los permisos, el tipo, el propietario y el grupo asociado con cada archivo. La salida muestra cualquier discrepancia.

Importante :Los paquetes marcados en los siguientes directorios pueden indicar que está utilizando una versión troyana del binario y, por lo tanto, no puede confiar en su salida:

• /bin
• /sbin
• /usr/bin
• /usr/sbin

El siguiente ejemplo muestra un archivo troyano:

S.5….T /bin/login

rpm -qa comando

Puede usar el comando rpm -qa para mostrar el orden cronológico de los paquetes instalados recientemente. Sin embargo, en el caso de un compromiso de raíz, la base de datos rpm también podría verse comprometida.

comando lsattr

Si el atacante obtiene acceso a la raíz y aplica troyanos a ciertos binarios, puede hacer que esos binarios sean inmutables para que no pueda reinstalar versiones limpias de ellos. Consulte los siguientes directorios:

• /bin
• /sbin
• /usr/bin
• /usr/sbin

El siguiente ejemplo muestra un archivo que un atacante ha convertido en inmutable:

-------i----- /bin/ps
Under normal circumstances in these directories, the rules should all look similar to:

------------- /bin/ps

buscar comando

find es una herramienta de Unix que puede ser fundamental para encontrar archivos modificados recientemente. Por ejemplo, puede encontrar archivos modificados en los últimos cinco días ejecutando el siguiente comando:

find / -mtime 5

Directorios comunes para web exploits

Compruebe los siguientes directorios de escritura mundial en los que Apache® suele escribir archivos temporales:

• ls -al /tmp
• ls -al /var/tmp
• ls -al /dev/shm

Busque cualquier archivo que no reconozca o que parezca sospechoso. Esté atento a los archivos ocultos y los archivos que tienen permisos de ejecución.

Si ha establecido permisos para directorios en su sitio web en 777, verifíquelos también.

Encontrar el punto de entrada

Si encuentra información útil utilizando las herramientas de las secciones anteriores, es posible que también tenga una marca de tiempo de cuándo el pirata informático instaló el archivo o archivos maliciosos en el servidor.

Puede usar esa marca de tiempo para revisar los registros de acceso de su sitio web en busca de entradas sospechosas que se agregaron durante ese período de tiempo. Si encuentra algo sospechoso, puede compararlo con la ubicación de los archivos maliciosos para reducir el punto de entrada.

Si bien la mayoría de los compromisos provienen de código explotable dentro de su sitio web, no puede descartar otros puntos de entrada. Asegúrese de revisar /var/log/* por cualquier cosa que parezca sospechosa durante el período informado.

Ejemplo de investigación

La investigación de ejemplo en esta sección demuestra el proceso que debe usar al investigar un supuesto compromiso a nivel raíz.

Identificar el tipo de ataque

Verifique si fue un ataque web básico o si el atacante realmente obtuvo privilegios de root. En la mayoría de los casos, el ataque es un ataque web simple que puede limpiar de forma segura.

1. Ejecute los siguientes comandos para determinar si el atacante obtuvo privilegios de root:

   lsattr /usr/sbin | menos

   lsattr/usr/bin | menos

   lsattr/bin | menos

   lsattr /sbin | menos

2. Busque atributos modificados, como archivos binarios que se hayan configurado como inmutables.

   Salida:

    s---ia------- /sbin/shs
   

   Cuando usas las strings comando en ese archivo, verá que es un backdoorshell.

Comprobar si el atacante limpió sus huellas

En muchos casos, los atacantes son inexpertos o descuidados y no han borrado sus huellas. Utilice los siguientes pasos para comprobar si el atacante ha dejado pistas:

1. Verifique que todas las cuentas de usuario en /etc/passwd tener un shell válido ejecutando el siguiente comando:

   gato /home/$USUARIO/.bash_history

2. Recupere el historial del usuario raíz ejecutando los siguientes comandos:

   historia

   gato /root/.bash_history

En este ejemplo, la salida de /root/.bash_history El comando revela que el atacante realizó las siguientes acciones en el servidor:

• Herramientas maliciosas descargadas para servir a través de Apache® en /var/www/html/* .
• Herramientas de Internet Relay Chat (IRC) instaladas y otras herramientas en /var/tmp/.ICE-unix .
• Modificó el crontab raíz para volver a descargar las herramientas maliciosas si alguien las elimina del servidor (* * * * * /var/tmp/.ICE-unix/update >/dev/null 2>&1 ).

Buscar hacks web básicos

Hasta este momento, hemos determinado que el ataque es probablemente un simple truco web que puede limpiar fácilmente sin formatear el servidor.

Sin embargo, en este ejemplo, sabemos que el atacante obtuvo privilegios de root. También podrían haber explotado phpMyAdmin . Después de que se cargó el PHP Shell de puerta trasera, el atacante pudo realizar un exploit de raíz local para escalar sus privilegios.

1. Ejecute los siguientes comandos para encontrar archivos y directorios ocultos en los directorios de lectura mundial en los que Apache suele escribir tmp archivos:

   ls -al /var/tmp |menos

   ls -al /tmp

   ls -al /dev/shm

2. En este ejemplo, los comandos devuelven el siguiente resultado:

   drwx—— 3 70 70 4096 19 de noviembre 02:00 /var/tmp/.ICE-unix

3. Si encuentra elementos aquí, debe intentar rastrear el punto de entrada para poder eliminar el sitio, actualizar el código del sitio o corregir el código explotable. El paso 5 presenta una forma rápida de realizar esta tarea. Sin embargo, si la salida del ps -waux El comando muestra que los bots de IRC se están ejecutando, luego puede intentar detectar desde dónde se está ejecutando el proceso utilizando lsof comando o ps -wauxxef |grep <pid> .

Busque los identificadores de proceso que están escuchando las conexiones entrantes

1. Ejecute los siguientes comandos para buscar identificadores de proceso (PID) que estén escuchando conexiones entrantes:

• netstat -natp :busca cualquier conexión sospechosa que se esté ejecutando en puertos impares

• ps -wauxxef :busca archivos sospechosos, como bash ejecutándose bajo un www contexto

• lsof <pid> :ayuda a determinar desde dónde se ejecuta el PID

  El resultado es similar al siguiente ejemplo:

    tcp 0 0 0.0.0.0:1144 0.0.0.0:* LISTEN 1008/bash
  
    tcp 0 1 172.16.23.13:60968 22.22.22.22:7000 SYN_SENT 6860/sshd
  

  En este ejemplo, varias otras conexiones establecidas por SSH también se ejecutan desde puertos de alto nivel, como se muestra en el siguiente ejemplo:

    [root@www tmp]# netstat -natp |grep sshd |awk '{print $4,$5,$6,$7}'
  
    0.0.0.0:22 0.0.0.0:* LISTEN 1046/sshd
  
    172.16.23.13:60986 22.22.22.22:6667 SYN_SENT 6860/sshd
  
    123.123.123.123:22 22.22.22.22:59361 ESTABLISHED 22795/sshd
  
    123.123.123.123:22 22.22.22.22:57434 ESTABLISHED 22796/sshd
  
    123.123.123.123:57139 143.143.143.143:6667 ESTABLISHED 6860/sshd
  
    123.123.123.123:57402 22.22.22.22:6667 ESTABLISHED 6860/sshd
  
    123.123.123.123:22 143.143.143.143:49238 ESTABLISHED 8860/sshd
  
    123.123.123.123:57134 22.22.22.22:6667 ESTABLISHED 6860/sshd
  
    123.123.123.123:56845 22.22.22.22:6667 ESTABLISHED 6860/sshd
  
    123.123.123.123:57127 143.143.143.143:6667 ESTABLISHED 6860/sshd
  

  Esta salida indica que los atacantes todavía están conectados a esta máquina. Sin embargo, no puede verlos porque probablemente modificaron los archivos binarios para ocultarse.

Determinar el punto de entrada para el compromiso original

Use los siguientes pasos para determinar el punto de entrada para el compromiso original:

1. Compruebe /var/log/[messages|secure] para intentos SSH de fuerza bruta.

2. Compruebe los registros de acceso y los registros de errores de Apache. Este paso podría ayudar a determinar qué sitio es explotable.

   También debe hacer una referencia cruzada de las IP con los registros si cree que existe la posibilidad de que se haya originado desde allí. Esta es una forma rápida y sencilla de rastrear el punto de origen.

   Puede verificar rápidamente los servidores que tienen una gran cantidad de registros web usando los siguientes comandos:

   cd /var/log/httpd
   
   for i in `ls * |grep access`; do echo $i && grep wget $i; done
   
   for i in `ls * |grep access`; do echo $i && grep curl $i; done
   

   Nota :Este ejemplo busca wget porque wget estaba en el archivo de historial de root bajo lo que podría haber sido parte del punto de entrada.

Resultado

En este ejemplo, nuestra investigación reveló que un atacante explotó el phpMyAdmin instalación en el /var/www/html directorio, probablemente porque la versión de phpMyAdmin instalado en el servidor estaba muy desactualizado. Parcheando phpMyAdmin en un horario regular evita que ocurra esta situación.