Phone Maker HTC Breaks Its Own Security. These Are The Guys Who Will Help Bring Us Mobile Payments?
Written by Frank HayesEven as retailers and customers ramp up for mobile commerce, some smartphone makers still don’t have a mindset that’s ready for handling payments. On Tuesday (Oct. 4), handset vendor HTC admitted that an application built into some of its Android phones could leak sensitive user information—such as GPS data, E-mail account information and potentially even payment-card numbers—to malware that could get the data without a password or any special permissions except the right to connect to the Internet.
The specific information that HTC’s logging software collects isn’t tremendously sensitive—we’re talking location, not payment-card numbers. However, the fact that megabytes of data are being scooped up by the phone’s maker, but not secured by even a password, is a sign that smartphone vendors still assume a phone is just a phone—instead of a combination payment terminal, mobile wallet and M-Commerce browser.
According to security researcher Trevor Eckert, who discovered the HTClogger software on his HTC Evo phone, the built-in software captures information on how long apps are used, phone identity, IP addresses, GPS location, mobile networks detected (Wi-Fi and Bluetooth) and contents of application clipboards. (You copied a payment-card number to the clipboard? It’s just been captured.) But once collected, none of the information is password-protected, and any app with permission to connect to the Internet—a very common permission for apps—can query the log files. (The supposedly secret HTClogger even has a help function that lists all available query commands.)
A week after Eckert reported the vulnerability to HTC (and a day after he went public with the information), the handset maker issued a statement that “while this HTC software itself does no harm to customers’ data, there is a vulnerability that could potentially be exploited by a malicious third-party application.” The company said no customers had reported attacks and it plans to issue a patch in short order.
A patch is good, but that’s still the wrong mindset for a device that can carry so much genuinely sensitive information. How would customers know their phones had been compromised if an innocent-appearing game with no special permissions silently copied the information that HTClogger collected and sent it across the Internet? Waiting for customers to tell you that you’ve built a security hole into your phones is not the way to show you’re ready to handle mobile payments.
Ignoring a non-public vulnerability report from a security researcher isn’t helping your customers, either. Most “white hat” hackers will keep vulnerabilities quiet if a vendor asks for time to fix a problem. They’ll even help a vendor to re-create the problem and explain how it can be exploited. All a vendor has to do is ask.
And when a phone maker has actually broken its own security by adding logging software, that phone maker needs all the help it can get. Yes, that’s right—all the information exposed by the logging app was originally secured and required special permission to access—until HTC added the logging software to the phone.
Worse still, once HTC added the logging software to its phones, the only way for a user to get rid of the insecurity would be to “root” the phone—that is, make it less secure.
That logging software was intended to keep the phone running well by detecting problems quickly. That’s a very reasonable purpose. But there’s just too much data flowing through a phone today for a handset maker to get sloppy.
Ironically, the security built into the Android operating system may have helped foster that security-blind mindset among the phone’s developers. Maybe they think they don’t have to worry about security, because the OS is locked down. But that’s a deadly assumption—as every retailer knows, it only takes one security-unconscious associate to blow a hole in carefully devised security defenses.
No wonder the PCI Council doesn’t want to touch the problem of approving mobile devices. Until handset developers start to think less like phone makers and more like cashiers, they won’t be ready for mobile payments anyway.