ESET Threat Blog

ESET Blog

Archive for February, 2009

Phish Phlags


Friday, February 27th, 2009

Here’s a phish one of ESET’s partners drew our attention to: it’s aimed at users of Maybank (http://www.maybank2u.com), the largest financial services group in Malaysia. The scam is somewhat more elaborate than many we see, and it’s worth a little analysis to see what flags we can extract from it for spotting a phisher at work

From: Maybank Online Account [mailto:admin@maybank2u.my]
[That looks like a genuine address, but it's spoofed: you'd need access to the mail headers to confirm that, though.]

Sent: Friday, 27 February, 2009 1:45 PM
Subject: Dear Account Holder,
[They have your money, but they don't know your name? Lack of personalization is a pretty reliable indicator of spammed, fraudulent mail.]

Dear maybank2u Account Holder,
[See above: but even if it used your email address, that wouldn't be much better. It's pretty easy to script a spam mailout to insert each recipient's email address. It's even feasible to parse the address to extract what may be the name of the account holder: however, that can result in curious effects like "Dear jero664..."]

 
     Maybank2u would like to inform you that an increased number of merchants and ATMs in your country have experienced data compromises of payment cards used in their stores and at their ATMs, and that your funds may be at risk.  To protect yourself, please follow the next steps :
[This is the threat: it's intended to panic you into taking an unconsidered, incautious action like giving your details to a complete stranger.
The next section, however, is where it gets interesting. Most phishes tell you to click on a link which will take you to a fake site. This one does something quite different.]

 * Log in into maybank2u online account 
[URL removed, but this is the real bank site]

* You must request for TAC online via maybank2u – your TAC will be sent via SMS to the mobile phone number you registered at the ATM.
      ( you can find the "request a TAC" button in the right menu of your account "Utilities" )
[As I don't have an account there, I haven't checked this personally, but apparently this involves accessing the genuine site and requesting a Transaction Authorization Code (TAC). This is only supposed to be sent to a mobile phone number which the owner has registered with the bank over the counter. So how does this benefit the scammer?]

    * Logout from your maybank2u account and close the browser.
[Ok...]
    * When you have received the TAC (Transaction Authorization Code) on your mobile phone, open the secured form attached to email and submit the requested information
      ( Account user ID, password and TAC )

[And this is where it all becomes clear. The attached form is, in fact, a JavaScript to a site in China that has nothing whatsoever to do with Maybank. It's just another link to a fake web site. The previous procedure performs threemain functions:

  • It obscures the fact that this is just a link to an unvalidated site with no proven connection to the apparent sender.
  • It sets up the victim to acquire all the information the scammer needs to plunder his account
  • It looks as if the procedure is a comprehensive, safe, genuine validation procedure (indeed, it apparently really is), so the victim is off-guard when the last stage of the con is executed: the fact that the procedure actually seems lengthy and a little bureaucratic reinforces the victims sense of false security.

    
     Please allow 48 hours for processing
[In other words, please give me 48 hours to wreak havoc with your finances.]

Thank you,
maybank2u Risk Management Department
[Have a nice day!]

I’m sure you can see ways in which this approach to be localized to map to where you live!

Thanks to Quah PK for bringing this to my attention.

David Harley BA CISSP FBCS CITP
Director of Malware Research

EXcel EXploits


Thursday, February 26th, 2009

Our guys in Bratislava have issued a press release about one of the latest examples of the current wave of Excel exploits, which we detect as X97M/TrojanDropper.Agent.NAI. When the malicious Excel document is opened, it drops the backdoor Trojan we call Win32/Agent.NVV, which allows a remote attacker to get access to and some control over the compromised machine. Unlike some of the exploits we’ve seen recently, this one is remarkably flexible about the range of platforms and versions to which it delivers its payload: according to Microsoft’s advisory, the vulnerability affects Windows versions as far back as Microsoft Office 2000, and also affects Office 2004 and 2008 for Mac (that’s the vulnerability, not the exploit!). Our lab guys also tell us that the exploit also affects Excel viewers. So if you remember those reassurances from the 1990s that you were safe using viewers to read MSOffice documents because they didn’t execute macros, I’m afraid that it no longer applies, because we’re not looking at malicious macros here.

According to the same advisory, the vulnerability allows a specially crafted Excel document to access an invalid object so that the attacker can execute arbitrary code. Pierre-Marc is doing some analysis at the moment: it looks as if in this case, the shellcode drops an executable embedded in the spreadsheet, then then registers the executable as a service and starts it.

According to Patrick Fitzgerald of Symantec, the shellcode in samples analysed there actually drops two files: the second file is a valid Excel document which is opened to mask the fact that Excel crashes when the Trojan is executed: however, I can’t confirm at this point that we’re talking about exactly the same malicious code. I may be able to tell you more about that later.

Like the Adobe exploits we’ve been talking about recently, this is a targeted attack: while that may change, it’s  not, for the moment, going to affect many people directly. Directly is an important word here, of course: a single person falling for one of these may have dangerous knock-on effects for many, inside and outside the targeted organization – consider, for instance, how many people could be impacted adversely by the misfortunes of a global banking organization, or a major government department.

There is no patch from Microsoft yet, though I’ll be surprised if there isn’t one sooner rather than later. Clearly, this isn’t a good time to be indiscriminately opening XLS files (the vulnerability doesn’t seem to exist in the newer .XLSX format), even from trusted sources. (One of the features of targeted attacks is that the attacker goes to some trouble to make it look as if the attack comes from a trusted source.) But then, there’s never a good time to be reckless about opening files… Microsoft’s other suggested workaround is to use their Microsoft Office Isolated Conversion Environment (MOICE), certainly when opening files from unknown or un-trusted sources. This should also afford some protection for users of Word and PowerPoint files in a number of attack scenarios, but MOICE can only be installed in Office 2003 or 2007.

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

TomTom to Get Bit by Microsoft Again


Thursday, February 26th, 2009

I read this morning that Microsoft is going to sue the GPS maker TomTom for patent infringement. You might recall that TomTom sold a GPS with malware already installed on it. It wouldn’t have been much of a problem if it wasn’t for Microsoft technology. It is Microsoft’s security nightmare called “autorun” that made having the Trojan on the TomTom really dangerous. All a user had to do was plug the TomTom into their windows computer and MS took care of the auto-infect routine. You would think that TomTom would have become a little bit shy about Microsoft Technologies!!!

No, I don’t think that MS is suing because of autorun technology. You can find the story at http://www.theregister.co.uk/2009/02/26/microsoft_sues_tomtom/ if you want to read more about it.

Randy Abrams
Director of Technical Education

Phishing the Web


Thursday, February 26th, 2009

A new advisory from the Anti-Phishing Working Group (APWG) offers advice to website owners on what actions to take when notified that their site or server has been compromised for use by phishers.

At 18 pages, it’s a substantial high-level document, including:

  • Some web site phishing attack and response scenarios
  • Identifying an attack
  • Reporting a compromise (how and to whom)
  • Containment and damage limitation
  • Recovery (This actually includes some proactive approaches to facilitating recovery before the problem arises, which seems a very sound approach to me.)
  • Follow-up (lessons learned, tightening up…)
  • The references section is actually more of a collection of relevant resources (short, but useful and relevant: the OWASP site alone could keep a site administrator wanting to improve site security busy for weeks).

So, a useful document dealing with an aspect of the phishing problem that receives far less attention from the media than the phishing emails that are all too visible to the everyday user. My only suggestion is that rather than pitching this as reading material for a site that’s just been compromised, APWG might consider pushing it as something to read before a compromise takes place: it would actually be a sound basis for establishing strategies and policies to mitigate future attacks.

If you’re in a position where you might need to know this stuff to deal with a compromise on your site, I’d suggest that you read it (and check out the resources it contains) now and start planning. Sometimes it pays to have your shields up before the enemy opens fire.

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

TinyURL: the Tiny Terror


Wednesday, February 25th, 2009

The Register today ran a story about the phishing attack spread by the Google Talk instant messaging system, which uses TinyURL to conceal the real name of the link. John Leyden’s story (quoting Graham Cluley at some length) makes several good points about reducing your exposure to the threat, and Graham’s blog makes some more.

This is yet another case of a good idea being misused for evil purpose: TinyURL offers you a way to avoid mailing long URLs that cause irritation by getting broken in transit, so that the recipient has to do some cut and pasting in order to get it into their browser. However, it’s obviously possible to make it harder to see what any URL really is, and that’s what happened here. Fortunately, TinyURL have done the decent thing and fixed this particular issue by blacklisting the malicious site, though obviously it wouldn’t be difficult for the gang to get round that by changing the site, for example.

This isn’t the first time that a malicious site has been camouflaged by giving it a TinyURL short name, of course, though it doesn’t seem to happen as often as you might think. That might be because there’s actually a semi-fix to the issue. On TinyURL’s front page, there’s a link to Preview Feature, which (as long as you’re willing to have cookies enabled) allows you a little extra security. If you enable Preview Feature, then click on a TinyURL, then instead of opening the target page straightaway, a page will be opened on the TinyURL site that tells you what the real target URL is and offers to take you there.

This really offers very limited extra security: it doesn’t prove that the site you eventually land on is what it says it is, and it doesn’t stop a criminal from using another site with similar name shortening functionality. Still, if you think you’re going to a particular website and realize that the real target has a name that doesn’t look right, that’s better than nothing. At the very least, it means that the bad guys have to work a bit harder to look "innocent."

Update: I just happened upon a site at http://www.surl.co.uk which offers a similar service to TinyURL’s (with some quirky additions that I’m going to have to play with :-D ). sURL also takes you to a preview page, but you can’t turn it off (which seems like a very good idea to me: how about it, TinyURL?) It also adds some nice little security touches like telling you whether it’s listed in hpHosts, MDL or PhishTank. Nice.

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence 

419 Frauds: They Just Keep Coming…


Tuesday, February 24th, 2009

A memo to Middle- East Asia Promotion. Thank you for letting me know that I’ve won $720,000.00 in a promotion sponsored by Dell and the Emirates Foundation. Four days running: nothing suspicious about that, nor the fact that my wife has apparently won the same amount in the same promotion every day for the past week. We’re just a lucky family.

Having been a security professional for nearly 20 years, I have of course never heard of a 419, advance fee fraud, or a lottery scam, and will be pleased to contact you immediately to find out how much money I need to send to you before you can release the funds due to me. Not.

I’ve seen some badly executed scams in my time, but this is in a class of its own. Although…

It seems another old favourite among 419 scams has succeeded in mildly embarrassing the UK government, even if it failed as a fraud. The Register reports that Jack Straw, the UK’s Justice Secretary, was used as the hook to hang a 419 on. A message was sent to constituents, colleagues and so on, allegedly from Straw himself, claiming that he was in trouble in Nigeria, having lost his wallet while promoting a charity.

Connoisseurs of the advanced fee fraud will immediately recognize this as a vintage scam: if it’s new to you, please be aware that such scams are not always focused on public figures and celebrities. Nor do they always claim a Nigerian connection: 419 gangs are as aware as anyone of the country’s bad reputation as regards this kind of fraud. Indeed, they sometimes exploit it by disguising their scams as some kind of anti-scam initiative.

Why is this case potentially embarrassing? Well, anyone can be used as the innocent hook for this particular fraud: however, there’s a question mark over the fact that the scammers were able to send the fraudulent message to the contacts associated with that address, which suggests that they gained access to an address book.

When I say that this scam is vintage, I’m perfectly serious. While this particular wrinkle dates back a few years, it’s clearly inspired by the Spanish Prisoner scam, where the "victim" is a rich and/or high-born individual held to ransom in a foreign country: Wikipedia says that this goes back to the 1920s, but other sources believe it goes back much earlier. Of course, most 419s can be traced back to the Spanish Prisoner trick in some respect, but the line of succession here is particularly obvious.

By the way, having spent several weeks in the US recently, a habit that generally involves my seeing more repeats of cop shows on television than is good for me, I was fascinated to discover that 419 is also a Hundred Code designation for a dead human body. Wikipedia, however, failed to hold my interest by telling me that it’s also the area code for the NW corner of Ohio. :)

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

False Positive Fracas


Tuesday, February 24th, 2009

False positives. Every anti-malware vendor’s worst nightmare.

The European publisher Heise, apparently recently reinvented as The H, has pointed out that both GData and Bitdefender were inaccurately flagging winlogon.exe as Trojan.Generic.1423603. In case you were wondering, this doesn’t mean the whole anti-malware industry has gone mad: GData’s product uses two engines, one of which is  Bitdefender’s.

In fact, it doesn’t mean that Bitdefender have gone crazy, either. False positives – diagnosing an infection where none actually exists – is one of those regrettable issues from which no vendor (or AV customer) is safe. Sometimes it’s a major inconvenience for customers, and that’s why Heise have been characteristically abrasive on the issue: "This latest case gives rise to the assumption that false alarms caused by anti-virus software will continue to unnerve users. " But the point is well taken: FPs can be alarming, confusing, inconvenient and downright expensive for customers (especially where innocent but essential files are quarantined or deleted), which is why we go to considerable lengths to minimize the risk (but even ESET can’t eliminate it altogether, and it really is an issue we work very hard on!)

In fact, high profile misidentifications are surprisingly rare, given the complexity and sophistication of the technology. There are probably quite a few instances of low-profile FP, affecting applications less commonly used, that are hardly noticed. Despite the anger that antivirus and antispam FPs sometimes inspire, much of the security industry is founded on the idea that for some organizations and individuals, a degree of inconvenience caused by sensitive filters (in the broadest sense of the word filter) is acceptable.

For example, it’s common for mail filters to block whole swathes of executable filetypes. It’s unlikely that a filename like something.lnk would ever be attached to a legitimate email file attachment (the suffix denotes a shortcut rather than a "real" executable file), so blocking that suffix hardly ever results in misidentification. However, there are a great many innocent files that have the .EXE suffix, yet we often accept the filtering of .EXE attachments because we consider the risk from malicious attachments worth the risk of not receiving a legitimate .EXE through the mail, or the inconvenience of finding an alternative mode of transportation. In fact, some organizations have been doing this for at least ten years (and similar considerations apply in the world of spam management, as I discussed more recently in a Virus Bulletin article).

The fact is that the industry has had to move on from the early days of exact identification and one sighature to one threat. Nowadays, products use combinations of approaches that are nearer to what we used to call generic detection like change detection: whitelisting, filtering by filetype, change detection, heuristics, behaviour analysis, and so on. (Of course, products vary widely in terms of which techniques they use, how they are implemented, and so on.)

Our labs are now seeing over 100,000 unique samples a day. Other vendors may use different ways of counting, but they all face the glut problem, which is why there is so much emphasis in the industry on automation, distributed processing, and dynamic analysis. The miracle is, in the face of these difficulties, that significant false positives are so rarely encountered.

But there you go: problems attract far more attention than a product doing pretty much what it was designed to do, especially an antimalware product…

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

 

More Acrobatics


Saturday, February 21st, 2009

For the geekier among us wanting or needing to know more about the Adobe vulnerability that Randy and I both blogged on yesterday, here are a few resources:

  • More from Shadowserver at http://www.shadowserver.org/wiki/pmwiki.php?n=Calendar.20090221
  • As we’ve said previously, disabling JavaScript, while it doesn’t address the underlying vulnerability, stops known exploits from working properly. There are rules for open source Snort at http://www.snort.org/vrt/advisories/vrt-rules-2009-02-20.html  (and sundry other information elsewhere on the site)

  • There’s also a batch-file for turning off JavaScript in Adobe Reader by altering Registry settings at http://www.phishlabs.com/blog/archives/122 (I haven’t tested it!). Assuming that it works as advertised, there’s no advantage to using this on one or a handful of PCs – do it by hand, as we’ve previously detailed. It won’t even work on many systems: it’s specific to version 9.0 of Reader. If you don’t understand what it does, or you don’t know if it matches the software configuration on your own machine(s) you shouldn’t use it. If you do understand it, it may save you some time if you need or want to disable JavaScript for multiple systems, even if you have to tweak it to suit your own systems, but you do need to know what you’re doing.
  • JavaScript in Adobe Reader is a Good Idea in general, not just in response to the current wave of exploits, but for most people, doing it through Edit | Preferences as described is a safer and surer way of doing it.

New malcode using this loophole is still appearing, though as far as I know the current exploits are still largely targeted rather than random. However, given the fact that more information is becoming public about the exact nature of the problem, it’s likely that we’ll see it used by other malware that may be more widely spammed. In other words, it will start to affect Joe Sixpack, not just specially targeted organizations.

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

 

Facing Down Facebook


Saturday, February 21st, 2009

An IT/business magazine called Information Age, apparently aimed at executives with interest and responsibilities in IT, hit my letterbox this morning. That’s an actual magazine with real paper pages: remember those? Seeing as it’s Saturday, I took it back to bed with me to look through while I had the first coffee of the day, and found an interesting opinion piece called Trapped in the Matrix (you can read it online here, if you’re interested).

The anonymous author tells how her Facebook account was hacked, she thinks by a "technically savvy, vindictive ex-boyfriend". Not an uncommon scenario, unfortunately: it’s a recurring theme on a "security clinic" page to which I contribute.

In this case, the victim’s page was "awash with libellous material" causing her to worry about her job, friends and reputation. Not nice for her, but equally disquieting is the inadequacy of the responses she reports receiving from Facebook:

  • No-one answered the phone
  • 36 hours waiting for a response from a real person (it does sound as if it was a weekend, though)
  • When she finally got some action, it was to disable the account, not to delete it. This is a commonly heard complaint: she suggests that it’s done because Facebook advertising revenue is based on the number of accounts in operation.
  • Encouragingly, a Facebook representative intending to forward her mail instead hit reply, thus allowing her to see an unflattering comment suggesting that her complaints were boring him.

She also cites an article in the New York Times by Maria Aspan, called "How Sticky is Facebook Membership? Just Try Breaking Free", so I looked for that too. Fascinating. And possibly useful: it includes a couple of resources for people who are determined to get their Facebook accounts deleted, a task that seems to be on a par with jelly-herding and nailing cats to the wall. Or something like that.

Apparently one Magnus Wallin of Stockholm has founded a Facebook group, “How to permanently delete your facebook account” which at the time the article was written (about a year ago) was close to reaching 4,300 members. While I’m having a hard time getting my head round the idea of a Facebook group about deleting Facebook accounts – is that something like a prison camp escape committee? – the size of that group certainly tells us something about the size of the problem.

The "Matrix" author also claims that if you google "hacked Facebook account" you’ll get "not a list of sites committed to helping victims, but a list of sites teaching people how to hack into accounts". Actually, I’d expect to get both types of hit to that search term, plus requests from hacked Facebook account holders asking for help: and when I tried it, that’s pretty much what I got. Looking at some of those links in detail, I found an interesting mixture:

  • Cries for help from victims
  • Aspiring hackers asking for information on how to do it
  • People offering hacking tools and keyloggers that were almost certainly Trojans
  • Someone called Thea who turned up on several lists asking for someone to hack into her account and delete it. Or more likely someone posing as Thea, trying to get someone else to sabotage Thea’s account.

In general, the most successful Facebook attack is probably phishing via Facebook messaging or other messaging systems, including standard email. In general, this is designed either to trick people into sharing their passwords directly, or to persuade them to run malicious programs like Koobface by passing them off as patches, videos and so on. One particularly feeble-minded attack is to pass round snippets of javascript and suggest to the potential victim that he should paste it into his address bar and "see what happens". Not recommended…

Security companies are well aware of the general problems with social network sites, but sometimes threats are difficult to track, due to the proprietary nature of the network. So while you should certainly have and maintain security software such as antimalware (I can recommend a good scanner if you don’t have one!!!) you shouldn’t rely on it to save you from thinking about your own security. It never ceases to amuse me that so many users of social networking sites want to be my friend. The thing to be aware of is that on the Internet, not everyone who seems friendly has benevolent intentions.

David Harley BA CISSP FBCS CITP
Director of Malware Intelligence

Securing the Perimeter


Friday, February 20th, 2009

I recently had the fantastic opportunity to participate on a panel discussion concerning cyber security. The event was hosted by the Bellevue Chamber of Commerce and coordinated by the US Chamber of Commerce and the Department of Homeland Security. Last year the Bush administration launched the Comprehensive National Cyber security Initiative or CNCI. Although focused primarily on securing federal computer systems, it recognizes the need to work with the private sector as well. The US Chamber of Commerce and the Department of Homeland Security are holding regional roundtable discussions in conjunction with various chambers of commerce. I believe then next one is in late March in Ann Arbor, Michigan, followed by another in San Diego in April.

The event in Bellevue featured a government panel and a private sector panel with presentations by the Washington State Attorney General Rob McKenna and Rear Admiral Mike Brown. The government panel included:

• Rear Admiral Mike Brown, Acting Assistant Secretary, Office of Cybersecurity and Communications, DHS
• Major General Timothy Lowenberg, Adjutant General/Homeland Security Advisor, State of Washington
• Agnes Kirk, Chief Information Security Officer, Department of Information Services, State of Washington
• Bill Schrier, Chief Technology Officer, City of Seattle

This panel discussed the challenges that government faces with cyber security, including how to better share information with the private sector. The private sector panel included:

• Stephen Whitlock, Chief Strategist, Information Security, The Boeing Company
• Angela McKay, Senior Security Strategist, Trustworthy Computing, Critical Infrastructure Protection Program, Microsoft Corporation
• Randy Abrams, Director of Technical Education, ESET

Both panels placed education as the most critical element of cyber security. One of the questions that we on the private panel could not answer adequately was something to the effect of “How does a small business who can’t afford a fulltime security person take care of their cyber security needs. If any of you readers who own small businesses care to share your practices it would be great information to have. Sharing this type of information allows others o improve their practices, which benefits us all, and allows for feedback that can help you to improve your own security.

The whole point of the roundtables is to share information for the promotion of a more secure internet and a more secure critical infrastructure. Everyone from the home user, to the small business, to the giant corporations have a significant role in cyber security.

Randy Abrams
Director of Technical Education