Các quản trị viên website và máy chủ sẽ phải mất lượng thời gian, công sức và tiền bạc đáng kể để giảm thiểu tất cả các rủi ro an ninh liên quan đến Heartbleed, một trong những lỗ hổng bảo mật nghiêm trọng nhất gây nguy hiểm cho thông tin liên lạc mã hóa SSL trong những năm gần đây. Lỗ hổng bảo mật này được công khai tiết lộ vào hôm thứ Hai tuần qua, không phải là kết quả của điểm yếu mật mã trong giao thức TLS (Transport Layer Security) đang được sử dụng rộng rãi hoặc giao thức truyền thông SSL (Secure Sockets Layer), mà bắt nguồn từ một lỗi lập trình trong thư viện SSL/TLS phổ biến gọi là OpenSSL - vốn được sử dụng bởi nhiềy hệ điều hành khác nhau, phần mềm máy chủ web, trình duyệt, ứng dụng di động và thậm chí cả các thiết bị phần cứng và các hệ thống nhúng. Kẻ tấn công có thể khai thác lỗ hổng này để buộc các máy chủ sử dụng phiên bản OpenSSL 1.0.1 thông qua 1.0.1f để lộ thông tin từ không gian bộ nhớ riêng của họ. Thông tin đó có thể bao gồm dữ liệu bí mật như mật khẩu, khóa phiên TLS và khóa riêng lâu dài của máy chủ cho phép giải mã lưu lượng SSL trong quá khứ và tương lai được bắt từ máy chủ. Ở cái nhìn đầu tiên, đối phó với vấn đề này dường như là rất dễ dàng: cập nhật OpenSSL lên phiên bản vá hiện đã có sẵn cho hầu hết các hệ điều hành. Tuy nhiên, có khả năng khả năng rằng các lỗ hổng có thể bị khai thác bởi những kẻ tấn công vào thời điểm một máy chủ cụ thể đã được vá và khóa TLS bí mật của nó có thể đã bị xâm nhập. Mọi thứ lại đột nhiên phức tạp hơn. Điều đầu tiên mà chủ sở hữu trang web cần làm là xác định những người chịu trách nhiệm duy trì phần mềm OpenSSL trên máy chủ lưu trữ trang web của họ. "Nếu nó là một máy chủ chuyên dụng thì chủ của nó là người có trách nhiệm", các nhà nghiên cứu từ hãng bảo mật web Sucuri cho biết trong một bài blog của công ty. "Nếu bạn đang ở trên một nền tảng chia sẻ lưu trữ, hãy liên hệ với nhà cung cấp hosting để nhắc họ cập nhật các máy chủ". Sau khi cài đặt OpenSSL được vá trên máy chủ, các cuộc tấn công sẽ không còn có thể diễn ra. Thời điểm này là lúc để có được chứng nhận SSL mới và thu hồi chứng nhận cũ để đảm bảo rằng bất kỳ kẻ tấn công nào đã thu thập được thông tin cũ sẽ không thể giải mã được lưu lượng thông tin trong tương lai. "Khuyến cáo là các nhà khai thác máy chủ phải thu hồi và cấp lại các chứng nhận, bởi có nhiều khả năng các khóa bí mật có thể đã bị đánh cắp", Matthew Green - chuyên gia mã hóa và trợ lý giáo sư nghiên cứu tại Viện bảo mật thông tin trường Đại học Johns Hopkins ở Baltimore, cho biết. "Vấn đề là điều này cần có thời gian và tiền bạc. Tôi không ngạc nhiên nếu nhiều nhà khai thác máy chủ bỏ qua bước này". Chủ sở hữu trang web nên kiểm tra với các cơ quan chứng nhận (CA) đã cấp giấy chứng nhận SSL hiện có của họ về bất kỳ chi phí nào có thể phát sinh trong việc tham gia vào tái lập khóa bảo mật và cấp lại các chứng nhận. "Các dịch vụ trên nền tảng Trustwave SSL đã luôn bao gồm việc tái bản các chứng nhận miễn, chúng tôi không bao giờ tính phí cho việc cấp lại các mã khóa bảo mật và thay thế chứng nhận cho khách hàng", Brian Trzupek - Phó chủ tịch phụ trách quản lý danh tính và SSL tại Trustwave, cho biết. "Trong trường hợp cụ thể của lỗ hổng bảo mật Heartbleed trên OpenSSL, đã có một khối lượng lớn các khách hàng sử dụng tính năng tự động cấp lại các khóa bảo mật và chứng nhận trong cổng SSL của chúng tôi. Công cụ này hoàn toàn miễn phí và đã giúp khắc phục khá tốt các vấn đề của Heartbleed". Symantec, hãng đang điều hành một trong các tổ chức cấp chứng chỉ lớn nhất kể từ khi mua lại mảng kinh doanh SSL của VeriSign trong năm 2010, cho biết rằng công ty đã thực hiện các bước cần thiết để sửa lại hệ thống đang có sử dụng các phiên bản bị lỗi của OpenSSL. "Chúng tôi đang theo dõi tình hình thực tế và đã tái lập các mã khóa bảo mật cùng các loại chứng nhận trên máy chủ web sử dụng phiên bản bị ảnh hưởng của OpenSSL", đại diện Symantec cho biết. "Trong khi các chứng chỉ Symantec không bị ảnh hưởng vấn đề gì, chúng tôi sẽ nỗ lực giải quyết lỗi bảo mật OpenSSL này bằng việc cung cấp lại khóa bảo mật cho khách hàng hoàn toàn miễn phí". Việc đối phó với lỗ hổng OpenSSL này cũng có thể là một cơ hội tốt cho các quản vị viên website và máy chủ để xem xét lại cấu hình SSL/TLS của mình và chắc chắn rằng chúng đạt được những tiêu chuẩn mới nhất. "Một khi bạn phải động vào cấu hình máy chủ và tạo các chứng chỉ SSL mới, chúng tôi khuyên bạn cũng nên đánh giá lại các thiết lập hệ chứng chỉ và cấu hình máy chủ", các nhà nghiên cứu từ công ty bảo mật F-Secure cho biết trong một bài blog của hãng. "Heartbleed không phải là vấn đề duy nhất trong việc triển khai SSL/TLS, một giao thức kém, cơ chế yếu có thể nguy hiểm ngang ngửa như lỗi Heartbleed". Các quy trình thực hành Open Web Application Security Project's (OWASP) Transport Layer Protection Cheat Sheet và SSL/TLS Deployment Best Practices của Qualys SSL Labs sẽ là điểm khởi đầu tốt cho các website và máy chủ bị ảnh hưởng bởi Heartbleed. Đây cũng là thời điểm thích hợp để xem xét cấu hình TLS với Perfect Forward Secrecy (PFS), một quy trình bảo mật của DiffieHellman - DHE và ECDHE - vốn đã được sử dụng trên một số trang web lớn, bao gồm cả Google. PFS làm cho việc giải mã lưu lượng truy cập TLS trước đây trở thành không thể ngay cả khi khóa riêng của máy chủ bị đánh cắp và Heartbleed sẽ không thể gây ảnh hưởng đến các máy chủ đã được cấu hình PFS cho TLS. Tại thời điểm này, việc quản lý các vấn đề bảo mật là quan trọng hơn bao giờ hết. Hiện tại, tất cả các thông tin Heartbleed đều đã được công khai và bất cứ ai cũng có thể sử dụng nó để chống lại các máy chủ chưa vá lỗi OpenSSL và thay đổi chứng chỉ SSL. Nó có thể dễ dàng mất vài tuần hoặc vài tháng cho các nhà phát triển để triển khai chứng chỉ SSL mới, và ngay cả như vậy, các hệ thống thu hồi và cấp mới chứng nhận hiện nay đều không đáng tin cậy và kém phù hợp với các trang web hiện đại. Trong khi đó, các dữ liệu bạn gửi tại các máy chủ bị ảnh hưởng sẽ được mở để xem trộm và giả mạo ngay sau khi khóa riêng SSL của họ được tiếp xúc. Vì lỗ hổng bảo mật Heartbleed cũng có thể được sử dụng để ăn cắp mật khẩu từ bộ nhớ của máy chủ, quản trị viên trang web cần đánh giá và xem xét những mục mật khẩu có thể bị thay đổi, như là một biện pháp phòng ngừa. Trong một số trường hợp, có thể buộc hoặc ít nhất là tư vấn cho tất cả người dùng thay đổi mật khẩu của họ. Ngoài đặt lại mật khẩu, việc làm mất hiệu lực tất cả các yêu cầu cross-site giả mạo (CSRF) và thẻ OAuth, cũng như cookies cũng có thể là một ý tưởng tốt. Nếu bị đánh cắp từ bộ nhớ máy chủ hoặc từ lưu lượng thông tin, các thẻ token này có thể được sử dụng để truy cập trái phép vào tài khoản người dùng trên các trang web bị ảnh hưởng. Cuối cùng, điều cũng vô cùng quan trọng đối với các quản trị viên là hãy xem xét toàn bộ cơ sở hạ tầng web của họ. Toàn bộ, chứ không chỉ là các máy chủ web cá nhân, khi đánh giá tác động của lỗ hổng này. Ví dụ , ngay cả khi một máy chủ Web chạy IIS (Internet Information Services) trên Windows và không bị ảnh hưởng bởi lỗ hổng này vì IIS không sử dụng OpenSSL. Nhưng vẫn có thể có một máy chủ Nginx với OpenSSL chạy như một trung tâm cân bằng tải cho lưu lượng thông tin, được mã hóa như một proxy ngược ở phía trước máy chủ IIS. Lúc đó, dù chính máy chủ riêng không bị dính lỗi bảo mật, nhưng những thứ chạy song song với nó sẽ là một nguy cơ tiềm ẩn. Nguồn PC World VN
