BBVA Wallet es una nueva aplicación que ha llegado a las plataformas de iOS y Android hace pocos días. Es la primera cartera virtual en España que te ofrece realizar pagos desde el móvil utilizando tecnologías como son NFC y Contactless. La aplicación nos permite realizar pagos desde nuestras tarjetas almacenadas en nuestra “cartera virtual” de una forma fácil y “segura”. No estoy de acuerdo con la afirmación de que la aplicación es segura por eso en esta entrada explicaré brevemente porque la aplicación no es segura...
|
etiquetas: bbva , bbva wallet , hacking , ios , seguridad 
El banco para el que hago la app tiene testers externos contratados y además una empresa que se dedica a hacer auditorías de seguridad (en la que entre otras cosas hacen ataques man in the middle con certificados falsos y demás). Incluso miran si pueden "descompilar" el código de la app y sacar información de ahí (las llamadas al servidor, la estructura del JSON que vuelve... cualquier cosa).
Cualquier tipo de fallo mínimo y la app no sale a producción. De hecho las pruebas que hacen nuestros testers mientras vamos desarrollando funcionalidad son como lo que describe el autor del blog. Es más, también usamos Charles
Pero vamos, como siempre en España se habrá hecho un proyecto con personas sub-sub-sub contratadas, en condiciones de mierda, con muchas prisas, etc. En vez de querer hacer las cosas bien, supongo que la cárnica habrá trincado el dinero y aquí paz y después gloria. Y que salga como salga para salir del paso y ale.
En iBanesto (ahora creo que cambian el portal) ocurre algo similar. Para entrar te pide nombre de usuario y un pin de cuatro cifras. Después para la mayoría de operaciones ya sí te piden algunos caracteres de una contraseña de 8 caracteres (creo que deben ser cifras y mayúsculas, las minúsculas no las acepta) y también confirmación por SMS.
Pero vamos, que la sensación general es que han metido la banca online con calzador a un sistema que nunca estuvo pensado para ella.
#0 No daba error de certificado?? No me creo que esté tan mal como para no quejarse de eso. Eso si que sería grave.
El SSL Pinning está bien, pero es difícil de desplegar (tiene que mantenerse un certificado firmado por una Autoridad certificadora concreta en el tiempo en ese servicio.) A la hora de programarlo parece buena idea, pero cuando el servicio lleva ¿años? y el certificado caduca, nadie se acuerda o no queda nadie y se lía petarda.
No creo que la aplicación esté tan mal (todas las apps bancarias son de este estilo), y mas bien creo que es lo que dice #11 seguramente se tengan que integrar con un demonio escrito en COBOL allá por el precámbrico por eso mandan datos esos datos, aunque ya puestos no estaría mal que los cifrasen.
Lo siento pero no estoy de acuerdo. Fiarse de un CA que está en la lista de CAs seguros no es un problema de seguridad, es lo que se supone que tienen que hacer las aplicaciones. Para este ataque se requiere acceso físico al dispositivo antes de poder hacer nada. Y una vez tienes acceso físico ya no hay seguridad posible, solo se puede obstruir más o menos el acceso.
El resto de datos enviados, aunque el artículo diga "en claro" parece que se envían también por https, aunque estoy de acuerdo en que muchas de las cosas enviadas parecen innecesarias (p.ej. numeros de tarjeta con fechas de caducidad y saldos).
#9 El mundo del software para bancos parece estar completamente separado del resto. Allí, pobrecicos, todavía no han acabado de descubrir muy bien como va el tema de las contraseñas, entre otras cosas. Dales 15 o 20 años más y ya verás como se dan cuenta.
se vota mucho con solo leer el nombre y la fuente.
Los trabajadores del sector TIC lo han dicho muchas veces.. si pagas con cacahuetes en condiciones lamentables contratarás monos a los que les importa un pimiento el resultado final, esto es un ejemplo.
#6 Muchas gracias por el curro
#23 No había leído tu comentario, en Everis habrán empezado con iOS hace nada y no habrán fichado a un crack sino a 4 mileuristas y habrán recolocado a alguien de Java.
Lo que también es raro, curioso, como para
En un proyecto un programador hace lo que le manda el analista ni más ni menos. El programador es un albañil del software que hace lo que se le manda (y cobra como tal). No puedes acusar al albañil de poner una puerta de casa que no es suficientemente segura si el que le da las órdenes le dijo que pusiera esa puerta.
La responsabilidad tiene que estar en el diseño, no en el que lo aplica (si lo ha aplicado tal y como se le pidió)
Por favor, trátennos con dignidad, un trabajo debería ser un derecho, no un privilegio o un regalito que nos hacen los dioses para que estemos superfelices con su magnaminidad.
Vamos que te están diciendo que no aceptan contraseñas seguras.
El banco para el que hago la app tiene testers externos contratados y además una empresa que se dedica a hacer auditorías de seguridad (en la que entre otras cosas hacen ataques man in the middle con certificados falsos y demás). Incluso miran si pueden "descompilar" el código de la app y sacar información de ahí (las llamadas al servidor, la estructura del JSON que vuelve... cualquier cosa).
Cualquier tipo de fallo mínimo y la app no sale a producción. De hecho las pruebas que hacen nuestros testers mientras vamos desarrollando funcionalidad son como lo que describe el autor del blog. Es más, también usamos Charles
Pero vamos, como siempre en España se habrá hecho un proyecto con personas sub-sub-sub contratadas, en condiciones de mierda, con muchas prisas, etc. En vez de querer hacer las cosas bien, supongo que la cárnica habrá trincado el dinero y aquí paz y después gloria. Y que salga como salga para salir del paso y ale.
Muy mal Everis y muy mal BBVA.
Y ese.. es el resultado.
#34 Es el banco quien ha cambiado la forma de subcontratación a sabiendas de que esto sucedería y con gran parte de los empleados del propio banco en contra . Se ha cambiado de subcontratar personas , para subcontratar paquetes de personas : te pago X por 15 personas , donde el montante de X es una risa , por lo que las 15 personas contratadas no están por norma general cualificadas para desempeñar el trabajo.
Lo que no tengo claro es que la culpa sea de los programadores, me gustaría ver el diseño y requisitos de la app, para descartar que la culpa no la tenga algún alma cándida que ni ha reparado en estos pequeños detalles de seguridad.
Lo ideal es que se involucre a seguridad en el diseño y se hagan pruebas en diferentes etapas del desarrollo, vamos lo que viene siendo SSDLC. Pero ya que eso no se hace muy a menudo, como mínimo una auditoría de la app debería ser un must!
Yo no he trabajado en Everis, pero en las otras que he estado ha sido así. Supongo que ese ha sido el caso.
Y en serio, no tengo nada en contra de los pobres chavales que les haya tocado el marrón de hacer esto (porque fijo que para ellos ha sido un marrón, que ya nos conocemos cómo funcionan las consultoras en España).
EDIT: Y tienes razón, algo como lo que he dicho de una auditoría de seguridad en una app de un banco es lo mínimo que se puede exigir. Y es cómo se tienen que hacer las cosas.
Por supuesto, no le voy a restar culpa a las cabezas pensantes del banco, que permiten esto, en lugar de exigir calidad. Pero sigo diciendo que el verdadero cancer son las cárnicas, no el cliente al que estafan o se deja estafar.
Los clientes son los que también deberían frenar estar prácticas, pero desgraciadamente no pasa y así tenemos montado lo que hay en España con las consultoras.
No voy a negar que utilizando su propio almacén de CAs de confianza mejoraría bastante la seguridad (el SSL Pinning es una exageración con muy poca visión de futuro), pero confiar en el almacén de CA del teléfono no es una vulnerabilidad en sí ni mala seguridad, como mucho un exceso de confianza.
A ver, no seamos alarmistas. Si en el navegador de tu PC te meten una CA de un "hacker" estás igual de jodido o peor.
Y sobre lo de cifrar con AES los datos... ya van cifrados así! El SSL usa AES desde hace años como principal algoritmo. Cifrar de nuevo los datos sólo traslada el problema a cómo almacenas esa segunda contraseña para el AES adicional y cómo se gestiona en caso de reinstalar la aplicación.
Y en cuanto a meterse con los programadores (#10 : Malos programadores detrás de la plataforma) me parece absurdo y de mal gusto: el programador debe ajustarse a las especificaciones que le piden. Muy posiblemente hubiese dos (o más) equipos, uno para la App móvil y otro para el servidor y se decidiese comunicar ambos de una manera concreta (xml + https o cualquier otra variante).
No echemos las culpas del diseño a un programador...
Si es que vaya gilipollez. Ya puestos se podría haber instalado un rootkit (troyano) en el móvil, a ver a que información tiene acceso.
De hecho puedes como en la propia web de development de Android hablan de ello: developer.android.com/training/articles/security-ssl.html
También puedes no aceptarlos por defecto cambiando parámetros en el manifest, como dicen en esta respuesta de StackOverflow: stackoverflow.com/questions/2012497/accepting-a-certificate-for-https-
De hecho como he dicho antes, yo hago una app para un banco grande y es lo primero que se hace en la app, comprobar que el certificado es válido.
Si a ti te la pela la seguridad que te pueda dar una app de un banco, bien. A mi no me gustaría que NADIE pudiera ver mis contraseñas para poder hacer una transferencia o lo que sea por internet.
Creo que toda seguridad es poca en algo tan sensible como datos bancarios. Nosotros ofuscamos el código, encriptamos la base de datos temporal(que guarda mientras la app está activa la lista de movimientos y cuentas, cuando no usas la app durante 5min, te desloga y se borra. También ocurre si cierras la app, obviamente), se verifican los certificados, además nunca se mandan los datos sensibles en texto plano y no recuerdo qué mas cosas se le metieron a la app. Sólo por si acaso pasa algo.
Sobre #21, no dice que no haya añadido estos certificados autofirmados manualmente a través de los ajustes de iOS, sólo "que se están fiando de un CA que no es el suyo".
Es más, me jugaría el cuello a que han echado mas horas que la puerta para poder cumplir con "los compromisos" adquiridos por el comercial/gerente/[inserte aquí al tocapelotas de turno]
Con un proxy interceptando SSL y una CA autofirmada, da error al iniciar la conexión SSL y no deja continuar.
Levantando un servidor suplantando el del BVVA y realizando DNS spoofing, el mismo comportamiento.
Conclusión: si no añades CA al móvil, la aplicación no te deja continuar ni envía un sólo dato.
Para mi gusto, igual de segura que cualquier navegador de cualquier dispositivo.
En el post no da a entender que hay que cambiarse la CA.
Coincido en que cifrar otra vez es un absurdo con con que este https bien implementado es suficiente.
No obstante la situación actual de la aplicación no es ni mucho menos como para dedicarle un post alarmista en el que no se explica claramente los requisitos previos (instalar una CA autofirmada en iOS, lo cual es un acto que pide confirmación y saltan advertencias de seguridad, y si es un móvil de empresa NO deja instalarla) y se tergiversa la realidad (texto plano es cuando NO hay SSL y en las capturas se aprecian siempre URL con https, y en ningún momento se indica que sin el requisito previo la aplicación NO envía ni un sólo dato)
Aun asi, me parece una gran cagada de BBVA, pero el riesgo no es demasiado alto... Para que sea un riesgo real, hay que conseguir introducir un certificado "fake" en el telefono, y eso parece mas complicado
Los proxies de intercepción negocian con el servidor final porque usan un certificado válido como puede ser el que usa tu navegador, solo te pueden hacer esto si te conectas a una wifi no fiable y pasa tanto en esta aplicación como en todas, como si lo haces a través del PC con una VPN de la leche, estás aceptando usar un certificado no fiable (el del proxy de intercepción).
¿Habeis probado a ver si conseguis "hackearos" capturando los paquetes con Wireshark? De verdad, si no tenéis ni idea de seguridad, no hagais el magufo como e la persona que ha escrito el blog.