ESET Threat Blog

Following my blog at http://www.eset.com/threat-center/blog/2009/12/18/a-trojan-anniversary, I came across a blog by Kurt Wismer that picked up the theme. As it happens, though I don't think we've ever met, Kurt and I have corresponded from time to time for quite a few years (fourteen, apparently), so I guess it's not so surprising that he also dates his entry into the anti-malware field back to 1989.

Kurt also pointed out that Eddy Willems (another veteran of alt.comp,virus) also posted a blog in which he too dates his entry into the field to 1989: apparently the AIDS Trojan was even more of a baptism of fire for him, After all the years I've been meeting Eddy at conferences, I can't believe we never compared notes on our "entry points" before, but then, the big conferences are often like those parties where you get to to talk to people for two minutes at a time till they wander off to another corner of the room to top up their drinks. Like speed-dating, but without the commitment.

 I'm sure I've recommended Kurt's blog at http://anti-virus-rants.blogspot.com/ here before and will again. He made an interesting point: was there a particular significance in events in 1989 that sparked people's interest in the field? Well, clearly Eddy and I had a push from Dr. Popp, but a sample of three is kind of small to come to conclusions on. However, it happens that there was a thread on an industry list back in the summer about this.

While I can't quote individuals because of the nature of the list, it certainly seems that there was a cluster of people from "our" generation entering the field between 1988 and 1991 (there were, of course, people who'd been in the field for some years before, and new people are coming in all the time). Most people were kickstarted by a close encounter with a specific instance of malware, though it wasn't always a big name like the Morris Worm or the AIDS Trojan. (Many took the route into analysis and development. Personally, I took a more convoluted route by way of systems administration: by 1991 I was building shell systems to make fairly basic scanners more "real-time" but always found myself being steered back to user support and documentation.)

Even though I think you can look at specific malware in retrospect and think "Ah, that was an indicator of things to come" (as I did in my earlier blog with the AIDS Trojan), I think Kurt is probably right when he suggests that the real significance of that particular period is that "that's about when awareness of the malware problem … was reaching the critical mass necessary to entrench itself firmly in the general public's consciousness – first as an obscure curiosity, but as an increasingly real and oftentimes personal annoyance …"

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

ESET Threatblog (TinyURL with preview enabled): http://preview.tinyurl.com/esetblog
ESET Threatblog notifications on Twitter: http://twitter.com/esetresearch (or @ESETblog)
ESET White Papers Page: http://www.eset.com/download/whitepapers.php

Securing Our eCity community initiative: http://www.securingourecity.org/

Also blogging at:
http://blog.isc2.org/
http://avien.net/blog
http://blogs.securiteam.com
http://dharley.wordpress.com/

Conficker

• If you have not already done so, deploy Microsoft’s MS08-067 patch for the vulnerability initially used by the worm to infect systems.  It is also a good idea to install the MS08-068 and MS09-001 patches as well.
• Disable AutoRun on removable media.  More about this below.
• Use strong passwords.  The Conficker worm contains a set of commonly-used passwords in order to make it easier for the worm to spread across network shares.  A list is mentioned in this news article.  For more information about choosing good passwords, see these three earlier ThreatBlog articles here, here and here.  We also have a white paper on the subject.

Worms continue to spread quick as a flash

Conclusion

Aryeh Goretsky MVP, ZCSE
Distinguished Researcher

I’m often exasperated by blinkered mindsets in the Mac community, of the security-related kind that Randy highlighted in a recent blog. You might have picked up a certain irritation in some of my blogs around the end of last month relating to Snow Leopard and malware detection, too. So it was refreshing to come across a light in tone but very much to-the-point piece by Adam Banks in Mac User.

