The Chrysalis Attack-a-thon

[rafaeldjpbrochado]

Hi everyone!

It's no secret that we're all eager to see Chrysalis on the mainnet. After months of development, testing and auditing by external companies, the IOTA Foundation is feeling very confident about the upcoming Chrysalis transition.

However, that doesn't mean we can't have some fun, does it? Introducing:

The Attack-a-thon is a community event where we all try to break different parts of Chrysalis. It'll run for around 10 days: starting on the 18th of March 2021 at 2PM UTC and ending on the 28th of March 2021 at 11:59 PM UTC.

Relevant repositories

In the scope of this event are the following IOTA components:

• The IOTA Node Software:
  • HORNET (The develop branch)
  • Bee (The chrysalis-pt-2 branch)
• Libraries:
  • wallet.rs (The develop branch)
  • iota.rs (The dev branch)
  • Bindings in NodeJS and Python (The dev branch)
• Stronghold:
  • stronghold.rs (The dev branch)

Rules of engagement

The rules of engagement are pretty simple:

• The first to submit a valid entry during the defined time period gets the prize
• Every issue in the scope counts singularly (e.g. If an injection makes it possible to escalate privileges it counts as two issues)
• The evaluation committee might count the submission if it is a particular vulnerability outside of the proposed scope although very connected to Chrysalis

Categories

There can be a lot of different things that we might find during our exploration of possible attacks on the Chrysalis network. As such, four types of priorities were defined.

Priority 1

Likelihood: medium/high (an attack can be carried out with little or no advanced resources)
Severity: corrupts/stops the network entirely. Arbitrarily changes the balances of many users.

• Consensus split of the network (practical attack).
• Arbitrary account (steal tokens) takeover.
• Double-spending existing funds or use funds “out of thin air” or Treasury Output.
• Stopping networks confirmations altogether (Coordinator).
• Reverting a confirmed transaction.

Priority 2

Likelihood: medium/low (an attack can be carried out under special conditions, with moderate or high difficulty to create)
Severity: compromise the entire network with low likelihood or consistently affect specific actors in the network with moderate resources.

• Consensus split of the network (theoretical attack).
• Censoring of arbitrary accounts, preventing confirmations.
• Get the network to accept Messages that violate established "validation" rules: insufficient PoW, malformed messages, breach dust rules, etc.
• Eclipse-attack, arbitrarily controlling node’s peering.

Priority 3

Likelihood: medium/low, an attack can be carried out under special conditions, with moderate or high difficulty to create.
Severity: Attacks that affect a limited number of actors in the network.

• Causing nodes to crash or hang under “average” network load.
• Cause a node to drop connection to an arbitrary peer.
• Reducing overall confirmation rate consistently below 50% without holding more than 20% hash-rate.
• Manipulate single wallet user experience to trick unwanted actions: pay to incorrect address, show bogus confirmation states, expose secret material, hijack migration process.

Priority 4

Likelihood: medium/low
Severity: disrupting end-user usability of the network, availability disruptions, etc.

• Prevent new nodes from joining the network.
• Preventing wallets to load Tangle data.
• Crash individual nodes under hard-to-obtain specific conditions.

Exclusions

What will not be evaluated (although a submission of the issue is still very welcome):

• Graphical bugs (wrong shape of a box, text not aligned and similar things)
• Typos (unless they can be used for an attack)
• Bugs that involve manipulation of the underlying runtime environment without exploiting app-specific bugs (e.g. malware running on the OS, malicious administrator user on the same system, etc.)
• Getting the nodes out of sync with a lot of spam without crashing the coordinator

Rewards

Everyone that submits an issue deemed valid by the evaluation committee and is an IOTA Discord member receives perpetual bragging rights and the Tanglebreaker badge. Plus, a couple more goodies as a token of everyone's appreciation. 🙏

Terms and conditions

• Prizes cannot be paid out to participants currently residing in countries subject to international sanctions imposed by the UNSC, OFAC and the EU or personally named on a Specially Designated National and Blocked Persons Lists (SDN) published by the aforementioned bodies
• Excluded from participation are all employees and contractors of the IOTA Foundation as well as any person who has already been working professionally on any parts of the Chrysalis code

How to participate

As soon as you find an issue that falls under the categories described above, jump to the relative GitHub repository and submit an Attack-a-thon issue using the pre-defined issue template:

The issue has to be structured as follows to be taken in consideration by the evaluation committee.

Description: What component was used (e.g. iota.rs python binding) and how.

Impact: Describe the vulnerability and its potential impact.

Proof of Concept: Give a detailed description of the steps, tools and versions needed to reproduce the issue (proof of concept scripts or screenshots are helpful).

By submitting the issue, the submitter warrants the report and any attachments do not violate the intellectual property rights of any third party, and the submitter grants the IOTA Foundation a non-exclusive, royalty-free, world-wide, perpetual license to use, reproduce, create derivative works, and publish the report and any attachments.

The evaluation committee

Submitted issues will be verified by IOTA Foundation members for correctness. They will reply to each and every issue on GitHub to confirm the validity of said issues and define the category each of them falls under.

Starting on the 8th of April 2021, winning participants will be contacted by IOTA's Community Manager @antonionardella, with a comment on the submitted GitHub issue. The subsequent verification and information exchange process to get the rewards will require you to publish a public gist, with information shared by e-mail.

Questions?

Ask them below! 👇