Investigación de amenazas de API: fallos de autorización de GraphQL en una plataforma de tecnología financiera

Sinopsis del incidente

Los investigadores de Salt Labs analizaron una gran plataforma de tecnología financiera (FinTech) de empresa a empresa (B2B) que ofrece servicios financieros mediante aplicaciones móviles basadas en API y software como servicio (SaaS) a pequeñas y medianas empresas (pymes) y marcas comerciales. Como resultado de las vulnerabilidades de API que identificaron nuestros investigadores, pudieron lanzar ataques en los que:

1. Cualquier usuario podía enviar transacciones no autorizadas contra otros clientes
2. Cualquier usuario podía recopilar datos confidenciales sobre los clientes

La organización utilizaba GraphQL en su pila tecnológica para gestionar las actividades de las cuentas de los clientes que usaban aplicaciones móviles. La organización también aprovechaba una API de terceros para recuperar registros de transacciones anteriores de las cuentas de los clientes. La implementación no autenticaba ni autorizaba correctamente a los clientes. Como resultado, los investigadores de Salt Labs pudieron enviar transacciones no autorizadas contra otros clientes del proveedor de servicios financieros, correlacionar la actividad de las cuentas de los usuarios y recuperar información de identificación personal (PII) de los clientes. Al igual que ocurre con muchas implementaciones de API defectuosas, varios de los problemas que permiten explotar los servicios se corresponden con el OWASP API Security Top 10, incluyendo:

• Autorización a nivel de objeto rota (BOLA)
• Autenticación rota
• Exposición excesiva de datos

Los servicios en cuestión provienen de una división FinTech de una gran marca de consumo que ofrece una combinación de servicios B2B y B2C. Mantener el anonimato de este proveedor de servicios es fundamental, por lo que hemos eliminado cualquier detalle técnico que pudiera identificar a la organización. Tras identificar la vulnerabilidad, revisamos nuestros hallazgos y proporcionamos a la organización las medidas de mitigación recomendadas. Como parte de la misión más amplia de Salt Labs, compartimos los hallazgos aquí para aumentar la concienciación sobre las vulnerabilidades de las API, explicando el patrón de ataque, detallando los pasos para propagar el ataque y destacando las técnicas de mitigación.

Motivación de la investigación

Salt Labs realiza investigaciones sobre amenazas para ayudar a clientes y clientes potenciales a identificar vulnerabilidades en sus propias API. El laboratorio también investiga plataformas públicas para descubrir fallos en la lógica de las aplicaciones, siguiendo prácticas de divulgación responsable y colaborando con las organizaciones pertinentes para resolver los problemas de las API. Publicamos esta información —anonimizada cuando es necesario— para ayudar a los profesionales a aprender de los errores ajenos y evitar incidentes derivados.

En este caso, los investigadores de Salt Labs analizaron la plataforma de tecnología financiera en línea porque la empresa estaba preocupada por posibles brechas de seguridad en sus API y solicitó asistencia a Salt Security. La implementación utilizaba servicios GraphQL, que han ganado popularidad. Varios aspectos de la estructura de la API de GraphQL pueden crear riesgos de seguridad que pueden ser más difíciles de evaluar. La concienciación sobre la seguridad en torno a GraphQL es todavía relativamente baja, y los detalles de la vulnerabilidad de la implementación de la API de esta organización proporcionan un valor educativo adicional para el sector.

El posible impacto empresarial de la brecha de seguridad de la API que encontramos

Una vulnerabilidad frecuente relacionada con GraphQL es que los desarrolladores deben implementar la autorización en cada capa de una consulta GraphQL multicapa para evitar ataques. Este efecto secundario aumenta la carga de trabajo de los equipos de desarrollo y operaciones, y puede prolongar los plazos de entrega de las aplicaciones con muchos puntos finales de API. También puede crear una situación más vulnerable al error humano. Algunos puntos finales pueden olvidarse o no tratarse adecuadamente, lo que provoca sus propios problemas a largo plazo. Por el contrario, las API REST incluyen controles de autenticación y autorización inherentes, siempre que se implementen correctamente mecanismos como OpenID Connect (OIDC) y OAuth2.

