블록체인 보안 문제에 대응하기 위해 Beosin(Chengdu Lianan) 팀은 매주 스마트 계약의 보안 취약성을 분석하고 직렬화하여 프로그래머가 문제가 발생하기 전에 더 안전하고 확고한 계약을 작성하여 문제가 발생하기 전에 예방할 수 있기를 바랍니다.
요약
요약
지난 권에서는 EOS 게임이 반복적으로 공격을 받았고, 난수 허점이 반복적으로 금지되었습니다.
이 문제의 주제
이 문제의 주제
DApp 위조 통화 오도, 전송 기능 감지 누락은 엉성합니다.
올해 더 큰 인기를 끌고 있는 국내 영화라고 하면 주윤발의 '오쌍'은 자리가 있어야 한다. .
보조 제목
기본 지식의 길을 닦다
EOS 스마트 계약의 아키텍처
EOS 스마트 계약은 일련의 작업으로 구성되며 각 작업은 조항의 특정 규칙을 구현하기 위한 계약 조항을 나타냅니다. EOS 스마트 계약을 실행하는 것은 작성, 배포 및 호출의 세 부분으로 나뉩니다.
그 중 스마트 컨트랙트를 배포하는 단계에서 각 EOS 스마트 컨트랙트는 작업 요청을 특정 처리 기능에 매핑하는 데 사용되는 apply() 함수를 구현해야 합니다. 구체적인 구현 세부 사항은 EOSIO_ABI 매크로에 캡슐화되어 있습니다. 이 설계를 통해 개발자는 기본 기술에 주의를 기울이지 않고 비즈니스 논리 개발에만 집중할 수 있으므로 개발이 간소화됩니다. 적용 기능의 예:
가짜 EOS 전송 공격
역사적 사건:
잘 알려진 EOSBet은 9월 12일 약 42,000 EOS를 잃었고, 이는 가짜 EOS 토큰을 사용하여 공격하는 해커의 급증을 시작했으며, eoswindice와 탈중앙화 거래소 newdex가 모두 해커로 전락했습니다.
공격 분석:
EOS 체인의 공통 토큰은 EOS 토큰으로 EOSIO가 배포한 eosio.token 계약에 의해 생성되지만 eosio.token 코드는 오픈 소스이므로 모든 eos 계정은 자체적으로 eosio.token 계약을 배포하고 축약된 이름 EOS의 토큰입니다. 그림과 같이 많은 수의 가치 없는 가짜 EOS를 볼 수 있습니다.
EOS의 진위를 식별하는 방법은 무엇입니까? 돈 탐지기? 물론 그렇지는 않지만 eosflare 브라우저에 토큰의 전체 이름이 표시되며 실제 EOS와 가짜 EOS의 전체 이름에는 차이가 있습니다.
사진에서 알 수 있듯이 하나는 EOS이고 그 뒤에 다른 설명이 없고 다른 하나는 환불 지갑의 가짜 EOS(refundwallet)입니다.
브라우저에서 트랜잭션 내역을 보고 트랜잭션에 사용된 EOS 토큰이 진위인지 판단할 수 있는데 스마트 컨트랙트에 넣으면 어떨까?
예를 들어 케이스 계약은 다음과 같습니다.
void transfer(const account_name& from,
const account_name& to,
const asset& quantity,
const string& memo)`
콜백을 받기 위해 사용하는 함수로, 가짜 EOS가 통과되면 진위를 판별할 수 있는 방법이 없습니다. 적용 시 EOS가 미리 감지되지 않으면 컨트랙트가 가짜 EOS를 수신하고 정상적인 비즈니스 로직을 실행하게 됩니다. 악의적인 계정이 컨트랙트를 배포하여 EOS 토큰을 발행하면 빈손 백랑을 실현하고 가짜 지폐를 실제 돈으로 교환할 수 있습니다.
버그 수정:
EOS의 발행자가 eosio인지 확인하기 위해서는 apply()에 == eosio.token 코드를 추가하여 판단해야 합니다.
보조 제목
변종 1: 전달 함수에 대한 직접 호출 공격
취약점 분석:
위에서 언급한 취약점 복구 방법에 따라 관련 판단을 추가한 후 많은 프로젝트 당사자들이 안도의 한숨을 내쉬었지만 EOSBet 사건을 일으킨 취약점 코드는 그리 쉽게 고쳐지지 않았습니다. 위에서 언급한 적용을 사용하여 코드 호출을 감지할 때 감지 조건이 다음과 같은 경우에만 다른 우회 상황이 있기 때문입니다.
if( code == self || code==N(eosio.token) ||action == N(onerror))
그런 다음 이 탐지 조건은 함수 자체 작업 호출과 eosio.token에서 작업 호출의 두 가지 탐지만 처리합니다. 확인 없는 전송 작업 호출자는 eosio.token 또는 자체 계약이어야 합니다.
이것은 계약 계정에서 직접 호출할 수 있는 전송으로 이어질 것입니다.
예를 들어, 사용자 A는 원래 eosio.token을 호출하여 사용자 B에게 1 EOS를 전송한 다음 eosio.token이 전송 영수증을 전송하여 컨트랙트 B의 전송 기능을 호출하여 비즈니스 로직을 실행했습니다. to, value 등의 매개변수를 수정하여 송금하지 않고 B 컨트랙트의 비즈니스 로직을 직접 실행합니다. 따라서 EOSBet을 공격한 공격자는 eosio.token->transfer 함수를 완전히 우회하여 올바른 매개변수로 eosbetdice11->transfer를 직접 호출하고 EOS를 컨트랙트로 전송하지 않고 컨트랙트의 비즈니스 로직을 실행했습니다.
버그 수정:
이러한 유형의 공격에 대한 방어 방법은 동작과 코드를 동시에 탐지하는 것입니다.
보조 제목
if (code == N(eosio.token) && action == N(transfer))
{ }
변종 2 EOS 가짜 영수증 공격
역사적 사건:
9월 14일 사건 이후 EOSBet은 코드 보안에 대한 중요성을 언급하는 공식 성명을 발표했습니다.
그러나 불과 한 달 후인 10월 15일, EOSBet은 다시 해킹을 당하여 거의 140,000 EOS를 잃었습니다.
취약점 분석:
취약점의 원인은 스마트 컨트랙트 처리 로직의 전달 기능에 to 판단이 부족하여 to 판단이 누락되면 컨트랙트가 전달을 받은 자신이 맞는지 판단할 수 없으며 계속 실행될 수 있음 공격자가 두 개의 계정 AB를 가지고 있고, c가 게임 컨트랙트 계정이고 공격자는 계정 A를 통해 eosio.token을 호출하여 계정 B로 EOS를 전송한 다음 계정 A 또는 B에 컨트랙트를 배포할 수 있다고 가정합니다. 그리고 callback transfer에서 require_recipient(N(XXXXXX)를 다시 호출); 게임 컨트랙트 C 계정으로 전송 알림을 전송하여 code==N(eosio.token)&&action==transfer 검증을 우회할 수 있도록 합니다. 비즈니스 로직을 실행할 수 있습니다.
버그 수정:
void transfer(const account_name& from,
const account_name& to,
const asset& quantity,
const string& memo) {
보조 제목
return;
}
코드 보안은 흑백입니다.
일련의 보안 사고와 코드 복구 후, 공격을 받고 있는 게임 관계자는 마침내 겉보기에 믿을 수 없는 허점을 해결했습니다. 블록체인 보안은 매우 엄격하고 가치 있는 기술이며 지난 2년 동안의 충돌과 충돌로 인해 매우 무거운 주제가 되었습니다. "오상"에 "흑백만 보는 사람은 무조건 패자다"라는 대사가 있는데 이 문장은 블록체인 분야에서는 해당되지 않는다. 영화.
인용하다:
인용하다:
[1]: 가짜 EOS 공격 업그레이드 다시: EOSCast는 해커 "가짜 EOS 전송 변종"의 공격을 받아 60,000개 이상의 EOS 손실；
[2]: 해커의 공격을 받는 BET의 전체 이야기, 실제 망치가 범죄 현장과 공격 방법을 복원합니다.；
[3]: 충격! EOSBet이 다시 공격을 받았습니다. 손실액은 5000만원에 달했다. 이것이 공격 방식입니까?；
IOS
Android