The Heartbleed Bug adalah kerentanan yang serius dalam perpustakaan perangkat lunak yang terkenal di kriptografi OpenSSL. Kelemahan ini memungkinkan pencurian terhadap informasi yang dilindungi, dalam kondisi normal, dengan enkripsi SSL/TLS digunakan untuk mengamankan internet. SSL/TLS menyediakan keamanan dan privasi komunikasi melalui intrnet untuk aplikasi seperti web, email, IM, dan beberapa VPN.
The heartbleed bug memungkinkan setiap orang di internet dapat membaca memori system yang dilindungi oleh versi vurnerable pada perangkat lunak OpenSSL. Ini adalah kunci rahasia yang digunakan untuk mengidentifikasi penyedia layanan dan mengenkripsi lalu lintas, nama dan password pengguna dan konten sebenarnya. Hai ini memungkinkan para penyerang mengetahui rahasia komunikasi, pencurian data secara langsung dari layanan dan pengguna serta meniru layanan dan pengguna.
Apa yang bocor dalam praktek?
Kami telah menguji beberapa layanan kami sendiri dari perspektif penyerang. Kami mencoba menyerang diri sendiri dari luar tanpa meninggalkan jejak. Tanpa menggunakan informasi rahasia atau kredensial kami mampu mencuri kunci rahasia kami sendiri yang digunakan untuk sertifikat X.509, nama pengguna dan password. IM, email, dokumen bisnis yang penting dan komunikasi.
Bagaimana menghentikan kebocoran ini?
Selama versi vulnerable OpenSSL sedang digunakan, hal itu bisa disalahgunakan. OpenSSL yang sudah pasti telah dirilis dan sekarang telah disebarkan. Vendor system operasi dan distribusi, vendor alat, vendor software independen memperbaiki dan memberitahu para pengguna mereka. Penyedia layanan dan pengguna harus menginstall perbaikan seperti yang tersedia pada system operasi, peralatan jaringan dan perangkat lunak yang mereka gunakan.
Q & A
Apa CVE-2014-0160 itu?
CVE-2014-0160 acuan resmi pada bug ini. CVE (Common Vulnerabilities and Exposures) adalah standar keamanan informasi nama kerentanan yang dikelola oleh MITRE. Karena penemuan insiden duplikat CVE, CVE-2014-0346 yang ditugaskan kepada kami, tidak boleh digunakan, sejak orang lain secara independen go public dengan identifier CVE-2014-0160.
Mengapa disebut Heartbleed Bug?
Bug adalah implementasi OpenSSL dari TLS/DTLS (transport layer security protocols), heartbeat extension (RFC6520). Ketika dieksploitasi hal tersebut pada kebocoran isi memori dari server ke klien dan dari klien ke server.
Apa yang membuat Heartbleed Bug unik?
Bug dalam perangkat lunak tunggal atau perpustakaan yang datang dan pergi ditetapkan dengan versi baru. Namun bug ini telah meninggalkan sejumlah kunci pribadi dan rahasia lain yang terhubung ke Internet. Mengingat kemudahan eksploitasi dan serangan tanpa meninggalkan jejak maka harus ditanggapi dengan serius.
Apakah ini desain cacat pada spesifikasi protokol SSL / TLS?
Tidak. Ini merupakan masalah implementasi , yaitu kesalahan pemrograman di perpustakaan OpenSSL yang populer menyediakan layanan kriptografi seperti SSL / TLS untuk aplikasi dan layanan .
Apa yang bocor?
Enkripsi digunakan untuk melindungi rahasia yang dapat membahayakan privasi atau keamanan jika bocor. Dalam rangka mengkoordinasikan pemulihan dari bug ini kami telah mengklasifikasikan rahasia dalam empat kategori : 1 ) material kunci primer , 2 ) material kunci sekunder dan 3 ) konten yang dilindungi dan 4 ) jaminan .
Apa yang bocor dari material kunci primer dan bagaimana memulihkannya?
Ini adalah permata mahkota , kunci enkripsi itu sendiri . Bocoran kunci rahasia memungkinkan penyerang untuk mendekripsi lalu lintas masa lalu dan masa depan untuk layanan yang dilindungi dan untuk menyamar sebagai layanan apapun. Perlindungan yang diberikan oleh enkripsi dan tanda tangan di sertifikat X.509 dapat dilewati. Pemulihan dari kebocoran ini membutuhkan tambalan kerentanan , pencabutan kunci dan penerbitan kembali dan pendistribusian kunci baru . Bahkan dengan melakukan semua ini masih akan meninggalkan lalu lintas yang dicegat oleh penyerang di masa lalu dan masih rentan terhadap dekripsi . Semua ini harus dilakukan oleh pemilik layanan.
Apa yang bocor dari material kunci sekunder dan bagaimana memulihkannya?
Ini adalah contoh kredensial pengguna ( nama pengguna dan password ) yang digunakan dalam layanan yang rentan . Pemulihan dari kebocoran ini membutuhkan pemilik layanan pertama untuk memulihkan kepercayaan ke layanan tersebut sesuai dengan langkah-langkah yang dijelaskan di atas. Setelah pengguna ini dapat mulai mengubah password mereka dan kunci enkripsi yang mungkin sesuai dengan petunjuk dari pemilik layanan yang telah dikompromikan . Semua kunci sesi dan cookie session harus hangus dan dianggap telah dikompromikan.
Apa yang bocor dari konten yang dilindungi dan bagaimana memulihkannya?
Ini adalah konten yang sebenarnya ditangani oleh layanan vulnerable. Ini mungkin rincian pribadi atau keuangan, komunikasi pribadi seperti email atau pesan instan , dokumen atau apa pun yang layak dilindungi oleh enkripsi . Hanya pemilik layanan akan dapat memperkirakan kemungkinan apa yang telah bocor dan mereka harus memberitahukan pengguna mereka. Yang paling penting adalah untuk memulihkan kepercayaan terhadap materi kunci materi primer dan sekunder seperti yang di deskripsikan di atas. Ini aman digunakan oleh layanan yang dikompromikan di masa depan.
Apa jaminan dari kebocoran dan bagaimana memulihkannya?
Jaminan kebocoran adalah rincian lain yang telah terkena penyerang dalam isi memori yang bocor. Hal ini mungkin berisi rincian teknis seperti alamat memori dan tindakan pengamanan seperti kenari digunakan untuk melindungi terhadap serangan overflow. Ini hanya memiliki nilai kontemporer dan akan kehilangan nilai mereka kepada penyerang ketika OpenSSL telah diupgrade ke versi tetap.
Pemulihan terdengar sulit, apakah ada jalan pintas ?
Setelah melihat apa yang kita lihat dengan " menyerang " diri sendiri , dengan mudah , kami memutuskan hal ini dengan serius . Kami telah berusaha menambal layanan penting kita sendiri dan berurusan dengan kompromi material kunci primer dan sekunder kita . Ini semua bukan yang pertama kali kami temukan dan hal ini bisa saja sudah dimanfaatkan di alam liar.
Bagaimana sertifikat pencabutan dan penerbitan kembali bekerja dalam prakteknya ?
Jika Anda adalah penyedia layanan yang telah menandatangani sertifikat Anda dengan Certificate Authority ( CA ) . Anda perlu memeriksa CA Anda bagaimana kunci yang dikompromikan dapat dicabut dan sertifikat baru diterbitkan kembali untuk kunci baru. Beberapa CA melakukan hal ini secara gratis , beberapa mungkin terkena biaya .
Apakah saya terkena bug ?
Anda mungkin akan terpengaruh baik secara langsung maupun tidak langsung . OpenSSL adalah open source library kriptografi yang terpopular dan pelaksanaan TLS ( transport layer security ) digunakan untuk mengenkripsi lalu lintas di Internet . Situs sosial Anda yang populer, situs perusahaan Anda , situs commerce , situs hobi , situs perangkat lunak atau bahkan dari situs yang dijalankan oleh pemerintah Anda mungkin menggunakan OpenSSL yang rentan . Banyak layanan online menggunakan TLS untuk mengidentifikasi diri mereka kepada Anda dan melindungi privasi dan transaksi Anda. Anda mungkin memiliki peralatan jaringan dengan login ini dijamin oleh implementasi dari TLS. Selain itu Anda mungkin memiliki perangkat lunak sisi klien pada komputer yang dapat mengekspos data dari komputer Anda jika Anda terhubung ke layanan yang dikompromikan.
Seberapa luas penyebaran ini?
Kebanyakan perangkat lunak terkenal menggunakan OpenSSL adalah server web open source seperti Apache dan nginx. Gabungan pangsa pasar yang terdiri dari dua situs aktif di Internet lebih dari 66 % menurut Netcraft April 2014 Web Server Survey. Selanjutnya OpenSSL digunakan untuk melindungi seperti server email ( SMTP , POP dan IMAP protokol ) , chatting server ( protokol XMPP ) , virtual private network ( VPN SSL ) , peralatan jaringan dan berbagai perangkat lunak klien . Untungnya banyak situs konsumen besar yang disimpan oleh pilihan konservatif dari peralatan terminasi SSL / TLS dan perangkat lunak. Ironisnya layanan yang lebih kecil dan lebih progresif atau mereka yang telah upgrade terbaru dan enkripsi terbaik akan lebih terpengaruh. Selanjutnya OpenSSL sangat populer di perangkat lunak klien dan sedikit populer dalam peralatan jaringan yang memiliki inersia dalam update.
Versi OpenSSL apa yang pengaruh ?
Status versi yang berbeda:
OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
OpenSSL 1.0.1g is NOT vulnerable
OpenSSL 1.0.0 branch is NOT vulnerable
OpenSSL 0.9.8 branch is NOT vulnerable
Bug diperkenalkan oleh OpenSSL pada December 2011 dan telah keluar sejak OpenSSL 1.0.1 rilis pada 14 Maret 2012. OpenSSL 1.0.1g rilis pada 7 April 2014 perbaikan bug.
Seberapa umum versi OpenSSL vulnerable?
Versi vulnerable telah keluar selama lebih dari dua tahun sampai sekarang dan mereka telah dengan cepat diadopsi oleh sistem operasi modern. Sebuah faktor utama adalah TLS versi 1.1 dan 1.2 tersedia dengan versi vulnerable OpenSSL ( 1.0.1 ) yang pertama dan komunitas keamanan telah mendorong TLS 1.2 karena serangan sebelumnya terhadap TLS ( seperti BEAST ) .
Bagaimana dengan sistem operasi ?
Beberapa distribusi sistem operasi yang telah dikirimkan dengan versi OpenSSL berpotensi rentan :
- Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
- Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
- CentOS 6.5, OpenSSL 1.0.1e-15
- Fedora 18, OpenSSL 1.0.1e-4
- OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
- FreeBSD 10.0 - OpenSSL 1.0.1e 11 Feb 2013
- NetBSD 5.0.2 (OpenSSL 1.0.1e)
- OpenSUSE 12.2 (OpenSSL 1.0.1c)
Distribusi sistem operasi dengan versi yang tidak rentan :
- Debian Squeeze (oldstable), OpenSSL 0.9.8o-4squeeze14
- SUSE Linux Enterprise Server
- FreeBSD 8.4 - OpenSSL 0.9.8y 5 Feb 2013
- FreeBSD 9.2 - OpenSSL 0.9.8y 5 Feb 2013
- FreeBSD Ports - OpenSSL 1.0.1g (At 7 Apr 21:46:40 2014 UTC)
Bagaimana OpenSSL dapat diperbaiki ?
Meskipun sebenarnya kode untuk perbaikan mungkin tampak sepele , tim OpenSSL adalah ahli dalam memperbaiki hal itu dengan benar hingga versi terbaru tetap 1.0.1g atau yang terbaru harus digunakan . Jika hal ini tidak mungkin pengembang perangkat lunak dapat mengkompilasi ulang OpenSSL dengan handshake dihapus dari kode dengan opsi waktu kompilasi - DOPENSSL_NO_HEARTBEATS.
Haruskah heartbeat dihapus untuk membantu dalam deteksi layanan yang rentan?
Pemulihan dari bug ini bisa mendapatkan keuntungan jika versi baru dari OpenSSL memperbaiki bug dan menonaktifkan heartbeat sementara sampai beberapa versi masa depan. Tampaknya hampir semua implementasi TLS yang merespon permintaan heartbeat saat ini adalah versi rentan OpenSSL. Apabila hanya versi rentan OpenSSL yang akan terus merespon heartbeat selama beberapa bulan ke depan maka respon yang terkoordinasi dalam skala besar untuk mencapai pemilik layanan yang rentan akan menjadi lebih layak.
Dapatkah saya mendeteksi jika seseorang telah mengeksploitasi hal ini terhadap saya?
Eksploitasi bug ini tidak meninggalkan jejak sesuatu yang abnormal terjadi ke log .
Dapatkah IDS / IPS mendeteksi atau memblokir serangan ini?
Meskipun isi dari permintaan heartbeat dienkripsi memiliki tipe record sendiri dalam protokol. Hal ini akan memungkinkan deteksi gangguan dan sistem pencegahan ( IDS / IPS ) dilatih untuk mendeteksi penggunaan permintaan heartbeat . Karena enkripsi membedakan antara penggunaan yang sah dan serangan tidak dapat didasarkan pada isi permintaan, tetapi serangan itu dapat dideteksi dengan membandingkan ukuran permintaan terhadap ukuran jawabannya. Hal ini berarti IDS / IPS dapat diprogram untuk mendeteksi serangan tetapi tidak untuk memblokir kecuali permintaan heartbeat diblokir semuanya .
Apakah ini telah disalahgunakan di alam liar?
Kita tidak tahu. Komunitas keamanan harus mengerahkan TLS / DTLS honeypots yang menjebak penyerang dan untuk mengingatkan tentang upaya eksploitasi .
Mampukah penyerang akses hanya 64k dari memori?
Tidak ada total 64 kilobyte pembatasan serangan, batas tersebut hanya berlaku untuk heartbeat tunggal. Penyerang dapat tetap berhubungan kembali atau selama koneksi TLS aktif terus meminta sebagian dari 64 kilobyte isi memori sampai rahasia terungkap.
Apakah bug MITM seperti Apple go to fail bug?
Tidak ini tidak memerlukan seseorang dalam serangan tengah ( MITM ) . Penyerang dapat langsung menghubungi layanan rentan atau menyerang setiap pengguna yang terhubung ke layanan berbahaya. Namun disamping ancaman langsung pencurian material kunci memungkinkan seseorang di penyerang tengah untuk meniru layanan yang dikompromikan.
Apakah sertifikat otentikasi TLS klien mengurangi hal ini?
Tidak, permintaan hearbeat dapat dikirim dan dijawab selama fase handshake protokol . Hal ini terjadi sebelum otentikasi sertifikat klien .
Apakah OpenSSL FIPS mode yang mengurangi hal ini ?
Tidak, OpenSSL Federal Information Processing Standard ( FIPS ) mode tidak berpengaruh pada fungsi heartbeat rentan .
Apakah Perfect Forward Secrecy ( PFS ) mengurangi ini ?
Penggunaan Perfect Forward Secrecy ( PFS ) , langka tapi kuat , seharusnya melindungi komunikasi terakhir dari dekripsi retrospektif. Lihat https://twitter.com/ivanristic/status/453280081897467905
seberapa tiket bocor dapat mempengaruhi hal ini .
Bisa ekstensi hartbeat dinonaktifkan selama TLS handshake?
Tidak , kode ekstensi heartbeat yang rentan diaktifkan terlepas dari hasil negosiasi tahap handshake. Satunya cara untuk melindungi diri sendiri adalah meng-upgrade ke versi tetap OpenSSL atau mengkompilasi ulang OpenSSL dengan handshake yang dihapus dari kode.
Siapa yang menemukan Heartbleed Bug ?
Bug ini secara independen ditemukan oleh sebuah tim insinyur keamanan ( Riku , Antti dan Matti ) di Codenomicon dan Neel Mehta dari Google Security , yang pertama kali melaporkan hal itu kepada tim OpenSSL . Tim Codenomicon menemukan heartbleed bug sekaligus meningkatkan fitur Safeguard dalam alat pengujian Defensics keamanan Codenomicon dan melaporkan bug ini ke NCSC - FI untuk koordinasi kerentanan dan melaporkan kepada tim OpenSSL .
Apa Safeguard Defensics?
Fitur Safeguard dari testtools Defensics keamanan Codenomicon secara otomatis menguji sistem target untuk kelemahan yang membahayakan integritas , privasi atau keamanan . Safeguard adalah solusi sistematis untuk mengekspos gagal cek sertifikat kriptografi , kebocoran privasi atau kelemahan otentikasi yang telah terkena pengguna internet untuk semua orang di tengah serangan dan mengetahui rahasia . Selain Heartbleed bug fitur Safeguard Defensics TLS baru dapat mendeteksi misalnya lubang keamanan dapat dieksploitasi di GnuTLS banyak digunakan perangkat lunak open source melalui fungsi SSL / TLS dan " goto fail ; " bug dalam implementasi TLS / SSL Apple yang ditambal pada bulan Februari 2014.
Siapa yang mengkoordinasikan respon terhadap kerentanan ini?
NCSC - FI bertugas dalam menjangkau para penulis dari OpenSSL , perangkat lunak , sistem operasi dan vendor alat , yang berpotensi terkena dampak . Namun, kerentanan ini ditemukan dan rincian yang dirilis secara independen oleh orang lain sebelum pekerjaan ini selesai . Vendor harus memberitahu pengguna mereka dan penyedia layanan . Penyedia layanan Internet harus memberitahu pengguna akhir mereka di mana dan kapan tindakan potensial diperlukan .
Apakah ada sisi terang dari semua ini?
Bagi penyedia jasa yang terpengaruh hal ini adalah kesempatan yang baik untuk meng-upgrade kekuatan keamanan kunci rahasia yang digunakan. Banyak perangkat lunak mendapat update yang dinyatakan belum mendesak. Meskipun hal ini menyakitkan bagi komunitas keamanan, kita yakin bahwa infrastruktur penjahat cyber dan rahasia mereka telah terkena juga.
Dimana dapat menemukan informasi lebih lanjut ?
Q & A diterbitkan sebagai tindak lanjut dari penasehat OpenSSL, karena kerentanan ini menjadi publik pada 7 April 2014 . Proyek OpenSSL telah membuat pernyataan di
NCSC-FI menerbitkan sebuah penasehat di
Vendor individu distribusi sistem operasi, pemilik yang terkena layanan internet, paket perangkat lunak dan vendor alat dapat mengeluarkan advisories mereka sendiri .
No comments:
Post a Comment