Vista发现之旅：管窥UAP功能

　　为了让读者诸公更好地享用后面的“正餐”，这里先上“开胃酒”，简单介绍一下UAP的功能。UAP（用户帐户保护）可以说是采用逆向思维的典范：传统的安全规则告诫用户必须工作在受限帐户下，大多数用户会困惑于为什么无法安装应用程序，为什么无法修改系统时间。并没有什么理由要求用户必须学习runas的用法，他们理应专注于本职工作，而不是和这些令人生厌的命令打交道。　　

　　而UAP则是鼓励用户工作在管理员帐户下，只是这个管理员帐户经过特殊的“降级”处理—多数情况下，用户并不会有掣肘之感。如果执行需要高特权的管理任务，系统会自动侦测到这种请求，在得到确认后，会自动提升到高级特权环境，以便顺利完成管理任务。　　

　　大家知道，要用“日期和时间”组件修改系统日期或者时间，当前帐户必须具备“更改系统时间”特权（该特权的内部名称为SeSystemTimePrivilege）。本文以“日期和时间”组件为例进行实验，查看其进程访问令牌的前后变化（主要是SeSystemTimePrivilege特权的变化），来简单剖析UAP功能的实质。

　　实验约定　

　　本实验在Windows Vista Build 5231上进行，测试帐户为TestAdmin，是管理员组成员。为了查看进程的访问令牌，需要借助聪明人Mark所提供的Process Explorer工具（这个工具实在太好了，我们经常用它来查看IE浏览器所加载的dll文件，以便进行排错），下载地址如下：http://www.sysinternals.com/Utilities/ProcessExplorer.html。　　

　　实验记录　

　　准备工作　　

　　鼠标右键单击Process Explorer程序图标，然后执行“Run Elevated”菜单命令，以便在完全权限下运行Process Explorer，这样我们就可以不受限制地查看任意进程的访问令牌。启动以后，单击“Options”　“Difference Highlight Duration”，设置变化时间为5秒。
　　
　查看rundll32进程的访问令牌　　

　 单击任务栏通知区域的时钟图标，然后单击“Date and Time Settings”，即可打开“时间和日期”窗口。正如你所预料的，现在还不能对系统时间进行任何修改。同时可以在Process Explorer窗口中看到新增一个进程rundll32（绿色显示），如图1所示。
　　
　　　　

　　双击该rundll32进程，即可打开其属性对话框。在“Image”标签页的“Command Line”文本框里可以看到timedate.cpl（“时间和日期”的控制面板扩展文件），如图2所示。这说明该rundll32进程就是“时间和日期”组件的宿主进程。　　

　　　

　 切换到“Security”标签页里，就可以看到经过特殊降级处理后的访问令牌，可以看到在下方的特权列表里，只有少得可怜的三个特权，而并没有SeSystemTimePrivilege特权。这就是为什么在缺省情况下，无法在TestAdmin环境下修改系统时间的原因。而在老的系统例如Windows XP，rundll32进程具有SeSystemTimePrivilege特权，如图3所示。

　　查看dllhost进程的访问令牌　　

　　要能够修改系统时间，只需单击“时间和日期”窗口右下侧的“Unlock”按钮，即可打开如图4所示的对话框，同时可以看到系统启动了一个consent进程。单击“I want to complete this action”选项，现在应该可以修改系统时间了。看来这个consent进程负责传递消息，以便系统确认提升操作权限。其本质应该是修改相关进程的访问令牌，对于本例来说，应该是在相关进程的安全令牌里添加SeSystemTimePrivilege特权。
　　


　　按照这样的推断，从理论上来说，现在rundll32进程的访问令牌里应该已经添加SeSystemTimePrivilege特权，以便我们可以修改系统时间，那么果真是这样吗？　　

　 结果很让人沮丧，重新打开rundll32进程的属性对话框，发现其访问令牌没有任何改变（并没有新增SeSystemTimePrivilege特权），这是怎么回事？　　

　　反复重新做实验后，终于发现，单击“I want to complete this action”选项后，系统会新增一个dllhost进程（在Process Explorer中绿色显示），在dllhost进程属性对话框的“Image”标签页的“Command Line”文本框里可以看到“/Processid: {9DF523B0-A6C0-4EA9-B5F1-F4565C3AC8B8}”参数。搜索注册表得知，{9DF523B0-A6C0-4EA9-B5F1-F4565C3AC8B8}就是timedate.cpl的AppID，如图5所示。
　　


　　接下来的步骤不说也知道，切换到“Security”标签页，不出所料，dllhost进程的访问令牌里果然有SeSystemTimePrivilege特权，如图6所示。
　　


　　现在真相大白了，原来Windows Vista表面上让rundll32进程“明修栈道”，背地里却让dllhost进程“暗渡陈仓”，真正让我们可以修改系统时间的是dllhost进程。

　　比较前后访问令牌的SID列表　　

　　仔细观察前后两个进程（rundll32进程和dllhost进程）访问令牌中的SID列表，会发现有以下两个显著的不同：　　

　 rundll32进程 Administrators组SID被标记为Deny only，其含义类似于Windows XP/2003中Restricted Token。这表明Administrators组可以访问的资源，和我们无关，而Administrators拒绝访问的资源，我们也不能访问。访问令牌里包含一个名为“Medium Mandatory Level”的古怪帐户（SID为S-1-16-8192）。　　

　　dllhost进程 包含一个名为“High Mandatory Level”的“古怪”帐户（SID为S-1-16-12288）。

　　实验结论　　

　　UAP的实质　　

　　非Administrator的管理员登录时，Explorer进程会获得一个“缩水”的访问令牌，也叫标准用户（Standard User）访问令牌。由于其他进程大多数都是由Explorer启动，所以这些进程会自动拷贝这份“缩水”的访问令牌（如本例的rundll32进程）。凭借这份“缩水”的访问令牌，用户可以完成绝大多数工作，如果需要执行管理任务，系统会提醒用户进行确认，一旦认可，将会获得完全版本的访问令牌（如本例的dllhost进程）。　　

　　进一步验证发现，本例的rundll32进程由explorer进程启动，所以默认会获得一份“缩水”令牌；而dllhost进程则由某个svchost进程启动。　　

　　古怪帐户的作用猜测

　　至于前后两个进程的访问令牌中新出现的“古怪”帐户（一个是“Medium Mandatory Level”，另一个是“High Mandatory Level”）。这两个帐户，既不能用来登录，似乎也不能用来对资源的ACL赋值，到底用来做什么？　　

　　个人的猜测是用来标记访问令牌，这样系统看到访问令牌中包含SID为S-1-16-8192的帐户（Medium Mandatory Level），马上就可以知道该令牌属于标准用户令牌；同样如果令牌中包含SID为S-1-16-12288的帐户（High Mandatory Level），马上就知道其属于完全权限的令牌。　　

　　那么为什么不在访问令牌中新增一个标志位，例如等于0时就是标准用户令牌，等于1时就是完全权限令牌？这样的话，就不需要新增两个SID了。个人猜测是为了兼容性，毕竟增加一个标志位，就等于要修改访问令牌的数据结构，这可不是一个好主意，而添加几个SID，则相对简单得多。　　

　　有趣的任务管理器　　

　　在实验中，还发现，如果右键单击任务栏空白区域，打开任务管理器（其父进程是Explorer），则任务管理器运行在标准用户的访问令牌下；而按下Ctrl+Shift+Esc组合键打开的任务管理器（其父进程是Winlogon），则运行在完全权限的访问令牌下。　　

　　最后小结

　 UAP好比给Windows Vista穿上一件铁布衫，有了它的庇护，像IE这样的进程不再奉行“不抵抗”政策，恶意网页胆敢再来“骚扰”，将被毫不犹豫地阻止。同时最终用户不再需要接受额外的培训，一切都由系统自动完成，只需要做出选择即可，你就没事偷着乐吧。

原文转自：http://www.ltesting.net