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.kjueaiud.com