Các nhà phát triển bitcoin lần đầu tiên tiết lộ chi tiết kỹ thuật và quy trình phát hiện lỗ hổng bảo mật Lightning Network

Tiêu đề gốc: "Chi tiết kỹ thuật và quy trình khám phá các lỗ hổng bảo mật mạng Lightning"

Nguồn gốc: Rusty Russell. Nhà phát triển bitcoin, nhà phát triển Lightning Network

Bản dịch gốc: Babbitt

Tác giả của bài viết này, Rusty Russell, là một nhà phát triển nổi tiếng của nhân Linux, hiện tham gia Blockstream để phát triển Bitcoin, tập trung vào phát triển nguyên mẫu Lightning Network của Bitcoin.

Vài ngày trước, nhà phát triển Rusty Russell Chi tiết kỹ thuật về các lỗ hổng bảo mật Lightning Network và các giải pháp tương ứng lần đầu tiên được tiết lộ.

Dưới đây là chi tiết kỹ thuật:

Nút Lightning Network chấp nhận kênh phải kiểm tra xem giao dịch cấp vốn có đầu ra là xác thực Kênh được đề xuất đã được mở, nếu không kẻ tấn công có thể yêu cầu mở một kênh và sau đó không thanh toán ngang hàng hoặc không thanh toán đầy đủ.

Sau khi giao dịch đạt đến độ sâu tối thiểu, giao dịch đó có thể tiêu tiền từ kênh. Nạn nhân chỉ nhận thấy hành vi nguy hiểm này khi họ cố gắng đóng kênh và mọi cam kết hoặc giao dịch lẫn nhau đều trở nên vô hiệu.

Các máy khách Lightning không nhất thiết phải thực hiện việc kiểm tra này:

c-lightning: v0.7.1 và các máy khách cao hơn thực hiện việc này một cách chính xác, trong khi phiên bản máy khách c-lightning trước đó không thể thực hiện được. (CVE-2019-12998)

1. Lỗ hổng này có thể bị khai thác bằng cách kết nối với một thiết bị ngang hàng và yêu cầu mở một kênh với bất kỳ id giao dịch nào.

lnd: v0.7.1 và các máy khách mới hơn giải quyết được vấn đề này, nhưng các phiên bản trước của lnd không kiểm tra số lượng. Các máy khách v0.7.0 trở lên kiểm tra chính xác scriptpubkey, các máy khách v0.6.x thực thi một phần việc cấp vốn cho ScriptPubkey, nhưng các máy khách trước v0.6.0 hoàn toàn không thực hiện việc xác thực này. (CVE-2019-12999)

1. Đối với tất cả các phiên bản trước của máy khách lnd, kẻ tấn công có thể vượt qua Không chính xác số lượng đã được sử dụng để tấn công. Kể từ phiên bản 0.7.0, kẻ tấn công phải sử dụng đúng scriptpubkey, thao tác này sẽ đốt tiền trong đầu ra cấp vốn.

2. Đối với các máy khách trước v0.6.0, kẻ tấn công có thể đạt được điều này thông qua tấn công scriptpubkey không chính xác. Trong ứng dụng khách v0.6.x, nếu giao dịch cấp vốn đạt đến số lượng xác nhận cần thiết, txindex=0 được chạy trên bất kỳ chương trình phụ trợ nút đầy đủ nào và nút đó ngoại tuyến thì lỗ hổng này cũng có thể bị khai thác.

3. Sử dụng sai outpoint để tấn công neutrino client (thường là di động hoặc laptop) người dùng yêu cầu kẻ tấn công Va chạm giả mạo của nó outpoint bằng tập lệnh outpoint thực trong bộ lọc BIP 158. Khóa siphash được sử dụng để tạo bộ lọc có nguồn gốc từ blockhash. Do đó, kẻ tấn công không thể tấn công trực tiếp mà không biết trước khối băm. Ngoài ra, các nút máy khách neutrino thường không lắng nghe hoặc có địa chỉ được quảng cáo, nghĩa là kẻ tấn công phải đợi cho đến khi nhận được kết nối gửi đến trước khi thực hiện cuộc tấn công.

eclair: Ứng dụng khách v0.3.1 trở lên giải quyết chính xác các rủi ro bảo mật. Nếu người dùng sử dụng bitcoin core As là phần phụ trợ, các phiên bản trước của ứng dụng khách eclair sẽ gặp rủi ro về bảo mật. Và người dùng Electrum chỉ kiểm tra kịch bản chứ không kiểm tra số lượng. (CVE-2019-13000)

1. Để tấn công người dùng máy khách Electrum (di động), người dùng phải chủ động kết nối với các nút Lightning Network độc hại và kẻ tấn công sử dụng đúng scriptpubkey. Điều này sẽ đốt tiền trong sản lượng tài trợ. Vì ứng dụng khách di động Eclair không chuyển tiếp thanh toán nên kẻ tấn công không thể rút tiền mà không có tương tác ngoài băng tần (ví dụ: bán thứ gì đó cho người dùng và thanh toán bằng tiền từ kênh giả).

Giải pháp

Sau khi quan sát thấy giao dịch cấp vốn, thiết bị ngang hàng phải kiểm tra `funding_created`[1 ] Liệu điểm cuối được mô tả trong `open_channel`[3] là đầu ra giao dịch cấp vốn[2] của số tiền được mô tả trong `open_channel`[3].

