ESET Threat Blog

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

Layer L0

Layer L1

Layer L2

Because almost the entire analysis was done statically, I missed some "tricks" during the rebuilding of the imports.

Anti Debug

Lukasz Kwiatek

I run (in my copious free time) a page called Mac Virus that I inherited from Susan Lesch, who ran it as a comprehensive Mac antivirus resource. (That page has nothing to do with the later pages at macvirus.org or macvirus.net, by the way, which also refer to themselves as Mac Virus, and recently experienced infestation problems with fake codecs.)

 I’ve never really had the time to keep Mac Virus current to the standard that Susan did, updating it on a pretty much daily basis, but I try to keep at least half an eye on the Mac malware scene and try to help out with Mac-related queries when I receive them. This week, I had one of those "So what Mac malware is there really?" enquiries. This really ought to be an FAQ at Mac Virus, I guess, but until it is (and because there are readers of this blog who are interested in Mac issues), here’s a quick summary of my response. Even at the risk of an avalanche of rabid Mac zealots telling me that I don’t know what I’m talking about.

 There are quite a few older malicious programs that are specific to the Mac, though hardly any of them are likely to have any effect on a modern system (especially an Intel-driven system, where the Classic/pre OS X environment is no longer supported), and I haven’t seen any of them reported in years. (Is anyone still using HyperCard?!) 

Then there are some proof of concept viruses for OS X, but they don’t pose much of an immediate threat. (Of course, replicative malware is a shrinking proportion of current malware even on Windows platforms.)

There are other malware-related threats that you should be aware of, if not panicked by. (We’re not talking huge numbers to date.) For instance, Trojans like the DNSchanger fake codecs mentioned earlier, the occasional rootkit, rogue anti-malware programs… Some of these are affecting

And there are the cross-platform issues: macro viruses aren’t a very big deal now, but they haven’t altogether disappeared, and there are other  issues with MS Office document vulnerabilities, though the exploits have been almost invariably Windows-specific till now. Also, VBA  is absent from the latest Office for Mac, though  it will be back in the next version, apparently.

In fact, there is a persistent risk of Windows-specific or cross-platform malware spreading by way of Windows non-users. It was actually an instance of that - the macro epidemic of the mid-1990s - that dragged me into the Mac anti-malware arena in the first place.

I would advocate that Mac users in a corporate environment should be using protected machines, irrespective of the perceived risk from Mac-specific threats. I would never discourage the use of commercial anti-malware by home users (there is some free AV for Macs, but none that offers comprehensive protection). Macs aren’t at anything like the same level of direct risk from malware that Windows is, and may never be. That said, we do see the bad guys getting interested in mining sparser seams of potential victims as Windows users become more security-conscious. Some, including me, believe that the risk level is increasing, but slowly. We may not yet be at the point where anti-malware protection is essential even for people who use Macs at home and who don’t take foolish risks. But never say never.

As it happens, Apple have just released a comprehensive - well, large, anyway - document on securing Leopard.  Being an Apple document, it includes a brief mention of viruses (summary: use antivirus, practice safe hex) but makes no mention of the wider range of malware that might concern you more. Ah well… I do happen to know that "OS X Exploits and Defense" (published recently by Syngress) includes more information on malware, because I wrote those two chapters. Contrary to the impression you may get from some book sites, though, I didn’t write or tech-edit the whole book (the confusion arises because I had to withdraw from editing due to imminent surgery), and I haven’t found time to read the rest of the book yet. When I do, I’ll give you the benefit of my prejudices.  

David Harley
Research Author
ESET LLC

With the June Virus Bulletin test, ESET became the first antivirus company in the world to pass 50 tests for VB100 awards.

As consumers I think you should know what the VB100 award means. First of all, a VB100 award does not mean that a product detects 100% of all viruses or malware. The VB test only includes self-replicating code (viruses and worms and potentially some bots). Normal Trojans, spyware, and adware are not in the test. The samples used by Virus Bulletin and most certification bodies are the samples on the Wildlist. The Wildlist organization has reporters throughout the world. If two reporters submit samples of the same virus from different locations then it is placed on the Wildlist.  We know for a fact that there are lots of viruses out there infecting people that are not on the Wildlist.

One of the purposes of the Wildlist is to create a test set that only includes samples that we know are infecting users and actually do work. One of the problems with many tests is that they use files that should not be detected because they are corrupted and do not run. In many cases we have seen harmless text files in test sets as well.

The Wildlist provides a scientifically sound test set. The Wildlist does not provide a statistically significant test set. That is to say that you cannot tell what anti-virus product is best based upon Wildlist testing alone. Even if we could collect every real threat in the world, I don’t think you could decide what product is best based upon any single test. That would be like picking a stock because it had the biggest gain one day.

Another thing to know about the VB100 is that it is essentially a test that all of the anti-virus companies have the answers to in advance. The AV companies have fundamentally the same set of samples before the test.

In order to obtain a VB100 award a company has to detect all of the samples on the Wildlist and do so with no false positives, both on-demand and on-access.

Most of the critics the VB100 award have obviously never successfully tried to make an antivirus product of even low relative quality. The fact that so many companies fail the tests for missed viruses indicates it actually is a bit more difficult than one might think, especially since the companies have the answers to the test in advance.

50 VB100 awards is a track record and an indication of the dedication of quality that ESET’s developers and researchers have!

There are more difficult tests out there, but you should expect your AV product to be able to deal with the easier tests on a consistent basis, especially since we all know that the samples in the test are really infecting users!

Randy Abrams
Director of Technical Education
ESET LLC