Security researchers from around the world are digesting the weekend's fare at Infiltrate2011, organized by security outfit Immunity. "No policy or high-level presentations, just hardcore thought-provoking technical meat" was promised, and presenters served it up sizzling.

The sessions folded in a variety of topics slicing up current offensive security issues with some defensive interest mixed in. Discussions spread from technical wizardry attacking hardened linux kernels to general network exploration and reconnaisance. Infiltrate2011 itself follows somewhat on the Blackhat/Defcon conference model, but reduces the corporate marketing at those conferences. The peer reviewed set of presentations and research sponsored by one of the best known offensive security/penetration testing groups in the business sets the bar high and undistracted for the level of technical content. The final agenda is listed here.

A user discovered potential malware on his computer the other day – the files “autorun.exe” and “autorun.inf” on the C: drive which, the user claims, reappear after being deleted.

After an initial analysis it was found that a number of files are downloaded, including .NET FrameWork, which is quietly installed in the background. That was quite a surprise – it’s been a while since I’ve seen malware cheeky enough to install .NET. So I decided to investigate this sample in full. It turned out to be very interesting both in terms of the malicious functionality and the method used to install its components.

The autorun.exe source file is an SFX archive created using WinRK, an archive utility that is not currently very widespread. After it is run a whole chain of various files are executed:

Autorun.exe -> .exe -> !.bat -> start.vbs -> .bat -> Hidden Start inst.bat -> evntstart.exe;

The interesting thing about this sequence is that it uses only standard, legitimate software:

• “Autorun.exe” – WinRK SFX;
• “.exe” – BatToExe;
• “inst.bat” – launched using Hidden Start;
• “evntstart.exe” – WinRK SFX;

By now most people have seen the Secunia test results and all the ensuing discussions. Frankly, I was a bit surprised by the vehemently negative reaction from a number of AV vendors.

And it doesn't seem to be about the 20% difference between the 'winner' and the rest. Criticism has focused on the testing methodology, which many people thought was dubious. Some of the suggestions were useful - mostly those from Andreas Marx, the well-known AV solutions tester from Germany. The general tone, though, seems to be that many AV vendors thought their results would have been a lot better if the test methodology had been different. And maybe they're right.

But I think people are too focused on looking for mistakes in the tests and/or attempting to explain their poor PoC detection rates. Sure, criticizing Secunia's testing methods is justified, but only if we're discussing testing methodology, and nothing else.

As I see it, Secunia wasn't trying to highlight the weaknesses of AV solutions - I think they were trying to make a different point...

