EGeezer
Go Bobcats
Premium
join:2002-08-04
Country!
 ·Callcentric
 ·RoadRunner Cable
·AT&T CallVantage
| reply to Shriyash
Re: Disabling 'Autorun' on USB and beyond. Need help.
AutoRUN is not the same as autoPLAY. I suggest a full read of the topic »Blocking autorun
--
Mayors of New York come from nowhere and go nowhere.
Wallace Sayre (apparently, so do governors... ) |
|
Shriyash
Sungazer
Premium
join:2005-02-23
PuNe, InDiA
| OH!
i didnt realize that Autorun is NOT the same as Autoplay 
Thanks for posting this link EGeezer.
»windowssecrets.com/comp/071108
Quote from the above website:
...Unfortunately, simply turning off AutoPlay, a separate feature, isn't enough to prevent AutoRun from introducing a rogue program into your system.
...In XP, you can change the defaults for AutoPlay on a given drive by right-clicking the drive in Windows Explorer and choosing Properties. Click the AutoPlay tab and use the controls there to change the settings for different types of media.
Making changes in this dialog box, however, has no effect in preventing autorun.inf from being executed. And heres the solution too.
(quoted from the article).
Block AutoRun for all devices all the time
You might think that you could proect yourself from AutoRun by using two keys in the Registry known as NoDriveAutoRun and NoDriveTypeAutoRun.
However, self-described "low-budget hacker" Nick Brown points out that these keys can be overridden. A Registry key named MountPoints2 stores information about all USB flash drives and other removable media that have ever been connected to your computer. Brown says this cache overrides the Registry settings that turn off AutoRun.
The solution is to globally block autorun.inf files from executing, without trying to use the dialog boxes in XP and Vista to do this. Here's the procedure:
Step 1. Start Notepad or another text editor.
Step 2. Copy the following text from this page and paste it into your text editor (everything between the square brackets should be all on one line):
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"
Step 3. Save the file with a name like NoAutoRun.reg, taking care to include the .reg extension.
Step 4. Right-click your .reg file and choose Merge. Confirm any warning prompts to add the information to the Registry.
The next time you insert a flash drive, CD, DVD, or other removable disc into your system, Windows will not execute the information in any autorun.inf file that may be present. 
Naturally, taking these steps means that the next time you put a game or installer disc into your CD or DVD drive, its software won't launch automatically. You'll have to open a Windows Explorer window or use a command line to launch the desired executable.
The benefit is a big one: a rogue program that you never intended to launch won't silently take over your system if you happen to insert a Trojan-carrying disc into a drive. |
|
OZO
Premium
join:2003-01-17
| reply to EGeezer
Yes, it's important to distinguish Autoplay from Autorun.
Autoplay is the way of starting (default) application from your computer based on the type of content in attached drive. You may keep Auptoplay always 'on' without ill effects.
Autorun - on the other side - is very dangerous and actually is an automatic way to be infected by potential malware. It's because by allowing Autorun you allow automatic execution of an application resided on the new attached media (e.g. USB drive).
To block Autorun from unexpected execution of potential malware you may want to change this registry value:
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoDriveTypeAutoRun"=dword:B1
Unfortunately even with this setting (and due to current implementation of this feature by m$) there still be risks of running a malware. Read this my post explaining my point with some details.
--
Keep it simple, it'll become complex by itself... |
|
EGeezer
Go Bobcats
Premium
join:2002-08-04
Country!
·Callcentric
·RoadRunner Cable
·AT&T CallVantage
| reply to Shriyash
said by Shriyash  :OH! i didnt realize that Autorun is NOT the same as Autoplay Thanks for posting this link EGeezer. Well, I can't take full credit for the distinction between the two - Wildcatboy and NickBrown 's posts in particular provided me with a better understanding of the two functions (although we might vary on our opinions of how much of an exposure autorun may be).
--
Mayors of New York come from nowhere and go nowhere.
Wallace Sayre (apparently, so do governors... ) |
|
mysec
Premium
join:2005-11-29
3 edits | reply to Shriyash
NoDriveTypeAutoRun and NoDriveAutoRun
Scott Dunn writes in the Windowssecrets newsletter,
You might think that you could protect yourself from AutoRun by using two keys in the Registry known as NoDriveAutoRun and NoDriveTypeAutoRun.
However, self-described "low-budget hacker" Nick Brown points out that these keys can be overridden.
A careful reading of Nick Brown's blog reveals he mentions only NoDriveTypeAutoRun.
Here is the pertinent stuff from the blog:
Now, in theory you can prevent certain drive types from executing the contents of their AUTORUN.INF files using a registry value (NoDriveTypeAutoRun). But... a little-known registry key called MountPoints2 contains cached information about every memory stick or other removable device which your PC has ever seen, and that overrides the NoDriveTypeAutoRun value if you insert a volume which the PC already knows about.
I decided to investigate this further.
Test 1
I plug in one of my USB backup drives with AutoRun enabled for all media.
(NoDriveTypeAutoRun dword value = 91)
I have an AutoRun.inf file on the drive which customizes the context menu. Here is the entry in the Mountpoints2 Key in the Registry which Nick Brown refers to. Note the _AutorunStatus value:
______________________________________________________________
The Shell commands configure the context menu:
______________________________________________________________
Test 2
I unplug the drive, reboot, and configure NoDriveTypeAutoRun
using TweakUI: My Computer|Autoplay|Types
to disable Removeable Media. (dword value = 95)
I plug in the drive and I get the same result as in Test 1: Nick Brown is correct: the PC has cached information about this drive which overrides the NoDriveTypeAutoRun setting.
Test 3
Same as Test 2 but I configure NoDriveAutoRun using TweakUI: My Computer|AutoPlay|Drives
to uncheck my USB drive.
I plug in the drive, the AutoRun.inf file does not execute, and, the _AutorunStatus value has changed:
____________________________________________________________________
My context menu has not been customized:
____________________________________________________________________
Repeated tests show the same results. With NoDriveAutoRun configured to uncheck that drive, the Autorun.inf file cannot be read by the PC.
Back to Nick Brown's statement:
...if you insert a volume which the PC already knows about.
What about a drive that the PC has not seen.
Suppose you purchase a digital picture frame, or a pendrive which is infected. What happens when you plug it in for the first time?
Test 4
With NoDriveTypeAutoRun configured to disable removeable media (dword value = 95), I plugged in a new Pen Drive, the drive folder did not open automatically, and nothing was written to it's key in Mountpoints2. To me, this makes sense, since there is no prior cached information on this drive.
More testing with different devices needs to be done to confirm this.
(I did not investigate the known bugs associated with NoDriveTypeAutoRun)
Nonetheless, configuring NoDriveAutoRun to uncheck that drive letter blocks in all cases.
Conclusions
1) Scott Dunn's statement that both keys can be overridden is not correct.
2) While Nick Brown is correct with regard to the NoDriveTypeAutoRun key being overridden, it would seem that a device plugged in for the first time would not be vulnerable to this.
Also, he omitted mentioning the NoDriveAutoRun tweak which effectively blocks the AutoRun.inf file from running in any case.
(These assertions are welcome to challenge if someone can create a situation in which they fail).
3) In the corporate world, I agree that Nick Brown's Registry Tweak
@="@SYS:DoesNotExist"
is preferable, for the reasons he lists.
For the home user who normally enables Autorun, TweakUI provides a quick way to toggle the NoDriveAutoRun settings if desired when using unknown CDRom or removeable media.
----
rich |
|
HA Nut
Premium
join:2004-05-13
USA | mysec: Thanks for the test! This is why this site is such a great resource! |
|
OZO
Premium
join:2003-01-17
| reply to mysec
mysec - you're doing great job testing autorun functionality and thank you for sharing your results with us. It's interesting to know how a new and/or old USB drive is treated by OS. Is an info from a drive is collected and kept (and for how long) in "MountPoints2" subkey? Will autorun.inf file be interpreted by WE? There is no doubt that all of this is interesting to know. But I think the most important thing (at least for this forum) is to focus on just one thing particularly - will WE/OS allow an unexpected automatic action (like giving control to an application from USB or CD/DVD) without prior user consent or there is a sure way to protect user from this action?
The way I see it - there should be guaranteed way that blocks any automatic execution of a program from removable media. And - is it an old media or a new one, is it USB or CD/DVD, is it drive F:, drive G: or drive Z: - all it doesn't matter. If you agree with setting that simple goal, let's find the way.
What is not important in pursuing the goal (and therefore should be discarded from investigation):
1) user makes a double click on unknown program in removable media effectively starting it;
2) WE interprets autorun.inf file and changes menu by adding new item(s) allowing user to execute program from removable media by clicking on the item.
In all cases above user can make a deliberate decision to run an application and it's his responsibility to run anything he wants. We should not be concerned about it.
From this perspective interpretation of autorun.inf file by WE is not an evil that we should be fighting against. The only thing from that interpretation that should be certainly blocked is automatic way of starting a program (particularly the lines with 'open=' or 'shellexecute=' or similar statements). Again, changing drive label, changing its icon, adding new menu items that may be done via autorun.inf file - it's not a problem at all (at least to me). The only exception is one dangerous case of substituting old "Open" and/or "Explore" menu item(s) that may be potentially dangerous (due to unexpected action in this case). See my post for more details on how to do this. But interpretation of autorun.inf file itself is not a problem.
If we narrow our focus - it'd be easier to achieve the goal - to make our computers more secure. Do you agree with that?
--
Keep it simple, it'll become complex by itself... |
|
mysec
Premium
join:2005-11-29
| said by OZO :It's interesting to know how a new and/or old USB drive is treated by OS. Is an info from a drive is collected and kept (and for how long) in "MountPoints2" subkey? Will autorun.inf file be interpreted by WE? There is no doubt that all of this is interesting to know.
Thanks for your comments and insights.
I don't know the answer to that - it may depend on a lot of things. Because of the uncertainty, I would not depend on consistent action here for security of any kind.
said by OZO :The way I see it - there should be guaranteed way that blocks any automatic execution of a program from removable media. And - is it an old media or a new one, is it USB or CD/DVD, is it drive F:, drive G: or drive Z: - all it doesn't matter. If you agree with setting that simple goal, let's find the way.
I've said before that Autorun.inf, iFrame, .ani (animated cursor), etc... have this in common: to run a program by remote code execution.
Each has a "fix":
Autorun.inf by disabling Autorun by some tweak or other
iFrame by patch from MS, or browser tweak
etc...
I would never depend on these as a last line of defense. Too many things can go wrong. Settings become changed, etc. Especially if more than one user on the computer.
Besides, what about the next new remote code execution exploit that is zero-day for a period of time? Remember the .wmf explolit?
The only sure-fire protection is White Listing,where no executable not White Listed can run. Period.
Using a TrendMicro analysis of a pendrive Autorun.inf exploit, I happened to get the trojan downloader file from another person to test.
Here is the Autorun.inf file:
I put it along with the trojan file on a CD and let it Auto Run:
_________________________________________________________
This is the only way that, to use your phrase. I would guarantee blocking any automatic execution of a program from removable media. Or from any other source.
----
rich |
|
Blackbird
Built for Speed
Premium
join:2005-01-14
Fort Wayne, IN
 ·Verizon Online DSL
