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

Click here to return to the 'Dumb question' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
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.


"Closer" Script

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


# 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" ]
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

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}"

# 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"

# 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/ 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\" \"\">" >> /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

# 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.


## 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.

# 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:

# 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.

# 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.


# 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 "$@"; }


# 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 ))

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


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

declare -r watchHashes

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

while true
# Calculate MD5 hash of each directory in watchItems, and
# compare to its reference value.
for (( i=0; i< watchCount; ++i ))

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

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

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

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:

[...] 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. 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 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:

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
Clarity Production LLC

[ Reply to This | # ]