저자: Immunefi 편집: Coinitme.com QDD
소개
블록체인 기술로 구동되는 스마트 계약은 분산화 및 자동화를 제공하여 다양한 산업에 혁명을 일으켰습니다. 그러나 그들은 또한 분산 응용 프로그램의 운영 및 설계에 새로운 유형의 보안 문제를 도입합니다.
이 기사에서는 안전하고 강력한 스마트 계약을 구축하기 위해 개발자와 감사자가 알아야 할 10가지 가장 일반적인 스마트 계약 취약점을 살펴봅니다.
참고: Immunefi를 통해 제출된 대부분의 프로젝트와 버그는 EVM 기반 블록체인을 사용합니다. 따라서 이 문서에서는 이러한 기술에 중점을 둘 것입니다. 그러나 이러한 분류는 일반적이며 모든 블록체인 기술로 확장 가능합니다. 목록에 있는 취약점은 2023년 1분기까지 Immunefi를 통해 제출되고 지불된 취약점을 자세히 설명하는 과거 버그 수정 검토 기사와 해킹의 조합을 통해 식별되었습니다.
허점
V01:2023 잘못된 입력 검증
개요
부적절한 입력 유효성 검사는 Immunefi를 통해 제출된 확인된 수많은 취약성 보고서와 야생에서의 익스플로잇의 주요 소스입니다. 입력 유효성 검사는 시스템에 입력된 데이터의 무결성, 정확성 및 보안을 확인하는 것과 관련된 중요한 보안 관행입니다. 입력을 제대로 확인하지 못하면 공격자가 취약성을 악용하고 시스템 동작을 조작할 가능성이 열립니다.
설명하다
부적절한 입력 유효성 검사는 스마트 계약이 사용자 입력을 적절하게 유효성 검사하고 삭제하지 못하여 다양한 유형의 공격에 취약할 때 발생합니다. 이러한 취약성은 계약 논리를 조작하거나 악의적인 데이터를 주입하거나 예기치 않은 동작을 유발하는 데 악용될 수 있습니다. 적절한 입력 유효성 검사는 계약이 유효하고 예상되는 데이터만 처리하도록 하여 악용 위험을 줄입니다.
예방법
이러한 취약성을 방지하기 위해 개발자는 포괄적인 입력 유효성 검사 루틴을 구현해야 합니다. 여기에는 데이터 유형 유효성 검사, 경계 조건 확인 및 사용자 입력 삭제가 포함되어 놀라움을 방지합니다. 강력한 입력 유효성 검사를 보장하려면 경계 사례 및 예기치 않은 입력을 포함하여 가능한 모든 입력 사례를 고려해야 합니다. 난독화 또는 기호 실행과 같은 일부 도구 및 기술은 개발자가 엣지 케이스를 놓치는 것을 방지하는 데 도움이 될 수 있습니다. 이러한 도구는 개발자가 다양한 입력을 테스트하여 악의적인 입력이 스마트 계약 불변성 또는 실행을 중단하지 않도록 합니다.
예
Beanstalk Logic Error Bugfix Review는 누락된 입력 유효성 검사 버그의 예를 보여줍니다. Beanstalk Token Facet 컨트랙트에는 msg.sender 허용량이 외부 모드 전송 중에 제대로 검증되지 않는 transferTokenFrom() 함수의 취약점이 있었습니다. 이 취약점으로 인해 공격자는 이전에 Beanstalk 계약을 승인한 피해자 계정에서 자금을 이체할 수 있었습니다.
참조:
l https://medium.com/immunefi/sovryn-loan-vulnerability-postmortem-ffaf4d1d688f
l https://medium.com/immunefi/zapper-arbitrary-call-data-bug-fix-postmortem-d75a4a076ae9
l https://medium.com/immunefi/cream-finance-insufficient-validation-bug-fix-postmortem-1ec7248e8865
l https://medium.com/immunefi/pancakeswap-logic-error-bug-fix-postmortem-f2d02adb6983
엘https://medium.com/immunefi/mcdex-insufficient-validation-bug-fix-postmortem-182fc6cab899
l https://medium.com/immunefi/polygon-lack-of-balance-check-bugfix-postmortem-2-2m-bounty-64ec66c24c7d
l https://medium.com/immunefi/notional-double-counting-free-collateral-bugfix-review-28b634903934
l https://medium.com/immunefi/port-finance-logic-error-bugfix-review-29767aced446
엘 https://medium.com/immunefi/aurora-withdrawal-logic-error-bugfix-review-c5b4e30a9160
엘https://medium.com/immunefi/aurora-improper-input-sanitization-bugfix-review-a9376dac046f
l https://medium.com/immunefi/mt-pelerin-double-transaction-bugfix-review-503838db3d70
엘 https://medium.com/immunefi/balancer-logic-error-bugfix-review-74f5edca8b1a
l https://medium.com/immunefi/beanstalk-logic-error-bugfix-review-4fea17478716
엘 https://medium.com/immunefi/hack-analysis-platypus-finance-february-2023-d11fce37d861
V02:2023 잘못된 계산
개요
부정확한 계산은 우리가 Immunefi에서 본 확인된 버그 보고서에서 거의 두 번째입니다.
스마트 계약에서 부정확하거나 일관되지 않은 계산은 부정확한 토큰 잔액, 부정확한 보상 분배 또는 계약 실행 중 예상치 못한 결과와 같은 의도하지 않은 결과를 초래할 수 있습니다. 잘못된 계산은 종종 충분히 활용되지 않은 코드 경로와 일치하며 잘못된 입력 유효성 검사 취약점과 밀접한 관련이 있습니다. 그러나 잘못된 계산과 관련된 취약점은 사용자가 어떤 작업을 수행할 수 있어야 하지만 잘못된 계산으로 인해 사용자가 해당 작업에서 예상보다 훨씬 더 많은 가치를 얻을 수 있다는 것입니다.
설명하다
스마트 계약에서 계산 오류는 수학적 계산이 잘못 수행되어 예기치 않거나 잘못된 결과가 발생할 때 발생합니다. 이러한 취약성은 정밀도, 값 범위에 대한 잘못된 가정 또는 계약의 다른 부분에 대한 일관되지 않은 계산과 같은 여러 가지 이유로 발생할 수 있습니다. 계약이 엣지 케이스를 고려하지 않거나 코너 케이스를 적절하게 처리하지 않는 경우에도 잘못된 계산이 발생할 수 있습니다. 경우에 따라 계약이 극한값을 고려하지 않거나 오버플로 또는 언더플로를 처리하지 못하여 예기치 않은 동작 또는 보안 위험이 발생할 수 있습니다. 공격자는 이러한 취약성을 악용하여 계약에서 계산을 조작하거나 승인되지 않은 이점을 얻을 수 있습니다. 이러한 취약성을 방지하려면 적절한 수학적 정밀도와 코너 케이스에 대한 신중한 고려가 중요합니다.
예방법
난독화 또는 기호 실행 과 함께 단위 테스트를 수행하면 누락된 엣지 케이스가 코드 베이스에 잠입하는 것을 방지할 수 있습니다. 또한 수학 공식의 공식 검증은 가능한 상태에 대한 보증을 제공하는 데 도움이 됩니다. 잘 테스트되고 안전한 수학 라이브러리 또는 블록체인 플랫폼에서 제공하는 내장 함수를 사용하여 정확하게 계산을 수행하십시오. 이러한 라이브러리에는 종종 오버플로 또는 언더플로와 같은 일반적인 계산 오류에 대한 보호 기능이 내장되어 있습니다.
예
예
참조:
엘 https://medium.com/immunefi/armorfi-bug-bounty-postmortem-cf46eb650b38
l https://medium.com/immunefi/vesper-rebase-vulnerability-postmortem-and-bug-bounty-55354a49d184
엘 https://medium.com/immunefi/pods-finance-bug-fix-postmortem-61a576897ebd
l https://medium.com/immunefi/tidal-finance-logic-error-bug-fix-postmortem-3607d8b7ed1f
l https://medium.com/immunefi/belt-finance-logic-error-bug-fix-postmortem-39308a158291
l https://medium.com/immunefi/cronos-theft-of-transactions-fees-bugfix-postmortem-b33f941b9570
l https://medium.com/immunefi/apwine-incorrect-check-of-delegations-bugfix-review-7e401a49c04f
l https://medium.com/immunefi/polygon-consensus-bypass-bugfix-review-7076ce5047fe
엘 https://medium.com/immunefi/synthetix-logic-error-bugfix-review-40da0ead5f4f
엘 https://medium.com/immunefi/building-a-poc-for-the-uranium-heist-ec83fbd83e9f
l https://medium.com/immunefi/hack-analysis-saddle-finance-april-2022-f2bcb119f38
엘 https://medium.com/immunefi/88mph-theft-of-unclaimed-mph-rewards-bugfix-review-1dec98b9956b
V03:2023 Oracle/ 가격 조작
개요
스마트 계약은 정보에 입각한 결정을 내리기 위해 종종 외부 데이터 소스(오라클이라고 함)에 의존합니다. 이러한 명목 화폐가 손상되거나 조작되면 잘못 가격이 책정된 스왑, 잘못 계산된 보상, 담보 비율이 허용하는 것보다 더 많은 자산 차용 또는 금융 거래와 관련된 기타 일반적인 문제로 이어질 수 있습니다. 이러한 외부 데이터 소스를 조작하는 것은 온체인 DeFi 취약점의 주요 원인 중 하나입니다. 신뢰할 수 있는 오라클을 선택하고 안전한 데이터 검증 메커니즘을 구현하는 것은 오라클/가격 조작과 관련된 위험을 줄이는 데 중요합니다.
설명하다
많은 프로토콜이 사용자 작업을 기반으로 자산 가격을 업데이트하므로 가격이 사용자 상호 작용을 기반으로 업데이트될 것으로 예상되므로 이는 명백하지만 간과하기 쉬운 취약점일 수 있습니다. 그러나 프로토콜이 이러한 내부 또는 외부 가격 책정 메커니즘에 의존하는 경우 현물 가격이 남용되지 않도록 신중하게 고려해야 합니다. 가격 조작이 효과적으로 실행될 수 있는지 여부는 현재 온체인 상태에 따라 크게 좌우됩니다. 액체 풀이 적을수록 액체 풀이 많을 때보다 조작될 위험이 더 높습니다. 신뢰할 수 있는 토큰을 신중하게 선택하고 안전한 데이터 검증 메커니즘을 구현하는 것이 중요합니다. 정적 확인, 평균 가격 메커니즘 및 읽기 전용 재진입 보호는 외부 가격 메커니즘의 강력한 통합을 위한 중요한 기능일 수 있습니다. 데이터 소스의 다양화는 또한 단일 프로토콜의 취약성이 전체 블록체인 생태계에 큰 피해를 입히는 것을 방지합니다.
예방법
오라클/가격 조작 취약점을 방지하기 위해 개발자는 입증된 실적이 있는 신뢰할 수 있는 오라클을 신중하게 선택해야 합니다. 암호화 증명 또는 다중 소스 집계와 같은 보안 데이터 확인 메커니즘을 구현하면 수신된 데이터의 정확성과 무결성을 보장하는 데 도움이 될 수 있습니다. 오라클 계약 및 스마트 계약과의 상호 작용에 대한 정기적인 감사 및 모니터링도 잠재적인 취약성을 발견하는 데 도움이 될 수 있습니다. 외부 오라클에서 반환된 데이터의 정확성에 대해 가정해서는 안 되며, 일시적인 가격 조작이나 오래된 데이터가 프로토콜 운영에 영향을 미치지 않도록 보호 조치를 취해야 합니다.
예
BonqDAO는 공격자가 빌릴 수 있는 것보다 훨씬 더 많은 스테이블 코인(BEUR)을 빌리기 위해 일시적으로 WALBT 토큰의 가격을 부풀릴 수 있는 가격 오라클 조작 공격으로 고통 받았습니다. 그런 다음 공격자는 가격을 다시 조작하여 30개가 넘는 담보가 없는 코인을 청산하기 위해 가격을 최소값으로 줄였습니다. BonqDAO의 취약점은 가격 보고 메커니즘이 허가가 없다는 것이 아니라 계약 계약의 현물 가격을 마지막으로 보고된 값으로 간주한다는 것입니다. 이 때문에 누구나 순식간에 주어진 가격의 가치를 올리거나 내릴 수 있다.
참조:
l https://medium.com/immunefi/fei-protocol-vulnerability-postmortem-483f9a7e6ad1
l https://medium.com/immunefi/fei-protocol-flashloan-vulnerability-postmortem-7c5dc001affb
l https://medium.com/immunefi/mushrooms-finance-theft-of-yield-bug-fix-postmortem-16bd6961388f
l https://medium.com/immunefi/enzyme-finance-price-oracle-manipulation-bug-fix-postmortem-4e1f3d4201b5
l https://medium.com/immunefi/hack-analysis-cream-finance-oct-2021-fc222d913fc5
l https://medium.com/immunefi/hack-analysis-bonqdao-february-2023-ef6aab0086d6
V04:2023 취약한 액세스 제어
개요
취약한 액세스 제어 메커니즘으로 인해 무단 사용자나 악의적인 행위자가 스마트 계약의 중요한 기능이나 데이터에 무단으로 액세스할 수 있습니다. 액세스 제어는 승인된 엔터티만 특정 기능과 상호 작용하거나 중요한 매개 변수를 수정할 수 있도록 하는 데 필수적입니다.
설명하다
무단 액세스를 방지하려면 역할 기반 권한 및 강력한 인증 메커니즘과 같은 적절한 액세스 제어 조치를 구현해야 합니다. 시스템 내 행위자의 이러한 제약 조건과 기능을 명확하게 문서화하면 심각한 취약성의 위험이 있는 작업을 강조하는 데 도움이 될 수 있습니다. 이러한 종류의 문서는 단위 테스트를 개선하고 잠재적인 충돌을 식별하여 시스템이 예상대로 작동하는지 확인하고 주요 버그로 이어지는 확인 누락의 위험을 최소화하는 데 도움이 됩니다. 또한 프로젝트는 Web2 세계의 위험이 전체 시스템에 돌이킬 수 없는 피해를 입히지 않도록 역할의 허용된 작업을 최대한 제한해야 합니다. 역할이 충분히 세분화되지 않았거나 프로토콜이 중앙 집중식 보안 모델에 크게 의존하는 경우 개인 키의 손상은 엄청난 피해를 줄 수 있습니다.
예방법
예방법
취약한 액세스 제어 취약성을 방지하려면 개발자는 역할 기반 액세스 제어 메커니즘을 구현해야 합니다. 계약 문서에서 역할 및 관련 권한을 명확하게 정의합니다. 입증되고 테스트된 라이브러리를 사용하여 강력한 서명 확인을 구현합니다. 시스템 요구 사항 또는 사용자 역할의 변경 사항을 설명하기 위해 액세스 제어 메커니즘을 정기적으로 검토하고 업데이트합니다.
예
Enzyme Finance는 주유소 네트워크라는 외부 구성 요소와 통합될 때 생성된 취약점을 발견한 연구원에게 보상을 했습니다. 주유소 네트워크는 dApp이 개별 사용자 대신 거래 비용을 지불할 수 있도록 하는 중계기의 탈중앙화 네트워크입니다. 결제 프로그램에는 중계 작업자가 환불에 사용한 금액을 반환하는 트러스트 포워더에 대한 확인이 없습니다. 동영상이 마음에 드신다면 Sense Finance의 $50,000 현상금 지급 분석을 시청하시기 바랍니다.
참조:
lhttps://medium.com/immunefi/88mph-function-initialization-bug-fix-postmortem-c3a2282894d3
lhttps://medium.com/immunefi/mushrooms-finance-logic-error-bug-fix-postmortem-780122821621
l https://medium.com/immunefi/alchemix-access-control-bug-fix-debrief-a13d39b9f2e0
엘 https://medium.com/immunefi/openzeppelin-bug-fix-postmortem-66d8c89ed166
엘https://medium.com/immunefi/sense-finance-access-control-issue-bugfix-review-32e0c806b1a0
엘 https://medium.com/immunefi/enzyme-finance-missing-privilege-check-bugfix-review-ddb5e87b8058
V05:2023 반복 공격 / 시그니처 변조
스마트 계약 개요
V05:2023 반복 공격 / 시그니처 변조
스마트 계약 개요
암호화는 모든 스마트 계약 기능의 핵심입니다. 프로토콜에 구현된 암호화 프리미티브는 일반적으로 무허가 방식으로 작동하는 온체인에서 사용되는 것과 동일합니다. 그러나 때때로 잘못 사용되어 예상보다 많은 작업이 수행되어 재정적 손실이나 잘못된 계약 상태가 발생할 수 있습니다.
설명하다
재생 공격은 공격자가 유효한 트랜잭션이나 메시지를 복사하여 스마트 계약이 작업을 두 번 이상 수행하도록 속일 때 발생합니다. EVM 기반 체인은 원래 ecrecover에 액세스할 수 있으므로 스마트 계약을 통해 특정 데이터가 복구 주소로 확인되고 서명되었는지 확인할 수 있습니다. 그러나 이 기본 기능은 어떤 형태의 재생 보호도 구현하지 않습니다.
일반적으로 재생 방지는 서명이 사용될 때 증가하는 nonce(한 번 사용되는 숫자)를 도입하여 구현되며 nonce가 업데이트되면 원래 서명을 다시 사용할 수 없습니다. 서명 가단성은 서명을 무효화하지 않고 수정하여 서명을 두 번 사용할 수 있는 기능을 말합니다. 데이터를 인코딩하거나 다른 유형 간에 변환할 때 서명을 확인할 때 값의 특정 부분이나 비트를 무시하고 재생 공격을 방지하기 위해 모두 사용하는 기능을 도입할 수 있습니다.
예방법
재생 공격 및 서명 변조 취약성을 방지하기 위해 개발자는 비 CE 기반 트랜잭션 관리를 구현해야 합니다. Nonce는 각 트랜잭션이 고유하도록 보장하여 재생 공격을 방지할 수 있습니다. 또한 서명의 무결성 및 신뢰성 확인과 같은 적절한 서명 확인 검사를 구현하면 서명 변조 공격을 방지하는 데 도움이 될 수 있습니다. 계약 설계에는 일회성 토큰 또는 고유 트랜잭션 식별자와 같은 작업의 우발적 복제를 방지하는 메커니즘도 포함되어야 합니다.
예
당시 역사상 가장 높은 현상금 버그인 Polygon의 Double-Spend 버그는 이전 블록에서 소각 트랜잭션의 포괄성과 고유성을 확인하는 데 사용된 Polygon의 WithdrawManager의 버그와 관련이 있습니다. 인코딩된 branchMask 메서드를 사용하면 여러 고유 분기 마스크를 동일한 이탈 ID로 인코딩할 수 있습니다. 이 서명의 변조 가능성으로 인해 공격자는 $100,000만 예치하고 서명을 재사용할 수 있으므로 $22.3백만의 손실이 발생합니다.
참조:
https://medium.com/immunefi/polygon-double-spend-bug-fix-postmortem-2m-bounty-5a1db09db7f1
https://medium.com/immunefi/hack-analysis-nomad-bridge-august-2022-5aa63d53814a
https://medium.com/immunefi/hack-analysis-binance-bridge-october-2022-2876d39247c1
V06:2023 오류
개요
부동 소수점 산술 및 반올림 오류를 부적절하게 처리하면 재정적 불일치 또는 계약 논리가 악용될 수 있습니다. 숫자 연산을 정확하게 처리(해당되는 경우 고정 소수점 산술 사용)하는 것은 이러한 취약점을 방지하는 데 중요합니다. 일반적으로 이러한 취약점은 비표준 십진수 값이 예기치 않은 결과를 초래할 수 있는 무허가 교환 프로토콜에 나타날 수 있습니다.
개요
부동 소수점 산술 및 반올림 오류를 부적절하게 처리하면 재정적 불일치 또는 계약 논리가 악용될 수 있습니다. 숫자 연산을 정확하게 처리(해당되는 경우 고정 소수점 산술 사용)하는 것은 이러한 취약점을 방지하는 데 중요합니다. 일반적으로 이러한 취약점은 비표준 십진수 값이 예기치 않은 결과를 초래할 수 있는 무허가 교환 프로토콜에 나타날 수 있습니다.
설명하다
반올림 오류는 스마트 계약이 정밀도나 반올림을 고려하지 않고 부동 소수점 연산과 관련된 계산을 수행할 때 발생합니다. 이러한 오류로 인해 재정적 불일치, 자금 손실 또는 계약 내에서 계산된 잘못된 보상이 발생할 수 있습니다. 스마트 계약은 소수점 계산을 정확하게 처리하기 위해 고정 소수점 산술 또는 기타 메커니즘을 사용하여 반올림 오류를 최소화하거나 제거해야 합니다.
예방법
반올림 오류를 방지하려면 개발자는 정확한 숫자 조작을 제공하는 고정 소수점 산술 또는 라이브러리를 사용해야 합니다. 고정 소수점 산술은 정수 값을 사용하여 부동 소수점 산술의 부정확성을 피하면서 분수를 나타냅니다. 또한 경계 조건 및 코너 케이스를 포함한 수치 연산의 철저한 테스트 및 검증은 잠재적인 반올림 오류를 식별하고 해결하는 데 도움이 될 수 있습니다.
예
특히 DFX Finance는 이전에 EURS 토큰에 대한 비표준 십진수 값 2로 인한 반올림 오류로 인한 취약점을 패치했습니다. 동화자는 모든 자산이 USDC와 쌍을 이루기 때문에 DFX Finance의 자동화된 시장 조성자에게 필수적입니다. AssimilatorV2 계약은 모든 금액을 숫자로 변환하거나 프로토콜 전체에서 계산에 사용되는 기본 값을 담당합니다. 문제는 정수 나누기로 인해 사용자가 전송한 토큰이 0인 경우에 발생하지만 사용자는 여전히 Curve 풀의 해당 부분을 나타내는 Curve 토큰을 받습니다.
참조:
엘 https://medium.com/immunefi/dfx-finance-rounding-error-bugfix-review-17ba5ffb4114
V07:2023 재진입
개요
재진입은 이더리움에서 오랜 역사를 가지고 있으며, 2016년 이더리움의 초기 네트워크에 대한 가장 큰 공격 중 하나인 "The DAO Hack"은 이러한 유형의 취약점으로 인해 발생했습니다. 재진입을 통해 공격자는 이전 호출이 완료되기 전에 취약한 계약을 반복적으로 호출할 수 있으므로 예기치 않은 상태 변경 및 무단 자금 이체가 발생합니다.
설명하다
재진입 취약점은 계약이 상태 변경 및 실행 흐름을 제대로 관리하지 않고 실행 중에 외부 호출을 허용할 때 발생합니다. 재진입을 통해 공격자는 이전 호출이 완료되기 전에 취약한 계약을 반복적으로 호출할 수 있으므로 예기치 않은 상태 변경 및 무단 자금 이체가 발생합니다. 안전한 상태 관리 패턴을 구현하고 뮤텍스를 적용하면 재진입 공격의 위험이 줄어듭니다. 계약에서 가능한 재진입을 식별하는 데 도움이 되는 일부 도구에는 Slither , Mythril 및 Pyrometer 가 포함됩니다. 재진입에 대한 자세한 내용은 The Ultimate Guide to Reentrancy 기사에서 확인할 수 있습니다.
방지
재진입 취약점을 방지하려면 개발자는 "CEI(Check-Influence-Interact)" 패턴과 같은 보안 상태 관리 패턴을 따라야 합니다. 이 패턴은 외부 호출이 이루어지기 전에 모든 상태 변경이 발생하도록 하여 재진입 공격을 방지합니다. 또한 뮤텍스를 구현하거나 " ReentrancyGuard " 패턴을 사용하면 재진입 호출을 차단하여 재진입을 방지할 수 있습니다.
예
Omni 프로토콜이 해킹당했고 Ethereum 스마트 계약이 재진입 공격을 받아 140만 달러의 손실을 입었습니다. 취약한 코드는 onERC721Received 인터페이스를 구현하는 스마트 계약을 호출하는 ERC721의 safeTransferFrom 메서드를 사용합니다. 이러한 외부 호출은 실행을 수신자에게 넘겨주어 재진입 취약점을 도입합니다.
참조:
https://medium.com/immunefi/hack-analysis-omni-protocol-july-2022-2d35091a0109
V08:2023 프런트러닝
개요
Frontrunning은 공격자가 보류 중인 트랜잭션을 관찰하고 이를 블록에 포함시키는 사이의 시간 지연을 악용하는 기술입니다. 가스 가격이 더 높은 피해자의 거래보다 자신의 거래를 먼저 배치함으로써 공격자는 특정 계약 상호 작용의 결과를 자신에게 유리하게 조작할 수 있습니다. 분산형 교환, 경매 또는 거래 순서가 중요한 모든 시나리오의 경우 선행 실행이 문제입니다.
설명하다
Frontrunning은 공격자가 선제적으로 트랜잭션을 실행하여 이점을 얻을 때 발생하며, 특히 블록에 포함될 보류 중인 트랜잭션을 알고 있을 때 발생합니다. 스마트 계약의 경우 트랜잭션 순서가 결과에 영향을 미치는 상황에서 선행 실행이 해로울 수 있습니다. 예를 들어 분산형 거래소에서 공격자는 피해자가 특정 가격에 특정 토큰을 구매하려는 보류 중인 트랜잭션을 관찰할 수 있습니다. 그런 다음 피해자의 거래가 실행되기 전에 더 낮은 가격으로 더 높은 가스 가격으로 동일한 토큰을 구매하기 위해 자신의 거래를 신속하게 제출할 수 있습니다. 이런 식으로 공격자는 가격 차이에서 이익을 얻고 피해자는 가격을 지불합니다. 프론트러닝은 mempool을 관찰하는 모든 사람이 수행할 수 있지만 블록 생산자 자신이 수행할 수도 있습니다. 일부 체인에는 위험을 줄이는 개인 RPC가 있지만 개인 mempool 내의 유효성 검사기와 블록 생산자도 잘못된 신뢰 가정을 만들 수 있습니다. 개발자는 프로토콜을 보호하기 위해 부분적으로 신뢰 또는 일관된 인센티브에 의존하는 외부 완화에 의존하기보다는 스마트 계약 수준에서 잠재적인 선행 실행 기회를 줄여야 합니다.
방지
프리런 방지는 기술과 설계의 종합적인 고려가 필요합니다. 몇 가지 예방 조치에는 비밀 유지 또는 커밋 공개 체계 사용, 거래가 확인될 때까지 가격 또는 입찰과 같은 민감한 정보를 비밀로 유지하는 체계 구현, 오프체인 주문 일치, 플래시 봇(사용자가 거래를 함께 묶고 채굴자에게 직접 제출할 수 있음)을 사용하여 선행 실행 가능성을 줄이고 수수료를 최적화하여 선두 주자에 의해 더 높은 입찰 기회를 줄이는 것이 포함됩니다.
예
예
프런트런 공격은 다양한 DeFi 프로토콜에서 발견되었습니다. RocketPool과 Lido는 두 베팅 서비스 모두에 영향을 미칠 수 있는 취약점에 대해 통보받았습니다. 악의적인 노드 운영자는 이전에 준비된 예치금 데이터와 최소 요구 예치금 값으로 사전 실행 예치금에 동일한 유효성 검사기 bls 키를 사용하여 사용자 예치금을 훔칠 수 있습니다.
참조:
https://medium.com/immunefi/rocketpool-lido-frontrunning-bug-fix-postmortem-e701f26d7971
V09:2023 초기화되지 않은 프록시 서버
개요
적절한 초기화 없이 프록시 계약을 사용하면 공격자가 초기화되지 않은 저장소 변수를 조작할 수 있으므로 취약점이 발생할 수 있습니다. 안전한 프록시 패턴을 구현하고 철저한 초기화 검사를 수행하는 것은 초기화되지 않은 계약 상태에 대한 무단 액세스를 방지하는 데 중요합니다. 초기화되지 않은 프록시 취약점으로 인해 현재까지 최대 1,000만 달러의 현상금이 발생했습니다.
설명하다
초기화되지 않은 프록시 계약은 프록시 계약의 상태 변수가 사용되기 전에 제대로 초기화되지 않은 경우입니다. 초기화되지 않은 스토리지 변수에 민감한 데이터가 포함되거나 중요한 계약 동작을 제어할 수 있으므로 보안 허점이 발생합니다. 공격자는 초기화되지 않은 저장소 변수를 조작하여 무단 액세스 권한을 얻거나 예기치 않은 작업을 수행함으로써 이러한 취약성을 악용할 수 있습니다. 이러한 위험을 줄이기 위해서는 프록시 계약이 프로덕션 환경에서 사용되기 전에 적절하게 초기화되었는지 확인해야 합니다.
예방법
초기화되지 않은 프록시 취약성을 방지하려면 개발자는 프록시를 배포하고 사용하기 전에 프록시 계약에 저장된 모든 변수가 적절하게 초기화되었는지 확인해야 합니다. 여기에는 민감한 데이터 초기화, 액세스 제어 권한 및 기타 중요한 상태 변수가 포함됩니다. 또한 개발자는 프록시 계약 내에서 포괄적인 초기화 검사를 구현하여 필요한 모든 변수와 종속성이 제대로 초기화되었는지 확인해야 합니다. 개발자는 올바른 초기화에 대한 2차 확인을 위한 모니터링 도구도 구현해야 합니다. 이는 자동화된 스크립트 또는 트랜잭션 번들에 의해 배포 후 호출되는 생성자 또는 초기화 기능을 통해 달성할 수 있습니다.
예
웜홀 초기화되지 않은 프록시 취약성 보고서는 지금까지 역사상 가장 높은 포상금을 받았습니다. 보고서를 제출한 흰 모자는 천만 달러의 포상금을 받았습니다. UUPS 프록시 계약을 배포할 때 "생성자"는 구현에 존재하는 일반 Solidity 기능입니다. 구현은 소유자를 초기화하는 initialize() 함수를 제공합니다. Wormhole은 구현하는 구현 계약을 초기화하지 않으므로 공격자가 구현을 제어하고 계약을 자체 파괴할 수 있으므로 프록시 계약이 가리키는 논리가 더 이상 존재하지 않기 때문에 프록시 계약이 실행되지 않습니다.
참조:
https://blog.openzeppelin.com/the-transparent-proxy-pattern
https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades
https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades
https://medium.com/immunefi/harvest-finance-uninitialized-proxies-bug-fix-postmortem-ea5c0f7af96b
https://medium.com/immunefi/wormhole-uninitialized-proxy-bugfix-review-90250c41a43a
V10:2023 거버넌스 공격 ( 거버넌스 공격 )
개요
거버넌스 공격은 분산 프로토콜 또는 스마트 계약 시스템에서 거버넌스 메커니즘을 조작하거나 악용하는 것을 말합니다. 이러한 공격은 의사 결정 프로세스, 투표 시스템 또는 거버넌스 시스템의 매개 변수 조정을 방해하여 공격자가 프로토콜에서 과도한 제어 또는 이익을 얻을 수 있도록 하는 것을 목표로 합니다.
설명하다
거버넌스 공격은 제안이 정족수 없이 실행되도록 허용하거나, 투표 단계 없이 제안이 실행되도록 허용하거나, 다른 참가자의 투표를 직접 조작하는 등 다양한 형태로 나타납니다. 이러한 공격은 프로토콜의 탈중앙화 특성을 약화시키고 권력을 집중시키거나 공격자에게 경제적 이익을 제공할 수 있습니다. 거버넌스 공격은 의사 결정 권한이 토큰 보유자에게 분산되는 분산형 자율 조직(DAO)과 특히 관련이 있습니다.
예방법
거버넌스 공격을 방지하려면 의사 결정 프로세스, 투표 메커니즘 및 참여 규칙을 설명하는 강력하고 명확하며 투명한 거버넌스 프레임워크를 갖추는 것이 필수적입니다. 안전한 변조 방지 투표 시스템을 구현하여 투표의 무결성을 보장합니다. 여기에는 보안 강화를 위한 암호화, 영지식 증명 또는 다중 서명 체계의 사용이 포함될 수 있습니다. 토큰의 공정하고 분산된 분배를 보장하고 소수의 독립체에 투표권이 집중되는 것을 방지합니다. 단기 조작을 방지하기 위해 토큰 베스팅 또는 락업 기간과 같은 메커니즘을 고려하십시오. 악의적인 행위자가 만장일치로 제안을 통과할 만큼 충분한 토큰을 획득하지 않도록 대부분의 거버넌스 토큰이 여러 거래소에 분산되지 않도록 합니다.
예
거버넌스 공격의 주목할만한 예는 무허가 FIAT 스테이블 코인 프로토콜 Beanstalk 에 대한 공격입니다. 해커는 BIP18 및 BIP19라는 두 가지 Beanstalk 개선 제안을 제출했습니다. 첫 번째 제안은 자금 전액을 공격자에게 이전하는 것이었고, 두 번째 제안은 $250,000 상당의 BEAN 토큰을 우크라이나 공식 암호화폐 기부 주소로 보내는 것이었습니다. 공격자는 Aave, Uniswap 및 SushiSwap에서 10억 달러 이상을 플래시 대출하여 긴급 거버넌스 시행을 촉발하기에 충분한 투표권(적어도 ⅔ 다수)을 얻었습니다.
참조:
https://medium.com/immunefi/hack-analysis-beanstalk-governance-attack-april-2022-f42788fc821e
결론적으로
스마트 계약이 계속 발전하고 널리 채택됨에 따라 개발자와 감사자는 최신 취약성과 보안 모범 사례를 파악하는 것이 중요합니다. 이러한 상위 10개 스마트 계약 취약성을 해결함으로써 이해 관계자는 스마트 계약의 보안 상태를 강화하고 블록체인 기반 시스템의 전반적인 신뢰와 신뢰성을 향상시킬 수 있습니다.
모든 댓글