AbdaullahAG/autonomous-ai-red-blue-lab

## ⚡ 关键数据 | 指标 | 阶段 1 (PoC) | 阶段 2 (自主) | |--------|:---:|:---:| | 🏗️ 应用构建与部署 | ~15秒 | ~15秒 | | 💥 完整攻击周期 (nmap → SQLi → XSS) | **70秒** | **70秒** | | 🛡️ 补丁生成与重新部署 | ~30秒 | **~30秒** | | 🔁 验证循环 | 手动 | **自主** | | ⏱️ **端到端总耗时** | **取决于人类速度** | **< 2 分钟** | | 💰 **总 API 成本** | **~$0.08** | **~$0.08** | | 👤 **人工干预** | **每个阶段都需要** | **零** | ## 🎯 项目简介 这是一个完全自主的 **AI 网络安全研究实验室**，两个不同的 AI 模型在真实的攻击-防御-修补-验证周期中展开正面交锋。 - 🔴 **红方智能体** (`GPT-4o`) 使用 `nmap`、`sqlmap` 和 `curl` 进行攻击，然后编写结构化的威胁情报报告 - 🔵 **蓝方智能体** (`gpt-5.2`) 构建目标应用，阅读攻击报告，使用纵深防御技术修补漏洞，并重新构建容器 - 🔴 **红方智能体** 对修补后的代码进行重新测试 —— 切换角色充当**中立安全审计员** - 🧠 **编排器** (`orchestrator.py`) 将所有内容连接成一个实时的闭环流水线 **关键设计决策：** 使用两个不同的模型（GPT-4o 对决 gpt-5.2）创造了真正的不对称性 —— 每个模型为其角色带来了不同的推理模式，使得实验比单一模型扮演双方角色更具现实意义和科学严谨性。 ## 🏗️ 系统架构 ``` flowchart TD O([🧠 orchestrator.py\nMaster Controller]) O -->|Phase 1: Launch attack| R subgraph RED ["🔴 Red Agent — GPT-4o"] R[Recon: nmap] --> R2[Exploit: SQLi + XSS\nnmap · sqlmap · curl] R2 --> R3[Generate structured\nthreat intelligence report] end R3 -->|Attack report + raw logs| O O -->|Phase 2: Report + vulnerable source code| B subgraph BLUE ["🔵 Blue Agent — gpt-5.2"] B[Analyze attack vectors\n& vulnerable code] --> B2[Rewrite app.py\nwith secure patterns] B2 --> B3[Parameterized Queries\n+ html.escape + CSP Headers] end B3 -->|Patched app.py| O O -->|Phase 3: Hot-reload| D subgraph DOCKER ["🐳 Docker Container — Python 3.11 / Werkzeug 3.1.8"] D[docker compose down\nRemove infected container] --> D2[docker compose up --build\nBuild from patched code] D2 --> D3[Secure webapp live\nlocalhost:5000] end D3 -->|New container running| O O -->|Phase 4: Send patched source for audit| R4 subgraph VERIFY ["🔴 Red Agent — Verification Mode"] R4[Reason about patched code\nSimulate previous payloads] --> R5{Bypass\nfound?} R5 -->|No| SEC[✅ SECURE\nPatches confirmed] R5 -->|Yes| LOOP[🔁 Loop back\nto Blue Agent] end style O fill:#1a1a2e,color:#fff,stroke:#e94560 style RED fill:#2d0000,color:#fff,stroke:#ff4444 style BLUE fill:#001a2d,color:#fff,stroke:#4488ff style DOCKER fill:#002d1a,color:#fff,stroke:#44ff88 style VERIFY fill:#2d1a00,color:#fff,stroke:#ffaa44 style SEC fill:#004400,color:#fff,stroke:#44ff44 style LOOP fill:#2d0000,color:#fff,stroke:#ff4444 ``` ## 🚀 快速开始 ### 前置条件 - Kali Linux (预装 nmap + sqlmap) - Docker + Docker Compose - Azure OpenAI 资源，包含**两个部署**：GPT-4o 和 gpt-5.2 - Python 3.11+ ### 1. 克隆与设置 ``` git clone https://github.com/YOUR_USERNAME/ai-red-blue-lab.git cd ai-red-blue-lab python3 -m venv venv && source venv/bin/activate pip install -r requirements.txt ``` ### 2. 配置凭据 ``` cp .env.example .env nano .env # fill in your Azure keys and deployment names python3 test_connection.py # Expected output: # 🔴 Red Agent (GPT-4o): ✅ Connection successful. Tokens: 15 # 🔵 Blue Agent (gpt-5.2): ✅ Connection successful. Tokens: 16 ``` ### 阶段 1 — 分步指南 (PoC) ``` # Deploy vulnerable target cd webapp && docker compose up -d --build && cd .. # Attack python3 red_agent/red_agent.py # Patch python3 blue_agent/blue_agent.py cd webapp && docker compose down && docker compose up -d --build && cd .. # Re-test bash red_agent/retest.sh ``` ### 阶段 2 — 完全自主 (单条命令) ``` python3 orchestrator.py ``` ## 📁 项目结构 ``` ai-red-blue-lab/ ├── 📄 README.md ← you are here (includes full write-up) ├── 📄 requirements.txt ├── 📄 .env.example ├── 📄 test_connection.py ← verify both model connections ├── 🧠 orchestrator.py ← Phase 2: single-command autonomous loop │ ├── 🌐 webapp/ │ ├── app.py ← vulnerable → patched Flask app │ ├── app.py.backup ← auto-saved before patch │ ├── Dockerfile ← Python 3.11-slim │ └── docker-compose.yml │ ├── 🔴 red_agent/ │ ├── red_agent.py ← GPT-4o powered attack + analysis │ ├── attack.sh ← nmap + sqlmap + curl pipeline │ └── retest.sh ← post-patch verification script │ ├── 🔵 blue_agent/ │ └── blue_agent.py ← gpt-5.2 powered patch agent │ └── 📊 logs/ ← auto-generated during run ├── red_team_report.txt ← raw attack output ├── ai_red_analysis.txt ← GPT-4o threat intelligence ├── blue_patch_report.txt ← patched source code ├── retest_report.txt ← verification results └── sqlmap/ ← sqlmap session + dumps ``` # 📖 详述：当 AI 攻击自身 ## 我脑海中挥之不去的想法 如果两个 AI 智能体相互对抗 —— 一个构建并防御 Web 应用，另一个试图攻破它会怎样？两个不同的模型。没有人工干预。无需等待。终端命令中没有拼写错误。 我运行了这个实验。结果比预期的更有趣 —— 不仅因为攻击和防御都起作用了，而是因为**一切发生得太快了**。 ## 环境设置 **两个模型。两个角色。一个隔离的 Kali Linux 虚拟机。** | 智能体 | 模型 | 角色 | |-------|-------|------| | 🔴 红方智能体 | GPT-4o (Azure OpenAI) | 攻击，分析发现，验证补丁 | | 🔵 蓝方智能体 | gpt-5.2 (Azure OpenAI) | 构建目标应用，修补漏洞 | **目标技术栈：** Flask · SQLite · Werkzeug 3.1.8 · Python 3.11.15 · Docker **为什么用两个不同的模型？** 使用 GPT-4o 进攻和 gpt-5.2 防御创造了真正的不对称性 —— 每个模型为其角色带来了不同的推理模式。单一模型扮演双方角色会产生有偏见的结果。 **关于工具的说明：** 我们最初使用 AutoGen 进行智能体编排，但遇到了库冲突 —— AutoGen 内置的 `openai` v0.x 与现代的 `openai` v1.x SDK 发生冲突。我们废弃了它并直接调用 Azure OpenAI API。更简单，更快，没有任何魔法。 ## 阶段 1：概念验证 ### 第一幕 —— 蓝方智能体构建目标 ⏱️ 15秒 蓝方智能体 (`gpt-5.2`) 接到一个指令：构建一个 Flask/SQLite Web 应用，通过 Docker 部署，并为实验故意在其中留下两个漏洞。 **漏洞 1：SQL 注入** ``` # ❌ User input injected directly into SQL query query = f"SELECT * FROM users WHERE username='{user}' AND password='{pwd}'" cur.execute(query) ``` **漏洞 2：存储型 XSS** ``` # ❌ Raw user input stored and rendered without sanitization comments_html = "".join(f"

