Có 4 bước khi triển khai tấn công này:
* Bước 1: client truy cập vào https://www.ebank.com. Lúc này client sẽ kết nối đến attacker, và gửi CLIENT_HELLO để bắt đầu giao thức TLS/SSL. Attacker sẽ tạm dừng cái kết nối này và lưu msg CLIENT_HELLO lại để dùng trong bước 3.
* Bước 2: attacker mở kết nối đến server thật. Hai bên sẽ bắt tay theo giao thức TLS/SSL để tạo thành một session. Sau khi hoàn tất bắt tay, attacker gửi một HTTP request, đại loại như:
POST /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\n
* Bước 3: server thấy có một request đến khu vực /account/ nên nó tạm thời dừng xử lý request này lại và như đã nói ở trên, nó yêu cầu attacker phải đưa client certificate cho nó xem. Cái hay ở đây, mặc dầu attacker không có (private key của) certificate của client, nhưng hắn vẫn có thể *proxy* cái certificate đó từ client lên server, mà không bị bên nào phát hiện cả.
Server bắt đầu quá trình xác thực bằng việc gửi một msg HELLO_REQUEST ngược lại cho attacker. Attacker nhận được msg này thì hắn gửi CLIENT_HELLO mà hắn đã lưu ở bước 1 ngược lại cho server. Rồi cứ thế, attacker đứng giữa, chuyển msg qua lại giữa client và server cho đến khi quá trình xác thực bằng client certificate kết thúc thành công.
Lưu ý là có 2 loại msg mà attacker sẽ gửi. Loại thứ nhất (trên sơ đồ là những msg kết thúc hoặc bắt đầu từ cột m) là những msg mà hắn phải giải mã/mã hóa trước khi gửi đi. Ví dụ như hắn nhận “Certificate” từ phía client thì hắn sẽ mã hóa cái msg này lại, rồi mới gửi cho server. Loại thứ hai (trên sơ đồ là những msg màu hồng và đỏ) là những msg mà hắn không đọc được (vì không có key), hắn chỉ làm mỗi việc là nhận từ client thì gửi qua server và ngược lại.
* Bước 4: quá trình xác thực client certificate đã kết thúc thành công, server tiếp tục xử lý cái request của attacker ở trên, và trả kết quả lại cho attacker (lưu ý là attacker sẽ không đọc được kết quả này).
Điểm yếu là ở đây. Như chúng ta thấy, khi attacker gửi request ở bước 3, lúc đó hắn chưa được xác thực. Nói cách khác, lúc này request của hắn là unauthenticated request. Việc xác thực diễn ra sau đó, và sau khi xác thực rồi thì server lại quay lại xử lý tiếp cái unauthenticated request của attacker.
Lưu ý, ở bước này, để tránh bị tình nghi, attacker có thể tiếp tục trả kết quả về cho client để đóng kết nối lại một cách êm đẹp.
KMA comment A:Đây mới là điểm lưu ý:
Thông thường nếu chưa bị ARP spoofing, thao tác check mail yahoo của các bác sẽ có bước redirect wa HTTPS ngọt sớt mà ko phải chứng kiến một cái "Warning SSL certificate" nào từ trình duyệt vì đơn giản cái SSL Certificate đã được chứng thực là đúng với cái domain đó của yahoo. Khi đã bị ARP poisoning thì chắc chắn khi check mail các bác sẽ bị pop-up ra một cái Warning SSL certificate giả do thằng Cain cung cấp. Nếu lúc này người dùng nhận ra và cancel thì thằng Cain cũng pó tay. SSL ngoài chuyện encrypt trên đường truyền, nó còn dùng để giúp người dùng nhận ra mình đang bị phishing, pharming attack.
(Trích từ hva)
-> Đây là thực nghiệm và những gì rút ra của mình: (Dùng Cain nhé)
1) Bị poinsioning trước xong victim mới vào trình duyệt và gõ URL- Từ mail.yahoo.com sẽ được redirect sang login.yahoo.com -> Có thể bị lộ pass
Đây là 2 khả năng xảy ra với TH1:
+ Nếu ở mục ARP-CERT va ARP-HTTPS trong Cain&Abel chưa có các thông tin nào thì trình duyệt sẽ thông báo rằng Secure Connection Failed và sau khi nhập username/pass vào rồi ấn Enter thì trình duyệt sẽ hiện ra một thông báo hỏi:
1 - Get me out of here (ở đây nếu victim theo bước này thì sẽ không bị sniff nữa nhưng đồng nghĩa với việc không vào mail được lúc đó nữa)
2 - Add exception, rồi victim xin cert để vào -> sẽ bị lộ pass
+ Nếu ở 2 mục ARP-CERT và ARP-HTTPS của Cain có thông tin rồi thì nó sẽ vào thẳng trong mailbox luôn mà không hỏi Cert nữa vì đã bị lừa từ trước
- Vào thẳng bằng URL: login.yahoo.com ->Có thể bị lộ pass
Cũng có 2 khả năng tương tự:
+ Nếu ở mục ARP-CERT va ARP-HTTPS trong Cain&Abel chưa có các thông tin nào thì trình duyệt sẽ thông báo rằng Secure Connection Failed và sau khi nhập username/pass vào rồi ấn Enter thì trình duyệt sẽ hiện ra một thông báo hỏi:
2) Attacker thực hiện Poinsioning sau khi Victim đã gõ URL vào và chuẩn bị gõ id/pass thì bị Poinsioning- Gõ mail.yahoo.com thì sẽ redirect sang login.yahoo.com -> đăng nhập như bình thường, vẫn bị sniff, Cain vẫn bắt được gói tin nhưng không nhìn được pass vì đã bị mã hoá.
3) Với việc đăng nhập bằng yahoo messenger:Khi đã bị Poinsioning rồi thì chỉ cần bật yahoo, đăng nhập tới lần thứ 2 (bằng chính nick đăng nhập ở lần 1 hoặc bằng 1 nick khác) thì pass cũng sẽ bị sniff ở dạng cleartext vì yahoo messenger giao dịch không an toàn, (còn không có cả cảnh báo ssl như ở web để giúp người dùng cảnh giác )
* Bước 1: client truy cập vào https://www.ebank.com. Lúc này client sẽ kết nối đến attacker, và gửi CLIENT_HELLO để bắt đầu giao thức TLS/SSL. Attacker sẽ tạm dừng cái kết nối này và lưu msg CLIENT_HELLO lại để dùng trong bước 3.
* Bước 2: attacker mở kết nối đến server thật. Hai bên sẽ bắt tay theo giao thức TLS/SSL để tạo thành một session. Sau khi hoàn tất bắt tay, attacker gửi một HTTP request, đại loại như:
POST /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\n
* Bước 3: server thấy có một request đến khu vực /account/ nên nó tạm thời dừng xử lý request này lại và như đã nói ở trên, nó yêu cầu attacker phải đưa client certificate cho nó xem. Cái hay ở đây, mặc dầu attacker không có (private key của) certificate của client, nhưng hắn vẫn có thể *proxy* cái certificate đó từ client lên server, mà không bị bên nào phát hiện cả.
Server bắt đầu quá trình xác thực bằng việc gửi một msg HELLO_REQUEST ngược lại cho attacker. Attacker nhận được msg này thì hắn gửi CLIENT_HELLO mà hắn đã lưu ở bước 1 ngược lại cho server. Rồi cứ thế, attacker đứng giữa, chuyển msg qua lại giữa client và server cho đến khi quá trình xác thực bằng client certificate kết thúc thành công.
Lưu ý là có 2 loại msg mà attacker sẽ gửi. Loại thứ nhất (trên sơ đồ là những msg kết thúc hoặc bắt đầu từ cột m) là những msg mà hắn phải giải mã/mã hóa trước khi gửi đi. Ví dụ như hắn nhận “Certificate” từ phía client thì hắn sẽ mã hóa cái msg này lại, rồi mới gửi cho server. Loại thứ hai (trên sơ đồ là những msg màu hồng và đỏ) là những msg mà hắn không đọc được (vì không có key), hắn chỉ làm mỗi việc là nhận từ client thì gửi qua server và ngược lại.
* Bước 4: quá trình xác thực client certificate đã kết thúc thành công, server tiếp tục xử lý cái request của attacker ở trên, và trả kết quả lại cho attacker (lưu ý là attacker sẽ không đọc được kết quả này).
Điểm yếu là ở đây. Như chúng ta thấy, khi attacker gửi request ở bước 3, lúc đó hắn chưa được xác thực. Nói cách khác, lúc này request của hắn là unauthenticated request. Việc xác thực diễn ra sau đó, và sau khi xác thực rồi thì server lại quay lại xử lý tiếp cái unauthenticated request của attacker.
Lưu ý, ở bước này, để tránh bị tình nghi, attacker có thể tiếp tục trả kết quả về cho client để đóng kết nối lại một cách êm đẹp.
KMA comment A:Đây mới là điểm lưu ý:
Thông thường nếu chưa bị ARP spoofing, thao tác check mail yahoo của các bác sẽ có bước redirect wa HTTPS ngọt sớt mà ko phải chứng kiến một cái "Warning SSL certificate" nào từ trình duyệt vì đơn giản cái SSL Certificate đã được chứng thực là đúng với cái domain đó của yahoo. Khi đã bị ARP poisoning thì chắc chắn khi check mail các bác sẽ bị pop-up ra một cái Warning SSL certificate giả do thằng Cain cung cấp. Nếu lúc này người dùng nhận ra và cancel thì thằng Cain cũng pó tay. SSL ngoài chuyện encrypt trên đường truyền, nó còn dùng để giúp người dùng nhận ra mình đang bị phishing, pharming attack.
(Trích từ hva)
-> Đây là thực nghiệm và những gì rút ra của mình: (Dùng Cain nhé)
1) Bị poinsioning trước xong victim mới vào trình duyệt và gõ URL- Từ mail.yahoo.com sẽ được redirect sang login.yahoo.com -> Có thể bị lộ pass
Đây là 2 khả năng xảy ra với TH1:
+ Nếu ở mục ARP-CERT va ARP-HTTPS trong Cain&Abel chưa có các thông tin nào thì trình duyệt sẽ thông báo rằng Secure Connection Failed và sau khi nhập username/pass vào rồi ấn Enter thì trình duyệt sẽ hiện ra một thông báo hỏi:
1 - Get me out of here (ở đây nếu victim theo bước này thì sẽ không bị sniff nữa nhưng đồng nghĩa với việc không vào mail được lúc đó nữa)
2 - Add exception, rồi victim xin cert để vào -> sẽ bị lộ pass
+ Nếu ở 2 mục ARP-CERT và ARP-HTTPS của Cain có thông tin rồi thì nó sẽ vào thẳng trong mailbox luôn mà không hỏi Cert nữa vì đã bị lừa từ trước
- Vào thẳng bằng URL: login.yahoo.com ->Có thể bị lộ pass
Cũng có 2 khả năng tương tự:
+ Nếu ở mục ARP-CERT va ARP-HTTPS trong Cain&Abel chưa có các thông tin nào thì trình duyệt sẽ thông báo rằng Secure Connection Failed và sau khi nhập username/pass vào rồi ấn Enter thì trình duyệt sẽ hiện ra một thông báo hỏi:
2) Attacker thực hiện Poinsioning sau khi Victim đã gõ URL vào và chuẩn bị gõ id/pass thì bị Poinsioning- Gõ mail.yahoo.com thì sẽ redirect sang login.yahoo.com -> đăng nhập như bình thường, vẫn bị sniff, Cain vẫn bắt được gói tin nhưng không nhìn được pass vì đã bị mã hoá.
3) Với việc đăng nhập bằng yahoo messenger:Khi đã bị Poinsioning rồi thì chỉ cần bật yahoo, đăng nhập tới lần thứ 2 (bằng chính nick đăng nhập ở lần 1 hoặc bằng 1 nick khác) thì pass cũng sẽ bị sniff ở dạng cleartext vì yahoo messenger giao dịch không an toàn, (còn không có cả cảnh báo ssl như ở web để giúp người dùng cảnh giác )