Entonces, he aquí que un sitio heredado que estábamos alojando para un cliente tenía una versión de FCKEditor que permitía a alguien cargar el temido exploit c99madshell en nuestro servidor web.
No soy un gran aficionado a la seguridad; francamente, solo soy un desarrollador actualmente responsable de las tareas de S/A debido a una pérdida de personal. En consecuencia, me encantaría recibir ayuda de quienes fallan en el servidor para evaluar el daño causado por el exploit.
Para darte un poco de información:
El archivo se cargó en un directorio dentro de la raíz web, "/_img/fck_uploads/File/". El usuario y el grupo de Apache están restringidos de modo que no pueden iniciar sesión y no tienen permisos fuera del directorio desde el cual servimos los sitios.
Todos los archivos tenían 770 permisos (usuario rwx, grupo rwx, ninguno más), algo que quería arreglar pero me dijeron que lo pospusiera porque no era "alta prioridad" (espero que esto cambie eso). Entonces parece que los piratas informáticos podrían haber ejecutado fácilmente el script.
Ahora no pude localizar c99madshell.php en sí, solo un montón de otros archivos HTML que contenían texto en ruso y algunos archivos .xl y .html con PHP en línea que eran versiones del hack de Madshell. Sin embargo, al investigar un poco, parece que el truco se destruye a sí mismo después de la ejecución: genial.
De todos modos, mi valoración inicial sería la siguiente:
No es necesario reconstruir todo el host, ya que dado el aislamiento del usuario/grupo de Apache, no deberían haber podido obtener contraseñas a nivel del sistema.
Es necesario corregir esta vulnerabilidad restringiendo las cargas para que no tengan permiso de ejecución, actualizando la versión de FCKEditor para corregir el objetivo del exploit original y agregando una configuración a nivel de servidor que niegue la ejecución del script PHP dentro del directorio de cargas.
Debería cambiar las contraseñas de la base de datos para la aplicación; dado que el archivo de configuración para la conexión de la base de datos se encuentra dentro de la raíz web, lo más probable es que el hacker podría haberlo capturado y con él la contraseña de la base de datos.
De todos modos, proporcionen cualquier comentario que tengan sobre lo que debería decirle al jefe. Obviamente, sería ideal evitar reconstruir todo el host, pero si eso es lo que tenemos que hacer para asegurarnos de que no estamos ejecutando una máquina pirateada, entonces eso es lo que será necesario.
Realmente aprecio la ayuda de sus muchachos. Además, no dude en solicitar más información (estaré encantado de ejecutar comandos/trabajar con ustedes para evaluar el daño). Malditos hackers :(.
Respuesta1
Obviamente, como han dicho otros, la respuesta oficial "segura" sería reconstruir la máquina.
La realidad de la situación podría impedirlo. Puede ejecutar algunas cosas para comprobar si hay compromisos:
- Chkrootkit- pruebas para detectar signos comunes de que el servidor está comprometido
- Si es un sistema rpm, 'rpm -Va|grep 5' verificará todos los binarios instalados rpm e informará un "5" si la suma MD5 ha cambiado. Es necesario reconstruir si encuentra alguna inconsistencia que no se explica en el binario personalizado.
- Busque en /tmp cualquier cosa sospechosa.
- Marque 'ps fax' para ver si hay procesos anormales. Si 'ps' está comprometido o mediante otras técnicas, es posible que aún se estén ejecutando procesos ocultos.
- Si encontró CUALQUIER archivo en su búsqueda que tuviera una propiedad distinta a Apache, las cuentas de su sistema definitivamente estaban comprometidas y necesita una reconstrucción.
Correcciones a realizar en la configuración de su sistema:
- Deshabilite las cargas mediante FCKeditor si es posible
- Asegúrese de que sus directorios temporales sean NOEXEC para evitar que los programas se ejecuten fuera de ellos.
- Todos los scripts php deben estar actualizados.
- Si desea obtener una instalación elegante, instale mod_security para buscar vulnerabilidades durante el tiempo de ejecución de los scripts php.
Hay un montón de cosas que me estoy perdiendo, pero esos serían los primeros pasos que daría. Dependiendo de lo que esté ejecutando en el servidor y la importancia de su seguridad (¿maneja transacciones CC?), podría ser necesaria una reconstrucción, pero si se trata de un servidor de "baja seguridad", podría estar de acuerdo con verificar lo anterior.
Respuesta2
Tienes que reconstruir el host. No sabes qué tipo de ataques de escalada de privilegios han utilizado contra el host, ni puedes estar absolutamente seguro de que no haya troyanos, keyloggers o rootkits instalados.
Una vez que se ve comprometido, no hay otra opción además de una reconstrucción desde cero.
Respuesta3
En resumen, reconstruiría el servidor.
Si tienen acceso a un usuario local (ahora tenían acceso como usuario de Apache), pueden ejecutar exploits locales. Por lo que debes considerar que todo el servidor está comprometido. También deberías buscar otros servidores.
¿Qué distribución estás ejecutando? Si está basado en rpm, puede verificar las firmas de los archivos. Inicie el CD de instalación y ejecute rpm -V para verificar los paquetes.
Respuesta4
Sé que no es lo que le gustaría escuchar, pero realmente recomendaría hacer una copia de seguridad de los datos, reconstruir el servidor y volver a importar todos los datos.
También asegúrese de revisar otros sitios para asegurarse de que este no sea el único afectado por el hack. Si todos los scripts de su servidor se ejecutan como un usuario de Apache ( nodoby/ www_data/lo-cualquier-sea-su-distro-use), cualquier cosa que pueda escribir en un sitio es casi seguro que también podrá escribir en el resto.
Además de cambiar todas las contraseñas, asegúrese de que todas las claves SSH del servidor queden invalidadas en todos los demás servidores (es decir, revoque las claves públicas dondequiera que estén almacenadas en lugar de simplemente eliminar la clave privada) y que cualquier otro sistema que pueda tener ingresó una contraseña (o almacenó una contraseña en un archivo) en/a través de ese servidor y cambió las contraseñas.