Blackbird
Built for Speed
Premium
join:2005-01-14
Fort Wayne, IN
 ·Verizon Online DSL
1 edit | reply to mysec
Re: Disabling 'Autorun' on USB and beyond. Need help.
said by mysec  :My conclusions: ... 2) TweakUI to disable the drive if you want to prevent the drive from executing the AutoRun.inf file. ... Question: do you or anyone else know for sure if the TweakUI settings persist in spite of the MountPoints2 key possibly over-riding various Windows settings, as Nick Brown noted in EGeezer 's »Blocking autorun link and Scott Dunn referred to in Shriyash 's »windowssecrets.com/comp/071108 link? I've got a friend in a 3rd-World country who's wrestling right now to protect against USB-drive malware that keeps appearing on flashdrives being exchanged with government ministries... govt malware protection is virtually non-existent there. Some of these drives pass back and forth multiple times, so if MountPoints2 stored data over-rides other settings and allows autorun.inf to run on a USB drive that's been plugged into their computer before, that presents a real threat to using TweakUI or similar in that locale. Using the IniFileMapping\AutoRun.inf reg-fix EGeezer noted above would probably be their only simple answer... but I'd really like to know for sure.
--
If God wanted us to work with electrons, He'd make them big enough to see... |
|
mysec
Premium
join:2005-11-29
2 edits | I read both the article and blog when they appeared.
Nick refers to the NoDriveTypeAutoRun key but not the NoDriveAutoRun key.
I've tested with the latter and have not found it to be overridden.
Regarding your friend: is he concerned about his own computer, or government computers?
If his own, just install a White List execution prevention program and he's safe.
----
rich |
|
HelloI
@com.cn | reply to Shriyash
asd |
|
OZO
Premium
join:2003-01-17
| reply to Shriyash
Re: Related articles
said by Shriyash :said by mysec :1) The IniFileMapping\AutoRun.inf key which tells Windows that AutoRun.inf file does not exist Got it.  ... It may be the only reliable solution (and you may just forget about the rest of the others if you use this one), but there is one drawback that stops me from using it.
If you apply it - you'll lose the ability to:
1) see a new drive label (potentially defined within AutoRun.inf)
2) see a new icon (potentially defined within AutoRun.inf)
3) see new context menu items (potentially defined within AutoRun.inf)
4) (and most importantly!) - run that startup program when you need it and you're confident that it's a legitimate one (eg. Windows OS or Office setup disk).
Applying the registry change ("NoDriveTypeAutoRun" value) would be the right solution in case if m$ wanted to fix the known potential problems with it. I just hope it will happen some day...
--
Keep it simple, it'll become complex by itself... |
|
Blackbird
Built for Speed
Premium
join:2005-01-14
Fort Wayne, IN
·Verizon Online DSL
| reply to mysec
Re: Disabling 'Autorun' on USB and beyond. Need help.
said by mysec :I read both the article and blog when they appeared. I've tested many times with my XP laptop and have never found the mountpoints2 entries to stick once the CD is removed from the drive, or USB drive unplugged. Nick doesn't elaborate on the cache setting, so I don't know what he is referring to. Regarding your friend: is he concerned about his own computer, or government computers? If his own, just install a White List execution prevention program and he's safe. ---- rich It's their own computer they're trying to protect. They've been attacked 3 times in recent days, and there's a concern that sooner or later their AV may not hold against the flood... the most recent attack was related to an autorun-triggered Win32/PSW virus varient that only made it onto their AV's signature list three days or so before the attack occurred.
There seems to be a number of things that affect the vulnerability of a computer to autorun-related malware. Obviously, Brown and Dunn seem to think there's a way for the MountPoints2 key to over-ride other settings. Your experience seems to show otherwise. It's never easy, is it? 
I guess I need to dig more deeply into the whitelisting approach... though I'm not sure how easy that will be for them to acquire and install where they are.
--
If God wanted us to work with electrons, He'd make them big enough to see... |
|
mysec
Premium
join:2005-11-29
| reply to OZO
Re: Related articles
said by OZO :If you apply it [The IniFileMapping\AutoRun.inf key] - you'll lose the ability to: ...
Also, it's a "sticky" fix - that is, you can't just merge a .reg file to remove the key - you have to also reboot - not convenient for those who want to block AutoRun only for unknown devices and leave it to work for normal operations.
The TweakUI settings can be toggled w/o a reboot.
said by Blackbird :There seems to be a number of things that affect the vulnerability of a computer to autorun-related malware. Obviously, Brown and Dunn seem to think there's a way for the MountPoints2 key to over-ride other settings. Your experience seems to show otherwise. It's never easy, is it?
It's wise to do your own testing, when possible.
Dunn just quotes Brown - he didn't do any testing to confirm.
Brown didn't give details or screenshots to explain what he means.
said by Blackbird :I guess I need to dig more deeply into the whitelisting approach... though I'm not sure how easy that will be for them to acquire and install where they are.
A simple way would be to run as Limited User, where no executable not already on the computer can install.
Also, programs using White Listing can be downloaded/installed from the internet. See the other anti-malware software thread at Wilders Forums for discussions of products.
----
rich |
|
planet
join:2001-11-05
Olmsted Falls, OH
 ·Cox HSI
