Rootkit.Duqu.A is digitally signed (with a stolen and revoked certificate) which means that it targets not only 32-bit Windows systems but also 64-bit editions of the Microsoft Windows operating system. According to information posted by Bitdefender, Duqu runs for 36 days on a computer collecting information entered via the keyboard. This may include passwords, emails, conversations, logins on popular sites and even banking and credit card information.

Symantec has posted additional information about Duqu’s installer. According to Symantec’s information, Duqu is spread as a Microsoft Word document that exploits a Windows kernel vulnerability that allows code execution. When a user opens the Word document the malicious code is executed and Duqu is installed on the system.

Duqu infections have already been confirmed in countries such as France, Switzerland, India, the United Kingdom, Austria and the Netherlands.

Symantec has released a whitepaper in pdf format that contains all known details up to this point.

Windows users who want to make sure that their system is clean and not infected by the Duqu rootkit can use Bitdefender’s Removal Tool to scan the system and if necessary disinfect it.

The portable rootkit remover can be downloaded from an official Bitdefender website. All that Windows users need to do is to click on the Scan button to start the scan. The program will list any files that have been identified to be part of the Duqu rootkit. Please note that the program may require elevated rights on some machines.

Is there a way to protect your computer in the meantime? Yes, do not open Word documents locally. Use an online document viewer like Google Docs or Docs.com for that. (via)

Security Advisory 2501696 reveals that the “vulnerability exists due to the way MHTML interprets MIME-formatted requests for content blocks within a document” and that it “could allow an attacker to cause a victim to run malicious scripts when visiting various Web sites, resulting in information disclosure”.

The vulnerability exists due to the way MHTML interprets MIME-formatted requests for content blocks within a document. It is possible under certain conditions for this vulnerability to allow an attacker to inject a client-side script in the response of a Web request run in the context of the victim’s Internet Explorer. The script could spoof content, disclose information, or take any action that the user could take on the affected Web site on behalf of the targeted user.

An example of a possible attack is given by Angela Gunn at the MSRC blog:

For instance, an attacker could construct an HTML link designed to trigger a malicious script and somehow convince the targeted user to click it. When the user clicked that link, the malicious script would run on the user’s computer for the rest of the current Internet Explorer session. Such a script might collect user information (eg., email), spoof content displayed in the browser, or otherwise interfere with the user’s experience.

Microsoft admits that proof-of-concept code has been published but mentions that they are not aware of active exploitations of the issue.

A workaround has been posted on the Security Advisory page. It basically locks down the MHTML protocol to protect the Windows operating system from possible exploits. Users need to modify the Windows Registry if they follow the suggested actions on the Security Advisory page. Administrators find information on how to apply it across domains by using Group Policy there as well.

Another option is to change the Internet Explorer security settings to high to block ActiveX Controls and Active Scripting. This may have an impact on websites and services that make use of the technologies.

A Fix-It solution has been created as well which makes the patching more comfortable.

While that excludes the majority of desktop users, it may still affect some that run web servers on their desktop systems. Those users are asked to update immediately once the patch is released.

About the release: Microsoft will make the security patch available on Microsoft Download first, before it will be distributed via Windows Update. Dave Forstrom, Director, Trustworthy Computing said it will take approximately a few days before the update is released on Windows Update and Windows Server Update as well.

For now, Windows Server users and Windows client users running a web server should monitor Microsoft’s Download Center for the patch, which will be made available there later today.

Admins who want additional information can take a closer look at the Microsoft Security Bulletin, which lists the affected operating systems, the maximum security impact and additional information about the vulnerability.

This security update resolves a publicly disclosed vulnerability in ASP.NET. The vulnerability could allow information disclosure. An attacker who successfully exploited this vulnerability could read data, such as the view state, which was encrypted by the server. This vulnerability can also be used for data tampering, which, if successfully exploited, could be used to decrypt and tamper with the data encrypted by the server. Microsoft .NET Framework versions prior to Microsoft .NET Framework 3.5 Service Pack 1 are not affected by the file content disclosure portion of this vulnerability.

