ESET Threat Blog

ESET Blog

Archive for April, 2009

Adobe: Lessons Not Learned


Thursday, April 30th, 2009

One of my all time favorite quotes is by “"Those who cannot remember the past are condemned to repeat it." George Santayana said this in The Life of Reason or The Phases of Human Progress: Reason in Common Sense 284 (2nd ed., Charles Scribner’s Sons, New York, New York 1924 (originally published 1905 Charles Scribner’s Sons)(appears in chapter XII, "Flux and Constancy in Human Nature") if wikianswers.com is to be believed :)

Winston Churchill is credited with a derivative of it that says “Those that fail to learn from history, are doomed to repeat it.” Either way, Adobe seems to not be able to remember the past or learn from it.

The addition of JavaScript to Acrobat vastly increased the attack surface of Acrobat documents. Microsoft learned about the power of macros many years ago and effectively disabled macros in Word, unless a user deliberately turns them on. Adobe, on the other hand, enables JavaScript, arguably as powerful as macros, and does not notify the user of the vastly increased vulnerability they have just been exposed to.

When a user disables JavaScript and opens a PDF with JavaScript in it they are prompted to allow it to run and there is a check box to always allow it to run. The option should conspicuously indicate that this is the option of least security.

Microsoft recently announced that they will disable autorun on USB devices for Windows 7, Vista, and XP. Autorun is yet another autoinfect mechanism, much like Javascript in PDF. As Microsoft improves security, Adobe plods along failing to learn the lessons of the macro virus.

At one time Acrobat was the secure alternative to Word. Today it is not the case at all.

Randy Abrams
Director of Technical Education

Pearls to Swine


Wednesday, April 29th, 2009

The swine flu “pandemic” that has been in the news is being exploited by swine… the bad guys. These creeps are after your pearls… your cash, your computer. You name it and every scam attack we have seen so far will pretty much incorporate “Swine Flu”.

Legitimate news information does not come from unsolicited emails. Legitimate medical information does not come from unsolicited emails. Legitimate news and medical information doesn’t appear on random websites.

If you want to find the news, look to established news organizations. If you want medical information look to legitimate medical sources. In the US, the Center for Disease Control is one such place.

If you want gory pictures, go see a psychologist and get some help, otherwise you’ll be calling you antivirus vendor for help cleaning your computer.

Randy Abrams
Director of Technical Education

Adobe: Wake Up & Smell the Javascript


Tuesday, April 28th, 2009

Ever since Adobe’s recent updates to Acrobat and Reader, I’ve been irritated by the fact that every time I open a PDF, I’m prompted to  re-enable JavaScript, which I disabled while we were all waiting patiently for those patches to the last round of vulnerabilities.

"This document contains JavaScripts. Do you want to enable JavaScripts from now on? The document may not behave correctly if they’re disabled."

The main cause of my irritation (apart from the fact that it doesn’t believe me the first time I click "no" and sits there till I click it again) is that this message is blatantly incorrect: more often than not these are documents I’ve just generated myself, and there ain’t no JavaScripts. (Yes, I have checked!)

Which is why I said in a previous blog: "It’s actually a little more annoying than that. I now find that every time I open a PDF on this system, Acrobat informs me that JavaScript is enabled in the document (even when I’ve just created it on a system with JS disabled), and prompts me to re-enable it in the application. While there may be no signficant danger in re-enabling it right now, that may not always be so, and in any case I’d prefer it if Adobe would be a little less insistent."

This might be a good time to say "I told you so."

Adobe’s PSIRT blog has today reported that Adobe is aware of "a potential vulnerability in Adobe Reader 9.1 and 8.1.4" and that it is investigating.: No further information is given, but the vulnerability referred to is described at http://www.securityfocus.com/bid/34736/info: "Adobe Reader ‘getAnnots()’ Javascript Function Remote Code Execution Vulnerability." (Yes, the RSS feed still works: no, I didn’t get an email from the Security Notification Service!) 

According to the SecurityFocus page, it’s known to affect Reader 8.1.4 and 9.1 for Linux, but it also suggests that other versions or platforms may be vulnerable, and links to an exploit. However, I’m not aware that the vulnerability is being used "in the wild" at the moment. If or when it is, it will probably be used for targeted attacks, as we’ve seen previously, though there’s no absolute reason why such vulnerabilities can’t be used for more random attacks too, so bear in mind that PDFs are not an automatically "safe" format.

In the current absence of further information, I’d suggest that you think about disabling JavaScript (if you haven’t already) and ignore Adobe’s vexatious prompting, though I can’t guarantee that doing so fixes the underlying vulnerability: I don’t have that information at the moment. And perhaps, as Mikko Hypponen has been saying for a while, it really is time to think about other PDF readers.

