Te dan una máquina y nadie te dice nada

Abre el laboratorio. Esta vez no vamos a decirte a qué carpeta ir.

Lo primero, como siempre:

ls
cat encargo.txt

Eso es todo el contexto que te dan, y es más de lo que te darán muchas veces. «Este servidor se comporta raro desde el martes. No tenemos documentación. Mira qué encuentras.»

Antes de tocar nada, dos preguntas que se hacen siempre al llegar a una máquina desconocida — y las dos ya sabes contestarlas:

cat /proc/version
cat /proc/uptime

Mira los dos números. La versión es de una rama vieja. Y el tiempo encendido, dividido entre 86.400, son más de trescientos días.

Ya tienes un contexto sin haber buscado nada: una máquina vieja que no ha reiniciado en casi un año. Eso no es el fallo, pero explica por qué es posible que haya uno.

El orden importa. Empieza por los procesos, porque un proceso te dice qué está pasando ahora, mientras los archivos solo dicen qué había antes.

ps

Recorre la lista con lo que aprendiste. Hay seis cosas que tienen sentido en un servidor web con base de datos. Y hay una que no, por las mismas tres razones de siempre: corre desde una carpeta temporal, está en una carpeta oculta, y consume mucho más que el resto.

Sigue el rastro hasta el archivo. La ruta te la dio el propio ps:

cd /tmp/.sys
ls -l

Ahí está el binario, con permisos abiertos de par en par, y un archivo de salida al lado. Léelo: dice cada cuánto está enviando datos.

Eso es lo que convierte esto en un incidente y no en una curiosidad. Un programa raro es un problema; un programa raro que está enviando algo cada cinco minutos es una filtración en curso.

Ya sabes qué está corriendo. Ahora la pregunta que de verdad importa: ¿cómo llegó ahí?

El proceso corre como el usuario del servidor web. Eso apunta a la aplicación, así que ve a buscarla. No sabes dónde está — usa el comando para eso:

find app

Entra y mira los permisos con atención:

ls -l

Hay una carpeta que canta: drwxrwxrwx. Todos los permisos, para todo el mundo, incluida la x. En una carpeta llamada subidas.

Piensa lo que significa: cualquiera puede dejar un archivo ahí y ejecutarlo. Es la combinación exacta que permite que un desconocido convierta «subir una foto de perfil» en «ejecutar mi programa en tu servidor».

Confírmalo en los registros, que es como se demuestra en un informe:

grep subidas /var/log/apache.log

Ahí está la secuencia, con hora: un POST a la carpeta de subidas, y treinta segundos después dos peticiones al programa que acabas de encontrar. Subió y ejecutó.

Lee la nota que hay dentro de la carpeta para el código.

Falta la parte que decide la gravedad, y es la que convierte tu informe en algo que se lee con urgencia.

El atacante ejecuta código como el usuario del servidor web. La pregunta es: ¿qué puede leer ese usuario?

Vuelve a la carpeta de la aplicación y mira los permisos otra vez. Hay un archivo de configuración con rw- para todos. Ábrelo.

Dentro hay una contraseña de base de datos en texto plano.

Ese es el hallazgo grave, y conviene entender por qué:

• Los dos anteriores permitían ejecutar algo en el servidor.
• Este permite leer la base de datos entera — pacientes, historias, todo.

Y fíjate en el detalle que un informe tiene que señalar: la contraseña es de root, el usuario que puede todo en la base de datos. No una cuenta limitada de la aplicación: la que puede leerlo y borrarlo todo.

Tres fallos que por separado son «revisar cuando se pueda». Juntos son la clínica entera: una carpeta que deja ejecutar, un proceso enviando datos, y las llaves de la base en un archivo que cualquiera lee.

Encontraste tres cosas. Ahora la parte que separa a alguien que sabe usar comandos de alguien a quien le pagan por esto: decir en qué orden se arreglan.

Y no se ordena por cuál es más grave. Se ordena por qué corta el daño que está pasando ahora mismo:

1. Aislar la máquina de la red. Hay un proceso enviando datos cada cinco minutos. Todo lo demás puede esperar cinco minutos; eso no.
2. Cambiar la contraseña de la base de datos. Está en manos de quien entró. Aunque cortes el proceso, la contraseña ya salió.
3. Quitar el permiso de ejecución a la carpeta de subidas. Cierra la puerta por la que entró, para que no vuelva mañana.
4. Y solo entonces limpiar el proceso, actualizar el sistema y averiguar qué se llevó.

Fíjate en que el punto 2 va antes que cerrar la puerta. Es lo que más se equivoca la gente al empezar: cierras la entrada, respiras, y resulta que quien entró ya tiene las llaves y vuelve por la puerta principal.

La regla, y con esto cierras el módulo: primero lo que está sangrando, después lo que ya se perdió, y al final lo que podría volver a pasar.