分析电子银行应用ELBA5中的远程代码执行漏洞
分析电子银行应用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客户端使用了硬编码凭证，因此这些凭证必定位于内存中的某个位置。快速搜索user、uid、password、pwd等字符串后，我并没有发现任何有趣的内容。 因此我猜测，在建立初始连接后，这些凭证可能会立即被清除。 此时就轮到暴力方法登场了：我下载了微软的procdump工具，在启动ELBA5时尽可能快地导出程序的内存。导出的内存如下所示，这种方法的确有效。我最终找到了两个有效的后端用户凭据：connector及elba：
再次安装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 总结
我一直认为对关键内容的总结很重要，因此我稍微总结了一下，如下图所示。该图整体介绍了底层漏洞原理和解决方案，这个演示文稿也有德语版本。
如果大家有任何问题，欢迎随时联系我（[email protected]）。