SYSTEM帐户、登录会话和窗口站

可能有不少读者兄弟还记得盆盆以前写过一篇文章《超级另类法用SYSTEM帐户登录系统》，描写如何以SYSTEM权限启动Windows XP中的Explorer进程，从而得以通过变相的手段以SYSTEM帐户身份登录系统。

　　在Windows 2000/XP下，我们可以有很多方法，以SYSTEM身份启动某个特定的进程，盆盆就曾经写过一篇《以System帐户身份运行应用程序的三种办法》。

　　SYSTEM帐户启动的实质

　　其实不管用哪种方法，其本质都一样。都是利用SYSTEM登录会话里已有的某个进程A，帮助我们创建一个子进程B，进程B会自然而然地在SYSTEM登录会话里运行--从而具有SYSTEM帐户的特权。

　　这里提到登录会话(Logon Session)的概念。

　　这个概念比较抽象，甚至连MSDN里都语焉不详。这里我们且不去管它(将会在后续的文章里给大家细述这个抽象概念)。在这里，我们只需要了解：登录会话用来代表特定安全主体(Security Principal)的一次登录实例，在Windows里，很多对象的访问权限，是基于登录会话，而非帐户本身。

　　盆盆注释 登录会话和帐户之间的关系，有点类似于进程和程序。登录会话是一个动态的概念，有生命周期，帐户则是一个静态的概念。登录会话有自己的SID。通常来说，我们很少接触到登录会话，但是在某些特定的场合，这个概念非常重要。

　　每个进程，都必须运行在特定的登录会话里。

　　这里就有一个问题：在交互式用户登录之前，Windows系统里已经运行了一些进程(最起码是Winlogon进程)，这些进程显然也应该运行在登录会话里，这就是所谓的SYSTEM登录会话，它所代表的安全主体就是SYSTEM帐户。

　　在Windows的安全机制里，特定登录会话里的某个进程所启动的其他进程，也会运行在该登录会话里，从而继承SYSTEM帐户的安全上下文。

　　《以System帐户身份运行应用程序的三种办法》这篇文章所描述的方法，都是运用这种原理。例如借助At命令以SYSTEM帐户身份启动某个任务，实际上该任务是由Task Scheduler服务启动的，而Task Scheduler服务的宿主进程svchost正是运行在SYSTEM登录会话，如附图所示。

　　

　　图中所示的Task Scheduler服务的进程svchost所在的登录会话ID(Logon Session ID)是0x0-3e7，这就是代表SYSTEM登录会话。

　　而采用Sysinternals Suite里的Psexec命令，道理也一样，实际上启动进程的是PsexecSvc服务，该服务的进程运行在SYSTEM登录会话。

如何看到SYSTEM下的进程

　　在Windows 2000/XP下，这个不是什么问题。然而在Windows Vista下问题就来了。如果企图用AT命令启动某个Local SYSTEM进程，就会警告说不能和用户进行交互，哪怕加上/Interactive参数也不行!

　　原来在Windows Vista下，存在一个会话0隔离的问题。而AT命令所对应的Task Scheduler服务运行在会话0，而会话0是不能和用户进行交互的。

　　盆盆评注 这里要注意，会话和登录会话，是两码事。具体的介绍，敬请期待后续的文章。

　　原来在会话0里，并没有WinSta0这个窗口站。天哪，又来了一个窗口站的概念，嗯，先不用管它，这里只需理解，窗口站用来保护进程的用户界面。只有WinSta0这个特殊的窗口站才可以接受用户的鼠标、键盘事件，才能和用户进行交互。

　　在Windows系统里，如果没有特别指定，SYSTEM登录会话里的进程，将会默认运行在Service-0X0-3E7$窗口站里，所以无法和用户进行交互。

　　所以很显然，要让以SYSTEM权限运行的进程，能够和用户进行交互，必须满足以下条件：

　　1. 必须不能运行在会话0下，例如可以运行在当前用户所在的会话下(例如会话1、2等)

　　2. 该SYSTEM进程必须运行在WinSta0窗口站。