En promedio, las aplicaciones móviles incluyen una cantidad significativamente mayor de vulnerabilidades que las aplicaciones web. La autenticación y la autorización suelen ser débiles, estar rotas o estar ausentes en el diseño de las aplicaciones móviles, ya que los desarrolladores se centran principalmente en la movilidad y la usabilidad. Los canales móviles también suelen ser menos seguros que los web. Por otra parte, las bases de código pueden ser mantenidas por equipos distintos, lo que genera discrepancias en la postura de seguridad de las API. Los atacantes conocen esta realidad y alternarán entre los clientes front-end y los servicios back-end para encontrar el eslabón más débil al atacar funcionalidades o datos. Las comunicaciones de las API web suelen estar cifradas con SSL o TLS, lo que da a las organizaciones una falsa sensación de seguridad sobre la resistencia de una aplicación o API ante los ataques. En este caso, los investigadores de Salt Labs pudieron aislar las llamadas a la API, solicitar datos a través de un navegador web estándar y recibir identificadores confidenciales que permitieron realizar ataques contra el mecanismo de autorización utilizado por la aplicación.

Ataque: Realizar transacciones de cuenta no autorizadas contra clientes

Las organizaciones deben dar servicio a múltiples tipos de front-end de aplicaciones, normalmente aplicaciones web y móviles, que a su vez se conectan con muchos servicios back-end. Los flujos de las aplicaciones suelen invocar una serie de llamadas a API internas y externas para proporcionar funcionalidades o datos, y estos flujos pueden variar según el tipo de usuario o la aplicación cliente asociada. Garantizar que una entidad autenticada esté autorizada para acceder a un recurso determinado durante toda una sesión es más fácil de decir que de hacer, sobre todo porque la mayoría de las organizaciones también trabajan con otros socios para habilitar funcionalidades como parte de una cadena de suministro digital más amplia. Una vez que un atacante ha obtenido una sesión autenticada, incluso con niveles de permiso básicos, puede abusar de la autorización para acceder a otros datos o funcionalidades proporcionados por las API y como parte del diseño general de la aplicación.

En nuestra investigación, pudimos alterar los números de cuenta de las llamadas a la API y realizar transferencias de fondos no autorizadas. Los números de cuenta son una forma de información de identificación personal (PII), pero también son útiles para perpetrar fraudes, ya que un atacante puede utilizar la información para realizar acciones en otras cuentas si una API no aplica correctamente la autorización. En este incidente, uno de los números de cuenta era un identificador único emitido por el gobierno y el otro era un identificador de cuenta financiera. Los números de cuenta podían recopilarse y correlacionarse a través de un punto final de API de terceros, lo cual se trata en la siguiente sección de este informe de amenazas.  

Ataque: Desanonimizar y correlacionar la actividad de la cuenta

Las organizaciones subcontratan regularmente el trabajo, incluida la ingeniería de sistemas y las operaciones. Esta práctica empresarial es especialmente común en aplicaciones y API, ya que el trabajo de desarrollo y los artefactos de código pueden provenir parcial o totalmente de terceros. Lamentablemente, un subproducto de la subcontratación suele ser la falta de conocimiento sobre la arquitectura completa y los flujos de aplicación de extremo a extremo. Las peculiaridades en la experiencia del usuario suelen ser el mejor de los casos. En el peor, surgen importantes brechas de seguridad donde la infraestructura puede estar mal configurada o el código presenta debilidades. Estos errores pueden dar lugar a la exposición de datos confidenciales, lógica de negocio abusable y vulnerabilidades explotables para las organizaciones.

En nuestra investigación, descubrimos una API de terceros integrada que exponía inadvertidamente datos confidenciales que desanonimizan a los clientes y permiten a los atacantes correlacionar la actividad de la cuenta. Se expusieron datos de PII, incluidos nombres, direcciones y números de cuenta, a través de este punto final de API de terceros. Los únicos datos necesarios para llamar a esta API y obtener la PII eran un identificador de registro de una transacción anterior. Los datos confidenciales como los descubiertos aquí están sujetos a muchas formas de normativas nacionales y regionales que rigen la actividad empresarial y la privacidad del usuario. Dicha exposición de datos puede dar lugar a sanciones y multas reglamentarias.

Los detalles técnicos de esta brecha de seguridad de la API

Nuestros investigadores analizaron la aplicación móvil y las API de back-end mediante una combinación de métodos que incluyó:

• Análisis del repositorio de Postman
• Ingeniería inversa de la aplicación móvil

Utilizando un repositorio de Postman proporcionado por el cliente, nuestros investigadores examinaron la estructura de la API utilizada por los clientes de la aplicación móvil. Los investigadores comenzaron a comprender qué tipos de solicitudes obtendrían datos útiles que podrían ser explotados. Paralelamente, nuestros investigadores también realizaron ingeniería inversa en la aplicación móvil y correlacionaron sus hallazgos sobre las llamadas a la API con los registros del repositorio de Postman. Nuestros investigadores encontraron y alteraron el certificado SSL/TLS incrustado dentro de la aplicación móvil que se utilizaba para el anclaje de certificados y el cifrado de las comunicaciones de la API. Esta elusión de un control del lado del cliente permitió a nuestros investigadores inspeccionar y manipular el tráfico de la API originado en la aplicación móvil.

A través de la aplicación móvil, un atacante podía ver al receptor de una transferencia de dinero. El uso de la API a través de Postman también expuso datos de PII relacionados con el remitente y el receptor. Además, las llamadas a la API incluían datos valiosos que nuestros investigadores podían utilizar para correlacionar la actividad del cliente y manipular las llamadas a la API de tal manera que pudieran realizar acciones en una cuenta. Nuestros investigadores validaron este patrón de ataque eligiendo un usuario, intentando una transferencia de fondos de cuenta y viendo la transacción en la aplicación móvil.

Los investigadores también descubrieron llamadas a un punto final de API de terceros no autenticado que respondía con un PDF de un recibo de una transacción determinada cuando se le proporcionaba un identificador de transacción único. El punto final de la API de terceros también devolvió otra PII, incluidos nombres, direcciones, importes en dólares e identificadores de cuenta que fueron útiles para verificar si los intentos de transacción maliciosos tuvieron éxito.

Estas vulnerabilidades de seguridad se encontraban en un punto final de API GraphQL, un tipo de API que ha ganado popularidad sobre las API REST para diseños de aplicaciones móviles. La organización no autenticaba ni autorizaba las solicitudes mediante la verificación de la identidad del remitente durante las solicitudes de transferencia de fondos. Técnicas de ataque similares funcionan tanto para diseños de API GraphQL como REST. La complejidad de GraphQL, como las consultas anidadas, a menudo exacerba los desafíos de la autorización, ya que una sola llamada a la API puede consolidar múltiples consultas y puntos finales de API.

Cualquier usuario podía enviar transacciones no autorizadas contra otros clientes

OWASP define los problemas de autorización como autorización de nivel de objeto rota (BOLA)Los atacantes aprovechan las vulnerabilidades BOLA para escalar privilegios y obtener acceso a datos para los que no están autorizados. En este caso, los investigadores de Salt Labs pudieron manipular consultas GraphQL para alterar los destinos de las transferencias de fondos y autorizar automáticamente esas mismas transacciones.  

Los investigadores de Salt descubrieron que un endpoint de la API GraphQL permitía parámetros de consulta controlados por el cliente en el cuerpo del mensaje de la solicitud de la API. El endpoint de la API tenía el siguiente aspecto:

“/BFF/graphql/mutation/doPayment”

En este ataque BOLA, la secuencia de llamadas a la API consistía en los siguientes pasos:

1. Un atacante llama al endpoint utilizando el identificador único (UID) de la víctima, el cual deposita fondos de una cuenta bancaria a una billetera digital. No hay límite en la cantidad de dinero que se puede transferir, pero en este caso, se intentó una transferencia de 100 dólares como prueba.

2. El servidor responde con un mensaje de estado 200 OK indicando que la transacción se envió correctamente. Dentro del payload, la variable “status” también indica que la transacción está pendiente de confirmación. El diseño de la aplicación no incluye ninguna notificación a la víctima sobre esta transferencia. El titular de la cuenta original no sabría que se transfirió dinero de su cuenta a menos que estuviera monitoreando de cerca la actividad de la misma. El valor TID es el identificador de transacción que puede utilizarse para buscar un registro de la operación en un endpoint de API de terceros independiente.

