디파이 프로토콜 아브라카다브라(Abracadabra)는 공격자가 배치 함수의 간단한 논리 오류를 악용하여 180만 달러의 손실을 입었습니다. 해켄(Hacken)의 분석가들은 공격자가 이미 토네이도 캐시(Tornado Cash)를 통해 자금을 세탁했다고 밝혔습니다.
- 공격자가 배치 함수의 간단한 논리적 실수를 악용한 후 아브라카다브라는 약 200만 달러의 손실을 입었습니다. 이는 며칠 전에 포크된 프로젝트에 가해진 공격과 유사합니다.
- 공격자는 차용인이 충분한 담보를 가지고 있는지 확인하기 위한 안전 플래그를 우회하여 한 번에 6개의 Cauldron을 비운 다음 도난한 MIM을 이더리움(ETH) 로 바꿔 Tornado Cash를 통해 라우팅했습니다.
- Abracadabra의 코드가 공격을 받은 것은 이번이 처음은 아니지만, 이 사건은 포크(Fork) 에서 동일한 결함이 발견되더라도, 구현되지 않은 작은 기능이 해커에게 어떻게 악용될 수 있는지를 보여줍니다.
10월 초, 사람들이 예치된 토큰을 담보로 스테이블코인 MIM을 빌릴 수 있게 해주는 DeFi 대출 프로토콜인 Abracadabra는 이전에 여러 차례 해커 공격을 받았지만 이번에는 공격자가 프로토콜의 배치 함수에서 간단한 논리적 실수를 이용해 담보를 제공하지 않고도 대출을 받은 후 약 180만 달러를 잃었습니다. 이는 며칠 전에 포크된 프로젝트가 공격을 받은 것과 같은 방식이라고 블록체인 보안 회사인 Hacken의 분석가들이 crypto.news에 공유한 연구 노트에서 밝혔습니다.
아브라카다브라는 사람들이 이자가 발생하는 토큰을 담보로 사용하여 매직 인터넷 머니(MIM)라는 미국 달러 연동 토큰을 빌릴 수 있도록 출시되었습니다. 이 시스템은 두 가지 요소로 구성됩니다. 대출 규칙을 처리하는 콜드론(Cauldrons)과 실제로 토큰을 보관하는 공유 금고인 데겐박스(DegenBox)입니다. 숏 말해, 콜드론에 담보를 넣으면 데겐박스가 이면에서 자금을 추적합니다.
문제의 숏 은 다음과 같습니다. 차용인이 실제로 담보를 보유하고 있는지 최종적으로 확인해야 하는 안전 플래그가 단일 거래 내에서 비활성화되었습니다. 해켄의 보고서에 따르면, 공격자는 "아브라카다브라의 cook() 함수에 있는 논리적 결함을 악용하여 MIM 토큰을 차용한 후 충분한 담보를 보유하고 있는지 확인해야 하는 유효성 검사 플래그를 즉시 재설정했습니다." 이로 인해 여러 Cauldron에서 단 한 번의 무담보 차용이 가능해졌습니다.
현미경으로
흐름은 다음과 같이 간단하게 설명할 수 있습니다. 아브라카다브라는 cook() 이라는 일괄 처리 함수를 사용하여 사용자가 한 번의 거래에서 여러 작업을 수행할 수 있도록 합니다. 예를 들어, 한 번의 클릭으로 담보를 예치하고 대출하는 작업을 수행할 수 있습니다. "대출" 단계와 같은 이러한 작업 중 하나는 needsSolvencyCheck 라는 플래그를 true로 설정합니다. 이는 "이 거래가 종료될 때 대출자가 안전한지 확인"을 의미합니다.
하지만 같은 배치 내에서 실행할 수 있는 또 다른 작업은 "_additionalCookAction(…)"을 호출합니다. Hacken이 지적했듯이, 해당 함수는 "가상"으로 선언되어 구현되지 않았기 때문에 기본적으로 needsSolvencyCheck 플래그를 포함하여 모든 것이 false로 설정된 빈 객체를 반환했습니다.
결과적으로 공격자는 대출 동작을 호출한 다음 플래그를 재설정하는 기본 동작을 호출했고, 결국 프로토콜은 지불능력을 검사하지 않았습니다.
분석가들은 공격자가 한 번에 6개의 Cauldron을 공격하여 약 179만 MIM을 빼돌려 이더리움(ETH) 로 교환했다고 밝혔습니다. 공격자들은 취약점을 악용하여 6개의 서로 다른 Cauldron을 체계적으로 검사하고 "전용 cook 함수 호출을 통해 동일한 기법"을 사용하여 각각을 소진시켰다고 분석가들은 설명했습니다.
공격자는 교환 후 암호화폐 혼합 프로토콜인 토네이도 캐시를 통해 자금을 전송했는데, 자금은 각각 10 이더리움(ETH) 로 구성되었으며 다음 날 점진적으로 전송되었습니다.
Abracadabra의 CauldronV4 코드가 문제에 연루된 것은 이번이 처음이 아닙니다. 올해 초 발생한 다른 사건들은 동일한 계약군 내에서 다른 예외 사례를 사용했습니다. 이제 흥미로운 점은 포크된 배포가 얼마나 빨리 반응했는가입니다.
보고서에 따르면 Synnax라는 포크(Fork) 는 Abracadabra 유출 사고가 발생하기 며칠 전에 자체 DegenBox에서 CauldronV4 마스터를 일시 중지하거나 허용 목록에서 제외했기 때문에 기본적으로 포크(Fork) 팀은 동일한 약한 패턴을 발견한 후 비상 브레이크를 당겼습니다. 이는 코드를 감시하는 팀에서 해당 위험이 눈에 띄었다는 것을 의미하며, 수정하지 않더라도 마찬가지입니다.
