¿De dónde provienen las solicitudes sospechosas de los usuarios registrados en mi sitio web?

1

Tengo una aplicación web ASP.Net MVC 4 que está alojada en un servidor Windows 2008. La aplicación está protegida por un proveedor de membresía ASP.Net personalizado. Solo los usuarios que tienen permiso del administrador tienen acceso. La aplicación contiene datos médicos confidenciales de individuos.

Recientemente, descubrí que 60 de los 320 usuarios registrados están enviando solicitudes sospechosas a mi sitio web. Estas solicitudes obtienen una respuesta HTTP de estado 404, ya que no existen en mi sitio y son inadecuadas. Como ejemplo, este es el subconjunto de URL que contienen 'admin':

    /_vti_bin/_vti_adm/admin.dll
    /admin.php
    /admin/597ea5fc-0805-4b3c-8ab8-3d5320d8683c
    /admin/chgpwd.php
    /admin/default.asp
    /AdminHTML/parse_xml.cgi
    /admin-serv/authenticate
    /admin-serv/config/admpw
    /advwebadmin/adminsettings/browsewebalizerexe.asp
    /advwebadmin/SQLServ/sqlbrowse.asp
    /iisprotect/admin/GlobalAdmin.asp
    /mailman/admin/mailman
    /phpmyadmin/sql.php
    /scripts/admin.cgi
    /shop/admin.php
    /shopscript/admin.php
    /SiteServer/admin/
    /store/admin.php

Se espera poco daño de una solicitud como /store/admin.php, ya que no hay archivos .php en el servidor. Todavía me molesta, porque mis usuarios han iniciado sesión cuando llegan las solicitudes. Es decir, las sesiones y las cookies de autenticación se envían con las solicitudes. Por lo tanto, si se enviara una solicitud válida, el servidor podría revelar información confidencial en la respuesta, ya que el servidor confía en que las solicitudes sean genuinas. Utilizo un token anti-falsificación para evitar la falsificación de solicitudes entre sitios, pero esto evitará solicitudes de obtención maliciosas. Estos son casi tan problemáticos, debido a los datos confidenciales en el sitio. Además, si las solicitudes sospechosas se originan en el navegador del usuario, no hay "sitios cruzados".

Hasta ahora, he podido confirmar que las solicitudes autenticadas llegan cuando el usuario realmente está usando la aplicación. Es decir, las solicitudes sospechosas llegan entre solicitudes válidas y mi registro también muestra que los usuarios han iniciado sesión. Ahora estoy intentando registrar solicitudes completas, incluidas direcciones IP de origen, encabezados HTTP y cookies. No es trivial, ya que mi aplicación está detrás de un servidor proxy inverso.

Mientras tanto, me pregunto cuál podría ser el origen de estas solicitudes, teniendo en cuenta que muchos de mis usuarios están involucrados. Podría ser:

  1. ¿Mucho malware presente en los navegadores de los usuarios?
  2. ¿Otro malware en los clientes?
  3. ¿Ataques de hombre en el medio?
  4. ¿Malware en el servidor web?
  5. Malware distribuido por mi aplicación web, javascript?

Además, la aplicación web se analiza regularmente con una herramienta de prueba de penetración de McAfee. Esta herramienta no inicia sesión. Descubrí que todas las URL en solicitudes sospechosas, hechas de sesiones de usuario, también las realiza McAfee (hasta ahora, 205 URL diferentes). Sin embargo, el propio McAfee también utiliza muchos otros (3300+). Esto me hace preguntarme si las solicitudes de los usuarios podrían mezclarse en algún lugar de la red, debido al almacenamiento en caché o lo que sea, por lo que realmente estoy viendo un problema. Por supuesto, tengo un problema mucho más grande si las solicitudes se mezclan. Por otro lado, las solicitudes están correlacionadas en el tiempo con las sesiones del usuario, no con los intervalos de ejecución de las pruebas de penetración y tal vez las URL son solo las vulnerabilidades que el malware está buscando.

    
pregunta user39471 04.02.2014 - 17:26
fuente

3 respuestas

0

Al final, esto fue solo un artefacto , como ya lo consideré:

  

Esto me hace preguntarme si las solicitudes de los usuarios podrían confundirse   En algún lugar de la red, debido al almacenamiento en caché o lo que sea, para que yo esté   en realidad mirando un no-problema.

Afortunadamente, solo el registro se confundió. Yo uso log4net. Al comienzo de cada solicitud, especifiqué propiedades como nombre de usuario, URL solicitada y dirección IP, en un ThreadContext de log4net. Desde cualquier lugar en el código, se puede crear una entrada de registro, sin conocer estas propiedades. Sin embargo, debido a la agilidad del hilo en ASP.Net, en el momento de crear realmente una entrada de registro y se leyeron las propiedades en ThreadContext, ASP.Net a veces procesaba otra solicitud en ese hilo que el una a la que pertenecían las propiedades!

Gracias por su tiempo, ayuda y disculpas por informar de este problema que malinterpreté por completo.

Lea log4net Problemas de contexto con la agilidad del hilo de ASP.Net para para un análisis preciso del problema, y log4net Contextual Properties and ASP.NET para una buena solución, que en realidad apliqué.

    
respondido por el user39471 02.05.2014 - 22:32
fuente
2

La lista de URL que ve es similar a las producidas por herramientas como nikto que solicitan una lista de URL potencialmente vulnerables o conocidas. Por supuesto, una lista como esta podría (y probablemente sea) utilizable por el malware, así como herramientas de prueba como nikto.

Un factor interesante para rastrear lo que está haciendo esto sería, ¿cuál es el agente de usuario en estas solicitudes? Muchas herramientas de prueba tendrán un agente de usuario personalizado para que se pueda detectar su actividad, mientras que el malware probablemente intentará hacer que parezca una cadena de navegador de usuarios estándar para que sea menos notable.

De cualquier manera, sería más difícil para la herramienta hacer coincidir por completo la cadena del navegador del usuario real, por lo que asociar a los usuarios "usuales" con las solicitudes extrañas que parecen provenir de ese usuario podría ayudarlo a resolver lo que está sucediendo.

    
respondido por el Rоry McCune 04.02.2014 - 18:26
fuente
2
  

Podría ser:
  ¿Mucho malware presente en los navegadores de los usuarios?

Posiblemente.

  

¿Otro malware en los clientes?

Posiblemente.

  

¿Ataques de hombre en el medio?

Menos probable.

  

¿Malware en el servidor web?

Menos probable.

  

Malware distribuido por mi aplicación web, javascript?

Posiblemente.

Sin embargo, lo más probable es que sea un bot o una herramienta de escaneo creada con el fin de detectar debilidades en los sitios. Podría estar alojado en la computadora de un usuario, o posiblemente no. Ese punto realmente no importa un montón entero. Lo que importa es a qué tiene acceso el bot y a qué es vulnerable tu aplicación.

El hecho de que un gran porcentaje de tus usuarios parezcan atacantes maliciosos es un poco desconcertante. Si en realidad es correcto, entonces eso significa que debe restringir su proceso de registro, pero me imagino que debe examinar sus eventos un poco más de cerca para determinar qué está sucediendo.

Recomiendo buscar en los registros de solicitudes reales (un archivo de texto IIS) que le proporcionarán la URL, el estado, el agente de usuario y la IP de cada solicitud (entre otras cosas) y puede correlacionar eso con otras solicitudes para ver si está realmente asociado con los usuarios registrados.

    
respondido por el tylerl 04.02.2014 - 18:26
fuente

Lea otras preguntas en las etiquetas