I may come back to that thought, but for now I’m on my way to the Infosec exhibition in London, and will be there for much of the next three days. Maybe I’ll see some of you around the ESET UK stand, or at my presentation on testing?  

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

Hexzone – FUD for Thought?


Sunday, April 26th, 2009

In a comment to a previous post, Finjan have confirmed that Win32/Hexzone.AP is just one of the malicious programs downloaded to machines infected by the unnamed bot  behind the 1.9 million PC botnet they reported: it isn’t the bot itself.  While I think we’d pretty much established that (especially after some very useful input from Atif Mushtaq), I appreciate that confirmation, given the previous confusion from reporting that suggested otherwise: for instance The Register said "Yuval Ben-Itzhak, chief technology officer at Finjan, said the malware that created the botnet used a variety of Internet Explorer, Firefox and PDF vulnerabilities to spread. He added that only four out of 39 anti-virus scanners detected the malware."

 Finjan have also observed that "The 1.9M number is very accurate." Well, I’m not in a position to confirm or refute that, but I’ve no reason to doubt it: it’s not a uniquely large number, by any means. If Hexzone isn’t the primary infector, that explains the disparity between sources.

Hopefully Finjan will be in a position to share more information about the primary malware at some point. At the very least, it would be nice to know if this is something that’s already widely detected.

Unfortunately, someone at Finjan also seems to be under the impression that I’ve accused them of spreading FUD (Fear, Uncertainty, Doubt). I don’t know where that quote comes from, but it wasn’t me, guys. This isn’t that sort of a blog, and I save my sarcasm for deserving cases like Mikeyy : I don’t deploy it against responsible members of the security community.

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

A little more Hexzone


Friday, April 24th, 2009

Firstly, here’s a little extra information from our lab in Slovakia.

