Wal-Mart is Latest Big Company with Mobile-App Security Problems

The evidence keeps mounting that companies that put out mobile apps are not paying nearly enough attention to security. Even big companies with large and experienced IT staffs are guilty.

The evidence keeps mounting that companies that put out mobile apps are not paying nearly enough attention to security. Even big companies with large and experienced IT staffs are guilty. In fact, the latest evidence suggests that the iOS mobile app of the largest company in the U.S., by revenue, Wal-Mart, exposes users' passwords, account names and email addresses, as well as many geolocation details. The retailer is famously IT-savvy and is said to owe much of its success to what goes on in the back office.

Wal-Mart has already addressed many of the issues raised by Daniel Wood (CISSP, GPEN), an independent penetration tester, and says it is fixing the geolocation problem.

Wood conducted the testing at the request of Computerworld. He also spotted security failings in Walgreens' iOS mobile app.

The Wal-Mart app also displays an extensive list of recently viewed and/or scanned products, which could prove quite embarrassing if viewed by a co-worker, date or relative. ("Stocking up on condoms, Father Smith?" And even worse, from an IT perspective, information saved unencrypted in the app reveals password access to a Wal-Mart development server along with information about the app's developer -- including account name -- that any fraudster who uses social-engineering techniques would find useful.

The list of large companies -- including Starbucks, Delta, Facebook, Match.com and eHarmony -- whose Android and/or iOS mobile apps have been found to reveal far more information than the companies knew has been growing. Besides Wal-Mart, we can now add Walgreens to the list. Its iOS app's Pill Reminder function encourages shoppers to photograph their prescriptions, but it seems that those images are stored unencrypted and available to anyone. The app also stores the full name and user ID of customers, not encrypted but encoded (Base64) -- which can be easily unencoded and accessed. Walgreens plans to fix both security holes within days, said Abhi Dhar, chief technology officer for e-commerce at Walgreens.

Dhar said Walgreens had expected shoppers to take pictures of prescribed pills -- showing an orange circular pill or a blue rectangular capsule, for example -- but many have been photographing the prescription labels. When executives realized that, he said, they knew Walgreens needed to up its security.

The unencrypted information stored in the Wal-Mart app is instantaneously available on any device that isn't protected by a password. Most mobile devices can be locked with a four-digit PIN, but that's hardly state-of-the-art security. Unlocked phones can be grabbed, as can locked phones whose PINs have been keyed in. PINs can also be shoulder-surfed. And of course a cyberthief could simply break the PIN through brute force, using tools like Fireeye or Cellebrite.

With Wal-Mart's iOS app, password information was at risk in the encrypted iTunes backup -- something that Wal-Mart just now fixed -- as well as if a user was registering while using public Wi-Fi. In the Wi-Fi situation, Wal-Mart relied too heavily on HTTPS doing the protection.

Why has it been so easy to find mobile apps with security problems? Not enough testing. Now, if you have worked on mobile-app development for a large company, you're probably going to tell me that you do lots of pre-launch app testing. I don't doubt you, but I'm willing to bet that it's overwhelmingly functionality testing, not security testing. I'm confident of this because Wood has been able to find all manner of glitches with just a few hours of testing. Why can't your security people do the same? Wal-Mart maintains that it does indeed do lots of security testing, but when we drilled down into the nature of that testing, it seemed likely that much of it was running automated scripts. Wood's testing was done by someone looking at the code and spotting problems.

Wal-Mart said that it runs "a set of automated systems that run and try and find things" as well as using various third parties, including Veracode and White Hat Security. But Wood observed that those companies offer both automated script testing and human testing, which costs more. Given what he found, he speculates that Wal-Mart probably used only automated scripts. Wal-Mart wouldn't clarify which services it uses from security vendors.

"We do extensive security testing, and we don't disclose how we test security, for obvious reasons," said Wal-Mart spokesperson Dan Toporek.

Toporek also said that "our iPhone app has and continues to use the iOS default or higher levels of security. We appreciate the feedback, as we're always looking to drive the highest levels of security to prevent even these types of unusual scenarios. We are continually enhancing the app and are fixing the issue that was storing geolocation information."

Exposing passwords and geolocation details is embarrassing for a company, and no business wants angry customers posting negative remarks about it on social media. So most companies are eager to fix those problems, though it seems to happen after the fact more often than not. Wal-Mart's app, though, exposes server access and internal codes, and that is a direct problem for the company itself.

The app's coding reveals, in plain text, the credentials for an internal development server at Wal-Mart. Given that those credentials have now been deactivated, I can tell you that the credentials themselves are enough to make any security specialist cringe: username "Mobile"; password "1111." (Really, Wal-Mart? Password 1111? Was 1234 already being used for your payroll system?) Wood also found a file called DeveloperCredentials.plist. (No "security through obscurity" in that filename.) The password there? "Password=password" and "username=developer@walmartlabs.com." That account has also now been disabled.

When Wood first found those mobile-account credentials, the server seemed to accept the password and then sent an email to the developer. Even more troubling, noted Wood: "The file also contains much if not all keys and definitions for defining Web service calls to the back-end data service. I was able to successfully make developer requests to their back end. That account was still active (at the time of our testing) because it executed a function."

According to Wood's diagnosis of the problem, the Wal-Mart team didn't sufficiently do the normal system cleanup before the app was published. "They didn't sanitize the application going from their testing environment to the production environment," Wood said. "It just shows that they didn't do their due diligence."

Another example: In the code, one developer revealed his exact username. During the build of the application's binary, the developer published the internal paths of his developer workstation, which revealed his full user path on the machine. A quick Google search revealed a ton of information about that user.

That is the kind of information that is solid gold to a cyberthief, especially one who specializes in social engineering. A fake email account could be created, for example, with which the cyberthief could send out emails purportedly from the developer handling that project. A cyberthief who sent such emails to other members of the team could ask for a password to be changed or for a link to be clicked on. "If so, you now have back-door access to that developer's machine and you might be able to inject malicious code into the application itself," Wood said.

But the security holes that affect users rather than Wal-Mart also could lead to serious consequences. One possibility is corporate espionage. A corporate spy who is targeting a particular company might start hanging out at bars, gyms, coffee shops and other places where employees of that company tend to hang out. He then patiently observes and waits until an opportunity arises to steal a phone. The spy might then access information directly -- emails anyone? -- or mine the phone for blackmail fodder -- prescriptions recorded on the Walgreens app, for example, or products scanned and stored on Wal-Mart's app.

How did we do our testing? The code was discovered by hooking into the systems APIs (hooking C functions and Objective-C methods, also called "Profiling") during runtime and running a tracer, logging API calls made by the Wal-Mart app, Wood said. This logs the class, method name, arguments, and return value that the app calls. "The data the tracer logs is stored in a SQLite DB, which I then pull from the device and run an analyzer on," he said.

Much of this data, though, can also be accessed wirelessly, particularly when the user is using a shared public Wi-Fi connection. Although it's true that all such public connections are security- and privacy-challenged, the way Wal-Mart crafted its mobile app makes it especially vulnerable to a wireless attack. First, all product images and scans are being transmitted in the clear, which means that anyone on that connection sniffing wirelessly will see everything. Even if it's a crowded Wi-Fi hotspot, tying that data back to a specific person isn't difficult. "Most smartphones broadcast the device name," said Wood, "so correlating the IP address that's looking at sensitive products and the device name -- MAC address will be the same -- is not hard to do. You just have to match and follow the TCP stream using a tool like Wireshark."

For more sensitive information -- such as passwords - Wal-Mart did use HTTPS, but it didn't encrypt or otherwise protect it, as it did with other information. Wal-Mart "managed to hash a lot for different functions (in its mobile app) when transmitting, so I don't know why they chose to send account creation details unhashed and just rely on HTTPS," Wood said. "And if a malicious user strips the SSL off, then they will be able to recover the username and password as they are sending it unhashed/unencrypted within the request."

Is there a more secure route that Wal-Mart could have gone? Wood argues there is. "To combat this, apps need to utilize certificate pinning. As a developer, you can either pin the Web service's certificate within the app itself, which takes the Certificate Authority out of the picture, or 'pin' the CA's certificate that was used to sign the server's certificate on the back end, limiting trust to only certificates signed by that CA," he said. "This is important because it reduces the threat against a malicious user being able to introduce their rogue certificate into the mix and prevent an attacker from utilizing a proxy server to masquerade as the server. While not an end-all, it helps defend against intercepting on the server side."

The point of all of this is not that Wal-Mart and Walgreens were especially reckless when it came to security -- although both could have certainly done more -- but that many of the largest companies with the best IT talent are still not focusing sufficiently on mobile app security. And if they're not, what are the chances that small companies are? Mobile app security needs to get top-tier IT attention, and it needs to happen now. I assure you: Cyberthieves and corporate espionage agents are already on it.

Evan Schuman has covered IT issues for a lot longer than he'll ever admit. The founding editor of retail technology site StorefrontBacktalk, he's been a columnist for CBSNews.com, RetailWeek and eWeek. Evan can be reached at eschuman@thecontentfirm.com and he can be followed at twitter.com/eschuman. Look for his column every Tuesday.

Read more about mobile security in Computerworld's Mobile Security Topic Center.

This story, "Wal-Mart is Latest Big Company with Mobile-App Security Problems" was originally published by Computerworld.

NEW! Download the State of the CIO 2017 report