Header Ads Widget

Ticker

6/recent/ticker-posts

5 importantes violaciones de datos de API modernas (y lo que podemos aprender de ellas)

 




El mundo está cada vez más conectado por el momento. Hace veinte años, la idea de tener un cepillo de dientes conectado a Internet era tan extraña como la idea de tener Internet hace cien años. El desarrollo avanza rápidamente y los nuevos inventos cambian continuamente el rostro de nuestras interacciones en la era digital.

Con ese marco de referencia, es impactante ver que algunos desarrolladores no se toman en serio la seguridad de la API . Las violaciones de datos de API a menudo ocurren debido a terceros. Sin embargo, en muchos casos, las simples fallas en tratar la seguridad de la API con respeto llevaron a algunas violaciones de datos importantes que afectaron a muchos millones de usuarios.

Hoy, veremos cinco importantes violaciones de datos de API modernas y veremos qué lecciones podemos extraer de ellas.


1 - Venmo

La API de Venmo permitió a uno raspar millones de transacciones que los usuarios no sabían que eran públicas.

Decir que Venmo tuvo una violación de datos es algo engañoso, ya que Venmo es "social" por diseño. La plataforma de pago comparte todas las descripciones de las transacciones (que suelen ser divertidas y están llenas de emojis) de forma predeterminada, lo que requiere que los usuarios opten por mantener estos datos privados. La “violación” en este caso provino del hecho de que la API que sirvió a estas descripciones no estaba protegida, lo que permitió la eliminación masiva de 200 millones de transacciones .

Este raspado incluía datos como los nombres completos de los remitentes, las notas adjuntas a cada transacción, el valor de la transacción y más. En particular, muchas de las descripciones de las transacciones de Venmo describían de manera transparente actividades privadas, lo que sugiere que muchos usuarios no estaban al tanto de la política pública de Venmo (o, al menos, no sabían hasta qué punto se podía compartir esta información). Si bien Venmo (y muchos de sus defensores) respondieron que la API funcionó como estaba previsto, esta no es la mejor defensa: una seguridad deficiente por diseño sigue siendo una seguridad deficiente.

Lección aprendida

El problema con este tipo de violación de datos no son los datos en sí, sino los datos en conjunto. Los proveedores tienden a pensar que sus conjuntos de datos limitados tienen un riesgo limitado de dañar a los usuarios de manera significativa. Debido a esto, normalmente no tratan las fuentes de datos tan importantes como lo son.

Por ejemplo, si bien un lote de transacciones relacionadas con entradas para conciertos o cenas compartidas de un remitente puede parecer inofensivo, los datos se vuelven más impactantes cuando se combinan con las transacciones del mismo remitente relacionadas con opciones médicas o actividades protegidas. Venmo se ha utilizado en las empresas principales, sí. Aún así, también se ha utilizado en círculos de activistas: estos datos agregados no solo exponen los comportamientos de quienes realizan sus compras, sino que los malos actores también pueden usarlos (junto con otras fuentes públicas y no públicas) para rastrear usuarios y hábitos.

En total, si bien esto puede parecer una violación menor para algunos, muchos de sus usuarios lo consideraron una violación fundamental de la privacidad, la confianza y la seguridad ética.

Lea también: Su API es vulnerable si estos 4 riesgos no se mitigan

2 - Infracciones de Facebook

A lo largo de los años, Facebook ha tenido numerosas vulnerabilidades de API explotadas dentro de varios servicios.

Facebook es conocido por una variedad de cosas, una de las cuales es un historial irregular con seguridad.

En septiembre de 2018, los piratas informáticos utilizaron una vulnerabilidad en la API de desarrollador de Facebook para exponer a millones de usuarios. Los datos extraídos eran bastante completos y, en muchos casos, podían eludir la ofuscación intencionada y las opciones de privacidad que de otro modo protegerían la información. El problema en cuestión, que no se corrigió durante 20 meses, se debió a una función en la función "Ver como" en la API de desarrollador que permitía a los desarrolladores representar páginas como un usuario. Desafortunadamente, esta función también entregó el token de autenticación para ese usuario directamente al desarrollador.

Los problemas de la API de Facebook no terminaron ahí. En diciembre, una exposición de la API de fotos de Facebook expuso datos privados en una violación que afectó a hasta 6,8 millones de usuarios y 1,500 aplicaciones. La vulnerabilidad se debió a un error con el inicio de sesión de Facebook que permitió a los desarrolladores externos retener el acceso a las fotos compartidas con el servicio, lo que permitió que las aplicaciones mantuvieran el contenido después de que los usuarios exigieran que este acceso terminara y se eliminaran los datos.

