Trên thang điểm từ 1 đến 10, lỗ hổng này được đánh giá ở mức 11. Sau đây là các bước cần thực hiện để bảo vệ bạn khỏi lỗi OpenSSL này.

Lỗ hổng OpenSSL có tên Heartbleed là khá nghiêm trọng. Nhiều người trong chúng tôi trong lĩnh vực an ninh mạng dễ cường điệu hóa lên khi một thủ thuật khai thác lớn đối với một phần mềm phổ biến được công bố, nhưng tôi không thể đánh giá nó tốt hơn so với Bruce Schneier đã làm khi ông nói, "Trên thang điểm từ 1 đến 10, nó ở mức thứ 11".

OpenSSL là một dịch vụ mã nguồn mở rất phổ biến sử dụng giao thức SSL và TLS. Nó là xương sống cho hàng chục nghìn chương trình và dịch vụ hỗ trợ SSL hoặc TLS. Nó được sử dụng trong Apache, Nginx, và hầu hết các hệ điều hành mã nguồn mở (chẳng hạn như Linux và BSD). OpenSSL được sử dụng cho 60% hoặc nhiều hơn số trang web hỗ trợ kết nối HTTPS và được sử dụng cho nhiều dịch vụ phổ biến khác có sử dụng giao thức SSL/TLS, như POP/S, IMAP/S, và VPN.

Khi bạn kết nối với một dịch vụ SSL/TLS mà không chạy trên hệ điều hành Microsoft Windows hoặc Apple OS X, điều này là không an toàn. Bao gồm hầu hết thiết bị VPN, máy sao chép, và thậm chí là hầu hết thiết bị. Nếu bạn có thể kết nối đến dịch vụ nào đó bằng giao thức HTTPS, và dịch vụ đó không chạy trên Microsoft Windows hay OS X, coi như nó có thể bị khai thác.

Lưu ý: Ngay cả máy tính chạy Microsoft Windows hoặc OS X (mặc định không thể bị khai thác) có thể chạy phần mềm hoặc dịch vụ mà có thể không an toàn.

Lỗi này được đặt tên là Heartbleed bởi vì nó xảy ra với một tính năng phổ biến được biết đến như một nhịp tim (heatbeat), lần đầu được giới thiệu vào tháng 12/2011, và đã không được loại bỏ khỏi mã nguồn của OpenSSL cho đến ngày 07/04/2014. Nếu bạn có bất cứ dịch vụ nào đang sử dụng OpenSSL phiên bản 1.0.1 đến 1.0.1f, nó có thể bị khai thác. Bạn có thể xem thông tin chính xác nhất về lỗ hổng này trên trang Heartbleed.com. Sau đây là một ví dụ về cách mà lỗi này có thể bị khai thác và những ảnh hưởng tiềm tàng của nó.

Khi lỗi này xuất hiện và tôi xác nhận rằng nó dễ dàng xảy ra như thế nào, tôi bắt đầu gọi cho những người bạn mà tôi biết rằng họ đang sử dụng hàng nghìn dịch vụ OpenSSL. Thú vị, hầu hết trong số họ hoặc là đã kiểm soát được hoặc là không hiểu được phạm vi ảnh hưởng. Nếu bạn nghĩ rằng bạn đã vá một vài máy tính có sử dụng OpenSSL và đã sử dụng nó cả ngày, có thể bạn đã không hiểu làm thế nào mà OpenSSL phổ biến đến như vậy. Nó là cách bạn kết nối với các thiết bị an ninh, router, gateway và switch. Nó là cách bạn kết nối với nhiều dịch vụ điện toán đám mây (không phải Microsoft). Để giảm thiểu nguy cơ từ lỗi OpenSSL, bạn cần rà soát hệ thống nội bộ của bạn và kiểm tra hệ thống bạn kết nối đến.

Đối với hệ thống OpenSSL trong tầm kiểm soát của bạn

Bước 1: Tìm và kiểm kê các dịch vụ sử dụng OpenSSL

Bắt đầu bằng cách tìm kiếm tất cả các dịch vụ sử dụng OpenSSL trong hệ thống của bạn. Một cách nhanh chóng để làm điều này là quét cổng TCP với các cổng SSL và TLS mặc định bằng công cụ yêu thích của bạn, và loại trừ những dịch vụ đang chạy trên Microsoft Windows, OS X, hoặc các sản phẩm không hỗ trợ OpenSSL. SSH trên cổng TCP 22 hay HTTPS trên cổng 443 là một khởi đầu tốt, nhưng vẫn có hàng chục giao thức và cổng có thể sử dụng OpenSSL.

