Presto Parking: ¿Un sitio web PCI-Compliant sin HTTPs? #PCI #PCICompliant #HTTPs

Hace unos días decidí ir al centro a hacer unas gestiones, y como tenía que aparcar en zona azul me descargué una app llamada "Presto Parking" que permite el pago telemático de la zona azul a través del móvil para no tener que andar buscando cuál es el poste de pago que corresponde a la calle en la que por fin pueda dejar el coche, para no esperar colas si hay otras personas haciendo lo mismo que yo, y para no tener que lidiar con las monedas, el cambio o esas cosas que tanto tiempo te hacen perder. Una app, y un clic, como debe ser el mundo digital.

Figura 1: Presto Parking ¿un sitio web "PCI-Compliant" sin HTTPs?

Estas ventajas son las que propone "Presto Parking". Ya sabéis que "Presto" en español tiene como acepción semántica la rapidez, la velocidad, la diligencia, la presteza. Sonaba bien, y está disponible en varios municipios de la Comunidad de Madrid, así que a probarla, pensé.

Figura 2: Presto Parking en Google Play

Lo primero que hice fue descargarme la app e intentar registrarme desde el smartphone. Sin embargo, cuando llegó el momento de introducir la tarjeta de crédito me pregunté - cosas que se pregunta uno cuando es su dinero lo que está en riesgo - si la conexión entre la app y el servidor que soporta el backend de la misma, estaría cifrada correctamente. Como en la app no indicaba nada y no tenía muchas ganas de ponerme a decompilar el código, decidí buscar la web del fabricante para ver si me podría registrar desde el navegador.

Registro vía web HTTP

Efectivamente, podía registrarme desde el sitio del fabricante, tal y como podéis ver,  pero para mi sorpresa, la web es insegura y envía todo el tráfico por HTTP. No dispone de un cifrado mínimo y por tanto los datos son visibles para cualquiera que este escuchando la red, para todos los que encaminen el tráfico, para todos los elementos de la red, etcétera.

Figura 3: Proceso de registro en formularios bajo HTTP

A pesar de ver que este proceso inicial de registro era inseguro, decidí seguir adelante pues consideré que mi dirección de correo electrónico y la matricula de mi vehículo me parecieron datos que en un momento dado no afectarían en demasía a mi vida - llámame loco -, con la sana intención de ver qué pasaba cuando la cosa se pusiera seria. Es decir, de ver qué pasaba cuando el sitio llegara a lo que de verdad me podría afectar: La tarjeta de crédito.

Ahora la tarjeta de crédito

Fue en la siguiente pantalla cuando me pidió la forma de pago y donde marqué tarjeta de crédito que es la mas cómoda para mí - y también la mas delicada por lo que supone una forma de pago fuente de muchos fraudes -, para ver si esto va "Presto" o "Cifrado".

Figura 4: Web de Presto Parking para enviar tu tarjeta de crédito sin HTTPS y con el logo de PCI-Compliant

Es en la siguiente pantalla donde el sitio web pide los datos de la tarjeta de crédito. No los datos de la tarjeta de crédito en general, sino los datos de MI tarjeta de crédito. Y aquí es donde decidí que había que parar pues, como se puede ver, la conexión sigue estando sin cifrar con HTTPs. Esto es muy preocupante pues cualquiera que escuche puede ver los datos que estoy enviado por la red.

Figura 5: La tarjeta de crédito, con todos sus datos, enviada en texto claro

Como se puede ver en la imagen probé con unos datos erróneos para ver si conectaba de forma segura con el servidor de alguna manera, pero no, los datos van en texto claro.

¿PCI-Compliant?

Pasado este punto, vi el logotipo de “PCI Compliant Enviroment” y ya me pareció demasiado extraño como para ser verdad. ¿Sin cifrado HTTPs puede una web ser PCI-Compliant? Mira que lo dudo.

Figura 6: Logo de PCI-Compliant Environment

¿Qué significa que una web o un entorno telemático es PCI-Compliant Enviroment? Pues en la web se puede ver pinchando aquí, que hay una buena explicación. Básicamente esta web certifica que, si no he entendido mal y el traductor no me ha traicionado:

“El estándar de seguridad de datos de la industria de tarjetas de pago (PCI DSS) es un conjunto de normas de seguridad diseñadas para garantizar que TODAS las empresas que aceptan, procesan, almacenan o transmiten información de tarjetas de crédito mantienen un entorno seguro.”

