Báo cáo sự cố từ Steakhouse tiết lộ vụ chiếm quyền điều khiển DNS do bỏ xác thực hai yếu tố của nhà đăng ký

ambcryptoXuất bản vào 2026-04-10Cập nhật gần nhất vào 2026-04-10

Tóm tắt

Báo cáo sự cố từ Steakhouse tiết lộ vụ tấn công chiếm quyền điều khiển DNS vào ngày 30/3, xuất phát từ hành vi giả mạo xã hội nhắm vào nhà đăng ký tên miền OVHcloud. Kẻ tấn công đã thuyết phục bộ phận hỗ trợ vô hiệu hóa xác thực hai lớp (2FA), từ đó chiếm quyền kiểm soát tài khoản và chuyển hướng DNS đến website giả mạo nhằm đánh cắp ví tiền điện tử. Mặc dù trang lừa đảo hoạt động trong khoảng 4 giờ, không có tài sản người dùng nào bị mất do hợp đồng thông minh và ví trên chuỗi không bị ảnh hưởng. Sự cố nhấn mạnh điểm yếu nghiêm trọng trong hạ tầng ngoài chuỗi, đặc biệt là rủi ro từ nhà cung cấp đơn lẻ và quy trình xác thực kém. Steakhouse đã chuyển sang nhà đăng ký mới, tăng cường giám sát DNS và áp dụng các biện pháp bảo mật bổ sung.

Báo cáo phân tích sự cố từ Steakhouse đã làm sáng tỏ vụ việc an ninh xảy ra vào ngày 30 tháng 3. Kẻ tấn công tạm thời chiếm quyền điều khiển tên miền để triển khai trang web lừa đảo, làm lộ ra điểm yếu nghiêm trọng trong cơ sở hạ tầng ngoài chuỗi thay vì hệ thống trên chuỗi.

Nhóm nghiên cứu xác nhận rằng cuộc tấn công bắt nguồn từ một nỗ lực tấn công kỹ thuật xã hội nhắm vào nhà đăng ký tên miền của họ, OVHcloud. Điều này cho phép kẻ tấn công bỏ qua xác thực hai yếu tố và giành quyền kiểm soát bản ghi DNS.

Tấn công kỹ thuật xã hội dẫn đến chiếm đoạt tài khoản toàn quyền

Theo báo cáo, kẻ tấn công đã liên hệ với bộ phận hỗ trợ của nhà đăng ký, mạo danh chủ tài khoản và thuyết phục nhân viên hỗ trợ gỡ bỏ xác thực hai yếu tố dựa trên phần cứng.

Khi được cấp quyền truy cập, kẻ tấn công nhanh chóng thực hiện một loạt hành động tự động. Điều này bao gồm xóa thông tin xác thực bảo mật hiện có, đăng ký thiết bị xác thực mới và chuyển hướng bản ghi DNS đến cơ sở hạ tầng do chúng kiểm soát.

Điều này cho phép triển khai một trang web Steakhouse sao chép có nhúng trình rút tiền ví, vẫn có thể truy cập không liên tục trong khoảng bốn giờ.

Trang web lừa đảo hoạt động, nhưng tiền vẫn an toàn

Bất chấp mức độ nghiêm trọng của vụ vi phạm, Steakhouse tuyên bố rằng không có khoản tiền nào của người dùng bị mất và không có giao dịch độc hại nào được xác nhận.

Sự xâm phạm chỉ giới hạn ở lớp tên miền. Các kho tiền trên chuỗi và hợp đồng thông minh, hoạt động độc lập với giao diện người dùng, không bị ảnh hưởng. Giao thức nhấn mạnh rằng họ không nắm giữ bất kỳ khóa quản trị nào có thể truy cập tiền gửi của người dùng.

Các biện pháp bảo vệ ví trình duyệt từ các nhà cung cấp như MetaMask và Phantom nhanh chóng đánh dấu trang web lừa đảo, trong khi nhóm nghiên cứu đưa ra cảnh báo công khai trong vòng 30 phút kể từ khi phát hiện sự cố.

Báo cáo phân tích nổi bật rủi ro nhà cung cấp và điểm yếu đơn lẻ

Báo cáo chỉ ra một điểm yếu quan trọng trong giả định bảo mật của Steakhouse: sự phụ thuộc vào một nhà đăng ký duy nhất mà quy trình hỗ trợ của họ có thể ghi đè các biện pháp bảo vệ dựa trên phần cứng.