Tôi có thể nhanh chóng đưa ra dách sách như sau: 22 (SSH), 26 (encryted SMTP), 443 (HTTPS), 563 (encryted NNTP), 636 (LDAP over SSL), 989 và 990 (encryted FTP), 992 (encryted Telnet) , 993 (IMAPS), 994 (IRC mã hóa) và 995 (POP3S). Có lẽ còn rất nhiều giao thức khác sử dụng OpenSSL cho việc hỗ trợ SSL /TLS, và bất kỳ dịch vụ nào có thể chạy trên bất kỳ cổng nào (nếu được cấu hình để không sử dụng cổng mặc định). Đừng quên những trang web được lưu trữ bên ngoài hệ thống của bạn nhưng được sở hữu hoặc được quản lý bởi đội ngũ của bạn.

Bước 2: Xác định cổng dịch vụ đang chạy một phiên bản không an toàn của OpenSSL

Sau khi đã xác định được địa chỉ IP và cổng dịch vụ có khả năng sử dụng OpenSSL, bạn sử dụng công cụ quét để tạo một kết nối và nhận về chuỗi kết nối phản hồi (thường bao gồm thông tin phiên bản). Nhiều công cụ quét, như Nmap rất phổ biến với tính năng phong phú (nmap.org), có thể thực hiện việc quét cổng và xác định hãng sản xuất và số phiên bản cùng một lúc.

Bước 3: Ưu tiên những hệ thống có thể bị xâm phạm

Tiếp theo, xác định hệ thống có thể bị xâm phạm và những nguy cơ mà công ty của bạn gặp phải. Một dịch vụ công khai trên Internet có chứa thông tin bí mật, tài khoản đăng nhập, và các dịch vụ quan trọng khác chắc chắn phải được đưa lên đầu danh sách. Tôi cũng sẽ thêm vào danh sách các thiết bị an ninh và thiết bị mạng.

Những hệ thống như máy sao chép có thể hoặc không cần khắc phục ngay lập tức. Một số độc giả nghĩ rằng máy sao chép có thể không bao giờ cần khắc phục. Nhưng nếu bạn kết nối đến một máy sao chép được nối mạng trong công ty (hoặc máy in) sử dụng trình duyệt với giao thức HTTPS, nó có thể sử dụng OpenSSL. Và các máy sao chép và máy in mạng thường được kết nối bằng các tài khoản dịch vụ thư mục. Một số thậm chí còn có thể truy cập qua Internet. Khi đó, quan điểm của bạn có thể phải thay đổi.

Bước 4: Nâng cấp những gì có thể

Nếu có thể, hãy cài đặt phiên bản an toàn của OpenSSL. Một cách khác là biên dịch lại phiên bản không an toàn hiện có với tùy chọn -DOPENSSL_NO_HeartbeatS.

Bước 5: Tạo một cặp khóa mới

Luôn luôn có khả năng rằng khóa bí mật của OpenSSL đã bị xâm phạm bởi một cuộc tấn công thành công trước đó nhắm vào lỗ hổng Heartbleed. Nếu bạn có kế hoạch tiếp tục sử dụng phiên bản an toàn của OpenSSL, hãy chắc chắn rằng bạn sẽ tạo ra một cặp khóa bí mật/công khai (private/public) mới, và bắt đầu sử dụng từ lúc này.

Bước 6: Giảm thiểu nguy cơ đối với các phiên bản không an toàn còn lại

Có thể sẽ có trường hợp mà bạn không thể nâng cấp phiên bản không an toàn của OpenSSL. Nó có thể là hệ thống vô cùng quan trọng mà không thể nâng cấp nếu không trải qua một quy trình kiểm soát thay đổi cực lớn, hoặc nó có thể là một thiết bị hoặc phần mềm mà bạn không có quyền truy cập.

Trong những trường hợp đó, để ngăn chặn những kẻ xấu khai thác các phiên bản không an toàn, bạn cần sử dụng bất kỳ cơ chế lọc nào có thể (như IP whitelist, domain whitelist, tường lửa, router, và VLAN).

