知乎、UAC 和 Windows 安全

首先，LZ 是个外行逗比，下面写得几乎没啥逻辑……如果你的时间宝贵，最好还是别浪费时间接着读了。
很欢迎各位 V 友前来吐槽，不过希望你们遵循 V2EX 的规则，多带来一些信息量。

知乎逛多了，LZ 就慢慢被灌输了这样的观念：
现代 Windows 很安全，有 UAC+SmartScreen+Windows Defender 这种立体防护，有 ASLR、DEP、SafeSEH 等等缓解漏洞利用的安全机制，还有 SecureBoot、Kernel Patch Protection （ PatchGuard ）、Driver Signature Enforcement，几乎无懈可击。

“关闭 UAC 等于把 Windows 的安全级别降到 Windows 98 水准”、“国产全家桶使用 Flash 漏洞等邪恶手段绕过 UAC ”

直到有一天，我发现了某人的 Github： https://github.com/hfiref0x
UAC 被完美绕过。
DSE 被不完美绕过。

再稍微搜索一下：
https://github.com/tandasat/PgResarch
http://www.nosuchcon.org/talks/2014/D2_01_Andrea_Allievi_Win8.1_Patch_protections.pdf
原来 Win7、8.1 的 PatchGuard 早在 2014 年就被完全破解了。

至于 SecureBoot，微软也泄露过一个不该泄露的东西：
https://rol.im/securegoldenkeyboot/

看完这几个东西，瞬间被刷新三观…… LZ 感觉系统安全似乎只能仰仗 Windows Defender 和 SmartScreen 了——然而，知乎里不少答案的观点都是 Windows Defender 只提供基础防御，甚至还有 WD 只杀病毒不杀流氓等诡辩说法出现。

而且，杀软真的靠谱么？
http://bobao.360.cn/learning/detail/3407.html
也许可以指望主动防御拦截可疑的网络请求，但至少“扫描”看上去被完全击败了。

其实，稍微反思一下，就会发现 UAC 的意义其实很有限——无论是截屏、按键记录还是窃取、破坏个人文件，UAC 都不会过问。
但逛完知乎，LZ 就形成了一种印象，感觉 UAC 就是系统的保护伞……
DSE、PatchGuard 这些机制具体起了多大作用，LZ 也说不好，但 LZ 现在已经不相信它们能让系统变得更安全了。

《 Windows 内核设计思想》这本书的序里这么写道：
如果你觉得 Windows 的 64 位版驱动要验签名了，内核有 PatchGuard 了，所以更安全了；如果你觉得你用的是“水果”，不越狱所以固若金汤；如果你觉得 Android 不 root 就是安全的，我只能说你还处于蒙昧无知的状态。如果你感觉到了哪里可能会有漏洞，而你可以一一填补，说明你混沌初开了。如果你像某些大公司的系统设计员一样，忽然冒出一个前无古人的想法，认为这样可以一劳永逸地解决安全问题，说明你开始了独立思考，可以着手安全问题了！如果你终于回到现实，甘愿像被缚的普罗米修斯一样，今夜痊愈，明日又开始新一轮的开膛破肚，永无休止，那你终于走上了正途！
（ https://book.douban.com/reading/34279756/）
现在 LZ 好像稍微理解一点这段话的意思了。不过，随便挑个问题问 LZ，LZ 也是一问三不知……

写了那么多，不知道写了啥，强行总结一下吧：
逛知乎虽然能让 LZ 注意到系统里有 UAC、DSE、PatchGuard 这些东西，但是——
知道了这些并不能让 LZ 用电脑比以前更舒心。
不管怎样，LZ 养成了双击 exe 之前非得看看数字签名是否有效等麻烦的习惯，不过这似乎也不会给自己带来太多实在的好处……

acess

2017-04-30 18:27:44 +08:00

@wevsty
Minifilter 看上去确实可以拦截到 IRP_MJ_CREATE ……这一点一开始我理解错了。

开了 Process Monitor，它的确拦截到了打开\Device\Harddisk0\DR0 的 IRP_MJ_CREATE。
PCHunter 的文件系统->微端口过滤器可以看到属于 PROCMON23.SYS 的项目，包括 IRP_MJ_CREATE PreFun、IRP_MJ_CREATE PostFun 等。

不过，调用链好像和您说的不太一样？
Process Monitor 的内核调用栈看起来是这样的：
FLTMGR.SYS!FltpPerformPreCallbacks
FLTMGR.SYS!FltpPassThroughInternal
FLTMGR.SYS!FiltpCreate
ntoskrnl!IopParseDevice
ntoskrnl!ObpLookupObjectName
ntoskrnl!ObOpenObjectByNameEx
ntoskrnl!IopCreateFile
ntoskrnl!NtCreateFile
ntoskrnl!KiSystemServiceCopyEnd
下面就是用户层了：
ntdll!NtCreateFile
KernelBase.dll!CreateFileInternal
KernelBase.dll!CreateFileW
KernelBase.dll!CreateFileA
……

结合这里的一张描述 Filter Manager 的图……
http://bobao.360.cn/learning/detail/3403.html
猜测到这里可能只是执行了 Minifilter 的 PreOperation，还没真正给下层驱动发送 IRP ？

acess

2017-04-30 21:38:11 +08:00

@wevsty
又打开 Process Monitor 试了一下……
看上去 Minifilter 还是可以拦截 IRP_MJ_WRITE 的？ Process Monitor 中显示的路径确实是\Device\Harddisk0\DR0
软件显示的内核调用栈如下：
FLTMGR.SYS!FltpPerformPreCallbacks
FLTMGR.SYS!FltpPassthroughInternal
FLTMGR.SYS!FltpPassThrough
FLTMGR.SYS!FltpDispatch
ntoskrnl.exe!IopSynchronousServiceTail
ntoskrnl.exe!NtWriteFile
ntoskrnl.exe!KiSystemServiceCopyEnd

我当时用 gdisk 打开了硬盘（\\.\PhysicalDrive0 ），稍微修改了一下 GPT 分区表，然后让 gdisk 写入了修改。

我还尝试过用 PCHunter 摘除 PROCMON23.SYS 的微端口过滤器，不过看上去在我摘除过滤器后这个驱动又重新把它注册回去了，所以没能通过这个方法验证是不是微端口过滤器拦截了 IRP_MJ_WRITE。
搜了一下，找到了 MSDN 上关于 Minifilter 的文档：
https://docs.microsoft.com/zh-cn/windows-hardware/drivers/ifs/filter-manager-concepts
看上去 Windows 搞了一个 Filter Manager 专门来处理过滤、拦截有关的事情……

wevsty

2017-04-30 22:31:42 +08:00

@acess
file system filter drivers 有好几种。
微软的文档表示，legacy file system filter drivers can ’ t attach to direct access (DAX) volumes。
我仔细翻阅了一下文档看来是我有点想当然了，File System Filter Drivers 里面要看你把驱动 attach 到什么地方。
如果只把 Filter Device Object Attach 到 File System，那么就只能拦截 IRP_MJ_CREATE 之类的不能拦截 IRP_MJ_WRITE。
如果 Filter Device Object Attach 到 Volume 上，那么就可以拦截 IRP_MJ_CREATE。
File System Minifilter Driver 也是类似的情况，看开发者怎么使用了
我表示没有调试过，IRP_MJ_WRITE 的具体拦截情况，看文档应该是有办法拦的，但是实际上我会觉得拦截 IRP_MJ_CREATE 这样的请求意义不是很大，绝大多数的程序不需要直接进行底层磁盘写入，如果要驱动来判断直接写入扇区是不是应该允许未免是个巨大的工程。一般不需要在这一步进行拦截，如果只是为了防止写入，拦截 IRP_MJ_CREATE 就足够了。