SignalPlus宏观分析特别版: Negative Revisions
10 giờ trước
PeckShield: Giao thức bZx lại bị tin tặc tấn công và công nghệ đằng sau "cuộc tấn công hai tổ hợp"
PeckShield
2020-02-20 10:21
本文约2515字，阅读全文需要约10分钟
Vào ngày 18 tháng 2, bZx lại gặp phải một cuộc tấn công tương tự, nguyên tắc kỹ thuật của cuộc tấn công này khác với lần trước, lần này hacker đã "lừa" hợp đồng bZx bằng cách thao túng
PeckShield: Phân tích công nghệ cốt lõi, toàn cảnh vụ giao thức bZx bị tin tặc tấn côngPeckShield: Phân tích công nghệ cốt lõi, toàn cảnh vụ giao thức bZx bị tin tặc tấn công"Trong phân tích, bZx đã bị tin tặc tấn công bằng một cuộc tấn công thanh khoản vào tài sản danh mục đầu tư vào ngày 15 tháng 2, nguyên nhân là do phán đoán không hoàn hảo về tình trạng tài sản thế chấp của hợp đồng bZx.
Vào ngày 18 tháng 2, bZx lại gặp phải một cuộc tấn công tương tự, nguyên tắc kỹ thuật của cuộc tấn công này khác với lần trước, lần này hacker đã "lừa" hợp đồng bZx bằng cách thao túng giá Oracle.
Từ góc độ của quá trình tấn công, lần này ngược lại với lần trước, nhưng phương pháp chênh lệch tổng thể vẫn giống nhau, nguyên nhân chủ yếu là do thanh khoản chia sẻ nhỏ giữa các nền tảng và lỗ hổng thiết kế trong cơ chế giá .
Figure: Five Exploitation Steps With Oracle Manipulation
Mục đích ban đầu của bài viết này là phân tích một số chi tiết tấn công của lỗ hổng này để mọi người có thể hiểu trực quan hơn về cuộc tấn công và hy vọng nó có thể dẫn đến các cuộc thảo luận chuyên sâu hơn. Chúng tôi tin rằng những cuộc thảo luận này sẽ rất có lợi cho việc cải thiện và phát triển cộng đồng DeFi, đặc biệt là khi bên dự án đang phát triển thế hệ sản phẩm DeFi tiếp theo, nó có thể giúp thiết kế một mô hình chia sẻ thanh khoản an toàn và đáng tin cậy hơn.
Các chi tiết tấn công của lỗ hổng như sau:
tiêu đề cấp đầu tiên
Bước 1: Cho vay chớp nhoáng để lấy tài sản sẵn có
Hợp đồng bZx có giao diện flashBorrowToken(), cho phép người gọi mượn tài sản từ nền tảng bZx để tham gia vào các hoạt động DeFi với "chi phí bằng không", sau đó hoàn trả phần tài sản này khi giao dịch hoàn tất. Và người gọi có thể chỉ định địa chỉ người nhận tài sản trong khi cho mượn tài sản.
Figure1: Flashloan Borrowing From bZx
Lần này, kẻ tấn công đã cho nền tảng bZx vay 7.500 ETH và chỉ định hợp đồng của kẻ tấn công (đã được triển khai trước đó) làm địa chỉ của người nhận tài sản. Phần này là chức năng cho vay cơ bản và sẽ không được giải thích thêm ở đây.
tiêu đề cấp đầu tiên
Bước 2: Tăng sUSD
Trước hết, hãy giới thiệu vai trò hỗ trợ tốt nhất của những kẻ tấn công ngày nay: sUSD, sUSD là một loại tiền tệ ổn định do bên dự án Synthetix phát hành, giá tiền tệ của nó thường bằng 1 đô la Mỹ và tổng số lượng lưu thông là 5.563.037 miếng (thống kê vào tháng 2 2020 18).
Sau khi lấy được ETH thông qua khoản vay chớp nhoáng đầu tiên, kẻ tấn công đã chia tổng cộng 900 ETH thành sUSD thông qua KyberNetwork DEX thành hai đợt. Trong số đó, 540 ETH được đổi lần đầu, (giá KyberUniswap thu được từ truy vấn nội bộ của KyberNetwork là tốt nhất), kẻ tấn công lấy được 92.419 sUSD; đợt thứ hai được chia thành 18 lần, mỗi lần đổi 20 ETH, (Kyber- sUSD đã được xác nhận sau khi truy vấn KyberNetwork Giá phù hợp nhất), kẻ tấn công đã lấy được 63.584 sUSD và thu được tổng cộng 156.003 sUSD.
Figure2: Pumping With Kyber (and Uniswap)
Hai bước này cũng là một quy trình trao đổi DEX bình thường, sau hai đợt hoạt động này, giá sUSD sang ETH tăng vọt lên 0,00899, gấp 2,5 lần giá thị trường.
tiêu đề cấp đầu tiên
Bước thứ ba: hấp thụ nhiều chip hơn
Kẻ tấn công hy vọng sẽ đổi tất cả 6.000 ETH trong tay của mình thành sUSD thông qua giao diện Synthetix exchangeEtherForSynths(). Và Synthetix không có đủ sUSD để thực hiện giao dịch này, chỉ trao đổi 3.518 ETH và trả lại 2.482 ETH còn lại cho kẻ tấn công và kẻ tấn công đã lấy được 943.837 sUSD.
Figure3：Hoarding From Synthetix
Cho đến nay, kẻ tấn công có tổng cộng 1.099.841 sUSD, chiếm 19,7% tổng lượng lưu thông.
tiêu đề cấp đầu tiên
Bước bốn: Vay thế chấp
Kẻ tấn công đã thế chấp tất cả 1.099.841 sUSD trong tay của mình vào hợp đồng bZx thông qua giao diện loanTokenFromDeposit() của bZx. Theo giá thông thường của sUSD/ETH, bZx lẽ ra phải cho kẻ tấn công vay 3.928 ETH, nhưng bZx đã lấy được từ Oracle Kyber Giá of quá cao, do đó 6.796 ETH đã được cho vay và 2.868 ETH đã được vay thêm.
Figure4: Collateralized Borrowing From bZx
tiêu đề cấp đầu tiên
Bước 5: Thanh toán khoản vay nhanh
Kẻ tấn công đã sử dụng 6.796 ETH đã vay từ bZx và tài sản còn lại trong tay để trả lại 7.500 ETH đã vay trước đó từ bZx, sau đó rời đi để hoàn tất hoạt động cho vay nhanh.
Figure5: Repay The Flashloan To bZx
Sau khi hoàn tất toàn bộ quy trình flash loan, tình hình tài sản hiện tại:
1) Nền tảng bZx đã cho kẻ tấn công vay 6.796 ETH;
2) Nền tảng bZx nắm giữ 1.099.841 sUSD;
3) Kẻ tấn công vẫn giữ 2.378 ETH.
Cuối cùng, 2.378 ETH do kẻ tấn công nắm giữ đã mang lại lợi nhuận cho anh ta, tổng cộng là $665.840tóm tắt
tóm tắt
Trong cuộc tấn công này, chúng ta có thể thấy một số vấn đề rõ ràng trong quá trình thiết kế các sản phẩm DeFi:
1) Khi giới thiệu Mã thông báo của bên thứ ba, cần kiểm tra tính bảo mật của Mã thông báo của bên thứ ba, liệu có thể bị thị trường đơn phương thao túng, từ đó gây ra biến động giá hay không;
2) Bản thân nền tảng DeFi phải có cơ chế kiểm tra và chấp nhận giá, khi sử dụng Oracle của bên thứ ba để lấy giá, dữ liệu của các bên khác phải được xác minh càng nhiều càng tốt;
3) Bản thân giàn cũng nên thiết lập cơ cấu van chặn nước cho giá.
Việc mất 1.271 ETH từ cuộc tấn công bZx đầu tiên và mất 2.378 ETH lần này và sự khác biệt giữa hai cuộc tấn công chỉ là 3 ngày, cho thấy vấn đề bảo mật của các dự án đặc biệt DeFi là rất nghiêm trọng.
Vì mỗi dự án được phát triển bởi các nhóm khác nhau và họ có hiểu biết hạn chế về thiết kế và triển khai các sản phẩm tương ứng, nên các sản phẩm tích hợp có thể gặp sự cố bảo mật trong quá trình tương tác với nền tảng của bên thứ ba, sau đó bị kẻ thù tấn công. PeckShield theo đây đề xuất rằng trước khi dự án DeFi đi vào hoạt động, nên cố gắng hết sức để tìm một nhóm có nghiên cứu chuyên sâu về thiết kế sản phẩm của từng liên kết DeFi để thực hiện kiểm tra bảo mật hoàn chỉnh nhằm tránh các rủi ro bảo mật tiềm ẩn.
PeckShield
作者文库
推荐文章
