it-swarm-vi.com

Có phải các cuộc tấn công "người ở giữa" là cực kỳ hiếm?

Trong "Một số suy nghĩ về tranh cãi danh sách liên lạc trên iPhone và bảo mật ứng dụng" , blog cdixon

Chris Dixon đưa ra tuyên bố về bảo mật web

Nhiều nhà bình luận đã cho rằng một rủi ro bảo mật chính là thực tế là dữ liệu được truyền đi dưới dạng văn bản thuần túy. Mã hóa qua dây luôn là một ý tưởng hay nhưng trong thực tế, các cuộc tấn công của người trung gian là cực kỳ hiếm. Tôi sẽ lo lắng chủ yếu về nhiều trường hợp phổ biến hơn của 1) ai đó (người trong cuộc hoặc người ngoài cuộc) ăn cắp trong cơ sở dữ liệu của công ty, 2) trát đòi chính phủ cho cơ sở dữ liệu của công ty. Cách bảo vệ tốt nhất trước những rủi ro này là mã hóa dữ liệu theo cách mà tin tặc và chính công ty có thể không mã hóa dữ liệu (hoặc không gửi dữ liệu đến máy chủ ngay từ đầu).

Tôi tự hỏi liệu có bất kỳ dữ liệu thế giới thực, cứng, lạnh để sao lưu khẳng định đó - là những cuộc tấn công "người ở giữa" thực sự hiếm gặp trong thế giới thực, dựa trên dữ liệu thu thập được từ các cuộc xâm nhập thực tế hoặc sự cố bảo mật?

135
Jeff Atwood

Tài nguyên hiện tại yêu thích của tôi cho dữ liệu thế giới thực lạnh, cứng Báo cáo điều tra vi phạm dữ liệu của Verizon 2011 . Một đoạn trích từ trang 69 của báo cáo:

Hành động

Ba loại hành động đe dọa hàng đầu là Hacking, Malware và Social. Các loại hành động hack phổ biến nhất được sử dụng là sử dụng thông tin đăng nhập bị đánh cắp, khai thác backtime và tấn công trung gian.

Từ việc đọc nó, tôi suy luận rằng đó là hành động thứ cấp được sử dụng một khi ai đó có chỗ đứng trong hệ thống, nhưng dữ liệu của Đơn vị tội phạm công nghệ cao Hà Lan nói rằng nó rất đáng tin cậy. Trong số 32 vi phạm dữ liệu tạo nên số liệu thống kê của họ, 15 hành động liên quan đến MITM.

Chắc chắn không dừng lại ở đó, mặc dù. Toàn bộ báo cáo đó là một mỏ vàng của việc đọc và là tác phẩm hay nhất mà tôi đã đi qua để chứng minh nơi các mối đe dọa thực sự xảy ra.

Để tham khảo nhiều hơn về các phương thức và tấn công MiTM, hãy xem thêm câu trả lời tuyệt vời này cho các cuộc tấn công MITM - khả năng của chúng như thế nào? Trên Serverfault.

Tôi sẽ đi xa hơn khi nói rằng bất kỳ trường hợp nào gốc SSL ho ra một chứng chỉ xấu là dấu hiệu của một cuộc tấn công, nếu không chúng sẽ là những thỏa hiệp khá vô dụng. Cuối cùng, vì tôi anh chàng đó, tôi chắc chắn sẽ cố gắng ghép vào hộp mạng của bạn bên ngoài tòa nhà nếu tôi đang làm điều đó. Người ta có thể làm những điều tuyệt vời với radio phần mềm ngay cả trên kết nối có dây.

103
Jeff Ferland

Câu trả lời đơn giản là không - có rất nhiều bằng chứng cho thấy loại tấn công này là phổ biến.

Một số kiểm soát do các ngân hàng mang lại (xác thực hai yếu tố, v.v.) một phần được yêu cầu để chống lại các cuộc tấn công MITM phổ biến hơn bao giờ hết đối với khách hàng.

