
편집자 주: 이 기사의 출처는배빗 정보 (ID: bitcoin8btc)편집자 주: 이 기사의 출처는
배빗 정보 (ID: bitcoin8btc)
배빗 정보 (ID: bitcoin8btc)
, 저자: rekt, 컴파일러: 무료 및 간편함, 승인을 받아 출시됨.
참고: 이번주 토요일 DeFi 프로토콜 Pickle Finance는 Jar 전략의 허점으로 인해 2천만 달러에 해킹당했습니다. 의정서에서 미화 5천만 달러가 구조되었고, 저자 Rekt는 사건을 요약했습니다.
재정적 발효가 계속되고 피클도 유통 기한이 있습니다.
Pickle Finance는 가짜 "Pickle jar" 취약점으로 인해 1,970만 DAI를 해킹당했습니다.
Pickle Finance는 최근 해킹 대유행의 희생자가 되었습니다.
그런데 이번에는 뭔가 다르다...
트위터 사람들이 또 다른 재정적 재난을 받아들이려고 하자 Rekt는 조사를 시작했습니다.
코드를 검토한 Stake Capital 팀에 연락하여 다른 피클 병이 위험할 수 있다고 경고했습니다.
우리는 신속하게 Pickle Finance 팀에 연락하여 Sketch Capital 구성원(@bneiluj, @vasa_developer)과 숙련된 개발자 @samczsun, @emilianobonassi 간의 전쟁실을 마련했습니다.
조사 후 최근 몇 주 동안 발생한 DeFi LEGO 스타일 해킹과는 매우 다른 것을 보고 있다는 것이 분명해졌습니다.
이것은 차익 거래가 아닙니다.
공격자는 Solidity와 EVM에 대해 잘 알고 있으며, 이 취약점은 한 달 전 Yearn에서 발견된 취약점과 유사하기 때문에 한동안 Yearn 코드에 세심한 주의를 기울였을 수 있습니다.
본질적으로 Pickle Jar는 Yearn yVaults의 포크이며 이러한 Jars는 Controller라는 계약에 의해 제어되며 사용자가 Jar 간에 자산을 교환할 수 있는 기능이 있습니다.
안타깝게도 Pickle에는 Jar가 이 스왑을 사용할 수 있는 화이트리스트가 없습니다.
해커는 가짜 Pickle Jar를 만들고 원래 Jar에서 자금을 교환했습니다. 이는 swapExactJarForJar가 "허용 목록에 있는" jar를 확인하지 않기 때문에 가능합니다.
Pickle Finance 팀은 도움이 필요하다는 것을 알았고 추가 피해를 방지하기 위해 기꺼이 다른 사람들과 협력했습니다.
Pickle은 "withdrawAll" 함수를 호출하려 했지만 트랜잭션이 실패했습니다.
이 출금 요청은 12시간 제한이 있는 거버넌스 DAO를 거쳐야 합니다.
Pickle 다중서명 그룹의 구성원만이 잠자는 동안 이 타임락을 우회할 수 있었습니다.
이것은 관리자가 Pickle Jar를 비울 수는 없지만 다른 해킹으로부터 관리자를 보호하지 못한다는 것을 의미합니다.
이어 Pickle Finance와 Curve는 사용자에게 Pickle에서 즉시 자금을 인출할 것을 경고했지만 잠재적으로 취약한 Pickle 항아리에 5천만 달러가 남아 있었고 White Hat 팀은 위반을 조사하고 나머지 자금의 안전을 확인했습니다.
구조팀은 잠자는 관리자를 깨우거나 항아리 자체를 비워야 합니다.
분대는 5가지 주요 과제를 극복해야 했습니다.
Pickle Finance 팀이 자금을 인출하기 위해 (6개의 멀티시그 중 3개를 통해) 거래를 12시간 타임록으로 푸시하여 자금을 구조하기 위해 여러 시간대에 걸쳐 함께 모이도록 합니다.
수천 명의 투자자가 자금을 인출할 수 있도록 합니다(풀 TVL이 떨어지고 APY가 1000% 이상으로 급증할 때 재투자를 방지).
다른 병에 대한 보안 검사를 수행하여 더 많은 공격이 발생할 수 있는지 확인하십시오.
누군가가 이 항아리를 다시 공격하기 전에 공격을 복제하고 자금을 이동하십시오.
나머지 5,000만 달러의 자금을 회수하려고 시도하는 동안 선행 실행을 피하십시오.
공격자는 보호자보다 그들의 동기가 분명히 더 일치하는데 화이트 햇 해커는 왜 그렇게 힘든 반격을 조율할까요?
분석하다
신용이 흰 모자에게 가고 돈이 해커에게 가는 것은 지속 가능하지 않습니다.
이 흰 모자가 검게 변하는 데 얼마나 걸립니까?
분석하다
아래 다이어그램은 @vasa_develop에 의해 생성되었습니다.여기일어나.
원본 파일은 다음에서 찾을 수 있습니다.여기。
자세한 내용은 공식을 참조하십시오여기조사 보고서
상대적으로 신생 보험 프로토콜인 커버 프로토콜이 첫 번째 클레임치고는 어마어마한 금액인 이번 사건을 어떻게 처리할지 귀추가 주목된다. 당신은 할 수 있습니다
여기
절임 피클은 느린 과정입니다.
DeFi에서 빠르게 실패하면 엄청난 비용이 듭니다.
수십 년 동안 "애자일 개발" 옹호자들은 개발자들에게 빨리 움직이고, 빨리 실패하고, 최소한의 실행 가능한 제품을 출시하라고 말해왔습니다.
이러한 아이디어는 적대적인 환경에서 구축하기에 적합하지 않습니다.
DeFi에서 빠르게 실패하면 엄청난 비용이 듭니다.
우리는 다른 접근 방식이 필요하지 않습니다. 공격을 받을 가능성을 줄이면서 빠른 반복을 허용하는 패러다임 전환이 필요합니다.
"감사가 있고 보안이 있다"는 생각을 멈추자. 대부분은 종종 다른 것으로 진화하는 이동 대상에 적용되는 체크리스트 스타일의 보안 조치의 스냅샷이다.
MixBytes(10월 3일) 및 Haechi(10월 20일)에 대한 감사는 이 공격의 핵심 벡터 중 하나인 ControllerV4(10월 23일) 추가 전에 완료되었습니다.