Comment by @bitbeckers • Hey

@definn.lens here's the postmortem we promised 🙂

Stats

Comments

Nice, thank you for publishing this! A few things that are kind of bugging me still: 👉 1. In the Strategy/Relayed contract (0x097...), there is a `isRoundContract` modifier for the vote() method...how the hell did the attacker passed this? Since this modifier checks the msg.sender, and the sender is the hacker's contract (0x16...). I didn't see any malicious transaction coming from the Round contract (0xA2...). 👉 2. I understood that the "backdoor" was introduced with the "voter" parameter being included in the encoded array, so now you're comparing with "relayerAddress". But can you guarantee the hacker can't also set the relayerAddress? Because, as far as I could check, the 0x16 contract is "replacing" the Round contract, so could also modify this parameter. 👉 3. Where does the ProjectID is mapped to the recipient address? Because all this flow happens with the encoded data so I couldn't see it being used as the attack vector. 👉 4. This is more related to helping Lens ecosystem itself: do you think there is a design patter we can implement to isolate Lens protocol from these attack vectors? I think that, if we gave a Lens Module an allowance, this module must check "sender/spender" correlation, it doesn't matter from which app the solicitation came. Otherwise, an exponential growth of the ecosystem is almost unsustainable if each app has to run its own full-stack security checks. I'm far from being a contract auditor, and I'm sorry for so many questions, take the time you need! And thank you again for the open communication 💚.