sábado, septiembre 12, 2015

Dorking & Pentesting con Tacyt: Las APIs de terceros

Otra de las fuentes de información que pueden ser más que útiles dentro de las apps que se suben a lo markets, son las credenciales que se utilizan para acceder a APIs de terceros. Es decir, cada vez que una app de un dispositivo móvil requiere los servicios de una API remota de pago - o que necesita autenticación - tiene que desarrollarse un modelo de autenticación seguro, y esto no siempre se consigue.

Figura 1: Dorking & Pentesting con Tacyt: Las APIs de Terceros

Ya en el pasado, con la publicación del estudio de Play Drone, vimos como muchas apps cuentan con Tokens de Acceso a servicios de terceros hardcodeados en las aplicaciones. De hecho, hay que evitar justo y buscar una alternativa que permita que la app pueda disfrutar de las funcionalidades de las API para hacer un mashup pero sin exponer las credenciales.

Figura 2: Tokens de Acceso descubiertos en apps de Google Play con Play Drone

Yo os dejé una idea de cómo se podría resolver esto en el artículo de "No pongas tus tokens OAuth en tus apps para Android". Además, debes tener en cuenta cuándo necesitas que una app haga algo en tu cuenta y cuando lo que se necesita es hacer algo en la cuenta de un usuario a través de la API, donde deberás hacer un proceso de autorización implícito, como vamos a ver más adelante.

Las API Keys y los accesos

Cuando el sitio en cuestión que ofrece los servicios a las apps remotamente lo hace vía una API Key, eso significa que el desarrollador está exponiendo un Token de Acceso en el código de la app para acceder a las funciones. Al final, esa API Key no deja de ser un Shared Secret, al igual que más o menos lo son las Application Passwords que se usan en sistemas de autenticación que cuenta con un 2FA. Si el API Key queda comprometida, el atacante podrá hacer uso de las funciones, pero nunca podrá poner en riesgo la cuenta. Es una situación de abuso que debe controlarse con otros sistemas de detección y respuesta.

Figura 3: API Key de un SDK hardcodeado en una app de Android

Las API Key, para nosotros, son un elemento de correlación más que nos ayuda a localizar relaciones entre apps en función de cuáles utilizan los mimos valores. Esto ayuda no solo a detectar identidades ocultas, sino también a saber si alguien está abusando del código legítimo de alguien.

Las APIs autenticadas

Por otro lado, si los accesos a las APIs de terceros hay que hacerlo mediante procesos de autenticación, entonces puede que sea más peligroso utilizarlas en apps, ya que obligará a los desarrolladores a exponer sus usuarios y contraseñas en el código. Este problema se produce habitualmente cuando una API está pensada para ser utilizada en entornos de servidor, como por ejemplo una aplicación web que tira de una API que está en otro servidor web.

Figura 4: Un acceso a los servicios de PathFinder hardcodeado en apps

Ahí, el el desarrollador no expone sus credenciales de acceso a la API porque se encuentran protegidas en el backend y solo debe asegurarse de que la conexión end-to-end vaya bien cifrada. Sin embargo, cuando una API para entornos web se usa en entornos móviles, las credenciales quedan expuestas y con ello puede que toda la cuenta. 

Figura 5: Otro acceso en otra app con credenciales de PathFinder

Buscando por cadenas en los enlaces de las apps como login.pass o user.password, es fácil localizar apps utilizando este tipo de APIs pensadas para entornos web. En este caso se puede ver, por ejemplo, URLs de las API de PathFinder en las que se introduce el usuario y la contraseña por parámetros.

Figura 6: Credenciales de acceso a Schenker en enlaces de la app

Esto pasa con muchas APIs de este tipo. Este es otro caso de una app que utiliza la API de Schenker para acceder a información que luego utiliza para su funcionalidad. Por supuesto, lo que deberían hacer los dueños de estas API es cambiar el modelo y permitir que los usuarios de sus API generen API Keys para sus apps asociadas a sus credenciales.

Los WebServices

A este tema ya le dediqué una entrada tiempo atrás. Se trata de apps que utilizan en el backend WebServices que le dan la funcionalidad al sistema. Estos pueden ser del mismo desarrollador o de un tercero. En cualquier caso, la exposición de un API vía llamadas a WebServices con toda la información pública permite que alguien pueda hacer uso de las llamadas para manipular todo el servicio.

Figura 7: Un WebService en el backend

En el ejemplo de arriba se puede ver un WebService descubierto por un enlace en una app que permite llamar a las funciones hasta de recuperar información de un usuario y obtener el hash de la password que está utilizando.

Los Client ID Secret

Cuando se trata de autorización de APIs de servicios de redes sociales como Twitter, Facebook o Instagram y se quiere que un usuario autorice a la app a hacer algo en las cuenta del usuario a través de la API de la red social pertinentente, se debe utilizar la autorización implicita - o client side -. Esto lo explican muy bien en la web de Instagram donde se deja claro que no se debe almacenar nunca el Client Secret en la app.

Figura 8: Autorización implícita en Client-Side

El Client Secret se utiliza cuando se hace uso de la autorización explícita, diseñada para entornos Server Side como servidores web. Es decir, lo mismo que os explicaba en el apartado de las APIs de terceros. Sin embargo, una búsqueda por la cadena de client_secret y se puede ver que hay miles de apps que los almacenan directamente en las URLs. El resto es negociar una autenticación manual del Access_Token de la cuenta y poder, por ejemplo, crear un servicio automático de followers de cualquiera de estas redes usando esos valores, o manipular la cuenta de otras formas como publicar posts virales para distribuir malware.

Figura 9: Tres enlaces extraídos de 3 apps de Android con
los valores de client_secret hardcodeados. Hay miles.

Por supuesto, si tienes una app de tu empresa que hace uso de estos servicios, revisa cómo se han configurado las conexiones. Un simple fallo en la implementación del sistema de autenticación y puedes generar un problema. En la siguiente parte vamos a entrar más aún en la parte de pentesting, así que espero que hayáis repasado vuestros conocimientos de SQL Injection, LDAP Injection y Command Injection.

Saludos Malignos!

***********************************************************************************
***********************************************************************************
a las

No hay comentarios:

Publicar un comentario