Tìm hiểu về tấn công Man-in-the-Middle – Chiếm quyền điểu khiển SSL

[emailhoc]

Trong phần bốn này, chúng tôi sẽ giới thiệu cho các bạn về tấn công giả mạo SSL, đây là một trong những tấn công MITM nguy hiểm nhất vì nó cho phép khai thác các dịch vụ mà người dùng tưởng rằng là an toàn. Chúng tôi sẽ bắt đầu giới thiệu này bằng cách thảo luận về một số lý thuyết nằm bên dưới các kết nối SSL và những gì có thể làm cho chúng an toàn, sau đó sẽ giới thiệu cách khai thác kiểu kết nối này như thế nào. Và cũng giống như các phần trước, phần cuối của bài sẽ là một số biện pháp phát hiện và ngăn chặn kiểu tấn công này.

SSL và HTTPS
Secure Socket Layers (SSL) hoặc Transport Layer Security (TLS) dưới sự thi hành hiện đại hơn của nó, là các giao thức được thiết kế để cung cấp bảo mật cho truyền thông mạng bằng phương pháp mã hóa. Giao thức này dễ được kết hợp với các giao thức khác nhất để cung cấp một thực thi an toàn cho dịch vụ mà giao thức cung cấp. Các ví dụ dẫn chứng ở đây gồm có SMTPS, IMAPS và HTTPS. Mục tiêu tối thượng là tạo các kênh an toàn trên các mạng không an toàn.
Trong phần này, chúng tôi sẽ tập trung giới thiệu vào tấn công SSL trên HTTP, được biết đến như HTTPS, vì nó là trường hợp sử dụng phổ biến nhất của SSL. Có thể không nhận ra nhưng hầu như chắc chắn bạn đang sử dụng HTTPS hàng ngày. Các dịch vụ email phổ biến nhất và các ứng dụng ngân hàng trực tuyến đều dựa vào HTTPS để bảo đảm truyền thông giữa trình duyệt web của bạn và các máy chủ của họ được mã hóa an toàn. Nếu không sử dụng công nghệ này thì bất cứ ai với một bộ “đánh hơi” gói dữ liệu trên mạng cũng đều có thể phát hiện ra được username, password và bất cứ thứ gì được ẩn khác.

Quá trình được sử dụng bởi HTTPS để bảo đảm an toàn dữ liệu là xiết chặt các trung tâm có liên quan đến việc phân phối các chứng chỉ giữa máy chủ, máy khách và hãng thứ ba được tin cậy. Lấy một ví dụ về trường hợp có một người dùng đang cố gắng kết nối đến một tài khoản email của Gmail. Quá trình này sẽ gồm có một vài bước dễ nhận thấy, các bước này đã được đơn giản hóa trong hình 1 bên dưới.

Hình 1: Quá trình truyền thông HTTPS

Quá trình được phác thảo trong hình 1 không phải là một quá trình chi tiết, tuy nhiên về cơ bản nó sẽ làm việc như sau:

1. Trình duyệt máy khách kết nối đến http://mail.google.com trên cổng 80 bằng cách sử dụng HTTP.
2. Máy chủ redirect phiên bản HTTPS máy khách của site này bằng cách sử dụng HTTP code 302.
3. Máy khách kết nối đến https://mail.google.com trên cổng 443.
4. Máy chủ sẽ cung cấp một chứng chỉ cho máy khách gồm có chữ ký số của nó. Chứng chỉ này được sử dụng để thẩm định sự nhận dạng của site.
5. Máy khách sử dụng chứng chỉ này và thẩm định chứng chỉ này với danh sách các nhà thẩm định chứng chỉ tin cậy của nó.
6. Truyền thông mã hóa sẽ xảy ra sau đó.

Nếu quá trình hợp lệ hóa chứng chỉ thất bại thì điều đó có nghĩa rằng các website đã thất bại trong việc thẩm định sự nhận dạng của nó. Tại điểm này, người dùng sẽ thấy xuất hiện một lỗi thẩm định chứng chỉ và họ vẫn có thể tiếp tục với những rủi ro có thể, vì rất có thể sẽ không có sự truyền thông thực sự với website mà họ nghĩ họ cần truy cập đến.