Mặc dù có các hình thức tấn công khác (thỏa hiệp của khách hàng là một hình thức tốt) mà giờ đây có thể dễ dàng thực hiện hơn thông qua việc sử dụng phần mềm độc hại để đặt trojan trên PC khách, trong hầu hết các trường hợp, MITM vẫn tương đối dễ dàng.

Thực tế cốt lõi cần nhớ là tội phạm có xu hướng hoạt động dựa trên lợi tức đầu tư tốt. ROI cho một kẻ tấn công là rất tốt:

  • nguy cơ bị bắt thấp
  • rủi ro vật lý thấp
  • một số nỗ lực trong việc mã hóa khai thác có thể dẫn đến lợi ích tiền tệ trong thế giới thực
  • mã này sau đó có thể được sử dụng lại hoặc bán cho các tội phạm khác

Như @CanBerk đã nói, chúng ta sẽ không bao giờ nhận được bất kỳ giao thức 'hoàn toàn an toàn' nào, nhưng làm cho cuộc sống của bọn tội phạm trở nên khó khăn hơn là một giải pháp. MITM sẽ không biến mất cho đến khi nó trở nên quá khó để có thể sinh lãi.

29
Rory Alsop

thỏa hiệp gần đây của cơ quan cấp chứng chỉ DigiNotar dẫn đến việc phát hành hơn 500 chứng chỉ giả cho google.com, Microsoft.com, cia .gov và hàng trăm trang web khác. Các chứng chỉ này bằng cách nào đó đã xâm nhập vào 40 ISP khác nhau của Iran, dẫn đến một cuộc tấn công khổng lồ , xác nhận đã ảnh hưởng đến hơn 300.000 người dùng Iran trong quá trình vài tháng.

(Các) hacker chịu trách nhiệm - đã xác nhận là cùng một người chịu trách nhiệm cho cuộc tấn công trước vào CA Comodo - tuyên bố có toàn quyền truy cập vào năm CA khác, mặc dù anh ta (họ) chỉ đặt tên cho một trong số họ .

Vì vậy, có, Tấn công trung gian là một mối đe dọa rất thực tế , ngay cả ngày nay.


Lưu ý: Để ngăn các loại tấn công này xảy ra với bạn, hãy xem xét sử dụng chương trình/addon để theo dõi các chứng chỉ cho những thay đổi đáng ngờ, như Patrol Patrol hoặc thử một trong các thay thế mới lạ mắt cho mô hình ủy quyền chứng chỉ mà mọi người đang nói đến.

18

Câu trả lời này chủ yếu là về tuyên bố của Chris Dixon hơn là trả lời "Có bao nhiêu cuộc tấn công đến từ MiTM".

Nếu chúng ta khẳng định cách khác nhau, người ta có thể trở thành MiTM và hậu quả đã cho, tôi nghĩ chúng ta có thể đưa ra một số kết luận về việc chúng ta có quan tâm đến việc các cuộc tấn công MiTM phổ biến hay không.

Nếu chúng ta xem xét một số rủi ro cho các tình huống khác nhau, chúng ta có thể có một cái gì đó như:

  • Ai đó đánh cắp cơ sở dữ liệu thông qua việc khai thác ứng dụng web?
  • Ai đó tấn công người dùng/quản trị viên thông qua cuộc tấn công MiTM

Tôi muốn nói rằng cái đầu tiên có tác động lớn hơn nhiều (nói chung) và theo nhiều cách nên được giảm nhẹ nhất và xử lý cái đầu tiên.

Vì vậy, để điểm 2 chiếm ưu thế so với điểm 1 Tôi nghĩ rằng MiTM sẽ thực sự điên rồ khi chúng ta đánh giá nó cao như một trở ngại bảo mật như điểm 1 (Như Chris biểu thị trong đoạn trích dẫn)!

