To run or not to run? That’s the question

2009-02-01

Roel Schouwenberg

Kaspersky Lab, USA
Editor: Helen Martin

Abstract

'Do media players, Sat Navs, SD cards or external hard drives make legitimate use of AutoRun?' Roel Schouwenberg, Kaspersky Lab, USA.


During 2008 a huge increase was observed in the amount of malware using the Microsoft Windows AutoRun functionality.

Previously, AutoRun was used mainly by malware coming from China targeting online games. Now, however, all sorts of malicious applications have been upgraded to include replication via AutoRun.

The current situation is reminiscent of the era of boot viruses. Some 15 years ago we faced a very similar problem with viruses spreading via floppies. Who doesn’t remember buying brand new floppies only to find out they had been infected at the factory in which they were assembled? These days one might encounter AutoRun malware on a brand new MP3 player, digital picture frame, external hard drive or Sat Nav, to name but a few devices.

Boot viruses started to die out following Microsoft's introduction of the Win95/NT operating system, on which a lot of malware failed to run. Can Microsoft repeat that trick once more?

Unfortunately, the situation we’re facing now doesn’t seem as easily solvable as the one we faced 15 years ago. The main problem is that it’s much easier for a clean machine to be infected by AutoRun malware than with a boot virus. Up until Windows XP SP1 an infected device only had to be plugged in for the malware to be run. With XP SP2 Microsoft changed how AutoRun was handled for USB devices, which meant that the malware would no longer be run automatically. However, accessing the device through Explorer still caused the malware to be run, and SP3 brought no change in this behaviour.

Realizing the error of its ways, Microsoft decided to handle things differently with Vista. In Vista, AutoRun does not play an active role by default for USB devices – a user has to activate the AutoRun command manually. However, while AutoRun no longer plays a significant role in Vista, AutoPlay is starting to play a bigger role for programs.

AutoPlay displays a prompt asking the user what it should do, with the default option being to run the program – and it’s not hard to guess what the majority of users will do. AutoPlay also offers to always take the same action for software, effectively making it the same as XP SP1 AutoRun.

While the user will no longer get infected (semi-)automatically by default, it’s unlikely that users will suddenly start being smart enough not to launch malware. In all likelihood, Microsoft made this move to improve security, but felt it necessary still to offer the equivalent user experience.

Some brief tests with Windows 7 showed the same results as with Vista, which pretty much means that nothing will change and infections via AutoRun/AutoPlay will continue.

It is obvious that Microsoft considers user-friendliness to be very important. But surely there are better ways to tackle the huge problem we are currently facing. Quite simply, there should be more differentiation between writable and read-only storage. The best course of action would simply be to eradicate AutoRun/AutoPlay for writable media – at least for programs.

This wouldn’t cause a problem for U3 devices as they have a read-only part, nor would it be a problem for CD/DVD-ROMs. The risk of infected read-only media is not great, and certainly not when compared to writable media.

Do media players, Sat Navs, SD cards or external hard drives make legitimate use of AutoRun? External hard drives may do, but there’s an easy solution for the problem of usability: simply allow AutoRun/AutoPlay for writable media only if the program is digitally signed. Any self-respecting company already signs its applications, so the issue of user-friendliness is not a big one at all.

Please, Microsoft, respond to this problem - it’s not too late to fix it by making the necessary changes to Windows 7.

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest articles:

Nexus Android banking botnet – compromising C&C panels and dissecting mobile AppInjects

Aditya Sood & Rohit Bansal provide details of a security vulnerability in the Nexus Android botnet C&C panel that was exploited to compromise the C&C panel in order to gather threat intelligence, and present a model of mobile AppInjects.

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…


Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.