　　而对于IT Pro来说，我们可以借助Mark Russinovich所写的Psexec工具，让任意指定的进程运行在SYSTEM权限下。

　　而对于Windows Vista来说，其实有好些Local SYSTEM进程本身运行在WinSta0下(非会话0)，例如Winlogon进程、某个csrss进程，还有我们大家很熟悉的UAC提示对话框(consent进程)，都运行在SYSTEM下，但是可以和用户进行交互。

　　为什么Local SYSTEM进程有能力加入到WinSta0窗口站?

　　大家可以回想一下，在Windows 2000/XP下，只有以Local SYSTEM运行的服务，可以选择“允许服务与桌面交互”。这实际上就是让该服务运行在WinSta0窗口站里，而不是运行在默认的Service-0X0-3e7$窗口站里。

　　但是为什么以其他帐户身份运行服务，不能选择这个选项?甚至连以当前登录帐户身份运行的服务都不行?例如当前以Admin用户帐户身份登录到系统，而系统中存在着一个服务，也以Admin身份运行。

　　这里我们可以查看一下WinSta0窗口站的安全权限。可以用Process Explorer，或者调试工具(例如Windbg)进行查看。

　　1. 用Windbg查看WinSta0的ACL

　　这里首先介绍用Windbg查看WinSta0窗口站的安全权限(更加完整)。由于Windows Vista默认禁用Kernel Debug，所以必须运行以下命令手动打开Kernel Debug选项：

　　

bcdedit -debug on

　　盆盆评注：注意，如果安装了Demon Tools之类的工具，请不要打开Kernel Debug的选项，以免产生冲突。

　　下图是利用Windbg所dump出来的WinSta0安全描述符的完整记录：

　　

　　我们主要关心日志中最后三个棕色加粗显示的结果：Local System帐户拥有0x000f037f权限组合;Administrators组帐户拥有0x00020166权限组合;还有一个SACL的ACE为S-1-16-4096。

　　0x000f037f和0x00020166，看上去甚是古怪，但搞开发的兄弟应该很容易理解，这实际上是安全权限的组合掩码。

　　咱IT Pro不需要理解这到底是什么意义，只需要知道0x000f037f代表拥有WinSta0的所有可能权限;而0x00020166代表拥有大多数可能的权限，但是无法读取屏幕内容。

　　还有一个SACL的ACE为S-1-16-4096。这又是什么意思?

　　嘻嘻，这里就要请大家参考MVP小青蛙s兄弟的大作《Windows Vista UIPI和窗口消息的故事》。原来在Windows Vista里，每个安全对象，包括窗口站，都有MIC等级的概念。这里可以看到WinSta0窗口站的MIC等级就是S-1-16-4096，实际上就是Low Integrity Level。当然在盆盆的多篇拙作里也曾经多次提及，例如《Windows Vista有趣的标签SID》。

　　WinSta0窗口站的MIC级别为什么会是低级?这可能是为了方便IE浏览器这样的Low MIC进程也能够读写WinSta0里的内容。

　　2. 用Process Explorer查看WinSta0的ACL

　　用Windbg查看WinSta0的ACL，可以得到比较丰富的信息，但是有一点小缺点，无法查看当前登录帐户的权限(相当于查看无用户登录时的WinSta0的安全权限)。

　　所以这里借助Process Explorer进行查看。

　　随便找到一个用户进程，查看其打开的句柄，可以发现其中有\Sessions\1\Windows\WindowStations\WinSta0这样的句柄，查看其安全权限。

　　可以看到当前登录帐户(本例是Admin)没有访问WinSta0的权限，如附图所示。

　　

　　除了SYSTEM之外，还有一个古怪帐户S-1-5-5-0-148836具有所有可能的权限，如附图所示。

　　

　　S-1-5-5-0-148836实际上就是Admin登录会话的SID。这样的结果非常有趣，WinSta0的权限是授予Admin的一次登录实例(登录会话)，而不是Admin这个安全主体本身，很有意义。其实道理很简单，登录会话是经过LSA验证的一次登录实例，Windows可以信任。而以Admin身份运行的进程，并不一定都是由当前登录用户触发的，还有可能是以Admin身份运行的服务，从WinSta0的ACL可以看出，这些服务无法访问WinSta0，尽管它们的身份就是登录用户的帐户本身!

