Hay veces que pienso que soy monotemático.
Que transmito una cizaña contra el STM.
Parece que mi legado va a ser asociar mi nombre con un sistema de transporte que quería que todos viajaran.
Esta vez las fallas son tan profundas que rozan faltas explícitas en las leyes de protección de datos personales.
Esta historia, como tantas otras antes que ella, empieza en una noche que pensé sería diferente, que iba a demostrar que se puede aprender de los errores del pasado.
Sinceramente esperé un contralor interno masivo luego de los diferentes reportes a las fallas del sistema pero no podría haber estado más equivocado.
Esa noche el sistema fue Movete. Es una excelente idea tomada prestada de las grandes metrópolis del mundo que ofrecen bicicletas a los usuarios de su sistema de transporte.
En un Montevideo que cada día ofrece mas ciclovías y espacios para que los ciclistas puedan desplazarse es casi obvio que dicho sistema exista.
Son necesarios varios pasos antes de poder usar una bicicleta que incluyen ir a la única oficina de Movete y pagar $140 pesos por año por adelantado.
Mas allá de este trámite existe una aplicación móvil que permite luego de saciados los pasos anteriores hacer uso del servicio de manera mas cómoda.
Santa Cláusula
Así empieza un poco la disección.
Una aplicación móvil que permitía acceder a las bicicletas de manera más fácil.
El infierno está empedrado de buenas intenciones, dicen.
Luego de tener la aplicación y la tarjeta STM habilitada hay algunos lugares de donde se pueden retirar bicicletas.
Actualmente los parkings son:
- Teatro Solís - Liniers y Reconquista
- Intendencia de Montevideo - 18 de Julio y Ejido
- Reconquista y Pérez Castellanos
- Plaza Fabini - 18 de Julio y Rio Negro
- Mercado del Puerto - Piedras y Pérez Castellanos
- Terminal Baltasar Brum - Río Branco y Galicia
- Terminal Ciudadela Norte - Piedras y Juncal
Plaza Matriz - Juan Carlos Gómez y Rincón
Y cómo estoy tan seguro se preguntarán?… porque asi empieza el problema:
/getParkingData.php es un archivo dentro del sistema de Movete que tiene como única resposabilidad listar todos los parkings disponibles. Como uno lo esperaría no hay nada extraño, es un comportamiento esperable en cualquier aplicación.
Pero que más podemos encontrar?
Enterrado en la aplicacion hay miles de secretos esperando para ser descubiertos y empezaremos por uno que es estremecedor:
Entre piedras y alimañas de codigo encontré esto:
Que interesante la elección de MD5. Una tecnología completamente inútil en la protección de contraseñas estaba siendo usada… pero con qué propósito?
Esta siendo usada con el peor propósito posible:
/mobile_change_pass.php
[email protected]
&pass=ohdiosmio
No es necesario ser un erudito para entender que es lo que está pasando.
Se trata de un archivo que toma como parámetro el email de un usuario y el nuevo password para dicha cuenta.
Que conste que el password es pasado en la forma deMD5(password) pero dado que controlamos ambos parámetros podemos cambiar el password a cualquier usuario del sistema.
Solamente sabiendo el email de un usuario del sistema podemos apropiarnos de su cuenta.
Y dónde esta el piloto?
Una peculiaridad que podemos saber de la aplicación es que su origen no es nacional. Todo lo contrario, fue producida en las tierras de Almodóvar por una empresa que se llama UsualBike que ha implementado la misma solución en Valladolid y Albacete.
Obviamente esto me da la oportunidad de analizar otra aplicación de la misma empresa que hasta donde puedo saber usa la misma tecnología en sus parkings.
Pero ver que es literalmente el mismo código fue otra revelación importante:
Lo que podemos saber es que Albabici y Movete son (hasta lo que estoy dispuesto a investigar) la misma aplicación pero con diferente interfaz y apuntando a servidores diferentes.
Pero por lo demás son lo mismo.
Una nota a pie de página importante es que Albabici no está funcionando actualmente. Parece que está relacionado con el final del contrato entre ellos y la empresa.
Pero Vallabici sí funciona.
Aunque está construida de una manera completamente diferente. Supongo que es la nueva versión que planean para todas sus instalaciones.
Dado que está desarrollada de manera diferente lo que encontré en las anteriores no funcionan las misma vulnerabilidades pero siempre se pueden encontrar nuevas.
Despedazando ésta aplicación tenemos información sobre los parkings. Sobre las estaciones en las cuales se habilitan las bicicletas para su uso.
Sumando todas las vulnerabilidades es posible armar un mapa de su posible funcionamiento.
De las anteriores sabemos que para desbloquear una bicicleta necesitamos: un identificador de usuario, un identificador de parking y una dirección de candado:
👤 + 🅿️ + 🔒 = 🚲💨
Los parking son nuestra incógnita mas grande pero gracias a la aplicación de Vallabici podemos saber mucho:
"station": {
"code": "B827EBBC591E",
"mac": "B8:27:EB:BC:59:1E",
"location": [ 41.653454, -4.730913 ],
"locks": [ ... ],
"ipAddr": "47.60.xxx.xx"
"online": true,
"idle": false
}
Ahora sabemos que cada estación de parking tiene un código que casualmente coincide con la MAC address de la misma.
También tenemos una dirección IP a la cual se conecta y habiendo visto fisicamente los parkings también podemos ver que no son grandes instalaciones.
Si tuviera que intentar descifrar como funciona diría que todos los parkings están interconectados a través de una VPNy reciben algún tipo de paquete en un puerto.
Este tipo de servidores, que toman una cadena de caracteres como entrada de datos para ejecutar una acción tienden a ser mayoritariamente usados en dos escenarios:
- Ejercicios de Facultad
- Productos chinos
Dejo al lector el voto sobre cual es el caso en esta situación.
Con toda esta información a mano lo correcto es reportar las vulnerabilidad así que lo que intenté fue usar el formulario de contacto:
Que claramente tampoco funcionaba…
La única herramienta de contacto desde el exterior y era otra pieza móvil que estaba cumpliendo su función.
El día de la bestia
Ya que esta es tierra de nadie es momento de saber hasta donde nos lleva ese agujero de conejo.
El impacto se extiende a lugares insospechados ya que el desinterés en prácticas básicas de seguridad es eterno.
Algo tan inocente como esto: /getLocksData.php?parkingID=2 cuya unica razón de existir es saber el estado de cada una de las bicicletas en un parking dado se vuelve tóxico.
Una injección SQL. Uno de los más peligrosos bugs que uno pueda encontrar en un sistema. Permite la lectura (y a veces la escritura) de la base de datos a la que tenga acceso la aplicación.
Todos y cada uno de los registros de la aplicación se vuelven vulnerables y tal vez no parezca mucho pero gracias al descubrimiento de que los passwords están guardados en MD5tenemos la certeza que no son seguros y así exponer el password de todos los usuarios de Movete.
Dado que no tenemos políticas sobre como escribir passwords es probable que se mantengan fieles a la idea de reusar sus contraseñas en varias aplicaciones.
Esta falla en particular me preocupaba dado que había riesgo real de perder control del servidor habilitando a un atacante a tener bajo su yugo un servidor de la Intendencia de Montevideo.
Ya que no tenía posibilidades de contactarme con los encargados de la aplicación decidí recurrir a CERTuy.
El día de la marmota
Como toda historia no sería digna de contarse si no hubiera una vuelta de tuerca al final.
Recurrir al CERTuy fue el camino más eficiente para poder lograr resultados.
La decisión mas acertada fue la que tomaron pero tambien la mas difícil también porque involuca dar de baja una porción importante del servicio.
Soy crítico con el STM. Bueno, más que crítico con el sistema lo he sido con cada una de las decisiones técnicas, pero siempre con un espíritu de contralor. El mismo espíritu que creo que cualquier ciudadano debe tener sobre sistemas, instutuciones e individuos que deben proteger información personal no por una brújula moral superior sino por ley.
La respuesta desde el CERTuy fue inmediata, las acciones desde la Intendencia de Montevideo fueron extremadamente rápidas y la decisión fue la apropiada dado el nivel de corrupción que existía en el servidor.
El antecedente frente a una vulnerabilidad de ésta índole hace que recupere la esperanza de que el contralor es posible, ejercible y beneficioso no al individuo o empresa sino al bien colectivo.
La extensión del STM va desde los ómnibus, los taxis y las bicicletas. Una herramienta tan transparente necesita ser observada con detenimiento, atención y de la manera mas crítica posible.
Y yo siempre voy a estar mirando.
Apocalipsis, del latín: Revelación
Tregua
Mi intención con la publicación original Hackeando el Sistema de Transporte Metropolitano siempre fue puramente técnica. Fue generar un impacto volcando luz sobre un tema que premeditadamete estaba en las sombras.
Pero como todo en el universo para cada acción hay una reacción, igual y opuesta.
Calma, solamente calma fue lo que encontré después de publicarlo, tanta calma que me asustó. Había logrado lo que me había propuesto, había seguido el proceso que creía apropiado, todo estaba bien, todo estaba en calma.
Pero no soy un hombre que sepa vivir en calma.
Hambre
Durante semanas mi cabeza solo podía estar en ese comentario…
Ya conozco esa hambre, ese apetito interminable. No importa cuanto intente luchar la curiosidad siempre va a ser más que yo.
Quise ser algo que no era, quedarme quieto pero la picazón siempre va a terminar ganando.
Incógnita
No sabía nada mas que ese comentario (y aunque no era la primera vez que lo escuchaba) no tenía manera de comprobarlo. Especialmente porque no uso tarjeta STM.
Evalué todas las opciones tecnicas que me pude imaginar pero partí de dos premisas básicas:
- Necesariamente es una aplicación Android dado que es el unico sistema que permitiria lo que la evidencia me mostraba.
- Necesita ser distribuida “facilmente” dado que no es un hardware especializado que compran en cantidad a una empresa china.
Y así surgió mi primer error: presuponer. Técnicamente en mi cabeza solo podía haber una opción:
- Una aplicación desarrollada internamente.
- Distribuida independiente a cada dispositivo.
- Resguardada en el bunker mas profundo.
Pero los prejuicios en todas sus formas son contraproducentes, es la experiencia lo valioso.
Tomé mucho tiempo pensando en que haría yo en lugar de pensar cual es el camino de menor resistencia…
Y el camino de menor resistencia era publicar la aplicación de control a todo el mundo en el Google Play Store.
Los caminos cortos obviamente tienen sus beneficios ya que es fundamental para avanzar rápido pero este particularmente me parece muy gracioso.
No porque se tomaron el tiempo de liberarla públicamente, ni siquiera por agregar fotos de la aplicación cual Candy Crush criollo.
Sino por la descripción:
Ese pedido de no descargar, esa invitación a curiosear, a saber mas. No había manera de parar ahora.
Adaptarse
Habiendo aprendido de mis errores del pasado no iba a dar nada por sentado así que recurrí al siempre observante ojo de Google por más información.
Un dejá vú fue lo que sentí al ver que como la vez anterior googlear me dió mucha mas información de la que hubiera esperado.
Y ahí radican las filtraciones. Dejar expuesta mas información de la que uno esperaría.
Todo con la idea de perpetuar una tarea no necesaria de controlar los pasajes que ya sucede en la propia expendedora de boletos.
Estas reglas de juego son diferentes, no es una tarjeta lo que necesitaba ser hackeado sino una aplicación.
Hay varios enfoques para obtener respuestas siendo los mas populares la intercepción de interacciones con la web (MITM) o la decompilación de código.
La primera supone medir una interacción entre una aplicación y una web pero esta vez me daba mas curiosidad que guardaba adentro ya que si encontré un diagrama interno de la STM en un pdf quién sabe que mas voy a poder encontrar.
Las herramientas de decompilación de una aplicación son bastante populares, en este caso particular me tomó 3 herramientas para poder tener una visión de pájaro de todas las piezas móviles.
Tuve que adaptarme o morir.
Santo Grial
Y ahí estaba, esperándome, todo el código de la aplicación, todos sus miedos y secretos prontos para ser diseccionados.
Obviamente con todo lo aprendido de la STM la primera pregunta que quise responder es sobre la interacción NFC de la aplicación. Más allá del control, que se supone que hacía.
Empecemos por partes dijo Jack… Lo interesante de esta línea es que usa ese identificador para corroborar la validez de una tarjeta. Si el UID (identificador único) de la tarjeta equivale a ese valor el programa sigue ejecutandose…
Eso significa que existe una Tarjeta Inspectora con caracteristicas únicas pero compartidas con la STM populares
Eso! más allá de verificar que el identificador sea el dado se checkea un bloque de la tarjeta en busca de un valor particular para marcar a ciencia cierta esta tarjeta como de inspección.
Entonces podemos concluir que la maquina expendedora interactua con la Tarjeta Inspectora y luego la aplicación móvil interactua con dicha tarjeta.
No sólo sabemos que existe una tarjeta inspectora, también sabemos que controla un viaje dado… y donde guarda esa información.
Pero no solamente eso, también podemos saber aprender más aún de la STM como que formato se usa (y en que bloques se guarda) la información de tiempo en la tarjeta.
Seamos inspectores por un día, repitamos la jornada de trabajo:
Entonces, la conclusión sería la siguiente:
- Inspector pone su tarjeta especial en la expendedora
- La expendedora carga información del viaje y sus ocupantes en la tarjeta. En este caso lo que queda guardado en el móvil es el UID (identificador único) de la tarjeta STM de los pasajeros.
- La aplicación lee la información de la tarjeta para y carga los datos en el móvil.
- El inspector usa la aplicación para leer las tarjetas de los pasajeros.
- Se envía dicha información a un servidor externo.
Hay varios problemas con este circuito siendo el primero que sabemos que los UID pueden ser trackeados hasta un individuo en particular ya que cada identificador tiene una CI relacionada.
Pero aún hay más!
Dentro de la aplicación hay código de respuesta de ejemplo así que podemos saber que información hay en el servidor sin tener que interactuar con él.
Todos los datos son enviados a un servidor externo luego de cada checkeo de viaje. No sólo eso sino que también nos permite aprender mucho sobre los diferentes tipos de STM que hay ahí afuera.
"Corriente"
"Estudiante A"
"Estudiante B"
"Estudiante Gratuito"
"Jubilado A"
"Jubilado B"
"Escuelas Especiales ANEP"
"Discapacidad I.M"
"nominado al Organismo con cupo"
"nominado al Funcionario con cupo"
"nominado al Organismo sin cupo"
"nominado al Funcionario sin cupo"
"Prepago nominado"
"Trabajador Transporte"
"Jubilado Transporte"
"Accionista Transporte"
"Familiar Transporte"
"Turistico"
Cada una tiene un identificador particular con el que es diferenciado, pero no solamente de tarjetas STM vive el hombre. También tenemos información sobre todos los posibles tipos de viaje que se pueden hacer:
"Sin viaje"
"Comun"
"1 hora"
"Zonal"
"Diferencial"
"2 horas"
"Met. entrante"
"Met. saliente"
"Gratuito"
"Testigo"
"Dif. metro 1"
"Local Metro 1"
"Centrico"
"Donacion A"
"Donacion B"
"Donacion C"
"Turistico 24 horas"
"Turistico 48 horas"
"1 tramo dep."
Me pregunto realmente la necesidad de una identificación tan profunda por parte de esta aplicación enviando donde y cuando se encuentra un pasajero.
Ya que tanto nos mirá la STM ya era hora de que devolvieramos el favor.
Terror
Se completó el circulo y la STM me sigue mostrando más información de la que podía imaginarme.
Hay mucha mas información en la aplicación y se podría armar una especificación del protocolo de la STM dedicandole el tiempo suficiente.
Todo este tipo de cosas me recuerdan a una anecdota de una caja fuerte “segura” que con la idea de ser millenial agregó un puerto USB tirando por borda toda la seguridad mecánica que ya tenía.
Aumentar la superficie de una aplicación aumenta necesariamente los vectores de ataque.
La STM permite una identificación bastante preocupante desde su principio y con esta aplicación se agrega mucha granularidad a la ya amplia información que queda registrada.
Horror
Lo he dicho mil y una veces, hay procesos para seguir y creo fervientemente que el contralor es necesario para evitar catastrofes.
Me decido a reportar lo que encontré directamente al mail responsable de la aplicación en Google Store porque más allá de todo es lo correcto.
Mail 1
De: "elcuervo" <[email protected]>
Para: xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Enviado: 30/7/2018 04:32:20 p.m.
Asunto: Reporte de vulnerabilidad
Buenas,
Quisiera reportar un vulnerabilidad en la aplicacion.
Podrian facilitarme clave gpg para enviar el reporte?
Gracias.
Respuesta 1
De: xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Para: "elcuervo"
Enviado: 30/7/2018 05:36:20 p.m.
Asunto: Reporte de vulnerabilidad
Mail 2
De: "elcuervo" <[email protected]>
Para: xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Enviado: 30/7/2018 05:38:12 p.m.
Asunto: Reporte de vulnerabilidad
Si este no es el mail adecuado te puedo pedir a donde enviarlo?
Muchas gracias
No es una exageración, esa fue la respuesta, sin texto, sin explicaciones, solo un meme. Y frente a la ultima pregunta aún estoy esperando respuesta.
No voy a mentir, me decepcioné, mucho. Esperaba un mínimo de interés.
Si bien no hubo una filtración de datos de usuario sí una exposición innecesaria de una arquitectura ya de por sí frágil.
Ofrecer medios de comunicación para el reporte de vulerabilidades y/o fallas es fundamental para sacarle trascendencia a dichas fallas.
Nunca más
Acción y reacción, la regla fundamental del universo. Una regla de la cual no estoy exento. No soy la misma persona que escribió la primera parte de la STM así como ahora no soy la misma persona que terminó la segunda.
Mucha gente me ha contactado con curiosidad sobre como funciona un sistema que muchos de nosotros usamos todo el tiempo. No es un sistema infalible aunque siendo honesto ninguno lo es.
Esta publicación como tantas otras antes y tantas otras que vendrán cumplen simplemente un propósito técnico e informativo. Como con cualquier herramienta lo importante es el uso que se le dé.
Lo dije antes y lo digo ahora, lo vulnerable de la STM es el sistema que lo rodea y siendo consientes y responsables podemos tomar decisiones informadas.
Quiero poder investigar mas abiertamente y que tal vez un día lo que comunique a afectados pueda ser tomado en serio. Ya que al final del día sólo colectivamente podemos hacer que las cosas estén mejor.
En el mientras tanto puede que este sea la última vez que escribo sobre la STM. Pero ya saben lo que dicen… nunca digas nunca:
]]>Ómnibus, del latín: Para todos
Érase una vez…
STM nace con el ideal de llevar a Montevideo al siglo 21 ofreciendo una tarjeta de transporte como las que hay en muchos otros lugares del mundo.
Más allá de la diversión técnica que trae crackear este tipo de tarjetas, la motivación principal es el aparente conocimiento por parte del estado de las carencias de seguridad de la misma. Véase la presentación más abajo.
Desde la invención de NFC, la batalla por qué tipo de tarjeta es mejor ha sido fiera. Pero hubo una que se hizo extremadamente famosa luego de ser adoptada en varios lugares del mundo para sistemas de transporte: la Mifare Classic de la empresa NXP.
Todo este blogpost trata sobre un problema que han tenido las tarjetas Mifare desde el principio. Siendo totalmente público desde el 2008, el mismo llevó a que la propia Mifare no recomiende el uso de sus tarjetas Classic cuando la seguridad es algo importante: Seguridad Mifare Classic
Following the broad acceptance of contactless ticketing technology and extraordinary success of the MIFARE Classic® product family, application requirements and security needs constantly increased. Therefore we do not recommend to use MIFARE Classic in security relevant applications anymore.
Bueno, empecemos con lo que nos atañe. Esta es una explicación de una vulnerabilidad que tiene tantos años como el producto en sí.
La vulnerabilidad afecta a todas y cada una de las tarjetas STM.
Para dar un poco de contexto, la siguiente es una presentación “interna” (gracias Google) que explica todo el sistema de transporte. Antes de que me digan nada, es del 2008.
Más allá de la antigüedad de la presentación, lo que más me llama la atención es la cantidad de información interna que hay.
… una tarjeta de transporte
Montevideo optó por un modelo de tarjeta NFC de la empresa NXP. NFC es una tecnología que tiene muchos años en el mercado, es ese tipo de magia negra que nos llena con la ilusión de estar viviendo en el futuro: transmisión de datos sin contacto. La elección del modelo de NXP sucedió hace ya mucho tiempo seguramente atado a un bajo precio o quién sabe qué.
… qué no era como las demás
Sabemos varias cosas: es una tecnología que lleva tiempo ahí afuera y que no es particularmente cara.
En cualquier otro escenario esto no sería ningún problema, el problema es (como con todas las ideas en general) la implementación, una idea no vale nada.
Dentro de la tecnología de la información hay dos escuelas: la cerrada, que pregona que toda tecnología privada y sellada es más valiosa; y la otra, donde optamos por compartir lo que sabemos (y se nos tilda de hippies que no entendemos nada en el proceso).
Mi mentor una vez me dijo: “nunca uses un algoritmo que no haya sido evaluado por pares; cuantos más ojos miren, más van a poder encontrar los errores”. Me tomó 15 años encontrar un caso tan evidente como este.
NXP, la empresa detrás del desarrollo de la tarjeta STM decidió usar su propio sistema criptográfico conocido como CRYPTO1.
Como se imaginarán, esa no fue una idea demasiado brillante.
La seguridad por oscuridad tiende a colapsar ante el primer vestigio de luz.
Unos meses después del lanzamiento de la tarjeta ya exisitía un exploit. El problema radica en la generación de números al azar (RNG) de la tarjeta donde por una mala implementación el azar es predecible. Así nació CRAPTO1.
… y quería que todos viajaran.
Esta es la parte jugosa.
Sabemos cómo funciona y sabemos cómo puede llegar a fallar. Ahora, ¿qué tan fácil es viajar gratis en el sistema de transporte metropolitano?
¿Qué información habrá en su interior? ¿Podrá ser víctima de un Replay Attack? Es decir, ¿se podrá clonar la tarjeta y/o restaurarla a un estado anterior terminando así con (a efectos prácticos) saldo ilimitado?
Mi investigación llevó un tiempo, desde la comprensión del problema hasta el acceso al hardware necesario.
Al día de hoy el costo de toda la investigación fue de $40 dólares de Trump ^_^.
Pero no siempre fue así.
La historia comienza cuando pude tener acceso a un lector NFC de bajo costo. El modelo que elegí fue el PN532 que sabía tenía buena compatibildad con Raspberry Pi. Esta elección se daba por lo siguiente:
El modelo de tarjeta NFC de la STM está dividida en sectores, y para tener acceso a cada sector se necesita una clave de lectura y otra de escritura.
Dado el problema en la generación de números aleatorios de la tarjeta, teniendo una clave cualquiera de las 32 posibles de una tarjeta se puede inferir el valor de todas las restantes. Esto puede ser un proceso tedioso de entre 5 minutos a algunas horas, pero garantiza una copia completa de la tarjeta siempre… siempre y cuando se tenga paciencia.
Mi enfoque original era bastante optimista, asumí que durante la implementación no habrían cambiado alguna de las claves que vienen en la tarjeta por defecto. Pero en defensa de quien sea que lo haya implementado, efectivamente cambiaron las claves por defecto de la tarjeta.
Pero aún no termina la historia, si bien es más fácil acceder a una tarjeta teniendo una de las claves, también existe otra manera: fuerza bruta.
Es por ese motivo que queria una Raspberry Pi: armé un setup con una Pi y el lector, redundancia electrica, una alerta para cuando encontrara algo, y tiré una moneda al aire.
4 días después me llené de euforia al ver esa clave hexadecimal: 0xd14400000000
Bueno, no esa… puse en cero algunos valores para hacerlo más interesante :P.
Habiendo conseguido esa clave pude inferir el resto de las claves de la tarjeta.
Pero, ¿cuál es la gracia si sólo se puede hacer en una tarjeta? Hay una cantidad gigante de claves ahí afuera, todos sabemos que repetir este proceso por cada una de ellas es ridículamente trabajoso… a menos que…
Intetando reproducir el experimento en otra tarjeta me cansé de esperar el ataque de fuerza bruta y probé las 32 claves que ya tenía de la tarjeta original.
31 claves denegadas después noté algo interesante… la primer clave de lectura del primer sector de todas las tarjetas es la misma. Usando esta clave “maestra” todo el resto de claves pueden ser inferidas.
Con mejor hardware, como un lector Proxmark3 el tiempo de crackeo de la clave es de menos de 10 segundos.
Un vestigio de luz.
Ahora ilumenemos todo el cuarto y veamos cómo funciona la STM.
En el momento que un usuario compra su tarjeta de transporte se asocia el UID de la tarjeta NFC a la cédula, sin puntos ni guiones:
UID: 123123123123 -> CI: 12346789
En caso de perder la tarjeta y solicitar una nueva se repite el proceso, pero la cédula (o usuario en este caso) cambia a 12346789_2, o sea, un guión bajo más el n siguiente.
Esto trae muchos problemeas, empezando por el anonimato: cada ruta de un portador de tarjeta STM puede ser inferida con bastante facilidad, pero no sólo eso. Los UID de las tarjetas NFC pueden ser leídos sin necesidad de una clave de lectura, por lo tanto un agente externo puede “identificar” a un usuario desde una distancia prudencial.
Luego, al subir a un ómnibus y acercar la tarjeta al lector sucede lo siguiente: se lee el primer sector con la clave maestra que irónicamente guarda el UID de la tarjeta, seguramente como validación. Con ese UID se calculan los valores de las claves de los siguientes sectores.
Se siguen varias de las recomendaciones de seguridad que les pide Mifare a los que usen este modelo viejo que son: contadores (que aumentan y decrecen) y que los datos como las fechas y el crédito no estén en texto plano (por suerte). Están guardados usando XOR.
Ese registro de crédito pasa a la computadora de abordo, ubicada arriba a la derecha entrando al ómnibus. Que tiene un pendrive que guarda los datos de las tarjetas y sus rutas y es entregado con la recaudación al final de cada jornada.
Es decir, el registro de boletos y su crédito es guardado de forma offline, y luego (¿diariamente?) es actualizado en una base central.
Lo que nos da como única fuente de la verdad a la tarjeta STM. Una tarjeta hackeable.
La tarjeta (en su implementación) es vulnerable a lo que se conoce como Replay Attack ya que si guardamos una imagen de la tarjeta con $2000 podemos restaurarla a su estado anterior.
Incluso el uso de emuladores NFC como el Proxmark3 hacen posible tener un dispositivo con saldo perpetuo.
Destino.
Uno de los conflictos mas grandes que encontré en esta investigación es la necesidad de atar la cédula de identidad de una persona a una tarjeta, esto no sólo evitando que un turista pueda tener su tarjeta para viajar sino que atentando a la identificación de las personas. La responsabilidad de los datos no se reduce a ofrecer garantías en donde se guardan sino que también es necesario entender cuando esta información es necesaria. Una excelente fuente para saber mas es este handbook
El problema no radica exclusivamente en la ejecución de la solución, sino en la falta de control que los sistemas estatales (y no estatales) tienen. El objetivo de esta investigación es entender un sistema y sus piezas móviles, no el abuso del mismo.
Cabe aclarar que no somos la excepción en la región, tanto la SUBE de Argentina, como la BIP! de Chile son vulnerables al mismo ataque. La única curiosidad que tengo es que nuestro sistema fue implementado luego de que este modelo de tarjeta se haya mostrado como vulnerable.
En un mundo ideal hay contralor, hay apertura, hay transparencia y la posibilidad de auditar el mundo que nos rodea cuando el propósito es mejorarlo.
En un mundo ideal hay libertades individuales y el uso de tecnología no nos ata a una base de datos.
Pero en el mundo real no siempre pasa y espero que esta publicación sea una pequeña luz al final del túnel sobre como un individuo puede contribuir hacia lo que puede ser posible.
]]>Bueno, ese fue terrible clickbaith no?. Este blogpost no es acerca de ninguna postura política sobre como destruir el capitalismo ni nada por el estilo. No es sobre como “teóricamente” se puede destruir el sistema bancario… es sobre como pude haber desbarrancado el sistema economico de Uruguay por un pequeño bug en una aplicación de ebanking.
Esta historia empieza hace mucho tiempo, no hace mucho tiempo en los tiempos que maneja la internet pero bastante. Uno de los bancos de mi país sacó una campaña diciendole a todos sus usuarios que tenían una aplicación móvil nueva. Fantástico.
Lo bueno es que está bastante bien diseñada y funciona en iOS y Android. Lo malo es que era la mitad de la noche y yo estaba suficientemente borracho como para tratar de destrozarla sin pensar demasiado.
Disclaimer
Después de intentar varias veces de comunicarme en una manera segura con el propio banco termine consiguiendo el email de un directivo y el bug fue reportado con detalle el 7 de Julio.
Se siguió el thread sobre el bug con varias notas que “Sería arreglado la próxima semana”
Expectativas
Tengo unas expectativas de lo que una aplicación de ebanking debería hacer:
- SSL en todo. TODO.
- SSL pinning del lado de la aplicación.
- Manejo adecuado de las claves.
Esta es una pequeña lista sobre las cosas que una aplicación debería considerar y cosas que los pentesters deberían revisar en sus tests.
Solo quiero recordarles que Pokemon Go tiene SSL pinning…
Realidad
Ninguna de las tres estaba presente, asi que empecé a escarvar… profundo.
Primero lo primero, reconocimiento.
Ya que la aplicacion no configuro SSL pinning correctamente es muy fácil intentar un MITM attack solo agregando un certificado root a mi dispositivo que me permita interceptar todas las llamadas.
Fue una sorpresa encontrar que no TODAS las llamadas tuvieran SSL. Todos los recursos del banco estaban correctamente como HTTPS pero uno de ellos no y casualmente era un Javascript. Un Javascript? Por qué? Solo por curiosidad lo miré:
http://maps.googleapis.com/maps/api/js
Entonces, tenemos un archivo HTTP plano pidiendo el Google Map JS API directamente a la aplicación para poder ver un mapa de todos los bancos. Entonces lo lógico sería una WebView embebida por alguna razón.
Intercepté la llamada solo probando una simple injección XSS. Bingo! Puedo ejecutar cualquier JS internamente a la aplicación, que más?
Teniendo la abilidad de inyectar cualquier JS me dio curiosidad que la aplicación no fuera mas que un sitio web empaquetado en Cordova conviertiendo en solo un programa en JS y con eso dandome la opción de investigar cada rincón de ella.
Como uno esperaría siendo una aplicación que maneja dinero REAL de gente REAL era… solamente un programa JS, un programa usando Ionic empaquetado con Cordova para ser mas específico.
Cómo es que sé esto? Bueno, se acuerdan que es posible ejecutar CUALQUIER JS en la aplicación?. Bueno, como puedo ejecutar lo que sea inicié un servidor de Weinre en mi máquina. Esta herramienta facilita el debug de una aplicación JS dentro del dispositivo. Extremadamente util para saber que esta sucediendo en el dispositivo y en este escenario muy util para ver todo lo que pasa.
Esta herramienta de ejecución de código remoto (y ya que la aplicación era solo un sitio web) me permitió ejecutar y cambiar lo que quisiese. Este camiino demostró solo útil para cambiar el logo del banco por un Dickbutt y publicando todo esto en Twitter… porque bueno… estaba borracho.
Banco. Me voy a dormir. Que descanses: pic.twitter.com/KEmmghnWmW— Cuervo (@cuerbot) January 5, 2016
Di el dia por terminado, ya hice mucho.
El fin esta cerca.
Quería saber mas y tenía todo para aprender de los recursos del banco y del código de la propia aplicación. Como toda la aplicación es JS es posible conseguir esto:
Todo, a la mano.
Entonces, tenemos el código de la aplicación, los recursos, la estructura y una manera de acceder a todo y modificarlo ya que es solo JS.
Teniendo acceso la código que se esta ejecutando me dió curiosidad de que informacion estaba siendo guardada en localStorage… para mi horror encontré la sesión actual en access_token ahí… esperando.
Prueba de Concepto
Pero que tipo de vector de ataque podemos usar? Tenemos muchas opciones
Un ataque posible solo para divertirme fue SSID spoofing con un MITM injection.
Cualquier wifi pública (y muchas privadas) son claramente no seguras y pueden ser facilmente atacables: https://medium.com/matter/heres-why-public-wifi-is-a-public-health-hazard-dd5b8dcb55e6
El concepto es muy simple, tenemos una Raspberry Pi:
Esta pequeña bestia clona un SSID y usa la segunda antena para darle a la victima(s?) acceso a Internet y poder ocultarse a simple vista.
El mundo en llamas.
Todo este suspenso fue por una razón.
Usando este ataque teorico podemos obtener usuario y password de cualquier usuario… y por si fuera poco podemos usar las credenciales que estan guardadas en la aplicación para hacer menos esfuerzo.
El tema es: puede que quieras robarle a personas… está mal y merecés ser procesado pero talvez, y solo talvez, también puede ser un mensaje.
$0.01 es la mínima trasferencia posible entre cuentas entre cuentas y no serias notificados (ya que no hay ningún tipo de notificación).
Teniendo acceso a un manojo de cuentas le puede permitir a un atacante congelar el sistema bancario por un tiempo considerable.
La máxima transferencia entre cuentas sin ningún tipo de token o autenticación a dos pasos son $1000.
Entonces el daño máximo posible es la transferencia minima (0.01) * el límite de transferencias (1000) pero entonces podemos aprovecharnos de que el límite es en dólares americanos pero el mínimo es 0.01 pesos uruguayos.
1000 * 27 / 0.01 = 2.700.000 transactions.
Y eso es solamente para una cuenta.
Siempre se pueden usar cantidades al azar en las transacciones para joder todo aún mas. Todo el sistema económico DDOSeado por un error tonto, en un día. Incontables horas hombre para revertir algo que no debería estar ahí.
Y si expanden el alcance siempre se pueden intentar transacciones a otros países solo para ver que pasa.
Conclusión
Estamos cagados. Fin. La tecnología es parte de nuestras sociedad pero aún así la tratamos como magia, como un callejón oscuro y misterioso.
La confianza es fundamental en nuestro mundo actual. Nuestros bancos, nuestros gobernantes, nosotros confiamos en ellos por ninguna otra razón mas allá de que se supone que confiemos.
Ser evaluado por nuestros pares es una de las mejores maneras de mejorar el código pero ademas un standard en la investigación de seguridad que DEBERÍA ser parte de cualquier ciclo de desarrollo ayer.
Creemos que la seguridad y el hacking es algo que le sucede a otra gente, en otros países. Internet nos enseño que las fronteras son cosas del pasado, algo de un libro de geografía.
Tenemos que pensar en seguridad, necesitamos DEMANDAR seguridad y transparencia a todos nuestros antigüos sistemas como lo son los bancos. Tenemos que adoptar standares de infosec.
Es solo necesario un mal dia para hacer que el castillo de cartas se derrumbe. Claro, hipoteticamente.
]]>