MrQuậy
Well-Known Member
-
24/09/2013
-
178
-
2.221 bài viết
Tấn công làm lộ địa chỉ truy cập qua giao thức HTTPS
Các nhà nghiên cứu vừa phát hiện một kiểu tấn công mới có thể làm lộ các địa chỉ truy cập qua giao thức HTTPS.
Kiểu tấn công này có thể thực hiện bởi người quản trị của các loại mạng, kể cả mạng Wifi công cộng, nơi mà người lướt web cần tới sự bảo vệ của HTTPS nhiều nhất. Thông qua việc lợi dụng tính năng WPAD (Web Proxy Autodisovery) tin tặc có đoạn mã khai thác được và chiếm quyền điều khiển hệ thống mạng. Kết quả nghiên cứu được trình bày lần đầu tiên tại hội thảo Black Hat ở Las Vegas tháng 8/2016. Kẻ tấn công có thể xem toàn bộ URL của tất cả các site mà người dùng đã duyệt qua. Hầu như mọi trình duyệt và hệ điều hành đều có thể bị lợi dụng.
Itzik Kotler, đồng sáng lập và là giám đốc công nghệ (CTO) của công ty bảo mật SafeBreach, thông báo rằng: “Mọi người dựa vào HTTPS để bảo mật các trao đổi ngay cả khi mạng LAN/Wifi không tin cậy (các mạng Wifi công cộng hay mạng LAN có thể bị tin tặc kiểm soát). Chúng tôi chứng minh rằng, HTTPS không thể đảm bảo bí mật khi tính năng WPAD được kích hoạt”. Vì kiểu tấn công này không lợi dụng giao thức TLS/SSL, nên việc cập nhật các thư viện hay thay đổi cấu hình của TLS/SSL không thể ngăn chặn nó.
Ngoài địa chỉ đầy đủ của các URL, tất cả các thông tin khác truyền qua HTTPS chưa bị lộ. Tuy nhiên, trong một số trường hợp, việc lộ URL có thể dẫn đến các nguy cơ về bảo mật. Chẳng hạn như chuẩn OpenID dùng các URL để xác thực người dùng cho các site và các dịch vụ hỗ trợ chuẩn này hoặc các dịch vụ chia sẻ tài liệu như của Google và Dropbox, hoạt động dựa vào các token bảo mật đặt trong các URL.
Tương tự, cơ chế đặt lại mật khẩu của một số ứng dụng/dịch vụ dựa vào các URL chứa token bảo mật nên tin tặc nắm được các URL kiểu đó có thể có quyền truy cập đầy đủ vào tài khoản và dữ liệu của người dùng. Các URL chứa thông tin xác thực người dùng (username/password) của các giao thức HTTP/HTTPS, FTP cũng là đích tấn công của tin tặc.
Tuy nhiên, khả năng chiếm đoạt thông tin xác thực người dùng của tin tặc còn phụ thuộc vào trình duyệt. Các trình duyệt như Chrome, Firefox dễ dàng bị tin tặc thực hiện kiểu tấn công này. Thông tin xác thực người dùng của HTTPS/HTTP chỉ có thể bị lộ khi người dùng sử dụng Firefox. Trong khi đó, tin tặc có thể chiếm thông tin xác thực người dùng của giao thức FTP với nhiều trình duyệt khác nhau: Firefox, IE8, Safari.
Cách dễ nhất để thực hiện cuộc tấn công kiểu này là người quản trị mạng gửi một phản hồi độc hại khi một máy tính dùng giao thức cấu hình động máy chủ DHCP để kết nối mạng. Ngoài việc cung cấp địa chỉ, DHCP còn dùng để thiết lập proxy server mà trình duyệt sẽ dùng để truy cập một số địa chỉ mạng nhất định, bằng cách buộc trình duyệt sử dụng một tệp proxy autoconfig (PAC), trong đó chỉ định những kiểu URL nào cần sử dụng proxy. Vì việc cấu hình này được thực hiện trước khi thiết lập các kết nối HTTPS, nên tin tặc có thể đọc được bản rõ đầy đủ của URL.
Tệp proxy auto-config (PAC) sử dụng Javascriptbased - dù đã bị hạn chế nên có thể truy cập tới khá nhiều hàm như: dnsDomainIs, isInNet, isPlainHostName, localHostOrDomainIs, dnsDomainLevels, weekdayRange.
Cách thứ hai là dùng mã độc sửa đổi các thiết lập mạng trên máy tính của người dùng để buộc họ dùng proxy.
Trong cả hai trường hợp, người dùng đều không phát hiện thấy dấu hiệu nào khả nghi và thanh địa chỉ của trình duyệt vẫn cho thấy các kết nối HTTPS hợp lệ. Khác biệt có thể nhận thấy, trong kịch bản thứ nhất, là thiết lập mạng của máy tính (ví dụ như tab Proxies trong phần thiết lập nâng cao của mạng trên máy Mac) sẽ cho thấy nó đang sử dụng proxy auto-discovery mà không kèm thêm chi tiết nào. Trong kịch bản thứ hai (tấn công bằng mã độc), cấu hình mạng của máy tính sẽ thể hiện nó đang dùng proxy auto-configuration và hiển thị URL của kẻ tấn công. Tuy nhiên, việc sửa đổi để thiết lập PAC trên máy tính của người dùng được thực hiện khá đơn giản khi mà can thiệp vào registry.
Ngoài các máy tính sử dụng Windows, PAC URL còn được hỗ trợ trên iPhone và thiết bị sử dụng hệ điều hành Android 5.0 trở lên.
Việc định hướng lại để đi qua proxy có thể dùng để tấn công DDoS các địa chỉ từ xa hoặc tấn công DoS ngay trong bản thân máy bị nhiễm độc (ví dụ như ngăn chặn các bản cập nhật an toàn được thực hiện qua giao thức HTTP/HTTPS).
Lỗ hổng cho phép thực hiện các tấn công này liên quan đến đặc tả WPAD - được phát hiện lần đầu vào năm 1999. Điều này cho thấy nó không dễ được khắc phục bởi các nhà phát triển hệ điều hành hay trình duyệt. Dù vậy, các trình duyệt có thể tìm đường vòng để tránh lỗi theo cách thức của Edge và Internet Explorer 11 - những trình duyệt gọi hàm FindProxyForUrl với các địa chỉ đã được cắt ngắn, chỉ để lại địa chỉ máy chủ. Người dùng cuối cũng có thể tìm cách vô hiệu hóa WPAD, nhưng cách này không thực hiện được trong các trường hợp cần tới tính năng này để truy cập một mạng nào đó.
Trong khi chờ đợi các nhà phát triển hệ điều hành, trình duyệt khắc phục lỗ hổng này, người dùng nên vô hiệu hóa WPAD với các mạng không tin cậy, dùng các trình duyệt ít bị ảnh hưởng như Edge hay Internet Explorer 11. Các doanh nghiệp nên áp dụng chính sách để tắt WPAD trên tất cả các thiết bị đầu cuối, loại bỏ thông tin nhạy cảm khỏi các URL bằng cách đưa chúng vào cookie hay header của các HTTP request.
Nguyễn Anh Tuấn (tổng hợp)
Theo ATTT
Kiểu tấn công này có thể thực hiện bởi người quản trị của các loại mạng, kể cả mạng Wifi công cộng, nơi mà người lướt web cần tới sự bảo vệ của HTTPS nhiều nhất. Thông qua việc lợi dụng tính năng WPAD (Web Proxy Autodisovery) tin tặc có đoạn mã khai thác được và chiếm quyền điều khiển hệ thống mạng. Kết quả nghiên cứu được trình bày lần đầu tiên tại hội thảo Black Hat ở Las Vegas tháng 8/2016. Kẻ tấn công có thể xem toàn bộ URL của tất cả các site mà người dùng đã duyệt qua. Hầu như mọi trình duyệt và hệ điều hành đều có thể bị lợi dụng.
Itzik Kotler, đồng sáng lập và là giám đốc công nghệ (CTO) của công ty bảo mật SafeBreach, thông báo rằng: “Mọi người dựa vào HTTPS để bảo mật các trao đổi ngay cả khi mạng LAN/Wifi không tin cậy (các mạng Wifi công cộng hay mạng LAN có thể bị tin tặc kiểm soát). Chúng tôi chứng minh rằng, HTTPS không thể đảm bảo bí mật khi tính năng WPAD được kích hoạt”. Vì kiểu tấn công này không lợi dụng giao thức TLS/SSL, nên việc cập nhật các thư viện hay thay đổi cấu hình của TLS/SSL không thể ngăn chặn nó.
Ngoài địa chỉ đầy đủ của các URL, tất cả các thông tin khác truyền qua HTTPS chưa bị lộ. Tuy nhiên, trong một số trường hợp, việc lộ URL có thể dẫn đến các nguy cơ về bảo mật. Chẳng hạn như chuẩn OpenID dùng các URL để xác thực người dùng cho các site và các dịch vụ hỗ trợ chuẩn này hoặc các dịch vụ chia sẻ tài liệu như của Google và Dropbox, hoạt động dựa vào các token bảo mật đặt trong các URL.
Tương tự, cơ chế đặt lại mật khẩu của một số ứng dụng/dịch vụ dựa vào các URL chứa token bảo mật nên tin tặc nắm được các URL kiểu đó có thể có quyền truy cập đầy đủ vào tài khoản và dữ liệu của người dùng. Các URL chứa thông tin xác thực người dùng (username/password) của các giao thức HTTP/HTTPS, FTP cũng là đích tấn công của tin tặc.
Tuy nhiên, khả năng chiếm đoạt thông tin xác thực người dùng của tin tặc còn phụ thuộc vào trình duyệt. Các trình duyệt như Chrome, Firefox dễ dàng bị tin tặc thực hiện kiểu tấn công này. Thông tin xác thực người dùng của HTTPS/HTTP chỉ có thể bị lộ khi người dùng sử dụng Firefox. Trong khi đó, tin tặc có thể chiếm thông tin xác thực người dùng của giao thức FTP với nhiều trình duyệt khác nhau: Firefox, IE8, Safari.
Cách dễ nhất để thực hiện cuộc tấn công kiểu này là người quản trị mạng gửi một phản hồi độc hại khi một máy tính dùng giao thức cấu hình động máy chủ DHCP để kết nối mạng. Ngoài việc cung cấp địa chỉ, DHCP còn dùng để thiết lập proxy server mà trình duyệt sẽ dùng để truy cập một số địa chỉ mạng nhất định, bằng cách buộc trình duyệt sử dụng một tệp proxy autoconfig (PAC), trong đó chỉ định những kiểu URL nào cần sử dụng proxy. Vì việc cấu hình này được thực hiện trước khi thiết lập các kết nối HTTPS, nên tin tặc có thể đọc được bản rõ đầy đủ của URL.
Tệp proxy auto-config (PAC) sử dụng Javascriptbased - dù đã bị hạn chế nên có thể truy cập tới khá nhiều hàm như: dnsDomainIs, isInNet, isPlainHostName, localHostOrDomainIs, dnsDomainLevels, weekdayRange.
Cách thứ hai là dùng mã độc sửa đổi các thiết lập mạng trên máy tính của người dùng để buộc họ dùng proxy.
Trong cả hai trường hợp, người dùng đều không phát hiện thấy dấu hiệu nào khả nghi và thanh địa chỉ của trình duyệt vẫn cho thấy các kết nối HTTPS hợp lệ. Khác biệt có thể nhận thấy, trong kịch bản thứ nhất, là thiết lập mạng của máy tính (ví dụ như tab Proxies trong phần thiết lập nâng cao của mạng trên máy Mac) sẽ cho thấy nó đang sử dụng proxy auto-discovery mà không kèm thêm chi tiết nào. Trong kịch bản thứ hai (tấn công bằng mã độc), cấu hình mạng của máy tính sẽ thể hiện nó đang dùng proxy auto-configuration và hiển thị URL của kẻ tấn công. Tuy nhiên, việc sửa đổi để thiết lập PAC trên máy tính của người dùng được thực hiện khá đơn giản khi mà can thiệp vào registry.
Ngoài các máy tính sử dụng Windows, PAC URL còn được hỗ trợ trên iPhone và thiết bị sử dụng hệ điều hành Android 5.0 trở lên.
Việc định hướng lại để đi qua proxy có thể dùng để tấn công DDoS các địa chỉ từ xa hoặc tấn công DoS ngay trong bản thân máy bị nhiễm độc (ví dụ như ngăn chặn các bản cập nhật an toàn được thực hiện qua giao thức HTTP/HTTPS).
Lỗ hổng cho phép thực hiện các tấn công này liên quan đến đặc tả WPAD - được phát hiện lần đầu vào năm 1999. Điều này cho thấy nó không dễ được khắc phục bởi các nhà phát triển hệ điều hành hay trình duyệt. Dù vậy, các trình duyệt có thể tìm đường vòng để tránh lỗi theo cách thức của Edge và Internet Explorer 11 - những trình duyệt gọi hàm FindProxyForUrl với các địa chỉ đã được cắt ngắn, chỉ để lại địa chỉ máy chủ. Người dùng cuối cũng có thể tìm cách vô hiệu hóa WPAD, nhưng cách này không thực hiện được trong các trường hợp cần tới tính năng này để truy cập một mạng nào đó.
Trong khi chờ đợi các nhà phát triển hệ điều hành, trình duyệt khắc phục lỗ hổng này, người dùng nên vô hiệu hóa WPAD với các mạng không tin cậy, dùng các trình duyệt ít bị ảnh hưởng như Edge hay Internet Explorer 11. Các doanh nghiệp nên áp dụng chính sách để tắt WPAD trên tất cả các thiết bị đầu cuối, loại bỏ thông tin nhạy cảm khỏi các URL bằng cách đưa chúng vào cookie hay header của các HTTP request.
Nguyễn Anh Tuấn (tổng hợp)
Theo ATTT