Comprender las Ciber amenazas a las APIs

Fecha: 01/06/2020

Autor: Edward Amoroso, CEO, TAG Cyber
Colaboración: Matthew Keil, Director de Product Marketing, Cequence.

Resumen:

Este es el cuarto artículo de una serie, que presenta y explica las amenazas, desafíos y soluciones de seguridad de las interfaces de programación de aplicaciones (API), para los participantes en el desarrollo, operaciones y protección de software.

Objetivo:

Brindar el conocimiento de cómo las mayores empresas de ventas en Internet rompieron las murallas de sus sistemas con un modelo conector uniforme. Utilizando un nuevo estilo de programación, con una técnica conocida como Representational State Transfer o REST, dando lugar a la invención de las API-REST, definiendo a la API como un estilo arquitectónico y de diseño de arquitecturas de software basado en Red.

Problemas de seguridad para las API.

Los muchos beneficios que las API aportan a las comunidades de desarrollo de software y aplicaciones es que están bien documentados, disponibles públicamente, mantienen estándar, son eficientes y fáciles de usar. Actualmente están siendo aprovechados por los malos actores para ejecutar ataques de alto perfil contra aplicaciones que dan la cara al público. Por ejemplo, sabemos que los desarrolladores pueden usar API para conectar recursos como formularios de registro web a muchos sistemas diferentes de back-end. La flexibilidad resultante para tareas de actualización del back-end también proporciona compatibilidad con ataques automatizados.

La encrucijada de la seguridad para las API es que, mientras la mayoría de los profesionales recomendarían decisiones de diseño que hagan que los recursos estén más ocultos y menos disponibles, la implementación exitosa de las API exige la disposición a centrarse en hacer que los recursos estén abiertos y disponibles. Esto ayuda a explicar la atención sobre este aspecto de la informática moderna y por qué es tan importante para los equipos de seguridad identificar las buenas estrategias de mitigación de riesgos para el uso de las API.

Los 10 riesgos principales del OWASP.

La Open Web Application Security Project (OWASP) Foundation fue creada para mejorar la seguridad del software a través de iniciativas de la comunidad. Su producto más famoso es el llamado “OWASP top ten risks”, que se publica para ayudar a los desarrolladores de software a evitar los riesgos más comunes en la creación y el uso de aplicaciones web. Se enumera a continuación una descripción de los diez principales riesgos de OWASP:

1. Inyección. Los errores de inyección, como la inyección de SQL, NoSQL, el sistema operativo y LDAP, se producen cuando datos no confiables son enviados a un intérprete como parte de un comando o consulta. Los datos hostiles del atacante pueden engañar al intérprete para que ejecute comandos no deseados o acceda a los datos sin la autorización adecuada.

2. Autenticación rota. Las funciones de aplicación relacionadas con la autenticación y la administración de sesiones a menudo se implementan incorrectamente, lo que permite a los atacantes comprometer la contraseñas, claves o tokens de sesión, o aprovechar otros defectos de implementación para asumir las identidades de otros usuarios de forma temporal o permanente.

3. Exposición de datos sensibles. Muchas aplicaciones web y las APIs no protegen adecuadamente los datos confidenciales, tales como los financieros, los datos de salud, entre otros. Los atacantes pueden robar o modificar los datos débilmente protegidos para llevar a cabo fraudes con tarjetas de crédito, robo de identidad u otros delitos. Los datos confidenciales pueden verse comprometidos sin la protección adicional, como el cifrado en reposo o en tránsito, y requieren precauciones especiales cuando se intercambian con el navegador.

4. Entidades externas XML (XXE). Muchos procesadores XML viejos o mal configurados evalúan las referencias de entidades externas en documentos XML. Las entidades externas se pueden usar para revelar archivos internos mediante el controlador de archivo URI, recursos compartidos de archivos internos, análisis de puertos internos, ejecución remota de código y ataques de denegación de servicio.

