Re: [Full-Disclosure] Silencing Windows File Protection
You're right, except that it's necessary to reboot for this to start working. Tested it on a Windows XP SP2 machine and received no warning after setting the appropiate registry value and rebooting. - Original Message - From: "Fixer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 08, 2004 10:14 PM Subject: [Full-Disclosure] Silencing Windows File Protection Hi all, In the past, the best way to bypass Windows File Protection (WFP) was to attempt to set it to the known registry value that would shut it down completely. This was the vector used by Code Red II and other forms of malware. This technique was effective until Microsoft changed this value to make it operating system and service pack specific, thus making it infeasible for general use. There exists, however, another mechanism for silencing, rather than shutting down, WFP. This mechanism represents an interesting flaw in the operation of WFP and has a variety of potential uses. While this is not an exploit in and of itself, it can potentially be used by various types of malware as a method for keeping access to a compromised machine or for installing additional malicious code such as backdoors, keyloggers, etc. Keep in mind that this, like other attacks against WFP, requires the attacker/malware/etc. to have administrator permissions on the target computer. This isn't an issue for malware that is exploiting a known vulnerability and then simply using this technique to hold on to that access. Details: In order to bypass WFP, it is necessary to navigate to the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon Contained within this key is the value SFCDisable. This value is of the DWORD type and can be set from 0 to 4. Setting it to 1 or 2 requires the use of a debugger and is not relevant to this discussion. When setting this value to 0, WFP operates normally. Setting this value to 4, however, produces a very interesting result. With this value, WFP is still enabled, but all notifications (including all Event Log entries) are suppressed. This allows for the replacement of critical system files with no warnings from Windows. Files that are protected by WFP are typically stored in two locations. The first location is the primary location of the file (c:\winnt\system32 for example). The second is the dllcache directory, which is a subdirectory of the system32 directory. The dllcache directory serves as a backup directory for all critical files that WFP protects. In the event that a critical file changes it is replaced from the copy in the dllcache directory. As such it is necessary to replace both the primary copy and the dllcache copy. Additionally it will be necessary to first delete the copy in the dllcache to ensure that the computer cannot simply replace the primary file with a copy from the dllcache. Execution Steps: In order to properly execute this, the following steps must be taken in precise order: + Set the value of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SFCDisable to 4 + Delete the target file in the dllcache directory + Delete the primary copy of the target file + Replace the dllcache and primary copies of the target file with the new copies. The order is irrelevant. + Set the value of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon to 0 (this step is optional) It should be noted that, according to Microsoft, WFP was designed as a system stability feature, not a security feature. In order to fix this problem it would be necessary to redesign the entire WFP architecture. Given that, Microsoft's official response was that the necessary solution would likely be implemented in Longhorn. As previously stated this is NOT an exploit by itself, simply a way to keep access once you've got it and maybe install some additional malicious code in the process. Miscellaneous Notes: + This process has been tested and verified under Windows 2000 SP4 and Windows XP SP2. + Using SFC /scannow will remove the altered files in the dllcache directory (but not in the primary directory) but it will not alert the administrator as to which files were altered. Additionally there will be the risk of causing software issues because of where SFC gets its replacement files from. + Replacing the original application in the dllcache will not result in WFP recognizing that a different application is in the primary location and copying the correct application into the primary location. Once the application has been deleted from both locations it appears that WFP does not track the application as part of its database from that point on. Hiya to all the H3 kennels out there... -fixer Sed Quis Custodiet Ipsos Custodes? ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosu
Re: [Full-Disclosure] RE: Norton AntiVirus Script Blocking Exploit -- Symantec's response
Here Symantec, much like Microsoft does very often, prefers to give a silly excuse instead of admitting their product needs to be fixed. I agree with you in that Script Blocking is supposed to block *any* script-based threats, without the need for any signatures. Obviously, that's not the case and Symantec won't admit Script Blocking has a hole. - Original Message - From: "Daniel Milisic" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, November 11, 2004 8:33 AM Subject: [Full-Disclosure] RE: Norton AntiVirus Script Blocking Exploit -- Symantec's response Hello, This is regarding my post on FD from a couple of days ago: Unfortunately it got bounced by Bugtraq. Norton AntiVirus 2004/2005 Scripting Vulnerability Pt.3 http://seclists.org/lists/fulldisclosure/2004/Nov/0160.html I slapped together a flash movie of the NAV Vulnerability in action so anyone interested can see for themselves without trashing a machine: http://64.5.53.205/navdemo.html (1.2MB, Flash plugin red'd; vnc2swf) This is a show featuring Norton AntiVirus getting deactivated and Script Blocking uninstalled by the VBScript code from my FD post. I don't have the bandwidth to host this file for long so if anyone wants to mirror feel free to do so. It was done on a slow VM and the WinXP splash screen takes a little while post-reboot so be patient, it's worth the wait. You'll see that Script Blocking gets *completely* uninstalled. As well, notice that Auto-Protect doesn't kick in until you click on the tray icon and launch the NAV console. By then, the 'Virus' had already launched quite some time before, as you can see in the cmd.exe window. Symantec's response goes something like: Yes, the exploit works but you have to be an administrator. That's ridiculous! Any customer who purchased Norton AntiVirus for their XP Home/Pro computer almost certainly *is* logged in as an Administrator. And in those situations, Script Blocking does a good job in blocking malicious JScript and VBScript... but *not* WMI in a .vbs (VBScript) file. Now, this shouldn't come as a surprise to anyone (especially Symantec), but NAV is aimed at the Home/SOHO market. By default, in the Windows XP OOBE (Out Of Box Experience) a Windows user *is* an administrator! So, the users of this product already meet the "administrator rights" requirement nicely. If the rare conscientious/paranoid user wanted to run with as a "Limited" User account, they would see how poorly NAV's update mechanism handles this scenario, so it's ironic and amusing they have chosen to take this position. Symantec tells users that "Script Blocking" is there to protect users in case they do something silly or get phished into running a script. There isn't any fine print and it's a blanket statement. The thing is, I demonstrated that Script Blocking doesn't protect the customer like it says it does. This is the whole point -- Script Blocking does not work as advertised. It's trivial for a Bad Guy to script around the limitations ScriptBlocking sets on the Windows Scripting Host. It's a joke. Regarding the signature detection; my demonstration code is one of many methods to wreak havoc using WMI. No, I will not point out all of them but my second FD post illustrates this... it's like plugging a hole in a dam. There are many ways to spin WMI to evade signature detection and accomplish the same goal. To summarize, I feel Symantec's response to this issue is disingenuous at best, and misleading at worst. In the end customers will either call them on it, or keep drinkin' the Kool-Aid... but at least the issue's out there for them to decide. Best Regards, Daniel Milisic __ Symantec is responding to a posting and an article that ran on public Web sites on November 3, 2004. The author of the article stated that his source, the poster, was able to create a VBS script that caused a minor denial of service by terminating the system tray icon for Symantec Norton AntiVirus as well as preventing the Auto-Protect pop-up alerts from displaying on the user’s system. Symantec would like to reiterate that the situation described is one of access rather than threat. The VBS scripts described can only be successfully run on the target system with administrator rights. To get a malicious script on a targeted system, the attacker requires “user assistance” by either enticing the targeted user to visit a location where the malicious file could be downloaded or have access to the target system to upload or transfer the malicious file. Script blocking, which is a function of Symantec Norton AntiVirus, assists its signature- based detection in identifying malicious scripts. The VBS script that has been referred to in the latest posting requires action on the part of an administrator to have any affect on the target system and to avoid detection by the
Re: [Full-Disclosure] dab@heise.de
Obviously this is usual, because the list is unmoderated... Either get a good AV or keep from clicking the executable attachments. ;) - Original Message - From: "Stephen Hunt" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 11, 2004 5:35 PM Subject: [Full-Disclosure] [EMAIL PROTECTED] Wow, 2nd day on this list and already a windows worm sent to it. Is this a regular occurrence? -Steve ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] dab@heise.de
May be the case, since many e-mail providers filter messages with known worms. Personally I hate this because I always want to handle my mail myself, but I understand it's useful for prone-to-click-attachments users. - Original Message - From: "Andrew Smith" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, November 12, 2004 2:25 PM Subject: Re: [Full-Disclosure] [EMAIL PROTECTED] Interesting, i haven't noticed any. I guess gmail is picking them up? On Fri, 12 Nov 2004 12:44:44 -0300, Jeff Donahue <[EMAIL PROTECTED]> wrote: Obviously this is usual, because the list is unmoderated... Either get a good AV or keep from clicking the executable attachments. ;) - Original Message - From: "Stephen Hunt" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 11, 2004 5:35 PM Subject: [Full-Disclosure] [EMAIL PROTECTED] > Wow, 2nd day on this list and already a windows worm sent to it. > > Is this a regular occurrence? > > -Steve > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Why is IRC still around?
That's because the Internet is free and no one can control what survives on it. What survives isn't what is *ethical* but what is *useful*. And IRC is very useful for some people, so it's here to stay. The problem is not IRC; the problem is the misuse some people make of it. We cannot make knives dissapear, because they are useful; instead, we must get rid of people that uses knives to kill. - Original Message - From: "Danny" <[EMAIL PROTECTED]> To: "Mailing List - Full-Disclosure" <[EMAIL PROTECTED]> Sent: Friday, November 19, 2004 2:40 PM Subject: [Full-Disclosure] Why is IRC still around? Well, it sure does help the anti-virus (anti-malware) and security consulting business, but besides that... is it not safe to say that: 1) A hell of a lot of viruses/worms/trojans use IRC to wreck further havoc? 2) A considerable amount of "script kiddies" originate and grow through IRC? 3) A wee bit of software piracy occurs? 4) That many organized DoS attacks through PC zombies are initiated through IRC? 5) The anonymity of the whole thing helps to foster all the illegal and malicious activity that occurs? The list goes on and on... Sorry to offend those that use IRC legitimately (LOL - find something else to chat with your buddies), but why the hell are we not pushing to sunset IRC? What would IT be like today without IRC (or the like)? Am I narrow minded to say that it would be a much safer place? ...D ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
