[02/06/2021] A principios de mayo, Peloton, la empresa de fitness, anunció que había expuesto datos de cuentas de clientes en Internet. Cualquiera puede acceder a los datos de las cuentas de los usuarios desde los servidores de Peloton, incluso si los usuarios configuran sus perfiles de cuenta como privados. La causa: una API defectuosa que permitía solicitudes no autenticadas.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Las interfaces de programación de aplicaciones (API, por sus siglas en inglés) permiten una fácil comunicación de máquina a máquina. El uso de las API ha experimentado un crecimiento explosivo últimamente. Según Akamai, las comunicaciones entre APIs ahora representan más del 83% de todo el tráfico de Internet.
También son la causa de muchos problemas de seguridad. Recientemente, además de Peloton, otras compañías como Equifax, Instagram, Facebook, Amazon y PayPal, han aparecido en las noticias por problemas de ciberseguridad relacionados con las API.
Los ataques y el uso de las API aumentan
Según un informe de Salt Security publicado en febrero, el 91% de las empresas tuvieron problemas de seguridad relacionados con las API el año pasado. Los más comunes fueron las vulnerabilidades, con el 54% de los encuestados, los problemas de autenticación con el 46%, los bots con el 20% y la denegación de servicio (DoS, por sus siglas en inglés) con el 19%.
El 80% de las organizaciones no cree que sus herramientas de seguridad puedan evitar los ataques a las API de manera efectiva. La encuesta de Salt Security encontró que dos tercios de las organizaciones han demorado el lanzamiento de una nueva aplicación en producción debido a preocupaciones relacionadas con la seguridad de la API. Los clientes de Salt, todos los cuales tenían firewalls de aplicaciones web (WAF, por sus siglas en inglés) y puertas de enlace para APIs, habían experimentado múltiples ataques a APIs por mes, lo que significa que los ataques a las API estaban superando a esas herramientas de seguridad. De hecho, según Salt, los WAFs y las puertas de enlace para APIs pasan por alto el 90% de las 10 principales amenazas a la seguridad de las API de OWASP.
Sin embargo, más de una cuarta parte de las organizaciones ejecutan aplicaciones críticas basadas en API sin una estrategia de seguridad. Peloton, por ejemplo, originalmente hizo que los datos del usuario fueran accesibles a través de APIs para cualquier persona, en cualquier lugar, sin ninguna autenticación, afirma Tim Mackey, estratega y director de seguridad del Synopsys Cybersecurity Research Center. "El primer paso que Peloton tomó para asegurar su API fue restringir el acceso a los suscriptores, pero eso aún significaba que cualquier usuario podía acceder a los datos de cualquier otro usuario, independientemente de la configuración de privacidad”, afirma. "Se podía acceder a datos como la edad y el sexo de un usuario, su imagen de perfil y algunos datos de actividad”.
Las fugas no son poco comunes en las API. Según el informe de Salt Security, el 82% de las organizaciones no confía en que conoce los detalles de las API, por ejemplo, si estas incluyen información de identificación personal (PII, por sus siglas en inglés) como la información en red del cliente, información de salud protegida y datos de tarjetas, y el 22% de las organizaciones afirma no tener manera de saber qué APIs exponen datos confidenciales.
El error de Peloton fue utilizar APIs no autenticadas, vulnerables a la autenticación a nivel de objeto roto, afirma Roshan Piyush, ingeniero de investigación de seguridad de Traceable. Otras empresas que se encontraron con el mismo problema incluyen a Panera, Fiserv, LifeLock y Kay Jewelers, afirma Piyush. "Y la lista continúa”. Por lo general, se reduce a que se pasa por alto la protección de autenticación y autorización para las APIs en el proceso de desarrollo, agrega.
La historia de crecimiento de la API de One Bank
Jeff Serota, gerente de tecnología de ciberseguridad en una institución financiera de tamaño mediano, afirma que el uso de las API de su empresa ha crecido drásticamente en los últimos meses. En la actualidad, las API conectan alrededor de tres mil terminales, que incluyen aplicaciones internas y las que pertenecen a socios de negocios, así como páginas web y dispositivos móviles orientados al cliente.
Eso es solo el comienzo, afirma Serota. "Llevamos dos años en un proceso que se espera dure cinco años, y los próximos tres años serán de una rápida aceleración. Conseguimos un nuevo CISO hace unos 16 meses y él viene del lado del desarrollo de APIs, por lo que definitivamente ha aumentado esa velocidad”.
Hasta ahora, añade Serota, en su mayoría han estado sentando las bases. "De hecho, estamos en un camino en este momento en el que estamos en una línea de tiempo para eliminar todos los centros de datos on premises y pasar a servicios web y APIs para todo”, señala Serota.
Las llamadas a la API pasan por cuatro URL principales, afirma Serota, con diferentes servicios que incluyen diferentes parámetros en sus llamadas a la API. Este enfoque crea una capa de protección. "Con las APIs, debido a lo riesgosas que eran, en realidad complicamos algunos de los nombres de los terminales de nuestras API para que fuera más difícil realizar ataques transversales o de descubrimiento”. Durante los últimos seis meses, nuestra institución también ha estado consolidando las múltiples puertas de enlace para APIs en una sola puerta de enlace principal.
Para la puerta de enlace para APIs, la empresa utiliza Apigee, proveedor de seguridad para APIs adquirido por Google en el 2016. "Esta es la única puerta de enlace que va a utilizar, y así es como se protegerá”, afirma Serota.
Algunas empresas han tenido problemas al tratar de incorporar a todos los desarrolladores con una única puerta de enlace, o estaban preocupadas por posibles cuellos de botella, puntos únicos de falla o ataques DDOS. Serota afirma que este no fue el caso de su institución. "Nuestros desarrolladores en realidad prefieren el método de puerta de enlace para APIs”, afirma. "Está basado en SaaS, es multirregional y, en realidad, les brinda una mejor disponibilidad y menor latencia. Debido a que saben que incrementará su escala automáticamente, no tienen las restricciones que tiene una puerta de enlace para APIs tradicional”.
Por ejemplo, se esperaba que una API registrara 10 millones de transacciones al mes, pero tenía 200 millones en las dos primeras semanas después de su lanzamiento, afirma Serota. "No han sentido latencia ni degradación del rendimiento”. En este momento, el ambiente de producción ve alrededor de dos mil millones de llamadas API al mes, afirma, en comparación con los 800 millones de hace dos años.
Para la autenticación, las aplicaciones móviles y basadas en la web de la empresa utilizan una tecnología Java más antigua, afirma Serota, "pero, a través de un kit de desarrollo de software, estamos en el proceso de trasladarlo a una autenticación basada en API. Es una parte importante de nuestra transición en este momento, y ha requerido mucha colaboración de varios departamentos”.
El nuevo enfoque cambia por completo la forma en que la institución busca ataques basados en credenciales, afirma Serota. Para los socios externos, la compañía está impulsando un modelo de confianza cero para sus llamadas API. "Lo aceleraríamos, pero tenemos socios que aún no están listos”.
Para los consumidores que accedan a la institución a través de su propia web o aplicaciones móviles, habrá persistencia. Esto significa que los consumidores no tendrán que pasar por el proceso de autenticación varias veces. "Nuestros modelos de confianza cero significan que no permitimos ningún tipo de persistencia de sesión, ningún tipo de cookies”, afirma Serota. "Uno debe volver a autenticarse cada vez. Vuelvo a la filosofía básica de que cuando usted desea seguridad, comodidad o rapidez, puede tener dos, pero no las tres”.
Para las API que permanecen dentro del perímetro de seguridad de la empresa, existe otro enfoque. "Una vez que está dentro, tendemos a utilizar otros métodos distintos de la confianza cero, que son más livianos”, comentó Serota. "Estamos usando seguridad IP, dependiendo de a dónde vaya, cuentas de servicio para autenticación, haciendo cosas que están más basadas en Active Directory”.
También existe analítica del comportamiento para detectar comportamientos sospechosos, tanto para el tráfico interno como externo, y filtros automáticos para los mensajes obvios incorrectos. "Ser capaces de separar la paja del trigo en la puerta principal, nos permite analizar las buenas decisiones esperadas de manera más intensiva”. La analítica de comportamiento también se refiere a las transacciones reales. "Usamos todo, desde la reputación de IP hasta la analítica del comportamiento para el usuario y patrones de cuenta”, afirma Serota. "Supongamos que tenemos un usuario que recibe un depósito de 200 dólares cada dos viernes y ahora comienza a depositar cheques de 800 dólares todos los miércoles; empezamos a mirar eso. No es solo para proteger nuestros activos, sino para asegurarnos de que estamos reportando de manera proactiva lo que podría ser lavado de dinero o tráfico de personas”.
Mediante el uso de la automatización, la compañía pudo reducir la cantidad de problemas que llegan a su centro de operaciones de red y su equipo de respuesta a incidentes de ciberseguridad en 35%, afirma Serota. "Les están llegando menos falsos positivos”.
Para ayudar con esto, hace poco más de un año, los equipos de NOC y CSIRT implementaron Salt Security, que se utiliza en flujo compartido con la puerta de enlace API de Apigee. "Es capaz de ver todo el tráfico que llega a nuestras API de nivel superior y luego aprenden de ellas, lo que nos brinda posibles atacantes y recomendaciones sobre cómo mejorar nuestro código”, afirma Serota.
Otros equipos también han adoptado la plataforma, incluido el equipo de detección de fraudes, el equipo de desarrollo y el equipo de arquitectura de seguridad. "Nos ha permitido acelerar los plazos en las migraciones de API”, afirma Serota.
Ataques de bot a las APIs
El tráfico de API está creciendo, pero el tráfico de API malicioso crece más rápido. El volumen mensual de llamadas API de los clientes de Salt Security creció 51%, mientras que el porcentaje de tráfico malicioso creció 211%
En un análisis de Akamai, equivalente a un mes de datos de APIs, de 100 clientes empresariales en las industrias de servicios financieros, comercio minorista, medios y entretenimiento, la empresa encontró 774 mil millones de llamadas de API, el 12% de las cuales provienen de actores maliciosos conocidos y el 25% de clientes finales que no eran navegadores web ni dispositivos o aplicaciones móviles, lo que significa que podrían haberse originado en actores maliciosos en lugar de usuarios legítimos.
Las aplicaciones frontales tradicionales (páginas web y aplicaciones móviles) tienen protecciones contra los atacantes, afirma Rishi Pande, gerente principal de ciberseguridad de Ernst & Young. Eso incluye defensas contra DDoS, relleno de credenciales y otros ataques automatizados. "Su interfaz puede estar protegida, pero si la puerta de enlace API no está resguardada, puede desbordarla con bastante facilidad”, afirma Pande. El espacio está evolucionando rápidamente y algunos clientes suponen que su tecnología ofrece protección, pero las herramientas en sí no están listas.
El problema del relleno de credenciales no solo desaparece con las APIs, agrega Pande. "Las personas aún no han resuelto ese problema”.
De hecho, los ataques a la capa de API se están volviendo populares entre los hackers porque son más anónimos, y las APIs no suelen estar tan bien protegidas como las páginas web y las aplicaciones móviles, afirma Jason Kent, hacker residente en Cequence Security. Kent una vez descubrió cómo abrir puertas de garaje aprovechando un problema de diseño con la API de la empresa de puertas de garaje. "En la seguridad estándar de una página web se cuenta con todo este código adicional que usted puede ejecutar, desde el lado del cliente, para saber si es un atacante o una persona real”, señala Kent. "En una API nos hemos deshecho de todas esas cosas. Realmente hemos facilitado que ocurra un ataque a alta velocidad con la frecuencia deseada”.
Kent afirma que la actual seguridad de las API se encuentra donde estaba la seguridad de las aplicaciones en el 2009. La forma en que hackeó la API de la puerta del garaje fue por medio de su aplicación móvil. "La aplicación que descargas de la tienda de aplicaciones es solo un montón de carpetas y archivos comprimidos”, agrega. "Contiene un manifiesto de todos los terminales de las API con las que hablará”. Kent dicta una clase sobre cómo hacerlo para OWASP.
Una vez que los atacantes desarman una aplicación móvil y descubren cómo se comunica, pueden usar el mismo canal de la API para enviar solicitudes. La inteligencia artificial y el aprendizaje automático pueden ayudar a defenderse contra esto, sostiene Kent, ya que las solicitudes de API que llegan a través de bots se ven diferentes de las que se originan con seres humanos reales que usan aplicaciones legítimas.
Es hora de cambiar a la izquierda
Según el informe 2020 State of the API de Postman, que encuestó a más de 13.500 desarrolladores, solo el 36% de las empresas realizan pruebas de seguridad de sus APIs -en comparación con el 70% que realiza pruebas funcionales y el 67% que realiza pruebas de integración. Según el informe 2020 State of API, de SmartBear, la disponibilidad era la principal preocupación que tenían los desarrolladores cuando se trataba de sus APIs, seguida de la funcionalidad; la seguridad se encontraba en el tercer lugar.
Parte del problema es que los equipos de desarrollo a menudo están separados de los equipos de seguridad, que están a su vez separados de los equipos de redes e infraestructura. "La solución a los silos es DevSecOps”, afirma Albert Whale, gerente senior de ciberseguridad de Capgemini North America. "Ahora podemos integrar las pruebas y darles el control de las pruebas a los desarrolladores de aplicaciones. Hacemos que todos sean miembros del equipo de seguridad”.
Whale afirma que crear aplicaciones más seguras desde el principio es más importante que tratar de asegurar las cosas al final con tecnologías como puertas de enlace para APIs. "Veo la puerta de enlace para APIs como un único punto de falla”, agrega Whale. "Va a ralentizar la aplicación porque tiene que recopilar toda la información para canalizarla de nuevo. Eso no quiere decir que sean terribles, se ajustan a sus necesidades como lo haría un firewall de aplicaciones web, pero hay ocasiones donde su uso es adecuado y tiempos para crecer más allá de ellos”.
Más bien, afirma Whale, las empresas deberían centrarse en una mejor arquitectura, una mejor seguridad y mejores llamadas API. "Se necesita más tiempo para hacer eso, pero las aplicaciones mejor codificadas son lo que se necesita para lograr una mejor protección. Cuando puede hacer una aplicación lo suficientemente robusta como para resistir ataques, no necesita otros elementos para brindar seguridad adicional”.
Los desarrolladores están comenzando a ser más conscientes de la seguridad, concuerda Mike Rothman, analista y presidente de Securosis, una firma de investigación de ciberseguridad. "Estamos viendo a DevSec para intentar que la gente colabore”, afirma. "¿Sucede siempre? No siempre, pero estamos tratando de derrumbar muchos de esos silos, derribando los muros y haciendo que los equipos trabajen juntos”.
Cuando se trata de seguridad para APIs, existen múltiples áreas de vulnerabilidad, afirma Rothman. Comienza con la lógica de negocios. "Este es uno de esos aspectos clave de la seguridad de las aplicaciones en el que no podría decirles que hemos acertado”. Debido a que las monolíticas aplicaciones se han dividido en pequeños servicios conectados mediante APIs, el desafío de encontrar y mitigar los problemas lógicos se magnifica. La aplicación podría estar funcionando exactamente como fue diseñada, el mecanismo de autenticación puede ser perfectamente seguro, podría estar completamente libre de vulnerabilidades, pero si existe un problema en la codificación, aún podría ocurrir una infracción.
Luego está el conjunto estándar de vulnerabilidades para tener en cuenta. El OWASP API Top 10, lanzado en el 2019, no ha cambiado en los últimos dos años, afirma Rothman. "Seguimos teniendo los mismos problemas una y otra vez”, añade. "Entonces necesitamos defender el ambiente en múltiples niveles -tecnología de red tradicional, tecnología de seguridad de aplicaciones tradicional”.
Finalmente, las organizaciones deben buscar herramientas, automatización, tecnologías de escaneo y monitoreo de telemetría porque no hay suficientes personas para monitorear la seguridad de las API manualmente. "Tenemos que aprovechar lo que tenemos, y no nos referimos a las personas”, afirma Rothman. "Realice un seguimiento para determinar cómo se llaman a las APIs y busque comportamientos anómalos que puedan indicar un uso indebido malintencionado”.
La firma Warehouse obtiene visibilidad de la seguridad de las API
Es más fácil que nunca para los desarrolladores poner en marcha un servicio web y configurar APIs. Como siempre ocurre con las nuevas tecnologías, la seguridad a menudo se queda atrás.
Incluso si los desarrolladores están todos a bordo con nuevos controles de seguridad, es posible que todavía haya sistemas antiguos dando vueltas. Estas APIs obsoletas y zombis representan un gran riesgo, al igual que las API que se esperaba que fueran de corta duración pero que nunca se retiraron.
"No se pueden proteger las cosas que no se conocen”, afirma Tyler Warren, director de seguridad de Prologis, una empresa de almacenamiento. "Mirando algunas soluciones de seguridad para APIs, uno tenía que saber lo que era lo que tenía para protegerlas. Eso ya era una causa perdida porque no lo sabía. Descubrir lo que teníamos era la primera prioridad”.
Warren, responsable del programa de seguridad para APIs de Prologis, afirma que su empresa comenzó a desarrollar sistemas orientados al cliente hace apenas cuatro años. "Tenemos casi mil millones de pies cuadrados [casi 93 millones de metros cuadrados], unos cinco mil almacenes en 19 países”, afirma. "Cuando las personas se enteran de que eres una empresa de almacenamiento, preguntan: '¿Qué podrían estar haciendo que sea de alta tecnología?' Pero la gerencia ha decidido que la tecnología es un facilitador del negocio, no un centro de costos”.
Entonces, Prologis cambió. Hace cuatro años, la mentalidad en el sector del almacén era: "Aquí están sus cuatro paredes y un techo, aquí están sus llaves, venga a hablar con nosotros en unos años cuando se renueve su contrato de arrendamiento”, afirma Warren.
Ahora, existe la plataforma Prologis Essentials, basada en la nube, que permite a los clientes enviar tickets de servicio o verificar el estado de las facturas, pero lo que es más importante, conectarse con proveedores locales que brindan control de plagas, montacargas, iluminación y otros productos y servicios necesarios cuando alguien se muda a un nuevo almacén.
Dado que era un servicio completamente nuevo, sin sistemas previos con los que lidiar, Prologis comenzó de inmediato con una arquitectura sin servidor basada en la nube. "Incluso nos saltamos los contenedores”, afirma Warren. "Somos casi exclusivamente sin servidor. Somos principalmente funciones de Amazon y Lambda”.
Prologis Essentials utiliza la puerta de enlace para APIs de AWS y tiene alrededor de 15 APIs que sirven a 500 terminales, afirma Warren, que incluye conexiones internas e integraciones con socios de negocios externos. El mes pasado, el sistema procesó 529 mil solicitudes de APIs.
Lo que descubrió fue que AWS no proporciona mucha información sobre lo que sucede con las API. "AWS en sí no brinda esa información”, afirma Warren. "Probamos algunas formas previas, pero un firewall de aplicaciones web no funciona, aunque le brinda un poco de protección si no tiene nada más”.
Warren buscó una tecnología que fuera fácil de implementar y que no se interpusiera en el camino del equipo de desarrollo. "Una vez que ha estropeado esa relación, uno se encuentra en problemas”, afirma. "Si se convierte en el tipo de seguridad que dice 'no', empiezan a pasarlo por alto. Por lo tanto, la solución tiene que encajar en su flujo de trabajo y ahora crear cualquier trabajo adicional para ellos”.
Prologis eligió Salt Security. Originalmente planearon un lanzamiento en el 2021, pero decidieron hacerlo en el 2020. "La superficie de ataque de la API está recibiendo más atención”, afirma Warren. "Los malos se han dado cuenta de que hay mucha superficie de ataque”.
Se tardó aproximadamente un mes en implementar Salt Security para el sistema Essentials. "Mucho del tiempo se dedicó a pruebas”, afirma Warren, "y asegurarse de que los desarrolladores estuvieran de acuerdo con ello, cerciorándose de que no haya impacto en el rendimiento”.
La herramienta se encuentra dentro del ambiente de AWS y escucha el tráfico en la puerta de enlace para APIs, captura registros y metadatos, y envía informes al panel de SaaS de Salt para recibir alertas y generar informes. "Originalmente supuse que teníamos 100 terminales de APIs”, afirma Warren. "Al final, teníamos 500. Por lo general, tengo una idea bastante clara de lo que sucede en la red, pero lo perdí por mucho. Ese es un problema común en la industria: la gente subestima drásticamente lo que tiene”.
El sistema estaba en funcionamiento el otoño [septentrional] pasado. Eventualmente, podría conectarse a WAF y activar acciones automáticamente. En este momento, envía informes para que el personal de seguridad los revise manualmente. "Lo último que quiero hacer es bloquear el tráfico legítimo”, afirma Warren.
El sistema también busca posibles fugas de PII, afirma Warren. Por ejemplo, se le advirtió que las claves privadas de AWS podrían tener fugas, pero resultó ser un falso positivo. "Tenemos números de cuenta que parecen claves de AWS, pero eso fue una coincidencia”.
El sistema también detectó algunos casos en los que las API proporcionaban más información de la estrictamente necesaria. "Di una combinación de una dirección de correo electrónico y un número de cuenta que no sea necesariamente confidencial”, afirma, "pero me refiero a 'si no lo necesita absolutamente, no lo haga'”. Ese es un consejo que muchas empresas deberían seguir cuando se trata de APIs.
Basado en el artículo de Maria Korolov (CSO) y editado por CIO Perú