ScaleBit TechFlow: Phân tích chi tiết các lỗ hổng bảo mật và danh sách các điểm tấn công trong hệ sinh thái blockchain
Tuyển chọn TechFlowTuyển chọn TechFlow
ScaleBit TechFlow: Phân tích chi tiết các lỗ hổng bảo mật và danh sách các điểm tấn công trong hệ sinh thái blockchain
Báo cáo này phân tích chi tiết các loại lỗ hổng bảo mật và bề mặt tấn công hiện tại.
Chuyên sâu báo cáo Web3Công nghệ blockchain mặc dù thể hiện tiềm năng lớn trong các khía cạnh phi tập trung, an toàn và cơ chế tin cậy, nhưng hệ sinh thái của nó vẫn tiềm ẩn nhiều rủi ro an ninh khác nhau. Từ những lỗ hổng trong giao tiếp chéo chuỗi L1/L2 (ví dụ như không tính đến việc hoàn tác khối, xử lý sai giao dịch thất bại, lỗi xác minh client nhẹ) đến các nguy cơ về thứ tự mô-đun, sử dụng số ngẫu nhiên và hoàn tác giao dịch trên các chuỗi ứng dụng Cosmos, cùng với rủi ro phát sinh từ cấu trúc script, xử lý UTXO và hoàn tác trong hệ sinh thái mở rộng của Bitcoin – tất cả đều đặt ra thách thức nghiêm trọng cho các ứng dụng blockchain. Đồng thời, những lỗi phổ biến trong hợp đồng thông minh hoặc ngôn ngữ lập trình tổng quát như tràn số nguyên, vòng lặp vô hạn, điều kiện đua tranh, sập do ngoại lệ cũng sẽ đe dọa nghiêm trọng đến khả năng sử dụng và an toàn của hệ thống.
Hơn nữa, kiến trúc mạng P2P cũng có điểm yếu (như tấn công Sybil, tấn công Eclipse) và các cuộc tấn công DoS cũng làm giảm hiệu quả và độ tin cậy của hệ thống blockchain; các lỗ hổng mật mã học (thuật toán băm không an toàn, thuật toán chữ ký yếu, tạo số ngẫu nhiên không an toàn…) lại trực tiếp đe dọa tính bảo mật và toàn vẹn dữ liệu. Việc xử lý không đúng cách đối với bộ nhớ giao dịch (mempool), khối mồ côi và cây Merkle ở cấp độ sổ cái có thể dẫn đến sự không nhất quán dữ liệu trên chuỗi hoặc rủi ro tài sản. Cuối cùng, nếu mô hình kinh tế và cơ chế quản trị được thiết kế chưa đầy đủ, có thể gây mất cân bằng khuyến khích mạng lưới hoặc phân mảnh, cho phép kẻ tấn công lợi dụng sự mất cân bằng này để ảnh hưởng đến sự ổn định của hệ thống.
Nhìn chung các rủi ro trên, chỉ khi hiểu sâu sắc và thực hiện các biện pháp phòng ngừa nghiêm ngặt, mới có thể đảm bảo tính an toàn và phát triển bền vững trong hệ sinh thái blockchain đang không ngừng tiến hóa. Vào cuối năm 2024, BitsLab – thương hiệu mẹ của ScaleBit – đã phát hành báo cáo "Quan sát Toàn cảnh và Báo cáo Nghiên cứu An toàn Hệ sinh thái Công cộng Mới nổi 2024". Báo cáo này phân tích chi tiết các loại lỗ hổng an toàn và bề mặt tấn công hiện tại, nội dung phong phú và thiết thực. Bài viết này trích một phần nội dung từ báo cáo nhằm tập trung làm rõ các loại lỗ hổng an toàn then chốt trong hệ sinh thái blockchain, giúp độc giả chủ động phòng ngừa, cùng thúc đẩy sự phát triển an toàn và lành mạnh của ngành.
Đọc bản gốc báo cáo: https://bitslab.xyz/reports-page
1) Danh sách các loại lỗ hổng an toàn
1.1 Lỗ hổng giao tiếp chéo chuỗi L2/L1
Giao tiếp chéo chuỗi là phương tiện quan trọng nâng cao khả năng tương tác trong hệ sinh thái blockchain, tuy nhiên quá trình triển khai cũng tiềm ẩn nhiều nguy cơ an ninh. Dưới đây là những điểm cần lưu ý chính:
L2 không tính đến việc hoàn tác khối trên L1
Khi gửi giao dịch L1 hoặc lấy dữ liệu từ chuỗi L1, nếu không xem xét tình huống này, có thể dẫn đến tổn thất tài sản.
L2 không kiểm tra xem giao dịch gửi đến L1 có thành công hay không
Do các vấn đề về mạng hoặc phí gas, giao dịch gửi đi có thể thất bại. Nếu không tính đến trường hợp này, có thể gây tổn thất tài sản cho dự án hoặc người dùng.
Giả mạo sự kiện trên chuỗi
Khi cầu nối chéo chuỗi theo dõi sự kiện trên chuỗi, nếu không xác minh sự kiện có phải đến từ địa chỉ hợp đồng cụ thể hay không, các hợp đồng khác có thể giả mạo sự kiện.
Một giao dịch chứa nhiều sự kiện trên chuỗi
Một giao dịch có thể chứa nhiều sự kiện. Nếu không tính đến trường hợp này, có thể dẫn đến tổn thất tài sản cho dự án hoặc người dùng.
Lỗ hổng xác minh client nhẹ
1. Chuỗi PoW không tính đến tấn công đào riêng
2. Không sử dụng thuật toán được khuyến nghị chính thức
Tấn công chặn giữa đường (Man-in-the-Middle)
Trong giao tiếp chéo chuỗi L2/L1, cơ chế truyền tin nhắn rất quan trọng, cần đảm bảo tính toàn vẹn và bí mật của tin nhắn trong quá trình truyền tải. Việc truyền tin nhắn giữa các chuỗi khác nhau có thể bị thay đổi hoặc nghe lén, do đó cần sử dụng các biện pháp mã hóa để bảo vệ an toàn thông tin. Ngoài ra, việc đảm bảo tính không thể chối bỏ của tin nhắn khi chuyển tiếp giữa các chuỗi cũng rất quan trọng, nhằm ngăn chặn việc thông tin bị thay đổi ác ý.
Vấn đề độ trễ và tính hoàn tất
Giao tiếp chéo chuỗi thường gặp phải vấn đề độ trễ và tính hoàn tất. Vì các cơ chế đồng thuận và thời gian xác nhận của các chuỗi khác nhau nên thời gian xác nhận giao dịch chéo chuỗi có thể không nhất quán, dẫn đến độ trễ cập nhật trạng thái, từ đó gia tăng rủi ro an ninh tiềm tàng. Khi thiết kế giao thức chéo chuỗi, cần làm rõ định nghĩa về tính hoàn tất, đảm bảo tính nhất quán trạng thái giao dịch, ngăn chặn các tấn công double-spend hoặc trạng thái không nhất quán do độ trễ xác nhận.
1.2 Lỗ hổng chuỗi ứng dụng Cosmos
Cosmos là một hệ sinh thái tập trung vào khả năng tương tác blockchain, cho phép các blockchain khác nhau kết nối thông qua IBC (giao thức giao tiếp chéo chuỗi). Tuy nhiên, chuỗi ứng dụng Cosmos trong quá trình triển khai cũng có thể tồn tại một số lỗ hổng và nguy cơ an ninh. Dưới đây là các điểm cần chú ý chính:
Lỗ hổng sập do BeginBlocker và EndBlocker
BeginBlocker và EndBlocker là các phương thức tùy chọn mà nhà phát triển mô-đun có thể triển khai trong mô-đun của họ. Chúng lần lượt được kích hoạt ở đầu và cuối mỗi khối. Việc sử dụng lệnh sập để xử lý lỗi trong các phương thức BeginBlock và EndBlock có thể khiến chuỗi dừng hoạt động khi xảy ra lỗi.
Sử dụng thời gian cục bộ không đúng
Do thời gian cục bộ của các nút khác nhau sẽ có sự chênh lệch, nếu không tính đến điều này khi tạo đồng thuận, sẽ gây ra vấn đề đồng thuận.
Nội dung tham khảo:
Nguồn ảnh
https://forum.cosmos.network/t/cosmos-sdk-security-advisory-jackfruit/5319
Sử dụng số ngẫu nhiên không đúng
Do các nút khác nhau tạo ra số ngẫu nhiên khác nhau, nếu không tính đến điều này khi tạo đồng thuận sẽ dẫn đến vấn đề đồng thuận.
Sử dụng sai chức năng lặp Map
Việc lặp map trong ngôn ngữ Go là không xác định, nếu không tính đến điều này khi tạo đồng thuận sẽ dẫn đến vấn đề đồng thuận. Mã ví dụ như sau:
Vấn đề do thứ tự mô-đun không hợp lý
Chuỗi ứng dụng Cosmos gồm nhiều mô-đun, trong một số xử lý sự kiện, giữa các mô-đun có thứ tự. Nếu thiết lập thứ tự không hợp lý, có thể dẫn đến vấn đề an ninh.
Giao dịch thất bại nhưng dữ liệu không hoàn tác
Trong chuỗi ứng dụng Cosmos, nếu một giao dịch thực thi thất bại nhưng do thiếu sót thiết kế, trạng thái dữ liệu không hoàn tác về trạng thái trước khi thực thi giao dịch, có thể dẫn đến dữ liệu trên chuỗi không nhất quán. Tình trạng này không chỉ ảnh hưởng đến niềm tin của người dùng mà còn có thể gây tổn thất tiền bạc. Vì vậy, khi thiết kế phải đảm bảo hợp đồng thông minh xử lý đúng giao dịch thất bại, đảm bảo tính nhất quán và đáng tin cậy của trạng thái, khi cần thiết phải triển khai cơ chế hoàn tác tự động.
Xác minh trạng thái sai
Logic xác minh trạng thái trong chuỗi ứng dụng Cosmos cần rất chặt chẽ. Nếu xác minh trạng thái không chính xác, có thể khiến giao dịch bất hợp pháp được xác nhận, ảnh hưởng đến an ninh chuỗi. Nhà phát triển cần thiết kế cẩn thận logic chuyển trạng thái và thử nghiệm toàn diện để tránh lỗ hổng do xác minh trạng thái sai.
An toàn truyền tin nhắn chéo chuỗi
Cơ chế IBC của Cosmos cho phép truyền tin nhắn giữa các chuỗi ứng dụng khác nhau, nhưng cũng mang theo rủi ro an ninh tiềm tàng. Ví dụ, nếu tin nhắn chéo chuỗi bị thay đổi trong quá trình truyền, có thể dẫn đến cập nhật trạng thái sai hoặc kẻ tấn công lợi dụng tin nhắn để thực hiện thao tác ác ý. Cần áp dụng cơ chế mã hóa và chữ ký để đảm bảo tính toàn vẹn và xác thực của tin nhắn, ngăn chặn việc thay đổi tin nhắn trong quá trình truyền.
Vấn đề nâng cấp hợp đồng và quản lý phiên bản
Hợp đồng chuỗi ứng dụng Cosmos có thể cần nâng cấp trong quá trình sử dụng, nhưng nếu nâng cấp không đúng cách có thể dẫn đến trạng thái hợp đồng cũ không tương thích hoặc lỗ hổng an ninh. Nhà phát triển cần xây dựng chiến lược nâng cấp hợp đồng rõ ràng, bao gồm quản lý phiên bản và phương án di chuyển, đảm bảo quá trình nâng cấp không ảnh hưởng đến hoạt động bình thường của chuỗi.
Mô hình kinh tế và cơ chế khuyến khích
Thiết kế mô hình kinh tế trong hệ sinh thái Cosmos ảnh hưởng trực tiếp đến an ninh và ổn định của chuỗi. Nếu cơ chế khuyến khích thiết lập không hợp lý, có thể dẫn đến hành vi tham gia mất cân bằng, xuất hiện hành vi ác ý hoặc tấn công kinh tế. Cần đánh giá toàn diện mô hình kinh tế để đảm bảo cơ chế khuyến khích duy trì hiệu quả an ninh và sức khỏe mạng lưới.
Lỗ hổng cơ chế quản trị
Cơ chế quản trị chuỗi ứng dụng Cosmos cho phép người nắm giữ token tham gia vào quyết định chuỗi, nhưng nếu thiết kế cơ chế quản trị không phù hợp, có thể dẫn đến tấn công quản trị hoặc vấn đề tập trung quyền lực. Cần đảm bảo tính công bằng và minh bạch của cơ chế quản trị để ngăn chặn thiểu số thao túng quá trình ra quyết định của chuỗi.
1.3 Lỗ hổng hệ sinh thái mở rộng Bitcoin
Lỗ hổng cấu trúc script Bitcoin
Script Bitcoin trong nhiều trường hợp được tạo và triển khai lên Bitcoin theo thời gian thực, và nội dung script bao gồm dữ liệu do người dùng cung cấp. Nếu cấu trúc script không an toàn, sẽ dẫn đến tổn thất tài sản.
Lỗ hổng do không tính đến tài sản phái sinh
Tài sản phái sinh phổ biến của Bitcoin là inscriptions và runes. Nếu L2 khi thao tác tài sản người dùng chỉ xét BTC gốc mà không tính đến tài sản phái sinh, sẽ dẫn đến tổn thất tài sản người dùng.
Lỗ hổng tính sai số lượng UTXO
1. Sai sót khi tính phí giao dịch
2. Sai sót khi tính số tiền hoàn trả
Ví dụ trong đoạn mã dưới đây, việc tính toán đầu ra hoàn trả có một điều kiện: chỉ khi số tiền hoàn trả lớn hơn hoặc bằng 546 satoshi thì mới thêm đầu ra hoàn trả. Giá trị này tương ứng với giới hạn bụi (dust limit) của giao dịch P2PKH truyền thống. Tuy nhiên, giới hạn bụi của các loại địa chỉ khác nhau là khác nhau. Đặc biệt, đối với địa chỉ Taproot, giới hạn bụi là 330 satoshi.
Giá trị cố định này không tính đến giới hạn bụi thấp hơn của địa chỉ Taproot, có thể dẫn đến mất tài sản nhỏ trong giao dịch liên quan đến địa chỉ Taproot. Thông tin chi tiết về giới hạn bụi của các loại địa chỉ khác nhau có thể tìm thấy trong mã nguồn Bitcoin Core và thảo luận trên diễn đàn BitcoinTalk.
https://bitcointalk.org/index.php?topic=5453107.msg62262343#msg62262343
Không kiểm tra UTXO có chứa "op_return"
UTXO có "op_return" là không thể tiêu được.
Lỗ hổng xác minh SPV
1. Không xác minh dấu thời gian tiêu đề khối
2. Không xác minh bằng chứng công việc (PoW) của tiêu đề khối
Không tính đến tình huống hoàn tác
Do Bitcoin dựa trên PoW nên thường xuyên xảy ra tổ chức lại khối. Khi gửi giao dịch Bitcoin hoặc lấy dữ liệu trên chuỗi Bitcoin, nếu không tính đến tình huống này, có thể dẫn đến tổn thất tài sản.
Không kiểm tra xem giao dịch Bitcoin có được gửi thành công hay không
Sau khi gửi giao dịch Bitcoin, chưa chắc đã được thợ đào đóng gói, vì vậy cần kiểm tra xem giao dịch có thành công trên chuỗi hay không. Đồng thời, bên thứ ba có thể tạo giao dịch có phí cao hơn để khiến giao dịch do L2 gửi nằm lâu trong bộ nhớ giao dịch mà không được đóng gói.
Lỗ hổng nhầm lẫn khóa thời gian tuyệt đối và khóa thời gian tương đối
Khi cấu trúc script Bitcoin, nếu nhầm lẫn hai loại thời gian này, trong trường hợp nghiêm trọng có thể dẫn đến tổn thất tài sản.
Thời gian thiết lập không hợp lý trong hợp đồng khóa thời gian băm (HTLC)
Có ba trường hợp phổ biến như sau:
1. Thời gian thiết lập quá lớn
2. Thời gian thiết lập quá nhỏ
3. Thời gian L1 và L2 không đồng bộ
1.4 Các loại lỗ hổng phổ biến trong ngôn ngữ lập trình
1.4.1 Tràn số nguyên
Tràn số nguyên xảy ra khi giá trị vượt quá phạm vi biểu diễn của kiểu dữ liệu, dẫn đến giá trị quay vòng hoặc lỗi logic, ảnh hưởng đến độ chính xác dữ liệu chương trình. Rust tự động phát hiện tràn trong chế độ gỡ lỗi, trong khi Go cần thêm kiểm tra giới hạn thủ công.
1.4.2 Vòng lặp vô hạn
Vòng lặp vô hạn là khi chương trình rơi vào vòng lặp vô tận dưới điều kiện nhất định, tiêu tốn tài nguyên hệ thống, khiến chương trình treo hoặc không phản hồi. Chìa khóa để tránh vấn đề này là thiết lập điều kiện thoát vòng lặp hợp lý, đồng thời sử dụng cơ chế timeout của Rust hoặc gói context của Go để kiểm soát vòng lặp chạy lâu dài.
1.4.3 Gọi đệ quy vô hạn
Gọi đệ quy vô hạn chỉ hàm đệ quy thiếu điều kiện dừng, dẫn đến tràn ngăn xếp và sập chương trình. Đảm bảo đệ quy có điều kiện dừng rõ ràng và giới hạn độ sâu đệ quy theo nhu cầu có thể hiệu quả ngăn chặn vấn đề này.
Rust sẽ hiển thị lỗi tràn ngăn xếp trong thông tin gỡ lỗi, tương tự như đầu ra sau:
1.4.4 Điều kiện đua tranh
Khi nhiều luồng truy cập tài nguyên chia sẻ mà không đồng bộ, sẽ xảy ra tranh chấp dữ liệu, dẫn đến dữ liệu không nhất quán. Rust tránh điều kiện đua tranh thông qua cơ chế sở hữu và thư viện an toàn đa luồng, Go cung cấp hỗ trợ đồng thời thông qua channel và gói sync.
Dưới đây là ví dụ Unsafe Rust minh họa hai luồng đồng thời truy cập và sửa đổi biến chia sẻ giống nhau, dẫn đến hành vi không xác định. Mã này gây tranh chấp dữ liệu vì không sử dụng bất kỳ cơ chế đồng bộ nào để bảo vệ tài nguyên chia sẻ:
Mặc dù Safe Rust ngăn chặn tranh chấp dữ liệu, nhưng tranh chấp logic vẫn có thể xảy ra. Điều kiện đua tranh logic (Race Condition) chỉ việc mã có thể tạo ra hành vi ngoài dự kiến dưới thứ tự thực thi cụ thể, đây là tranh chấp ở cấp độ logic. Ví dụ trong các tình huống sau:
1. Thao tác nhạy cảm với thời gian: Thứ tự thao tác giữa hai luồng có thể ảnh hưởng đến kết quả logic cuối cùng. Ví dụ:
a. Một luồng kiểm tra xem điều kiện nào đó có đúng hay không, trong khi đó luồng khác thay đổi điều kiện. Trong Rust, điều này có thể được điều phối thông qua cơ chế đồng bộ như Arc
2. Khóa kiểm tra kép (Double-Checked Locking): Nếu nhiều luồng cố gắng khởi tạo tài nguyên chia sẻ và đều cho rằng tài nguyên chưa được khởi tạo, có thể dẫn đến lỗi logic. Trong trường hợp này, mặc dù không xảy ra tranh chấp dữ liệu, nhưng có thể tạo ra lỗi logic ngoài ý muốn.
3. Thứ tự khóa không đúng: Nếu sử dụng nhiều khóa, các luồng có thể lấy khóa theo thứ tự không nhất quán, dẫn đến nguy cơ tắc nghẽn. Hệ thống kiểu của Rust không thể ngăn chặn loại điều kiện đua tranh này.
Dưới đây là minh họa lỗ hổng điều kiện đua tranh trong Safe Rust. Trong ví dụ này:
● Hai luồng lần lượt cộng 1 vào biến chia sẻ data. Mỗi luồng sẽ khóa data rồi tăng giá trị.
● Vì thao tác được thực hiện từng bước, mặc dù dữ liệu được bảo vệ bởi Mutex, thứ tự thực thi của luồng 1 và luồng 2 sẽ ảnh hưởng đến kết quả in cuối cùng. Về lý thuyết, giá trị cuối cùng phải là 2, nhưng thứ tự in đầu ra cụ thể của các luồng có thể không cố định.
1.4.5 Sập do ngoại lệ
Sập do ngoại lệ thường do lỗi chưa xử lý gây ra, dẫn đến chương trình dừng bất ngờ. Go sử dụng defer/panic/recover để bắt ngoại lệ, Rust sử dụng hệ thống kiểu Result và Option để cung cấp xử lý lỗi mạnh mẽ hơn.
Dưới đây là ví dụ không bắt panic dẫn đến sập chương trình:
1.4.6 Lỗ hổng chia cho 0
Lỗ hổng chia cho 0 chỉ việc chương trình thực hiện phép chia với mẫu số bằng 0, có thể gây ngoại lệ hoặc sập. Nên kiểm tra giá trị mẫu số trước khi chia để tránh thao tác với giá trị 0 và đảm bảo tính ổn định chương trình.
1.4.7 Chuyển đổi kiểu dữ liệu
Lỗi chuyển đổi kiểu dữ liệu thường do chuyển đổi không an toàn hoặc không tương thích, có thể gây hành vi không lường trước. Go và Rust sẽ cảnh báo kiểu dữ liệu không tương thích khi chuyển đổi, Rust nghiêm ngặt hơn, yêu cầu sử dụng toán tử "as" để chuyển đổi rõ ràng.
Trong đoạn mã ví dụ dưới đây, người dùng thêm lượng thanh khoản amount token, sau đó hệ thống ghi nhận số lượng thanh khoản của họ. Nếu amount = (u128::MAX << 64) | 1, thực tế chỉ thanh toán 1 token, nhưng số dư thanh khoản ghi nhận là 340282366920938463444927863358058659841.
1.4.8 Truy cập ngoài phạm vi mảng
Truy cập ngoài phạm vi mảng chỉ việc truy cập vị trí chỉ mục không hợp lệ trong mảng, dẫn đến lỗi truy cập bộ nhớ hoặc sập chương trình.
Đoạn mã ví dụ dưới đây minh họa việc truy cập ngoài phạm vi mảng dẫn đến sập chương trình:
1.5 Lỗ hổng mạng P2P
Mạng P2P (ngang hàng) trong hệ thống blockchain dùng để kết nối và giao tiếp trực tiếp giữa các nút phân tán. Mặc dù mạng P2P cung cấp nền tảng mạng cho hệ thống phi tập trung, nhưng cũng đối mặt với loạt lỗ hổng an ninh và rủi ro tấn công.
Về góc độ an ninh, mạng P2P có thể chia làm hai loại: một loại không cần giấy phép, loại này dùng nhiều trên L1; một loại cần giấy phép, loại này phổ biến hơn trên L2.
Trong mạng P2P không cần giấy phép, nhiều cuộc tấn công dựa trên tấn công Sybil. Trong mạng cần giấy phép, chúng ta không thể giả định tất cả các nút đều đáng tin cậy, về mặt an ninh, cần giả định ít nhất có một nút ác ý.
Các loại lỗ hổng phổ biến của mạng P2P như sau:
1. Lỗ hổng tấn công dị hình:
Tấn công dị hình còn gọi là ô nhiễm bể địa chỉ, là một phương pháp tấn công dụ các nút chuỗi tương tự xâm nhập và làm ô nhiễm lẫn nhau, nguyên nhân chính của lỗ hổng là hệ thống chuỗi tương tự không nhận diện nút không cùng loại trong giao thức truyền thông.
Một số chuỗi tương tự Ethereum từng gặp lỗ hổng tương tự. Các chuỗi tương tự Ethereum (cụ thể là các chuỗi công khai sử dụng giao thức phát hiện nút discv4 P2P của Ethereum, bao gồm Ethereum, Ethereum Classic) do sử dụng giao thức bắt tay tương thích, không thể phân biệt nút có thuộc cùng chuỗi hay không, dẫn đến bể địa chỉ bị làm ô nhiễm lẫn nhau, hiệu suất truyền thông nút giảm, cuối cùng gây tắc nghẽn nút.
Quá trình tấn công như hình dưới:
2. Thiếu cơ chế mô hình tin cậy
Xây dựng điểm uy tín cho từng nút, điều chỉnh mức độ tin cậy dựa trên hành vi lịch sử của nút. Ví dụ, nếu nút thường xuyên gửi dữ liệu không hợp lệ, hãy giảm uy tín của nó. Các nút uy tín cao được tin tưởng hơn, trong khi các nút uy tín thấp cần bị hạn chế.
3. Thiếu cơ chế giới hạn số lượng nút
Giới hạn tốc độ tạo nút mới hoặc số kết nối mỗi IP, ngăn tạo hàng loạt nút giả trong thời gian ngắn.
4. Vấn đề thuật toán phát hiện nút
Thuật toán phát hiện và lựa chọn nút chịu trách nhiệm định vị nút mới và thiết lập kết nối trong mạng P2P. Nếu thuật toán thiết kế không hợp lý, ví dụ thuật toán khoảng cách không cân bằng, dễ dẫn đến mất cân bằng bố cục mạng, một số nút quá tải. Cần đảm bảo tính cân bằng và không thể đoán trước của thuật toán để nâng cao an ninh phân bố nút và khả năng chống tấn công của mạng.
Hình dưới minh họa một trường hợp cực đoan của mất cân bằng bố cục mạng:
5. Cơ chế lựa chọn nút dễ bị tấn công
Nếu nút sử dụng cơ chế lựa chọn nút dễ bị tấn công, thì tất cả các nút khác mà nó kết nối có thể đều là nút ác ý, dẫn đến Tấn công Eclipse. Dưới đây là các cơ chế an toàn lựa chọn nút phổ biến:
Lựa chọn nút ngẫu nhiên: Làm ngẫu nhiên mục tiêu kết nối nút, khiến kẻ tấn công khó kiểm soát cấu trúc kết nối nút.
Chiến lược kết nối cục bộ: Cho phép nút ưu tiên kết nối với các nút gần về mặt vật lý hoặc bố cục mạng, khiến kẻ tấn công khó xâm nhập toàn bộ mạng.
6. Thiếu xác thực danh tính
Trong mạng P2P cần giấy phép, cần xác thực danh tính nút
7. Thiếu cơ chế cập nhật định kỳ bảng định tuyến
Nếu phát hiện một nút trả về dữ liệu bất hợp pháp, cần cân nhắc xóa bản ghi của nó khỏi bảng định tuyến
Các nút nên định kỳ loại bỏ các nút không hoạt động lâu khỏi bảng định tuyến, thay thế bằng nút mới, từ đó tránh bị cô lập mạng do bảng định tuyến失效.
8. Lỗ hổng bị chặn giữa đường (Man-in-the-Middle)
Dữ liệu p2p trong quá trình truyền tải phải giữ nguyên tính toàn vẹn. Nếu thuật toán mã hóa sử dụng không đúng hoặc có lỗ hổng, dữ liệu có thể bị thay đổi.
1.6 Lỗ hổng DoS
Lỗ hổng DoS (từ chối dịch vụ) khiến tài nguyên hệ thống cạn kiệt, cản trở người dùng hợp pháp truy cập bình thường, dưới đây là các loại chính:
1. Tấn công làm cạn bộ nhớ
Tận dụng nhu cầu bộ nhớ lớn để làm sập hệ thống, đề xuất thiết lập giới hạn tài nguyên để phòng ngừa.
Một loại tấn công làm cạn bộ nhớ phổ biến là "zip bomb". Nguyên lý cơ bản của zip bomb là tạo một tệp rất lớn với toàn bộ nội dung là 0 (hoặc giá trị khác), sau đó nén thành tệp zip. Do tỷ lệ nén của tệp có nội dung giống nhau rất lớn, tệp zip tạo ra lúc này rất nhỏ. Mục tiêu bị tấn công khi giải nén tệp zip cần tiêu tốn rất nhiều bộ nhớ để lưu trữ tệp sau khi giải nén, bộ nhớ nhanh chóng cạn kiệt, mục tiêu sập do OOM.
Các thuật toán nén khác cũng gặp vấn đề tương tự. Dưới đây là bảng tỷ lệ nén của các thuật toán phổ biến khi nén tệp 1GB toàn bộ nội dung là 0:
2. Tấn công làm cạn ổ cứng: Ghi dữ liệu vô ích chiếm đầy không gian lưu trữ, ngăn ngừa thiếu tài nguyên bằng cách quản lý hạn ngạch đĩa.
Tấn công làm cạn ổ cứng thường có hai tình huống sau:
1. Zip bomb. Phương pháp tấn công giống như "tấn công làm cạn bộ nhớ" ở trên, chỉ khác là chương trình mục tiêu giải nén zip ra đĩa chứ không phải trực tiếp vào bộ nhớ.
2. Viết lượng lớn dữ liệu với chi phí không hoặc thấp vào đĩa, có thể làm cạn dữ liệu đĩa
3. Tấn công làm cạn bộ xử lý kernel: Số lượng lớn yêu cầu tài nguyên làm cạn bộ xử lý, đề xuất kiểm soát việc phân bổ bộ xử lý và giám sát bất thường.
Nguyên lý cơ bản của cuộc tấn công này là: kẻ tấn công lợi dụng lỗ hổng khiến bộ xử lý kernel của nút mục tiêu cạn kiệt hoặc gần cạn kiệt, khiến nó không thể phản hồi yêu cầu nghiệp vụ bình thường.
Một loại tấn công phổ biến là "tấn công gây áp lực Socket". Nếu nút mục tiêu không giới hạn số lượng kết nối và số lượng đồng thời, kẻ tấn công có thể gửi và duy trì nhiều yêu cầu kết nối, làm cạn tài nguyên Socket hệ thống.
4. Rò rỉ bộ nhớ liên tục: Bộ nhớ không thể giải phóng bình thường dẫn đến cạn kiệt tài nguyên, cần định kỳ kiểm tra việc sử dụng bộ nhớ để ngăn chặn vấn đề xấu đi.
Rò rỉ bộ nhớ nói chung không được coi là lỗ hổng an ninh. Nhưng nếu kẻ tấn công có thể chủ động kích hoạt rò rỉ bộ nhớ ở nút mục tiêu và có thể lặp lại thao tác này, tích tụ theo thời gian, chương trình nút mục tiêu sẽ sập do thiếu bộ nhớ.
1.7 Lỗ hổng mật mã học
Lỗ hổng mật mã học sẽ phá hủy tính bí mật và toàn vẹn dữ liệu, gây ra mối đe dọa an ninh tiềm tàng cho hệ thống. Dưới đây là các loại lỗ hổng mật mã học chính:
Sử dụng thuật toán băm đã được chứng minh là không an toàn
Thuật toán băm dùng để tạo định danh duy nhất của dữ liệu, đảm bảo tính toàn vẹn không bị thay đổi. Các thuật toán băm phổ biến như MD5 và SHA-1 đã được chứng minh có rủi ro va chạm, có thể bị kẻ tấn công ác ý lợi dụng. Vì vậy, nên sử dụng các thuật toán băm hiện đại an toàn hơn như SHA-256 hoặc SHA-3, đồng thời cập nhật thuật toán thường xuyên, tránh rủi ro tính toàn vẹn dữ liệu do các thuật toán cũ dễ bị bẻ khóa.
Sử dụng thuật toán băm tùy chỉnh không an toàn
Một số dự án sử dụng thuật toán băm tự định nghĩa, nhìn chung các thuật toán này không an toàn bằng các thuật toán nổi tiếng công khai.
Ví dụ trong quá trình kiểm toán, chúng tôi gặp thuật toán băm tùy chỉnh như sau:
Hàm `hashCode` không phải là một hàm băm mã hóa, và rất dễ xảy ra va chạm. Nó chỉ thực hiện các phép toán bit và cộng rất đơn giản. Hơn nữa, độ dài đầu vào và đầu ra của hàm tuân theo mẫu rõ ràng và có thể dự đoán, khiến nó rất dễ bị đảo ngược và bẻ khóa. Do cơ chế băm yếu này, kẻ tấn công có thể dễ dàng tạo ra các khóa dẫn đến cùng một giá trị `CONST_KEY_HASH`, từ đó đe dọa đến tính an toàn của quá trình ủy quyền API.
Dưới đây là mã proof-of-concept (PoC) minh họa cách lợi dụng lỗ hổng của băm yếu này:
Va chạm băm do sử dụng không an toàn
Một tình huống phổ biến là, HASH(A+B+C)=HASH(D+E), nguyên nhân là A+B+C=D+E, do 'A+B+C' và 'D+E' hoàn toàn giống nhau, nhưng A, B, C, D, E từng cái một là khác nhau.
Sử dụng thuật toán chữ ký số không an toàn
Thuật toán chữ ký số dùng để xác minh tính xác thực và nguồn gốc dữ liệu, ngăn dữ liệu bị thay đổi. Các thuật toán chữ ký sớm như DSA và RSA có thể mất hiệu lực dưới mối đe dọa máy tính lượng tử. Sử dụng các thuật toán chữ ký hiện đại như ECDSA hoặc EdDSA có thể cung cấp độ an toàn cao hơn, bảo vệ tính hợp pháp và khả năng chống làm giả dữ liệu. Đặc biệt trong các hệ thống phân tán và hợp đồng thông minh, đảm bảo độ tin cậy của thuật toán chữ ký là cực kỳ quan trọng.
Sử dụng thuật toán mã hóa không an toàn
Độ mạnh của thuật toán mã hóa ảnh hưởng trực tiếp đến tính bí mật dữ liệu, thuật toán mã hóa yếu (như DES) có thể bị kẻ tấn công dễ dàng bẻ khóa. Nên sử dụng các thuật toán mã hóa đối xứng bậc cao hơn như AES-256, và thực hiện mã hóa đầu cuối (như TLS) trong quá trình truyền thông để đảm bảo an toàn truyền dữ liệu, ngăn chặn nghe lén hoặc thay đổi. Ngoài ra, đảm bảo quản lý khóa đúng cách, ngăn rò rỉ khóa.
Sử dụng thuật toán tạo số ngẫu nhiên không an toàn
Bộ tạo số ngẫu nhiên là nền tảng cho nhiều thao tác mật mã học, đặc biệt quan trọng khi tạo khóa, IV (vector khởi tạo) và các tham số quan trọng trong mã hóa bất đối xứng, đảm bảo tính không thể đoán trước là rất quan trọng. Dưới đây là các vấn đề an ninh phổ biến:
1. Thuật toán tạo số ngẫu nhiên không an toàn dẫn đến số ngẫu nhiên có thể bị đoán hoặc thao túng;
2. Trên các chuỗi công khai, thuật toán số ngẫu nhiên cơ bản đều có rủi ro bị đoán, vì thông tin hoàn toàn công khai minh bạch nên số ngẫu nhiên đều có thể bị đoán.
3. Thuật toán tạo số ngẫu nhiên không an toàn dẫn đến tính ngẫu nhiên kém, từ đó làm tăng xác suất xảy ra một số lỗ hổng hoặc vấn đề (ví dụ thợ đào tạo khối).
Sử dụng hạt giống số ngẫu nhiên không an toàn
Hạt giống số ngẫu nhiên bị rò rỉ hoặc có thể bị bẻ khóa bằng vũ lực dẫn đến hạt giống bị rò rỉ, từ đó khiến số ngẫu nhiên bị đoán;
Tấn công kênh bên mật mã học
Tấn công kênh bên thông qua giám sát các đặc điểm vật lý hệ thống (như tiêu thụ điện, thời gian thực thi, bộ nhớ đệm...) để lấy thông tin nhạy cảm. Loại tấn công này vượt qua tính an toàn của bản thân thuật toán, phổ biến hơn trong thiết bị phần cứng và hệ thống nhúng. Biện pháp phòng thủ bao gồm tối ưu hóa việc triển khai thuật toán để thời gian thực thi và tiêu thụ điện luôn hằng định, giảm đặc điểm có thể rò rỉ. Ngoài ra, sử dụng các kỹ thuật như che chắn và làm rối để giảm khả năng rò rỉ thông tin kênh bên.
Tính kéo dài chữ ký
Tính kéo dài chữ ký chỉ việc, dưới điều kiện không thay đổi nội dung chữ ký, có thể suy ra và tính toán một chữ ký hợp lệ khác từ chữ ký hợp lệ đã biết. Một rủi ro đáng chú ý do đặc điểm này là tính kéo dài giao dịch, khiến người dùng ác ý có thể lợi dụng các biến thể chữ ký khác nhau để phát lại giao dịch, giao dịch phát lại do chữ ký khác nhau nên có giá trị hash khác nhau, gây nhầm lẫn cho người dùng về trạng thái giao dịch trong quá trình xác nhận, từ đó thực hiện thanh toán kép.
1.8 Lỗ hổng an toàn sổ cái
Lỗ hổng bộ nhớ giao dịch (mempool)
1. Giao dịch có thể phát lại
2. Giao dịch thất bại không bị trừ phí
Lỗ hổng va chạm hash khối
Nếu cách cấu tạo khối có vấn đề, sẽ tạo ra va chạm.
Lỗ hổng logic xử lý khối mồ côi
Khối mồ côi có thể chọn loại bỏ trực tiếp, nhưng nếu chọn lưu tạm thì phải thêm các điều kiện giới hạn như chiều cao, thời gian...
Lỗ hổng va chạm hash cây Merkle
Nếu cách cấu tạo nút lá cây Merkle có vấn đề, sẽ tạo ra va chạm.
Vấn đề xử lý số tiền giao dịch
Do tràn giới hạn trên/dưới khi xử lý số tiền giao dịch, kiểu dữ liệu không thống nhất, sai số độ chính xác, xuất hiện số âm và giá trị ngoài dự kiến do điều kiện bên ngoài thay đổi
Vấn đề xử lý phí giao dịch
Do tràn giới hạn trên/dưới khi xử lý phí giao dịch, kiểu dữ liệu không thống nhất, sai số độ chính xác, xuất hiện số âm và giá trị ngoài dự kiến do điều kiện bên ngoài thay đổi
Thời gian xác minh khối và giao dịch quá nhạy cảm
Do thời gian các nút khác nhau có sai số, nên xác minh thời gian không thể quá nhạy cảm, nếu không dễ dẫn đến phân nhánh khối
Logic ủy quyền giao dịch có vấn đề
Bao gồm chủ yếu hai khía cạnh sau:
1. Giả mạo danh tính để vượt qua
2. Kiểm tra quyền sai
1.9 Lỗ hổng mô hình kinh tế
Mô hình kinh tế đóng vai trò quan trọng trong blockchain và hệ thống phân tán, ảnh hưởng đến cơ chế khuyến khích mạng lưới, cấu trúc quản trị và tính bền vững tổng thể. Dưới đây là các điểm cần chú ý chính:
Mô hình kinh tế chuỗi ứng dụng Cosmos (lấy UniChain làm ví dụ)
Chuỗi ứng dụng Cosmos áp dụng mô hình kinh tế lấy khả năng tương tác và mở rộng blockchain làm cốt lõi. Lấy UniChain làm ví dụ, thiết kế mô hình kinh tế của nó không chỉ xem xét lưu thông và sử dụng token trên chuỗi mà còn xem xét nhu cầu của các trường hợp sử dụng khác nhau. Thông qua việc sử dụng Cosmos SDK, UniChain có thể tạo blockchain chuyên biệt theo ứng dụng và thực hiện giao tiếp chéo chuỗi, thúc đẩy chia sẻ tài nguyên và lưu chuyển giá trị giữa các chuỗi khác nhau. Mô hình kinh tế cần chú ý đến lượng phát hành token, tỷ lệ lạm phát, cấu trúc phí giao dịch và cơ chế quản trị trên chuỗi để đảm bảo sự ổn định và thịnh vượng của hệ sinh thái.
Cơ chế khuyến khích có hợp lý hay không
Cơ chế khuyến khích là phần cốt lõi của mô hình kinh tế, ảnh hưởng trực tiếp đến mức độ tham gia của người dùng và nút. Cơ chế khuyến khích hợp lý nên đảm bảo các bên tham gia (như thợ đào, trình xác thực, nhà phát triển và người dùng) đều nhận được phần thưởng công bằng. Cần đánh giá tính bền vững của cấu trúc khuyến khích, đảm bảo có thể hiệu quả ngăn chặn hành vi ác ý và xu hướng tập trung. Ngoài ra, cơ chế khuyến khích cũng nên thích nghi với sự thay đổi thị trường, điều chỉnh theo sự trưởng thành của mạng lưới và sự thay đổi nhu cầu người dùng. Ví dụ, có thiết lập cơ chế thưởng phạt phù hợp hay không, làm thế nào để cân bằng khuyến khích ngắn hạn và dài hạn... đều là những vấn đề cần phân tích sâu.
Tính bền vững kinh tế mạng lưới
Mô hình kinh tế còn cần chú ý đến tính bền vững dài hạn của mạng lưới, bao gồm khuyến khích kinh tế, tạo giá trị và quản lý phân phối giá trị cho các bên trong hệ sinh thái. Cần đánh giá xem có tồn tại tình trạng mất cân bằng kinh tế hoặc lãng phí tài nguyên hay không, đảm bảo tất cả các bên tham gia đều nhận được giá trị hợp lý trong mạng lưới. Ngoài ra, cần phân tích các yếu tố bên ngoài có thể ảnh hưởng đến sự ổn định mạng lưới, như biến động thị trường và thay đổi hành vi người dùng.
Cơ chế phản hồi thị trường
Xây dựng cơ chế phản hồi thị trường hiệu quả, để mô hình kinh tế có thể điều chỉnh theo nhu cầu người dùng và động thái thị trường. Thông qua phân tích dữ liệu định kỳ và phản hồi người dùng, có thể kịp thời nhận diện và sửa chữa các vấn đề tiềm tàng, đảm bảo tính linh hoạt và thích nghi của mô hình kinh tế.
Tác động của cấu trúc quản trị
Thiết kế mô hình kinh tế nên kết hợp với cấu trúc quản trị, đảm bảo người dùng có thể tham gia vào quyết định kinh tế trong quá trình quản trị, từ đó tăng cảm giác tham gia và归属 cộng đồng. Cơ chế quản trị hợp lý có thể thúc đẩy khả năng tự sửa chữa và tối ưu hóa liên tục của mô hình kinh tế, nâng cao sức khỏe tổng thể của mạng lưới.
Sau khi hiểu sâu về các loại lỗ hổng an toàn tồn tại trong hệ sinh thái blockchain, bước tiếp theo là khám phá các bề mặt tấn công cụ thể mà những lỗ hổng này có thể bị lợi dụng. Bề mặt tấn công là các lối vào và đường đi mà kẻ tấn công tiềm tàng có thể khai thác, thông qua việc nhận diện và phân tích các bề mặt tấn công này, có thể đánh giá rủi ro hiệu quả hơn và xây dựng các chiến lược bảo vệ tương ứng. Vì vậy, nắm vững mối quan hệ giữa các loại lỗ hổng và bề mặt tấn công là điều cực kỳ quan trọng để xây dựng hàng rào an ninh blockchain vững chắc. Dưới đây sẽ liệt kê chi tiết các bề mặt tấn công phổ biến trong hệ sinh thái blockchain hiện tại, giúp người đọc hiểu rõ hơn về cách thức hiện thực cụ thể của các mối đe dọa.
2. Danh sách bề mặt tấn công
Dưới đây là danh sách các bề mặt tấn công phổ biến:
4.1 Máy ảo
Bề mặt tấn công: Máy ảo chịu trách nhiệm thực thi hợp đồng thông minh và xử lý bytecode, thường gánh vác logic phức tạp, tồn tại rủi ro tiềm tàng như tấn công gọi lại, tràn số nguyên và tràn bộ nhớ. Ngoài ra, hợp đồng thông minh tiêu tốn tính toán cao có thể gây ra tấn công DoS, dẫn đến cạn kiệt tài nguyên. Hơn nữa, nếu bytecode hợp đồng thông minh chứa lỗ hổng chưa được kiểm toán, dễ dẫn đến thực thi mã tùy ý và nâng quyền.
4.2 Mô-đun phát hiện nút P2P và đồng bộ dữ liệu
Bề mặt tấn công: Nếu chức năng phát hiện và đồng bộ nút P2P được thiết kế không đúng, dễ gặp tấn công Sybil (Sybil Attack), bằng cách giả mạo hàng loạt nút giả để kiểm soát mạng, khiến hiệu suất mạng giảm hoặc thậm chí mất hiệu lực. Việc làm ô nhiễm bảng định tuyến trong quá trình đồng bộ dữ liệu nút có thể ảnh hưởng đến chất lượng kết nối giữa các nút, khiến một số nút không dùng được. Ngoài ra, gói dữ liệu có thể chứa dữ liệu giả mạo hoặc ác ý, khiến nút nhận thông tin sai, từ đó ảnh hưởng đến đồng bộ và đồng thuận.
4.3 Mô-đun phân tích khối
Bề mặt tấn công: Phân tích khối liên quan đến xử lý lượng lớn dữ liệu, nếu mã phân tích tồn tại tràn hoặc xử lý lỗi, có thể bị tấn công bởi khối ác ý, dẫn đến sập dịch vụ hoặc từ chối dịch vụ (DoS). Ngoài ra, việc xác minh định dạng khối không chính xác có thể khiến khối truyền qua mạng bị thay đổi mà không thể nhận diện, từ đó ảnh hưởng đến tính nhất quán toàn mạng.
4.4 Mô-đun phân tích giao dịch
Bề mặt tấn công: Phân tích giao dịch liên quan đến xác minh cấu trúc giao dịch và chữ ký, nếu xử lý không đúng với định dạng giao dịch giả mạo, dữ liệu ác ý hoặc chữ ký bất thường, có thể khiến giao dịch giả mạo được thông qua, tiêu tốn tài nguyên hệ thống. Ngoài ra, nếu tồn tại vấn đề tràn biên giới trong phân tích giao dịch, cũng có thể bị lợi dụng để thực hiện tấn công tiêm nhiễm bộ nhớ.
4.5 Bộ nhớ giao dịch (mempool)
Bề mặt tấn công: Mempool là khu vực lưu trữ tạm thời trước khi giao dịch vào chuỗi, có thể bị lạm dụng để chèn lượng lớn giao dịch không hợp lệ hoặc ác ý, dẫn đến tấn công chiếm dụng bộ nhớ, khiến nút không thể phản hồi yêu cầu bình thường. Ngoài ra, kẻ tấn công ác ý có thể lợi dụng mempool để chèn giao dịch trùng lặp hoặc tần suất cao, gây thêm rủi ro kiệt quệ tài nguyên và DoS.
4.6 Mô-đun giao thức đồng thuận
Bề mặt tấn công: Khi cơ chế đồng thuận được thiết kế không hoàn thiện hoặc bị thao túng, có thể gặp các vấn đề như tấn công double-spend, đào ích kỷ, tấn công 51%. Kẻ tấn công có thể kiểm soát hơn một nửa năng lực tính toán để thực hiện phân nhánh ác ý, ảnh hưởng đến tính hợp pháp của bản ghi giao dịch. Ngoài ra, một số cơ chế đồng thuận khi đối mặt với mạng độ trễ cao hoặc phân vùng, có thể mất hiệu lực do thiếu cơ chế dung sai rõ ràng.
4.7 Giao diện RPC
Bề mặt tấn công: Giao diện RPC là con đường tương tác giữa bên ngoài với nút blockchain, nếu cấu hình quyền truy cập không đúng, có thể dẫn đến truy cập trái phép và rò rỉ dữ liệu. Nếu giao diện RPC đặc quyền không được bảo vệ đúng cách, kẻ tấn công có thể giả mạo yêu cầu thực hiện thao tác quyền cao, từ đó thao túng dữ liệu trên chuỗi. Ngoài ra, giao diện RPC dễ gặp tấn công lũ yêu cầu, khiến nút phản hồi quá tải.
4.8 Mô-đun xử lý nhật ký
Bề mặt tấn công: Mô-đun nhật ký chịu trách nhiệm ghi lại thông tin chi tiết vận hành hệ thống, nếu kẻ tấn công có thể ghi nội dung nhật ký giả mạo thông qua tiêm nhật ký, có thể dẫn đến rò rỉ thông tin nhạy cảm. Nhật ký ghi quá mức cũng có thể bị lợi dụng ác ý gây phình to nhật ký, dẫn đến tiêu tốn tài nguyên lưu trữ hoặc hệ thống không dùng được.
4.9 Phần mềm trung gian mạng
Bề mặt tấn công: Nếu phần mềm trung gian truyền thông blockchain không có cơ chế mã hóa truyền và xác thực danh tính, có thể gặp tấn công man-in-the-middle (MITM), dẫn đến việc gói dữ liệu bị chặn và thay đổi. Ngoài ra, phần mềm trung gian dễ bị tấn công lưu lượng (như DoS) và tấn công lạm dụng giao thức, ảnh hưởng đến truyền thông bình thường của toàn bộ mạng.
4.10 Thuật toán mã hóa
Bề mặt tấn công: Thiết kế và triển khai thuật toán mã hóa liên quan trực tiếp đến an toàn dữ liệu. Nếu tồn tại lỗ hổng va chạm băm, có thể khiến nội dung giao dịch bị giả mạo; nếu thuật toán mã hóa không tuân theo nguyên tắc ngẫu nhiên mạnh, có thể khiến khóa bị rò rỉ. Các cuộc tấn công phổ biến khác bao gồm tấn công kênh bên, ví dụ như quan sát tiêu thụ năng lượng hoặc rò rỉ điện từ trong quá trình thực thi mã hóa để lấy thông tin nhạy cảm.
4.11 Mô hình kinh tế
Bề mặt tấn công: Thiết kế mô hình kinh tế blockchain cần cân bằng khuyến khích các bên, nếu không có thể khiến kẻ tấn công ảnh hưởng đến sự ổn định hệ thống bằng cách thao túng lưu thông token, giảm thưởng thợ đào... Thiết kế khuyến khích không hợp lý trong mô hình kinh tế có thể khiến thợ đào (hoặc nút xác thực) không hành động như dự kiến, mang lại rủi ro tấn công kinh tế.
4.12 Mô-đun lưu trữ dữ liệu
Bề mặt tấn công: Lưu trữ dữ liệu trên chuỗi và ngoài chuỗi tồn tại rủi ro truy cập trái phép, thay đổi và tính bền vững dữ liệu. Kẻ tấn công có thể cố gắng lợi dụng quyền cơ sở dữ liệu không đủ hoặc cơ chế lưu trữ không an toàn để trực tiếp sửa đổi dữ liệu sổ cái hoặc trạng thái hợp đồng thông minh. Ngoài ra, chiến lược lưu trữ dữ liệu không hợp lý có thể dẫn đến phình to dữ liệu, ảnh hưởng đến hiệu suất hệ thống.
4.13 Mô-đun quản lý trạng thái
Bề mặt tấn công: Quản lý trạng thái blockchain dùng để ghi lại dữ liệu quan trọng như số dư tài khoản, lưu trữ hợp đồng... Nếu mô-đun quản lý trạng thái thiết kế không đúng, có thể bị kẻ tấn công lợi dụng, gây lỗi số dư tài khoản hoặc thay đổi thông tin trạng thái. Kẻ tấn công ác ý cũng có thể tạo giao dịch đặc biệt để gây cướp trạng thái, dẫn đến khóa tài nguyên.
Kết luận
Tóm lại, mặc dù hệ sinh thái blockchain đầy tiềm năng đổi mới và phát triển, nhưng vấn đề an ninh của nó cũng không thể xem nhẹ. Bài viết này chi tiết thảo luận các loại lỗ hổng an toàn từ nhiều lĩnh vực then chốt như giao tiếp chéo chuỗi, chuỗi ứng dụng Cosmos, hệ sinh thái mở rộng Bitcoin, đến các lỗ hổng ngôn ngữ lập trình, lỗ hổng mạng P2P, tấn công DoS, lỗ hổng mật mã học và an toàn sổ cái. Thông qua phân tích và khái quát hệ thống, nhằm giúp các nhà phát triển và chuyên gia an ninh nhận diện rủi ro tiềm tàng, thực hiện các biện pháp phòng ngừa hiệu quả, nâng cao mức độ an toàn tổng thể. Trước những thách thức an ninh ngày càng phức tạp và đa dạng, chỉ khi không ngừng tăng cường năng lực bảo vệ kỹ thuật, hoàn thiện cơ chế kiểm toán an ninh và thúc đẩy hợp tác, trao đổi trong ngành, mới có thể đảm bảo sự phát triển lành mạnh và bền vững của công nghệ blockchain. ScaleBit cùng công ty mẹ BitsLab sẽ tiếp tục cam kết nghiên cứu an ninh blockchain, cung cấp các giải pháp an ninh tiên phong, góp phần xây dựng hệ sinh thái blockchain vững chắc và đáng tin cậy hơn.
Đọc và tải xuống Báo cáo Quan sát Toàn cảnh và Nghiên cứu An toàn Hệ sinh thái Công cộng Mới nổi 2024: Chào mừng tham gia cộng đồng chính thức TechFlow Nhóm Telegram:https://t.me/TechFlowDaily Tài khoản Twitter chính thức:https://x.com/TechFlowPost Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@scalebit_
