Finally Microsoft has released an automatic update which disables AutoPlay in USB drives for all its Windows Operating Systems. Up until now only Windows 7 disabled this functionality by default. With this update Microsoft finally puts a stop to one of the most common malware infection vectors of the last 6 years.
Let’s quickly review the history of this functionality which during 2010 has been said to account for 25% of malware infections worldwide and the source of quite a few embarrassments for many companies (examples here and here). But first some definitions:
AutoRun: feature to automatically launch programs from removable media as soon as they are mounted on the system. Under Windows the parameters of this auto-execution are defined inside a file called autorun.inf which is located at the root of the removable media.
AutoPlay: introduced with Windows XP, analizes the removable media and depending on the contents launches a dialog window which suggests the most appropriate programs to reproduce the content. If the default is chosen the dialog window will not show again thanks to AutoRun and the AutoPlay “memory”.
- In 2005 USB drives became popular and malware started using them to propagate.
- Even three years after malware started actively using this method to infect customers, Microsoft refused to accept the reality of the problem and continued offering AutoRun enabled by default in the Windows OS’s. However in 2008 Microsoft added an option for disabling AutoRun via policies or manual registry entries. However the workaround provided did not work. Even when disabled users were still open to attack from the AutoRun infection vector.
- In July 2008 Microsoft published MS08-038 which “fixed the broken fix” but this was only available via Windows Update for Windows Vista and Windows 2008. Instead of patching XP users as well, it kept the problem unsolved in what some might consider a business strategy to sell more Vista licenses.
- Towards the end of 2008 Conficker showed up taking advantage of the AutoRun feature in a never seen before manner. It created an autorun.inf file whose content looked like garbage yet was fully functional. All the Microsoft recommended workarounds to date via NoDriveTypeAutorun policies continued to be useless against malware exploits.
- In early 2009 and due to Conficker’s success Microsoft corrected a bug (CVE-2009-0243) which fixed portions of the previous problem and which was pushed out automatically to all Windows XP users. Amazingly it wasn’t considered a “security patch” and does not have an associated Microsoft Bulletin. In addition the patch modified the behaviour of AutoRun and after applying it created a new registry entry which was required to be manually configured correctly. Effectively AutoRun continued being a problem for the vast majority of users.
- In mid 2009 there seems to be some light at the end of the tunnel and Microsoft decides to improve the security of AutoRun in writeable removable media by preventing the AutoPlay dialog window in USB drives. However this is only included by default under Windows 7. Windows XP users, still the most widely used platform by far, had to manually download and install KB971029. This move was effectively useless from the point of protecting XP users from malware infection. Again some might consider this move a business-driven decision to “keep security low in XP in order to drive sales of the more secure Windows 7”.
- In July 2010 Stuxnet shocks the world. It is able to propagate via USB drives without requiring an autorun.inf file and using a zero-day vulnerability in .LNK files which allows for code execution even with AutoRun and AutoPlay disabled, which Microsoft promptly patches.
- Finally in February 2011 Microsoft decided to push an update to fix the problem for Operating Systems prior to Windows 7.
It has been a long and tedious road to have this wide open door finally shut down. The main question that comes to mind given the technical simplicity of the fix is “why wasn’t this issue fixed before?“. Why has Microsoft allowed its users to become easily infected by malware for years when the solution was readily available? Of course the real reasons might never see the light of day. Instead arguments such as “improved usability and portability” will probably take the spotlight. But how about the security implications of the dozens of millions of infections which have siphoned credentials, money and personal information from users during all these years?
As a side note, there are still many infected and unpatched machines out there so be sure to apply the Microsoft patch and use something like USB Vaccine to provide an additional layer of protection.
NOTE: this post is based on the original published by Hispasec .
I think you are rushing a bit with this, as Microsoft is misleading in their advisory. They say: “The update to Autorun described in Microsoft Knowledge Base Article 971029 is now available via automatic updating.”
However, KB971029 is served as an optional update. In addition to XP, it also applies to Windows Vista and Windows Server 2008, where the Automatic Update feature can also deliver optional updates.
However, their statement is only half-true because that’s not the case on XP, where probably this update is most important anyway.
On XP only High Priority (Critical) updates are served through Automatic Update. To receive optional updates one needs to go to the Windows Update or Microsoft Update websites and manually select them. There’s nothing automatic about it.
I’m willing to bet that most vulnerable users won’t do that.
I’ve discover a in 2005 too. It’s Trj/Flashy.A in my university computer room.
And it infect most of student’s home computer because this trojan is new in that time.
@Skello you’re right in that KB971029 was shown as optional but on February 22, 2011 MSFT changed the deployment logic and now its installed as High Priority under XP by default. Check http://www.microsoft.com/technet/security/advisory/967940.mspx under the latest change:
“Change to the deployment logic for updates described in this advisory. This change in deployment logic is intended to minimize the user interaction required to install the updates on systems configured for automatic updating. With the change, typically no user action will be required to install the updates because automatic updating detects the configuration of the target system, downloads the updates, and installs the updates automatically or on a schedule specified by the user. “
I don’t know about your recommendation to use the MS patch and then add “something like USB Vaccine to provide an additional layer of protection”! I have just installed UBS Vacinne on my Win& desktop and used it to “vaccinate” several of my USB drives. Bad idea. Clearly not supported. Evidently not appropriate to use on a Win7 system. Among what are perhaps good features, it does the bad thing of erasing the device name, and preventing it from being reset. I suggest USB Vaccine either by removed from the market or dragged kicking and screaming up from version 184.108.40.206 of sometime back in 2009! Cheers.