Werkzeug更新带来的Flask debug pin码生成方式改变
Werkzeug更新带来的Flask debug pin码生成方式改变
复现2020GYCTF-FLASKAPP及 2019CISCN double_secret出现异常。题目本身有两个解题方式。
其中一个思路是:
当Flask开启debug模式时,可以在报错页面输入pin码来执行python命令。
pin码需要配合SSTI或文件包含等情况获取系统信息来构造。有SSTI即可执行python命令,因而题目一般会严格过滤来框定做题路径。
关于flask pin码构造已经有许多文章了:
但按照以往的解题操作无法复现成功。甚至对于同一个题目2019CISCN double_secret的最新解法说明https://www.anquanke.com/post/id/197602也无法成功。
由于pin码构建需要6个参数,不同环境下,参数会有变化。因而一开始怀疑是自己的某些参数不正确。具体需要获取的参数是以及生成pin码的代码在/site-packages/werkzeug/debug/__init__.py
我们只要集齐6个参数,再按照__init__.py中的代码生成PIN码即可:
username 启动这个Flask的用户
modname 一般默认flask.app
getattr(app, '__name__', getattr(app.__class__, '__name__')) 一般默认flask.app为Flask
getattr(mod, '__file__', None)为flask目录下的一个app.py的绝对路径,可在爆错页面看到
str(uuid.getnode()) 则是网卡mac地址的十进制表达式
get_machine_id() 系统id
除了默认不变的参数,其他参数我们可以这样获得:
username
可以从/etc/passwd或者/proc/self/environ环境变量中读取
网卡地址
读取这两个地址:/sys/class/net/eth0/address /sys/class/net/ens33/address
getattr(mod, '__file__', None)
flask目录下的一个app.py的绝对路径,这个值可以在报错页面看到。但有个坑,python3是app.py,python2中是app.pyc
machine_id()
linux读取这三个文 /proc/self/cgroup、/etc/machine-id、/proc/sys/kernel/random/boot_id
windows读取注册表中的HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Cryptography
异常:
一开始按照原先的解释和去读取信息然后构造PIN码,但得到的PIN码错误,仔细检查参数值,也没有异常。最后在docker中调试输出参数,才发现get_machine_id()生成的值与以往不同的。然后才意识到应该是Flask下的werzeug版本更新,代码发生了变化,而且这个更新应该是在近期。
去查阅github项目,找到了对应的修改,在1月5号:get_machine_id unique for podman
https://github.com/pallets/werkzeug/commit/617309a7c317ae1ade428de48f5bc4a906c2950f
修改前是依序读取/proc/self/cgroup、/etc/machine-id、/proc/sys/kernel/random/boot_id三个文件,只要读取到一个文件的内容,立马返回值。
修改后是从/etc/machine-id、/proc/sys/kernel/random/boot_id中读到一个值后立即break,然后和/proc/self/cgroup中的id值拼接。
注意:根据环境不同,这三个文件并不是都存在的
python:3-slim-stretch下3个文件都存在,python:2.7-alpine下/etc/machine-id不存在
思考:
那如果我们在Dockerfile中指定Flask的版本来构建Docker镜像,是否能避免上述问题呢?
测试:
使用命令开启一个纯净的python环境:
docker run -dti python:3-slim-stretch
进入容器中执行命令安装老版本Flask:
pip install Flask==1.0.2
可以看到,pip自动下载了最新版本的werkzeug。
(2020.4.13 flask最新版本为1.1.2,werkzeug最新版为1.0.1)
当然如果指定了Werkzeug版本就可以避免该情况
Flask==1.0.2
Werkzeug==0.14.1
那么也就是说,只要是在2020.1.5之后构建的题目镜像,没有指定werkzeug版本的情况下,其PIN码构造方式都发生了变化。而网上还没有相关的信息发布,这是个值得注意的解题点。如果事前没有注意到这一点,再去解此类题目时,则会掉进“坑”里。