ESET Threat Blog

Well, there’s not much doubt about the SecurityFocus view of the Race to Zero event. A report by Robert Lemos is festooned with advertising that states "If you want to stop a hacker…you have to act like one." Perhaps Symantec, who own SecurityFocus, can afford to be relaxed about the event, since their scanners weren’t represented in the test panel. All that apart, what are we actually learning as we pass zero?

Well, according to organizer Simon Howard we’ve learned that pattern-based detection isn’t working. Well, no, Simon: signatures actually work very well against known viruses. Do you really think it’s unnecessary to detect old viruses (maybe you should read our earlier blogs on Angelina and Helkern, or Kurt Wismer’s comment piece in the August issue of Virus Bulletin), or are you insisting that we should detect them heuristically? Given ESET’s expertise in heuristics, we’re not going to deny its importance, but in some contexts, signature detection can actually save a lot of processing time, depending on how it’s implemented. And who on earth told you that server-hosted anti-malware doesn’t use behavior analysis?

We’ve also learned that antivirus researchers started using "behavioral detection" in 2006. Except that some of us have been using proactive techniques for many more years than that.

Furthermore, we’ve learned that there’s a certain amount of confusion out there about what constitutes a variant, what is meant by "in the wild", and what the differences are between an exploit, a vulnerability, and a worm. (I think I’ll tackle those issues in other blogs: this is already taking rather too much of a Sunday afternoon when I’d rather be watching the Olympics).

So, so far, we’ve learned that if you modify malware - whether it’s an old soldier like the Stoned boot sector infector or a recent troublemaker like Virut (a polymorphic which even without handcrafting still causes some products real difficulty) - you can very quickly tweak it enough to hide it from any scanner you target. (Actually, you don’t even have to modify it by hand, but we already knew that, and the chances are that you did, too.)  

Still, as Simon says (you have no idea how careful I’m being not to take a cheap shot here), the whole exercise is worth it if all those Moms and Dads who avidly follow SecurityFocus (apparently) change their anti-virus settings to activate the "behavioral features".  Except, of course, that it’s rather unusual to find a mainstream anti-virus scanner that uses only signature detection, even in its least paranoid settings.

Well, that’s enough goading of the anti-AV crowd who are, no doubt now queueing up to heap abuse upon me. Here’s a wholly serious thought.

When this contest was first publicised, I said that no mainstream anti-virus company would take part directly because of the possible damage to their reputation as an ethical organization. That seems to have been largely true, but one of the teams represented in the contest turns out to have consisted of researchers from a security firm that does operate on the fringes of the anti-malware community, though they don’t actually have their own AV product. I find that a little sad that they’ve endorsed this competition to the extent of actually participating, without at least acknowledging the legitimate concerns of the anti-malware community as a whole. Well, perhaps they did, but those comments weren’t quoted. From some other comments that were made, though, I suspect that they simply weren’t aware of them.

David Harley
Malware Intelligence Team

