Các tấn công sử dụ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 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 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]. . [2]. RFC 1918: Address Allocation for Private Internets, 1996. [3]. . [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
10:00 | 10/04/2024
Hiện nay, số lượng các cuộc tấn công mạng nhắm đến hệ điều hành Linux đang ngày càng gia tăng cả về số lượng lẫn mức độ tinh vi, đặc biệt là các sự cố liên quan đến việc lộ lọt mật khẩu. Thông thường, khi tạo tài khoản mới trên Linux, người dùng có thể sử dụng những mật khẩu tùy ý, kể cả những mật khẩu yếu, điều này có thể gây ra nhiều rủi ro bảo mật tiềm ẩn trong hệ thống mạng, các tác nhân đe dọa sẽ dễ dàng tấn công và xâm phạm tài khoản hơn. Do đó, cần phải thực thi các chính sách sử dụng mật khẩu đủ mạnh để bảo vệ tài khoản người dùng tránh bị tấn công. Trong bài viết này sẽ gửi đến độc giả hướng dẫn thiết lập cấu hình mật khẩu an toàn trên Linux với nền tảng Centos 7.
09:00 | 01/04/2024
Trong thời đại số ngày nay, việc quản lý truy cập và chia sẻ thông tin cá nhân trên các thiết bị di động thông minh đã trở thành vấn đề đáng quan tâm đối với mọi người dùng. Việc không kiểm soát quyền truy cập và sự phổ biến của dữ liệu cá nhân có thể gây ra các rủi ro về quyền riêng tư và lạm dụng thông tin. Bài viết này sẽ giới thiệu đến độc giả về Safety Check - một tính năng mới trên iOS 16 cho phép người dùng quản lý, kiểm tra và cập nhật các quyền và thông tin được chia sẻ với người và ứng dụng khác ngay trên điện thoại của chính mình, giúp đảm bảo an toàn và bảo mật khi sử dụng ứng dụng và truy cập dữ liệu cá nhân.
10:00 | 22/03/2024
Với sự tương tác kinh tế, xã hội và văn hóa ngày càng diễn ra phổ biến trên Internet, nhu cầu ngày càng tăng trong vài thập kỷ qua nhằm bắt chước sự ngẫu nhiên của thế giới tự nhiên và tạo ra các hệ thống kỹ thuật số để tạo ra các kết quả không thể đoán trước. Các trường hợp sử dụng cho tính không thể đoán trước này bao gồm đưa vào sự khan hiếm nhân tạo, xây dựng các cơ chế bảo mật mạnh mẽ hơn và tạo điều kiện cho các quy trình ra quyết định trung lập đáng tin cậy. Trong bài viết này, tác giả sẽ phân tích tính ngẫu nhiên, tìm hiểu về các loại ngẫu nhiên và vai trò quan trọng của sự ngẫu nhiên đối với Blockchain và hệ sinh thái Web3.
14:00 | 04/03/2024
Ngày nay, tất cả các lĩnh vực trong đời sống xã hội đều có xu hướng tích hợp và tự động hóa, trong đó các giao dịch số là yêu cầu bắt buộc. Do vậy, các tấn công lên thiết bị phần cứng, đặc biệt là các thiết bị bảo mật có thể kéo theo những tổn thất to lớn như: lộ thông tin cá nhân, bị truy cập trái phép hoặc đánh cắp tài khoản ngân hàng,… So với các loại tấn công khác, tấn công kênh kề hiện đang có nhiều khả năng vượt trội. Trong bài báo này, nhóm tác giả sẽ trình bày sơ lược về kết quả thực hành tấn công kênh kề lên mã khối Kalyna trên hệ thống Analyzr của Viện Khoa học - Công nghệ mật mã. Nhóm tác giả đã tấn công thành công và khôi phục đúng 15 byte khóa trên tổng số 16 byte khóa của thuật toán Kalyna cài đặt trên bo mạch Nucleo 64.
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
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.
11:00 | 13/05/2024
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. Nhiều giải pháp để bảo vệ phần cứng được đưa ra, trong đó, hàm không thể sao chép vật lý PUF (Physically Unclonable Functions) đang nổi lên như là một trong số những giải pháp bảo mật phần cứng rất triển vọng mạnh mẽ. RO-PUF (Ring Oscillator Physically Unclonable Function) là một kỹ thuật thiết kế PUF nội tại điển hình trong xác thực hay định danh chính xác thiết bị. Bài báo sẽ trình bày một mô hình ứng dụng RO-PUF và chứng minh tính năng xác thực của PUF trong bảo vệ phần cứng FPGA.
10:00 | 13/05/2024
