分析电子银行应用ELBA5中的远程代码执行漏洞

原文:https://pentestmag.com/remote-code-execution-vulnerability-in-the-austrian-electronic-banking-application-elba5/

0x00 简介

如下所示,ELBA5是奥地利针对商业领域最重要的电子银行应用之一,被许多大型组织的财务部门所使用,支持大约24家不同的银行。

需要注意的是,ELBA5有两个不同的版本,即ELBA5单用户版(single-seat)和ELBA5多用户(multi-user,也称为网络安装版)。本文所处讨论的漏洞仅适用于ELBA5网络安装版。尽管如此,我还报告了单用户版其他几个问题,虽然这些问题等级并没有那么严重。因此,这里我强烈建议用户升级到最新版本。

为了便于大家理解ELBA5系列软件在多用户版环境中的工作原理,我绘制了如下示意图。图左侧为ELBA5服务器:这个角色有两个不同的功能:一方面它使用标准的Windows文件共享方式为所有客户端提供ELBA5二进制应用程序;另一方面,它提供了ELBA5后端服务,也就是SAP SQL Anywhere数据库。

最终用户系统只需连接到这个文件共享服务,然后从该位置启动ELBA5客户端即可。通过这种方式,应用程序的更新变得非常容易,每个人使用的都是同一个程序包。ELBA5客户端所查看、修改或创建的所有数据都直接存储在后端数据库中。以上信息就是我们为了理解漏洞所需掌握的背景知识。

0x01 发现问题

整个故事开始于去年的一次渗透测试。 在这次渗透测试中,我能够访问财务部门的终端服务器。除此之外,他们还使用ELBA5网络安装版来开展日常业务。我天生好奇心非常强,因此立即开始调查所有看起来比较有趣的应用程序。后续的测试步骤如下图所示,大家能发现一些(可能存在的)问题吗?

上面有个环节引起了我的注意:在之前没有经过任何身份验证的情况下,如何做到自动安装更新?ELBA5应用程序是否使用了硬编码的凭据来连接到后端服务?

0x02 初步分析

初步发现这个疑点后,我开始深入挖掘。由于ELBA5采用Java语言开发,因此我使用CRF反编译器来获取该应用内部工作原理的更多信息。奇怪的是,我找不到与数据库后端建立连接的任何代码,当时真的引起了我非常大的兴趣。

第一次尝试失败后,我转而使用更加暴力的方法:由于我猜测ELBA5客户端使用了硬编码凭证,因此这些凭证必定位于内存中的某个位置。快速搜索useruidpasswordpwd等字符串后,我并没有发现任何有趣的内容。 因此我猜测,在建立初始连接后,这些凭证可能会立即被清除。 此时就轮到暴力方法登场了:我下载了微软的procdump工具,在启动ELBA5时尽可能快地导出程序的内存。导出的内存如下所示,这种方法的确有效。我最终找到了两个有效的后端用户凭据:connectorelba

再次安装ELBA5网络版后,我证实了connector用户始终使用相同的静态密码,而elba用户的密码并非一成不变。这的确是一个问题,因为只有elba用户拥有管理DBA的权限。 基于这些信息,我猜测这种环境中必须有两个步骤来进行身份验证:

0x03 具体细节

仔细观察调试机器上的connector用户的权限后(我知道该环境中的DBA密码),我发现该帐户仅被授权访问单个表中的单个列。此时我知道了加密后的DBA密码的存储位置。我将daten列的内容与已知的elba密码进行比较后,我发现该密码经过加密处理(或至少被混淆处理过),因为这两者完全不同。

因此我不得不再次仔细查看应用的源代码。经过几个小时的调试后,我最终发现了一条有趣的注释:

数据库逻辑是否已经“对外封装”到一个单独的库中?为此,我从systemtools.dll库中提取了所有字符串,立马就能看到一些不同寻常的地方:

上图中高亮标记的SQL命令可能用于解密加密后的elba DBA数据库密码。我推测这里使用了AES加密算法来保护密码。但是,仅从静态字符串中我无法提取所需的密码。所以我不得不使用更加动态的方法::Immunity Debugger。

在上述字符串的内存地址上设置断点(以及几个小时的调试)后,我在堆栈上找到了以下信息。 高亮部分中包含用于解密elba用户密码的硬编码密钥。

0x04 利用已有信息

综合以上信息后,现在我们可以准确提取出每个ELBA5网络版的DBA权限信息:

1、使用硬编码的connector用户连接到数据库,然后SELECT获取经过AES加密的DBA用户密码;

2、在Immunity Debugger的帮助下,使用静态的AES密钥来解密该密码;

3、使用elba用户和解密出来的密码连接到数据库。我们现在可以完全控制存储在数据库中的所有信息。

然而,这只是有趣旅程的开始。

0x05 添加后门用户

由于我们的目标是银行应用,我认为此时多赚取一点额外的现金肯定是很棒的一件事。那么,要不要说一下添加后门用户?

再次分析源代码后,我发现了该应用会将用户的密码存储在BEDIENER表中。

分析所有相关方法后,我梳理出了更具可读性的代码:

这样我们就可以将任意用户远程添加到ELBA5实例中,并且在逻辑上具有管理员权限:

0x06 远程代码执行

稍等,还有很多事情可以做。从测试者的角度来看,我们更关心控制服务器,而不是窃取金钱。幸运的是,我们可以使用ELBA5 SQL Anywhere数据库服务器中我们熟悉的一个老伙伴:xp_cmdshell。这条SQL命令可用来在操作系统上运行任意应用。更令人感兴趣的是,这个数据库以完整的SYSTEM权限来运行:

这意味着我们还可以添加新的Windows管理员,这样我们就可以完全控制被攻击的服务器。比如我们可以使用Mimikatz等工具。

0x07 PoC

为了自动化这个攻击过程,我开发了一个具备完全功能的python漏洞利用脚本。该脚本可以用来将新的ELBA5用户添加到数据库中,也可以远程运行目标系统上具有SYSTEM权限的命令。唯一需要满足的是ELBA5 SQL Anywhere数据库服务运行的是易受攻击的版本,并且可以通过网络进行访问(TCP端口2640)。

大家可以访问此处下载完整的利用代码。

0x08 协调漏洞公布进度

这里我还想简要讨论一下我与ELBA5的开发人员一起协调的漏洞公开披露流程。我于去年最早提交了相关漏洞,厂商在几天内就进行了确认。正如一些人猜测的那样,这更像是一个架构问题,因此需要进行复杂的重写和测试。在此过程中,我总共两次被要邀请讨论当前问题状态。我们开诚布公地谈论了相关风险以及如何减轻这个风险。

我希望所有人都能了解这个问题的完整过程。没有多少公司会认真对待IT安全,这个问题真实地展示了该厂商对合作伙伴和最终用户的重视程度。再次表示我的谢意。

0x09 缓解措施

这个协调过程对最终用户来说也很重要。用户唯一要做的就是从https://www.elba.at安装最新的ELBA5 5.8.1版本。厂商进行了大量测试,使得新的认证模块对用户完全透明。

0x0A 总结

我一直认为对关键内容的总结很重要,因此我稍微总结了一下,如下图所示。该图整体介绍了底层漏洞原理和解决方案,这个演示文稿也有德语版本。

如果大家有任何问题,欢迎随时联系我(florian@bee-itsecurity.at)。

点击收藏 | 0 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