Rò rỉ lưu lượng VPN có nghĩa là các dữ liệu được quy định phải được truyền đi thông qua các kênh VPN dưới dạng đã mã hóa thì lại được truyền dưới dạng rõ. Đây không phải là lỗi của VPN Client hay VPN Server, mà vấn đề phức tạp hơn thế.
Trường hợp đơn giản nhất là khi kênh VPN bị ngắt giữa chừng. Ví dụ, một hacker thực hiện quét máy tính mục tiêu bằng Nmap thông qua VPN (để che giấu IP của mình). Anh ta khởi động Nmap rồi rời máy tính của mình để đi làm việc khác. Trong thời gian này, vì lý do nào đó mà kênh VPN bị ngắt, nhưng Nmap vẫn tiếp tục hoạt động, khi đó, toàn bộ lưu lượng sẽ mang địa chỉ mạng của hacker này.
Khả năng tiếp theo là việc rò rỉ lưu lượng xảy ra trong mạng hỗ trợ đồng thời hai giao thức IPv4 và IPv6, hay còn gọi là dual - stacked network/host.
Nguyên nhân của vấn đề
Việc tồn tại đồng thời hai giao thức IPv4 và IPv6 đôi lúc dẫn đến những hệ quả bất ngờ. IPv6 mặc dù không tương thích ngược với IPv4, nhưng hai phiên bản này thường được hỗ trợ đồng thời trong máy chủ phân giải tên miền (DNS). Ví dụ sau có thể làm rõ hơn vấn đề này. Giả thiết website www.example.com hỗ trợ cả IPv4 và IPv6. Khi đó, trên DNS sẽ chứa cả hai kiểu bản ghi DNS là A và AAAA. Mỗi bản ghi kiểu A chứa một địa chỉ IPv4, còn mỗi bản ghi kiểu AAAA chứa một địa chỉ IPv6. Như vậy, nếu một ứng dụng hỗ trợ cả hai giao thức IPv4 và IPv6 mà muốn giao tiếp với website này, thì có thể sử dụng một trong những địa chỉ trên.
VPN trong trường hợp tồn tại đồng thời IPv4 và IPv6
Nhiều sản phẩm VPN không hỗ trợ, thậm chí là bỏ qua giao thức IPv6. Những sản phẩm như thế sẽ chỉ bảo vệ lưu lượng IPv4 mà không bảo vệ lưu lượng IPv6. Nếu địa chỉ trong gói tin là IPv6 thì gói tin đó sẽ được gửi vào mạng dưới dạng rõ tới router của IPv6.
Xét trường hợp một máy tính hỗ trợ đồng thời IPv4 và IPv6, trên máy này có cài đặt VPN Client (chỉ hỗ trợ IPv4). Khi trên máy này có một ứng dụng muốn kết nối tới website đã nêu ở trên, nó sẽ yêu cầu phân giải cả hai bản ghi là A và AAAA. Khi đó, một trong những khả năng là ứng dụng sẽ kết nối với website bằng giao thức IPv6 (Mà sản phẩm VPN trên máy tính không hỗ trợ IPv6), nên toàn bộ lưu lượng giữa ứng dụng và website sẽ được truyền qua mạng dưới dạng rõ, trong khi người dùng không nhận thấy điều này và tin rằng dữ liệu của mình được bảo vệ bởi kênh VPN.
Bên cạnh trường hợp mang tính chất xác suất trên đây, kẻ tấn công có thể chủ động can thiệp vào việc lựa chọn giao thức IPv6 trên máy của nạn nhân bằng cách giả mạo các thông điệp ICMPv6 Router Advertisement. Việc này có thể được thực hiện bằng cách sử dụng các công cụ như rtadvd (bit.ly/WLIH4x), SI6 Networks’ IPv6 Toolkit (bit.ly/TYdw6j) hay THC- IPv6 (bit.ly/150FQbc).
Một số lời khuyên hữu ích
Sẽ rất nguy hiểm nếu những dữ liệu chúng ta muốn bảo vệ bằng VPN lại được gửi vào mạng dưới dạng rõ. Để tránh được các trường hợp trên, có một số giải pháp sau:
a. Trường hợp VPN Client được cấu hình để bảo vệ lưu lượng IPv4:
- Nếu VPN Client không hỗ trợ IPv6 thì cần tắt hỗ trợ IPv6 trên tất cả các card mạng, khi đó mọi ứng dụng trên máy tính sẽ phải kết nối mạng bằng IPv4.
- Nếu VPN Client có hỗ trợ IPv6 thì cần phải kiểm tra lại cấu hình để đảm bảo chắc chắn rằng các gói tin IPv6 cũng được truyền đi qua kênh VPN.
b. Để tránh trường hợp lưu lượng bị rò rỉ khi kênh VPN bị ngắt đột ngột (và toàn bộ dữ liệu được gửi qua gateway mặc định) thì cần thực hiện các bước:
- Xóa cấu hình gateway mặc định để bắt buộc tất cả dữ liệu mạng phải được gửi qua VPN;
- Sử dụng công cụ VPNetMon (bit.ly/HKpREg). Công cụ này thực hiện giám sát trạng thái của kết nối VPN. Một khi kết nối VPN bị ngắt, nó sẽ lập tức đóng các ứng dụng mà người dùng đã chỉ định (ví dụ như các torrent client, web browser, scanner);
- Sử dụng công cụ VPNCheck (bit.ly/IWX2Rm). Đây là công cụ tương tự như VPNetMon, nhưng ngoài khả năng đóng các ứng dụng, nó còn có khả năng ngắt hoàn toàn card mạng.
Giải mã lưu lượng VPN
Ngay cả khi máy tính đã được cấu hình đúng và không để xảy ra việc rò rỉ lưu lượng VPN vào mạng dưới dạng rõ, thì điều đó vẫn không có nghĩa là dữ liệu người dùng được đảm bảo an toàn. Bởi vì lưu lượng VPN có thể bị chặn bắt và giải mã. Nếu VPN hoạt động trên giao thức PPTP thì khả năng giải mã thành công có thể tới 100%.
Khi VPN hoạt động theo giao thức PPTP (Point- to - Point Tunneling Protocol) thì việc xác thực người dùng được thực hiện theo giao thức MS- CHAPv2, là giao thức được phát triển bởi Microsoft. Mặc dù MS - CHAPv2 đã khá lạc hậu và bị nghi ngờ về tính an toàn, nhưng nó vẫn tiếp tục được sử dụng một cách rộng rãi. Tại hội nghị DEFCON lần thứ 20 (tháng 7/2012), hacker Moxie Marlinspike công bố đã bẻ khóa thành công giao thức MS- CHAPv2. Hoạt động của giao thức MS - CHAPv2 được thể hiện như trên hình dưới đây và được mô tả chi tiết trong RFC 2759 (Hình 1).
.jpg)
Hình 1: Hoạt động của giao thức MS-CHAPv2 của Microsoft
Để tìm ra bản tóm lược này, ta có thể sử dụng phương pháp dò mật khẩu. Tuy nhiên, phương pháp này chỉ khả thi khi người dùng đặt mật khẩu đơn giản (tấn công từ điển), còn trong trường hợp mật khẩu có độ phức tạp cao thì dò tìm là không thể. Một cách nữa là dò chính giá trị tóm lược này. Nhưng hàm băm MD4 cho bản tóm lược có độ dài 128 bit, với năng lực tính toán hiện nay, vét cạn 2128 trường hợp là không thể. Vậy Moxie Marlinspike đã làm thế nào?
Chia để trị
Bản tóm lược MD4 của mật khẩu được sử dụng để sinh ra 3 khóa DES, mỗi khóa 7 byte, và các khóa này được sử dụng hoàn toàn độc lập với nhau. Như vậy, thay vì dò tìm giá trị tóm lược, ta có thể dò 3 khóa DES này với tổng số trường hợp là 256 + 256 + 256 = 257,59. Rõ ràng là con số này nhỏ hơn rất nhiều so với 2128.
Nhưng đó vẫn chưa là con số cuối cùng. Mặc dù nói là sinh 3 khóa DES (3x7=21 byte), nhưng bản tóm lược MD4 chỉ có 16 byte, như vậy trong số 21 byte kia thì có đến 5 byte là dùng lặp lại. Tóm lại, có thể cho rằng chỉ có 2 khóa đầu là có độ dài 7 byte, còn khóa thứ 3 chỉ có độ dài 2 byte (16 bit). Mà việc dò 216 trường hợp khóa DES thì có thể được thực hiện trong vòng vài giây. Như vậy, người ta chỉ quan tâm tới việc dò 2 khóa đầu.
.jpg)
Để thực hiện dò khóa, như có thể thấy trên sơ đồ giao thức MS- CHAPv2, ta có 2 cặp bản rõ - bản mã, tuy nhiên, hai bản rõ là giống nhau và vì sử dụng hai khóa khác nhau nên có hai bản mã khác nhau. Như vậy, thay vì dò 2 khóa một cách độc lập thì có thể thực hiện dò đồng thời hai khóa. Với một giá trị khóa nhất định, nếu kết quả mã hóa là bản mã thứ nhất thì đó là khóa thứ nhất, còn nếu trùng với bản mã thứ hai thì đó là khóa thứ hai. Tóm lại, số trường hợp cần phải kiểm tra chỉ là 256.
Hiện nay, đã có những thiết bị cho phép thám thành công DES trong thời gian tính bằng giờ. Chẳng hạn công ty Pico Computing - một tổ chức chuyên nghiên cứu chế tạo thiết bị trên nền FPGA phục vụ các ứng dụng mật mã, đã cho ra đời DES cracking box với 400 nhân, tốc độ 450MHz, cho phép thám thành công DES trong thời gian tối đa là 23 giờ. Pico Computing cung cấp cho khách hàng khả năng khai thác năng lực tính toán này thông qua dịch vụ điện toán đám mây của họ.
Hơn thế nữa, để việc tấn công vào PPTP VPN được thuận tiện, Moxie Marlinspike đã phát triển công cụ chapcrack (mã nguồn mở). Nó tự động thực hiện phân tách dữ liệu chặn bắt được của phiên thiết lập kết nối VPN, tự động dò tìm thông tin bắt tay MS- CHAPv2 và đưa ra tên tài khoản (username), bản rõ, hai bản mã và tự động dò khóa thứ ba. Đồng thời, chapcrack cũng sinh ra token để gửi lên CloudCracker nhằm tìm ra hai khóa còn lại.
Kết luận
Lý thuyết về VPN khiến người ta liên tưởng VPN với sự an toàn, với tính ẩn danh và sử dụng VPN để giữ bí mật thông tin, để che giấu vị trí địa lý thật của mình.... Nhưng thực tế cho thấy lưu lượng VPN hoàn toàn có khả năng rò rỉ vào mạng truyền thông ở dạng rõ, mà nếu không bị rò rỉ thì vẫn có thể bị giải mã. Bên cạnh đó, nếu VPN hoạt động theo giao thức PPTP thì có thể coi rằng dữ liệu không hề được mã hóa.
