Con la versión 3.0 de iOS llegaron las compras in-app, o dentro de la aplicación. Este sistema permitía comprar productos dentro de las aplicaciones (por ejemplo, un nuevo coche para un juego o temas distintos para una aplicación de lectura) usando el sistema de pagos de la App Store. Es una buena idea pero con fallos de seguridad, tal y como ha demostrado Alexey Borodin.
Es un ataque del tipo MITM (man-in-the-middle, literalmente hombre en el medio). Instalando unos certificados y cambiando las DNS del teléfono, las compras in-app son interceptadas y pasan al servidor de Borodin en lugar de al de Apple.
El servidor de Borodin devuelve a la aplicación un certificado de compra, que hace pensar a la aplicación que el usuario ya ha pagado aunque en realidad no se haya desembolsado nada. ¿De dónde sale ese certificado de compra? Dado que no contienen ningún dato sobre el comprador, lo único que necesita Borodin es un único certificado real, que pasa a todos los que hacen la misma compra
No todas las aplicaciones son vulnerables
La forma en la que está diseñado el proceso de compras a través de la aplicación hace que no todas sean vulnerables. Hay dos modelos distintos que los desarrolladores pueden adoptar. El más seguro es el modelo con servidor externo: la aplicación procesa la petición de compra y recibe el certificado, que es enviado al servidor externo de la aplicación. En cuanto lo recibe, lo verifica con la App Store y, si es válido, devolverá a la aplicación el contenido comprado.
Los desarrolladores que usen este modelo no son vulnerables, ya que el ataque MITM sólo afecta al teléfono. Las comunicaciones entre la aplicación y su servidor, y entre el servidor y la App Store no se interceptan y por lo tanto el fraude queda detectado.
Sin embargo, hay otro modelo en el que sólo participa la aplicación. Según las directrices de Apple, en este caso no se verifica el certificado de compra y por lo tanto son totalmente vulnerables. Y, de todas formas, aunque se hiciese, el servidor de Borodin interceptaría la petición y haría pensar a la aplicación que la transacción es válida.
Usando este hack, podrían haberse hecho más de 30.000 ventas falsas en las aplicaciones. Ahora mismo, lo único que pueden hacer los desarrolladores es o bien verificar las compras con un servidor propio o esperar a que Apple corrija este fallo en su API.
Vía | The Next Web
Más información | Apple
Ver 13 comentarios
13 comentarios
92563
"esperar a que Apple corrija este fallo en su API"
Ojo, porque no es un fallo en la API de compras in-app. Hay un mecanismo por el cual el desarrollador debe verificar la compra desde su propio servidor con los servidores de Apple, si el desarrollador omite el programa que hace esta verificación antes de dar los items, goodies o lo que sea al dispositivo solicitante, pues es completamente responsabilidad del desarrollador, no de Apple.
Esto ni siquiera es un exploit en el sistema de compras in-app, es un exploit de la falta de cuidado para desarrollar sistemas por parte del desarrollador.
jdeb
pues que yo sepa en cydia ya hace mucho que se puede hacer estoy con muchos juegos en los que hay que comprar cosas .., y en mi ipod touch funciona muy bien
guipita
Esa era la clase de fallo que estaba esperando que bien
jpeeri
OJO!! Para los que quieran hacerlo, tened en cuenta que muy posiblemente al poner esas DNS e introducir tu ID de Apple el hacker éste se quede con tus credenciales. Muy importante!!!