Lỗ hổng này có tác động tiềm năng cao bởi vì nếu hệ thống của bạn đã bị tấn công, nó sẽ vẫn dễ bị tổn thương ngay cả sau khi vá, và các cuộc tấn công có thể không để lại bất kỳ dấu vết nào trong nhật ký. Rất có thể nếu bạn vá nhanh chóng và bạn không phải là mục tiêu cao cấp, sẽ không có ai có thể tấn công bạn, nhưng thật khó để chắc chắn.
Tôi có dễ bị tổn thương không?
Phiên bản lỗi của OpenSSL
Phần mềm có lỗi là thư viện OpenSSL 1.0.1 lên tới 1.0.1f và OpenSSL 1.0.2 lên đến beta1. Các phiên bản cũ hơn (0.9.x, 1.0.0) và các phiên bản đã sửa lỗi (1.0.1g trở đi, 1.0.2 beta 2 trở đi) không bị ảnh hưởng. Đó là một lỗi triển khai, không phải là một lỗ hổng trong giao thức, vì vậy chỉ các chương trình sử dụng thư viện OpenSSL bị ảnh hưởng.
Bạn có thể sử dụng công cụ dòng lệnh openssl version -ađể hiển thị số phiên bản OpenSSL. Lưu ý rằng một số bản phân phối chuyển bản sửa lỗi sang các bản phát hành trước đó; nếu nhật ký thay đổi gói của bạn đề cập đến sửa lỗi Heartbleed, thì tốt, ngay cả khi bạn thấy một phiên bản như 1.0.1f. Nếu openssl version -ađề cập đến ngày xây dựng (không phải ngày trên dòng đầu tiên) của 2014-04-07 vào khoảng tối UTC trở lên, bạn sẽ ổn. Lưu ý rằng gói OpenSSL có thể có 1.0.0trong tên của nó mặc dù phiên bản là 1.0.1 ( 1.0.0đề cập đến khả năng tương thích nhị phân).
Ứng dụng bị ảnh hưởng
Khai thác được thực hiện thông qua một ứng dụng sử dụng thư viện OpenSSL để thực hiện các kết nối SSL . Nhiều ứng dụng sử dụng OpenSSL cho các dịch vụ mật mã khác, và điều đó cũng ổn: lỗi là ở việc triển khai một tính năng cụ thể của giao thức SSL, nhịp tim đập nhịp tim.
Bạn có thể muốn kiểm tra những chương trình nào được liên kết với thư viện trên hệ thống của bạn. Trên các hệ thống sử dụng dpkg và apt (Debian, Ubuntu, Mint, '), lệnh sau liệt kê các gói được cài đặt ngoài các thư viện sử dụng libssl1.0.0(gói bị ảnh hưởng):
apt-cache rdepends libssl1.0.0 | tail -n +3 |
xargs dpkg -l 2>/dev/null | grep '^ii' | grep -v '^ii lib'
Nếu bạn chạy một số phần mềm máy chủ trong danh sách này và lắng nghe các kết nối SSL, bạn có thể bị ảnh hưởng. Điều này liên quan đến máy chủ web, máy chủ email, máy chủ VPN, v.v. Bạn sẽ biết rằng bạn đã bật SSL vì bạn phải tạo chứng chỉ, bằng cách gửi yêu cầu ký chứng chỉ cho cơ quan chứng nhận hoặc bằng cách tự ký tên chứng chỉ. (Có thể một số quy trình cài đặt đã tạo chứng chỉ tự ký mà bạn không nhận thấy, nhưng điều đó thường chỉ được thực hiện cho các máy chủ nội bộ, không phải cho các máy chủ tiếp xúc với Internet.) Nếu bạn chạy một máy chủ dễ bị tổn thương tiếp xúc với Internet, hãy xem xét nó bị xâm phạm trừ khi nhật ký của bạn hiển thị không có kết nối kể từ thông báo vào ngày 2014-04-07. (Điều này giả định rằng lỗ hổng không được khai thác trước khi thông báo.) Nếu máy chủ của bạn chỉ bị lộ trong nội bộ,
Phần mềm máy khách chỉ bị ảnh hưởng nếu bạn sử dụng nó để kết nối với máy chủ độc hại. Vì vậy, nếu bạn kết nối với nhà cung cấp email của mình bằng IMAPS, bạn không cần phải lo lắng (trừ khi nhà cung cấp bị tấn công - nhưng nếu đó là trường hợp họ nên cho bạn biết), nhưng nếu bạn duyệt các trang web ngẫu nhiên có trình duyệt dễ bị tổn thương, bạn có thể cần lo lắng. Cho đến nay, có vẻ như lỗ hổng đã không được khai thác trước khi nó được phát hiện, vì vậy bạn chỉ cần lo lắng nếu bạn kết nối với các máy chủ độc hại kể từ 2014-04-08.
Các chương trình sau không bị ảnh hưởng vì chúng không sử dụng OpenSSL để triển khai SSL:
- SSH (giao thức không phải là SSL)
- Chrome / Chromium ( sử dụng NSS )
- Firefox (sử dụng NSS) (ít nhất là với Firefox 27 trên Ubuntu 12.04, nhưng không phải với tất cả các bản dựng?
Tác động là gì?
Lỗi này cho phép mọi khách hàng có thể kết nối với máy chủ SSL của bạn để lấy khoảng 64kB bộ nhớ từ máy chủ cùng một lúc. Khách hàng không cần phải được xác thực theo bất kỳ cách nào. Bằng cách lặp lại cuộc tấn công, khách hàng có thể kết xuất các phần khác nhau của bộ nhớ trong các lần thử liên tiếp. Điều này có khả năng cho phép kẻ tấn công lấy bất kỳ dữ liệu nào có trong bộ nhớ của quá trình máy chủ, bao gồm các khóa, mật khẩu, cookie, v.v.
Một trong những phần dữ liệu quan trọng mà kẻ tấn công có thể lấy được là khóa riêng SSL của máy chủ. Với dữ liệu này, kẻ tấn công có thể mạo danh máy chủ của bạn.
Lỗi này cũng cho phép bất kỳ máy chủ nào mà máy khách SSL của bạn kết nối để lấy khoảng 64kB bộ nhớ từ máy khách cùng một lúc. Đây là một vấn đề đáng lo ngại nếu bạn đã sử dụng một máy khách dễ bị tấn công để thao tác dữ liệu nhạy cảm và sau đó được kết nối với một máy chủ không tin cậy với cùng một máy khách. Do đó, các kịch bản tấn công ở bên này ít có khả năng hơn đáng kể so với phía máy chủ.
Lưu ý rằng đối với các bản phân phối thông thường, không có tác động bảo mật đối với phân phối gói vì tính toàn vẹn của các gói phụ thuộc vào chữ ký GPG, không phải trên vận chuyển SSL.
Làm cách nào để khắc phục lỗ hổng?
Khắc phục sự cố máy chủ
Lấy tất cả các máy chủ bị ảnh hưởng ngoại tuyến. Miễn là họ đang chạy, họ có khả năng rò rỉ dữ liệu quan trọng.
Nâng cấp gói thư viện OpenSSL . Tất cả các bản phân phối nên có một bản sửa lỗi ngay bây giờ (với 1.0.1g hoặc với một bản vá sửa lỗi mà không thay đổi số phiên bản). Nếu bạn biên dịch từ nguồn, hãy nâng cấp lên 1.0.1g trở lên. Hãy chắc chắn rằng tất cả các máy chủ bị ảnh hưởng được khởi động lại.
Trên Linux, bạn có thể kiểm tra xem các quy trình có khả năng bị ảnh hưởng có còn chạy với khônggrep 'libssl.*(deleted)' /proc/*/maps
Tạo khóa mới . Điều này là cần thiết bởi vì lỗi có thể đã cho phép kẻ tấn công lấy được khóa riêng cũ. Thực hiện theo các thủ tục tương tự bạn đã sử dụng ban đầu.
- Nếu bạn sử dụng chứng chỉ được ký bởi cơ quan chứng nhận, hãy gửi khóa công khai mới cho CA. Khi bạn nhận được chứng chỉ mới, hãy cài đặt nó trên máy chủ của bạn.
- Nếu bạn sử dụng chứng chỉ tự ký, hãy cài đặt nó trên máy chủ của bạn.
- Dù bằng cách nào, hãy di chuyển các khóa và chứng chỉ cũ ra khỏi đường đi (nhưng đừng xóa chúng, chỉ cần đảm bảo chúng không được sử dụng nữa).
Bây giờ bạn có các khóa không thỏa hiệp mới, bạn có thể đưa máy chủ của mình trực tuyến trở lại .
Thu hồi các chứng chỉ cũ.
Đánh giá thiệt hại : bất kỳ dữ liệu nào có trong bộ nhớ của quy trình phục vụ các kết nối SSL có thể có khả năng đã bị rò rỉ. Điều này có thể bao gồm mật khẩu người dùng và dữ liệu bí mật khác. Bạn cần đánh giá những gì dữ liệu này có thể đã được.
- Nếu bạn đang chạy một dịch vụ cho phép xác thực mật khẩu, thì mật khẩu của người dùng đã kết nối một chút trước khi lỗ hổng được công bố sẽ bị coi là bị xâm phạm. Kiểm tra nhật ký của bạn và thay đổi mật khẩu của bất kỳ người dùng bị ảnh hưởng.
- Cũng vô hiệu hóa tất cả các cookie phiên, vì chúng có thể đã bị xâm phạm.
- Chứng chỉ khách hàng không bị xâm phạm.
- Bất kỳ dữ liệu nào được trao đổi từ một chút trước khi lỗ hổng có thể vẫn còn trong bộ nhớ của máy chủ và do đó có thể đã bị rò rỉ cho kẻ tấn công.
- Nếu ai đó đã ghi lại kết nối SSL cũ và truy xuất khóa của máy chủ của bạn, giờ đây họ có thể giải mã bản sao của họ. (Trừ khi PFS được đảm bảo - nếu bạn không biết, thì không.)
Khắc phục trong các trường hợp khác
Các máy chủ chỉ nghe trên localhost hoặc trên mạng nội bộ chỉ được xem là bị lộ nếu người dùng không tin cậy có thể kết nối với chúng.
Với khách hàng, chỉ có các tình huống hiếm hoi mà lỗi có thể bị khai thác: một khai thác sẽ yêu cầu bạn sử dụng cùng một quy trình khách hàng để
- thao túng dữ liệu bí mật (ví dụ mật khẩu, chứng chỉ ứng dụng khách, nhận);
- và sau đó, trong cùng một quy trình, được kết nối với một máy chủ độc hại qua SSL.
Vì vậy, ví dụ một ứng dụng email mà bạn chỉ sử dụng để kết nối với nhà cung cấp thư (không hoàn toàn không tin cậy) của bạn không phải là vấn đề đáng lo ngại (không phải là máy chủ độc hại). Chạy wget để tải xuống một tập tin không phải là một mối quan tâm (không có dữ liệu bí mật để rò rỉ).
Nếu bạn đã làm điều đó trong khoảng thời gian từ 2014-04-07 tối UTC và nâng cấp thư viện OpenSSL của bạn, hãy xem xét bất kỳ dữ liệu nào trong bộ nhớ của khách hàng sẽ bị xâm phạm.
Người giới thiệu