Bây giờ nếu chúng ta thấy ở các vectơ tấn công khác nhau. Đầu tiên cho MiTM. Để trở thành MiTM, người ta có thể lấy ví dụ:

  • Sở hữu một điểm truy cập không dây lừa đảo. Điều này là không đáng kể, nhưng đối với một cuộc tấn công có chủ đích, bạn sẽ phải ở cùng một vị trí vật lý của nạn nhân bằng cách sử dụng webapp của bạn.
  • Đánh hơi dữ liệu không dây hoặc dữ liệu không được mã hóa thông qua HUB (chúng thậm chí còn tồn tại nữa?)
  • Sử dụng ARP Poisoning để tấn công người dùng. Không tầm thường trừ khi bạn ở trên cùng một mạng với người dùng được nhắm mục tiêu sử dụng ứng dụng web của bạn.
  • Ngộ độc bộ nhớ cache DNS. Để làm việc này, bạn cần phải đầu độc DNS đang được sử dụng bởi người dùng được nhắm mục tiêu. Nếu DNS không được thiết lập đúng cách, cuộc tấn công này sẽ trở nên hơi tầm thường để thực hiện, tuy nhiên có rất nhiều điều để dựa vào việc này để hoạt động.
  • Tấn công lừa đảo. Chúng vẫn đánh lừa những người dùng không nghi ngờ và ngây thơ, tuy nhiên rất nhiều trách nhiệm thuộc về người dùng.

Tất cả điều này chỉ để tấn công một hoặc một tập hợp nhỏ người dùng. Ngay cả khi đó, việc tấn công những người dùng này sẽ đưa ra cảnh báo cho họ trong trình duyệt của họ (có nhiều cách để tấn công điều này, nhưng tôi không đưa nó lên đây). Chỉ bằng cách thỏa hiệp một CA gốc hoặc bằng cách tìm ra lỗ hổng trong thuật toán được sử dụng để tạo chứng chỉ, bạn mới được phép đặt ra như một nhà phát hành chứng chỉ tin cậy.

Mặt khác, nếu chúng ta nhìn vào tất cả những thứ khó chịu tiềm tàng mà chúng ta có thể thấy nếu chúng ta không đầu tư vào bảo mật của chính ứng dụng web, chúng ta sẽ thấy các vectơ tấn công như:

  • SQL Injection - tầm thường và dễ dàng để khai thác và khám phá. Tác động thiệt hại rất cao.
  • XSS (Cross Site Scripting) - dễ khám phá, khó khai thác hơn. Tôi nghĩ rằng chúng ta sẽ thấy tác động của người dùng ngày càng cao hơn từ điều này trong tương lai. Tôi thấy trước điều này đang trở thành xu hướng "SQL SQL mới" mà chúng ta đã thấy trở lại trong những ngày qua.
  • CSRF (Cross Site Request giả mạo) - Vừa phải để khám phá, vừa phải để khai thác. Điều này sẽ yêu cầu người dùng điều hướng đến một trang web đã sở hữu, kích hoạt yêu cầu tới ứng dụng web của bạn, giao dịch thay mặt người dùng.

Vì vậy, chỉ bằng cách đề cập đến một vài phương pháp phổ biến cho cả tấn công webapp và trở thành MiTM, tôi sẽ để nó phân tích rủi ro/hậu quả cụ thể của tổ chức cụ thể mà bạn đang cố gắng bảo mật, cho dù bạn có nên bảo vệ người dùng của mình trực tiếp hay không triển khai SSL hoặc bằng cách bảo vệ toàn bộ ứng dụng web (bao gồm cả sở hữu trí tuệ, dữ liệu người dùng, dữ liệu nhạy cảm, dữ liệu tiềm năng có thể vi phạm các ứng dụng khác, v.v.).

Vì vậy, theo quan điểm khiêm tốn của tôi, tôi rất đồng ý với tuyên bố của Chris Dixon. Ưu tiên bảo mật webapp càng nhiều càng tốt trước khi bạn bắt đầu nghĩ đến việc bảo vệ lớp vận chuyển.

Chỉnh sửa: Lưu ý phụ: Các trang như Facebook, Gmail và các trang khác đã bị tấn công MiTM nặng nề trong sự kiện Firesheep. Điều này chỉ có thể được giảm thiểu thông qua SSL và nhận thức.

Tuy nhiên, nếu bạn nghĩ về nó, việc đánh hơi lưu lượng không dây bằng Firesheep và chiếm quyền điều khiển các phiên sẽ yêu cầu mạng LAN không dây mà bạn được kết nối để không có bất kỳ mã hóa nào.

