MacInTouch Reader Reports
 Ads     E-mail     Find     Home     Resources     Sitemap 


 

"Opener" Malware

  1. Oct. 22
  2. Oct. 25
  3. Oct. 26
  4. Oct. 27

  5. Part 2...
  6. Part 3...

  7. Links



Oct. 22, 2004

Opener Malware

MacInTouch Reader
There's now a real [malware program] out there for Mac OS X that can do some real damage. It doesn't seem to be too destructive although it does delete some UNIX commands and modifies prefs for a couple of others. It will gather all password info on your machine. For now, lets call it "Opener."

My system was a responding a bit slowly and a check of my /var/log files showed that they were _all_ empty and had the same mod date. The Activity Monitor showed a process called "john" eating almost an entire processor.

Some further looking showed an unknown startupitem in /Library/StartupItems/ called "opener". The executable file is a well-commented bash program. It scans for passwords for every user, processes the hashed info using your own Mac, turns on file sharing, and puts all this stuff into an invisible folder called .info on each users Public folder.

It does much, much more but it's important that a warning get out quickly.


Chris Waldrip

A quick Google search of "opener startupitems" revealed a thread at Macintosh Underground Forum Index -> Security & Hacking > Startup scripts.
Apparently this is a startup script whose development is ongoing. It does not look like something that can be maliciously installed, since the shell script can't be installed by just any user on a machine. Although I guess it could be installed secretly by a less than scrupulous shareware program.

My guess is that this started out with some legitimate purposes in mind, and it's been modified so that now it appears to copy itself to mounted volumes, and allows for several 'back doors'. Luckily most of this can be easily reversed. I'm not sure how this could be guarded against though.

For references this seems to be the initial comments in the script...

########################################################################
# opener 2.3.5a - a startup script to turn on services and gather user info & hashes for Mac OS X
########################################################################
# Originally written by DimBulb
# Additional code: hard-mac, JawnDoh!, Dr_Springfield, g@pple
# Additional ideas and advice: Zo, BSDOSX
# This script runs in bash (as is noted by the very first line of this script)
# To install this script you need admin access or
# physical access (boot from a CD or firewire/usb, ignore permissions on the internal drive) or
# write access to either /Library/StartupItems /System/Library/StartupItems or
# write access to any existing StartupItem (which you can then replace with this script) or
# write access to the rc, crontab, or periodic files (and have them run or install the script) or
# you could trick someone who has an admin account into installing it.
# It should go in /System/Library/StartupItems or /Library/StartupItems (when it is executed it
# will move itself to /System/Library/StartupItems)
# Since it is a StartupItem it will run as root - thus no "sudo" commands are needed. If you run
# it as any other user most of the commands will generate errors! (You could sudo ./opener)
# Save start time and date for performance testing

I've looked through the latest version of the script available online (2.3.8 it looks like), and here's a brief rundown about everything that this script does...

  • Opener tries to install ohphoneX, a teleconferencing program - for spying on you through your webcam I'm sure.
  • It kills LittleSnitch before every Internet connection it makes
  • It installs a keystroke recorder
  • Allows backdoor access in case someone deletes the hidden account
  • Grabs the open-firmware password
  • Installs OSXvnc
  • Grabs your office 2004 PID (serial number), as well as serial numbers for Mac OS XServer, adobe registrations, VirtualPC 6, Final Cut Pro, LittleSnitch, Apple Pro Apps, your DynDNS account, Timbuk2, and webserver users to name a few.
  • It tries to decrypts all the MD5 encrypted user passwords
  • Decrypts all users keychains.
  • Grabs your AIM logs, and tons of other settings and preferences with info you probably don't want folks to have... even your bash (terminal) history
  • Grabs stuff from your Classic preferences
  • Changes your Limewire settings to max out your upload and files.
  • The hidden user account is called LDAP-daemon instead of the name hacker used in earlier versions. Looks more innocent than hacker.
  • Even has your daily cron task try to get your password from the virtual memory swapfile
  • It installs an app called John The Ripper - a password cracker that uses a dictionary method to crack passwords
  • installs dsniff to sniff for passwords...

