Kẻ tấn công chiếm quyền kiểm soát hơn 300 relay Tor để chặn kết nối SSH
"Attackers compromised over 300 Tor exit relays between October 1-5, 2026, to intercept SSH connections. They modified relay configurations to allow port 22, redirecting traffic to servers that stole login credentials. Users who accepted a changed host key and logged in with a password were at risk."
Cuộc tấn công này cho thấy lỗ hổng bảo mật nghiêm trọng trong mạng Tor, có thể dẫn đến đánh cắp thông tin đăng nhập và mất quyền truy cập vào các hệ thống quan trọng.
Các doanh nghiệp sử dụng Tor để truy cập tài nguyên nội bộ có thể bị gián đoạn hoạt động và mất dữ liệu do thông tin đăng nhập bị đánh cắp. Việc giám sát lưu lượng mạng và cập nhật chính sách bảo mật là cần thiết.
Từ ngày 1-5 tháng 10 năm 2026, kẻ tấn công đã kiểm soát hơn 300 relay thoát (exit relay) của mạng Tor để chặn lưu lượng SSH và đánh cắp mật khẩu đăng nhập. Các relay này được cấu hình lại để cho phép cổng 22, chuyển hướng lưu lượng đến các máy chủ thu thập thông tin đăng nhập. Người dùng chấp nhận khóa máy chủ (host key) thay đổi và đăng nhập bằng mật khẩu có nguy cơ bị lộ.
Dự án Tor bắt đầu đánh dấu các relay bị xâm nhập từ ngày 4 tháng 10 và đến ngày 5 tháng 10, không còn relay nào trong danh sách đồng thuận (consensus) – danh sách các relay mà máy khách Tor sử dụng. Tại thời điểm cao điểm ngày 4 tháng 10, các relay có chính sách thoát của kẻ tấn công chiếm 7,46% tổng dung lượng thoát của Tor, theo phân tích dữ liệu thư mục công khai được đăng trên danh sách thư tor-relays.
Nghiên cứu viên kaba đã quét tất cả khoảng 3.000 relay thoát của Tor vào ngày 2 tháng 10 và phát hiện 333 relay chuyển hướng SSH đến 12 máy chủ chặn. Phân tích dữ liệu thư mục cho thấy 377 relay do 59 nhà điều hành quản lý đã chuyển sang chính sách thoát của kẻ tấn công từ ngày 1 đến ngày 4 tháng 10.
Relay thoát chỉ xử lý lưu lượng đến các cổng được phép trong chính sách thoát của nó. Kẻ tấn công đã sửa đổi tệp cấu hình torrc của các relay để cho phép cổng 22 (cổng SSH), kích hoạt SSH trên 342 relay trước đây chặn cổng này. 24 relay khác, trước đây không phải là relay thoát, đã trở thành relay thoát. Nhóm sức khỏe mạng của Dự án Tor cho biết, kẻ tấn công có thể truy cập các máy chủ Linux và chỉnh sửa tệp torrc để biến chúng thành relay thoát, nhằm thực hiện tấn công SSH.
Kẻ tấn công cũng đóng các cổng email được mã hóa (IMAPS và POP3S) và mở các cổng plaintext (POP3 và IMAP) trên hầu hết các relay. Khi kết nối SSH đi qua một trong các relay này, nó sẽ được chuyển đến một trong 12 máy chủ chặn thay vì đích đến thực tế. Máy chủ chặn sẽ trình bày khóa máy chủ của riêng nó. Nếu người dùng chấp nhận khóa này và nhập mật khẩu, thông tin đăng nhập sẽ bị đánh cắp. Kẻ tấn công có thể kết nối đến máy chủ thực, ghi lại mọi lệnh và sử dụng mật khẩu bị đánh cắp để đăng nhập và chạy một trình cài đặt Perl được mã hóa base64. Tuy nhiên, đăng nhập SSH bằng khóa không bị ảnh hưởng vì chữ ký của máy khách bao gồm một định danh duy nhất cho mỗi phiên.
Để bị ảnh hưởng, người dùng phải kết nối đến máy chủ SSH qua Tor từ ngày 1 đến chiều ngày 5 tháng 10, gặp phải một trong các relay bị xâm nhập, chấp nhận khóa máy chủ của kẻ tấn công và đăng nhập bằng mật khẩu. Hiện chưa có thống kê về số lượng nạn nhân.
Câu hỏi thường gặp
Thời gian xảy ra cuộc tấn công là khi nào?
Cuộc tấn công diễn ra từ ngày 1 đến ngày 5 tháng 10 năm 2026. Kẻ tấn công kiểm soát hơn 300 relay thoát của Tor trong khoảng thời gian này.
Những ai có nguy cơ bị ảnh hưởng bởi cuộc tấn công này?
Người dùng kết nối đến máy chủ SSH qua Tor trong khoảng thời gian trên, chấp nhận khóa máy chủ thay đổi và đăng nhập bằng mật khẩu có nguy cơ bị lộ thông tin đăng nhập.
Kẻ tấn công đã làm gì với các relay Tor bị xâm nhập?
Kẻ tấn công đã cấu hình lại các relay để cho phép cổng 22 (SSH) và chuyển hướng lưu lượng đến các máy chủ chặn, nơi thông tin đăng nhập có thể bị đánh cắp.
Góc nhìn của Orange Cloud
Theo chúng tôi, sự việc này cho thấy tầm quan trọng của việc xác minh khóa máy chủ khi kết nối SSH qua Tor. Các doanh nghiệp Việt Nam sử dụng Tor để truy cập tài nguyên nội bộ nên kiểm tra nhật ký và giám sát các kết nối bất thường. Điều đáng chú ý là các kỹ sư nên cân nhắc sử dụng xác thực khóa SSH thay vì mật khẩu để tăng cường bảo mật.