PDA

View Full Version : Removal tool for trojan found in pirated copies of iWork 09


MacBytes
Jan 23, 2009, 08:06 AM
http://www.macbytes.com/images/bytessig.gif (http://www.macbytes.com)

Category: News and Press Releases
Link: Removal tool for trojan found in pirated copies of iWork 09 (http://www.macbytes.com/link.php?sid=20090123090658)
Description:: This tool is in response to a new trojan horse in the wild that comes bundled with pirated copies of Apple's iWork 09.

Posted on MacBytes.com (http://www.macbytes.com)
Approved by Mudbug

bbplayer5
Jan 23, 2009, 08:15 AM
Anyone know what this installs? I ran the remover but it says the trojan downloads and installs in the background...

SFStateStudent
Jan 23, 2009, 08:42 AM
I'm not sure, b/c I have iWork '08.:confused:

GoCubsGo
Jan 23, 2009, 08:43 AM
No offense, but I am completely confused as to why this is being posted. The article on the fact that the pirated copies of iWork 09 contain a trojan is one thing, but to post the tool to remove it gives me the impression this behavior is suddenly supported around these parts. While I get this is news, this is news to get the twunts out of hot water. :rolleyes: I'd let them suffer on their own. There, I said it. :D

alexbates
Jan 23, 2009, 08:46 AM
Does the removal tool really work? Or is it better to follow the steps in Terminal shown on one of the earlier posts on the front page of MR?

Mudbug
Jan 23, 2009, 08:50 AM
I grappled with whether to post it or not - the final decision I made was based on thinking that any effort to stop propagation of a BAD THING™ in the world that I can do without helping to spread the BAD THING™ is a GOOD THING™.

I didn't link to a way to get the torrent, nor do I condone at all the stealing of software. I just simply linked to another site offering assistance in the unlikely event you found yourself fubar'd by doing a very stupid thing. IMHO what's likely a momentary lapse of good judgement shouldn't brick your Mac, or whatever it does.

SFStateStudent
Jan 23, 2009, 08:55 AM
No offense, but I am completely confused as to why this is being posted. The article on the fact that the pirated copies of iWork 09 contain a trojan is one thing, but to post the tool to remove it gives me the impression this behavior is suddenly supported around these parts. While I get this is news, this is news to get the twunts out of hot water. :rolleyes: I'd let them suffer on their own. There, I said it. :D

Do you think it's possible that some people thought they were buying iWork '09 legitimately, let's say at the local swap meet for $20 from the "iWorks for pirated software booth? (just kidding) :D

+1 ^^^ I agree, they get what they got comin'...:eek:

benpatient
Jan 23, 2009, 08:55 AM
that's the problem with trojans...

they aren't good for anyone.

not like anyone uses iwork anyway...

:)

Looks like security through obscurity is finally starting to crack.

The dark secret of the mac world is that a LOT more mac users download software illegally from torrent sites, etc.

It's so much easier to install something on a mac (usually just drag the .app into your folder) than it is to deal with registries, etc. on a PC. Add to that the "serial box" and you've got an environment that practically begs people to rip off software. One of my windows buddies in college switched to a mac because it was so easy to get any software he wanted and get it running trouble-free. He had a burned DVD with like 400 commercial apps on it. Most of them you just had to drag to the hard drive.

it was only a matter of time before someone stuck a trojan into one of those things...expect to see repeats of this news ever couple of months with different new software releases from here on out. The cat is out of the bag.

Maybe just being aware of the possibility of a mac trojan will give downloaders pause before bit torrenting everything under the sun. Maybe Apple released it themselves? ha. It's their official "serial protection" scheme for iWork 09.

that's pushing the envelope!

alexbates
Jan 23, 2009, 09:17 AM
...not like anyone uses iwork anyway...


Wrong. I used the free trial of iWork '08 and loved it. I am getting sick of Microsoft Office 2004 because all of the bugs (still) so I am going to get iWork '09 one way or another, even if I buy it.

bitWrangler
Jan 23, 2009, 09:19 AM
I grappled with whether to post it or not - the final decision I made was based on thinking that any effort to stop propagation of a BAD THING™ in the world that I can do without helping to spread the BAD THING™ is a GOOD THING™.

I think this brings up a hugely important point here. While from a personal level I agree with others who say that anyone pirating pretty much deserves whatever they get. However, from the standpoint of the Mac community, it is far better if we squash any form of trojans/worms/virus ASAP. This is an opportunity to nip things like this in the bud. What if the "additional" code that this thing downloads is able to exploit a weakness in OSX and actually propagate itself to other Macs on a network. Everybody loses at this point, both technically and esp for Apple, from a PR standpoint as one of the primary selling points of OSX goes down the crapper with one mass infection.

Krevnik
Jan 23, 2009, 09:20 AM
Looks like security through obscurity is finally starting to crack.

I have yet to see an OS that can fully avoid an attack like this. The trojan installs by using a modified iWork installer package which already asks for elevation (piggybacking on an action that happens normally to install itself).

If I modified a Windows MSI to install a trojan, or a binary installer package for Linux, and someone is stupid enough to give it admin privileges without ensuring the trust chain... well, those systems are compromised as well.

Apple themselves tell developers to /not/ use installers whenever possible for a mix of security and other reasons. Just dragging a .app file over to Applications won't expose you to this attack (unless you then stupidly give it admin privs when it asks, and it was a trojan app to begin with).

If anything, this exposes the fact that there really is no good way to ensure a trust chain through P2P without having some other means to check the signature against a trustable source (i.e. MD5 hashes you can check against the official distribution). And when it comes to pirated content, there is no such thing as a trust chain unless you are pirating stuff from your friends (and even then, they can expose you to bad things if they don't check stuff out themselves).

atszyman
Jan 23, 2009, 09:32 AM
Apple themselves tell developers to /not/ use installers whenever possible for a mix of security and other reasons. Just dragging a .app file over to Applications won't expose you to this attack (unless you then stupidly give it admin privs when it asks, and it was a trojan app to begin with).

Now I'm not an expert in programming, installers, or the like, but I do know that a .app file is really a folder with all kinds of underlying pieces including the true executable. If someone wanted, could they not go in and create a script/program with the correct executable name that calls their malicious code and then launches the renamed executable file thus bypassing the installer stuff?

I'm sure it would still probably need to be authenticated before it could truly cause a lot of damage, but for users who run as admin, or think they're immune they might not catch that they shouldn't have to give the .app admin privileges to run.

Krevnik
Jan 23, 2009, 09:47 AM
Now I'm not an expert in programming, installers, or the like, but I do know that a .app file is really a folder with all kinds of underlying pieces including the true executable. If someone wanted, could they not go in and create a script/program with the correct executable name that calls their malicious code and then launches the renamed executable file thus bypassing the installer stuff?

I'm sure it would still probably need to be authenticated before it could truly cause a lot of damage, but for users who run as admin, or think they're immune they might not catch that they shouldn't have to give the .app admin privileges to run.

There is a difference between an admin user, and admin privileges on OS X, Linux and Windows Vista/7.

This is the reason why you still have to give username/password for an installer, even as an admin user. You don't actually have permission to write files to the startup folder and any other system folder (other than /Applications) without elevating.

And you are right about the .app bundle. This isn't impossible on other systems either. However, as long as they can't elevate, the damage a trojan can do is limited to the running user, and any process will be killed when the user logs out. Makes it hard to run a botnet if you require them to run your modified executable every time. You can't run things like keyloggers or other juicy things the botnet owners want without getting elevated. The potential of modified binaries getting distributed is the reason why I kept talking about trust in the other post as well. You have to be able to /trust/ the source of the binary. With anonymous P2P, we've yet to learn there is no such thing. You can choose to trust it, but how do you know to trust it beyond a leap of faith? We give P2P too much trust because we don't look at the risks beyond the immediate monetary risk (like we would when dealing with a company asking for money for a product).

Put simply, unless:
- The trojan uses an elevation exploit in the OS.
- You elevate the trojan for it.

It cannot get into your system in such a way that lets it turn into a keylogger that always runs the moment you turn on the machine. This is why it is so important that Apple fix elevation exploits ASAP (and I do wish they would do a better job here).

atszyman
Jan 23, 2009, 12:50 PM
And you are right about the .app bundle. This isn't impossible on other systems either. However, as long as they can't elevate, the damage a trojan can do is limited to the running user, and any process will be killed when the user logs out.

But assuming that the user just downloaded the app and it's their first run, they might not pay extremely close attention to the login dialogue box, should it appear, and thus elevate the malicious code, upon subsequent running most users would notice the repeated dialogue box unless the malicious code removed it's launching from the app bundle.

I realize that to most this behaviour would be much more suspicious to some users than the installer method for distributing apps, but it would be a workaround to bypass the installer and infect the machines of those who don't pay enough attention.

impierced
Jan 23, 2009, 01:09 PM
But assuming that the user just downloaded the app and it's their first run, they might not pay extremely close attention to the login dialogue box, should it appear, and thus elevate the malicious code, upon subsequent running most users would notice the repeated dialogue box unless the malicious code removed it's launching from the app bundle.

I realize that to most this behaviour would be much more suspicious to some users than the installer method for distributing apps, but it would be a workaround to bypass the installer and infect the machines of those who don't pay enough attention.

True, but when an application prompts for administrative privileges I always to a double take. Though I've noticed Adobe Reader and Real Player doing this to add their internet plug-ins and I cringe each time.

It's so incredibly easy (too easy?) to add a .pkg (package) file to a .mpkg (multi-package) and have it be executed as part of the installation. I've done it before in our corporate environment to apply patches, custom fixes, to bad installers. However, there should really be a checksum from the mpkg that at least brings up a dialog box warning about the inclusion of a foreign .pkg.

Krevnik
Jan 23, 2009, 01:12 PM
But assuming that the user just downloaded the app and it's their first run, they might not pay extremely close attention to the login dialogue box, should it appear, and thus elevate the malicious code, upon subsequent running most users would notice the repeated dialogue box unless the malicious code removed it's launching from the app bundle.

I realize that to most this behaviour would be much more suspicious to some users than the installer method for distributing apps, but it would be a workaround to bypass the installer and infect the machines of those who don't pay enough attention.

You are right, it could be. And I could flip heads constantly on a coin.

The problem really starts becoming an issue when apps start asking for admin privs to install files on first launch regularly. Bad mojo. It is one of the big strikes I have against TextMate right now is that it doesn't /need/ admin access to setup the link it wants to, but does it anyways on first launch. If more apps follow TextMate's lead, your scenario becomes more and more plausible.

The best a programmer can (and should be doing) is reducing the amount of opportunities for the user to get confused and think risky behavior is normal. So it means things like not using installers when you don't have to (since it is normal for installers to ask for elevation, and adds risk), not elevating when you aren't a system tool, start shipping code-signed bundles if you store passwords in the keychain so that a malicious version with a trojan can't get access to those stored passwords, and so on.

But, at some point, you have to be willing to shrug and let user error be user error. If they want to enter their password to any app that asks for it, there are consequences for it. While it would be ideal to prevent all of it, you can't really close the "Well, it wanted admin privs and I gave consent" hole. What you can do is reduce the opportunities to make users think it is normal to give consent for an app to elevate. Which is why installer packages should be more limited to system-level bits than it currently is. Still worlds better than the security sludge I have to think about and dredge through as part of my daily Windows work.

EDIT: As an aside, this is still why I keep harping on trust. You cannot fix users who do risky things by over-engineering the software. You cannot 'fix' the risky behavior of sex with random partners with a condom. You can lower the risk, but the /best/ answer to both STD and computer virus propagation is to be aware of who you interact with. We take many more risks online than we would in real life, partly because we don't understand the consequences, and consequences do come after the fact, making it difficult for people to learn what the mistake was. At some point we have to stop harping on the software to do the thinking for us and start figuring out how we can develop trust in an anonymous world.

atszyman
Jan 23, 2009, 01:32 PM
The problem really starts becoming an issue when apps start asking for admin privs to install files on first launch regularly. Bad mojo.

...

So it means things like not using installers when you don't have to (since it is normal for installers to ask for elevation, and adds risk), not elevating when you aren't a system tool, start shipping code-signed bundles if you store passwords in the keychain so that a malicious version with a trojan can't get access to those stored passwords, and so on.

...

But, at some point, you have to be willing to shrug and let user error be user error.

...

EDIT: As an aside, this is still why I keep harping on trust.

I completely agree with everything you said, of course if you only deal with trusted sources all the time, the installer versus drag and drop, shouldn't matter.

I love the drag and drop, and to me it's the only way a (non-utility) application should ever be distributed. Even for Windows. I hate when an application has to put files in a dozen different locations to run, I'd rather have the app create it's own directory structure so that it knows where all of it's own files are, and where they should be for access. I don't care if I have 600 coppies of a 5k .dll on my machine because every application needs it, disk space is cheap, and the knowledge that when I drag the application's directory to the trash that it's all gone is very nice indeed.

Krevnik
Jan 23, 2009, 01:43 PM
I completely agree with everything you said, of course if you only deal with trusted sources all the time, the installer versus drag and drop, shouldn't matter.

I love the drag and drop, and to me it's the only way a (non-utility) application should ever be distributed. Even for Windows. I hate when an application has to put files in a dozen different locations to run, I'd rather have the app create it's own directory structure so that it knows where all of it's own files are, and where they should be for access. I don't care if I have 600 coppies of a 5k .dll on my machine because every application needs it, disk space is cheap, and the knowledge that when I drag the application's directory to the trash that it's all gone is very nice indeed.

Agreed. Windows is currently a soup of risky behavior. If the normal avenue of service exploits and other true security holes get closed up, services sandboxed and all that good stuff, expect the bad guys to rely on social engineering instead. With Vista and UAC, the number of 'allow/cancel' dialogs is just at the point where you train users not to care at all. I don't even care much anymore about my dev machine. It is just so intrusive to my work I just want it to go away.