Imagine un portero corpulento en una fiesta exclusiva. Cuando alguien afirma ser invitado, el portero verifica su invitación y la ejecuta con los nombres de la lista. Si no coincide, la persona no lo atraviesa a través de la cuerda de terciopelo. Pero, ¿qué sucede si el portero no está haciendo su trabajo? Su lapso podría permitir que un timbre en la fiesta avance en los caballos y robar los objetos de valor.
No es una analogía perfecta, por supuesto, pero los acuerdos de la FTC con la compañía de información crediticia Karma y el sitio de boletos de película Fandango demuestran los peligros cuando las empresas anulan la configuración predeterminada de los sistemas operativos diseñados para autenticar y asegurar las conexiones utilizadas para transmitir información confidencial.
Así es como funcionan las cosas después de que un consumidor ha descargado una aplicación en un dispositivo. Piense en la capa de enchufes seguros (SSL), el protocolo estándar de la industria para establecer conexiones encriptadas, como el portero. Cuando un servicio en línea quiere conectarse a una aplicación, el servicio presenta un certificado SSL para obtener de su identidad. Una vez que la aplicación valida el certificado, el servicio en línea está permitido a través de la cuerda de terciopelo y establece una conexión encriptada con el dispositivo para que el consumidor pueda enviar información. Este solo golpe de validación a través de un certificado y cifrado SSL crea una forma más segura para que las personas transmitan datos confidenciales.
Pero se sabe que los estafadores utilizan técnicas de falsificación para montar lo que se llaman ataques de hombre en el medio. Si la aplicación no verifica el certificado SSL, un atacante puede usar un certificado no válido para poner su pie en la puerta y establecer una conexión para interceptar la información enviada entre la aplicación y el servicio en línea. Ni la persona que usa la aplicación ni el servicio en línea se dan cuenta de lo que está sucediendo.
Asegurar la transmisión de información personal contra amenazas como los ataques del hombre en los medios es tan importante que los sistemas operativos iOS y Android proporcionan a los desarrolladores interfaces de programación de aplicaciones fáciles de usar, API, para implementar SSL. Por defecto, estas API validan automáticamente los certificados SSL y rechazan la conexión si el certificado no es válido.
La documentación del desarrollador para los sistemas operativos iOS y Android utiliza un lenguaje particularmente fuerte para advertir contra la deshabilitación de las configuraciones de validación predeterminadas. Según la documentación de iOS, no validar los certificados SSL “elimina cualquier beneficio que de otro modo podría haber obtenido de usar una conexión segura. La conexión resultante no es más segura que enviar la solicitud a través de HTTP sin cifrar porque no proporciona protección contra la falsificación por parte de un servidor falso ". La documentación de Android tampoco hace palabras: una aplicación que no valida los certificados SSL "también podría no ser una comunicación encriptadora, porque cualquiera puede atacar a los usuarios en un punto caliente público de Wi-Fi. . . (y) el atacante puede registrar contraseñas y datos personales ".
Según la FTC, Credit Karma y Fandango ignoraron esas advertencias de "No vayas allí". Mientras desarrolla su aplicación iOS, que permite a los consumidores obtener sus puntajes de crédito y monitorear otros datos financieros, Credit Karma autorizó a un proveedor de servicios para usar el código que desactivó la validación del certificado SSL para fines de pruebas. Pero la FTC dice que Credit Karma deja que la aplicación vaya al mercado sin volver a encender la configuración predeterminada. Entonces, entre el 18 de julio de 2012 y alrededor del 1 de enero de 2013, la aplicación iOS de la compañía era vulnerable a los ataques de hombre en el medio, poniendo en riesgo los números de seguro social de los usuarios, fechas de nacimiento e informes de crédito.
¿Cómo se enteró Creditkarma sobre el problema? Según la FTC, no a través de sus propios controles y monitoreo internos. La queja alega que un usuario contactó a Credit Karma, lo que llevó a los ingenieros de la compañía a actualizar la aplicación en enero de 2013 para restaurar la configuración predeterminada.
Pero ese no es el final de la historia de Karma Credit. Poco tiempo después, el personal de la FTC contactó a Credit Karma sobre el problema. Solo entonces el equipo interno de la compañía realizó una revisión de seguridad en ambas versiones de la aplicación. ¿Fue una cosa complicada, costosa y que consume mucho tiempo? No. Según la FTC, tomó solo unas pocas horas y costó casi nada. ¿Y adivina lo que reveló? En febrero de 2013 – después Credit Karma había sido contado sobre la vulnerabilidad de iOS: la compañía lanzó la versión de Android de su aplicación con exactamente el mismo problema. La revisión también reveló otra falla de seguridad: la aplicación iOS estaba almacenando tokens de autenticación y códigos de acceso en el dispositivo de manera insegura.
La demanda de la FTC contra Fandango cobra a la compañía con fallas similares. Desde marzo de 2009 hasta marzo de 2013, la versión iOS de la aplicación de Fandango no pudo validar los certificados SSL, anulando los incumplimientos de seguridad del sistema. Según la FTC, Fandango no probó su aplicación antes de la versión para asegurarse de que estaba validando los certificados SSL y transmitiendo de forma segura los datos personales de los consumidores, incluidos los números de tarjetas de crédito, las fechas de vencimiento y los códigos de seguridad. Sí, Fandango encargó algunas auditorías en 2011, dos años completos después de que se lanzó la aplicación. Pero incluso entonces, limitó el alcance para incluir solo amenazas planteadas cuando el atacante tenía acceso físico al dispositivo de un consumidor. No probó la transmisión segura de datos. Por lo tanto, Fandango perdió la oportunidad de detectar la vulnerabilidad que había introducido al anular los valores predeterminados.
La FTC dice que Fandango agravó el problema al no tener un canal efectivo para que las personas informen problemas de seguridad. Según la queja, un investigador contactó a la compañía en diciembre de 2012 a través del único método fácilmente disponible: un formulario web de servicio al cliente. Debido a que el mensaje del investigador incluía el término "contraseña", el sistema de servicio al cliente de Fandango lo trató como una solicitud de restablecimiento de contraseña de rutina y respondió con un mensaje enlatado. Luego, el sistema desestimó la advertencia de seguridad como "resuelta".
¿Cuándo solucionó Fandango el problema? Según la queja, no fue hasta que la compañía escuchó al personal de la FTC. Solo entonces Fandango ejecutó la prueba simple que reveló que su aplicación no pudo validar los certificados SSL. Fandango también descubrió que la vulnerabilidad afectó una aplicación de boleto de cine separada que organizó para un tercero. En tres semanas, Fandango emitió una actualización de ambas aplicaciones de iOS que restauró la configuración predeterminada, conectando así ese orificio de seguridad.
Los acuerdos propuestos con Credit Karma y Fandango requieren que las empresas establezcan programas de seguridad integrales para abordar los riesgos relacionados con el desarrollo y la gestión de productos nuevos y existentes y para proteger la seguridad, la integridad y la confidencialidad de la información cubierta por la orden. De acuerdo con otros acuerdos, Credit Karma y Fandango necesitarán auditorías de seguridad STEM-a-Stern de un profesional independiente cada dos años durante los próximos 20 años. Por supuesto, los términos de los acuerdos se aplican solo a esas compañías, pero las empresas inteligentes querrán leer las órdenes propuestas para ver qué se requiere de Credit Karma y Fandango. Puede presentar un comentario sobre los acuerdos propuestos antes del 28 de abril de 2014.
¿Qué más pueden aprender las empresas de estos casos?
1. ejercicio de atención extrema al modificar los valores predeterminados de seguridad. Si las empresas se hubieran dejado lo suficientemente solo, los incumplimientos de seguridad de los sistemas operativos habrían protegido la información personal de los consumidores de los ataques de hombre en el medio. Por supuesto, no estamos diciendo que siempre es ilegal modificar una configuración predeterminada. De hecho, hay formas de ir más allá de la validación de certificado SSL predeterminada implementando un método de autenticación aún más fuerte conocido como "fijación de certificados". Pero modificar los valores predeterminados de seguridad es la cirugía cerebral del desarrollo de aplicaciones. Las empresas deben estar seguras de que saben lo que están haciendo.
2. Pruebe su aplicación a fondo antes de liberarla. Los carpinteros tienen un viejo adagio: "Medir dos veces, cortar una vez". El corolario para los desarrolladores de aplicaciones: aproveche los métodos fácilmente disponibles para probar la seguridad de sus aplicaciones. antes Los pones en manos de los consumidores.
3. Considere cómo las personas usarán sus aplicaciones. Hay una razón por la cual SSL es tan importante en el entorno móvil y por qué la documentación del desarrollador de iOS y Android hace que sea tan importante al respecto: porque las personas a menudo usan aplicaciones móviles en redes Wi-Fi públicas no garantizadas. Al igual que los jugadores de ajedrez, los desarrolladores deben pensar algunos avances por delante. Antes de lanzar una aplicación, piense en cómo las personas es probable que la usen y asegure con esas consideraciones del mundo real en mente.
4. Eres responsable de lo que otros hacen en tu nombre. Según la queja, Credit Karma autorizó a un proveedor de servicios para deshabilitar el proceso de validación del certificado SSL durante las pruebas de preliminación previa, pero no se encargó de que la configuración de seguridad se restableciera después de eso. La primera preocupación: la prueba podría haberse realizado sin apagar los valores predeterminados. Pero aun así, es de vital importancia que las empresas se aseguren de que todo vuelva a la orden de la tarta de Apple antes de que los consumidores obtengan la aplicación.
5. Mantenga la oreja en el suelo. Existe una comunidad de investigación activa que comparte información sobre posibles vulnerabilidades de seguridad. Pero al responder a una advertencia seria con una "carta de chinches" estándar, Fandango perdió la oportunidad de solucionar los problemas. Tiene una persona conocedora contactada su ¿Compañía recientemente sobre un riesgo potencial? ¿Y ese mensaje es languidecedor no leído en un cuadro de correo electrónico?
6. Consulte los recursos disponibles. El folleto de la FTC, desarrolladores de aplicaciones móviles: comienza con seguridad, ofrece consejos para las empresas sobre la protección contra este tipo de vulnerabilidad:
Para proteger a los usuarios, los desarrolladores a menudo implementan SSL/TLS en forma de HTTPS. Considere usar HTTPS u otro método estándar de la industria. No hay necesidad de reinventar la rueda. Si usa HTTPS, use un certificado digital y asegúrese de verificarlo correctamente. Un certificado digital sin lujos de un proveedor de buena reputación es económico y ayuda a sus clientes a garantizar que se comuniquen con sus servidores, y no el de otra persona. Pero los estándares cambian, así que vigile las tecnologías actuales y asegúrese de utilizar las últimas y mejores características de seguridad.
Marque la página de privacidad y seguridad de la FTC y consulte a otras fuentes públicas para obtener información gratuita sobre el desarrollo de aplicaciones más seguras.
