如何分析报告并成为出色的审计师

以下内容由 bogo 友情提供，作为安全研究员内容贡献者计划的一部分。

提高你的审计技能并进阶到下一个层次的最佳方式之一是通过对你亲自执行的审计的反馈来实现。具体来说，我指的是审计结束后编写的报告，无论是私有的还是竞赛中的。

审查你错过的发现提供了一个宝贵的机会，通过学习他人的方法和识别你的薄弱环节来提升你的审计员思维。

然而，分析报告需要自己的一套技巧，就像审计一样。要获得真正的价值，正确地进行分析至关重要。

把报告想象成装满宝藏的金库。如果你了解打开它们的机制，你就能享受到里面的东西。

本文旨在帮助你破解这个机制。我将分解该过程，提供每一步的示例和深入解释。到最后，你将拥有有效分析的工具。

发现 1

链接

https://github.com/code-423n4/2023-10-wildcat-findings/issues/491

发现者

https://x.com/milotruck

背景

这个发现来自我参加的一个比赛，关注的是一个借贷协议。该协议使用工厂合约来部署市场。这些市场是智能合约，它们促进借贷过程，每个市场提供独特的条件，例如费用、清算阈值、代币类型等。

漏洞

这是MiloTruck提交的一个相当聪明的发现，最终被认为是独特的。工厂合约使用Create2来部署每个市场合约，并不允许同一市场被部署两次。问题出在工厂用来防止再次部署同一合约的检查上。

它使用 .codehash 来检查地址处是否存在代码。根据协议逻辑，如果某些代码已在地址上部署，codehash 应返回 该代码的哈希；否则，它将为0，表示没有代码被部署。问题在于 address.codehash 在判断地址上是否存在代码时并不可靠。如果任何 ETH（1 wei） 被发送到一个没有代码的地址，它开始返回 keccak256(“”) 而不是 bytes32(0)。这使得攻击者可以在市场部署之前向该地址发送ETH，从而对部署造成拒绝服务（DoS）攻击。

分析

我有意省略了太多细节，这样我们就可以动脑筋，搞清楚这位审计员是如何发现这个漏洞的。这是一种更好的学习方式，相信我！

提出正确的问题至关重要并将引导我们。所以，让我们开始问问题吧。

什么是 address.codehash?

经过一番谷歌搜索，这么说来

因此，根据定义，codehash 返回特定地址上代码的哈希——如果存在代码的话。它还表明可以用来判断地址是否对应于智能合约。然而，从上面描述的漏洞来看，我们已经知道这并不完全正确，这导致我们的第一个结论：不要盲目相信声明；始终进行验证。

让我们继续下一个问题。

审计员做了什么来获取关于address.codehash的额外信息？

显然，他认真读完了整个EIP，最终你会发现：

结论二——彻底阅读规范，细节决定成败。

最后一个问题

审计员是如何利用这些信息的？

他应用 codehash 于上述检查并开始测试各种场景。经过几次迭代，他意识到向一个空地址发送以太币会欺骗协议，从而让协议认为代码已部署。

结论

• 不要相信文件中的声明——验证它们是否成立
• 彻底研究，不要止步于表面理解

发现 2

链接 https://github.com/hats-finance/Paladin-0x1610bfde27e57b068af7f38aec3d2a7b1d146989/issues/5

发现者

https://x.com/p_tsanev

背景

这是来自Hats Finance平台的Paladin比赛。Paladin是一个治理协议，其中包括一个名为 Loot 的合约。Loot 管理用户从投票、分配和其他激励活动中获得的奖励。需要注意的是，奖励在特定期限内归属，如果提前认领，将会根据剩余归属期扣减惩罚。

漏洞

正如前面提到的，提前提取奖励会导致用户获得更少的奖励，因为一部分会被削减。此外，还有一个由 owner 可调用的函数 updateVestingDuration。

漏洞发生在 updateVestingDuration 交易在用户补全奖励（在期限已过后）提取交易之前执行时。这种情况下，如果 updateVestingDuration 延长 了到一个更晚的时间戳，用户的奖励会被削减。

分析

鉴于该漏洞的性质，需要超越协议的直接层面，考虑区块链的基本原则，让我们提出一个问题：

合约的归属期限的变化如何会影响用户提前提取奖励时所遭受的惩罚，特别是在归属期限的更新发生在用户提取交易之前的情况下？

的确，审计员很可能不是通过盯着合约来发现这个漏洞的。他可能花了时间来理解合约流，然后后退一步寻找潜在的薄弱点。`duration` 变量显得格外突出，促使他思考如果在进行的提取交易之前变更会发生什么。这项调查很可能引导他审查像 updateVestingDuration 这样的函数，以查看是否可能发生这样的变化，最终连接点发现了这个漏洞。

值得注意的是，在这个背景下，owner被视为可信的角色，排除此类恶意行为，如由可信角色的抢跑交易，这通常被视为无效的（在竞赛中）。这引导我们到第二个问题。

审计员是如何论证一个初看似无效的发现的？

这是这个发现的另一个重要部分。审计员强调，这个问题并不是由于owner的恶意抢跑交易造成的。

问题在于内存池中的交易并不保证按特定顺序执行，因此漏洞自然发生，超出了所有者的控制。这突显了一个关键的启示：使用正确的论据和推理可以成就或毁灭一个发现。

结论

• 花时间建立一个坚实的防线，以保护你的发现不至于崩溃。

发现 3

链接

