Bagaimana cara menggunakan Internet saat Heartbleed diperbaiki?


119

Ada banyak situs yang saat ini tidak rentan, tapi saya tidak tahu apakah mereka berada rentan beberapa hari yang lalu.

Sebagai contoh:

  • twitter.com: Tidak rentan sekarang, tetapi sertifikat dari Rabu 05 Mar 00:00:00 UTC 2014
  • google.com: Tidak rentan sekarang, tetapi sertifikat dari Rabu 12 Maret 09:53:40 UTC 2014
  • bankofamerica.com: Tidak rentan saat ini, tetapi sertifikat dari Kamis 05 Des 00:00:00 UTC 2013

Apa yang saya lakukan? Tidak menggunakan ini sampai diterbitkan kembali? Bagaimana saya tahu bahwa mereka menerbitkan kembali sertifikat dengan kunci baru? Sepertinya saya bahkan tidak boleh masuk ke situs-situs ini untuk mengubah kata sandi saya karena tidak ada cara untuk mengetahui bahwa mereka adalah situs web yang sebenarnya.


4
Kemungkinan duplikat apa yang harus dilakukan pengguna akhir tentang Heartbleed? di security.stackexchange.com
Philipp

Jawaban:


201

Pembaruan 2014-04-11

Cloudflare menyiapkan tantangan untuk memverifikasi bahwa ekstraksi kunci privat sebenarnya dimungkinkan. Itu telah dilakukan dengan sekitar 100 ribu permintaan, dan memverifikasi ketakutan. Ini tidak lagi teoretis, tetapi terbukti . Anda dapat pergi ke sini untuk membacanya.

Juga, Bloomberg telah melaporkan bahwa NSA telah mengetahui tentang eksploitasi ini setidaknya selama dua tahun . Ini masuk akal karena NSA memiliki sumber daya untuk mempekerjakan analis yang tugas utamanya adalah menemukan exploit dalam perangkat lunak seperti ini. Sekarang kita tahu bahwa pemerintah AS telah mengeksploitasinya begitu lama, kemungkinan bahwa negara-negara lain telah mengetahui dan mengeksploitasinya.


TL; DR Perhatikan pengumuman dari organisasi mengenai status sistem mereka, ubah SEMUA kata sandi Anda, dan perhatikan penipuan / aktivitas mencurigakan di akun penting seperti perbankan atau sistem keuangan lainnya.

Untuk memahami mengapa situasinya sangat berbahaya, pertama-tama kita harus memahami apa sebenarnya serangan ini. CVE-2014-0160, AKA Heartbleed, adalah bug buffer overread yang memungkinkan penyerang mendapatkan memori hingga 64 kB dari server yang menjalankan versi OpenSSL yang rentan.

Kedengarannya sangat buruk. Bagaimana cara kerjanya dalam praktik

Anda benar, ini adalah kesalahan serius, tetapi kami akan kembali ke situ nanti. Sekarang mari kita bicara tentang mengapa exploit bekerja. Transport Layer Security (TLS) digunakan untuk mengamankan informasi oleh banyak aplikasi termasuk HTTP ( HTTPS ) atau untuk mengamankan SMTPjika diaktifkan misalnya. Dalam RFC 5246, yang menetapkan standar untuk TLS, ada fungsi yang dikenal sebagai detak jantung. Klien dan server mengirim beberapa data bolak-balik untuk menjaga koneksi tetap hidup sehingga dapat digunakan nanti. Sekarang dalam praktiknya klien akan mengirim beberapa data dan server hanya akan mengirimkannya kembali, dan semuanya hebat. Namun dalam versi OpenSSL yang terpengaruh tidak ada pemeriksaan untuk melihat apakah klien benar-benar mengirim jumlah data yang dikatakannya. Jadi jika saya mengirimnya 1 byte dan memberi tahu server bahwa saya benar-benar mengirimnya 64 kB maka ia akan dengan senang hati mengirim saya kembali 64 kB. Dari mana byte-byte lain itu berasal? Itulah kunci masalah di sana. OpenSSL akan mengirim Anda kembali 64 kB - 1 byte memori yang dapat diakses oleh proses dan yang awalnya tidak Anda kirim, tergantung tempat penyimpanan 1 byte Anda.bahan kunci pribadi¹ dan informasi yang didekripsi server untuk digunakan. Contohnya adalah: kata sandi, informasi kartu kredit, dan / atau PIN .

