efficient usb Virus Prevention, using Software Restriction Policies

hiii folks ,
i found this usefull paper while searching and i wanted to share it with u



efficient usb Virus Prevention, using Software Restriction Policies

Summary

This paper describes how to set up a Windows XP Security Policy that very effectively prevents Virus on USB "Handy Drives" from infecting your computer. It does not address how to prevent your USB "Handy Drive" from becoming infected with (and thus becoming a carrier of) virus that can spread to other computers. But should your USB "Handy Drive" become infected, the virus would not infect your computer if your Windows XP has this policy in place. The strategy here is to apply "Software Restriction Policies" that prohibits any "running" of programs directly from USB. Since no program on USB can be run, any virus that might be on USB drives cannot infect your computer. Not directly ... Our strategy does nothing to prevent, for example, accidentally copying virus-infected programs from USB to hard disk and infecting the computer by running the copy. But USB virus is prevented from being run "automatically." Please note that it is necessary to be logged-in as a member of the Administrators Group to be able to set these policies. The "Software Restriction Policies" facility is rather powerful. We present but one aspect of it. Specifically, we use "Path Rule." Other methods that this facility provide are "Certificate Rule," "Hash Rule," and "Internet Zone Rule." These and several other aspects of the facility are not within the scope of this paper. Please refer to Microsoft's documentation if you feel that you need to do more than is presented in this paper. The following web page provides detail:- http://www.microsoft.com/technet/security/prodtech/winclnt/secwinxp/xpsgch06.mspx

Part One -- Step-by-step Procedure

• Identify drive letters that USB devices are assigned. In our example computer, drive letters C:\ and D:\ are assigned to hard disks; drive letter E:\ is assigned to CD-ROM. This example computer has 4 USB ports. Therefore, drive letters that can be assigned to USB devices are:-
F:\
G:\
H:\
I:\


We proceed setting policy to prohibit running of programs directly from these drive letters ...
• click: start > run... type: secpol.msc click: ok
• select: Software Restriction Policies click: Action > New Software Security Policies



• expand: Software Restriction Policies select: Additional Rules click: Action > New Path Rules...
• type: F:\ click: ok
• Repeat the above procedure until all USB drive letters have been added.



Part Two -- How will the Computer Act Differently?

Case One
If you primarily use your USB drive to carry documents such as Word, PowerPoint, PDF, photographs, songs, and the likes, then there would be no difference on your day-to-day use of your computer. Unless your USB drive has become infected. If a virus-infected USB drive is attached to your computer, Software Restriction Policies would protect your computer. If you see a pop-up error message similar to the following it usually means that the USB drive has virus on it and that it attempted to infect your computer. Taking a closer look at the above error message, please notice that "autorun.inf" was prevented by Software Restriction Policy from being open. Most, but not all, USB virus try to infect computers by way of the autorun.inf facility. You should ask a computer technician to clean the USB drive for you.


Case Two
If you carry programs on your USB drive such as Acrobat Reader installer software, games or other software, you would likely see more pop-up messages. Any time that you attempt to run a program directly from your USB drive, Software Restriction Policies would prevent you from doing so. Software Restriction Policies does not know the difference between a virus program and a regular useful program. It would prevent both types of programs from running. For example: In the above example pop-up message, "games\Solitaire.exe" was blocked. If your are sure that this is a good program and want to run it, you would have to copy it to hard disk and run the copy from the hard disk instead.




As a rule of thumb:-
If you see the pop-up message when you did not intend to run a program, chances are that Software Restriction Policies blocked a virus. For example, when you double-click on a USB drive letter -- your intention is to view the content of the USB drive -- your intention is not to run a program. In this case your USB drive is probably virus-infected.
1. If you see the pop-up message when you indeed wanted to run a program, there is a good chance that it is safe to copy the program to hard disk and run the copy.
2. If you are not totally sure, it is best to ask a computer technician.


Conclusion to Part Two
With Software Restriction Policies in place, no programs are allowed to run directly from USB drives. This prevents any virus, that may be on the USB drive, from "automatically" infecting your computer.
You are not prevented from, however, copying programs from the USB drive to hard disk and then running them. Caution must be taken if you choose to this. If the program that you copy to hard disk and run is infected with virus, your computer can still be infected, despite Software Restriction Policies being in place.


Part Three -- What is a Program? What is a Document?


Generally speaking, programs are files that end with .exe, .vbs, .dll and several others. Documents are, generally, those that end in .pdf, .doc, .jpg, etc.
A list is maintained by Software Restriction Policies as to what "file name endings" (file extensions) considered to be programs. Policies are applied to files with these extensions. Attempt to "open" a file with one of these extensions will be prohibited.
It is possible to customize this list. If you need to do so, then:-
run: secpol.msc select: Software Restriction Policies right-click: Designated File Types > Properties
Created by: Aperat Purabibadhana

-----------------------------

so i hope u got some benefit from it

best regards

 

i think by this strategy and if u added all the drive letters from the usb drive letter and untill the "Z:/" letter

