回归最本质的信息安全

如何黑掉SQL服务器?

2016年9月26日发布

3,208
0
0

导语:把SQL服务器黑了是件很有趣的事儿。今年早些时候,我发了篇有关于黑掉SQL服务器而不用密码的博客。

把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通信都是有加密且有认证的。

第二,永远遵守最低权限原则。远程账户只能拥有最基本的功能。管理员权限要被严格限制。

最后,同所有的安全问题一样,保持你的系统和固件都被打上了漏洞补丁。

本文翻译于antian,如若转载,请注明来源于嘶吼: http://www.4hou.com/info/news/1831.html

点赞 0
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

Change

Change

嘶吼编辑

发私信

发表评论