This security update is rated Important for all supported editions of ASP.NET except Microsoft .NET Framework 1.0 Service Pack 3. For more information, see the subsection, Affected and Non-Affected Software, in this section.
The security update addresses the vulnerability by additionally signing all data that is encrypted by ASP.NET. For more information about the vulnerability, see the Frequently Asked Questions (FAQ) subsection for the specific vulnerability entry under the next section, Vulnerability Information.

Windows client users who are not running a web server are not affected by the vulnerability. Some may want to consider installing the update nevertheless.

The problem with executable files is that the search priority list changes. According to a blog post at the Acros Security blog, exe files are either loaded with the highest or second highest priority in Windows.

This means for instance that a command to launch a new process will look into the current working directory prior to looking into the Windows directories or directories in the path environment.

An attacker could exploit this by placing executables of the same name in the working directory, e.g. a malicious explorer.exe that is launched by the application executed by the user of the system.

What does it mean? It means that the situation is highly critical as the available workarounds to protect a system from the DLL hijacking vulnerability are not working to protect it against the exe hijacking.

[CreateProcess] Apparently the current working directory is in the second place, which means that when an application tries to launch the Windows Calculator by calling something like CreateProcess(NULL,”calc.exe”,…), a malicious calc.exe lurking in the current working directory will get launched instead. And remotely, too, if the current working directory happens to point to a remote network share in a local network or on Internet. And no, launching remote executables using these functions will never issue any security warnings to the user, in contrast to ShellExecute*. As far as we know, introducing ShellExecute-like security warnings to these functions would cause serious problems with various batch jobs and server back-end operations running without humans present.

Acros have created a test and have released it to the public. The Online Binary Planting Exposure Test is available on Binaryplanting.com. This test is aimed at users who want totest their exposure to binary planting attacks.

The easiest way to fix the issue, at least for users who do not use WebDav is to disable it. Windows 7 users need to open the Windows Services with the hotkey Windows-R, typing services.msc and hitting enter. They then need to locate the service WebClient, which is set to manual by default. A double-click on the entry and the selection of disabled disables the service completely on the operating system.

webclient

The issue itself still exists on local drives, after disabling WebDav. An example was given for Apple’s Safari web browser, which can be used in the attacks (Apple has updated the browser since then):

As a result of an incorrect process launching in Apple Safari for Windows, an attacker can cause her malicious EXE [1] to be loaded and executed from local drives, remote Windows shares, and even shares located on Internet.

What a remote attacker has to do is plant a malicious explorer.exe on a network share and get the user to open an HTML file from this network location with Safari – which should require minimal social engineering. Then, when the user tries to open one of his downloaded files in the
containing folder (e.g., menu: Window -> Downloads -> right-click on a file -> Show Containing Folder), the malicious explorer.exe is launched instead of the legitimate one.

Alternatively, if the HTML file opens (or redirects to) any “file://” location, Safari’s attempt to launch Windows Explorer will result in launching the malicious explorer.exe. (via)

Security software that is up to date is the most effective option in protecting the system from local attacks.

New users who want to read up on it can open our coverage of the issue, or Microsoft’s Security Advisory. Both offer a deeper explanation and workarounds for the issue.

The free software DLLHiJackAuditor has been designed to test software for the vulnerability. The portable program can audit any 32-bit Windows application.

The program is dead easy to use. Users need to select an application from the computer system first before they click on the start audit button to test the application.

dll hijack vulnerability

The portable software will automatically load the application, and terminate it. It will uncover any vulnerable DLLs that are found during the audit, and report those back to the user of the program.

The Exploit button becomes active if a vulnerable DLL has been found in the selected software.

Finally, it is possible to create a HTML report of the findings, which contains detailed technical information that the developer of the vulnerable application can use to fix the issue.

DLL Hijack Audit does not require any third party tools to function properly. It has in addition been designed in a way that it does not trigger antivirus or security software on the system. Finally, the program require no special privileges for auditing applications, with the exception if the target executable does).

The software program is available for download at the developer website over at SecurityXploded. The tool can be useful for software developers, and users who want to make sure that the programs they run on their system are not affected by the security issue.

In simple terms: Applications that do not use qualified paths for external dynamic link libraries use Windows default settings to find those dlls on the system, and one of the first locations to be searched is the program directory, which can be a local or remote directory.