El valor UID aquí es un identificador nacional único. Si el atacante desconoce ese valor, puede obtener la información llamando a un endpoint de API de terceros independiente, como se describe en la siguiente sección. Al acceder a esa API de terceros con un identificador de transacción, se presenta al atacante un recibo de la transacción en formato HTML o PDF. Ese recibo incluye el número de cuenta de la víctima, el ID de la billetera digital, la dirección, el monto de dinero y otros ejemplos de datos de identificación personal (PII). Con esos datos PII obtenidos, el atacante puede iniciar transferencias a cualquier otra cuenta o usuario.

Cualquier usuario podría recopilar datos confidenciales sobre los clientes

Durante la investigación de amenazas, los investigadores de Salt Labs también descubrieron un endpoint de API de terceros que no requería autenticación y que también exponía datos confidenciales. El primero de estos problemas se corresponde con OWASP API2: Autenticación de usuario rota. El segundo problema se corresponde con OWASP API3: Exposición excesiva de datos.  

Los investigadores de Salt descubrieron una función dentro del endpoint de la API GraphQL que, a su vez, llamaba al endpoint vulnerable de la API de terceros. El endpoint de la API GraphQL tenía el siguiente aspecto:

“/BFF/graphql/mutation/receiptUrl”

En este ataque de recopilación de datos, la secuencia de llamadas a la API consistía en los siguientes pasos:

1. Después de que un usuario envía una transacción exitosa en la aplicación móvil, la cual a su vez llama al endpoint GraphQL para la función doPayment, la aplicación móvil realiza otra llamada al endpoint GraphQL para proporcionar un registro de la transacción. La solicitud contiene el identificador de usuario, UID, y el identificador de transacción, TID. Esa solicitud tenía un aspecto similar al siguiente:

2. La respuesta a esa llamada a la API GraphQL contiene una llamada a la API REST anidada que, a su vez, es invocada por la aplicación móvil para devolver un registro de la transacción en formato PDF. Esa respuesta tiene un aspecto similar al siguiente:

3. Esa URL anidada puede llamarse directamente con una solicitud HTTP GET básica o simplemente iniciando la URL en un navegador. Solo era necesario el identificador de transacción, TID, como parámetro, y no se requería ninguna sesión autenticada para obtener los datos. La API de terceros responde con un registro completo de la transacción en formato PDF. Ese recibo en PDF incluye la cuenta de la víctima, el ID de la billetera digital, el nombre, la dirección, los montos en dólares y otros ejemplos de datos PII.

El endpoint de la API de terceros fue útil para validar que el ataque BOLA funcionaba según lo previsto. La API de terceros también exponía demasiados datos confidenciales, y realizar las llamadas fuera de la aplicación móvil sin ningún contexto autenticado validó que los controles de acceso no se estaban aplicando. Estos datos son útiles para perpetrar otros tipos de fraude en la plataforma, y también pueden utilizarse para desanonimizar a los clientes y correlacionar la actividad de las cuentas. El endpoint de la API también parecía carecer de controles de límite de recursos o de tasa, lo que habría hecho posible una mayor enumeración de identificadores de transacciones y el scraping masivo.

Métodos para mitigar esta brecha de seguridad en la API

Explotar las vulnerabilidades de esta plataforma de servicios financieros en línea entre empresas (B2B) requeriría la correlación de datos proporcionados por APIs de terceros y una manipulación única de la lógica de negocio empleada en la API GraphQL utilizada por las interfaces de aplicaciones móviles. Las técnicas de remediación y mitigación adecuadas también deben ser específicas.

Mitigación de fallos de autorización que permiten a un atacante enviar y autorizar transacciones automáticamente

Una API segura debe requerir una verificación constante de que el usuario que solicita datos o funcionalidades está autorizado para acceder a ellos. El sistema debe validar continuamente la autorización en cada sesión y en cada solicitud de acceso a datos. Este enfoque de autorización continua es fundamental para la práctica de seguridad de menor privilegio, que a su vez es una premisa crucial de la arquitectura de confianza cero (zero-trust).

Las organizaciones deben aplicar las siguientes contramedidas para mitigar las debilidades de autorización identificadas por Salt Labs:

