Despite the hiccup caused by the recent ban on cab aggregators, India’s cab-hiring app market continues to grow at breakneck speed. Ola Cabs is currently offering 60,000 cabs in 52 Indian cities and plans to touch 200 cities by end-2015.
Companies like Ola Cabs, Uber and TaxiForSure are growing at a breathtaking speed. But that’s not what we are talking about today. What is more important to us is how secure these applications should be so that people don’t misuse it.
At Appknox, we’ve built a cloud-based scanner that helps mobile app developers and businesses make their mobile applications more secure. We help detect security vulnerabilities in mobiles apps and also suggest ways in which developers can fix these issues.
Looking at the recent news of Ola we decided to put the Ola app ,available on the Google Play store, through our system to find out how secure it is.
Our engine reports that Ola Cabs app, which is available to download for consumers, is 42.86% unsecured. We decided to do some more in-depth analysis about the bugs which were reported. More than 80% of the apps in the Top 100 grossing applications in Google Android app store have problems with incorrect SSL Configuration which we have spoken about extensively.
As we scanned the Ola app, we found issues related to Cryptographic Keys, Insufficient Transport Layer Protection and issues in SSL Certificate verifier.
Cryptographic Keys
The very first problem we saw in the Ola app was in the Cryptographic Keys they were using. According to our scan, we found that the App is using AES/ECB/PKCS5Padding encryption which is not very strong. Appknox engine also predicted exactly in which method the AES Encryption was written. We can also find the AES Key which is:
80, 82, 79, 68, 75, 69, 89, 80, 82, 79, 68, 75, 69, 89, 49, 50
The above key is shown in decimal, and if we convert this into ASCII we get the AES key as: PRODKEYPRODKEY12
A little search in the OLA App code we find that with the same key, the user password is encrypted with AES and then encoded into base64.
Since we know the AES key, we can now decrypt password of anyone who holds an account in Ola. This is very dangerous since passwords should be encrypted with a one way hash, so that even if someone gets your password hash, one cannot decrypt it back to get the password.
Summary: In simple words, we found a way in which we can recover passwords for any Ola user account. This means, one can use your Ola account and your Ola credits to book cabs as well. Clearly, no one would want that right? The bigger concern is that all the user account passwords are stored using the same encrypted key PRODKEYPRODKEY12. This issue still exists and they’re going to have a tough time fixing this one!
Insufficient Transport Layer Protection
The next problem Appknox engine found is known as “Insufficient Transport Layer Protection”. When the data is sent from the mobile app to the server over insecure channels, whether the data is transmitted through the carrier network or through WiFi, it will end up through the Internet either way before it could reach the remote server. There are several ways where unprotected data transmitted over the network could be sniffed; things like routers, proxies, cell towers, are some of the few ways data could be sniffed while in transit.
How safe is your Transport Layer?
We found that Ola was not using SSL endpoints for it’s API, which makes it easier for us to intercept the request response of the API. For this to work, we made a proxy setup through which the network connection will route, which inturn will show the different requests being made to the server side of Ola.
For this purpose, we used Burp Proxy, which can intercept the request made by the OLA App installed in the phone. After configuring Burp proxy server, the traffic was routed via that proxy server so that each request were tracked on the terminal.
The communication between the OLA Cabs App goes like this:
The client makes a connection to the server.
The router redirects the connection to Burp Proxy, which is typically listening on a local port of the same host. Burp Proxy then consults the routing mechanism to establish what the original destination was.
The client believes it’s talking to the remote server, and initiates the SSL connection. It uses SNI to indicate the hostname it is connecting to.
Burp Proxy connects to the server, and establishes an SSL connection using the SNI hostname indicated by the client.
The server responds with the matching SSL certificate, which contains the CN and SAN values needed to generate the interception certificate.
Burp Proxy generates the interception cert, and continues the client SSL handshake paused in step 3.
The client sends the request over the established SSL connection.
Burp Proxy passes the request on to the server over the SSL connection initiated in step 4.
When transaction was finished, a call was being made from app to Ola servers to tell that transaction was successful, which is the call responsible for recharging the wallet.
Running the same request again resulted in a successful transaction which implies there was no validation against the recharge order. Hence we get to recharge our Ola Wallet without even going through the Payment Gateway.
Summary: What this means is that, using the same recharge reference code, we were able to recharge our Ola wallets multiple times. In short, you recharge just one, for any amount, and then you can use the same reference code to recharge over and over again. Time to get rich, eh?
We found these issues way back in early February. While we are a security company, we hack only to help our customers and not to take benefit or misuse their weaknesses. We tried to reach out to the OLA Security Team multiple times, and it seems they don’t think it is highly important. We also reached out to Bhavish Aggarwal, CEO of Ola Cabs reporting the same to him. Finally, after around 2 months the issue seems to be fixed.
The alerting mechanism that they speak of here is not true because they could get to know about it only once we contacted them. In fact, we’ve tried and tested this on other accounts as well but they couldn’t track it obviously because they blocked the user with the appknox.com email ID! Clearly, there is no automated tracking mechanism in place.
The same has been reported by Shubham Paramhans (one of the developers atKuliza) as well and even he got the same kind of response from the Ola team. We know that nobody is perfect, but companies can be more proactive towards such issues and should respond better.
We hope all companies take attention to this. We’ve been big fans of Ola and Uber and we often use their services to commute from home to work to meetings and more. Since we are consumers as well, we’d love to help the company and other businesses avoid such mishaps.
At Appknox, we encourage businesses to be proactive towards security and help them secure their mobile apps. We offer an extensive security scan of mobile apps by detecting security loopholes with suggestions to fix them. If yours is an app that involves making online payments or collecting user data, you can talk to our in-house security experts to discover ways to protect your app from cyber crimes. Just click on the link below.