The last comments in the thread have them talking about adding VNC support, modifying parts of files w/out changing the date/time, adding to the list of files to grab info from, and talking about sending the info to an IRCbot. It looks like that least version discussed on this site was 2.3.8 and that was back in September. I don't know if they took their discussion off-line or if they were 'happy' with it. I'm betting the former.

I'm now actually a bit spooked.


Peter Gawlocki
This was posted earlier this year [March 28] ... Macintosh Underground Forum Index -> Security & Hacking > Startup Script Take a look at the file... and what it does. Note the second comment line.

# You need an admin level user name and password or physical access (boot from a CD or firewire, ignore permissions on the internal drive) to install this


Thomas Lundvall

I searched the Internet for other reports. What I found was very interesting. In April 2004, there was a discussion and exchange of code at Macintosh Underground. Here is the first couple of lines from that code.

##################################
# opener - a startup script to turn on services and gather user info & hashes for Mac OS X
##################################
# This script is written for bash (as is noted by the very first line of this script)

There is another discussion at that website titled "10.3.x Password Hashes & cracking success at last!" It discusses how to access passwords, and mentions hiding the program running.

Here are the 2 urls.
Macintosh Underground Forum Index -> Security & Hacking > Startup Scripts
Macintosh Underground Forum Index -> Cryptography > 10.3.x Password Hashes & cracking success at last!


Trevor Zylstra
I very much doubt that this is a virus. Much more likely is that a cracker has broken in to this person's computer and manually installed some programs. The "John" that is sucking up CPU cycles is probably John the Ripper: a well known UNIX password cracker.

If the user in question uses the same password for e-mail (which is sent in cleartext across the Internet) as he or she does for his or her computer, it is trivial to sniff the e-mail password and use it to log in to the computer via an open service such as telnet or ssh. Once able to log in, the cracker can install other programs with the same privileges as the logged in account.

If the scenario outlined above is what happened, this is not a weakness in OS X, it is simply poor practice on the part of the user, to use the same password for different accounts, one which is important (the computer user) and one of which is trivial to discover (e-mail).


Marc Ozon

'john' sounds like it's likely the John the Ripper password cracker, a common tool in the *nix world for checking the strength of passwords.

More to the point, the reader doesn't have any virus or malware, but rather that their machine has been compromised, and that person now has admin privileges on the machine. [after a bit of Googling] The 'opener' script the reader found is probably the one described and linked here: Macintosh Underground Forum Index -> Security & Hacking > OS X Rootkit - initial public release It's part of a 'rootkit' for OS X, i.e., software run by an attacker after they gain root privileges. The attacker might be a local user, or it might be someone who gained access via a vulnerable network service, program, or other system vulnerability. Besides john, it appears that it installs a network sniffing tool (for capturing passwords), and something called osxphone, for 'remote audio monitoring', presumably using the Mac's audio input or microphone.

Without further data, it's hard to say for sure exactly how the person's machine was compromised, but for starters, there are some questions that might help narrow down the list of possibilities. What network services or other network-aware programs are they running? If there are multiple users on the machine, particularly users with admin privileges, are they all fully trusted? Are all programs and the OS fully up-to-date with the latest security updates and patches?

Though it seems likely that this is a typical case of a system being compromised somehow, what *is* interesting is that this case is an example of how the MacOS is fully a member of the *nix world, and with all the good comes this sort of possibility of bad. As with any OS, then, security -- especially keeping software up-to-date and monitoring user privileges -- must be a priority.


John C. Welch
I'm thinking this is possibly less a virus and more of a Trojan horse. It looks like it's running a copy of "John the Ripper", a well known password cracking tool. If someone's trying to root your box, that would be a good tool to use. If you don't want to get caught, then deleting log files is a sensible thing to do. I’ll bet the process is owned by root too, so it’s harder to kill, and most Mac users aren’t going to kill a root process anyway.

Using /Library/StartupItems/ for it shows some thought about Mac OS X. One of the problems with that directory is that, while items in it run as root prior to login, you don't have to be root to create startup items in that directory, nor do they have to be owned by root to run. Any admin user can use this directory to create startup items that will run as root. That's a weakness that hopefully will get fixed.

