Cómo descubrí el agujero de seguridad de Global Omnium
Quizás te has enterado del agujero de seguridad que ha dejado al descubierto datos de miles de de vecinos de València y que ha llevado al Ayuntamiento a pedir una auditoría externa a Global Omnium. Pues bueno, aquí te cuento cómo descubrí el agujero y sus detalles más técnicos.
Soy una persona muy inquieta, eso es un hecho. Con los años, he desarrollado un sexto sentido que me permite anticipar cómo funcionan los productos digitales por dentro y percibir cuando algo huele mal. Cuando inocentemente me bajé en mi móvil la aplicación de ‘Global Omnium’ para ver el consumo de agua de mi casa, esas malas vibraciones no tardaron en llegar. Pero incluso cuando te temes lo peor, algo más insólito te sorprende. Te invito a adentrarte conmigo en el mundo de la desidia tecnológica, cuyo resultado deja expuestos datos personales de miles de ciudadanos. ¿No queríais celebrar Halloween? Pues aquí va una historia terrorífica.
Global Omnium: el gigante del agua potable
Para los lectores que no conozcan Global Omnium, se trata de un grupo empresarial de capital español dedicado a la gestión de aguas que abastece a más de 6 millones de personas. Muchos municipios españoles confían en esta empresa para la gestión integral del agua, como es el caso de València mediante EMIVASA.
Además, en los últimos años Global Omnium ha estado apostando por crear hubs de innovación alrededor del agua, industria 4.0 y smart cities, impulsando una aceleradora propia llamada Go:hub. Todo muy puntero e innovador, sin duda.
Vine por mi consumo y me quedé por el agujero
Tenía ya la aplicación de clientes Global Omnium descargada en mi iPhone e inicié sesión por primera vez con mi e-mail y mi contraseña. Me llamó bastante la atención el aspecto poco nativo y fuera de toda línea de diseño de Apple, asumiendo que sería algún tipo de desarrollo multiplataforma Xamarin (este tipo de pensamientos intrusivos que solo suelo tener yo).
Cuando estaba ya dentro de mi cuenta, me percaté de que podía acceder a los consumos de agua con una actualización casi diaria. Wow. Los nuevos contadores que ponen en València son inteligentes y transmiten datos de forma automática y con regularidad, cosa que es bastante guay. Así que se me encendió la bombilla y, en mi afán de domotizar mi casa y tener el mayor número de datos sobre la vivienda, se me ocurrió conectar los datos de esta aplicación a mi centro de domótica de código abierto (Home Assistant). ¿Para qué? Así podría tener un estimado de lo que voy a pagar día a día y tener una mayor conciencia sobre el consumo de agua en mi casa. Repito: ¿para qué? Bueno, no sé, dejémoslo en que me gusta conectar cosas.
Con este objetivo en mente, me preparé para hacer una primera auditoría al funcionamiento de la aplicación y la comunicación con el servidor. Por lo general, un cliente (la app) y un servidor (el de Global Omnium) intercambian paquetes de datos en la red (Internet) mediante una serie de protocolos. Es como una conversación en la que se preguntan y responden de una forma ordenada y estructurada. Es común utilizar el protocolo HTTP para que estas conversaciones sucedan, por lo que si analizásemos los paquetes de datos que ocurren en nuestra red, podríamos ver las conversaciones y el baile de datos de un sitio a otro.
Como os podéis imaginar, sería un tanto peligroso quedarnos solo con este protocolo de intercambio de información, ya que simplemente interceptando los paquetes de un lado al otro podríamos enterarnos de qué va la conversación entera. Un poco desastre. Así que gente muy lista ideó lo que conocemos como Seguridad de la capa de transporte (TLS), que implementan protocolos de cifrado en los mensajes. ¿Resultado? Aunque interceptásemos uno de ellos, solo veríamos números y letras rarísimos y nos quedaríamos igual. Hoy en día casi todas las comunicaciones sobre HTTP implementan TLS, por suerte para todos. (HTTPS)
Con todo esto en mente, abrí Burp Suite, mi herramienta de seguridad y analítica de redes favorita. Activé el proxy en mi móvil, que no es más que decirle al iPhone que, a partir de ese momento, todo el tráfico de red tiene que pasar por mi ordenador. En mi ordenador ya estaba Burp Suite esperando tráfico (mensajes) y listo para interceptarlos.
¿Qué ocurre cuando ponemos un proxy y las aplicaciones intentan comunicarse mediante HTTPS? Pues que fallan. No pueden. Nada funciona. Sin entrar en tecnicismos, al haber un intermediario cuyo certificado es completamente desconocido, las peticiones se marcan como inseguras y no funcionan. Además, muchas aplicaciones como Instagram, Twitter… bloquean el intento de transmisión al haber un destino u origen desconocido.
Sin embargo… ¿qué hacía la aplicación de Global Omnium? Pues bueno, ignorar completamente el hecho de que el destino y origen de los paquetes no era legítimo y obviar que mi proxy estaba en medio de todas las comunicaciones sin importarle lo más mínimo. En su momento esto me pareció algo grave, sin duda. Pero lo peor estaba por llegar.
Disclaimer: esta auditoría de seguridad se ha llevado a cabo por motivos meramente educativos, sin perjuicio a ningún usuario y usando un único proxy para analizar los paquetes en la red personal. Por lo tanto, no han intervenido técnicas de decompilación de binarios ni de acceso a programación interna de carácter privado de la empresa.
Disclaimer 2: La información que se relata en este artículo ha sido puesta en manos de la empresa Global Omnium para evitar que las vulnerabilidades pudiesen ser explotadas por otros usuarios y ya han sido corregidas según informaron al diario ValenciaPlaza.
Tragedia 1: la tecnología del servidor y sus protocolos
Para empezar y por ponernos en contexto, todas las peticiones que realiza la aplicación van a parar al servidor al que apunta la ruta: https://sslmovil.aguasdevalencia.es/WS/WS2015.svc
Como muchos ya os habréis percatado, se trata de un radiante servicio SOAP (en pleno 2020) funcionando sobre un magnífico Microsoft-IIS/7.5 con la versión 4.0.30319 de ASP.NET. No contentos con usar tecnología obsoleta, tiene todo el servicio en modo debug o desarrollador, junto a ejemplitos prácticos de implementación. Comodísimo para cualquier persona que quiera explotar vulnerabilidades del sistema.
Al tener el modo debug activado, el servidor nos responde con una tremenda precisión acerca de los fallos internos, dándonos rutas e idea de cómo está construído por dentro. Además, cuando en las peticiones se adjuntan parámetros incorrectos o inesperados, el servidor no las filtra e intenta ejecutarlas, junto con la respuesta de salida. Esto nos lleva a infinidad de posibilidades en ataques de inyección XSS en las consultas a la base de datos, entre otras.
Tragedia 2: el inexistente protocolo de autenticación
Cuando una aplicación interactúa con un servidor y quiere autenticarse para acceder a recursos limitados, existen toda una serie de tecnologías y protocolos disponibles para garantizar la seguridad, tales como OAuth. La idea general consiste en obtener claves únicas que relacionan al usuario que está haciendo la petición.
Pero Global Omnium pensó que implementar un protocolo de autenticación era arduo y costoso, por lo que se les ocurrió una idea mucho mejor: enviar el usuario y la contraseña en plano en cada petición. ¿Pero eso significa que la aplicación de mi móvil se guarda mi contraseña en texto plano para poder adjuntarla en cada petición al servidor? Sí, señor. ¿Y a esto se le suma el hecho de que la aplicación se salta el protocolo TLS y al interceptar el paquete podría leerla siempre que quiera? Sí, señor.
Como veis en este ejemplo del cuerpo de una petición, la aplicación adjunta mis credenciales en texto plano para identificarme y hacer operaciones en mi nombre. Esta operativa es constante en todos los servicios que se exponen, junto a otros elementos de los que hablaremos más adelante como el llamado NIA y SUBNIA, que no es más que el número de mi contador.
Tragedia 3: el inexistente mecanismo de autorización
El concepto de autorización hace referencia a los recursos que podemos leer y/o escribir dependiendo del usuario que seamos. No es lo mismo ser un administrador, que podrá ver y modificar todos los recursos, o un cliente de Aguas de València, que podrá ver solo sus propios consumos y facturas.
Parece que esta premisa que parece obvia y sencilla, para Global Omnium no lo es tanto. Vamos a ver este interesante servicio para obtener los consumos de agua diarios en mi casa:
Tal y como se ve en la imagen, la petición vuelve a adjuntar mi usuario y contraseña (cómo no), junto a otra serie de datos que vale la pena explicar:
NIA: el número de contador asignado. Es un número incremental.
SUBNIA: en caso de que el usuario tenga varios suministros, se identifican por este número incremental.
EMPRESA: dado que Global Omnium contiene da soporte a distintas empresas municipales de agua, se identifican por este número a la que pertenece. En este caso, EMIVASA.
Llegados a este punto, me pregunto: ¿y si replico exactamente la misma petición pero dejando en blanco los parámetros de usuario y contraseña?Para ello solo nos hace falta cualquier aplicación que permita construir peticiones HTTP (cURL, Postman) y ver qué ocurre. Veamos su respuesta:
Llegados a este punto ya me lo creo todo. Resulta que teniendo un número de contador podemos acceder a todos sus consumos, día a día. Sin necesidad de usuario ni contraseña. Además, recordemos que NIA y SUBNIA no son más que número incrementales por lo que, simplemente haciéndole peticiones al servidor para todos los números, podríamos obtener los consumos enteros de la ciudad de València. Muy bien.
Tragedia 4: esto ya es el colmo
Pero aún faltaba ver cómo funcionaba el acceso a las facturas. Los clientes de Global Omnium pueden ver los cobros efectuados y bajarse una factura PDF con todos los detalles. ¿Cómo funciona esta petición?
En el ejemplo que os muestro, ya he quitado de la petición mi usuario y mi contraseña, puesto que, como hemos visto en el apartado anterior, no sirven para absolutamente nada. En esta petición aparece un parámetro nuevo llamado IdUsuario, que no es más que otro número incremental que hace relación al usuario que consulta la información. El servidor responde con las facturas disponibles aunque no incluyamos este dato, pero ahora explicaré un poco más para qué sirve este parámetro. Vamos a ver la respuesta:
Una vez más, simplemente incluyendo el número de contador obtenemos a la información sobre las facturas emitidas. Además, se incluye un enlace a una factura PDF. Y aquí está lo interesante:
https://sslmovil.aguasdevalencia.es/WS/descarga2.aspx?ref=JyA5IfWLOJikURvm05O+wAA9CdooNEp+4osekVEONgukxQtPXju/JxMj7TaopjXcJ2euV9DSBCgF1/fJe56LeMvc+Qjya+s3GPRfpmwpJzV9dh08hDxUP46DQaRYEY2112hmYI3No6iG7BE0tW+m6w==
Como podréis ver, se trata de un enlace que incluye un parámetro GET llamado ref, que según mis investigaciones se trata de una cadena en Base64 con contenido cifrado. Esta cadena contiene, entre otras cosas, el número de factura que queremos consultar y el famoso idUsuario. Les damos un aplauso a Global Omnium por haber implementado seguridad de algún tipo a la hora de acceder a este fichero y cifrar el parámetro.
¡¿PERO A QUIÉN SE LE OCURRE QUE EL PARÁMETRO QUE PERMITE ACCEDER A ESTA INFORMACIÓN SEA UN SIMPLE NÚMERO ENTERO INCREMENTAL?!
Comos os podéis imaginar, el proceso para acceder al fichero PDF es tan sencillo como hacer peticiones al servidor probando número en un rango limitado hasta dar con el enlace correcto. Para que os hagáis una idea: fijando mi número de contador y haciendo un script automático para probar idUsuario, tardé 10 minutos en poder acceder a mi PDF:
Tragedia 5: vulnerabilidades con mucho potencial en un servidor sin límites
Las distintas vulnerabilidades y fallos en la arquitectura de Global Omnium están vinculadas a la falta de mecanismos de autorización y el uso de identificadores basados en números. Por lo que, si automatizamos las consultas masivas podríamos obtener todos los contadores en el sistema, sus consumos y sus ficheros PDF con datos personales.
De normal, los servidores cuentan con mecanismos que bloquean las peticiones masivas, de cara a mitigar ataques de denegación de servicio (DDoS) o intentos de acceso por fuerza bruta. Sin embargo, en las pruebas de carga efectuadas al servidor, no se ha visto una respuesta de este tipo, lo que deja abierto un enorme agujero que afecta a los ciudadanos de muchos municipios. Global Omnium no implementa ningún tipo de límite en las consultas, pudiendo recorrer la base de datos entera en base a los identificadores incrementales sin restricciones.
Conclusiones y propuestas
Todo mal. ¿Para qué nos vamos a engañar? Me apena profundamente que empresas tan grandes, con recursos y en las que miles de ciudadanos e instituciones públicas depositan su confianza puedan hacer semejantes barbaridades desde el punto de vista de la construcción de software.
No sé si es falta de interés, desconocimiento o simplemente desidia. Y, sinceramente, lo único que espero con todo esto es que se pongan en marcha a solucionar estos problemas y los clientes podamos sentirnos seguros de la custodia de nuestros datos. Así que aquí van unas propuestas sencillas:
- Impedir conexiones TLS cuyo origen y destino no sea legítimo.
- Desactivar el modo debug en producción.
- Implementar un sistema de autenticación con OAuth 2.0.
- Requerir autenticación en todos los servicios web.
- Implementar un sistema de autorización a los datos de los servicios.
- Implementar limitaciones de peticiones al servidor.
Por último, incidir en que la metodología utilizada en esta auditoría no ha perjudicado a ningún cliente ni se han usado técnicas que pudiesen comprometer información ajena. Me encantaría que dejaseis vuestros comentarios en este artículo o contactándome en @pabgn.
También puedes seguir leyendo otras cosas mías en: https://medium.com/pm-reflections
¡Nos leemos!
