Bogus credentials may be enough to ensnare some smartphone apps, researchers say.

Enlarge / One of the many fraudulent SSL certificates, this one impersonating Facebook. Facebook apps won't be fooled by it, but other programs might.

Netcraft

Researchers have found dozens of fake certificates impersonating the secure sections of online banks, e-commerce sites, and social networks. Google, Facebook, iTunes, and even a POP e-mail server belonging to GoDaddy are a small sample of the services affected by the fraudulent credentials, which in some cases can allow attackers to read and modify encrypted traffic passing between end users and protected servers.

The secure sockets layer (SSL) certificates don't pose much of a threat to people using a popular Web browser to visit spoofed websites, because the credentials aren't digitally signed by a trusted certificate authority, researchers from Netcraft wrote in a blog post published Wednesday. They went on to say that people accessing sensitive websites with smartphone apps or other non-browser software may not be so lucky.

"Online banking apps for mobile devices are tempting targets for man-in-the-middle attacks, as SSL certificate validation is far from trivial, and mobile applications often fall short of the standard of validation performed by web browsers," the Netcraft researchers wrote in Wednesday's report. "40 percent of iOS-based banking apps tested by IO Active are vulnerable to such attacks because they fail to validate the authenticity of SSL certificates presented by the server. 41 percent of selected Android apps were found to be vulnerable in manual tests by Leibniz University of Hannover and Philipps University of Marburg in Germany."

Many of the fake SSL certificates discovered by Netcraft were created with malicious intentions. A wildcard certificate for *.google.com suggests an attempt to spoof a variety of Google services. The fake certificate was served by a machine in Romania hosting other sites with .ro and .com domains. The phony credential claims to have been issued by America Online Root Certification Authority 42. The name closely mimics a legitimate trusted root certificate that is installed in all browsers, although it's not enough to trick them. Other fraudulent credentials masqueraded as certificates for Facebook, iTunes, and a payment service and bank located in Russia.

"In this case, the opportunities could be criminal (capturing mail credentials, issuing password resets, stealing sensitive data) or even state spying, although it is unexpected to see such a certificate being offered via a website," the Netcraft report stated. "Although the actual intentions are unknown, it is worth noting that many mail clients allow certificate errors to be ignored either temporarily or permanently, and some users may be accustomed to dismissing such warnings."

Fortunately, many of the most popular apps—such as those for Twitter, Facebook, Google, and others—use a technique known as certificate pinning that automatically rejects connections from sites that offer bogus SSL certificates. And as already stated, major browsers will offer scary warnings when encountering unsigned credentials. But given the large number of e-mail clients, smartphone apps, and other non-browser programs available, it's not a stretch to think the certificates discovered by Netcraft are fooling some people right now. You should carefully consider the source of any app that connects to an SSL-protected server before installing it, and you should never click through pop-up windows that warn of self-signed certificates.

