Tấn công định thời dựa trên WebSockets: cách các hệ thống chống gian lận quét các cổng nội bộ của bạn

Bạn có muốn thử Octo Browser với giá giảm không?
Sử dụng mã khuyến mãi OCTOSCRAPER để được giảm giá 30% cho bất kỳ gói đăng ký nào. Ưu đãi này chỉ dành cho người dùng mới.

Cách WebSocket trở thành một trình quét cục bộ

Đầu tiên, là một chút thông tin nền tảng. WebSocket là một giao thức truyền thông dựa trên TCP được thiết kế để trao đổi tin nhắn theo thời gian thực giữa máy khách và máy chủ.

Ban đầu, nó được tạo ra để cho phép những thứ như trò chơi trên trình duyệt có độ trễ tối thiểu hoặc chỉ báo nhập văn bản theo thời gian thực trong các ứng dụng trò chuyện. Nhưng các nhà phát triển hệ thống chống gian lận nhanh chóng nhận ra rằng nếu trình duyệt có thể mở một socket đến máy chủ từ xa, thì trong hầu hết các trường hợp, không có gì ngăn cản nó cố gắng kết nối với các địa chỉ cục bộ của người dùng.

Đây là cách hoạt động: ngay khi WebPage mục tiêu tải—hoặc khi bạn đăng nhập—một tập lệnh chống gian lận ẩn sẽ bắt đầu cố gắng thiết lập các kết nối một cách bất đồng bộ. Nó không quét mọi cổng khả thi. Thay vào đó, nó thăm dò 127.0.0.1 bằng danh sách các cổng được định nghĩa trước, chẳng hạn như 9222 cho CDP hoặc các cổng thường được sử dụng bởi các máy khách VPN cục bộ và máy chủ cơ sở dữ liệu. Thông thường, cách tiếp cận này hoạt động.

Tại sao các trình duyệt cho phép điều này

Các trình duyệt và hệ điều hành hiện đại có hai đặc điểm kiến trúc khiến điều này trở nên khả thi.

1. Vượt qua các hạn chế CORS nghiêm ngặt. Nếu tập lệnh chống gian lận cố gắng quét cổng bằng yêu cầu HTTP thông thường (qua fetch() hoặc XMLHttpRequest), trình duyệt sẽ chặn quyền truy cập vào phản hồi vì các biện pháp bảo mật, chính sách cùng nguồn gốc (same-origin policy), hạn chế CORS và các quy tắc nội dung hỗn hợp. WebSockets hoạt động khác. Giao thức này không sử dụng mô hình CORS truyền thống để hạn chế quyền truy cập vào các phản hồi. Thay vào đó, nó gửi một tiêu đề Origin, mà máy chủ có thể chọn để xác thực. Việc chỉ xác định xem kết nối thành công hay thất bại đã cung cấp thông tin có giá trị cho việc phân tích.

2. Điểm mù của tường lửa. Giao diện loopback (127.0.0.1) được hưởng mức độ tin cậy đặc biệt cao trong hệ điều hành, vì lưu lượng truy cập được gửi từ trình duyệt đến cổng cục bộ không bao giờ rời khỏi giao diện mạng của bạn.

Do đó, các tường lửa tích hợp trong Windows và macOS thường không kiểm tra hoặc lọc các kết nối nội bộ này, coi chúng là an toàn vốn có.

Điều này cung cấp cho các hệ thống chống gian lận một kênh hợp pháp, về cơ bản là không bị hạn chế, để thăm dò môi trường cục bộ của bạn.

Nhưng làm thế nào họ có thể biết liệu một cổng có đang mở hay không nếu các chính sách bảo mật của trình duyệt ngăn họ đọc phản hồi trực tiếp từ hệ thống?

Đó là lúc các cuộc tấn công định thì (timing attacks) phát huy tác dụng.

Cách hoạt động của cuộc tấn công định thì

Trình duyệt sandbox áp đặt các hạn chế nghiêm ngặt đối với các tập lệnh. Do Chính sách cùng nguồn gốc (SOP) và các hạn chế CORS, một tập lệnh không thể chỉ đơn giản là đọc phản hồi từ một dịch vụ cục bộ hoặc lấy mã lỗi chính xác được trả về bởi một kết nối không thành công. Thật may mắn cho một cuộc tấn công định thì, nó không cần phải làm vậy.

Quy trình hoạt động như sau:

1. Tập lệnh khởi động một bộ đếm thời gian nội bộ (thường sử dụng performance.now()).

2. Nó bắt đầu một kết nối WebSocket:
   new WebSocket('ws://127.0.0.1:9222')

3. Tập lệnh đợi sự kiện onerror kích hoạt.

