Los datos de los clientes de Panamericana siguen expuestos

El pasado 5 de abril encontré un link vulnerable en el proceso de actualización de datos de clientes en Panamericana, yo reliacé el reporte y a la fecha de 24 de abril del 2023 no he recibido comunicación alguna de parte de Panamericana. Sin embargo, el día 11 de abril encontré diferencias en el proceso pero sigue siendo vulnerable como describo a continuación.

La UX (experiencia de usuario)

El objetivo de Panamericana es que los usuarios sean los que actualicen sus propios datos personales. Para eso ellos han ubicado unos códigos QR en las cajas de sus almacenes. Los códigos dirigen a un URL parecida a esta:

https://integraciones.panamericana.com.co/WebApiCRMClientesQR/?&up={codigo-de-la-tienda}

Al escanearlo la página que dirige luce así.

Y al seleccionar persona natural se dirige a otro formulario que solicita el tipo de identificación y el número.

Y voila!, este formulario es un oráculo de información personal. Basta con digitar un número de identificación existente y arroja (no siempre) nombre completo, celular, email y dirección.

Los cambios hechos por Panamericana

Panamericana ha intentado solucionar la vulnerabilidad, su primer paso, fue eliminar el endpoint que había reportado inicialmente, ya no se puede (como si se alcanzó a probar) enumerar cédulas y descargar toda la información personal de sus clientes de forma prográmatica. Pero sigue habiendo una vulnerabilidad.

🤖 Agregaron captcha, El captcha es una herramienta que verifica o intenta verificar que el usuario sea un humano. Panamericana usó el captcha de Google el cual es bastante efectivo, aunque podría cuestionarse por temas de privacidad pero creo que como medida para prevenir la vulnerabilidad reportada es suficiente.

🤔 La URL necesita un identificador de la tienda, esta medida sí me parece un poco ingenua. La idea es que los clientes solo puedan usar la página si la URL tiene un parámetro up con un código de tienda válido. Sin embargo no tenerlo solo requiere un poco de JavaScript para hacer que funcione ya que las validaciones son solo del lado del navegador (cliente).

Ahora bien, ¿porqué me parece ingenua la medida tomada?. El código de una de las tiendas de panamericana luce así: U2FsdGVkX19pUghqTcz45Guqwf2e7HxmksVQ8nqMaak=. Es una cadena de bytes codificada en base64, como no es necesaria no le hice más indagaciones (por ahora). Al ingresar a la URL sin el código de tienda deja ingresar a la página pero la momento de mostrar el formulario de consulta aparece un pop-up diciendo que no se pudo identificar la tienda y al cabo de unos segundos redirige a panamericana.com.co:

ERROR!: No logramos reconocer en qué tienda te encuentras, Escanea de nuevo el Código QR.

Pero como decía anteriormente, saltar ese pop-up solo requiere un poco de JS justo antes de redirigir a la página de ecommerce de Panamericana.

for(i=0; i<100; i++) {
	window.clearInterval(i);
};

Lo que hace ese código es limpiar todos los posibles contadores inicializados en la página. El contador redirige a panamericana.com al llegar a cero. Con ese código ya no redirige, se limpia un poco el HTML en el navegador y el formulario sigue funcionando sin necesidad del código de tienda.

Para que ese código de tienda sea una medida válida, tendría que ser cambiado cada 5 minutos, incluso menos, o para cada usuario. De lo contrario un atacante que obtenga el código va a poder usarlo mientras dure. Eso si, asumiendo que va a ser requerido en todo el proceso de la actualización de datos.

Posibles soluciones

• No dejar que los clientes actualicen sus datos ellos mismos, 🤷 compensar entre seguridad y usabilidad no es una decisión fácil. Sin embargo es mejor siempre abogar por la seguridad. Nada es más importante que respetar la privacidad de la información, en especial información personal.

• No mostrar la información anterior al actualizar los datos. En este momento el formulario muestra los datos al hacer clic en un botón llamado “Actualizar datos”, el formulario no debería mostrar nada, en caso de querer mostrar la información podría ser una versión ofuscada solo los últimos tres dígitos del celular, solo la primera letra del correo electrónico y el dominio, ejemplo: [email protected]. Pero me inclino más por no mostrar nada.

• Generar un código único para autorizar la actualización de datos, en vez de generar un código por tienda evaluar generar un código por usuario, ejemplo: El usuario se arrima a la caja a pagar, en caja le preguntan si desea factura electrónica, en caso de que si, el cajero genera un código QR único con una clave criptográfica válida por un tiempo corto (un JWE puede funcionar) que le permita acceder al formulario.

• ¿Cómo evitar que alguien modifique la información maliciosamente?, ese es un riesgo con el actual proceso, y las soluciones que propongo igual dejan abierta esa posibilidad. Creo que las personas deberían recibir algún tipo de código de un solo uso para autenticarse en el formulario, claro, si los datos no están actualizados el código no puede llegar a un destino válido, en ese caso el cajero debería hacer la actualización.

En conclusión

• Panamericana sigue sin dar respuesta a mi caso. Ya no importa, ahora solo lo documento.
• Crear apliaciones seguras es díficil.
• Como escribí en mi reporte inicial, necesitamos una mejor cultura del reporte.