Last Updated: 2010-07-18 21:17:04 UTC
by Joel Esler (Version: 4)
We've received plenty of information over the past couple days about this alleged vulnerability in Windows's "lnk" file, and it's use against "SCADA" networks.
UPDATE: Two of our Handlers have copies of it now on their analyzation systems. Thank you, we will analyze it.
UPDATE 2: We have been notified via our comments that Symantec has definitions for this malware as well now.
UPDATE 3 (from Bojan):
Microsoft posted the advisory about the vulnerability in Windows Shell that has been exploited in some targeted attacks (the advisory is at http://www.microsoft.com/technet/security/advisory/2286198.mspx).
I've tested the exploit and can confirm that it works in Windows XP, Vista and Windows 7. The exploit uses a specially crafted LNK file. This file allows the attacker to execute an arbitrary file by carefully specifying its location – the LNK file in itself does not exploit any vulnerability such as buffer overflows, for example, so it is a legitimate LNK file. The LNK file used in targeted attacks was manually crafted as some fields that are normally present, such as CreationTime, AccessTime or WriteTime are all set to 0.
I will not be posting details about how the exploit works, but here are some things that you should be aware of:
- If autorun is disabled, when a USB device with malicious LNK files is inserted, the exploit will not be triggered automatically.
- The exploit is triggered every time a folder containing a malicious LNK files is opened (for example, with Windows Explorer). It does not matter where this folder is – it does not have to be on a USB device, but in order to execute to malicious binary, the attacker has to specify its location correctly.
What makes this vulnerability extremely serious is the fact that it can be opened from any place, including remote shares, for example. The victim just has to browse to the remote share in order to trigger the vulnerability. So double check permissions on any remote shares you use in your companies (you shouldn't allow users to write in root folders, for example).
Some AV vendors started adding detection for these LNK files, although it is still very, very bad.
We will, of course, keep an eye on the development of this.
UPDATE 4 (from Bojan):
A PoC that exploits this vulnerability has been posted today. I would recommend everyone to take a look at Microsoft's advisory that is available at http://www.microsoft.com/technet/security/advisory/2286198.mspx, especially the workarounds section ("Disable the displaying of icons for shortcuts").
Last Updated: 2010-07-16 01:25:19 UTC
by Joel Esler (Version: 1)
This is a notification just to let you know that ISC.org has released a new version of BIND, 9.7.1-P2. This reverses a change made in 9.7.1.
"The change attempted to correct the behavior of a validating recursive resolver when explicitly queried for records of the type 'RRSIG'. These queries do not occur in normal DNSSEC operation, because RRSIG records are ordinarily returned along with the records they cover. However, a type 'RRSIG; query can be used for manual testing purposes. As a result of the change in 9.7.1, if the cache did not contain any RRSIG records for the name, such a query would trigger an endless loop of recursive queries to the authoritative server."
This patch backs out that change, and this will be fixed in a future release. So, those of you that upgraded to 9.7.1-P1, you'll need to apply this patch.
It can be downloaded from