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.

Si es que van pidiendo guerra

En muchas auditorías que tenemos que hacer en el curro, la historia comienza con una llamada del tipo “me han cambiado la página de inicio”, “me han quitado de Google por estar sirviendo malware desde mi web” o el clásico “me han borrado todo y no tengo backup!”.

Cuando tienes que hacer una auditoría que empieza así… sabes que va a ser coser y cantar. Alguna cagada gorda tienen. Y sí, siempre sale un RFI, un panel de control con SQL Injection, una base de datos con contraseñas sin cifrar y alguna bonita forma de calzar una Shell. Sorprendentemente, no pasa todo lo que debería pasar, porque hay mucha gente que aún no ha tomado conciencia de los riesgos de no preocuparse por la seguridad. Y de eso va esta historia de domingo.

Estaba yo matando el tiempo en esas cosas que se suelen hacer, ya sabes, buscar alguna manera de dar por saco. Como dice el dicho, “Cuando el diablo no sabe qué hacer…”. En concreto quería hacer un conteo de cuantas bases de datos .mdb quedan publicadas y localizables con información sensible en España. Ya sabes, solo por jugar un rato.


Figura 1: Pues todavía quedan mdbs por ahí...
En uno de los links me apareció una URL con el puerto 8080 y pensé: “Coño, esos sitios sí que son graciosos. Vamos a buscar webs por el 8080 y así veo que puertos curiosos acaban indexados en Google”.


Figura 2: Buscando 8080s
Una vez ahí, me acordé de que en una auditoría nos había tocado un JBoss en el que el usuario era admin y la password [Una de las tres primeras que se te ocurra] y decidí buscar los Tomcat con el status abierto por el puerto 8080 y ver si esto era muy típico. Aparecieron un cerro de Tomcats, y … un montón de JBOSS.


Figura 3: Buscando el status del TomCat
En los JBOSS, normalmente se instala una consola de administración web y la consola JMX. Si el sitio tiene abierto el path por defecto basta con que pidas el directorio principal y te sale la ventana principal de JBOSS.


Figura 4: Página principal de JBOSS
Pero si no, es tan sencillo como pedir /web-console/ o /jmx-console/. Tras probar con los tres primeros al azar, los tres permitían entrar con admin[una de las tres primeras que se te ocurra]


Figura 5: Web-Console de un JBOSS
Tras jugar un poco con ellos, la gran mayoría son vulnerables a ese par de contraseñas por defecto en la que la password es igual que el nombre. De hecho, una vez que estás en ese punto de la consola de administración, basta con crear un Web Archiver [war file] y crear una nueva aplicación en el sitio web. Tienes un guía muy chula sobre cómo hacer esto en: Hacking JBOSS.

En la consola JMX puedes acceder a un montón de información chula. Para entrar, tan sencillo como pedir /jmx-console/ y listo.


Figura 6: JMX-console de un JBOSS
Y haciendo búsqueda por las configuraciones de la conexión a la base de datos, puedes ver las opciones seleccionadas.


Figura 7: Configuración de la base de datos
Sí, sa, y me lo he encontrado en varios que iban sobre Microsoft. Pero también he visto un JBOSS corriendo como root. Otra parte chula es la configuración de correo, en el servicio mail. Para montar una aplicación de SPAM es perfecto.

Mirando algo de información, he visto que esto lleva así desde tiempo ha, y hay un Google Dork para detectar sitios que directamente no piden usuario y contraseña. Es decir, para que subas tu Shell y… ¿vamos, es esto serio? ¿Esto es de coña, no?

intitle:”jboss management console” “application server” version inurl:”web-console”

Pues sí, el Google Dork busca la página se server-info. Y una vez que estés en el sitio, busca las consolas pidiendo /web-console/ y /jmx-console/ Si es que van pidiendo guerra…

Saludos Malignos!