Softpanorama

Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells

Softpanorama Malware Protection Bulletin, 2000

Malware 2019 2018 2017 2016 2015 2014 2013 2012 2011 2010
2009 2008 2007 2006 2005 2004 2003 2002 2001 2000 1999

Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Sept 7, 2000] Hybris(hahaha, sexyfun) Virus

rather dangerous and pretty successful mail-worm that is not based on old VBA technology, but actually is an executable Trojan that mass mail itself to propagate.

Love Microsoft - Who's to blame for the ILOVEYOU virus Who else by James Gleick

In recent years, Microsoft's designers have deliberately blurred the distinction between opening some data and running a program. To run Word, you no longer have to find the program and execute it. You can run Word indirectly, just by clicking on any Word document, identified by its filename, ending with the three-letter extension .doc. In the same way, if you click on a music file in the .mp3 format, you will execute a music player-by default, of course, Microsoft's own Media Player. The virus executed the Windows Scripting Host because it endedwith the extension .vbs.

Microsoft Responds:

James Gleick's commentary on the "ILOVEYOU" worm ignores some important realities regarding the way software works and the ways people use it.

Perhaps most striking is the implication that viruses in general-and this virus in particular-are somehow specific to Microsoft products. In fact, the most famous incident of this type, the Internet Worm of 1988, spread exclusively through Unix systems, using a mechanism very similar to the one used by the "ILOVEYOU" virus. Even in the case of the "ILOVEYOU" virus, Microsoft products were not the only ones affected; at least two competing e-mail products were affected in exactly the same way as Microsoft's were.

The fact is that viruses can be-and are-written to run on any operating system, using virtually any software vendor's products. Gleick's article seizes upon the fact that this virus would not run on a Unix or MacOS system as proof that there must be a flaw in Microsoft products. But in fact, his statement is simply true by definition-the virus doesn't run on Unix or MacOS because it wasn't designed to. The author of the virus could have designed it to run on those systems but chose not to. Why? Because virus writers tend to be motivated by publicity. Compare the global news coverage that accompanied the "ILOVEYOU" virus with the near-total silence regarding major attacks against competing systems earlier this year, and you can easily see why the virus writer chose to target the systems he did.

People were writing Trojan horses, worms, and viruses for Unix, Macintosh, and other operating systems as back as far as the days of Windows 3.1 and before. They were able to do so because all modern software systems make it easy for one program to call another. Why do these systems do this? Because computers exist to automate tasks. You can't, for instance, integrate your company's invoicing and supply systems unless the systems can communicate with each other. Just the same, it's important to retain checkpoints where human judgment is needed. This is the role that the warning dialogues in Outlook serve-they're a compromise that attempts to give users fair warning without limiting their ability to use their systems.

Gleick nominates a number of design features-the blurring of the line between opening data and running a program, the ability to have more than one file extension, and so forth-as "design flaws" that contributed to the problem. However, none of these are central to the issue. The correct warning dialogues were displayed regardless of how the program was launched, and the correct icon was shown regardless of whether double file extensions were used.

If Gleick would review the history of Outlook's handling of attachments-and Microsoft's approach to security in general-over the past few years, he would see that Microsoft has mounted a vigorous effort to tune the tradeoff between ease of use and security. Our goal is to provide customers with the features they want, along with the security they need. We are continuing to review these tradeoffs on an ongoing basis and will, no doubt, make additional improvements in the future.

-Scott Culp and Steve Lipner
Microsoft Security Response Center
Reader Response from The Fray:

Re: Microsoft's response. Sure, other systems are subject to viral attacks, and, sure Microsoft systems are a big target. But, you fail to address the main points of the article, firstly that Windows blurs the distinction between programs and data, and, secondly and most importantly that any program--regardless of its source--can do what it likes to the system. This is a disaster waiting to happen. And this doesn't affect all systems equally. Linux/Unix limits access for ordinary users, Java has definitive protection from unvetted applications, and so on. Windows security relies on scanning what comes in, using inherently out-of-date virus signature lists. This level of security simply is not appropriate for a computer connected to the internet--if it ever was.

--Jim Birch

(To reply, click here.)

