把SQL服务器黑了是件很有趣的事儿。今年早些时候，我发了篇有关于黑掉SQL服务器而不用密码的博客。我利用Ettercap制作了一个中间人攻击，并将它放在了微软SQL服务器和用户之间。利用Ettercap过滤器，我展示了如何立刻将SQL的查询替换成你自己的恶意查询。这允许你去运行一系列的攻击，如制作一个数据库的管理员用户来帮助你获得数据或者执行功能。我写了一个脚本来使得整个过程能够自动运行，供大家学习使用。
当脚本工作时，它会有一些限制。第一，你必须知道数据库正在运行的SQL查询。一般来讲，你不大可能有这样的消息。第二，脚本依赖于Ettercap来运行MITM攻击。最后，它只支持微软SQL服务器。虽然它是一个很流行的数据库引擎，但它只代表了数据库种类中的一小部分。
在最近的一个对于Anitian用户的渗透测试中，我决定重写一下整个工具，来将我所进行的一些测试变成自动化。目标是做成一个一体化的SQL MITM工具。你可以用一下的表格来下载这个Python原程序。（这里是对于你要进行的下载的条款）
由于之前的博客已经详细说明漏洞以及如何补救的方法，这篇博客则主要讲解如何利用这个工具来查找SQL MITM漏洞。
Options
这个工具有五个必须的项目。
交互界面：要去监听的网络交互界面。
SQL 类型：第二个项目需要提供具体的SQL服务器类型。目前，工具支持MSSQL，MySQL，Oracle和PostgreSQL.这是目前最为流行的四种数据库引擎。
用户 IP：发送请求SQL用户的IP地址。
服务器IP：SQL服务器的IP地址。这两个IP地址允许脚本进行ARP毒化攻击。这表明这个程序能自己执行MITM攻击而不需要诸如Ettercap的外部工具。
新请求：新的SQL请求。这是一个有害SQL字符串，它们会被植入到连接中。
同样，还有两个可选条目
开始关键字：脚本搜索的第一个关键字。
结束关键字：脚本所要搜索的最后一个关键字（或者字符）。
这两个项目是原始SQL字符串中的开始和结束关键字。从这些关键字可以辨认出SQL请求而不需要提前知道整个请求。比如说，开始关键字的默认值是“选择”，而结束关键字的默认值是分号。这满足所有如下的例子：
这使得这个脚本拥有较好的通用型。你不需要知道具体的SQL请求来插入有害请求。
Scapy
我使用Python来进行这个项目，原因是它用起来很简单，并且我能利用它所拥有的Scapy操作库。Scapy有对于很多协议的内在支持，在这个情形下，重要的是TCP和ARP协议支持。它能够用来当作独立的数据包操作程序，或者是其他项目的库文件。
ARP 毒化
攻击的第一步是毒化用户和服务器的ARP缓存。这一步欺骗你的服务器将主机当作用户，反之亦然。你所有需要做的仅仅是将用户和服务器IP地址输入就好了。这个脚本利用ARP来辨认相应的MAC地址。然后，脚本调用arp_spoof()函数。这个函数能够构建正确的ARP数据包来毒化用户和服务器缓存。利用一个计时器，arp_spoof()函数每15秒被调用一次。这保证缓存器能够在攻击期间保持被毒化的状态。
Scap_sniff()函数被用来嗅探数据包。这个函数会一直嗅探输入的数据包并一直循环下去，直到攻击者按下了ctrl+c来跳出程序的执行。每当线上有数据包被探测到的时候，sniff()函数会利用过滤器来分辨这个数据包是发送给SQL服务器IP的还是用户IP 的。如果不是，那么这个数据包会被忽略掉。如果真是这样，那么数据包会被送到processPacket()函数。
数据包处理
这儿是所有神奇的事情发生的地方。脚本会根据攻击者所选择的SQL引擎类型来处理数据。它在整个数据包中搜索开始和结束字符。如果找不到，那么就将数据包正常发送出去。
如果它找到了，那么它会比较原始请求的长度和新请求的长度。如果新请求比较长，那么脚本给出个错误，然后将原始数据包送出并不做改变。这是因为TCP的工作方式。被改变的数据包必须要和原始数据包一样长，不然则会打破TCP连接，并导致重启。结果就是，原始请求越长，你能拥有的替换空间就越大。
如果新的请求比原始请求要小，那么一切都很好。脚本用新的请求更新数据包，并在数据包的尾部增加一些补丁，用以将数据包保持原有的长度。然后，修改好了的数据包会被送到服务器。
Re-ARPing
在攻击的最后，按下ctrl+c来停止程序。脚本会检测到这个反应，并在结束前调用undo_arp_spoof()函数。这会重置ARP存储器，如此一来，受害者会正常地接受消息。如果没有这一步，用户和服务器会有联网问题，并且攻击会被简单地发现。
下面是一些例子。
MSSQL
首先，我会用Microsoft SQL来验证这个软件。我创建了一个简单的测试数据库，如下所示。
你可以看到在产品表中有三条输入项。下面我会运行一个基本的命令来从表中抽取一个简单的目标。
你会看到我查找了名为ProductZero的产品。服务器仅仅返回了一个匹配的输入。然后我运行了sqlmitm.py脚本来注入有害命令。
利用这些声明，脚本会替换SELECT为我所选择的的命令。意思是说，不管我用SELECT从数据库中选择了什么，服务器的返回值永远是ProductOne这一输入项。
你可以看到我运行了一个请求来提取 ProductZero数据，但是服务器回复了ProductOne！这个回复并不正确！MITM脚本在传输中替换了请求。客户并不知道这一事件发生了。这一过程允许所有目的的恶意程序。
MySQL
现在，我们来试试MySQL。我构建了一个类似的数据库来测试MySQL服务器。
下一步，我运行了sqlmitm.py脚本，但是这次我设置成攻击MySQL服务器。
你可以在输出发现脚本分辨出了一个匹配的数据包并替换了语句。
但是在用户端看是什么样子？
你会发现我试图去提取“Test Product 1”的信息，但是服务器却给了我“Test Product 2”.同样，客户端并没有发现任何问题。
Oracle
下一步，我来测试Oracle.这里是测试用数据库。
然后，继续来运行这个脚本。
当它已经被设置好并在运行时，我运行了另一个相似的命令。
服务器又给了错误的回复。
PostgreSQL
过程依然是相似的。这里是测试用数据库。
运行脚本。
运行命令。
脚本又一次替换了数据并且用户端依然不知道发生了什么。
创建一个MySQL用户
之前的例子都是无害的。下面我来试试比较有危害性的事儿：来建一个MySQL上的用户？这需要三步操作。
第一步，我们来创建数据库用户。
这一请求会创建一个名为“anitian”的用户，并允许这个用户从任何地方登录。用户的密码是“hacked”。在运行完mitm脚本之后，我回到MySQL用户，并执行一个无害的SELECT请求。
注意到，没有行真正被返回了。我们的返回值与请求并不相符。但是，如果这个请求时从一个应用程序发出的，估计谁都不会发现。
下面，我们来提高用户的权限。这会给我们制造的用户所有的权限，只要受害者拥有这些权限。
我又运行了一次SELECT请求。
没有错误被返回。看来命令执行成功了。最后，我们需要告诉MySQL服务器去掉这些权限。
然后我再最后运行一次SELECT请求。
现在，用户应该已经被创建了。现在来试着登录吧。
成了！它开始工作了！现在我们创建的用户拥有数据库的控制权限。当然，这意味着你可以所任何你想做的事情，例如偷点受保护数据什么的。这仅仅是这个脚本能做的一个例子。
保护自己
在这一系列的一开始，我们讨论了如何来避免这种攻击。这个脚本仅仅只能在未加密的数据库连接中使用，或者你可以用假身份来打破这个加密。如此一来，避免SQL MITMM攻击的最简单方法就是要求所有的SQL通信都是有加密且有认证的。
第二，永远遵守最低权限原则。远程账户只能拥有最基本的功能。管理员权限要被严格限制。
最后，同所有的安全问题一样，保持你的系统和固件都被打上了漏洞补丁。
- 4HOU.COM
评论