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

迷南。 2022-08-27 03:39 215阅读 0赞

可能有不少读者兄弟还记得盆盆以前写过一篇文章《超级另类法用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登录会话，如附图所示。

![2][]

图中所示的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选项：

<table style="BORDER-RIGHT: #cccccc 1px dotted; TABLE-LAYOUT: fixed; BORDER-TOP: #cccccc 1px dotted; BORDER-LEFT: #cccccc 1px dotted; BORDER-BOTTOM: #cccccc 1px dotted"> 
 <tbody> 
  <tr> 
   <td style="WORD-WRAP: break-word">bcdedit&nbsp;-debug&nbsp;on</td> 
  </tr> 
 </tbody> 
</table>

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

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

![1][]

我们主要关心日志中最后三个棕色加粗显示的结果：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的权限，如附图所示。

![2][2 1]

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

![3][]

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的安全描述符，果然发现完整了，有附图为证!

![2u2l2w4e68f0.jpg][]

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

问题到这里并没有结束。

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

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

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

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

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

![ph4gb9tb341w.jpg][]

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

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

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

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

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

[2]: http://winsystem.ctocio.com.cn/imagelist/2008/142/g7237qr800sy.png
[1]: http://winsystem.ctocio.com.cn/imagelist/2008/142/1j37ejz70xm7.png
[2 1]: http://winsystem.ctocio.com.cn/imagelist/2008/142/11yi461ga186.png
[3]: http://winsystem.ctocio.com.cn/imagelist/2008/142/bh3873su231n.png
[2u2l2w4e68f0.jpg]: http://winsystem.ctocio.com.cn/imagelist/2008/142/2u2l2w4e68f0.jpg
[ph4gb9tb341w.jpg]: http://winsystem.ctocio.com.cn/imagelist/2008/142/ph4gb9tb341w.jpg