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
14:00 | 27/01/2025
Khi làm việc trên Internet mỗi ngày, người dùng phải quản lý rất nhiều tài khoản và mật khẩu khác nhau, điều này khiến việc ghi nhớ trở nên khó khăn và dễ gây nhầm lẫn. Khi cần đăng nhập vào bất kỳ tài khoản nào, người dùng phải tìm kiếm lại thông tin khá mất thời gian, ảnh hưởng đến tiến độ công việc. Chính vì vậy, chúng ta cần tạo thói quen sử dụng trình quản lý mật khẩu để quản lý ổn định và an toàn cho các tài khoản, mật khẩu của mình. Bài viết dưới dây sẽ giúp người dùng hiểu và sử dụng dễ dàng phần mềm LastPass, một trong những phần mềm quản lý mật khẩu phổ biến nhất hiện nay.
13:00 | 21/08/2024
Tội phạm mạng gần đây đã chuyển từ tấn công các tập đoàn đa ngành lớn sang các ngành công nghiệp hẹp hơn, ví dụ như các lĩnh vực dịch vụ tài chính hoặc chăm sóc sức khỏe. Đặc biệt trong lĩnh vực chăm sóc sức khỏe, tin tặc chú trọng nhắm mục tiêu vào các thiết bị y tế của bệnh nhân được kết nối với Internet. Bài báo sẽ thông tin tới độc giả tình tình an ninh mạng trong lĩnh vực y tế, chăm sóc sức khỏe, các mối đe dọa từ bên trong, bên ngoài và đưa ra một số giải pháp giúp cải thiện tình hình an ninh mạng trong lĩnh vực này.
10:00 | 27/05/2024
Quản lý rủi ro chuỗi cung ứng (Supply Chain Risk Management - SCRM) là quá trình tìm kiếm và giải quyết các lỗ hổng tiềm ẩn trong chuỗi cung ứng của một doanh nghiệp. Mục đích của SCRM là nhằm giảm thiểu tác động của những rủi ro này đối với hoạt động, thương hiệu và hiệu quả tài chính của doanh nghiệp.
11:00 | 13/05/2024
Trong lĩnh vực chữ ký số, lược đồ ký số dựa trên đường cong Elliptic (ECDSA) được đánh giá là một trong những lược đồ chữ ký số có độ an toàn cao, dù ra đời sau nhưng ECDSA đang dần được thay thế cho lược đồ ký số RSA. Bài báo này tập trung giới thiệu lược đồ ECDSA, ứng dụng của ECDSA trong thực tế và các tham số an toàn được khuyến nghị dùng cho ECDSA.
22:00 | 30/01/2025|Giải pháp khác
08:00 | 29/01/2025|Công nghệ thông tin
Trong bối cảnh chuyển đổi số và ứng dụng rộng rãi của công nghệ thông tin (CNTT) thì xu hướng kết nối liên mạng để chia sẻ cơ sở dữ liệu (CSDL) trở nên tất yếu. Các hệ thống công nghệ vận hành (Operational Technology - OT) cũng không nằm ngoài xu hướng này, quá trình đó được gọi là Hội tụ IT/OT. Do vậy, nhu cầu truyền dữ liệu một chiều giữa các mạng độc lập ngày càng tăng để phục vụ cho mục đích khai thác dữ liệu. Bài viết này giới thiệu một giải pháp mới dựa trên công nghệ vi mạch tích hợp khả trình (Field-Programmable Gate Array - FPGA), sử dụng cơ chế xử lý đa luồng tốc độ cao, giúp duy trì băng thông hệ thống mà không gây ra tình trạng treo hoặc nghẽn mạng, cho phép các kết nối yêu cầu thời gian thực. Đồng thời, bài viết cũng sẽ trình bày giải pháp giả lập giao thức TCP/IP hỗ trợ cho các giao thức truyền thông trong các hệ thống mạng điều khiển IT/OT.
09:00 | 06/01/2025
Trong bối cảnh phát triển mạnh mẽ của Trí tuệ nhân tạo (AI), vấn đề khai thác lỗ hổng (Jailbreak) đã trở thành một thách thức đáng chú ý trong việc quản lý và kiểm soát mô hình ngôn ngữ lớn tạo sinh (Generative Pre-trained Transformer - GPT). Trong phạm vi bài viết này, nhóm tác giả sẽ giới thiệu tổng quan về mô hình ngôn ngữ lớn GPT hiện nay, một số phương thức khai thác lỗ hổng trong mô hình GPT và cung cấp một góc nhìn về khai thác lỗ hổng trong tương lai.
22:00 | 30/01/2025
