我不久之前从事IT，但是最近我对网络安全这一话题感到迷惑。五学期的职业特别有趣。在浏览时，我看到了由Security Shenanigans撰写的很酷的文章“配置错误的数据库如何使我们拥有超过25K主机的整个云”。这两部分的翻译并引起您的注意。
介绍
在本文中，您将学习我们如何使用BMC / IPMI来执行与数据库的直接sqlmap连接，以危害大型客户端。
背景
几年前，我们的团队收到了一项任务：在Openstack网络上进行基础架构渗透测试。它由大约2,000台物理服务器组成，托管了25,000多个虚拟机。我们从一个小型子网开始了工作，该子网限制了传出流量。快速扫描后，Nmap无法找到任何可以利用的明显漏洞。因此，我们开始研究可为我们提供的服务。其中，我们发现了托管在开发服务器上的无防御PostgreSQL服务器。在使用公司名称的几种派生词创建自定义单词表后，我们能够使用来自帐户的相对简单的数据潜入系统。用户名是Postgres，密码是“ admin”。
接下来，我们决定使用sqlmap。该工具是为使用SQL注入而构建的，但是在建立直接数据库连接时（如果您具有凭据），它也可以为您提供多种选择。这些选项之一是针对生产中的数据库启动命令外壳。
在测试完外壳之后，我们决定构建一个自定义的有效负载（有效负载）以获取反向连接。这将使工作更舒适。
我们使用msfvenom构建了有效负载。在这种情况下，有效负载是Linux x64计算机的反向TCP Shell。在上图中，您可以看到我们需要选择数据库体系结构。
使用msfvenom收集有效负载
此有效负载的优点在于，可以使用简单的Netcat将其用于重新连接。大多数其他有效负载都需要类似Metasploit的东西（选择利用/多重/处理程序）来完成相同的任务。
使用sqlmap包装器运行有效负载后，我们获得了与服务器的连接。
启动有效负载重新连接
并测试访问
使用BMC设备
每当您运行基础结构渗透测试并破坏新网段上的计算机时，都应重新扫描以查看是否有新事物出现。该数据库使我们能够连接到公司的云网络，包括大多数虚拟机和主机。我们发现了几台BMC设备，对新扫描的结果感到非常满意。
三个BMC设备之一
BMC（基板管理控制器，服务处理器）是连接到主服务器的首选嵌入式设备，可提供带外监视和控制。它独立于CPU，BIOS和操作系统运行。这些元素中的任何一个发生的错误都不能影响其操作。该微控制器具有自己的处理器，内存和网络接口，因此即使服务器本身已关闭，该微控制器仍然可用。所有主要设备供应商的产品都有特定的BMC：
- 戴尔DRAC
- IBM IMM
- 惠普iLO
- 超微IPMI
您需要熟悉的另一个术语IPMI（智能平台管理接口）基本上是用于与这些设备进行通信的协议。其目的是监视和管理服务器硬件，而不管操作系统是什么，即使服务器已关闭但已连接到电源也是如此。
只能说IPMI是迄今为止可以找到的最不安全的协议之一。为了给您一个想法，IPMI 2.0的设计方式是，您可以在身份验证步骤中直接从服务器请求自定义哈希。当您以“密码0”模式请求授权时，存在另一个漏洞，该漏洞使您可以使用任何密码登录。 您可能会发现
IPMI块体系结构
BMC设备通常没有得到很好的保护，因为它们是一种在数据中心组装阶段配置一次的设备，然后仅在服务器无法通过常规方式使用时才使用。
我们能够在启用了密码0的某些设备上轻松进行身份验证。
在这里，您可以看到我们如何使用随机密码登录。注意“ -C 0”部分。
使用随机密码成功登录到设备的设备的
网络信息
即使某些设备上未启用密码0，您仍然可以使用其他方式登录。最为著名的两个是使用默认凭据（系统管理员通常不尝试更改）或利用哈希公开漏洞（然后破解哈希）。后者必须在大多数设备上完成。
大多数用户的默认默认用户名/密码对
包含我们从服务器请求的包含用户哈希的单词列表
使用metasploit扩展自定义散列
立即获得有关典型散列的数据
在遍历所有散列之后，我们开始破解它们。
破解第一个哈希
在几分钟内，我们可以访问约600 BMC。
成功破解了609个散列值
我们无法破解一些HP ILO设备。对我们来说幸运的是，HP iLO 4 1.00到2.50也具有身份验证旁路。这允许您通过Web服务器处理的HTTP连接头中的缓冲区溢出来创建管理员帐户。 漏洞利用此漏洞获得对其余API的特权访问，从而使您拥有创建帐户的权限。
使用CVE-2017-12542
经过这些步骤，我们可以完全控制公司90％的BMC设备。如果您已阅读有关BMC设备的信息，那么现在您知道它们使您能够：
- 监控
- 重启
- 重新安装
- KVM（虚拟化）
连接的设备。一切都很好，但是它们仅模拟对服务器的物理访问，您仍然需要进入内部。是的，您可以通过关闭设备来闲逛，但是我们认为这还不够，因此我们不断进行挖掘。
破解具有物理地址的硬件的最常见方法之一是重新启动它并控制根外壳程序的自动运行。您可以在Unix，Mac和Windows上执行此操作。
这种方法的困难在于，每个服务器通常托管大约2000个虚拟主机。因此，我们需要找到一个未使用的服务器。计划是将其关闭（如果已经关闭，则将其启动），然后编辑自动运行以授予我们root访问权限。之后，我们希望查看配置以查找任何漏洞/有效载荷，这些漏洞/有效载荷也将使我们也可以破坏其他服务器。
Openstack允许您查询本地基础结构和查询特定参数。其中之一是虚拟机的状态，在这家本地公司的情况下，其定义为VM的可用性（用于接收流量的白名单/黑名单）+操作状态（已启动/已禁用）。
我们需要找到一个列入黑名单的服务器（工作状态无关紧要），并且由于磁盘问题我们发现其中一台服务器不工作。幸运的是，我们能够启动，但是文件系统的某些部分最终以只读模式运行。
Openstack请求合适的黑客服务器
找到它之后，我们使用之前找到的凭据登录。
使用先前获得的访问
权限访问KVM接口KVM
接口模拟通过BMC与服务器的直接连接。在启动时，您需要编辑Grub自动加载并添加
ro init = / bin / bash到相应的行以启动到根shell中...通常，使用读/写标志（rw），但我们必须使用只读标志（ro）来防止发生故障的磁盘出现任何问题。
编辑grub菜单
登录后，我们检查了网络接口以测试与服务器的连接。如您所见，ifconfig显示了10个以上的活动接口。
在花了一些时间分析网络结构并了解我们的位置之后，我们开始研究服务器。
几分钟后，我们在bash_history中找到了bash_history（可在Linux机器上找到的有价值信息的最佳来源之一）的
中间立场
对于不熟悉Openstack架构的人员，Nova是一个管理数据库，用于存储整个云的管理信息，例如证书，配额，实例名称，元数据以及更重要的信息。
检查凭据
登录后，我们使用Grants_MySQL检查了管理员访问权限。
完成此操作后，我们可以看到NovaDB的内部结构。
Novadb数据库中的表
查看有关VM的信息，我们可以看到大约34,000个设备。但是，其中约有三分之一不可用/不工作。确切的数量可以在行条目float_ips中看到。
让我解释一下为什么来自数据库的数据如此重要。
如果要关闭整个公司，则可以通过BMC界面关闭每个虚拟服务器。在系统管理员重新启动之前，它们将无法工作。
您可以编写自己的恶意软件来感染所有服务器，但是通过BMC通道进行大规模部署并不容易（请记住，在访问Grub自动运行之前，我们必须启动未使用的服务器来编辑Grub自动运行）。
但是，通过访问NovaDB，您可以简单地破坏数据库，并且整个云环境将停止工作。即使假设sysadmin足够聪明，可以快速查看数据库，对损坏的数据库进行故障排除也比丢失数据库困难得多。
另外，系统管理员可以找出问题所在，并用最新的备份覆盖所有内容，对吗？我们也考虑过了。这就是为什么我们继续进行并破坏备份的原因。
最初，我们尝试使用诸如之类的查询主数据库
SELECT * FROM information_schema.PROCESSLIST AS p WHERE p.COMMAND = 'Binlog Dump'; ，但该公司使用了自己的备份解决方案，该解决方案运行不规则，并且没有使用主/从方案。因此，我们继续扫描相邻的子网，以查找与主端口运行在同一端口上的备份数据库。
我们如何找到备份的方法
我们检查了使用现有凭据的可能性，当然，还提出了这些凭据。
验证对备份的访问权限
使用我们自己的备份，我们能够证明虚拟化基础架构的完全妥协以及在几分钟之内完成操作的一种方法。
我总是喜欢以对可能发现的问题进行修复的方式结束审查/报告。此外，其中有很多，例如：
- 重用凭证
- 没有网络分段
- 普通密码
- 不安全的备份结构
- 固件过时
一个不容易解决的关键问题是IPMI协议中的缺陷。
最成功的解决方案是将启用BMC的服务器放置在具有受限IP地址列表的不同网段上。这是这家公司最终所做的。
希望您喜欢我们的故事。在学习这个主题的过程中，我们获得了很多乐趣。