1. Autorización continua - la API y los servicios de back-end integrados deben emplear una validación continua para garantizar que el usuario autenticado esté autorizado para acceder a los datos o funciones solicitados.
2. Devolver códigos de error HTTP precisos - Si un usuario autenticado intenta acceder a los registros de otro usuario, el servidor debe responder con un código de estado HTTP "401 Unauthorized" o "403 Forbidden", y/o redirigir al usuario no autenticado a una página de inicio de sesión que muestre un código de estado HTTP 30X.
3. Invalidar sesiones de solicitudes abusivas - Diseñar la plataforma para que supervise e invalide las sesiones en las que los usuarios realicen solicitudes excesivas, enumeren registros o hagan intentos repetidos de acceder a datos no autorizados.
4. Evitar nombres predeterminados o simples - Utilizar nombres e índices únicos que los atacantes no puedan adivinar, atacar por fuerza bruta o enumerar fácilmente.
5. Utilizar límites de tasa (rate limits) - Aplicar límites de tasa en los puntos finales de la API para evitar la enumeración, teniendo en cuenta que los atacantes reducirán sus tasas de solicitud para evadir la detección.
6. Garantizar la coherencia de la autenticación y autorización entre canales web y móviles - Las plataformas deben diseñarse de modo que implementen la autorización y la autenticación en estos puntos finales vulnerables y cuando los usuarios cambien entre canales o interfaces. SSL y TLS ayudan a cifrar las comunicaciones de la API, pero los atacantes pueden eludir dicha protección de transporte.

Mitigación del riesgo de deanonimización y correlación

Muchas implementaciones de API son ecosistemas expansivos o cadenas de suministro digitales, donde una organización se integra con cualquier número de APIs y servicios de terceros para facilitar sus operaciones. Este fue el caso de esta organización financiera en particular, ya que uno de los puntos finales de la API de terceros devolvía identificadores de cuenta que resultaron útiles para perpetuar el ataque de autorización. Ese punto final de la API de terceros tampoco requería autenticación, y mucho menos autorización.

Aplicar las siguientes contramedidas para mitigar las debilidades de deanonimización y correlación identificadas por Salt Labs:

1. Autentique siempre y autorice de forma continua — Cualquier API que proporcione datos confidenciales debe requerir autenticación y validar continuamente si el usuario autenticado tiene autorización para acceder al recurso solicitado.
2. Utilice límites de tasa — Aplique límites de tasa en los puntos finales de la API para evitar formas básicas de enumeración y mitigar el riesgo de extracción masiva de datos. Tenga en cuenta que los atacantes también regularán sus tasas de solicitud para evadir la detección o activar un límite de tasa.
3. Utilice suficiente entropía — Asegúrese de que todos los identificadores sean lo suficientemente largos, complejos y aleatorios para limitar la eficacia de las técnicas de enumeración y ataques de fuerza bruta. Esta contramedida también puede ayudar a mantener la seudonimización al dificultar que los atacantes correlacionen cuentas y datos.
4. Evite el uso de identificadores estáticos como factor de autenticación — Los identificadores de registro deben ser lo suficientemente complejos y aleatorios. Además, si dichos identificadores se utilizan como factor de autenticación, deben ser dinámicos y tener fecha de caducidad. Con suficiente tiempo y dependiendo de las contramedidas de limitación de tasa, los atacantes pueden aplicar fuerza bruta a estos valores utilizados en las llamadas a la API. Este tipo de vulnerabilidad de API es similar a depender de las claves de API como único medio de autenticación para quienes llaman a la API. Los atacantes pueden recopilar o aplicar fuerza bruta a dichos datos, y lo harán.
5. Evite exponer demasiados datos en las respuestas — No envíe a los clientes datos que no sean necesarios para completar una función determinada. Tenga en cuenta también cualquier normativa que afecte a la transmisión y retención de datos confidenciales, especialmente en lo que respecta a la privacidad.
6. Valide la seguridad de los servicios de terceros siempre que sea posible — Los socios y proveedores también deben ofrecer un nivel de garantía con respecto a la seguridad de la API, la seguridad de los datos y la privacidad del usuario. Algunos elementos de seguridad de terceros pueden ser validados por la organización principal, como verificar que los puntos finales de la API requieran TLS y autenticación. Es posible que también deba solicitar una certificación a los proveedores, ya que no todo el código o la configuración serán visibles para la organización principal.

Lecciones aprendidas