https://github.com/code-423n4/2024-03-ondo-finance-findings/issues/278

发现者

https://x.com/0xBreeje

背景

这个比赛相对较小，包括约 800 行代码。它是Ondo协议的升级，该协议涉及机构级金融产品。该协议作为web3世界与机构金融市场之间的桥梁，包括美国国债和债券。本次比赛的重点是该协议引入的一个新合约 OUSGInstantManager。该合约允许已列入白名单的用户存入 USDC 并获得协议原生代币 OUSG 的铸造。OUSG 的价格由 oracle 决定。

漏洞

这个漏洞的有趣之处在于，它并不立即明显；需要一些抽象的或超出常规思维的思考来揭示。如前所述，当用户存入 USDC 时，oracle 会获取 OUSG/USDC 的价格并铸造相应数量的 OUSG 代币。

OUSG 铸造计算的解释：

• 从oracle获取的价格是铸造单个OUSG代币所需的USDC金额
• 我们用用户存入的USDC除以价格，就得到了要铸造的OUSG代币

即使来自oracle的 OUSG 价格得到了正确的验证，但 USDC 本身的价格却没有。协议简单地假设1 USDC 始终等于1 USD，这并不准确。在 USDC去锚（depeg） 事件期间（例如，当其跌至1美元以下时），存款人仍会获得相同数量的 OUSG 代币，实际上是在以折扣价格购买它们。

分析

这个问题有点棘手，因为它并不是一个典型的逻辑错误，你不能仅通过查看代码来推断出来。这更像是一个概念性漏洞，要求更广泛的知识和抽象、超出常规的思维来揭示。因此，分析这个问题很有必要。

让我们提出一个问题以深入探讨。

代码中是否存在会导致此漏洞的逻辑错误？

如果你查看合约，似乎没有什么问题。oracle之前已经经过审计，所有最佳实践都得到应用——包括时效性检查、可接受价格范围和价格偏差的实现，以确保 OUSG 价格的有效性。即便我们把代码运行一千次，也不会发现任何问题。因此，显然，这里不是问题的所在。

那么，是什么让审计员发现了这个漏洞？

我可以对此进行大量猜测，但我最好的猜测是经验或良好的习惯，关注区块链领域的重要事件并保持更新。你可能以两种方式了解到像 USDC 这样的稳定币可能会与 USD 的1:1比率脱钩：

• 要么你之前读过相关资料
• 要么你有过类似的经历，促使你去研究 USDC 过去是否有过 去锚（depeg） 事件。

结论

• 阅读web3资源并保持更新可以拓宽你的思维，给予你更 抽象的视角
• 与第一个发现相同——从不盲目相信假设，进行验证

发现 4

链接

https://github.com/code-423n4/2024-04-renzo-findings/issues/612

发现者

LessDupes 团队

背景

这个问题来自 Renzo 协议的比赛。了解该协议的复杂细节并不重要。重要的是要知道，用户存入资产并获得铸造的 Renzo 代币。他们可以通过返回这些 Renzo 代币来检索他们的资产。 ETH 是可以存入的资产之一。

漏洞

这个漏洞本身是基本和琐碎的——低级转账只用2300油费。然而，值得注意的是 审计员是如何将其严重性提升 从 QA 到 HIGH 只有1个重复 的。

*澄清一下——EVM 最初引入低级转账只用2300油费是为了防止重入攻击。随着时间的推移，由于油费上涨，这个数额变得不足，导致即使是简单的ETH转账也存在潜在的拒绝服务（DoS）攻击的风险。

这个漏洞是 如此常见，以至于通常会在每次比赛开始时被机器人标记。在 95%的情况下，评审会将这样的提交标记为超出范围（OOS），因为它们已经被机器人报告过。

分析

让我们分析一下，如何一个通常被标记为超出范围（OOS）的漏洞被提升到一个几乎 独特的HIGH 严重性，在这个 有25万大奖池 的比赛中 🤑。首先，提出问题：

审计员关注了哪些具体因素或方面，使得通常OOS的漏洞在此次比赛中严重性得到提升到HIGH？

他提交的以下论点是答案的关键：

你明白了吗？

让我来澄清一下。静态分析器本身并不是智能的；它们只是标记在代码库中检测到的模式。特别是在低级转账的情况下，它们报告合约中发现的实例，而不深入具体的上下文或使用细节，导致大多数情况下显得严重性较低。

然而，这个场景中的审计员分析了转账使用的具体情况。通过运用这种详细理解，他构建了一个令人信服的论点，揭示了潜在的危险：

让我们理清思路：

• 由于发送的低油费，像Gnosis这样的安全合约无法处理资金的接收。
• claim() 函数要求调用者与通过withdraw() 启动的原始提取请求的地址相同。
• 因此，由于 仅 可用于发起 withdrawal 的Gnosis安全合约可以 claim 这些资金（而它不能）。

现在，告诉我，这不仅仅是 QA 问题就可以了，不是吗？

结论

一个漏洞本身可能毫无价值，但如果你注入了稳固的论点和适当的上下文，它可以 大放异彩。这里的启示是为你的提交提供适当的上下文。如你所见，这可能使得 $0.04 和 $1,000 的差别。

这就是结束！希望你今天学到了一些东西！

在社交媒体上关注 Bogo： Twitter: https://x.com/xb0g0

Github: https://github.com/BogoCvetkov/portfolio

• 原文链接： hatsfinance.medium.com/g...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～