Những người vận hành node Lightning đang bước vào một đợt kiểm tra an ninh khẩn cấp. Hôm qua, BTCPay Server – tự xưng là giải pháp thanh toán Bitcoin không phí, không trung gian – cùng với Lightning Network Daemon (LND) đã đưa ra bản vá bảo mật cho một lỗ hổng được đánh giá nghiêm trọng. Thông báo ngắn gọn, nhưng đủ sức làm đảo lộn thói quen quản lý khóa của hàng chục nghìn người dùng. Kẻ tấn công không cần tài khoản, không cần mật khẩu, thậm chí không cần biết bất kỳ thông tin nào về nạn nhân. Chúng chỉ cần tìm ra node của bạn và tải về một tệp tin nhỏ, có tên là admin.macaroon. Sau đó, chúng có thể rút hết số Bitcoin trong các kênh thanh toán, mà không để lại dấu vết nào ngoài một giao dịch đã ký hợp lệ.
Tôi còn nhớ cảm giác đọc dòng tin này.Trong nhiều năm làm kiểm toán hợp đồng thông minh, tôi đã thấy không ít lỗ hổng tương tự – những lỗ hổng không đến từ thuật toán phức tạp, mà đến từ một giả định tưởng chừng vô hại: thư mục chứa khóa sẽ không bao giờ bị truy cập từ bên ngoài. Khi giả định đó sụp đổ, toàn bộ mô hình bảo mật sụp đổ theo. Và lần này, nó xảy ra với một trong những phần mềm tự quản lý được tin dùng nhất trong cộng đồng Bitcoin.
BTCPay Server không phải là một cái tên xa lạ. Từ những ngày đầu của phong trào chấp nhận Bitcoin, nó đã trở thành lựa chọn hàng đầu cho các doanh nghiệp nhỏ, các nhà sáng tạo nội dung và những người theo chủ nghĩa tự do tài chính. Với khẩu hiệu “zero fee, zero middleman”, nó cho phép một cửa hàng chạy trên máy chủ riêng, kết nối trực tiếp với node Bitcoin và node Lightning, và xử lý thanh toán mà không phải trả phí phần trăm cho bất kỳ ai. Trong một thế giới mà OpenNode hay Strike thu 1% phí cho mỗi giao dịch, đây là một lời hứa hấp dẫn.
Nhưng lời hứa đó đi kèm một cái giá thầm lặng. Người dùng tự chịu trách nhiệm về bảo mật hệ thống của mình. Họ phải biết cách cập nhật Docker image, cấu hình nginx, quản lý SSL certificate, theo dõi log. Phần lớn người dùng không phải là kỹ sư hạ tầng. Họ là chủ cửa hàng cà phê, nhà văn, lập trình viên tự do. Và bởi vì không có một đội ngũ hỗ trợ tập trung nào đứng sau, nên khi một lỗ hổng xuất hiện, họ phải tự cứu mình.
Lỗ hổng lần này nằm ở cách BTCPay Server quản lý các tệp tin xác thực của LND. Nếu bạn chưa từng nghe về LND, nó là một trong những phần mềm phổ biến nhất để chạy node Lightning. LND quản lý các kênh thanh toán, theo dõi số dư trong các hợp đồng thông minh trên Lightning, và thực hiện lệnh chuyển tiền khi có yêu cầu. Để ứng dụng bên ngoài – ví như BTCPay Server – có thể điều khiển LND, LND phát hành một loại “vé thông hành” gọi là macaroon. Đây là một chuỗi mã hóa chứa thông tin về quyền hạn: quyền đọc số dư, quyền tạo hóa đơn, quyền gửi thanh toán, quyền đóng kênh. Một file macaroon với quyền admin còn có thể rút toàn bộ tiền trong node về một địa chỉ do kẻ tấn công kiểm soát.
Theo mô tả trong thông báo an ninh, kẻ tấn công chưa được xác thực có thể truy cập từ xa vào các tệp .macaroon này. Nghĩa là không cần bất kỳ thông tin nào, chỉ cần gửi một yêu cầu HTTP tới máy chủ của nạn nhân, kẻ tấn công có thể tải về chiếc chìa khóa vạn năng. Thông báo cũng xác nhận lỗ hổng đã bị khai thác thực tế và gây mất tiền. Điều đó đưa mức độ nghiêm trọng lên hàng đầu, bởi vì kết hợp giữa “chưa cần xác thực” và “truy cập từ xa” luôn là cơn ác mộng với bất kỳ hệ thống nào.
Từ những manh mối công khai, tôi suy đoán đây có thể là một lỗ hổng path traversal, tức lỗ hổng điều hướng đường dẫn. Trong một ứng dụng web, thông thường máy chủ sẽ phục vụ các tệp tĩnh như hình ảnh, CSS, JavaScript từ một thư mục đã được chỉ định. Nếu lập trình viên không kiểm tra chuỗi đường dẫn do người dùng gửi lên, kẻ tấn công có thể chèn chuỗi ../ để trở về thư mục gốc của hệ điều hành. Ví dụ, thay vì yêu cầu /static/css/style.css, chúng gửi /static/../../.lnd/data/chain/bitcoin/mainnet/admin.macaroon. Nếu máy chủ không chuẩn hóa đường dẫn, nó sẽ mở đúng tệp khóa. Kẻ tấn công không cần phải phá mã hóa, không cần brute-force. Chúng chỉ cần lách qua một lớp kiểm tra.
Một khả năng khác là lỗ hổng đến từ cấu hình sai khi BTCPay Server proxy các yêu cầu tới LND. Trong một số thiết lập, BTCPay Server đóng vai trò trung gian để trình duyệt của người dùng gọi API của LND mà không lộ key. Nếu nginx hoặc Caddy được cấu hình không đúng, thư mục dữ liệu của LND có thể vô tình nằm trong vùng public. Trong cả hai trường hợp, kết quả đều giống nhau: một lỗ hổng ở tầng access control, không phải lỗ hổng trong logic nghiệp vụ phức tạp. Điều này giải thích vì sao hai bản vá được phát hành đồng thời: một cho BTCPay Server 2.4.2, một cho LND 0.21.1. Có thể bản vá của BTCPay Server chặn các đường dẫn bất hợp pháp, còn bản vá của LND tăng cường kiểm tra quyền và bổ sung hàng rào bảo vệ.
Điều đáng chú ý là thông báo an ninh không cung cấp chi tiết kỹ thuật, không nêu rõ cách khai thác, và cũng không tiết lộ tổng số tiền bị đánh cắp. Đây là một cách tiếp cận thận trọng, đúng chuẩn. Trong giai đoạn đầu của một vụ việc bảo mật, tiết lộ quá nhiều chi tiết có thể tạo điều kiện cho kẻ xấu viết exploit. Nhưng nó cũng có nghĩa cộng đồng vẫn đang trong vùng tối. Chúng tôi – những người làm bảo mật – phải dựa trên các dấu hiệu để phán đoán. Tôi đánh giá rủi ro thực tế của lỗ hổng này ở mức rất cao, không chỉ vì tính chất kỹ thuật mà còn vì quy mô triển khai.
Hãy nhìn vào những con số. Trên GitHub, dự án BTCPay Server đã vượt mốc một triệu lượt tải về. Số lượng instance đang hoạt động ước tính vài trăm nghìn. Không phải tất cả các instance này đều mở ra internet, nhưng với một node thanh toán thương mại, mở cổng 80 và 443 là điều gần như bắt buộc. Điều đó có nghĩa hàng chục nghìn máy chủ đang phơi bày bề mặt tấn công. Trong một khoảng thời gian từ khi lỗ hổng xuất hiện cho đến khi được vá, kẻ tấn công có thể quét toàn bộ IPv4 để tìm kiếm các BTCPay Server có dấu hiệu lộ đường dẫn. Đây là điều mà các bot tự động làm rất tốt, và chúng không cần nhắm mục tiêu cá nhân. Chúng tấn công trên diện rộng và chỉ cần một số ít nạn nhân sơ hở là đủ.
Nếu bạn là người đang vận hành một BTCPay Server, hãy nâng cấp ngay lập tức. Không phải ngày mai. Không phải cuối tuần. Ngay bây giờ. Phiên bản 2.4.2 dành cho BTCPay Server và phiên bản 0.21.1 dành cho LND là hai mảnh ghép cần phải có. Trì hoãn dù chỉ một ngày cũng là liều lĩnh, bởi vì trong thế giới tài sản số, thời gian vuln tồn tại tỷ lệ nghịch với khả năng bị khai thác trên quy mô lớn.
Sau khi nâng cấp, bạn cần kiểm tra thêm vài thứ. Đầu tiên, hãy rà soát cấu hình web server. Nếu bạn đang dùng nginx, hãy chắc chắn rằng alias và root không trỏ vào thư mục dữ liệu của LND. Thứ hai, hãy áp dụng nguyên tắc đặc quyền tối thiểu: tạo một macaroon chỉ có quyền tạo hóa đơn và kiểm tra số dư, thay vì dùng admin.macaroon cho mọi tác vụ. Nếu BTCPay Server chỉ cần quyền tạo hóa đơn, đừng cấp cho nó quyền rút tiền. Thứ ba, hãy bật xác thực hai lớp và hạn chế IP truy cập vào các endpoint quản trị. Những biện pháp này không thể chặn một lỗ hổng path traversal, nhưng nó sẽ khiến kẻ tấn công phải làm việc vất vả hơn.
Với tôi, lỗ hổng này là một lời nhắc về tầm quan trọng của việc kiểm tra access control. Trong các buổi kiểm toán hợp đồng thông minh, tôi thường nói với đội ngũ phát triển rằng: đừng chỉ tập trung vào các hàm xử lý tiền, hãy nhìn vào những hàm đọc dữ liệu, những endpoint tưởng chừng vô hại. Bởi vì một tham số đường dẫn không được lọc, một quyền hạn quá rộng, hay một biến môi trường bị rò rỉ – tất cả đều có thể mở ra con đường trực tiếp đến tài sản. Lần này, thứ bị rò rỉ là macaroon; lần khác, nó có thể là khóa riêng, database, hoặc biến môi trường chứa mã thông báo quản trị.
Sự kiện BTCPay Server cũng đặt ra một câu hỏi khó chịu cho toàn ngành. Khi chúng ta nói về “tự quản lý”, chúng ta thường hình dung một chiếc ví lạnh – nơi khóa riêng nằm im trong một thiết bị không kết nối internet. Nhưng thực tế, với các dịch vụ thanh toán chấp nhận Lightning, bạn buộc phải để một phần tài sản trong node “nóng”. Node đó phải online 24/7, phải giao tiếp với internet, phải chạy các phần mềm phức tạp như LND và BTCPay Server. Đây chính là điểm yếu: khi bạn tham gia mạng lưới để nhận thanh toán, bạn đã bước ra khỏi ranh giới của ví lạnh. Và nếu không có năng lực bảo trì phù hợp, bạn đang tự đặt mình vào vùng rủi ro cao.
Chính vì vậy, thông báo “ví on-chain không bị ảnh hưởng” trong thông cáo của BTCPay Server, theo quan điểm của tôi, là một sự trấn an mang tính kỹ thuật nhưng dễ gây hiểu lầm. Đúng, Bitcoin nằm trong ví cold do bạn tự tạo có thể an toàn – nếu bạn không nhập mnemonic vào một máy tính online. Nhưng đối với người dùng LND, số dư trong node Lightning thường bao gồm cả những Bitcoin được dùng để mở kênh và cũng có thể là những Bitcoin được gửi vào ví nóng do LND quản lý. Kẻ tấn công chiếm được admin.macaroon có thể đóng kênh và rút toàn bộ số dư về địa chỉ của chúng. Đối với những người dùng đã mở nhiều kênh với số dư lớn, số tiền này không hề nhỏ. Và ngay cả khi kẻ tấn công không rút tiền, việc lộ macaroon cũng có nghĩa chúng đọc được toàn bộ lịch sử giao dịch, biết rõ dòng tiền của bạn. Đó là một vi phạm quyền riêng tư nghiêm trọng.
Bối cảnh thị trường càng khiến câu chuyện thêm phần căng thẳng. Hiện tại, thị trường tiền mã hóa đang trong giai đoạn giảm. Thanh khoản kém, tâm lý bi quan, và các khoản đầu tư đang bị thu hẹp. Trong môi trường như vậy, một vụ tấn công xảy ra có thể tạo ra phản ứng dây chuyền. Các nhà đầu tư sẽ nhìn vào sự kiện này như một minh chứng rằng các giải pháp phi tập trung vẫn chưa đủ an toàn để áp dụng đại trà. Các merchant đang cân nhắc chấp nhận Lightning có thể lùi bước. Điều này làm suy yếu một trong những luận điểm quan trọng nhất của Bitcoin: trở thành một mạng lưới thanh toán không cần trung gian.
Nhưng ở chiều ngược lại, tôi cho rằng đây không phải là ngày tận thế của Lightning, mà là một hồi chuông cảnh tỉnh. Mã nguồn mở có một lợi thế mà các hệ thống tập trung không bao giờ có: khả năng phản ứng cộng đồng cực kỳ nhanh. Chỉ trong vài giờ sau khi lỗ hổng được xác nhận, cả hai bản vá đã được phát hành, thông báo an ninh được soạn thảo, và hướng dẫn nâng cấp được phổ biến rộng rãi. Nếu đây là một công ty tài chính truyền thống, quy trình phê duyệt nội bộ và kiểm toán trước khi phát hành có thể kéo dài hàng tuần. Sự nhanh nhạy đó là một minh chứng rõ ràng cho sức sống của cộng đồng. Vấn đề còn lại chỉ là làm sao để kéo người dùng đi cùng.
Nếu nhìn vào lịch sử các vụ tấn công DeFi lớn, chúng ta sẽ thấy một quy luật: mỗi một cuộc khủng hoảng bảo mật đều để lại những bài học được đúc kết thành công cụ và quy trình tốt hơn. Vụ hack Parity năm 2017 dạy chúng ta về phá hủy hợp đồng. Vụ tấn công flash loan năm 2020 dạy chúng ta về oracle price. Vụ sập Terra Luna năm 2022 dạy chúng ta về thiết kế stablecoin. Và vụ này sẽ dạy chúng ta về quản lý tệp tin xác thực trong các ứng dụng thanh toán tự quản lý. Tôi tin rằng sau sự kiện, BTCPay Server và LND sẽ phải tăng cường quy trình bảo mật: bổ sung các bài kiểm tra bảo mật tự động, mời các công ty kiểm toán độc lập, và có thể thành lập một quỹ bug bounty với mức thưởng hấp dẫn. Đây chính là cách một dự án trưởng thành sau khủng hoảng.
Điều đáng nói là lỗ hổng này không liên quan đến một đồng coin hay token mới phát hành. Nó xảy ra trên những công cụ hạ tầng đã tồn tại nhiều năm. Điều này nhắc nhở chúng ta rằng bảo mật không phải là một trạng thái tĩnh. Ngay cả phần mềm được đánh giá cao, được tải về hơn một triệu lần, vẫn có thể mắc những lỗi cơ bản. Ngày hôm qua mọi thứ đều ổn, hôm nay bạn có thể mất sạch.
Trong một cuộc phỏng vấn gần đây, ai đó hỏi tôi rằng: “Liệu anh có đặt toàn bộ tài sản của mình vào một giải pháp tự quản lý không?” Câu trả lời của tôi là: “Nếu tôi có số tiền lớn, tôi sẽ không đặt nó trong một node Lightning đang chạy trên VPS. Tôi sẽ tách bạch: một phần nhỏ cho thanh toán hàng ngày, phần lớn để trong ví lạnh. Và nếu tôi cần chấp nhận thanh toán Lightning, tôi sẽ thuê một chuyên gia vận hành hoặc sử dụng giải pháp lai.” Điều đó nghe có vẻ phản bội tinh thần tự quản lý, nhưng thực ra nó là sự quản lý rủi ro đúng đắn. Bạn không cần phải là một chiến binh tự do tài chính và xem thường sự an toàn của mình.
Sự kiện BTCPay Server lần này nếu xét trên khía cạnh pháp lý, nó không chạm đến nhiều vấn đề mới. BTCPay Server là phần mềm mã nguồn mở, không có chủ sở hữu hợp pháp duy nhất, không có công ty đứng sau chịu trách nhiệm. Người dùng có thể kiện ai? Không ai cả. Họ chỉ có thể tự trách mình đã không nâng cấp kịp thời. Tuy nhiên, nếu merchant sử dụng BTCPay Server bị tấn công và làm lộ dữ liệu khách hàng, họ có thể bị quy trách nhiệm theo các quy định bảo vệ dữ liệu như GDPR ở châu Âu hoặc các đạo luật thông báo vi phạm của Mỹ. Điều này có thể dẫn đến một sự dịch chuyển: các nhà bán lẻ sẽ buộc phải tìm đến các dịch vụ thanh toán có hợp đồng rõ ràng, có đội ngũ pháp lý và bảo hiểm mạng. Điều đó vô tình làm tăng lợi thế cho các giải pháp lưu ký.
Về mặt cạnh tranh, lỗ hổng này là một cú hích cho các nền tảng thanh toán lưu ký tập trung như OpenNode, Strike hay Coinbase Commerce. Họ có thể lập tức tung ra các chiến dịch quảng bá nói rằng: “Đừng tự mình vật lộn, hãy để chúng tôi lo phần bảo mật”. Trong ngắn hạn, họ có thể giành được một lượng khách hàng. Nhưng về lâu dài, việc tập trung hóa thanh toán sẽ làm xói mòn ý nghĩa của Bitcoin. Đây là một vòng luẩn quẩn: muốn phi tập trung thì cần trách nhiệm cá nhân, nhưng trách nhiệm cá nhân lại luôn là điểm yếu với đa số con người.
Tôi vẫn nhớ khi kiểm toán các hợp đồng ICO cho EOS vào năm 2017, chúng tôi phát hiện lỗ hổng trong cơ chế đa chữ ký – một lỗ hổng mà về lý thuyết không quá phức tạp, nhưng lại nằm ở vị trí khiến mọi quỹ trong hợp đồng có thể bị rút. Nguyên nhân sâu xa là do một nhầm lẫn trong kiểm soát truy cập: một hàm tưởng như chỉ dành cho nội bộ hóa ra lại có thể được gọi từ bên ngoài. Vụ việc đó giúp tôi hình thành thói quen: khi kiểm tra một hệ thống, tôi luôn đặt câu hỏi “Lộ trình dữ liệu nhạy cảm từ nơi sinh ra cho đến nơi sử dụng có bị chặn ở đâu không?” Nếu có một chặng đường không được bảo vệ, toàn bộ hệ thống không an toàn.
Vụ BTCPay Server cũng tương tự. Macaroon là một vật thể sống, nó phải được truyền từ LND đến BTCPay Server, và từ BTCPay Server đến trình duyệt. Nếu ở bất kỳ đâu, nó bị lộ, thì dù mã hóa có mạnh cỡ nào cũng vô nghĩa. Vấn đề nằm ở con đường truyền tải, không phải ở vật thể. Và con đường đó thường được xây dựng bởi các lập trình viên có niềm tin rằng “môi trường của tôi là an toàn”. Cách nghĩ đó là một cái bẫy.
Một điểm nữa mà tôi muốn nhấn mạnh: sự kiện này cho thấy giới đầu tư và người dùng cuối cần xem xét lại cách họ đánh giá dự án. Khi một giao thức không có token, không có quỹ đầu tư, không có doanh số, người ta thường xem nhẹ mức độ rủi ro. Nhưng hạ tầng thanh toán của Bitcoin còn quan trọng hơn nhiều một meme coin. Nếu nó gục ngã, toàn bộ hệ sinh thái ứng dụng xung quanh sẽ chịu ảnh hưởng. Vì vậy, các quỹ đầu tư và cộng đồng nên chủ động tài trợ cho các cuộc kiểm toán bảo mật của các phần mềm mã nguồn mở. Đó là một hình thức “bảo hiểm hạ tầng” mà chúng ta có thể thực hiện ngay hôm nay.
Trong bối cảnh thị trường còn nhiều bất ổn, các vụ tấn công như thế này thường bị thổi phồng lên thành một bằng chứng cho sự thất bại của DeFi. Tôi không nghĩ vậy. Ngược lại, tôi nghĩ đây là một minh chứng cho thấy mô hình mã nguồn mở có thể tự chữa lành. Điều tôi lo lắng hơn là những người dùng nhỏ lẻ, những người không theo dõi các thông báo bảo mật, có thể trở thành nạn nhân mà không kịp nhận ra. Khi một người mất tiền, họ không chỉ mất một món tiền, họ mất niềm tin vào toàn bộ hệ sinh thái. Niềm tin là thứ khó xây dựng nhất, và dễ phá hủy nhất.
Vậy câu hỏi đặt ra cho mỗi chúng ta là: chúng ta có sẵn sàng trả cái giá của tự do? Với tôi, tự do không có nghĩa là không có bất kỳ ràng buộc nào. Nó có nghĩa là bạn được lựa chọn ràng buộc của mình. Bạn có thể chọn một giải pháp lưu ký, mất đi một phần quyền kiểm soát nhưng được an toàn. Hoặc bạn chọn tự quản lý, giữ toàn quyền nhưng phải liên tục học hỏi, liên tục cập nhật, liên tục cảnh giác. Không có lựa chọn nào đúng tuyệt đối. Nhưng nếu bạn chọn tự quản lý, đừng ngây thơ nghĩ rằng bạn có thể làm mà không cần hiểu biết sâu sắc.
Cộng đồng đã sửa lỗi trong một ngày. Nhưng vết nứt niềm tin sẽ cần nhiều tháng để hàn gắn. Có lẽ một trong những điều tốt đẹp nhất đến từ thảm họa này là nó buộc tất cả chúng ta phải nhìn lại: liệu một chiếc ví tự quản có phải là một thùng vàng bị niêm phong, hay là một ngôi nhà cần lắp chuông báo động? Tôi đã có câu trả lời cho riêng mình. Còn bạn thì sao?