| reply to mysec
said by mysec :... Conclusions1) Scott Dunn's statement that both keys can be overridden is not correct. 2) While Nick Brown is correct with regard to the NoDriveTypeAutoRun key being overridden, it would seem that a device plugged in for the first time would not be vulnerable to this. Also, he omitted mentioning the NoDriveAutoRun tweak which effectively blocks the AutoRun.inf file from running in any case. ... Thank you for your tests - excellent documentation and careful reasoning! While there are probably unknowns and untested issues, it is encouraging to see Mountpoints2's Autorun Status value changing when you do the NoDriveAutoRun setting in TweakUI... at least something is communicating between TweakUI and that key, and your test results indicate the "something" has to do with blocking autorun.
I agree that the NoDriveAutoRun key isn't mentioned in Brown's blog... possibly the similarity between the two key names (NoDriveAutoRun and NoDriveTypeAutoRun) has created confusion for people.
Regarding your #2 Conclusion... sneaker-net situations (like my friend's, in the 3rd World country) do exist all too often. And in those situations, frequently a given flashdrive will move back and forth as a simple transport device for collaboration/review of documents. So if computer A is 'clean' and places a document on a freshly-"installed" flashdrive, if that flashdrive moves into an infected computer B for editing the document, the flashdrive will become infected. Then when that flashdrive moves back into computer A, an autorun.inf infection would do an end-run around the NoDriveTypeAutoRun reg setting via the MountPoints2 over-ride behavior. While initial protection would be afforded by the NoDriveTypeAutoRun key setting, subsequent exposures to the later-infected flashdrive's autorun would occur. This is the exact usage situation my friend is having to deal with: a flashdrive is moving back and forth between them and government ministry computers.
The IniFileMapping key fix will evidently block all autoruns from occurring. Now I'm increasingly confident that your TweakUI approach will work effectively as well on specific drives, based on your tests and your pointing out the 2-key error Dunn made about Brown's work in his (Dunn's) writeup. Particularly, your TweakUI NoDriveAutoRun approach offers the clear advantage of ease-of-use and re-setability. And certainly, white-listing (as I'm coming to understand it) will totally block this and a lot of other problems.
This has been a very enlightening thread thus far, and it's begun to dispel a lot of confusion I'd retained from earlier threads. My appreciation goes out to Shriyash as well for his original post!
--
If God wanted us to work with electrons, He'd make them big enough to see... |
|
OZO
Premium
join:2003-01-17
| reply to mysec
Unfortunately you did not mention what was the data set for the value "NoDriveTypeAutoRun" in your last test. And this is important to interpret the test results.
I've repeated the test similar to yours (actually the same I've done before my post here) and here are my results:
--- With "NoDriveTypeAutoRun"=dword:ff
1) notepad.exe is not launched automatically when I insert CD/DVD with autorun.inf (see its content below)
2) notepad.exe is launched when I made click on My Computer | E: which is completely unexpected
3) notepad.exe may be started by clicking on replaced "Open" menu item (user doesn't want that)
4) notepad.exe may be started by clicking on replaced "Explore" menu item (user doesn't want that)
Cases #2 - 4 must be fixed by the developer of the OS !
--- With "NoDriveTypeAutoRun"=dword:91 (default for WXP2)
1) notepad.exe is launched automatically when I insert CD/DVD with autorun.inf (see its content below) - as expected.
The rest of results are the same as above.
Here is content of autorun.inf file:
Here is the picture:
AutoRun
In this test I was using only "NoDriveTypeAutoRun" value placed in this key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer]
I do not modify / use "NoDriveAutoRun" value.
And finally, because I do not block interpretation of autorun.inf file I'm able to see new drive label (see picture above), as well as its new icon (from notepad.exe in this case) and have all new menu items in context menu. Which is the way it should be.
--
Keep it simple, it'll become complex by itself... |
|
mysec
Premium
join:2005-11-29
| said by OZO :Unfortunately you did not mention what was the data set for the value " NoDriveTypeAutoRun" in your last test. And this is important to interpret the test results.
Last test (4) - same as Test 2,3:
CD/DVD drive enabled, Removable Drives disabled in TweakUI, dword value = 95
I just now included this with the tests.
Other settings in TweakUI:
Both CD/DVD and Removable drives enabled, dword value = 91.
With CD/DVD disabled and Removable Drives enabled, dword value = b1
With both disabled, dword value = b5
|
|
OZO
Premium
join:2003-01-17 | Thanks |
|
mysec
Premium
join:2005-11-29
| reply to OZO
said by OZO :--- With "NoDriveTypeAutoRun"=dword:ff1) notepad.exe is not launched automatically when I insert CD/DVD with autorun.inf (see its content below) 2) notepad.exe is launched when I made click on My Computer | E: which is completely unexpected 3) notepad.exe may be started by clicking on replaced "Open" menu item (user doesn't want that) 4) notepad.exe may be started by clicking on replaced "Explore" menu item (user doesn't want that) Cases #2 - 4 must be fixed by the developer of the OS !
I disagree: The behavior you describe is by design so that the context menu can be customized by including Shell commands in the Autorun.inf file. I would not want that useful feature to be "fixed!"
----
rich |
|
OZO
Premium
join:2003-01-17
| There is no disagreement!
The behavior I've described is by design, so that the context menu can be customized by including Shell commands in the Autorun.inf file. I would not want that useful feature to be "discarded" as well. But, as you can see, I did emphasize the words "replaced" and did it for a purpose.
If a malware is able to replace two well known menu items that I've mentioned - user is in potential trouble. By clicking on those items user expects that drive will be opened/explored by WE. But, instead of that, what he may get is an unexpected execution of a program from removable media. Just simple like that. And that's dangerous.
That's why I said that the functionality must be fixed. There should be a protection from 'replacement' those well known menu items by autorun.inf file.
--
Keep it simple, it'll become complex by itself... |
|
mysec
Premium
join:2005-11-29
| said by OZO :There is no disagreement!... But, as you can see, I did emphasize the words " replaced" and did it for a purpose.
OK, I see your point.
By clicking on those items user expects that drive will be opened/explored by WE. But, instead of that, what he may get is an unexpected execution of a program from removable media. Just simple like that. And that's dangerous.
This is why White List protection will always prevent the unexpected execution of a program from any media or source. Simplest way is running as a Limited User. Other solutions involve security programs with Execution protection.
Other precautions when using unknown removable media:
1) Use TweakUI toggle the NoDriveAutorun setting for that drive. No Shell commands in the Autorun file will be executed.
2) Instead of clicking on the drive letter in My Computer, open to the drive in Windows Explorer, which is just a Tree View of My Computer. The contents of the drive highlighted in the left pane are displayed in the right pane. No right-context menu items are invoked.
You can create shortcuts to open to any directory/drive in Explorer View. Here, opening to D:\
%windir%\explorer.exe /e, D:\
The /e switch opens the drive in "expanded" or Tree View.
----
rich |
|
OZO
Premium
join:2003-01-17
| You're right - White List protection surely may help. As well as advice do not click on drive in My Computer, open to the drive in Windows Explorer instead. But not everyone runs a special program that supports a White List and not everyone remembers the rule - do not open a drive from My Computer, which may be a common practice (though personally I never do it, I respect others opinions who do it and why not). I'd call all of these - additional layers of protection.
My point here is if the basic layer is broken - it should be fixed first. And solution should be simple like marking one check box in Folder Options dialog box (see my picture below):
Folder Options - Autorun
--
Keep it simple, it'll become complex by itself... |
|
R2
R Not
Premium,MVM
join:2000-09-18
Long Beach, CA
clubs: | reply to mysec
Sorry, can I back up a step? Tweak UI's NoDriveAutoRun seems to be as helpful as the "DoesNotExist" .reg file -- yet is does not require a reboot. Is that correct? Thanks. |
|
mysec
Premium
join:2005-11-29
1 edit | Yes - as noted here on WinXP SP1. |
|