Khi tôi lái xe chiến tranh ngày hôm nay, nó đã giảm đáng kể số lượng AP không dây mở và cả số lượng AP được kích hoạt WEP. Chúng tôi tiếp tục thấy ngày càng nhiều AP mã hóa WPA2 mà trong hầu hết các trường hợp cung cấp cho chúng tôi đủ bảo mật.

Bây giờ nguy cơ ai đó tạo ra một công cụ dễ dàng và thuận tiện để đánh hơi và chiếm quyền điều khiển phiên người dùng của bạn là gì? Tác động đối với những người dùng là gì? Nó cũng có thể được giảm nhẹ theo nhiều cách khác nhau (xác thực lại người dùng khi đến từ các dấu chân khác nhau cùng một lúc, thông báo cho người dùng khi có gì đó không ổn (gmail là một ví dụ tốt về điều này)).

7
Chris Dale

Nó không tìm thấy bất kỳ tờ giấy trắng hay tĩnh nào bao gồm dữ liệu trong thế giới thực mà bạn muốn có.

Tuy nhiên, tôi muốn thêm rằng các cuộc tấn công MitM trong các công ty xảy ra hàng ngày và hơn một lần. Một số nhà cung cấp bảo mật có các giải pháp để quét lưu lượng được mã hóa (ví dụ: Palo Alto Networks ) và ít nhất công ty tôi hiện đang làm việc đã kích hoạt tính năng này.

Để làm điều này, thiết bị tường lửa/proxy chỉ đơn giản được cấp chứng chỉ từ Tổ chức phát hành chứng chỉ nội bộ (CA) đã được tất cả khách hàng tin cậy. Khi một ứng dụng yêu cầu kết nối an toàn, thiết bị tường lửa/proxy sẽ tạo chứng chỉ mới cho máy chủ mục tiêu một cách nhanh chóng và gửi nó đến máy khách. Vì máy khách tin tưởng CA nội bộ, nó cũng tin tưởng chứng chỉ thiết bị và sẽ vui vẻ bắt đầu kết nối "an toàn".

2
Tex Hex

Tôi khá chắc chắn việc đánh hơi mật khẩu trên các mạng không dây là cực kỳ phổ biến. Chỉ cần xem có bao nhiêu hướng dẫn dành cho nó trên web từ một Tìm kiếm Google hoặc Tìm kiếm Bing .

0
Dare Obasanjo

Tôi đồng ý với daramarak rằng sẽ khá khó để tìm thấy dữ liệu trong thế giới thực về các cuộc tấn công của MitM. Một lý do cho điều đó là, các cuộc tấn công MitM về bản chất thường nhắm vào các cá nhân, trong khi các cuộc tấn công như DDoS hoặc SQL thường được nhắm mục tiêu vào các công ty, tổ chức, v.v.

Do đó, mặc dù chúng tôi thấy một báo cáo DDoS/tiêm/bất cứ điều gì gần như mỗi ngày, thông tin liên quan đến các cuộc tấn công MitM thường mang tính học thuật (ví dụ: "Twitter là DDoS'd!" So với "SSL dễ bị tổn thương bởi MitM")

Tuy nhiên, cần lưu ý rằng "hiếm" không nhất thiết có nghĩa là "cứng". Hầu hết các cuộc tấn công MitM được cho là dễ kéo hơn nhiều so với hầu hết các loại tấn công khác và nhiều giao thức chúng ta sử dụng hàng ngày dễ bị tấn công như vậy bằng cách này hay cách khác, đơn giản là vì rất khó để tạo ra một giao thức hoàn toàn an toàn chống lại MitM. Trên thực tế đây là trường hợp của hầu hết các vấn đề bảo mật, hầu hết các giải pháp là "nỗ lực tốt nhất" trái ngược với "hoàn toàn và tuyệt đối an toàn".

Do đó, tôi nghĩ lý do chính khiến các cuộc tấn công MitM ít phổ biến hơn là thường không có nhu cầu/khuyến khích để thực hiện.

0
Can Berk Güder