Putting it into ~/Public as an invisible file again shows some forethought. The Finder doesn’t normally register .files, so a user unaware of this, or that you have to use terminal, or some other application to manipulate things, so the passwords found with John are going to be invisible to the user. Placing it into the user’s Public folder means that you can get to it via AFP or SMB, (Apple File Protocol, or Server Message Block, used for Windows file sharing respectively) without needing to authenticate, as a guest.

What you’re seeing is most likely more of a Trojan than a virus, making use of techniques straight out of Cracking 101. If I were this person, I’d kill all external network access that wasn’t ABSOLUTELY necessary, and lock the /etc/hostconfig file too, because someone is fixing to root, and probably zombie their box.


Jason Froikin
The process "john" that the MacInTouch Reader noted in the "Opener Malware" notice is a brute force and dictionary DES password cracker. My guess is since MacOS X stores passwords as encrypted strings, the malware was packaged with "john" to try and crack those passwords before sending them somewhere.


Dave Taylor
You might notify people that the fastest way for them to see if they've had this little bugger show up is to run:

$ sudo ls -l /Users/*/Public/.info

A good result is:

ls: /Users/*/Public/.info: No such file or directory

If you get anything else, it's time to pop into /Library/StartupItems and see what's in there.


Tom Trinko

I saw the article about this malware. This script, when saved as a stay open script and run will display a dialog whenever a process that contains the text "john" appears.

on idle
set process_name to "john"
tell application "System Events"
set matches to every process whose name contains process_name
if the length of matches > 0 then
set mesg to "These processes contain " & process_name & return
repeat with a_process in matches
set mesg to mesg & the name of a_process & return
end repeat
display dialog mesg
activate
end if
end tell
return 5
end idle

To reduce system load increase the value in the return statement, i.e. replace 5 with say 10 or 100. It's the time in seconds between running the script. this works with 10.3. Use at your own risk, no warranty expressed or implied, etc. I spent about 5 minutes writing this for folks who are worried about this but who don't want to keep checking their startup items every 10 minutes. :) a better technique would be to add a folder action script to the /Library/startupitems folder but I didn't have time to test that out.


Dan Sokol
I think it's more important to know HOW it got in his machine and how it replicates. What it does is secondary.


MacInTouch Reader
From looking through the pages, you can see this is where the malware masquerading as iTunes was created as well. It appears the malware steals passwords, registration numbers, installs Timbuktu and opens up a cloaked copy, turns on all kinds of sharing, turns off firewalls, kills LittleSnitch, creates a user that does not show up in the Accounts list but does show up in NetInfo, etc., etc., etc..

Apple addressed some of these vulnerabilities in its security updates. The forum was last updated 9-10-2004. The script lives on. You still need an admin password to install this in the first place. Very interesting read...


Christoph Trusch
I would like to know the following: 1) which incarnation of OS X is the reader using 2) did the reader apply the critical security update that patches the known browser vulnerability 3) how did the reader actually get infected 4) how does a program manage to "delete unix commands"? Other than manually installing a program while the owner e.g. is away and forgot to log out/shut down, I don't see any way of getting something like this onto a Mac OS X installation....



Oct. 25, 2004

Opener Malware

Jason Lockhart
I think this guy got hacked. My guess is this user, (1.) did not apply security patches (especially sshd patches) through Software Update in a timely fashion, (2.)they used an admin (or root) password that was not a strong password, or (3.)they transmitted their admin or root password via plain text and it was intercepted.

Everything the user describes happening to his system is indicative of an intrusion scheme not a virus scheme[...]


Joshua Brauer

It is worth noting a few things on the "Opener" report. First David Taylor suggests using 'ls' to find the .info files. There are several problems with this including that Opener is made to be modified and the folder could easily be renamed.

Second, as this is a part of a rootkit install it means the user has root. This means any program on that machine, especially including ls, ps, find etc. could have been replaced with a cracked version to hide the offending processes. The only utilities (especially command line utilities) that can be trusted at this point are either on a non-compromised machine or on a CD/DVD.

Also in the rootkit it moves Opener to /System/Library/StartupItems instead of /Library/StartupItems.