| mysec, thanks for further discussion regarding TweakUI. I am using it now to disable autoplay on specific drive letters and drives themselves. I also typically run in a limited user account which is a further safeguard. I don't intend to use the reg tweak at this time myself.
|
|
Name Game
Premium
join:2002-07-07
North Myrtle Beach, SC
1 edit | reply to Shriyash
Re: Disabling 'Autorun' on USB and beyond. Need help.
Case history in progress>>>
Another bloodhound.packed.jmp issue, Cannot access hidden files and hard drive
»gladiator-antivirus.com/forum/in···ic=70868
Now he is finally asking the right questions after his PC was cleaned..
Questions:
After a computer scare, I have been hesitant to use my USB on my computer, since the computer obtained a virus around the time I used the USB on the computer. Whether it was the USB or not, I don't know. Now, here's the problem: I have University assignments INSIDE the USB. My question is: Do USBs infect computers by putting them in the hard-drive slot, or does the outbreak occur when opening a file within the USB? (Powerpoint presentations and Word documents)
I need to know this, so I can confirm whether I'll have to schedule time at the library to work solely on the computers there. If it's the latter case (preferably), then I can insert it and then scan it and fix the USB (somehow) before really opening up and continuing to work on my projects.
I'm not asking for a solution, since I don't have a problem (per se). I just need to know when EXACTLY do infected USB drivers affect computers (upon insertion or upon opening a file inside the USB)?
Greatly appreciate any help!
»gladiator-antivirus.com/forum/in···=201462&
--
Gladiator Security Forum »www.gladiator-antivirus.com/
Missing Kids
»www.missingkids.com/ |
|
Shriyash
Sungazer
Premium
join:2005-02-23
PuNe, InDiA
| said by Name Game :Now he is finally asking the right questions after his PC was cleaned.. Yes, and i hope he will soon breathe easy,
as discovering the NoAutoRun.reg solution is just a click away for him!
--
Alex Jones Bullhorning Bilderberg.
»www.jonesreport.com/articles/211···erg.html |
|
Name Game
Premium
join:2002-07-07
North Myrtle Beach, SC |  Yup...
I hope the College Library PC's also feel the same. 
Thanks for your thread Shriyash |
|
Shriyash
Sungazer
Premium
join:2005-02-23
PuNe, InDiA | Im just thankful that as always,
the knowledgeable folks here at DSLR came to help me out,lol  |
|
EGeezer
Summertime -
Premium
join:2002-08-04
Country!
 ·Callcentric
·RoadRunner Cable
·AT&T CallVantage
| reply to Name Game
I note in the bloodhound.packed.jmp issue, the infected user was running a security suite. You and I remember the days when viruses were spread by sneakernetting diskettes. Unfortunately, despite all the progress in fancy GUIs, slick effects in operating systems, snazzy web pages and massive security "suites", Sneakernet still works.
--
Mayors of New York come from nowhere and go nowhere.
Wallace Sayre (apparently, so do governors... ) |
|
Name Game
Premium
join:2002-07-07
North Myrtle Beach, SC
1 edit | said by EGeezer :I note in the bloodhound.packed.jmp issue, the infected user was running a security suite. You and I remember the days when viruses were spread by sneakernetting diskettes. Unfortunately, despite all the progress in fancy GUIs, slick effects in operating systems, snazzy web pages and massive security "suites", Sneakernet still works. Exactly..and this bloodhound.packed.jmp with the auto crap is coming on strong...This is only our hijackthis help forum look..
»gladiator-antivirus.com/forum/in···orum=170
and so many of the new posts for help are about this one.
I have not seen a badboy come on this strong for a while and I think as you and others have pointed out..it is only the tip of the iceberg and it will soon come to a theatre near you.
It is of course that packer those suite have to start understanding if the want their users to stop being infected. But once the stuff is on a public system..or on those USB drive storage devices..then even the innocent users are whacked and spreading joy through out the land.
--
Gladiator Security Forum »www.gladiator-antivirus.com/
Missing Kids
»www.missingkids.com/ |
|
Name Game
Premium
join:2002-07-07
North Myrtle Beach, SC
| reply to Shriyash
as a review...
Discovered: January 19, 2004
Updated: February 13, 2007 12:16:26 PM
Type: Trojan Horse, Worm, Virus
Systems Affected: Windows 2000, Windows 95, Windows 98, Windows Me, Windows NT, Windows Server 2003, Windows XP
Symantec antivirus products exclusively use the virus name Bloodhound.Packed when a potentially unknown virus is found using Symantec Bloodhound technology. Bloodhound technology consists of heuristic algorithms used to detect unknown viruses. The actual file detected under Bloodhound.Packed is likely to be infected with a new, packed, 32-bit Windows virus.
Bloodhound.Packed is detected only in Portable Executable (PE) files. Bloodhound.Packed can detect any threat within a packed file.
What are Portable Executable (PE) files?
Portable Executable (PE) files are files that are portable across all the Microsoft 32-bit operating systems. The same PE-format executable can be executed on any version of Windows 95, 98, Me, NT, 2000, and XP. All the PE files are executable, but not all the executable files are portable.
--
Gladiator Security Forum »www.gladiator-antivirus.com/ Missing Kids »www.missingkids.com/ |
|
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... |
|
