SecureMac identifies first ARDAgent-based trojan
SecureMac has identified AppleScript.THT, a trojan-horse type virus of malware that exploits a Apple Remote Desktop Agent vulnerability publicized earlier this week that can "allow a malicious user complete access to the system."
The malware is distributed as a compiled AppleScript, named ASthtv05, or an application bundle named AStht_v06. The files are 60K and 3.1MB in size, respectively.
Users must download and run the scripts in order for their computer to become infected. The trojan will install itself in the /Library/Caches folder, and will set itself to run at startup.
To protect yourself, use extreme caution when running AppleScript files or applications sent to you in an email, or downloaded from the internet.
While we can't say for sure that these are the same people that developed this malware, you can read about the evolution of a very similar exploit script here, including a June 14th mention of the ARDAgent vulnerability. Very depressing.
Share
Categories
SecureMac has identified AppleScript.THT, a trojan-horse type virus of malware that exploits a Apple Remote Desktop Agent vulnerability...
Add a Comment
RobK: I agree that I should have added a warning about not running Repair Permissions until this is officially fixed by Apple. My bad. Thanx.
I also agree that perhaps clearing the "sticky bit" that allows the dangerous "setuid" functionality to happen with ARDAgent could POSSIBLY be a better solution. For those of you out in TV Land that are now more confused than ever, you can apply the fix that RobK suggests by opening up Terminal, and typing the following (all on one line):
sudo chmod 755 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
Then press Return.
Enter your password and press Return.
Then Quit the Terminal.
As for your suggestion to "hide" ARDAgent, that is not a practical solution for many people who depend on ARD to administer multiple Macs in educational and corporate networks, or just plain folks who want to use ARD.
By the way, Apple allegedly changed the way "setuid" works in Leopard, such that something that wants to run a "process" as the "owner" (root, in this case), cannot just rely on the setuid bit. Instead, they must call a "function", called "setuid()". I don't run Leopard, so I cannot confirm or deny this.
Until Apple patches this vulnerability, there are 2 fixes. Take your pick. Both work:
1. Don't leave your machine with a user logged in, or at least without an "Administrative" user logged in.
OR
1. Launch the "Terminal" app.
2. Enter the following incantations:
cd /usr/bin/
sudo chmod 550 osascript
(now, enter your password and press return)
Quit the Terminal. Fixed!
What that bit of Sorcery did was to block ALL access to "osascript" for any user that is not "root" (which even an Administrative-level user is NOT), or is not a member of the group "wheel" (which your user is NOT). This does NOT affect Apple Remote Desktop in any way.
If you have any problems with this (you shouldn't), simply repeat the steps above, with "555" in place of the "550". That will restore the original permissions.
You can make sure your change happened by typing the following into Terminal:
ls -ld osascript
At the left-hand side of the resulting output from the "ls" command, it SHOULD look like the following (after the chmod 550, above):
-r-xr-x--- 1 root wheel 91536 Mar 20 2005 osascript
If you were NOT successful, it will likely return the default permissions, which will look like:
-r-xr-xr-x 1 root wheel 91536 Mar 20 2005 osascript
The difference is in the last 3 characters, which define the permisions for "everyone else" (other than the "owner" and the owner's "group"). Before the "chmod 550", "everyone else" had the same permissions (read (but not write), and "execute").
And when Apple officially fixes this (probably in the next security update), I would recommend changing osascript's permissions BACK to "555" BEFORE downloading their official patch.
There is a problem with your solution. If one runs "Repair Permissions" the permissions on osascript will be restored so that all users can run osascript.
Of course the solution is NOT to run Repair Permissions until Apple fixes the problem.
But if you are going to change permissions why do it on osascript and NOT on the file with the problem ARDAgent. I would just remove the setuid bit on ARDAgent and you will be safe until someone does a "Repair Permissions". At least that way others can still use osascript and you won't break other apps that use it.
A better solution would be to tar up the ARDAgent.app application (which really looks like a directory to the tar command). Then no one can use ARDAgent. Repair Permissions will not restore it.
When Apple releases a fix you can untar it. But why do that unless you really use ARDAgent.
Folks, this isn't a virus or malware this is a "hey dumbass, please install or run this script on your computer"
There is NOTHING you can do at the OS level from stopping someone from doing this.
You've been able to do this on Mac's, Windows, Linux, HP-UX for years.
I guess that's an advantage to being double NAT'd. If back to my mac won't work, neither would this.
Why do people think Macs are magically immune to hacks, exploits, trojans and malware? They aren't, there just aren't as many people targeting OS X because it's a very small percent of the market share. Once OS X becomes more mainstream we'll all be using some kind of Anti-Virus app on our Macs - it's inevitable.
June 20 2008 at 12:23 PM Report abuse Permalink rate up rate down ReplyIt is interesting that almost ALL of the recent critical security exploits were found on Apple developed software (not on all the Open Source *nix software underlying Mac OS X).
It sounds like Apple needs to pay more attention to security issues when developing and releasing its own applications. When will Apple take security more seriously?
When Apple's OS gets hit hard by a nasty, self replicating worm.
June 20 2008 at 11:14 AM Report abuse Permalink rate up rate down ReplyYou should probably mention the temporary "fix" in the post, turning *ON* ARD seems to prevent the sample 'whois' script from running.
June 20 2008 at 9:56 AM Report abuse Permalink rate up rate down ReplyTom, my original post about the vulnerability (linked at the top of the post) included the ARD-on workaround. Unfortunately it's been demonstrated that turning ARD on does not confer full protection, as it's possible to kill and respawn the ARDAgent process quickly to force it to launch with setuid.
June 20 2008 at 11:39 AM Report abuse Permalink rate up rate down ReplyMacintosh and Linux OS are more secure because they are better thought, but the truth is that there is little malware because the "developers" don't have interest in doing it.
If either Linux or Mac where so spread as Windoze we would have tons of malware by now.
Mac and Linux are more secure because none of their users run as root. 99% of Windows users run as root, and therefore all programs they run have root privileges (just like this nasty ARDAgent vulnerability).
June 20 2008 at 10:00 AM Report abuse Permalink rate up rate down ReplyI use both OS X and Linux. Debian about 95 percent of the time and Ubuntu or RedHat for the remainder.
Aside from the fact 'all' these platforms are secure by design they have a chance to compromise a system when a user's web surfing or other personal habits allow them to.
At my former job as a systems administrator at a community college, I now work as a systems administrator at a university, I found the computers which had the greatest risk of compromise in open labs was 'porn' rows. These were usually computers sitting away from an instructor in the back of class.
Before software like 'Deep Freeze' my Windows machines, regardless of how tightly I managed the policies, basically the 'porn row' machines were useless.
My Linux and OS X machines have over the last three years at the university have yet to be compromised. I manage them just like I do a Windows machine.
Will I get hit sooner-or-later? The probability exists. Will it be as damaging as java or activex exploits on the Windows boxes. Probably not. OS X and Linux boxes are generally good citizens on the network.
and you still have to activly download and run the trojan for it to work
June 20 2008 at 6:59 AM Report abuse Permalink rate up rate down ReplyUnlike the trojan last month that had to ask the user for his/her root password before it could do damage. Any application that can execute Applescript can immediately without warning compromise your machine, or do something malicious.
Coupled with another exploit in another application, like for instance, Safari, were screwed.
I have used Macs for 20 years now, and had a virus once, at least 15 years ago. It deleted entire lines of code from all the high resolution files. Nasty. At the time, because macs were relatively slow, I worked largely with small images until sending the files to repro for high res files to be added, so the damage was minimal. Imagine the damage it would do now. Scary, especially losing all my digital photographs.
June 20 2008 at 6:51 AM Report abuse Permalink rate up rate down ReplyHot Apps on TUAW
Deals of the Day
more deals- Altec Lansing Octiv Duo iDock for $48 + free shipping
- Used Apple iMac 17" Core Duo 1.83GHz for $430 + $28 s&h
- Lounge Deluxe Stand for iPhone / iPod touch for $28 + $8 s&h
- Brookstone Surround-Sound Earbuds for $14 + $7 s&h
- Refurbished Skullcandy Tokidoki Smokin' Buds Mic'd Headset for $5 + $2 s&h
- Stitchway Backup Battery for iPod / iPhone for $5 + free shipping
Software Updates
more updates- EFI Firmware Update brings Lion Internet Recovery to 2010-model Macs
- OS X Lion 10.7.3 released with Safari 5.1.3, Wi-Fi bug fix
- Aperture updated to 3.2.2, addresses Photo Stream issue
- Apple updates Keynote to address Lion issues
- Google Search app gets new look on iPad
- Apple releases Apple TV Software Update 4.4.3



32 Comments