- Pada 2008, saat memperbaiki bottleneck login SSH GitHub, muncul petunjuk adanya kolisi tidak normal ketika pengguna yang berbeda memiliki sidik jari kunci SSH yang sama
- Untuk menghindari masalah pencarian linear pada file
authorized_keysyang terus membesar, GitHub menambal OpenSSH agar mencari sidik jari kunci di MySQL - Setelah patch dirilis, muncul masalah akses ke repositori pengguna lain lewat SSH, tetapi kolisi sidik jari kunci yang berulang sulit dijelaskan hanya sebagai bug patch biasa
- Pada 13 Mei 2008, publikasi DSA-1571-1 mengungkap bahwa Debian OpenSSL selama sekitar 18 bulan membuat kunci privat yang dapat diprediksi, sehingga jumlah kunci yang mungkin per pengguna menyusut menjadi sedikit di atas 32.000
- Insiden keamanan besar sering bermula dari sinyal kecil bahwa “ada yang aneh”, dan perbedaan nyata ditentukan oleh waktu dan kemampuan untuk menelusuri petunjuk itu sampai tuntas
Insiden yang bermula dari bottleneck login SSH GitHub
- Pada Maret 2008, penulis yang bekerja di Engine Yard diminta membantu masalah performa login SSH GitHub, yang saat itu merupakan pelanggan perusahaan hosting berfokus Rails tersebut
- GitHub menyediakan akses ke repositori Git melalui autentikasi kunci publik setelah pengguna terhubung via SSH ke
git@github.com - Saat itu pengelolaan kunci masih bergantung pada cara umum, yaitu file
~/.ssh/authorized_keys- Saat menerima permintaan autentikasi kunci publik, SSH akan membuka file
authorized_keysdan melakukan pencarian linear untuk menemukan entri yang cocok dengan kunci yang diajukan - Pada akun biasa yang hanya memiliki beberapa kunci, ini bukan masalah besar, tetapi di GitHub yang tumbuh cepat, semua kunci SSH menumpuk dalam satu file besar sehingga waktu login melambat secara nyata
- Saat menerima permintaan autentikasi kunci publik, SSH akan membuka file
Patch OpenSSH dan pencarian kunci lewat MySQL
- Setelah meninjau beberapa solusi, tim GitHub dan penulis memilih menambal OpenSSH agar mencari kunci berdasarkan sidik jari kunci di database MySQL
- Keputusan ini bukan perubahan yang bisa diambil dengan ringan
- Memodifikasi OpenSSH bisa berakibat fatal bagi keamanan jika dilakukan keliru
- Karena opsi lain lebih buruk, ini dinilai sebagai pilihan “yang paling tidak buruk”
- Sebagian besar pekerjaan perubahan ini dihabiskan untuk memastikan keamanan tidak dirusak
- Setelah dirilis pada awal April 2008, login SSH menjadi lebih cepat, dan tampaknya masalah yang sama tidak perlu dikhawatirkan untuk sementara waktu
Gejala yang tampak mustahil: sidik jari kunci ganda
- Pada awal Mei 2008, tim GitHub mengirim kabar bahwa beberapa pengguna GitHub dapat mengakses repositori milik pengguna lain melalui SSH
- Karena masalah ini berhubungan langsung dengan autentikasi kunci SSH dan patch OpenSSH baru saja dirilis, kode yang ditulis penulis menjadi tersangka utama pertama
- Setelah debugging, terkonfirmasi bahwa dua pengguna yang berbeda memiliki sidik jari kunci yang sama
- Hal seperti ini pada praktiknya sulit terjadi kecuali para pengguna memang saling berbagi kunci
- Pengguna yang terdampak tidak saling mengenal, dan mengatakan bahwa mereka tidak pernah mempublikasikan kunci mereka
- Setelah itu, sidik jari kunci yang sama juga ditemukan pada pasangan pengguna lain, dan nilainya berbeda dari kasus sebelumnya
- Situasinya menjadi sulit dipandang sebagai kebetulan tunggal atau sekadar bug aplikasi web
- Setelah cukup dipastikan bahwa patch OpenSSH bukan penyebabnya, keterlibatan langsung penulis pun berkurang
- Penulis bukan karyawan GitHub, dan masih harus menangani pekerjaan dukungan pelanggan lain di Engine Yard
- Tim GitHub terus melakukan verifikasi dengan para pengguna, dan menemukan kesamaan bahwa kunci SSH dibuat di sistem Debian atau Ubuntu
Penyebabnya terungkap lewat publikasi kerentanan Debian OpenSSL
- Pada 13 Mei 2008, publikasi DSA-1571-1 membuat situasinya menjadi jelas
- Paket Debian OpenSSL selama sekitar 18 bulan telah menghasilkan kunci privat yang dapat diprediksi
- Penyebabnya adalah saat merapikan kode pembangkit bilangan acak OpenSSL, seorang pengelola Debian tanpa sengaja sangat memperkecil ruang kunci yang mungkin dihasilkan
- Jumlah kunci yang mungkin dibuat oleh pengguna tertentu menyusut dari “jumlah yang sangat besar” menjadi sedikit di atas 32.000
- Karena banyak pengguna mendaftar ke GitHub, sebagian mungkin membuat kunci baru secara terpisah sesuai praktik yang dianjurkan, dan akibatnya tabrakan bisa terjadi
- Publikasi ini menjadi bukti penentu bahwa patch OpenSSH buatan penulis bukan penyebabnya
Pekerjaan terkait Debian weak keys setelahnya
- Penulis kemudian kembali bersinggungan dengan Debian weak keys di masa berikutnya
- Ia mengelola pwnedkeys.com, yang menangani repositori besar kunci-kunci yang diketahui telah terkompromi
- Kunci-kunci itu juga digunakan untuk menemukan Certificate Authority yang berperilaku salah
Perbedaan yang diciptakan oleh waktu untuk menelusuri “ada yang aneh”
- Penulis tidak berhasil menemukan kapan tepatnya dan bagaimana Luciano Bello pertama kali menemukan kerentanan yang kemudian diberi CVE-2008-0166
- Karena rilis stable Debian yang memuat kode rentan itu sudah keluar setahun sebelum pengungkapan, mungkin ada waktu untuk melihat kolisi kunci, merasa “ada yang aneh”, lalu menggali lebih dalam
- Backdoor XZ yang lebih baru juga terungkap lewat pengamatan bahwa “ada yang aneh” dan penyelidikan yang intensif
- Bagian pentingnya adalah kemampuan dan waktu untuk benar-benar melakukan penyelidikan intensif semacam itu
- Penulis sendiri saat itu tidak bisa melakukan penyelidikan mendalam secara langsung
- Tim GitHub juga sibuk mengembangkan fitur dan menangani gangguan pada layanan yang tumbuh cepat
- Penulis pun masih menangani tiket dukungan di Engine Yard
- Perbedaan besar tercipta ketika, pada saat yang tepat, ada orang dengan keterampilan, waktu, dan energi untuk mengikuti petunjuk itu sampai akhir
1 komentar
Pendapat di Hacker News
Mengenai bagian “tidak ditemukan kapan dan bagaimana persisnya Luciano Bello menemukan kerentanan yang kelak menjadi CVE-2008-0166”, log IRC saat itu mencatat seperti ini
17:23 < luciano> has really an accident. I was needing many primes numbers... 0:-)17:23 < Sesse> and you got the same numbers every time?17:25 < luciano> Sesse, not every time :PPernyataan bahwa “industri beruntung karena ada orang dengan keterampilan, waktu, dan energi yang tepat pada momen yang tepat” adalah titik di mana statistik tentang banyak mata dan “sinar matahari adalah disinfektan terbaik” terasa nyata
Betapapun kecil kemungkinannya seseorang kebetulan lewat lalu menemukan bug, karena itu mungkin, hal tersebut benar-benar terjadi
Pada kode proprietary/tertutup, probabilitas itu mendekati nol
Seseorang menyadari ada yang janggal, lalu dapat memeriksa situasi nyata bersama kode sumber dan melihat bahwa memang ada sesuatu yang mencurigakan
Mereka menghubungi pakar keamanan di distro-distro utama untuk ditinjau lebih lanjut, dan para pakar itu juga mengonfirmasi adanya isu keamanan lalu bisa segera merespons
Setelah dipublikasikan, orang-orang dengan keahlian di berbagai bidang perangkat lunak dan keamanan dapat membongkar apa yang terjadi, bagaimana itu dilakukan, dan apa risikonya
Commit mencurigakan yang ditinggalkan pengembang yang sama di perangkat lunak lain juga dilacak dan dikonfirmasi, dan analisis dampaknya masih berlanjut
Setiap distro menjadi lebih peka terhadap detail tentang bagaimana kerusakan terjadi di sekitar arsip build, dan mulai mencari cara untuk mendeteksi serta mencegah kasus serupa ke depannya
Dibandingkan dengan closed source, laporan seperti “perangkat lunaknya agak lambat” kemungkinan besar nyaris tidak akan mendapat perhatian sampai ada eksploitasi nyata
Kalaupun perusahaan akhirnya mengetahuinya, yang keluar mungkin hanya penjelasan yang sangat hati-hati dengan informasi seminimal mungkin, dan ini sangat merusak kemampuan industri secara keseluruhan untuk menghindari pengulangan
Namun kemungkinan besar masalahnya tidak bisa diperbaiki, atau tidak ada tindakan apa pun
Kebanyakan orang, meski menemukan bug, tidak tahu harus melakukan apa. Saya dulu sekali juga begitu, dan baru kemudian menyadari bahwa hal-hal yang pernah saya lihat itu adalah bug
Detailnya samar karena hampir 30 tahun lalu, tetapi saya ingat pernah mengutak-atik Microsoft NetMeeting di Windows dan bisa membuatnya crash dengan galat buffer overrun
Saat itu saya masih pemula komputer, dan tidak memahami bahwa buffer overflow pada aplikasi jaringan adalah hal yang sangat buruk. Tampaknya banyak orang yang sudah lama di industri pun begitu
Pada masa itu, melaporkan isu keamanan juga jauh lebih sulit, dan dalam beberapa kasus bahkan berbahaya
Pada akhirnya, yang dibutuhkan ada banyak hal: menemui masalahnya, memahami komputasi cukup dalam untuk mengenali bahwa masalah itu buruk, sarana untuk melaporkan bug ke tempat yang akan diperiksa orang, serta budaya keamanan yang tahu kapan dan bagaimana menangani laporan
Namun saat membaca kalimat yang sama, yang membuat saya penasaran adalah berapa banyak bug keamanan serius seperti Heartbleed, CVE-2008-0166, dan insiden xz yang terjadi tanpa pernah ditemukan atau dipublikasikan
Fakta penting yang baru belakangan ini saya ketahui tentang kerentanan ini adalah bahwa perubahan tersebut bukan sesuatu yang dilakukan tergesa-gesa
Maintainer memposting masalah yang ia lihat ke mailing list OpenSSL, meminta umpan balik, mengusulkan perbaikan, dan menerima beberapa balasan, termasuk dari upstream
Hasilnya memang kerentanan yang mengerikan, tetapi ini lebih tampak seperti nasib yang sangat buruk karena semua orang melewatkan masalahnya
Selain itu, kode upstream OpenSSL sedang memanggil undefined behavior. Jadi, kalau compiler melakukan transformasi yang persis sama seperti yang dilakukan maintainer Debian, itu mungkin saja valid
Waktu itu, ini terasa seperti pembahasan akademis. Rasanya tidak mungkin compiler akan bertindak sejahat itu
Setelahnya, kami jadi lebih memahami bahwa undefined behavior harus dihindari sama sekali
Lalu 8 tahun kemudian, ketika Heartbleed ditemukan, semua orang mendadak menyadari betapa buruknya pemeliharaan OpenSSL
Sebagai pembelaan, pekerjaan itu hampir seperti kerja sukarela, dan untungnya setelah itu dukungan pendanaan membuat situasinya membaik
Untuk kode generator angka acak yang penting bagi keamanan, rasanya benar-benar perlu ada pengujian yang menghasilkan angka acak dalam jumlah sangat besar lalu memverifikasi bahwa semuanya unik
Saat membaca hal seperti ini, jadi penasaran seberapa besar kemungkinan hal seperti ini sudah terjadi, atau akan terjadi, pada fungsi pembuatan seed di salah satu dompet hardware Bitcoin yang populer
Dan juga penasaran seperti apa dampaknya
Selama 22 bulan terakhir, Unciphered menangani kerentanan yang memengaruhi BitcoinJS, yang banyak digunakan untuk pembuatan dompet kripto berbasis browser, serta produk dan proyek yang dibuat dengan software ini
Selama bertahun-tahun, kerentanan ini menyebabkan terciptanya cukup banyak dompet kripto yang rentan
Dalam kasus kerentanan SSH, orang harus secara aktif memeriksa apakah server yang ingin diakses memiliki salah satu fingerprint buruk, sedangkan di sisi dompet, orang bisa secara otomatis mengakses dana orang lain di jaringan
Namun dalam kasus itu, kecil kemungkinan hal tersebut sengaja dimasukkan
Dengan teknologi saat ini mungkin perlu waktu komputasi jutaan tahun, tetapi bagi aktor negara yang bisa menggelontorkan uang nyaris tak terbatas untuk menjalankan komputasi sebesar itu dalam beberapa minggu, mungkin itu bukan di luar jangkauan
Pada akhirnya bisa saja tiba saatnya siapa pun yang mengetahui alamat dapat mengakses semua dompet
Jika bisa menjadi target seseorang yang punya otak dan uang, Bitcoin tidak begitu aman untuk menyimpan nilai
Kalimat “Ezra Zygmuntowitz menghubungkan saya dengan GitHub, dan memberi saya waktu untuk menggali masalah ini bersama tim GitHub” itu lucu
Mungkin karena saya bukan penutur asli, kalimat itu juga terbaca seolah ada masalah besar pada tim GitHub itu sendiri, jadi saya kira kalimat-kalimat berikutnya akan menggali hal tersebut
Bagian “saya penasaran berapa lama lagi ini baru ditemukan kalau Luciano tidak menemukannya” mungkin berarti hanya GitHub atau penyedia cloud besar yang kebetulan akan menabraknya
Karena tidak banyak tempat yang menyimpan ribuan hingga puluhan ribu key pengguna
Masalahnya adalah apakah kalimat harus dibaca sebagai
(menggali masalah) (bersama tim GitHub), atau(menggali masalah tentang tim GitHub)Menangani hal ini dengan benar dikenal sebagai hal yang cukup sulit
Sejauh yang saya pahami, generator bilangan acak OpenSSL di-seed dengan memori stack yang belum diinisialisasi dan PID, lalu Debian membuatnya hanya di-seed dengan PID
Tapi bukankah itu sudah cukup berbahaya bahkan tanpa patch Debian?
Di kode OpenSSL ada dua titik yang menyalin sekumpulan byte, dan salah satunya bisa menyalin nilai sampah yang belum diinisialisasi. Itu memang salah
Seseorang menulis patch untuk memperbaikinya, lalu setelah itu, tanpa bantuan LLM dan murni karena ketidakmampuan manusia, ada yang berkata “di dekat sini ada satu penyalinan lain yang mirip, jadi ini juga harus dihapus”
Debian memasukkan patch yang menerapkan kedua perubahan itu
Akibatnya, OpenSSL kini tidak menyalin byte apa pun
Bagus karena tidak menyalin data yang belum diinisialisasi, tetapi entropi acak sungguhan juga tidak lagi disalin ke pool. Aduh
Pada bagian “setelah meninjau beberapa solusi yang mungkin, kami menyimpulkan bahwa pilihan yang paling tidak buruk adalah mem-patch OpenSSH agar mencari key di database MySQL yang diindeks dengan fingerprint key”, kenapa MySQL, bukan sqlite?
Situasinya adalah ingin mempercepat akses ke ~/.ssh/authorized_keys, dan kasus seperti ini justru situasi yang dirancang agar MySQL bersinar
Sepertinya mem-patch OpenSSH agar memeriksa ~/.ssh/authorized_keys.db akan lebih sedikit pekerjaannya daripada mem-patch agar memakai MySQL
Besar kemungkinan MySQL sudah berjalan. Kalau begitu, biaya awal untuk menyimpan data di sana juga tidak ada
Lagi pula database pengguna pasti sudah ada di suatu tempat
Terlepas dari ditemukannya sejumlah kecil key lemah, menarik bahwa waktu login SSH yang lambat adalah petunjuk yang layak ditarik-tarik karena berbagai alasan
Episode menarik lainnya adalah kasus mendeteksi key RSA yang memiliki faktor
patauqyang sama menggunakan faktor persekutuan terbesar: https://factorable.net/weakkeys12.extended.pdfPenasaran apakah GitHub masih menjalankan openssh yang sudah dipatch
Beli satu salinan GitHub Enterprise, hilangkan obfuscation file-nya, lalu lihat-lihat. Deobfuscation-nya tantangan yang menarik dan juga tidak terlalu sulit
Sayangnya karena bukan open source, kodenya tidak bisa dibagikan, dibicarakan, atau ditautkan di GitHub
Namun jika GitHub Enterprise masih memakai patch seperti itu, besar kemungkinan GitHub produksi juga begitu
~/.ssh/authorized_keysJika tersambung dengan telnet ke port 22 di
github.com, string versinya langsung ditampilkanKoreksi, awalnya saya bilang golang, tetapi setelah dicek ternyata yang memakai golang adalah Bitbucket