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.
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!
To spy without permission requires less pleasant approaches:
/dev/vcs* you can also read the virtual consoles directly. This *might* require root access, but not always :).
* 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.
Some thoughts on seeing what someone else sees:
If you can manage to get read permissions on Linux under
screen can be setup with similar functionality to kibitz.
With insecure X permissions, you can use xwd to dump images from a remote xserver. With a short script you can also grab remote keypresses and events for logging.
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.
Do you have "." in your path?
This is why . is at the end of my path, and it's not in root's path at all.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
> 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.