The exploit dlls simply have to be placed in those directories to be executed by the applications. Affected are many popular programs, including Firefox, VLC, Opera, Photoshop, uTorrent or PowerPoint.

Microsoft published additional information about the DLL preloading remote attack vector in a blog post at the Security Research and Defense blog.

Among the information is a workaround that requires the creation of Registry keys to change the library loading behavior either on a system wide level, or specific applications.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
Session Manager\CWDIllegalInDllSearch
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\
Image File Execution Options\binaryname.exe\CWDIllegalInDllSearch

Both keys support the following values, which have different effects depending on the location of the application:

Scenario 1: The application is started from a local folder, such as C:\Program Files
0xffffffff Removes the current working directory from the default DLL search order.
0 Uses the default DLL search path. This is the Windows default, and the least secure setting.
1 Blocks a DLL load from the current working directory if the current working directory is set to a WebDAV folder.
2 Blocks a DLL load from the current working directory if the current working directory is set to a remote folder.

Scenario 2: The application is started from a remote folder, such as \\remote\share
0xffffffff Removes the current working directory from the default DLL search order.
0 Uses the default DLL search path. This is the Windows default, and the least secure setting.
1 Blocks a DLL load from the current working directory if the current working directory is set to a WebDAV folder.
2 Allows DLL load from the current working directory if the current working directory is set to a remote folder. DLL’s that are loaded from a WebDAV share are blocked if the current working directory is set to a WebDAV share.

Scenario 3: The application is started from a WebDAV folder, such as http://remote/share
0xffffffff Removes the current working directory from the default DLL search order.
0 Uses the default DLL search path. This is the Windows default, and the least secure setting.

Attackers could exploit the vulnerability to infect Windows operating systems during connection of removable drives, if autoplay is enabled on the system. The attack uses a specifically prepared lnk-file, containing code that is executed because Windows Shell does not parse that parameter sufficiently.

Affected are all Microsoft operating systems since (and including) Windows XP. Microsoft mentions other attack scenarios besides removable devices. The vulnerability can also be exploited via WebDAV or network shares.

Microsoft mentions three mitigating factors in the security advisory. A successful attack will give the attacker the same rights as the active user. Limited usage rights would mean that the attack could have less impact than an attack on a system where the user has administrative rights.

Systems with autoplay disabled cannot be attacked during connection. A user would have to launch “Windows Explorer or a similar application and browse to the root folder of the removable disk” for the attack to be started.

Finally, “Blocking outbound SMB connections on the perimeter firewall will reduce the risk of remote exploitation using file shares”.

A patch is currently not offered, a workaround exists however. The following steps need to be completed to protect a computer system:

Disable the displaying of icons for shortcuts

Note Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. For information about how to edit the registry, view the “Changing Keys And Values” Help topic in Registry Editor (Regedit.exe) or view the “Add and Delete Information in the Registry” and “Edit Registry Data” Help topics in Regedt32.exe.

1. Click Start, click Run, type Regedit in the Open box, and then click OK
2. Locate and then click the following registry key:
   HKEY_CLASSES_ROOT\lnkfile\shellex\IconHandler
3. Click the File menu and select Export
4. In the Export Registry File dialog box, enter LNK_Icon_Backup.reg and click Save

   Note This will create a backup of this registry key in the My Documents folder by default

5. Select the value (Default) on the right hand window in the Registy Editor. Press Enter to edit the value of the key. Remove the value, so that the value is blank, and press Enter.
6. Restart explorer.exe or restart the computer.

Impact: Will disable all shortcut icons, which means for instance that all Windows 7 taskbar items or start menu items are showing as white icons, which makes identification hard to impossible.

Microsoft suggests to disable the WebClient service to block the most likely remote attack vector through the Web Distributed Authoring and Versioning (WebDAV) client service.

To disable the WebClient Service, follow these steps:

• Click Start, click Run, type Services.msc and then click OK.
• Right-click WebClient service and select Properties.
• Change the Startup type to Disabled. If the service is running, click Stop.
• Click OK and exit the management application.

Additional information are available at the Microsoft Security Advisory page and the Wilders Security forum.

