오소리가 판 스시 (Badgers digg sushi)
오소리들은 밤중에 먹이를 구하기 위해 항상 같은 경로로 이동하는 것으로 알려져 있습니다. 이것은 들판과 숲에 잘 닦인 길을 만들어냅니다.
만약 오소리가 평소에 다니던 길이 어떤 식으로 방해를 받거나 막히게 되면 오소리를 혼란스럽게 해서, 그들이 잘못된 짝으로 리베이싱되게 만듭니다.
저희는 한 경험 많은 DeFi 유저가 Badger DAO의 토큰인 DIGG을 통해 0.001 을 81.68 ETH 로 바꾼 거래를 확인했습니다.
더 깊게 조사를 해보니, 해킹이 있었으나 그 피해는 이미 발생했었고 전체 스시스왑 프로토콜의 위협으로 생각되었던 해킹은, 사실 똑똑한 도둑이 이미 도난당하고 남아있는 것을 주어갔을 뿐이라는 사실을 알 수 있었습니다.
이미 알려진 지갑은 스시스왑 팀의 관리 소홀로 다시 발생한 오래된 허점으로 이득을 취하고 있었습니다.
저희의 눈길을 끈 트랜잭션은 큰 문제가 될 수 있을 것으로 보였으나, 스시 팀과 얘기하고 난 이후에 크게 걱정해야 할 이유가 없어졌습니다.
트랜잭션은 SushiMaker가 아주 적은 유동성만 있는 DIGG/ETH 풀을 통해 0.05%의 DIGG/WBTC 스왑 수수료를 ETH로 변환하기 위해 시도하면서 높은 슬리피지를 감당할 수밖에 없었고, 그 때문에 DIGG/ETH 풀의 유동성 공급자들에게 비정상적으로 많은 수수료 보상이 주어졌던 것입니다.
이 수수료들은 XSUSHI 보유자들에게 지불되어야했지만, 전부 공격자에게 지불되었습니다.
이런 일이 어떻게 발생했을까요?
해결책은 몇 주 전부터 완성이 되었었지만, 새로운 풀마다 일일이 적용했어야 했습니다. 이 해결책이 적용되지 않았기 때문에 도둑은 몰래 숨어 들어서 xSushi 보유자들에게 지불되었어야할 수수료를 가로챌 수 있었습니다.
스시스왑의 Onsen에 새로운 페어들이 등록될 때, 일부 ETH 페어가 아닌 것들이 등록되었으나, SushiMaker의 DIGG/WBTC의 경우 "브릿지"가 만들어지지 않았습니다.
SushiMaker는 0.05%의 거래 수수료를 받아 비영구적인 손실 없이, 추가 SUSHI를 얻기 위해 SUSHI를 스테이킹해서 xSUSHI를 받은 유저들에게 수수료를 지불하는 컨트랙트입니다.
기본 설정으로 SushiMaker는 모인 수수료 (그리고 그들의 페어)를 ETH를 받고 팔고 다시 SUSHI를 매수합니다.
브릿지가 의미하는 바는, SushiMaker가 ETH 페어가 없는 자산을 매도할 때, 적절한 유동성을 가진 ETH가 아닌 다른 자산으로도 가능함을 의미합니다.
브릿지가 없다면, SushiMaker가 수수료를 해당 자산으로 바꾸기 위해 시도할 ETH 페어를 만들어 유동성을 제공할 수 있고, 이는 총 유동성이 적기 때문에 가격에 큰 영향을 끼치게 될 것입니다.
이것은 xSUSHI 참여자들에게 보상으로 지불되기 위해 SushiMaker "serving" 에 모아뒀던 수수료가 해당 ETH 페어의 유동성 제공자에게 지불되는 결과를 낳고 말았습니다.
다행스럽게도, 연관된 LP나 xSUSHI 포지션에는 영향을 미치지 않았고, 단지 영향 받은 자산의 이전에 모아뒀던 수수료(DIGG/WBTC 스왑 시 발생하는 0.05% 수수료 - 81 ETH) 만 도난당했습니다.
xSUSHI 보유자들에게 발생한 이슈를 해결하기 위해서 maker 컨트랙트를 통해 DIGG를 위한 브릿지가 생성되었습니다. 이 브릿지는 SushiMaker에도 포함되어 있습니다.
스시스왑 디스코드에서 나눈 대화를 통해 이번 해킹 과정에 대한 인사이트를 얻을 수 있었습니다:
저희가 도둑의 주소를 분석해본 결과, 그는 이미 봇과 플래시 론을 사용하는 알려진 유저라는 사실을 확인할 수 있었습니다.
Nansen으로 부터 얻은 데이터
저희는 이 도둑이 허점을 활용하여 LP 수수료를 훔쳐가려고 시도한 여러 트랜잭션들을 찾아낼 수 있었습니다.
0x90fb0c9976361f537330a5617a404045ffb3fef5972cf67b531386014eeae7a9
0x0af5a6d2d8b49f68dcfd4599a0e767450e76e08a5aeba9b3d534a604d308e60b
0xcec93808a657d00cbb0245711e9419d0ea278b3a60a9a6d0a8c3353523c0e982
0xe0527f7befaea54257113a09c8b3f4cd416e11a0e196cd2ba2e5e07c47767ddf
재앙이 될 수 있었던 이번 사건은, 스시 팀에게 약간의 굴욕으로 남았습니다.
공격자가 성공적으로 해킹할 수는 있었지만, 현재 19억 달러의 TVL을 보호해야할 스시스왑에게는 간 떨리는 순간이었습니다.
걱정스러운 부분은, 디스코드의 대화에 의하면 그들은 해당 수정사항은 자동화하지 않을 것이며 앞으로도 기억에 의존하여서 각각 적용할 것이라고 밝혔다는 점입니다.
왜 필수적이지 않은 곳에서 인간적인 실수를 할 수 있는 여지를 남겨두는 것일까요?
코드는 탈중앙화 되어있지만, 이처럼 큰 TVL을 가진 프로토콜에서 일하는 개발자들은 엄청난 책임감을 안고 일하고 있습니다. 하지만 이를 통해 발생하는 스트레스가 미치는 영향은 자주 저평가되어 "번 아웃"에 빠지는 개발자들을 주변에서 많이 볼 수 있습니다. 코딩하면서 잘못될 가능성은 매우 많기 때문에, 스시스왑은 자동화의 이점을 살리는 것이 좋을 것 같습니다.
이 이야기에서 얻을 수 있는 교훈은, 해커나 차익거래자들이 일부 자금을 훔치거나 아니면 프로젝트가 망가질 정도로 완전히 훔치기 위해 프로토콜의 일거수일투족을 항상 관찰하고 있다는 것입니다.
그러나 이것은 또 다른 시사점을 제공합니다 - 트위터 유저 “simp2win” 와 같은 아마추어도 저 멀리서 해커들을 관찰할 수 있다는 것입니다. 그들의 노력은 칭찬받을만하지만, 분석은 전문가들에게 맡기는 것이 더 나아보입니다.
저희는 뭔가 말하고 싶은 해커들을 항상 환영하며, Ethereum call data를 통해 메세지를 주실 것을 기대합니다.
내가 1000만 달러를 벌었다고 얘기하는 트위터의 simp2win은 누구인가요? ㅋㅋㅋ 그랬었으면 좋겠네요
REKT는 익명 작성자들에 의한 공공 플랫폼이며, REKT에 작성된 관점이나 내용에 대해서 그 어떤 책임도 지지 않습니다.
기부 (ETH / ERC20): 0x3C5c2F4bCeC51a36494682f91Dbc6cA7c63B514C
disclaimer:
REKT는 당사 웹 사이트의 익명의 작성자 또는 REKT에 의해 게시되거나 관련된 서비스에서 게시되는 콘텐츠에 대해 어떠한 책임도 지지 않습니다. 당사는 익명 작성자들의 행동 및 게시물에 대한 규칙을 제공하지만, 익명의 작성자가 웹 사이트 또는 서비스에 게시, 전송 혹은 공유한 내용을 통제하거나 책임지지 않으며, 귀하가 웹 사이트 또는 서비스에서 직면할 수 있는 불쾌함, 부적절함, 음란함, 불법 또는 기타 해로운 콘텐츠에 대해서도 책임을 지지 않습니다. REKT는 당사 웹 사이트 또는 서비스 사용자의 온라인 또는 오프라인 행위에 대한 책임을 지지 않습니다.