About | Buy | News | Products | Rants | Search | Security
Home » Security

Protecting Your Windows File System

Do like Microsoft.

Get It

Try It

Reading about the China attack on Google and then the Backdoor.Tidserv.K trojan gives one reason to pause. In both cases, the trojans slid easily onto a Windows file system, then evaded the 'Keystone Kops' tasked with patrolling the dark alleyways, and took over the host computers.

 An ever-vigilant Windows antivirus suite in action, responding to yet another alert.

The China attack used sophisticated code to infect the Registry and register a new system service; the Backdoor.Tidserv.K trojan is in ways even more evil: it deletes itself from disk as soon as it's arrived and gone into memory.

How is one to remove a trojan from the hard drive that's not on the hard drive?

Indeed. The prophetic words of Bill Joy come back to haunt. Joy was the one who questioned how Microsoft could put what he called a standalone system on the Internet without a thought for the safety of users.

But is Windows really a standalone system? Is there no better protection available?


The key to solving this riddle is to consult the Microsoft system API for protecting files. It's called SetFileAttributes. Here's the basic API. You can click on the image to be transported to the actual documentation page.

 The Windows SetFileAttributes function, incorrectly described as C++.

Now you don't have to be a coding genius (or even an adept) to figure out what that gibberish means, for this article shall help you.

  • The function (for that's what they're called at that level) admits of two parameters or arguments.

    1. lpFileName - the 'path' to the file. Such as 'C:\WINDOWS\system32'.
    2. dwFileAttributes - a doubleword containing all the file attributes to be set.

  • A doubleword is a term describing a 32-bit integer. 32-bit integers have - unsurprisingly enough - 32 bits.

  • In this scheme of things, each bit is used to describe a unique file attribute.

You don't have to specify those bits yourself - the application you use to set file attributes does it for you. All you need to know are the plain language terms for the various file attributes. And that's easy enough. Here's a screen dump of Radsoft's stellar file attribute utility X-attrib.

 Radsoft's file management utility X-attrib accesses all 32 possible file system attributes.

As you can see, not all of the 32 file attributes are defined (but X-attrib gets at them anyway). The application also uses a rather cryptic description system mostly suitable for professionals, so it's necessary to visit that Microsoft documentation page and decipher the plain language there instead.

Following is Microsoft's current table of Windows file system attributes. (Note not all 32 values are represented.)

Official NameValueBitDescription
FILE_ATTRIBUTE_READONLY10Makes the file read-only (you cannot write to it). Note this applies only to files. Windows directories can always be written to.
FILE_ATTRIBUTE_HIDDEN21Hides the file so it's normally not listed. (Note you can still access the file if you know its name.)
FILE_ATTRIBUTE_SYSTEM42A descriptive attribute with no specific meaning which certain utilities can choose to interpret as they see fit. Simply means 'system file'. Can be ignored by any software.
FILE_ATTRIBUTE_VOLUME83Not listed by Microsoft but it's there. Indicates a directory entry without corresponding file, used only to denote the name of a hard drive volume. Was used to 'hack' the long file name system of Windows 95.
FILE_ATTRIBUTE_DIRECTORY164Indicates the file is a directory. Cannot be changed by the user (or any software).
FILE_ATTRIBUTE_ARCHIVE325Used by backup systems. All file saves on Windows automatically set this attribute so backup systems know which files need to be backed up.
FILE_ATTRIBUTE_DEVICE646Currently not in use.
FILE_ATTRIBUTE_NORMAL1287Strangely enough, Microsoft indeed have an attribute that means 'no attributes' (instead of just leaving the attribute field blank). This attribute literally means 'no attributes'.
FILE_ATTRIBUTE_TEMPORARY2568Indicates a temporary file the application is likely to remove when exiting. The system can then try to speed things up by actually keeping the file contents in the faster cache memory if possible.
FILE_ATTRIBUTE_SPARSE_FILE5129Indicates a sparse file. Cannot be set with this API. The file must be modified with other APIs.
FILE_ATTRIBUTE_REPARSE_POINT102410Indicates a reparse point. Cannot be set with this API. The file must be modified with other APIs.
FILE_ATTRIBUTE_COMPRESSED204811Indicates the file is compressed on disk. Compression cannot be set with this API - other APIs are again necessary.
FILE_ATTRIBUTE_OFFLINE409612Indicates the file has been moved to temporary storage and is not currently available. This attribute might be set by the user but it's advised against.
FILE_ATTRIBUTE_NOT_CONTENT_INDEXED819213Indicates a file that shouldn't be indexed by the content indexing service.
FILE_ATTRIBUTE_ENCRYPTED1638414Indicates the file is encrypted. Encryption cannot be enabled/disabled by this API. Separate APIs are necessary.

Those then are the Microsoft Windows file system attributes. If you're going to protect your file system, you should ideally be able to do it with one or more of them. (There is a separate security API with so-called access control lists but that's normally kept out of reach of ordinary users.)

So which file attributes do we set to protect our Windows file system?

It's been easy to see that most of the above file attributes have little to do with protection. In fact, many of them stink of 'file server': temporary, sparse file, reparse point, offline... Others are mere baubles (or not configurable): volume, directory, device, system... Hiding a file is of little consequence - applications can still write code to find it. It's only hidden by applications that choose to observe the 'hint' to keep it hidden. Trojans and viruses aren't going observe it. Obviously.

How about read-only? What if we make all our files read-only? Good idea but for one small minor detail: it's just as easy to remove the attribute as it is to set it. Meaning malware only has to go in and remove this attribute from any files it wants to corrupt and it's done.

What makes matters even worse is you can't use this API to make Windows directories read-only - you can't prevent malware from putting trojans anywhere it wants on your disk.

Watch this clip from Symantec. Files are put in C:\WINDOWS\system32 and there's not a thing the attributes can do about it.

And that's a real bummer.

The scenario should be clear by now. Trojans and other forms of malware seem to be able to descend onto a Windows file system with the greatest of ease. They can come in a mail attachment, they can come from an innocently looking web page; you as a user are fundamentally powerless to prevent this. Your only hope is that your antivirus suite can detect them when they arrive. But to do that, the virus has to already be known. And it's going to infect your file system anyway, antivirus or no.

So how do you protect your Windows file system? How do you protect it so viruses and trojans never get in? So the 'Keystone Kops' don't have to scramble all the time, looking for something that's not often there, and too well hidden when it is?

It's easy. You do the same thing Microsoft have been doing all along, for every one of their expensive system security certifications.

You disconnect from the Internet, you physically remove (with screwdriver, whatever) all floppy drives and CD/DVD bays, and you lock the door. You make sure your file system can't be accessed by anyone or anything, from anywhere, at any time.

Best of luck.

See Also
Radsoft Security: Symantec on the China Attack
Symantec Connect: Backdoor.Tidserv.K: Now You See Me, Now You Don't

About | Buy | News | Products | Rants | Search | Security
Copyright © Radsoft. All rights reserved.