5. Control de acceso roto. Las restricciones sobre lo que los usuarios autenticados pueden hacer a menudo no se aplican correctamente. Los atacantes pueden explotar estos defectos para acceder a funciones y/ o datos no autorizados, tales como acceder a cuentas de otros usuarios, ver archivos confidenciales, modificar los datos de otros usuarios, cambiar los derechos de acceso, etc.

6. Configuración incorrecta de seguridad. La configuración incorrecta de seguridad es el problema más común. Esto suele ser el resultado de configuraciones predeterminadas inseguras, configuraciones incompletas o ad hoc, almacenamiento en la nube abierto, encabezados HTTP mal configurados y mensajes de error detallados que contienen información confidencial. No solo todos los sistemas operativos, frameworks, bibliotecas y aplicaciones deben configurarse de forma segura, sino que deben estar parchados o actualizados de forma oportuna.

7. Cross-Site Scripting (XSS). Los defectos de XSS se producen siempre que una aplicación incluye datos no confiables en una nueva página web sin una validación o escape adecuados, o actualiza una página web con datos proporcionados por el usuario mediante una API de navegador que puede crear HTML o JavaScript. Permitiendo a los atacantes ejecutar scripts en el navegador de la víctima que pueden secuestrar sesiones de usuario, desfigurar sitios web, o redirigir al usuario a sitios maliciosos.

8. Deserialización insegura. La deserialización insegura a menudo permite la ejecución remota de código. Incluso si los defectos de deserialización no dan lugar a la ejecución remota de código, se pueden usar para realizar: ataques de reproducción, ataques de inyección y ataques de escalamiento de privilegios.

9. Uso de componentes con vulnerabilidades conocidas. Los componentes, como bibliotecas, frameworks, y otros módulos de software, se ejecutan con los mismos privilegios que la aplicación. Si se explota un componente vulnerable, un ataque de este tipo puede facilitar la pérdida de datos o la toma del servidor. Las aplicaciones y las APIs que utilizan componentes con vulnerabilidades conocidas pueden debilitar las defensas de las aplicaciones y permitir diversos ataques e impactos.

10. Supervisión de logs insuficiente. La supervisión de logs insuficiente, junto con la integración no efectiva o una ineficaz respuesta a incidentes, permiten que los atacantes vulneren los sistemas, mantengan la persistencia, manipulen los sistemas, extraigan o destruyan los datos. La mayoría de los estudios de incumplimiento muestran que el tiempo para detectar una violación es de más de 200 días, normalmente detectados por partes externas en lugar de procesos internos o monitoreo.

Requisitos de seguridad de las API. 

Como lo ejemplifica la lista de OWASP, la comunidad de seguridad cibernética está empezando a identificar muchos problemas que surgen en el uso de API para aplicaciones orientadas al público. A continuación se presentan cinco requisitos generalizados de seguridad cibernética para las API en el contexto de diseño y desarrollo para aplicaciones de Internet nuevas y heredadas:

Visibilidad. El adagio de que el conocimiento es poder parece apropiado cuando se trata de visibilidad de la API. Los desarrolladores y usuarios de aplicaciones deben saber qué API se están publicando, cómo y cuándo se actualizan, quién accede a ellas y cómo se accede a ellas. Comprender el alcance del uso de la API es el primer paso para protegerlos.

Control de acceso. El acceso a la API a menudo se controla libremente, lo que puede provocar una exposición no deseada. Garantizar que el conjunto correcto de usuarios tenga los permisos de acceso adecuados para cada API es un requisito de seguridad crítico que debe coordinarse con los sistemas de administración de acceso e identidad empresarial (IAM).

Mitigación de bots. n algunos entornos, hasta el 90% del respectivo tráfico de aplicaciones (por ejemplo, inicio de sesión o registro de la cuenta, pago del carro de la compra) es generado por bots automatizados. Comprender y administrar los perfiles de tráfico, incluida la diferenciación de los bots buenos de los bots malos, es necesario para evitar ataques automatizados, sin bloquear el tráfico legítimo. Las medidas complementarias eficaces incluyen la implementación de políticas de lista blanca, lista negra y limitación de velocidad, así como la geo-defensa de los casos de uso específicos y los endpoints de las API correspondientes.