James Gleick has one or two good points, but who can I blame if I stab myself in the head with my brand new shiny Ginsu knife that slices and dices twice as fast? Ginsu promised me the best cutting knife in the world with all the features. What if someone were to attack me with that knife? Am I to blame Ginsu for making a knife so sharp that it's deadly? Should I have stuck with butter knives? What if I drive my safe Volvo with front and side airbags off the meteor crater in Arizona? Will Volvo take the blame? What if I continuously hammer my co-worker over his head with my phone? Damn that Nortel for making such a powerful piece of plastic. If I was smart, I might use the phone cord to strangle him with it. No matter how "safe" a product is, whether it's soft, hard, electronic, pointy, blunt, etc., there's a way to shoot yourself in the foot with it. There's inherent danger in everything.

--Jim F

(To reply, click here.)

Microsoft has chosen to ignore the heart of James Gleick's criticisms. Because they have, I will condense them to a single sentence: Windows Scripting Host gives a Visual Basic script the authority of the user executing the script, not the authority of the author of the script.

Because the script "inherits" the user's privileges, scripts received as attachments, or Visual Basic auto_run VBA procedures received in attached Office documents, can do just about anything the user who opens the document can do. That's why a script can not only make changes to the registry, but it can make changes to registry entries that control scripts. In other words, the registry says "scripts will time out in 10 seconds", and then Windows Scripting Host allows a running script to not only change that setting for all scripts, but for its own running session!

I would like someone at Microsoft to explain why Visual Basic scripts do not inherit the authority of their authors, rather than the person executing them. This strikes me as a fundamental security flaw in their design.

--John Carder

(To reply, click here.)

A methodology for studying untrusted software With Application to the Real Case of the WinSatan Trojan by J.C Hernández Castro, J.M. Sierra Cámara, A. Ribagorda Garnacho, B. Ramos Álvarez, and A. Muñoz Cuenca

USENIX ;login June '00

The IT Security Laboratory from the Carlos III University of Madrid was created in 1990, and since these days it has been focused on IT security research and development. Its members have participated in multiple research projects and have worked with a number of companies. They can be reached at <http://benjusuf.uc3m.es/miembros>.

The authors present a general methodology for studying untrusted software that is particularly suitable for the analysis of dangerous software (viruses, worms, and trojans). In many cases, it is useful to learn exactly what untrusted software does on a computer. This methodology is demonstrated with our work on the recent trojan called WinSatan.

sendmail.net killerresume

Jose Nazario has updated the .cf/.mc patch on his mirror site to include "Killer Resume" and was kind enough to share the fix with us. The patch, designed to block the ILOVEYOU worm and related worm/virus medleys, works on sendmail 8.9.x and above using the subject line checking options available. Koos van den Hout did the original based on last year's Melissa patch, with additions by Nazario and further tweaks by Keith Petersen at army.mil (who also modified the error code to be a 552, as per RFC 821).

It's worth noting that in the long run, header checks are an inadequate solution to this problem for a couple of reasons. First, they can cause email about the virus to bounce (as people on the Bugtraq list quickly realized at the time of the ILOVEYOU worm). Second, there's no reason to think this sort of thing won't continue, which means that the list of offending subject lines will eventually reach absurd proportions.

Leveraging the Power of the Windows Scripting Host

FlameThrower is a highly configurable add-in for Microsoft's Exchange and Outlook email that scans incoming messages to determine whether they're spam. If they meet the criteria you set, they're moved to a special folder. You can also create a list of senders you want excluded from the spam lists. (Shareware/Win95-98-NT) Click for more.

[May 19, 2000] Invoking procmail from sendmail. See also Invoking procmail from sendmail

Re: Invoking procmail from sendmail

Author: Per Hedeland <per@erix.ericsson.se>
Date: 2000/05/12
Forum: comp.mail.sendmail

...

>I read somewhere that you can invoke procmail from within sendmail. How
>do I do that? Does that mean that some filtering can be done in
>sendmail?

Summarized from another recent thread - this will send all mail through
procmail.

Put this in your .mc file:

