Umee 프로토콜에 대한 스마트 계약 감사 보고서
원문 링크: https://medium.com/umeeblog/umees-smart-contract-audit-report-by-peckshield-a4d78c4b23d1
자세한 내용을 알고 싶으시다면 베리온에서 번역한 감사 보고서의 번역본을 참조해주세요: https://bit.ly/34l4fRK
1 | 소개
Umee 프로토콜의 설계 문서 및 관련 스마트 컨트랙트의 소스 코드를 검토할 수 있는 기회가 주어졌으므로 이 보고서를 통해 스마트 컨트랙트 구현의 잠재적 보안 문제를 평가하고 스마트 컨트랙트 코드와 설계 문서 사이의 가능한 의미론적 불일치를 확인하기 위한 체계적인 접근 방식을 설명하고 개선을 위한 추가 제안 또는 권장 사항을 제공합니다. 결과에서 볼 수 있듯이 보안 또는 성능과 관련된 몇 가지 문제가 있었기 때문에 주어진 버전의 스마트 컨트랙트를 더욱 개선할 수 있음을 보여줍니다. 이 문서는 감사 결과를 설명합니다.
1.1 Umee에 대해서
Umee는 네트워크 간의 교차 체인 상호 작용을 위한 분산형 인프라입니다. 사용자들을 연결하여 대출 및 차용 포지션을 만들고, 체인 간에 자본을 이동하고, 새로운 수익 기회를 발견하고, 원활하고 신용이 없는 방식으로 네트워크를 교차하는 DeFi 애플리케이션을 탐색할 수 있습니다. 감사를 받는 차용 프로토콜은 AaveV2를 기반으로 개발되었으며 사용자가 예금자 또는 차용인으로 참여할 수 있는 분산형 비보관 자금 시장 프로토콜 역할을 합니다. 예금자는 시장에 유동성을 제공하여 수동적 소득을 얻는 반면 차용자는 과잉 담보(영구적으로) 또는 과소 담보(원-블록(One-Block) 유동성) 방식으로 대출을 할 수 있습니다. 감사 프로토콜의 기본 정보는 다음과 같습니다:
다음은 검토된 파일의 Git 리포지토리와 이 감사에 사용된 커밋(Commit) 해시 값에 대하여 보여줍니다:
• https://github.com/umee-network/umee-v1-contracts.git (cf35c19)
• https://github.com/umee-network/umee-incentives.git (ff5208b)
감사에서 발견된 문제에 대한 모든 수정 사항이 확인된 후의 커밋 ID는 다음과 같습니다.
• https://github.com/umee-network/umee-v1-contracts.git (84c69cd)
• https://github.com/umee-network/umee-incentives.git (8d5b168)
1.2 PeckShield에 대해서
PeckShield Inc.[10]는 업계 최고의 서비스 및 제품(스마트 컨트랙트 감사 서비스 포함)을 제공하며 현재 블록체인 생태계의 보안, 개인 정보 보호 및 사용성을 향상시키는 것을 목표로 하는 선도적인 블록체인 보안 회사입니다. 텔레그램(https://t.me/peckshield), 트위터 (http://twitter.com/peckshield) 또는 이메일(contact@peckshield.com)로 연락할 수 있습니다.
1.3 방법론
평가를 표준화하기 위해 OWASP 위험 평가 방법론을 기반으로 다음 용어를 정의합니다[9]:
• 가능도는 특정 취약점이 발견되고 악용될 가능성을 나타냅니다;
• 영향도는 성공적인 공격으로 인한 기술적 손실 및 사업 피해를 측정합니다;
• 심각도는 위험의 전반적인 위험 상태를 나타냅니다.
가능도와 영향도는 H, M 및 L의 세 가지 등급으로 분류됩니다. 이는 높음(High), 중간(Medium) 및 낮음(Low)입니다. 심각도는 가능도와 영향도에 따라 결정됩니다. 이에 따라 표 1.2에 표시된 심각(Critical), 높음(High), 중간(Medium), 낮음(Low)의 4가지 범주로 분류될 수 있습니다.
위험을 평가하기 위해 당사는 항목 체크리스트를 살펴보고 각 항목에 심각도 범주 레이블을 지정합니다. 하나의 점검 항목에 대해 당사의 도구 또는 분석을 통해 문제를 식별하지 못하면 해당 점검 항목은 안전한 컨트랙트로 간주됩니다. 발견된 문제에 대해서는 당사의 비공개 테스트넷에 추가로 컨트랙트를 배포하고 결과를 확인하기 위해 테스트를 실행할 수 있습니다. 필요한 경우 악용 가능성을 입증하기 위해 PoC를 추가로 구축할 것입니다. 구체적인 점검 항목 목록은 표 1.3과 같습니다.
당사는 다음 절차에 따라 감사를 수행합니다:
• 기본 코딩 버그: 먼저 알려진 코딩 버그에 대해 독점적인 정적 코드 분석기로 주어진 스마트 컨트랙트를 정적으로 분석한 다음 발견한 모든 문제를 수동으로 확인(거부 또는 확인)합니다.
• 의미 일관성 검사: 구현된 스마트 컨트랙트의 논리를 수동으로 확인하고 백서의 설명과 비교합니다.
• 상급 디파이 정밀 조사: 당사는 비즈니스 로직을 추가로 검토하고, 시스템 운영을 검토하고, DeFi 관련 측면을 면밀히 조사하여 가능한 위험 및/또는 버그를 찾아냅니다.
• 추가 권장 사항: 검증된 프로그래밍 관행의 관점에서 스마트 컨트랙트의 코딩 및 개발에 관한 추가 제안을 제공합니다.
당사가 식별한 각 문제를 더 잘 묘사하기 위해 Common Weakness Enumeration(CWE-699) [8] 을 사용하여 결과를 분류합니다. 이는 커뮤니티에서 개발한 소프트웨어 약점 유형 목록이며 소프트웨어 개발에서 자주 접하는 개념에 대한 약점을 설명합니다. CWE-699에 사용된 일부 범주는 스마트 컨트랙트와 관련이 없을 수 있지만 당사는 표 1.4의 CWE 범주를 사용하여 결과를 분류합니다. 또한 배포된 활성 프로토콜에 영향을 줄 수 있는 문제가 있는 경우 이 보고서의 공개 버전은 이러한 문제를 생략할 수 있지만 영향을 받는 프로토콜이 각 수정 사항으로 업그레이드된 직후 전체 세부 정보로 수정될 것입니다.
1.4 면책 조항
이 보안 감사는 소프트웨어 배포 전에 필요한 기능 테스트를 대체하도록 설계되지 않았으며 주어진 스마트 컨트랙트 또는 블록체인 소프트웨어의 모든 가능한 보안 문제를 찾는다는 보증을 제공하지 않습니다. 평가 결과는 보안 문제에 대한 추가 발견 사항이 없음을 보장하지 않습니다. 하나의 감사 평가는 포괄적인 것으로 간주될 수 없으므로 스마트 컨트랙트의 보안을 보장하기 위해서는 여러 개의 독립 감사 및 공개 버그 포상 프로그램을 진행하는 것이 좋습니다. 마지막으로 이 보안 감사를 투자 조언으로 사용해서는 안 됩니다.
이 범주의 약점은 안전하지 않은 것으로 간주되는 코딩 관행과 관련되어 있으며 응용 프로그램에 악용 가능한 취약점이 존재할 가능성이 높습니다. 취약점을 직접 도입하지는 않지만 제품이 신중하게 개발되거나 유지 관리되지 않았음을 나타냅니다.
2 | 조사 결과
2.1 요약
다음은 Umee 프로토콜의 구현을 분석한 후 발견한 내용을 요약한 것입니다. 감사의 첫 번째 단계에서는 스마트 컨트랙트 소스 코드를 연구하고 코드베이스를 통해 정적 코드 분석기를 실행합니다. 여기의 목적은 알려진 코딩 버그를 정적으로 식별한 다음 당사 도구에서 보고된 문제를 수동으로 확인(거부 또는 확인)하는 것입니다. 당사는 추가로 비즈니스 로직을 수동으로 검토하고, 시스템 운영을 검사하고, DeFi 관련 측면을 면밀히 조사하여 가능한 위험 및/또는 버그를 찾아냅니다.
당사는 지금까지 잠재적인 문제 목록을 확인했습니다. 그 중 일부는 이전에 생각하지 못한 세밀한 코너 케이스(Corner Cases)와 관련되어 있고 다른 부분은 여러 컨트랙트 간의 비정상적인 상호 작용을 나타냅니다. 따라서 발견된 각 문제에 대해 추론, 재생산 및/또는 검증을 위한 테스트 케이스를 개발했습니다. 추가 분석과 내부 논의를 거쳐 위의 표에 분류된 다양한 심각도의 몇 가지 문제를 제기하고 더 많은 관심을 기울여야 한다고 결정했습니다. 자세한 내용은 다음 하위 부문에서 찾을 수 있으며 각각에 대한 자세한 설명은 부분-3에서 확인할 수 있습니다:
2.2 주요 발견
전반적으로 스마트 컨트랙트는 잘 설계되고 제작되었지만 1개의 중간 심각도 취약점, 4개의 낮은 심각도 취약점 및 1개의 정보용 권장 사항이 발견되었습니다. 식별된 문제(표 2.1 참조)를 해결하여 구현을 개선할 수 있습니다.
확인된 문제 외에도 중요한 것은 사용자 대면 응용 프로그램 및 서비스에 대해 필요한 위험 통제 메커니즘을 개발하고 메인넷 배포 전에 실행할 수 있는 비상 계획을 수립하는 것입니다. 위험 통제 메커니즘은 컨트랙트가 메인넷에 배포되는 바로 그 순간에 시작되어야 합니다. 자세한 내용은 부문-3을 참조하십시오.
4 | 결론
이 감사에서 당사는 네트워크 간의 교차 체인 상호 작용을 위한 분산형 인프라인 Umee 프로토콜의 설계 및 구현을 분석했습니다. 감사를 받는 차용 프로토콜은 AaveV2를 기반으로 개발되었으며 자체 인센티브 메커니즘을 통해 분산형 비구금형 자산 시장 프로토콜 역할을 합니다. 현재 코드 베이스는 잘 구성되어 있고 깔끔하게 정리되어 있습니다. 식별된 문제는 즉시 확인되고 해결되었습니다
또한 Solidity-기반 스마트 컨트랙트 전체가 아직 초기 단계이지만 흥미로운 개발 단계라는 점을 강조하고 싶습니다. 이 보고서를 개선하기 위해 방법론, 감사 결과 또는 스코프/범위의 잠재적 격차에 대한 건설적인 피드백이나 제안을 주시면 감사하겠습니다.
참조 문헌
[1] MITRE. CWE-287: Improper Authentication. https://cwe.mitre.org/data/definitions/287.html.
[2] MITRE. CWE-682: Incorrect Calculation. https://cwe.mitre.org/data/definitions/682.html.
[3] MITRE. CWE-837: Improper Enforcement of a Single, Unique Action. https://cwe.mitre.org/ data/definitions/837.html.
[4] MITRE. CWE-841: Improper Enforcement of Behavioral Workflow. https://cwe.mitre.org/ data/definitions/841.html.
[5] MITRE. CWE CATEGORY: 7PK — Security Features. https://cwe.mitre.org/data/definitions/ 254.html.
[6] MITRE. CWE CATEGORY: Business Logic Errors. https://cwe.mitre.org/data/definitions/ 840.html.
[7] MITRE. CWE CATEGORY: Error Conditions, Return Values, Status Codes. https://cwe.mitre. org/data/definitions/389.html.
[8] MITRE. CWE VIEW: Development Concepts. https://cwe.mitre.org/data/definitions/699. html.
[9] OWASP. Risk Rating Methodology. https://www.owasp.org/index.php/OWASP_Risk_ Rating_Methodology.
[10] PeckShield. PeckShield Inc. https://www.peckshield.com.
