audit-system 2.0.0

package/obsidian-vault/exploits/ronin-2022.md

@@ -0,0 +1,251 @@
+# Ronin Bridge Exploit (2022)
+
+**Date:** March 23, 2022  
+**Loss:** $625 million (173,600 ETH + 25.5M USDC)  
+**Type:** Validator Compromise / Multi-sig Attack  
+**Severity:** CRITICAL
+
+---
+
+## Summary
+
+The Ronin Bridge was a cross-chain bridge connecting Ethereum to the Ronin sidechain (built for Axie Infinity). The attacker gained control of 5 out of 9 validator keys, allowing them to approve fraudulent withdrawals.
+
+---
+
+## Technical Details
+
+### Vulnerability Root Cause
+
+The Ronin bridge used a **5-of-9 multi-signature scheme** for validating withdrawals. The attacker compromised:
+
+1. **4 validator keys** from Sky Mavis (Ronin operator)
+2. **1 validator key** from Axie DAO (governance validator)
+
+With 5 of 9 keys, the attacker could create valid withdrawal proofs.
+
+### Attack Vector
+
+```solidity
+// Simplified Ronin Bridge Logic
+contract RoninBridge {
+    mapping(bytes32 => bool) public processedWithdrawals;
+    address[] public validators; // 9 validators
+    uint256 public constant VALIDATOR_THRESHOLD = 5;
+
+    function withdraw(
+        address recipient,
+        uint256 amount,
+        bytes memory signatures
+    ) external {
+        bytes32 withdrawalHash = keccak256(
+            abi.encode(recipient, amount, nonce)
+        );
+
+        require(!processedWithdrawals[withdrawalHash], "Already processed");
+
+        // Verify 5 of 9 validator signatures
+        require(
+            verifySignatures(withdrawalHash, signatures, validators),
+            "Invalid signatures"
+        );
+
+        processedWithdrawals[withdrawalHash] = true;
+
+        // Transfer tokens to attacker
+        IERC20(token).transfer(recipient, amount);
+    }
+}
+```
+
+### Attack Sequence
+
+```
+1. Attacker gains control of 5 validator private keys
+   - 4 keys from Sky Mavis (compromised via social engineering/malware)
+   - 1 key from Axie DAO validator
+
+2. Attacker creates fraudulent withdrawal request:
+   - Recipient: attacker address
+   - Amount: 173,600 ETH + 25.5M USDC
+
+3. Attacker signs withdrawal with 5 compromised keys
+
+4. Bridge verifies signatures (5 of 9 = valid)
+
+5. Tokens transferred to attacker
+
+6. Attacker launders funds through Tornado Cash
+```
+
+---
+
+## Why Standard Audits Missed This
+
+| Audit Focus | What Was Missed |
+|-------------|-----------------|
+| Smart contract code | Off-chain key management |
+| Signature verification | Validator selection/security |
+| Reentrancy, overflow | Centralization of validator keys |
+| Economic incentives | Single entity controlled 4/9 keys |
+
+---
+
+## Key Lessons
+
+### 1. Validator Centralization Risk
+```
+PROBLEM: 4 of 9 validators controlled by single entity (Sky Mavis)
+SOLUTION: Distribute validators across independent entities/jurisdictions
+```
+
+### 2. Threshold Selection
+```
+PROBLEM: 5/9 = 55.5% threshold too low for high-value bridge
+SOLUTION: Higher thresholds (e.g., 7/9 = 77.8%) for large withdrawals
+```
+
+### 3. Withdrawal Rate Limits
+```
+PROBLEM: No daily/monthly withdrawal caps
+SOLUTION: Implement time-based limits with emergency escalation
+```
+
+### 4. Multi-Sig Upgrade Mechanism
+```
+PROBLEM: Validator set could not be changed quickly
+SOLUTION: Emergency multi-sig to rotate compromised validators
+```
+
+---
+
+## Exploit Code (Simplified PoC)
+
+```solidity
+// Foundry PoC for Ronin-style attack
+contract RoninExploitTest is Test {
+    RoninBridge bridge;
+    address[9] validators;
+    address attacker = makeAddr("attacker");
+
+    function test_validatorCompromiseAttack() public {
+        // Setup: Deploy bridge with 9 validators, 5 threshold
+        bridge = new RoninBridge(validators, 5);
+
+        // Fund bridge
+        deal(address(bridge), 200_000 ether);
+
+        // Attacker controls 5 validators
+        address[5] memory compromisedValidators = [
+            validators[0], validators[1], validators[2],
+            validators[3], validators[4]
+        ];
+
+        // Create withdrawal hash
+        bytes32 withdrawalHash = keccak256(
+            abi.encode(attacker, 173_600 ether, block.number)
+        );
+
+        // Sign with 5 compromised keys
+        bytes memory signatures = createSignatures(
+            withdrawalHash,
+            compromisedValidators
+        );
+
+        // Execute fraudulent withdrawal
+        uint256 balanceBefore = attacker.balance;
+        bridge.withdraw(attacker, 173_600 ether, signatures);
+        uint256 balanceAfter = attacker.balance;
+
+        // Verify attack succeeded
+        assertEq(balanceAfter - balanceBefore, 173_600 ether);
+        console.log("Attack successful: drained 173,600 ETH");
+    }
+
+    function createSignatures(
+        bytes32 hash,
+        address[5] memory signers
+    ) internal pure returns (bytes memory) {
+        // Simplified signature aggregation
+        // In reality, would use ECDSA signatures
+        return abi.encodePacked(hash, signers);
+    }
+}
+```
+
+---
+
+## Detection Checklist for Auditors
+
+When auditing bridges, verify:
+
+- [ ] Validator set is sufficiently decentralized
+- [ ] No single entity controls threshold number of validators
+- [ ] Withdrawal rate limits exist (daily/monthly caps)
+- [ ] Emergency pause mechanism with multi-sig
+- [ ] Validator rotation mechanism exists
+- [ ] Slashing conditions for malicious validators
+- [ ] Time delays for large withdrawals
+- [ ] Multi-chain confirmation requirements
+
+---
+
+## Invariants That Should Have Been Tested
+
+```solidity
+// INVARIANT: No single entity should control threshold validators
+function invariant_validatorDecentralization() public view {
+    mapping(address => uint256) entityValidators;
+
+    for (uint i = 0; i < validators.length; i++) {
+        address entity = getValidatorEntity(validators[i]);
+        entityValidators[entity]++;
+    }
+
+    for (address entity : allEntities) {
+        assert(
+            entityValidators[entity] < THRESHOLD,
+            "Single entity controls threshold"
+        );
+    }
+}
+
+// INVARIANT: Daily withdrawals should not exceed limit
+function invariant_dailyWithdrawalLimit() public {
+    uint256 dailyTotal = getWithdrawalsToday();
+    assert(dailyTotal <= MAX_DAILY_WITHDRAWAL);
+}
+
+// INVARIANT: Large withdrawals require additional confirmation
+function invariant_largeWithdrawalDelay() public {
+    if (withdrawalAmount > LARGE_WITHDRAWAL_THRESHOLD) {
+        assert(block.timestamp >= withdrawalRequestTime + DELAY);
+    }
+}
+```
+
+---
+
+## Aftermath
+
+| Action | Result |
+|--------|--------|
+| Bridge paused | March 23, 2022 |
+| FBI investigation | Attributed to Lazarus Group (North Korea) |
+| $30M recovered | From USDC freeze |
+| $625M+ lost | Remainder in Tornado Cash |
+| Sky Mavis raise | Raised $150M to rebuild |
+
+---
+
+## Related Exploits
+- [[wormhole-2022]] - Similar signature verification bypass
+- [[nomad-2022]] - Replay attack on merkle proofs
+- [[harmony-2022]] - Multi-sig compromise
+
+---
+
+## References
+- [Ronin Bridge Post-Mortem](https://roninblockchain.substack.com/p/ronin-network-validator-compromise)
+- [Chainalysis Report](https://blog.chainalysis.com/reports/north-korea-lazarus-group-cryptocurrency-thefts-2022-update/)
+- [FBI Press Release](https://www.justice.gov/opa/pr/north-korean-lazarus-group-members-charged-conspiring-launder-2021-cyberheist-proceeds)

package/obsidian-vault/exploits/wormhole-2022.md

@@ -0,0 +1,284 @@
+# Wormhole Bridge Exploit (2022)
+
+**Date:** February 2, 2022  
+**Loss:** $325 million (120,000 wETH)  
+**Type:** Signature Verification Bypass  
+**Severity:** CRITICAL
+
+---
+
+## Summary
+
+The Wormhole bridge (Solana ↔ Ethereum) was exploited due to a bug in the signature verification logic. The attacker was able to create valid withdrawal proofs without proper validator signatures.
+
+---
+
+## Technical Details
+
+### Vulnerability Root Cause
+
+The vulnerability was in the **signature verification function** on the Solana side. The code failed to properly verify that the validator signatures matched the withdrawal data.
+
+```rust
+// Simplified Wormhole Guardian Logic (VULNERABLE)
+fn verify_signatures(
+    message: &Message,
+    signatures: &[Signature],
+    guardians: &[Pubkey]
+) -> Result<()> {
+    // BUG: Function verified signatures were valid
+    // But did NOT verify signatures were for THIS message
+
+    for (sig, guardian) in signatures.iter().zip(guardians.iter()) {
+        // Checked: Is this a valid signature from this guardian?
+        // Missing: Is this signature for THIS specific message?
+        if !verify_ed25519(sig, guardian, message) {
+            return Err(InvalidSignature);
+        }
+    }
+
+    Ok(())
+}
+```
+
+### The Actual Bug
+
+In the real code, the issue was more subtle. The guardian set verification had a logic error where:
+
+1. The code checked if signatures were from valid guardians
+2. But did not properly bind the signatures to the specific withdrawal hash
+3. This allowed reuse of signatures or creation of fake proofs
+
+### Attack Sequence
+
+```
+1. Attacker identifies signature verification bug
+
+2. Creates fraudulent withdrawal instruction:
+   - Amount: 120,000 wETH
+   - Recipient: attacker-controlled address on Ethereum
+
+3. Bypasses signature verification:
+   - Either reuses old valid signatures
+   - Or creates signatures that verify without guardian keys
+
+4. Submits proof to Wormhole contract
+
+5. Contract verifies (buggy) signatures - PASSES
+
+6. 120,000 wETH minted and sent to attacker
+
+7. Attacker bridges to Ethereum and cashes out
+```
+
+---
+
+## Exploit Code Analysis
+
+### Vulnerable Pattern
+
+```rust
+// BEFORE FIX - Vulnerable
+fn post_vaa(
+    &mut self,
+    vaa: Vec<u8>,
+) -> Result<()> {
+    let parsed_vaa = parse_vaa(&vaa)?;
+
+    // BUG: Signature verification didn't properly bind to VAA body
+    verify_signatures(
+        &parsed_vaa.signatures,
+        &self.guardian_set
+    )?;
+
+    // Process withdrawal based on unverified VAA
+    self.process_withdrawal(&parsed_vaa.body)?;
+
+    Ok(())
+}
+
+// AFTER FIX - Correct
+fn post_vaa_fixed(
+    &mut self,
+    vaa: Vec<u8>,
+) -> Result<()> {
+    let parsed_vaa = parse_vaa(&vaa)?;
+
+    // FIX: Hash includes full VAA body
+    let message_hash = keccak256(&parsed_vaa.body);
+
+    // Signatures must match THIS specific hash
+    verify_signatures_bound_to_hash(
+        &parsed_vaa.signatures,
+        &self.guardian_set,
+        &message_hash  // <-- Added hash binding
+    )?;
+
+    self.process_withdrawal(&parsed_vaa.body)?;
+    Ok(())
+}
+```
+
+---
+
+## Foundry PoC Template
+
+```solidity
+// Simplified PoC for Wormhole-style signature bypass
+contract WormholeExploitTest is Test {
+    WormholeBridge bridge;
+    address[] guardians;
+
+    function test_signatureVerificationBypass() public {
+        // Setup: Bridge with guardian set
+        guardians = createGuardians(19);
+        bridge = new WormholeBridge(guardians, 13); // 13/19 threshold
+
+        // Fund bridge
+        deal(address(bridge.weth()), 200_000 ether);
+
+        // Create withdrawal message
+        Withdrawal memory withdrawal = Withdrawal({
+            recipient: address(this),
+            amount: 120_000 ether,
+            chainId: 1,
+            nonce: 1
+        });
+
+        // BUG: Create signatures that verify but aren't bound to message
+        bytes memory fakeSignatures = createUnboundSignatures();
+
+        // Submit fraudulent VAA (Verifiable Action Approval)
+        bytes memory vaa = abi.encode(withdrawal, fakeSignatures);
+
+        uint256 balanceBefore = address(this).balance;
+
+        // This should fail but doesn't due to bug
+        bridge.postVAA(vaa);
+
+        uint256 balanceAfter = address(this).balance;
+
+        // Verify exploit succeeded
+        assertEq(balanceAfter - balanceBefore, 120_000 ether);
+        console.log("Wormhole exploit successful: 120,000 ETH drained");
+    }
+
+    function createUnboundSignatures() internal pure returns (bytes memory) {
+        // Simulates creating signatures that verify
+        // but aren't properly bound to message hash
+        return new bytes(65 * 13); // 13 signatures
+    }
+}
+```
+
+---
+
+## Why This Was Missed
+
+| Audit Gap | Explanation |
+|-----------|-------------|
+| Assumed crypto correctness | Auditors assumed signature lib was correct |
+| Focus on business logic | Didn't deep-dive into crypto primitives |
+| Cross-chain complexity | Solana + Ethereum made review harder |
+| Time pressure | Rapid deployment for competitive reasons |
+
+---
+
+## Key Lessons for Auditors
+
+### 1. Never Assume Crypto Correctness
+```
+ALWAYS verify:
+- Signature binding to specific message hash
+- Nonce/replay protection
+- Chain ID inclusion
+- Domain separation
+```
+
+### 2. Cross-Chain State Consistency
+```
+VERIFY:
+- State on Chain A matches state on Chain B
+- Wrapped supply = locked supply
+- No double-spend vectors
+```
+
+### 3. Guardian/Validator Security
+```
+CHECK:
+- Guardian key management
+- Threshold selection rationale
+- Guardian rotation mechanism
+- Slashing for malicious guardians
+```
+
+---
+
+## Detection Checklist
+
+When auditing bridges with signature verification:
+
+- [ ] Signatures are bound to specific message hash
+- [ ] Message hash includes: amount, recipient, nonce, chainId
+- [ ] Replay protection implemented (nonce or unique ID)
+- [ ] Domain separation prevents cross-chain replay
+- [ ] Guardian set is immutable or has secure rotation
+- [ ] Threshold is appropriate for value at risk
+- [ ] Rate limits on large withdrawals
+- [ ] Emergency pause mechanism
+
+---
+
+## Invariants to Test
+
+```solidity
+// INVARIANT: Every withdrawal must have valid guardian signatures
+function invariant_withdrawalSignatures() public {
+    for (uint i = 0; i < withdrawalCount; i++) {
+        Withdrawal memory w = withdrawals[i];
+        assertTrue(
+            verifySignaturesBoundToMessage(w.signatures, w.hash),
+            "Signature not bound to message"
+        );
+    }
+}
+
+// INVARIANT: Total wrapped supply equals locked supply
+function invariant_wrappedSupply() public view {
+    assertEq(
+        wrappedToken.totalSupply(),
+        lockedToken.balanceOf(address(bridge))
+    );
+}
+
+// INVARIANT: No duplicate nonces
+function invariant_nonceUniqueness() public {
+    // Should revert if any nonce is reused
+}
+```
+
+---
+
+## Aftermath
+
+| Action | Result |
+|--------|--------|
+| Bridge paused | February 2, 2022 |
+| Jump Crypto bailout | Covered $325M loss |
+| Bridge reopened | February 23, 2022 |
+| Security audit | Multiple firms engaged |
+| Code open sourced | Full transparency |
+
+---
+
+## Related Exploits
+- [[ronin-2022]] - Validator compromise
+- [[nomad-2022]] - Replay attack
+- [[multichain-2023]] - Similar bridge exploit
+
+---
+
+## References
+- [Wormhole Post-Mortem](https://wormhole.com/post-mortem)
+- [Neodyme Analysis](https://neodyme.io/en/blog/wormhole)
+- [OtterSec Report](https://osec.io/blog/wormhole-exploit)

package/obsidian-vault/failed-hypotheses/_template.md

@@ -0,0 +1,77 @@
+# Failed Hypothesis Template
+
+tags: #failed-hypothesis #template #learning
+
+---
+
+## Hypothesis
+[One sentence describing the attempted attack]
+
+## Contract
+[Nome do Contrato] — [Address if deployed]
+
+---
+
+## What Was Tested
+[Description of the attack vector that was attempted]
+
+## Attack Steps Attempted
+```
+1. [Step taken]
+2. [Step taken]
+3. [Step taken]
+```
+
+---
+
+## Why It Failed
+
+### Technical Reason
+[The specific code, check, or condition that prevented the attack]
+
+### Code Reference
+```solidity
+// The line or function that blocked the attack
+```
+
+### Root Cause Category
+- [ ] Validation check present
+- [ ] Access control blocked
+- [ ] State transition invalid
+- [ ] Economic assumptions wrong
+- [ ] Timing constraints
+- [ ] Protocol design prevents it
+- [ ] Other: [specify]
+
+---
+
+## Lessons Learned
+
+### About This Contract
+[What this tells us about the contract's security]
+
+### Pattern Recognition
+[What to look for in future audits — "this pattern prevents X"]
+
+### Alternative Angles
+[Ways this could still be exploitable or related attack vectors to try]
+
+---
+
+## Related Hypotheses
+- [[hypotheses/]] — Successful hypothesis on same contract
+- [[attack-patterns/]] — Pattern this relates to
+
+---
+
+## Metadata
+- **Date:** [When tested]
+- **Auditor:** [Name]
+- **Time Invested:** [How long spent on this hypothesis]
+- **Confidence Before:** [High/Medium/Low]
+- **Confidence After:** [Confirmed refuted]
+
+---
+
+## Notes
+[Any additional observations, traces, or context]

package/obsidian-vault/hypotheses/_template.md

@@ -0,0 +1,43 @@
+# Hypothesis Template
+
+tags: #hypothesis #template
+
+---
+
+## Contract
+[Contract name and address if deployed]
+
+## Hypothesis
+[One sentence: IF [condition] THEN [consequence]]
+
+## Attack Pattern
+[Which pattern does this relate to? Link to attack-patterns/]
+
+## Preconditions
+- [ ] Condition 1
+- [ ] Condition 2
+
+## Attack Steps
+```
+1. 
+2. 
+3. 
+```
+
+## Expected Outcome
+[What happens if hypothesis is correct?]
+
+## Test Strategy
+[How to test this hypothesis in Foundry?]
+
+## Result
+- [ ] Confirmed — vulnerability exists
+- [ ] Refuted — not exploitable
+- [ ] Partial — exists but limited impact
+
+## Notes
+[Observations during testing]
+
+## Links
+- [[vulnerabilities/]]
+- [[attack-patterns/]]