0
0
In accordance with ethics of responsible disclosure, the vendor was informed but emails were left unreplied/ignored Timeline
- First email on 08 March 2016
- Second email on 14 March 2016
Prelude
In recent years we have seen an evolution of people lifestyle, and digital identity is becoming part of our real life with all connected risks.Our “digital native” children have access to networked digital technologies, playing with tables, smartphones or smart toys; We must ensure that this new kind of “game” must be safe in the same way as we make for physical one. The research presented here is a privacy analysis of the app Magic Kinder and takes its inspiration from a niece who asked to her dear uncle to install this app on her smartphone.
The app
The Magic Kinder app is designed for children to involve them in educational games; this app allows messages and media content sharing between family and friends, according to the app description: “The Magic Kinder app will help you and your child always stay in touch with the people you love through the Family Diary.In a few steps you can create your private community with relatives and trusted friends and start sharing emotions, exchanging voice messages, photos and creations whilst **staying connected in a safe and protected environment**”
The sharing function is called FamilyDiary, this function should be confined only to family members and friends, the target of our research is to prove the complete absence of restriction mechanisms for content sharing, this could allow privacy violation of any children, making it possible for a malicious user to read the chat of the children, send them messages, photographs and videos or change user profile info such as date of birth and gender.
Analysis
Using an http proxy we intercepted the traffic between the app and the backend to take a close look to the api calls to familyDiary, the following interaction between the client app and backend have been analyzed:
Send a message
When a client try to send e message, make a POST request to “/familyDiary/share”, in that request we can observe a JSON with 3 fields:
- users
- text or content_id
- post_type
The users field contain an array of recipients; each recipient has 2 parameter: user_id and user_type
the second field of JSON contains the payload of the message:
- Text message has the parameter “text” followed by its value
- Multimedia message has the parameter “content_id” followed by id of the uploaded multimedia content
The value of post_type field is 1 for text message or 3 for images
Our analysis demostrate that tampering user_id parameter in the following POST request it is possible to send a message or an image to any other user_id and not only to those associated with the actual account
Read the familyDiary status
When the client app try to read the status of familiDiary make a GET request to api “familiDiary” with the following parameters:
- child_id
- enddate
- startdate
The response is JSON containing all the data from the target child_id familyDiary, in this case, tampering child_id parameter we can retrieve familyDiary data from all others child_ids
Update user data
When the client tries to update child_id date of birth and gender make a POST request to “user/avatar/update/XXXXXX” (where XXXXXX is the user_id/child_id), in the request we can observe a JSON with these fields:
- date_of_birth
- gender
Tampering the user_id/child_id in the url, it is possible to change the “date_of_birth” and the “gender” of any other user.
Last but not least, all communications are transmitted in clear text; no encryption is involved across the whole app. Happy Easter to everybody!:)
(Massimo Bozza)
Recent Comments