개발자가 프론트엔드 월렛 드레인 공격을 방지하는 방법: BONK.fun 해킹 사례 연구

Source: Dev.to

Incident Summary

악성 코드가 배포된 후 웹사이트와 상호작용하고 서명 요청을 승인한 사용자만 영향을 받았습니다.

Attack Sequence

1. 공격자가 내부 팀 계정을 탈취했습니다.
2. 악성 코드가 웹사이트에 배포되었습니다.
3. 가짜 서비스 약관 서명 프롬프트가 표시되었습니다.
4. 사용자가 승인 / 서명을 클릭했습니다.
5. 악성 스크립트가 실행되어 지갑 권한을 악용했습니다.
6. 토큰이 공격자 소유 지갑으로 전송되었습니다.

Example of a Malicious Script

// Example: how a malicious script could drain funds
const connection = new solanaWeb3.Connection(/* RPC endpoint */);
const attackerWallet = new solanaWeb3.PublicKey(/* attacker address */);

const transaction = new solanaWeb3.Transaction().add(
  solanaWeb3.SystemProgram.transfer({
    fromPubkey: wallet.publicKey,
    toPubkey: attackerWallet,
    lamports: /* amount to steal */
  })
);

const signedTx = await wallet.signTransaction(transaction);
const txid = await connection.sendRawTransaction(signedTx.serialize());

console.log("Funds transferred:", txid);

사용자가 트랜잭션에 서명하면 지갑이 전송을 승인하고, 공격자는 자산을 탈취할 수 있습니다.

Root Causes

1. Compromised Developer Account

   • 인증 정보 피싱, 약한 비밀번호, 도난당한 API 키, 다중 인증(MFA) 부재.

2. Unprotected Deployment Pipeline

   • 커밋 서명 검증 누락, 빌드 검증 부족, 릴리즈 승인 절차 미비.

3. Lack of Frontend Integrity Protection

   • Subresource Integrity(SRI) 또는 엄격한 Content Security Policy(CSP) 미적용.

4. Unsafe Wallet Signature UX

   • 거래 세부 정보를 숨기는 모호한 프롬프트.

Secure Architecture for Web3 Platforms

1. Enforce Multi‑Factor Authentication

• 모든 특권 계정에 하드웨어 보안 키, FIDO2 인증 또는 패스키 기반 로그인을 사용합니다.

2. Secure CI/CD Pipelines

• 사용자 계정에서 직접 배포하는 것을 금지합니다.

• 예시 파이프라인:

  GitHub → CI Pipeline → Static Analysis → Security Scan → Production

• 의존성 스캔, 악성 코드 탐지, 무단 커밋 알림 등 보안 검사를 포함합니다.

3. Use Subresource Integrity (SRI)

• 외부 스크립트에 무결성 속성을 추가해 브라우저가 실행 전에 스크립트 해시를 검증하도록 합니다.

4. Implement a Strict Content Security Policy

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; connect-src https://api.example.com;

5. Improve Wallet Signature Transparency

• 사용자가 서명하기 전에 수신자, 금액, 목적 등 명확한 거래 정보를 표시합니다.

6. Detect Suspicious On‑Chain Activity

if (tx.type !== "expected_action") {
  // reject unexpected transaction types
}
if (tx.amount > MAX_ALLOWED_LIMIT) {
  // flag unusually large transfers
  return true;
}

프론트엔드에서 직접 생성된 검증되지 않은 트랜잭션은 절대 허용하지 마세요.

Conclusion

이번 사건은 Web3 보안이 스마트 계약을 훨씬 넘어선다는 것을 보여줍니다. 블록체인 자체가 안전하더라도, 공격자는 프론트엔드 인프라, 개발자 계정, 지갑 상호작용 흐름을 악용해 자금을 탈취할 수 있습니다. 유사 사건을 방지하려면 Web3 팀이 안전한 DevOps 관행을 채택하고, 프론트엔드 인프라를 강화하며, 투명한 지갑 상호작용 경험을 설계해야 합니다.