標籤:

技術詳解:基於Web的LDAP注入漏洞

企業通常會部署Active Directory環境來管理域對象,如用戶,組織,部門,計算機和印表機,並將此與自定義Web應用程序的增加結合起來,企業組織自然也希望將這兩種技術集成在一起。這種集成是為了在域環境中創建最佳的集中式的身份驗證方式,同時也提供了查詢和管理Active Directory環境的方法。

需要記住的是,集成這兩種技術也可能會為惡意攻擊者提供另一個攻擊面。因此,在與Active Directory集成時,實現良好的Web應用程序安全性至關重要。

在開始使用之前,我們首先了解一下用於將Web應用程序與Active Directory – LDAP(輕量級Active Directory協議)集成的協議。LDAP不僅可以從目錄資料庫查詢對象,還可以用於管理和身份驗證。

另外要記住的是LDAP 本身並不是目錄資料庫。它是一種提供訪問目錄資料庫方法的服務和協議。此外,LDAP也並不是微軟Active Directory環境獨有的。實際上也有其他幾種類型的資料庫使用了LDAP,如OpenLDAP。

SQL注入是人們想到Web應用程序開發的時候想到的最典型的攻擊方法,但是LDAP集成的網站也可能通過注入攻擊被利用。SQL注入和LDAP注入之間存在著明顯的差異,因為兩者之間的語法差異很大。

為了說明LDAP注入,我搭建了一個集成了LDAP的有漏洞的Web應用程序,並將在下面演示一個簡單的注入過程。在演示LDAP注入之前,我們先來介紹一下這兩個知識點:

1. 了解目錄資料庫結構。

2. 了解LDAP語法。

目錄資料庫結構

根據企業組織的不同,目錄資料庫可能非常複雜而且非常龐大。因此,我將使用LDIF(LDAP交換格式)文件來說明一個簡單的目錄結構。LDIF文件只是表示目錄數據和LDAP命令的純文本文件。它們也用於讀取,寫入和更新目錄中的數據。你可以在下面看到一個LDIF模板文件示例。

第8-10行:我們定義了頂級域名「 org 」。

第12-15行:我們定義了子域「 yourcompany 」,即「 yourcompany.org 」。

第17-37行:我們定義了三個組織單元(ou):財務和銷售。

第29+行:我們在域「yourcompany.org」中添加了一個用途,並為屬性賦值。例如,「 cn 」表示規範名稱(或名字),「 sn 」表示姓氏,「 郵件 」表示該員工的電子郵件地址。

注意:

根據你使用的環境類型,LDAP屬性會有所不同。例如,「userPassword」存在於OpenLDAP中,但不在Active Directory環境中。

了解基本的LDAP語法

LDAP具有非常特定的查詢結構,並具有特定的語法。以下是在LDAP查詢中使用的常見操作符:

· 「=」(等於)

· &(邏輯和)

· | (邏輯或)

· !(邏輯不)

· *(通配符)

例如,如果我們想要在上面的LDAP結構中查詢名為「 steve 」的人,我們的查詢將如下所示:

(cn=steve)

也許我們想要搜索名稱以「 s 」 開頭的任何成員,那麼我們可以使用通配符:

(cn=s*)

我們還可以使用「 | 」運算符搜索名稱以「s」或「t」開頭的任何人:

(|(cn=s*)(cn=t*))

我們也可以使用「&」運算符來要求這兩個欄位都是正確的。例如,如果我們想要搜索名稱以「s」開頭,姓氏以「d 」 結尾的任何人。

(&(cn=s*)(sn=*d))

最後,我們可以將所有這些操作符合併在一起來執行查詢。例如,假設我們想要查找任何名字以「s 」 開頭的人,但他們的姓必須以「d」或「r」 開頭:

