Tìm hiểu về tấn công

Man-in-the-Middle –

Chiếm quyền điểu khiển

SSL
Quản trị mạng – Trong phần tiếp theo của loạt bài 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, bên

cạnh đó là một số lý thuyết bên dưới các kết nối SSL và những

gì làm cho chúng được an toàn.

Cho tới phần này, chúng tôi đã giới thiệu cho các bạn về các tấn

công giả mạo ARP cache, giả mạo DNS và chiếm quyền điều

khiển session trong loạt bài về các tấn công “man-in-the-middle”

nói chung. 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:

 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.

 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.

 Máy khách kết nối đến https://mail.google.com trên cổng

443.

 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.

 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ó.

 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:

 Lưu lượng giữa máy khách và máy chủ đầu tiên sẽ bị chặn

 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ó.

 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.

 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.