Today we’ve seen another phishing attack in Italy. Online banking are becoming more popular and so are phishing attacks. This one, like many others, targets poste.it users.

For a change the authors, possibly from Germany, spent a little more time in the translation so unlike previous attacks this one uses proper Italian,

Those of you using our consumer products will see the friendly phishing warning popup warning of the fraudulent site.

I was amused to read the following article the other day: “OneCare rises from bottom-place ranking”. The reporter notes that “Microsoft’s anti-virus product OneCare is no longer bottom of the pile when it comes to the tests carried out by an independent anti-virus researcher.” 

Unfortunately, these are two completely different kinds of tests, so this is kind of like comparing apples and hammers. The February 2007 comparative test by AV-Comparatives is a bulk-detection test. You take a giant pile of malware, turn off all the real-time functionality in a completely updated product, and perform an on-demand scan of the pile. The collection of malware used can span years, but most companies never remove signatures from their definitions, so everyone should be on an equal footing.

By comparison, a retrospective/proactive test, like the one from May cited in the article above takes a very different approach. This test starts with smaller pile of new malware (say, anything received by the reviewer in the last couple of months), and scans that collection with signatures older than the oldest sample in the collection. In theory, this means that the test measures the ability of the products to detect new malware. In other words, these are samples they could not possibly have written signatures for, because they did not exist at the time the signatures were written.

What this means is that you can write signatures that detect everything that exists today, and nothing that comes into being tomorrow. Or vice versa. So our quote is like saying that my car, which failed its safety crash test last week has improved because it completed the quarter mile in less time than someone else. Although it doesn’t mean that both areas haven’t improved, it certainly doesn’t tell you that they have.

This is not meant to take anything away from Microsoft or AV-Comparatives. But we as humans (and especially magazine publishers) tend to like black-and-white answers, and try to make everything fit that mold. Unfortunately, we can make incorrect assumptions when we leap to the wrong conclusions.  For example:

• Particularly for proactive tests, the score of any particular vendor might be related to the quality of their heuristics, but might also be related to the size, distribution, and false-tolerance of their user base. Companies with larger or more diverse customer bases have to be more cautious in developing new heuristics to avoid false positives on (relatively) obscure files that some small, but non-trivial, portion of their user base might be using with the vendor’s knowledge. Likewise, companies that provide only gateway scanners can tend to be more aggressive, because the impacts of a false positive (deleted email or blocked download) are much lower than they might be if files running on important servers were deleted. 
• The numbers generated for proactive tests might also be lower than what a user might see for a number of reasons:
• The signatures used in these tests are frozen months or at least weeks before the test starts. A user who is only two days out of date will likely receive much better proactive detection rates than the worst-case scenario offered here.
• This kind of test, which never executes the malware in question, will underestimate the benefits of behavioral technologies, such as our Access Protection Rules, Generic Buffer Overflow technology, and System Guards. 
• Comparative tests such as the February 2007 tests likewise have some caveats that should be understood:
• Each piece of malware is treated equally, so a highly prevalent and damaging virus that has infected millions of computers is considered as important as an obscure Trojan horse that may have existed only on a handful of computers.
• Like the proactive test, the benefits of on-access or real-time and behavioral technologies at preventing or limiting the impact of zero-day threats are ignored.
• Some of the samples may be old or irrelevant to the platform the product is designed to defend. In fact, one of the reasons that AV signatures always grow is that none of the vendors can remove signatures for old threats, because we’re likely to see them in reviews and get slammed for missing them.

Very few tests actually test running malware against real, fully updated security products. This provides the best correlation to real-world performance, but is very labor- and time-consuming to test. As a result, most tests of this nature are run on a small set of malware samples (at most 10 to 20). This means that the performance of any particular vendor might be different tomorrow if the test were run on a different sample set.

Needless to say, all of these techniques are useful and contain important data. In fact, we run all of these kinds of tests in our lab to determine whether we are improving over time, and whether our products meet our quality standards. 

That being said, from years of experience I can say that higher numbers on tests do not always correlate to improved performance. Optimizing for one kind of result is likely to cause worse performance in other areas, be they the size of definitions, system performance, false-positive rates, removal effectiveness, or supportability. 

