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登录会话,如附图所示。

  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选项:

  

bcdedit -debug on
  盆盆评注:注意,如果安装了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

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

  

  图中棕色加粗的部分,就是登录会话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窗口站的权限有关。

阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页