Biện pháp bảo mật mới của Chrome nhằm hạn chế toàn bộ các kiểu tấn công Web

Tin tặc từ lâu đã sử dụng các trình duyệt như một phương tiện tấn công. Google đã nhắm đến PNA (Private Network Access) để thay đổi điều đó.

Trong hơn một thập kỷ, Internet vẫn dễ bị tấn công bởi một loạt các cuộc tấn công sử dụng trình duyệt làm cơ sở để truy cập vào các bộ định tuyến (router) và các thiết bị nhạy cảm khác trên một mạng máy tính được nhắm làm mục tiêu. Và bây giờ, Google cuối cùng cũng tìm được cách để khắc phục điểm yếu này.

Bắt đầu từ phiên bản Chrome 98, trình duyệt sẽ bắt đầu chuyển tiếp các yêu cầu khi một trang web công cộng bên ngoài muốn truy cập đến các điểm cuối (endpoint) bên trong mạng riêng của người dùng đang truy cập trang web. Hiện tại, các yêu cầu không thành công sẽ không ngăn cản các kết nối xảy ra. Thay vào đó, chúng sẽ chỉ được ghi lại. Có thể trong Chrome 101 — giả sử kết quả của quá trình chạy thử này không cho thấy các phần chính của Internet sẽ bị hỏng — các trang web công cộng bắt buộc phải có sự cho phép rõ ràng trước khi chúng có thể truy cập vào điểm cuối phía sau trình duyệt.

Việc ngừng sử dụng quyền truy cập này theo kế hoạch diễn ra khi Google kích hoạt một thông số kỹ thuật mới được gọi là quyền truy cập mạng riêng tư, PNA-Private Network Acess, cho phép các trang web công cộng chỉ truy cập tài nguyên mạng nội bộ sau khi các trang web đã yêu cầu rõ ràng và trình duyệt cho phép yêu cầu đó. Thông tin liên lạc PNA được gửi bằng giao thức CORS, hay còn gọi là Cross-Origin Resource Sharing (Chia sẻ tài nguyên đa nguồn gốc). Theo cơ chế này, trang web công khai sẽ gửi trước một yêu cầu preflight dưới dạng header mới Access-Control-Request-Private-Network: true. Để yêu cầu này được cấp phép, trình duyệt phải trả lời với header tương ứng Access-Control-Allow-Private-Network: true.

Xâm nhập mạng qua trình duyệt

Cho đến nay, các trang web, theo mặc định, đều có khả năng sử dụng Chrome và các trình duyệt khác làm proxy để truy cập các tài nguyên bên trong mạng cục bộ của người dùng đang truy cập trang web đó. Mặc dù các thiết bị như bộ định tuyến, máy in hoặc các nội dung mạng khác thường bị khóa, nhưng các trình duyệt — do nhu cầu tương tác với rất nhiều dịch vụ — theo mặc định lại được phép kết nối với hầu như bất kỳ tài nguyên nào bên trong phạm vi mạng cục bộ. Điều này đã làm phát sinh một loại tấn công được gọi là CSRF, viết tắt của cross-site request forgery (giả mạo yêu cầu trên nhiều trang web).

Các cuộc tấn công như vậy, đã được đưa ra trên lý thuyết trong hơn một thập kỷ, và cũng đã được thực hiện trong thực tế, thường gây ra những hậu quả đáng kể. Trong một sự cố năm 2014, tin tặc đã sử dụng CSRF để thay đổi cài đặt máy chủ DNS cho hơn 300.000 bộ định tuyến không dây.

Thay đổi này khiến các bộ định tuyến bị xâm nhập sử dụng các máy chủ DNS độc hại để phân giải địa chỉ IP mà người dùng cuối đang cố gắng truy cập. Ví dụ: thay vì truy cập vào trang Google.com chính danh, máy chủ độc hại có thể trả lại địa chỉ IP cho một trang web mạo danh mà người dùng cuối không có lý do gì để tin là có hại. Hình ảnh dưới đây, từ các nhà nghiên cứu tại Team Cymru, cho thấy ba bước liên quan đến các cuộc tấn công đó.

Ba giai đoạn của cuộc tấn công làm thay đổi cài đặt DNS của bộ định tuyến, bằng cách khai thác lỗ hổng yêu cầu chéo trang trong giao diện Web của thiết bị.

Vào năm 2016, những kẻ đứng sau cuộc tấn công tương tự đã quay trở lại để phát tán phần mềm độc hại được gọi là DNSChanger. Như tôi đã giải thích vào thời điểm đó, chiến dịch này đã hoạt động tấn công vào các bộ định tuyến gia đình và văn phòng của các nhà sản xuất Netgear, DLink, Comtrend và Pirelli được thực hiện theo cách này:

DNSChanger sử dụng một tập hợp các giao thức truyền thông thời gian thực được gọi là webRTC để gửi cái gọi là yêu cầu máy chủ STUN được sử dụng trong truyền thông VoIP. Việc khai thác cuối cùng có thể tạo mã kênh thông qua trình duyệt Chrome dành cho Windows và Android để truy cập bộ định tuyến mạng. Sau đó, cuộc tấn công sẽ đối chiếu bộ định tuyến đã truy cập được với kho 166 “dấu vân tay” hình ảnh phần mềm firmware của các bộ định tuyến đã bị tấn công trước đó.

Giả sử đặc tả kỹ thuật PNA hoàn toàn có hiệu lực, Chrome sẽ không cho phép các kết nối như vậy nữa, trừ khi các thiết bị bên trong mạng riêng của người dùng cho phép rõ ràng. Đây là hai sơ đồ cho thấy biện pháp này hoạt động như thế nào.

Con đường còn ở phía trước

Bắt đầu từ phiên bản 98, nếu Chrome phát hiện thấy một yêu cầu muốn truy cập mạng riêng tư, thì một “yêu cầu đặt trước” sẽ được gửi đến trình duyệt trước. Nếu yêu cầu preflight này không thành công, yêu cầu cuối cùng sẽ vẫn được gửi nhưng cảnh báo sẽ hiển thị trong bảng các sự cố DevTools.

“Bất kỳ yêu cầu gửi trước nào không thành công sẽ dẫn đến việc tìm nạp nội dung không thành công”, kỹ sư Titouan Rigoudy của Google và nhà phát triển Google Eiji Kitamura đã viết trong một bài đăng trên blog gần đây. “Điều này có thể cho phép bạn kiểm tra xem trang web của mình có hoạt động sau giai đoạn thứ hai của kế hoạch triển khai của chúng tôi hay không. Các lỗi có thể được chẩn đoán theo cách giống như cảnh báo bằng cách sử dụng bảng DevTools được đề cập ở trên.”

Nếu và khi Google tự tin rằng sẽ không có gián đoạn truy cập hàng loạt, các yêu cầu preflight sẽ phải được chấp thuận để thực hiện.

* New Chrome security measure aims to curtail an entire class of Web attack | Ars Technica

Trả lời

Email của bạn sẽ không được hiển thị công khai.

Back to top button