FB, Gmail và Yahoo áp dụng cái này giờ khó rồi. Đơn giản là hãy dùng HTTPS, cả 3 site trên đều cho phép bật mặc định dùng HTTPS. Mã hoá rồi thì man trên giời cũng ko middle được (dĩ nhiên cũng phải biết tí chút là khi nào SSL Cert bị giả mạo và trình duyệt từ chối nhé). 

myquartz wrote:

FB, Gmail và Yahoo áp dụng cái này giờ khó rồi. Đơn giản là hãy dùng HTTPS, cả 3 site trên đều cho phép bật mặc định dùng HTTPS. Mã hoá rồi thì man trên giời cũng ko middle được (dĩ nhiên cũng phải biết tí chút là khi nào SSL Cert bị giả mạo và trình duyệt từ chối nhé). 

Ai trong dân kĩ thuật cũng biết SSL/TLS sẽ hỗ trợ việc chống lại man-in-middle attack. Thế nhưng đó là người dùng am hiểu kĩ thuật, còn người dùng bình thường chả mấy quan tâm, nhất là dân business. Việc HTTPS không được yêu cầu mặc định trong các website cũng là một nguyên nhân khiến kiểu tấn công này vẫn dung hại. Đáng nhẽ các website phải ép người dùng dùng HTTPS để an toàn Đã bảo là cái title được giật cho vui và để có cái mà bàn luận mà, dĩ nhiên thực tế là Gmail và Yahoo đã chơi trò ép người dùng được một thời gian rồi :D Mặt khác, SSL/TLS hiện đang bị kiểu tấn công do lão mrro mới công bố đe doạ nghiêm trọng. Kĩ thuật tấn công đó khó khăn khi tấn công từ xa, nhưng nếu tấn công trong một mạng local dạng mạng wireless, khi các dữ liệu dễ dàng bị nghe lén thì khả năng tấn công diễn ra dễ dàng hơn rất nhiều. Đọc thêm bài viết trên blog của lão mrro để rõ thêm Một câu hỏi nhỏ: Các bạn thử nghĩ tại sao mà các trang web hầu hết đều không áp dụng giao thức HTTPS là yêu cầu kết nối mặc định ? :*-  

myquartz wrote:

FB, Gmail và Yahoo áp dụng cái này giờ khó rồi. Đơn giản là hãy dùng HTTPS, cả 3 site trên đều cho phép bật mặc định dùng HTTPS. Mã hoá rồi thì man trên giời cũng ko middle được (dĩ nhiên cũng phải biết tí chút là khi nào SSL Cert bị giả mạo và trình duyệt từ chối nhé). 

Ai trong dân kĩ thuật cũng biết SSL/TLS sẽ hỗ trợ việc chống lại man-in-middle attack. Thế nhưng đó là người dùng am hiểu kĩ thuật, còn người dùng bình thường chả mấy quan tâm, nhất là dân business. Việc HTTPS không được yêu cầu mặc định trong các website cũng là một nguyên nhân khiến kiểu tấn công này vẫn dung hại. Đáng nhẽ các website phải ép người dùng dùng HTTPS để an toàn Đã bảo là cái title được giật cho vui và để có cái mà bàn luận mà, dĩ nhiên thực tế là Gmail và Yahoo đã chơi trò ép người dùng được một thời gian rồi :D Mặt khác, SSL/TLS hiện đang bị kiểu tấn công do lão mrro mới công bố đe doạ nghiêm trọng. Kĩ thuật tấn công đó khó khăn khi tấn công từ xa, nhưng nếu tấn công trong một mạng local dạng mạng wireless, khi các dữ liệu dễ dàng bị nghe lén thì khả năng tấn công diễn ra dễ dàng hơn rất nhiều. Đọc thêm bài viết trên blog của lão mrro để rõ thêm Một câu hỏi nhỏ: Các bạn thử nghĩ tại sao mà các trang web hầu hết đều không áp dụng giao thức HTTPS là yêu cầu kết nối mặc định ? :*-  

Mình nghĩ có một số lý do chính : - Đề phòng client không hỗ trợ SSL - Performance (cost cho server encrypt...) - Không ai để home page là https cả vì chắc chắn là người dùng sẽ gõ thiếu :-) - Chỉ dùng được 1 domain trên 1 ip với https  

freakmind wrote:

Mình nghĩ có một số lý do chính : - Đề phòng client không hỗ trợ SSL - Performance (cost cho server encrypt...) - Không ai để home page là https cả vì chắc chắn là người dùng sẽ gõ thiếu :-) - Chỉ dùng được 1 domain trên 1 ip với https  

Cái màu vàng này hay à nha. Bạn giải thích một chút được không?  

@freakmind Xin bạn nói rõ hơn việc 1 cert chỉ gắn với một ip và domain? Theo tui nghĩ thì cert chỉ gắn với domain. Domain có thể có nhiều ip (load balancing). Xin nói thêm nếu arp poison + sslstrip thì attacker có thể lấy được session cookie 

@freakmind cert chứa domain trong CN, nên client kiểm tra là kiểm tra domain name. Còn việc hạn chế 1 ip - 1 cert là do hạn chế của Name Virtual Host đối với apache httpd http://wiki.apache.org/httpd/NameBasedSSLVHosts Trong tài liệu bạn gửi có sơ đồ cụ thể cho việc này. Lúc thiết lập SSL thì HTTP GET request chưa được web server handle nên chưa thể xử lý Name Virtual Host (field Host trong HTTP request) -> 1 ip chỉ có thể gắn với 1 cert, tuy nhiên không có ai cấm bạn sử dụng 1 cert cho nhiều ip, tất nhiên với điều kiện là các ip đó đều resolve ra 1 domain đã ghi trong CN của cert đó.  

- Không ai để home page là https cả vì chắc chắn là người dùng sẽ gõ thiếu  

- Chỉ dùng được 1 domain trên 1 ip với https  

Mình nghĩ cần điều chỉnh lại 1 chút:

- Đề phòng client không hỗ trợ SSL  

Hầu hết các web brower giờ cái nào không hỗ trợ SSL?  

Gõ http:// thì trang web sẽ wwwect về https để ép người dùng sử dụng https.  

Mình confirm là Apache phiên bản mới (mình không nhớ rõ 2.x bao nhiêu) nhưng cho phép 1 IP multiple ssl certs.  

Trả lời anh xnohat: HTTPS không phải mặc định là tại vì thêm chữ "S". Một chữ thôi nhưng server và client phải làm việc nhiều lằm :) khoai 

• Trình duyệt: Firefox (bắt buộc) Thực hiện ARP Poison Routing: Cain&Abel Sniff dữ liệu và tái dựng TCP Stream: Wireshark Cookie injection: Firefox và Add-on GreaseMonkey, Cookie Injector script (down file đính kèm)

• IP của HTTP Server: đây chính là IP của facebook IP của client: đây chính là IP của người dùng đang truy cập facebook

Ip.addr eq địa_chỉ_ip_của_HTTP_Server (vd: Ip.addr eq 69.171.228.13 )  

Ip.addr eq địa_chỉ_ip_của_HTTP_Server and Ip.addr eq địa_chỉ_ip_của_Client 

HTTPS không phải mặc định là tại vì thêm chữ "S". Một chữ thôi nhưng server và client phải làm việc nhiều lằm.  

MrKhoai wrote:

HTTPS không phải mặc định là tại vì thêm chữ "S". Một chữ thôi nhưng server và client phải làm việc nhiều lằm.  

anh không nghĩ là server và client phải làm việc quá nhiều. nhiều site lơn trên thế giới bây giờ đã triển khai mặc định HTTPS cho nhiều dịch vụ lớn của họ. em xem thêm http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html. -m  

@xnohat : Cho mình hỏi nếu bind IP cho MAC (hoặc static IP MAC tại client ) liệu cách tấn công này còn hữu hiệu không vậy xnohat ? Cain&Abel liện có poinsoning được router hay gateway không ? Thanks ! 

Có lẽ ở đây mình không chú ý đến cái wifi và trạng thái card mạng mà mình gắn nó vào LAN. Nếu dùng Static arp and gán MAC router cho client , trong LAN có 1 host bật trạng thái card mạng Promiscuous mode thì có bị poison ko ?  

1. Bạn gắn static arp cho router hay client? Router của bạn của hãng nào, thuộc dòng nào? bạn cấu hình nó ra sao? => Nếu dùng static ARP cho cả client và router thì không thể poison ARP nữa, nhưng gói tin vẫn có nguy cơ bị sniff :P 2. Để phòng tránh thì tốt nhất là dùng tính năng port security trên Switch (và chỉ có một máy tính nối trực tiếp đến port được bật tính năng port security) đồng thời dùng arp tĩnh cho client và switch thì không có host nào có thể sniff cũng như poison được. - Ky0 -  

