Werkzeug更新带来的Flask debug pin码生成方式改变

前言：  

      首发在Freebuf：https://www.freebuf.com/articles/network/238485.html 于2020.4月成稿，时隔3个月被发布，内容为flask debug pin码构造方式的改变。

 

正文：

       复现2020GYCTF-FLASKAPP及 2019CISCN double_secret出现异常。题目本身有两个解题方式。其中一个思路是：

当Flask开启debug模式时，可以在报错页面输入pin码来执行python命令。

pin码需要配合SSTI或文件包含等情况获取系统信息来构造。有SSTI即可执行python命令，因而题目一般会严格过滤来框定做题路径。

 

 

关于flask pin码构造已经有许多文章了：

  https://www.anquanke.com/post/id/197602

  https://xz.aliyun.com/t/2553

  https://www.cnblogs.com/HacTF/p/8160076.html

 

但按照以往的解题操作无法复现成功。甚至对于同一个题目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

/usr/local/lib/python3.7/site-packages/flask/app.py

/usr/local/lib/python2.7/site-packages/flask/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码构造方式都发生了变化。而网上还没有相关的信息发布，这是个值得注意的解题点。如果事前没有注意到这一点，再去解此类题目时，则会掉进“坑”里。