Otra violación masiva de datos no se pudo identificar en la API de Facebook per se: más de 267 millones de ID de Facebook, números de teléfono y nombres se registraron en una base de datos de acceso público que fue descubierta por el investigador de seguridad Bob Diachenko. Lo más probable es que la base de datos provenga de una de dos fuentes: o los perfiles de Facebook se rasparon ilegalmente o la API de Facebook tenía otro agujero que permitía este tipo de actividad. Si bien no se ha confirmado de ninguna manera, la sugerencia de algunos de los afectados de que ya habían bloqueado su configuración de privacidad antes de la filtración sugiere que esto no fue el resultado de la compilación de información de acceso público, sino que fue el resultado de una filtración de API.

Lecciones aprendidas

Los problemas de Facebook ejemplifican lo que sucede cuando intentas crear un monolito ágil con la cantidad de datos que tiene. Cuando cada bit de código es su propio módulo con su propio equipo, obtienes una gran cantidad de flexibilidad, escalabilidad y eficiencia, pero también introduces la posibilidad de conexiones fallidas en términos de comunicación de equipo y gestión de proyectos.

Si bien no se ha confirmado que estas brechas de API sean el resultado de una gestión interna fallida, el hecho de que hayan ocurrido en clústeres y funciones de servicios aparentemente dispares sugiere que una combinación de código heredado, simplificación excesiva y división de equipos, e ineficaz las auditorías fueron la causa principal de estas infracciones.

También debe tenerse en cuenta que Facebook ha diseñado gran parte de su conjunto de datos para que se pueda minar en su forma principal. Las aplicaciones de Facebook tienen altos niveles de acceso a perfiles que “optan” a su uso (incluso si las aplicaciones en cuestión pueden no revelar sus usos secretos de estos datos). Cambridge Analytica fue un ejemplo de alto perfil de esto en 2016, donde una aplicación conocida como "This Is Your Digital Life" recopiló datos de millones de usuarios; se le permitió hacerlo debido a una falla en el diseño de la estructura de datos de Facebook que permitió la aplicación no solo para capturar datos de aquellos que habían optado por la recopilación, sino también los datos de los amigos de aquellos que habían optado por hacerlo.

La lección aquí es simple: cuando su código es masivo y en el límite inmanejable, necesita repensar fundamentalmente cómo maneja los datos, la estructura del código e incluso la alineación interna del equipo.

Audite la seguridad de su API aquí: Presentación del modelo de madurez de seguridad de API

3 - Exposición de la base de datos corporativa de USPS

Una infracción importante de la API implicó la inseguridad con el Sistema de visibilidad informado de USPS en 2018.

En 2018, se publicó un problema con la API web para USPS. La debilidad, que permitió a un atacante consultar el sitio web de USPS y extraer una base de datos de más de 60 millones de usuarios corporativos , direcciones de correo electrónico, números de cuenta, direcciones, datos de campañas y números de teléfono, se informó originalmente un año antes, pero no se resolvió durante bastante tiempo. largo tiempo.

El problema subyacente era, como ocurre en muchas infracciones, debido a un problema de autenticación: este problema permitía el acceso inadecuado a un servicio API llamado "Visibilidad informada", que fue diseñado para entregar datos de seguimiento en tiempo real para operaciones de envío a gran escala. Este sistema de seguimiento estaba vinculado a la API web de tal manera que un usuario podía modificar los parámetros de búsqueda comodín a un valor arbitrario sin privilegios escalados; en esencia, mientras que el proceso de encontrar un objetivo específico era difícil, la exposición masiva a muchos, muchos usuarios a la vez fue muy fácil de hacer. Dado que no existía un sistema anti-raspado robusto (por ejemplo, limitación de velocidad), esta exposición masiva solo se vio agravada por el acceso automatizado y sin restricciones disponible.

Lección aprendida

El ejemplo de USPS es uno que aparece una y otra vez en diferentes brechas: facilidad de acceso versus seguridad. Demasiados proveedores están dispuestos a otorgar poderes extremos a un servicio o función específicos, y al no asegurar cada permutación del flujo de interacción de ese servicio o función, este poder puede aprovecharse para causar daño.

Los propietarios de API deben desarrollar cada aspecto de su API con el concepto de que algún día, es muy probable que se abuse de ella, no solo internamente, sino por fuerzas externas. Si la codificación se realiza bajo esta suposición, entonces se pueden tomar las medidas adecuadas para mitigar daños futuros, o al menos poner en marcha sistemas que detecten este mal uso.


4 - Federación de Industrias del Estado de São Paulo

En 2018, la base de datos FIESP de Brasil expuso millones de registros de empresas.

En 2018, el organismo industrial profesional más grande de Brasil, la FIESP, fue acusado de exponer millones de puntos de datos para más de 130.000 empresas en tres bases de datos. Los registros incluían nombres, números de identificación y de seguridad social, direcciones, correos electrónicos y más, y la mayor de las tres fuentes contenía 34,8 millones de entradas.

Si bien la infracción fue claramente el resultado de algún tipo de falla en la API o la base de datos, no está claro cuáles fueron en realidad los mecanismos específicos responsables de la exposición; esto se debe en gran parte al hecho de que la organización se negó a aceptar la infracción y ha declarado que creen que no se ha expuesto ninguna "información personal de la base de datos".

