網絡技術是從1990年代中期發展起來的新技術,它把互聯網上分散的資源融為有機整體,實現資源的全面共享和有機協作,使人們能夠透明地使用資源的整體能力并按需獲取信息。資源包括高性能計算機、存儲資源、數據資源、信息資源、知識資源、專家資源、大型數據庫、網絡、傳感器等。 當前的互聯網只限于信息共享,網絡則被認為是互聯網發展的第三階段。 I、 摘要II、 關于SAM III、注冊表中SAM數據庫的結構 IV、 SAM數據庫的結構和主要內容 V、 關于SAM數據庫分析的結論 一、摘要 分析安全帳號管理器結構是在一個多月前做的事情了,只零碎地記錄下片段,沒有發布過。不發布的主要 原因是安全帳戶管理器(SAM)是WIN系統帳戶管理的核心,并且非常系統化,我也有很多地方僅僅是進行的推 斷和猜測,同時,SAM hack可能造成啟動時lsass.exe加載帳戶管理器出錯,即便是安全模式也不能修復(啟動 時候必然加載SAM)使得整個系統啟動崩潰(我通常需要依靠第二系統刪除SAM文件來啟動)。至于現在發布出 來,主要是因為Adam和叮叮的《克隆管理員帳號》種所描述的制作rootkit辦法隱蔽性和危害性,對SAM的結構 的熟悉,可以幫助安全維護人員做好安全檢測(當然也可能讓不良企圖者利用)。 這里只介紹關于SAM的內容,同Security相關的暫時不公開。 二、關于SAM 不要誤解了SAM,這不是一個文件sam這么簡單。SAM(Security Accounts Manager安全帳戶管理器)負責 SAM數據庫的控制和維護。SAM數據庫位于注冊表HKLM\SAM\SAM下,受到ACL保護,可以使用regedt32.exe打開注 冊表編輯器并設置適當權限查看SAM中的內容。SAM數據庫在磁盤上就保存在%systemroot%system32\config\目 錄下的sam文件中,在這個目錄下還包括一個security文件,是安全數據庫的內容,兩者有不少關系。 SAM數據庫中包含所有組、帳戶的信息,包括密碼HASH、帳戶的SID等。這些內容在后面詳細介紹。以我分 析的系統中文Win2K Adv Server為例。 三、注冊表中SAM數據庫的結構 展開注冊表HKLM\SAM\SAM\: 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數據庫所在的位置:\systemroot\system32\config\sam,然 后是一端空白,直到01000h(hbin),從這里開始就是整個數據庫的內容。SAM數據庫的文件內容不作主要介紹, 不過會穿插著介紹,有興趣可以自己去研究。 四、SAM數據庫的結構和主要內容: 在整個數據庫中,帳號主要內容存在于下面這些位置: 在\Domains\下就是域(或本機)中的SAM內容,其下有兩個分支“Account”和“Builtin”。 \Domains\Account是用戶帳號內容。 \Domains\Account\Users下就是各個帳號的信息。其下的子鍵就是各個帳號的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關聯的關系。 \Domains\Account\Users\000001F4,這就是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簡單。 \Domains\Builtin下的內容是同帳戶組相關的。其結構同\Account下的類似,并且也存在相應的問題,就不再 羅嗦了。 SAM數據庫保存的文件sam中,可沒有注冊表中的這么簡明的內容,而主要是通過偏移量、長度來定位內容。并 且單個帳號的信息都是集中在一塊的,而不是象注冊表形式這樣分隔開(名字的一個鍵而內容在另外一個鍵)。 sam文件中,可根據這些下面這些分隔符來定位數據含義: nk (6E 6B) 鍵或者子鍵名 vk (76 6B) 相應的值 if (6C 66) 子鍵列表 sk (73 6B) 權限 五、關于SAM數據庫分析的結論: SAM HACK是非常有危險性的。不正確的修改會將系統的安全數據管理器破壞,造成系統啟動問題,雖然可以通過 刪除SAM文件來讓啟動恢復。如果能夠熟悉SAM的結構,你將發現,可以對用戶名與用戶名之間、用戶組與用戶組之間 進行調換,以及帳戶和帳戶組偽造,完全打破微軟的帳戶格局。并且非常隱蔽,讓帳戶相關的API函數摸不著頭腦。 雖然微軟處理帳號信息中犯了不少邏輯問題,但是安全帳號數據庫并非不安全,所有操作都必須能完全擁有管理 員權限。 當隱蔽后門的辦法被提出來之后,一定會讓不少“黑客”利用,管理員也應該多多熟悉相關技術,作好安全檢測, 我的目的就達到了。對《克隆管理員帳號》的簡單檢測工具可以在我的主頁(www.opengram.com)下載,但是更多的還是需要管理員學習相關知識,才能更好地檢測入侵。 網絡的神奇作用吸引著越來越多的用戶加入其中,正因如此,網絡的承受能力也面臨著越來越嚴峻的考驗―從硬件上、軟件上、所用標準上......,各項技術都需要適時應勢,對應發展,這正是網絡迅速走向進步的催化劑。 |
溫馨提示:喜歡本站的話,請收藏一下本站!