Modules of current malware were first time detected by “VirusBlokAda” (http://anti-virus.by/en/) company specialists on the 17th of June, 2010 and were added to the anti-virus bases as Trojan-Spy.0485 and Malware-Cryptor.Win32.Inject.gen.2. During the analysis of malware there was revealed that it uses USB storage device for propagation.

You should take into consideration that virus infects Operation System in unusual way through vulnerability in processing lnk-files (without usage of autorun.inf file).

So you just have to open infected USB storage device using Microsoft Explorer or any other file manager which can display icons (for i.e. Total Commander) to infect your Operating System and allow execution of the malware.

Malware installs two drivers: mrxnet.sys and mrxcls.sys. They are used to inject code into systems processes and hide malware itself. That’s the reason why you can’t see malware files on the infected USB storage device. We have added those drivers to anti-virus bases as Rootkit.TmpHider and SScope.Rookit.TmpHider.2. Note that both drivers are signed with digital signature of Realtek Semiconductor Corp. (www.realtek.com).

Thus, current malware should be added to very dangerous category causes the risk of the virus epidemic at the current moment.

After we have added a new recordes to the anti-virus bases we are admitting a lot of detections of Rootkit.TmpHider and SScope.Rookit.TmpHider.2 all over the world.

Expect a patch soon that is addressing the issue.

Microsoft is aware of limited targeted attacks that exploit the vulnerability. These attacks use specially crafted links on web pages or email messages with the hcp:// prefix instead of http://.

The HCP protocol is used to execute links in the Help and Support Center. The threat is caused by the Windows Help and Support Center not properly validating links that use the HCP protcol.

Attackers who successfully exploit the vulnerability could take complete control of the system if the user is logged in with administrative privileges. The vulnerability can only be exploited if the user clicks on a prepared link.

Microsoft has created a Fix-It script that can be used to protect Windows XP and Windows Server 2003 systems from the vulnerability.

The script disables the threat by unregistering the HCP protocol on the target system.

A manual workaround was also posted

• 1. Click Start, click Run, type Regedit in the Open box, and then click OK
• 2. Locate and then click the following registry key:
  HKEY_CLASSES_ROOT\HCP
• 3.Click the File menu and select Export
• 4.In the Export Registry File dialog box, enter HCP_Procotol_Backup.reg and click Save. Note This will create a backup of this registry key in the My Documents folder by default.
• 5. Press the Delete key on the keyboard to delete the registry key. When prompted to delete the registry key via the Confirm Key Delete dialog box, click Yes.

Using a Managed Deployment Script

• 1. Create a backup copy of the registry keys by using a managed deployment script that contains the following commands:Regedit.exe /e HCP_Protocol_Backup.reg

  HKEY_CLASSES_ROOT\HCP

• 2. Next, save the following to a file with a .REG extension, such as Disable_HCP_Protocol.reg:Windows Registry Editor Version 5.00

  [-HKEY_CLASSES_ROOT\HCP]

• 3. Run the above registry script on the target machine with the following command from an elevated command prompt: Regedit.exe /s Disable_HCP_Protocol.reg

Disabling the HCP protocol will break all links, be they local or remote, that use the HCP procotol.

The vulnerability was discovered in the Windows Canonical Display Driver (cdd.dll) which is used by “desktop composition to blend the Windows Graphics Device Interface (GDI) and DirectX drawing”.

The vulnerability received a preliminary Exploitable Index rating of 3:

Although it is possible that the vulnerability could allow code execution, successful code execution is unlikely due to memory randomization. In most scenarios, it is much more likely that an attacker who successfully exploited this vulnerability could cause the affected system to stop responding and automatically restart.

The vulnerability is only affecting Windows systems with the Windows Aero theme installed and in use. Windows Aero is not the default theme in Windows Server 2008 R2.

Microsoft’s suggested action is to disable the Windows Aero theme for the time being until a security patch for the vulnerability is released.

To disable Windows Aero by changing the theme, perform the following steps for each user on a system:
1.
Click Start, select the Control Panel, and then click on Appearance and Personalization.
2.
Under the Personalization category, click on Change the Theme.
3.
Scroll to the bottom of the listed themes and select one of the available Basic and High Contrast Themes.

The security advisory and the blog post announcing the security vulnerability contain additional information.

Update: The 64-bit vulnerability has been patched. Windows users who have downloaded all recent security patches for their operating system, or installed the first Service Pack for it, are safe from the exploit. Users who have disabled the Aero theme because of the exploit can turn it back on. This is done by following the same steps outlined above.

Cause of the problem is the virtual dos machine (vdm) that was introduced in 1993 to support 16-bit applications. The exploit was uncovered by Tavis Ormandy, a member of Google’s security team. It makes it possible to run code with elevated rights on the computer system. The full technical explanation of the vulnerability and example exploit code are available at Neohapsis.

No patch has been issued by Microsoft until now even though Ormandy mentioned that he had contacted Microsoft about the issue six months ago. There is however a quick fix for most Windows operating systems: Disallowing VDM.

There are two possibilities on how to do that. System administrators and users with access to the Windows Group Policy Editor and an operating system that is Windows 2003 or newer can enable the policy to “Prevent access to 16-bit applications” in Computer Configuration > Administrative Templates > Windows Components > Application Compatibility”.

This setting has the consequence that 16-bit applications will not execute on the computer system which should not have an effect on most home users.

Users with operating systems prior to Windows 2003, Windows XP comes to mind, can alternatively create a new Windows Registry key to close the security vulnerability in the operating system.

This is done by navigating to the Registry key

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\AppCompat

and creating the new DWORD VDMDisallowed and setting the value of the Dword to 1.

Operating systems that are not affected include Windows XP, Windows 7 final and Windows Server 2003. No patch is currently available to fix the vulnerability. Microsoft has published workarounds to protect the operating system from possible attacks.

Disable SMB v2

To modify the registry key, perform the following steps:

Note Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. For information about how to edit the registry, view the “Changing Keys And Values” Help topic in Registry Editor (Regedit.exe) or view the “Add and Delete Information in the Registry” and “Edit Registry Data” Help topics in Regedt32.exe.

1. Click Start, click Run, type Regedit in the Open box, and then click OK.
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
3. Click LanmanServer.
4. Click Parameters.
5. Right-click to add a new DWORD (32 bit) Value.
6. Enter smb2 in the Name data field, and change the Value data field to 0.
7. Exit.
8. Restart the “Server” service by performing one of the following:
- Open up the computer management MMC, navigate to Services and Applications, click Services, right-click the Server service name and click Restart. Answer Yes in the pop-up menu.
- From a command prompt and with administrator privileges, type net stop server and then net start server.

Impact of workaround. Host will not be able to communicate using SMB2.

Block TCP ports 139 and 445 at the firewall

These ports are used to initiate a connection with the affected component. Blocking TCP ports 139 and 445 at the firewall will help protect systems that are behind that firewall from attempts to exploit this vulnerability. Microsoft recommends that you block all unsolicited inbound communication from the Internet to help prevent attacks that may use other ports. For more information about ports, see TCP and UDP Port Assignments.

Impact of Workaround: Several Windows services use the affected ports. Blocking connectivity to the ports may cause various applications or services to not function. Some of the applications or services that could be impacted are listed below:

• Applications that use SMB (CIFS)
• Applications that use mailslots or named pipes (RPC over SMB)
• Server (File and Print Sharing)
• Group Policy
• Net Logon
• Distributed File System (DFS)
• Terminal Server Licensing
• Print Spooler
• Computer Browser
• Remote Procedure Call Locator
• Fax Service
• Indexing Service
• Performance Logs and Alerts
• Systems Management Server
• License Logging Service

Users that are running one of the operating systems that are affected by the vulnerability are encouraged to use one of the workarounds to protect their computer systems. More information are available at the Microsoft Security Advisory page.

The security bulletin resolves three vulnerabilities in Microsoft Server Message Block (SMB) Protocol which could allow remote code execution on affected systems. An attacker could run programs, create new user accounts and view, change or delete data on the computer system. It is interesting to note that Windows 7 is affected as well even though it is not mentioned in the security bulletin.

The security vulnerability would be rated as moderate for the upcoming operating system which is why Microsoft will not provide a patch at the current time (They chose to only patch critical security vulnerabilities immediately). A patch will be released with the next public release of Windows 7.

Patches can be applied as usual through the various official update channels.