Lección aprendida

Si bien este es un caso de exposición de datos bastante corto y seco, la verdadera lección aprendida aquí se reduce a la responsabilidad. En este caso, la FIESP se negó a responsabilizarse por la violación de datos, llegando a decir que la violación ni siquiera ocurrió. Algunas cosas surgen de tal falta de divulgación y responsabilidad.

En primer lugar, la investigación se vuelve extremadamente difícil. Los investigadores de seguridad solo pueden ver una cantidad limitada de datos y, en muchos casos, solo saben tanto como el lego promedio que también puede acceder a los datos. Se intentó la divulgación responsable en el caso de la FIESP, pero sin la parte responsable dispuesta a coordinar esfuerzos o aceptar la realidad de una infracción, dicha divulgación no ofrece ninguna herramienta para la investigación mutua o la ayuda general. Los investigadores solo pueden adivinar y estimar, esencialmente quedando excluidos del ecosistema que están tratando de proteger.

En segundo lugar, no aceptar una infracción significa que los afectados no pueden ser advertidos ni preparados adecuadamente. Debido a esto, las malas prácticas de seguridad, como las contraseñas reutilizadas o la falta de autenticación de dos factores (que tiene sus propios problemas) amplifican el impacto de la filtración de datos a través de la propagación. Si se advierte a los usuarios, como mínimo, se vuelven más conscientes de los peligros que acechan en sus cuentas; si no se les advierte, todo sigue igual que antes.


5 - JustDial

Las 100 millones de cuentas de Justdial se expusieron a través de puntos finales de API de acceso público en 2019.

JustDial, el motor de búsqueda local y el mercado social más grande de la India, fue acusado en 2019 de filtrar toda su base de datos de información de clientes: los puntos de datos de sus más de 100 millones de usuarios incluían nombres, correos electrónicos, números de teléfonos móviles, fecha de nacimiento, género, ocupación. , fotos y más. Básicamente, se filtró cualquier dato proporcionado a través del uso de su sitio web, su aplicación, su sistema de atención al cliente, todo.

¿Cómo pasó esto? Resulta que los puntos finales de la API de JustDial eran de acceso público, existiendo básicamente sin autenticación, autorización o cifrado. El acceso a la base de datos se proporcionó a través de API sin restricciones desde al menos 2015, lo que permite que cualquiera acceda a la base de datos y extraiga los datos que desee solicitar.

Durante las pruebas, también se descubrió que, a diferencia de otras violaciones de datos de alto perfil, estos datos no provenían de un servidor limitado o de desarrollo; las pruebas mostraron de manera concluyente que los datos expuestos se estaban recuperando en tiempo real, lo que indica que el acceso fue a un servidor de producción en vivo real. Pruebas adicionales en la plataforma JustDial mostraron que la API principal no era la única expuesta; se descubrió que las API adicionales, como un sistema de solicitud OPT, también no estaban seguras.

Lecciones aprendidas

JustDial es un gran ejemplo de algo técnico que se pasa por alto en la lógica empresarial. El concepto de JustDial es sólido y su código hace lo que se supone que debe hacer; a pesar de esto, su falla en asegurar sus API expuso una cantidad increíble de información. La extraña dicotomía entre una empresa profesional y un error francamente amateur (no asegurar su servidor de producción con autenticación o autorización) es común.

Por supuesto, esto podría rectificarse fácilmente: las auditorías simples deberían ser suficientes para investigar posibles exposiciones de datos y asegurarse de que estén conectadas antes de que se conviertan en un problema. La mayor preocupación aquí es si se trata de un descuido único o el primero expuesto en una serie de descuidos. Se podría argumentar que no hacer algo simple, como asegurar un servidor de producción, podría indicar otros problemas internos, tanto de código como de otro tipo; esto queda por validar en los próximos años.


Conclusión

La conclusión definitiva de todo esto es simplemente que la seguridad debe ser de suma importancia . Desarrollar con la seguridad primero en mente debería mitigar muchos de estos problemas; de hecho, no codificar con la seguridad primero en mente es un problema importante tanto en el espacio de API como en el espacio tecnológico general, y es uno que debe solucionarse con urgencia. Con gran parte del mundo conectándose con API, Internet de las cosas desarrollando conexiones entre cosas tan diversas como un secador de pelo y un marcapasos, y cada vez se crean más puntos de datos a medida que nos movemos por el mundo, la falta de seguridad no solo es inaceptable, en algunas partes. del mundo, como la UE, es criminal.

¿Cuáles cree que son algunas de las infracciones de API de alto perfil en los últimos años? ¿Perdimos alguno de los principales? ¿Cuál es su solución para el acto de equilibrio entre la necesidad de acceso y la inseguridad de dicho acceso? ¡Háganos saber en los comentarios a continuación!

Publicar un comentario

0 Comentarios