BAIK. Apa artinya itu bagi keamanan informasi? Jika Anda memahami cara kerja kriptografi asimetris maka Anda sudah tahu bahwa ini serius karena pengungkapan membuat enkripsi tidak lebih dari kebingungan. Ini berarti bahwa meskipun server mungkin ditambal dan tidak lagi bocor memori, sesi mungkin masih tidak aman. Ada kemungkinan bahwa ini dieksploitasi sebelum diketahui publik atau saat penambalan sedang berlangsung, tetapi saat ini tidak ada metode yang terbukti menunjukkan bahwa serangan terjadi. Ada kemungkinan bahwa aturan untuk IDS dapat tersedia, tetapi sampai sekarang bukan itu masalahnya. Aturan IDS telah dirilis . Itu sendiri sangat berbahaya, karena operator tidak tahu apakah kunci mereka masih aman.

Kami terpaksa mengasumsikan bahwa kunci telah bocor, artinya adalah mungkin bahwa semua yang Anda kirim melalui kabel dapat didekripsi oleh pihak ketiga. Satu-satunya cara untuk mengurangi ini adalah dengan membuat ulang kunci dan mendapatkan sertifikat baru diterbitkan kembali sementara yang lama dibatalkan. Sayangnya, ini membutuhkan waktu karena CA tidak diragukan lagi dibanjiri permintaan ini sekarang. Tetap ini meninggalkan kemungkinan untuk serangan man-in-the-middle , atau peluang phishing lainnya.

Kapan itu aman? Mengetahui kapan akan aman adalah pertanyaan yang sulit. Beberapa hal yang saya sarankan tonton adalah pengumuman publik yang menjelaskan bahwa bug telah ditambal di lingkungan mereka atau bahwa mereka tidak pernah rentan, karena mereka tidak pernah menggunakan versi yang terpengaruh. Ketika mereka telah mengumumkan bahwa mereka telah meningkatkan ke versi baru OpenSSL saya akan memastikan bahwa mereka menggunakan sertifikat baru yang ditandatangani setelah tanggal rilis publik dari eksploitasi yang 2014-04-07.

** Perhatikan bahwa lalu lintas yang direkam sebelumnya dapat didekripsi jika kunci pribadi kemudian bocor.

Apa yang bisa saya lakukan sebagai pengguna untuk melindungi diri saya sendiri

Untuk beberapa hari ke depan jika Anda dapat menghindari menggunakan situs-situs penting seperti perbankan online atau akses grafik medis online, saya sarankan Anda melakukannya. Jika Anda harus melakukannya, pahami bahwa sesi Anda berpotensi berisiko dan bersiaplah untuk menerima konsekuensi dari itu. Selain itu, setelah organisasi mengumumkan bahwa mereka tidak lagi rentan, Anda harus mengubah kata sandi Anda ; menggunakan pengelola kata sandi dapat membantu. Anda juga harus bersiap untuk mengubah atau memantau informasi lain yang Anda gunakan seperti detail bank atau nomor kartu kredit.

Pemberitahuan khusus kepada para aktivis

Apa pun yang menggunakan OpenSSL dapat terpengaruh, termasuk Tor . Ada kemungkinan bahwa pemerintah telah dapat menggunakan cacat ini sejak dimasukkan dalam rilis OpenSSL dari lebih dari dua tahun yang lalu karena mereka akan memiliki sumber daya yang luas yang diperlukan untuk mencari eksploitasi seperti ini, dan dengan demikian Anda harus siap bahwa informasi dapat tidak lagi bersifat pribadi.

** Perhatikan bahwa lalu lintas yang direkam sebelumnya dapat didekripsi jika kunci pribadi kemudian dibocorkan kecuali keamanan penerusan yang sempurna (PFS) diimplementasikan.

¹- Ada klaim bahwa ada kemungkinan kunci privat tidak ada di memori, tetapi pada saat yang sama ada klaim ekstraksi kunci yang berhasil. Pada titik ini tidak pasti sisi mana yang benar.


45
Sejauh ini, ini adalah teks yang paling informatif yang saya baca tentang serangan Heartbleed panas-gila-kritis baru ini (semua artikel / blog / posting berita lainnya hanya mengandung sedikit demi sedikit informasi). Pekerjaan yang baik :) .
Radu Murzea

4
Bagaimana kita tahu bahwa sertifikat baru dihasilkan menggunakan kunci baru?