Y aquí es donde algo falla. O esta web no ha pasado la auditoría PCI y está utilizando el sello como el que coge una imagen de Google Images y lo pega en la web, o el que ha hecho la auditoría PCI no la ha hecho correctamente. ¿Qué habrá sido? Yo me he ido a mirar la guía de cumplimiento del sitio PCI Compliance y el cifrado HTTPs es una parte fundamental del procesado seguro de la captura de la tarjeta de crédito. De hecho, cuando salen bugs como Poodle o Beast, dedican artículos a explicar cómo arreglar estos fallos y volver a tener un entorno seguro que cumpla la nuevas normas de la PCI.

¿El backend seguro?

Lo más curioso es que "el entorno seguro" debe aplicarse a toda la infraestructura, también al backend y almacenamiento, para lo que se deben hacer auditorías de seguridad periódicas. Y no hace falta más que pedir un documento que no existe en la web de Presto Parking para ver que no tienen ni el software actualizado ni los errores controlados.

Figura 7: Errores TomCat de versión desactualizada no controlados

De hecho, si miramos la última versión de la rama Apache TomCat 7.0 vemos que, a día de hoy, es la 7.0.77 y esta versión es la 7.0.61, así que hace tiempo que no se actualiza. Además, el panel de administración de Presto Parking está público y sin cifrado HTTPs, así que un robo de credenciales de cualquiera de los administradores y adios toda la base de datos de tarjetas de crédito. ¿Las tendrán bien cifradas? Si son PCI Compliance deberían, y si no, deberían tener cuidado porque son un objetivo del Carding Básico, sí o sí.

Figura 8: Panel de administración sin HTTPs.. ¿tendrá 2FA?

Lo cierto es que hay por ahí entre 50.000 y 100.000 personas que, según Google Play Store, han instalado esta aplicación y la están usando y que han podido enviar su tarjeta de crédito. Y, visto esto, la pregunta es si estará todo bien como para estar tranquilo. ¿Vosotros qué creéis?

Autor: José C. A.

SandaS & SandaS GRC: Gestión y Gobierno de la Seguridad

Llevábamos trabajando desde principios de este año en la construcción y renovación de nuestros productos que integramos en los Servicios de Seguridad Gestionada que se ofrecen desde Telefónica en los nueve SOCs que tenemos desplegados por todo el mundo. En esta estrategia, que os detallaremos mucho más durante el Innovation Security Day que tendrá lugar el 8 de Octubre de este año, se lanza la primera versión de SandaS y SandaS GRC.

Figura 1: SandaS & SandaS GRC. Gestión y Gobierno de la Seguridad

El primero es un entorno inteligente de tratamiento de eventos de seguridad que correlaciona los incidentes que se detectan continuamente en todos los nodos y elementos de seguridad de una red, como servidores, dispositivos de comunicaciones, IDS, firewalls o balanceadores, y que automatiza el tratamiento de los mismos integrándose en los sistemas de ticketing y alertas. Por supuesto, la gran potencia de este sistema es que, en tiempo real, permite conocer los valores de SLA (Service Level Assurance) de la seguridad de la red.

Figura 2: SandaS en los Servicios de Seguridad Gestionada de Telefónica

Este producto, en el que además hemos utilizado la potencia de Sinfonier para el procesamiento masivo de datos, es una plataforma en la que se han integrado muchos fabricantes de sistemas de seguridad, que además tendrán su espacio en nuestro próximo evento donde haremos alguna demostración de cómo funciona el sistema, con demos en real de orquestación de eventos y visualización en tiempo real de SLAs. 

Sandas GRC

A esta plataforma inteligente para la gestión de la seguridad queríamos añadir una capa de GRC (Governance, Risk Management & Compliance). Esta capa permite tener a los responsables de seguridad un control en tiempo real de en qué niveles de seguridad se encuentra en todo el momento la compañía, teniendo en cuenta los riesgos a los que se está viendo sometido y el estado del cumplimiento normativo al que se ve sometido.

Figura 3: Cuadro principal de gestión de SandaS GRC

Esto permite a los CEO, CISO, CIO o CSOs tener un control del Gobierno de la Seguridad en tiempo real en toda la empresa, teniendo además integrada la parte técnica de la seguridad, ya que el sistema GRC bebe de los datos que se generan en los sistemas de Gestión de la Seguridad. 

Figura 4: Gestión de activos y riesgos en SandaS GRC

Con este objetivo, además de terminar y avanzar en la construcción de SandaS, decidimos en Eleven Paths adquirir el software de GRC de Gesconsultores e integrarlo en nuestra oferta como Sandas GRC, tal y como anunciamos en nuestro blog.

