Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    86382698

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

身份驗證繞過漏洞是現代web應用程序中普遍存在的漏洞,也是隱藏最深很難被發現的漏洞。

為此安全防護人員不斷在開發新的認證方法,保障組織的網絡安全。儘管單點登錄(SSO)等工具通常是對舊的登錄用戶方式的改進,但這些技術仍然可能包含嚴重的漏洞。無論是業務邏輯錯誤還是其他軟件漏洞,都需要專業人員來分析其中的複雜性。

我們將在本文中介紹五種真實的身份驗證繞過技術。

技術1——刷新令牌終端配置錯誤在這種情況下,一旦用戶使用有效憑證登錄到應用程序,它就會創建一個在應用程序其他地方使用的承載身份驗證令牌。該認證令牌在一段時間後過期。就在過期之前,應用程序在終端/refresh/tokenlogin中向後端服務器發送了一個請求,該請求在標頭和HTTP主體部分的用戶名參數中包含有效的身份驗證令牌。

進一步的測試表明,刪除請求上的Authorization標頭並更改HTTP主體上的用戶名參數將為提供的用戶名創建一個新的有效令牌。利用此漏洞,擁有匿名配置文件的攻擊者可以通過提供用戶名為任何用戶生成身份驗證令牌。

1.png

技術2 ——SSO配置不正確大多數應用程序都使用SSO系統,因為與處理許多身份驗證門戶相比,SSO系統更容易安全管理。但是簡單地使用SSO並不能自動保護系統,因為SSO的配置也應得到保護。

現在,一個應用程序使用Microsoft SSO系統進行身份驗證。當訪問internal.redacted.com URL時,web瀏覽器會重定向到單點登錄系統:

2.png

乍一看,它似乎是安全的,但對後端請求的分析顯示,應用程序在重定向響應上返回了異常大的內容長度(超過40000字節)

3.png

為什麼應用程序要這樣做呢?當然是配置錯誤。在將用戶發送到SSO的重定向時,應用程序向每個請求洩露了其內部響應。因此,可以篡改響應,將302 Found頭更改為200 OK,並刪除整個Location標頭,從而獲得對整個應用程序的訪問。

4.png

此外,可以通過在Burp Suite中添加Match Replace規則來自動刪除標題並自動更改值,從而實現這個過程的自動化。

5.png

技術3——基於CMS的訪問漏洞內容管理系統(CMS),如WordPress、Drupal和Hubspot也需要進行安全配置,以免它們在使用中中引入漏洞。

在發現的一個示例中,在一個內部應用程序中使用了一個流行的CMS平台Liferay。該應用程序只有一個不需要身份驗證就可以訪問的登錄頁面,所有其他頁面都在應用程序UI中受到限制。

對於那些不熟悉Liferay的人來說,CMS為應用程序工作流使用了portlet,它的參數是數字中的p_p_id。對於該應用程序,可以通過將參數值更改為58來訪問登錄portlet。在正常的登錄頁面中,只有登錄表單是可訪問的。然而,通過直接訪問portlet,可以達到Create Account功能,然後在不需要適當的授權情況下就可以進行自註冊並訪問內部應用程序。

6.png

請注意,雖然Liferay以前使用過這個工作流,但它的最新版本使用了portlet名稱而不是數字ID。不過,也可以通過更改名稱來訪問其他portlet。

技術4 ——JWT令牌的使用JWT令牌或JSON web令牌,在新的web應用程序中很流行。但是,雖然它們默認具有安全機制,但後端服務器配置也應該是安全的。

我的一項任務是在他們的內部應用程序中使用SSO身份驗證。當直接訪問時,應用程序將用戶重定向到Microsoft SSO web頁面。到目前為止,一切順利。

然而,一些JS文件不需要身份驗證就可以訪問。測試顯示,該應用程序使用了安全登錄後通過Microsoft SSO系統發送的JWT令牌。在後端機制上,存在一個安全錯誤配置,即不檢查是否為特定的應用程序生成了JWT令牌。相反,它接受任何具有有效簽名的JWT令牌。因此,使用來自微軟網站的JWT令牌示例如下:

7.jpg

在通用值內:

8.jpg

有可能訪問內部終端,洩露公司數據。

9.png

技術5——將身份驗證類型更改為Null在此情況中,應用程序通過base64 編碼的XML 請求向HTTP 發布數據上發送所有請求。在登錄機制上,它將用戶名作為參數別名發送,將密碼作為scode發送。 scode 參數內的值已進行哈希處理。分析顯示,它使用了所提供密碼值的md5 值。請求中還有另一個有趣的標誌:scode 有一個屬性,其類型值為2。

10.png

我嘗試將該值賦值為1,它將接受明文密碼。成功了!因此,在明文值中使用暴力攻擊中是可能的。沒什麼大不了的,但這標誌著我走對了路。把它賦值給空值怎麼樣?或者其他值,如-1、0或9999999999?大多數都返回了除0之外的錯誤代碼。我用屬性0做了幾次嘗試,但沒有成功,直到我將密碼值作為空值發送出去。

11.png

我意識到只需提供用戶名和密碼即可訪問任何帳戶。事實證明,這是一個很大的錯誤。

總結複雜的身份驗證機制可能成為攻擊者使用的最具隱蔽性的攻擊手段,特別是在容易出現業務邏輯漏洞的應用程序上。因為自動掃描器大多無法進入這類漏洞,所以仍然需要手工來找到它們。鑑於現代軟件環境的複雜性,沒有任何一個安全研究人員能夠發現所有可能的漏洞或攻擊載體。