Bagaimana cara saya pulih dari bug Heartbleed di OpenSSL?

CVE-2014-0160 alias Heartbleed adalah kerentanan di OpenSSL. Itu terlihat menakutkan.

Bagaimana saya menentukan apakah saya terpengaruh?

Jika saya terpengaruh, apa yang harus saya lakukan? Rupanya upgrade tidak cukup.

Kerentanan ini memiliki dampak potensial yang tinggi karena jika sistem Anda telah diserang, ia akan tetap rentan bahkan setelah ditambal, dan serangan mungkin tidak meninggalkan jejak dalam log. Kemungkinan bahwa jika Anda menambal dengan cepat dan Anda bukan target profil tinggi, tidak ada yang akan menyerang Anda, tetapi sulit untuk memastikan.

Apakah saya rentan?

Versi buggy dari OpenSSL

Perangkat lunak kereta adalah perpustakaan OpenSSL 1.0.1 hingga 1.0.1f , dan OpenSSL 1.0.2 hingga beta1. Versi yang lebih lama (0.9.x, 1.0.0) dan versi di mana bug telah diperbaiki (1.0.1g dan seterusnya, 1.0.2 beta 2 dan seterusnya) tidak terpengaruh. Ini adalah bug implementasi, bukan cacat dalam protokol, jadi hanya program yang menggunakan pustaka OpenSSL yang terpengaruh.

Anda dapat menggunakan alat baris perintah openssl version -auntuk menampilkan nomor versi OpenSSL. Perhatikan bahwa beberapa distribusi port memperbaiki bug ke rilis sebelumnya; jika log perubahan paket Anda menyebutkan perbaikan bug Heartbleed, tidak apa-apa, bahkan jika Anda melihat versi seperti 1.0.1f. Jika openssl version -amenyebutkan tanggal pembuatan (bukan tanggal di baris pertama) 2014-04-07 sekitar malam UTC atau lebih baru, Anda harus baik-baik saja. Perhatikan bahwa paket OpenSSL mungkin memiliki 1.0.0di nya nama meskipun versi adalah 1.0.1 ( 1.0.0mengacu pada kompatibilitas biner).

Aplikasi yang terpengaruh

Eksploitasi dilakukan melalui aplikasi yang menggunakan pustaka OpenSSL untuk mengimplementasikan koneksi SSL . Banyak aplikasi menggunakan OpenSSL untuk layanan kriptografi lainnya, dan itu tidak masalah: bug tersebut dalam implementasi fitur tertentu dari protokol SSL, "detak jantung".

Anda mungkin ingin memeriksa program mana yang ditautkan dengan perpustakaan di sistem Anda. Pada sistem yang menggunakan dpkg dan apt (Debian, Ubuntu, Mint, ...), perintah berikut mencantumkan paket yang diinstal selain pustaka yang menggunakan libssl1.0.0(paket yang terpengaruh):

apt-cache rdepends libssl1.0.0 | tail -n +3 |
xargs dpkg -l 2>/dev/null | grep '^ii' | grep -v '^ii  lib'

Jika Anda menjalankan beberapa perangkat lunak server yang ada dalam daftar ini dan mendengarkan koneksi SSL, Anda mungkin terpengaruh. Ini menyangkut server web, server email, server VPN, dll. Anda akan tahu bahwa Anda telah mengaktifkan SSL karena Anda harus membuat sertifikat, baik dengan mengirimkan permintaan penandatanganan sertifikat ke otoritas sertifikasi atau dengan membuat sendiri tanda tangan Anda sertifikat. (Ada kemungkinan bahwa beberapa prosedur instalasi telah menghasilkan sertifikat yang ditandatangani sendiri tanpa Anda sadari, tetapi itu umumnya dilakukan hanya untuk server internal, bukan untuk server yang terpapar ke Internet.) kecuali log Anda tidak menunjukkan koneksi sejak pengumuman pada 2014-04-07. (Ini mengasumsikan bahwa kerentanan tidak dieksploitasi sebelum diumumkan.) Jika server Anda hanya diekspos secara internal,

Perangkat lunak klien hanya terpengaruh jika Anda menggunakannya untuk terhubung ke server jahat. Jadi, jika Anda terhubung ke penyedia email Anda menggunakan IMAPS, Anda tidak perlu khawatir (kecuali jika penyedia itu diserang - tetapi jika demikian mereka seharusnya memberi tahu Anda), tetapi jika Anda meramban situs web acak dengan peramban yang rentan, Anda mungkin perlu khawatir. Sejauh ini tampaknya kerentanan tidak dieksploitasi sebelum ditemukan, jadi Anda hanya perlu khawatir jika Anda terhubung ke server jahat sejak 2014-04-08.

Program-program berikut ini tidak terpengaruh karena mereka tidak menggunakan OpenSSL untuk mengimplementasikan SSL:

• SSH (protokolnya bukan SSL)
• Chrome / Chromium ( menggunakan NSS )
• Firefox (menggunakan NSS) (setidaknya dengan Firefox 27 di Ubuntu 12.04, tetapi tidak dengan semua build?

Apa dampaknya?

Bug ini memungkinkan setiap klien yang dapat terhubung ke server SSL Anda untuk mengambil sekitar 64 kB memori dari server sekaligus. Klien tidak perlu diautentikasi dengan cara apa pun. Dengan mengulangi serangan, klien dapat membuang berbagai bagian memori dalam upaya berturut-turut. Ini berpotensi memungkinkan penyerang untuk mengambil data apa saja yang ada di memori proses server, termasuk kunci, kata sandi, cookie, dll.

Salah satu bagian penting dari data yang dapat diambil oleh penyerang adalah kunci privat SSL server. Dengan data ini, penyerang dapat menyamar sebagai server Anda.

Bug ini juga memungkinkan server apa pun yang terhubung dengan klien SSL Anda untuk mengambil sekitar 64 kB memori dari klien sekaligus. Ini mengkhawatirkan jika Anda menggunakan klien yang rentan untuk memanipulasi data sensitif dan kemudian terhubung ke server yang tidak terpercaya dengan klien yang sama. Skenario serangan di sisi ini secara signifikan lebih kecil kemungkinannya daripada di sisi server.

Perhatikan bahwa untuk distribusi tipikal, tidak ada dampak keamanan pada distribusi paket karena integritas paket bergantung pada tanda tangan GPG, bukan pada transportasi SSL.

Bagaimana cara saya memperbaiki kerentanan?

Remediasi server yang terpapar

1. Jadikan semua server yang terpengaruh offline. Selama mereka berjalan, mereka berpotensi membocorkan data penting.

2. Tingkatkan paket perpustakaan OpenSSL . Semua distribusi harus sudah diperbaiki sekarang (baik dengan 1.0.1g, atau dengan tambalan yang memperbaiki bug tanpa mengubah nomor versi). Jika Anda dikompilasi dari sumber, tingkatkan ke 1.0.1g atau lebih tinggi. Pastikan semua server yang terpengaruh dihidupkan ulang.
   Di Linux, Anda dapat memeriksa apakah proses yang berpotensi terkena dampak masih berjalangrep 'libssl.*(deleted)' /proc/*/maps

3. Buat kunci baru . Ini diperlukan karena bug tersebut memungkinkan penyerang mendapatkan kunci privat yang lama. Ikuti prosedur yang sama yang Anda gunakan pada awalnya.

   • Jika Anda menggunakan sertifikat yang ditandatangani oleh otoritas sertifikasi, kirimkan kunci publik baru Anda ke CA. Ketika Anda mendapatkan sertifikat baru, instal di server Anda.
   • Jika Anda menggunakan sertifikat yang ditandatangani sendiri, pasang di server Anda.
   • Bagaimanapun, pindahkan kunci dan sertifikat lama dari jalan (tapi jangan menghapusnya, hanya memastikan mereka tidak digunakan lagi).

4. Sekarang Anda memiliki kunci baru tanpa kompromi, Anda dapat membawa server Anda kembali online .

5. Cabut sertifikat lama.

6. Penilaian kerusakan : semua data yang ada dalam memori suatu proses yang melayani koneksi SSL mungkin berpotensi bocor. Ini dapat mencakup kata sandi pengguna dan data rahasia lainnya. Anda perlu mengevaluasi apa data ini mungkin.

   • Jika Anda menjalankan layanan yang memungkinkan otentikasi kata sandi, maka kata sandi pengguna yang terhubung sejak sedikit sebelum kerentanan diumumkan harus dianggap dikompromikan. Periksa log Anda dan ubah kata sandi setiap pengguna yang terpengaruh.
   • Juga membatalkan semua cookie sesi, karena mungkin telah dikompromikan.
   • Sertifikat klien tidak dikompromikan.
   • Data apa pun yang dipertukarkan sejak sedikit sebelum kerentanan mungkin tetap ada dalam memori server dan karenanya mungkin telah bocor ke penyerang.
   • Jika seseorang telah mencatat koneksi SSL lama dan mengambil kunci server Anda, mereka sekarang dapat mendekripsi transkrip mereka. (Kecuali PFS dipastikan - jika Anda tidak tahu, itu bukan.)

Remediasi dalam kasus lain

Server yang hanya mendengarkan di localhost atau di intranet hanya dianggap terbuka jika pengguna yang tidak dipercaya dapat terhubung ke mereka.

Dengan klien, hanya ada skenario langka di mana bug dapat dieksploitasi: eksploitasi akan mengharuskan Anda menggunakan proses klien yang sama untuk

1. memanipulasi data rahasia (mis. kata sandi, sertifikat klien, ...);
2. dan kemudian, dalam proses yang sama, terhubung ke server jahat melalui SSL.

Jadi misalnya klien email yang hanya Anda gunakan untuk menyambung ke penyedia email Anda (tidak sepenuhnya tidak dipercaya) bukanlah masalah (bukan server jahat). Menjalankan wget untuk mengunduh file bukan masalah (tidak ada data rahasia yang bocor).

Jika Anda melakukannya antara 2014-04-07 malam UTC dan memutakhirkan pustaka OpenSSL Anda, pertimbangkan data apa pun yang ada di memori klien untuk dikompromikan.

Referensi

• The Heartbleed Bug (oleh salah satu dari dua tim yang secara independen menemukan bug)
• Bagaimana tepatnya cara kerja detak jantung OpenSSL TLS (Heartbleed) bekerja?
• Apakah Heartbleed berarti sertifikat baru untuk setiap server SSL?
• Heartbleed: Apa itu dan apa saja pilihan untuk menguranginya?

Untuk menguji apakah Anda rentan, buka di sini: http://filippo.io/Heartbleed/

Jika Anda menemukan Anda rentan memperbarui openssldan mulai ulang server web Anda.

Tidak ada cara untuk pulih dari bug ini. Simpan semua log, mereka akan diperlukan jika seseorang benar-benar menyadari kerentanan sebenarnya ada sebelum diumumkan