Làm cách nào để vá lỗi Heartbleed (CVE-2014-0160) trong OpenSSL?

Cho đến hôm nay, một lỗi trong OpenSSL đã được tìm thấy ảnh hưởng đến các phiên bản 1.0.1thông qua 1.0.1f(bao gồm) và 1.0.2-beta.

Kể từ Ubuntu 12.04, tất cả chúng ta đều dễ bị lỗi này. Để vá lỗ hổng này, người dùng bị ảnh hưởng nên cập nhật lên OpenSSL 1.0.1g.

Làm thế nào mọi người dùng bị ảnh hưởng có thể áp dụng bản cập nhật này ngay bây giờ ?

Các bản cập nhật bảo mật có sẵn cho 12.04, 12.10, 13.10 và 14.04, xem Thông báo bảo mật Ubuntu USN-2165-1 .

Vì vậy, trước tiên bạn cần áp dụng các bản cập nhật bảo mật có sẵn, ví dụ bằng cách chạy

sudo apt-get update
sudo apt-get upgrade

từ dòng lệnh.

Đừng quên khởi động lại các dịch vụ (HTTP, SMTP, v.v.) sử dụng phiên bản OpenSSL bị ảnh hưởng, nếu không bạn vẫn dễ bị tổn thương. Xem thêm Heartbleed: Nó là gì và các tùy chọn để giảm thiểu nó là gì? trên Serverfault.com.

Lệnh sau hiển thị (sau khi nâng cấp) tất cả các dịch vụ cần được khởi động lại:

sudo find /proc -maxdepth 2 -name maps -exec grep -HE '/libssl\.so.* \(deleted\)' {} \; | cut -d/ -f3 | sort -u | xargs --no-run-if-empty ps uwwp

Sau đó, bạn cần tạo lại tất cả các khóa SSL của máy chủ , sau đó đánh giá xem các khóa của bạn có bị rò rỉ hay không, trong trường hợp đó, kẻ tấn công có thể đã lấy thông tin bí mật từ máy chủ của bạn.

Lỗi được gọi là Heartbleed .

Tôi có dễ bị tổn thương không?

Nói chung, bạn bị ảnh hưởng nếu bạn chạy một số máy chủ mà bạn đã tạo khóa SSL tại một số điểm. Hầu hết người dùng cuối không bị ảnh hưởng (trực tiếp); ít nhất Firefox và Chrome không sử dụng OpenSSL. SSH không bị ảnh hưởng. Việc phân phối các gói Ubuntu không bị ảnh hưởng (nó phụ thuộc vào chữ ký GPG).

Bạn dễ bị tổn thương nếu bạn chạy bất kỳ loại máy chủ nào sử dụng phiên bản OpenSSL 1.0 chàng1.0.1f (ngoại trừ các phiên bản khóa học đã được vá từ khi lỗi được phát hiện). Các phiên bản Ubuntu bị ảnh hưởng là 11.10 một chiều cho đến trước 14.04 bản phát hành đáng tin cậy. Đó 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. Nếu bạn có một chương trình được liên kết với phiên bản OpenSSL 0.9.x cũ, thì nó không bị ảnh hưởng. Chỉ các chương trình sử dụng thư viện OpenSSL để thực hiện giao thức SSL bị ảnh hưởng; các chương trình sử dụng OpenSSL cho những thứ khác không bị ảnh hưởng.

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 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ộ bên trong, việc bạn có cần thay đổi khóa hay không sẽ phụ thuộc vào các biện pháp bảo mật khác được áp 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ủ. 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.

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àm cách nào để khôi phục trên máy chủ?

1. 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.

