Hơn 300 nút thoát Tor bị xóa sổ: Khi mạng ẩn danh lớn nhất thế giới bị tấn công có tổ chức

Vào sáng thứ Sáu ngày 2/10, 333 nút thoát Tor bị nhiễm độc đã đồng loạt khởi động một chiến dịch chặn bắt kết nối SSH và thu thập tối đa dữ liệu không mã hóa. Con số này chiếm khoảng 10% trong tổng số gần 3.000 exit relay của toàn bộ mạng Tor, một quy mô đủ lớn để gây ảnh hưởng nghiêm trọng tới người dùng.

Câu chuyện dưới đây được kể lại từ góc nhìn của một nhà nghiên cứu trực tiếp phát hiện, phân tích và góp phần đưa các nút nhiễm độc ra khỏi mạng lưới — đồng thời cũng là lời cảnh báo thiết thực cho cộng đồng vận hành hệ thống.

Minh họa sự cố hàng loạt nút Tor ngoại tuyến

Diễn biến của cuộc tấn công

Kẻ tấn công đã xâm nhập được vào các máy chủ từ hai tháng trước đó, vào tháng 8, rồi lặng lẽ cấy Ebury 1.8.3 — một backdoor OpenSSH kiêm công cụ đánh cắp thông tin đăng nhập dành cho Linux.

Cuộc tấn công dường như nhắm tới hai mục tiêu chính:

• Thu thập tối đa lưu lượng email không mã hóa đi qua mạng Tor
• Chặn bắt các kết nối SSH theo hình thức tấn công xen giữa (MITM)

Bằng cách chặn một số cổng nhất định, kẻ tấn công buộc các nút thoát bị nhiễm chỉ xử lý lưu lượng email không mã hóa — một chi tiết đã được một quản trị viên Tor kỳ cựu phân tích khá kỹ trong bài viết của mình.

Sơ đồ sự cố chặn bắt SSH qua nút thoát Tor

Khi kết nối SSH bị "bắt cóc" giữa đường

Nếu người dùng vô tình tạo một circuit đi qua một trong 333 nút thoát nhiễm độc, ban đầu sẽ không thấy dấu hiệu bất thường nào. Lưu lượng web đã mã hóa vẫn được chuyển tiếp như thường lệ.

Nhưng khi kết nối SSH qua cổng 22, kết nối đó bị âm thầm chuyển hướng tới một trong 12 máy chủ chặn bắt SSH của kẻ tấn công. Chính tác giả bài viết đã trải qua tình huống này vào sáng thứ Sáu, khi nhận được cảnh báo quen thuộc của OpenSSH về việc khóa máy chủ từ xa đã thay đổi — kèm lời nhắc rằng "ai đó có thể đang nghe lén bạn ngay lúc này".

Nếu vô tình bỏ qua cảnh báo và tiếp tục đăng nhập, kẻ tấn công sẽ làm ba việc:

• Đánh cắp mật khẩu của người dùng
• Mở một kết nối tới máy chủ đích và theo dõi từng lệnh được gõ, đóng vai trò trung gian
• Mở thêm một kết nối thứ hai tới cùng máy chủ đó để cài cắm Ebury

Tức là chỉ sau một lần đăng nhập bất cẩn, server của nạn nhân có thể bị lây nhiễm và trở thành một mắt lưới mới trong mạng botnet.

Quá trình gỡ bỏ các nút nhiễm độc

Tối thứ Sáu, tác giả đã liên hệ với nhóm phụ trách sức khỏe mạng lưới (Network Health Team) của Tor Project và cung cấp các phát hiện của mình. Nhóm xác nhận đây là kiểu tấn công chưa từng gặp trước đây và lập tức bắt tay vào việc liên hệ với các quản trị viên relay bị ảnh hưởng.

Dòng thời gian diễn ra khá nhanh:

• Thứ Sáu 2/10: Cuộc chặn bắt bắt đầu
• Chủ nhật 4/10: Tor Project công bố thông báo cho các quản trị viên, những người này bắt đầu tắt các exit node của mình
• Chủ nhật 4/10: Các relay bị đánh dấu BadExit, nên máy khách không còn dùng chúng để thoát lưu lượng
• Thứ Hai 5/10: Kẻ tấn công khởi động lại nhiều relay, nhưng vì đã bị gắn cờ nên chúng chỉ còn dùng được như middle relay
• Thứ Hai 5/10: Toàn bộ máy chủ bị nhiễm đều bị tắt, một phần do quản trị viên, một phần do chính kẻ tấn công