Los tres problemas principales dentro de los 10 riesgos de seguridad de API de OWASP estaban presentes en esta arquitectura de aplicación: autorización rota, autenticación rota y exposición excesiva de datos. La organización utilizaba tecnología más reciente en forma de GraphQL, lo que aporta una mayor complejidad y un mayor riesgo de problemas de autorización. GraphQL está ganando adopción como facilitador del patrón de diseño de back-end para front-ends (BFF). Muchas organizaciones están impulsando activamente iniciativas de GraphQL donde necesitan proporcionar una serie de servicios a grandes bases de usuarios, donde incluso la más mínima latencia potencial para sistemas front-end como aplicaciones móviles es motivo de preocupación. Sin embargo, los profesionales deben ser conscientes de que las implementaciones de GraphQL son susceptibles a muchos de los mismos patrones de ataque de API que REST. Los riesgos de seguridad potenciales también pueden verse agravados con GraphQL, particularmente con ataques de denegación de servicio (DoS) a nivel de aplicación y fallos de autorización.

Los atacantes utilizan técnicas que funcionan universalmente tanto para GraphQL como para las API REST. Una de las mejores características de GraphQL, la capacidad de consolidar consultas y puntos finales, también eleva el riesgo de seguridad. Implementar una autorización adecuada se convierte en una tarea compleja al tener en cuenta todas las formas en que un front-end determinado podría utilizar una API de GraphQL, que a su vez llama a otras API de back-end. GraphQL conlleva otros riesgos de seguridad potenciales que las organizaciones deben tener en cuenta a medida que adoptan esta tecnología más reciente. La seguridad por oscuridad nunca es una estrategia sólida. Las organizaciones deben operar con la mentalidad de que los atacantes realizarán ingeniería inversa regularmente en las aplicaciones y llamadas a la API, lo que incluye todas las formas de binarios de aplicaciones móviles y protocolos de API.

Un tema recurrente dentro de la seguridad de las API es que la arquitectura importa. Este principio es válido para sus propios diseños de API, lo que busca en las soluciones y cómo aborda la estrategia de seguridad. Las organizaciones a menudo dedican mucha mano de obra a realizar pruebas exhaustivas, a veces automáticamente como parte de las canalizaciones de compilación, pero siempre con el objetivo de intentar identificar tantos problemas a nivel de código y configuraciones incorrectas como sea posible antes del lanzamiento a producción. Desafortunadamente, probar todos los flujos de aplicaciones y secuencias de llamadas a la API es más fácil de decir que de hacer con las herramientas de prueba de seguridad tradicionales. Además, escanear el código antes de su lanzamiento a producción tiene sus límites; de hecho, la mayoría de los casos de lógica de negocio explotable solo pueden encontrarse analizando comportamientos en tiempo de ejecución. El problema solo empeora con la subcontratación del desarrollo y las operaciones. Una aplicación totalmente integrada y todos sus servicios son una compleja telaraña de servicios internos y externos, así como conexiones de socios que pueden describirse mejor como una cadena de suministro digital.

Salt Labs ha detallado las vulnerabilidades de GraphQL, los pasos que podría seguir un atacante y las acciones preventivas que las organizaciones pueden tomar para mitigar este tipo de ataques. Es fundamental que cualquier API que proporcione datos confidenciales, independientemente del protocolo, requiera autenticación y autorización. El control de acceso y el monitoreo de la actividad deben ser continuos durante todas las sesiones para garantizar que quienes llaman a la API no soliciten datos o funcionalidades para los que no están autorizados. Este enfoque es fundamental para la seguridad de las API, así como para otros principios de seguridad, incluidos el privilegio mínimo y la arquitectura de confianza cero.

Salt Labs publica investigaciones sobre amenazas a las API y recomendaciones de mitigación para ayudar a crear conciencia en el espacio de la seguridad de las API y educar a los profesionales. Todas las organizaciones están creando o integrando API en alguna capacidad. Muchas también trabajan con socios y proveedores para impulsar sus negocios y brindar servicios a los clientes. Todas las organizaciones pueden beneficiarse de un enfoque de ciclo de vida completo para la seguridad de las API, y muchas deberían buscar herramientas de seguridad de API dedicadas para poder encontrar y abordar el conjunto completo de posibles problemas de seguridad de las API.

Si le interesa ver la plataforma de protección de API de Salt Security en acción, contáctenos para una demostración personalizada hoy mismo.

‍