☰

Hack de PHP eval(gzinflate(base64_decode(..))) - ¿cómo evitar que vuelva a ocurrir?

tag-icon • tag-icon security php hacking vulnerabilities
Hack de PHP eval(gzinflate(base64_decode(..))) - ¿cómo evitar que vuelva a ocurrir?

Recientemente pirateamos un sitio web, donde se inyectó un código PHP en el archivo index.php que se parecía a:

eval (gzinflate(base64_decode('s127ezsS/...bA236UA1')));

El código provocaba que se incluyera otro archivo php (cnfg.php), lo que provocaba que se mostrara spam relacionado con productos farmacéuticos (pero sólo visible para googlebot et al). Esto se parece al truco farmacéutico para WordPress, excepto que no estamos ejecutando dicho software. Desde entonces, el código se eliminó, pero me gustaría evitar que esto suceda en el futuro.

Me doy cuenta de que este es un problema bastante amplio y que podría haber una gran cantidad de agujeros de seguridad que podrían ser responsables, pero pensé en publicarlo en caso de que alguien haya tenido experiencia con un problema de este tipo en el pasado.

¿Cuáles son algunos posibles agujeros de seguridad que permitirían cargar estos archivos php? ¿Y qué puedo hacer para evitar que esto suceda en el futuro?

Salud

Respuesta1

Necesitas descubrir cómo llegó eso allí.

  • ¿El atacante tuvo acceso al sistema de archivos a través de sftp/scp?
    • Si esto sucedió, debes bloquear tus métodos de acceso remoto.
  • ¿El atacante utilizó algún script de carga o algún error en un script existente que le permitió modificar archivos?
    • Corrija el script, cambie los permisos en sus scripts y contenido web para que el proceso del servidor web no pueda cambiarlos. El servidor web debe limitarse a modificar archivos en un directorio de datos en algún lugar. Por lo general, sus scripts y archivos no deben ser propiedad del servidor web ni deben poder escribirse en él.
  • ¿El script forma parte de algún software malicioso que instalaste?
    • He visto cosas así incluidas como parte de las plantillas de WordPress. Un usuario desprevenido descargó plantillas de algún sitio aleatorio. Esas plantillas incluían una función para ejecutar código desde un servidor web externo. Esto, combinado con una configuración de permisos deficiente, permitió al atacante modificar otras cosas.

Respuesta2

Sólo una advertencia.

Si está utilizando FileZilla como su cliente FTP, existe malware que tomará sus credenciales FTP del ARCHIVO DE TEXTO SIMPLE de Filezilla (¡ay!) y usará esa información para insertar ese código de malware (indicado por el tipo de código #b58b6f# alrededor de un comando "gzinflate(base64_decode)" Así es como sus archivos serán atacados/comprometidos.

Busque en su carpeta %APPDATA%/Roaming/Filezilla. ¡Uno de los archivos XML que contiene tiene todas las credenciales de su sitio web FTP (usuario/contraseña/etc.) en TEXTO SIMPLE! Y la gente de FileZilla se niega a arreglar ese evidente agujero de seguridad.

Mi recomendación: elimina FileZilla de tu computadora (y tienes que eliminar manualmente la carpeta en tu carpeta APPDATA).

Si necesita un cliente FTP seguro, utilice WinSCP (www .winscp .net ), donde puede establecer una contraseña maestra y todas las credenciales de su sitio están cifradas.

Sólo una advertencia... Rick... J

Respuesta3

Hay un enorme abanico de posibilidades sobre cómo podría haber llegado esto. Un dato que ayuda a limitar esto es qué tipo de alojamiento tiene (compartido, dedicado, virtual) y quién es su anfitrión. Algunos posibles puntos de entrada son

  • Compromiso de la cuenta de administrador
  • Compromiso desucuenta ftp/ssh/web console/etc con su proveedor. Si alguna vez envía su contraseña a través de un protocolo no cifrado (como FTP), deje de hacerlo.
  • Compromiso desupropia máquina de desarrollo local
  • La vulnerabilidad es cualquiera de los programas del servidor en el servidor, como Apache o cualquiera de sus módulos.

  • Vulnerabilidad a nivel de aplicación en PHP en su sitio:

    • ¿Está utilizando software de terceros? De ser así, ¿está todo actualizado?
    • ¿Ha escrito una cantidad significativa de su propia programación en el sitio? Si es así, hay un millón de maneras en que podrías haber escrito un agujero. Marque cualquier método que toque datos provenientes de la entrada del usuario (SOLICITUD/OBTENER/POST/COOKIES/ARCHIVOS). Si permite la carga de archivos, ¿guarda esos archivos sin filtrar en un directorio visible en la web? Si es así, alguien podría cargar un script .php y luego simplemente verlo. Las declaraciones include/require son objetivos especialmente importantes si utiliza una solución de plantillas como:

    <?php include $_GET['page'] . '.php'; ?>

¿Cómo evitar que vuelva a ocurrir?

  • Asegúrese de confiar absolutamente en la seguridad de su anfitrión. Llámelos e infórmeles sobre sus políticas de seguridad, qué tan rápido parchean sus servicios cuando surgen vulnerabilidades, etc.
  • Evite el alojamiento compartido barato y pague por uno dedicado o virtual. Menos personas usando el servidor significa menos vectores de ataque
  • Mantenga actualizadas sus propias aplicaciones/bibliotecas de terceros. Inscríbase en su lista de correo, canales RSS o cualquier cosa para mantenerse actualizado con sus lanzamientos.
  • Audita tu propio código. Si no tiene suficiente experiencia para esto, busque a alguien que pague por ello.
  • Mantenga su sitio en control de versiones como git o subversion. Mantenga su directorio de producción como una copia de trabajo para que pueda detectar fácilmente cambios en su código base (pero asegúrese de bloquear el acceso a metadatos como los directorios .git y .svn).

Respuesta4

Quizás quieras probarhttp://www.hardened-php.net/suhosin/que, entre otras cosas, podría haber desactivado eval(). Si cnfg.php estuviera alojado de forma remota, podría haber impedido que también se incluyera.

Si es posible, no conceda al usuario que el servidor web se esté ejecutando como acceso de escritura a los archivos php.

información relacionada