FEATURE(`mailertable')
MAILER(`procmail')

LOCAL_CONFIG
CP PROCMAIL

LOCAL_RULE_0
R$*				$: <> $1			mark all
R<> < @ $* > $*			$: < @ $1 > $2			skip route-addr
R<> $* < @ $* . PROCMAIL . >	$: $>3 $1 @ $2			already filtered
R<> $* < @ PROCMAIL . >		$: $1				already filtered
R<> $* < @ $* . >		$: <> $1 < @ $2 >		remove dot
R<> $* < @ $* >			$: $1 < @ $2 . PROCMAIL . >	send to procmail
R<> $*				$: $1 < @ PROCMAIL . >		send to procmail

And in your mailertable:

PROCMAIL   procmail:/etc/procmailrcs/some.rc
.PROCMAIL  procmail:/etc/procmailrcs/some.rc

See cf/README in the sendmail distribution, and the procmail man page,
for further details.

You may also want to use

MODIFY_MAILER_FLAGS(`PROCMAIL', `+m')

or for pre-8.10 sendmail

define(`PROCMAIL_MAILER_FLAGS', `SPhnu9m')

in your .mc file - this will improve performance by sending mail for
multiple recipients through a single invocation of procmail, but makes
address-based processing in the procmaillrc trickier.

--Per Hedeland

per@erix.ericsson.se

[May 5, 2000] Note on Lovebug from the AV Defense Secrets

Lovebug is a VBScript worm (a worm is a type of self replicating program that does not attach itself to other programs -- so technically speaking it's not a virus, but who cares) that affected mainly users of windows 98 on May 4, 2000 and at least one full subsequent week. Other smaller groups of users that include users of Windows 2000 and beta testers of Microsoft IE5 browser were also hit, but still it looks like this worm was mainly Win98 oriented because this version of Windows was the most mass version that has so called Windows Scripting Host used by the virus (see below).

Like Melissa it spreads via mass mailed e-mail but Melissa limit mailing to the first 50 entries while Lovebug is greedy and mail itself to everybody. This worm is one of the new Melissa-style type of worms that make use of AV program less effective as it mass mail itself on the very first invocation. Therefore if it was not detected at this time it makes little sense to upgrade AV program in order to detect is afterward). But update of AV program when it was most needed proved to be a tricky business. The WEB sites of AV vendors were down due to this denial of service attack. For example McAfee WEB site was the first victim of the worm because is has the most clueless architecture (running on NT) with a lot of scripts, pictures and other bell and whistles died instantly under the load. Semantic site was slightly better and refused to die, but was extremely slow and from practical reasons can be considered as down from 10:00am on May 4th or so. Smaller vendors WEB sites died like flies on the frost. I do not envy people who tried to download, say, an update for F-secure on May 4th.

Actually the most useful source of information were portals that are used to huge traffic and served information all the time -- for example Excite had F-secure description stored locally and was probably the most assessable site with more or less valid information about the virus.

This epidemic also revealed a really bad state of e-mail filtering in some major corporations and ISPs and stressed the importance of filtering capabilities on the mail gateway. Several fixes for Sendmail were published the same day in the Sendmail Usenet group and were also available from Freshmeat the same day. Sendmail that generally is well known for the obscure configuration files provided official patch only on May 5. But it was essentially worse that some files suggested in the Usenet newsgroup. Several e-mail gateway vendors upgraded their products to make filtering easier.

Sendmail proved to be weak -- no patch blocking .vbs attachments was available during the week after the discovery of the virus. Exchange and Lotus Notes proved to be weak too from this point of view as well. Sendmail installtions that use Procmail were probably the only one that come out of this situation with flying colors, but very few people know how to use Procmail as a standard MDA with sendmail.

Procmail come out of this situation with flying colors

Here is the procmail fix from Tomas Andershem

 :0 B
* !^FROM_DAEMON
* !^X-Loop: viruscheck
* ^Content-Disposition:.*
* .*.vbs.*
| (formail -rI"Precedence: Virus" \
-A"X-Loop: viruscheck" ; \
echo "Our system received your mail,"; \
echo "but it found something that indicated a virus."; \
echo "and did not delivered this mail"; \
echo "Please do not respond to this mail, it is an auto reply"; \
) | $SENDMAIL -oi -t

The worm actively spread itself until at least May 11. Actually Monday May 9th was worse than Friday May 5 for some US regions.

[May 5, 2000] CNET.com - News - Enterprise Computing - Virus posing as Symantec email could be worst

Several clones with at least two written by people with good social engineering skills:

The mutation comes in an email with the subject header "VIRUS ALERT!!!" The email begins, "Dear Symantec customer," and proceeds to describe the virus in detail. Its attachment is called "protect.vbs."

This variant overwrites *.bat and *com files, in addition to the image and audio files already overwritten or hidden by the original "Love" bug.

c FWD: JOKE VERYFUNNY.
vbs
yes
d** I Love You LOVE-LETTER-
FOR-YOU.TXT.
vbs
yes
e Mother's Day Order Confirmation mothersday.
vbs
no
f*** Dangerous Virus Warning virus_warning.
jpg.vbs
yes
g**** VIRUS ALERT!!! protect.vbs yes
h***** A killer for VBS/LoveMail and VBS/Kak worm viruskiller.vbs yes

[May 5, 2000] sendmail.net lovefix -- See also Sendmail - Alert - Blocking Feature for Love Bug Extremely weak clueless patch. I am convinced that the best approach to the fighting lovebug is blocking *.vbs attachments but stupid filtering of the subject lines proposed. But instead of developing a decent patch Sendmail tries to be nice with AV vendors (see below ;-).

L OCAL_RULESETS
# Love Letter virus checking routine.
# You just need enough of a pattern to match.
# Instructional note: Follow these instructions exactly
# The format for the rule is
#
# RExactly the thing you want to quote
#
# No quote marks, no tabs, absolutely nothing in
# parentheses (like this, they're considered comments
# and will be removed before they get to the rules).
# After the exact thing, then a tab, and the $#error.
# Note, the $* matches anything, so it's useful for
# wildcarding. This also scans all messages with
# Subject: headers and invokes a rule, so there is
# a performance hit.

HSubject: $>Check_Subject
D{MPat}ILOVEYOU
D{MMsg}This message may contain the LoveLetter virus.

SCheck_Subject
R${MPat} $* $#error $: 550 ${MMsg}

Another sign of questionable usefulness of Sendmail

Sendmail tries to be nice with AV vendors, but actually fail to create a decent patch for ILOVEYOU than blocks *.vbs attachments ;-).

Emeryville, CA - February 29, 2000 - Sendmail, Inc., the provider of the ubiquitous Sendmail® Internet Mail platform for e-communications, applications and services, today announced a powerful new framework for easily and reliably preventing Internet-borne viruses from infecting corporations and service providers. Sendmail, Inc. is now providing API access for industry-leading anti-virus vendors such as Symantec, Trend Micro and Network Associates to deploy their solutions at the server-level on the Sendmail Switch product line. Integrated server-level virus scanning is a much faster and more flexible approach to protection that eliminates viruses before they reach the desktops of the end users.

[May 5, 2000] [fm] Sendmail protection for iloveyou worm

People tries to do something useful with Sendmail but most parches are limited to the subject line filtering due to defects in the product:

better (?) rules
Carles Mateu - May 05th 2000, 03:32 EST

Just a light modification to simplify the pattern filtering:

HSubject $>CheckSubject

D{MMsg} This message may contain some of the e-mail viruses (ILOVEYOU, MELISSA, etc)
F{MPat} /etc/mail/viruspats

SCheckSubject
R$={MPat} $* $#error $: 553 ${MMsg}
RRe:$={MPat} $* $#error $: 553 ${MMsg}
RFwd:$={MPat} $* $#error $: 553 ${MMsg}


And in /etc/mail/viruspat just add the patterns (one for line):
ILOVEYOU
Important Message

and so.

ILOVEYOU sendmail filter
Jim M. - May 04th 2000, 15:51 EST

This worked on our systems, it can be added at the end of the sendmail.cf. The only important formatting is there should be a TAB between the $* and $# in the last two lines. Note this (and the other one) will match any message with ILOVEYOU anywhere in the subject.

 HSubject:       $>Check_Subject
D{MPat}ILOVEYOU
D{MMsg}This message may contain the ILOVEYOU virus.

SCheck_Subject
R${MPat} $*	$#error $: 553 ${MMsg}
RRe: ${MPat} $*	$#error $: 553 ${MMsg}

[May 4, 2000] SECURITY- ZDNet UK- Experts call on firms to embrace bug free Linux

Technical director of Symantec Anti-Virus Europe Kevin Street stresses that even though it is impossible to infect a computer running Linux with a Windows virus, this doesn't mean Linux is totally immune to them. "Even thought a Linux mail server cannot be infected, it doesn't mean it wont be affected. The amount of mail it could receive might mean that it is brought down and even though your company is immune, you have no email."

[Jan.9, 2000] SecurityPortal.com Network Intrusion Detection Systems and Virus Scanners - are they the answer? by Kurt Seifried

http://www.securityportal.com/
Anti-virus software

Entire classes of software with literally hundreds (ok, maybe not hundreds but a lot) of companies producing products have sprung up over the last few years, and is now beginning to consolidate into several large companies providing complete product lines to cover everything you could want, and dozens of medium to small sized companies with sometimes just one main product. Of this the anti-virus software vendors were one of the original groups of vendors to start writing add-on software to enhance the security (which was non-existent on Microsoft platforms at the time) available for ensuring software that you used was not malicious. This has lead to an "arm's race" (apologies for using this but it is a decent analogy) between virus software writers, and anti-virus vendors. Most anti-virus software packages started out as simple programs that checked the files against a known list of "bad" ones (i.e. via checksum and so forth), which lead to polymorphic viruses (that is the software would modify itself a little bit each time, thus defeating this detection technique). The anti-virus vendors then started scanning the actual binary code for the various pieces of code present in viruses, and heuristic packages that supposedly figure out what the software will do, and based on that can block it if it is considered malicious (if this worked properly though we wouldn't be needing anymore virus signature updates now would we?). Additionally things have gotten more complicated, with the integration of anti-virus software with such services as email, www and ftp. A small list of "new" problems with anti-virus software that have come out in the last few months:

That's all I could find from the last month or two of Bugtraq. Obviously the anti-virus vendors have a ways to go before their products can even be called remotely reliable. The last dozen or so viruses that spread via email have all left the anti-virus vendor community flat footed, the Melissa virus (which was relatively harmless) resulted in several large sites (Microsoft, Intel, etc.) shutting down the mail servers (and in some cases it overwhelmed mail servers causing them to be effectively shut down).

It is obvious that anti-virus vendors will always be playing catch-up with the virus writers, which wouldn't be such a problem if anti-virus software updates were released quickly and people installed them. This is however impossible. The life cycle of a virus looks something like:

  1. virus is written, tested, possibly deployed on a test network (computers are cheap now) and otherwise honed
  2. virus is released, possibly on a selected target (university campus, corporate network, etc.)
  3. virus (if "successful" in a biological sense) spreads like wildfire, possibly causing severe damage (such as wiping motherboard BIOS chips)
  4. someone notices the strange activity, takes whatever data is left over, and sends it to an anti-virus vendor - this is the first point at which people start taking corrective steps, the virus has already had time to spread
  5. the virus is analyzed, decompiled, and otherwise ripped apart, a signature is created
  6. typically the anti-virus vendor will share data with other competitors, they may or may not do this promptly
  7. the anti-virus vendors issue bulletins, make the update (if one exists yet) available
  8. some customers with support contracts and so on will be notified, some will have automated distribution systems for the update, resulting in a rapid deployment of the fix, most will not
  9. network and system administrators, home users, and so on possibly read the advisory or hear about the virus on CNN, they get the update (which can be near impossible during peak times) and install it

During steps 2, 3, 4, 5, and up till 6 the virus will spread unchecked. Once an update is created and distributed the virus will only spread to systems without protection (a good sized percentage). The amount of effort it takes to install software on millions of computers is horrendous, even when heavily automated, compared to the amount of effort a virus author spends, the ROI (return on investment) can be significant.