Chuẩn IEEE 802.11i cung cấp có hiệu quả một số dịch vụ an ninh; tuy nhiên, có một số lỗ hổng bảo mật đƣợc phát hiện ra trong một vài năm gần đây. Ta sẽ thảo luận về các lỗ hổng, các tấn công lợi dụng những lỗ hổng này, và những cơ chế ngăn chặn.
Sinh ra AAD Sinh ra Nonce Mã hoá CCM Sinh ra CCMP header Tăng PN || Plaintext MPDU Key PN KeyID Dữ liệu A2 Priority Dữ liệu đã mã hoá, MIC MAC header MPDU đã mã hoá
2.3.2.1. Lỗ hổng của IEEE 802.1X [9]
IEEE 802.1X sử dụng chuẩn IEEE802.11i để phân phối và xác thực khoá. Ba thực thể: thiết bị nhận yêu cầu xác thực (Authenticator), ngƣời cần xác thực (Supplicant) và máy chủ xác thực (Authenticator server) tham gia cùng một tiến trình. Giả định cơ bản là giao thức xác thực luôn luôn đáng tin cậy. Do đó, supplicant không xác minh thông báo nhận đƣợc từ authenticator và đáp ứng vô điều kiện đối với thông báo này. Tuy nhiên, trong thực tế đối thủ cũng có thể thực hiện xác thực, điều này làm cho giao thức dữ bị tổn thƣơng dẫn đến tấn công cƣớp quyền và tấn công ngƣời ở giữa (man-in-the-midle). Hình 2.11 chỉ ra cách đối thủ có thể khai thác lỗ hổng đã đề cập ở trên để tấn công cƣớp quyền điều khiển. Đối thủ có thể chờ đến khi authenticator và supplicant hoàn thành quá trình xác thực và authenticator gửi thông báo EAP success đến supplicant. Theo đó, đối thủ gửi một thông báo phân tách (disassociate message) đến supplicant với IP giả của authenticator. Supplicant cho rằng phiên làm việc đã bị ngắt bởi authenticator là thông báo không xác thực tính toàn vẹn. Đối thủ giành đƣợc quyền truy cập vào mạng bằng cách giả mạo địa chỉ MAC của supplicant và truy cập với một thủ tục xác thực lẫn nhau sử dụng phƣơng pháp bắt tay bốn bƣớc.
Hình 2.11: Tấn công cướp quyền điều khiển trong cơ chế xác thực 802.1X
Hình 2.12 cho thấy một tấn công ngƣời ở giữa đƣợc đối thủ thực hiện khi khai thác vào IEEE 802.1X. Sau khi thiết lập trao đổi thông báo EAP request và response giữa supplicant và authenticator, đối thủ gửi thông báo EAP success đến supplicant sử dụng địa chỉ MAC của chính nó. Vì giao thức IEEE 802.1X thừa nhận quá trình chuyển đổi vô điều kiện dựa trên việc nhận thông báo EAP success của supplicant, suplicant cho rằng đây là xác thực của authenticator và thay đổi trạng thái. Khi authenticator gửi thông báo EAP success, supplicant đã qua trạng thái này và đang đợi thông báo thành công, do đó nó không phản ứng với thông báo này. Supplicant cho rằng đổi thủ là authenticator hợp pháp trong khi đối thủ có thể dễ dàng giả mạo địa chỉ MAC của supplicant để giao tiếp với authenticator. Do đó, đối thủ sẽ trở thành trung gian giữa supplicant và authenticator. Giải pháp đề xuất để ngăn chặn tấn công nay là đề nghị kiểm tra xác thực và toàn vẹn thông báo EAP giữa authenticator và supplicant. Giải pháp cũng đề xuất sự chấp thuận
Authenticator Supplicant Địch thủ EAP request EAP response … … EAP success Supplicant đã xác thực Ngắt kết nối 802.11 MAC
Lưu lượng mạng Chiếm kết nối
mạng
Giả mạo địa chỉ MAC của authenticator
của mô hình chứng thực dựa trên mạng ngang hàng (peer - to - peer) khi authenticator và supplicant hoạt động giống nhƣ các peer và supplicant kiểm tra thông báo từ authenticator trong quá trình thiết lập tin cậy. Mô hình peer to peer đƣợc cho là thích hợp cho mạng không dây mesh khi cả authenticator và supplicant đều là WMN router.
Hình 2.12: Tấn công man-in-the-midle trong cơ chế xác thực 802.1X
2.3.2.2. Những lỗ hổng của quá trình bắt tay bốn bước [7]
Quá trình bắt tay bốn bƣớc là cơ chế sử dụng sự xác thực lẫn nhau của supplicant và authenticator trong IEEE 802.11i. Quá trình bắt tay bắt đầu sau khi cặp khoá chủ thông minh (PMK) đƣợc phân phối đến supplicant và authenticator. Supplicant đợi một khoảng thời gian nhất định cho thông báo 1 của quá trình bắt tay từ authenticator. Nếu không nhận đƣợc thông báo, supplicant tách nó ra khỏi authenticator. Lƣu ý rằng thời gian chỉ đƣợc supplicant sử dụng. Nếu supplicant nhận đƣợc thông báo 1, supplicant phải trả lời tất cả các thông báo từ authenticator và chờ đến khi nhận đƣợc hồi đáp. Mặt khác, authenticator sẽ time-out mọi thông báo nếu không nhận đƣợc hồi đáp nó chờ đợi sau một khoảng thời gian cụ thể. Thêm vào đó, supplicant sẽ không đƣợc xác thực nếu hồi đáp không đƣợc nhận sau một vài lần thử. Lƣu ý rằng cả authenticator và supplicant đều tự bỏ thông báo nếu mã toàn vẹn thông báo (MIC) của thông báo không xác minh đƣợc. Cơ chế này của quá trình bắt tay bốn bƣớc có nhƣợc điểm là dễ bị tấn công từ chối dịch vụ. Theo Hình 2.13, authenticator gửi thông báo 1 cho supplicant. Lƣu ý rằng thông báo 1 không mã hoá. Supplicant sinh ra SNonce mới và sau đó sử dụng ANonce, SNonce và một số trƣờng khác sinh ra PTK và trả lời bằng thông báo 2, thông báo này đƣợc mã hoá bằng PTK. Tại thời điểm này, đối thủ gửi tin nhắn độc hại 1 với địa chỉ MAC giả của authenticator. Supplicant chắc chắn sẽ trả lời thông báo này. Giả sử rằng thông báo 2 đó đƣợc gửi đến authenticator bị mất và authenticator truyền lại thông báo 1. Vì thế, PTK* đƣợc tính toán lại (khác với PTK cũ và ghi đè lên PTK cũ) dựa trên ANonce đã đƣợc đối thủ gửi và gửi thông báo 2 một lần nữa sử dụng mã hoá PTK*. Trong khi đó, authenticator trả lời thông báo 2 đầu tiên của supplicant bằng thông báo 3 sử dụng PTK. Kiểm tra toàn vẹn thông báo 3 trên supplicant sẽ báo lỗi vì supplicant bây giờ sử dụng PTK* trong khi authenticator sử dụng PTK để mã hoá. Kết quả là quá trình bắt tay bốn
Authenticator Địch thủ Supplicant EAP request EAP response EAP success Supplicant đã xác thực No action Lưu lượng mạng EAP success Supplicant chuyển trạng thái
bƣớc bị khoá cho đến khi authenticator không xác thực supplicant sau vài lần thử, và từ chối dịch vụ đối với supplicant.
Lƣu ý rằng bất cứ lúc nào supplicant nhận đƣợc thông báo 1, nó sẽ sinh ra một SNonce mới ràng buộc với ANonce (đƣợc truyền ở thông báo 1 của authenticator) và một số thông tin khác để sinh ra PTK. Giải pháp hiệu quả nhất đƣợc đề xuất để ngăn chặn tấn công nói trên là supplicant nên lƣu lại SNonce đƣợc tạo ra trong quá trình trả lời thông báo 1 nhận đƣợc từ authenticator. Một SNonce nhƣ vậy cũng nên đƣợc sử dụng cho các thông báo 1 tiếp theo cho đến khi supplicant nhận đƣợc thông báo 3 từ authenticator. Khi nhận đƣợc thông báo 3, supplicant nên sử dụng ANonce của thông báo 3 và SNonce đã lƣu để sinh ra PTK một lần nữa, PTK này sẽ đƣợc dùng để mã hoá thông báo 3. Việc sử dụng cùng một SNonce và ANonce sẽ sinh ra cùng một PTK nếu các thông tin khác vẫn không thay đổi. Do đó, supplicant sẽ có thể trả lời đƣợc thông báo 3 hợp lên thậm chí nó nhận đƣợc nhiều thông báo 1 từ đối thủ. Lƣu ý rằng đổi thủ không thể gửi thông báo 3 độc hại đƣợc bởi vì thông báo 3 dùng PTK để mã hoá, điều này phụ thuộc vào PMK (chỉ có supplicant và authenticator biết).
Hình 2.13: Tấn công từ chối dịch vụ trong quá trình bắt tay bốn bước 2.3.2.3. Những lỗ hổng trong mã hoá CCMP [17]
Mặc dù CCMP (đƣợc sử dụng bởi IEEE 802.11i) sử dụng mã hoá CCM, sức mạnh trong đó là thời gian thử nghiệm, giao thức vẫn có thể bị tấn công bằng tấn công từng phần và tấn công tính toán trƣớc. Trƣờng địa chỉ A2, trƣờng priority của tiêu đề MAC và trƣờng PN trong tiêu đề CCMP đƣợc truyền phát bằng bản gốc trên các header và cũng đƣợc ở dạng mã hoá nhƣ là một phần của mã xác thực thông báo. Điều này dẫn đến việc tấn công kết hợp từng phần và các nhà nghiên cứu đã chỉ ra rằng độ mạnh của mã hoá 128-bit đƣợc sử dụng trong CCMP sẽ bị suy giảm. Sự suy giảm độ mạnh của khoá làm lộ ra các tấn công giao thức có tính toán trƣớc, kết quả dẫn đến việc làm tổn thƣơng các dữ liệu
Authenticator Kẻ tấn công Supplicant
Msg1: ANonce Tạo ra PTK Msg1: Snonce, MICPTK Msg1: Anonce* Tạo ra GTK Tạo ra PTK* Msg3: GTK, MICPTK (PTK bị ghi đè) PTK và PTK* khác nhau nên MIC không đƣợc kiểm
tra, giao thức bị khoá
(Kẻ tấn công gửi thông báo với địa chỉ MAC giả của authenticator)
bảo mật và dữ liệu toàn vẹn. Hơn nữa, quá trình mã hoá CCM đƣợc chia làm hai giai đoạn. Trong giai đoạn đầu, mã toàn vẹn thông báo sẽ đƣợc tính toán, việc mã hoá diễn ra ở giai đoạn hai. Tƣơng tự nhƣ vậy, việc giải mã cũng đƣợc diễn ra trong hai giai đoạn. Ở đó, đầu tiên thông báo toàn vẹn đƣợc xác nhận bởi mã toàn vẹn thông báo và sau đó quá trình giải mã diễn ra. Hai giai đoạn này thực hiện tại mỗi liên kết không dây có thể dẫn đến việc chậm trễ đáng kể trong trƣờng hợp các mạng không dây đa hop nhƣ mạng không dây mesh khi mà dữ liệu đi qua một số hop trung gian trƣớc khi đến đƣợc nút Internet có dây. Sự trì hoãn đƣợc đƣa ra bởi các dịch vụ bảo mật sẽ dẫn đến việc không thể thực hiện đƣợc giao thức CCMP cho các mạng không dây lớn có nhiều nút trung gian.