Best idea ever: don't buy anything via CC with your phone. Buy it from iTunes Desktop or Android Mega-App-Store-Dot-Org Desktop, sync it to your phone, and never have to worry about bogus certs, phone-snooping apps, etc. Same goes for Amazon, et al. I don't get why anyone would buy via their phone unless there was no other option and it was an urgent thing (like you need a new mini-drive for your business presentation in 2 days, and the Local Yocal Lodge you're staying at does not have secure internet).

Also GoDaddy is arguably the worst "big name" hosting company there is. They do not take care of the details at all, so it's no surprise they're part of the problem.

OS vendors need to be a lot more careful regarding whose root and/or intermediate certs they include with their software. In Windows open certmgr.msc and look under trusted root > certificates, intermediate > certificates, 3rd party > certificates. You get the idea. Certs issued by any one of those entities are in the trusted chain. it is up to those entities to ensure whoever is requesting a cert for a given domain name actually owns that domain name. Without that we got no way to verify identity. Sure the connection is still encrypted, but you don't know who's on the other end.

Best idea ever: don't buy anything via CC with your phone. Buy it from iTunes Desktop or Android Mega-App-Store-Dot-Org Desktop, sync it to your phone, and never have to worry about bogus certs, phone-snooping apps, etc. Same goes for Amazon, et al. I don't get why anyone would buy via their phone unless there was no other option and it was an urgent thing (like you need a new mini-drive for your business presentation in 2 days, and the Local Yocal Lodge you're staying at does not have secure internet).

Also GoDaddy is arguably the worst "big name" hosting company there is. They do not take care of the details at all, so it's no surprise they're part of the problem.

Worst idea ever: assume that one computer (your desktop) is magically more secure than another (phone). These cert exploits might be one subset of exploit more widespread on the smartphone, but on the whole it's a wash.

Best idea ever: don't buy anything via CC with your phone. Buy it from iTunes Desktop or Android Mega-App-Store-Dot-Org Desktop, sync it to your phone, and never have to worry about bogus certs, phone-snooping apps, etc. Same goes for Amazon, et al. I don't get why anyone would buy via their phone unless there was no other option and it was an urgent thing (like you need a new mini-drive for your business presentation in 2 days, and the Local Yocal Lodge you're staying at does not have secure internet).

Also GoDaddy is arguably the worst "big name" hosting company there is. They do not take care of the details at all, so it's no surprise they're part of the problem.

Worst idea ever: assume that one computer (your desktop) is magically more secure than another (phone). These cert exploits might be one subset of exploit more widespread on the smartphone, but on the whole it's a wash.

I have zero problems buying stuff on my phone & tablet from, say, the Play store or my Amazon app using a CC. Your CC very well protected from fraud, which is to say as long as you keep an eye on your transactions, you're not liable for any losses.

I will not do any sort of banking or serious financial transactions on my phone or tablet. It never even touches that portion of my life. Separate credentials, email profiles, hell even a pared down Keepass db. There is no way you're going to convince me my phone, whether on LTE or WiFi (yes, even secured though a VPN) is as secure as my home PC, which has many layers of protection not available on a mobile device, the least of which is it never leaves my home, which is to say is not nearly as prone to theft or simple misplacing.

Best idea ever: don't buy anything via CC with your phone. Buy it from iTunes Desktop or Android Mega-App-Store-Dot-Org Desktop, sync it to your phone, and never have to worry about bogus certs, phone-snooping apps, etc. Same goes for Amazon, et al. I don't get why anyone would buy via their phone unless there was no other option and it was an urgent thing (like you need a new mini-drive for your business presentation in 2 days, and the Local Yocal Lodge you're staying at does not have secure internet).

Also GoDaddy is arguably the worst "big name" hosting company there is. They do not take care of the details at all, so it's no surprise they're part of the problem.

Worst idea ever: assume that one computer (your desktop) is magically more secure than another (phone). These cert exploits might be one subset of exploit more widespread on the smartphone, but on the whole it's a wash.

There is nothing magical about it...most people are using their browser to access those services, which are much better about at least verifying that the cert is even valid in the first place. Most phone apps on the other hand are a product of ass-backwards API's that make it difficult to do proper pinning, and so just accept anything and are vulnurable to MitM attacks. No pixie dust required.

I think it's worth noting that Safari on iOS (and likely Chrome on Android as well) is just as secure as the desktop version of the same, and as such, the mobile website (when available) can be considered a very reasonable alternative to using the mobile app.

(At least, until all of these issues are properly ironed out by way of standardized SSL APIs from the OS vendors, of course.)

I think it's worth noting that Safari on iOS (and likely Chrome on Android as well) is just as secure as the desktop version of the same, and as such, the mobile website (when available) can be considered a very reasonable alternative to using the mobile app.

(At least, until all of these issues are properly ironed out by way of standardized SSL APIs from the OS vendors, of course.)

Google is on record saying that Chrome has certificate pinning for its websites and possibly popular websites operated by other companies. I'm not aware of Apple making any assurances about certificate pinning in Safari. Based on that, I think Chrome probably is the (slightly) safer choice.

Could you maybe use your contacts with Apple and ask them to add this to their checklist of approval for apps in the App Store?

They could easily load a fake certificate for SubjectName=* into an offline network and test to see if the app returns an error, or tries to connect without validating the cert. Use it as a plus point of the App Store approval process.

Could you maybe use your contacts with Apple and ask them to add this to their checklist of approval for apps in the App Store?

They could easily load a fake certificate for SubjectName=* into an offline network and test to see if the app returns an error, or tries to connect without validating the cert. Use it as a plus point of the App Store approval process.

I think you may be overestimating my influence in getting Apple to talk about security-related topics. In my nine years on the beat, Apple has responded to only a handful of my requests for comment. I'm not aware of any security reporters with a different experience with the company.

Old news. Glad to see it in the spotlight again. Only public attention can fix the broken CA system we use.

While the CA system is broken in many ways, this story doesn't have to do with any of them.

I'm pretty sure iOS and Android provide X.509-compliant validation methods in their APIs. Are devs required to use them for SSL communications? I doubt.

Also even well-known apps can have weaknesses. Safari for example doesn't do revocation checking except for EV certs maybe. This has gotten us to the sad state where an unauthorized cert has to be blacklisted by a browser instead of just relying on the existing mechanism of CRL/OCSP to catch it.

Old news. Glad to see it in the spotlight again. Only public attention can fix the broken CA system we use.

While the CA system is broken in many ways, this story doesn't have to do with any of them.

I'm pretty sure iOS and Android provide X.509-compliant validation methods in their APIs. Are devs required to use them for SSL communications? I doubt.

Also even well-known apps can have weaknesses. Safari for example doesn't do revocation checking except for EV certs maybe. This has gotten us to the sad state where an unauthorized cert has to be blacklisted by a browser instead of just relying on the existing mechanism of CRL/OCSP to catch it.

To me, the current X.509 API's are the equivalent of releasing a File API where you are required to manually manipulate inodes instead of file paths. Not physically impossible, but complicated enough that most people just don't care if they are not required to.

Is this unusual? My school's WebSense replaces SSL certificates all the time?

With Websense It's different. Your school basically needs to run their own CA and add trust to it on clients.Usually you push the certs to IE via Group Policy. If you don't it will flip and error out on every SSL connection.

If you're using Firefox then there's always the Perspectives and Certificate Patrol add-ons to verify certificates.

Unfortunately there are so many new certs being issued by Google and some others that there is a danger of becoming complacent and just clicking through warnings. However I do take extra notice of certificates on sites associated with money in any way e.g. banks, eBay, PayPal etc.

IIRC if you create a HTTPS connection in an Android or iOS app it will flip out if you have an invalid cert because it checks to see if the certificate is valid or in the certificate store. This is because both Android and iOS apps use OpenSSL at the lowest layer for establishing secure connections if memory serves me right.

(Source: I did a LOB Android app that needed to connect over HTTPS. I had to hack my way around our self-signed cert. I know it was bad, but the business side didn't want to pay for an actual SSL cert. I also vaguely remember the same being needed for iOS)

Having worked on Firefox OS for the past year and a half this intrigues me: I think that this kind of exploit wouldn't be possible in a Firefox OS app since certificate validation is done by the underlying browser engine which should work exactly as desktop Firefox but I'm not entirely sure; it's probably worth a try.

First off.. this is really old news. As this article says.. some of these studies are years old. I guess it's good to remind people of how bad SSL implementations are outside the major browsers.

Quote:

And as already stated, major browsers will offer scary warnings when encountering unsigned credentials

The problem is - people regularly "train" to ignore these messages. Sometimes there are technical reasons that you want to actually get around / ignore these messages. If you understand the technical reasons then fine, but most people don't so they just assume that scary messages can be ignored and it's okay. This bad training really defeats the purpose of the security messages.

Two examples of legit cases... my homepage is https://google.com .. but that means when I go somewhere with public WiFi where they don't re-route but actually replace my homepage with their own public WiFi login or terms acceptance page... I get the scary SSL message as I should. I can say ignore as most people would, and it's no problem (or I can usually just browse to any non-SSL page to get the error-free login... however that takes an understanding of why the error is showing and what can be done to prevent it). Another example is Java. Developers are not keeping up with new Java runtime's security requirements... but when you actually NEED to use old java you have to ignore and/or bypass Java's security messages/settings.

Conclusion: online security is still not refined... until it is, the general population will continue to get caught with their pants down... sometimes literally.