Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Regarding the 'opener' malware script System
Since OS X Hints is intentionally not a news site, I've stayed away from discussing the 'opener' malware that's been covered on most every major Mac site out there. The site's focus is not changing, but since there are finally some "hint related" aspects of this issue, I will take some time to cover those pieces of it this morning.

If you're not familiar with the opener malware (also known as a 'root kit'), it's basically a large shell script that, once installed, does all sorts of Really Bad Things to your machine -- nothing overt like erasing your user's directory, but much worse stuff. It installs software that disables Little Snitch (an outbound firewall, basically ... [Edit: It actually kills it before making outbound connections, and moves it to last in the boot order, but doesn't actually disable it]), it installs remote access software, it installs a password decoder app, etc. It goes by many names; Symantec calls it SH.Renepo.B, and their writeup of it covers all its evilness in great detail.

Read the rest of the hint for some tips on how to avoid Opener, and how to remove it if you do get it...

Opener is a lot of things, but it's not a worm or virus: it can't self-propagate, and it doesn't automatically infect a machine. Opener has to be installed, either during a software installation (of a package that's been intentionally infected with Opener), or by a user who has gained root access to a machine. If your machine is secure, you can't be infected accidentally -- it requires proactive action on your part. So the best ways to avoid Opener are:
  • Physically secure your machine, if possible.
  • Always use a screensaver/locking program when you leave your machine, even for a minute or two.
  • Apply all security updates in a timely fashion.
  • Use secure passwords.
  • Only install software from trusted sources -- stick to places like MacUpdate, VersionTracker, HyperJeff's OS X Software page, etc. Don't download and run things from Limewire, etc., unless you really like living on the edge.
  • Think twice before giving your admin password to every installer that asks for it. Personally, I only 'trust' the major names in the business (i.e. Adobe, Apple, Microsoft, etc.) when it comes to giving an admin password on install. Beyond that, I'll quit the installer and dig around inside the package to see if I can figure out why it wants my admin password. If I can't figure out why, I'll usually email the author before I try to install it. Your admin password should be protected, and that includes not letting any old application have it when it requests it.
  • To be extremely cautious, don't run as 'admin' at all -- create a non-privileged user account for your day-to-day stuff. Personally, I find this a bit onerous (I tried for a while), but it definitely would give you a more secure environment (assuming you don't then just provide the admin password when requested!).
  • KEEP GOOD BACKUPS! This is important in any context, but especially one in which a piece of malware could easily rm -rf * (force erase everything NOW -- do *not* try this command!). Good backups are easily worth the time they take to create.
How can you tell if you have somehow managed to get Opener installed on your machine? The fastest way is to open Terminal (in Applications -> Utilities), and type sudo ls -l /Users/*/Public/.info, then hit return. If your machine is most likely** clean, you'll see ls: /Users/*/Public/.info: No such file or directory as the result. If you see anything else, your machine is infected.

** Since this is a malware script, and it's installation requires root, you can't be 100% sure you're clean with the above command. If the hacker is really good, they can replace ls with their own version, or just rename the script components, etc -- since they have to have root access to install in the first place, they can do whatever they like! But the above command will catch all the simple 'script kiddie' installations of Opener.

The above little tidbit came from Macintouch's excellent Opener Malware Reader Reports series, which is also where you can find other monitoring tools, as well as a removal tool (all subject to the above disclaimer, of course). In particular, check out:
  • Donald Hall's script on the October 22nd report to monitor for a process named John (the password decoder).
  • Rams' entry on the Oct 28 page about how to create and set permissions on /Library/Statup Items, which will close one method that the Opener malware uses to accomplish its evilness.
  • Harold Martin's 'Closer' script on the Oct 31 page. This will (hopefully) get rid of an installed Opener.
  • Greg Guerin's Watcher script (also on the Oct 31 page), which watches the two Startup Items folders and alerts you if they are modified. Since Greg was kind enough to release his code into the public domain, I have also put a copy on macosxhints.
Finally, for a great general overview on securing OS X, read the NSA's new OS X System Configuration Guide [3.1MB PDF]. It's definitely not required for most home users to institute everything listed in its entirety, but it's a great overview of the system and some ways to make it even more secure than it already is. At nearly 100 pages, it's not a light read, but it's well worth the time.

In summary, malware can (and does) exist for any platform -- with the assumption that root access has been obtained, anything and everything is possible. Opener is not a worm, nor a virus. Spreading it requires either user intervention or a compromised machine, and it must be hand-installed on each machine to be infected. Take the basic steps necessary to secure your machine and your work habits, and you should feel quite comfortable with the safety of your system and its data -- but please, have a backup or two or three, just in case!
    •    
  • Currently 2.40 / 5
  You rated: 2 / 5 (5 votes cast)
 
[24,997 views]  

Regarding the 'opener' malware script | 31 comments | Create New Account
Click here to return to the 'Regarding the 'opener' malware script' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Regarding the 'opener' malware script
Authored by: diamondsw on Nov 01, '04 10:25:06AM
# Physically secure your machine, if possible.
# Always use a screensaver/locking program when you leave your machine, even for a minute or two.
# Apply all security updates in a timely fashion.

And how are these supposed to protect your machine? Good advice for the paranoid, but these will do nothing for Opener. These only make a difference if someone else knows your password, which is required to install it. So the only real advice is:

Don't give out your password

