(source : https://unsplash.com/photos/N6e9cnOMXEk)

Find My Contacts (or personal data of 650,000 people)

This is my third write-up, feel free to give me feedback on Twitter (@thibeault_chenu) or in the comments to help me. 🙂

Introduction

I recently analyzed mobile applications that allow you to find the contacts saved on your phone on a map (if they have installed the application obviously). 🗺️

To analyze its applications, I prefer to use my personal phone, i.e. an iPhone. It’s easier for me and it allows me to test it quickly as soon as I have to.

When I talk about analysis, in the case of this application we will talk about dynamic analysis.

That is to say, I will analyze the application’s network exchanges. Either HTTP(s), WS etc. requests. I sometimes do static analysis, i.e. I decompile the application and look for interesting elements (with APKTool and JADX).

What is interesting with the traffic that we will be able to capture and analyze is the exchange, especially with the APIs of the application’s publishing company.

These exchanges will allow to have an idea of the technical architecture of the APIs used (technologies, endpoints, parameters, authentication system) and this is what interests me personally because I am a web developer and not a specialized mobile developer, I prefer to leave this to my colleague Elliot Alderson. 😜

In this article we will focus on a Spanish application that I will anonymize at the developer’s request. This application is available on the App Store and Play Store.

Analyze the traffic with Charles Proxy

To analyze all HTTP requests, I use Charles Proxy in its mobile version. As I said, I identify “targets” previously on the App Store, I look briefly at the exchanges made and I select the application for a more advanced analysis.

The application is quite simple to use, just install an SSL certificate provided by Charles Proxy to analyze HTTPS requests and off you go.

Once I have used the application, I export all queries. Once exported they can be used on Charles Proxy’s desktop application but personally I prefer to use Postman or Burp Suite.

Play with endpoints

What seemed suspicious to me with this application was some endpoints in particular that used a parameter named “iddespite an authentication token present in the headers of the “Authorization: Bearer …” request.

In the best case, the authentication token makes it possible to identify the connected person and thus to know his unique identifier.

The same value appears especially when the application updates your position in the background (every 5 minutes by default) through an endpoint named backgroundPosition with the parameter “id_usuario”.

We can thus deduce that id = id_usuario = unique id identifying a user.

When I see this form of identifier I’m willing to bet that it’s a basic incremental identifier, it gives us an information: there have been at least 638,967 people since my registration date on this application.

Following this deduction and the fact that this identifier is sent to update data, it is possible that faults of the IDOR type are present and this is what I will demonstrate to you.

IDOR flaw

The most impactful would be to be able to read or modify another person’s data, i.e. their email address 📥, telephone number 📱or even their location 📍.

To do so, I will look for the endpoint that allows me to modify my personal information and try to modify the user ID parameter named id (a test account).

(so…?)
Response : “OK”

So I can take control of any account by modifying an incremental identifier, let’s move to the next endpoint.

I am now looking to retrieve the list of registered locations, this one is accessible via the historicalUsuario endpoint.

Guess the parameter necessary to execute this request? “id”. 🤫

(HTTP request to find all localizations of a user)
(HTTP response with list of all localizations of a user)

Above you will find first the request to obtain the history of locations and then the response.

First shocking point: the hash value of the password is visible and is MD5.

The second problem is that there is unnecessary personal information for what we are trying to do. Simply return the latitude and longitude to get a point on a 2D map, no need to mention the user’s email address, phone number etc.

Now let’s see if by changing the user ID we have another person’s data.

(request to get data of my test account)
(data of my test account)

As you can see, I have access to all the information of all users by modifying an increment identifier again. 🙄

Conclusion

In conclusion, it was possible to retrieive and takeover the personal data of 650,000 people, i. e :

  • E-mail address,
  • Telephone number,
  • Photo,
  • First and last name,
  • Latitude and longitude at several periods,
  • MD5 Password,
  • Etc.

Timeline :

March 20, 2019 : report sent to the developer
March 20, 2019: the developer answers me that he will fix the flaw the next day
March 21, 2019: the flaw is fixed