4. Khi lỗi xảy ra, bộ đếm thời gian dừng lại và thời gian đã trôi qua được tính toán.

Chìa khóa nằm ở cách ngăn xếp mạng của hệ điều hành xử lý các kết nối TCP:

1. Nếu cổng bị đóng. Hệ điều hành ngay lập tức từ chối gói tin SYN đến bằng cách gửi một gói tin TCP RST phản hồi. Trình duyệt đóng socket và kích hoạt trình xử lý onerror. Trên máy cục bộ, việc này thường chỉ mất từ 1–5 mili giây.

2. Nếu cổng mở. Đầu tiên, quy trình bắt tay ba bước TCP đầy đủ được hoàn thành. Trình duyệt sau đó gửi yêu cầu HTTP Upgrade để thiết lập kết nối WebSocket. Ngay cả khi dịch vụ đang lắng nghe trên cổng đó không thực sự là máy chủ WebSocket (ví dụ: cơ sở dữ liệu hoặc daemon SSH), kết nối không bị chấm dứt ngay lập tức. Thay vào đó, nó chỉ thất bại sau khi phát hiện thấy sự không khớp giao thức. Thời gian bổ sung cần thiết cho quá trình bắt tay và trao đổi dữ liệu làm tăng độ trễ lên khoảng 10–50 mili giây.

3. Nếu cổng bị lọc bởi tường lửa. Tường lửa âm thầm bỏ gói tin SYN thay vì từ chối nó. Trình duyệt không nhận được phản hồi từ hệ điều hành và đợi cho đến khi hết thời gian chờ của hệ thống. Trong trường hợp này, độ trễ được tính bằng giây chứ không phải mili giây.

Các trình duyệt hiện đại cố tình giảm độ chính xác của bộ đếm thời gian xuống khoảng 0.1–1 ms. Tuy nhiên, các cuộc tấn công định thì mạng không yêu cầu độ chính xác đến mức phần tỷ giây.

Sự khác biệt giữa một TCP RST ngay lập tức và một nỗ lực kết nối bị trì hoãn được đo bằng hàng chục mili giây, điều này là quá đủ để phát hiện đáng tin cậy.

Các hệ thống chống gian lận tiên tiến cũng tính đến các yếu tố như tải CPU, dọn rác JavaScript và hành vi của hệ điều hành, vì vậy họ không dựa vào các ngưỡng cố định.

Thay vào đó, tập lệnh trước tiên tự hiệu chuẩn.

Trước khi thăm dò các cổng mà nó thực sự quan tâm, nó cố gắng kết nối với một cổng ngẫu nhiên có chủ ý, có số hiệu cao và có lẽ đã bị đóng, ví dụ:

ws://127.0.0.1:54321

Điều này thiết lập thời gian phản hồi cơ bản cho một cổng đã đóng trên máy cụ thể của bạn tại thời điểm đó.

Chỉ khi đó, hệ thống chống gian lận mới so sánh thời gian của các cổng thường liên quan đến các công cụ đa tài khoản với mốc cơ sở này để xác định các điểm bất thường.

Tại sao các hệ thống chống gian lận quan tâm đến localhost của bạn

Mục tiêu chính của hệ thống chống gian lận là hủy ẩn danh các cấu hình trình duyệt và phát hiện việc tạo nhiều tài khoản (multi-accounting).

Hầu hết các giải pháp chống phát hiện tập trung mạnh vào việc giả mạo vân tay trình duyệt—Canvas, WebGL, phông chữ và các tín hiệu tương tự—trong khi ít chú ý hơn đến ngăn xếp mạng.

Các cổng cục bộ mở liên quan đến các công cụ tự động hóa trở thành các chỉ báo có độ tin cậy cao cho thấy một danh tính kỹ thuật số đã bị giả mạo.

Các thuật toán chấm điểm tìm kiếm điều gì

Dữ liệu thời gian được thu thập trong vòng chưa đầy một giây sẽ được gửi đến máy chủ chấm điểm chống gian lận.

Tại đó, mô hình cổng quan sát được sẽ được phân tích. Tùy thuộc vào kết quả, điểm rủi ro tiêu cực có thể được cộng vào điểm tổng thể của cấu hình của bạn.

Nếu cổng 9222 mở, đó là dấu hiệu mạnh mẽ cho thấy trình duyệt đang được kiểm soát thông qua Chrome DevTools Protocol (CDP) bởi các khung tự động hóa như Puppeteer, Playwright, hoặc Selenium.

Tại thời điểm đó, việc mô phỏng chuyển động chuột hoặc mô phỏng thao tác nhập liệu của con người không chắc sẽ giúp ích. Phiên làm việc có thể nhận được điểm rủi ro rất cao, dẫn đến bất kỳ điều gì từ thử thách CAPTCHA cho đến khóa tài khoản hoàn toàn, tùy thuộc vào mức độ quyết liệt của hệ thống chống gian lận.