(&(cn=s*)(|(sn=d*) (sn=r*))

LDAP注入演示

現在我們對相關的知識點有了更好的了解,讓我們繼續進行演示。從下圖中可以看到一個叫做 「Your Company LLC」的公司的「員工搜索表單」的網頁示例:

我們先簡單地輸入一些數據並提交。

我們的表單通過獲取查詢(在上面的url欄中看到)提交值「 s 」和屬性「 cn 」(名字)並返回給我們一個表,其中包含了名字以「s」開頭的員工。

我們可以查看本網站的網頁源碼,查看相應的表單欄位並獲取URL中的參數(見下圖)。

我們可以看到,LDAP屬性只允許我們選擇某些欄位。我們可以在我們的URL中進行更改,也可以在開發人員控制台中直接編輯欄位的值。這通常比在開發者控制台中更容易修改。顯然,修改URL參數並不適用於POST請求,因此,我通常更願意在開發人員控制台中編輯這些值。另一種方法是使用像Burpsuite或ZAP這樣的代理在發送到伺服器之前修改這些值。

下面你可以看到這個欄位從「cn」更改為了「password」。

然後我們只需點擊提交按鈕,OK,下面我們可以看到,我們操縱了正在發送的數據,目的是檢索用戶的密碼哈希值。但是,這仍然不是LDAP注入,只是一個很糟糕的編碼習慣,導致了在客戶端代碼中可以控制這些屬性。

現在讓我們看看是否可以將LDAP注入到查詢中並操縱我們看到的結果。在這個演示中,我將簡單地顯示LDAP語句預注入(見下圖)。請注意,在滲透測試中,你將不可能看到這些語句的源代碼。在這些情況下,可能必須使用模糊測試和信息偵察來成功利用LDAP注入。

正如我們所看到的,開發者沒有做任何類型的輸入驗證或過濾用戶在連接之前傳遞的值。與SQL注入一樣,查詢的字元串連接也是危險的。使用LDAP庫的大多數Web框架還提供了一種經過驗證的方法,用於在查詢之前轉義和/或過濾用戶提供的輸入。如果在與目錄資料庫集成時使用LDAP,應始終利用這些安全的方法或功能。

在上面的查詢中,有幾件事情正在發生:

1. 我們的聲明以邏輯或「|」開始 其中包括兩個子語句。如果匹配到一個對象,那麼該對象將返回所需的屬性包含了"cn","sn"和"ou"。

2. 在第一個子語句中,我們執行了(&(<supplied attribute>=<search term>)(department=finance))。這意味著我們可以搜索具有我們想要的任何屬性和值的對象,但是該對象也必須屬於財務部門。

3. 在第二個子語句中,我們執行了(&(<supplied attribute>=<search term>)(department=sales))。這意味著我們可以搜索具有我們想要的任何屬性和值的對象,但該對象也必須屬於銷售部門。

4. 通過將這兩者結合在一起,開發人員正試圖將搜索查詢僅限於屬於財務或銷售部門的用戶對象。

儘管竊取銷售或財務人員的憑證可能具有不可估量的價值,但是能夠獲取到域管理員的憑證那當然是更好的了。所以,我們來製作一個利用這個製作精妙的查詢的注入。例如,在將URL中所需的LDAP屬性從「 cn 」更改為「 password 」後,我們可以將LDAP語法作為我們的搜索條件注入:

))(department=it)(|(cn=

這將改變我們的查詢:

改為:

這個語句現在可以查詢我們的目錄中的任何對象,這些對象需要包含:

1. 要有密碼;

要麼

2. 要屬於「IT」部門;

要麼

3. 要有任何規範的名稱或在財務部門;

要麼

4. 要有任何規範的名稱或在銷售部門。

當我們要利用LDAP注入時,用「OR」要比「AND」更好。

讓我們試試這個新的查詢:

真棒!利用這個技巧,我們現在得到了域憑據。正如我們所看到的,修改屬性並注入正確的LDAP語法能夠使我們可以從目錄中查詢任何我們想要的內容。

防禦方法

1. 始終使用框架提供的功能來正確的驗證,過濾或轉義用戶提供的輸入數據。

2. 不允許用戶指定客戶端的屬性值。使用可由用戶指定的存儲值或伺服器端功能。

3. 更好地格式化你的查詢(以及其他預防方法)以防止被修改。例如,如果上面的語句已被更改為

那麼攻擊者要查詢到財務或銷售部門的數據將是相當困難的。再次,適當的查詢結構並不足以保護其本身。

4. 如果有問題的框架不提供驗證,過濾或轉義這些值的方法,請盡量通過正則表達式,存儲過程或其他一些輸入驗證方法過濾用戶提供的輸入。但是,自定義方法只能作為最後的手段,應該由其他開發人員或安全專業人員驗證其準確性。

其他說明

1. 在滲透測試中,你將不可能獲得有關目錄資料庫的源代碼和信息。因此,適當的偵察和模糊測試是比較關鍵的。

2. 你可能有權訪問或無法修改屬性。在這種情況下,你可能僅限於注入並僅從預定義的屬性中檢索信息。

3. LDAP也可以用來更新或刪除一個目錄資料庫,所以在進行滲透測試時請一定要小心。

4. LDAP注入也可以用來繞過認證。具體內容請查看下面的OWASP文章的詳細鏈接。

有關LDAP的一些比較有用的鏈接:

· LDAP注入身份驗證繞過:owasp.org/index.php/Tes

· OpenLDAP屬性:zytrax.com/books/ldap/a

· Ldap查詢基礎知識:technet.microsoft.com/e

· Active Directory屬性:msdn.microsoft.com/en-u

本文翻譯自:pen-testing.sans.org/bl ,如若轉載,請註明原文地址: 4hou.com/technology/909 更多內容請關注「嘶吼專業版」——Pro4hou

推薦閱讀:

基於ios平台的滲透測試工具兵器譜
Poking holes in information hiding · Week 10
C/S架構下密碼加密的作用?
創建AD蜜罐賬號居然有防禦的功效?

TAG:信息安全 |