Phá hủy HTTPS
Quá trình này được xem là an toàn cao cách đây một vài năm khi có một tấn công đã công bố rằng nó có thể chiếm quyền điều khiển thành công quá trình truyền thông. Quá trình này không liên quan đến bản thân việc phá hủy (defeating) SSL, mà đúng hơn là phá hủy “cầu nối” giữa truyền thông không mã hóa và mã hóa.

Moxie Marlinspike, một chuyên gia nghiên cứu bảo mật hàng đầu đã cho rằng trong hầu hết các trường hợp, SSL chưa bao giờ bị trực tiếp tấn công. Hầu hết thời gian một kết nối SSL được khởi tạo thông qua HTTPS nên nguyên nhân có thể là do ai đó đã redirect một HTTPS thông qua một mã đáp trả HTTP 302 hoặc họ kích vào liên kết direct họ đến một site HTTPS, chẳng hạn như nút đăng nhập. Ý tưởng ở đây là rằng nếu bạn tấn công một phiên giao dịch từ một kết nối không an toàn đến một kết nối an toàn, trong trường hợp này là từ HTTP vào HTTPS, bạn sẽ tấn công cầu nối và có thể “man-in-the-middle” kết nối SSL trước khi nó xuất hiện. Để thực hiện hiệu quả điều này, Moxie đã tạo một công cụ SSLstrip, chúng ta sẽ sử dụng công cụ này dưới đây.
Quá trình thực hiện khá đơn giản và gợi nhớ lại các tấn công mà chúng ta đã nghiên cứu trong các phần trước của loạt bài. Nó được phác thảo như trong hình 2 bên dưới.

Hình 2: Chiếm quyền điều khiển truyền thông HTTPS

Quá trình được phác thảo trong hình 2 làm việc như sau:

1. Lưu lượng giữa máy khách và máy chủ đầu tiên sẽ bị chặn
2. Khi bắt gặp một HTTPS URL, sslstrip sẽ thay thế nó bằng một liên kết HTTP và sẽ ánh xạ những thay đổi của nó.
3. Máy tấn công sẽ cung cấp các chứng chỉ cho máy chủ web và giả mạo máy khách.
4. Lưu lượng được nhận trở lại từ website an toàn và được cung cấp trở lại cho máy khách.

Quá trình làm việc khá tốt, máy chủ có liên quan vẫn nhận lưu lượng SSL mà không hề biết về sự khác biệt này. Chỉ có một sự khác biệt rõ rệt trong trải nghiệm người dùng là lưu lượng sẽ không được cắm cờ HTTPS trong trình duyệt, vì vậy một người dùng có kinh nghiệm sẽ có thể thấy đó là một điều dị thường.

Sử dụng SSLStrip
Chương trình trợ giúp cho tấn công này mang tên SSLstrip, bạn có thể download nó tại đây. Chương trình này chỉ chạy trên Linux vì vậy bạn có thể download và tự cài đặt nó, trong trường hợp không muốn thực hiện công việc này, bạn có thể download và chạy bản Backtrack 4, đây là bản đã được cài đặt trước của công cụ này.

Khi đã truy cập vào SSLstrip, bạn sẽ thấy có một vài nhiệm vụ đặc quyền cần thực hiện. Trước tiên, phân phối Linux mà bạn đang sử dụng phải được cấu hình để chuyển tiếp IP. Để thực hiện điều này, hãy nhập lệnh echo "1" > /proc/sys/net/ipv4/ip_forward vào một shell.

Hình 3: Kích hoạt IP Forwarding

Khi thực hiện xong, chúng ta phải làm cho tất cả lưu lượng HTTP được chặn sẽ được định tuyến đến cổng mà ở đó SSLstrip sẽ lắng nghe. Điều này được thực hiện bằng cách thay đổi cấu hình iptables của tường lửa. Sử dụng lệnh iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port <listenPort>.

Hình 4: Cấu hình IPTables để định tuyến đúng lưu lượng HTTP

Rõ ràng, bạn cần thay thế <listenPort> bằng một cổng nào đó theo lựa chọn của mình. Sau khi thực hiện xong việc cấu hình này, chúng ta có thể chạy sslstrip và cấu hình sao cho nó có thể lắng nghe trên cổng được chỉ định bằng lệnh sslstrip -l <listenPort>.

Hình 5: Sử dụng sslstrip