1. Tất nhiên mình làm cho cả router và client , router mình có Port Security . Mình cấu hình nó theo yêu cầu của mình . 2. Mình cũng nghĩ phương pháp ngăn chặn trên là hữu hiệu nhất , nếu gói tin vẫn bị sniff nhưng giao thức là SSL thì mình nghĩ tấn công trong LAN khi đã có các cơ chế bảo mật như thế thì ok và để lấy đc Session là rất khó như đã nói ở trên . Nếu client change MAC và dùng 1 Static IP khác trong lớp thì sao nhỉ vẫn không có khả năng poision . Thanks Ky0  

@xnohat : Cho mình hỏi nếu bind IP cho MAC (hoặc static IP MAC tại client ) liệu cách tấn công này còn hữu hiệu không vậy xnohat ? Cain&Abel liện có poinsoning được router hay gateway không ? Thanks ! 

mrro wrote:

MrKhoai wrote:

HTTPS không phải mặc định là tại vì thêm chữ "S". Một chữ thôi nhưng server và client phải làm việc nhiều lằm.  

anh không nghĩ là server và client phải làm việc quá nhiều. nhiều site lơn trên thế giới bây giờ đã triển khai mặc định HTTPS cho nhiều dịch vụ lớn của họ. em xem thêm http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html. -m  

Gần đây em đang bị 1 vấn đề về SSL trên website của mình Nếu sử dụng các link internal mình có thể format thành "https" được. Nhưng nếu trong website có 1 link external format là "http" thì trình duyệt sẽ báo lỗi cert. Ví dụ như Gmail cũng hay bị báo lỗi như thế này

Theo em nghĩ "https" sẽ được mở khi chúng ta vào những link yêu cầu nhập thông tin cá nhân trên 1 website là hợp lý nhất vì những trang đó ít khi kèm các link external ( ví dụ như : login, register... ) 

@mrro Xin ý kiến của mrro về nhận định ở trong blog post này http://vincent.bernat.im/en/blog/2011-ssl-dos-mitigation.html Theo đó thì với tỷ lệ CPU giữa client : server thì việc client có thể làm tốn CPU của server khá nhiều. Như vậy thì chừng vài chục máy trạm là có thể làm quá tài server? DOS ở đây sẽ là DOS về CPU chứ không còn là network nữa.  