Tương tự như vậy, nếu các cổng như 22 (SSH), 3306 (MySQL), hoặc các cổng thường được sử dụng bởi các ứng dụng proxy cục bộ đang mở, thật khó để vượt qua vòng kiểm duyệt như một thiết bị của người dùng thông thường.

Hệ thống chống gian lận có thể sẽ kết luận rằng nó đang xử lý một máy ảo, một máy chủ đi thuê hoặc một máy trạm đa tài khoản chuyên nghiệp, làm giảm đáng kể mức độ tin cậy được gán cho tài khoản.

Liên kết chéo và phát hiện trang trại tài khoản

Đây có lẽ là mối quan tâm lớn nhất đối với bất kỳ ai quản lý nhiều tài khoản.

Hãy tưởng tượng bạn đang chạy 50 cấu hình trình duyệt trên một máy duy nhất.

Mỗi cấu hình có:

• một vân tay trình duyệt duy nhất;

• một proxy chuyên dụng;

• một địa chỉ IP khác nhau.

Đối với các trang web bên ngoài, họ dường như là 50 người khác nhau. Tuy nhiên, hệ điều hành hoặc máy chủ cơ bản vẫn là một.

Điều đó có nghĩa là các dịch vụ nền tương tự đang chạy, để lộ cùng một bộ cổng mở. Sự kết hợp độc đáo này của các cổng mở có thể thực sự trở thành một siêu vân tay.

Một hệ thống chống gian lận có thể nhận ra rằng năm mươi người dùng được cho là không liên quan đều chia sẻ chính xác cùng một cấu hình dịch vụ cục bộ rất bất thường. Sau đó, nó có thể liên kết chúng lại với nhau thành một trang trại tài khoản duy nhất và shadow-ban (khóa ngầm) toàn bộ nhóm.

Nói cách khác, bằng cách quét localhost, các hệ thống chống bot có thể nhìn vào phía sau vân tay trình duyệt của bạn và phát hiện ra cơ sở hạ tầng thực tế cung cấp năng lượng cho thiết lập đa tài khoản của bạn.

Cách tự bảo vệ: cô lập và cấu hình tường lửa

Khi đối phó với các hệ thống chống gian lận tinh vi, chiến lược phòng thủ của bạn nên dựa trên các nguyên tắc sau:

1. Cô lập ngăn xếp mạng. Sử dụng các máy ảo hoặc container với môi trường mạng được cô lập nghiêm ngặt. Nếu trình duyệt chạy trong một môi trường cô lập hoàn toàn, các cuộc tấn công định thì sẽ trả về thời gian phản hồi tiêu chuẩn của các cổng đã đóng vì các dịch vụ chạy trên máy chủ vật lý không thể tiếp cận được từ bên trong môi trường ảo.

2. Cấu hình tường lửa của bạn một cách chính xác. Tường lửa của bạn không nên chỉ đơn giản là chặn các nỗ lực kết nối, nó nên từ chối chúng ngay lập tức. Cụ thể, sử dụng REJECT, hành động này trả về ngay lập tức một gói tin TCP RST, thay vì một hành động DROP, âm thầm loại bỏ các gói tin và buộc trình duyệt phải đợi thời gian chờ. Phản hồi REJECT bắt chước hành vi của một cổng bị đóng tự nhiên và do đó không có vẻ đáng ngờ đối với các thuật toán phát hiện dựa trên định thì.

3. Chặn hoàn toàn quyền truy cập localhost. Cách tiếp cận triệt để nhất—nhưng cũng hiệu quả nhất—là ngăn chặn hoàn toàn trình duyệt truy cập vào localhost. Điều này ngay lập tức vô hiệu hóa các tập lệnh chống gian lận cố gắng thăm dò hệ thống của bạn.

Tuy nhiên, cách tiếp cận này có nhược điểm: một số ứng dụng hợp pháp, chẳng hạn như phần mềm cho khóa bảo mật phần cứng hoặc các công cụ chữ ký số, giao tiếp thông qua các tác nhân cục bộ. Việc mất quyền truy cập vào các dịch vụ đó có thể tự biến thành một sự bất thường góp phần làm tăng điểm rủi ro cao hơn.

Do đó, có hai hướng tiếp cận thực tế:

• Lọc chi tiết. Chỉ cho phép truy cập vào các dịch vụ cục bộ đáng tin cậy ở cấp độ tường lửa hoặc tiện ích mở rộng trình duyệt, đồng thời từ chối ngay lập tức (sử dụng REJECT) bất kỳ nỗ lực ngầm nào nhằm thiết lập kết nối WebSocket đến các cổng cục bộ không xác định.