Likewise, reading too much (or too little) into test results can lead to selecting the wrong product for your situation. Here are some links to excellent resources on testing methodology and interpretation:

Comparing the Comparatives

Counting Spyware Detections

Antivirus Testing Workshop in Reykjavik

And particularly check the FAQ section of the methodology document located off of the Comparatives tab at http://www.av-comparatives.org/.

We received a sample of a virus written for the programmable calculator TI-89, produced by Texas Instruments. This calculator runs on the Motorola 68000 processor and has a computing power comparable to the first IBM PCs. It also offers cable connectivity to a PC and to other calculators to exchange programs.

Essentially, this calculator is a small computer that runs programs. One can get a wide variety of games for it–from classic Tetris and Pacman to full-blown chess! There is little security built in so programs have full access to all other programs–just like in the time of DOS for IBM PCs.

Reliable detection of this proof-of-concept virus (we call it TIOS/Tigraa) is easy, even though it attempts to hide by obfuscating the call to the virus body within the infected file. The problem is that there is no AV software yet for calculators, so protection can only be built on a PC. This would not block propagation between calculators should a similar virus ever get into the field. Fortunately, the chances of this happening are rather slim.

This incident would not normally be worth mentioning but it prompts me to emphasize one important point. More and more mobile devices (pocket organizers, smartphones, Internet tablets, calculators, etc.) receive enough computing power and not enough security features to create breeding grounds for malicious code. We urge developers for all mobile devices to make the necessary investment into securing the environment they create. Prevention is always better than a cure!

Wired posted an excellent article recently that highlights the pitfalls of hiring a “blackhat” to do a “whitehat’s” job. Brett Shannon Johnson was once on the U.S. Secret Service’s most-wanted fugitives list for credit-card and identity theft. After being apprehended, he was recruited to help catch the bad guys as an operative for the Secret Service. Before long he was back to his old tricks.

“It was $350 a week [from the Secret Service] vs. $5,000 or $6,000 a week” from his fraudulent tax-refund scam, Johnson told Wired News by phone. Johnson had set up a tax-refund fraud scheme. The Secret Service caught him and he was arrested again.

Although Johnson claimed to have stopped $3 million in fraud before backsliding, he noted that having to work with his former partners in crime was like “taking an unrehabilitated crack or heroin addict and placing him in a drug environment, telling him not to use drugs.”

Trustworthiness is a huge consideration security companies ponder when looking at prospective candidates–and Brett Shannon Johnson is an example why most security companies do not knowingly hire blackhats.

It has been standard policy for a long time in the anti-virus (AV) industry not to hire virus authors, largely because of the myth that it was the AV companies who wrote the threats that they then sold protection for. With the plethora of threats on the Internet today, I think most people understand that we have no reason to create any more work for ourselves. Of course, not everyone shares this zero-tolerance policy. In 2004, it was reported that Sven Jaschan, author of the Sasser worm, was hired by SecurePoint. This ended up costing the security firm a partner in the AV space; H+BEDV severed their ties with SecurePoint.

The topic of hiring someone who’s written a virus overlaps with our most recently published podcast, which tackles the issue of teaching malware authoring in higher education. For more on this topic, have a listen:
http://podcasts.mcafee.com/audioparasitics/

As for Brett Shannon Johnson, he aspires to work as a fraud consultant one day.

As we talked about organized cyber crime on the rise, the script kiddies are not taking a break. CVE-2007-2221 was patched in MS07-027 on May 8th, 2007; barely two days after a proof of concept was published on the Internet. During the weeks that followed, we saw the original proof of concept exploit code posted onto hundreds of script kiddie websites and forums. Fine, all proof of concepts we’ve seen in the past already spread like fire; and CVE-2007-2221, a vulnerability for a non-default Windows service, is unlikely to have an impact quite like Exploit-AniFile.c. So what’s the big deal ?

Amusingly, we see many variations of the original proof of concept code. In most cases, we know they all originated from the same source because none of the comments or author’s name were changed (oh yes, script kiddies give credit too). Some impress with shellcode “boosters”, others rip off a heap buffer overflow “turbo-kit” from Exploit-VMLFill; all that for a vulnerability that doesn’t even cause a buffer overflow. With so much script kiddie goodies, it deserves a GUI script kiddie tool written by a 18-year old.