Prevención de la explotación de vulnerabilidades. Los procesos sencillos de ataques de las APIS para eliminar un formulario web o una aplicación móvil permiten a un mal actor explotar más fácilmente una vulnerabilidad dirigida. Proteger los puntos de conexión de la API contra el abuso de la lógica empresarial y otras vulnerabilidades es, por lo tanto, un requisito clave de mitigación de la seguridad de la API.

Prevención de pérdida de datos.El prevenir la pérdida de datos sobre las API expuestas para usuarios con privilegios, ya sea debido a errores de programación o brechas de control de seguridad, es un requisito de seguridad crítico. Muchos ataques a la API están diseñados específicamente para obtener acceso a los datos críticos disponibles en servidores y sistemas de back-end.

La comunidad de API continúa impulsando hacia un acuerdo del estándar sobre el enfoque óptimo de la seguridad. Para ello, grupos del sector como OAUTH, por ejemplo, han propuesto criterios para la seguridad de la API que son bastante útiles. El progreso más probable es que la comunidad de seguridad de software continuará perfeccionando su comprensión y conocimiento de la gama completa de requisitos de seguridad de API en los próximos años. Por lo tanto, se espera ver una evolución continua en esta área.

Métodos de seguridad API

Abuso a la API en acción.

Por diseño, las API no tienen estado, suponiendo que la solicitud y la respuesta inicial son independientes, manteniendo toda la información necesaria para completar la transacción. Creando llamadas de programa a una API directamente o como parte de una aplicación móvil o web, mejora la experiencia del usuario y el rendimiento general. Esto hace que sea muy fácil para un mal actor escribir y automatizar su ataque como se destaca en los siguientes dos ejemplos:

• Toma de control de la cuenta y fraude romántico: Zoosk es una aplicación de citas conocida. Los malos actores descompilaron la aplicación Zoosk para descubrir las API de inicio de sesión de la cuenta. Mediante el uso de kits de herramientas de automatización y ataque, luego ejecutaron ataques de adquisición de cuentas. En algunos casos, se utilizaron cuentas comprometidas para establecer una relación personal con otro usuario de Zoosk y, a medida que la relación floreció, el mal actor solicitó dinero debido a una muerte repentina o enfermedad en la familia. El usuario desprevenido le dio el dinero al mal actor, del cual nunca más volvería a saber de él. Antes de implementar Cequence, las estafas románticas en Zoosk promediaron $12,000 por cada evento ocurrido. Ahora, prácticamente están virtualmente eliminadas, como resultado hubo un incremento de confianza de los usuarios y un fortalecimiento de la conciencia de la marca.

• Toma de control de cuentas y fraude financiero: Otro ejemplo de ataque dirigido a las API es el ataque automatizado que implica una búsqueda de grandes clientes de servicios financieros a los cuales los atacantes se han dirigido al API de inicio de sesión de aplicaciones móviles para ejecutar la toma de control de cuentas. Si este tiene éxito, los malos actores podrían intentar cometer fraude financiero transfiriendo fondos a través de la API de Transferencia de Fondos Abiertos (OFX). OFX, por supuesto, es la API estándar de la industria para la transferencia de fondos dentro de la comunidad de servicios financieros, y como tal las API están disponibles públicamente y bien documentadas para facilitar su uso.

La omnipresencia y la naturaleza apátrida de las API son beneficiosas de muchas maneras, pero también introducen numerosos desafíos que las tecnologías de seguridad tradicionales no pueden abordar. Por diseño, las API no tienen un componente del lado cliente, por lo que las técnicas de defensa tradicionales como: Captchas o JavaScript y la instrumentación móvil SDK, no se pueden usar para evitar un ataque automatizado. A menudo, no hay un navegador o aplicación móvil correspondiente para la redirección y la asignación de cookies para la instrumentación. El resultado es que la API y la aplicación asociada se dejan sin protección o solo están parcialmente protegidas.

Referencia:

https://www.helpnetsecurity.com/2020/06/05/api-security-threats/