It is also lamentable the way Apple configures SSH. If you enable the root account then it is by default given SSH access. We're seeing a lot of brute force attacks on the root account (searching for passwords) and many users surprised by the ability to log in as root remotely (having been trained to log in as user x and then su to root). The Opener script itself isn't much of a threat but combined with the rootkit or the brute force attacks on root accounts it's a much bigger potential threat.


Brian
Mike Romo at Symantec states that there is a patch in the 10-21-04 Symantec Norton Anti-Virus virus definitions for [Opener.]


David Cebula
Symantec lists a “Hacktool.Openerscript” as a new threat added in their October 22 virus definitions. They do not have any details on it yet, but it is probably “Opener” given that Symantec released at rare mid-month definitions update for Mac on October 21st.

The script has also been submitted to ClamAV, to add to their database.


Nathan Florea
John C. Welch wrote "One of the problems with [/Library/StartupItems/ is that, while items in it run as root prior to login, you don't have to be root to create startup items in that directory."

Luckily, this is incorrect. The directory's permissions are:

drwxr-xr-x 2 root admin 68 8 Feb 2004 /Library/StartupItems/

which allows administrators and others to look in the directory, but only root to modify it. An admin user would have to authenticate themselves, which you will be given an option to do if you try to copy a file into that directory. To my knowledge, this has always been the case and given how obvious a problem it would be, I would be very doubtful of claims that Apple missed it in a prior release. Of course, a user could always modify the directories permissions to allow what Mr. Welch suggests, but Apple can hardly be be blamed for a user's errors.

Also, if you don't want to get caught, deleting log files is [the wrong]thing to do. That is like removing a house after you burglarize it: the victim might not be able to find any evidence you left, but the absence is fairly conspicuous.

As for this "virus", here is one that is much more destructive:

#!/bin/sh
sudo rm -rf /*.* [DO NOT TRY THIS!!]

The key here is not to run programs you download unless you are sure you can trust the source and to be careful to make sure you know why a program needs you to put in your admin password. There is nothing here that should worry normal users.


Dave Schroeder

This is not a virus, not a worm, and not even a trojan (a "trojan" is something that masquerades as one thing and does something else, usually undesirable; this script does exactly what it advertises...for example, a "trojan" would be some other installer that would also secretly put this script on your computer).

There is no proof that any "installer" actually even installs this. In fact, none probably does: the only person who has allegedly found this on their machine is one MacInTouch poster, and it probably got on his machine manually, or because of a weak password issue, or some other means.

Additionally, there is no way for this to spread or propagate in any automated fashion, making it completely worthless. The only reason this script is getting any attention at all is because it is targeted specifically at Mac OS X, and does Mac OS X-specific things; but at its heart, it's nothing more than a UNIX shell script - one that needs to be manually installed by someone with admin/root or physical access to the machine!


[...] because of Mac OS X's inherent and fundamental design, and the fact that almost all of its networking services (things like apache, OpenSSH, etc.) are based on open source projects that receive great scrutiny for security and thus have theoretical security holes corrected before they become practically exploitable ones, and because Apple didn't make the same mistakes/assumptions Microsoft did in creating things like Outlook with so much control over the OS and other applications, there will likely never be any exploit, worm, or virus that can spread in an automated fashion. Yes, people can write "viruses" and scripts like this for Mac OS X - but if they have no means of spread other than manual, they're absolutely worthless, and don't rise to the level of even the most benign Windows virus.

[...] What does this translate to? Follow good security practices, use screensaver password protection, use strong passwords, protect your machine with Open Firmware passwords, don't let untrusted users have physical access to your machine, don't open ports unnecessarily, etc. Following security best practices for Mac OS X, both for ourselves and our users, such as those outlined in Corsair Limited's Securing Mac OS X.pdf, will continue to leave Macs essentially immune to any such attacks, social engineering and trojans notwithstanding.


Andrew Laurence
Regarding Opener, it's important to think about UNIX vulnerabilities, not about Mac software. Opener is a rootkit, which by definition requires a compromised machine in order to install.

Machines can be compromised:

  • Through physical access. (e.g. boot off CD)
  • Through software vulnerabilities. (Have you installed all Security Updates?)
  • Through Trojan horses.

The third is probably the most dangerous. This script could *easily* be embedded in an application installer. The installer prompts you for Admin authentication, you type your password and click OK. *BAM*, the script runs and your machine is owned.

Recommendations:

  • Don't run as an Admin user.
  • Always install Security Updates.
  • Always install the latest 10.x.y for your 10.x.


Geniver Montalvo
To me, the scariest things in Mac OS X are dialogs requesting the admin password to install software. There is no way to know what happens to the password after you type it in. Windows has the ctrl-alt-del keystroke combination that can not be intercepted by applications. A user knows that the dialog box that appears after typing ctrl-alt-del belongs to the OS. Too bad that Windows allows Active-X to install and run programs without user intervention!

I have seen Mac OS X installation programs - even for Internet programs like Yahoo Messenger - that don't even put up a standard dialog box when requesting the admin password. I know that these dialog boxes belong to some third party installer, and I have to trust that it will play nice with my admin password. Some programs even require that the computer be connected to the Internet during the install. You don't even get to see what you are installing before giving permission to install.

It would be nice if the next generation of Macs had something similar to ctrl-alt-del that opened up an "official" dialog box for all authentication. It would be even nicer if all software had to be installed by an "official" installer that could only be executed from that dialog box after "official" authentication. Nicer still if that installer allowed for user entry of the permission levels to be granted to the installed program. The ultimate would be if there was some level of permission less than root that would allow programs that think they need to be root to accomplish legitimate work.

Of course, the Mac way would be to make it a one-button operation - one button that does nothing else.

Actually, it might be possible to retrofit that function into the power button. If so, this kind of security could be put into Tiger and work with existing Macs.


Kevin Purcell
Apple has done pretty well with Mac OS X in terms of out of the box security: they install Mac OS X by default with unneeded services turned off minimizing the attack cross-section for the platform. They have root user turned off by default and let people who need root access to use sudo instead. All of this is good.

But there is one thing they could do to improve security: to discourage Mac OS X users from using administrator privileged accounts as their primary account preferably by changing the OS setup. I hope they will do this in Tiger before attack from something like Opener becomes widespread.

I encourage all Mac OS X users to create a separate administrator account and use that account only for machine-wide administration. You shouldn't need admin privileges for day to day use (even if you are a developer). Finder even tries to help you if you try to copy a file to a location that you don't have permissions for: it tells you don't have permissions but provides a button to authenticate yourself as the administrator to complete the operation. The same in System Preferences: click on a padlock and authenticate. So most of the time you don't need to login as the administrator. And even if you do fast-user-switching makes that less of a bind. Don't forget you can put applications in the Applications folder in your home folder (where I place most of my non-Apple applications) without authentication.

Not having a user have administrator privileges by default will make it more clear when a trojan tries to do something it shouldn't (e.g. install a file in a folder outside your home folder (tree)). Users can help by demanding applications that drag install rather than have a complicated installer. Applications shouldn't require administrator privileges to install. If they do they should state why they need those privileges.

This thinking is best reflected in the 10 Immutable Laws of Security from Microsoft Security Response Center published in TechNet. Read the article for more details. Don't laugh. Microsoft has got very serious about security since the big security push at the start of 2002. Security is now taken seriously in the design of their products. Windows Server 2003 was the first product shipped under this new regime and Windows XP SP2 shows more of this thinking. They aren't perfect (and with a huge insecure installed base they probably never will be perfect either). One of the Security Push efforts was to stop applications requiring administrator privileges and to discourage everyone from running as a member of the Admins group on their machine.

[...] Finally security is a process not a thing: always think security in depth rather than looking for a magic bullet.


Donald Hall

Tom Trinko's stay open AppleScript script may not be effective. As far as I can tell the statements tell application "System Events" set matches to every process whose name contains process_name will only consider processes started after the user has logged in. If the malware was put into /System/Library/StartupItems or /Library/StartupItems it won't be seen.

Here is an alternate script using the UNIX command "top":

global theMonitoredName
global idleReturnTime
set theMonitoredName to "John" -- N.B. top only shows first 10 letters of process names
set idleReturnTime to 5on idle
set theTable to every paragraph of (do shell script "top -l1 -R -F")
set matches to {}
-- seek blank line at the end of the header section (should be 7th line, but...)
set i to 1
repeat until item i of theTable is ""
set i to i + 1
end repeat

-- skip over blank line and column headers
repeat with j from i + 3 to count of theTable
set oneProcName to (characters 7 thru 16 of item j of theTable) as text
ignoring white space
if oneProcName contains theMonitoredName then
set the end of matches to oneProcName
end if
end ignoring
end repeat

if the length of matches > 0 then
set msg to "These process names contain \"" & theMonitoredName & "\"" & return
repeat with oneItem in matches
set msg to msg & oneItem & return
end repeat
beep
display dialog msg giving up after 60
activate
end if
return idleReturnTime
end idle

This script should get every running process from kernel_task on up.

Tom's suggestion of a folder action script attached to all of the StartupItems folders is probably a better way to go - and might be a good idea in any case. Apple provides us with a script called "add - new item alert.scpt" located in /Library/Scripts/Folder Action Scripts that will do the job. I have attached it to my /System/Library/StartupItems folder, which is my only StartupItems folder at the moment.


Louis Bertrand

I'd like to comment on the statement by John C. Welch about /Library/Startup Items: You don't need to be root to install items there, but you do need administrative privileges. chown-ing the items to root is also easily accomplished by an admin user so there is no additional security benefits.
  On my 10.3.5 installation, I see

$ cd /Library
$ ls -ld StartupItems
drwxr-xr-x 5 root admin 170 4 Nov 2002 StartupItems
$ cd StartupItems
$ ls -al
total 16
drwxr-xr-x 5 root admin 170 4 Nov 2002 .
drwxrwxr-x 39 root admin 1326 4 Nov 2002 ..
-rw-rw-rw- 1 root wheel 6148 4 Nov 2002 .DS_Store
drwxr-xr-x 6 root admin 204 20 Oct 18:28 FTDIReEnumerate
drwxr-xr-x 5 root admin 170 18 Sep 16:35 PostgreSQL
(PostgreSQL is a database server that I installed from Fink.)

Attempting to drop a file or folder into this with Finder triggers the "Authenticate" dialog box. The admin user would have to be fooled into installing the trojan under some other guise.

General comments

The attack community has had years of experience with Unix exploits and they have now found a group of relatively inexperienced (and possibly naive) Unix users. Not a good prospect for the future.

I work in a college/university environment that deploys a few hundred Mac laptops. Time to investigate some of those integrity checker projects out there. Initial short list:



Oct. 26, 2004

Opener Malware

MacInTouch Reader
My box had Opener on it. It is behind a firewall and only has the ports for filesharing (AFP, 548) and Halo (2302) forwarded to it. It is not in the DMZ.

I don't know how it got there. The file has a creation date of 10/14/04. No one has physical access to my machine.

I assume either: (i) someone hacked another machine inside my firewall and then hacked my machine or (ii) it was installed by an installer program. [...]


Steve Wicinski

I would like to respond to a couple of comments about comparing Windows security to OS X that were posted in your Opener report. Geniver Montalvo wrote"There is no way to know what happens to the password after you type it in. Windows has the ctrl-alt-del keystroke combination that can not be intercepted by applications. A user knows that the dialog box that appears after typing ctrl-alt-del belongs to the OS."

This is true, but its not an even comparison. In Windows, you use ctrl-alt-del to bring up the login dialog. Once you've logged in, however, you don't need to re-authenticate at any point when installing programs. If you're an Admin user, you can then do anything you want (or anything any nefarious installer or application wants).

Well-written OS X software should prompt for the admin authentication using OS X's built-in authentication, I believe the calling side does not have access to the password (they shouldn't be able to get it, although not being a programmer, I can't say for sure). However, OS X does let you know what program is requesting the password. Some third-party installers prompt for the admin password themselves directly. I would be more wary of these programs.

Kevin Purcell quotes Microsoft's security guidelines in recommending that users not use Administrator accounts. (Of course, MS doesn't follow its own guidelines with XP Home, but that's another story.) I just want to point out that Admin users on OS X are different than Windows. Windows administrators can do anything with Windows: install programs, change system files/settings, etc. OS X administrators still need to authenticate before installing software, can't write to system directories, etc. So, while I'm sure there's some safety/security involved in running software as 'users', I don't think its as much of a magic bullet as it is under windows.

BTW, on a final point, authentication (or admin access) is only needed to install files into system-wide directories. Trojans and viruses can still install themselves for the current user without any type of message or prompt. Now while this only affects you, if you're the only user on your system, its not much difference than a system-wide virus.


David E. Frank
[...] the best thing we as users can do to protect ourselves from this type of malware is: protect your admin accounts!

  • DON'T log in with an admin account to do day-to-day tasks that do not require admin access.
  • DON'T read email will logged in as an admin.
  • DON'T execute email attachments whose source you are unsure of.

Some additional steps you can take to protect yourself:

  • If you have an always-on internet connection, use a firewall.
  • Use an encrypted disk image to secure sensitive data, or use FileVault.
  • KEEP GOOD BACKUPS! Buy an external Firewire drive or two, download Carbon Copy Cloner or use the 10.3 Disk Utility. This is important whether there is a malware threat or not.
  • Watch for security updates from Apple.

Anti-virus software is helpful, too, but these two are reactive - they protect against known threats. The above steps are proactive - they are both the "star wars" missile defense shield and how you "harden" your system against the malware nuke.


John C. Welch
Nathan Florea wrote: "The /Library/StartupItems/ directory's permissions are:

drwxr-xr-x 2 root admin 68 8 Feb 2004 /Library/StartupItems/

which allows administrators and others to look in the directory, but only root to modify it. An admin user would have to authenticate themselves, which you will be given an option to do if you try to copy a file into that directory. To my knowledge, this has always been the case and given how obvious a problem it would be, I would be very doubtful of claims that Apple missed it in a prior release..."

Unfortunately, it’s not that simple. Checking through my network I discovered that /Library/StartupItems has very different permissions:

drwxrwxr-x 5 root admin 170 12 Aug 17:12 StartupItems
drwxr-xr-x 5 root admin 170 12 Aug 16:39 StartupItems
dr-xr-xr-x 3 root admin 102 26 Mar 2004 StartupItems

On the first two machines, they both have identical startup items, the third one has only one, Adobe VersionCue, which the first two share as well.

Checking other machines showed differences in the group writing permissions setup, although the all are as current as can be. Even on those machines where the users are not admins, and are running from network home directories, there’s no set standard for permissions on this directory. Note that running Repair Permissions makes no changes at all to the permissions on this directory, so there’s no way to tell what they are supposed to be.

Even on Mac OS X Server, the permissions on this directory are not standardized. Yes, I am quite sure who is and who is not able to muck with such things. It’s a little disconcerting to see that a directory that can be such fantastic entry point to malware is less protected than the Desktop folder in my home director. At the very least repairPermissions should reset that directory to drwxr-xr-x 4 root wheel, and preferably drwxr-x--- 4 root wheel, and not allow anything to execute that is not owned by root.

This is one place where Apple needs to be draconian about the permissions setup.




Oct. 27, 2004

Opener Malware

Dave Schroeder
[I sent the following to Apple.] FYI...this is the only place where I really see an issue. Otherwise, if something is actively *prompting* for elevated privileges, you'd better know what it's doing.

To: Product Security <product-security@apple.com>
Subject: Security issue with /Library/StartupItems

SUMMARY

Items can be placed /Library/StartupItems and become root on the next boot without the user's knowledge

DESCRIPTION

/Library/StartupItems does not exist by default on a standard installation of Mac OS X. Its permissions are set by the first user/installer to create it; if none are explicitly specified, it is created with the permissions of the parent /Library directory, which is root:admin 775

At first glance, this does not appear to violate the standard permissions and administrative user model for Mac OS X. Every task that can allow an installer or other process to actually become 'root' prompts for a password either via sudo or AuthServices, notifying the user that something is requesting elevated privileges. However, this is not true of /Library/StartupItems. Because its permissions usually end up being root:admin 775, items may be placed within it without the users knowledge, and may become root upon the next boot. This represents a serious discrepancy in the model of always prompting for credentials for elevated privileges.

While it might indeed be a trojan that would do something like this, prompting for administrative privileges is an important delineation: in the prompt scenario, the user must explicitly grant the installer or process root-equivalent privileges. But with the current /Library/StartupItems situation, an installer, or even an application without an installer, can place items in /Library/StartupItems, creating it first if necessary, without any prompts or knowledge of the user, and can subsequently become root. There is no other scenario that I can think of on Mac OS X where a piece of software being executed or moved somewhere in the directory structure can become root WITHOUT first prompting for a password via sudo or AuthServices.

SOLUTION

Create /Library/StartupItems if not present, set its permissions as root:admin 755, and enforce those permissions via a potential BOM on a receipt for proper set or retention permissions during permissions repair.


Colin Sutton
[For those infected] Did you check to see if you had installed anything on that date: search the disk for files with that date? None of the suggestions given so far (other than having an up-to-date virus checker installed) will protect against the installation of a Trojan-laden download by an administrator. I see a new DVD decrypter/copier download being offered quite regularly. Such an offer would tempt many users. Is there a list that reports downloads that are compromised anywhere?


Eben
Question for the two people who have compromised systems. Did they ever run an installer for a program acquired through a file sharing network?


MacInTouch Reader
Adding more to the information here, I don't even have a /Library/StartupItems on four machines: PowerBook 17, 1.5 GHz (April 2004), 2.5 G5 (October 2004), a G4/867 (from roughly end 2000 or early 2001, I can't remember exactly), and an iMac G4 from June 2003.

I am guessing that those directories are created and installed by non-Apple software. This would explain why (1) permissions are nonstandard, and (2) "Repair Permissions" does not do anything to them.


iBookBB
In response to Geniver Montalvo: It would be nice if the next generation of Macs had something similar to ctrl-alt-del

I'm guessing that s/he never pressed Command-Option-Escape... now while it is not as 'advanced' as Windows' Ctrl-Alt-Del, if you need to kill an app, that is where it is done... and who says that that particular dialog 'can't be intercepted'? back in MS-DOS/Win 3.1/Win 9[5/8], all that the three-finger salute did was kill stuff, be it the whole smash, or through a selection, it does not matter...If you honestly think that a program is not doing it's legitimate business, just C-O-Esc it in Win XP(possibly all NT Windows), the salute has not one, but two steps for killing programs

I will grant, however, the OS X window is nowhere where it could be, BUT, you must also recall that the MacOS just went to having a *nix subsystem, and the issue of security was only disabling macros...


Geniver Montalvo
Responding to Steve Wicinski:

It is true that Windows only uses Ctrl-Alt-Del to bring up the login dialog. That's why I said, "Too bad that Windows allows Active-X to install and run programs without user intervention!"

You said, "Well-written OS X software should prompt for the admin authentication using OS X's built-in authentication, ... However, OS X does let you know what program is requesting the password. Some third-party installers prompt for the admin password themselves directly. I would be more wary of these programs."

I don't know if you meant that, or made a typo. I do not believe that OS X lets you know what program is requesting the password. My point is that a third party can make a password dialog that looks EXACTLY like the built-in dialog if she wants to, and the user won't be able to tell the difference. A third party can put up a dialog box requesting a password without telling the OS that it is requesting a password.

Windows is no better in this regard (unless you believe that Windows users are more wary. I don't think anybody believes that).

I am suggesting that Windows would be a lot safer if a password were required to install Windows software, and if the user had to press ctrl-alt-del before entering that password. I am also saying that I would feel a little more secure if Mac OS X had a similar mechanism.

Note: This won't prevent the user for installing malicious software. It will prevent software from gaining or using the administrator password. For instance, you have to enter a master password to gain unrestricted key chain access. If a special keystroke was also required, then a program couldn't enter the password.



Links

 


On to Part 2...

Respond to today's report

 


 Ads     E-mail     Find     Home     Resources     Sitemap

Copyright 2004 by MacInTouch, Inc. All rights reserved.



click for more info