so that u can protect ur computer not only from the usb viruses but also u can protect ur data from any extra hard disk connected to ur pc to copy data to and/or from it

and now i hope that one of the wilders expert users to share us about the essential folders to be added the additional path rules of the srp like the temp folders of the browsers and the shared folders

but please with the exact path
for example for opera browser "c:/Documents and Settings/user/Local Settings/Application Data/opera/opera/profile/......"

 

Any way to implement this sort of thing, in a straightforward way, on XP Home?
It would perhaps be useful to specify that the procedure applies to XP Pro.

 

wonderful paper , Doctor

i think compining the software restriction policy with virualizing software like shadow defender or shadow user can allow the user to leave and loose other important security softwares like the traditional antiviruses , defensewall , geswall and sandboxie

btw i agree with Tarq57 that the above mentioned functionalities are absent in XP home

 

You may wish to look at https://www.wilderssecurity.com/showthread.php?t=232857. The topic title is 'Vista' but also can be used on XP. Also see https://www.wilderssecurity.com/showthread.php?t=200772.

 

Thanks for that. A couple of healthy reads.
I might just not go through that exercise, for now anyway.

 

Sorry to burst your bubble, but infected USB sticks with autorun.inf will defeat this SRP strategy. It would seem that you cannot keep an autorun.inf from starting, as it is not an executable that SRP can 'restrict' or 'deny'. It has been tested, that you can set a rule in place, very specifically to a USB stick drive letter, and deny autorun*, *autorun* or autorun.inf, and they all fail. This is due to the actual autorun.inf is not actually what executes.

In the registry there is as mentioned by both Lucy, Tlu and Rmus, a way to almost guarantee that autorun does not auto run. This is the only way native to windows that seems dead set to stop an infected USB stick with autorun infection method.

You may also try adding a DIRECTORY named autorun.inf to the root of c:, and the root of every USB stick or active partition or external drive. The existence of this directory means that the malware cannot install it's own autorun.inf FILE. Evidentily, without special considerations, most scripts do not check for existence of a DIRECTORY, only a FILE. If it were only a FILE it would work, even as a READ ONLY file.

So, you might also forgo the whole method of finding what drive letters you need. You can consider that using the wildcard ? with drives is a neat way. For example, if you wanted to stop setup.exe, you could try to use
?:\setup.exe
This would then apply to all drives. Now I have not tried.. yet .. that you might do this
?:\setup.exe - Deny or Restrict
c:\setup.exe - Allow

I am unsure ATM whether the deny rule takes control over the allowed, or whether, like MS IPSEc rules go, the deny is generic to all, unless a specific rule stating otherwise is declared.

If you are successful to get XP or Vista to block an Autorun.inf USB stick from doing it's autorun thing, I am MOST interested to see your configuration. However, you must have Autoplay and Autorun enabled for this to be the case.

You might also mention that one should PROBABLY include all files INCLUDING DLL's in the files to apply the SRP to.

I apologize in advance if what I am saying is in error. I have been testing this exact topic for a few days now, in XP home and PRo, and have yet to stop autorun.inf natively without reg edit.

Good thread though, full of stuff to discover.

Sul.

 

hi sully
i tested that with an infected usb stick and also infected another hard disk
and the viruses are prevented from the 1st run

about the drive letters
i emerically add all the letters after my last drive letter of the main hard disk

if i have 4 drives c:/ d:/ e:/ f:/

so i will begin from the G:/ and untill the Z:/ drive letters

i really did not understand the way u explained about how the executable autorun.inf can easily BYPASS the SRP

 

Hmm. That is strange. I was trying that just today on xp home. With a myriad of different syntax to block.

But, perhaps I was engrossed in the variables too much. I may not have tried just adding a drive letter alone (ie. f:\ ).

I do know that from my tests, autorun.inf, when you insert usb or cd into computer, will run, but it is being executed by dll calls. These dll's you would have to have blocked. Have you tried this with the setting in SRP to exclude dll's? BTW, if anyone knows of a specific dll or exe that is soley responsible for a portion of the autorun/autoplay I would be most happy to know of it.

Of course too, I am hoping to find how to use ? so you don't have to go through and enumerate every drive like you did.

Very good post. And I might add, lol, impeccable timing with what I have been playing with myself.

Sul.

 

Hi,

EXPoff, (or something, nickname for fameous hacker) now working at Microsoft, wrote some PoC which decieved SRP in the way Sully describred. I lost the reference to the article.

Setting SRP to include or exclude DLL's could also make the difference between your tests.

Regards Kees

 

I recently cleaned up an interesting infection on a friend's PC. As part of it's dirty deeds, it would infect a USB flash drive when inserted by writing an autorun.inf and an executable to the drive.

I was already aware of the method that Sully notes where I had previously placed an autorun.inf folder on the drive. My folder had the attributes of Archive, System, Read Only and Hidden. When this drive was inserted, the infection wrote the executable with no problem. And it thought that it had written the appropriate autorun.inf too. But the folder in place did indeed prevent it from writing it's own inf file. (One oddity I noticed is that the infection removed the attributes that I placed on the folder. But the folder itself remained intact.)

