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
09:00 | 08/03/2024
Từ lâu, botnet là một trong những mối đe dọa lớn nhất đối với an ninh mạng, nó đã gây ra nhiều thiệt hại cho các tổ chức và doanh nghiệp trên toàn thế giới. Bài báo sẽ giới thiệu tới độc giả một số kỹ thuật phát hiện botnet bằng Honeynet và tính hiệu quả của chúng, đồng thời đề xuất một số hướng phát triển trong tương lai để nâng cao khả năng phát hiện và ngăn chặn botnet bằng Honeynet.
13:00 | 29/12/2023
Hiện nay, số lượng các vụ tấn công mạng trên ứng dụng web đang có xu hướng ngày càng gia tăng cả về quy mô lẫn mức độ tinh vi, với mục tiêu nhắm vào các dịch vụ cơ sở trọng yếu, khối tài chính, ngân hàng và các tổ chức/doanh nghiệp (TC/DN) lớn. Hậu quả của các cuộc tấn công này có thể là giả mạo giao dịch, gián đoạn hoạt động kinh doanh hay vi phạm dữ liệu, dẫn đến nguy cơ rò rỉ thông tin và mất mát dữ liệu quan trọng. Điều này gây ra nhiều thiệt hại đáng kể về tài chính cũng như uy tín của các TC/ DN. Bài báo sẽ trình bày thực trạng về bảo mật ứng dụng web năm 2023 dựa trên báo cáo của công ty an ninh mạng OPSWAT, cùng các giải pháp phòng tránh mối đe dọa tấn công mạng này.
10:00 | 10/11/2023
Google đã thực hiện một bước quan trọng nhằm tăng cường bảo mật Internet của Chrome bằng cách tự động nâng cấp các yêu cầu HTTP không an toàn lên các kết nối HTTPS cho toàn bộ người dùng.
15:00 | 24/10/2023
Google cho biết đang thử nghiệm tính năng “IP Protection” mới cho trình duyệt Chrome để nâng cao quyền riêng tư của người dùng bằng cách che giấu địa chỉ IP của họ bằng máy chủ proxy.
14:00 | 11/09/2024|Công nghệ PKI
11:00 | 03/09/2024|GP ATM
08:00 | 26/08/2024|GP ATM
10:00 | 19/08/2024|Tin tức sản phẩm
Trong thời đại ngày nay, cùng với sự phát triển của khoa học kỹ thuật có ngày càng nhiều những cuộc tấn công vào phần cứng và gây ra nhiều hậu quả nghiêm trọng. So với các loại tấn công khác, tấn công qua kênh kề đang được nghiên cứu do khả năng khôi phục lại khóa bí mật trong khi hệ thống vẫn hoạt động bình thường mà không hề làm thay đổi phần cứng. Bài báo này sẽ trình bày một cách sơ lược về những kết quả cuộc tấn công kênh kề lên mã hóa RSA cài đặt trên điện thoại thông minh sử dụng hệ điều hành Android tại Viện Khoa học - Công nghệ mật mã. Nhóm tác giả đã tấn công khôi phục được một phần khóa bí mật của mã hóa RSA cài đặt trên điện thoại thông minh và chứng minh khả năng rò rỉ thông tin qua kênh kề.
14:00 | 11/09/2024
Trong thời đại kỹ thuật số ngày nay, ransomware đã trở thành một trong những mối đe dọa nguy hiểm nhất đối với cả cá nhân lẫn tổ chức. Đây không chỉ là một loại phần mềm độc hại, mà còn là một công cụ về chính trị và kinh tế của các nhóm tội phạm mạng. Ransomware không chỉ gây tổn thất về tài chính mà còn đe dọa đến sự bảo mật thông tin, uy tín và hoạt động kinh doanh của các tổ chức. Bài báo này sẽ trang bị một số kỹ năng cần thiết cho các tổ chức để thực hiện các biện pháp giúp giảm thiểu tác động của các cuộc tấn công ransomware, nhấn mạnh việc triển khai một cách chủ động để bảo vệ hệ thống trước các mối nguy hiểm tiềm tàng.
10:00 | 04/10/2024
