Search results matching tags 'Cybercrime' and 'SMS'

Tidserv and MS10-015 – Symantec Security Response

cmosby — Wed, 17 Feb 2010 05:00:00 GMT

Tidserv and MS10-015

February 12th, 2010

Tags: Endpoint Protection (AntiVirus), Malicious Code, Security, Vulnerabilities & Exploits, Security Response

In the past, viruses and computer threats were created simply for the sake of it. Sometimes these threats would wipe your hard drive clean—just to let you know you’d been owned. This is not the case anymore; nowadays most of the threats we see are profit-oriented and try to keep a very low profile so that they aren't easily detectable by security software.

Backdoor.Tidserv does a very good job in that sense, especially with the latest version (TDL3), which uses an advanced rootkit technology to hide its presence on a system by infecting one of the low-level kernel drivers and then covering its tracks. While the rootkit is active there is no easy way to detect the infection, and because it goes so deep into the kernel, most users cannot see anything wrong in the system.

Most of the time the driver chosen by Tidserv to be infected is “atapi.sys,” but that may vary depending on the hardware configuration. One of the very things the infected driver does when it is loaded by the operating system is to retrieve critical API addresses so that it can allocate memory to load the actual malicious code:

These APIs are retrieved via hard-coded relative virtual addresses (RVAs) into the kernel module, which are calculated at the infection time. Microsoft recently released a kernel patch that addressed a non-related issue (MS10-015 / KB977165), which updates the kernel modules. They also released a blog about blue screen issues after applying this patch.

What seems to have happened in Tidserv's case is that after this update, the RVAs for the above mentioned APIs changed—therefore causing the infected drivers out there to call invalid addresses and, in turn, cause blue screens every time Windows boots up:

Even worse, because the infected driver is critical for system boot-up, Windows will not boot in Safe Mode either. However, there is still hope for the users who get stuck in this infinite loop of BSoD, in the sense that they are not required to reinstall everything from scratch, but only the infected driver (from a known, clean source). And, here is an example for the most commonly infected system driver, atapi.sys:

1. Boot from a clean source (e.g. Windows CD)

2. Locate the infected partition, which is normally the boot partition

3. Replace atapi.sys in \%Windir%\system32\drivers with the clean backup copy

4. Reboot

Here's a list with the most common driver names infected by the rootkit, which can be used in the above process:

atapi.sys

iastor.sys

idechndr.sys

ndis.sys

nvata.sys

vmscsi.sys

We are aware that the blue screens may be caused by other good or bad kernel mode applications that were relying on hard coded addresses, but Tidserv is one of the most prevalent threats that may cause this problem. Symantec detects these infected drivers on disk as Backdoor.Tidserv!inf, but recommends that the files are replaced manually, since attempting to remove the file automatically may render the system unbootable.

In conclusion, it seems that no matter how complex and stealthy a threat may be, it may be given away by such a small thing as a software update. This should be a lesson for the authors that developed the rootkit—but more importantly for the victims that fell for the back door.

Advance Notification for Out-of-Band Bulletin Release - The Microsoft Security Response Center

cmosby — Thu, 21 Jan 2010 05:00:00 GMT

Advance Notification for Out-of-Band Bulletin Release

Today we issued our Advanced Notification Service (ANS) to advise customers that we will be releasing MS10-002 tomorrow, January 21^st, 2010. We are planning to release the update as close to 10:00 a.m. PST (UTC -8) as possible. This is a standard cumulative update, accelerated from our regularly scheduled February release, for Internet Explorer with an aggregate severity rating of Critical. It addresses the vulnerability related to recent attacks against Google and small subset of corporations, as well as several other vulnerabilities. Once applied, customers are protected against the known attacks that have been widely publicized. We recommend that customers install the update as soon as it is available. For customers using automatic updates, this update will automatically be applied once it is released.

Today we also updated Security Advisory 979352 to include technical details addressing additional customer questions.

The updated Security Advisory includes guidance in relation to reports of proof of concept (POC) code that bypasses Data Execution Prevention (DEP) and additional information on the exploitability of, and mitigations and workarounds for, Microsoft products that use mshtml.dll.

Based on our comprehensive monitoring of the threat landscape, we continue to see only limited attacks. To date, the only successful attacks that we are aware of have been against Internet Explorer 6.

We continue to recommend that customers update to Internet Explorer 8 to benefit from the improved security protection it offers.

Additional Technical Details Related to Security Advisory 979352

Data Execution Prevention (DEP) Bypass

There is a report of a new exploit that bypasses Data Execution Prevention (DEP). We have analyzed the Proof-of-Concept (POC) exploit code and have found that Windows Vista and later versions of Windows offer more effective protections in blocking the exploit due to the improved security protection offered by Address Space Layout Randomization (ASLR).

On Windows XP, which does not benefit from the improved security protection provided by ASLR, attacks using the DEP bypass techniques are likely to be more effective.

The DEP bypass exploit is not, at this time, publicly available and we have not seen it used in attacks.

Additional details on the DEP bypass exploit are provided in a Security Research and Defense Blog published today.

Microsoft E-Mail Products That Render using mshtml.dll Protected by Default

There have been reports that supported versions of Outlook, Outlook Express and Windows Live Mail are affected by the vulnerability in Security Advisory 979352.

For customers using the default configuration of all supported versions of Outlook, Outlook Express and Windows Live Mail the risk of exploit using Outlook as an attack vector is low. We are unaware of active exploit against supported versions of Outlook, Outlook Express or Windows Live.

By default, Outlook, Outlook Express and Windows Live Mail open HTML e-mail messages in the Restricted sites zone, which helps mitigate attacks seeking to exploit this vulnerability by preventing Active Scripting and ActiveX controls from being used. Additionally, Outlook 2007 uses a different component to render HTML e-mail, removing the risk of the exploit.

If customers have modified their default configuration to not run in Restricted sites zone, their environments will be in a less secure, more vulnerable, state.

Other products may also use the HTML rendering engine for Internet Explorer and could expose this vulnerability. Any successful attack would require bypassing the default security mechanisms used by each individual application. Therefore customers who use these default application configurations may have reduced risk from being exploited through additional vectors.

Office Applications with Active Scripting Enabled Potentially Vulnerable

We are also aware that the vulnerability can be exploited by including an ActiveX control in a Microsoft Access, Word, Excel, or PowerPoint file. Customers would have to open a malicious file to be at risk of exploitation.

To prevent exploitation, we recommend that customers disable ActiveX Controls in Microsoft Office.

Detailed information on how to disable ActiveX Controls is included in the Security Advisory.

To be clear, applying the update for Internet Explorer addresses the issue across all products that may use mshtml.dll. Customers should install the update to be protected.

We continue to monitor the situation and will keep customers apprised of any changes to the situation or threat landscape through the Microsoft Security Response Center Blog.

Please join us Thursday, January 21 at 1:00 p.m. PST (UTC – 8) for a public webcast where we will present information on the bulletin and take customer questions. Registration information:

Date: Thursday Jan 21
Time: 1:00 p.m. PST (UTC -8)
Registration: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032440627

Thanks,

Jerry Bryant

*This posting is provided "AS IS" with no warranties, and confers no rights*

Anonymous comments are disabled