They report that the variants they have analyzed use a custom packer that makes multiple calls to the graphical user interface API (Application Programming Interface, presumably in order to fool emulators and analysts into thinking they are dealing with a standard application. The Hexzone family has been with us for quite a while, and ESET has developed over that time a pretty effective generic detection algorithm for existing and new variants: hence the fact that our scanners were one of the few to detect Win32/Hexzone.AP proactively at the time Finjan first made their announcement.

However, as we’ve previously mentioned, our threat tracking system ThreatSense.Net® doesn’t suggest that Hexzone is responsible all by itself for the 1.9 million botnet that Finjan claim to have seen.

Atif Mushtaq, whom we cited at length in a later blog, has also made a convincing case in his responses to the first blog that "Hexzone along with other trojan like Win32.AutoIt seems only the secondary download." He also talked with representatives of Finjan at RSA, but they were unwilling or unable to tell him the name of the original bot that downloaded the other malware associated with this incident, claiming that they couldn’t do so because they were working with law enforcement agencies.

In the meantime, Russian readers may be interested to know that (as we’ve learned from Richard Wang of Sophos) that Dr. Web have produced a tool that can work out the unlock code generated by ransomware also associated with this group of threats.

 

Hexzone Hotzone


Thursday, April 23rd, 2009

Some more information on the Hexzone botnet has come my way, mostly from FireEye’s Atif Mushtaq and Paul Ferguson’s hairdresser (don’t ask!).

Atif also mentions the association with ransomware: the malware is installed as a Browser Helper Object (BHO) on the victim’s machine, and hijacks browsing sessions, taking the victim to a page hosting pornography. The victim is instructed to send an SMS (text) message. The attacker’s "ransom" is the amount withdrawn  from the sender’s balance and transferred to the owner of the number it references, in order to remove the pornographic content.

However, Pierre-Marc has also sent me a screenshot which is similar to another version, which attempts to lock the desktop. The ransom mechanism is similar, however: the victim is instructed to send a text message to the number given, then enter the code that’s returned to them.

While all the examples I’ve seen so far have been in Russian, Atif notes that there seem to be equivalent SMS short codes or room numbers for other countries including Ukraine, Kazakhstan and Germany.

As Pierre-Marc has already noted, the C&C (Command and Control) server is registered to an address in Watford, in the UK. However, the registrant appeared to believe that Watford is in London… The server hosts a number of other domains owned by someone with a very Russian name.

Perhaps the most interesting part of Atif’s very informative blog is that he offers a possible explanation as to the disparity between Finjan’s estimate of the size of the botnet and the observations of ourselves and FireEye, suggesting a much less dramatic size and rate of spread. It looks as if URLs listed in Finjan’s articles include C&C servers for botnets associated with other malware. This suggests that the count includes zombies from a number of other botnets, grouped together because a central management system is being used to control them all. This makes sense: a similar hierarchical structure is used by a number of better-known botnets such as Rustock, and I’ve believed for a while that the one-named-bot-per-botnet model is becoming almost as misleading as the one-name-per-variant model.

Don’t panic: the sky isn’t falling. But the Win32/Hexzone approach does show a continuing trend among cyber-criminals towards stealing small sums from lots of people as alternatives to high-profile, high-intensity attacks on big companies and sites. One of the advantages of this approach is that it’s less likely to attract the attention of law-enforcement agencies, who usually have to focus mostly on incidents where large sums are involved.

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

 

Another Big Botnet


Wednesday, April 22nd, 2009

There is some chatter about a news item that has been released by Finjan in a blog post this morning.  The news has been picked up by Computer Weekly and USA Today.

The un-named bot involved in this story is detected by ESET as Win32/Hexzone.AP.  It is a typical Trojan that reports to a command and control server using the HTTP protocol.  The malware lets an attacker control your computer and do whatever he wants with it.  It can be used to send spam, launch a denial of service attack or install other malware.  The variants we have analyzed use a custom packer that makes multiple calls to graphical user interface API, probably to fool emulators and analysts into thinking they are dealing with a standard application. 

Win32/Hexzone.AP seems to be distributed from a server located in the United Kingdom.  Infected computers also communicate with a command and control server located in that same country.  Both servers use domain names that have been registered in Russia.  We have seen Win32/Hexzone.AP install RansomWare in Russian, meaning that its victims are probably from this area.

This threat has not attracted a lot of attention from our analysts because we have good generic detection for this threat.  Secondly, we have not seen a lot of activity from this Trojan on ThreatSense.  Win32/Hexzone.AP and the other variants of this family do not appear in the list  of 20 most prevalent malware.  So far, this family has only been detected about 140,000 times over the last week, which is a very small number compared to 16 million detections of malware using Autorun (INF/Autorun heuristic) or 2 million for Win32/Conficker during the same period of time.

Update: As explained below, the detection numbers quoted here shouldn’t be seen as any form of absolute infection statistic, as they simply represent instances where known malware has been flagged by our software. Apart from the usual honeytraps of various types, we also have a data collection system that receives data from some of our customers’ machines (it isn’t compulsory and it doesn’t affect performance!) and provides invaluable threat-tracking information. When we pass this on, though, we normally do so as percentages, not as raw numbers, which can be misleading. We’ll be more careful about doing that in the future: sorry for any confusion!

Pierre-Marc Bureau
Senior Researcher

Mac Musings


Tuesday, April 21st, 2009

I haven’t commented on the recent flurry of interest in the Mac botnet issue, having already mentioned it a few weeks ago here. It’s not as though anyone has shown much interest in the technical aspects, such as the interesting use of the Authorization Services APIs to trick the victim into authorizing installation. Just one of the ways in which a combination of social engineering and a technical wrinkle could be used to subvert the supposed invulnerability of OS X. But I suppose you need to read the Virus Bulletin article to get into that in any depth.

In fact, if you ignore the "yes it matters"/"no it doesn’t matter" feuding between a couple of vendors, people only seem to be interested in the fact that it could happen at all. As Randy has already pointed out, "The only remarkable or surprising thing about the Mac botnet is that anyone was surprised at all."

And, yes, it does matter. It may not have been much of a botnet, but it is one more step towards a a potential reality where Mac users start to feel the sort of pain they felt during the 1990s, when there were significant threats to pre-OS X operating systems out in the real world.

Adam O’Donnell wrote an article last year in which he hypothesised, that "the Mac platform won’t become appealing to attackers until it makes up 1/6th of the market for client systems."  I’m not totally convinced by this invocation of game theory as justification for an arbitrary figure – perhaps because it reminds me of the way the academics in "Numb3rs" drag it in at frequent intervals as a plot device – but he does acknowledge elsewhere in the article that this prediction is liable to modification by other variables. He certainly makes a strong case for the "economicmotivation" argument. It makes perfect sense in the current threat landscape that as more people use Macs, the more economically viable it becomes for malware authors to target them for malware-associated attacks.

In a thread elsewhere today, it occurred to me that there’s a curious paradox at work here.  Looking back over nearly 20 years of involvement with Mac malware, I notice that Mac users were targeted more by virus writers before OS X, although the number of Mac viruses seen at that time was a tiny fraction of the quantity of PC viruses known at that time. (Leaving macro viruses, which were to an extent platform-independent, out of the equation.)

 Yet many of them appeared at a time when Macs were a very niche product and priced accordingly (I’m thinking long before the first iMac), and home Macs were probably much rarer than now (perhaps less so in the US, where Apple pricing tended to be a little more generous).

I don’t think that’s an anomaly, though: at that point, malware was almost exclusively hobbyist virus-writing, so economic motivation or Return On Investment wasn’t really the issue. Of course, there are other factors:

  • Perhaps Mac users really are brighter than the rest of us, and therefore less susceptible to social engineering. Well, as a Mac user myself, I suppose I should say the rest of you… However, I’ve never found that argument very convincing: in fact, I’d say (and have, many times) that many Mac users are more susceptible to social engineering, due to having bought into the "there isn’t, never was, and never could be Mac malware" argument.
  • OS X may not be invulnerable (what O’Donnell describes as the "securedesign" argument – I’m not too sure about his aversion to the spacebar, but I agree with his reservations as to the Mac’s presumed superiority in this respect), but OS X does at least have a security model, and it’s by no means a bad one.

However,it’s far from perfect: in the past week, Heise have checked and reported that several vulnerabilities highlighted recently at CanSecWest remain unpatched. Well, these things take time, as we’ve seen with recent Adobe and Microsoft updates, and it’s possible that the presentation in February was the first notification they received. Be that as it may, it’s clear that the Mac community is not escaping the attention of vulnerability researchers (white hat, black hat, grey hat and all…)

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

 

 

Oh My, a Mac Botnet!


Monday, April 20th, 2009

Some of you may have recently read of researchers discovering a botnet that is using Mac computers. Are you surprised? Well, perhaps if you drink the Apple flavored Kool-Aid you are, but if you understand operating systems at all then this is really not at all surprising.

Operating systems are designed to run programs. A general purpose operating system is designed to run lots of different types of programs. To say that a Mac can’t get malware is like saying that the Mac OS, a general purpose operating system, is dysfunctional. Of course it isn’t dysfunctional and that is why it can, and does run malware.

For those who are too young to remember, missed it when it was news, or have simply forgotten history, in 1988 a young Robert Morris unleashed a worm on the internet that wreaked havoc. By some estimates, nearly 10% of the computers on the internet were infected. This may surprise you, but Windows was not around at that time. The worm only ran on some versions of UNIX. The only reason the worm was not more widespread is that many computers on the internet at that time ran other versions of UNIX that the worm could not run on. There were some people with a compatible version of UNIX who did not get infected because they did things like use good passwords and patched their operating system. Some things never change!

A modern Mac computer runs a UNIX based operating system. Due to how UNIX is designed, viruses don’t generally spread as well on UNIX, but they certainly can. Today viruses are a small percentage of the malicious software infecting Windows computers. Viruses replicate. Most of the malware we see today is not self-replicating. Most malware requires user interaction and the most common way to get the malware onto a computer is to trick the user into running it. Macs offer no more protection than Windows when it comes to tricking users. The only really effective defense is education.

The reported botnet appears to have been distributed in pirated software. Pirated software gets users to install software by appealing to greed. There are many other human emotions that can be manipulated to trick people into running bad programs, and we will see more of this trickery used in the Mac world as the Apple marketing department does their job of selling Macs.

The only remarkable or surprising thing about the Mac botnet is that anyone was surprised at all.

Randy Abrams
Director of Technical Education

Taking the Mikeyy


Monday, April 20th, 2009

Well, Mikeyy may not be the only security problem Twitter has right now, but the Hoodied Bore does seem to be doing an excellent job of exhausting everyone’s patience, including that of The Register’s John Leyden, who described him as "increasingly annoying".

It appears that Mr. Mooney did take responsibility for at least the first of the latest wave of XSS worms: it’s not quite clear whether he really wants to move on from his recently acquired job at exqSoft and work for Twitter (as messages sent by the worm suggest), or what exqSoft think about these developments. What is clear is that Mooney is a couple of quarters short of a full moon, if he thinks that he has much of a future in security. However, I should probably withdraw my suggestion that he should get on his bikeyy: his behaviour suggests that he’s not yet graduated from a trikeyy.

Meanwhile, there have been a number of reports of messages being spread by Twaniac.com and TheSmartECard.com, apparently the prelude to a phishing scam.

Twitter itself does have a helpdesk article that tries to address some of these issues more or less generically. And, despite the frequent criticism of in the past few weeks of Twitter’s presumed incompetence, from the security industry as well as the media (and, of course, Mikeyy), I think it’s a reasonable attempt to cover the immediate problems in terms few Twitter users will be unable to understand, offering advice on recognizing that your account has been compromised, what to do about, and some simple precautions to lessen the risk of compromise.

Now if they’d only do something about those cross-site scripting weaknesses…

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

(Thanks to Dave Kennedy for pointing out the Twitter article!)