An interesting comment turned up today to my "Malware du Jour" blog entry at Securiteam (http://blogs.securiteam.com/index.php/archives/1121). The poster asked a couple of questions, based on content from the ESET mid-year Global Threat Report, one of which was ‘How do you define "possibly unwanted applications [PUAs]?"’

My first thought was to refer him to the definition on our own web pages, but I couldn’t actually find one, so that’s something I’ll be addressing forthwith. My second thought was to refer him to the vendor-neutral definition on the Virus Bulletin site, which I did. Good though that is, however, for me it lacks a dimension. There’s an essential distinction to be made between PUAs and other forms of adware and spyware, largely based on the existence and validity of a corresponding EULA (End User License Agreement).

In general, a PUA has some functionality that might just be considered useful by the PC user. Or else the PUA is installed as part of the installation/configuration process for another package that the PC user is consciously desirous of installing: in such a case, the user might accept the intrusive activities of the PUA as a trade-off against the advantages of installing the primary package. Characteristically, the package or packages will include some indication of the intrusive, privacy-compromising, or other less-desirable functionality, though it’s likely to be buried deep in the EULA where the user is less likely to notice it (and is not necessarily fully informative about what a nuisance that functionality is likely to be in practice!)

There is a (sometimes rather hazy) line where we can stop giving a program the benefit of the doubt as being "possibly unwanted" and categorize it as an out-and-out Trojan horse. Some examples of this include:

• When it doesn’t give any indication whatsoever of the undesirable functionality it includes: for example, when DNS (Domain Name Service) lookup utility or search engines are compromised so that the PC user can only access the sites that a remote attacker wants him to access.
• When the program is associated with unequivocally malicious or fraudulent activity such as the "infection" of other PCs, or the dissemination of phishing messages.
• When the program pushes its own agenda, or rather that of its creator or a remote attacker(bombarding the system with advertising material such as pop-up messages, using it as a conduit for the distribution of spam or malware, fake "anti-spyware" packages, and so on) so that the PC owner is unable to use his system for his own legitimate purposes.  A prime example is Virtumonde, which isn’t noted for giving the victim any choice about installation, is made deliberately difficult (even unsafe) to remove, and hits an affected PC with so much garbage that it becomes effectively unusable.

Before I was assimilated by the anti-malware industry, I regarded the PUA/PUP category as a slightly weaselly way of saying "This describes something you really don’t want on your machine but we’re at risk of legal action if we describe it as malicious." However, the last thing a hard-pressed security company needs is to be harassed by crooks with smart lawyers. And the sad fact is that some people may see usefulness in something that most of us hate with a passion: otherwise, no-one would ever respond to spam…

Our mid-yearly Global Threat Report looks at malware threat trends over the past six months, based on data from our ThreatSense®.net threat tracking system. This report focuses on broad trends rather than individual malware variants: this reflects better the proactive detection which is the strength of our products, but is also more useful to most readers. Here’s a fairly brief summary of a rather bulky document.

• Malicious software that tries to use the Windows Autorun facility to self-install from removable media (such as flash drives and CDs) continues to flourish. While we have an efficient heuristic detection for this, we strongly advise disabling the facility in Windows.
• We’ve been seeing high volumes of malware intended to steal passwords for online gaming and virtual worlds like Second Life since 2007 and earlier, but are now seeing a dramatic upsurge. This isn’t just about teenage mischief any more: the theft of “virtual” treasure often translates into real profit for organized criminal gangs. While we’re pleased to see other security vendors taking more notice of the issue recently, users in general need to be aware of just how much malicious activity occurs in virtual worlds (phishing, “grey goo” viral malware, griefing attacks). 
• Potentially Unwanted Applications and other adware and spyware continue to constitute a large proportion of the programs we detect. While such programs are sometimes defended as being harmless and legitimate advertising material, they’re often presented in a deceptive manner, skating over the damaging effects on the usefulness of an affected system: 
  • Extensive modifications are made to the host system, and may entail breaches of privacy, inability to access legitimate sites, and exposure to malicious sites and software.
• • Once installed, it’s made intentionally difficult to remove the application, especially when it’s still in memory.
  • The performance hit caused by the program’s payload can amount to a denial of service. Adware like the Virtumonde Trojan can serve so much advertising material that the system becomes effectively unusable for the legitimate purposes for which the owner acquired it.
• The use of email as a direct channel for the transport of new malware is in dramatic decline, though email remains a major vector for the transmission of malicious URLs, so that social engineering is used to persuade the recipient to access a malicious web site. Malicious attachments are far less likely to be completely new threats: indeed, many of the top detections are elderly mass mailers like Netsky.Q, suggesting that the main sources of email-borne malware nowadays are unprotected machines, probably mostly home machines rather than corporate systems.

As a result of the way the threat scene changes at an ever-accelerating rate, most of our top-ranking detections are generic and/or heuristic, focusing on detecting and blocking malware before it has a chance to cause damage, rather than waiting for detailed laboratory analysis. Generic signatures and advanced heuristics identify new malware through code and behavior analysis, supplementing signature detection and greatly expanding the range of threats detected. It’s also possible when a product uses advanced multiple heuristic algorithms, for a single sample to be detectable potentially by more than one detection (generic, heuristic, or signature), and several factors may determine which detection is actually “flagged” when the scanner checks the sample.

The only detection in the global top ten over the period in question that identified a specific variant was an IRCBot variant. Bots remain a major malware issue, but tend to be somewhat under-represented in “top ten” lists based on prevalence, because of the wide range of bot families and the comparatively short lifespan of specific bot instantiations. Successful botnets are highly adaptive, continually changing and evolving in order to reduce the risk of detection by security software: they don’t tend to be propagated by long runs of the same malware.

The full report can be found at http://www.eset.com/threat-center/  If you have any questions or comments on the report, please mail threatreports@eset.com.

David Harley
Malware Intelligence Team

I had an interesting query from Scientific American (see Larry Greenemeier’s blog at http://www.sciam.com/blog/60-second-science/post.cfm?id=apple-disses-hackers-black-hat-conv-2008-08-05 to see the main thrust of the discussion). He asked, "Could Apple’s move to pull its security presentation from the Black Hat conference backfire on the company and make the company more of a target for hacker scrutiny? Why?"

It certainly made them a target for discussion on Slashdot (http://it.slashdot.org/it/08/08/03/0031228.shtml), which isn’t quite the same thing, but to some extent reflects hacker (in quite a broad sense) interest. Unlike Herbert Thompson, who’s quoted in the original blog, I’m not convinced, though, that this reticence is going to increase scrutiny: there’s already plenty of interest in the platform from hobbyist hackers, profit-driven gangs (a persistent trickle of malware, fake antispyware etc), not to mention security companies (a couple of AV companies have dipped their toes into the Mac arena in the last year).

In my view, the real damage to Apple is that they’ve given the impression that their security initiatives are driven by marketing considerations. Of course, in the real (corporate) world it’s quite normal to maintain right of veto over public statements and appearances (that goes for the public sector too), but there are a lot of people falling into the general category of "security researcher" who aren’t particularly aligned with the corporate world and have little sympathy with it, let alone understanding of how it works. 

That said, Apple continue to display a worrying naivete and, in some instances, lack of awareness ("We don’t know of any OS X malware"). They give the impression of remaining wedded to a model of "no discussion, tight product control, and no disclosure until we’re ready" that sits strangely with their extensive use of open source code. A lot of people have pointed to the fact that their latest patch, while addressing DNS issues, is incomplete (http://isc.sans.org/diary.html?storyid=4810), though in fact that applies to other vendors too. I’d say that in the last year or so fewer people have been ready to accept Apple’s security credentials as a given, and perhaps the company could learn something from Microsoft’s experiences over the past several years. Not that Microsoft hasn’t made its share of mistakes, but it’s done a fair few things right, too, in security terms. And in today’s world, no-one can afford to be seen as thinking that "security isn’t important".

It does seem to me that the simplistic model of "Apple good, Apple safe: Microsoft evil, Microsoft unsafe" is years past its best-by date: mistrust the credentials of anyone who takes it as read.

David Harley
Malware Intelligence Team

Alas, Andrew Lee, our beloved leader in the Research team, has left ESET for green fields and postures - er, pastures - new. He was last observed heading for the beach and muttering something about bikinis, but assures us that he isn’t leaving the antivirus industry. That’s certainly a good thing, as even before he joined ESET, he was well respected in the industry, and his influence since joining has extended far beyond the borders of ESET.

In the Research team, we’ll miss his support and his vision, not to mention his wit. Especially those of us who have inherited his enormous workload.

All the best, AJ. See you at a conference or a workshop soon, I hope.

David Harley
Malware Intelligence Team

 For many years, anti-malware industry developers and researchers have been waging a bitter war against malware writers. Even if the objectives of the malware writers have radically changed from fun to profit, the arms race has always continued. Malware writers are constantly trying to create programs that will evade antivirus detection. On the other side of no-man’s land, antivirus software developers have constantly worked to create innovative and efficient solutions with the best possible malware detection rate.

Various techniques can be used to bypass antivirus software. Some types of malware continuously modify themselves to look different every time they infect or execute, thus fooling some solutions. In fact, in the 1990s the rise of the polymorphic virus changed the face of the industry when some antivirus vendors who were unable to keep up with this trend simply abandoned ship. Another "classic" approach is to hide the evidence of compromise or infection from security software using stealth techniques: we used to call this advanced or level 3 stealth. While present-day rootkits often use stealth techniques to conceal their presence. (http://www.eset.com/download/whitepapers/Whitepaper-Rootkit_Root_Of_All_Evil.pdf). On occasion, malware may attempt to exploit some feature of a specific security program, especially a programming error leading to a vulnerability such as a buffer overflow. While you might get the impression from the media and some sectors of the security industry that this is an enormous problem, in real life such vulnerabilities are dealt with as quickly as possible, and we don’t see much evidence that malware authors spend a lot of time on exploiting such vulnerabilities.

More aggressive malware may also try to disable security software, including personal firewalls and antivirus. There’s nothing novel about this: we’ve been seeing it for decades. Malware intentionally interfering with antimalware software goes back to 1990, at least. Antivirus software and malicious software, however sophisticated, are simply programs that execute within an operating system. The fact that one program can sometimes affect the running of another (and even disable it) is not a bug that needs to be fixed, but a normal function within most operating systems. (There are operating systems that enforce much stricter control, but it’s unlikely that you have one on your desktop.) For example, it is mandatory for a program that manages the power on a laptop to be able to suspend all processes when the system is going into hibernation.

Some malware families have been trying to disable ESET Antivirus (and other top-rated anti-malware products) for years and, in some scenarios, will succeed: this is something we take seriously and we have implemented various defensive mechanisms to reduce the likelihood of their succeeding. It isn’t surprising when the bad guys go out of their way to target a solution that’s particularly noted for its ability to detect many new threats proactively. After all, a program that can evade detection by ESET Antivirus is likely to be missed by many other vendors, too.

 While we do our best to mitigate the risks from our side, there are also a number of simple measures that any antivirus user can take to reduce the risk that their scanner will be disabled by a malicious program:

• Make sure your security software is kept up-to-date
• Log onto the system as a normal user without administrative privileges instead of an administrator (in Windows) or root (in Unix-derived systems):. If the antivirus program executes with higher privileges than the user logged in (as happens with Windows service or a Unix daemon), a malicious program with lower privileges (those of a normal user) will normally be unable to terminate the antivirus (assuming the absence of some form of privilege escalation exploit).
• Keep operating systems and applications fully patched and up-to-date with all hot fixes
• Avoid risky web sites (we know, easier said than done: the trick is to be cautious and if in doubt, don’t)
• Enable all security features in your web browser
• Above all, don’t run software from untrusted and untrustworthy sources.

It doesn’t matter how sophisticated malicious code is if it never gets the chance to run. Don’t fall into the trap of thinking that security software (even ours!) offers such perfect protection that you don’t have to think about whether it’s wise to run a program from an unreliable source. Anti-virus can’t catch everything, even with advanced heuristics like ours.

The ESET Research Team

Kurt Wismer (whose blog at http://anti-virus-rants.blogspot.com/ is well worth tracking, by the way) responded to my “Giving Old Viruses the Boot” blog as follows (I’ve only just seen it, hence my re-opening the topic as a fresh blog, rather than as another response to the original blog):

kurt wismer Says:
June 20th, 2008 at 11:39 am
“How could such an elderly virus infect a protected system? ”

’simple - old viruses never die, they just become too rare to measure their prevalence accurately…’

The question I was trying to answer was actually how an aged BSI (Boot Sector Infector) can be detected post-infection but not pre-infection. In fact there are at least two relevant scenarios: (possibly inadvertent) floppy booting, as mentioned above, and infection earlier in the supply chain, before AV was installed. Most times, the scanner should have picked up the infected boot sector when the diskette was originally accessed, but if the diskette is inserted but never accessed and then left in the drive, that will usually result in an infection.

I suspect, though, that Kurt had in mind the fact that manyvendors no longer detect obsolete malware of a certain age, and in fact that does seem to have happened with regard to Stoned.Angelina and the infected Medion laptops of 2007. I can understand why vendors sometimes drop detection for antique zoo viruses (though sometimes this can result in poor performance in detection tests that use large collections of obsolete malware), but there’s clearly an additional risk in dropping detection of malware that was formerly in the wild. (Actually, I’m surprised Angelina hasn’t made a return to the WildList: maybe I blinked and missed it.)

Thanks also to Derek W. for pointing out that "Actually, some BIOS now have a switch for “OS Install” that won’t allow updates to the boot block area unless its set to “Enable”." Over the years, there’ve also been attempts to do something like this in software, with varying degrees of success. Certainly, though, this seems a useful facility, given that the occasional BSI zombie does continue to come to life. And I won’t even mention MBR-infesting rootkits…

David Harley
Research Author

Further to my recent post on the venerable (but still out there) Slammer worm, we were asked recently about a real old-timer, a boot-sector infector called Stoned.Angelina. (Oddly enough, I think this was the last BSI reported to me when I was still doing occasional 2nd-linet AV support earlier in this decade.) How could such an elderly virus infect a protected system?

For those who may have missed out on this phase of virus pre-history, a BSI infects when a PC is booted with an infected floppy (remember those?) in drive A. (The floppy doesn’t have to be bootable.) Which is why we used to advise people to reconfigure their PC CMOS settings so that the system would boot by default off the hard disk even if there was a floppy disk present - when people made extensive use of the funny little things, it was surprisingly easy to forget there was one still in the floppy drive when you switched off the system.

From a detection point of view, the difficulty is that if the system isn’t initially booting from the hard disk, the infection has already taken place by the time a scanner gets a look-in, and, unfortunately, NT derived systems can present particular problems if a BSI does manage to infect the hard disk.

Because so many systems nowadays are floppy-free zones, we tend not to give much thought to the issue. However, there are clearly still vulnerable systems and infected diskettes out there. If this might apply to you, you might want to consider:

• Checking CMOS configuration on all systems (especially older systems) and fix any that are still set to boot by default from drive A
• Doing a little data housekeeping. Floppy disks aren’t the most reliable of media for very long-term storage, and you may want to transfer data that still need to be kept to a more resilient and less risky storage medium.
• While you’re doing that housekeeping, you might want to take the opportunity to scan those disks with an up-to-date scanner. Certainly I have floppies around here that were probably last checked with scanners that don’t even exist any more.

David Harley
Research Author
ESET LLC

With the release of ESET’s Mobile Antivirus, a security solution for smart phones, I started asking myself about mobile threats. While there is not as much malicious software attacking mobile platforms as exists in the desktop world, I was able to find some interesting samples to analyze. The following is an analysis of the WinCE/Brador.A malware.

The first job most malicious programs do upon execution is to insure they will be started every time an infected system boots. To do so, Brador.A copies itself to the \\Windows\\Startup folder under the name svchost.exe. Under Windows mobile, there is no need to modify the registry to start an application automatically.

The main functionality of the threat Brador.A is to open a backdoor on the mobile device. The attacker is notified by an email when a new device is infected. The backdoor can perform the following tasks:

• Find a file on the local drive
• Read a file from disk and send it to the attacker
• Execute an executable from disk
• Display a message box saying “Hi” using the MessageBoxW API.
• Close backdoor connection

The orders from the controller are sent over a TCP connection. The first character of the network packet is the order sent from the attacker, for example, ‘f’ denotes find. Even if the code has been compiled for ARM processors, understanding it is relatively easy for anyone with experience in the x86 world:

BL      recv ; Calls the recv function
LDRB    R0, reception_buffer
LDR     R1, =dgrpmf_string

cmp_string:
LDRB    R2, [R1],#1
CMP     R0, R2
BNE     cmp_string
LDR     R0, =(dgrpmf_string+1)
SUB     R1, R1, R0
LDR     R3, =call_table ; Call table contains references to the six functions of the backdoor
LDR     PC, [R3,R1,LSL#2]; Call the corresponding function from call_table

The samples I have analyzed are all very similar. They seem to have been released in 2004 and don’t use any packing mechanism to hide their behavior or hamper reverse engineering. Furthermore, the code we analyzed does not contain any infection routine. Thus, the only way a mobile device can be infected by this threat is if a user runs the program. To ensure the security of your mobile device, we recommend that you use the same security measures as for a desktop: don’t run unknown programs.

Pierre-Marc Bureau

Malware Researcher

 In my copious free time, I sometimes answer questions on security issues on one of those "Ask the Experts"  pages. It sometimes feels a bit like stepping into a not-quite-parallel universe, where it’s still 2002-3: a strangely high proportion of those queries are about Helkern (the worm most us know as Slammer or SQL Slammer, or even Sapphire). How can such an old threat still constitute such a problem?

In fact, it doesn’t. It’s essentially a noise generator, a classic example of malware intended only to replicate. That’s bad enough, of course: no-one wants to waste bandwidth on the networking equivalent to housedust, and in any case, there’s always a risk that malware that does very little will have unexpected consequences on some systems in some contexts. In general, though, it doesn’t pose a significant risk to anyone not running an unpatched SQL Server installation. The "noise" comes from the fact that there obviously are still unpatched installations out there somewhere that keep sending probes out to random IP addresses over UDP/1434. The problem arises because some security software generates an alert every time it sees that wretched UDP packet, and users assume that (a) their system is in danger (b) they’re the victim of a targeted attack (not so - the target IPs are selected randomly (c) they’re seeing a huge onslaught of attacks by a worm that isn’t picked up by other security software. Back in this universe, any competent, mainstream scanner is capable of detecting Slammer, but most don’t generate alerts for random probes.

However, it’s usually possible to turn off alerts for network attacks in firewalls (and at least one AV engine) where alerting on everything is enabled by default, without turning off protection, and you can still check logs to see that the product is doing its job and blocking such probes, where appropriate, if you need that reassurance.

David Harley
Research Author
ESET LLC