3
Note that previously recorded traffic may be decrypted if the private key was later leaked. Tidak jika server menggunakan sandi dengan kerahasiaan maju.
Wes

2
@Apakah Anda benar bahwa PFS kemungkinan besar akan menjaga lalu lintas tetap aman. Saya mencoba untuk berjalan dalam garis menjelaskan situasi tanpa membingungkan orang. Sayangnya PFS tidak digunakan secara luas.
Jacob

6
Untuk meringkas what is heartbleed bug xkcd.com/1354
GoodSp33d

14

Risiko yang ditimbulkan oleh kerentanan ini sedang overhyped. Saya mengatakan ini karena ada NOL bukti bahwa kerentanan ini diketahui atau dieksploitasi sebelum dipublikasikan oleh para peneliti 2 hari yang lalu.

Biar saya jelaskan, sangat mendesak bahwa situs web yang rentan, terutama yang bertransaksi data sensitif di Internet, ditambal. Sama pentingnya bahwa tanda tangan untuk serangan dimasukkan ke IDS dan alat perlindungan malware. Di dalam IT, kita harus menanggapi kerentanan ini dengan prioritas tertinggi.

Karena itu, saya tidak merasa bahwa tingkat risiko yang terkait dengan kerentanan ini oleh pers publik dibenarkan.

Apa yang harus dilakukan individu untuk melindungi diri mereka sendiri? Jangan gunakan situs yang menjalankan versi OpenSSL yang rentan.

Sampai dan kecuali ada bukti bahwa kerentanan ini dieksploitasi, tindakan lebih lanjut tidak ada gunanya dan termotivasi oleh tidak lebih dari FUD. Anda tidak setuju? Pertimbangkan banyak kerentanan yang dirilis setiap bulan atau kuartal yang memungkinkan eksekusi kode arbitrer . Mereka yang memberi root penyerang atau tingkat sistem hak istimewa atau di mana penyerang kemudian bisa mendapatkannya melalui eskalasi hak istimewa menghadirkan risiko yang lebih atau lebih terhadap keamanan semua data yang ditangani oleh sistem yang rentan sebagaimana kerentanan ini hadirkan.

Dalam banyak kasus, kerentanan ini ditemukan oleh vendor perangkat lunak atau peneliti yang menginformasikan vendor. Vendor memproduksi tambalan dan melepaskannya ke pasar tanpa publikasi rincian kerentanan. Dalam beberapa kasus, detail diterbitkan dan eksploitasi dipublikasikan oleh komunitas keamanan untuk digunakan dalam alat pengujian. Kami tidak bereaksi terhadap banyak kerentanan ini dengan mengatakan, "Semua rahasia kami MUNGKIN telah diungkapkan!"

Jika ada bukti eksploitasi, kita harus bereaksi dengan tepat. Saya melihat risiko besar dalam reaksi berlebihan dari para peneliti yang mengumumkan kerentanan ini dan di media yang telah memperkuat perbincangan longgar para peneliti. Mereka menangis serigala.

- El viejo


9
Jawaban ini harus dipilih lebih banyak IMO. Ada banyak kerentanan yang diterbitkan setiap bulan yang memungkinkan orang untuk mencuri kunci pribadi server, dan tidak banyak keributan tentang mereka. Yang ini lebih serius daripada rata-rata karena di mana-mana OpenSSL, tetapi masih over-hyped.
alastair

2
"Sampai dan kecuali ada bukti bahwa kerentanan ini dieksploitasi." "Jika ada bukti eksploitasi, kita harus bereaksi dengan tepat." Anda banyak bicara tentang bukti eksploitasi. Namun salah satu hal yang menakutkan tentang bug Heartbleed adalah bahwa eksploitasi yang sukses tidak dapat terdeteksi setelah fakta (kecuali jika Anda menyimpan pesan detak jantung yang masuk secara penuh setiap saat selama-lamanya, dan bahkan saat itu tidak dijamin bahwa eksploitasi yang berhasil menyebabkan pelanggaran terhadap keamanan). Bagaimana Anda mengusulkan kami membangun setelah bukti fakta keberhasilan eksploitasi bug?
CVn

6
-1 karena penulis ini tidak benar-benar memahami sifat serangan saya tidak berpikir. Untuk satu, penyerang yang memiliki akses semacam ini akan bekerja sangat keras untuk merahasiakannya dan tidak membiarkan bukti intrusi mereka keluar. Bug seperti ini yang memotong keamanan sekitar setengah dari lalu lintas aman di internet sama sekali tidak menangis. Ini adalah masalah yang sangat serius menurut saya.
Tampilan elips