Besides adding the autorun.inf folder, another method that appears to work is to use the new Panda USB Vaccine. http://research.pandasecurity.com/archive/Panda-USB-and-AutoRun-Vaccine.aspx I have done some minimal testing and from what I see, it appears to work as advertised. Specifically, the autorun.inf file that it places on the USB drive can only be removed by a formatting of the drive. No other method I've found will allow access to the file (I haven't tried accessing the file via another OS other than Windows though. Of course, it's there to protect Windows and that's the whole idea.) Panda has yet to release how they are creating an inaccessible file on a FAT32 drive but it clearly works. (The C: drive protection is pretty much the method mentioned by Solaris in the comments section. Apparently also quite effective.)

BTW, any thoughts as to how Panda is creating an inaccessible file from within Windows?

Thought some of you might find my experiences helpful...

 

Hii sully

i tried also and the autorun.inf never passed to my pc

i never know before that xp home has srp functionality coz i never installed it on my machine , have u tried the professional version

sully , i really wants to know what's wrong with ur machine
u can try to add the drive letter of ur usb drive to the path rule of srp
also try xp professional instead
and let us know the results

 

Hiii Kees1958

in fact i should say that i'm very impressed by ur strategy using the srp and so i follow ur posts concerning the srp in the "What is your security setup these days?" thread

and in the 2nd reply of this thread when i said that may an expert user of the srp could provide us by the certain folders to be included in the srp path rule , i think u can do that
how can i know the exact location of the temp folders of certain browser like the opera , internet explorer , ect.., to be included in the srp path rule , and what is the efficiency of such measure

BTW , u mentioned b4 that u set the temp folders to limited rights , do u do that using the srp or just LUA and how

thanks in advance

 

lol, I am not Kees, but I can answer this part. You can get your temp folders by using registry environment paths. There are some examples of these already in xp and vista. You just need to know which key and value has the data you are needing in the registry. Here would be the syntax
%[Registry Hive]\[Registry Key Name]\[Value Name]%
you can also use environment variables, like %windir%

A temp folders limited rights can be assigned with ACL.

XP and Vista, all versions, have safer values. Safer is part of the OS. During certain calls, the OS will check the Safer values. Group Policy can be used to add these, but they are still just registry values. If you delete the registry values, the group policy still shows the restrictions but without the reg vals they do nothing. Since it is built into the OS, any version can have a hand made registry value in Safer that will work. From my testing anyway.

I normally use xp pro, but also use xp home to test with. These issues work the same in both versions.

I don't think anything is wrong with my machine. It must be my syntax or setting in SRP. But I will test today and find out hopefully. Can you make a simple example in your SRP and then export your
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
key and pm me that? Then I could recreate exactly what you have done to test.

Sul.

 

http://hype-free.blogspot.com/2009/03/how-does-panda-usb-vaccination-work.html

 

Thanks MrBrian! Very interesting!

 

thanks sully , for help

 

sully , in fact i don't have specific or execptional rules in the srp
only the simply path rules for the drives
i think the rule is that srp should fight the autoruns and the exeptional is the reverse

any way i created the reg file u asked for

 

Please see this thread
https://www.wilderssecurity.com/showthread.php?t=240474

Sul.

 

FWIW...

I tried deleting the Panda created AUTORUN.INF file from my USB flash drive and had no success. Most likely I was doing something wrong but from reading the blog, there were a couple others that couldn't delete it either.

Any other thoughts?

 

The information in this URL is incorrect. It seem like the author simply looked at the code but didn't verify his findings to see if the program behaves as he thought. The code he mentions is in the executable, but that's just not how the program works.

Pb
research.pandasecurity.com

 

Thanks for the follow-up.

In the end, understanding how the file is created doesn't affect my use of the Panda immunization process. I know it works and that it appears that removing it would take some very serious efforts on the part of a malware writer. And that higher level of autorun protection is what I'm after...

 

And, by the end of the day, isn't that what we just want? To make their lives harder?

Every detail counts, and that's just one piece of the puzzle.

 

Sorry,I installed Panda's USB Vaccine a week ago on my 4GB USB disk.Still,it was actually infected by real malware using the "autorun.inf" method. My Avira blocked the .exe virus when I plugged my usb disk to my computer.

I did manually copied some files from the infected computer (I didn't know it was an infected computer until Avira popped up saying virus found in my usb disk.) But I think my usb disk was infected by autorun.inf (double click open).

The virus created another file named autorun.inf_ as same as Panda did. I don't know how it succeeded in creating a file with a same name under same folder.

 

bonedriven: I am a bit confused. Are you saying that the autorun.inf file written by the Panda program was either erased or over written? Had you verified before this incident that the correct file was indeed in place and was inaccessible?

The file name you post is autorun.,inf_ If this is correct, it is not the correct name. It can only be autorun.inf

It's important to keep in mind that the autorun.inf is never the virus/trojan/malware. It is one part of the delivery system, not the executable that actually infects the PC.