CertiK: 사고 보험을 판매한 보험 회사도 사고를 당했습니까? Cover 프로토콜 취약점 분석
최근 동네에 떠도는 유기견이 나타났는데, 이웃집 아이가 개를 보고 놀라 도망가다가 오히려 개에게 쫓겨 물렸다고 합니다.
다행스럽게도 부모는 수완이 좋아서 아이에게 상해보험을 가입시켰고, 광견병 백신 몇 접종도 큰 비용이 들지 않았다.
통화 시민으로서 암호화된 자산이 안타깝게도 도난당했지만 프로젝트 당사자 또는 귀하가 개인적으로 보험을 구입한 경우 보험 회사가 손실된 자산을 상환할 것이라고 안심할 수 있습니다.
하지만 최악의 상황이 있다. 그런데 보험사까지 보안 사고가 발생해 공격을 받는다면?

기술적 분석
공격자는 프로젝트의 스마트 컨트랙트를 반복적으로 약정하고 회수하여 토큰 발행 작업을 트리거하고 Cover 토큰을 무한히 발행하여 Cover 토큰의 가격을 폭락시켰습니다.
기술적 분석
주요 공격은 다음 단계로 나뉩니다.
① Balancer Pool에 총 2,573 DAI 유동성 제공
②공격자는 Balancer Pool에 유동성을 제공하여 약 132,688개의 Balancer 유동성 증명 토큰 BPT를 획득했습니다.
그림 1: blacksmith.sol의 deposit() 함수
입금 기능을 호출하여 공격자는 획득한 BPT 유동성 증명을 커버 프로토콜에 약속합니다.
먼저 그림 1의 라인 118을 통해 현재 유동성 증명 토큰의 풀 데이터를 메모리로 읽은 다음 라인 121을 호출하여 현재 풀의 데이터를 업데이트합니다.

다음으로, 그림 3의 318행에 표시된 대로 deposit()은 _claimCoverRewards() 함수를 호출하여 특정 수의 커버 토큰을 함수 호출자(msg.sender)에게 캐스팅합니다.
발행된 커버 토큰의 수는 pool.accRewardsPerToken, CAL_MULTIPLIER 및 miner.rewardWriteoff의 세 가지 변수와 관련이 있습니다.
여기서 pool.accRewardsPerToken의 값은 그림 2의 update() 함수를 사용하여 업데이트된 값이 아니라 메모리에 저장된 풀 데이터를 사용한다는 점에 유의하십시오.
동시에 miner.rewardWriteoff의 값 업데이트는 _claimCoverRewards() 함수의 실행이 완료된 후에 발생함을 그림 1의 예금 함수에서 알 수 있습니다.
따라서 원래 설계에서는 miner.rewardWriteoff의 업데이트된 값을 사용하여 발행해야 하는 커버 토큰의 수를 계산해야 합니다. 커버토큰이 발행된 토큰의 수보다 많아져 그 수가 증가하여 결국 토큰의 발행으로 이어졌습니다.
서약이 성공한 후 공격자는 blacksmith.sol 스마트 컨트랙트의 철수() 함수를 호출하여 서약된 BPT를 검색하고 추가로 발행된 커버 토큰을 얻어 공격을 완료합니다.
deposit()함수와withdraw()함수 실행 후 토큰 잔고표를 비교해보면, 공격자는 이 입출금 함수를 호출한 후 약 704개의 COVER 토큰을 획득할 수 있음을 알 수 있다.
입금 후():
인출 후():
공격 후 보도 시간 현재 공식 표지는 대장장이를 안전한 버전으로 마이그레이션했습니다.
취약한 대장장이 주소:
0xe0b94a7bb45dd905c79bb1992c9879f40f1caed5
임시 수정 후 대장장이 주소:
0x1d5fab8a0e88020309e52b77b9c8edf63c519a26
일시적으로 수리된 대장장이 계약은 공격자가 계속해서 공격하지 못하도록 모든 서약 및 출금 작업을 일시적으로 금지합니다.
이 공격에서 공격자는 총 440만 달러(약 2,900만 위안)의 이익을 챙겼습니다.
이 취약점을 이용하여 유사한 공격을 실행하는 다른 공격자가 있습니다.예를 들어 Grap.finance 프로젝트 관계자는 이 취약점을 사용하여 공격에 참여하여 4350 ETH 토큰을 얻었습니다.
안전 조언
안전 조언
방문을 환영합니다https://www.certik.foundation/
CertiK 보안 제품에 대한 자세한 정보를 보려면 CertiK 재단의 공식 웹사이트를 입력하십시오!







