完全解剖安全帳號管理器（SAM）結構

安全設置不得不需要了解的東西
一、摘要
　　
　　分析安全帳號管理器結構是在一個多月前做的事情了，只零碎地記錄下片段，沒有發佈過。不發佈的主要原因是安全帳戶管理器（SAM）是WIN系統帳戶管理的核心，並且非常系統化，我也有很多地方僅僅是進行的推斷和猜測，同時，SAM hack可能造成啓動時lsass.exe加載帳戶管理器出錯，即便是安全模式也不能修復（啓動時候必然加載SAM）使得整個系統啓動崩潰（我通常需要依靠第二系統刪除SAM文件來啓動）。至於現在發佈出來，主要是因爲Adam和叮叮的《克隆管理員帳號》種所描述的製作rootkit辦法隱蔽性和危害性，對SAM的結構的熟悉，可以幫助安全維護人員做好安全檢測（當然也可能讓不良企圖者利用）。這裏只介紹關於SAM的內容，同Security相關的暫時不公開。
　　
　　二、關於SAM
　　
　　不要誤解了SAM，這不是一個文件sam這麼簡單。SAM（Security Accounts Manager安全帳戶管理器）負責SAM數據庫的控制和維護。SAM數據庫位於註冊表HKLMSAMSAM下，受到ACL保護，可以使用regedt32.exe打開註冊表編輯器並設置適當權限查看SAM中的內容。SAM數據庫在磁盤上就保存在%systemroot%system32config目錄下的sam文件中，在這個目錄下還包括一個security文件，是安全數據庫的內容，兩者有不少關係。
　　
　　SAM數據庫中包含所有組、帳戶的信息，包括密碼HASH、帳戶的SID等。這些內容在後面詳細介紹。分析的系統中文Win2K Adv Server爲例。
　　
　　三、註冊表中SAM數據庫的結構
　　
　　展開註冊表HKLMSAMSAM:
　　
　　HKLM---SAM
　　|---SAM
　　|---Domains
　　| |---Account
　　| | |---Aliases
　　| | | |---Members
　　| | | |---Names
　　| | |---Groups
　　| | | |---00000201
　　| | | |---Names
　　| | | |---None
　　| | |---Users
　　| | |---000001F4
　　| | |---000001F5
　　| | |---000003E8
　　| | |---000003E9
　　| | |---Names
　　| | |---Adaministrator
　　| | |---Guest
　　| | |---IUSR_REFDOM
　　| | |---IWASM_REFDOM
　　| |---Builtin
　　| |---Aliases
　　| | |---00000220
　　| | |---00000221
　　| | |---00000222
　　| | |---00000223
　　| | |---Members
　　| | | |---S-1-5-21-1214440339-706699826-1708537768
　　| | | |---000001F4
　　| | | |---000001F5
　　| | | |---000003E8
　　| | | |---000003E9
　　| | |--- Names
　　| | |---Administrators
　　| | |---Users
　　| | |---Guests
　　| | |---Power Users
　　| |---Groups
　　| | |---Names
　　| |
　　| |---Users
　　| |---Names
　　|
　　|---RXACT
　　
　　這是機器上註冊表中的SAM樹。
　　
　　對照SAM文件中的內容，可以看出，註冊表中的SAM樹實際上就是SAM文件中一樣。不過，SAM文件中是先列RXACT然後在是Domains內容（以此類推），文件中的表達順序和註冊表中的樹形順序是相反的。如果習慣於看文件內容，從文件的0000h到0006Ch，表示的是SAM數據庫所在的位置：systemrootsystem32configsam，然後是一端空白，直到01000h（hbin），從這裏開始就是整個數據庫的內容。SAM數據庫的文件內容不作主要介紹，不過會穿插着介紹，有興趣可以自己去研究。
　　
　　四、SAM數據庫的結構和主要內容：
　　
　　在整個數據庫中，帳號主要內容存在於下面這些位置：
　　
　　在Domains下就是域（或本機）中的SAM內容，其下有兩個分支“Account”和“Builtin”
　　
　　DomainsAccount是用戶帳號內容。
　　
　　DomainsAccountUsers下就是各個帳號的信息。其下的子鍵就是各個帳號的SID相對標誌符。比如000001F4，每個帳號下面有兩個子項，F和V。其中Names下是用戶帳號名，每個帳號名只有一個默認的子項，項中類型不是一般的註冊表數據類型，而是指向標誌這個帳號的SID最後一項（相對標識符），比如其下的Administrator，類型爲0x1F4，於是從前面的000001F4就對應着帳戶名administrator的內容。由此可見MS帳號搜索的邏輯。
　　
　　推斷一：從註冊表中結構來看帳號，如果查詢一個帳戶名refdom的相關信息，那麼，微軟從帳號名refdom中
　　
　　找到其類型0x3EB,然後查找相對標誌符（或者SID）爲000003EB的帳號內容。所有的API函數（比如NetUserEnum()）都是這樣來執行的。因此，如果改變refdom帳號中的類型0x3EB爲0x1F4，那麼這個帳號將被指向類000001F4的帳戶。而這個帳號000001F4就是administrator帳戶，這樣，系統在登錄過程中就把refdom帳號完全轉爲了administrator帳號，帳號refdom所使用的所有內容、信息都是adminisrtator內容，包括密碼、權限、桌面、記錄、訪問時間等等。這個推斷應該成立，但是，將意味着兩個用戶名對應一個用戶信息，系統啓動上應該會發生錯誤！
　　
　　推斷一是在以前分析結構的時候即得出了，揭示了登錄過程中及之後帳戶名和SID關聯的關係。
　　
　　DomainsAccountUsers00001F4，這就是administrator的帳戶信息（其他類似）。其中有兩個子項V和F。
　　
　　項目V中保存的是帳戶的基本資料，用戶名、用戶全名(full name)、所屬組、描述、密碼hash、註釋、是否可以更改密碼、帳戶啓用、密碼設置時間等。項目F中保存的是一些登錄記錄，比如上次登錄時間、錯誤登錄次數等，還有一個重要的地方就是這個帳號的SID相對標誌符。
　　
　　以前分析結構的時候沒有留意到這個地方，這就是Adam提出的思路。這個地方就是這個SID相對標誌符在註冊表中一個帳號出現了兩遍，一個是在子鍵000001F4，另一個地方就是子鍵中項F的內容裏面，從48到51的四個字節：F4 01 00 00，這實際上是一個long類型變量，也就是00 00 01 F4。當一個標誌出現在兩個地方的時候就將發生同步問題。明顯，微軟犯了這個毛病。兩個變量本應該統一標誌一個用戶帳號，但是微軟把兩個變量分別發揮各自的作用，卻沒有同步統一起來。
　　
　　子鍵中000001F4用來同用戶名administrator對應，方便通過用戶查詢帳戶信息，比如LookupAccountSid（）等帳號相關API函數都是通過這個位置來定位用戶信息的，這個關聯應該是用在了帳戶登錄以後。而項目V值中的F4 01 00 00是同帳戶登錄最直接相關聯的。
　　
　　推斷二：WIN登錄的時候，將從SAM中獲得相對標誌符，而這個相對標誌符的位置是V值中的 F4 01 00 00。但是，帳戶信息查詢卻使用的SAM中子鍵內容。
　　
　　推斷二的原因假設（假設一）：在帳戶登錄的時候，登錄過程獲得SAM數據庫中用戶名使用的帳戶記錄信息中的相對標誌符值（相當於V值中的 F4 01 00 00），帳戶登錄之後，所有跟帳戶相關的之後，這個值不再被API函數使用，而相對標誌符由一個數據記錄項的字段名代替（相當於子鍵000001F4）。微軟犯了一個同步邏輯問題！
　　
　　推斷二是根據Adam提出而進行的，以前沒有這樣推斷過。:( 推斷二如果成立，揭示了在登錄過程中帳戶SID進行的過程。這就是爲什麼V中的值都是跟帳戶登錄記錄（登錄時間，密碼錯誤次數等）相關的原因。同時，因爲F中保存了一個用戶名內容，而API函數查詢的是這個用戶名，所以Adam的克隆辦法還是容易露臉，經叮叮補充過後，這個用戶名也被恢復原用戶名了，從用戶名上檢測就相對難了。
　　
　　上面對項目V的介紹可以知道，其中保存的是帳戶的基本資料，用戶名、用戶全名(full name)、所屬組、描述、密碼hash、註釋、是否可以更改密碼、帳戶啓用、密碼設置時間等。現在來關心的是密碼HASH。
　　
　　假設二：在帳戶的項V中，包含了用戶HASH，分別包括是LM2和NT的密碼加密散列，Crack時，可分開進行。畢竟LM2簡單。
　　
　　DomainsBuiltin下的內容是同帳戶組相關的。其結構同Account下的類似，並且也存在相應的問題，就不再羅嗦了。
　　
　　SAM數據庫保存的文件sam中，可沒有註冊表中的這麼簡明的內容，而主要是通過偏移量、長度來定位內容。並且單個帳號的信息都是集中在一塊的，而不是象註冊表形式這樣分隔開（名字的一個鍵而內容在另外一個鍵）。
　　
　　sam文件中，可根據這些下面這些分隔符來定位數據含義：
　　
　　nk (6E 6B) 鍵或者子鍵名
　　vk (76 6B) 相應的值
　　if (6C 66) 子鍵列表
　　sk (73 6B) 權限
　　
　　五、關於SAM數據庫分析的結論：
　　
　　SAM HACK是非常有危險性的。不正確的修改會將系統的安全數據管理器破壞，造成系統啓動問題，雖然可以通過刪除SAM文件來讓啓動恢復。如果能夠熟悉SAM的結構，你將發現，可以對用戶名與用戶名之間、用戶組與用戶組之間進行調換，以及帳戶和帳戶組僞造，完全打破微軟的帳戶格局。並且非常隱蔽，讓帳戶相關的API函數摸不着頭腦。雖然微軟處理帳號信息中犯了不少邏輯問題，但是安全帳號數據庫並非不安全，所有操作都必須能完全擁有管理員權限。
　　
　　當隱蔽後門的辦法被提出來之後，一定會讓不少“黑客”利用，管理員也應該多多熟悉相關技術，作好安全檢測。