Nền

Để mở kênh Lightning Network, bên cấp vốn gửi đề xuất với `funding_satoshis` (số tiền ) của `open_channel`. Người được cấp trả lời bằng `accept_channel`, cung cấp khóa mà họ muốn sử dụng cho giao dịch cấp vốn. Sau đó, nhà cấp vốn tạo giao dịch cấp vốn và gửi id giao dịch cũng như số đầu ra trong thông báo `funding_created`.

Nút A là "nhà tài trợ" và nút B là "người được tài trợ"

Với thông tin này, The " người được tài trợ" có thể tạo chữ ký trên "giao dịch cam kết" đầu tiên và gửi nó trong tin nhắn `funding_signed` để nếu có sự cố xảy ra, nhà tài trợ có thể lấy lại tiền của họ. Bằng cách này, nhà đầu tư có thể ký và phát sóng giao dịch mở một cách an toàn. Sau một số xác nhận nhất định (do "người nhận tài trợ đặt ra"), kênh sẽ bắt đầu hoạt động (`funding_locked`).
Thông số kỹ thuật mô tả rõ ràng các yêu cầu để kiểm tra xem các chữ ký khác nhau được trao đổi có thực sự cho phép tạo giao dịch cam kết hợp lệ hay không[4] và mô tả thời gian chờ Yêu cầu xác nhận [5].

Tuy nhiên, nó không yêu cầu người nhận phải thực sự kiểm tra xem giao dịch có đúng như những gì nhà tài trợ đã hứa hay không: bao gồm số tiền và scriptpubkey thực tế .

Quy trình phát hiện lỗ hổng

Rusty Russell (Blockstream) đã phát hiện ra lỗ hổng này trong khi tiến hành thử nghiệm giao thức cho chính thông số kỹ thuật đó, đồng thời bổ sung thêm một số tính năng mới được đề xuất [6].

Khi viết bài kiểm tra, công cụ mở kênh đã cung cấp `funding_output_index` không chính xác trong thông báo `funding_created`, Russell Nhận ra rằng C- Máy khách Lightning sẽ không từ chối nó, bởi vì C-Lightning chỉ kiểm tra số lượng xác nhận của `funding_txid`, thậm chí không kiểm tra xem `funding_output_index` có tồn tại hay không!

Yêu cầu này không được đề cập trong đặc tả, vì vậy Rusty ngay lập tức hỗ trợ các khách hàng được sử dụng rộng rãi khác (eclair và lnd) đã phát hiện ra vấn đề này. Sau khi điều tra, họ phát hiện ra rằng vấn đề như vậy đã tồn tại. Vì vậy, một số nhóm đã đưa ra quyết định âm thầm khắc phục các sự cố này trong phiên bản mới của máy khách và sau đó tám tuần (sau khi hầu hết người dùng đã hoàn tất nâng cấp), bản thân các sự cố sẽ lộ ra và bốn tuần sau, họ sẽ Chỉ tiết lộ đầy đủ lỗ hổng.

Rất may, lỗ hổng tồn tại lâu đời này chưa bị khai thác rộng rãi và nó cung cấp bản thử nghiệm cho toàn bộ hệ sinh thái Lightning Network. cho các phương pháp liên lạc và nâng cấp hệ thống.

Dòng thời gian về lỗ hổng

27/06/2019: Rusty Russell đã phát hiện ra lỗ hổng và thông báo cho các tác giả khách hàng LND và Eclair;

2019- 06- Ngày 28: Số lỗ hổng CVE đã được chỉ định;

2019-07-02: Phát hành ứng dụng khách lnd v0.7.0-beta;

2019-07-03: Phát hành ứng dụng khách Eclair 0.3.1;

2019-07-04: phát hành ứng dụng khách c-lightning 0.7.1;

2019 -07-06: Rusty Russell và những người khác bắt đầu tiết lộ các lỗ hổng cho các tác giả khách hàng khác (rust-lightning, ptarmigan, BLW);

2019-07-30 : lnd v0.7.1-beta client đã được phát hành;

17/08/2019: [Theo trạng thái triển khai/ Vui lòng kiểm tra ngày tiếp theo về vấn đề này];

2019-08-30: Sự tồn tại của lỗ hổng CVE được tiết lộ cho công chúng và người dùng sử dụng phiên bản cũ hơn các phiên bản của máy khách nên Nâng cấp;

2019-09-07: Lần đầu tiên, ai đó đã cố gắng khai thác lỗ hổng này;

27/09/2019: Tiết lộ đầy đủ chi tiết về lỗ hổng CVE;

2019- 09-27: Gửi PR theo yêu cầu kỹ thuật.

Bản dịch gốc của Babbitt: https://www.8btc.com/article/489415

[1] https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/02-peer-protocol.md#the-funding_created-message

[2] https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/03-transactions.md # tài trợ-giao dịch-đầu ra

[3] https://github.com/lightningnetwork/lightning-rfc/blob/v1 . 0/02-peer-protocol.md#the-open_channel-message

[4] https://github.com / Lightningnetwork/lightning-rfc/blob/v1.0/02-peer-protocol.md#requirements-2

[5 ] https://github.com/lightningnetwork/lightning-rfc/blob/v1.0/02-peer-protocol.md#the-funding_locked-message

[6] https://github.com/ElementsProject/lightning-rfc-protocol-test

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia