Standing Order

The brief

A grant program pays out against approvals signed by its committee. Two redemption paths exist (one for small onboarding credits, one for the committee's own larger approvals) and both were wired against the same signature check.

• standing-order-player.zip, 5 KB

In short

A grant contract paid out ETH before marking a committee voucher as used, and the voucher's signature did not name a recipient. The lab built a contract that calls back when paid and redeemed one 1 ETH voucher 20 times, emptying the reserve.

One voucher, signed for anyone

The reserve holds 20 ETH. The player is handed one committee voucher for 1 ETH with nonce 0. Its signature covers only the amount and the nonce, not who gets paid or which path redeems it.

Pay first, mark later

The disburse path checks that the voucher is unused and signed, sends the ETH, and only then marks it used. A recipient that runs code gets control in between, while the voucher still counts as fresh.

A recipient that calls back

The lab assembled a small contract opcode by opcode. Whenever ETH arrives, it copies a ready disburse() call out of its own code, writes itself in as recipient and calls again with the same voucher.

Twenty payouts, one voucher

One transaction set it off. Each 1 ETH payment ran the contract again before the voucher was marked, twenty calls deep, and the receipt lists 20 Paid events.

Reserve at zero

The reserve fell from 20 ETH to 0, far under the 0.2 ETH win line, and isSolved() returned true. The checker then issued the flag.

The insight

The payout sends ETH before it marks the voucher used and the signature never names a recipient, so one 1 ETH voucher can be spent 20 times.

The flag

hiCTF{one_sig_two_paths_then_the_l00p_516eb76c8a}