Grindr 2.2.1 Insufficient Validation

Type packetstorm
Reporter Benjamin Kunz Mejri
Modified 2015-05-04T00:00:00


                                            `Document Title:  
Grindr v2.1.1 iOS - (eMail) Session Vulnerability  
References (Source):  
Release Date:  
Vulnerability Laboratory ID (VL-ID):  
Common Vulnerability Scoring System:  
Product & Service Introduction:  
Grindr, which first launched in 2009, has exploded into the largest and most popular all-male location-based social network out there.   
With more than 5 million guys in 192 countries around the world -- and approximately 10,000 more new users downloading the app   
every day -- you’ll always find a new date, buddy, or friend on Grindr. Grindr is a simple app that uses your mobile device’s   
location-based services to show you the guys closest to you who are also on Grindr. How much of your info they see is   
entirely your call.  
(Copy of the Vendor Homepage: )  
Abstract Advisory Information:  
The Vulnerbaility Laboratory Research Team discovered a session vulnerability and a validation issue in the Grindr v2.1.1 iOS mobile app api & connected account system.  
Vulnerability Disclosure Timeline:  
2015-01-23: Researcher Notification & Coordination (Benjamin Kunz Mejri - Evolution Security)  
2015-01-23: Vendor Notification (Grinder - Bug Bounty Program)  
2015-02-01: Vendor Response/Feedback (Grinder - Bug Bounty Program)  
2015-04-01: Vendor Fix/Patch (Grindr Developer Team - Reward: x & Manager: x)  
2015-05-04: Public Disclosure (Vulnerability Laboratory)  
Discovery Status:  
Affected Product(s):  
Grindr LLC  
Product: Grinder - iOS Mobile Web Application (API) 2.2.1  
Exploitation Technique:  
Severity Level:  
Technical Details & Description:  
By usage of the mobile iOS app we was able to figure out the following vulnerability. The vulnerability is located in the email and old_email values of the service. The encoding and the input validation allows the usage of special chars in the client-side (GET) url request which impact the first risk.   
The second risk is that the request can be intercepted by an attacker to manipulate the session values only with an existing profileId. The profile id and the email of an user can be captured by usage of the regular frontend service. The attacker includes to the request an existing session id and uses the old email profile values to compromise another users account. For example an attacker can use the profile id of another users account to change the email to his own by usage of the vulnerable values. Attacker can also use empty string and other text formats to confuse the validation on email changes to compromise service accounts. In the referer request that opens the old_email the attacker can change the full request. By exchanging the old refer in the live request the attacker is able to reset another account with new values. Not only the validation itself is broken, the login mechism loads any string or payload that is injected to the admin panel. The season for this little connected issue is that there is no input check, input restriction and the validation procedure is missing. Even if no @ for example is in the value the context loads which is a kind of design issue in the same location.  
Request Method(s):  
[+] GET  
Vulnerable Module(s):  
[+] email > edit  
Vulnerable Parameter(s):  
[+] old_email > email  
Proof of Concept (PoC):  
The session data and validation vulnerability can be exploited by remote attackers with privileged application user account and low user intaction.  
For security demonstration or to reproduce the security vulnerability follow the provided information and steps below to continue.  
Manual steps to reproduce the security vulnerability ...  
1. Request  
2. Open the connected module after the first request  
3. Change the profileID and use the same email  
4. Successful reproduce of the vulnerability!  
Extended manual steps to reproduce ... (device)  
The intercepting of the session from the device to the website needs to be done manually.  
I tried it again and it just works well the manual way.  
1. Request  
2. Open the connected module after the first request  
3. Change the profileID and use the same email  
4. Successful reproduce of the vulnerability!  
Note: Perform two requests and manipulate the https with the values of your test accounts. Then start a session tamper to intercept the value in the live request   
by the ios device side to the account system. (install a debugging proxy and point your iPhone - http protocol) Then you do not get any error and be successful.  
Solution - Fix & Patch:  
1. Disallow to load the url value plain in the old_email parameter  
2. Approve the profileID by a valid request that is connected with a unqiue cookie/token  
Note: If the context changes after a manipulation it is required that the session expires on referer changes  
3. Same must be done in die edit?email to ensure that the followup request does not bypass the internal auth liek in my case.  
Security Risk:  
The security risk of the session vulnerability and validation issue is estimated as high. (CVSS 6.8)  
Credits & Authors:  
Vulnerability Laboratory [Research Team] - Benjamin Kunz Mejri ( []  
Disclaimer & Information:  
The information provided in this advisory is provided as it is without any warranty. Vulnerability Lab disclaims all warranties, either expressed   
or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability-Lab or its suppliers are not liable   
in any case of damage, including direct, indirect, incidental, consequential loss of business profits or special damages, even if Vulnerability-Lab   
or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for   
consequential or incidental damages so the foregoing limitation may not apply. We do not approve or encourage anybody to break any vendor licenses,   
policies, deface websites, hack into databases or trade with fraud/stolen material.  
Domains: - -  
Contact: - -  
Section: - -  
Social:!/vuln_lab - -  
Feeds: - -  
Programs: - -  
Any modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory. Permission to   
electronically redistribute this alert in its unmodified form is granted. All other rights, including the use of other media, are reserved by   
Vulnerability-Lab Research Team or its suppliers. All pictures, texts, advisories, source code, videos and other information on this website   
is trademark of vulnerability-lab team & the specific authors or managers. To record, list (feed), modify, use or edit our material contact   
( or to get a permission.  
Copyright © 2015 | Vulnerability Laboratory - [Evolution Security GmbH]™