Big name apps like Uber and Venmo may be putting some users ill at ease by requiring payment card information in order to function, but experts say the risk is relatively low.
By Grant Hatchimonji, CSO | Data Protection, Mobile Security
September 08, 2014, 11:46 AM — Data is compromised so frequently these days that it seems like nothing is safe anymore. So one would be forgiven for thinking that using apps that require the user to voluntarily submit payment card information in order to function -- think Venmo, Uber, etc. -- would be a risky play. The reality, however, is that these kinds of apps are actually no more risky than any other transaction involving payment cards.
"Look at it this way: when you buy something online using a credit card, a website is literally doing the exact same thing," says Tyler Shields, a senior analyst for Forrester. "If designed properly, that's all a mobile app is...a component to access data stored on a server."
Though Shields admits that developers don't necessarily always follow best practices, they generally avoid having apps store any sensitive data locally on the device. Instead, when users submit their payment card information, it's submitted via a one-time encrypted transaction to third party backend servers managed by a payment processing company.
"What typically happens is the company that is accepting payments stores the username and email address along with some sort of reference number that is completely independent of your credit card information," says Mathew Rowley, a technical director at the NCC Group.
From then on, the card information is stored in an encrypted fashion on backend servers and never comes back to the client through the application again. In order to make transactions, the app simply pings the encrypted card on the server using a private key to decrypt it, making sure that information never hits the airwaves again. Typically payment processing centers provide developers with an SDK to plug into their application so they can securely communicate over web interfaces, but Rowley notes that things sometimes get problematic when companies try to take that responsibility on themselves.
"Some companies try to do a custom, create-your-own-encryption scheme," he says. "That's where the flaws usually come in -- trying to make that communication channel secure."
Locking down the app
Aside from trying to secure communication channels, there are additional security measures that app developers are beginning to employ. However, they have yet to become the norm, according to Shields.
"There are more advanced techniques being used in a few cases," he says. "Banks are using app protection and app hardening techniques, where they're hardening the client side with fraud protection or anomaly detection."
For instance, developers can put code into the app that checks to see if the device is jailbroken and if it is, it won't allow it to connect to the servers. Code can also be inserted to determine if apps on the device are known or if there are rogue apps.
"So it's looking for indicators of compromise," says Shields. "Eventually those techniques will fill the gap to the more common apps, but right now, they're mostly used in the banking sector."
Joe Schumacher, a senior security consultant at Neohapsis, adds that some developers implement code obfuscation to prevent apps from being decoded or looked at through the source code. Without that kind of protection, there's nothing stopping attackers from disassembling the app and obtaining -- and subsequently using -- any sensitive information they may find.
"So you have to be careful how code is written and what you're putting into your code," says Schumacher. "You don't want to put in usernames and passwords."
Malwarebytes Labs researcher Armando Orozco agrees that attackers would normally look at the apps themselves for vulnerabilities, because some apps in the past have kept confidential information stored as a text file in the data area of the app or on an SD card. As such, he has found that deck scramblers are especially useful as a first line of defense.
"Malware can tear an apart and look for obvious vulnerabilities where they're not storing data properly...we saw that with Skype a few years ago, where they were storing passwords in clear text on SD cards," says Orozco. "Deck scramblers jumble the code around and make it difficult to extract what's going on with the app itself if it's disassembled."
But in all likelihood, the experts say, criminals aren't going to target individual users and pick off their card information one at a time. Rowley admits that if the cryptographic security is downgraded over the communication channel, an attacker could crack and gain access to the data stream, but it's an unlikely scenario.
"It wouldn't make much sense to try to break these streams to get one credit card per stream," says Rowley. "Each one is only going to sell for a couple of bucks in the black market."
Shields also recognizes the possibility for compromise, but says that since card data is so rarely accessed in a non-encrypted form, it's simply not efficient for criminals to try to attack through the app.
"When users sign up with a credit card, there's that single moment in time," he says. "There isn't a multiplier there, so I can compromise your phone, maybe, that one time. You could also get the data when it's entering the backend system that first time. There's absolutely the potential to compromise over time by planting something that detects every user sign up, but that's difficult to do."
Instead, attackers need to focus on the backend systems. One of the more serious flaws that Rowley says he's encountered while pen testing apps is with the XML communication flow between the mobile device and the backend processing system. Known as XML external entity (XXE) processing, the vulnerability lets people see the data going back and forth, something that many of the developers that make backend systems don't realize.
"It allows you to do anything from reading files in the file system to causing the server to reach out to other devices," says Rowley.
Securing the backend
So if anything, it's how users' data is stored and protected on these third party backend servers that should be the point of concern. Though how payment processing companies opt to do this tends to vary, there are some security best practices that they are ideally meeting.
"When it comes to storing sensitive data, there's no foolproof way to say whether you're secure or not," says Schumacher. "If you're relying on third parties, make sure they're doing their due diligence. Hopefully they have it where they have a tiered network architecture that has zones that denote untrusted to trusted and makes sure that the sensitive data only stays in the trusted."
He went on to say that one of the best options attackers have are either utilizing man-in-the-middle attacks (if the user is on a shared network like a Wi-Fi hotspot) or by using proxies that allow for the manipulation of traffic.
"If the app is sending a session back to the client to authenticate, the attacker [through their proxy] can jump the user's privilege," says Schumacher. "They can use a different username but the same authentication to access sensitive files."
Well-implemented authentication and access control measures, therefore, are imperative.
"Authentication and access control are the two things that come to mind first," says Rowley. "Uber, for example, has a payment processor; it can process traffic and restrict network access to only Uber's IP address."
While it's true that these backend systems will have some sort of encryption implemented, Shields points out that generally it's not the strength of the encryption that is the point of concern. After all, if companies know how to encrypt their data, they know to do it with a reasonable level of strength.
"What's more important is how they store the keys to the encryption and how they're protected...and how the servers themselves are protected," he says.
Convenience without forsaking security
The experts all agree that while it ultimately comes down to a matter of preference ("It's a tradeoff, but for me it's absolutely worth the risk," says Shields), there's no reason for users to worry about using these types of apps -- at least not any more than they would worry about using payment cards on ecommerce sites. Rowley agrees with Shields' point about the difficulty and inefficiency of compromising users' information on an individual basis, pointing out that it's important to think about what attackers' intentions are in this situation. Unless a user is a high profile target that criminals know has a lot of money, they're probably not going to be the victim of a targeted attack.
"If [the attacker's] goal is to get as many credit cards as possible, they're not going to sit there and monitor your traffic and try to get your one card number," Rowley says. "They're going to attack the payment processors or the banks."
And as Rowley and Orozco both point out, users' sensitive data resides with banking institutions regardless of whether or not they choose to use apps that require it. If attackers chose to go straight for the banks -- which is generally the more strategic route -- customers are already out of luck because the banks have their information anyway. The apps don't introduce any new risks to that equation.
"If attackers target the banks, you've lost there because your data is already there," says Rowley. "I don't think you're opening yourself in a less secure manner than if you were to not use a banking [related] app."
Still, there are the typical steps that users can take to ensure that they don't put themselves in riskier situations than is necessary.
"In my opinion it's safe to use them, but I would make sure you get these apps from a trusted source," says Orozco. "Make sure banking apps, for example, come directly from your bank and not a third party. Make sure [other apps involving payment card information] are approved in the Apple App Store or Google Play Store."
Schumacher shares similar sentiments, stressing that users shouldn't judge all apps the same and should, instead, "think about what's going on behind the app." However, he expresses concern over whether people actually take the time to vet their apps because, generally speaking, convenience trumps safety for users.
"Unfortunately, our society has shown that convenience is first in mind," says Schumacher. "This is the tip of the iceberg with people blindly trusting parties, whether it's an app or cloud based storage or whatever. They're just default trusting these places."
