Muy buenas compañeros, llevaba tiempo ya queriendo estrenarme en el blog y finalmente he conseguido el tiempo suficiente para traeros este post.
Primeramente comentar que la vulnerabilidad mostrada en esta entrada ya ha sido comunicada a la empresa auditada, y que por supuesto no se mostrará información sobre la empresa ni sus clientes. La publicación unicamente tiene fines educativos, con el proposito añadido de concienciar a los desarrolladores web a evitar este tipo de fallas de seguridad en sus aplicaciones.
Y sin más os pongo en situación, hoy en día gran parte de las ventas que se hacen vía telefónica (a través de Contact Center), ya sean de un producto, un servicio determinado, o la contratación de suministros requiere de la aceptación de un contrato a través de Internet.
La empresa auditada genera una llamada telefónica hacia el cliente con el fin de venderle su servicio, cuando el cliente accede a contratar el mismo recibe un SMS donde se le redirige a una URL con sus datos y el contrato para aceptar como podemos ver a continuación.
Lógicamente los datos han de ser enviados por GET y podemos apreciar en la URL que se envía un identificador de cliente (id) y un teléfono (phone), comprobamos que sucede si alteramos el teléfono:
Hemos descubierto que si el ID y el PHONE no coinciden la
página nos muestra un error de mysql sin controlar. Por lo tanto podemos
hacernos una idea de la consulta SQL que hay en el PHP que genera el contrato.
Llega el momento de comprobar si el desarrollador simplemente olvidó quitar
el Display Error o es que no realiza ningún tipo de control de los datos
recibidos:
Tras realizar varias pruebas y comprobar que es vulnerable a una inyección
SQL (Más sobre SQLi: Enlace) vemos que tenemos acceso a
absolutamente todos los datos de los clientes, incluidas las tarjetas de
crédito y sus datos bancarios, además de poder aceptar los contratos en su
nombre, si bien el Sistema de Detección de Intrusos (IDS) bloquea las
herramientas automatizadas como SQLmap o NinjaSQL, así como las consultas de
gran carga como las que abusan de concat.
Por lo tanto emplearemos "--" para comentar la consulta que
sigue al id y evitar de esta forma tener que introducir el teléfono del
cliente para obtener sus datos.
Es en este momento donde echaremos mano de CURL (empleando un servicio
oculto de TOR), para el que no lo conozca CURL nos permite enviar peticiones a
un servidor web y analizar la respuesta. En este caso concreto hice un pequeño
script para automatizar el envío de peticiones con PHP y almacenar todos los
contratos.
De esta forma tan sencilla es posible acceder a los datos de los clientes de
la Empresa auditada que no pone en peligro sus propios datos sino los que hacen
referencia a sus clientes, incumpliendo la normativa europea y por supuesto la
LOPD.
¿Cómo evitamos esta vulnerabilidad?
La web está generada en PHP por lo tanto el programador puede utilizar la
función mysql_real_escape_string o bien controlar los datos recibidos.
Es importante también implantar un protocolo de transferencia seguro (HTTPS en
vez de HTTP) para evitar que la información llegue al servidor web en texto
plano y evitar que se visualicen los mensajes de error por el cliente.
Un saludo compañeros,
Alejandro Cañas