Skip to content

目的

  • 研究如何发现的这个漏洞
  • 自己研究出来payload
  • 思考问题的本质是什么
  • 举一反三，是否有其他的组件同样存在相关的漏洞

CVE-2023-42820 简介：在jumpserver使用的 django-simple-captcha 模块作为验证码的校验模块，其在重置密码的环节当中，会存在一个问题：重置密码的code是来源于随机数的生成，然而随机数的种子我们能够进行查看。并且能够进行模拟该种子进行预测最后的随机数。

redis 连接不上

可以学习下 如何配置的 docker环境，我当初在这里一直没有完成 redis环境的配置

漏洞简述 ： 分为几个阶段

  1. 随机数种子seed 曝光，生成图片 1
  2. 刷新使用验证码图片2
  3. 反复请求图片 1的地址
  4. 预测出 code

captcha的过程

  1. aptchaField内部会生成随机的验证字符串（challenge）和答案（response）
  2. challenge可以是传统的4个字符的文本，也可以是我博客或Jumpserver中使用的四则运算，这个通过配置来定义。
  3. hashkey = func(challenge,response)，hashkey和验证码是对应存在的
  4. 开发者使用 hashkey + captcha_image 视图 --》 加入 url routers当中 == 最后生成的图片
  5. 用户看到图片之后，random.seed(key)，key 为 hashkey

验证码的逻辑

  1. 用户进入页面之后，后台生成 challenge【计算的方式，可能是】和 response【直接就是答案】，根据这两个数又生成 hashkey，返回hashkey
  2. 用户传输hashkey到后台，后台通过hashkey 得到相关的 challenge和response，并且通过hashkey作为种子，再进行随机生成图片的噪点，最终返回一张图片。【但是实际上都是伪随机的】
  3. 用户得到一张图片之后，输入 answer 并和 hashkey一起进行提交，服务端拿到answer和challenge进行计算，最终进行比对。

在哪里进行创建并返回相关的 hashkey？

generate_key
    fetch_captcha_store
    CaptchaTextInput#render
        #generator=None Class CaptchaTextInput 
        #self.generator = generator
        Class CaptchaField

如何进行搭建docker docker-compose 和 env 的属性应当如何进行书写 我之前所进行纠结的 redis是什么问题

引申

提问

这个漏洞是如何被发现的？ 其漏洞引用的是第三方的 组件的漏洞，应当发现大家都使用到的第三方组件

其深层次的能力： 需要对 python 的django的项目的随机数的原理了解，或者在不了解的情况下，能够进行探索其中的伪随机漏洞

CVE-2023-42819 读取文件或者上传文件

python 任意文件读取的技巧

在Django等使用python语言进行开发的web平台上，如果使用 os.path.join 来连接目录和文件 例如 

os.path.join(BASE_DIR, 'static', 'app.js')

当我们能够进行控制'app.js'这个位置的时候，即使前面对参数有判断其中是否存在 ./ .. 等符号，进行了限制。我们依旧可以使用 绝对路径进行覆盖，并且使用绝对路径的情况下，会忽略这个路径之前已经Join的所有内容。
举例 

BASE_DIR="/ss/ss"
path="/etc/passwd"
if path.find('./') >= 0 or path.find('..') >= 0:
    raise ValidationError('...')

path = os.path.join(BASE_DIR, 'static', path)
print(path)

CVE-2023-42442 目录权限被绕过导致的录像文件被下载

JumpServer的Core模块基于Django进行开发，包含两种类型的后端视图

  • 基于原生Django与模板渲染的视图
  • 基于Django Rest Framework DRF的API视图

DRF的Permission的基础权限类存在两个接口

  • has_permission 判断列表相关方法的权限
  • has_object_permission 判断数据库对象相关方法的权限

发现 展示 session列表的 接口，其可以获取所有的详情信息 但是只是做了 has_object_permission判断
当发现 path 是以 xpack/ 或 setting 开头的时候，直接返回True 所以payload 为此直接绕过权限校验 xpack/../

https://www.leavesongs.com/PENETRATION/jumpserver-sep-2023-multiple-vulnerabilities-go-through.html

csrf的防御 https://www.leavesongs.com/PENETRATION/think-about-cookie-form-csrf-protected.html

Back to top