La idea de este post es dejar al descubierto como reaccionan las empresas cuando se les reporta un problema de seguridad critico, como no son capaces de responder e intentan esconder el error.
Servipag es un servicio para pago de cuentas en linea, muchos usuarios hacen uso de este servicio sin saber realmente a quien estan entregando su información.
En la sección “Quienes somos” podemos ver el siguiente mensaje:
Como es de costumbre de todas estas empresas, todas tienen un “alto estandar de seguridad” y todos invierten millones y millones en las ultimas tecnologias y ultimos estandares de seguridad, pero todos nosotros sabemos que eso es una mentira.
Según ellos:
Seguridad
Contamos con las herramientas de más alto nivel en seguridad y eficiencia que la tecnología virtual ofrece en el mercado actualmente.
Desde hace meses que Servipag.cl es vulnerable a distintos tipos de ataques que afectan directamente al servidor y tambien a los usuarios. Las vulnerabilidades que se reportaron en este sitio son Directory Traversal, Local File Include (LFI) y Cross Site Scripting (XSS).
Al ser reportadas tardaron 2 días en dar una respuesta. Como ya es un hecho en la mayoria de los sitios web, no cuentan con un procedimiento para reportar vulnerabilidades lo que hace más lento todo este proceso. Por twitter, la cuenta @ServipagOnLine comenzó a seguirme y me dijo “Nuestro jefe de proyectos se contactara contigo“, 7 días despues lo único que he recibido es un correo que dice:
Le respondí cómo podía contactarme y eso fue el fin de la conversación.
Las vulnerabilidades
Local File Include & Directory Traversal
Esta vulnerabilidad permite navegar arbitrariamente por los archivos del sistema, pudiendo ver su contenido. La vulnerabilidad se encuentra en el archivo “browse.asp”, al pasarle mediante la variable “pagina” el archivo que deseamos ver, por ejemplo “../../../../../../../../../../../boot.ini”.
Antes de haber enviado el primer reporte de vulnerabilidad, esta vulnerabilidad podia ser explotada añadiendo la ruta del directorio usando los “slash” normales (/), pero magicamente durante la semana y luego de haber sido reportada, la vulnerabilidad ya no podía ser explotada de esa forma, y el sistema mostraba un error:
Pero gracias a la contribución de @1error500, nos dimos cuenta que no había sido solucionado. El programador o quien sea que haya hecho el cambio, lo único que hizo fue un vergonzoso parche, ya que si cambiamos los “slash” por “backslash” (\), podemos explotar nuevamente la vulnerabilidad.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
127.0.0.1 localhost
192.168.2.8www.servipag.com
Una verguenza de seguridad.
Cross Site Scripting (XSS)
Como si fuera poco, este sitio tambien es vulnerable a XSS que afectaba al mismo archivo browse.asp, pero esta vez a la variable “p” y a la variable “mensaje_error” dependiendo de la “pagina” a mostrar.
- http://www.servipag.com/browse.asp?pagina=web/preguntas_frecuentes4.htm&bloque=Pagos%20Preguntas%20Frecuentes1&p=%3Cscript%3Ealert(/XSS/)%3C/script%3E
- http://www.servipag.com/browse.asp?pagina=web/msgerror.htm&mensaje_error=%3C/a%3E%3Cscript%3Ealert(%27XSS%27)%3C/script%3E
Aparentemente el error está corregido, ya que muestra el mismo mensaje de más arriba. Pero, estará realmente corregido?
Bueno, esto demuestra el horrible manejo de incidentes que tienen las empresas que dicen tener altos estandares de seguridad. Empresas que prometen privacidad y seguridad, hacen que los usuarios confien en ellos y nuevamente quedan al descubierto.