The Adobe AIR and Adobe Flash Player Incubator program updated their Flash Platform runtime beta program to version 5, delivered as Flash Player version 11.2.300.130. It includes a "sandboxed" version of the 32-bit Flash Player they are calling "Protected Mode for Mozilla Firefox on Windows 7 and Windows Vista systems". It has been over a year since Adobe discussed the Internet Explorer ActiveX Protected Mode version release on their ASSET blog, and the version running on Google Chrome was sandboxed too.
Adobe is building on the successes that they have seen in their Adobe Reader X software. Its sandbox technology has substantially raised the bar for driving up the costs of "offensive research", resulting in a dearth of Itw exploits on Reader X. As in "none" in 2011. This trend reflects 2011 targeted attack activity that we’ve observed. 2011 APT related attacks nailed outdated versions of Adobe Flash software delivered as "authplay.dll" in Adobe Reader v8.x and v9.x and the general Flash component "NPSWF32.dll" used by older versions of Microsoft Office and other applications. Adobe X just wasn't hit. IE Protected Mode wasn't hit. Chrome sandboxed Flash wasn't hit. If there are incident handlers out there that saw a different story, please let me know.
mwcollectd v4, a next-generation low-interaction malware collection honeypot, has just been released. It's written in C++, but the easy integration of additional Python modules means that malware researchers around the world can easily extend the honeypot with new protocols and features.
We're happy to be sponsoring this project, which was mainly developed by Georg Wicherski (one of our virus analysts in Germany) and Mark Schloesser, from RWTH Aachen University. It's published under the LGPL license. If you want to take a look at mwcollectd, it's here, and libemu, which is used by mwcollectd, is here.
On January 13th we raised the alert level for the Kido family to orange: moderate risk. It's been quite a while since an 'old school' network worm has caused such a stir - Kido's managed it by not only relying on critical Windows SMB vulnerabilities to spread but it also bruteforces weak passwords in order to gain access to other machines in a local network.
Because of this (along with a few other things) Kido can be very painful to get rid of. That's why we've decided to release a free tool which can be used to clean infected machines.
You can grab our KidoKiller tool here.
Feel free to give it a try.
Our previous blog on Gpcode said we'd managed to find a way to restore files in addition to those files that can be restored using the PhotoRec utility.
It turns out that if a user has files that are encrypted by Gpcode and versions of those same files that are unencrypted, then the pairs of files (the encrypted and corresponding unencrypted file) can be used to restore other files on the victim machine. This is the method that the StopGpcode2 tool uses.
Where can these unencrypted files be found? They may be the result of using PhotoRec. Moreover, these files may be found in a backup storage or on removable media (e.g., the original files of photographs copied to the hard disk of a computer that has been attacked by Gpcode may still be on a camera’s memory card). Unencrypted files may also have been saved somewhere on a network resource (e.g., films or video clips on a public server) that the Gpcode virus has not reached.
We can't guarantee that files will be restored, as the method used relies not only on the user having unencrypted versions of the affected files but also on the characteristics of the infected machine. All the same, the results we achieved during testing (80% of encrypted files were restored) suggest that it's worth doing if you need to recover your files.
The more pairs of files that can be found the more data that can be restored.
Detailed instructions on the use of the StopGpcode2 tool can be found in the description of Virus.Win32.Gpcode.ak.
Currently, it's not possible to decrypt files encrypted by Gpcode.ak without the private key. However, there is a way in which encrypted files can be restored to their original condition.
When encrypting files, Gpcode.ak creates a new file next to the file that it intends to encrypt. Gpcode writes the encrypted data from the original file data to this new file, and then deletes the original file.
It's known that it is possible to restore a deleted file as long as the data on disk has not been significantly modified. This is why, right from the beginning, we recommended users not to reboot their computers, but to contact us instead. We told users who contacted us to use a range of utilities to restore deleted files from disk. Unfortunately, nearly all the available utilties are shareware – we wanted to offer an effective, accessible utility that could help restore files that had been deleted by Gpcode.
What did we settle on? An excellent free utility called PhotoRec, which was created by Christophe Grenier and which is distributed under General Public License (GPL).
The utility was originally created in order to restore graphics files (presumably that's why it's called PhotoRec, short for Photo Recovery). Later, the functionality was extended, and the utility can currently be used to restore Microsoft Office documents, executable files, PDF and TXT documents, and also a range of file archives.
You can find a full list of supported formats here. The official PhotoRec utility site is here. The PhotoRec utility is part of the TestDisk package, and you can find the latest version of TestDisk, including PhotoRec here.
It should be stressed the PhotoRec excels at the task it was designed for: restoring file data on a specific disk. However, it has difficulty in restoring exact file names and paths. In order to address this issue, we've developed a small, free program, called StopGpcode.
If you've fallen victim to GpCode, don't pay the author of the virus to restore your data. Use PhotoRec instead – if you want, you can make a donation to the developer of the program.
The description of Gpcode contains detailed instructions on how to manually restore files attacked by the virus using PhotoRec and Stopgpcode.
Exactly two years ago we introduced our extended databases.
These databases protect against AdWare, RiskWare and PornWare. Some people like to refer to the extended databases simply as anti-spyware protection, but we actually detect much more than just that with the help of these databases, most notably RiskWare programs.
Back then we still had cumulative updates and the extended databases consisted of three components: advware.avc, riskware.avc and pornware.avc.
Later two of those names changed to adware.avc and obscene.avc. Since the beginning of this year we simply have combined them into extxxx.avc database, where the x stands for a decimal figure. However, we've actually been detecting these types of threats for much longer than two years.
Before we introduced the extended databases the detection of AdWare etc. was included in x-files.avc.
Two years ago it was special to have a separate option to cover such threats, now it is a much more common feature for antivirus programs.
You can select the extended databases by going to KAV's settings, clicking on Threats and exclusions, and then selecting the extended database.
Be sure to read the pop-up message when choosing a database from the dropdown list.
MSN released version 7 of their Messenger yesterday.
In addition to some other new features, the new version also incorporates functions to prevent the spreading of malware.
The developers have taken some serious steps to prevent the sharing or spreading of .pif files. Any incoming or outgoing message with a ".pif" in it will be blocked completely.
Too bad that MSNM doesn't tell you that this is happening. Messages won't get delivered to the recipient, but neither the recipient nor sender will be notified that the message has been blocked. Not very user-friendly, IMHO.
In addition to filtering messages, MSN 7 also filters incoming file transfers. This filtration applies to files such as executables (with extensions such as .exe, .com, .scr etc) and other potentially dangerous types of file such as .vbs and .reg.
We've already seen IM-worms which spread in the form of a link to .scr files, so the measures that MSN developers have taken won't be 100% effective. But I think the complete blocking of .pif files is the most important innovation, as it's IM-worms spreading as .pif files which have been the most 'successful' to date.
Although some users may not like this kind of filtering, I think in the long run we're better off. IM-worms are becoming more and more common. Sooner or later users will have to learn to live with security measures designed to combat their spread.
Kudos to our development folks who've come up with a public beta version of the interesting KAV Web Scanner, a free service which scans your computer for viruses, and runs directly from a web page on our site.
We encourage everybody go ahead and take a look:
Please keep in mind this is not a finished product so we are especially interested in any opinions and/or suggestions you may have. Feedback, queries and (ahem) bug reports should go to: webscannerbeta (at) kaspersky (dot) com
We have put together a new removal tool that detects and disinfects malware on smartphones and other mobile devices running Symbian OS.
It's available for download and is effective until May 1, 2005.
OS Supported: Symbian OS 6.1, 7.0.
Devices supported: Series 60 smartphones.
Note: This version was tested on Nokia 3650, Nokia 7650, Nokia 6600, Siemens SX1.
Download the utility directly to your smartphone via WAP or download it to your PC and copy it to the device(size is 9.2 KB).
Install it as a common Symbian application package by opening the message that you recieve when downloading the file.
You will need to download and install the utility again every time you would like to update the antivirus databases (we recommend that you do this when you hear of new malware for Symbian OS).
Microsoft has released a beta version of its antispyware program.
Response from the IT community has been mixed so far, not surprisingly.
For instance, today we received a report about MS AntiSpyware flagging
a suspicious file:
"c:\winnt\system32\notpad.exe" was detected as a Remote Administration Tool.
This file - which was a French version of notepad - would normally be called notepad.exe. For some reason, we don't know why, the file was renamed as notpad.exe.
When we looked closely, it was clear what this file was. So we figured that MS AS had a faulty signature meaning this particular French version of notepad is detected as ItEye RAT.
Not every version (language, build) of every (Windows) file gets tested to check for false alarms, so this might have slipped by.
However we quickly realized that it was the combination of file name/location that made MS AntiSpyware go off.
In fact, the beta version of MS AntiSpyware detects any file with the name "notpad.exe" - even a completely empty one - residing in %sysdir% as being this particular RAT.
So at least a part of the "ItEye RAT" detection is strictly based on filename/location, which can result in situations like these.
Because of this, we think it's best to detect files by file signatures, not location.