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