[ Reply to This | # ]
Regarding the 'opener' malware script
Authored by: DonkeyHo-T on Nov 01, '04 10:44:30AM

There are additional problems beyond merely giving out your password.

Nothing gaurantees the permissions of /Library/StartupItems and any StartupItems placed in the folder run as root during the next startup.

As the opener script itself points out, there are numerous programs that store passwords in preference files rather than in the keychain and some of those preference files can contain an admin password in clear text so if a person has read access to your drive (for instance physical access and you do not set a screen-saver password) then the person may well be able to obtain your password without "you" giving it to them.



[ Reply to This | # ]
physical access
Authored by: hayne on Nov 01, '04 12:46:20PM

if someone has physical access to your machine, they can restart it with the Install CD or via "single-user" mode and thus obtain 'root' privileges without the need for any password. Thus the admonition to physically secure your machine. For machines that are publicly accessible, it is essential to set the "open firmware" password to prevent the above.

If you leave your Mac running without activating the screensaver, anyone can access your files and (for example) install hidden malware using the privileges of your user account. This is often the first step towards obtaining your password and full control of the machine.



[ Reply to This | # ]
more on physical access
Authored by: echo mirage on Nov 01, '04 01:19:02PM

The first poster should also know that all precautions, OF security modes and otherwise, go out the window if the machine's case is unlocked. A real padlock completes the 'reasonable' physical security checklist. Without a locked case, I wouldn't bother with OF mode changes, frankly.

You should keep your machine's case integrity in mind when considering counterintrusion policies unless you live alone in the woods with lethal perimeter security, and see other humans infrequently.

---
--------------------------------------------
d i l i g e n t i a . v i s . c e l e r i t a s
--------------------------------------------



[ Reply to This | # ]
Regarding the 'opener' malware script
Authored by: legacyb4 on Nov 01, '04 10:29:45AM

For what it's worth, I run my account as a regular user but have modified the /etc/sudoers file to allow me to 'sudo' when working in Terminal.

This prevents any GUI-based intentional or accidental actions (dragging stuff in/out of folders where they shouldn't be going, etc.), forces the authentication dialog box to appear when doing any GUI-based apps, but allows me enough freedom on the command line to do what I need.



[ Reply to This | # ]
Locking up when you leave...
Authored by: lullabud on Nov 01, '04 12:26:08PM
  • Always use a screensaver/locking program when you leave your machine, even for a minute or two.
If you have a bluetooth phone this feature can be automated with BluePhoneElite (or something similar, BPE is beta), which can do certain things when your phone leaves bluetooth range or enters bluetooth range. I find peace of mind knowing that my computer locks itself up and pauses iTunes for me when I walk down the hall to the printer or break room.

[ Reply to This | # ]
Locking up when you leave...
Authored by: jiga on Nov 02, '04 09:58:21AM

Of course, installing this app requires one to enter the root password, which means you already break rule #6 "Think twice before giving your admin password to every installer that asks for it" :-)



[ Reply to This | # ]
Dumb question
Authored by: jasmine on Nov 01, '04 02:09:08PM

Forgive me... this may be a dumb question...
I typed sudo ls -l /Users/*/Public/.info in Terminal and instead of "No such file or directory", I saw this:
We trust that you have received the usual lecture from the local System Adminstrator. It usually boils down to these two things:
1) Respect the privacy of others.
2) Think before you type.
Password:

Does this mean my mac is infected?



[ Reply to This | # ]
Dumb question
Authored by: Tulse on Nov 01, '04 02:15:43PM
Jasmine, the message you see is the standard one that you see when invoking sudo. Because sudo temporarily gives you extra privileges, it will just remind you that you can potentially do harm if you use it improperly. To actually run the command you want, you will need to enter in the password -- the command will then run, and give you the feedback that let's you know if your machine is compromised.

[ Reply to This | # ]
Dumb question
Authored by: thornrag on Nov 01, '04 02:17:40PM

It means it's the first time you've run sudo. It's asking you to enter your account password. You'll only see this the first time you use sudo. After that, you'll be asked for your password without the usual lecture bit.

Personally, I find the usual lecture bit to be paternalistic, pandering, and other words that start with 'p'. Moreover, apparently, it's confusing to new users.

But don't sweat, it's normal.



[ Reply to This | # ]
Dumb question
Authored by: jasmine on Nov 01, '04 02:24:04PM

*Whew* Thank you! :D



[ Reply to This | # ]
Another Dumb question
Authored by: rdemby on Nov 01, '04 07:33:24PM

My terminal response is :" tcsh: sudo: No match."
Do I have it?



[ Reply to This | # ]
Another Dumb question
Authored by: jwd on Nov 01, '04 07:45:44PM

I get the same ...

---
Is this thing on???



[ Reply to This | # ]
Another Dumb question
Authored by: BrettTaylor on Nov 01, '04 11:07:05PM

You are getting this because you're running tcsh as your shell. You are not infected. If you want to check this for sure, in terminal type "bash", then the aformentioned command and you'll find you get the "ls: /Users/*/Public/.info: No such file or directory" output.



[ Reply to This | # ]
Re: Another Dumb question
Authored by: derrickbass on Nov 01, '04 09:00:45PM

No, you are not infected. (Well, probably not. There might be variants of Opener that manifest themselves differently. So far, however, we only know of the one.)

The difference depends on which shell you are using. The shell is decided upon when your account is created and only changes after that if you do so explicitly.

Before Panther, the default shell was "tcsh". If your account was created under Jaguar or earlier then your shell is tcsh, even if you have subsequently upgraded to Panther. Under Panther, the default shell is "bash" for newly created accounts.

Anyway, what the command is doing is checking whether the file ".info" exists in the Public directory of any user. If it exists in one of your user directories, it means you have "Opener". If it does not exist, then you get an error message (which is good; it means you probably don't have Opener). However, bash and tcsh appear to give different error messages.



[ Reply to This | # ]
Dumb question
Authored by: clarityprod on Nov 29, '04 06:58:34PM

no it does not mean that you are infected. You would know that your infected because some of the signs are in your face. Like, programs opening over and over again. Your firewall and shared folders would be active so that outside hackers can get in. The script also sends passwords to the person that wrote the script. Thats why they open your firewall etc. This is also what it is called OPENER. Here is the latest info i attained on this problem.

USE AT YOUR OWN RISK. I HAVE NOT TESTED THIS.

"Closer" Script

Harold Martin
I just wrote a script designed to remove opener from an infected system [listed here]:

#!/bin/bash

################################################################################################
# closer - this is the door closer
#
# This will turn most system services (ie SMB, SSH, Apache) off
# even if they were on before opener and will match kill a
# bunch of processes
#
# "What is wrong with us? Nothing.
#
# Just don't take your security for granted. Open a door, and we'll walk it.
# All you have to do is keep your doors closed,
# or watch who's walking around outside."
# Hackenslacker
################################################################################################
# Originally written by hmartin

# This script runs in bash (as is noted by the very first line of this script)

# To run this script you need admin access

# Get the name of the evil script to remove
if [ -z "$1" ]
then
echo "Usage: `basename $0` malware name"
echo "If you are unsure what to use then run these commands or just use 'opener'"
echo "ls -1 /System/Library/StartupItems/ > StartupItems"
echo "diff CleanStartupItems StartupItems"
exit 1
fi

rm -rf /System/Library/StartupItems/"${1}"

# Remove from any mounted startup volume.
ls /Volumes | while read vol; do
if test -d /Volumes/"${vol}"/System/Library ; then
rm -rf /Volumes/"${vol}"/System/Library/StartupItems/"${1}"
fi
done

# If this script is run by anyone other than root it warns the user, but tries to disinfect anway
# Most of the commands in the script will just generate errors if it isn't run as root
if [ `id -u` != "0" ]; then
echo "This script is not running as root, probably won't work"
exit
fi

# Enable system accounting
# How to test whether it's currently on or off?

# Clear out ohphoneX
rm -rf /private/.phone/
killall -9 -m ohphoneX

# Enable OS X built-in firewall
defaults write /Library/Preferences/com.apple.sharing.firewall state yes &

# Restore LittleSnitch Prefs
if test -d /Library/StartupItems/LittleSnitch ; then
echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>" > /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo "<!DOCTYPE plist PUBLIC \"-//Apple Computer//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo "<plist version=\"1.0\">" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo "<dict>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo " <key>Description</key>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo " <string>Loading Little Snitch</string>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo " <key>OrderPreference</key>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo " <string>First</string>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo " <key>Provides</key>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo " <array>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo " <string>LittleSnitch</string>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo " </array>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo "</dict>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo "</plist>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
fi

# Kill KRec
killall -9 -m KRec
rm -rf /Library/Preferences/KRec*

# Turn ssh off
echo "service ssh" > /private/etc/xinetd.d/ssh
echo "{" >> /private/etc/xinetd.d/ssh
echo "disable = yes" >> /private/etc/xinetd.d/ssh
echo "socket_type = stream" >> /private/etc/xinetd.d/ssh
echo "wait = no" >> /private/etc/xinetd.d/ssh
echo "user = root" >> /private/etc/xinetd.d/ssh
echo "server = /usr/libexec/sshd-keygen-wrapper" >> /private/etc/xinetd.d/ssh
echo "server_args = -i" >> /private/etc/xinetd.d/ssh
echo "groups = yes" >> /private/etc/xinetd.d/ssh
echo "flags = REUSE IPv6" >> /private/etc/xinetd.d/ssh
echo "session_create = yes" >> /private/etc/xinetd.d/ssh
echo "}" >> /private/etc/xinetd.d/ssh &
echo "SSHSERVER=-NO-" >> /etc/hostconfig

# Turn FileSharing and webserving off
echo "AFPSERVER=-NO-" >> /etc/hostconfig
killall AppleFileServer
echo "SMBSERVER=-NO-" >> /etc/hostconfig
echo "WEBSERVER=-NO-" >> /etc/hostconfig

# Lock system files back up
chmod 644 /etc/hostconfig
chmod 444 /etc/xinetd.d/ssh
chmod -R 755 /etc/periodic/daily /etc/periodic/weekly /etc/periodic/monthly
chflags uchg /etc/hostconfig /etc/xinetd.d/ssh /etc/daily /etc/weekly /etc/monthly

# Delete all that hard earned info
rm -r /.info
find . -maxdepth 2 -name "Public" -type d -exec rm -rf '{}/.info' \;
rm -rf /Library/Preferences/.indexed/v_m.txt

# No idea what the default LW settings are supposed to be...

# Can anyone confirm if this works?
# I'd rather not trash the NI db
# nidump -destroy . /users/LDAP-daemon

# How to cut the last line of the cron log deletion jobs?

# Bye john
rm -rf /Library/Preferences/jtr
killall -9 -m john

# Misc
chmod 775 /Library

# Remove dsniff
rm -rf /Library/Preferences/dsstart
killall -9 -m dsniff
killall -9 -m dsstart
# This will definately need a lot more work
# Probably uploading known good version and reinstalling them
# Anyone want to host

# Should forwarding be turned off?
# sysctl -w net.inet.ip.forwarding=0







"Watcher" Script

Greg Guerin
The attached Watcher.command script is the preventive counterpart to Harold Martin's Closer.

It watches the two StartupItems folders and draws your attention to changes.

Released into the public domain, as-is without warranty.

#!/bin/bash

## This shell-script is intended to be seen and modified.
## It should work on Mac OS 10.2 and up, with the BSD subsystem installed.
## If you didn't install BSD, this script will probably fail.
## It may work in other configurations, but I haven't tried it.
## - - - - -
## Originally written by Gregory Guerin.
## PROVIDED AS-IS AND WITHOUT WARRANTY OF ANY KIND.
## RELEASED INTO THE PUBLIC DOMAIN: 31 OCT 2004. BOO!


# Watcher -- watches for changes made by Opener installation.

# This script watches for changes in certain places: the StartupItems dirs.
# It performs a check every 15 seconds, by default.
# Very little CPU is needed to perform a check, so more frequent checks are possible.
# You can change the interval here:
betweenChecks=15

# When a change is seen, a message is spoken using Mac OS X's speech synthesis.
# Also, a timestamped message is written to stdout.
# You can change the action by editing the function eachFailure below.


# YOU MUST BE FREE OF INFECTION BEFORE RUNNING THIS SCRIPT.
# When this script detects a change, you should immediately determine the cause.
# It will continue to complain about the change until you quit it.
# When you rerun it, it will take the then-current state of the directories
# as the new baseline, and only complain about subsequent changes.
# So if you run it when you're already infected, it WILL NOT see a change.

# There are many ways that Opener can defeat this little script.
# I won't list them. They involve hiding information from the
# commands used to check integrity (md5), or subverting commands
# used to detect changes (ls), or even subverting bash itself.


## FUNCTIONS

# This function is invoked each time a change is detected
# on each iteration of the main watching loop.
# You can edit this function to do anything you want.
# By default, it emits a message to stdout
# and also speaks the name of what changed.
# You can change it to send an email, write to a served web-page,
# post to a URL, dial a pager number, or any other commands you want.
# To run an AppleScript, see the man-page of the 'osascript' command.
function eachFailure ()
{
# Echo a time-stamped complaint to system console log.
echo `date` "-- Change in" "$@"

# Speak complaint using default voice.
osascript -e "say \"Attention, $1 was changed\""
}


# This function produces output characterizing the state of a file or dir.
# When the state changes, the output should change.
# The output is used to calculate the MD5 hash for each dir being watched.
# It can also be used as a debugging aid.
function characterize ()
{ ls -lTond "$@"; ls -lTon "$@"; }


## MAIN CODE

# The 'watchItems' array holds dir-names to watch for changes.
# You can edit it here.
# It's declared read-only to avoid accidental changes.
# Its length and values determine what the rest of the script checks.
declare -ra watchItems=('/System/Library/Startupitems' '/Library/StartupItems')



# Determine length of watchItems, as a read-only integer.
declare -ri watchCount=${#watchItems[*]}

# Calculate reference MD5 hash of each directory in watchItems.
# The directory must exist and be readable to the current user.
for (( i=0; i< watchCount; ++i ))
do
item="${watchItems[i]}"

# Only calculate a hash if item is an existing directory.
hash=0
test -d "$item" && hash=`characterize "$item" | md5`

watchHashes[i]="$hash"

# echo "#####" ; characterize "$item"
echo "$i : $hash : $item"
done

declare -r watchHashes


# MAIN LOOP -- runs until quit, interrupted, or logout.

while true
do
# Calculate MD5 hash of each directory in watchItems, and
# compare to its reference value.
for (( i=0; i< watchCount; ++i ))
do
item="${watchItems[i]}"
ref="${watchHashes[i]}"

# Only calculate a hash if item is an existing directory.
hash=0
test -d "$item" && hash=`characterize "$item" | md5`

# If hash differs from reference, run eachFailure.
test "$hash" != "$ref" && eachFailure "$item"
done

# Param is how long between checks, measured in seconds.
sleep "$betweenChecks"
done




Nov. 1, 2004
Ruben Orduz
Though I sure appreciate Harold Martin for taking the time to write this code, there is still the problem that the computer binaries might have been compromised (i.e. Re-written and compiled not to list or remove "opener" "John" or .info) by the same program that installed the opener in the first place.

One way to insure this script actually does the work for you, is to have fresh, trusted copies of rm, ls, find, etc installed in your system before actually running this script.

If the opener is malicious enough that can detect the new binaries, then install them with a different name, and also modify the name in the script provided by Matt so that they match.


Dave Schroeder
There are some serious problems with relying on or recommending scripts to "restore" a machine once it has been compromised by a rootkit.
1. Very minor changes to opener will render these scripts useless.
2. Once a machine has been compromised, you have no idea what else has been backdoored or compromised. If a "removal" script misses one item, the machine is still completely compromised.
3. Scripts such as these, unless very well written in terms of error and sanity checks, could actually do damage to an otherwise unharmed machine. (I'm not insinuating that these scripts will cause damage; this is a general statement.)
4. Since average users are tempted to seek out a technological fix for a problem with no technological solution, things such as these give people a false sense of security: IF a machine has been compromised by a rootkit, the only way you can really be secure again is to reinstall the OS (unless you can undo every single thing the particular rootkit did, and somehow know everything else on the machine that may have subsequently been touched).

Exploits, worms, and viruses are one thing - and yes, rootkits have technological aspects that should certainly be understood. But rootkits inherently require some other compromise or avenue of access to take place first. This means that once you're compromised, an average user - and even sometimes very skilled system administrators - have no way of knowing the extent of the compromise. Other binaries may have been backdoored, other services may be running without your knowledge - and trojaned versions of system utilities such as top and ps could, for example, be installed that conceal them - etc.

The best advice for opener is as follows:
1. Check to see if an item called 'opener', or otherwise unknown item, exists in /Library/StartupItems or /System/Library/StartupItems. If there is, consider reinstalling your OS. An 'Archive and Install' is not necessarily sufficient, as backdoors from opener would be retained.
2. Simply follow security best practices and DO NOT run untrusted software (i.e., software from p2p/warez networks, or software that was previously unheard of from a source of questionable origin).
[This raises an interesting issue: Do you download anti-Opener programs offered on the Web? You might trust Apple posting one, but Apple is unlikely to do that. What other sources do you trust and what sources don't you trust? -MacInTouch]


Richard C. Haight
It would be nice to know what the 'official' suid/root file list is -- e.g.: as derived from the following Terminal commands:

sudo find / -perm -4700 -user root -print

or equivalent source. Then we could easily compare our Mac to that list.


Neil Mayhew
As noted already, restricting the permissions on /Library/StartupItems/ is not enough, they must be restricted on the parent folder too. Otherwise StartupItems can be removed and a modified one put in its place. However, this argument applies all the way up to the root (/). Apple has had a policy, from the earliest days of Mac OS X, of making / group-writeable. This is a serious security hole, as it allows group 'admin' to alter any desired part of the file system.

/Library/StartupItems is particularly dangerous, because items in there obtain root privileges (on reboot) without needing to have set-user-id or anything like that. But there are lots of other places that spyware could hang out, for example /Library/Frameworks, /Library/Internet Plug-Ins or /Library/Screen Savers, that would allow some level of confidential info to be snagged even without root privileges.

What's more, all this can be done without requesting a higher level of authorization via a password dialog. If you are logged in as an administrator (i.e. a member of group 'admin'), any program that you run can write to these places. In particular, it is possible for malware hidden in an 'innocuous' download to install itself in /Library/StartupItems without your knowledge. Even a drag-installed program could do this the first time it is run.

The moral of the story? Don't allow naive users to use an account with administrator privileges, as a careless download could compromise your whole system. In particular, make sure that kids (especially teenagers) use their own, non-administrator, logins. And be very careful what you download yourself.


MacInTouch Reader
Opener is not the only rootkit for the Mac. a rootkit has a primary purpose, to allow someone continued root access to your machine. These are commonplace, and easily researched for various *nixes. The attack *vector* is something else, usually software with a hole in it, weak passwords, passwords in the clear on a compromised network, etc. See some links:

http://neil.slampt.net/
http://www.packetstormsecurity.org/
http://www.syngress.com/catalog/sg_main.cfm?pid=2490
http://www.bastille-linux.org/osx.html
http://www.net-security.org/article.php?id=713
http://www.nsa.gov/snac/index.cfm?MenuID=scg10.3.1

[...] Hopefully some light will help people see that passwords and security are something to be taken extremely seriously. The Mac provides loads of tools to help make your world secure, it is the users who are to blame here.


Peter Schoenrank
The recent discussion of 'opener' has caused me to pay more attention to the software I install on my Mac. Today, when I installed the Microsoft UAM for Mac OS X, I took a close look at what it actually installed.

The executables and folders that it installed in /Library/Filesystems/AppleShare/Authentication/ are writable by everyone. That means that an unprivileged (standard) user can rewrite the UAM to execute arbitrary code as a privileged user (admin or root) the next time that a privileged user connects to a Windows server.

This is only a local privilege escalation vulnerability, and I wouldn't be at all surprised to learn that there are other, more easily exploited privilege escalation vulnerabilities in Mac OS X, but a little care on Microsoft's part in creating the installer package would have easily prevented the vulnerability.

I suspect that other software installer packages might cause similar unintentional vulnerabilities.


Eric Hall
If you think you have a compromised system, boot from another device (FireWire drive for example, with a fresh, clean install on it), or put your system into FireWire target mode and mount it on a trusted, clean system. Why you ask? Not only are particular binaries often replaced with modified versions, but so are system libraries, kernel extensions, and even the kernel itself. From a different system you can have a look around on the disk and see what you can find. Note that there are lot of places you can't see from the Finder, so working from the Terminal (or your favorite equivalent) is a good idea.

Reinstalling the system is your best bet if you find anything that makes you doubt the integrity of your system. Yes, its a real pain to do so, but (IMHO), better to be sure than sorry later.

Reporting to law enforcement is a good thing to think about as well, the more information law enforcement has the sooner they're likely to catch (and stop) whomever is spreading these things.



Brian Opitz
After sifting through the various responses from readers this problem seems to boil down to a few simple things. Openr.sh has to be deliberately downloaded or copied to a Mac through direct access to the machine. 'Direct access' means physical access to the machine with sufficient privileges to copy files to appropriate directories or access via remote log-in with the same privilege levels and a method to execute the script. Basic (paranoid) security needs to be exercised in order to prevent/mitigate the unsophisticated type of attack that Opener.sh represents.

Servers should be isolated from casual access (all the system level security in the world won't help if someone gets to your box with a boot CD) and never left unattended with admin/owner or root logged-in. Remote log-ins (ssh) to servers should be allowed only with the root user and interactive log-ins disabled combined with an ACL (access control list). Restrict admin/root access to a limited number of people. Unused/unneeded services should be disabled and their ports closed.

Workstations in an office setting should have the screen saver enabled with a short time-out and password required to unlock/wake up. Automatic log-in to workstations should be disabled. Inactivity log-out should be enabled. No users other than designated admins should have admin level privileges or access to an admin level account on these machines.

Use "strong" passwords. Passwords like 'guyvlv*&%*%@KJBb039' are harder to guess or crack than 'a12345'. Change passwords often, especially admin level passwords.

Users are logged into their machines, by default, as the owner of the machine who is a member of the admin group. For your own personal account on your own machine create a standard/no limits account for everyday use. Enable 'fast user switching' so you can change to to the owner account for admin level tasks that you may need to perform on a day-to-day basis.

Disable the root account. First enable the root account, give it a different password from the owner account, then disable the root account. You can do just about everything the root user can do as the owner/admin user of the machine without root access. This won't affect how the root(system) user processes run. See this Apple KB article on how to enable/disable the root user: http://docs.info.apple.com/article.html?artnum=106290.

Reduce your 'attack surface' by turning off unneeded services. Securing and turning off services on workstations is first accomplished by selecting the 'Security' System Preferences item and check the 'Require password to unlock each secure system preference'. Then under Sharing in System Preferences, select the Services tab and turn off (uncheck) all unnecessary services. The same goes for the Firewall and Internet tabs. Then click the lock icon to prevent tampering.

Permissions on certain directories, particularly /System/Library/StartUpItems, are incorrect and there seems to be some confusion as to what they should be. Incorrect permissions combined with elevated access privileges can lead to unfortunate incidents with inexperienced/malicious users. Permissions on system level files and directories should not be changed without a full understanding of the implications of such changes. Problems with incorrect permissions can range from applications unexpectedly quitting to kernel panics, so users should tread carefully.

In particular the permissions on /System/Library/StartUpItems should not be set to root:admin as owner and group but root:wheel. Directories and binaries in /System/Library/StartUpItems should be set with permissions of 755, while .plist and .strings files in these directories should be 744. These are the default permissions that are set after installation or a permissions repair are done. Recursive changing of access permissions with 'chmod -R' or owner:group ownership with 'chown -R' should be used with caution.

If you feel that something is amiss with your Mac you can get a good sense of what is going on 'under the hood' by using the terminal and the 'ps' command. Typing:

ps -aeux

in a terminal window will give you a quick snapshot of what's happening; including commands, paths, and user processes running on your Mac.
For a 'live' view of what's going on you can use the 'top' command. The 'top' command has several options to allow absolute, cumulative, or delta display of system resource usage. To terminate top while it is running simply press 'q' on the keyboard and you will be returned to the prompt. To see more options for 'top' type:

man top | more

in a terminal window to view the man page for top.


Brian Robison
There are tools in the market designed to detect anomalies on systems without the dependency of virus updates etc. I work for Tripwire, Inc. in Portland Oregon. We design tools that detect even the smallest changes in a file system or network device. Our policy language is very extensible and can monitor many attributes of files.

Tripwire has been a tool in the market place for nearly a decade and is installed on hundreds of thousands of computers all over the world. Nearly every UNIX security book mentions Tripwire's change detection as a fundamental corner stone to computer security. If you can't trust the data sitting on your hard drive, then all the firewalls and virus scanners in the world are worthless.

Tripwire is a commercially available product marketed to corporations striving for visibility into the changes on their systems (network devices and servers).

Several years ago, Tripwire released their version 2.3 into the open-source community, hoping that a large install base, especially in the Linux community would help communicate the need for Tripwire. Since that release, the open source version has been ported to many different platforms including, most importantly, MacOS X.

A great starting point for your readers looking for some level of visibility into their MacOS X system specifically can be found at: MacGuru:TripwireTM on Mac OS X. With the built-in default policy file included with this build, the 'opener' program would have been caught and the user alerted.

Tripwire is a tool that monitors many attributes on files including hashing the file with up to 4 different checksum algorithms. It can alert users to added, deleted, and modified binaries, or text files. Very useful in detecting new virus, or worms. Also very useful in detecting changes to systems when installing software. The policy file can be edited to monitor whatever files/directories you are interested, and comes with a built-in default that is a good starting point.

You'd be very surprised to know what happens to files on your hard drive when you have a tool that can show you the changes over time. It's a real eye opener!



Nov. 4, 2004

Michael G. Ross
One person in the discussion of setting /Library permissions to defend against Opener suggested that restricting /Library to 755 was futile since / is given 775 permissions. Actually, the sticky bit for / is set, which prevents non-root users from renaming or removing root-owned elements in /.

Similarly, setting the sticky bit of /Library (sudo chmod +t /Library) prevents a non-root user from renaming or removing the StartupItems folder, once it is created.


Mike Byrne
As noted by Michael L Dickens on your second page, changing the mode of /Library/StartupItems to 755 doesn't completely solve the problem as any admin user can remove the entire directory and re-create it however they wish.

What I've done to prevent this on my system (I had no preexisting /Library/StartupItems directory when I started) is:

sudo mkdir /Library/StartupItems
sudo chmod 755 /Library/StartupItems
sudo SetFile -a L /Library/StartupItems

SetFile is a tool that comes with the Developer Tools. I use this to set the "Locked" attribute for the directory (equivalent to doing a chattr +i on linux) which blocks the ability of anybody (including root) from removing the directory. If it can't be removed, it can't be re-created with more favorable permissions. It should also be "Repair Permissions" safe.


Harold Martin
In reply to Dave Schroeder's comments:

Closer was written to counteract the effects of the "official" opener strain written on the Mac Underground forums. As such, it is not meant to be a catch-all solution for all opener variants, or even future opener versions.

The extent of the damage in the Closer script is limited to closing services that may have been legitimately opened.

Closer will not completely eradicate opener in its present state. It does not replace the binaries that dsniff replaces (these should be copied from a trusted source by hand) and it does not remove the LDAP-daemon user (which should be remove in the NetInfo utility by hand). Both of these design decisions were made in order to keep closer from causing any possible damage to the machine

Eric Hall's advice that one boot from a FireWire device must be taken with great caution, since opener is designed to copy itself to all mounted volumes (such as FireWire drives and shared network devices) with a /System folder.

In the end, the only sure way to remove *any* malware is to reformat and reinstall OS X on all affected machines on a network.



Use at your own risk. I dont have this problem but I do stay on top of what is going on. Its called preventative maintenance

---
kenneth bailey
Owner
Clarity Production LLC



[ Reply to This | # ]
Regarding the VIRUS?
Authored by: dr_turgeon on Nov 01, '04 06:04:53PM

Symantec, the link you posted, seems to classify this as a virus.

Why (or why not) is it?



[ Reply to This | # ]
Regarding the VIRUS?
Authored by: greenwood on Nov 01, '04 06:38:11PM
From http://en.wikipedia.org/wiki/Computer_virus

"In common parlance, the term virus is often extended to refer to computer worms and other sorts of malware. "

[ Reply to This | # ]
Regarding the VIRUS?
Authored by: Makosuke on Nov 01, '04 07:43:33PM

Yes, although "virus" is used in very general terms to mean "porgrams that secretly do bad things to your computer" (more accurately called "malware"), it has a more precise definition, and Opener does not fit it.

Roughly:

*Virus - A program that, like a biological virus, automatically replicates itself.

*Worm - Very similar to a virus, but it actively tries to infect other computers (for example by emailing itself to other people or via network backdoors). Almost all the big Windows nasties are, therefore, technically worms.

*Trojan - A program that pretends to do one thing, but actually does something else (usually installs some other malware or virus).

Coming back to Opener: as explained above, it needs to be installed by someone (or something) with administrator-level access to your computer, so by itself it is none of these things.

It does not (so far as I have read) replicate itself, and it certainly does not have any means of spreading itself beyond the computer on which it is installed and any connected machines (if it can even do that, in which case it would, I suppose, be a virus, albeit a very limited one since it is only installed in specific locations).



[ Reply to This | # ]
Regarding the VIRUS?
Authored by: dr_turgeon on Nov 02, '04 02:27:51PM

Symantec is clearly wrong about classifying Opener as a virus then?



[ Reply to This | # ]
Finding out if you are infected
Authored by: derrickbass on Nov 01, '04 09:20:00PM
Why is the command to find out if you are infected "sudo ls -l /Users/*/Public/.info"?

In particular, I presume that the sudo is there just in case the permissions on the directory have been changed. (Ordinarily, everyone is allowed to see your Public directory.) However, because the "*" is expanded before sudo is executed, it won't help; if the directory is not readable by the user executing the command, it will never even get passed to sudo.

I can't think of a simple way to do this. One can either:


sudo -s
ls -l /Users/*/Public/.info
exit

(Make sure to type exit! sudo -s gives you a root shell, which is very dangerous, so you want to exit the shell as soon as you are done.)

Or you can write a loop: In tcsh:


foreach i (/Users/*)
   sudo ls -l "$i"/Public/.info
end

In bash: well, I dunno, but I'm sure someone will translate the above script.

If see a bunch of error messages, that's good. If you see an actual listing of a file, that is bad.

[ Reply to This | # ]

Finding out if you are infected
Authored by: bdm on Nov 01, '04 11:14:28PM

Your comment is quite correct:
sudo ls -l /Users/*/Public/.info
is NOT a correct check for file of that form.

To do it in a single command, use this:
sudo sh -c 'ls -l /Users/*/Public/.info'
(including the single quotes). That way the * is not expanded until sudo has established the right privileges.

Brendan



[ Reply to This | # ]
Regarding the 'opener' malware script
Authored by: Gordon Werner on Nov 02, '04 12:17:07AM

so how exactly is this thing installed? Is this a case of someone downloading stolen software or MP3s that really install this little application?

or what?



[ Reply to This | # ]
Regarding the 'opener' malware script
Authored by: virus1984 on Nov 02, '04 05:35:51AM

You have to install it yourself, manually. Installation requires admin priviledges...so it shouldn't be easy to get fooled into installing it.

---
Don't forget to think different.



[ Reply to This | # ]
Regarding the 'opener' malware script
Authored by: themacnut on Nov 02, '04 05:50:36AM

Opener can be disguised as a trojan in the form of an MP3 or stolen software-it can also be hidden in stolen software as an extra piece of code. You download it, run it and it does it's thing.

Also, someone else can physically sit in front of your Mac and download the script from a web or ftp site. Hence all the posts above about physically securing your machine when you're away from it.

Also since it's just a script and doesn't require an installer, someone sitting at your machine may not even need an admin password to run it-a shell script (which is what Opener is, IIRC)is just a text file until it's made executable.



---
The MacNut



[ Reply to This | # ]
Regarding the 'opener' malware script
Authored by: jimhoyt on Nov 02, '04 02:13:33PM
Malware such as "opener" can be placed into your StartupItems folder by any installer (even those you might find on such sites as VersionTracker) that requires an admin password. The new startup item will not necessarily be executed until you restart your Mac. All startup items are then executed with root rights.

Be very careful of everything that you install and backup regularly.

[ Reply to This | # ]
Regarding the 'opener' malware script
Authored by: Gordon Werner on Nov 04, '04 03:15:29PM

I guess this is my question ...

since you'd have to be pretty unwise to deliberately install this on your mac ... I was wondering how it is disguised so that I, and others, can avoid running into it ... i.e. if there is a specific MP3 file that does it ... or some other specific application.



[ Reply to This | # ]
Regarding the 'opener' malware script
Authored by: LC on Nov 03, '04 07:36:59PM

How about this as another easy command (assuming that the 'weekly' script has been run by the system, very recently;) --
locate /Users/\\*/Public/.info

I guess that's not as good, since there's a time lapse between the updatedb and the query. So, check the date like so, first --
ls -l /var/db/locate.database

Larry.



[ Reply to This | # ]
Regarding the 'opener' malware script
Authored by: LC on Nov 03, '04 07:39:24PM

Oops, I thought one backslash would have been eaten by the code here. Sorry, only one backslash to escape that asterisk, or else use quotes in the shell. '/Users/*/...'



[ Reply to This | # ]
Care with Installers.
Authored by: macmath on Nov 05, '04 01:32:50AM

I am particularly glad now that I bought a license to
<A HREF="http://www.charlessoft.com/">Pacifist</A>. I commonly just extract to the desktop and install myself.



[ Reply to This | # ]
"Closer" Script
Authored by: clarityprod on Nov 29, '04 07:08:09PM

USE AT YOUR OWN RISK. I HAVE NOT TESTED THIS.

"Closer" Script

Harold Martin
I just wrote a script designed to remove opener from an infected system [listed here]:

#!/bin/bash

################################################################################################
# closer - this is the door closer
#
# This will turn most system services (ie SMB, SSH, Apache) off
# even if they were on before opener and will match kill a
# bunch of processes
#
# "What is wrong with us? Nothing.
#
# Just don't take your security for granted. Open a door, and we'll walk it.
# All you have to do is keep your doors closed,
# or watch who's walking around outside."
# Hackenslacker
################################################################################################
# Originally written by hmartin

# This script runs in bash (as is noted by the very first line of this script)

# To run this script you need admin access

# Get the name of the evil script to remove
if [ -z "$1" ]
then
echo "Usage: `basename $0` malware name"
echo "If you are unsure what to use then run these commands or just use 'opener'"
echo "ls -1 /System/Library/StartupItems/ > StartupItems"
echo "diff CleanStartupItems StartupItems"
exit 1
fi

rm -rf /System/Library/StartupItems/"${1}"

# Remove from any mounted startup volume.
ls /Volumes | while read vol; do
if test -d /Volumes/"${vol}"/System/Library ; then
rm -rf /Volumes/"${vol}"/System/Library/StartupItems/"${1}"
fi
done

# If this script is run by anyone other than root it warns the user, but tries to disinfect anway
# Most of the commands in the script will just generate errors if it isn't run as root
if [ `id -u` != "0" ]; then
echo "This script is not running as root, probably won't work"
exit
fi

# Enable system accounting
# How to test whether it's currently on or off?

# Clear out ohphoneX
rm -rf /private/.phone/
killall -9 -m ohphoneX

# Enable OS X built-in firewall
defaults write /Library/Preferences/com.apple.sharing.firewall state yes &

# Restore LittleSnitch Prefs
if test -d /Library/StartupItems/LittleSnitch ; then
echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>" > /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo "<!DOCTYPE plist PUBLIC \"-//Apple Computer//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo "<plist version=\"1.0\">" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo "<dict>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo " <key>Description</key>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo " <string>Loading Little Snitch</string>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo " <key>OrderPreference</key>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo " <string>First</string>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo " <key>Provides</key>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo " <array>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo " <string>LittleSnitch</string>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo " </array>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo "</dict>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
echo "</plist>" >> /Library/StartupItems/LittleSnitch/StartupParameters.plist
fi

# Kill KRec
killall -9 -m KRec
rm -rf /Library/Preferences/KRec*

# Turn ssh off
echo "service ssh" > /private/etc/xinetd.d/ssh
echo "{" >> /private/etc/xinetd.d/ssh
echo "disable = yes" >> /private/etc/xinetd.d/ssh
echo "socket_type = stream" >> /private/etc/xinetd.d/ssh
echo "wait = no" >> /private/etc/xinetd.d/ssh
echo "user = root" >> /private/etc/xinetd.d/ssh
echo "server = /usr/libexec/sshd-keygen-wrapper" >> /private/etc/xinetd.d/ssh
echo "server_args = -i" >> /private/etc/xinetd.d/ssh
echo "groups = yes" >> /private/etc/xinetd.d/ssh
echo "flags = REUSE IPv6" >> /private/etc/xinetd.d/ssh
echo "session_create = yes" >> /private/etc/xinetd.d/ssh
echo "}" >> /private/etc/xinetd.d/ssh &
echo "SSHSERVER=-NO-" >> /etc/hostconfig

# Turn FileSharing and webserving off
echo "AFPSERVER=-NO-" >> /etc/hostconfig
killall AppleFileServer
echo "SMBSERVER=-NO-" >> /etc/hostconfig
echo "WEBSERVER=-NO-" >> /etc/hostconfig

# Lock system files back up
chmod 644 /etc/hostconfig
chmod 444 /etc/xinetd.d/ssh
chmod -R 755 /etc/periodic/daily /etc/periodic/weekly /etc/periodic/monthly
chflags uchg /etc/hostconfig /etc/xinetd.d/ssh /etc/daily /etc/weekly /etc/monthly

# Delete all that hard earned info
rm -r /.info
find . -maxdepth 2 -name "Public" -type d -exec rm -rf '{}/.info' \;
rm -rf /Library/Preferences/.indexed/v_m.txt

# No idea what the default LW settings are supposed to be...

# Can anyone confirm if this works?
# I'd rather not trash the NI db
# nidump -destroy . /users/LDAP-daemon

# How to cut the last line of the cron log deletion jobs?

# Bye john
rm -rf /Library/Preferences/jtr
killall -9 -m john

# Misc
chmod 775 /Library

# Remove dsniff
rm -rf /Library/Preferences/dsstart
killall -9 -m dsniff
killall -9 -m dsstart
# This will definately need a lot more work
# Probably uploading known good version and reinstalling them
# Anyone want to host

# Should forwarding be turned off?
# sysctl -w net.inet.ip.forwarding=0







"Watcher" Script

Greg Guerin
The attached Watcher.command script is the preventive counterpart to Harold Martin's Closer.

It watches the two StartupItems folders and draws your attention to changes.

Released into the public domain, as-is without warranty.

#!/bin/bash

## This shell-script is intended to be seen and modified.
## It should work on Mac OS 10.2 and up, with the BSD subsystem installed.
## If you didn't install BSD, this script will probably fail.
## It may work in other configurations, but I haven't tried it.
## - - - - -
## Originally written by Gregory Guerin.
## PROVIDED AS-IS AND WITHOUT WARRANTY OF ANY KIND.
## RELEASED INTO THE PUBLIC DOMAIN: 31 OCT 2004. BOO!


# Watcher -- watches for changes made by Opener installation.

# This script watches for changes in certain places: the StartupItems dirs.
# It performs a check every 15 seconds, by default.
# Very little CPU is needed to perform a check, so more frequent checks are possible.
# You can change the interval here:
betweenChecks=15

# When a change is seen, a message is spoken using Mac OS X's speech synthesis.
# Also, a timestamped message is written to stdout.
# You can change the action by editing the function eachFailure below.


# YOU MUST BE FREE OF INFECTION BEFORE RUNNING THIS SCRIPT.
# When this script detects a change, you should immediately determine the cause.
# It will continue to complain about the change until you quit it.
# When you rerun it, it will take the then-current state of the directories
# as the new baseline, and only complain about subsequent changes.
# So if you run it when you're already infected, it WILL NOT see a change.

# There are many ways that Opener can defeat this little script.
# I won't list them. They involve hiding information from the
# commands used to check integrity (md5), or subverting commands
# used to detect changes (ls), or even subverting bash itself.


## FUNCTIONS

# This function is invoked each time a change is detected
# on each iteration of the main watching loop.
# You can edit this function to do anything you want.
# By default, it emits a message to stdout
# and also speaks the name of what changed.
# You can change it to send an email, write to a served web-page,
# post to a URL, dial a pager number, or any other commands you want.
# To run an AppleScript, see the man-page of the 'osascript' command.
function eachFailure ()
{
# Echo a time-stamped complaint to system console log.
echo `date` "-- Change in" "$@"

# Speak complaint using default voice.
osascript -e "say \"Attention, $1 was changed\""
}


# This function produces output characterizing the state of a file or dir.
# When the state changes, the output should change.
# The output is used to calculate the MD5 hash for each dir being watched.
# It can also be used as a debugging aid.
function characterize ()
{ ls -lTond "$@"; ls -lTon "$@"; }


## MAIN CODE

# The 'watchItems' array holds dir-names to watch for changes.
# You can edit it here.
# It's declared read-only to avoid accidental changes.
# Its length and values determine what the rest of the script checks.
declare -ra watchItems=('/System/Library/Startupitems' '/Library/StartupItems')



# Determine length of watchItems, as a read-only integer.
declare -ri watchCount=${#watchItems[*]}

# Calculate reference MD5 hash of each directory in watchItems.
# The directory must exist and be readable to the current user.
for (( i=0; i< watchCount; ++i ))
do
item="${watchItems[i]}"

# Only calculate a hash if item is an existing directory.
hash=0
test -d "$item" && hash=`characterize "$item" | md5`

watchHashes[i]="$hash"

# echo "#####" ; characterize "$item"
echo "$i : $hash : $item"
done

declare -r watchHashes


# MAIN LOOP -- runs until quit, interrupted, or logout.

while true
do
# Calculate MD5 hash of each directory in watchItems, and
# compare to its reference value.
for (( i=0; i< watchCount; ++i ))
do
item="${watchItems[i]}"
ref="${watchHashes[i]}"

# Only calculate a hash if item is an existing directory.
hash=0
test -d "$item" && hash=`characterize "$item" | md5`

# If hash differs from reference, run eachFailure.
test "$hash" != "$ref" && eachFailure "$item"
done

# Param is how long between checks, measured in seconds.
sleep "$betweenChecks"
done




Nov. 1, 2004
Ruben Orduz
Though I sure appreciate Harold Martin for taking the time to write this code, there is still the problem that the computer binaries might have been compromised (i.e. Re-written and compiled not to list or remove "opener" "John" or .info) by the same program that installed the opener in the first place.

One way to insure this script actually does the work for you, is to have fresh, trusted copies of rm, ls, find, etc installed in your system before actually running this script.

If the opener is malicious enough that can detect the new binaries, then install them with a different name, and also modify the name in the script provided by Matt so that they match.


Dave Schroeder
There are some serious problems with relying on or recommending scripts to "restore" a machine once it has been compromised by a rootkit.
1. Very minor changes to opener will render these scripts useless.
2. Once a machine has been compromised, you have no idea what else has been backdoored or compromised. If a "removal" script misses one item, the machine is still completely compromised.
3. Scripts such as these, unless very well written in terms of error and sanity checks, could actually do damage to an otherwise unharmed machine. (I'm not insinuating that these scripts will cause damage; this is a general statement.)
4. Since average users are tempted to seek out a technological fix for a problem with no technological solution, things such as these give people a false sense of security: IF a machine has been compromised by a rootkit, the only way you can really be secure again is to reinstall the OS (unless you can undo every single thing the particular rootkit did, and somehow know everything else on the machine that may have subsequently been touched).

Exploits, worms, and viruses are one thing - and yes, rootkits have technological aspects that should certainly be understood. But rootkits inherently require some other compromise or avenue of access to take place first. This means that once you're compromised, an average user - and even sometimes very skilled system administrators - have no way of knowing the extent of the compromise. Other binaries may have been backdoored, other services may be running without your knowledge - and trojaned versions of system utilities such as top and ps could, for example, be installed that conceal them - etc.

The best advice for opener is as follows:
1. Check to see if an item called 'opener', or otherwise unknown item, exists in /Library/StartupItems or /System/Library/StartupItems. If there is, consider reinstalling your OS. An 'Archive and Install' is not necessarily sufficient, as backdoors from opener would be retained.
2. Simply follow security best practices and DO NOT run untrusted software (i.e., software from p2p/warez networks, or software that was previously unheard of from a source of questionable origin).
[This raises an interesting issue: Do you download anti-Opener programs offered on the Web? You might trust Apple posting one, but Apple is unlikely to do that. What other sources do you trust and what sources don't you trust? -MacInTouch]


Richard C. Haight
It would be nice to know what the 'official' suid/root file list is -- e.g.: as derived from the following Terminal commands:

sudo find / -perm -4700 -user root -print

or equivalent source. Then we could easily compare our Mac to that list.


Neil Mayhew
As noted already, restricting the permissions on /Library/StartupItems/ is not enough, they must be restricted on the parent folder too. Otherwise StartupItems can be removed and a modified one put in its place. However, this argument applies all the way up to the root (/). Apple has had a policy, from the earliest days of Mac OS X, of making / group-writeable. This is a serious security hole, as it allows group 'admin' to alter any desired part of the file system.

/Library/StartupItems is particularly dangerous, because items in there obtain root privileges (on reboot) without needing to have set-user-id or anything like that. But there are lots of other places that spyware could hang out, for example /Library/Frameworks, /Library/Internet Plug-Ins or /Library/Screen Savers, that would allow some level of confidential info to be snagged even without root privileges.

What's more, all this can be done without requesting a higher level of authorization via a password dialog. If you are logged in as an administrator (i.e. a member of group 'admin'), any program that you run can write to these places. In particular, it is possible for malware hidden in an 'innocuous' download to install itself in /Library/StartupItems without your knowledge. Even a drag-installed program could do this the first time it is run.

The moral of the story? Don't allow naive users to use an account with administrator privileges, as a careless download could compromise your whole system. In particular, make sure that kids (especially teenagers) use their own, non-administrator, logins. And be very careful what you download yourself.


MacInTouch Reader
Opener is not the only rootkit for the Mac. a rootkit has a primary purpose, to allow someone continued root access to your machine. These are commonplace, and easily researched for various *nixes. The attack *vector* is something else, usually software with a hole in it, weak passwords, passwords in the clear on a compromised network, etc. See some links:

http://neil.slampt.net/
http://www.packetstormsecurity.org/
http://www.syngress.com/catalog/sg_main.cfm?pid=2490
http://www.bastille-linux.org/osx.html
http://www.net-security.org/article.php?id=713
http://www.nsa.gov/snac/index.cfm?MenuID=scg10.3.1

[...] Hopefully some light will help people see that passwords and security are something to be taken extremely seriously. The Mac provides loads of tools to help make your world secure, it is the users who are to blame here.


Peter Schoenrank
The recent discussion of 'opener' has caused me to pay more attention to the software I install on my Mac. Today, when I installed the Microsoft UAM for Mac OS X, I took a close look at what it actually installed.

The executables and folders that it installed in /Library/Filesystems/AppleShare/Authentication/ are writable by everyone. That means that an unprivileged (standard) user can rewrite the UAM to execute arbitrary code as a privileged user (admin or root) the next time that a privileged user connects to a Windows server.

This is only a local privilege escalation vulnerability, and I wouldn't be at all surprised to learn that there are other, more easily exploited privilege escalation vulnerabilities in Mac OS X, but a little care on Microsoft's part in creating the installer package would have easily prevented the vulnerability.

I suspect that other software installer packages might cause similar unintentional vulnerabilities.


Eric Hall
If you think you have a compromised system, boot from another device (FireWire drive for example, with a fresh, clean install on it), or put your system into FireWire target mode and mount it on a trusted, clean system. Why you ask? Not only are particular binaries often replaced with modified versions, but so are system libraries, kernel extensions, and even the kernel itself. From a different system you can have a look around on the disk and see what you can find. Note that there are lot of places you can't see from the Finder, so working from the Terminal (or your favorite equivalent) is a good idea.

Reinstalling the system is your best bet if you find anything that makes you doubt the integrity of your system. Yes, its a real pain to do so, but (IMHO), better to be sure than sorry later.

Reporting to law enforcement is a good thing to think about as well, the more information law enforcement has the sooner they're likely to catch (and stop) whomever is spreading these things.



Brian Opitz
After sifting through the various responses from readers this problem seems to boil down to a few simple things. Openr.sh has to be deliberately downloaded or copied to a Mac through direct access to the machine. 'Direct access' means physical access to the machine with sufficient privileges to copy files to appropriate directories or access via remote log-in with the same privilege levels and a method to execute the script. Basic (paranoid) security needs to be exercised in order to prevent/mitigate the unsophisticated type of attack that Opener.sh represents.

Servers should be isolated from casual access (all the system level security in the world won't help if someone gets to your box with a boot CD) and never left unattended with admin/owner or root logged-in. Remote log-ins (ssh) to servers should be allowed only with the root user and interactive log-ins disabled combined with an ACL (access control list). Restrict admin/root access to a limited number of people. Unused/unneeded services should be disabled and their ports closed.

Workstations in an office setting should have the screen saver enabled with a short time-out and password required to unlock/wake up. Automatic log-in to workstations should be disabled. Inactivity log-out should be enabled. No users other than designated admins should have admin level privileges or access to an admin level account on these machines.

Use "strong" passwords. Passwords like 'guyvlv*&%*%@KJBb039' are harder to guess or crack than 'a12345'. Change passwords often, especially admin level passwords.

Users are logged into their machines, by default, as the owner of the machine who is a member of the admin group. For your own personal account on your own machine create a standard/no limits account for everyday use. Enable 'fast user switching' so you can change to to the owner account for admin level tasks that you may need to perform on a day-to-day basis.

Disable the root account. First enable the root account, give it a different password from the owner account, then disable the root account. You can do just about everything the root user can do as the owner/admin user of the machine without root access. This won't affect how the root(system) user processes run. See this Apple KB article on how to enable/disable the root user: http://docs.info.apple.com/article.html?artnum=106290.

Reduce your 'attack surface' by turning off unneeded services. Securing and turning off services on workstations is first accomplished by selecting the 'Security' System Preferences item and check the 'Require password to unlock each secure system preference'. Then under Sharing in System Preferences, select the Services tab and turn off (uncheck) all unnecessary services. The same goes for the Firewall and Internet tabs. Then click the lock icon to prevent tampering.

Permissions on certain directories, particularly /System/Library/StartUpItems, are incorrect and there seems to be some confusion as to what they should be. Incorrect permissions combined with elevated access privileges can lead to unfortunate incidents with inexperienced/malicious users. Permissions on system level files and directories should not be changed without a full understanding of the implications of such changes. Problems with incorrect permissions can range from applications unexpectedly quitting to kernel panics, so users should tread carefully.

In particular the permissions on /System/Library/StartUpItems should not be set to root:admin as owner and group but root:wheel. Directories and binaries in /System/Library/StartUpItems should be set with permissions of 755, while .plist and .strings files in these directories should be 744. These are the default permissions that are set after installation or a permissions repair are done. Recursive changing of access permissions with 'chmod -R' or owner:group ownership with 'chown -R' should be used with caution.

If you feel that something is amiss with your Mac you can get a good sense of what is going on 'under the hood' by using the terminal and the 'ps' command. Typing:

ps -aeux

in a terminal window will give you a quick snapshot of what's happening; including commands, paths, and user processes running on your Mac.
For a 'live' view of what's going on you can use the 'top' command. The 'top' command has several options to allow absolute, cumulative, or delta display of system resource usage. To terminate top while it is running simply press 'q' on the keyboard and you will be returned to the prompt. To see more options for 'top' type:

man top | more

in a terminal window to view the man page for top.


Brian Robison
There are tools in the market designed to detect anomalies on systems without the dependency of virus updates etc. I work for Tripwire, Inc. in Portland Oregon. We design tools that detect even the smallest changes in a file system or network device. Our policy language is very extensible and can monitor many attributes of files.

Tripwire has been a tool in the market place for nearly a decade and is installed on hundreds of thousands of computers all over the world. Nearly every UNIX security book mentions Tripwire's change detection as a fundamental corner stone to computer security. If you can't trust the data sitting on your hard drive, then all the firewalls and virus scanners in the world are worthless.

Tripwire is a commercially available product marketed to corporations striving for visibility into the changes on their systems (network devices and servers).

Several years ago, Tripwire released their version 2.3 into the open-source community, hoping that a large install base, especially in the Linux community would help communicate the need for Tripwire. Since that release, the open source version has been ported to many different platforms including, most importantly, MacOS X.

A great starting point for your readers looking for some level of visibility into their MacOS X system specifically can be found at: MacGuru:TripwireTM on Mac OS X. With the built-in default policy file included with this build, the 'opener' program would have been caught and the user alerted.

Tripwire is a tool that monitors many attributes on files including hashing the file with up to 4 different checksum algorithms. It can alert users to added, deleted, and modified binaries, or text files. Very useful in detecting new virus, or worms. Also very useful in detecting changes to systems when installing software. The policy file can be edited to monitor whatever files/directories you are interested, and comes with a built-in default that is a good starting point.

You'd be very surprised to know what happens to files on your hard drive when you have a tool that can show you the changes over time. It's a real eye opener!



Nov. 4, 2004

Michael G. Ross
One person in the discussion of setting /Library permissions to defend against Opener suggested that restricting /Library to 755 was futile since / is given 775 permissions. Actually, the sticky bit for / is set, which prevents non-root users from renaming or removing root-owned elements in /.

Similarly, setting the sticky bit of /Library (sudo chmod +t /Library) prevents a non-root user from renaming or removing the StartupItems folder, once it is created.


Mike Byrne
As noted by Michael L Dickens on your second page, changing the mode of /Library/StartupItems to 755 doesn't completely solve the problem as any admin user can remove the entire directory and re-create it however they wish.

What I've done to prevent this on my system (I had no preexisting /Library/StartupItems directory when I started) is:

sudo mkdir /Library/StartupItems
sudo chmod 755 /Library/StartupItems
sudo SetFile -a L /Library/StartupItems

SetFile is a tool that comes with the Developer Tools. I use this to set the "Locked" attribute for the directory (equivalent to doing a chattr +i on linux) which blocks the ability of anybody (including root) from removing the directory. If it can't be removed, it can't be re-created with more favorable permissions. It should also be "Repair Permissions" safe.


Harold Martin
In reply to Dave Schroeder's comments:

Closer was written to counteract the effects of the "official" opener strain written on the Mac Underground forums. As such, it is not meant to be a catch-all solution for all opener variants, or even future opener versions.

The extent of the damage in the Closer script is limited to closing services that may have been legitimately opened.

Closer will not completely eradicate opener in its present state. It does not replace the binaries that dsniff replaces (these should be copied from a trusted source by hand) and it does not remove the LDAP-daemon user (which should be remove in the NetInfo utility by hand). Both of these design decisions were made in order to keep closer from causing any possible damage to the machine

Eric Hall's advice that one boot from a FireWire device must be taken with great caution, since opener is designed to copy itself to all mounted volumes (such as FireWire drives and shared network devices) with a /System folder.

In the end, the only sure way to remove *any* malware is to reformat and reinstall OS X on all affected machines on a network.



Use at your own risk. I dont have this problem but I do stay on top of what is going on. Its called preventative maintenance

---
kenneth bailey
Owner
Clarity Production LLC



[ Reply to This | # ]