“AS.MW2004.Trojan – that affects Mac OS X. This Trojan horse, when double-clicked, permanently deletes all the files in the current user’s home folder. Intego has notified Apple, Microsoft and the CERT, and has been working in close collaboration with these companies and organizations,” Macworld UK reports.
“The AS.MW2004.Trojan is a compiled AppleScript applet, a 108 KB self-contained application, with an icon resembling an installer for Microsoft Office 2004 for Mac OS X. This AppleScript runs a Unix command that removes files, using AppleScript’s ability to run such commands. The AppleScript displays no messages, dialogs or alerts. Once the user double-clicks this file, their home folder and all its contents are deleted permanently,” Macworld UK reports.
“Intego advises all Macintosh users to only download and run applications from trusted sources. However Intego has updated its VirusBarrier X software to address this vulnerability. Intego VirusBarrier X eradicates this Trojan horse, using its virus definitions dated May 11, 2004, and Intego remains diligent to ensure that VirusBarrier X will also eradicate any future viruses that may try to exploit this same technique. All Intego VirusBarrier X users should make sure that their virus definitions are up to date by using the NetUpdate preference pane in the Mac OS X System Preferences,” Macworld UK reports.
“[According to Intego] Nothing prevents users from creating other, similar AppleScripts, with different names and custom icons that can run the same damaging command. The current version that is in the wild only deletes a user’s files and folders. Other such commands could attempt to delete all the files on a Macintosh computer running Mac OS X, but they would need to request an administrator password. However, users may not hesitate to type their administrator’s password for what they think is an installer; after all, Apple’s Installer requires this password to install any applications and updates to Mac OS X,” Macworld UK reports.
“[According to Intego] This Trojan horse highlights a serious weakness with Mac OS X. Since it is built on a Unix foundation, it can run powerful commands very easily. These commands can delete or damage a user’s files with no warning, and AppleScript offers no protection against malicious commands,” Macworld UK reports.
Full article here.
MacDailyNews Take: Intego is the company that, just over a month ago, trumpeted a so-called Mac OS X Trojan horse which turned out to be exaggerated FUD designed to sell security software – basically a non-issue. And this “trojan” supposedly comes with a Microsoft Office icon, of all things! So forgive us for being just a tad skeptical. We swear we just heard someone cry “wolf?” Maybe we’re hearing things.
This makes us wonder who would’ve released this in the wild via P2P file sharing networks, if it’s true? What would the creator(s) have to gain? What companies would have the most to gain? Interesting questions to ponder. But, hey, at least they used AppleScript!
In case you’re guessing, color us unconcerned, bored, or blue with pink spots for all we care about this. Just in case, and because we can, we post this story for your use. Enjoy.
Reminders:
1. don’t click it if you don’t know where it came from or what it is.
2. Microsoft wants you to buy Office for Mac, not download it for free. (Please note that MS Word is not, nor has it ever been, 108 KB)
3. Intego wants to sell you “VirusBarrier X.”
Throw all three in a blender, mix, and see what you come up with – we think it’s called “Intego-Schmintego.”
Related MacDailyNews articles:
Mac OS X so-called Trojan horse ‘exaggerated FUD to sell security software, a non-issue’ – April 10, 2004
Joel, actually there is a way to force to use the script but it is more invasive and requires changes done as root. Then rm (even from the Applescript) would be nurtured. I hesitate to do this, so I am not recommending but I also said Mac users should get exposed to Unix and its power. Follow me and do it if you feel confident and always do a ‘man <command>’ to learn about it on the terminal.
rm and other shell builtins are essentially no more than shell scripts. You may alter them or substitute them.
Type ‘type rm’ on a terminal, this shows the location of it, you should get:
$ type rm
$ rm is hashed (/bin/rm)
There is where ‘rm’ leaves (with other builtin commands). Now a very little trick that shows the power of control you have on a Unix machine (ie OS X).
Read till end before trying (#statements are my comments, do not type them on the terminal):
# go where ‘rm’ lives
$ cd /bin
# we are going to change ‘rm’ to something else
# for that we check we are not overwriting anything, say we will call ‘rm’ as
# ‘remove’ instead, or any other meaningful name for you
$ type remove
-bash: type: remove: not found
# good, no command named ‘remove’ does exist
# change ‘rm’ into ‘remove’. System asks you to identify as root
$ sudo mv rm remove
Password: �������������������
# create an empty file on your home directory
$ touch ~/killme
# try to remove it with ‘rm’ as would the script do
$ rm ~/killme
-bash: /bin/rm: No such file or directory
The script would not work: ‘rm’ is now ‘remove’. But we probably do not want to do that, we want ‘rm’ act more safely, say as the trash script of my previous link. First lets try a little experiment:
# make ‘rm’ again present on the system but be a name for ‘ls’, to list files
# instead of deleting them
# the following creates a symbolic link to ‘ls’ named ‘rm’
$ sudo ls -s ls rm
Password:�����������������
# show that it does now exist
# the ‘@’ character should not appear on your terminal: is part of my config
# to mark sym links
$ ls rm
rm@
# on your system it would show like:
$ ls rm
rm
# now try the *new* ‘rm’
$ rm ~/killme
/Users/<youraccount>/killme
# as you see now ‘rm’ is as synonyme for ‘ls’ : it simply has listed ~/killme
#now you say you want to have your script for the trash-remove act as ‘rm’
# use the *old* ‘rm’ which is now ‘remove’ to delete the symlink
$ sudo remove rm
Password:���������������
# use again the ‘ln -s’ command to have ‘rm’ be a symling to the trash-rm
# script
$ sudo ln -s <the trash-script location> rm
Password: �����������������
# try the *new* ‘rm’, should now execute the script, as well from the
# Applescript. (the Applescript would also fail if you simply keep ‘rm’ named
# as ‘remove’
Caveat: you may harm your system if you mistype things and do not know what you do. Use ‘man <command>’ to learn a bit about commands and buy a book on Unix. Tiger is coming: unleash fully OS X power.
Acc: A TYPO: THE ABOVE
# the following creates a symbolic link to ‘ls’ named ‘rm’
$ sudo ls -s ls rm
Password:�����������������
should read:
# the following creates a symbolic link to ‘ls’ named ‘rm’
$ sudo ln -s ls rm
Password:�����������������
the typo is safe, what you get instead is:
$ sudo ls -s ls rm
Password: ����������������
$ ls rm
ls: rm: No such file or directory
the above ‘ls -s’ display the number of file system blocks actually used by each file. Hence the typo does not change the system but shows that you have to be careful and know how to restore things back in case of mistakes.
The command for creating links is ‘ln’; do ‘man ln’. ‘ln -s’ creates a symbolik link.
Mac User 47 – We probably agree on lots of things, but are fundamentally opposed in some. It’s a pretty normal state of affairs.
I won’t mention the ‘C’ word f you don’t
” width=”19″ height=”19″ alt=”wink” style=”border:0;” />
Since we’d started “imivation”, let me nominate a new word to the lexicon:
“Integoize”
verb: to spread false, misleading, or malignant rumours in order to intimidate the public into purchasing useless goods and services. Used most often in the pharmaceutical and software industry.
Usage examples:
1. “I was ‘Integoized’ into buying a drug I didn’t need because their ads convinced me I had an imaginary disease.”
2. “Security experts demonstrate new virus hoax rumour is an effort to ‘Integoize’ public into purchasing useless antivirus software”
So spread it around, soon enough everyone will use it, it’ll end up on the top of Google’s list like “Santorum” … teehee
I saw lot’s of stupid affirmations on this list.
Fortunately, some people know what they speak about and do not just make assumptions.
Thanks Hywel for the definition of a Trojan.
iMike, you should use another world: Macworldize
If you can read, read this:
http://www.macworld.co.uk/news/main_news.cfm?NewsID=8664
By the way, pretending that antivirus software is “useless”, is the same as pretending that there is no virus for Macintosh. This is not only untrue, this is irresponsible. You are inviting people to prove that you are wrong. And what is the best proof ?
MacDust wrote: “File Vault really is just an encrypted disk image”
This is wrong. Look at http://www.apple.com/macosx/features/filevault/ if you want to know more. When using file vault, data is encrypted in the fly and encrypted data is written to the disk. Using disk images is just like using another volume on your desktop. However, you can create encrypted disk images, and this has nothing to do with File Vault. (This can be done on any Mac OS X system version).
– Nobody wrote: “If anyone stupid enough to think 108KB (Kilobytes) file is an installer for Office 2004…”
– Did you here about web installers who are very small applications which download the real installers ?
Do you know that many Macintosh user’s are not experts and make no difference between 100 K or 500 K?
To MacDust who wrote “I wonder if this affects a user if they have File Vault enabled”:
File Vault prevents from other people being able to read your private data, not from yourself deleting it! And it’s what’s happening if you run a script like this “trojan”.
Now a question to those who attacked Intego:
Imagine that you are a company making and selling an anti-virus program.
You get a mail from Macworld informing you that a malicious trojan do exist on some P2P servers.
Macworld publishes an article about this. What would you do ?
Another stupid question:
Imagine: You heard about viruses for Windows, and discussions about viruses for Macintoshes. Some pretend they do not exist, others not. Anyway, you want to be on the safe side and you buy an antivirus program.
Then you read in the news that a trojan (what’s this?) has been found which deletes your home directory.
What would you expect from your antivirus program and from the company making it ?
Seahawk:
“Applescript should simply have an option to honor shell configuration files: that would keep the portability issue. I simply do not see any security factor in ignoring them – actually this example showed the opposite.””
This wouldn’t matter, the -f option overrides the -i option. Look it up by doing: man rm
So much for that idea. Besides, you cannot “honor” local configuration files because those local config files may do things that would cause problems for the shell script running.
One more point: as I described in detail in an earlier post here, DO SHELL SCRIPT and/or RM ARE NOT THE PROBLEM! You can delete files using ANY programming language. It takes very little knowledge to create Trojan Horses. The ONLY way to stop Trojan Horses is to not “invite them in.” Read the story about Troy. Hey, you could even watch the movie that’s coming out, I guess.
“this is Unix, not a weakness of OS X, as Viridian says”
Seahawk,
A point of correction: I certainly don’t see this as a weakness, and if you read my post again, you’ll notice that I never said that. I was questioning Intego’s ludicrous claim that it is a weakness.
Cheers
The question is: Regarding the fact that an Applescript can delete files with no warning, is this a weakness of Mac OS X ?
Or, considering the fact that, with an active option of hiding extensions for common file types, a Windows user could double-click a file thinking it is a text file where it was in reality something else, like the famous I love you VBscript , was this a weakness of Windows ?
I would say, in some way: yes, although the user should feel responsible if he uses non trusted applications…
By the way: Some people call this Word trojan “Word for dummies”…
But we should consider that many users of Macintoshes are no computer experts, and that it is actually the strength of Apple, to build computers which anybody can uses easily. Hence, I think that a Macintosh should remain as fool proof as possible.
Reminders:
1. The earth is not the center of the univers
2. If you go to the ocean, you will not fall down at the end
3. The earth is a sphere (almost)
Krioni: the configuration thing was not about that, was about having a trash-script running at the place of ‘rm’. The script ignores that but locally your configuration does not use the builtin rm.
Anyway, look out of curiosity about POSIX_STRICT. That makes -i and -f being mutually overriding. It is rumored that in the future ‘rm -i’ will be sticky and not overridden by a subsequent -f so that contrary to what happens now it will be ‘rm -i’ == ‘rm -if’ == ‘rm -fi’ that is ‘-i’ *stronger* than -f.
Apart from this I agree that this is not a weakness nor a security flaw of OS X nor a problem of Applescript. Although for unrelated reasons Applescript might have a preference to run a shell script as if it was run on a regular shell, ie in the same environment. Then you might have, eg, your own shell script as clickable on the desktop and execute them from there rather then only from terminal.
As you imply, it is a question of portability not security but not having Applescript capable of honoring – if needed – local configuration is, IMHO, a limitation.
Viridian: that is exactly what I meant by quoting you. Was not formulated well: should have been:
“this is Unix”, as Viridian says, not a weakness of OS X as Intego tries to imply.
Seahawk (and anyone else curious):
Go to:
http://developer.apple.com/technotes/tn2002/tn2065.html
Specifically, read the ‘Gory Details’ and ‘Issuing Commands’ sections.
This is Apple’s Technical Note on ‘do shell script’ and describes exactly why it cannot use your ‘local configuration file.’ There are different ones for different shell flavors. In fact, you can even change your default shell (the default in Jaguar and earlier was tcsh, in Panther it was changed to bash). Thus, configurations are different. Do Shell Script uses the basic ‘sh,’ although that is actually aliased to another shell.
Any other method would cause a lot of problems for developers, and would not actually make you any safer. This would be like saying that no one can lock the doors of their houses since that may slow them down leaving during a fire. Little help for much bigger downsides.
Please don’t try to refute what I’ve said without actually reading the Technical Note – it explains it better than I have, and makes clear why that is the correct path to take.
Krioni: I have read that and stand with my point. /bin/sh is nothing special, it points to tcsh in Jaguar and bash in Panther.
Apple explains the portability issues for chosing not to take into account the shell configuration files. They say nothing about security reasons.
I am not saying it would make it safer, I am saying it would not undermine security and make the use of shell in Applescript more powerful and that Applescript should have a preference setting.
As it is now I cannot use this features in that Applescript is not able to access my config files hence cannot use it to run my shell scripts that rely on what is present in .bash_login, .bash_logout, .bashrc, and .profile
They say the choice is for security and portability issues then the reasons touch only portability examples and/or details. Again, where in that document the ‘security’ issue involved?
Can you point it to me, ’cause I cannot see it.
…and don’t tell me it is because Applescript does not know what shell the user is using: it is an environment variable and Applescript can perfectly get that info.
“This is Apple’s Technical Note on ‘do shell script’ and describes exactly why it cannot use your ‘local configuration file.’ There are different ones for different shell flavors. In fact, you can even change your default shell (the default in Jaguar and earlier was tcsh, in Panther it was changed to bash). Thus, configurations are different. Do Shell Script uses the basic ‘sh,’ although that is actually aliased to another shell.”
From what you say I am not sure how much you know about how Unix works. The above is not an issue or a problem for the issue at hand. Configuration files for different shells can coexist. Shells do not read other shells config files, there is no risk of confusing the system.
As a matter of fact I have config files for both bash and tcsh, they are not the same, they are called differently, they configure the environment the same way so that whether I am with bash or with tcsh the system behaves the same and with same commands and allows to maintains shell scripts (and test them) for user with different shells but using the same application.
This is the reason why sw is distributed usually with both configuration setup scripts as ‘setup.sh’ and ‘setup.chs’ so that the sw would run the same whatever the shell family of the end user.
My guess is that Apple introduced ‘do shell’ in Applescript late 2003 and it is still under development.
“This would be like saying that no one can lock the doors of their houses since that may slow them down leaving during a fire. Little help for much bigger downsides.”
Actually it is like saying I do not know if some user have driving license and owns a car so I’ll make everyone walk for ‘security reasons’.
Seahawk:
Obviously you do know quite a bit about shells. Question: which config file should ‘do shell script’ use, then?
Either way, this whole question of whether it should read config files has nothing to do with the Trojan horse issue, since the ‘rm’ command is nothing special. Someone could easily write a little app in C or any other language that does the same thing.
Basically, the behavior of ‘do shell script’ is currently designed for consistency. Changing it might make some power-users happy, but wouldn’t help with security at all.
Krioni: from what Apple says ‘do shell script’ does not even read the system wide config files, for example /private/etc/bashrc . Those are there – for every possible shell known to OS X – so that users do not need to have local config whatever shell they use and they are in an established working environment. Minimally but sufficiently configured.
Tried to modify the system one that but ‘do shell’ did not notice so it looks like it is a builtin environment (and they say in the document what env it has access to). It looks pretty much fixed, a sort as minimum common denominator to ensure working conditions and portability, with the exception of environment variables.
” width=”19″ height=”19″ alt=”wink” style=”border:0;” /> )
Which is fine but a preference option could be fine as well. For portability the ‘do shell’ might have a command to say ‘do not use local configuration’ if needed for Applescripts to be distributed (like the Trojan
Anyway, we are out of topic here as all this, you realize that too, had nothing to do really with Trojan and/or security. It came out because it surprised me that ‘do shell’ had no way to inherit local env, not even as an option.
“Question: which config file should ‘do shell script’ use, then?”
Applescript – per Apple saying – has access to $SHELL, so it knows – if allowed to – what config scripts to honor whatever shell is used by the user.
so lets say someone was dumb enough to run this supposid trojan virus….and subsequently wiped out thier whole directory…is this data recoverable? just curious? pardon my ignorance…i’m just a kid