The bit that originally caught my attention was a reference to a Mac keyboard hack described by K. Chen of the Georgia Institute of Technology at this year’s Blackhat: it describes a Proof of Concept attack on Macs using the firmware update mechanism for the Apple Aluminum Keyboard. (It’s an interesting paper, but the content is both less dramatic than some have implied and wider-reaching: lots of peripherals and other hardware has updateable firmware – not just PCs and routers, but stuff you might not have thought about such as audiovisual equipment. I’d worry about this a lot more if there weren’t mitigating factors such as the sheer diversity of brands within product classes and the fact that physical access is usually sine qua non for this kind of attack so far. Even the keyboard attack isn’t specific to Apple, but to USB keyboards in general. There’s some interesting comment to all this at Slashdot and at Intego by the way.

[Though no-one seems to have noticed that Trojanized keyboards for Macs are, not unlike Win32/Induc.A, a new spin on an old concept. The "Welcome Datacomp" message, often mistaken for a virus symptom in pre-OS X days, was actually caused by a third-party keyboard for Mac. A quantity of these keyboards were released with a Trojanized ROM.]

Still, it’s unusual to read about security matters that geeky in a Mac consumer magazine, so I read on. (Ken Bechtel, if you’re reading this, put your coffee down.) 

Adam wonders "What’s going to be the next cyber-security threat? Biscuits?" Well, he could be right there. Biscuits (or cookies, if you must) are, according to the Daily Telegraph, responsible for a wide range of injuries to humans including scalding, chipped teeth, choking, and assaults by hungry pets. Strangely, the article doesn’t mention the damage that can be done by an over-dunked Morning Coffee biscuit to an adjacent keyboard. Not a pretty sight.

But I’ve strayed from the point: what was Adam’s point about security that appealed to me so much? Well, there was a whole barrage of points about Gary McKinnon, Sony rootkits, and attacks on social networking. But the one that really grabbed me was the one about a suggestion by London’s comic-relief-in-political-residence,Boris Johnson, that the Pentagon should employ McKinnon as a consultant. I’ve often wondered, sometimes publicly, why people who don’t have much experience of IT security are so apt to assume that getting caught is proof of hacking competence that eclipses the knowledge of security professionals. But Adam puts it much more succinctly and wittily.

"Employing McKinnon as a security consultant would be like catching a six-year-old nicking sweets and enrolling him in Hendon Police College."

I’m not sure that McKinnon deserves the years in prison that are hanging over his head. But I’m pretty sure the US security services have lots of IT security expertise. They’re probably not responsible for the slack systems administration that allowed McKinnon access to all areas.

[Tip of the hat to Gadi Evron for pointing out the aggressive biscuits article!]

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

ESET Threatblog (TinyURL with preview enabled): http://preview.tinyurl.com/esetblog
ESET Threatblog notifications on Twitter: http://twitter.com/esetresearch
ESET White Papers Page: http://www.eset.com/download/whitepapers.php

Securing Our eCity community initiative: http://www.securingourecity.org/

Nigel Morris, of the UK’s "Independent" newspaper reported recently on new powers given to police in the UK and proposals to extend similar powers across the European Union.

Understandably, civil rights groups like Liberty have apparently expressed the belief that such expansion of "police hacking operations" should be regulated by Act of Parliament and that there should be a requirement for the police to apply to a court for a warrant.

An issue that could be of particular concern to anti-malware vendors is that the article refers not only to the use of keylogging hardware and eavesdropping over wireless networks, but also to the practice of "sending an email containing a virus to a suspect’s computer that then transmits information … to a distant surveillance team."

It’s not clear to me whether a "magic lantern"-like Trojan is really on the cards or whether that’s a political journalist’s extrapolation. The fact that the article refers to a virus rather than a Trojan raises a red flag. I seriously doubt whether replicative malware would be considered the best way to spread a tool like this: you might want to bug every PC in the world, but to do so via a virus might be seriously counterproductive, since every bugged PC would increase the likelihood of detection sooner or later. (Yes, I can see some possibilities for making a viral scheme more viable, but I’m not sure this is the place to discuss them…)

The fact that the article also talks about distribution by email attachment also suggests a fairly vague hypothesis, rather than deep knowledge of how things really are in the current threatscape.

The idea of a "good" Trojan like the FBI’s does pose serious ethical issues, though I won’t go into those now. The question is whether a UK or other European government would attempt to force a vendor to "ignore" it. That risk may be overstated: apart from anything else, they’d have to share information about the precise nature of the Trojan with a great many companies worldwide, militating against the covert nature of this approach to surveillance. However, other governments have certainly explored this possibility: there’s actually a term – "policeware" – that covers certain software tools used by law enforcement .

David Harley BA CISSP FBCS CITP

I’ve just picked up a comment to a previous blog that pointed to what I presumed to be a malicious URL. We’re grateful for all such information, but for obvious reasons, we won’t approve comments that point to malicious code!

You can find information in our knowledgebase here about how to forward malware samples or false positive samples to our labs: it doesn’t specifically mention malicious URLs, but you can send those to the same address.

It’s not that we’re not willing to pass on information to the labs ourselves (and I’ve already forwarded the link), but it’s much more effective for you to send the information direct. As a case in point, it turns out that by the time I saw this comment and forwarded the link, our products had already been updated to detect this particular binary.

Thanks!

David Harley CISSP FBCS CITP
Director of Malware Intelligence

Hello again. I’m back from Washington (not to mention Vienna, Bratislava and York), but I haven’t escaped from detection testing issues. Not that I’m complaining: after many years of campaigning for better testing and better information about testing, it feels very positive that people are prepared to sit through a 60 minute presentation and then go on asking questions for another half hour. We may be a very long way from solutions to some of the problems that concern me, but recognizing that they exist and taking a is a vital step towards those solutions.

First of all, let me mention that the UK computing magazine Computer Weekly has just published one of a series of columns I’ve been doing for them. And yes, it’s about detection testing, AMTSO, the Universe and Everthing. To be precise, it’s a follow-up to a column on the same subject I wrote before the Anti-Malware Testing Standards Organization was founded, as it seemed a good time to consider what impact the organization has had so far on the testing problem (or, rather, the problem of bad testing) and the thorny issue of static testing versus dynamic testing.

Secondly, for our Spanish-speaking readers (¡Hola!), we’d like to draw your attention to the fact that the ESET team in Latin America have made available Spanish translations of the two essential documents on the "Fundamental Principles of Testing" and "Good Practice in Dynamic Testing" approved and published by AMTSO last month. The translated "Principles" document is available at  www.eset-la.com/amtso/amtso_principios.pdf, The "Dynamic Testing" document is at www.eset-la.com/amtso/amtso_mejores_practicas.pdf.

I’m currently working on a list of available resources relating specifically to anti-malware testing: watch this space for more details.

David Harley CISSP FBCS CITP
Director of Malware Intelligence

CNET, who hosts Download.com, has enjoyed a reputation for being a safe place to download software from. The program you download may be great or may be useless, but it had been “Tested Spyware Free.” At least that is what Download.com says about their downloads.

Today it has come to my attention that the site is hosting two notorious spyware/adware programs. One of the programs is called “Anti-spyware 2008” and the other is called “Anti-virus Defender 1.01”

According to Download.com these programs have been tested free of spyware, viruses, and other malware. Unfortunately, many security products have a very different opinion. These fake security products will infect your computer, rather than protect your computer.

As always, do some research before deciding on a security product to evaluate. For anti-virus/anti-spyware look for testing at Virus Bulletin (http://www.virusbulletin.com), and/or certification at West Coast Labs (http://www.westcoastlabs.org/) and ICSA Labs (http://www.icsalabs.org/icsa/icsahome.php). For West Coast Labs you’ll want to look at the Checkmark Certification tab. Virus Bulletin does not test anti-spyware, however both the ICSA and West Coast (Checkmark) certify products for spyware detection and removal.

It is not clear at this time if CNET’s Download.com was hacked, or the malicious software found its way there by other means. Certainly a label “Spyware free” should be viewed with a high degree of skepticism. Any one can say it.

Randy Abrams
Director of Technical Education

Randy has just reminded me that today is the 20th anniversary of the Morris Worm (sometimes known as the Internet Worm), which came as close as anything else to shutting down the entire internet. It didn’t, of course: it  only ran on and propagated from machines running specific versions of Unix on specific hardware platforms. However, the internet was, and to some extent still is, definable as the sum of the computers that are connected to it, and a small but significant group of affected (and infected) server had a major and debilitating effect on the entire internet. Most people remember its (considerable) impact on mail services, but a lot of other services were affected.

The worm used two notable exploits. It exploited a buffer overflow vulnerability in a widely used version of fingerd. (The once widely-used finger service is both less exciting and more interesting than it sounds: it enables pretty much anyone to harvest more information about you than you might be altogether comfortable with. Which is one of the reasons why, by the time I became a Unix administrator in the early 90s, it was already common practice to disable or restrict the service.) It also made use of the fact that sendmail was, at that time, commonly shipped with debug mode enabled, making it rather easy for an attacker to pass commands to the host system.

It’s usually accepted that the Morris Worm was not intentionally destructive. However, it included a somewhat buggy replication process that could have a serious impact on the host system, resulting in the degradation of a number of processes and services (a characteristic shared by many later viruses and worms). Furthermore, it attempted to break into user accounts on an infected machine, using basic guessing and dictionary techniques similar to those used by many bots and mass-mailers. It even included a routine that was supposed to pass back information about its own progress to a machine at the University of California (as it happens, it didn’t work), which could be seen as a first step towards the tracking and Command & Control features of so much later malware.

In fact, in "Viruses Revealed", Robert Slade and I said that ""In many ways, the Internet Worm is the story of data security in miniature." Seven years on from that book, though, I’m not so sure. 1987’s CHRISTMA EXEC worm included the social engineering dimension that doesn’t seem to have interested Morris, whose worm was strictly self-launching, and prefigured the mass-mailers that plagued our lives by the turn of the century.

Next year, by the way, is the 20th anniversary of the "AIDS" Trojan, and therefore of my own assimilation into the security industry. Watch this space (sometime around the 19th December 2009…)

David Harley CISSP FBCS CITP
Director of Malware Intelligence

References

"The Internet Worm Program: an Analysis": Eugene H. Spafford); http://homes.cerias.purdue.edu/~spaf/tech-reps/823.pdf

"With Microscope and Tweezers: An Analysis of the Internet Virus of November 1988": Mark W. Eichin, Jon Rochlis; Proceedings of the 1989 IEEE Computer Society Symposium on Security and Privacy, 1988

"The Morris Worm (Internet Worm)" in "Viruses Revealed" by David Harley, Robert Slade and Urs Gattiker (Osborne 2008)

"The Art of Computer Virus Research and Defense": Peter Szor (Addison-Wesley 2005)

"21st Century Paranoid Man" by David Harley and Ken Bechtel in "AVIEN Malware Defense Guide for the Enterprise", edited Harley (Syngress 2007)

You may have noticed that we have an intense interest in issues around sample-sharing and testing. Recently we noticed a thread in a forum associated with a free security product, originating in an open letter to a well-known tester, asking him to donate his sample set for the improvement of the product.

You might think that the anti-malware industry might hate the idea of free anti-malware products. As it happens, we aren’t against free products in principle: some companies make a free version of their software available for home users, and others (like ESET) make a free on-line version available. (There is a problem with many free products if the user gets the idea that they’re better protected by freeware than is really the case, and I’ll revisit that issue in another, more general blog.)

However, on this occasion, many of the people involved in the thread have missed the point, and that’s the point I want to focus on now.

Sample sharing in the anti-malware industry is done on the basis of responsible, ethical exchange between trusted parties (including reputable testing organizations). The exchange might be regulated by contractual agreements, but even when the agreement is informal, it’s always on the assumption that the same samples will only be passed on subject to terms acceptable to the original source of the samples.

In other words, if source A gives samples to tester B, A is entitled to expect that B will not pass them on to anyone else unless that’s within the terms of their agreement, and that if B does pass them on, it will be in a responsible manner to a trustworthy individual. (Let’s be original and call him C.) If those expectations are not met (as when B doesn’t have permission to share A’s samples, or A doesn’t regard C as a trustworthy individual), the trust relationship between A and B evaporates: A stops giving samples to B, so C’s supply also dries up. Everybody loses.

It’s not about C being in competition with the commercial interests of mainstream vendors: the purveyors of free software aren’t generally able to offer the full range of features and support that commercial vendors can, so aren’t really in competition. It’s perfectly possible for a developer of free software to develop trust relationships of his own with the anti-malware industry, but he has to prove in some way that he’s honest and competent.

Let’s assume that C is a sincerely well-meaning individual with no hidden agenda, but has no interest in co-operating with the anti-malware community at large. That may be because he doesn’t trust that community, which is his prerogative, but means there is no basis for a mutual trust relationship. Even worse, he may not understand not only the ethical framework but also the technical issues around co-operation in the industry, which suggests that he doesn’t really understand the nature of the threat he’s aiming to mitigate. (That’s also an issue that deserves its own blog.)

To attempt to use someone else’s trust relationship to get an occasional transfusion of samples so as to avoid subjecting oneself to the scrutiny of the anti-malware industry would , regardless of the ethical issues, simply not be a practical approach to maintaining a serious malware-specific scanner.

David Harley
Director of Malware Intelligence