What brought this to our attention was an in-the-wild discovery of Exploit-CVE2007-2221. We believe this would be the first time that a malicious exploit for CVE-2007-2221 is discovered in the wild. Exploit-CVE2007-2221 is abusing a vulnerability in a Microsoft Windows Media Server 4.1 component through Internet Explorer. When successful, attackers can overwrite any files on the victim’s machine with malware.

The discovered exploit code was hosted on hxxp://web733{blocked}914.{blocked}.128web.com which was reportedly hosting the infamous Exploit-AniFile.c back in March 2007. At the time of writing, the malicious payload was no longer available for download. Exploit-CVE2007-2221 used on this site was, as you guessed, generated with that “shellcode-enhanced” script kiddie tool.

As for the malicious sites which are monitored by McAfee Avert Labs, some are dead, moved or no longer host exploit codes. However, as long as site administrators do not enforce a policy of taking malicious sites down, many can continue to seek opportunities to host new malware, and will be awakened whenever a new exploit made available for their malicious activities. But did they tell you the exploit code doesn’t even have to make sense ?

In April 2007, the number of unique phishing websites detected by APWG was 55,643. In its report, the association shows a 166% rise from the previous month and 48% from the previous high for phishing URLs (in October 2006).

This trend indeed is going up. It does not follow the total number of unique phishing reports submitted to APWG. This other statistics is steady and, surprisingly known mirror sites are more numerous than known attacks!

In this report, Laura Mather, Ph.D., Senior Scientist at MarkMonitor explains this huge number. Similar to what they were doing in late 2006, the phishers start again using the tactic of putting a large numbers of mirror sites on the same domain. She relates to have seen cases where there were thousands.

Typically, URL multiplying techniques involve apparently automated creation of subdomains (xxxx.fakedomain.com) to establish discrete hosts for phishing sites or the use of different directories on the same domain (xxxx.fakedomain.com/xxxx).

Criminals do this in an attempt to get around website blocking that Internet Explorer 7.0 and Firefox 2 have deployed to protect consumers from fraudulent sites.

The last APWG Phishing Trends Activity Report (April 2007) is available here : http://www.antiphishing.org/reports/apwg_report_april_2007.pdf

During the past seven years at McAfee Avert Labs, I’ve had the opportunity to fill several roles. More recently I’ve stepped away from day-to-day threat processing and focused on mid- and long-term threat intelligence. Namely this includes threat forecasting; gathering and analyzing threat trends and upcoming influential factors to forecast what may lie ahead. The resulting data is being used by customers to help them plan for the future, invest more wisely, and mitigate risk. The information also helps drive and shape McAfee product offerings.

One of the areas that I’ve spent some time analyzing is that of the zero-day threat. The first step when considering a threat is to define it. Over the years, the term zero day has been used for a number of things; from vulnerabilies and exploits, to viruses, Trojans, and even spam and phish. I define a zero-day threat as follows:

Exploit information does not necessarily mean a working exploit, or even proof of concept code, but at a minimum it means that enough technical details are available for someone to find the vulnerability on their own, to create a working exploit.

This definition excludes a number of things that some would not like to exclude:

• Malware that doesn’t exploit anything new. Some like to refer to new malware as a zero-day threat, so that they can claim zero-day protection. We already have a term for that, proactive protection.
• Spam & phish that doesn’t exploit anything new. The same applies here.
• Vulnerabilities that are privately disclosed to the vendor. I do not consider brief, yet public, “Upcoming Advisories” that are published when a vendor is notified to be a zero-day threat; unless sufficient vulnerability details are also made public.