Bước cuối cùng trong quá trình này là cấu hình giả mạo ARP để chặn lưu lượng của host đích. Chúng ta đã thực hiện điều này bằng cách sử dụng Cain và Abel trong Windows ở các phần trước, tuy nhiên trong trường hợp này, chúng ta sẽ sử dụng tiện ích arpspoof, đây là tiện ích có trong Backtrack 4. Lệnh để thực hiện là arpspoof -i <interface> -t <targetIP> <gatewayIP>.

Hình 6: Cấu hình giả mạo ARP

Sử dụng lệnh này bạn cần thay thế <interface> bằng giao diện mạng mà bạn đang thực hiện các hành động này (eth0, eth1,...), <targetIP> bằng địa chỉ IP của máy khách mục tiêu, <gatewayIP> là địa chỉ IP của router cổng mà mục tiêu đang sử dụng.

Khi hoàn tất, bạn sẽ có thể chiếm quyền điều khiển bất cứ kết nối SSL nào đang được thiết lập. Từ đây, bạn có thể khởi chạy tiện ích “đánh hơi” dữ liệu và thu thập mật khẩu, các thông tin nhận dạng cá nhân khác như số thẻ tín dụng,... từ lưu lượng.

Biện pháp phòng chống
Như được giới thiệu ở trên, việc chiếm quyền điều khiển SSL theo cách này là hầu như không thể phát hiện từ phía trình chủ vì máy chủ cứ tưởng nó vẫn truyền thông bình thường với máy khách. Nó không hề có ý tưởng rằng đang truyền thông với một client bởi proxy. May mắn thay, có một vài thứ có thể thực hiện từ bối cảnh trình khách để phát hiện và ngăn chặn các kiểu tấn công này.

• Sử dụng kết nối an toàn HTTPS – Khi bạn thực hiện tấn công được mô tả ở đây, nó sẽ lấy đi khía cạnh an toàn của kết nối, thứ có thể xác định được trong trình duyệt. Điều này có nghĩa rằng nếu bạn đăng nhập vào tài khoản ngân hàng trực tuyến và thấy rằng nó chỉ là một kết nối HTTP chuẩn thì chắc chắn có thứ gì đó sai ở đây. Bất cứ khi nào trình duyệt mà bạn chọn sử dụng cũng cần bảo đảm rằng bạn biết cách phân biệt các kết nối an toàn với những kết nối không an toàn.
• Lưu tài khoản ngân hàng trực tuyến ở nhà – Cơ hội cho ai đó có thể chặn lưu lượng của bạn trên mạng gia đình sẽ ít hơn nhiều so với mạng ở nơi làm việc của bạn. Điều này không phải vì máy tính gia đình của bạn an toàn hơn (mà sự thật có lẽ là kém an toàn hơn), nhưng sự thật nếu chỉ có một hoặc hai máy tính ở nhà thì các bạn chỉ phải quan tâm đến việc chiếm quyền điều khiển session nếu có ai đó trong nhà bạn (cậu trai lớn) bắt đầu xem và tập theo các video về hacking trên YouTube. Trong mạng công ty, bạn không biết những gì đang diễn ra dưới tiền sảnh hoặc văn phòng chi nhánh cách đó nhiều km, vì vậy nguồn tấn công tiềm tàng là rất nhiều. Một trong những mục tiêu lớn nhất cho tấn công chiếm quyền điều khiển session là ngân hàng trực tuyến, tuy nhiên thủ phạm này có thể áp dụng cho bất cứ thứ gì.
• Bảo mật các máy tính bên trong mạng – Không đánh một con ngựa đã chết, nhưng một lần nữa, các tấn công giống như vậy thường được thực thi bên trong một mạng. Nếu các thiết bị mạng của bạn được an toàn thì nguy cơ bị thỏa hiệp các host để sau đó được sử dụng để khởi chạy tấn công chiếm quyền điều khiển session cũng sẽ giảm.

Kết luận
Hình thức tấn công MITM này là một trong những hình thức chết chóc nhất vì nó làm cho chúng ta nghĩ đang ở một kết nối an toàn nhưng sự thật lại không phải vậy. Nếu bạn xem xét số lượng các site an toàn mà mình viếng thăm mỗi ngày, sau đó xem xét sự ảnh hưởng tiềm tàng nếu tất cả trong số các kết nối đó không an toàn và dữ liệu bị rơi vào những kẻ xấu thì bạn sẽ hiểu một cách đúng đắn mức độ nguy hiểm có thể xảy ra với bạn hoặc tổ chức bạn.