Figura 6: Cuadro de Mando personalizado en SandaS GRC

El software de Sandas GRC permite gestionar y medir el cumplimiento normativo de legislaciones como la LOPD, el ENS, PCI-DSS, ITIL y casi cualquier certificación de calidad y de seguridad ISO 27000, permitiendo a los responsables de seguridad controlar las fortalezas y debilidades de sus compañías. En el siguiente vídeo tienes una breve descripción de sus funcionalidades.

Figura 7: SandaS GRC para el Gobierno de la Seguridad

Desde hace unas semanas, tanto el producto como el equipo técnico detrás del desarrollo del mismo forman parte ya de Eleven Paths y estamos trabajando en enseñaros las novedades en el próximo Innovation Security Day, pero si quieres más información del mismo, no dudes en consultar la web de SandaS y SandaS GRC y ponerte en contacto con nosotros.

Saludos Malignos!

Evaluar la calidad de un escáner de vulnerabilidades web

Como ya os he contado, en Eleven Paths estamos creando una nueva cosa que internamente llamamos Foca as a Service. No es nada más que una FOCA mutada para encargarse de hacer los servicios de Pentesting Continuo que vamos a empezar a ofrecer desde el próximo mes de septiembre para crear una nueva forma de hacer auditorías continuas a los sitios web de las organizaciones que lo contraten.

Ayer tuve la ocasión de sentarme a ver en detalle los resultados que estamos obteniendo, y la verdad es que estoy muy contento de la cantidad de pruebas que se hacen en un sitio, y los resultados obtenidos en cada una de las prueba contra sitios que ya habían tenido una auditoría previa. Ahora bien, en los scanners de vulnerabilidades web siempre queda la pregunta que te hace un cliente.

¿Cómo saber que este escaneo de un escáner de vulnerabilidades es suficientemente bueno?

Es difícil de valorar, y dependiendo de la naturaleza de las vulnerabilidades que tenga el sitio web unos encontrarán más o menos resultados. En un trabajo del 2013 realizado por Fernando Román Muñoz y Luis Javier García Villalba en la Universidad Complutense de Madrid titulado "METHODS TO TEST WEB APPLICATION SCANNERS" se hacía una curiosa comparativa sobre varios tests de comparación de resultados sobre escáners de vulnerabilidades web.

Figura 1: Clasificación de escáners web en 4 comparativas distintas

En él se concluye al final que es necesario crear un conjunto de vulnerabilidades de referencia en aplicaciones web que vayan adaptándose a la realidad del tiempo, es decir, que vaya cambiando el conjunto de referencia a medida que avanza el estudio de nuevas vulnerabilidades o técnicas de descubrimiento.

Figura 2: Tipos de vulnerabilidades que se evalúan en las diferentes comparativas

En PCI DSS, el famoso estándar para los medios de pago con tarjetas de crédito, existe la figura del ASV (Approved Scanning Vendors) que no es más que escáners de vulnerabilidades aprobados por PDI DSS para ser utilizados en la búsqueda de vulnerabilidades para pasar la certificación PCI. Estos escáners deben buscar y encontrar un conjunto de vulnerabilidades antes de conseguir el nivel de aprobación, y estas van desde nivel de red o versiones de software desactualizadas hasta las que aparecen en aplicaciones web.

La descripción de las vulnerabilidades que debe buscar y encontrar un ASV las podéis ver en la guía "Payment Card Industry (PCI) Approved Scanning Vendors" donde en la parte relativa a web se describe lo siguiente:

Figura 3: ¿Qué vulnerabilidades web debe encontrar un ASV?

Por supuesto, los ASV no tienen necesariamente que ser los mejores del mundo, pero sí que han pasado al menos un conjunto estandarizado de vulnerabilidades que eliminarían las que PCI ha definido como más importantes.

En un entorno real, puede que la vulnerabilidad sea muy gorda, pero ningún escáner sea capaz de localizarla. De hecho, hace tiempo hicimos una comparativa con los escáners más populares y las Inverted Queries, es decir, consultas SQL escritas al revés con vulnerabilidades de SQL Injection, y los resultados fueron bastante sorprendentes.

Figura 4: How "·$% developers defeat the web vulnerability scanners de Chema Alonso

Al final, la recomendación más efectiva es utilizar cuantos más escáners se pueda mejor para buscar las vulnerabilidades, porque no todos utilizan las mismas técnicas de detección y no buscan las mismas vulnerabiliades y fallos en las aplicaciones web, que estas pueden aparecer y ser encontradas de formas muy diversas.

Saludos Malignos!