Cómo y porqué proteger las APIs públicas

Sandy Carielli y el equipo de Forrester han publicado su informe "The State Of Application Security, 2021" (pago). Se puede encontrar un resumen bastante extenso en el blog de Ayala Goldstein. Ahora vamos que discutir los cientos de millones de perfiles de usuario de Facebook y Clubhouse que se recolectaron mediante scrapping de sus respectivas APIs públicas.

Regalo Building an Identity Architecture

Lecciones aprendidas de Facebook y sus APIs

La mayor noticia de filtración de datos reciente es la enorme base de datos de 530 millones de usuarios de Facebook. Facebook ha hecho una declaración oficial sobre el incidente, considerándola de "bajo riesgo" y restándole importancia porque "los datos ya fueron descargados" en 2019 utilizando las API de Facebook, en lugar de obtenerse a través de algún tipo de acceso a la base de datos u otro truco directo".

La vulnerabilidad (sí, vulnerabilidad) que explotaron los atacantes estaba en la API que Facebook creó para descubrir amigos en función de los contactos de su teléfono. Facebook quería facilitar a los usuarios la búsqueda de sus amigos en la red social, por lo que la aplicación utilizaba una API para cargar los contactos de los teléfonos de los usuarios a Facebook y buscar los perfiles de los usuarios que coinciden con los números de teléfono cargados.

Suena agradable y fácil de usar, pero como suele suceder, facilitar las cosas también puede hacerlas menos seguras. Los atacantes aprovecharon la función generando enormes "guías telefónicas" y enviándolas a la API. Después de todo, los números de teléfono son solo una secuencia de números que siguen una sintaxis establecida: código de país, código de área y un número de N dígitos. Por lo tanto, iterar a través de ellos no es difícil.

Esto permitió descargar la base de datos del usuario y recopilar un enorme conjunto de datos personales, definitivamente algo que no debería haber sucedido y probablemente debería haberse previsto. Después de todo, los atacantes son un grupo muy ingenioso. Ahora, con la publicación del conjunto de datos extraído, la información sobre nombres, ID de Facebook, números de teléfono y direcciones de correo electrónico de 530 millones de usuarios (incluido el propio Mark Zuckerberg) ha terminado en el ámbito público.

Naturalmente, con un caso de alto perfil como este, muchos investigadores han estado investigando los detalles. Por ejemplo, este hilo de Ashkan Soltani.

Intentemos resumir el impacto:

• La postura de Facebook de que si se utilizó la API para recopilar los datos, no es un hack tiene poco sentido. Las API son solo otro vector de ataque, y de hecho uno de los principales vectores de ataque en estos días, utilizado por actores maliciosos. Un truco es un truco, independientemente del vector de ataque empleado.
• Aunque algunos de los datos son públicos (como nombres), conjuntos de datos tan grandes de esta información pública combinados con otros detalles se pueden utilizar para varios ataques de phishing y de ingeniería social. Ha habido informes sobre otros conjuntos de datos que también incluyen los "Me gusta" de páginas de los usuarios. Esto agrava considerablemente la situación: cuantos más detalles tengan los estafadores a su disposición, más convincentes serán las estafas.
• La API también expuso el número de teléfono, incluso si estaba configurado para que no se compartiera, o si solo se usaba para la autenticación de múltiples factores. ¡Esta es una gran violación de la privacidad y la confianza del usuario!
• Los informes indican que Facebook había estado recibiendo informes sobre la vulnerabilidad durante años antes de solucionarla finalmente en 2019.
• Las API son una de las principales superficies de ataque actuales. Incluso la información pública puede volverse peligrosa una vez que esté disponible como un gran conjunto de datos. La información es poder, después de todo: más información, más poder. No se debe permitir que caiga en manos equivocadas por negligencia. Las API no deben brindar acceso a más datos de los que se permite.
• Las operaciones masivas son extremadamente peligrosas. Siempre se debe limitar no solo la velocidad a las que se pueden invocar las API, sino también la cantidad de datos que pueden devolver. Se debe utilizar Rate-Limit.
• Las API deben estar protegidas por diseño. Solucionar problemas solo después de haber sido explotados puede llegar desastrosamente tarde.
• Monitorear, alertar y reaccionar rápidamente a los informes de vulnerabilidad son buenas medidas de mitigación adicionales.

Lecciones aprendidas de Clubhouse y sus APIs

Al igual que con Facebook, también hay un buen análisis de la historia de Clubhouse. Por ejemplo, lea este hilo de Henk Van Ess.

Como acabamos de comentar, el hecho de que se hayan utilizado las API para recuperar la información no cambia el impacto (y la responsabilidad del proveedor) de ninguna manera. Las consecuencias son similares al caso de Facebook:

• Ls grandes conjuntos de datos de usuarios son problemáticos. Permiten el phishing y otros ataques de ingeniería social, incluso si los datos ya han estado disponibles en páginas de usuarios individuales.
• Los datos contienen enlaces a perfiles de usuario en otras redes sociales. Para algunos usuarios, esto significa que sus cuentas privadas de Twitter e Instagram se des-anonimizaron.
• Clubhouse facilitó la recuperación de datos porque los ID de usuario son números enteros secuenciales. Por lo tanto, las API se pueden utilizar para recuperar información sobre el usuario 1, 2, 3, ..., etc. . Esto hace que la enumeración de toda la base de usuarios sea un juego de niños.

Las lecciones aprendidas son más o menos iguales o similares a las de Facebook, con una extra: no se deben utilizar ID secuenciales, nunca. En su lugar, un uso simple de GUID hace que todo sea más difícil para los atacantes. Y, nunca, nunca permita que los atacantes iteren los registros de usuarios o recursos.

Fuente: APISecurity