条件竞争（Race condition）漏洞挖掘技巧及实战案例全汇总

1、漏洞理解

条件竞争漏洞（Race condition）官方概念是“发生在多个线程同时访问同一个共享代码、变量、文件等没有进行锁操作或者同步操作的场景中。” 这个漏洞存在于操作系统、数据库、web等多个层面，像有名的脏牛（dirty cow）。

对于这个漏洞的理解，关键词是”多线程”和“同时”和“同一个”，通常的web处理方式是通过单线程线性完成的，如果出现多线程并发请求的情况，数据处理逻辑就可能出现异常。这个漏洞的思想和参数污染漏洞（HPP）比较像（传送门），都是通过附加的情况使得程序异常，但原理不同。

2、漏洞原理

对于条件竞争漏洞比较经典的案例是转账、购买，也是条件竞争漏洞的高发场景。这里从数据库层面还原一个星巴克无限购买案例。直观解释下这个漏洞的原理，假设我们使用账户里的1000元购买10件100元的商品，正常购买流程为：

购买物品——>查询余额是否大于商品价格——>购买成功，余额-1000，商品数+1/购买失败，提示余额不足：

1） 查看数据库账户余额及物品数：

2） 点击购买，拦截数据包，设置intruder发送50个数据包，线程调到25后发进行并发请求：

3） 查看数据库的日志，可以看到对count的查看SELECT和更新UPDATE并不是线性依次执行的，所以导致在完成对count-1000的操作之前进行了另一次查询count仍为1000，最终结果是购买数量大于10，而余额为负数：

4） 解决方案通常是加“锁”，mysql执行事务前加BEGIN，后加COMMIT，从而锁定一次事务处理，使按序进行：

3、挖掘技巧：

1）方法：

必须使用的模块是Inturder，将线程调到25进行多线程异步发包，也可以使用curl同时发包。通过查看多个异步请求返回的不同结果，比如11个测试中有10个相同，那一个包可能就是攻击成功的请求。

2）漏洞场景：

挖掘需要关注的功能点有：

1. 购买：付款/购买/积分/订单操纵相关的漏洞
2. 兑换：积分/优惠券/注册邀请码（案例1）
3. 绕过次数限制（案例2）
4. 多过程处理，如文件上传处理（案例4）
5. 此外还可能存在DOS攻击（案例3）

特点总结来说就是——共享同一资源，生成其他结果。

3）注意：

这个漏洞具有偶现性，很受环境因素的影响，比如网络延迟、服务器的处理能力等，所以只执行一次可能并不会成功，尽量多尝试几次。

4、实战案例：

1）积分兑换

Hackerone上一个flag兑换邀请码的案例，使用同一Flag请求70次并获得了2次邀请：

另一个Slack的类似案例：

2）绕过数量限制

Shopify商店具有添加地址的功能，但拥有的地点数量最多是4个，可以通过多线程发包绕过软限制：

看到成功成功创建了8个地址：

同样的案例也有：绕过员工帐户数量限制、单次投票机会等，有数量上限的场景都可以尝试多线程绕过。

3）DOS攻击

一个在建议提交处无频率限制从而导致DOS的案例：

4）文件上传漏洞

文件上传也是条件竞争的一个经典案例，在之前文件上传的汇总中也有提及：传送门。

漏洞产生的原因来自文件上传的逻辑机制，多过程的处理机制都可能存在这个问题，补充一个gitlab的案例：

Gitlab允许文件import.tar.gz上传，它会将临时文件复制到

/var/opt/gitlab//tmp/project_exports/uploads/import.tar.gz。同时它会执行一个异步操作，负责解压缩导入文件并恢复其内容。

但是，由于在复制文件和处理作业之间存在延迟，其他人可以上传具有相同文件名的文件。如果在导入作业处理之前发生这种情况，受害者将在不知不觉中覆盖攻击者的导入文件。当攻击者的文件被执行时，它将解压缩受害者的导入文件并恢复攻击者存储库中的文件。漏洞攻击不易触发，思路也不易想到。

5、漏洞防御

1）对于业务端条件竞争的防范，一般的方法是设置锁；

2）对于文件上传，一定要经过充分完整的检查之后再上传；

3）在操作系统的角度，共享数据要进行上锁保护。