2. Nâng cấp libssl1.0.0gói và đảm bảo rằng tất cả các máy chủ bị ảnh hưởng được khởi động lại.
   Bạn có thể kiểm tra xem các tiến trình bị ảnh hưởng có còn chạy với libssl `` grep 'không. (đã xóa) '/ Proc / / maps`

3. 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 của bạn đến 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).

4. 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 .

5. Thu hồi các chứng chỉ cũ.

6. Đá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. (Trước đây một chút, vì mật khẩu có thể vẫn chưa được sử dụng trong bộ nhớ trong một thời gian.) 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 nào.
   • 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.)

Làm thế nào để tôi phục hồi trên một khách hàng?

Chỉ có một vài tình huống trong đó các ứng dụng khách bị ảnh hưởng. Vấn đề ở phía máy chủ là bất kỳ ai cũng có thể kết nối với máy chủ và khai thác lỗi. Để khai thác một khách hàng, phải đáp ứng ba điều kiện:

• Chương trình máy khách đã sử dụng phiên bản lỗi của thư viện OpenSSL để thực hiện giao thức SSL.
• Máy khách được kết nối với một máy chủ độc hại. (Vì vậy, ví dụ, nếu bạn kết nối với nhà cung cấp email, đây không phải là vấn đề đáng lo ngại.) Điều này đã xảy ra sau khi chủ sở hữu máy chủ nhận thức được lỗ hổng, vì vậy có lẽ là sau 2014-04-07.
• Quá trình máy khách có dữ liệu bí mật trong bộ nhớ không được chia sẻ với máy chủ. (Vì vậy, nếu bạn vừa chạy wgetđể tải xuống một tệp, không có dữ liệu nào bị 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 quy trình khách hàng sẽ bị xâm phạm.

Người giới thiệu

• Lỗi Heartbleed (do một trong hai đội phát hiện ra lỗi độc lập)
• Chính xác thì khai thác nhịp tim OpenSSL TLS (Heartbleed) hoạt động như thế nào?
• Heartbleed có nghĩa là chứng chỉ mới cho mọi máy chủ SSL không?
• Heartbleed: Nó là gì và các tùy chọn để giảm thiểu nó là gì?

Để xem phiên bản OpenSSL nào được cài đặt trên Ubuntu chạy:

dpkg -l | grep openssl

Nếu bạn thấy đầu ra phiên bản sau, nên bao gồm bản vá cho CVE-2014-0160.

ii  openssl      1.0.1-4ubuntu5.12      Secure Socket Layer (SSL)...

Nhìn vào https://launchpad.net/ubfox/+source/openssl/1.0.1-4ubfox5.12 , nó cho thấy loại lỗi nào đã được sửa:

...
 SECURITY UPDATE: memory disclosure in TLS heartbeat extension
    - debian/patches/CVE-2014-0160.patch: use correct lengths in
      ssl/d1_both.c, ssl/t1_lib.c.
    - CVE-2014-0160
 -- Marc Deslauriers <email address hidden>   Mon, 07 Apr 2014 15:45:14 -0400
...

Nếu kho apt-get của bạn không chứa bất kỳ phiên bản OpenSSL nào được biên dịch trước , vì vậy chỉ cần tải xuống các nguồn từ trang web chính thức và biên dịch nó.

Bên dưới dòng lệnh đơn để biên dịch và cài đặt phiên bản openssl cuối cùng.

curl https://www.openssl.org/source/openssl-1.0.1g.tar.gz | tar xz && cd openssl-1.0.1g && sudo ./config && sudo make && sudo make install

Thay thế tệp nhị phân openssl cũ bằng tệp mới thông qua liên kết tượng trưng.

sudo ln -sf /usr/local/ssl/bin/openssl `which openssl`

Bạn là tất cả tốt!

# openssl version should return
openssl version
OpenSSL 1.0.1g 7 Apr 2014

Cf bài blog này .

Lưu ý: Như đã nêu trong bài đăng trên blog, cách giải quyết này sẽ không khắc phục "Nginx và máy chủ Apache phải được biên dịch lại với các nguồn openSSL."

Đối với những người không muốn thực hiện nâng cấp gói toàn máy chủ. Tôi đã đọc một loạt các hướng dẫn này ngày hôm nay và apt-get upgrade openssl=== apt-get upgradeđiều này sẽ áp dụng tất cả các bản sửa lỗi bảo mật được yêu cầu bởi máy của bạn. Thật tuyệt vời, trừ khi bạn rõ ràng đang dựa vào một phiên bản gói cũ ở đâu đó.

Đây là hành động tối thiểu cần có trên Ubuntu 12.04 LTS chạy Apache 2:

• Tới địa chỉ này và chứng minh bạn có lỗ hổng. Bạn nên sử dụng ĐỊA CHỈ NGOẠI TRỪ TRỰC TIẾP CỦA MÁY CHỦ WEB CỦA BẠN. Nếu bạn sử dụng bộ cân bằng tải (ví dụ ELB), bạn có thể không liên hệ trực tiếp với máy chủ web của mình.

• Chạy 1 lớp lót sau để nâng cấp các gói và khởi động lại. Có, tôi đã thấy tất cả các hướng dẫn nói rằng bạn nên có dấu thời gian muộn hơn ngày 4 tháng 4 năm 2014, điều này dường như không đúng với tôi.

  Cập nhật apt-get && apt-get install openssl libssl1.0.0 && /etc/init.d/apache2 khởi động lại

• Đảm bảo bạn đã cài đặt các phiên bản gói phù hợp và kiểm tra lỗ hổng máy chủ web của bạn một lần nữa.

Các gói chính như sau, tôi đã xác định thông tin này bằng cách sử dụng lệnh bên dưới sau đó chỉnh sửa hành trình (bạn không cần biết nhiều về trạng thái của các máy của tôi).

$ dpkg -l | grep ssl

ii  libssl-dev                       1.0.1-4ubuntu5.12          SSL development libraries, header files and documentation
ii  libssl1.0.0                      1.0.1-4ubuntu5.12          SSL shared libraries
ii  openssl                          1.0.1-4ubuntu5.12          Secure Socket Layer (SSL)* binary and related cryptographic tools

1.0.1-4ubuntu5.12KHÔNG nên chứa lỗ hổng. Đảm bảo đây là trường hợp một lần nữa vào trang web bên dưới và kiểm tra máy chủ web của bạn.

http://filippo.io/Heartbleed/

Tôi nhận thấy nhiều người bình luận ở đây cần được giúp đỡ khẩn cấp. Họ đang làm theo hướng dẫn, nâng cấp và khởi động lại, và vẫn dễ bị tổn thương khi sử dụng một số trang web thử nghiệm.

Bạn phải kiểm tra để đảm bảo rằng bạn không có các gói bị giữ như libssl.

:~$ sudo apt-get upgrade -V
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
  libssl-dev (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  libssl1.0.0 (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  linux-image-virtual (3.2.0.31.34 => 3.2.0.60.71)
  linux-virtual (3.2.0.31.34 => 3.2.0.60.71)
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.

Để nâng cấp những cái đó apt-mark unhold libssl1.0.0(ví dụ). Sau đó nâng cấp : apt-get upgrade -V. Sau đó, khởi động lại các dịch vụ bị ảnh hưởng.