Trong thông báo của mình, nhóm Network Health mô tả rõ cách thức: kẻ tấn công xâm nhập các máy chủ Linux, và khi thấy những máy này đang chạy ở chế độ không phải exit, chúng chỉnh sửa tệp torrc để biến chúng thành exit node nhằm thực hiện đòn tấn công SSH.

Chi tiết các nút thoát Tor bị ảnh hưởng

Trên trang metrics.torproject.org, có thể thấy rõ một cú sụt giảm số lượng nút thoát vào ngày 4/10 và đến nay vẫn chưa phục hồi.

Cách tìm ra toàn bộ các nút bị nhiễm

Phần kỹ thuật đáng chú ý nhất là cách tác giả lần ra tất cả các nút thoát nhiễm độc. Anh dùng exitmap để viết một script đơn giản với cơ chế như sau:

• Ghim một exit node cụ thể, sau đó mở kết nối SSH từ máy chủ A tới máy chủ B
• Máy chủ A kiểm tra xem có nhận đúng dấu vân tay SSH của máy chủ B hay không
• Máy chủ B kiểm tra xem kết nối đến từ exit node đã ghim hay từ một trong 12 máy chủ chặn bắt

Script được chạy với toàn bộ khoảng 3.000 exit relay. Kết quả: khoảng một chục nút trả về dấu vân tay giả, và hơn 300 nút không trực tiếp chặn bắt nhưng lại chuyển hướng qua chính các máy chủ chặn bắt đó. Chỉ riêng việc chuyển hướng sai đích đã đủ để khẳng định nút thoát đã bị nhiễm.

Trong bước phân tích sâu hơn, tác giả dùng sshesame làm honeypot. Dụ kẻ tấn công đăng nhập vào honeypot cho thấy chúng dùng paramiko (một thư viện SSH của Python) và tìm cách cài Ebury bằng Perl, với thủ thuật kiểm tra quyền trước rồi thực thi một lệnh mã hóa base64.

Những câu hỏi còn bỏ ngỏ

Câu hỏi lớn nhất vẫn là cách kẻ tấn công xâm nhập được vào tất cả các máy chủ đó ngay từ đầu. Một giả thuyết cho rằng chính công ty cung cấp hosting đã bị hack, nhưng đây vẫn chỉ là suy đoán — thực tế chưa ai xác nhận được.

"Xét số lượng máy chủ từng nhiễm Ebury trong giai đoạn 2009–2023 (khoảng 400.000 máy), rất có thể vẫn còn những relay Tor bị nhiễm khác ngoài kia." — Marc-Etienne M. Léveillé

Việc sử dụng Ebury cùng với chiến lược thu thập dữ liệu không mã hóa trên diện rộng cho thấy đây có thể là một nhóm tội phạm mạng hoạt động vì lợi nhuận, song đây cũng chỉ là phỏng đoán. Tác giả còn nghi ngờ kẻ tấn công cố tình chọn thứ Sáu để ra tay, với hy vọng không ai muốn phá hỏng ngày nghỉ cuối tuần của mình để xử lý sự cố.

Bài học cho cộng đồng vận hành hệ thống

Thông điệp rút ra không mới nhưng luôn đúng: đầu tư thêm cho bảo mật là khoản đầu tư xứng đáng. Cụ thể:

• Tắt xác thực bằng mật khẩu, chuyển sang dùng khóa SSH
• Cân nhắc dùng khóa phần cứng (hardware key) cho các tài khoản quan trọng
• Với người vận hành relay và bridge: hãy đối xử với các máy này như hệ thống production bị nhắm mục tiêu cao độ, thay vì coi chúng là máy phụ ít quan trọng

"Suy cho cùng, relay và bridge cần được đối xử như những máy production bị nhắm mục tiêu cao độ." — George

Với người dùng Tor tại Việt Nam và khu vực, sự cố này là lời nhắc rằng Tor vẫn là công cụ hữu ích cho quyền riêng tư, nhưng an toàn của toàn mạng lưới phụ thuộc vào chất lượng vận hành của từng relay. Việc người dùng luôn để ý cảnh báo thay đổi khóa máy chủ khi kết nối SSH, kể cả khi đi qua mạng ẩn danh, có thể là khác biệt giữa một lần đăng nhập an toàn và một máy chủ bị chiếm quyền điều khiển.