　　Process Explorer虽然可以看到完整的安全描述符信息，也可以看到更详细的权限。但是有两个小缺点，一是无法显示WinSta0的MIC级别，而是只显示所谓的常规权限，而没有显示针对窗口站的特定权限。可能Mark Russinovich还没有来得及更新，抑或这位大牛认为这太简单了，认为大家很容易理解，不想再修改了。

　　盆盆评注：如何理解登录会话的SID?可以用服务和服务SID的关系进行类比。

3. 小结

　　罗罗嗦嗦说了那么多，结论呢?

　　实际上很简单，查看WinSta0窗口站发现，只有System和登录会话SID拥有所有的可能权限。所以这就可以解释，为什么在Windows里，只有运行在System权限下的服务才可以选择“允许服务与桌面交互”，因为实在是只有System才有权限访问WinSta0窗口站啊!

　　为什么Windbg不能转储完整的WinSta0窗口站的安全描述符?为什么会少了登录会话SID和登录帐户的对应ACE?

　　盆盆很快发现，原来是自己的问题。为了方便，直接用远程桌面连接到另外一台实验Windows Vista机器，这时候由于是远程桌面登录的，拿到的是会话2。但是在Windbg里检查的却是\Sessions\1\Windows\WindowStation\WinSta0。

　　也就是说，盆盆实际上是检查的会话1里的WinSta0窗口站，而不是远程桌面里的WinSta0窗口站(会话2)!!

　　难怪检查出来的结果，发现WinSta0窗口站里居然没有登录SID和Admin的对应ACE!!

　　1. 完整的WinSta0安全描述符

　　为了验证这个结果，盆盆重新做实验，这次直接控制台登录(会话1)，再查看WinSta0的安全描述符，果然发现完整了，有附图为证!

　　

　　图中棕色加粗的部分，就是登录会话SID和登录帐户Admin所拥有的ACE，这里可以看到登录会话SID拥有所有可能的权限，而Admin则几乎没有任何访问权限。

　　问题到这里并没有结束。

　　为什么会出现先前那篇文章里的错误?从中可以猜测到哪些结论?

　　2. 为什么只允许一个交互用户登录?

　　这里盆盆大胆假设Windows Vista(XP)为什么只能允许一个交互用户登录到系统(包括远程桌面)。原来是和WinSta0窗口站的权限有关!

　　当新的用户登录进来后，原来用户会话里的WinSta0的安全权限会发生变化，登录SID和登录帐户的ACE(访问控制项)会被删除。难怪我们看不到先前登录用户的桌面!

　　可以在远程桌面的环境里打开Process Explorer，查看一个在先前用户环境里打开的进程(例如Explorer)，可以发现其句柄列表里没有WinSta0窗口站，如附图所示。

　　

　　从图中可以看出，当前的用户桌面，会话2里的Explorer进程句柄表里包含WinSta0窗口站，所以可以和用户进行交互;而先前的登录用户，会话1里的Explorer进程句柄表里，没有WinSta0窗口站，所以虽然这些进程还在运行，但是无法和用户进行交互。

　　为什么先前的用户会话里的进程没有WinSta0的句柄，现在应该很明白了，因为该会话里的WinSta窗口站对象的ACL定义发生了变化，现在不再授予登录会话SID访问。

　　这一切看来和WinSta0窗口站的安全权限有关。可见，登录会话、窗口站的概念有多重要了。

　　知道了这个原因，从理论上，我们可以通过修改先前会话里的WinSta0窗口站的安全权限，来突破同一时刻只能允许一个用户交互登录的限制。但是实际上没有那么简单，盆盆既然能够想到，微软肯定早就已经想到了。

　　网上貌似有通过替换一个文件(termsrv.dll)的方法，让Windows Vista支持多个用户交互登录。如果这个方法能够成功，其原理也许还是和WinSta0窗口站的权限有关。