Cuộc tấn công giả mạo IP khiến cả thế giới gửi báo cáo lạm dụng về cho bạn bè của mình
(delroth.net)- Hetzner đã chuyển tiếp một báo cáo lạm dụng cho biết có quét cổng SSH từ
195.201.9.37, nhưng bên trong máy chủ không tìm thấy tiến trình độc hại, thay đổi tệp hay bằng chứng lưu lượng bất thường - Luồng thực tế được xác nhận bằng
tcpdumpcho thấy máy chủ không hề kết nối ra ngoài tới22/tcp, mà gần giống backscatter khi nhiều host trên Internet gửi trả TCP RST về máy chủ - Nguyên nhân cốt lõi là có thể gửi các gói với IP nguồn tùy ý qua những mạng không lọc BCP38, và với TCP·QUIC·TLS vốn cần phản hồi hai chiều thì kẻ tấn công không thể trực tiếp nhìn thấy phản hồi
- Mẫu tương tự cũng xuất hiện trên 2 Tor relay khác của tác giả, và trong mailing list
tor-relayscùng issue của Tor Project đã có báo cáo hiện tượng tương tự từ vài ngày trước, bao gồm cả trường hợp một số node tạm thời bị ngừng hoạt động - Kẻ tấn công có thể giả mạo IP của nạn nhân làm địa chỉ nguồn để gửi các nỗ lực kết nối tới nhiều đích SSH, từ đó kích hoạt báo cáo lạm dụng tự động, đưa vào danh sách chặn và dẫn tới hành động từ nhà cung cấp hosting
Báo cáo lạm dụng từ Hetzner và kiểm tra máy chủ
- Hetzner gửi email AbuseInfo liên quan đến IP
195.201.9.37- Người báo cáo là
abuse@watchdogcyberdefense.com - Nhật ký có nhiều mục
DENIEDhướng tới22/tcpcủa các đích202.91.16x.x
- Người báo cáo là
- Nhìn bề ngoài thì giống như máy chủ đã bắt đầu gửi kết nối SSH ra Internet, một tình huống mà thông thường đủ để nghi ngờ nhiễm mã độc
- Nhưng sau 1–2 giờ kiểm tra, trạng thái máy chủ gần như bình thường
- Không có tiến trình bất thường
- Không có thay đổi hệ thống tệp
- Không có lưu lượng mạng bất thường xét từ góc nhìn hypervisor
- Trên máy chủ đó đang chạy nhiều dịch vụ phân tán và liên hợp
- Syncthing relay
- Mastodon instance
- Tor relay
- Matrix homeserver
- Tor relay có kết nối tới một số relay
22/tcp, nhưng không khớp với mạng bị báo cáo; log Matrix·Mastodon và hàng đợi Mastodon Sidekiq cũng không cho thấy dấu vết yêu cầu từ IP hay cổng ngẫu nhiên
Luồng gói thực tế mà tcpdump cho thấy
- Ban đầu tác giả định dùng bộ lọc
dst port 22để kiểm tra lưu lượng đi từ máy chủ ra ngoài tới22/tcp - Khi đổi bộ lọc thành
not src host 195.201.9.37, tác giả thấy các gói TCP RST từ22/tcpcủa nhiều IP bên ngoài đi vào các cổng tạm thời trên máy chủ - Thực tế không phải máy chủ gửi kết nối tới
22/tcpcủa các host ngẫu nhiên, mà là các host ngẫu nhiên trên Internet đang gửi gói reset về máy chủ - Mẫu này khớp với backscatter, nơi các gói phản hồi quay về IP bị giả mạo do giả mạo IP nguồn
Giả mạo IP nguồn và lỗ hổng của BCP38
- Trên Internet, IP đích phải chính xác, nhưng vẫn có thể gửi gói đến nhiều đích với IP nguồn được đặt giả
- BCP38 là thực tiễn tốt nhất hiện hành, yêu cầu mạng ngang hàng chỉ cho phép dùng các địa chỉ IP nguồn được kỳ vọng
- Việc lọc này phải được áp dụng ở giai đoạn đầu của đường đi gói tin thì mới hiệu quả
- Ở cấp transit provider lớn, việc lọc có ý nghĩa là khó vì peer kỳ vọng provider đó chuyển tiếp lưu lượng cho toàn bộ Internet
- Chỉ cần tìm được một transit provider không áp dụng BCP38 là có thể gửi gói với IP nguồn tùy ý
- APNIC đã đăng một bài viết năm 2023 về lý do việc xác thực địa chỉ nguồn vẫn còn là vấn đề
- Các giao thức thuộc họ TCP, QUIC, TLS cần giao tiếp hai chiều nên nếu giả mạo IP nguồn, kẻ tấn công sẽ không nhìn thấy phản hồi
- Không phù hợp để kiểm tra kết quả quét cổng thông thường
- Dù vậy vẫn tồn tại các cách lạm dụng đã biết như phản xạ DDoS
Vì sao kiểu giả mạo này lại gây thiệt hại
- Kịch bản hợp lý nhất là ai đó dùng IP của tác giả làm nguồn để gửi nỗ lực kết nối tới
22/tcpcủa nhiều host trên Internet - Nếu mục tiêu là dò cổng mở thông thường thì điều này không hợp lý về mặt logic, vì kẻ giả mạo không thể thấy phản hồi
- Trước đây từng có kỹ thuật Idle Scanning, nhưng nó phụ thuộc vào máy chủ ít bận và các bộ đếm của network stack có thể dự đoán, nên đã mất tính thực dụng từ hàng chục năm trước
- Quy mô lưu lượng quá thấp và thời gian kéo dài quá lâu, nên khả năng chỉ là nhập nhầm IP nguồn trong cấu hình scanner cũng không thuyết phục
- Thiệt hại thực sự đến từ tự động hóa báo cáo lạm dụng
- Các nỗ lực kết nối bị giả mạo chạm vào những mạng có honeypot hoặc hệ thống phát hiện xâm nhập
- Một số hệ thống tự động gửi báo cáo lạm dụng
- Nhà cung cấp hosting có thể hiểu nhầm rằng máy chủ nạn nhân đã bị xâm nhập hoặc là độc hại
Mẫu lặp lại trên các Tor relay khác
- Tác giả một lần nữa xác nhận rằng máy chủ của mình đang hoạt động như một Tor relay
- Tor relay là node nội bộ của mạng Tor; nếu không phải exit node thì nó không giao tiếp trực tiếp với Internet công cộng
- Relay chuyển tiếp lưu lượng ẩn danh đã mã hóa giữa các node tham gia mạng Tor
- Một số relay có thể hoạt động như Guard Node, trở thành điểm vào mạng Tor
- Tác giả chạy
tcpdumptrên 2 relay bổ sung ở các quốc gia và ISP khác nhau- Một relay trên đường truyền gia đình
- Một relay trên VPS Linode tại Nhật Bản
- Trên cả hai relay cũng xuất hiện cùng mẫu phản hồi TCP bị giả mạo từ
22/tcpbên ngoài hướng về IP relay - Tác giả đã gửi thư tới mailing list
tor-relays, và đã có issue trên Tor Project mô tả cùng hiện tượng từ vài ngày trước - Cuộc tấn công giả mạo này bắt đầu trên các loại node khác trước cả relay, và đã có trường hợp một số node tạm thời bị gián đoạn bởi các kết nối giả mạo với quy mô lớn hơn
Quy trình tấn công có thể nhắm vào bất kỳ ai
- Quy trình tấn công khả dĩ như sau
- Kẻ tấn công có quyền truy cập vào mạng không có lọc BCP38
- Gửi yêu cầu kết nối TCP tới
22/tcpcủa nhiều host Internet ngẫu nhiên - Giả mạo IP nguồn thành IP của nạn nhân
- Host đích hoặc hệ thống bảo mật sẽ cho rằng nạn nhân là bên đang cố kết nối và gửi báo cáo lạm dụng
- Nếu đủ quy mô, IP nạn nhân có thể bị đưa vào nhiều danh sách chặn và nhà cung cấp hosting có thể tạm ngừng máy chủ
- Không có yếu tố nào trong cuộc tấn công này là đặc thù riêng cho Tor
- Đây không phải là cách thức có vẻ đặc biệt khó để một kẻ tấn công có động cơ đơn lẻ thực hiện
- Nạn nhân không phải là kẻ tấn công thực sự mà là chủ sở hữu của IP nguồn bị giả mạo, nhưng vẫn có thể chịu thiệt hại vận hành do báo cáo lạm dụng tự động và phản ứng từ nhà cung cấp hosting
Vấn đề vận hành Internet vẫn còn tồn tại trong năm 2024
- Việc giả mạo IP nguồn vẫn là vấn đề trong năm 2024 gần như là một thất bại trong vận hành Internet
- Không chỉ BCP38 mà cả RPKI cũng gặp vấn đề tương tự về triển khai, và chỉ bắt đầu mở rộng khi các công ty Internet lớn trực tiếp áp đặt yêu cầu lên các peer của họ
- Bước tiếp theo để xử lý kiểu tấn công này vẫn chưa rõ ràng
- Nó đã thực sự xảy ra ngoài thực tế
- Tác giả không biết đây có phải là kiểu tấn công đã được tài liệu hóa trước đó hay không
- Tác giả cũng không biết cách lần vết nguồn gốc thực sự của các gói có IP giả mạo sau khi sự việc đã xảy ra
- Những nhà vận hành nhận được báo cáo lạm dụng tương tự cần xác minh rằng máy chủ của họ có thể là nạn nhân chứ không phải thủ phạm, đồng thời thu thập cơ sở để giải thích với nhà cung cấp hosting
1 bình luận
Ý kiến trên Hacker News
Những vấn đề kiểu này xử lý thật sự rất phiền. Vì câu trả lời chính đáng cho một báo cáo lạm dụng — “ai đó đã spoof IP của tôi, không phải tôi làm, và thiết bị của tôi cũng không bị xâm nhập” — hoàn toàn giống với cái cớ mà một kẻ xấu sẽ đưa ra.
Rốt cuộc, như trong bài viết, bạn phải chứng minh điều không tồn tại với một bên vốn chẳng mấy quan tâm, mà việc đó trên thực tế gần như bất khả thi.
Một báo cáo lạm dụng tự động về thứ có thể dễ dàng bị spoof không đủ để tự nó trở nên chính đáng, nhưng có thể là lý do để nhanh chóng kiểm tra xem máy chủ của tôi có đang hoạt động bình thường và không bị chiếm quyền hay không.
Ít nhất cần có căn cứ về danh tính và thẩm quyền tài phán, thậm chí có thể cần cả cuộc gọi video. Chỉ ẩn danh trên Internet rồi nói “tôi là người tốt” và yêu cầu người khác tin là chưa đủ.
Địa chỉ MAC bị spoof, địa chỉ email, thông điệp ARP, Neighbor Discovery, chứng chỉ TLS man-in-the-middle cũng tương tự.
Dù vậy, vẫn thật đáng kinh ngạc là còn có thứ hoạt động được.
Nếu cố làm cho nó được thiết kế và vận hành hoàn hảo, có lẽ nó lại rất thường xuyên hỏng lớn. Khả năng chịu đựng một chút không hoàn hảo đã đóng góp rất nhiều vào độ vững chắc và tính hữu dụng của Internet.
Điều đó không có nghĩa là đừng cải thiện, mà giống một lời cảnh báo rằng khi theo đuổi chủ nghĩa hoàn hảo, ta rất dễ mắc sai lầm lớn làm hỏng mọi thứ.
Trước đây, chúng tôi từng quét máy chủ phản xạ DrDoS theo cách tương tự. Không nhà cung cấp hosting nào muốn nhận báo cáo port scan, nên nếu đặt địa chỉ nguồn của lần quét là IP của một nhà cung cấp cloud vô tội có uy tín, các máy chủ phản xạ sẽ vui vẻ gửi phản hồi UDP về phía đó.
Nhà cung cấp cloud dĩ nhiên sẽ nhận vô số báo cáo, nhưng nếu tôi nói máy chủ của tôi không thực hiện quét thì họ kiểm tra và không tắt dịch vụ. Vì máy chủ gửi các gói quét bị spoof không bị phát hiện, có thể liên tục quét toàn bộ Internet mà không gặp vấn đề báo cáo lạm dụng thông thường.
Tôi không biết chuyện này thực sự xảy ra thường xuyên đến mức nào, nhưng nếu phối hợp với các nhà vận chuyển và lần ngược từng hop thì có thể truy vết nguồn gốc các gói spoof. Có lần JPMorgan phối hợp với Cogent và báo cho chúng tôi đừng gửi gói tin tới địa chỉ IP của họ. Nhân tiện, Cogent là một trong những nhà mạng tier 1 trên Internet khá khoan dung với spoofing.
Đây là lần đầu tôi nghe cách này được dùng nhắm cụ thể vào Tor, và nó hơi ngược trực giác. Vì bên gửi gói spoof có vẻ sẽ là người ủng hộ Tor. Khả năng cao chỉ là troll, và may là các nhà cung cấp hosting Tor có lẽ sẽ không quá bận tâm đến chuyện này.
Có thể chỉ là troll, nhưng cũng có thể là phía muốn biến Tor thành thứ bị đối xử như chất thải phóng xạ vì Tor cản trở hoạt động giám sát.
Đây không phải chuyện mới. Vài năm trước tôi tạo một quy tắc tường lửa rất cơ bản: với các gói TCP đi vào cổng đích 22, nếu SYN=1, ACK=0 thì chặn IP nguồn trong một ngày.
Nhưng rồi có phàn nàn rằng một số trang và dịch vụ không dùng được; hóa ra cứ vài ngày lại có những gói như vậy đến từ IP của các máy chủ phổ biến như 8.8.8.8, 1.1.1.1, Steam, Roblox, Microsoft, Facebook, Instagram và nhiều dịch vụ chat. Tất nhiên tất cả đều là gói spoof, và cuối cùng tôi phải thêm một chút kiểm chứng vào quy tắc tường lửa.
Vì vậy tôi tin chắc việc này khá phổ biến. Cá nhân tôi biết mình là trường hợp ngoại lệ khi vận hành nhiều địa chỉ IP, nhưng tôi cần sự linh hoạt để dùng bất kỳ địa chỉ nguồn nào của mình gửi gói qua bất kỳ ISP nào. Điều đó quan trọng với tôi, và nếu ISP lọc theo địa chỉ nguồn thì đó là lý do chấm dứt hợp đồng, tôi sẽ chuyển sang ISP khác.
Trường hợp sau giống kiểu “bật lại sưởi bằng phím cách”, và tôi mong các ISP sửa các mạng bị hỏng.
Một công ty host một số tài sản web tại on-premises của chi nhánh, nơi đó có đường truyền 1Gbps. Trụ sở chính có nhiều đường 10G và một datacenter khá tốt, nên họ chuyển VM web về trụ sở nhưng giữ nguyên địa chỉ IP được cấp, tức IP tĩnh công khai của ISP-A. Họ định tuyến qua VPN về trụ sở, và máy chủ dùng default gateway để gửi phản hồi mang IP nguồn của ISP-A ra đường 10G của ISP-B.
Nhờ vậy dù chiều nhận bị giới hạn ở 1G, chiều gửi tận dụng được 10G. Dù sao cũng chỉ là các yêu cầu GET. Đây không phải cấu hình tối ưu và cuối cùng họ đã đổi IP, nhưng có vẻ là một trường hợp sử dụng hợp lệ.
Ví dụ thứ hai: có hai đường ISP khác nhau, ASN riêng và dải /23 riêng. Để cân bằng tải một phần lưu lượng, một nửa IP được gửi qua ISP-A, nửa còn lại qua ISP-B. Hoạt động tốt, nhưng khi cố trộn cân bằng thêm một chút thì lộ ra một vấn đề thú vị. /24 đầu tiên được announce với ISP-A, /24 thứ hai với ISP-B, nhưng ISP-A có RP filtering. Vì vậy phải announce tất cả IP qua phía họ nữa.
Do cách bộ lọc RP hoạt động, không thể dùng prepend hay thứ tương tự, và toàn bộ lưu lượng phải đi vào qua họ. Nếu nó thấy một tuyến tốt hơn tới prefix đó, nó sẽ lọc. Trong vài tháng họ từ chối sửa với lý do bảo mật. Vì họ viện cớ đây là best practice về bảo mật nên có lẽ có thể nêu tên ISP: đó là Virgin Media.
Nhân tiện, đường Internet có rp_filter đó không phải loại 20 USD/tháng mà là hơn 5.000 USD/tháng. Khu vực đó không có lựa chọn thay thế nên không thể đổi, nhưng nếu có thì rõ ràng ai sẽ mất hợp đồng.
Giả thuyết “ai đó ghét các relay Tor” có vẻ không thuyết phục lắm so với công sức bỏ ra
Có thể bên vận hành các relay độc hại đang kéo sập các relay hợp pháp theo cách phi đạo đức, nhằm tăng tỷ lệ mạng do họ kiểm soát
Chỉ cần chạy vài lượt tải BitTorrent cũng có thể đủ
Cần điều gì để đủ nhiều nhà mạng từ chối traffic của mọi AS không triển khai BCP38, khiến spoofing không còn khả thi nữa?
Vì họ đã nắm đủ nhiều traffic inbound, nên câu “đang kiểm tra bảo mật kết nối” có thể thật sự có ý nghĩa
Tuy nhiên, giảm hệ số khuếch đại phản xạ thì dễ hơn nhiều. Vì với IPv4 có thể quét các vector phản xạ và khiếu nại những bên phản hồi gấp 10 lần số byte đầu vào
Đây là vấn đề tương tự swatting. Nó dựa vào việc một chủ thể có thẩm quyền thực hiện biện pháp mạnh dựa trên một báo cáo sự cố chưa được xác minh
Điểm khác có lẽ là thay vì liên hệ trực tiếp với người có thẩm quyền, nó dùng một bên thứ ba không liên quan để gửi báo cáo
Với các yêu cầu chỉ là một gói tin đơn lẻ và không có lượt khứ hồi, hệ thống có lẽ không nên tự động gửi báo cáo lạm dụng, trừ khi đó là traffic ở mức từ chối dịch vụ
Đặc biệt nếu là SSH, trước khi có bất kỳ dạng handshake nào diễn ra thì không có cách nào xem đó là một nỗ lực kết nối hợp lệ
Máy chủ chính của tôi cũng từng bị hạ vì một báo cáo lạm dụng giả. Họ nói rằng từ IP của tôi đã có một cuộc tấn công DoS hơn 1Gbps, nhưng đường truyền máy chủ của tôi bị giới hạn ở 400Mbps. Chỉ cần có người đọc báo cáo thôi là đã biết điều đó là bất khả thi, và tôi cũng đã không phải vật lộn với hỗ trợ qua điện thoại suốt hai ngày trong kỳ nghỉ
Đây giống như phiên bản IP của swatting, quấy rối bằng bằng sáng chế, gán tội cho người vô tội, hay yêu cầu gỡ nội dung DMCA nhằm loại bỏ đối thủ
Về bản chất, đó là cách vũ khí hóa cơ chế chống lạm dụng để tấn công mục tiêu mình không ưa. Điểm thú vị là chủ thể có thẩm quyền trở thành mắt xích yếu và có thể bị lợi dụng tích cực để giúp kẻ vô đạo đức đạt mục đích, nhưng đây không phải hiện tượng hoàn toàn mới
Nhìn vào đồ thị số lượng relay và “advertised bandwidth” trên metrics.torproject.org thì có vẻ nó không tạo ra khác biệt lớn, nhưng dù sao vẫn thú vị
Điều tệ nhất là những nơi bắt chước kiểu tống tiền như “Watchdog Cyber Defense”, Spamhaus, Shadowserver hoặc UCEPROTECT có thể gửi hàng triệu báo cáo tự động, và các host trên thực tế buộc phải nghe theo nếu không muốn dải IP của mình bị đưa vào danh sách chặn
Không có giải pháp trong băng cho vấn đề này, nhưng có thể có giải pháp ngoài băng
Ví dụ: (1) báo cho ISP đích rằng họ đang nhận traffic ngược, (2) ISP đó kiểm tra xem gói tin đến từ đâu và báo cho ISP tương ứng, (3) lặp lại bước 2 cho đến khi tìm được nguồn, (4) cách ly một phần mạng đó cho đến khi nó hoạt động đúng
Rốt cuộc, Internet được tạo nên bởi con người