Uli's Web Site |
|
blog |
Heise reports Mac TrojanLooks like the Mac has finally reached critical mass and become attractive enough for Malware authors. German publisher Heise reports: Mac-Trojan in video codec of porn sites As is to be expected, this uses either the Open Secure Files option that Apple should have removed years ago, or alternatively instructs the user how to expose themselves using social engineering ("to install the codec, launch the downloaded installer and enter your password"). However, the damage it causes is very interesting: (...)The Trojan twists [sic!] the DNS-entries to point to servers controlled by the virus authors, which will return manipulated DNS answers for eBay, PayPal and some banks, pointing to phishing sites, and will install a cron job that checks these settings every minute and restores them as needed. To me, if this malware really works as advertised, I'd say the Mac has been cracked. And neither code-signing, nor the sandboxing offered in Leopard help here, because the malware makers can sign their files themselves, and the sandboxing is done by the application itself. So unless Apple adds a method to prohibit any application from changing the system configuration without being explicitly allowed, and separately from any permission one may need to simply install an application, this will be a problem we'll have to live with from now on. But even then this won't remove the exploit: I guess the problem is that it's not obvious that a codec should not need internet access. The user may think it's a streaming codec. And if not, that may be the explanation the web site will give. Social engineering will always work, even though it'll be harder to apply to educated users that don't follow spam links and don't trust any old web site. We get asked for our password for many installations, why shouldn't a codec ask for it? I guess one way to let at least knowledgeable users avoid issues like this is for Apple to standardize on an installer for all installations. E.g. if I have an app that is a drop-install, but then installs a Kernel extension to do its magic, my app should launch an Apple Installer Package embedded in its bundle and then the user could inspect this package, get a summary what gets installed where, etc. And Apple could have different "safety levels" for packages, so that they can either use standard hooks which the installer can display in a readable way even to newbie users, or if they need a script to do their work, the package would get flagged as potentially dangerous. If Apple offers enough canned behaviours for common things, users could get used to not seeing this warning, and wouldn't be tricked as easily. Moreover, they could be educated that a Codec should never need to contain a Kernel extension or need access to system configuration or address book. And why is there still no way to prevent applications from accessing my address book?
|
Created: 2007-11-01 @703 Last change: 2007-11-01 @743 | Home | Admin | Edit © Copyright 2003-2024 by M. Uli Kusterer, all rights reserved. |