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

11 of 212 comments (clear)

  1. Easy linux virus transport format: by Anonymous Coward · · Score: 5, Insightful
    RPM


    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.

  2. Re:And... by JoeBuck · · Score: 3, Insightful

    Actually, if I were inclined to mod you down, it would be because the first Unix worm came out in 1988.

  3. Not that special... by CoolVibe · · Score: 5, Insightful
    A *NIX trojan/malware is easy to craft.

    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.

    1. Re:Not that special... by Erotomek · · Score: 2, Insightful

      A *NIX trojan/malware is easy to craft. 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.

      It's easy to stick "rm -rf $HOME" but it's also easy to grep for "rm -rf" or similar strings. It can be much more dangerous with such code like this:

      #!/bin/sh
      lots of code...
      some code;b=m;some code
      lots of code...
      some code;b=r$b;some code
      lots of code...
      some code;c=r;some code
      lots of code...
      some code;d=f;some code
      lots of code...
      some code;c=-$c;some code
      lots of code...
      some code;c=$c$d;some code
      lots of code...
      some code;e=~;some code
      lots of code...
      some code;a="$b $c";some code
      lots of code...
      some code;a="$a $e";some code
      lots of code...
      some code;$a;some code
      lots of code...

      Here the ;$a; is the killer. A simple Perl script could insert parts of such commands into a configure script. The only solution is to not run any code which you don't trust. It can be quite difficult (if not impossible), because you not only have to trust the author that he's not evil, but also you have to trust that he was never r00ted by someone evil. I think that I can be safe apt-get'ting software from push-primary/secondary Debian mirrors (I think that their admins are good and before the software gets to the mirrors it's checked by the Debian folks — maybe Sid may be not safe, but Woody and Potato are checked by many people, by reading the code, as well as by running the software), but probably trusting the CPAN is not very safe, because the code is not checked by anyone before it gets to the mirrors, so if a PAUSE user is r00ted by evil haxorz, his code on CPAN can be easily trojaned.

      (for lame filter: x384yrgnfqpeiruchf,xoerjg,cnw;orihj,adoixhjeorg,xw rg uiirumzgipergpiwehrx,gcmopeirjhpqojtcn 3409ic p34c1541xc541 ewsfdcerycwty r;qeiorqo;ewirjfoqeir hoqeirh oqeirh oiwerhfoq;wihrt134pq'wo e'rqwj v0u45tnv 0245tvuj45yji2c6 y2 y62y6vf reihfoqieurc0143[x'.rqszmq39u4sxn18yt38pas,u54z2 2p9syt29pasyt2qtputa/ori)

      --

      Krótko: kady Erotomek
      W pimiennictwie ma swój domek.

  4. Uhhhh, huh? by Misuta+Supakulo · · Score: 5, Insightful

    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!
    1. Re:Uhhhh, huh? by I_redwolf · · Score: 3, Insightful

      1) Unix has always been alot more functional and featureful when it came to anything back then. IE: Dos didn't even multitask

      2) I agree with, but just because it's designed to be controlled by a brain dead monkey doesn't mean that it should be insecure. For instance NASA/RSA/etc create interfaces to far more critical components that can't afford to fail; they are controlled by monkeys. Another example is simply Mac OS X, they've done a stellar job with administration utilities that make it easy but secure (at least in respect to say Microsoft).

      3) "Hackers/Crackers" who go after the desktop are usually just script kids who take a researched exploit and write some lame stupid trojan that preys on as you said the feeble. However it becomes harder to break a system that has been tried/tested and proved over time. As you say, unix never was invulnerable but it is harder for a unix system to be vulnerable just by it's design. Just like a 4x4 built for off-roading it's still vulnerable to get stuck somewhere like a car; but less vulnerable. Usually on the net if you want a secure box with very few problems you put up a unix system and 9 times outta 10 you won't get stuck.

      So everytime people talk like somehow unix doesn't get hacked because it doesn't have market share I remind them what the net was built on and what it was founded on. I then refer them to the track record of unix in stability and security. Unix has been around longer is more secure and was designed that way, thats why you see less exploits for it. I usually also recommend people actually try to put a rogue rpm/script or whatever out there and see how far it makes it in the wild for a unix system and then duplicate some of the same effects on a windows machine if possible and notice the difference. It really has nothing to do with market share.

  5. Got root? by Trevelyan · · Score: 2, Insightful

    To do anything these viruses need to run as root. But the article make no mention of this, or how a virus could get root.

    If the user is using root as their user account, then its their fault if they get infected. Maybe trick the user, I know I worry about installing closed source stuff as root, hance my UT and Tribes2 is installed under another user.

    Yes a virus could have fun in /tmp doing stuff, and maybe write to a users .bashrc (or equiv) so the virus get to run when ever the user logs in.
    But I dont see how a virus could do much more then mess with that user's files, it cant play with other users on the system (unless they get infected) and it cant attack the system itself

    1. Re:Got root? by CoolVibe · · Score: 5, Insightful

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

  6. virii by bsdparasite · · Score: 3, Insightful
    The strong permissions in UNIX have a way of helping people avoid these viruses, but with the growth of "Desktop" UNIX systems, more and more of these will pop up for sure. Clicking attachments from email, executing them on the fly, and permissions to execute scripts from E-mail software is not just restricted to Windblows. It will permeate the masses as soon as more and more "Desktop" type systems come into place.

  7. Shell script worms by GigsVT · · Score: 4, Insightful

    Not many people know this but:

    cat /dev/tcp/localhost/22
    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.
  8. I was thinking about this last week.... by jpmorgan · · Score: 2, Insightful
    If I wanted to write a virus to hit a lot of Linux systems, I'd have it infect shell scripts, make files and executables, and would have two running modes.

    In user mode, it is running as an unpriviledged user. It searches for configure scripts and make files to infect. The infected configure script/make file modifies the output binary of the build so it is infected with the virus immediately. How many of you check your configure scripts when you ./configure; make; sudo make install? How many would even be able to tell what an infected configure script looked like. The moment the infected configure script/make file/binary is run as root, it switches to root mode...

    Root mode. Infect every binary on the system. In fect the kernel. Infect the init scripts.

    What about those people who only ever install packages from say, red hat, or debian? Well, as soon as red hat or debian ship a piece of software developed by someone infected with the virus, bam, the entire distro is infected.

    This is all adided by the complexity of Linux development, the distribution model, and the fact that an extraordinary number of Linux users are under the mistaken impression that Linux's security model will protect them. There are too many user-created holes in security models, and there is a very poor trust mechanism. It's just waiting to be exploited. No Linux user expects to get hit by a virus, so it would take much, much longer to be detected than a Window virus.

    Security is a good thing. A false impression of security is a bad thing.