Tối 10/XNUMX, dịch vụ hỗ trợ Mail.ru bắt đầu nhận được khiếu nại của người dùng về việc không thể kết nối với máy chủ Mail.ru IMAP/SMTP thông qua các chương trình email. Đồng thời, một số kết nối không thành công và một số hiển thị lỗi chứng chỉ. Lỗi xảy ra do "máy chủ" cấp chứng chỉ TLS tự ký.
Trong hai ngày, hơn 10 đơn khiếu nại được gửi đến từ người dùng trên nhiều mạng và với nhiều thiết bị khác nhau, khiến khó có khả năng sự cố nằm ở mạng của bất kỳ nhà cung cấp nào. Phân tích chi tiết hơn về vấn đề cho thấy máy chủ imap.mail.ru (cũng như các máy chủ và dịch vụ thư khác) đang được thay thế ở cấp DNS. Hơn nữa, với sự trợ giúp tích cực của người dùng, chúng tôi phát hiện ra rằng nguyên nhân là do mục nhập không chính xác trong bộ đệm của bộ định tuyến của họ, bộ đệm này cũng là trình phân giải DNS cục bộ và trong nhiều trường hợp (nhưng không phải tất cả) hóa ra là MikroTik. thiết bị, rất phổ biến trong các mạng công ty nhỏ và từ các nhà cung cấp Internet nhỏ.
Vấn đề là gì
Vào tháng 2019 năm XNUMX, các nhà nghiên cứu một số lỗ hổng trong MikroTik RouterOS (CVE-2019-3976, CVE-2019-3977, CVE-2019-3978, CVE-2019-3979), cho phép tấn công ngộ độc bộ đệm DNS, tức là. khả năng giả mạo các bản ghi DNS trong bộ đệm DNS của bộ định tuyến và CVE-2019-3978 cho phép kẻ tấn công không phải đợi ai đó từ mạng nội bộ yêu cầu quyền truy cập vào máy chủ DNS của mình nhằm đầu độc bộ đệm của trình phân giải mà bắt đầu như vậy tự mình yêu cầu thông qua cổng 8291 (UDP và TCP). Lỗ hổng đã được MikroTik vá trong các phiên bản RouterOS 6.45.7 (ổn định) và 6.44.6 (dài hạn) vào ngày 28/2019/XNUMX, nhưng theo Hầu hết người dùng hiện chưa cài đặt các bản vá.
Rõ ràng vấn đề này hiện đang được tích cực khai thác “trực tiếp”.
Tại sao nó nguy hiểm
Kẻ tấn công có thể giả mạo bản ghi DNS của bất kỳ máy chủ nào được người dùng truy cập trên mạng nội bộ, từ đó chặn lưu lượng truy cập vào máy chủ đó. Nếu thông tin nhạy cảm được truyền đi mà không mã hóa (ví dụ: qua http:// mà không có TLS) hoặc người dùng đồng ý chấp nhận chứng chỉ giả, kẻ tấn công có thể lấy được tất cả dữ liệu được gửi qua kết nối, chẳng hạn như thông tin đăng nhập hoặc mật khẩu. Thật không may, thực tế cho thấy rằng nếu người dùng có cơ hội chấp nhận chứng chỉ giả, anh ta sẽ lợi dụng nó.
Tại sao máy chủ SMTP và IMAP và điều gì đã cứu người dùng
Tại sao những kẻ tấn công cố gắng chặn lưu lượng truy cập SMTP/IMAP của các ứng dụng email chứ không phải lưu lượng truy cập web, mặc dù hầu hết người dùng truy cập thư của họ thông qua trình duyệt HTTPS?
Không phải tất cả các chương trình email hoạt động qua SMTP và IMAP/POP3 đều bảo vệ người dùng khỏi lỗi, ngăn người dùng gửi thông tin đăng nhập và mật khẩu thông qua kết nối không an toàn hoặc bị xâm phạm, mặc dù theo tiêu chuẩn. , được áp dụng vào năm 2018 (và được triển khai trong Mail.ru sớm hơn nhiều), họ phải bảo vệ người dùng khỏi bị chặn mật khẩu thông qua mọi kết nối không an toàn. Ngoài ra, giao thức OAuth rất hiếm khi được sử dụng trong ứng dụng email (nó được hỗ trợ bởi máy chủ thư Mail.ru) và nếu không có nó, thông tin đăng nhập và mật khẩu sẽ được truyền trong mỗi phiên.
Các trình duyệt có thể được bảo vệ tốt hơn một chút trước các cuộc tấn công Man-in-the-Middle. Trên tất cả các miền quan trọng của mail.ru, ngoài HTTPS, chính sách HSTS (bảo mật truyền tải nghiêm ngặt HTTP) đều được bật. Khi bật HSTS, trình duyệt hiện đại không cung cấp cho người dùng tùy chọn dễ dàng để chấp nhận chứng chỉ giả, ngay cả khi người dùng muốn. Ngoài HSTS, người dùng đã được cứu vì thực tế là kể từ năm 2017, các máy chủ SMTP, IMAP và POP3 của Mail.ru cấm chuyển mật khẩu qua kết nối không bảo mật, tất cả người dùng của chúng tôi đã sử dụng TLS để truy cập qua SMTP, POP3 và IMAP, và do đó thông tin đăng nhập và mật khẩu chỉ có thể chặn nếu chính người dùng đồng ý chấp nhận chứng chỉ giả mạo.
Đối với người dùng di động, chúng tôi luôn khuyên bạn nên sử dụng ứng dụng Mail.ru để truy cập thư, vì... làm việc với thư trong đó an toàn hơn so với trong trình duyệt hoặc ứng dụng khách SMTP/IMAP tích hợp sẵn.
Phải làm gì
Cần phải cập nhật chương trình cơ sở MikroTik RouterOS lên phiên bản an toàn. Nếu vì lý do nào đó mà điều này không thể thực hiện được thì cần phải lọc lưu lượng trên cổng 8291 (tcp và udp), điều này sẽ làm phức tạp thêm việc khai thác sự cố, mặc dù nó sẽ không loại trừ khả năng bị chèn thụ động vào bộ đệm DNS. ISP nên lọc cổng này trên mạng của họ để bảo vệ người dùng doanh nghiệp.
Tất cả người dùng đã chấp nhận chứng chỉ thay thế phải khẩn trương thay đổi mật khẩu cho email và các dịch vụ khác mà chứng chỉ này được chấp nhận. Về phần mình, chúng tôi sẽ thông báo cho người dùng truy cập thư thông qua các thiết bị dễ bị tấn công.
PS Ngoài ra còn có một lỗ hổng liên quan được mô tả trong bài viết "".
Nguồn: www.habr.com