Skip to content

Self-Inflicted DNS, SSL Hijack Targets Less-Than-Ethical iPhone Users

2012-07-25

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

Joe Levy, Solera Networks’ CTO, stumbled upon a social engineering scam, targeted at users of iOS or OS X, at about the same time last week as did a Russian blog and several news sites. As a result, Apple is struggling to get security in its in-app purchases working again.

In this instance, victims are asked to download and install bogus SSL certificates, including a fake Verisign CA certificate — bypassing several warnings in the process — and to modify their own DNS settings to point to servers under the control of an unknown third party. There is no technological bypass at work here: This is an entirely self-inflicted malady that comes about as a result of users making changes affecting the security of their own devices without understanding the consequences of those changes.

The person who operates the Web site referenced in the tweet, in-appstore.com, makes a convincing case for a victim to modify their own DNS settings and install two bogus SSL certificates: ZonD80, also known as Alexey Borodin, promises people who do this that they will be able to bypass Apple’s in-app purchasing through iTunes, and obtain (normally for-pay) additional content at no cost, if you just install the certs and hijack your own DNS. On the Web site, you’ll also find handy, step by step instructions to, among other things, install a VeriSign CA certificate, which Borodin can use to generate new SSL certificates for any Web site he chooses.

But the problem here is that this is a bigger issue than merely stealing in-app purchases (though, as of July 16th, it appears that it is still possible to do so). The more long term, significant threat here is not the abuse of Apple’s store, but the potential for users to easily (and in a hard to detect way) leak or lose control of sensitive personal information.

The instructions include helpful screenshots of the error messages you were certain to see if you perform the same actions on your phone. Likewise, if you use OS X, you can also install the bogus certificates.

While a debate rages on in the comments section of in-appstore.com about the ethics of depriving app developers of revenue, many users miss the far more serious point: In exchange for some extra credits in a game, or a rare special item needed to complete a quest, users literally could be giving up the keys to their digital kingdom. A victim could find that sensitive information he or she thought was protected in transit by SSL encryption is not protected at all.

This particular type of hijack is extremely dangerous because, theoretically, the two modifications together could permit a criminal to have greater, less transparent control over the user’s Web browsing activity: He could surreptitiously redirect any domain name to any IP address, and he could decode the data being transmitted over SSL.

To be fair to Mr. Boronov, it’s hard to know his motives beyond getting free in-app purchases, but frankly the problem has opened a much larger can of worms.

Once the changes have been put in place, the Search tab within the iTunes app displays an odd message. It reads:

Hi, Dude!

You connected to in-appstore.com, but…

Looks like you are using AppStore client.
Please use application itself or remove DNS
setting if you want to use AppStore client.

The In-appstore page also links to this dnsmasq.conf file, which instructs machines running dnsmasq DNS server software to redirect the .itunes.apple.com subdomains, as well as itunes.com and edgesuite.net, to 91.224.160.136.

That IP address is owned by a company based in the British Virgin Islands, but the machine hosting that server is physically located in the Netherlands, according to the MaxMind GeoIP database. The in-appstore domain was registered using a private registrar based in Panama on July 11th. (Sounds legit.)

The implications are enormous, because they are only limited by the scam artist’s imagination and ability to convince i-device users to further compromise their own security. We’ve already noticed one undesirable data leakage: One test device performed an HTTP POST of data to ax.su.itunes.apple.com when we launched the App store app. The data was a gzipped manifest listing all the installed applications on the device, but because the DNS was modified, the device sent that data to 91.224.160.136, the server Mr. Boronov appears to operate. So, if you open iTunes on a modified device, it sends this data to ZonD80’s server.

It’s not that big of a deal unless you’re talking about things like Web site credentials.

The repair process involves manually removing the DNS modifications and deleting the certificates. On a victim’s machine, certificates are stored in an extra entry in the Settings > General menu, labeled Profile, which only appears if a certificate has been added to the local store. Click the Profiles item, then click each certificate one by one, followed by the red Remove button.

Bottom line: A DNS hijack is bad enough; That merely gives a malicious third party the opportunity to redirect Web traffic to a computer of their choosing, instead of the real Web site’s IP address. When you add in a bogus VeriSign CA SSL certificate into the mix, it becomes a whole lot worse. Now, a bad guy can stand up a real-looking Web page — any Web page — and even equip it with working SSL, and just slurp the credentials that come down the wire when people try to log in.

“An element of our greater concern is that this tactic is likely to be employed and/or escalated by real bad guys, who will entice many to subject themselves to DNS and certificate-level attacks,” Joe says. Besides educating users that they shouldn’t make these changes — especially in the face of sternly-worded warnings they can choose to ignore — what can we do to defend against that?Solera blog stats

Comments are closed.

%d bloggers like this: