오늘 저희는 @blockaid_와 긴밀히 협력하여 어젯밤 @humafinance v1 프로토콜을 표적으로 삼은 취약점 공격을 조사했습니다. Blockaid의 사건 분석 보고서는 매우 상세하므로(첫 번째 답변에 링크 있음) 여기서는 반복하지 않겠습니다.
아래는 이번 행사의 요약(TL;DR)과 시스템 아키텍처 및 운영과 관련하여 얻은 교훈입니다. 👇
요약
공격 사건: 공격자들은 스마트 계약의 취약점을 발견하고 폴리곤의 오래된 v1 풀 3개에서 약 10만 1천 달러 상당의 프로토콜 수수료와 풀 소유자 수수료를 탈취했습니다.
사용자 자금: 사용자 자금은 어떠한 영향도 받지 않았습니다.
리스크 격리: 문제는 Huma EVM v1 계약에 있습니다. 이는 PST 및 Solana의 모든 Huma 스마트 계약과는 완전히 무관합니다.
솔라나 계약: 솔라나의 프로그램은 완전히 새롭게 설계된 아키텍처를 사용하며, 이번 사건에서 문제가 되었던 로직은 포함하지 않습니다.
현재 상태: 모든 v1 유동성 풀이 중단되었습니다.
핵심 교훈: 표면적으로는 2023년 초에 출시된 버전 1의 스마트 계약 취약점처럼 보이지만, 이는 프로토콜 설계 및 운영상의 여러 문제점을 드러냅니다.
1. 복잡한 로직을 가진 함수 내에 중요한 상태 전환을 혼합하지 않도록 하십시오. v1 스마트 계약에서 가장 복잡한 부분은 만기 금액과 각종 수수료를 계산하는 `_updateDueInfo()`와 `_getDueInfo()` 함수입니다. 이러한 복잡한 함수 내에 차용자의 상태 전환을 포함시키는 것은 현명한 선택이 아닙니다. 저희는 이후 이러한 설계 방식에 불만을 느끼고 Huma v2 스마트 계약 설계에서는 이를 버리고 더 간단한 아키텍처를 채택했습니다.
2. 불필요한 기능을 제거하십시오. `requestCredit()` 함수는 향후 확장을 지원하기 위해 도입되었지만 실제 운영에서는 한 번도 사용되지 않았습니다. 중요하지 않은 기능은 필연적으로 테스트 및 보안 검토가 덜 이루어지므로 불필요한 공격 표면을 만듭니다. 출시 전에 해당 함수를 제거하는 것을 논의했지만 당시에는 큰 문제가 발생하지 않을 것으로 판단하여 유지했습니다. 필수적이지 않은 기능은 계약에 포함되어서는 안 됩니다.
3. 사용하지 않는 풀은 선제적으로 폐쇄해야 합니다. 더 이상 필요하지 않은 오래된 풀을 유지하는 것은 불필요한 리스크 초래합니다. 오늘날 개발자와 공격자 모두 AI를 적극적으로 활용하고 있으며, AI로 감사 않은 일부 오래된 계약에는 더 많은 취약점이 있을 수 있습니다. v1 유동성 풀 폐쇄 작업은 진행 중이지만 최우선 순위로 처리되지는 않았습니다. 이 문제에 대해 더욱 단호한 조치를 취해야 합니다.
이것은 뼈아픈 교훈입니다. 우리는 이 경험에서 배우고, 이처럼 값비싼 대가를 헛되이 치르지 않아야 합니다. 저희는 이번 경험을 통해 얻은 교훈과 초기 성찰을 공유하며, 특히 오래된 계약을 보유한 프로젝트를 비롯한 다른 생태계 구축자들이 해커 공격에 대한 방어력을 더욱 효과적으로 강화할 수 있도록 돕고자 합니다. DeFi는 하나로 뭉쳐 더욱 강해집니다! 🛡️
