Commonly in conversation with family or friends I am asked questions that begin with statements such as “Well, I had this computer virus…” Further into these conversations after asking some additional questions of my own, I become more convinced that the person believes they had a virus. From the descriptions provided I am often inclined to suspect classes of malware and potentially unwanted programs that are commonly referred to as FakeAlerts and rogue security software are responsible.

I have come across many of these types of programs disguised as anti-virus or anti-spyware products that generate false warnings of malware that is supposedly present on the system:

Fake alerts are typically trojans that generate false warnings of spyware on the computer. These alerts are most often displayed as a balloon pop-up from the systray. The fake alerts will typically encourage the user to download or install a rogue security software product by means of “detecting” bogus infections on the system and frighten the user into buying the rogue software in order to clean the fictitious malware that that was discovered.

I am continually surprised at the prevalence of these types of applications and how many computer users install and use these so I thought it might be useful to post some tips that may help with identifying traits that are commonly associated with these types of scams.

Use Responsible browsing practices:
Trojans typically spread manually, often under the premise that they are beneficial or wanted. To do this often times similar techniques such as those used in product marketing are involved. Responsible browsing practices can include identifying when propaganda is used to persuade one into believing something, doing something, or buying something. This is not solely indicative of something malicious in nature, however being able to tell when these methods are utilized can sometimes help one to know when to ask more questions about the motivation or intentions for the use of the tactic.

Do some quick research:
If something does flag ones attention it may be worth the effort to do some quick investigation. Use a well known search engine and enter search terms such as the name of the product you are being asked to purchase, the title of the dialog being displayed, the name of the malware that is being detected, etc. Try to avoid pages that are sponsored by the target of your investigation. Look for third party opinions or reviews. This may help provide some additional counterpoints that may help with an objective analysis of the software in question.

Are there any secondary indications of an infection?
Look for the presence of the files being identified by the software as malicious. Often these files will not exist on the system at all. Sometimes however these types of programs will write the fake files to the system so that it can later detect them as malicious.

Check the time and date stamps on the files. Are they similar to that of the time the program was installed or ran a scan?

Submit the file to an online scanning service such as VirusTotal and see if established anti-virus programs detect them.

These are just a few simple examples from the quick and easy do-it-yourself malware research guide!!

Some news is in circulation regarding a recently disclosed (and patched) vulnerability in Adobe’s Flash. The attack used dereferenced NULL pointers, which were believed to be very hard to exploit.

The findings were first revealed in a paper called “Application-Specific Attacks: Leveraging the ActionScript Virtual Machine,”(pdf) by Mark Dowd. The paper described a new technique for causing exploitable memory corruption vulnerability in Adobe’s Flash. Whilst the technique has targeted the ActionScript Virtual Machine for Win32/Intel platform, it’s understood that the attack could be carried out on any other platforms where Flash is available. The real question is whether this attack can be more generic to target dereferenced NULL pointers in general!

It is possible to do so, but it’s not that easy. There are certain conditions an exploit of this type has to satisfy before reaching the ultimate goal. Dowd used some wacky techniques to inject malicious ActionScript byte code into Flash runtime (basically by crafting an SWF with something to trigger the vulnerability and point the execution to another loaded-in-memory part of the file that had the malicious content). Then he forced malloc() to fail by trying to allocate some huge memory chunk. When malloc() failed, it returned NULL.

(OK, at this step a program trying to access a NULL pointer would basically crash, and something to check for malloc() return value is necessary to prevent that crash.)

In this case, Flash didn’t check for malloc() failure and did some pointer arithmetic operation to add the value of the pointer (NULL here) to some offset. Now, this “offset” was controllable, and this is where Dowd had preloaded his malicious content. (Don’t get too excited, folks. There were quite a few other conditions that Dowd’s exploit had to meet before loading his payload. But I’m eliminating a lot of details to present the overall picture). So now we have a pretty successful and reproducible exploit on Flash ActionScript VM. It even bypassed Vista’s ASLR because Vista’s Flash was compiled with the runtime security bit off.

Now, scaling this attack against native code is more difficult in spite of the success it had against ActionScript VM. We will still be looking for a controllable offset and a place to preload our payload. Nevertheless, it is still a neat discovery when taking into consideration the level of complexity needed to load the malicious payload.

This discovery reflects a trend that it is possible to circumvent runtime security countermeasures such as ASLR and the like by targeting other environments with higher privileges running on top of the native platform. And if you’re involved in any secure development lifecycle, you’d better go and check your code!