| 會員  | MS 已經把 "NoDriveTypeAutoRun" 漏洞補好了 引用:
話說回來, 以上只是治標不治本, 所以防毒軟體還是有其重要性, 只不過由於小弟所使用的硬體跟不上潮流, 因此本身並不喜歡疊床架屋, 何苦另外又裝個專殺隨身碟病毒的軟體, 甚至第二套防毒軟體? 有用, 一套就夠了, 沒用, 除了討救兵之外, 檢討自己的操作習慣才是第一要務 引用:
| ||
| 回覆 |
| 會員 | 以下精彩文章, 礙於版權, 請自行前往 安全性監控: 跳島攻擊：廠商贈品袋的入侵誘惑 安全性監控: 跳島攻擊：防堵不當的依存性 Windows Vista fails to properly handle the NoDriveTypeAutoRun registry value Autorun.inf 和Shell32.dll 有關, 小弟的版本是6.00.2900.3241 (xpsp_sp2_gdr.071025-1248), 但小弟還無法確定Shell32.dll 是否就是元兇, 所以僅提供參考 |
| 回覆 |
| You can call me sexy baby | 回覆: 請問一下USB病毒之防範 說真的，kavo這類隨身碟病毒沒什麼特殊的 玩了那麼久，永遠都是那101招 買一套不差的防毒軟體，連特徵碼都不用更新 就能夠搞定了 |
| 回覆 |
| 會員  | 回覆: MS 已經把 "NoDriveTypeAutoRun" 漏洞補好了 引用:
2 一開始我也是看 Rogerspeaking 提供的訊息在半信半疑的狀況下針對 "NoDriveTypeAutoRun" 的屬性進行設定, 後來發現根本沒有任何差別, 一直到自己找原廠(Microsoft)文件並做實際測試(2008/01/28)後才初步確定沒用, 隨後不久又有人(曾義峰在 2008/03/25)進行類似測試並得到相同結果.. 3 現在單位內近 300 台電腦, 除了少數10幾部無法使用隨身碟外, 其餘電腦都可以自由使用 USB 隨身碟, 而且電腦的 "NoDriveTypeAutoRun" 已改回預設值... ... 在這種近狀況 300 台電腦由員工自由使用 USB 隨身碟的狀況下, 防毒主控台一直都有發現使用者 USB 隨身碟有病毒, 但是以今年來說, 還沒發現任何一台電腦系統本身因 USB 隨身碟的使用而中毒, 所以我才會很肯定的說改一些有的沒有的(NoDriveTypeAutoRun)是沒用的!! 此篇文章於 2008-05-26 12:06 AM 被 wscooch 編輯。. | |
| 回覆 |
| 會員 | 引用:
其實MountPoint2 方案在對岸文章出現得很早, 而 "NoDriveTypeAutoRun" 又修正得很晚, 小弟並未指稱你的結論有誤, 而是你測試的項目少了 "MountPoint2" 引用:
小弟自己更正一下, 原先以為問題在於Shell32.dll (KB943460), 後來又懷疑Explorer.exe (KB938828), 全部猜錯, 所以尚未找到是哪個修正程式, 繼續努力尋找中 | ||
| 回覆 |
| 會員  | 回覆: 請問一下USB病毒之防範 目前只有两个方法有效，一个是独立运行后台常驻程序，随时监控autorun，例如usbkiller之类。一个是修改磁盘数据，建立只读autorun.inf,目前只对fat32类型有效，参见http://bbs.et8.net/bbs/showthread.php?t=929213。 第二种方法比较新颖，跟往常见到的带小数点文件夹不同。 |
| 回覆 |
| 會員 | 回覆: 請問一下USB病毒之防範 引用:
USB 隨身碟病毒去年在我的服務單位造成我不少困擾, 問題的事先預防與事後解決都有很多種不同方式, 我一直試圖在兼顧安全與使用者便利的前提下, 用最少的時間解決多數的問題, 一開始從建立大量特定名稱目錄來防止病毒檔的產生開始, 然後是 autorun 的相關設定反覆摸索, 同時面對近300台電腦(說多不多,說少不少)的病毒處裡手法跟家用個人電腦的處理手法其實有很大的差異, 有些方法在一定的期間內的確產生預期的效果, 有的沒有, 假設每遇到不同類型的病毒就要去更改每台電腦的不同登錄值才能解決問題, 我的思考方向是立刻停止這種需要耗費大量人力的方法, 並開始評估不同的工具或方法來達成問題的預防或處裡, 或許 USB 隨身碟病毒的預防或解決真的可以或者是真的一定要去更改一些特定系統登錄值才能解決, 那我真的會恨死病毒作者,比爾蓋茲和眾多的防毒大廠, 並且審慎考量更換跑道.. 我的結論是: 在不更改系統設定的狀況下就可以透過防毒軟體達到防護目的狀況下, 何需去做那些修改? 認識問題的來龍去脈是好事, 但哪一種方式才能用最少資源解決多數問題, 朝這個方向去探索討論或許會有一些不同的意外收穫!! 此篇文章於 2008-05-27 08:26 PM 被 wscooch 編輯。. | |
| 回覆 |
| 會員 | 回覆: 請問一下USB病毒之防範 請問丫一大跟FYI大: 不知您是否有遇過被"映像劫持"的電腦~ 當某檔案名稱被劫持後~全部該名稱的檔案會打不開~ 不知把這技術用在防止autorun.inf上面~是否可行? |
| 回覆 |
| 會員 | 引用:
其實在wscooch 兄提到大量佈署的問題之前, 小弟就想回覆了, 但因為 "東施效顰" (學Mark 用Process Monitor) 不得其法, 所以遲疑了幾天 Mark's Blog : The Case of the Missing AutoPlay有些問題可以在登入網域之後, 由DC 加以控制, 例如群組原則, 不過由於 "NoDriveTypeAutoRun" & "NoDriveAutoRun" 的作用不完整, 所以目前只能另謀出路, 小弟不懂DC, 所以不知道DC 是否能夠停用客戶端的 "Shell Hardware Detection" 服務? 否則再加上由群組原則停用自動播放, 就可以完全關閉卸除式磁碟機和硬碟機的自動執行 如果您以Process Monitor 實驗, 就會發現自動執行之前, Rundll32.exe 會檢查兩個機碼, "RestrictRun" & "DisallowRun", 這兩個機碼都可以用來關閉特定名稱的程式", 但是kavo 變種太多, 因此成效不大, 真正有效的是由Nick Brown 所提出的: Nick Brown's blog: Memory stick worms也就是你所要的答案, 讓Windows (csrss.exe) 把Autorun.inf 視為單純的安裝資訊檔, 而不是自動執行檔, 也就不會自動執行 在Nick Brown 的文章中提到 "MountPoints2" (先前誤植為 "MountPoint2", 少了 "s") 會覆蓋 "NoDriveTypeAutoRun", 而由csrss.exe 檢查 "IniFileMapping" 機碼的行為來看, 很可能和 "Shell Hardware Detection" 服務有關, 因為只有在剛插入隨身碟時才會檢查 "IniFileMapping\Autorun.inf" 機碼, 而在小弟對於 "NoDriveTypeAutoRun" 的實驗中, 也發現似乎和 "Shell Hardware Detection" 的行為相關, 實驗步驟如下:
另一個避免不小心觸發自動執行的方法, 就是避免使用Windows 內建檔案總管, 改用第三方檔案管理程式, 小弟鄭重推薦 "xplorer² Lite", 在xplorer² 之中, 雙擊就是展開, 並不會執行Autorun.inf 之中的open 或shellexecute 指令, 但右鍵選單仍會受到Autorun.inf 影響 最後, 至於變更Everyone 群組的 "MountPoints2" 權限, 由於目前對於 "MountPoints2" 的研究有限, 既然有其他方法可以限制自動執行, 所以沒有必要修改 "MountPoints2" 權限 Steve Riley on Security : Autorun: good for you? Steve Riley on Security : More on Autorun Social Engineering, the USB Way - Desktop Security - Dark Reading | |
| 回覆 |
| 會員 | 建立無法存取的Autorun.inf, 阻止自動執行 引用:
其次, BlueFang 網友所介紹在卸除式磁碟建立無法刪除或變更的Autorun.inf (FAT16/FAT32), 方法是從磁碟的Directory Table 找到 "AUTORUN INF" 進入點, 然後將第12 個位元組, 也就是檔案屬性(00ADVSHR), 原來是0x20, 代表Archive, 改成0xE5 或0xE2, 按照小弟的實驗, 以上技巧在於設定未定義(公開)的位元(Bit6, Device), 導致作業系統無法存取Autorun.inf (存取被拒), 這個方法不但可以愚弄Windows XP, 也可以通過磁碟檢查, 這就達到為卸除式磁碟打預防針的目的, 實在是一個聰明的辦法, 當然結果並非完全免疫, 而是免於自動執行, 操作步驟如下:
8.3 filename - Wikipedia, the free encyclopedia | |
| 回覆 |
| XML | RSS 2.0 | RSS |
本論壇所有文章僅代表留言者個人意見，並不代表本站之立場，討論區以「即時留言」方式運作，故無法完全監察所有即時留言，若您發現文章可能有異議，請 email :[email protected] 處理。