19
Saya menghargai Bruce Schneier, dalam hal keamanan IT. Mengutip posting blognya tentang kerentanan Heartbleed : "Bencana" adalah kata yang tepat. Pada skala 1 hingga 10, ini adalah 11 . Itu saja sudah cukup bagi saya untuk sangat tidak setuju dengan meremehkan masalah Anda.
abstrask

8
Pos ini harus diturunkan. Masalahnya BUKAN dilebih-lebihkan, itu adalah kegagalan besar OpenSSL, selain itu bahkan jika itu tidak digunakan sampai diumumkan secara publik, para pemain yang buruk pasti telah mengkompromikan situs-situs dengannya kemudian. Kemungkinan besar NSA juga mengetahui hal itu (tetapi ini tidak dapat dibuktikan). Ada teori-teori yang meyakinkan yang menunjukkan bahwa ini adalah kompromi yang disengaja meskipun penulis membantahnya.
davidgo

5

Tidak setiap situs web menggunakan pustaka OpenSSL untuk HTTPS (ada juga GnuTLS dan PolarSSL misalnya), dan tidak semua versi OpenSSL rentan (versi yang lebih lama tidak). Ini berarti ada peluang yang adil bahwa situs web yang Anda sebutkan tidak mengubah sertifikat karena mereka tidak perlu melakukannya. Hanya dengan melihat tanggal yang dikeluarkan sertifikat tidak cukup memberi tahu Anda.

Ada sejumlah alat dan situs yang dapat membantu Anda memeriksa apakah situs web rentan, misalnya: - http://filippo.io/Heartbleed - https://gist.github.com/mitsuhiko/10130454 - https: / /www.ssllabs.com/ssltest/

Sayangnya, seperti yang sudah Anda nyatakan, ini tidak memberi tahu Anda jika memang demikian. Saya khawatir masalah utama di sini adalah kepercayaan: tidak ada cara obyektif untuk memverifikasi pustaka SSL mana yang mereka gunakan dan gunakan tanpa informasi orang dalam. Anda harus berharap mereka melakukan apa yang perlu mereka lakukan (karena itu adalah hal yang benar, atau bahkan karena mereka takut penghinaan publik) dan jika mereka melakukannya Anda hanya bisa berharap mereka terbuka tentang hal itu.

Tentu saja, Anda selalu dapat menanyakan situs web ini jika terpengaruh, saya telah melihat sejumlah situs web yang mengeluarkan pernyataan publik tentang hal ini. Bertanya secara publik menggunakan media sosial seperti Twitter atau Facebook sering berhasil.

Jadi saran terbaik yang bisa saya berikan adalah saran umum: berhati-hatilah dengan apa yang Anda tinggalkan di internet dan situs web mana yang Anda percayai dengan informasi pribadi Anda.


3
menunggu untuk PolarSSL bug tak terelakkan muncul (itu adalah berikutnya dalam daftar ...)
strugee

1

Mengenai kunci pribadi yang terbuka, perlu ditambahkan bahwa, sementara seseorang mungkin dapat mendekripsi data dalam sesi terenkripsi, karena mereka sekarang memiliki kunci pribadi, mereka masih perlu memantapkan diri mereka sebagai pria di tengah-tengah sesi . Tidak sembarang orang di Internet dapat melakukan ini.

Pemahaman saya adalah bahwa mereka masih perlu mencegat lalu lintas baik dengan berada di spoofing LAN dan ARP lokal Anda atau mampu membajak / mengarahkan lalu lintas dengan mengiklankan rute palsu ke router Internet. Serangan seperti ini selalu dimungkinkan bahkan tanpa kerentanan ini.


2
Belum tentu benar dengan Heartbleed. Bug ada karena data (apa yang seharusnya dienkripsi) dapat diekspos dengan mengakses RAM. Karenanya, mereka tidak perlu mencegat / mengendus traffic untuk mengeksploitasi kerentanan ini. Namun, perlu ada beberapa perangkat lunak berbahaya yang diinstal pada server atau klien dan juga perlu akses yang tepat untuk mengakses RAM.
ub3rst4r

