freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

Werkzeug更新带来的Flask debug pin码生成方式改变
2020-07-02 21:49:52

复现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

1591001972_5ed4c37457db8.png!small

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

1591002007_5ed4c397e4b05.png!small

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。

1591002109_5ed4c3fddb7fd.png!small

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

# pin码 # werkzeug # Flask debug
本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者