At Kaspersky, we've taken a decision not to detect PoC vulnerabilities - it's far more sensible to focus on protecting users from the real threats and exploits that are being used by malware authors in the real world. That's what our antivirus databases are for. The point isn't so much that detecting PoCs is a pretty difficult task (although the test results clearly show that even Microsoft and Symantec, with all of their resources, didn't fare all that well) but that detecting PoC s is a dead end, and doesn't address the fundamental problem.

So what is the problem?

This week we added another unusual detection – detection for a calculator virus.

Virus.TI.Tigraa.a is a memory resident virus, and in the best tradition of DOS viruses, it's a mere 492 bytes in size. It works on Texas Instruments TI-89 graphing calculators (the TI-89, TI-89 Titanium, and the Voyage 200 which will run most programs for the TI-89) with the Motorola 68000 processor. The virus is designed to clear the screen and then display a message saying 't89.GAARA'.

Of course, Tigraa.a is classic proof of concept code. It'll only work on individual calculators, and can't spread. But nevertheless, it's created another entry in the roll call of potentially infectable devices.

Do you think that installing Linux on an iPod is a waste of time? If you work in an anti-virus company it's not – you’re preparing the device to play with the first known virus for iPod.

It’s a typical proof of concept sample, showing that here’s another device that can be infected. It took us time to run the sample because the virus has bugs and sometimes crashes the system with Linux debug messages.

Overall, I don't think iViruses will cause serious problems in the future. The iPod world is very different from the PC and smartphone world. Users aren’t constantly installing new software and downloading a wide range of files, so that cuts down on the possible infection vectors. And what’s there to steal from an iPod? Multimedia files, and that's about all.

So – it was an interesting little puzzle, this proof of concept, but nothing more.

Yesterday, we added detection for Virus.Win64.Abul.a to our antivirus databases.

In addition to being the third Win64 virus we've seen (following on from Virus.Win64.Rugrat.a and Virus.Win64.Shruggle.a) Abul has got some neat points. It's written in C, is a very compact 3700 bytes in size, and uses operating system functions to compress part of infected files, so that the file size doesn’t change.

Apart from this, however, there's nothing really outstanding about Abul. It uses classic file infection methods which have been widely used to infect Win32 platforms.

It injects itself into the CSRSS.EXE and Winlogon.exe processes, and attempts to recursively infect all executable files on the hard disk. If it can't compress a section of a file so that there's space to add its code, the file will remain uninfected.

So this latest creation shows that virus writers are still using tried and trusted methods to infect new platforms, with only minor modifications. It’ll probably be a while before we start to see anything truly new for Win64, but then again, in the world of viruses, you never quite know what's round the next corner.

With various elections now taking place in the U.S., a recent report published by Ariel J. Feldman, J. Alex Halderman and Edward W. Felten of Princeton University details insecurities found in AccuVote-TS/x e-voting machines. Pointing out and detailing three different types of software-based attacks, this paper is sure to receive further attention.

The question is will it be the attention of malicious attackers, or from Diebold and the U.S. government.

From a malware research perspective, the most interesting attack detailed in the article is the Vote stealing virus. After reading this section of the paper I was left with the impression of a small malicious program with rootkit-like characteristics. We aren't talking about hidden files and modified software kernels however. In the described attack, covering tracks is as easy as modifying two separate data files in a way that end results agree with each other.

As described the malicious program randomly steals votes from one candidate and gives them to another. The authors of the paper understand well enough about election fraud, and took steps to ensure their malicious program did not result in a completely lopsided election result. In theory, if the results "feel" right, officials won't detect the fraud and may accept the results. There will be no need for people to vote again.

All-in-all a very interesting paper, and unlike the recent RFID proof-of-concept paper this one seems to have substance to it. One can easily imagine a would-be attacker slipping into a small, hidden, enclosed space to do their thing. In this case, that small enclosed space might just be your local voting booth!

Read more

• Security Analysis of the Diebold AccuVote-TS Voting Machine

We have just received a new version of the StarOffice malware we wrote about last week. Like the previous versions, this one doesn't work either, suffering from the same severe programming errors.

Speaking of which, it's come to our attention that the previous blogpost maybe wasn't very clear regarding the intended nature of Stardust. We'd like to clarify that - Stardust is broken and can't replicate.

You can check our description for details, or simply put, the virus is way too buggy to work.

We're continuing to get requests from users with files which have been encrypted by GpCode.

The good news is that we've sorted the encryption algorithm, and added a decryption routine to the latest antivirus database updates.

If you have files which have been encrypted by GpCode, update your antivirus databases, and scan your machine.Your files will be automatically decrypted.

If you've updated your antivirus databases, and your files are still encrypted, please send them to newvirus@kaspersky.com

I came across something interesting today: a macro virus which we’ve named Virus.StarOffice.Stardust.a

You might wonder what's interesting about this - viruses have been around for a long time, and are starting to fade from the scene.

But if you look more closely at the name, you can see why I'm interested: Stardust is a macro virus written for StarOffice, the first one I’ve seen. Macro viruses usually infect MS Office applications.

Stardust is the first virus I know of which is theoretically capable of infecting StarOffice and/ or OpenOffice. It's written in Star Basic. It downloads an image file (with adult content) from the Internet and then opens this file in a new document.

We’ll have a description of it in the Virus Encyclopaedia soon.