Khả năng vô hiệu hóa xác thực hai yếu tố qua cuộc gọi điện thoại, mà không có xác minh ngoài luồng mạnh mẽ, đã biến rò rỉ thông tin đăng nhập thành chiếm đoạt tài khoản toàn quyền.

Steakhouse thừa nhận rằng họ đã không đánh giá đầy đủ rủi ro này, mô tả nhà đăng ký là "điểm yếu đơn lẻ" trong cơ sở hạ tầng của họ.

Lỗ hổng ngoài chuỗi vẫn là mắt xích yếu

Sự cố này nhấn mạnh một vấn đề rộng lớn hơn trong bảo mật tiền mã hóa — đó là các biện pháp bảo vệ mạnh mẽ trên chuỗi không loại bỏ rủi ro trong cơ sở hạ tầng xung quanh.

Mặc dù hợp đồng thông minh và kho tiền vẫn an toàn, quyền kiểm soát DNS cho phép kẻ tấn công nhắm mục tiêu người dùng thông qua lừa đảo, một phương pháp ngày càng phổ biến trong hệ sinh thái.

Cuộc tấn công cũng liên quan đến các công cụ phù hợp với hoạt động "dịch vụ rút tiền", làm nổi bật cách kẻ tấn công tiếp tục kết hợp kỹ thuật xã hội với bộ khai thác sẵn có.

Nâng cấp bảo mật và các bước tiếp theo

Sau sự cố, Steakhouse đã chuyển sang một nhà đăng ký an toàn hơn. Họ triển khai giám sát DNS liên tục, luân chuyển thông tin xác thực và tiến hành đánh giá rộng hơn về các phương pháp bảo mật của nhà cung cấp.

Nhóm nghiên cứu cũng giới thiệu các biện pháp kiểm soát chặt chẽ hơn cho quản lý tên miền, bao gồm thực thi khóa phần cứng và khóa cấp nhà đăng ký.


Tóm tắt cuối cùng

  • Báo cáo phân tích sự cố của Steakhouse tiết lộ rằng việc bỏ qua 2FA ở cấp nhà đăng ký đã cho phép chiếm quyền điều khiển DNS, khiến người dùng phải đối mặt với lừa đảo mặc dù hệ thống trên chuỗi an toàn.
  • Sự cố này làm nổi bật cách cơ sở hạ tầng ngoài chuỗi và bảo mật nhà cung cấp vẫn là lỗ hổng quan trọng trong hệ sinh thái tiền mã hóa.

Câu hỏi Liên quan

QSự cố bảo mật xảy ra với Steakhouse vào ngày nào và nguyên nhân gốc rễ là gì?

ASự cố xảy ra vào ngày 30 tháng 3. Nguyên nhân gốc rễ là một cuộc tấn công kỹ thuật xã hội thành công nhắm vào nhà đăng ký tên miền OVHcloud của họ, cho phép kẻ tấn công bỏ qua xác thực hai yếu tố (2FA) và chiếm quyền kiểm soát bản ghi DNS.

QKẻ tấn công đã vô hiệu hóa xác thực hai yếu tố (2FA) như thế nào?

AKẻ tấn công đã liên hệ với bộ phận hỗ trợ của nhà đăng ký, giả mạo chủ sở hữu tài khoản và thuyết phục một nhân viên hỗ trợ gỡ bỏ xác thực hai yếu tố dựa trên phần cứng.

QHậu quả của vụ tấn công này đối với người dùng và quỹ của họ là gì?

ARất may, không có quỹ nào của người dùng bị mất và không có giao dịch độc hại nào được xác nhận. Các khoản tiền gửi trên chain (on-chain vaults) và hợp đồng thông minh không bị ảnh hưởng vì chúng hoạt động độc lập với frontend.

QBài học chính về bảo mật mà Steakhouse rút ra từ sự cố này là gì?

ABài học chính là việc phụ thuộc vào một nhà đăng ký duy nhất có quy trình hỗ trợ có thể ghi đè các biện pháp bảo vệ phần cứng đã tạo ra một 'điểm hỏng đơn' (single point of failure). Họ nhận thấy rằng các lỗ hổng bảo mật off-chain (bên ngoài chuỗi) vẫn là mắt xích yếu.

QSteakhouse đã thực hiện những biện pháp nào để nâng cấp bảo mật sau sự cố?