{r[0]}

" for r in rows) ``` 数据库预置了两个用户：`admin:secret123` 和 `alice:pass456`。 从执行脚本到 `Container vulnerable-webapp Started`：**15 秒**。 ``` $ curl -s http://localhost:5000/login | grep -o "

.*

"

Login

# ✅ App is live on port 5000 ``` ### 第二幕 —— 红方智能体攻击 ⏱️ 70秒 红方智能体 (`GPT-4o`) 自动运行了四阶段的攻击脚本。 **阶段 1 —— 侦察：nmap (6.38 秒)** ``` PORT STATE SERVICE VERSION 5000/tcp open http Werkzeug httpd 3.1.8 (Python 3.11.15) ``` 框架版本指纹已识别。我们清楚自己面对的是什么了。 **阶段 2 —— 手动 SQL 注入 (< 1 秒)** ``` Payload: admin' OR '1'='1 Response: ✅ Welcome admin! ``` 第一次尝试就绕过了登录。经典的基于 OR 的注入。 **阶段 3 —— sqlmap 自动化扫描 (10 秒)** sqlmap 自动识别出后端为 SQLite，然后在同一个 `username` 参数上发现了**三种注入技术**： ``` Type: boolean-based blind Payload: username=admin' AND CASE WHEN 1348=1348 THEN 1348 ELSE JSON(CHAR(69,74,90,69)) END AND 'xgKy'='xgKy Type: time-based blind Payload: username=admin' AND 7314=LIKE(CHAR(65,66,67,68,69,70,71), UPPER(HEX(RANDOMBLOB(500000000/2)))) AND 'fesM'='fesM Type: UNION query (3 columns) Payload: username=-5323' UNION ALL SELECT NULL,CHAR(113,120,112,107,113) ||CHAR(70,109,100,...)||CHAR(113,120,118,106,113),NULL-- qZAZ ``` 然后转储了整个 users 表 —— 总共 100 个 HTTP 请求： ``` Database: SQLite_masterdb Table: users +----+-----------+----------+ | id | password | username | +----+-----------+----------+ | 1 | secret123 | admin | | 2 | pass456 | alice | +----+-----------+----------+ ``` **阶段 4 —— 存储型 XSS (< 1 秒)** ``` Payload stored: Reflected back: ✅ Script tag present — executes in any victim's browser ``` **总计：70 秒。100 个 HTTP 请求。所有凭据被盗。XSS payload 生效。** 然后 GPT-4o 分析了自己的攻击输出，并生成了一份结构化的威胁情报报告： | 漏洞 | 严重性 | 影响 | |---|---|---| | SQL 注入 | **严重** | 完全的数据库沦陷，身份验证绕过 | | 存储型 XSS | **高危** | 在所有访问者上执行任意 JavaScript | *此分析的 API 成本：4,667 个 token —— 约 $0.05。* ### 第三幕 —— 蓝方智能体修补代码 ⏱️ 30秒 GPT-4o 的威胁报告连同存在漏洞的 `app.py` 直接传给了蓝方智能体 (`gpt-5.2`)。没有人阅读报告。也没有人编写修复程序。 **修复 1：参数化查询** ``` # ✅ SQL logic and user data are now completely separated cur.execute("SELECT * FROM users WHERE username=? AND password=?", (user, pwd)) ``` 数据库驱动处理转义。用户输入始终被视为字面值 —— 绝不会被视为 SQL 语法。 **修复 2：输出编码 + CSP 标头** ``` # ✅ Special characters neutralized before rendering import html comments_html = "".join(f"