Việc ngăn các bên không được phép truy cập dịch vụ sử dụng OpenSSL của bạn là một điều tốt cần làm sau khi bạn đã xác định được các phiên bản không an toàn. Trên thực tế, đó là một ý tưởng tuyệt vời cần thực hiện đối với một lỗ hổng đã biết.

Đối với những hệ thống ngoài tầm kiểm soát của bạn

Bạn có thể tìm thấy nhiều hệ thống liên quan đến bạn, hoặc trong hệ thống nội bộ hoặc bên ngoài, mà cần khắc phục. Liên hệ với chủ sở hữu hoặc các nhà cung cấp của chúng, cho họ biết bạn đã xác định một phiên bản không an toàn, và hỏi họ phương pháp khắc phục.

Có lẽ bạn đang không trực tiếp quản lý tất cả các trang web bên ngoài mà liên quan đến công ty của bạn. Xem xét việc thiết lập cơ chế lọc các kết nối SSL/TLS đến (hoặc thậm chí cả kết nối đi) để tạo ra một danh sách dịch vụ OpenSSL tiềm tàng khác. Các liên kết mà tôi đã đưa ra ở trên đã bao gồm thông tin cho phép bạn kiểm tra các trang web trên Internet.

Lưu ý: Luật pháp không xác định rõ ràng về việc "kiểm tra" là hợp pháp hay không. Chỉ kiểm tra các trang web mà bạn sở hữu hoặc chắc chắn bạn đang được phép về mặt pháp lý để kiểm tra.

Phá hủy và xây dựng lại

Hầu hết các chuyên gia giả định sự xâm phạm hoàn toàn trên mọi hệ thống OpenSSL không an toàn, và thay đổi tất cả các bí mật liên quan đến hệ thống bị xâm phạm. Điều này có nghĩa là thay đổi tất cả thông tin đăng nhập được lưu trữ hoặc truy cập thông qua hệ thống, và định liệu những gì có nghĩa là nếu dữ liệu trên đó bị xâm phạm, bị đánh cắp, hoặc bị pha trộn.

Nếu bạn gặp phải tình huống này, bạn có thể mong muốn xây dựng lại hệ thống từ đầu. Khi bất kỳ hệ thống bị xâm phạm mà bạn có thể không bao giờ chắc chắn rằng hệ điều hành bên dưới không bị sửa đổi mà cho phép cài đặt một backdoor thường trực.

Nó còn tồi tệ hơn nhiều

Đáng buồn thay, có khả năng là hàng triệu các bản cài không an toàn chưa được vá và chưa được giảm thiểu nguy cơ trong thế giới thực. Chắc chắn, chúng ta sẽ sửa chữa những gì chúng ta tìm thấy và được phép khắc phục. Nhưng rất nhiều hệ thống sử dụng phiên bản OpenSSL không an toàn có thể thuộc sở hữu và được điều hành bởi những người chưa hề nghe nói về lỗ hổng Heartbleed, và sẽ không nghe nói về nó. Những thiết bị và hệ thống được cài đặt bởi người khác, và thậm chí các thiết bị họ mua và được cài đặt mà không có thông tin về việc sử dụng OpenSSL, ít hơn nhiều cho dù nó không an toàn.

Router không dây của bạn đã cài đặt như thế nào ở nhà?  TV ưa thích mới như thế nào? Bạn có thể kết nối với nó bằng giao thức HTTPS không? Nếu có thể, nó có thể chạy một máy chủ web mã nguồn mở và máy chủ web mã nguồn mở đó có thể sử dụng OpenSSL. Có lẽ một cơ may duy nhất, cho hàng triệu người, là thiết bị hỗ trợ OpenSSL có thể được biên dịch hai năm trước, và vì vậy chúng sẽ không tồn tại lỗ hổng Heartbeat. Tất nhiên, nếu không được cập nhật gì trong hai năm qua, chúng có khả năng tồn tại hàng ngàn lỗ hổng khác, nhưng ít nhất không phải tất cả được thảo luận công khai tại thời điểm này.

Hãy làm việc chăm chỉ hết sức để đảm bảo rằng bạn và công ty của bạn đã được che chắn. Đây không chỉ là về các trang web bên ngoài Internet. Những kẻ xấu thường xuyên thăm dò mạng nội bộ và họ sẽ nỗ lực tìm kiếm phiên bản không an toàn của OpenSSL .