Trojan archives - IT Trenches

Jun 24 2009 6:24PM GMT

Did you see this? - SYSTEM CLEANING: GETTING RID OF MALWARE FROM INFECTED PCS

Posted by: Troy Tate

malware, malicious software, Security, information security, integrity, availability, trojan, bot, botnet, registry, antivirus, anti-virus, av

I don’t know about you but I do get frustrated when a white paper is advertised and it has little or no meat to it. Most times it seems like the whitepapers offered by vendors today are light marketing fluff with little substance to help IT folks do their job better.

I came across a whitepaper/research document today that will help you do your job better if you manage systems that may become affected by malware. This means anyone that uses a computer could get some use from this document and website.

Check it out today. The whitepaper does not require any registration (another pet peeve of mine - check out bugmenot for Firefox if registrations bug you too!). The whitepaper is titled SYSTEM CLEANING: GETTING
RID OF MALWARE FROM INFECTED PCS.

Thanks for reading and let’s continue to be good network citizens.

0 Comments

RSS Feed

Email a friend

Jan 21 2009 5:10PM GMT

Microsoft guidelines for Turning off Windows AutoRun do NOT work properly!

Posted by: Troy Tate

anti-virus, antivirus, Security, information security, CERT, Windows, trojan, digital picture frame, risks, security notification

One of the information security lists I subscribe to is the US-CERT Technical Cyber Security Alerts. US-CERT is the United States Computer Emergency Readiness Team. If you have information security responsibilities, I highly recommend that you visit their website and register for their mailing lists and subscribe to the RSS feeds to get the latest information on information security issues from a trusted US Government source.

In case you have not seen or heard the latest US-CERT Technical Cyber Security Alert reads as shown below. I don’t know about you but the information in this bulletin really concerns me. I know personally how autorun.inf can affect a computer. I recently received a digital picture frame (DPF) as a gift. It is a very nice one in that it can handle several different types of media and is even an MP3 player. When I connected it to my computer the first time, Windows went through the “new device found” routine. Windows found the device as a standard removable storage device. That was no big deal. However, the DPF has 128MB of internal storage and that storage held an autorun.inf file that referenced a trojan executable! Fortunately my anti-virus detected it and deleted the file before it could do damage. How many consumers do not have antivirus? How would the trojan affected their systems? That is a substantial risk in today’s technology environment!

I would highly recommend taking the steps outlined below to ensure that autorun.inf does not take down a critical system within your organization.

Thanks for reading & let’s continue to be good network citizens.

================================================

National Cyber Alert System

Technical Cyber Security Alert TA09-020A

Microsoft Windows Does Not Disable AutoRun Properly

Original release date: January 20, 2009

Last revised: –

Source: US-CERT

Systems Affected

* Microsoft Windows

Overview

Disabling AutoRun on Microsoft Windows systems can help prevent the spread of malicious code. However, Microsoft’s guidelines for disabling AutoRun are not fully effective, which could be considered a vulnerability.

I. Description

Microsoft Windows includes an AutoRun feature, which can automatically run code when removable devices are connected to the computer. AutoRun (and the closely related AutoPlay) can unexpectedly cause arbitrary code execution in the following situations:

* A removable device is connected to a computer. This includes, but is not limited to, inserting a CD or DVD, connecting a USB or Firewire device, or mapping a network drive. This connection can result in code execution without any additional user interaction.

* A user clicks the drive icon for a removable device in Windows Explorer. Rather than exploring the drive’s contents, this action can cause code execution.

* The user selects an option from the AutoPlay dialog that is displayed when a removable device is connected. Malicious software, such as W32.Downadup, is using AutoRun to spread. Disabling AutoRun, as specified in the CERT/CC Vulnerability Analysis blog, is an effective way of helping to prevent the spread of malicious code.

The Autorun and NoDriveTypeAutorun registry values are both ineffective for fully disabling AutoRun capabilities on Microsoft Windows systems. Setting the Autorun registry value to 0 will not prevent newly connected devices from automatically running code specified in the Autorun.inf file. It will, however, disable Media Change Notification (MCN) messages, which may prevent Windows from detecting when a CD or DVD is changed. According to Microsoft, setting the NoDriveTypeAutorun registry value to 0xFF “disables

Autoplay on all types of drives.” Even with this value set, Windows may execute arbitrary code when the user clicks the icon for the device in Windows Explorer.

II. Impact

By placing an Autorun.inf file on a device, an attacker may be able to automatically execute arbitrary code when the device is connected to a Windows system. Code execution may also take place when the user attempts to browse to the software location with Windows Explorer.

III. Solution

Disable AutoRun in Microsoft Windows

To effectively disable AutoRun in Microsoft Windows, import the following registry value:

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]

@=”@SYS:DoesNotExist”

To import this value, perform the following steps:

* Copy the text

* Paste the text into Windows Notepad

* Save the file as autorun.reg

* Navigate to the file location

* Double-click the file to import it into the Windows registry

Microsoft Windows can also cache the AutoRun information from mounted devices in the MountPoints2 registry key. We recommend restarting Windows after making the registry change so that any cached mount points are reinitialized in a way that ignores the Autorun.inf file. Alternatively, the following registry key may be deleted:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Once these changes have been made, all of the AutoRun code execution scenarios described above will be mitigated because Windows will no longer parse Autorun.inf files to determine which actions to take. Further details are available in the CERT/CC Vulnerability Analysis blog. Thanks to Nick Brown and Emin Atac for providing the workaround.

IV. References

* The Dangers of Windows AutoRun -

<http://www.cert.org/blogs/vuls/2008/04/the_dangers_of_windows_autorun.html>

* US-CERT Vulnerability Note VU#889747 -

<http://www.kb.cert.org/vuls/id/889747>

* Nick Brown’s blog: Memory stick worms -

<http://nick.brown.free.fr/blog/2007/10/memory-stick-worms>

* TR08-004 Disabling Autorun -

<http://www.publicsafety.gc.ca/prg/em/ccirc/2008/tr08-004-eng.aspx>

* How to Enable or Disable Automatically Running CD-ROMs -

<http://support.microsoft.com/kb/155217>

* NoDriveTypeAutoRun -