More on the Mac OS X type/creator, .extension "trojan horse"
Continuing our coverage of the MP3Concept (MP3Virus.Gen) potential vulnerability - which exploits a weakness in Mac OS X where applications can appear to be other types of files - we have a new folder action which checks for correspondence between a filename's extension and the type/kind.
MacFixIt reader Rick Bargerhuff writes "Simply attach the folder action to the folders where your downloads go to. The following is a comment I posted under the comment section on this article.
"This 'alert' has always existed in the Mac OS but has been under the radar for a long time until now. So I decided to code a Folder Action which I hope will ease Mac user's minds.
"The Folder Action will check any files or folders to see if a file's name- extension corresponds to the file's Type and kind. If it does not meet this criteria, the script asks the user if they want to quarantine the file. If the file does not have an extension and the file's type and kind indicates it is an application, the script acts as if the file did not meet the criteria. If the user chooses to quarantine a file, the script creates a folder named 'Quarantined' which is created inside the directory the Folder Action is attached to. More info is available in the read me."
The folder action can be downloaded from http://home.comcast.net/~c0ugar/files/Mismatch.sit.
Restricting application usage In order to prevent unsuspecting users from launching potentially harmful false MP3 files, MacFixIt reader Jack Pate suggests simply restricting application launch capabilities to a certain folder - namely the default /Applications directory.
"To nip this while thing in the bud, simply change the "limitations" of all your users to only applications in the Applications folder (and OS9 Apps, if applicable. . . ). It's is an easy 'check-box' setting, and should TOTALLY eliminate the threat, because it would prevent any executable code from being run outside these apps, while still allowing .sit files to open normally and EVEN 'real' MP3 files, because it would be launching a qualified app in the approved folder to play it."
OpenOSX Publishes Free TrojanDefuser Meanwhile OpenOSX has announced the immediate availability of TrojanDefuser, offering users "drag and drop operation that will render files suspected of being the recently discovered variations of the Trojan Horse 'MP3Virus.Gen' harmless, by making a copy of the suspected file without the resource fork, therefore eliminating the potentially malicious code and at the same time preserving the data fork of the file."
"If the software detects a potential ?Trojan Horse?, a copy of the file(s) that are suspect will be created in the same location as the original(s) starting with the prefix "SAFE_", ending with the original file name and leaving the original file intact. For example a ?disinfected? version of "virus.mp3" would become "SAFE_virus.mp3"". The tool is available for free download from http://OpenOSX.com/support/
Users finding suspicious files Via the methodology listed in Friday's edition, users are finding some strange files - oddly coming from Apple's own distribution.
Terrell Smith writes "I did a search in Finder on my HD for any file "Name contains .mp3" and "Kind: Application," and was surprised to discover that the old iTunes Sampler that came with the original iTunes has a file called "Max Graham Airtight.mp3" which is also a Classic Application. Creation date is Jan 22, 2001."
Symantec posts LiveUpdate file The update for Norton AntiVirus from Symantec encompassing the MP3Concept flaw has been posted via the company's LiveUpdate mechanism.
There is also a manual download link for the new definition.
As posted to Symantec's Web site: "MP3Concept is a proof-of-concept Trojan targeted at the Mac OS X platform, that is currently not seen 'in the wild.' It is not spreading or infecting Mac users. The proof-of-concept program does not contain any malicious payload such as viral code, ability to email itself or perform destructive functions such as deleting files. It only contains code to display a message box and mp3 audio data of a man laughing."
Feedback? Late-breakers@macfixit.com.
Resources
(a) The file has no extension, but still looks like an MP3, JPG, etc.
(b) The file has an .app extension, which the users can't see (even if they turn on file extension viewing)
(c) The file looks like it has an extension of .mp3 (or whatever), but the dot isn't a classic period but some other character (a comma in the simplistic form, which most people won't notice is not a period) followed by a .app extension (which the user won't see).
In all these cases, the file will look just like a file, but will run as an app.
No matter how you cut it, this whole thing is still a whole lotta hype about nothing (or, at the very least, nothing new). Let's get serious here. This concept has been around for a decade or more. Its never been tried on a big scale, to the best of my knowledge, but has been fairly well known.
Remember, the worst trojan seen so far has actually come from Apple themselves. iTunes v2.0 installer had a nifty built-in feature of deleting your entire hard drive if you dared do something stupid like have a space in the hard drive's name. (Well, and some would call OS X.3's firewire problems another trojan or virus, but that's neither here nor there).
Wake me when some real news occurs.
LouZer said:
The folder action only applies if you have (a) a file with a file extension not
.app, and (b) has a type code of APPL. It won't apply if:
(a) The file has no extension, but still looks like an MP3, JPG, etc.
(b) The file has an .app extension, which the users can't see (even if they turn
on file extension viewing)
(c) The file looks like it has an extension of .mp3 (or whatever), but the dot
isn't a classic period but some other character (a comma in the simplistic
form, which most people won't notice is not a period) followed by a .app
extension (which the user won't see).
In all these cases, the file will look just like a file, but will run as an app
Incorrect on all counts. The folder action isn't restricted to the Finder's view
of the landscape, which should have been apparent given the script's ability
to check Type codes (which the Finder Never shows the user). Given this,
your points (b) & (c) are incorrect. The info available for any given file
includes a weath of information, not the least of which is the actual file
extension applied to the file, regardless of the Finder's (and, therefore, the
User's) ability to see it. Furthermore, had you read the description carefully
(or bothered to look at the source AppleScript code), you'd also know that the
folder action treats APPL files without extentions as Suspect. That's not to
say that it's bullet-proof, but...
Do try a teensy bit of forensics before posting this type of response.
I'll grant you that it will handle non-extension files. But I still don't see how it handles files ending in .app? You can't see these extensions in the Finder, so the user can't tell these are applications or not by just looking at them (without having to look at info or the kind column in the finder). Your script will ignore these (not that I can read applescript) because they do have an extension of .app. or is your script basically set up to tell you just whether a file is an app or not an app (which would have been simpler than trying to map things against a file extension and checking type codes)?
My point is, if the file is a .app, but has no type code (.apps generally don't), then there's no protection unless it assumes ALL files are unsafe.
Second, how does it handle shell scripts?
The script uses AppleScript's 'info for' command, which returns a record of
several attributes. When 'info for' is called on (for example) Chess, this is
what is returned for your use:
name:"Chess.app"
creation date:date "Saturday, September 27, 2003 4:30:32 AM"
modification date:date "Saturday, September 27, 2003 4:30:32 AM"
icon position:{0, 0}
size:3.5839E+6
folder:true
alias:false
name extension:"app"
extension hidden:true
visible:true
package folder:true
file type:"APPL"
file creator:"mbch"
displayed name:"Chess"
default application:alias "HardDrive:Applications:Chess.app:"
kind:"Application"
short version:"2.0"
long version:"Chess Version 2.0, Copyright 2003 Apple Computer, Inc."
bundle identifier:"com.apple.Chess"
The folder action uses information in this record to determine what is an app
and what isn't. Pretty reliable for ID purposes, though there are things that
can be slipped past the casual user.
<more to come>
As for Unix Executables, I got this info on the 'jar' executable in my Java 1.4.1
folder:
name:"jar"
creation date:date "Tuesday, April 6, 2004 9:35:51 AM"
modification date:date "Tuesday, April 6, 2004 9:35:54 AM"
icon position:{0, 0}
size:3.624E+4
folder:false
alias:false
name extension:missing value
extension hidden:false
visible:true
package folder:false
file type:""
file creator:""
displayed name:"jar"
kind:"Unix Executable File"
locked:false
busy status:false
short version:""
long version:""
The folder action would ignore this file, though a quick mod to the 'kind' test
would take care of that. Keep in mind that Unix Executables won't have
resource forks, and the exploit that triggered this whole thing requires a
Carbon application (ie: resource fork and APPL file type). Interestingly, the
file type and creator codes (universally 4 characters each) on this file consist
of four ASCII zeros, even though they appears here as simply "". The actual
dangers of Unix Executables are beyond the scope of my current knowledge,
but I'm working on it. ;o)
Anyone?
Hey Doug,
If you think it would be a good idea to make it so Unix Executables are found,
let me know.
Thanks
I certainly don't think it'll hurt, though I really think this sort of spoof ought
to be handled by the Finder when the file is double-clicked. Same premise as
your script, but different. ;) If it is an application with an extension, the
Finder should know when the two are mismatched and respond with an alert
when it's launched. Or something.
But like I said, I'm not sure how (or if) a Unix Executable can have a resource
fork and a media extension... Time to do some reading.
Nice work, BTW. Thanks for the effort.
I'm told that this method of a Trojan could work with extensions other than
APPL - for example, an appe could run as well. Any thoughts?
Carbon apps have no extension. Everyone has carbon apps.
The Finder seems to display any app name with a extra . in with the .app (so
making a trojan.mp3.app would show trojan.mp3.app). However,
1. I can call it MySong.app, and it will show as MySong. I can also call it
MyPicture.app (or NakedLesbians.app) or ReadMe.app. Either you catch all
.apps, or none of them.
2. There are a few dot-characters in unicode; the closest (i.e. most believable)
is probably 0x2024, "ONE DOT LEADER" (add "character palette" to your
keyboard menu, view: unicode, unicode blocks, basic latin, click the period.
click the 'character info' triangle, it will be one of the 'related characters').
This way, I can call it MySong,mp3.app (replace , with ONE DOT LEADER), and
it will look like "MySong.mp3".
This game of fooling people (windows doesn't show extensions by default,
MySong.exe with an mp3 icon would work for a lot of people) will only end
when OS X only allows launching of apps with .app (and shows it to you) or
displays a warning and tells you to authenticate apps first (this is the better
way).
And in windows, shortcuts (.lnk) appear to have no extension too, so you can
make a mysong.mp3.lnk with an mp3 icon, which runs "deltree c:\". You just
hope nobody notices the shortcut arrow.
First, how does one restrict application usage to the app's folder? The reader says its just a click of a box, but where's the box? Netinfo? System Preferences? Get Info window?
Second, what type of scanning did NAV include in their app? Is it specifically looking for this code signature? Is is tied to MP3 concepts (where updates would be needed for the first JPG or MP3 variant)? Is it tied to the extension vs. type check? Is it something else?
You can restrict the abilities of a user through the "Accounts" pane of System
Preferences.
You can only restrict the abilities of non-admin users, however.
If you really wanted to be able to do this with an admin user, I imagine you
could change their group ownership, and subsequently change the group
modification rights to all related files. That's too much trouble for me to work
through, however, so it's left as an exercise for the reader.
I updated the Folder Action because it had a BUG that wasn't it allowing to
find a suspicious file nested inside a group of folders, for example...
~/Desktop/Mismatch/virus.mp3\ folder/VIRUS1/VIRUS2/VIRUS3/virus.mp3
The download link now reflects the current version.
Thanks - cougar
unkillable warning dialog. thanks for the good work other then that it seems
cool.
uber
Hello Uber,
I contacted you via Email but I guess it has not reach you yet. Your
explanation does not make sense because if you unstuff the archive from the
folder with the Folder Action attached to it, it finds the file and asks if you
want to quarantine it. Simply choose "Yes" or "No" from the dialog. I have
been able to reproduce an "unkillable" dialog like you have described.
Rick
- by Wild West Studios April 12, 2004 6:35 PM PDT
- <class="merchant"><span>></span><div class="datestamp"><i>This is a reply to a previous comment by FriscoFrog</i></div></class><br />
- Like this Reply to this comment
-
(16 Comments)Yeah I found the same thing. I'm also running 10.2.8 and it does not
work for me, either. Hopefully it is a simple fix.