AHọ đã chuyển sang một nhà đăng ký bảo mật hơn, triển khai giám sát DNS liên tục, luân chuyển thông tin xác thực, thực hiện kiểm tra chi tiết các phương thức bảo mật của nhà cung cấp, và áp dụng các biện pháp kiểm soát chặt chẽ hơn cho việc quản lý tên miền, bao gồm bắt buộc sử dụng khóa phần cứng và các khóa ở cấp nhà đăng ký.

Nội dung Liên quan

Tại sao Mỹ không có 'Huabei' và 'Jiebei'?

Tại sao Mỹ không có các sản phẩm cho vay tiêu dùng quy mô lớn như "Huabei" hay "Jiebei" của Trung Quốc? Bài viết phân tích những rào cản hệ thống khiến các nền tảng cho vay nhỏ lẻ kiểu này khó phát triển tại Mỹ. Dù có nhu cầu thực tế (khoảng 5,6 triệu hộ gia đình không có tài khoản ngân hàng và 19 triệu hộ thiếu dịch vụ ngân hàng), người dân thu nhập thấp thường phải dựa vào các khoản vay lãi suất cao (lên tới 400%/năm) hoặc dịch vụ "mua trước trả sau" (BNPL). Thẻ tín dụng thống trị thị trường với 1,28 nghìn tỷ USD dư nợ và lãi suất trung bình 22,3%, trở thành "khoản vay hợp pháp mang tính bóc lột lớn nhất nước Mỹ". Bốn rào cản chính ngăn chặn sự xuất hiện của các "Huabei" kiểu Mỹ là: 1) Hệ thống quy định chặt chẽ và phân mảnh (liên bang & tiểu bang) làm tăng chi phí tuân thủ; 2) Luật bảo vệ dữ liệu (như FCRA, CCPA) ngăn các công ty tech sử dụng dữ liệu người dùng cho mô hình xếp hạng tín dụng; 3) Áp lực từ thị trường vốn khiến công ty tech bị định giá thấp nếu kinh doanh dịch vụ tài chính; 4) Các ngân hàng lớn nắm quyền kiểm soát và định giá tín dụng, bảo vệ lợi ích của hệ thống hiện có. Kết quả là một hệ thống tài chính mà người nghèo phải trả lãi cao, còn các ngân hàng và người dùng trả đầy đủ thẻ tín dụng được hưởng lợi.

Odaily星球日报41 phút trước

Tại sao Mỹ không có 'Huabei' và 'Jiebei'?

Odaily星球日报41 phút trước

"Siêu thị mô hình" ngày càng nhiều: ByteDance, Alibaba, Tencent cạnh tranh tích hợp

Mô hình "siêu thị mô hình" đang trở thành xu hướng cạnh tranh của các gã khổng lồ công nghệ như ByteDance, Alibaba và Tencent. Cụ thể, ByteDance mới ra mắt Coding Plan với khả năng tích hợp nhiều mô hình AI hàng đầu như GLM-5.1, Minimax M2.7, Kimi k2.6 và DeepSeek-V3.2, cho phép nhà phát triển truy cập chỉ với một gói đăng ký từ 40-200 USD/tháng. Tuy nhiên, cộng đồng nhà phát triển phản ánh nhiều vấn đề như giới hạn sử dụng nhanh hết (chỉ 5 giờ), lỗi 429 do quá tải và độ trễ cao. Các gói dịch vụ cũng áp dụng hệ số khấu trừ khác nhau tùy mô hình, khiến chi phí thực tế không minh bạch. Các hãng cloud như Alibaba, Tencent và Baidu cũng đẩy mạnh mô hình tích hợp đa nền tảng, chuyển trọng tâm từ cạnh tranh mô hình đơn lẻ sang khả năng tích hợp và dịch vụ. Điều này đặt ra nguy cơ "ống dẫn hóa" (pipeline) cho các công ty mô hình độc lập, buộc họ tìm cách tự nâng cấp (như智谱 với autonomous agent) hoặc chuyên sâu vào lĩnh vực dọc. Dù vậy, các chuyên gia nhận định đây là sự phân công lại ngành, nơi công ty mô hình tập trung vào thuật toán, còn nền tảng đám mây đảm nhận triển khai. Cuộc cạnh tranh vẫn đang ở giai đoạn đầu và chưa thể kết luận ai sẽ thống trị.

marsbit43 phút trước

"Siêu thị mô hình" ngày càng nhiều: ByteDance, Alibaba, Tencent cạnh tranh tích hợp

marsbit43 phút trước

Giao dịch

Giao ngay
Hợp đồng Tương lai
活动图片