Tidak begitu. Itu bisa dikompromikan oleh serangan Man-In-The-Middle juga. Selanjutnya dump memori tidak hanya mempengaruhi sesi itu, adalah mungkin (tergantung pada isi blok memori) untuk melihat nama pengguna dan kata sandi yang tidak terenkripsi dari pengguna lain, di samping kunci pribadi untuk memfasilitasi decoding semua lalu lintas [melalui serangan MITM]
davidgo

Saya kira saya seharusnya sedikit lebih jelas bahwa saya terutama merujuk pada penggunaan kunci yang dikompromikan setelah server ditambal.
PeterJ

0

Anda dapat memasukkan URL untuk situs di LastPass Heartbleed Checker dan itu akan memberi tahu Anda apakah situs itu rentan atau tidak, dan ketika sertifikatnya diperbarui.

Ada juga ekstensi Chrome bernama Chromebleed yang akan memperingatkan Anda jika Anda mengunjungi situs yang terpengaruh oleh Heartbleed.

Mashable.com memiliki daftar situs terkenal, apakah mereka terpengaruh, dan apakah Anda harus mengubah kata sandi Anda. Menariknya, tidak ada situs di daftar Bank dan Pialang yang terkena dampak.



-1

Secara keseluruhan, saya akan mengatakan jangan biarkan paranoia menghampiri Anda. Secara realistis, hanya dapat mendekripsi lalu lintas dan memperoleh kata sandi Anda tidak sama dengan benar-benar melakukannya.

Jika Anda menggunakan otentikasi dua faktor (dan Anda harus) di situs-situs seperti Twitter, Facebook, Gmail, dan perbankan Anda, maka Anda seharusnya tidak terlalu khawatir, dan bahkan jika tidak, Anda mungkin baik-baik saja.

Jika Anda merasa perlu mengubah semua kata sandi Anda, Anda harus terus maju dan melakukannya di mana Anda merasa Anda membutuhkannya. Itu semua yang ada untuk itu, sungguh.


1
otentikasi dua faktor tidak akan menghentikan pihak jahat melakukan apa pun yang mungkin seputar eksploit ini. Saya tidak yakin alasan Anda mengemukakannya. Mendapatkan akses ke akun sosial Anda sebenarnya bukan urusan seseorang yang mungkin memanfaatkan eksploitasi ini di OpenSSL.
Ramhound

1
@ramhound yang saya sebutkan di komentar sebelum komentar dihapus, dua faktor membantu karena sekali situs memiliki sertifikat baru mengeluarkan kata sandi yang mungkin dimiliki penyerang tidak lagi berguna. Karena tidak ada gunanya mengubah kata sandi sampai setelah sertifikat baru dikeluarkan (dan server ditambal) apa yang Anda peroleh adalah pengamanan kembali akun secara instan dari kemungkinan kebocoran kredensial yang mungkin terjadi ketika penyerang memiliki kunci pribadi. Selain itu, twitter dan Facebook juga penting karena dapat digunakan sebagai sistem masuk tunggal untuk banyak situs web lain (termasuk yang saya percayai ini?)
Sirex

Kata sandi masih membantu karena orang menggunakan kata sandi yang sama, ya, bahkan orang yang menggunakan otentikasi 2-faktor. Selama penyerang pada dasarnya dapat membuang data sesi mereka dapat melakukan serangan MiTM terhadap Anda.
Ramhound

Ya, tetapi menggunakan kembali kata sandi adalah kegagalan tersendiri. Maksud saya adalah dua faktor yang membantu mengurangi keparahan dan umur panjang setelahnya, tetapi ya itu tidak akan membantu dengan bug aktual yang dieksploitasi.
Sirex

@ Sirex Sejauh yang saya tahu tidak ada situs yang saya masuki menggunakan dua faktor auth telah membatalkan cookie pada mesin saya. Ini tentu saja merupakan kegagalan pada bagian mereka, tetapi poin saya adalah, saat ini dua faktor auth bukan penyelamat. Seorang penyerang bisa dengan mudah mencegat cookie dan menggunakannya atas permintaan mereka sendiri. Selain itu, karena tidak ada cara untuk mengetahui apakah ada yang mengeksploitasi bug ini (bahkan untuk administrator sistem), asumsi HANYA aman adalah bahwa bug itu dieksploitasi. Saya tahu misalnya bahwa chase.com masih rentan hingga Rabu pagi. Tidak mungkin para penyerang melewatkan yang itu.
CrazyCasta
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.