Mobile App Wall Of Shame: Trip38

Compared to Android users, iOS users tend to feel fairly safe from lurking threats. But, occasionally, that sense of security is tested. Zscaler ThreatLabZ recently came across an app that had a significant flaw, causing it to leak the personal information of iOS users. The details of the app are as follows: Name: Trip38 Travel Assistant – Free Platform: iOS Seller: Trip38 Technologies Private Limited Size: 25.7 MB Category: Travel Compatibility: Requires iOS 8.0 or later. Compatible with iPhone, iPad, and iPod touch. Languages: English, Simplified Chinese, Spanish Price: Free   Fig 1: Trip38 app on App Store Trip38 is a travel assistant app that allows users to plan and track their travel. It stores travel details, including flight times, origination and destination city/country, and accommodation information, such as hotel name, booking dates, etc. We discovered that this app was communicating with its server in an insecure manner.  The app contacted its server via API calls, and all details passed to the server were being sent in plain text, with plain-text responses from the server. Communicating in plain text makes it easy to carry out Man-In-The-Middle (MITM) and other attacks. Login credentials may be intercepted and private information, including the user’s location and travel plans, may be exposed. This vulnerability is worse when you consider that the app is likely to be used by travelers at hotels, coffee shops, airport terminals, and similar locations that offer free Wi-Fi services, where the chances of eavesdropping are high.  Let’s look at the app’s functions and the data being leaked.  As soon as a user installs and uses the app for the first time, it asks for the user’s location. It was strange to see a second pop-up asking “Allow” for location access even when the app is not in use. The screenshot below shows both pop-ups:  Fig 2: Location access   The user may allow or disallow this feature, but in the travel category, it’s likely that users will allow location access to the app. After this, the user can either log in or register. Being a new user to the app, we tried registering. As shown in screenshot below, it asks for Name, Email, and Password.  Fig 3: Sign up process   As soon as user signs up, all the information—name, email, password, and location details—is sent to the server in plain text as shown below:  Fig 4: Plain text username and password   Upon successful response from server, the app performs an automatic user login request. Again, the details are sent to the server in plain text, except that during signup, the request is sent to userSignup.php with doSignup as the action, and during the login action, the request is sent to doUserLogin to userLogin.php. Fig 5: Username and password leakage during auto-login   After auto-logging in the user, the app displays the following screen, where it asks to either add a trip or track a flight.  Fig 6: First screen after signup/login   If a user is already registered, the app requests a trip list and, again, the trip request and response are in plain text. In the below screenshot, the trip list is empty because we did not add a past trip. For registered users, the server would respond with a complete list of previous and upcoming trips.  Fig 7: Fetching trip list in plain text We found that Trip38 is also available on Android, and that version has the same flaws as the iOS version. The requests and responses shown above were the same on Android with only one difference. In the case of iOS, requests contained flag_ios valued as 1; for Android requests, flag_android was set to 1. The screenshot below shows the Google Play page. Fig 8: Trip38 app on Google Play    According to OWASP Mobile Top 10, we can mark the Trip38 vulnerability as M3-Insecure Communication and M4-Insecure Authentication.  Conclusion:  This is not first time ThreatLabZ has come across an app with flaws like those in Trip38. We blogged about a similar case where an iOS-based SMS app was leaking data. Due to the omnipresence nature of mobile devices and the millions of apps available for them, it has become critical to prevent data leakage at every step. App developers have a responsibility to use standard code security practices, and encryption is essential for keeping users’ data intact and safe from prying eyes.   Note: We contacted the developer of Trip38 about this issue and, as of this writing, we have not heard from them. We have also notified Google and Apple.

*** This is a Security Bloggers Network syndicated blog from Research Blog authored by [email protected]. Read the original post at: http://www.zscaler.com/blogs/research/mobile-app-wall-shame-trip38