• Sử dụng các công cụ chuyên dụng. Lựa chọn khác là dựa vào phần mềm xử lý các vấn đề này ở cấp độ nhân trình duyệt, chẳng hạn như trình duyệt chống phát hiện.

Ví dụ, Octo Browser bao gồm tính năng bảo vệ tích hợp chống lại việc quét cổng cục bộ. Octo chặn đứng bất kỳ nỗ lực nào của các tập lệnh, bao gồm cả những tập lệnh sử dụng API WebSocket, để truy cập các địa chỉ trong phạm vi 127.0.0.0/8 hoặc localhost, xử lý chúng trực tiếp ở cấp độ API trình duyệt.

Kiểm tra các biện pháp bảo vệ

Bạn có thể dễ dàng thấy cách hoạt động của tính năng này bằng một bài kiểm tra đơn giản.

Đầu tiên, khởi động bất kỳ máy chủ cục bộ nào trên thiết bị của bạn để nó mở một cổng lắng nghe.

Một cổng mở sẽ trông giống như thế này.

Tiếp theo, mở bất kỳ trang web nào trong trình duyệt của bạn và cố gắng truy cập vào cổng đang mở đó.

Trong trình duyệt Chrome tiêu chuẩn, phản hồi sẽ đến với một chút chậm trễ. Sự chậm trễ đó xác nhận rằng cổng đang mở.

Thực hiện cùng một bài kiểm tra trong Octo Browser, và bạn sẽ thấy rằng cổng đó xuất hiện như thể đã bị đóng.

Octo Browser kiểm soát quyền truy cập vào các cổng cục bộ của bạn để ngăn chặn rò rỉ dữ liệu.

Private Network Access (PNA) có giải quyết được vấn đề này không?

Private Network Access (PNA) là một tính năng bảo mật được triển khai trong các trình duyệt hiện đại (chủ yếu là Chrome) nhằm ngăn chặn các trang web công khai gửi yêu cầu đến các thiết bị hoặc máy chủ trên mạng cục bộ của người dùng.

Các trình duyệt hiện đại cố gắng giảm thiểu lỗ hổng này bằng cách:

• hạn chế hoặc chặn hoàn toàn quyền truy cập vào localhost từ các ngữ cảnh công cộng không an toàn;

• yêu cầu một Ngữ cảnh An toàn (HTTPS) trước khi các kết nối đó có thể được bắt đầu;

• thực hiện các yêu cầu CORS preflight trước khi cho phép truy cập vào các tài nguyên mạng cục bộ.

Tuy nhiên, các nhà phát triển hệ thống chống gian lận cũng đã thích ứng với điều này. Họ sử dụng các miền công cộng phân giải thành 127.0.0.1 (ví dụ: yourapp.localhost.com) cùng với các chứng chỉ HTTPS hợp lệ, cho phép họ vượt qua một số hạn chế cơ bản này.

Quan trọng hơn, PNA không thể bảo vệ bạn khỏi các cuộc tấn công định thì ở cấp độ TCP. Ngay cả khi PNA cuối cùng chặn một yêu cầu vì thiếu các tiêu đề cần thiết, trước tiên trình duyệt phải thiết lập kết nối TCP trước khi nó có thể xác định xem các tiêu đề đó có được chấp nhận hay không. Nếu cổng bị đóng, hệ điều hành ngay lập tức từ chối kết nối bằng gói tin TCP RST. Nếu cổng mở, quá trình bắt tay TCP hoàn tất thành công. Trình duyệt sau đó cố gắng trao đổi dữ liệu, gặp phải các hạn chế PNA, chấm dứt kết nối và chỉ khi đó mới báo lỗi.

Những bước bổ sung đó mất hàng chục mili giây, chính xác là sự khác biệt về thời gian mà các thuật toán chống gian lận dựa vào. Nói cách khác, PNA ngăn các trang web đọc dữ liệu cục bộ, nhưng nó không thể che giấu thời gian cần thiết để thiết lập kết nối.

Kết luận

Ngày nay, tính năng ẩn danh hiệu quả đòi hỏi một cách tiếp cận toàn diện. Bạn có thể tạo ra những gì xuất hiện như một cấu hình trình duyệt hoàn hảo, nhưng một cổng gỡ lỗi bị lãng quên như 9222 hoặc một cổng cơ sở dữ liệu bị lộ có thể hoàn toàn hủy hoại nỗ lực giả mạo hoàn hảo trước đó của bạn. Hãy bảo vệ ngăn xếp mạng của bạn: cô lập môi trường làm việc, định cấu hình tường lửa cẩn thận hoặc dựa vào các giải pháp giải quyết các loại rò rỉ này ở cấp độ nhân trình duyệt.