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

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

Thibeault Chenu
5 min readMar 21, 2019

--

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 ā€œidā€ despite 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

June 30, 2019: the flaw still not fixed.

--

--