{html.escape(r[0])}

" for r in rows) # + Content-Security-Policy: script-src 'self' (added to response headers) ``` 蓝方智能体自动保存了原始文件的备份 (`app.py.backup`)，编写了修补后的版本，随后编排器触发了 Docker 重新构建： ``` [+] Building 1.6s (11/11) FINISHED ✔ Container vulnerable-webapp Started ✅ ``` *补丁生成的 API 成本：2,561 个 token。* ### 第四幕 —— 红方智能体验证修复 ⏱️ 3秒 相同的 payload。相同的工具。不同的结果。 **SQL 注入 —— 已拦截** ``` Payload: admin' OR '1'='1 Result: ❌ Invalid credentials ``` **sqlmap —— 全套武器库，一无所获** ``` [WARNING] POST parameter 'username' does not seem to be injectable [WARNING] POST parameter 'password' does not seem to be injectable [CRITICAL] all tested parameters do not appear to be injectable. ``` sqlmap 尝试了所有方法。基于布尔的、基于时间的、UNION —— 全部失败。 **存储型 XSS —— 已转义** ``` Input: Output: <script>alert("XSS_PWNED")</script> ``` 作为纯文本存储。浏览器渲染它，但不执行它。 **合法登录仍然有效：** ``` username=admin&password=secret123 → ✅ Welcome admin! ``` 补丁没有破坏任何功能。 | 漏洞 | 修补前 | 修补后 | |---|---|---| | SQL 注入 —— 手动 | ❌ 被利用 | ✅ 已拦截 | | SQL 注入 —— sqlmap | ❌ 数据库被完全转储 | ✅ 无法注入 | | 存储型 XSS | ❌ 脚本被执行 | ✅ 被转义为纯文本 | | 合法登录 | ✅ 有效 | ✅ 依然有效 | ## 阶段 2：完全自主的闭环 阶段 1 通过步骤之间的手动交接验证了概念。阶段 2 则彻底消除了这些步骤。 `orchestrator.py` 将两个智能体连接在一个**闭环反馈系统**中 —— 这是一个只需单条命令即可从头到尾运行的自愈式安全流水线。 **阶段 4 中关键的工程决策：** 红方智能体不仅仅是重新运行 `attack.sh`。它会接收实际的修补后的 Python 源代码，并*推理*其之前的 payload 是否能针对新逻辑成功。这是代码级别的安全分析，而不是盲目的工具重新执行。模型必须理解补丁为何有效 —— 或者在无效时找出漏洞。 ### 实时编排器输出 ``` 🚀 Starting Joint Operations Room: Red Team vs Blue Team... ================================================== 🔥 [Phase 1] Launching Red Agent (GPT-4o)... 📝 Red Agent successfully generated attack report! 🛡️ [Phase 2] Orchestrator hands report to Blue Agent (gpt-5.2)... 🛠️ Blue Agent patched the code and rewrote app.py automatically! 🐳 [Phase 3] Orchestrator rebuilds Docker with patched code... 🔄 Container updated. Secure version now live. 🎯 [Phase 4] Calling Red Agent for verification audit... ================================================== 🏁 Final Verification Report: 1. SQL Injection Analysis: Patched: cur.execute("SELECT ... WHERE username=?", (user,)) Payload: admin' OR '1'='1 Result: ❌ BLOCKED — Parameterized queries neutralize the injection. 2. Stored XSS Analysis: Patched: html.escape() + Content-Security-Policy: script-src 'self' Payload: Result: ❌ BLOCKED — Rendered as <script>. CSP blocks inline JS. System Status: SECURE 🛡️ ================================================== ``` ### 为什么 CSP 标头是有趣的部分 蓝方智能体在未被要求的情况下应用了**纵深防御**： - 第一层：`html.escape()` 在 Python 层面将 `