Armor Finance Withdrawal Bug
Notice: This page is a freshly imported case study from the original repository. The original content was in a different format, and may not have relevant information for all sections. Please help restructure the content by moving information from the 'About' and 'General Prevention' sections to other sections, and add any missing information or sources you can find. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.
Notice: This page contains sources which are not attributed to any text. The unattributed sources follow the initial description. Please assist by visiting each source, reviewing the content, and placing that reference next to any text it can be used to support. Feel free to add any information that you come across which isn't present already. Sources which don't contain any relevant information can be removed. Broken links can be replaced with versions from the Internet Archive. See General Tutorial on Wikis, Anatomy of a Case Study, and/or Citing Your Sources Guide for additional information. Thanks for your help!
Armor Finance launched a smart contract which allowed participants to withdraw significantly more funds than they deposited.
This error was caught a white hacker who was generously compensated.
This is a global/international case not involving a specific country.[1][2][3][4]
About Armor Finance
"Armor is a decentralized brokerage for cover underwritten by Nexus Mutual's blockchain-based insurance alternative." "ArmorFi provides insurance for DeFi protocols. When withdrawing the amount agreed by the coverage policy, the amount returned is in wei but was treated as ether by mistake, converting it to wei again and returning 10^18 times more wei than it should."
"Alexander Schlindwein @bobface16, CTO of Idea Markets, found a critical bug before it went fully live!" "On January 30, Alexander Schlindwein, CTO of Ideamarkets, submitted a critical bug to Immunefi for ArmorFi’s smart contract code. Armor, which had joined the Immunefi platform about a week prior, had just upgraded the size of its bug bounty to 1,000,000 mostly vested $ARMOR tokens, and the upgrade was too tempting to ignore." "[T]he bounty went from about $23,000 USD to $700,000 USD, and within about a day, a critical vuln landed in our inbox."
"The way this vulnerability works is relatively simple: some user with coverage makes a claim against a coverage pool in Armor, presumably after suffering some sort of event covered by the policy. However, rather than withdrawing the amount of the policy, the exploit allows them to get 10^18 as much as they purchased. A single dollar worth of coverage could have enabled a malicious attacker to withdraw far more assets than available. In ClaimManager.sol, line 62 uint256 payment = _amount * 10 ** 18; should not have been present in the contract."
"We just got off the phone with @ArmorFi, and they're raising their critical bug bounty to $600,000, which means that it's **the largest smart** contract bounty."
"The bug (which would have affected successful claim payouts) was immediately fixed and did not affect any staked assets." "It is important to be generous with bug bounties and to appreciate whitehats who help you keep users safe. Safety must come before every other goal."
"This successful disclosure is an excellent proof of concept of how bug bounties can function in the smart contract space. Moreover, it achieved three important objectives. First, it solved a critical vulnerability that stood a good chance of being exploited on some timeline. Second, Armor has the opportunity to review its code and security processes more closely. And third, the community reacted overwhelmingly positive to Armor taking security seriously with its bug bounty program and successful payout. As of publication, the current value of the bounty is $876,000 USD."
"The system is working as intended and will continue to do so."
This is a global/international case not involving a specific country.
The background of the exchange platform, service, or individuals involved, as it would have been seen or understood at the time of the events.
Include:
- Known history of when and how the service was started.
- What problems does the company or service claim to solve?
- What marketing materials were used by the firm or business?
- Audits performed, and excerpts that may have been included.
- Business registration documents shown (fake or legitimate).
- How were people recruited to participate?
- Public warnings and announcements prior to the event.
Don't Include:
- Any wording which directly states or implies that the business is/was illegitimate, or that a vulnerability existed.
- Anything that wasn't reasonably knowable at the time of the event.
There could be more than one section here. If the same platform is involved with multiple incidents, then it can be linked to a main article page.
The Reality
This sections is included if a case involved deception or information that was unknown at the time. Examples include:
- When the service was actually started (if different than the "official story").
- Who actually ran a service and their own personal history.
- How the service was structured behind the scenes. (For example, there was no "trading bot".)
- Details of what audits reported and how vulnerabilities were missed during auditing.
What Happened
The specific events of the loss and how it came about. What actually happened to cause the loss and some of the events leading up to it.
| Date | Event | Description |
|---|---|---|
| January 30th, 2021 | Main Event | Expand this into a brief description of what happened and the impact. If multiple lines are necessary, add them here. |
Technical Details
This section includes specific detailed technical analysis of any security breaches which happened. What specific software vulnerabilities contributed to the problem and how were they exploited?
Total Amount Lost
No funds were lost.
How much was lost and how was it calculated? If there are conflicting reports, which are accurate and where does the discrepancy lie?
Immediate Reactions
How did the various parties involved (firm, platform, management, and/or affected individual(s)) deal with the events? Were services shut down? Were announcements made? Were groups formed?
Ultimate Outcome
What was the end result? Was any investigation done? Were any individuals prosecuted? Was there a lawsuit? Was any tracing done?
Total Amount Recovered
There do not appear to have been any funds recovered in this case.
What funds were recovered? What funds were reimbursed for those affected users?
Ongoing Developments
What parts of this case are still remaining to be concluded?
General Prevention Policies
No user funds were lost.
Individual Prevention Policies
No specific policies for individual prevention have yet been identified in this case.
For the full list of how to protect your funds as an individual, check our Prevention Policies for Individuals guide.
Platform Prevention Policies
Policies for platforms to take to prevent this situation have not yet been selected in this case.
For the full list of how to protect your funds as a financial service, check our Prevention Policies for Platforms guide.
Regulatory Prevention Policies
No specific regulatory policies have yet been identified in this case.
For the full list of regulatory policies that can prevent loss, check our Prevention Policies for Regulators guide.
References
- ↑ List of Ethereum Smart Contracts Post-Mortems - Security - OpenZeppelin Community (Jun 23, 2021)
- ↑ @ArmorFi Twitter (Jun 22, 2021)
- ↑ Armorfi Bug Bounty Postmortem (Jun 22, 2021)
- ↑ Armor.Fi (Jul 29, 2021)