Các tấn công sử dụng lỗ hổng TunnelCrack mới được phát hiện gần đây, tập trung vào thao túng máy khách để gửi lưu lượng truy cập ra bên ngoài đường hầm VPN, nghĩa là sẽ bị rò rỉ ở dạng rõ. Trong điều kiện bình thường, bảng định tuyến của máy khách đảm bảo rằng tất cả lưu lượng truy cập do máy khách tạo ra sẽ được gửi qua đường hầm VPN. Tuy nhiên, hầu hết máy khách đều thêm ngoại lệ vào bảng định tuyến để gửi hai loại lưu lượng bên ngoài đường hầm VPN, đó là lưu lượng được gửi đến, đi từ mạng nội bộ và lưu lượng được gửi đến, đi từ máy chủ VPN. Kẻ tấn công có thể thao túng các ngoại lệ định tuyến này để khiến cho lưu lượng truy cập tùy ý sẽ được gửi ngoài đường hầm VPN.
Đầu tiên, kẻ tấn công có thể thao túng dải địa chỉ IP của mạng nội bộ, gây rò rỉ lưu lượng Internet. Sau đó, trong điều kiện thích hợp, kẻ tấn công có thể giả mạo địa chỉ IP của máy chủ VPN, gây rò rỉ lưu lượng truy cập (tùy ý) một lần nữa do các ngoại lệ định tuyến ở trên. Hai ngoại lệ định tuyến này dẫn đến hai loại tấn công được gọi lần lượt là tấn công LocalNet (CVE-2023-36672 và CVE-2023-35838) và ServerIP (CVE-2023- 36673 và CVE-2023-36671) [1]. Ngoài ra, các tấn công này cũng có thể dẫn đến việc chặn lưu lượng truy cập mục tiêu trong khi VPN đang được sử dụng.
Tấn công LocalNet khai thác một ngoại lệ định tuyến phổ biến trong nhiều VPN, cụ thể là cho phép truy cập mạng nội bộ, để khiến máy nạn nhân gửi lưu lượng truy cập tùy ý không được mã hóa bên ngoài đường hầm VPN. Để đạt được điều này, kẻ tấn công mạng nội bộ tạo một AP (Access Point) giả mạo và đặt dải IP của mạng nội bộ thành dải chứa địa chỉ IP của máy chủ mục tiêu. Sau đó, máy khách VPN trên thiết bị của nạn nhân sẽ bị đánh lừa tin rằng trang web đang cố gắng kết nối nằm trong mạng nội bộ và không sử dụng đường hầm VPN khi giao tiếp với trang web đó.
Hình 1. Sơ đồ mạng của các tấn công LocalNet, trong đó lưu lượng đến “target.com” bị rò rỉ ra ngoài đường hầm VPN và sau đó được chuyển hướng đến một máy chủ độc hại
Kịch bản tấn công này được minh họa bằng ví dụ trong Hình 1. Thông thường, mạng nội bộ sẽ sử dụng dải địa chỉ IP riêng như 192.168.1.0/24. Nếu người dùng trong mạng này cố gắng truy cập máy chủ web có địa chỉ IP 1.2.3.20 thì đường hầm VPN sẽ được sử dụng. Tuy nhiên, nếu AP sử dụng dải địa chỉ IP 1.2.3.0/24 cho mạng nội bộ thì địa chỉ IP của máy chủ mục tiêu nằm trong mạng nội bộ này. Do đó, máy khách VPN của nạn nhân sẽ tin rằng máy chủ web đang cố gắng kết nối nằm trong cùng một mạng nội bộ với chính nó. Kết quả là máy khách sẽ cố gắng kết nối trực tiếp với máy chủ web mà không cần sử dụng đường hầm VPN.
Tấn công này cũng có thể được sử dụng để chặn gần như tất cả lưu lượng IP bằng cách gán dải IP 0.0.0.0/1 hoặc 128.0.0.0/1 cho mạng nội bộ. Sau đó, kẻ tấn công có thể chuyển tiếp các gói bị rò rỉ đến máy chủ thực và theo dõi kết nối kết quả để đánh cắp dữ liệu người dùng (trong trường hợp nạn nhân không sử dụng lớp bảo vệ khác như HTTPS). Ngoài ra, nếu sử dụng giao thức HTTP, kẻ tấn công có thể thiết lập một máy chủ nội bộ có cùng địa chỉ IP với máy chủ thực để lưu trữ một bản sao độc hại của trang web và đánh cắp thông tin xác thực của người dùng hoặc phát tán phần mềm độc hại. Trong trường hợp giao thức HTTPS được sử dụng, cuộc tấn công sẽ tiết lộ địa chỉ IP mà máy nạn nhân đang giao tiếp, địa chỉ này thường đủ thông tin để tìm hiểu trang web đang được truy cập. Đối phương cũng có thể cố gắng khởi động các tấn công tiếp theo chống lại bất kỳ giao thức bảo mật lớp cao hơn nào để đánh cắp thông tin người dùng.
Với một số VPN, tấn công trên không khiến máy nạn nhân gửi các gói ngoài đường hầm VPN mà thay vào đó khiến máy nạn nhân chặn các gói tới địa chỉ IP mục tiêu, đây cũng được coi là một rủi ro bảo mật. Ví dụ, đối phương có thể lạm dụng điều này để chặn lưu lượng truy cập và cảnh báo từ ứng dụng camera an ninh hoặc chặn các cập nhật bảo mật, trong khi các ứng dụng khác vẫn hoạt động bình thường, khiến nạn nhân không biết về tấn công.
Tấn công ServerIP khai thác một ngoại lệ định tuyến phổ biến khác, đó là lưu lượng được gửi đến địa chỉ IP của máy chủ VPN không gửi qua đường hầm VPN. Ngoại lệ này vốn để ngăn chặn các vòng lặp định tuyến bằng cách không mã hóa lại lưu lượng truy cập đã được mã hóa đến máy chủ VPN.
Việc rò rỉ lưu lượng truy cập đến địa chỉ IP của máy chủ VPN có thể gây ra rủi ro bảo mật. Đặc biệt, nó có thể bị lạm dụng để khử ẩn danh khách truy cập của một trang web. Điều này có thể đạt được thông qua lạm dụng chức năng của trang web, chẳng hạn như đưa hình ảnh từ xa vào bài đăng trên diễn đàn hoặc bằng cách xâm phạm máy chủ của trang web. Sau đó, bằng cách giám sát lưu lượng văn bản rõ đến địa chỉ IP của máy chủ VPN, địa chỉ IP thực của khách truy cập có thể được biết đến.
Nếu đối phương có thể kiểm soát địa chỉ IP mà máy khách sử dụng cho máy chủ VPN, ngoại lệ định tuyến trên có thể bị lợi dụng để rò rỉ lưu lượng truy cập tùy ý. Kẻ tấn công có thể nhắm vào các ứng dụng VPN sử dụng giao thức DNS rõ (không mã hóa) và giả mạo các phản hồi DNS để thay đổi địa chỉ của máy chủ. Trên thực tế, nếu hoạt động như một AP giả mạo, đối phương có thể sử dụng DHCP để gán cho máy khách một máy chủ DNS ưa thích và máy chủ này thậm chí có thể bị chính đối phương kiểm soát. Sau khi địa chỉ IP của máy chủ VPN bị giả mạo và máy nạn nhân cố gắng kết nối với máy chủ tại địa chỉ IP giả mạo, kẻ tấn công sẽ chuyển hướng các gói này đến máy chủ VPN thực để máy khách vẫn thiết lập thành công đường hầm VPN. Khi máy khách thiết lập đường hầm VPN, tất cả lưu lượng truy cập đến địa chỉ IP giả mạo sẽ không được gửi qua đường hầm VPN.
Tấn công này được minh họa bằng ví dụ trong Hình 2 dưới đây, trong đó mục tiêu của kẻ tấn công là chặn dữ liệu được gửi đến target.com, nghĩa là tới địa chỉ IP 1.2.3.4. Theo mặc định, máy chủ VPN vpn.com có địa chỉ IP 2.2.2.2, nghĩa là máy nạn nhân sẽ gửi lưu lượng truy cập đến trang web mục tiêu thông qua đường hầm VPN. Tuy nhiên, kẻ tấn công sẽ giả mạo các phản hồi DNS để máy nạn nhân cho rằng máy chủ VPN vpn.com có địa chỉ IP 1.2.3.4 và sẽ chuyển hướng lưu lượng VPN đến máy chủ VPN thực để máy nạn nhân vẫn có thể thiết lập kết nối VPN thành công. Kết quả là tất cả lưu lượng truy cập đến 1.2.3.4, tức là đến target.com, giờ đây sẽ được gửi ở dạng văn bản rõ bên ngoài đường hầm VPN.
Kiểu tấn công ServerIP cũng có thể bị lạm dụng để cố gắng chặn tất cả lưu lượng truy cập đến máy chủ DNS do máy khách VPN thiết lập. Kẻ tấn công có thể chặn các yêu cầu DNS và giả mạo phản hồi, cho phép chặn hầu hết lưu lượng truy cập dựa trên IP. Địa chỉ IP của máy chủ DNS do máy khách VPN thiết lập có thể được suy ra từ VPN mà máy nạn nhân sử dụng và ngược lại, VPN đang được sử dụng có thể được suy ra từ địa chỉ IP của máy chủ VPN.
Cách phòng thủ đơn giản và đầy đủ nhất chống lại các kiểu tấn công LocalNet là tắt lưu lượng truy cập nội bộ theo mặc định. Những máy khách có hỗ trợ và triển khai tắt lưu lượng truy cập nội bộ được xác nhận là đã ngăn chặn được tấn công này. Tuy nhiên, nhược điểm của biện pháp bảo vệ này là các kết nối hợp pháp trong mạng nội bộ, chẳng hạn như truy cập máy in sẽ không còn khả dụng khi sử dụng VPN. Do đó, nhược điểm này có thể được giảm nhẹ bằng cách vẫn cho phép lưu lượng truy cập nội bộ khi được kết nối với mạng đáng tin cậy. Một tùy chọn khác là triển khai định tuyến dựa trên chính sách, trong đó chỉ những ứng dụng cụ thể mới được phép truy cập mạng nội bộ.
Một biện pháp bảo vệ thay thế, trong trường hợp cần phải truy cập vào mạng nội bộ khi sử dụng VPN theo mặc định, là chỉ cho phép truy cập trực tiếp vào các địa chỉ IP không thể định tuyến. Đặc biệt, RFC 1918 định nghĩa các dải IP hợp lệ cho mạng riêng [2] và chỉ những dải IP này mới được loại trừ khỏi đường hầm VPN. Tuy nhiên, nếu VPN được sử dụng trong cài đặt đường hầm phân chia để có quyền truy cập từ xa vào mạng riêng (nội bộ) của một tổ chức, kẻ tấn công vẫn có thể thực hiện tấn công nhằm làm rò rỉ lưu lượng truy cập tới các dịch vụ của công ty được lưu trữ trong mạng riêng tư.
Một biện pháp bảo vệ chống lại các tấn công ServerIP là định tuyến dựa trên chính sách để gửi lưu lượng của tất cả các ứng dụng, ngoại trừ máy khách VPN, qua đường hầm VPN. Định tuyến dựa trên chính sách đã được giới thiệu trong Android 4.4 và định tuyến dựa trên người dùng có sẵn trên Linux kể từ kernel 4.4 [3]. Android 13 cũng đã thực hiện đúng cách tiếp cận này và do đó ngăn chặn được tấn công.
Một biện pháp giảm thiểu khác là xác minh địa chỉ IP của máy chủ VPN sau khi máy khách đã kết nối với máy chủ. Sau khi máy khách thiết lập kết nối an toàn với máy chủ VPN, máy chủ có thể gửi IP công cộng của nó qua kết nối an toàn này. Nếu địa chỉ IP được cung cấp không khớp với địa chỉ IP mà máy khách đang sử dụng cho máy chủ thì kết nối VPN sẽ bị ngắt, khi đó máy khách có thể thử kết nối lại với địa chỉ IP thực. Điều này ngăn chặn kẻ tấn công khiến máy khách loại trừ một địa chỉ IP tùy ý khỏi đường hầm VPN, ngăn chặn sự rò rỉ ngoài ý muốn. Tuy nhiên, điều này không ngăn chặn các tấn công khử ẩn danh, trong đó máy nạn nhân bị đánh lừa khởi tạo kết nối ở dạng rõ với chính máy chủ VPN.
Để làm rò rỉ lưu lượng truy cập tùy ý trong các tấn công ServerIP, kẻ tấn công cần giả mạo các phản hồi DNS. Do đó, tác động của tấn công có thể được giảm bớt bằng cách sử dụng DNS qua giao thức TLS hoặc HTTPS [4, 5]. Ngoài ra, DNSSEC có thể được sử dụng để xác thực tất cả các phản hồi DNS, nghĩa là kẻ tấn công không thể sửa đổi hoặc giả mạo chúng [6]. Khi sử dụng biến thể DNS được bảo vệ này, điều cần thiết là máy khách không quay trở lại DNS rõ khi các yêu cầu DNS được bảo vệ không thành công, vì kẻ tấn công có thể cố gắng chặn các yêu cầu DNS được bảo vệ và sau đó giả mạo phản hồi DNS khi máy khách quay lại sử dụng DNS rõ không được xác thực. Tuy nhiên, việc sử dụng DNS được bảo vệ cũng không ngăn chặn được các tấn công khử ẩn danh.
Bài báo đã đề cập đến hai tấn công sử dụng lỗ hổng TunnelCrack nhằm vào các máy khách VPN cho phép kẻ tấn công thao túng bảng định tuyến của máy nạn nhân để làm rò rỉ các gói ra bên ngoài đường hầm VPN, đồng thời đưa ra một số biện pháp giúp phòng chống các tấn công đó. Các tấn công này là độc lập với giao thức VPN đang được sử dụng, do đó có khả năng ảnh hưởng đến tất cả các giao thức phổ biến như PPTP, OpenVPN, Ipsec/IKEv2, SSTP và WireGuard.
|
TÀI LIỆU THAM KHẢO [1]. https://www.kaspersky.com/blog/how-to-fix-tunnelcrack-vpn-leak/48788/. [2]. RFC 1918: Address Allocation for Private Internets, 1996. [3]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4fb74506838b. [4]. RFC 8484: DNS Queries over HTTPS (DoH), 2018. [5]. RFC 7858: DNS over Transport Layer Security (TLS), 2016. [6]. RFC 4033: DNS Security Introduction and Requirements, 2005. |
ThS. Hoàng Thu Phương, Nguyễn Đình Đại (Viện Khoa học - Công nghệ mật mã)
15:00 | 19/02/2024
10:00 | 01/06/2023
08:00 | 17/04/2024
14:00 | 16/05/2023
13:00 | 26/02/2024
Operation Triangulation là một chiến dịch phức tạp nhắm vào thiết bị iOS trong các cuộc tấn công zero-click. Tạp chí An toàn thông tin đã từng cung cấp một số bài viết liên quan đến chiến dịch này, như giải mã tính năng che giấu của phần mềm độc hại TriangleDB, những cuộc tấn công zero-day trên thiết bị iOS hay giới thiệu cách sử dụng công cụ bảo mật phát hiện tấn công zero-click. Tiếp nối chuỗi bài viết về chiến dịch Operation Triangulation, bài viết sẽ phân tích các phương thức khai thác, tấn công chính của tin tặc trong chuỗi tấn công này, dựa trên báo cáo của hãng bảo mật Kaspersky.
08:00 | 06/11/2023
Khi 5G ngày càng phổ biến và được nhiều doanh nghiệp sử dụng cho truyền tải không dây, một câu hỏi quan trọng được đặt ra đó là: “Ai chịu trách nhiệm đảm bảo bảo mật cho 5G?”. Việc triển khai 5G bảo mật bao gồm nhiều khía cạnh và trách nhiệm, nó sẽ là trách nhiệm chung của cả các nhà cung cấp dịch vụ và các doanh nghiệp triển khai.
17:00 | 11/08/2023
Wireless Mesh Network là công nghệ mạng truyền thông đầy hứa hẹn với khả năng kết nối mạnh mẽ và ổn định, được ứng dụng trong nhiều lĩnh vực khác nhau. Trong số 1 (071) 2023 của Tạp chí An toàn thông tin, nhóm tác giả đã giới thiệu về cơ sở lý thuyết của Wifi Mesh. Để ứng dụng thực tiễn nền tảng này, trong bài báo dưới đây nhóm tác giả đề xuất một giải pháp thiết kế hệ thống giám sát độ nghiêng của thiết bị trong không gian ba chiều X, Y, Z sử dụng module ESP32 WROOM có tính năng truyền nhận dữ liệu bằng Wifi Mesh.
14:00 | 17/05/2023
Một trong những lý do khiến các tổ chức e ngại khi sử dụng các dịch vụ điện toán đám mây là vấn đề về an toàn thông tin. Tuy nhiên, dù nhìn nhận từ góc độ nào thì hầu hết chúng ta đều phải công nhận là các nhà cung cấp dịch vụ điện toán đám mây lớn như Amazon, Microsoft hay Google đều có nhiều nguồn lực và nhân sự giỏi về an ninh bảo mật hơn hầu hết các doanh nghiệp khác. Vậy tại sao chúng ta liên tục nhận được tin tức về các sự cố bảo mật của các doanh nghiệp khi sử dụng điện toán đám mây?
08:00 | 11/01/2024 | Chính sách - Chiến lược
09:00 | 10/01/2024 | Giải pháp khác
09:00 | 05/01/2024|Chính sách - Chiến lược
09:00 | 05/01/2024|An ninh – Quốc Phòng
Lược đồ chữ ký số dựa trên hàm băm là một trong những lược đồ chữ ký số kháng lượng tử đã được Viện Tiêu chuẩn và Công nghệ Quốc gia Mỹ (NIST) chuẩn hóa trong tiêu chuẩn đề cử FIPS 205 (Stateless Hash Based Digital Signature Standard) vào tháng 8/2023. Bài báo này sẽ trình bày tổng quan về sự phát triển của của lược đồ chữ ký số dựa trên hàm băm thông qua việc phân tích đặc trưng của các phiên bản điển hình của dòng lược đồ chữ ký số này.
09:00 | 01/04/2024
Theo báo cáo năm 2022 về những mối đe doạ mạng của SonicWall, trong năm 2021, thế giới có tổng cộng 623,3 triệu cuộc tấn công ransomware, tương đương với trung bình có 19 cuộc tấn công mỗi giây. Điều này cho thấy một nhu cầu cấp thiết là các tổ chức cần tăng cường khả năng an ninh mạng của mình. Như việc gần đây, các cuộc tấn công mã độc tống tiền (ransomware) liên tục xảy ra. Do đó, các tổ chức, doanh nghiệp cần quan tâm hơn đến phương án khôi phục sau khi bị tấn công.
19:00 | 30/04/2024
