검증되지 않은 새로운 dApp에 지갑을 연결할 때의 위험은 무엇입니까?

검증되지 않은 dApp에 대한 지갑 연결의 위험

1. 사용자가 검증되지 않은 분산 애플리케이션에 지갑을 연결할 때 범위를 완전히 이해하지 못한 채 광범위한 권한을 부여하는 경우가 많습니다. 많은 dApp은 무제한 토큰 승인을 요청하여 계약이 추가 동의 없이 자산을 반복적으로 인출할 수 있도록 합니다.

2. 악의적인 계약에는 연결 시 자동 전송을 트리거하는 논리가 포함될 수 있습니다. 특히 지갑에 전송 후크 또는 재진입 취약점이 있는 토큰이 있는 경우 더욱 그렇습니다. 이로 인해 사용자가 거래를 승인한 지 몇 초 만에 전체 잔액을 잃어버리는 수많은 사건이 발생했습니다.

3. 가짜 인터페이스는 합법적인 프로토콜을 모방하여 사용자를 속여 표준 연결 요청으로 위장한 피싱 페이로드에 서명하도록 합니다. 이러한 페이로드에는 "지갑 연결" 또는 "로그인"을 가장하여 임의 계약 호출을 승인하는 악의적인 서명 요청이 포함될 수 있습니다.

4. 일부 dApp은 최소한의 노드 인프라를 갖춘 모호한 EVM 호환 체인에 배포되어 전면 실행, 샌드위치 공격 또는 예상되는 상태 전환을 무효화하는 체인 재구성의 가능성을 높여 사용자가 소리 없는 자금 손실에 노출되도록 합니다.

5. MetaMask와 같은 지갑 확장은 서명 요청을 요청하기 전에 계약 바이트 코드 무결성을 확인하지 않습니다. 하이재킹된 CDN 호스팅 라이브러리와 같이 dApp의 프런트엔드에서 손상된 단일 종속성은 사용자의 브라우저 컨텍스트에 직접 악성 서명 논리를 주입할 수 있습니다.

토큰 승인 활용 패턴

1. 레거시 ERC-20 승인은 프로토콜 업그레이드 및 체인 마이그레이션 전반에 걸쳐 활성 상태로 유지됩니다. 공격자는 동일한 기능 선택기를 공유하는 새로 배포된 악성 계약에 대한 이전 승인을 재사용하여 이를 악용합니다.

2. 대리 계약에 부여된 승인은 사용자 통지 없이 기본 구현이 업그레이드될 수 있으므로 특히 위험합니다. 관리자 키를 제어하는 ​​공격자는 언제든지 로직을 교체하여 승인된 토큰을 배출할 수 있습니다.

3. 일부 dApp은 오프체인 허가 기반 승인을 사용하여 사용자가 EIP-712 메시지에 서명하도록 요구합니다. 도메인 구분 기호가 잘못 구성되었거나 메시지 구조가 모호한 경우 서명이 네트워크 전체에서 재생되거나 무단 전송을 위해 용도가 변경될 수 있습니다.

4. 승인 메시지가 표시되는 동안 지갑에 전체 ABI 인코딩 통화 데이터가 표시되는 경우는 거의 없습니다. 사용자는 승인이 진짜 토큰 주소를 대상으로 하는지, 아니면 유사한 체크섬 케이싱이나 유니코드 동형이의어 트릭을 사용하여 공격자가 배포한 유사 주소를 대상으로 하는지 확인할 수 없습니다.

프런트엔드 공급망 취약점

1. 개발자가 실수로 글로벌 범위에서 중요한 참조를 노출할 경우 npm 종속성을 통해 주입된 타사 분석 스크립트가 메모리 내 지갑 개체에서 개인 키를 유출하는 것이 관찰되었습니다.

2. dApp 빌더가 사용하는 손상된 UI 프레임워크에는 니모닉 입력 필드 중 키 입력을 캡처하는 숨겨진 이벤트 리스너가 포함되는 경우가 있습니다. 해당 필드가 CSS를 통해 비활성화되거나 숨겨지더라도 마찬가지입니다.

3. 브라우저 확장 충돌로 인해 지갑 제공업체가 서명 요청을 올바르게 가로채지 못하는 경쟁 조건이 발생하여 잘못된 매개변수나 nonce로 서명된 원시 거래 브로드캐스트가 발생합니다.

4. 축소되지 않은 JavaScript 번들에는 공격자가 악의적인 중계기를 통해 트래픽을 라우팅하는 동안 신뢰할 수 있는 백엔드 서비스를 시뮬레이션하기 위해 스크랩하고 용도를 ​​변경하는 하드코딩된 API 키, 지갑 주소 또는 테스트넷 자격 증명이 포함되는 경우가 많습니다.

네트워크 수준의 속임수 전술

1. 악성 RPC 엔드포인트는 위조된 블록체인 상태를 제공하여, 되돌릴 수 없는 작업을 시작하기 전에 가짜 토큰 잔액 또는 조작된 거래 확인을 표시하여 잘못된 신뢰를 유도합니다.

2. DNS 중독 공격은 공식 dApp 도메인을 방문하려는 사용자를 동일한 UI를 호스팅하지만 공격자가 제어하는 ​​스마트 계약을 가리키는 미러링된 사이트로 리디렉션합니다.

3. 중간자 프록시는 지갑과 dApp 사이의 WebSocket 연결을 가로채서 응답 페이로드를 변경하여 보류 중인 승인을 숨기거나 알려진 사기 계약 주소에 의해 트리거되는 경고 배너를 억제합니다.

4. dApp 온보딩 흐름과 함께 번들로 제공되는 테스트넷 수도꼭지는 때때로 합법적인 계약과 함께 악성 계약을 배포하여 사용자가 두 가지 모두와 상호 작용하도록 장려하여 메인넷에 공격적인 논리를 도입하기 전에 신뢰를 구축합니다.

자주 묻는 질문

Q: dApp이 거래에 서명하지 않고 지갑을 연결하는 것만으로도 자금을 훔칠 수 있나요? 답: 그렇습니다. 연결만으로는 자금이 이동되지 않지만 많은 dApp은 즉시 토큰 승인을 요청하거나 사용자의 지갑 컨텍스트를 사용하여 임의의 코드를 실행하는 위임자 호출 패턴을 호출합니다.

Q: 하드웨어 지갑을 사용하면 이러한 위험이 제거됩니까? A: 아니요. 하드웨어 지갑은 개인 키를 보호하지만 여전히 프런트엔드에서 요청한 거래에 서명합니다. dApp이 잘못된 정보를 표시하거나 사기성 통화 데이터를 구성하는 경우 하드웨어 장치는 지시에 따라 서명합니다.

Q: 오픈 소스 dApp은 자동으로 연결해도 안전합니까? 답: 반드시 그렇지는 않습니다. 공개 소스 코드는 배포 무결성을 보장하지 않습니다. 공격자는 정적 분석 도구를 우회하는 변경된 소유자 주소 또는 백도어 폴백 기능과 같은 미묘한 변경을 통해 감사된 계약의 수정된 버전을 자주 배포합니다.

Q: 일부 지갑 확장 프로그램에는 경고가 표시되는 반면 다른 확장 프로그램에는 경고가 표시되지 않는 이유는 무엇입니까? A: 경고 동작은 확장 공급자가 유지 관리하는 실시간 계약 주소 평판 데이터베이스에 따라 달라집니다. 이러한 데이터베이스는 새로운 배포보다 뒤떨어져 있으며 잘 알려지지 않은 체인이나 새로 체결된 계약에 대한 적용 범위가 부족한 경우가 많습니다.