cảm ơn anh em làm được rồi, nhưng cái cảm giác vào nhà người ta không xin phép sao sao ấy :( 

@freakmind Xin bạn nói rõ hơn việc 1 cert chỉ gắn với một ip và domain? Theo tui nghĩ thì cert chỉ gắn với domain. Domain có thể có nhiều ip (load balancing). Xin nói thêm nếu arp poison + sslstrip thì attacker có thể lấy được session cookie 

Ý mình ở đây tức là bản thân thằng broadcast đã che giấu nó đi rồi. Bằng cách gán static ARP, disable Net Bios, thiết lập firewall cá nhân. Loại bỏ các gói ICMP, nói chung là làm mọi cách để tất cả mọi người trong mạng đó không thể lần ra nó, thậm chí là ping cũng không ? Thì liệu kẻ ăn cắp có thể mò ra không ?  

Mình hơi thắc mắc chuyện này, nếu như trong hệ thống mạng đó sử dụng cơ chế mã hoá gói tin thì có thể khắc phục được không ? Tức là mã hoá gói tin từ client --> Gateway thì liệu có khả năng vẫn bị đánh cắp thông tin ? Đối với 1 số đơn vị không có điều kiện để sở hữu các thiết bị thông minh có khả năng tránh flood ARP cũng như giả Mac, thì liệu còn cách nào để đỡ vụ này ? Nếu mình sử dụng tất cả IP động được tập trung quản lý bởi DHCP server và DNS server thì liệu có tránh được hay không ? 

Bạn gắn static arp cho router hay client? Router của bạn của hãng nào, thuộc dòng nào? bạn cấu hình nó ra sao? => Nếu dùng static ARP cho cả client và router thì không thể poison ARP nữa, nhưng gói tin vẫn có nguy cơ bị sniff :P Để phòng tránh thì tốt nhất là dùng tính năng port security trên Switch (và chỉ có một máy tính nối trực tiếp đến port được bật tính năng port security) đồng thời dùng arp tĩnh cho client và switch thì không có host nào có thể sniff cũng như poison được. - Ky0 -  

Hôm nay thử làm chi tiết lại các bước, mình vẫn dừng lại ở bước dựng session. Cái grease monkey của mình vẫn chưa cài được cái script như xnohat trình bày ( chưa tải được). Nhưng mình vẫn sniff được username và password trước khi nó được mã hoá thành chuỗi các con số. Chi tiết vụn vặt không cần bàn, nhưng dựa theo bạn Kill, mình thử trên 2 hệ thống, 1 là dựa vào 1 server trung gian giữa router và client. Kết quả là ko thể poison được. Nhưng khi gắn với router thì ra hết. Vì thế nên mình thắc mắc, không có cách nào mã hoá được dữ liệu trước khi nó được send (dạng plaint text) trong mạng hay sao ? Ít ra cũng phải có cách nào đỡ được chứ, trong trường hợp cấu hình static cho router và client không hiệu quả ? 

peter_nguyen1405 wrote:

Hôm nay thử làm chi tiết lại các bước, mình vẫn dừng lại ở bước dựng session. Cái grease monkey của mình vẫn chưa cài được cái script như xnohat trình bày ( chưa tải được). Nhưng mình vẫn sniff được username và password trước khi nó được mã hoá thành chuỗi các con số. Chi tiết vụn vặt không cần bàn, nhưng dựa theo bạn Kill, mình thử trên 2 hệ thống, 1 là dựa vào 1 server trung gian giữa router và client. Kết quả là ko thể poison được. Nhưng khi gắn với router thì ra hết. Vì thế nên mình thắc mắc, không có cách nào mã hoá được dữ liệu trước khi nó được send (dạng plaint text) trong mạng hay sao ? Ít ra cũng phải có cách nào đỡ được chứ, trong trường hợp cấu hình static cho router và client không hiệu quả ? 

1. File tải script grease-monkey về hoàn toàn bình thường, file được đặt trên server của HVA 2. Tôi chưa rõ đoạn này "mình thử trên 2 hệ thống, 1 là dựa vào 1 server trung gian giữa router và client. Kết quả là ko thể poison được. Nhưng khi gắn với router thì ra hết." bồ thực ra muốn nói về điều gì, nên chưa thể đưa ra câu trả lời thoả đáng được. 3. Cách đỡ ? , đơn giản nhất có HTTPS , còn phức tạp hơn thì phải có các thiết bị mạng của hãng Cisco hoặc thiết lập một hệ thống đặc chủng để giám sát mạng và loại bỏ các máy tính đang thực hiện ARP Poisoning. Cách dùng HTTPS là đơn giản nhất cho người dùng thông thường tự bảo vệ mình. Các quán cafe thì có thể (hoặc nên) in ra một bảng hướng dẫn người dùng tự set static MAC add của Gateway Router lên máy mình ( rất đơn giản ) Đây là lý do tôi không viết thêm phần 3 của loạt bài như dư định ban đầu, vốn sẽ viết về các cách tấn công thông dụng nhằm vô hiệu hoá biện pháp sử dụng HTTPS.  

gần 1 năm rồi e mới quay lại hva mà gặp đc bài của anh xnohat viết quá chi tiết :x em chưa thử nhưng cách này chỉ vào đc fb của người khác chứ không lấy được pass đúng ko ạ? Và nếu người kia đổi pass thì mình cũng phải đợi cơ hội để hack lại, còn cookies cũ thì ko dùng đc nữa có đúng không anh? 

@xnohat: có thể nêu một số gợi ý để vượt qua https được không :) 

E vẫn chưa biết làm cách nào để đăng nhập bằng HTTPS trong facebook, em đâu thấy chỗ nào ghi đăng nhập bằng HTTPS đâu. 

cái quan trọng là mình làm sao hack pass wifi đây xnohat :D 

Em đang hóng các phần tiếp theo :) Quá hay. Em đã làm thử theo các anh nhưng mà làm dc tới cái Wireshap ak :) Mà theo em thấy thì hình như làm như vầy khiến mạng bị chậm à. Khi em làm thì các máy tính khác truy cập facebook rất lâu, không thể load hình và khung chat. Do khi mình chuyển trung gian thì việc truyền dữ liệu chậm lại thấy rõ?