False positive on sfc.dll
Bojan was the primary handler on this one... We received a report that Symantec Antivirus was detecting a virus on sfc.dll, which is a component of Windows File Protection. At first, we were a little worried that a trojan was disabling the protection features, which would be a bad thing. However, it looks like this was a false positive and new signatures released today seems to have fixed the problem. This was occuring on Windows 2000 SP4 machines without the Security Rollup applied.
UPDATE
Just a short update about this problem. As we already wrote, Symantec removed detection for this file from their definitions.
However, the main reason why they added this detection is pretty interesting, so we decided to write a bit more about this, as we received some useful information from Symantec's security response team.
Basically, the sfc.dll file provides Windows 2000 and XP operating systems with a feature called System File Checker (SFC), which is part of Windows File Protection. Windows File Protection prevents programs from replacing critical Windows system files (you can find more information about WFP at http://support.microsoft.com/kb/222193).
As you can see, WFP makes it a bit more difficult for malware to replace Windows system files. The bad guys, however, found a way to circumvent SFC ? all they have to do is to "patch" the sfc.dll file (the patch actually only modifies 2 bytes!) and add an undocumented registry key.
According to Symantec, a lot of Infostealer Trojans modify the sfc.dll file, so they added detection for it. However, it looks like there might be some other, legitimate, reasons for this, so some people might have been caught with this false positive detection (when the system actually wasn't infected).
Symantec posted a knowledge base article about this, so if you were affected visit http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2006102011570548.
UPDATE
Just a short update about this problem. As we already wrote, Symantec removed detection for this file from their definitions.
However, the main reason why they added this detection is pretty interesting, so we decided to write a bit more about this, as we received some useful information from Symantec's security response team.
Basically, the sfc.dll file provides Windows 2000 and XP operating systems with a feature called System File Checker (SFC), which is part of Windows File Protection. Windows File Protection prevents programs from replacing critical Windows system files (you can find more information about WFP at http://support.microsoft.com/kb/222193).
As you can see, WFP makes it a bit more difficult for malware to replace Windows system files. The bad guys, however, found a way to circumvent SFC ? all they have to do is to "patch" the sfc.dll file (the patch actually only modifies 2 bytes!) and add an undocumented registry key.
According to Symantec, a lot of Infostealer Trojans modify the sfc.dll file, so they added detection for it. However, it looks like there might be some other, legitimate, reasons for this, so some people might have been caught with this false positive detection (when the system actually wasn't infected).
Symantec posted a knowledge base article about this, so if you were affected visit http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2006102011570548.
Keywords:
0 comment(s)
Analysis of botnet spamming trojan (SecureWorks)
The following article is a great analysis of a trojan that pumps out spam. There are some new techniques described that are very interesting. Great work by Joe Stewart and the folks at SecureWorks (recently merged with LURHQ). http://www.secureworks.com/analysis/spamthru/
Keywords:
0 comment(s)
New Internet Explorer and an old vulnerability
As you probably know by now, Microsoft yesterday released the final version of Internet Explorer 7; if you want to install it on your machine you can download it from http://www.microsoft.com/windows/ie/default.mspx. Microsoft also said that in couple of weeks this will be automatically pushed to all client machines through Windows Update, so if you still haven't tested your mission critical internal web applications with IE7, you better do it now.
Besides news about the final version of IE7, a lot of people are already talking about the first vulnerability for IE7, which was announced yesterday on various security mailing lists. The vulnerability is caused by an error in redirections handling with the "mhtml:" URI handler.
After analyzing this security vulnerability, we have to disappoint you ? it's nothing new. Actually, this vulnerability was announced way back in April this year for Internet Explorer 6 (http://secunia.com/advisories/19738). It is still not patched, so besides IE7, this vulnerability can be exploited in a fully patched IE6 installation as well.
So what's going on here, did Microsoft just used old code? Not really. The vulnerability exists in the MSXML ActiveX component which is actually part of Outlook Express (so it is installed on every machine as well).
The exploit uses a "double" redirection trick ? it will first create an Msxml2.XMLHTTP ActiveX object which is then used to retrieve a web page from the same server that the original web page is hosted on (one containing the exploit). This web page is actually just a redirection (302) which uses a mhtml: URI. This causes the ActiveX object to retrieve any other web page referenced by the mhtml: URI, which can be referenced from the original web page.
In other words, this exploit can be used by an attacker to possibly retrieve other data that your browser has access to. While stealing information like banking data is possible, our testing showed that only content of the web page can be retrieved by the attacker ? they can not steal your credentials and they can not retrieve that data unless you are logged in to your bank account at the same time when you visit the web page hosting the exploit.
It looks like Microsoft once again got caught into "ancient" bugs which were already present on the machine (we do wonder why this hasn't been fixed before though).
One thing worth noting is that Internet Explorer 7 has a native XMLHTTPRequest object implementation so theoretically it should be possible to disable the ActiveX object, but pages using it would have to be rewritten (hence support for the ActiveX object). Further testing will show if the native support implementation is also vulnerable ? we'll post new information as we get it.
Besides news about the final version of IE7, a lot of people are already talking about the first vulnerability for IE7, which was announced yesterday on various security mailing lists. The vulnerability is caused by an error in redirections handling with the "mhtml:" URI handler.
After analyzing this security vulnerability, we have to disappoint you ? it's nothing new. Actually, this vulnerability was announced way back in April this year for Internet Explorer 6 (http://secunia.com/advisories/19738). It is still not patched, so besides IE7, this vulnerability can be exploited in a fully patched IE6 installation as well.
So what's going on here, did Microsoft just used old code? Not really. The vulnerability exists in the MSXML ActiveX component which is actually part of Outlook Express (so it is installed on every machine as well).
The exploit uses a "double" redirection trick ? it will first create an Msxml2.XMLHTTP ActiveX object which is then used to retrieve a web page from the same server that the original web page is hosted on (one containing the exploit). This web page is actually just a redirection (302) which uses a mhtml: URI. This causes the ActiveX object to retrieve any other web page referenced by the mhtml: URI, which can be referenced from the original web page.
In other words, this exploit can be used by an attacker to possibly retrieve other data that your browser has access to. While stealing information like banking data is possible, our testing showed that only content of the web page can be retrieved by the attacker ? they can not steal your credentials and they can not retrieve that data unless you are logged in to your bank account at the same time when you visit the web page hosting the exploit.
It looks like Microsoft once again got caught into "ancient" bugs which were already present on the machine (we do wonder why this hasn't been fixed before though).
One thing worth noting is that Internet Explorer 7 has a native XMLHTTPRequest object implementation so theoretically it should be possible to disable the ActiveX object, but pages using it would have to be rewritten (hence support for the ActiveX object). Further testing will show if the native support implementation is also vulnerable ? we'll post new information as we get it.
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
Comments