The two recent Yahoo Messenger vulnerabilities were an interesting case. Ryan Naraine’s blog has a good write-up. eEye published an “Upcoming Advisory” after discovering the vulnerabilies and reporting them to the vendor. A Yahoo spokesperson inadvertently spilled the beans and gave additional details that were not public. While I wouldn’t say that those details were sufficient to call these zero-day threats at that point, they were enough for a researcher to find the vulnerability within an hour, give or take. The results of that research, proof-of-concept exploit code posted to the Full Disclosure mailing list, were zero-day threats. Shortly thereafter, other exploit code was posted to the Web, and attacks were discovered in the field. In the end it didn’t much matter what the zero-day timestamp was for this threat, Yahoo users were put at risk, and certainly attacked. Yahoo did manage to turn around a patch in an amazing 48 hours, but surely there are many thousands of users who have yet to apply the patch.

There’s much more to cover on the topic of zero-day threats. Stay tuned for part 2 of this series.

– Update June 14 –
Part 2 has been posted: Zero-Day Threats, Part 2: Who’s Behind Them and Why?

Episode 9 is the second installment of our two-part discussion on malware-authoring courses being offered in higher education. We are joined in this discussion by Karthik Raman and Craig Schmugar (both of McAfee). Do we endorse or condone these courses? What are the ethical and legal issues involved? What are the real goals behind teaching these courses? These are some of the questions we address in this two-part series.

This might be our best episode yet. Phenomenal intro bits and content.

Available for download from iTunes or Podzinger.

Yesterday, Apple announced Safari 3.0, including a new version for Windows. This announcement is discussed in an article on CNN with a particularly unfortunate turn of phrase in one quote:

“Safari is another Trojan horse that introduces an innovation of Apple to the Windows community and entices them to the Mac platform”

Now, presumably the intention of this quote was to say that Apple is bringing a gift of innovative and exciting new software to Windows users, who’ll then be lured away to the wonders of Mac-land. Much like the “halo effect” of the iPod.

But it would seem that there’s something aside from enticing software that may be coming with this gift – new and exciting software vulnerabilities!
Among the first to welcome the new Apple Web browser were vulnerability researchers. Shortly after the beta release, security forums were abuzz with talk of new vulnerabilities in this new version of Safari. At least three researchers say they have already found security holes in the new browser.

Applications have become a prime target not just for security researchers looking for vulnerabilities, but also for cybercriminals. As Microsoft has improved the security of Windows, applications that run on the operating system have become increasingly popular attack vectors. Our take has always been that Apple software, regardless of what hardware or OS it’s run on, is just as vulnerable to issues as any other software. Apple software running on Mac OS X has been less of a target because it isn’t as widely used as that running on Windows. QuickTime in particular, which is widely used by Windows users, has long been favorite of vulnerability hunters and cybercriminals. It would seem Safari could be next.

Three of the researchers that announced vulnerabilities in Safari shortly after its release are Aviv Raff, David Maynor and Thor Larholm.
These guys claim several of the vulnerabilities they found could let an attacker remotely gain complete control over a Windows computer running Safari.

Safari 3.0 is still in beta and beta software is expected to have bugs. Even after final release, browsers with vulnerabilities have become more rule than exception. Microsoft’s Internet Explorer, Mozilla’s Firefox, and the existing version of Safari for OS X, regularly get patched to fix security vulnerabilities.

What it boils down to is this: The usual advice for safe computing remains the same. Don’t assume any software is inherently safe, regardless of how safe it purports to be. Software is written by humans, and humans do make mistakes, which can lead to vulnerabilities. Make sure you’re running up to date security software and install the latest security fixes from your software vendors.

Today Microsoft released six Security Bulletins detailing 15 vulnerabilities. Three of the vulnerabilities had surfaced before today’s fixes. Two vulnerabilities are uniquely found on Windows Vista; one can lead to disclosure of sensitive information on Vista and one to remote code execution via Vista’s Windows Mail. After the release of the patches today, exploit details for MS07-032, the Windows SChannel vulnerability have been posted.

Did Microsoft actually patch more than 15 vulnerabilities? The actual number is indeed higher judging from the MS07-030 Visio Security Bulletin: “This important update resolves [...] in addition to other security issues identified during the course of the investigation.”. Silently fixing “other security issues” leaves Microsoft’s customers in the dark since they can’t tell the urgency to apply the patches and whether their security tools will protect the affected software.

The monthly update of the numbers is shown below. After adding the fifteen patched vulnerabilities, the 2007 numbers are still higher than those of earlier years.
Š