Summary

A malicious seller (auditor) can manipulate buyer (protocol) in initiating an escrow with no arbiter while having no intent to actually provide any services.
This is done strictly to drain protocol of funds as the audit payment would remain permanently locked in the escrow.

Vulnerability Details

A buyer (protocol) and seller (auditor) must reach a mutual agreement before initiating an escrow contract.
Things they need to settle upon from a smart contract point of view

• price to be paid for the service

• the crypto currency used

• the intermediary arbiter and his corresponding fee

With this in mind, a malicious actor with the sole intent of damaging the buyer (protocol) by draining their funds, manipulates buyer into accepting their "service" without using an arbiter. Then subsequently abandons the project. By doing so the funds are forever lost in the escrow.

This is possible because audit payment is sent at escrow contract creation and only leave the escrow when the buyer allows it via confirmReceipt called after the audit service was provided

or when, in a dispute, the arbiter sends it as it decides, to buyer and/or seller

This second case requires an arbiter to exist otherwise it will not function.

Attack flow:

• alice (buyer) is a low budget protocol that need an audit and can't afford the high fees for truly "vetted" auditors

• bob (seller) is a rival protocol that wishes to eliminate alice to increase his market share and chance of surviving

• bob makes a fake account on the escrow platform and bids for alice's project with a bellow market price, good offer with the condition that "no arbiter to be used because we only trust you, the client"

• alice accepts as there is no better offer around and, again, she cannot afford the vetted/known auditors

• alice launches the escrow with the money and sets bob's address, as the escrow logic dictates

• bob erases his escrow platform account, stops all communication with alice and simply walks away

• alice has lost the money for the audit and is an impossibility to continue with her protocol

Lowballing has existed in the normal service-consumer market for years and is even evident in NFT ecosystems where prices are artificially brought down. This type of attack, malicious lowballing cannot be discarded as "user mistake" because this is an act of manipulation that will happen on the escrow platform regardless.

Also, currently creating an account on the platform requires only an EVM compatible wallet address. Socials are optional but can easily be faked (fake Twitter and LinkedIn accounts are a daily encounter and even github commits can be spoofed), as such, it is only a matter of time before this attack will be seen ITW.

Impact

• Complete loss of buyer funds

• Irreparable reputation damage to the escrow platform itself if even one such attack happens

Tools Used

Manual analysis

Recommendations

Do not allow the creation of escrows without an arbiter set. This is the simplest way to protect future victims.
A somewhat workaround would be to not allow, at least not through the platform itself (mitigating reputation damage), of the creating of escrow contracts where the seller address is not KYC.
There are experimental on-chain mechanism that can attest to a KYC without revealing information, as a future perspective.