Published
Jun 26 2019 11:25 PM
3,411
Views
First published on TechNet on Jan 15, 2006
By now many of you have heard that Symantec released a security advisory last Tuesday that reported its use of rootkit-like cloaking technology in its SystemWorks product. The Symantec use of rootkit-like cloaking raises the question of what exactly defines a “rootkit” and whether or not there is ever a justifiable reason to use cloaking. I’ll first describe Symantec’s cloaking and then I’ll move on to trying to answer these two questions.
SystemWorks includes a feature called Norton Protected Recycle Bin that serves as an extension of the standard Windows Recycle Bin, saving copies of deleted files that the standard Recycle Bin doesn’t capture such as those deleted by applications. The saved files store in a directory named NPROTECT that SystemWorks creates under the standard Windows Recycle Bin directory, RECYCLER, of each volume. Symantec was originally concerned that end-users might stumble across the directory, not realize its purpose, and inadvertently permanently delete the backups of their already deleted files. The cloaking therefore uses a file system filter driver to mask the presence the NPROTECT directories from Windows directory enumeration APIs.
I learned of the cloaking several months again when users of our RootkitRevealer rootkit detection tool sent us log files asking whether their was evidence of malware (others have posted logs in the Sysinternals forums). A little research showed that it was generally known that SystemWorks creates NPROTECT directories that show up as “false-positives” in RootkitRevealer scans.
After the Sony rootkit story died down I turned my attention to commercial use of rootkits, purchased a copy of SystemWorks and installed it. I deleted some files, ran RootkitRevealer, and verified that the NPROTECT directory was being cloaked:
On a whim I decided to see if the Symantec cloak had the same behavior as the Sony XCP rootkit. Sony’s rootkit only masked the directory from directory enumeration APIs, but allowed access to the directory if specified explicitly by name. To my amazement, Symantec’s cloak let me into the NPROTECT directory when I entered its full path into Explorer or a command prompt change-directory command. I confirmed that a security vulnerability similar to Sony’s exists in the cloaking by copying files into the directory and noting that they did not appear in the SystemWorks interface that displays the contents of the NPROTECT directories. I contacted Symantec and they quickly agreed to remove the cloaking altogether.
So does Symantec’s cloaking classify it as a rootkit? I arrived at my working definition for the word rootkit several years ago as:
Software that hides itself or other objects, such as files, processes, and Registry keys, from view of standard diagnostic, administrative, and security software.
My definition is based largely on the way I’ve seen the term used by developers of cloaking technologies, including those that frequent http://www.rootkit.com/ , the central gathering place of both cloaking and anti-cloaking developers. The only text on the subject, Hogland (founder of Rootkit.com) and Butler’s “Rootkits: Subverting the Windows Kernel”, has a definition similar to mine:
A rootkit is a set of programs and code that allows a permanent or consistent, undetectable presence on a computer.
Symantec disagrees with my definition, and presumably Hogland and Butler’s, because they feel that malicious intent has been attributed with the word through general use in the media and that aspect is missing from the definition. But if we turn to the Rootkit.com community for guidance intent is also absent from their usage: Hoglund has even recently argued in an article he posted on Rootkit.com that Sony was justified in its use of the XCP rootkit.
Despite the evidence I see to back my definition I’m willing to concede, especially after the Sony debacle, that malicious intent has been associated with the term. The security industry is just now debating a formal definition for the word so in the meantime I’ve agreed to use “rootkit-like” when discussing cloaking that’s intended to benefit the consumer rather than the software publisher (or music publisher, in the case of the Sony rootkit).
Symantec’s use of a rootkit technique is a great place to start examining the question as to whether there’s ever justifiable use of rootkit technology. I strongly believe that there is never a case for its use, and I’ve had several discussions with Dave Cutler, Senior Technical Fellow at Microsoft and the original architect of Windows NT, and he agrees unequivocally with my view.
The obvious risk rootkits present, which has been demonstrated by both Sony’s and Symantec’s implementation, is malware being able to hide beneath the cloak. Even if a vendor has ensured with certainty that that’s not possible, the cloak makes it impossible for a security administrator to ensure that the cloaked objects have correctly configured security, and if they consist of executable code, are updated with the latest security patches.
Another detrimental effect of cloaking is that it changes the way Windows operates, making it difficult or impossible for users and systems administrators to understand the behavior of modified systems and to diagnose issues that arise as a result of altered behavior. Cloaking can make it impossible to account for resource usage like disk space, memory, or CPU, to perform a complete inventory of a system, to understand incompatibilities between Windows or other software and the cloaked objects, and even to make a functional backup. As I said when originally discussing the Sony case, a cloaked driver that crashes a computer can cause a misdiagnosis of the problem and can be extremely difficult to remove or update.
If a software developer ever believes a rootkit is a necessary part of their architecture they should go back and re-architect their solution. Microsoft was faced with a predicament very similar to Symantec’s when they implemented Windows XP System Restore. Instead of cloaking the directory that stores restore points they create a directory in the root of each volume named System Volume Information and set permissions on it so that only the Local System account has access. Even power users that check the “Show hidden files and folders” and deselect “Hide protected operating system files” settings in Explorer cannot enter the directory and inadvertently delete their backup files. There are any number of non-cloaking approaches that Symantec could have chosen.
I hope that the publicity generated by the Sony and Symantec examples have sent a strong message to the software and music industries and that they follow Symantec’s lead by removing the use of rootkit techniques from their applications and avoiding them in the future.
Originally by Mark Russinovich on 1/15/2006 5:54:00 PM
Migrated from original Sysinternals.com/Blog
# re: Rootkits in Commercial Software
As it is well known Kaspersky Labs is using ADS in their AV product. ADS per se are not malicious, but they can be used in malicious way.
http://www.viruslist.com/en/weblog?weblogid=177727537
Also Mr. Greg Hoglund discovered that Blizzard is using warden client software in their WoW game, which IMHO is much bigger invasion of privacy than ADS or NPROTECT.
http://www.rootkit.com/blog.php?newsid=358
I believe that when developers are using "controversial" programming techniques, then they should be well documented and users must have the option to disable them.
1/15/2006 7:12:00 PM by denial
# re: Rootkits in Commercial Software
Just wonder... Would NAV ever scan the hidden NPROTECT directory?
1/15/2006 7:49:00 PM by william
# re: Rootkits in Commercial Software
It amazes me that a company that is as security oriented as Symantec would make such a basic mistake. To their credit, it sounds like they are much more responsible than Sony over the issue.
I see no reason technical or otherwise that this NPROTECT folder could not be under c:\Program Files\Symantec\NPROTECT as an unprotected folder. IMO it does not need cloaking of any kind beyond the "show the contents of this folder" afforded to Program Files.
Keep up the good work Mark.
Also, is it technically possible or feasible for Microsoft to prevent any software from creating a cloaked folder, and if so should pressure be applied to Microsoft to get serious about rootkit prevention?
Adam
1/15/2006 7:54:00 PM by Anonymous
# re: Rootkits in Commercial Software
At least they agreed to remove it right away with no fuss
1/15/2006 9:37:00 PM by Arlan
# re: Rootkits in Commercial Software
You have a point for OSs that have ACLs, however you are not required to install XP on an NTFS drive (I don't know the effect on System Restore), so you can have an insecure file system and if Norton wants to saturate as much as the market as possible, they have to be able to install and protect files on FAT drives.
Just an observation.
1/15/2006 10:08:00 PM by darkmane
# re: Rootkits in Commercial Software
Ok, that does it! I have debated this before but now it's official, I will now be looking for another corporate AV product to replace symantec on the 4000+ desktops i administer. Does anyone know of another good ("Reputable") product with the same amout of features as SAV 10 that is cheaper? I will tell symantec they should not expect any more 5-figure per year license payments from now on.
1/16/2006 12:25:00 AM by cb
# re: Rootkits in Commercial Software
What about Alternate Data Streams (ADS)? Functionallity built into the OS that allows files to exist on a system that can not be found with naitive tools? Yes, there are 3rd party tools (and perhaps MS distributes tools as well) that allow admins to know about ADS, but then again admins have RootkitRevealer to find "NPROTECT" too ;-)
So what's your stance on ADS?
1/16/2006 12:36:00 AM by Anonymous
# re: Rootkits in Commercial Software
The trouble is... Do you really think there are people care about this? Does this represent a REAL danger? Aren't there much larger and more seriour security holes than this?
I'm aware that articles on this subject are mostly because of your self promotion and earning money (and there's nothing wrong with that), but, please, go back to the roots - your articles about internals were genuinely adoreable.
P.S. NHF, please.
1/16/2006 2:45:00 AM by Goran Mitrovic
# re: Rootkits in Commercial Software
Even if cloaking itself does not constitute a full bloodied rootkit, the point is, unless the cloaking is airtight to the application or process to which it belongs, it can provide an umbrella of invisibility, under which all manner of malignant sofware can take root .
Sematic arguments are scant consolation.
1/16/2006 4:27:00 AM by ruy_lopez
# re: Rootkits in Commercial Software
"So what's your stance on ADS?"
I'm fine with the use of ADS because its a documented operating system feature.
1/16/2006 6:15:00 AM by Mark Russinovich
# re: Rootkits in Commercial Software
I think it is fine for Symantec to use this kind of prevention as long as they make it well-known that it's there and they include an easy way to enable/disable it--many people don't wander into the options, so on the main window would be best.
I'm very upset that they made this mistake. Pre-planted rootkits can be a BIG security hole if another hacker discovers their presence. They can use the rootkit that the user may "approve" of to give them full control over the computer. As a security programmer, I've always trusted Symantec the best when it comes to things like this. But it seems companies are taking things like this too lightly--at least they immediately agreed to get rid of it, but that was probably out of fear after seeing what happened to Sony.
1/16/2006 7:27:00 AM by TSA Admin
# re: Rootkits in Commercial Software
The logical consequence of your argument, Mark, leads directly to open source software. If admins are to have total clarity when it comes to the operation of their systems, it follows that transparent source code is necessary. You can't really demand transparency down to the level of the OS, then say, okay, from here on down to the architechture, opacity is fine. Which begs the question. Why do you persist with NT?
1/16/2006 7:38:00 AM by ruy_lopez
# re: Rootkits in Commercial Software
I don't follow your logic, Ruy. Rootkit techniques deliberately prevent reliable and thorough systems management. Use of documented functionality doesn't. It's not a question of open source vs closed source.
1/16/2006 8:33:00 AM by Mark Russinovich
# re: Rootkits in Commercial Software
"I see no reason technical or otherwise that this NPROTECT folder could not be under c:\Program Files\Symantec\NPROTECT as an unprotected folder."
No, no, no! The entire Program Files subtree should not be writable except by admins, and should only be written when installing an app. NPROTECT is a recycle bin extension. The natural place for that is in the Documents and Settings subtree, or in a separate folder created by Symantec and set with the appropriate permissions.
Looking at that screen shot, it appears that the files in the NPROTECT directory may not be segregated by user name. There may be a security hole where a file deleted by one user can be recovered by another user. I don't have Norton to try it though, and given that most users run as admins it probably doesn't matter much.
1/16/2006 8:36:00 AM by Anonymous
# re: Rootkits in Commercial Software
"Rootkit techniques deliberately prevent reliable and thorough systems management."
Intent wasn't in your definition.
Without the code, the documented functionality is built upon opaque structures, effectively a cloak.
But I think I know where you are coming from. To you the documentation seems adequate because you do in fact have access to the code. Or at least access to the coders.
To the average admin, proprietary software is like one big cloak. They are reliant upon the proprietors, and their insiders , to be guardians of the realm.
As an admin would you trust your systems management to be mediated in such a way? ;-)
1/16/2006 8:53:00 AM by ruy_lopez
# re: Rootkits in Commercial Software
But at least they can use standard diagnostic, administrative and security tools to observe the behavior and effect of applications that use documented operating system functionality.
1/16/2006 9:41:00 AM by Mark Russinovich
# re: Rootkits in Commercial Software
In response to the open source/closed source argument:
While I would love to see the day that MS make their source code public (and I don't believe that day will be far away) it has to be said that MS have made good efforts in making their OS transparent by providing a full set of symbols for public download along with debugging tools.
On the cloaking argument:
I have to agree with Mark here. While I agree with Greg H. that Sony and other companies have a right to take measures to protect their intellectual property I cannot see any reason why a cloaking technology would ever be needed to accomplish such a job. When software depends on its 'invisibility' for its security this usually means that it has *no security*.
1/16/2006 10:49:00 AM by lamie
# re: Rootkits in Commercial Software
To cb who was looking for a new Corporate AV.
My own experience in 2 differents large companies: Computer Associates Etrust.
CA bought Cheyenne in the late 90s, so their AV software is based on the old Cheyenne InoculateIT. The best. IMHO
1/16/2006 12:01:00 PM by P.V.
# re: Rootkits in Commercial Software
I just thought I would point out that you do NOT have to install norton protect with SAV it is an option and I am pretty sure you can uninstall that feature also through add/remove programs.
Now if it creates a security hole then it is a problem.
But to me that makes their "rootkit-like" behavior much more acceptable that Sony-BMG basically saying you can not use this CD unless you have our junk running on your PC and you will have no way of removing it.
1/16/2006 12:15:00 PM by Anonymous
# re: Rootkits in Commercial Software
For the person looking for an alternative to NAV, try Avast or F-Secure.
1/16/2006 1:20:00 PM by Anonymous
# re: Rootkits in Commercial Software
In regards to the open vs. closed source discussion, I'd just like to point out that rootkits exist for open source operating systems.
Open source software will not fix problems like these.
1/16/2006 1:25:00 PM by mpd
# re: Rootkits in Commercial Software
The purported intent of Symantec or anyone else that installs a rootkit on people's systems is irrelevant. Because once the presence of the rootkit (or any other vulnerability) becomes publicly known (and they always do, eventually) the hole on the system will be exploited by malicious people. To be willfully ignorant of the malicious potential of the hole they created on people's systems does nothing to cleanse their motives for placing it there.
1/16/2006 1:43:00 PM by Anonymous
# re: Rootkits in Commercial Software
So, if MS is opposed to these rootkit-like techniques why do they use them? Check out the "C:\WINDOWS\Downloaded Program Files" directory. Then open a command prompt and cd there. There are plenty of hidden exe files. I've just been waiting for someone to jump on this one.
1/16/2006 5:08:00 PM by Anonymous
# re: Rootkits in Commercial Software
So, if MS is opposed to these rootkit-like techniques why do they use them? Check out the "C:\WINDOWS\Downloaded Program Files" directory. Then open a command prompt and cd there. There are plenty of hidden exe files. I've just been waiting for someone to jump on this one.
1/16/2006 5:09:00 PM by Anonymous
# re: Rootkits in Commercial Software
Re: Downloaded Program Files, etc.
That's called a shell extension, not a rootkit, and is easily disabled.
1/16/2006 5:24:00 PM by Anonymous
# re: Rootkits in Commercial Software
"Then open a command prompt and cd there. There are plenty of hidden exe files."
I don't think I'd call that rootkit-like. Explorer does behave strangely in that folder, but any other file manager appears to show the full contents. Evidently, the API's are cooperative and will show what's there; explorer just acts a bit funny.
1/16/2006 5:32:00 PM by Anonymous
# re: Rootkits in Commercial Software
"I see no reason technical or otherwise that this NPROTECT folder could not be under c:\Program Files\Symantec\NPROTECT as an unprotected folder."
It's obvious that hidden recycle folder should exist on every logical disk, otherwise moving big files there would be too long etc.
"C:\WINDOWS\Downloaded Program Files"
It's just a usual folder with "system" attribute. Check the “Show hidden files and folders” and deselect “Hide protected operating system files” settings in Explorer as it written in the article.
1/16/2006 5:50:00 PM by MASTAN
# re: Rootkits in Commercial Software
So - Those who understand the arguments are all agreed...
Rootkits = Bad
So, What should be done about it - what do we think the OS makers (regardless of whatever form of source disclosure they prefer) should be encourage to do to restrict potentially malicious activities.
Mark - Do you think there are effective ways to "lock" the places where the registry hooks and bad-boy filter drivers are inserted now without affecting the applications we want to run?
1/16/2006 6:00:00 PM by J a m e s
# re: Rootkits in Commercial Software
Hello Mark.
By technical view, Filemon & Regmon 7.xx do some thing:
1.Using NtLoadDriver and the value of registry "LegacyDriver", the monitor driver can't see in the service list.
2. Dynamic Extract from PE Resource & "Erase on Load", like the stealth trojan behavior.
My question is "Are They Rootkit-like Program?".
Thanks.
Kuon@chroot.org
1/17/2006 12:55:00 AM by Kuon
# re: Rootkits in Commercial Software
No, Filemon and Regmon don't hide their loaded drivers from view of standard driver enumeration utilities.
1/17/2006 5:51:00 AM by Mark Russinovich
# re: Rootkits in Commercial Software
@james
I don't think there's any way for the OS to stop rootkits anymore than they can stop other forms of malware.
We really need two things: smarter users and better programming. I'm not holding my breath waiting for the former.
1/17/2006 8:54:00 AM by mpd
# re: Rootkits in Commercial Software
I'm glad you've pointed this out, Mark. I've known for years that Norton SystemWorks does this with the Recycle bin. I stopped using any of their products years ago and this was one of the reasons. I had SystemWorks installed once, for about a week, 10 years ago and it behaved in this way at that time. Plus it sucked up most of the available system resources. Gee, thanks.
I've come to loathe and avoid ALL things Symantec. They have some of the most bloated, unhelpful and easily broken software out there. In fact, I could argue that most of the crap that they sell is broken from the moment it's installed, not to mention that it's ridculously expensive. There are many FREE and much lower cost programs out there that are far more effective. Plus they have almost zero drain on system resources comparatively and don't impact system performance the way that Symantec software does.
I've been actively helping companies, that I consult for, to ween themselves off of their Symantec dependencies. They've all been happier as a result.
As for the System Volume Information directory, it is possible to access it on FAT32 drives and there is a bug which exists on NTFS volumes that allows you to access the folder. If you go to the Sharing and Security properties tab for the folder, Share the folder and click "Ok", it will give you an error and close the dialog. However, once you've done this, you now have access to the folder...
Keep up the good work Mark!
Thanks again.
1/17/2006 10:25:00 AM by Dr. Zhivago
# re: Rootkits in Commercial Software
For me, the root kit debacle by Sony and others is evidence of unclear thinking. By hiding certain files with a root kit rather than standard OS mechanisms you're simply escalating the [non-]hiddeness of the file. It becomes an arms race between the revealer and hider software to see whether a file will be visible, with your computer as the battleground. This arms race is not well defined and because it's not well defined it will make your computer unstable. There is no justification for bypassing standard OS mechanisms. The whole point of an OS is to standardise and moderate access to the hardware. Making a root kit hack well known does not obviate this. How would you like 10,000 companies all with there own root kit hacks on the battleground that is your computer?
1/17/2006 10:59:00 AM by Anonymous
# re: Rootkits in Commercial Software
I have a \RECYCLER\NPROTECT folder on one of my (non-system) drives. I uninstalled Norton SystemWorks about 6 months ago, and have recently reinstalled Windows.
The problem I am facing is that the folder appears to contain 3,441 files totalling 560MB, and none of them can be deleted. I don't know if this is related to Symantec's rootkit-like technology, but if Explorer is correct and I really am losing 560MB of space then I'd like it back.
---------------------------
Error Deleting File or Folder
---------------------------
Cannot delete file: Cannot read from the source file or disk.
---------------------------
OK
---------------------------
1/17/2006 11:57:00 AM by luv-snail
# re: Rootkits in Commercial Software
Yeah luv-snail, I had that exact same problem too. A while ago, I figured out that Symantec rootkit-ed that directory so I turned the feature off right away. I wasn't able to delete a bunch of the files, but they're only taking up around 68 MB for me, so I really don't care too much. I tried everything that I could think of to remove them, but nothing seems to work.
They don't seem to exist although I can see them......
1/17/2006 3:00:00 PM by Aaron
# re: Rootkits in Commercial Software
I was once again thinking about why I couldn't delete those files that I mentioned earlier, and I think I understand why.
The files that I can't delete have no extension, but do have a dot (.) in their name.
For example: "00039625." (without quotes)
I think that's why Windows is having trouble finding them. When I tried to make a file called "test." in a separate directory, Windows automatically deleted the dot, making it named "test"
Anyways, I think I'll play around with this. I'm betting that there's a way to delete them.
1/17/2006 3:14:00 PM by Aaron
# re: Rootkits in Commercial Software
Eight years ago I decided to trust with my money Symantec and purchased a Norton subscripton thinking that I will get the protection needed for my system.
Four months later a small box opened in the middle of my desktop and I found myself chatting with someone from brazil who gained access on my computer.
I got precious advice regarding the security of my system "for free" from a person who beat Norton's so-called protection to my system.
Then is when I realized Symantec was just a scam, they got my money in exchange for nothing. Their product did not delivered.
Could have been that so-called "almost-rootkit" have facilitated that brazilian guy access to my system? I tend to think it is possible now in the light of the truth.
It has been 8 years I have removed Norton from my systems and keeping advising everyone to avoid the products of that company.
Lately, the meaning of "commercial software" looks more like: pay for empty promises. Could the EULA of this kind of sofware mention "you are not having the right to held us responsible of this n that"? Most probably..
Same for Microsoft Windows: you "pay" for the software and become an instant Microsoft Windows "tester" keeping up with the good works of patching, updating and hey why not? pay for getting technical support for a product you spent money on.
1/17/2006 3:36:00 PM by Anonymous
# re: Rootkits in Commercial Software
Dr. Zhivago:
The easiest way to get access to 'system volume information' is just to to give yourself full control over the folder. The OS won't block you from adding administrator accounts to the list of authorized users.
Aaron:
I've found it's possible to whack files with invalid names by using a sector editor to alter the filenames to something valid. In my case, I accidentally created 'nul.png', which Windows kept mistaking for the nul device whenever I tried to delete it. What I finally did to get rid of nul.png was use Disk Explorer (an NTFS-aware sector editor) to rename the 'file' to 'nxx.png' and then deleted it normally.
1/17/2006 10:46:00 PM by Sum Gai
# re: Rootkits in Commercial Software
To Sum gai:
Hmm, good idea. I'm in the middle of writing a simple program that attempts to rename the files.
I'll see how that works out...I wasn't able to finish it yesterday due to homework.
1/18/2006 6:27:00 AM by Aaron
# re: Rootkits in Commercial Software
I can confirm that the NPROTECT files I am unable to delete also end in a dot with no extension, so I think you've hit the nail on the head there, aaron.
Let us know if you manage to get that program working.
1/18/2006 9:16:00 AM by luv-snail
# re: Rootkits in Commercial Software
This program works to delete invalid files and folders: http://www.purgeie.com/delinv/index.htm
1/18/2006 10:35:00 AM by Dr. Zhivago
# re: Rootkits in Commercial Software
Why then is Microsoft using the same techniques? On Windows XP, try emptying your "Temporary Internet Files" using the approved dialog, then go to the folder using Windows Explorer, and delete all of its contents. Now use the Properties dialog of the folder and see how much space the folder is still using! The culprit is the IE cache, contained in a subfolder called "Content.IE5" and numerous other subfolders of this folder. The only way I have ever found to expose the folder directly in Windows Explorer is to type the actual path into the locaton bar; albeit the folder does show up by using "dir" at a command prompt.
1/18/2006 12:41:00 PM by Anonymous
# re: Rootkits in Commercial Software
Ok, I haven't got it working so far, but being busy with college classes, I haven't had much time to work on it.
I've got the code written, but the inital run didn't work. I'm gonna change something and try again.
~Aaron~
1/18/2006 12:41:00 PM by Aaron
# re: Rootkits in Commercial Software
Ok I think I got it!
The solution came from microsoft, actually, from this link
http://support.microsoft.com/default.aspx?scid=kb;en-us;320081
Anyways, I got my program to work using the same strategy, since there were a bunch of the files and I'm not really sure how to do a wildcard thing with Microsoft's instructions, even though it MIGHT be possible.
Here's a link to a zip file with source code and binary:
http://awebs.dyndns.org/ExtensionRemover.zip
I'll also try to paste the source code below, but I don't know how it will work out. Anyways, you can just try to follow Microsoft's instructions, or use my program, whatever you want. Oh, and I can't guarantee that the program will work correctly. I slapped it together rather fast, but it worked for me. It will rename all files to .dud extensions. Make sure you don't have files with duplicate names, (like test.acc and test.wps) or they might get overwritten. It will prompt you for the directory at run time, and will prompt for confirmation once you enter one.
Source code:
//---------------------------------------------------------------------------
// i had to remove the angle brackets and replace with quotes to post this onthe blog, try changing them back if quotes don't work
#include "windows.h"
#include "iostream.h"
#include "stdlib.h"
#include "string.h"
bool RenameFile(char*, char*);
bool ChangeExtension(char*);
//---------------------------------------------------------------------------
int main(int argc, char* argv[])
{
char folder[MAX_PATH];
char choice;
char newFileName[MAX_PATH];
char oldFileName[MAX_PATH];
char searchFolder[MAX_PATH];
// prompt for folder
cout << "Enter the FULL PATH of the folder that contains the files with the extensions you want to change.\n\n\n";
cin.getline(folder, MAX_PATH);
// add ending / if user didnt enter it
int folderLength = strlen(folder);
if (folderLength - 1 >= 0){
if (folder[folderLength-1] != '\\'){
if (folderLength + 1 < MAX_PATH){
strcat(folder,"\\");
}else{
cout << "\n\nError, exceeded MAX_PATH number of characters for path.\n";
system("Pause");
return 0;
}
}
}
// get confirmation
cout << "\n\nOk, so you want to change all file extensions in the folder \"" << folder << "\" to \".dud\"?\n(y/n)?";
cin >> choice;
strcpy(searchFolder, folder);
// add * to path so windows searches for all files
if (folderLength + 1 < MAX_PATH){
strcat(searchFolder,"*");
}else{
cout << "\n\nError, exceeded MAX_PATH number of characters for path.\n";
system("Pause");
return 0;
}
// if user confirmed rename,
if ((choice == 'y') || (choice == 'Y')){
WIN32_FIND_DATA foundFileData; // holds found file info
// attempt to find the first file
HANDLE hFindHandle = FindFirstFile(searchFolder, &foundFileData);
// if it is not a directory
if (foundFileData.dwFileAttributes != FILE_ATTRIBUTE_DIRECTORY){
strcpy(newFileName, folder);
strcat(newFileName, foundFileData.cFileName);
strcpy(oldFileName, "\\\\?\\");
strcat(oldFileName, folder);
strcat(oldFileName, foundFileData.cFileName);
if (ChangeExtension(newFileName)){
cout << "\n\n" << oldFileName << " --> " << newFileName << "---" << flush;
if (RenameFile(newFileName, oldFileName)){
cout << "Success!" << endl;
}else{
cout << "Failure..." << endl;
}
}else{
cout << "!!Did not rename " << oldFileName << endl;
}
}
// loop for all the rest of the files
while (FindNextFile(hFindHandle, &foundFileData)){
if (foundFileData.dwFileAttributes != FILE_ATTRIBUTE_DIRECTORY){
strcpy(newFileName, folder);
strcat(newFileName, foundFileData.cFileName);
strcpy(oldFileName, "\\\\?\\");
strcat(oldFileName, folder);
strcat(oldFileName, foundFileData.cFileName);
//oldFileName[strlen(oldFileName) - 1] = '\0';
if (ChangeExtension(newFileName)){
cout << oldFileName << " --> " << newFileName << "---" << flush;
if (RenameFile(newFileName, oldFileName)){
cout << "Success!" << endl;
}else{
cout << "Failure..." << endl;
}
}else{
cout << "!!Did not rename " << oldFileName << endl;
}
}
}
// close search handle
FindClose(hFindHandle);
}else{
cout << "\n\nOk, no action has been taken.\n";
}
system("Pause");
return 0;
}
//---------------------------------------------------------------------------
bool RenameFile(char* dest, char* src){
if (CopyFile(src, dest, false)){
if (DeleteFile(src)){
return true;
}else{
return false;
}
}else{
return false;
}
}
//---------------------------------------------------------------------------
bool ChangeExtension(char* file){
int length = strlen(file);
int counter;
for (counter = length - 1; counter >= 0; counter--){
if (file[counter] == '.'){
break;
}
}
if (counter >= 0){
file[counter] = '\0';
if (strlen(file) + 3 < MAX_PATH){
strcat(file, ".dud");
return true;
}else{
return false;
}
}else{
return false;
}
}
//---------------------------------------------------------------------------
1/18/2006 1:29:00 PM by Aaron
# re: Rootkits in Commercial Software
I find that many thing are done in the name of greed!!!
You can catch a cor-pirates attention. but to make them change you need to practically nuke them from the face of the planet!!!
Law suites they understand. And are stocked with large hi budget legal departments!! Laws they also understand. They know if you grease enough palms you can get any law made to tailored specs in their favour.
The cor-pirates use the peon consumer as profit fodder and that only is how they see you!!!
Beat them over the head like we have only has temporary effects!!
They know the consumer peons have short memories and will strike again more insidiously then before!!!
1/18/2006 2:13:00 PM by Anonymous
# re: Rootkits in Commercial Software
Hi Mark, I fully agree with your views. I have a question that doesn't seem obvious to me. Why does Microsoft provide the ability for developers to be able to alter the OS (i.e. other peoples' OS) at such a fundamental level? If they wanted to eliminate the capability for rootkits to exist surely a patch would cause this whole controversy to evaporate. As others have pointed out, the OS should be standard. Also, where would we be if every piece of software wanted a piece of the same action in the same way. (We already have something like that already with the huge amount of services and user agents now being installed and permanently running to support applications that are only used occasionally.) Would it make sense for Microsoft to eliminate the capability for rootkits to hook in?
1/18/2006 5:20:00 PM by Anonymous
# re: Rootkits in Commercial Software
Great work on rootkits, Mark, but, like the anti-adware companies who have removed listings for companies that either threaten or pay them, you've sold out! To call a rootkit "rootkit-like" when it is from a commercial vendor is another case of not being willing to call a spade a spade. By being "willing to concede" your definition of a rootkit, you've conceded much more than that.
It is MY computer! No one has a right to hide something on it without clearly asking my permission and getting explicit approval to do so. For instance, parental controls would ask for and get such permission.
But the real point of my comment is to say that if Dave Cutler unequivocally agrees with you about there being no valid reason for cloaking, Dave Cutler is the guy who can end rootkits once and for all.
You can read my comments about it on my blog at http://www.dalepreston.com/Blog/2005/04/rootkits-and-hooks.html .
Since the chain of hooks is maintained internally by Windows, it would be trivial to expose that chain in a read-only fashion. Then each hook in the chain of hooks, for each type of hook, could be compared to a database of known and expected hooks. Exceptions would raise flags. That would spell the end of rootkits as we know them today.
My guess is that it would take a developer who understood the code for managing the chains of hooks about 8 hours to develop API methods to expose them. Add about 500 hours of testing, QA, and documentation, another 500 hours for developing and testing the deployment process for the patch.
Assuming that the average costs per man-year for all the teams involved is about $120,000.00, then you get a price for completely eliminating rootkits as we know them today of about $60,000. Talk to your buddy Dave Cutler about that!
1/20/2006 8:18:00 PM by Dale Preston
# re: Rootkits in Commercial Software
Microsoft moved to contain the problem in Vista on x64:
Digital Signatures for Kernel Modules on x64-based Systems Running Windows Vista .
According to this article at OSROnline , this would indirectly force developers to acquire a Verisign certificate. To my views, it could stop/halt the development of many useful utilities that extensively employ kernel drivers like some from SysInternals , Rightmark , Daemon Tools and many others.
1/22/2006 9:22:00 AM by Sébastien Mouren
# re: Rootkits in Commercial Software
Another annoying aspect of Symantec's AV products is their hobbling of WinDbg. I recently needed to debug a driver problem on a production machine being used by a beta tester (brave soul). Unfortunately, I had to remove the Symantec software in order to use WinDbg. I'm guessing that crippling support for kernel debugging was a deliberate move by Symantec to make it more difficult for people to reverse engineer their product. However, in my book it's not okay to cripple services that I might use to conduct legitimate, unrelated work on my computer. Anyone else find this annoying?
1/25/2006 4:03:00 PM by Chris Russell
# re: Rootkits in Commercial Software
Mark
I wonder if symantec do not do something similar for the quarentine emails/files detected by their antivirus
1/27/2006 10:55:00 PM by NotAvailable
# re: Rootkits in Commercial Software
I always find ideas like yours are great correct, very insightful enough but still don't understand why always wonder ?
1/29/2006 10:15:00 AM by Anonymous
# re: Rootkits in Commercial Software
CB, you may be overreacting. I'll assume you're using SAVCE, especially for 4000+ users.
NProtect is part of Norton SystemWorks, not SAVCE.
2/9/2006 9:37:00 AM by ConQuer0r
# re: Rootkits in Commercial Software
For those with \RECYCLER\NPROTECT problems, try these, copied from a Langalist newsletter;
http://www.softwarepatch.com/software/moveonboot.html
http://ccollomb.free.fr/unlocker
These, and others like them, should be able to delete the files in quesiton. To find others, google it.
2/9/2006 9:49:00 AM by ConQuer0r
# re: Rootkits in Commercial Software
Nice write-up, but man, this stuff gets gnarley.
(And I thought that watching 24 hours of TV straight was bad
http://www.24HoursOfTV.com)
2/24/2006 4:44:00 PM by b1-66er
# re: Rootkits in Commercial Software
Mark,
I appreciate the time and effort you put into writing this up for the Internet's viewing pleasure. Your Winternals/Sysinternals applications have been a great value to me in my personal computing for a long time, and I expect they will be for as long as I use them.
Reading through your blog is also helping me to gain a deeper understanding of this field, and that is definitely a nice change. I'm too used to reading things written at an elementary level.
Thanks!
5/29/2006 8:38:00 PM by Garrett from Phoenix,AZ
# re: Rootkits in Commercial Software
Why you don't publish my posts????
7/19/2006 2:00:00 PM by Poorguy
# re: Rootkits in Commercial Software
Huh! eTrust Antivirus version 7.0.139 has files hidden from the Windows API too!
7/26/2006 9:21:00 PM by Anonymous
# re: Rootkits in Commercial Software
good article. teh comments were fun to read.
10/2/2006 10:01:00 AM by Order Taking
By now many of you have heard that Symantec released a security advisory last Tuesday that reported its use of rootkit-like cloaking technology in its SystemWorks product. The Symantec use of rootkit-like cloaking raises the question of what exactly defines a “rootkit” and whether or not there is ever a justifiable reason to use cloaking. I’ll first describe Symantec’s cloaking and then I’ll move on to trying to answer these two questions.
SystemWorks includes a feature called Norton Protected Recycle Bin that serves as an extension of the standard Windows Recycle Bin, saving copies of deleted files that the standard Recycle Bin doesn’t capture such as those deleted by applications. The saved files store in a directory named NPROTECT that SystemWorks creates under the standard Windows Recycle Bin directory, RECYCLER, of each volume. Symantec was originally concerned that end-users might stumble across the directory, not realize its purpose, and inadvertently permanently delete the backups of their already deleted files. The cloaking therefore uses a file system filter driver to mask the presence the NPROTECT directories from Windows directory enumeration APIs.
I learned of the cloaking several months again when users of our RootkitRevealer rootkit detection tool sent us log files asking whether their was evidence of malware (others have posted logs in the Sysinternals forums). A little research showed that it was generally known that SystemWorks creates NPROTECT directories that show up as “false-positives” in RootkitRevealer scans.
After the Sony rootkit story died down I turned my attention to commercial use of rootkits, purchased a copy of SystemWorks and installed it. I deleted some files, ran RootkitRevealer, and verified that the NPROTECT directory was being cloaked:
On a whim I decided to see if the Symantec cloak had the same behavior as the Sony XCP rootkit. Sony’s rootkit only masked the directory from directory enumeration APIs, but allowed access to the directory if specified explicitly by name. To my amazement, Symantec’s cloak let me into the NPROTECT directory when I entered its full path into Explorer or a command prompt change-directory command. I confirmed that a security vulnerability similar to Sony’s exists in the cloaking by copying files into the directory and noting that they did not appear in the SystemWorks interface that displays the contents of the NPROTECT directories. I contacted Symantec and they quickly agreed to remove the cloaking altogether.
So does Symantec’s cloaking classify it as a rootkit? I arrived at my working definition for the word rootkit several years ago as:
Software that hides itself or other objects, such as files, processes, and Registry keys, from view of standard diagnostic, administrative, and security software.
My definition is based largely on the way I’ve seen the term used by developers of cloaking technologies, including those that frequent http://www.rootkit.com/ , the central gathering place of both cloaking and anti-cloaking developers. The only text on the subject, Hogland (founder of Rootkit.com) and Butler’s “Rootkits: Subverting the Windows Kernel”, has a definition similar to mine:
A rootkit is a set of programs and code that allows a permanent or consistent, undetectable presence on a computer.
Symantec disagrees with my definition, and presumably Hogland and Butler’s, because they feel that malicious intent has been attributed with the word through general use in the media and that aspect is missing from the definition. But if we turn to the Rootkit.com community for guidance intent is also absent from their usage: Hoglund has even recently argued in an article he posted on Rootkit.com that Sony was justified in its use of the XCP rootkit.
Despite the evidence I see to back my definition I’m willing to concede, especially after the Sony debacle, that malicious intent has been associated with the term. The security industry is just now debating a formal definition for the word so in the meantime I’ve agreed to use “rootkit-like” when discussing cloaking that’s intended to benefit the consumer rather than the software publisher (or music publisher, in the case of the Sony rootkit).
Symantec’s use of a rootkit technique is a great place to start examining the question as to whether there’s ever justifiable use of rootkit technology. I strongly believe that there is never a case for its use, and I’ve had several discussions with Dave Cutler, Senior Technical Fellow at Microsoft and the original architect of Windows NT, and he agrees unequivocally with my view.
The obvious risk rootkits present, which has been demonstrated by both Sony’s and Symantec’s implementation, is malware being able to hide beneath the cloak. Even if a vendor has ensured with certainty that that’s not possible, the cloak makes it impossible for a security administrator to ensure that the cloaked objects have correctly configured security, and if they consist of executable code, are updated with the latest security patches.
Another detrimental effect of cloaking is that it changes the way Windows operates, making it difficult or impossible for users and systems administrators to understand the behavior of modified systems and to diagnose issues that arise as a result of altered behavior. Cloaking can make it impossible to account for resource usage like disk space, memory, or CPU, to perform a complete inventory of a system, to understand incompatibilities between Windows or other software and the cloaked objects, and even to make a functional backup. As I said when originally discussing the Sony case, a cloaked driver that crashes a computer can cause a misdiagnosis of the problem and can be extremely difficult to remove or update.
If a software developer ever believes a rootkit is a necessary part of their architecture they should go back and re-architect their solution. Microsoft was faced with a predicament very similar to Symantec’s when they implemented Windows XP System Restore. Instead of cloaking the directory that stores restore points they create a directory in the root of each volume named System Volume Information and set permissions on it so that only the Local System account has access. Even power users that check the “Show hidden files and folders” and deselect “Hide protected operating system files” settings in Explorer cannot enter the directory and inadvertently delete their backup files. There are any number of non-cloaking approaches that Symantec could have chosen.
I hope that the publicity generated by the Sony and Symantec examples have sent a strong message to the software and music industries and that they follow Symantec’s lead by removing the use of rootkit techniques from their applications and avoiding them in the future.
Originally by Mark Russinovich on 1/15/2006 5:54:00 PM
Migrated from original Sysinternals.com/Blog
# re: Rootkits in Commercial Software
As it is well known Kaspersky Labs is using ADS in their AV product. ADS per se are not malicious, but they can be used in malicious way.
http://www.viruslist.com/en/weblog?weblogid=177727537
Also Mr. Greg Hoglund discovered that Blizzard is using warden client software in their WoW game, which IMHO is much bigger invasion of privacy than ADS or NPROTECT.
http://www.rootkit.com/blog.php?newsid=358
I believe that when developers are using "controversial" programming techniques, then they should be well documented and users must have the option to disable them.
1/15/2006 7:12:00 PM by denial
# re: Rootkits in Commercial Software
Just wonder... Would NAV ever scan the hidden NPROTECT directory?
1/15/2006 7:49:00 PM by william
# re: Rootkits in Commercial Software
It amazes me that a company that is as security oriented as Symantec would make such a basic mistake. To their credit, it sounds like they are much more responsible than Sony over the issue.
I see no reason technical or otherwise that this NPROTECT folder could not be under c:\Program Files\Symantec\NPROTECT as an unprotected folder. IMO it does not need cloaking of any kind beyond the "show the contents of this folder" afforded to Program Files.
Keep up the good work Mark.
Also, is it technically possible or feasible for Microsoft to prevent any software from creating a cloaked folder, and if so should pressure be applied to Microsoft to get serious about rootkit prevention?
Adam
1/15/2006 7:54:00 PM by Anonymous
# re: Rootkits in Commercial Software
At least they agreed to remove it right away with no fuss
1/15/2006 9:37:00 PM by Arlan
# re: Rootkits in Commercial Software
You have a point for OSs that have ACLs, however you are not required to install XP on an NTFS drive (I don't know the effect on System Restore), so you can have an insecure file system and if Norton wants to saturate as much as the market as possible, they have to be able to install and protect files on FAT drives.
Just an observation.
1/15/2006 10:08:00 PM by darkmane
# re: Rootkits in Commercial Software
Ok, that does it! I have debated this before but now it's official, I will now be looking for another corporate AV product to replace symantec on the 4000+ desktops i administer. Does anyone know of another good ("Reputable") product with the same amout of features as SAV 10 that is cheaper? I will tell symantec they should not expect any more 5-figure per year license payments from now on.
1/16/2006 12:25:00 AM by cb
# re: Rootkits in Commercial Software
What about Alternate Data Streams (ADS)? Functionallity built into the OS that allows files to exist on a system that can not be found with naitive tools? Yes, there are 3rd party tools (and perhaps MS distributes tools as well) that allow admins to know about ADS, but then again admins have RootkitRevealer to find "NPROTECT" too ;-)
So what's your stance on ADS?
1/16/2006 12:36:00 AM by Anonymous
# re: Rootkits in Commercial Software
The trouble is... Do you really think there are people care about this? Does this represent a REAL danger? Aren't there much larger and more seriour security holes than this?
I'm aware that articles on this subject are mostly because of your self promotion and earning money (and there's nothing wrong with that), but, please, go back to the roots - your articles about internals were genuinely adoreable.
P.S. NHF, please.
1/16/2006 2:45:00 AM by Goran Mitrovic
# re: Rootkits in Commercial Software
Even if cloaking itself does not constitute a full bloodied rootkit, the point is, unless the cloaking is airtight to the application or process to which it belongs, it can provide an umbrella of invisibility, under which all manner of malignant sofware can take root .
Sematic arguments are scant consolation.
1/16/2006 4:27:00 AM by ruy_lopez
# re: Rootkits in Commercial Software
"So what's your stance on ADS?"
I'm fine with the use of ADS because its a documented operating system feature.
1/16/2006 6:15:00 AM by Mark Russinovich
# re: Rootkits in Commercial Software
I think it is fine for Symantec to use this kind of prevention as long as they make it well-known that it's there and they include an easy way to enable/disable it--many people don't wander into the options, so on the main window would be best.
I'm very upset that they made this mistake. Pre-planted rootkits can be a BIG security hole if another hacker discovers their presence. They can use the rootkit that the user may "approve" of to give them full control over the computer. As a security programmer, I've always trusted Symantec the best when it comes to things like this. But it seems companies are taking things like this too lightly--at least they immediately agreed to get rid of it, but that was probably out of fear after seeing what happened to Sony.
1/16/2006 7:27:00 AM by TSA Admin
# re: Rootkits in Commercial Software
The logical consequence of your argument, Mark, leads directly to open source software. If admins are to have total clarity when it comes to the operation of their systems, it follows that transparent source code is necessary. You can't really demand transparency down to the level of the OS, then say, okay, from here on down to the architechture, opacity is fine. Which begs the question. Why do you persist with NT?
1/16/2006 7:38:00 AM by ruy_lopez
# re: Rootkits in Commercial Software
I don't follow your logic, Ruy. Rootkit techniques deliberately prevent reliable and thorough systems management. Use of documented functionality doesn't. It's not a question of open source vs closed source.
1/16/2006 8:33:00 AM by Mark Russinovich
# re: Rootkits in Commercial Software
"I see no reason technical or otherwise that this NPROTECT folder could not be under c:\Program Files\Symantec\NPROTECT as an unprotected folder."
No, no, no! The entire Program Files subtree should not be writable except by admins, and should only be written when installing an app. NPROTECT is a recycle bin extension. The natural place for that is in the Documents and Settings subtree, or in a separate folder created by Symantec and set with the appropriate permissions.
Looking at that screen shot, it appears that the files in the NPROTECT directory may not be segregated by user name. There may be a security hole where a file deleted by one user can be recovered by another user. I don't have Norton to try it though, and given that most users run as admins it probably doesn't matter much.
1/16/2006 8:36:00 AM by Anonymous
# re: Rootkits in Commercial Software
"Rootkit techniques deliberately prevent reliable and thorough systems management."
Intent wasn't in your definition.
Without the code, the documented functionality is built upon opaque structures, effectively a cloak.
But I think I know where you are coming from. To you the documentation seems adequate because you do in fact have access to the code. Or at least access to the coders.
To the average admin, proprietary software is like one big cloak. They are reliant upon the proprietors, and their insiders , to be guardians of the realm.
As an admin would you trust your systems management to be mediated in such a way? ;-)
1/16/2006 8:53:00 AM by ruy_lopez
# re: Rootkits in Commercial Software
But at least they can use standard diagnostic, administrative and security tools to observe the behavior and effect of applications that use documented operating system functionality.
1/16/2006 9:41:00 AM by Mark Russinovich
# re: Rootkits in Commercial Software
In response to the open source/closed source argument:
While I would love to see the day that MS make their source code public (and I don't believe that day will be far away) it has to be said that MS have made good efforts in making their OS transparent by providing a full set of symbols for public download along with debugging tools.
On the cloaking argument:
I have to agree with Mark here. While I agree with Greg H. that Sony and other companies have a right to take measures to protect their intellectual property I cannot see any reason why a cloaking technology would ever be needed to accomplish such a job. When software depends on its 'invisibility' for its security this usually means that it has *no security*.
1/16/2006 10:49:00 AM by lamie
# re: Rootkits in Commercial Software
To cb who was looking for a new Corporate AV.
My own experience in 2 differents large companies: Computer Associates Etrust.
CA bought Cheyenne in the late 90s, so their AV software is based on the old Cheyenne InoculateIT. The best. IMHO
1/16/2006 12:01:00 PM by P.V.
# re: Rootkits in Commercial Software
I just thought I would point out that you do NOT have to install norton protect with SAV it is an option and I am pretty sure you can uninstall that feature also through add/remove programs.
Now if it creates a security hole then it is a problem.
But to me that makes their "rootkit-like" behavior much more acceptable that Sony-BMG basically saying you can not use this CD unless you have our junk running on your PC and you will have no way of removing it.
1/16/2006 12:15:00 PM by Anonymous
# re: Rootkits in Commercial Software
For the person looking for an alternative to NAV, try Avast or F-Secure.
1/16/2006 1:20:00 PM by Anonymous
# re: Rootkits in Commercial Software
In regards to the open vs. closed source discussion, I'd just like to point out that rootkits exist for open source operating systems.
Open source software will not fix problems like these.
1/16/2006 1:25:00 PM by mpd
# re: Rootkits in Commercial Software
The purported intent of Symantec or anyone else that installs a rootkit on people's systems is irrelevant. Because once the presence of the rootkit (or any other vulnerability) becomes publicly known (and they always do, eventually) the hole on the system will be exploited by malicious people. To be willfully ignorant of the malicious potential of the hole they created on people's systems does nothing to cleanse their motives for placing it there.
1/16/2006 1:43:00 PM by Anonymous
# re: Rootkits in Commercial Software
So, if MS is opposed to these rootkit-like techniques why do they use them? Check out the "C:\WINDOWS\Downloaded Program Files" directory. Then open a command prompt and cd there. There are plenty of hidden exe files. I've just been waiting for someone to jump on this one.
1/16/2006 5:08:00 PM by Anonymous
# re: Rootkits in Commercial Software
So, if MS is opposed to these rootkit-like techniques why do they use them? Check out the "C:\WINDOWS\Downloaded Program Files" directory. Then open a command prompt and cd there. There are plenty of hidden exe files. I've just been waiting for someone to jump on this one.
1/16/2006 5:09:00 PM by Anonymous
# re: Rootkits in Commercial Software
Re: Downloaded Program Files, etc.
That's called a shell extension, not a rootkit, and is easily disabled.
1/16/2006 5:24:00 PM by Anonymous
# re: Rootkits in Commercial Software
"Then open a command prompt and cd there. There are plenty of hidden exe files."
I don't think I'd call that rootkit-like. Explorer does behave strangely in that folder, but any other file manager appears to show the full contents. Evidently, the API's are cooperative and will show what's there; explorer just acts a bit funny.
1/16/2006 5:32:00 PM by Anonymous
# re: Rootkits in Commercial Software
"I see no reason technical or otherwise that this NPROTECT folder could not be under c:\Program Files\Symantec\NPROTECT as an unprotected folder."
It's obvious that hidden recycle folder should exist on every logical disk, otherwise moving big files there would be too long etc.
"C:\WINDOWS\Downloaded Program Files"
It's just a usual folder with "system" attribute. Check the “Show hidden files and folders” and deselect “Hide protected operating system files” settings in Explorer as it written in the article.
1/16/2006 5:50:00 PM by MASTAN
# re: Rootkits in Commercial Software
So - Those who understand the arguments are all agreed...
Rootkits = Bad
So, What should be done about it - what do we think the OS makers (regardless of whatever form of source disclosure they prefer) should be encourage to do to restrict potentially malicious activities.
Mark - Do you think there are effective ways to "lock" the places where the registry hooks and bad-boy filter drivers are inserted now without affecting the applications we want to run?
1/16/2006 6:00:00 PM by J a m e s
# re: Rootkits in Commercial Software
Hello Mark.
By technical view, Filemon & Regmon 7.xx do some thing:
1.Using NtLoadDriver and the value of registry "LegacyDriver", the monitor driver can't see in the service list.
2. Dynamic Extract from PE Resource & "Erase on Load", like the stealth trojan behavior.
My question is "Are They Rootkit-like Program?".
Thanks.
Kuon@chroot.org
1/17/2006 12:55:00 AM by Kuon
# re: Rootkits in Commercial Software
No, Filemon and Regmon don't hide their loaded drivers from view of standard driver enumeration utilities.
1/17/2006 5:51:00 AM by Mark Russinovich
# re: Rootkits in Commercial Software
@james
I don't think there's any way for the OS to stop rootkits anymore than they can stop other forms of malware.
We really need two things: smarter users and better programming. I'm not holding my breath waiting for the former.
1/17/2006 8:54:00 AM by mpd
# re: Rootkits in Commercial Software
I'm glad you've pointed this out, Mark. I've known for years that Norton SystemWorks does this with the Recycle bin. I stopped using any of their products years ago and this was one of the reasons. I had SystemWorks installed once, for about a week, 10 years ago and it behaved in this way at that time. Plus it sucked up most of the available system resources. Gee, thanks.
I've come to loathe and avoid ALL things Symantec. They have some of the most bloated, unhelpful and easily broken software out there. In fact, I could argue that most of the crap that they sell is broken from the moment it's installed, not to mention that it's ridculously expensive. There are many FREE and much lower cost programs out there that are far more effective. Plus they have almost zero drain on system resources comparatively and don't impact system performance the way that Symantec software does.
I've been actively helping companies, that I consult for, to ween themselves off of their Symantec dependencies. They've all been happier as a result.
As for the System Volume Information directory, it is possible to access it on FAT32 drives and there is a bug which exists on NTFS volumes that allows you to access the folder. If you go to the Sharing and Security properties tab for the folder, Share the folder and click "Ok", it will give you an error and close the dialog. However, once you've done this, you now have access to the folder...
Keep up the good work Mark!
Thanks again.
1/17/2006 10:25:00 AM by Dr. Zhivago
# re: Rootkits in Commercial Software
For me, the root kit debacle by Sony and others is evidence of unclear thinking. By hiding certain files with a root kit rather than standard OS mechanisms you're simply escalating the [non-]hiddeness of the file. It becomes an arms race between the revealer and hider software to see whether a file will be visible, with your computer as the battleground. This arms race is not well defined and because it's not well defined it will make your computer unstable. There is no justification for bypassing standard OS mechanisms. The whole point of an OS is to standardise and moderate access to the hardware. Making a root kit hack well known does not obviate this. How would you like 10,000 companies all with there own root kit hacks on the battleground that is your computer?
1/17/2006 10:59:00 AM by Anonymous
# re: Rootkits in Commercial Software
I have a \RECYCLER\NPROTECT folder on one of my (non-system) drives. I uninstalled Norton SystemWorks about 6 months ago, and have recently reinstalled Windows.
The problem I am facing is that the folder appears to contain 3,441 files totalling 560MB, and none of them can be deleted. I don't know if this is related to Symantec's rootkit-like technology, but if Explorer is correct and I really am losing 560MB of space then I'd like it back.
---------------------------
Error Deleting File or Folder
---------------------------
Cannot delete file: Cannot read from the source file or disk.
---------------------------
OK
---------------------------
1/17/2006 11:57:00 AM by luv-snail
# re: Rootkits in Commercial Software
Yeah luv-snail, I had that exact same problem too. A while ago, I figured out that Symantec rootkit-ed that directory so I turned the feature off right away. I wasn't able to delete a bunch of the files, but they're only taking up around 68 MB for me, so I really don't care too much. I tried everything that I could think of to remove them, but nothing seems to work.
They don't seem to exist although I can see them......
1/17/2006 3:00:00 PM by Aaron
# re: Rootkits in Commercial Software
I was once again thinking about why I couldn't delete those files that I mentioned earlier, and I think I understand why.
The files that I can't delete have no extension, but do have a dot (.) in their name.
For example: "00039625." (without quotes)
I think that's why Windows is having trouble finding them. When I tried to make a file called "test." in a separate directory, Windows automatically deleted the dot, making it named "test"
Anyways, I think I'll play around with this. I'm betting that there's a way to delete them.
1/17/2006 3:14:00 PM by Aaron
# re: Rootkits in Commercial Software
Eight years ago I decided to trust with my money Symantec and purchased a Norton subscripton thinking that I will get the protection needed for my system.
Four months later a small box opened in the middle of my desktop and I found myself chatting with someone from brazil who gained access on my computer.
I got precious advice regarding the security of my system "for free" from a person who beat Norton's so-called protection to my system.
Then is when I realized Symantec was just a scam, they got my money in exchange for nothing. Their product did not delivered.
Could have been that so-called "almost-rootkit" have facilitated that brazilian guy access to my system? I tend to think it is possible now in the light of the truth.
It has been 8 years I have removed Norton from my systems and keeping advising everyone to avoid the products of that company.
Lately, the meaning of "commercial software" looks more like: pay for empty promises. Could the EULA of this kind of sofware mention "you are not having the right to held us responsible of this n that"? Most probably..
Same for Microsoft Windows: you "pay" for the software and become an instant Microsoft Windows "tester" keeping up with the good works of patching, updating and hey why not? pay for getting technical support for a product you spent money on.
1/17/2006 3:36:00 PM by Anonymous
# re: Rootkits in Commercial Software
Dr. Zhivago:
The easiest way to get access to 'system volume information' is just to to give yourself full control over the folder. The OS won't block you from adding administrator accounts to the list of authorized users.
Aaron:
I've found it's possible to whack files with invalid names by using a sector editor to alter the filenames to something valid. In my case, I accidentally created 'nul.png', which Windows kept mistaking for the nul device whenever I tried to delete it. What I finally did to get rid of nul.png was use Disk Explorer (an NTFS-aware sector editor) to rename the 'file' to 'nxx.png' and then deleted it normally.
1/17/2006 10:46:00 PM by Sum Gai
# re: Rootkits in Commercial Software
To Sum gai:
Hmm, good idea. I'm in the middle of writing a simple program that attempts to rename the files.
I'll see how that works out...I wasn't able to finish it yesterday due to homework.
1/18/2006 6:27:00 AM by Aaron
# re: Rootkits in Commercial Software
I can confirm that the NPROTECT files I am unable to delete also end in a dot with no extension, so I think you've hit the nail on the head there, aaron.
Let us know if you manage to get that program working.
1/18/2006 9:16:00 AM by luv-snail
# re: Rootkits in Commercial Software
This program works to delete invalid files and folders: http://www.purgeie.com/delinv/index.htm
1/18/2006 10:35:00 AM by Dr. Zhivago
# re: Rootkits in Commercial Software
Why then is Microsoft using the same techniques? On Windows XP, try emptying your "Temporary Internet Files" using the approved dialog, then go to the folder using Windows Explorer, and delete all of its contents. Now use the Properties dialog of the folder and see how much space the folder is still using! The culprit is the IE cache, contained in a subfolder called "Content.IE5" and numerous other subfolders of this folder. The only way I have ever found to expose the folder directly in Windows Explorer is to type the actual path into the locaton bar; albeit the folder does show up by using "dir" at a command prompt.
1/18/2006 12:41:00 PM by Anonymous
# re: Rootkits in Commercial Software
Ok, I haven't got it working so far, but being busy with college classes, I haven't had much time to work on it.
I've got the code written, but the inital run didn't work. I'm gonna change something and try again.
~Aaron~
1/18/2006 12:41:00 PM by Aaron
# re: Rootkits in Commercial Software
Ok I think I got it!
The solution came from microsoft, actually, from this link
http://support.microsoft.com/default.aspx?scid=kb;en-us;320081
Anyways, I got my program to work using the same strategy, since there were a bunch of the files and I'm not really sure how to do a wildcard thing with Microsoft's instructions, even though it MIGHT be possible.
Here's a link to a zip file with source code and binary:
http://awebs.dyndns.org/ExtensionRemover.zip
I'll also try to paste the source code below, but I don't know how it will work out. Anyways, you can just try to follow Microsoft's instructions, or use my program, whatever you want. Oh, and I can't guarantee that the program will work correctly. I slapped it together rather fast, but it worked for me. It will rename all files to .dud extensions. Make sure you don't have files with duplicate names, (like test.acc and test.wps) or they might get overwritten. It will prompt you for the directory at run time, and will prompt for confirmation once you enter one.
Source code:
//---------------------------------------------------------------------------
// i had to remove the angle brackets and replace with quotes to post this onthe blog, try changing them back if quotes don't work
#include "windows.h"
#include "iostream.h"
#include "stdlib.h"
#include "string.h"
bool RenameFile(char*, char*);
bool ChangeExtension(char*);
//---------------------------------------------------------------------------
int main(int argc, char* argv[])
{
char folder[MAX_PATH];
char choice;
char newFileName[MAX_PATH];
char oldFileName[MAX_PATH];
char searchFolder[MAX_PATH];
// prompt for folder
cout << "Enter the FULL PATH of the folder that contains the files with the extensions you want to change.\n\n\n";
cin.getline(folder, MAX_PATH);
// add ending / if user didnt enter it
int folderLength = strlen(folder);
if (folderLength - 1 >= 0){
if (folder[folderLength-1] != '\\'){
if (folderLength + 1 < MAX_PATH){
strcat(folder,"\\");
}else{
cout << "\n\nError, exceeded MAX_PATH number of characters for path.\n";
system("Pause");
return 0;
}
}
}
// get confirmation
cout << "\n\nOk, so you want to change all file extensions in the folder \"" << folder << "\" to \".dud\"?\n(y/n)?";
cin >> choice;
strcpy(searchFolder, folder);
// add * to path so windows searches for all files
if (folderLength + 1 < MAX_PATH){
strcat(searchFolder,"*");
}else{
cout << "\n\nError, exceeded MAX_PATH number of characters for path.\n";
system("Pause");
return 0;
}
// if user confirmed rename,
if ((choice == 'y') || (choice == 'Y')){
WIN32_FIND_DATA foundFileData; // holds found file info
// attempt to find the first file
HANDLE hFindHandle = FindFirstFile(searchFolder, &foundFileData);
// if it is not a directory
if (foundFileData.dwFileAttributes != FILE_ATTRIBUTE_DIRECTORY){
strcpy(newFileName, folder);
strcat(newFileName, foundFileData.cFileName);
strcpy(oldFileName, "\\\\?\\");
strcat(oldFileName, folder);
strcat(oldFileName, foundFileData.cFileName);
if (ChangeExtension(newFileName)){
cout << "\n\n" << oldFileName << " --> " << newFileName << "---" << flush;
if (RenameFile(newFileName, oldFileName)){
cout << "Success!" << endl;
}else{
cout << "Failure..." << endl;
}
}else{
cout << "!!Did not rename " << oldFileName << endl;
}
}
// loop for all the rest of the files
while (FindNextFile(hFindHandle, &foundFileData)){
if (foundFileData.dwFileAttributes != FILE_ATTRIBUTE_DIRECTORY){
strcpy(newFileName, folder);
strcat(newFileName, foundFileData.cFileName);
strcpy(oldFileName, "\\\\?\\");
strcat(oldFileName, folder);
strcat(oldFileName, foundFileData.cFileName);
//oldFileName[strlen(oldFileName) - 1] = '\0';
if (ChangeExtension(newFileName)){
cout << oldFileName << " --> " << newFileName << "---" << flush;
if (RenameFile(newFileName, oldFileName)){
cout << "Success!" << endl;
}else{
cout << "Failure..." << endl;
}
}else{
cout << "!!Did not rename " << oldFileName << endl;
}
}
}
// close search handle
FindClose(hFindHandle);
}else{
cout << "\n\nOk, no action has been taken.\n";
}
system("Pause");
return 0;
}
//---------------------------------------------------------------------------
bool RenameFile(char* dest, char* src){
if (CopyFile(src, dest, false)){
if (DeleteFile(src)){
return true;
}else{
return false;
}
}else{
return false;
}
}
//---------------------------------------------------------------------------
bool ChangeExtension(char* file){
int length = strlen(file);
int counter;
for (counter = length - 1; counter >= 0; counter--){
if (file[counter] == '.'){
break;
}
}
if (counter >= 0){
file[counter] = '\0';
if (strlen(file) + 3 < MAX_PATH){
strcat(file, ".dud");
return true;
}else{
return false;
}
}else{
return false;
}
}
//---------------------------------------------------------------------------
1/18/2006 1:29:00 PM by Aaron
# re: Rootkits in Commercial Software
I find that many thing are done in the name of greed!!!
You can catch a cor-pirates attention. but to make them change you need to practically nuke them from the face of the planet!!!
Law suites they understand. And are stocked with large hi budget legal departments!! Laws they also understand. They know if you grease enough palms you can get any law made to tailored specs in their favour.
The cor-pirates use the peon consumer as profit fodder and that only is how they see you!!!
Beat them over the head like we have only has temporary effects!!
They know the consumer peons have short memories and will strike again more insidiously then before!!!
1/18/2006 2:13:00 PM by Anonymous
# re: Rootkits in Commercial Software
Hi Mark, I fully agree with your views. I have a question that doesn't seem obvious to me. Why does Microsoft provide the ability for developers to be able to alter the OS (i.e. other peoples' OS) at such a fundamental level? If they wanted to eliminate the capability for rootkits to exist surely a patch would cause this whole controversy to evaporate. As others have pointed out, the OS should be standard. Also, where would we be if every piece of software wanted a piece of the same action in the same way. (We already have something like that already with the huge amount of services and user agents now being installed and permanently running to support applications that are only used occasionally.) Would it make sense for Microsoft to eliminate the capability for rootkits to hook in?
1/18/2006 5:20:00 PM by Anonymous
# re: Rootkits in Commercial Software
Great work on rootkits, Mark, but, like the anti-adware companies who have removed listings for companies that either threaten or pay them, you've sold out! To call a rootkit "rootkit-like" when it is from a commercial vendor is another case of not being willing to call a spade a spade. By being "willing to concede" your definition of a rootkit, you've conceded much more than that.
It is MY computer! No one has a right to hide something on it without clearly asking my permission and getting explicit approval to do so. For instance, parental controls would ask for and get such permission.
But the real point of my comment is to say that if Dave Cutler unequivocally agrees with you about there being no valid reason for cloaking, Dave Cutler is the guy who can end rootkits once and for all.
You can read my comments about it on my blog at http://www.dalepreston.com/Blog/2005/04/rootkits-and-hooks.html .
Since the chain of hooks is maintained internally by Windows, it would be trivial to expose that chain in a read-only fashion. Then each hook in the chain of hooks, for each type of hook, could be compared to a database of known and expected hooks. Exceptions would raise flags. That would spell the end of rootkits as we know them today.
My guess is that it would take a developer who understood the code for managing the chains of hooks about 8 hours to develop API methods to expose them. Add about 500 hours of testing, QA, and documentation, another 500 hours for developing and testing the deployment process for the patch.
Assuming that the average costs per man-year for all the teams involved is about $120,000.00, then you get a price for completely eliminating rootkits as we know them today of about $60,000. Talk to your buddy Dave Cutler about that!
1/20/2006 8:18:00 PM by Dale Preston
# re: Rootkits in Commercial Software
Microsoft moved to contain the problem in Vista on x64:
Digital Signatures for Kernel Modules on x64-based Systems Running Windows Vista .
According to this article at OSROnline , this would indirectly force developers to acquire a Verisign certificate. To my views, it could stop/halt the development of many useful utilities that extensively employ kernel drivers like some from SysInternals , Rightmark , Daemon Tools and many others.
1/22/2006 9:22:00 AM by Sébastien Mouren
# re: Rootkits in Commercial Software
Another annoying aspect of Symantec's AV products is their hobbling of WinDbg. I recently needed to debug a driver problem on a production machine being used by a beta tester (brave soul). Unfortunately, I had to remove the Symantec software in order to use WinDbg. I'm guessing that crippling support for kernel debugging was a deliberate move by Symantec to make it more difficult for people to reverse engineer their product. However, in my book it's not okay to cripple services that I might use to conduct legitimate, unrelated work on my computer. Anyone else find this annoying?
1/25/2006 4:03:00 PM by Chris Russell
# re: Rootkits in Commercial Software
Mark
I wonder if symantec do not do something similar for the quarentine emails/files detected by their antivirus
1/27/2006 10:55:00 PM by NotAvailable
# re: Rootkits in Commercial Software
I always find ideas like yours are great correct, very insightful enough but still don't understand why always wonder ?
1/29/2006 10:15:00 AM by Anonymous
# re: Rootkits in Commercial Software
CB, you may be overreacting. I'll assume you're using SAVCE, especially for 4000+ users.
NProtect is part of Norton SystemWorks, not SAVCE.
2/9/2006 9:37:00 AM by ConQuer0r
# re: Rootkits in Commercial Software
For those with \RECYCLER\NPROTECT problems, try these, copied from a Langalist newsletter;
http://www.softwarepatch.com/software/moveonboot.html
http://ccollomb.free.fr/unlocker
These, and others like them, should be able to delete the files in quesiton. To find others, google it.
2/9/2006 9:49:00 AM by ConQuer0r
# re: Rootkits in Commercial Software
Nice write-up, but man, this stuff gets gnarley.
(And I thought that watching 24 hours of TV straight was bad
http://www.24HoursOfTV.com)
2/24/2006 4:44:00 PM by b1-66er
# re: Rootkits in Commercial Software
Mark,
I appreciate the time and effort you put into writing this up for the Internet's viewing pleasure. Your Winternals/Sysinternals applications have been a great value to me in my personal computing for a long time, and I expect they will be for as long as I use them.
Reading through your blog is also helping me to gain a deeper understanding of this field, and that is definitely a nice change. I'm too used to reading things written at an elementary level.
Thanks!
5/29/2006 8:38:00 PM by Garrett from Phoenix,AZ
# re: Rootkits in Commercial Software
Why you don't publish my posts????
7/19/2006 2:00:00 PM by Poorguy
# re: Rootkits in Commercial Software
Huh! eTrust Antivirus version 7.0.139 has files hidden from the Windows API too!
7/26/2006 9:21:00 PM by Anonymous
# re: Rootkits in Commercial Software
good article. teh comments were fun to read.
10/2/2006 10:01:00 AM by Order Taking