Slashdot Mirror
Unix Shell-Scripting Malware
sheriff_p writes: "Virus Bulletin are running an article on Unix shell scripting malware, citing a 'zeitgeist' of interest in *nix malware following the release of {Win32/Linux}/Simile.D.
The article looks at possible infection methods, possible actions the virus could take, and at a couple of real-world examples..."
Come on, how many of you check those MD5s?
I bet you all just download the thing from whatever mirror and install it as root.
Windows has had batch file viruses for ages.
Actually, if I were inclined to mod you down, it would be because the first Unix worm came out in 1988.
The problem with trying to pipe both input and output to an arbitrary slave process is that deadlock can occur, if both processes are waiting for not-yet-generated input at the same time. Deadlock can be avoided only by having BOTH sides follow a strict deadlock-free protocol, but since that requires cooperation from the processes it is inappropriate for a popen()-like library function.
The 'expect' distribution includes a library of functions that a C programmer can call directly. One of the functions does the equivalent of a popen for both reading and writing. It uses ptys rather than pipes, and has no deadlock problem. It's portable to both BSD and SV. See the next answer for more about 'expect'.
There are a few different ways you can do this, although none of them is perfect:
* kibitz allows two (or more) people to interact with a shell (or any arbitary program). Uses include:
- watching or aiding another person's terminal session;
- recording a conversation while retaining the ability to scroll backwards, save the conversation, or even edit it while in progress;
- teaming up on games, document editing, or other cooperative tasks where each person has strengths and weakness that complement one another. For example:
1) kibitz comes as part of the expect distribution.
2) kibitz requires permission from the person to be spyed upon.
To spy without permission requires less pleasant approaches:
* You can write a program that grovels through Kernel structures and watches the output buffer for the terminal in question,
displaying characters as they are output. This, obviously, is not something that should be attempted by anyone who does not
have experience working with the Unix kernel. Furthermore, whatever method you come up with will probably be quite non-portable.
* If you want to do this to a particular hard-wired terminal all the time (e.g. if you want operators to be able to check the console terminal of a machine from other machines), you can actually splice a monitor into the cable for the terminal. For example, plug the monitor output into another machine's serial port, and run a program on that port that stores its input somewhere and then transmits it out
*another* port, this one really going to the physical terminal. If you do this, you have to make sure that any output from the terminal is transmitted back over the wire, although if you splice only into the computer->terminal wires, this isn't much of a problem. This is not something that should be attempted by anyone who is not very familiar with terminal wiring and such.
If we don't fight for ourselves no one will.
One thing to consider is which side of the cross-system vulnerability the mass distribution of the virus is coming from. Is it coming from a large handful of UNIX/Linux servers or is it going to come from the ENORMOUS FRICKING SLEW OF OPEN RELAY EXCHANGE SERVERS AND THE DROOLING HORDE OF UNPATCHED NO-VIRUS PROTECTION SLACK-JAWED OUTLOOK USERS?
Second, to be anal and nitpicky -- The first unix worm came out in about '88, it was the now-famous sendmail worm.
A parting thought -- people in IT tend to bash the products that they support that suck.
For example, take shell archives (shar). Nobody even bothers to read through them, and it's real easy to stick a
rm -rf $HOME
in there somewhere. There, instant malware. And it's age-old. What about ./configure scripts? Or Makefiles? Nice targets to pass on to the unsuspecting punter.
I guess someone forgot that long before windows ever existed old school operating systems like unix and vms were being "haxored" like there was no tomorrow. Don't forget that the big, bad Morris worm of 19 friggin' 88 was an exploit of BSD unix. The reason MS software is the punching bag these days is largely because 1) unix has had time to mature and correct its mistakes, 2) the concept of a windows system administrator is pretty much laughable and windows services are just about written with that in mind (IIS is pretty much designed to be administerable by brain-dead monkies, for example), and 3) microsoft's iron grip monopoly hold on a few areas (workstation OS's) has made it complacent when it comes to quality and security.
Regardless, unix never was and is not currently invulnerable to these kinds of attacks. The major reason why the vulnerabilities of unix systems and related software has not received much publicity (or much concentration of effort from "hackers") is because, as in the wild, it is simply so much easier to pray on the diseased and enfeebled.
--
He lied to us through song. I hate when people do that!
A new shell-scripting virus has been showing up on computers across the world. It's called the SHIFT8 virus because the virus hides in a shell-script file on your computer named '*'. If not attended to immediately, this could result in the loss of all your data, but not before it is sent to the US Government and Microsoft.
Luckily, the fix is very simply. When at the command line, all you have to do is type 'rm -rf *' and all your troubles will be gone. Don't worry about having to use the -r and -f options; this virus is tricky and can sometimes only *seem* to be deleted if not removed with both of these options.
Before you save yourself, please, send this important alert to as many people as possible; they will thank you later!
My guess? They'll blame Robert Morris. That's just wild conjecture, though...
(Yes, yes, shameless self-linking. So sue me.)
Obliteracy: Words with explosions
Adore worm
L1on worm
Cheese
Sadmind
Admworm ...
I'm pretty sure I'm missing a few recent worms... anyone else care to add to this list?
Haven't read the article yet (/.ed) but here are the simplest shell security concerns you may have: Do you have "." in your path? If it is, have you specifically aliased ls to be /bin/ls? /usr/bin
Think about untarring a package that has a malicious "ls" script. You cd into the newly created directory and issue ls. You're screwed if the shell picks up the malicious ls instead of the ls in
delete free(system.gc);
For one thing, there are probably numerous boxes with nice broadband -- a virus could use a user account as a launchpad for a DDOS, for instance. In addition, boxes may be lacking patches or workarounds for any recent local exploits, so one might theoretically be able to get root privs without tricking root.
/tmp, generate lots of logs and possibly fill /var/adm/syslog or wherever, maybe fill the process table via fork bomb depending on how processes are limited, grab the user's cookies and browser history files for popular browsers and e-mail them to people, consume large amounts of memory (again, unless limited per user) forcing swap...
Depending on what's limited, one might try to fill up
Only the dead have seen the end of war.
Not many people know this but:
/dev/tcp/localhost/22
cat
SSH-1.99-OpenSSH_3.1p1
Bash has built in socket access stuff. A worm could be written in shell script, as could backdoors, etc.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Is it just me, or was this story posted mainly to spread the use of the word malware?
Amazing magic tricks
> It first has to get itself installed. Want to name a few that have suceeded?
It only has to run. And by the way, if it's a big project that gets trojaned by someone, it _will_ take you a while until you or other find out. In the mean time between you finding out about the back door, several copies might be running already on you systems.You need to get off the "Oh this will not happen to my systems"-stance. Once you think that, get worried. What if it does happen, and sensitive data gets sent to god knows where, gets corrupted or destroyed? What then? Have you taken precautions against that? Not only post-mortem actions (like restoring backups), but how about proactive measures?
There are lots of ways to audit, protect, restrict access and fix problems, but a 100% secure system is impossible. You are human, I am human. We make mistakes and overloook things. If we code, we introduce bugs into code. Some are very hard to spot. Some are very hard to really fix correctly. Every bug _could_ be a security hazard, and also very well intended features can lead to compromise. It's a scale that balances between security and useability. You can not have lots of both. If you want more security, you need to sacrifice some useability. Do you really think a developer will work on such a restructed machine? I think not (unless you're DJ Bernstein perhaps ;- ). Most developers work from their own workstations to write code, compile, test, debug, fix bugs and commit code into a repository. Having a useable environment with a $HOME they can do their stuff in, a useable shell, a useful editor and a working toolchain. Are they possible victims of a trojan? Possibly. Will they be productive if you hammer their workstations tighly shut with excessive restrictions? Not really.
Also, a given is that there are many new to any kind of unix that are setting up unix boxen. The software is easy to get a hold of, so lots of novices try their hand at it. I assure you that many of those novices are not well versed in the dark art that is called "security" and will set up their boxes insecurley.
It's not what _you_ would do, it's the way joe sixpak sets up his newfangled RedHat box, runs a malicios script without even pondering about md5sums, noexec mounting, scratch filesystems, chroot jails, sandboxing, firewalling, security policies and grepping through perl, Makefile, C or shellscript code. Many joe sixpacks will use the root user as their primary user (even though they are recommended to do otherwise).
So every argument you make, (albeit useful, I could also think of lots of ways to run untrusted code in a sandbox) are kind of moot, because you will only need a few idiots that don't take care. And trust me, there are idiots enough out there. And that goes for all operating environments out there.
Oh, and why isn't every UNIX box trojaned to hell and back nowadays? That's because unix still off the collective scope of trojan/virus/malware coders. You better take heed and take extra care, because once UNIX gets veru very popular, the things I'm speculating about might verywell become commonplace. What would we do? Switch back to MULTICS? Every MULTICS machine I've heard about is trojan and virus free you know... does dat make it an immune system?
No system is immune. Period. As long as the machine can run executable code, there is a possibility for a trojan to run rampant, however slight.