FreeBufWerkzeug更新带来的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码即可:
【FreeBufWerkzeug更新带来的Flask debug 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

本文插图
修改前是依序读取/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）