Steakhouse cho biết sự cố bảo mật ngày 30/3 xuất phát từ việc kẻ tấn công chiếm quyền kiểm soát tên miền và DNS để dựng trang web giả mạo, trong khi các thành phần on-chain như vault và hợp đồng thông minh không bị xâm phạm.
Sự việc đáng chú ý vì nó cho thấy điểm yếu có thể nằm ở hạ tầng “ngoài chuỗi” như nhà đăng ký tên miền và quy trình hỗ trợ khách hàng, nơi một cuộc tấn công kỹ nghệ xã hội có thể vô hiệu hóa lớp bảo vệ như xác thực hai yếu tố.
- Kẻ tấn công dùng kỹ nghệ xã hội với bộ phận hỗ trợ của OVHcloud để vượt 2FA và nắm quyền DNS của Steakhouse.
- Trang web giả mạo có gắn công cụ rút ví (wallet drainer) xuất hiện gián đoạn khoảng 4 giờ, nhưng không ghi nhận thất thoát tiền và không có giao dịch độc hại được xác nhận.
- Steakhouse chuyển sang nhà đăng ký an toàn hơn, tăng giám sát DNS, xoay vòng thông tin xác thực và siết kiểm soát quản trị tên miền.
Sự cố ngày 30/3 đã xảy ra như thế nào?
Kẻ tấn công tạm thời chiếm quyền tên miền của Steakhouse để chuyển hướng người dùng sang trang lừa đảo, thay vì tấn công trực tiếp vào hệ thống on-chain.
Theo bản postmortem, nguyên nhân gốc là một cuộc tấn công kỹ nghệ xã hội nhắm vào nhà đăng ký tên miền OVHcloud. Từ đó, kẻ xấu có thể vượt qua xác thực hai yếu tố và kiểm soát các bản ghi DNS.
Khi DNS bị chiếm, kẻ tấn công dựng một bản sao trang web Steakhouse và nhúng cơ chế “wallet drainer”. Trang lừa đảo này hoạt động theo kiểu truy cập được không liên tục trong khoảng 4 giờ.
Vì sao kỹ nghệ xã hội lại dẫn đến chiếm toàn bộ tài khoản?
Kẻ tấn công giả mạo chủ tài khoản, thuyết phục nhân viên hỗ trợ của nhà đăng ký gỡ bỏ 2FA dạng phần cứng, từ đó mở đường cho việc tiếp quản tài khoản.
Báo cáo mô tả kẻ tấn công liên hệ bộ phận hỗ trợ, mạo danh chủ sở hữu tài khoản và khiến nhân viên đồng ý loại bỏ lớp xác thực hai yếu tố dựa trên phần cứng.
Sau khi có quyền truy cập, kẻ tấn công thực hiện nhanh một chuỗi thao tác tự động: xóa thông tin xác thực hiện có, đăng ký thiết bị xác thực mới, rồi chỉnh sửa DNS để trỏ về hạ tầng do chúng kiểm soát.
Người dùng có bị mất tiền không?
Steakhouse cho biết không có tiền của người dùng bị mất và không xác nhận được giao dịch độc hại, dù trang giả mạo đã từng hoạt động.
Phạm vi bị ảnh hưởng được mô tả là “tầng tên miền”. Các vault và hợp đồng thông minh vận hành tách biệt với giao diện web nên không bị tác động trực tiếp.
Giao thức cũng nhấn mạnh họ không nắm “admin keys” có thể truy cập tiền gửi của người dùng. Ngoài ra, ví trình duyệt như MetaMask và Phantom đã sớm gắn cờ trang lừa đảo.
Nhóm dự án cho biết họ đã đưa ra cảnh báo công khai trong vòng 30 phút kể từ khi phát hiện sự cố.
Sự cố nói gì về rủi ro từ nhà cung cấp và “điểm lỗi duy nhất”?
Postmortem cho thấy việc phụ thuộc vào một nhà đăng ký duy nhất, nơi quy trình hỗ trợ có thể ghi đè bảo vệ phần cứng, đã tạo ra “điểm lỗi duy nhất” trong hạ tầng.
Báo cáo nêu một giả định an ninh đã không đứng vững: cơ chế bảo vệ dựa trên khóa phần cứng vẫn có thể bị vô hiệu hóa qua kênh hỗ trợ nếu thiếu xác minh độc lập ngoài băng (out-of-band) đủ chặt.
Khả năng tắt 2FA chỉ bằng một cuộc gọi đã biến một rủi ro kiểu lộ thông tin/chiếm đoạt danh tính thành việc chiếm toàn bộ tài khoản quản trị tên miền.
Steakhouse thừa nhận họ đã chưa đánh giá đầy đủ rủi ro này và mô tả nhà đăng ký như một “single point of failure” trong hạ tầng.
Vì sao lỗ hổng off-chain vẫn là mắt xích yếu của bảo mật crypto?
Dù hợp đồng thông minh có thể an toàn, hạ tầng off-chain như DNS vẫn có thể bị lợi dụng để dẫn dụ người dùng vào bẫy lừa đảo, khiến rủi ro chuyển từ “hack on-chain” sang “đánh cắp qua giao diện”.
Sự cố nhấn mạnh một vấn đề phổ biến: lớp on-chain mạnh không tự động loại bỏ nguy cơ từ các thành phần bao quanh như tên miền, hosting, và quy trình vận hành.
Trong trường hợp này, quyền kiểm soát DNS giúp kẻ tấn công đổi đích đến của người truy cập sang trang giả mạo, nhắm vào hành vi ký giao dịch hoặc kết nối ví của người dùng.
Báo cáo cũng đề cập việc sử dụng công cụ có dấu hiệu tương đồng với mô hình “drainer-as-a-service”, cho thấy kẻ xấu kết hợp kỹ nghệ xã hội với bộ công cụ tấn công dựng sẵn.
Steakhouse đã thay đổi gì sau sự cố?
Sau vụ việc, Steakhouse chuyển sang nhà đăng ký bảo mật hơn, tăng giám sát DNS, thay đổi thông tin xác thực và siết kiểm soát quản trị tên miền.
Các bước được nêu gồm: triển khai giám sát DNS liên tục, xoay vòng (rotate) thông tin xác thực, và mở rộng rà soát về thực hành bảo mật của các nhà cung cấp.
Nhóm cũng áp dụng kiểm soát nghiêm ngặt hơn cho quản lý domain, bao gồm yêu cầu khóa phần cứng và kích hoạt các cơ chế khóa ở cấp nhà đăng ký (registrar-level locks).
Tổng kết
Sự cố ngày 30/3 của Steakhouse là ví dụ điển hình về rủi ro off-chain: chỉ cần chiếm DNS, kẻ tấn công có thể dựng trang lừa đảo dù hệ thống on-chain vẫn an toàn. Điểm cần theo dõi tiếp là hiệu quả của các biện pháp siết quản trị tên miền và quản trị rủi ro nhà cung cấp sau khi dự án đã chuyển đổi hạ tầng.
