Se dice que “la experiencia es la mejor maestra”. No digo que la experiencia sea necesariamente necesaria. Si observa detenidamente, estos cinco ataques mortales a API ofrecen lecciones que pueden ayudar a cualquier organización a proteger mejor sus API.
por favor.
Zendesk 2017
Escenario: La plataforma de emisión de tickets de Helpdesk, Zendesk, quedó expuesta a atacantes a través de una vulnerabilidad de inyección SQL en su punto final GraphQL. La segunda falla permite a un atacante “robar datos de cualquier tabla en el RDS de una cuenta Zendesk objetivo sin necesidad de SQLi”. La plataforma de seguridad Varonis informó del error a Zendesk y la empresa pudo reparar el daño en una semana. No se comprometió ningún dato confidencial, pero si la vulnerabilidad hubiera sido descubierta y explotada por actores malintencionados, los comentarios de los clientes, las conversaciones, las direcciones de correo electrónico y los tickets podrían haberse visto comprometidos.
Solución: GraphQL es susceptible a ataques de inyección por diversas razones. GraphQL introduce nuevos pasos de procesamiento: analizadores, puertas de enlace y solucionadores de subgrafos, cada uno de los cuales puede explotarse como vector de ataque. Además, varias llamadas API se traducen en una sola llamada, lo que podría provocar más daños por inyección de SQL en un solo ataque. La protección contra esto es básica: desinfecte la entrada de la base de datos, use argumentos almacenados o declaraciones preparadas que no puedan interpretarse como código y aplique el principio de privilegio mínimo en todos los clientes de la base de datos.
buzón 2022
Escenario: este notable ataque a la API comenzó como una estafa de phishing. En octubre de 2022, Dropbox fue atacado por un actor malicioso. Los atacantes comprometieron los repositorios de código fuente de GitHub y accedieron a “miles de nombres y direcciones de correo electrónico de empleados de Dropbox, clientes actuales y anteriores, clientes potenciales y proveedores”. Es de destacar que en este artículo los datos robados incluían varias claves API utilizadas por los desarrolladores de Dropbox.
Solución: Varias medidas podrían haber evitado esto, incluidas las precauciones básicas de MFA. En segundo lugar, debería haberse implementado una capacitación de concientización contra el phishing. Los piratas informáticos obtuvieron acceso haciendo que los desarrolladores hicieran clic en un enlace malicioso en un correo electrónico falso de CircleCI y se autenticaran en el sitio falso de CircleCI. Pero lo más importante de todo es cómo se almacenó finalmente la clave API. Por esta misma razón, es una buena práctica no codificar claves API u otras credenciales directamente en su código fuente. Para detectar tales instancias en su código fuente, utilice herramientas de análisis de código para encontrarlas.
Gorjeo 2022
Escenario: Este hackeo de API resultó en la filtración y venta en línea de información personal de millones de usuarios de Twitter. En uno de los mayores robos de API en años, los actores de amenazas explotaron las vulnerabilidades de la API de Twitter y manipularon las funciones de “descubrimiento” para obtener acceso a las identificaciones de Twitter de los usuarios con solo un correo electrónico y un número de teléfono. Al final, 5,4 millones de registros se vieron comprometidos, pero a este ataque de día cero le siguió otro ataque (que aprovechó la misma vulnerabilidad en una API diferente), lo que elevó el número total de registros a aproximadamente 7 millones. Twitter solucionó la vulnerabilidad seis meses después de que se descubriera por primera vez.
Solución: Resolver problemas sistémicos de API requiere una solución sistemática. Las organizaciones necesitan un programa de seguridad de API que busque periódicamente API vulnerables en tiempo real, incluidas aquellas que son de código abierto y están disponibles públicamente. En lugar de simplemente construir un firewall alrededor de las API, el siguiente paso es probar, validar y clasificar continuamente estas API en tiempo de ejecución para que las empresas puedan estar seguras de que sus versiones son seguras.
El futuro de la seguridad API
A medida que las API continúan creciendo, evolucionando y volviéndose más populares, los ataques a API también se expanden. Las técnicas simples “únicas” de los ataques SQL de Zendesk en 2017 han sido reemplazadas por exploits “más lentos” a más largo plazo. Las tecnologías tradicionales basadas en reglas y firmas no pueden detectar ataques que puedan explotar debilidades y realizar acciones maliciosas sofisticadas que pasan desapercibidas durante meses. Los atacantes tienen tiempo y van a esperar el gran partido.
¿Cuál es la solución? Además de mantener las mejores prácticas como las enumeradas anteriormente, el siguiente nivel de seguridad de API requiere implementar protecciones de tiempo de ejecución como:
Fuzzing para identificar código vulnerable. Registro y seguimiento para establecer líneas de base e identificar anomalías. API de intermediario con puertas de enlace API para una mayor visibilidad. Cifre los datos enviados por API para una defensa en capas. Externalizar el control de acceso y los almacenes de identidad. No utilice claves API para la autenticación.
Las empresas se beneficiaron rápidamente de la fiebre del oro de las API, pero la velocidad de adopción ha dejado atrás la seguridad de las API. Desde simples hazañas hasta tácticas de reconocimiento más sofisticadas, los atacantes no han dudado en llenar los vacíos. Al aprender de fallas pasadas de API y anticipar ataques futuros, puede escalar la seguridad de API para satisfacer las demandas de ese crecimiento.
Fuente: https://www.itsecurityguru.org/2024/03/11/what-we-learned-from-these-3-api-security-breaches/
