Trong những năm gần đây, ví cứng được coi là một trong những phương thức lưu trữ khóa riêng tương đối an toàn trong ngành công nghiệp blockchain. Sau khi khóa riêng được tạo ra, nó sẽ được lưu trữ trong chip an toàn (Secure Element) của ví cứng, chỉ được sử dụng để ký thông tin từ bên ngoài. Thiết kế phần cứng kín không thể kết nối mạng này, kết hợp với cơ chế phần mềm cấm xuất khẩu khóa riêng, đã xây dựng một rào cản bảo vệ mạnh mẽ.
Tuy nhiên, kiến trúc an ninh này cũng có "điểm yếu" của nó - ví phần cứng phụ thuộc rất nhiều vào phần mềm khách hàng bên ngoài và các kênh truyền thông. Một khi những yếu tố bên ngoài này bị can thiệp, kẻ tấn công có thể thực hiện "tấn công trung gian" (MITM), thay thế thông tin mà người dùng không hề hay biết, dẫn đến mất mát tài sản.
Trung gian tấn công là gì
Tấn công trung gian là chỉ hành động của kẻ tấn công can thiệp một cách bí mật vào giữa hai bên giao tiếp, chặn, sửa đổi hoặc làm giả nội dung giao tiếp giữa hai bên, trong khi hai bên giao tiếp đều nghĩ rằng họ đang tương tác trực tiếp.
Loại tấn công này thường gặp trong các tình huống như giám sát mạng, giả mạo dữ liệu, đánh cắp danh tính và thay thế địa chỉ. Trong lĩnh vực tài sản mã hóa, điều này đặc biệt nguy hiểm, vì kẻ tấn công chỉ cần thay thế một địa chỉ có thể gây ra tổn thất tài sản lớn.
Một ví dụ trong cuộc sống: Bạn gửi cho bạn bè một bức thư quan trọng. Một "người đưa thư xấu" đã chặn bức thư trên đường đi, thay đổi nội dung bức thư, sau đó đóng lại và gửi đi. Khi bạn bè nhận được bức thư, thông tin mà họ nhận được đã không còn chính xác nữa vì bị người đưa thư thay thế.
Trong ví dụ này, người đưa thư đóng vai trò là trung gian, thực hiện cuộc tấn công trung gian bằng cách thay thế nội dung bức thư.
Trong hệ thống blockchain, do hầu hết các giao dịch trên chuỗi công cộng chỉ cần địa chỉ nhận tiền mà không cần xác thực thêm như tên. Trong những tình huống này, các cuộc tấn công trung gian dễ dàng thành công hơn, và thiệt hại thường lớn hơn, khó phục hồi hơn.
Quy trình giao tiếp ví cứng: Người đưa thư vô hình
Các loại ví cứng phổ biến trên thị trường chủ yếu sử dụng bốn phương thức giao tiếp:
USB: Phổ biến nhất và ổn định, thực hiện truyền dữ liệu hai chiều qua cáp.
Bluetooth: Bluetooth Low Energy BLE, thường được sử dụng trên thiết bị di động
Mã QR: airgap, một phương pháp tương đối mới, cách ly vật lý, đạt được mục đích giao tiếp thông qua việc quét mã qua lại.
NFC：Giao tiếp trường gần, hiện tại ít được sử dụng hơn.
Trong đó, USB và Bluetooth là phổ biến nhất. Dù sử dụng phương thức nào, quy trình giao tiếp về cơ bản là giống nhau:
"Ví điện tử" khởi xướng kết nối, chẳng hạn như ví tiện ích mở rộng trình duyệt hoặc ví ứng dụng di động.
Gửi yêu cầu đến "ví cứng", chẳng hạn như lấy địa chỉ bên trong của ví cứng, khởi xướng ký kết, v.v.
Yêu cầu gửi đến thiết bị phần cứng qua "kênh truyền thông" đã nêu trên
Thiết bị hoàn thành xử lý và trả về phản hồi
"Ví" nhận và hiển thị kết quả
Mặc dù ví phần cứng tự nó là "kho chứa" an toàn, nhưng quá trình giao tiếp lại phụ thuộc vào khách hàng và kênh giao tiếp, tức là "chuỗi người chuyển phát". Một khi "người chuyển phát" bị khống chế hoặc làm hại, thông tin dữ liệu được truyền đi có thể đã bị thay đổi từ lâu.
Đây chính là mối đe dọa bí mật của "Thanh kiếm Damocles" treo lơ lửng trên ví cứng - - Tấn công trung gian.
Trường hợp thực tiễn: Tấn công người trung gian dựa trên kịch bản độc hại
Tuyên bố
Tất cả mã và hoạt động đều diễn ra vào tháng 9 năm 2023, đã hơn 20 tháng kể từ thời điểm bài viết này được công bố (tháng 6 năm 2025).
Tất cả các buổi trình diễn dựa trên phiên bản phần mềm chính thức công khai vào thời điểm đó, thông tin phiên bản cụ thể đã được chỉ ra trong văn bản.
Các phương thức tấn công liên quan đã được tiết lộ và xác nhận với các nhóm liên quan vào thời điểm đó.
Tất cả nội dung trong bài viết này chỉ dành cho việc học tập và nghiên cứu an toàn, quan điểm chỉ đại diện cho tác giả.
Bài viết này không chịu trách nhiệm cho bất kỳ hành động hoặc hậu quả nào phát sinh từ đây.
Quy trình giao tiếp cơ bản của Trezor
Trezor có thể chọn giao tiếp thông qua Trezor Bridge khi kết nối ví trình duyệt Metamask qua USB, quy trình cơ bản của Trezor Bridge.
Sau khi cài đặt phần mềm, một máy chủ HTTP sẽ được khởi động trên cổng 21325 trên máy tính của người dùng.
Khi Metamask kết nối với ví cứng Trezor, nó sẽ tải JS SDK thông qua một trang web bật lên.
SDK của Trezor sẽ cố gắng gửi dữ liệu được tuần tự hóa dựa trên protobuf đến máy chủ cục bộ này.
Sau khi Trezor Bridge nhận được dữ liệu, nó sẽ tìm kiếm các thiết bị Trezor PID VID thỏa mãn điều kiện trong máy tính địa phương thông qua thư viện lib-usb và truyền dữ liệu.
Khi phát hiện Trezor Bridge đã được cài đặt trên máy, tất cả dữ liệu tuần tự qua trang web, tức là Trezor SDK, sẽ được chuyển tiếp đến thiết bị qua máy chủ Trezor Bridge cục bộ, mà không sử dụng Web USB.
Thông tin cơ bản về Trezor Bridge
Trezor Bridge được phát triển bằng Golang, phiên bản người dùng hiện tại là v2.0.27.
Từ kho lưu trữ mã nguồn mở trên GitHub có thể thấy, v2.0.27 sử dụng xgo để biên dịch đa nền tảng, từ đó tạo ra gói cài đặt cho MacOS, Windows và Linux.
Lấy ví dụ về MacOS, trong quá trình cài đặt sẽ tạo ra tệp nhị phân máy chủ trezord tại thư mục /Applications/Utilities/TREZOR\ Bridge/trezord, và tạo ra tệp com.bitcointrezor.trezorBridge.trezord.plist trên máy tính của người dùng, thông qua KeepAlive để thực hiện khởi động tự động khi mở máy và giám sát tiến trình.
Quy trình cơ bản của cuộc tấn công
Khi kết nối thiết bị Trezor với Metamask, thiết bị sẽ ngay lập tức đọc khóa công khai ETH bên trong, sau đó dựa trên số thứ tự địa chỉ phát sinh để tính toán các địa chỉ theo các đường dẫn khác nhau trong ứng dụng Metamask.
Trong quá trình này, không có bất kỳ xác nhận hoặc thông báo phần cứng nào, điều này cũng cung cấp một con đường khả thi cho một cuộc tấn công trung gian đơn giản.
Khi Trezor Bridge bị phần mềm độc hại cục bộ kiểm soát, sẽ xuất hiện một "người đưa thư xấu" trên toàn bộ liên kết giao tiếp. Kẻ tấn công có thể biến nó thành một máy chủ trung gian, đánh cắp tất cả dữ liệu giao tiếp với ví phần cứng. Do đó, dữ liệu gửi đến ví phần cứng và dữ liệu trả về từ ví phần cứng có thể bị thay đổi, dẫn đến việc thông tin hiển thị trên giao diện không nhất quán với thông tin thực tế của phần cứng. Một khi quy trình phần mềm có lỗ hổng hoặc thông tin trên phần cứng không được xác nhận nghiêm túc, cuộc tấn công trung gian có thể thành công.
Kiểm tra tấn công
Đầu tiên cài đặt Trezor Suite v23.8.1, Trezor Bridge v2.0.27 và Metamask v11.0.0
Chuẩn bị hai chiếc Trezor Model T: một chiếc hoạt động theo quy trình bình thường, chiếc còn lại dùng để kiểm tra tấn công trung gian.
Đầu tiên hiển thị quy trình bình thường: Hai thiết bị đều có thể đọc địa chỉ đúng trong Trezor Suite và Metamask
Thực thi kịch bản độc hại thay thế tiến trình trezord
Thiết bị đầu tiên vẫn có thể đọc chính xác địa chỉ trong Metamask, quy trình diễn ra bình thường.
Địa chỉ được thiết bị thứ hai đọc trong Metamask đã bị người trung gian thay thế, không khớp với địa chỉ hiển thị trên Trezor Suite và phần cứng.
Phân tích mã
Thêm đánh dấu nhật ký ở vị trí quan trọng của Trezor Bridge, ghi lại dữ liệu yêu cầu và phản hồi trong quá trình giao tiếp thiết bị:
Trong giai đoạn đọc khóa công khai của SDK, hexbodyStr và hexres hoàn toàn giống nhau về tham số thao tác và kết quả trả về vào những thời điểm khác nhau khi gọi nhiều lần trên cùng một thiết bị. Qua việc lọc nhật ký, phát hiện dữ liệu gọi hàm khi Metamask đọc địa chỉ ETH như sau:
Theo so sánh nhật ký,
003700000000 và 000b0000001f08ac8080800808bc80808008088080808008080008002207426974636f696e đều là kết quả tuần tự hóa của các thông điệp gửi và nhận.
Thông qua kiểm tra phát lại, trong quá trình xây dựng thông tin không có tham số như dấu thời gian, có thể rất dễ dàng mô phỏng các phương pháp tấn công, tức là nhắm vào một phần thông điệp đã gửi, mã cứng kết quả trả về và thay thế kết quả.
Trong ví dụ này, chúng tôi đã thay thế dữ liệu một cách có mục tiêu. Khi nhận được yêu cầu SDK lấy khóa công ETH, chúng tôi không còn sử dụng kết quả trả về từ phần cứng nữa, mà trực tiếp sử dụng kết quả được mã hóa cứng trong mã trên. Sau khi biên dịch lại qua tài liệu, tạo ra tệp nhị phân, đồng thời tạo ra các thành phần cần thiết cho các cuộc tấn công như daemon.
Sau khi công việc chuẩn bị hoàn tất, khi người dùng vô tình cài đặt và chạy phần mềm độc hại. Mỗi khi người dùng sử dụng Metamask để kết nối với Trezor và gửi dữ liệu, dữ liệu truyền thông qua bridge không còn là thông tin được đọc từ phần cứng nữa, mà là dữ liệu đã được tuần tự hóa cứng trong mã trên, và dựa trên việc giải tuần tự hóa của SDK kinh doanh, thông tin địa chỉ được đọc tức là đã thành công trong việc thay thế. Cuộc tấn công hoàn chỉnh như video trên đã chỉ ra.
Giao tiếp với đội ngũ
Sau khi sắp xếp các vấn đề và thao tác, tôi đã ngay lập tức liên lạc với đội ngũ Metamask và Trezor, dưới đây là tất cả thông tin liên lạc và email.
Hồ sơ giao tiếp Metamask:
Thông tin liên lạc qua email Trezor:
Cốt lõi của vấn đề và đề xuất
Metamask đọc địa chỉ đầy đủ, không cần xác nhận phần cứng
Phần cứng có thể được coi là một môi trường an toàn khép kín, vì vậy tất cả thông tin nên được căn cứ vào phần cứng. Tuy nhiên, trong quy trình thiết kế sản phẩm của Metamask, thông tin địa chỉ đầy đủ dưới dạng văn bản rõ ràng được đọc và hiển thị trực tiếp mà không có bất kỳ hiển thị nào từ phần cứng.
Phương pháp ethereumGetAddress của Trezor SDK cung cấp tham số showOnTrezor, có tác dụng là đọc địa chỉ của phần cứng và hiển thị trên phần cứng để người dùng xác nhận lần hai.
Đây là một vấn đề về sự lựa chọn trong thiết kế sản phẩm, nếu mỗi lần đều cần người dùng xác nhận mới có thể đọc địa chỉ, thì trong các tình huống thêm địa chỉ hàng loạt, người dùng sẽ rất khổ sở. Do đó, trong các ứng dụng hỗ trợ ví phần cứng phổ biến, đồng thời hỗ trợ đọc địa chỉ một cách lặng lẽ, nhưng nếu muốn nhận tài sản, đều cần phải thực hiện xác nhận phần cứng địa chỉ trước, nhằm ngăn chặn việc xuất hiện các tình huống tấn công như trên.
Metamask đã đọc địa chỉ một cách lặng lẽ mà không yêu cầu người dùng xác nhận, ngay lập tức hiển thị địa chỉ đầy đủ, điều này khiến người dùng lần đầu sử dụng dễ bị tấn công.
Mối đe dọa của chữ ký mù có thể lớn hơn chúng ta tưởng tượng.
Theo phương pháp và cách tấn công này, chúng ta có thể kết luận rằng: tất cả thông tin phần cứng không xác định đều lý thuyết là không an toàn.
Tất cả các chữ ký mù đều tương tự, mặc dù phần cứng chữ ký mù có xác nhận, nhưng thông tin xác nhận này thì người dùng không thể đọc được, vì vậy nó cũng thỏa mãn thông tin không xác định của phần cứng, không thể đảm bảo không bị tấn công bởi bên trung gian.
Vụ việc của ví đa chữ ký safe là một ví dụ điển hình, thông tin chữ ký được cấu trúc của ví bị mã độc javascript trên máy chủ thay thế, đồng thời vì ví ledger là chữ ký mù, dẫn đến việc xảy ra cuộc tấn công này.
Cuộc tấn công trung gian vào kênh giao tiếp, có nhiều hình thức
Ngoài việc người dùng có phần mềm độc hại trên máy tính của họ, một số quy trình giao tiếp và xây dựng của ví có thể liên quan đến máy chủ (ví dụ như một số ví encodeTx cần phải được xây dựng qua máy chủ). Đây đều là những mục tiêu tấn công tiềm ẩn và điểm bị tấn công.
Kênh truyền thông chắc chắn còn bao gồm cả mặt phần cứng, chẳng hạn như thiết bị webcam không an toàn, cáp USB không an toàn, v.v. Từ tầng vật lý đến tầng ứng dụng, ở cấp độ truyền thông, tất cả các khâu đều có khả năng bị tấn công.
Tăng cường nhận thức về an ninh, nhiệm vụ nặng nề và còn dài phía trước
Giao tiếp hoàn chỉnh từ khách hàng đến ví phần cứng về lý thuyết là không cần kết nối Internet. Vì vậy, ngay cả khi có giao tiếp mã hóa đầu cuối, cũng không thể đảm bảo 100% an toàn cho quy trình.
Sau khi tăng cường mã hóa đầu cuối, điều tăng lên chỉ là chi phí phá vỡ kênh giao tiếp đối với những hacker thực sự, mà thôi. Còn về chính cuộc tấn công, chưa bao giờ là một cuộc chiến về độ khó, mà là sự xem xét về chi phí mà hacker phải bỏ ra và hậu quả pháp lý.
Đồng thời, hầu hết các nhóm sản phẩm blockchain, thường khi đối mặt với những mối đe dọa tấn công giữa này, sẽ đặt việc tối ưu hóa này ở mức ưu tiên thấp trong toàn bộ quá trình lặp lại, tương đương với việc cho phép xuất hiện một phần rủi ro tấn công giữa. Như trong email giao tiếp của nhóm ở trên, giao diện bug bounty của Metamask đã loại trừ tấn công giữa MITM.
Vì vậy, đối với người dùng, cần chủ động nâng cao nhận thức phòng ngừa. Đối với tài sản quan trọng, ngay cả khi sử dụng ví cứng, tốt nhất nên cách ly máy tính, không kết nối với mạng không đáng tin cậy, không truy cập vào các trang web không đáng tin cậy, v.v.
Viết ở cuối
Mối "huyền thoại an toàn" của ví phần cứng không chỉ đến từ thiết bị đơn lẻ mà được xây dựng trên sự hợp tác an toàn của toàn bộ hệ sinh thái.
Khi chúng ta lơ là độ tin cậy của khách hàng và nới lỏng bảo vệ các kênh truyền thông, thì "Thanh kiếm Damocles" sẽ lặng lẽ treo trên tài sản của chúng ta.
An ninh thực sự không chỉ nằm ở phần cứng, mà còn ở từng chi tiết mà bạn nghĩ là "không quan trọng".
Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Ví cứng上的达摩克利斯之剑：威胁 của người trung gian
Tác giả: Revan Zhang Nguồn: Medium
Trong những năm gần đây, ví cứng được coi là một trong những phương thức lưu trữ khóa riêng tương đối an toàn trong ngành công nghiệp blockchain. Sau khi khóa riêng được tạo ra, nó sẽ được lưu trữ trong chip an toàn (Secure Element) của ví cứng, chỉ được sử dụng để ký thông tin từ bên ngoài. Thiết kế phần cứng kín không thể kết nối mạng này, kết hợp với cơ chế phần mềm cấm xuất khẩu khóa riêng, đã xây dựng một rào cản bảo vệ mạnh mẽ.
Tuy nhiên, kiến trúc an ninh này cũng có "điểm yếu" của nó - ví phần cứng phụ thuộc rất nhiều vào phần mềm khách hàng bên ngoài và các kênh truyền thông. Một khi những yếu tố bên ngoài này bị can thiệp, kẻ tấn công có thể thực hiện "tấn công trung gian" (MITM), thay thế thông tin mà người dùng không hề hay biết, dẫn đến mất mát tài sản.
Trung gian tấn công là gì
Tấn công trung gian là chỉ hành động của kẻ tấn công can thiệp một cách bí mật vào giữa hai bên giao tiếp, chặn, sửa đổi hoặc làm giả nội dung giao tiếp giữa hai bên, trong khi hai bên giao tiếp đều nghĩ rằng họ đang tương tác trực tiếp.
Loại tấn công này thường gặp trong các tình huống như giám sát mạng, giả mạo dữ liệu, đánh cắp danh tính và thay thế địa chỉ. Trong lĩnh vực tài sản mã hóa, điều này đặc biệt nguy hiểm, vì kẻ tấn công chỉ cần thay thế một địa chỉ có thể gây ra tổn thất tài sản lớn.
Một ví dụ trong cuộc sống: Bạn gửi cho bạn bè một bức thư quan trọng. Một "người đưa thư xấu" đã chặn bức thư trên đường đi, thay đổi nội dung bức thư, sau đó đóng lại và gửi đi. Khi bạn bè nhận được bức thư, thông tin mà họ nhận được đã không còn chính xác nữa vì bị người đưa thư thay thế.
Trong ví dụ này, người đưa thư đóng vai trò là trung gian, thực hiện cuộc tấn công trung gian bằng cách thay thế nội dung bức thư.
Trong hệ thống blockchain, do hầu hết các giao dịch trên chuỗi công cộng chỉ cần địa chỉ nhận tiền mà không cần xác thực thêm như tên. Trong những tình huống này, các cuộc tấn công trung gian dễ dàng thành công hơn, và thiệt hại thường lớn hơn, khó phục hồi hơn.
Quy trình giao tiếp ví cứng: Người đưa thư vô hình
Các loại ví cứng phổ biến trên thị trường chủ yếu sử dụng bốn phương thức giao tiếp:
Trong đó, USB và Bluetooth là phổ biến nhất. Dù sử dụng phương thức nào, quy trình giao tiếp về cơ bản là giống nhau:
Mặc dù ví phần cứng tự nó là "kho chứa" an toàn, nhưng quá trình giao tiếp lại phụ thuộc vào khách hàng và kênh giao tiếp, tức là "chuỗi người chuyển phát". Một khi "người chuyển phát" bị khống chế hoặc làm hại, thông tin dữ liệu được truyền đi có thể đã bị thay đổi từ lâu.
Trường hợp thực tiễn: Tấn công người trung gian dựa trên kịch bản độc hại
Tuyên bố
Quy trình giao tiếp cơ bản của Trezor
Trezor có thể chọn giao tiếp thông qua Trezor Bridge khi kết nối ví trình duyệt Metamask qua USB, quy trình cơ bản của Trezor Bridge.
Khi phát hiện Trezor Bridge đã được cài đặt trên máy, tất cả dữ liệu tuần tự qua trang web, tức là Trezor SDK, sẽ được chuyển tiếp đến thiết bị qua máy chủ Trezor Bridge cục bộ, mà không sử dụng Web USB.
Thông tin cơ bản về Trezor Bridge
Trezor Bridge được phát triển bằng Golang, phiên bản người dùng hiện tại là v2.0.27.
Từ kho lưu trữ mã nguồn mở trên GitHub có thể thấy, v2.0.27 sử dụng xgo để biên dịch đa nền tảng, từ đó tạo ra gói cài đặt cho MacOS, Windows và Linux.
Lấy ví dụ về MacOS, trong quá trình cài đặt sẽ tạo ra tệp nhị phân máy chủ trezord tại thư mục /Applications/Utilities/TREZOR\ Bridge/trezord, và tạo ra tệp com.bitcointrezor.trezorBridge.trezord.plist trên máy tính của người dùng, thông qua KeepAlive để thực hiện khởi động tự động khi mở máy và giám sát tiến trình.
Quy trình cơ bản của cuộc tấn công
Khi kết nối thiết bị Trezor với Metamask, thiết bị sẽ ngay lập tức đọc khóa công khai ETH bên trong, sau đó dựa trên số thứ tự địa chỉ phát sinh để tính toán các địa chỉ theo các đường dẫn khác nhau trong ứng dụng Metamask.
Trong quá trình này, không có bất kỳ xác nhận hoặc thông báo phần cứng nào, điều này cũng cung cấp một con đường khả thi cho một cuộc tấn công trung gian đơn giản.
Khi Trezor Bridge bị phần mềm độc hại cục bộ kiểm soát, sẽ xuất hiện một "người đưa thư xấu" trên toàn bộ liên kết giao tiếp. Kẻ tấn công có thể biến nó thành một máy chủ trung gian, đánh cắp tất cả dữ liệu giao tiếp với ví phần cứng. Do đó, dữ liệu gửi đến ví phần cứng và dữ liệu trả về từ ví phần cứng có thể bị thay đổi, dẫn đến việc thông tin hiển thị trên giao diện không nhất quán với thông tin thực tế của phần cứng. Một khi quy trình phần mềm có lỗ hổng hoặc thông tin trên phần cứng không được xác nhận nghiêm túc, cuộc tấn công trung gian có thể thành công.
Kiểm tra tấn công
Phân tích mã
Thêm đánh dấu nhật ký ở vị trí quan trọng của Trezor Bridge, ghi lại dữ liệu yêu cầu và phản hồi trong quá trình giao tiếp thiết bị:
Trong giai đoạn đọc khóa công khai của SDK, hexbodyStr và hexres hoàn toàn giống nhau về tham số thao tác và kết quả trả về vào những thời điểm khác nhau khi gọi nhiều lần trên cùng một thiết bị. Qua việc lọc nhật ký, phát hiện dữ liệu gọi hàm khi Metamask đọc địa chỉ ETH như sau:
Theo so sánh nhật ký,
003700000000 và 000b0000001f08ac8080800808bc80808008088080808008080008002207426974636f696e đều là kết quả tuần tự hóa của các thông điệp gửi và nhận.
Thông qua kiểm tra phát lại, trong quá trình xây dựng thông tin không có tham số như dấu thời gian, có thể rất dễ dàng mô phỏng các phương pháp tấn công, tức là nhắm vào một phần thông điệp đã gửi, mã cứng kết quả trả về và thay thế kết quả.
Trong ví dụ này, chúng tôi đã thay thế dữ liệu một cách có mục tiêu. Khi nhận được yêu cầu SDK lấy khóa công ETH, chúng tôi không còn sử dụng kết quả trả về từ phần cứng nữa, mà trực tiếp sử dụng kết quả được mã hóa cứng trong mã trên. Sau khi biên dịch lại qua tài liệu, tạo ra tệp nhị phân, đồng thời tạo ra các thành phần cần thiết cho các cuộc tấn công như daemon.
Sau khi công việc chuẩn bị hoàn tất, khi người dùng vô tình cài đặt và chạy phần mềm độc hại. Mỗi khi người dùng sử dụng Metamask để kết nối với Trezor và gửi dữ liệu, dữ liệu truyền thông qua bridge không còn là thông tin được đọc từ phần cứng nữa, mà là dữ liệu đã được tuần tự hóa cứng trong mã trên, và dựa trên việc giải tuần tự hóa của SDK kinh doanh, thông tin địa chỉ được đọc tức là đã thành công trong việc thay thế. Cuộc tấn công hoàn chỉnh như video trên đã chỉ ra.
Giao tiếp với đội ngũ
Sau khi sắp xếp các vấn đề và thao tác, tôi đã ngay lập tức liên lạc với đội ngũ Metamask và Trezor, dưới đây là tất cả thông tin liên lạc và email.
Cốt lõi của vấn đề và đề xuất
Metamask đọc địa chỉ đầy đủ, không cần xác nhận phần cứng
Phần cứng có thể được coi là một môi trường an toàn khép kín, vì vậy tất cả thông tin nên được căn cứ vào phần cứng. Tuy nhiên, trong quy trình thiết kế sản phẩm của Metamask, thông tin địa chỉ đầy đủ dưới dạng văn bản rõ ràng được đọc và hiển thị trực tiếp mà không có bất kỳ hiển thị nào từ phần cứng.
Phương pháp ethereumGetAddress của Trezor SDK cung cấp tham số showOnTrezor, có tác dụng là đọc địa chỉ của phần cứng và hiển thị trên phần cứng để người dùng xác nhận lần hai.
Đây là một vấn đề về sự lựa chọn trong thiết kế sản phẩm, nếu mỗi lần đều cần người dùng xác nhận mới có thể đọc địa chỉ, thì trong các tình huống thêm địa chỉ hàng loạt, người dùng sẽ rất khổ sở. Do đó, trong các ứng dụng hỗ trợ ví phần cứng phổ biến, đồng thời hỗ trợ đọc địa chỉ một cách lặng lẽ, nhưng nếu muốn nhận tài sản, đều cần phải thực hiện xác nhận phần cứng địa chỉ trước, nhằm ngăn chặn việc xuất hiện các tình huống tấn công như trên.
Metamask đã đọc địa chỉ một cách lặng lẽ mà không yêu cầu người dùng xác nhận, ngay lập tức hiển thị địa chỉ đầy đủ, điều này khiến người dùng lần đầu sử dụng dễ bị tấn công.
Mối đe dọa của chữ ký mù có thể lớn hơn chúng ta tưởng tượng.
Theo phương pháp và cách tấn công này, chúng ta có thể kết luận rằng: tất cả thông tin phần cứng không xác định đều lý thuyết là không an toàn.
Tất cả các chữ ký mù đều tương tự, mặc dù phần cứng chữ ký mù có xác nhận, nhưng thông tin xác nhận này thì người dùng không thể đọc được, vì vậy nó cũng thỏa mãn thông tin không xác định của phần cứng, không thể đảm bảo không bị tấn công bởi bên trung gian.
Vụ việc của ví đa chữ ký safe là một ví dụ điển hình, thông tin chữ ký được cấu trúc của ví bị mã độc javascript trên máy chủ thay thế, đồng thời vì ví ledger là chữ ký mù, dẫn đến việc xảy ra cuộc tấn công này.
Cuộc tấn công trung gian vào kênh giao tiếp, có nhiều hình thức
Ngoài việc người dùng có phần mềm độc hại trên máy tính của họ, một số quy trình giao tiếp và xây dựng của ví có thể liên quan đến máy chủ (ví dụ như một số ví encodeTx cần phải được xây dựng qua máy chủ). Đây đều là những mục tiêu tấn công tiềm ẩn và điểm bị tấn công.
Kênh truyền thông chắc chắn còn bao gồm cả mặt phần cứng, chẳng hạn như thiết bị webcam không an toàn, cáp USB không an toàn, v.v. Từ tầng vật lý đến tầng ứng dụng, ở cấp độ truyền thông, tất cả các khâu đều có khả năng bị tấn công.
Tăng cường nhận thức về an ninh, nhiệm vụ nặng nề và còn dài phía trước
Giao tiếp hoàn chỉnh từ khách hàng đến ví phần cứng về lý thuyết là không cần kết nối Internet. Vì vậy, ngay cả khi có giao tiếp mã hóa đầu cuối, cũng không thể đảm bảo 100% an toàn cho quy trình.
Sau khi tăng cường mã hóa đầu cuối, điều tăng lên chỉ là chi phí phá vỡ kênh giao tiếp đối với những hacker thực sự, mà thôi. Còn về chính cuộc tấn công, chưa bao giờ là một cuộc chiến về độ khó, mà là sự xem xét về chi phí mà hacker phải bỏ ra và hậu quả pháp lý.
Đồng thời, hầu hết các nhóm sản phẩm blockchain, thường khi đối mặt với những mối đe dọa tấn công giữa này, sẽ đặt việc tối ưu hóa này ở mức ưu tiên thấp trong toàn bộ quá trình lặp lại, tương đương với việc cho phép xuất hiện một phần rủi ro tấn công giữa. Như trong email giao tiếp của nhóm ở trên, giao diện bug bounty của Metamask đã loại trừ tấn công giữa MITM.
Vì vậy, đối với người dùng, cần chủ động nâng cao nhận thức phòng ngừa. Đối với tài sản quan trọng, ngay cả khi sử dụng ví cứng, tốt nhất nên cách ly máy tính, không kết nối với mạng không đáng tin cậy, không truy cập vào các trang web không đáng tin cậy, v.v.
Viết ở cuối
Mối "huyền thoại an toàn" của ví phần cứng không chỉ đến từ thiết bị đơn lẻ mà được xây dựng trên sự hợp tác an toàn của toàn bộ hệ sinh thái.
Khi chúng ta lơ là độ tin cậy của khách hàng và nới lỏng bảo vệ các kênh truyền thông, thì "Thanh kiếm Damocles" sẽ lặng lẽ treo trên tài sản của chúng ta.
An ninh thực sự không chỉ nằm ở phần cứng, mà còn ở từng chi tiết mà bạn nghĩ là "không quan trọng".