Minggu Ini Dalam Keamanan: OpenSSL Fizzle, Java XML, Dan Tidak Ada Yang Terlihat

Dunia keamanan menahan napas kolektif kami awal minggu ini untuk pengumuman kerentanan OpenSSL yang besar. Ternyata itu adalah dua masalah terpisah, keduanya terkait dengan penanganan kode puny, dan telah diturunkan ke tingkat keparahan tinggi alih-alih kritis. Punycode, omong-omong, adalah sistem untuk menggunakan karakter Unicode non-ASCII dalam nama domain. Kerentanan pertama, CVE-2022-3602, adalah buffer overflow yang menulis empat byte sewenang-wenang ke stack. Khususnya, kode rentan hanya dijalankan setelah rantai sertifikat diverifikasi. Sertifikat berbahaya harus ditandatangani dengan benar oleh Otoritas Sertifikat, atau dipercaya secara manual tanpa tanda tangan yang valid.

Beberapa sumber telah menyusun rincian kerentanan ini. Ini adalah kesalahan satu per satu dalam satu lingkaran, di mana panjang buffer diperiksa lebih awal dalam loop daripada variabel panjang bertambah. Karena slip logika, loop berpotensi berjalan terlalu banyak. Loop itu memproses karakter Unicode, dikodekan di akhir string punycode, dan menyuntikkannya di tempat yang tepat, sebagai hasilnya menggeser sisa string di atas satu byte dalam memori. Jika total panjang keluaran adalah 513 karakter, itu adalah luapan karakter tunggal. Karakter Unicode membutuhkan empat byte, jadi ada kelebihan empat byte Anda.

Sekarang, seberapa eksploitatifnya overflow ini bergantung pada apa yang ada dalam empat byte itu. Ketika peneliti Datadog menguji kerentanan di Linux, mereka menemukan bahwa pada dasarnya setiap biner yang dikompilasi memiliki bagian 4-byte memori bebas di sini, yang diinisialisasi hanya setelah overflow. Dengan kata lain, pada binari tersebut, kerentanan ini sepenuhnya tidak berbahaya. Di Windows, bagian memori itu ditangani secara berbeda oleh kompiler, karena optimasi yang berbeda. Di sini, ini berisi tumpukan kenari. Itu adalah nilai khusus yang ada di antara buffer terakhir di tumpukan, dan nilai penunjuk dan pengembalian. Di akhir fungsi yang menggunakan stack canary, nilainya divalidasi sebelum kembali ke fungsi induk, dan proses akan mogok jika telah diubah. Idenya adalah buffer overflow yang menimpa alamat pengirim tidak akan dapat memprediksi nilai canary, dan canary cenderung dengan sengaja memasukkan byte terminator seperti 0x00 untuk membuat eksploitasi lebih sulit. Perhatikan bahwa binari Linux juga menggunakan kenari tumpukan, yang akan mencegah eksploitasi, tetapi karena tata letak memori dan panjang luapan yang terbatas, ini tidak pernah dimodifikasi.

Masalah kedua yang diperbaiki adalah CVE-2022-3786, dan Checkpoint Security mencoba menjelaskan yang satu ini. Dalam kasus Punycode diikuti oleh sebuah titik, titik tersebut ditambahkan ke akhir string keluaran, berpotensi melewati akhir buffer. Ini kebalikan dari kerentanan sebelumnya. Di sini panjang overflow hampir sewenang-wenang, tetapi nilainya dikunci hanya pada simbol titik. Akibatnya, yang satu ini benar-benar masalah Denial of Service.

Untungnya langit tidak jatuh dengan kerentanan ini, tetapi mungkin masih ada kasus yang tidak terduga di mana OpenSSL tidak dikompilasi dengan stack canaries, atau crash dapat digunakan sebagai bagian dari rantai eksploitasi yang lebih rumit, jadi tetap pastikan untuk mengambil patch yang diperbarui atau di-backport jika Anda menjalankan pustaka yang rentan, versi 3.0.0-3.0.6.

Peneliti Keamanan Beralih ke Sisi Gelap?

Hukum headline Betteridge tentu saja berperan di sini. Cerita ini hanya aneh, karena seseorang telah meluncurkan serangan ransomware, yang juga merupakan perangkat protes, dan juga mengklaim sebagai karya dari beberapa peneliti keamanan terkemuka. Jadi, apakah Bleeping Computer benar-benar berada di balik kampanye ransomware yang juga memprotes kurangnya dukungan untuk Ukraina dari Barat? Oof, ada banyak yang harus dibongkar di sini.

Pertama, tampaknya bukan ransomware, karena tidak ada cara untuk membeli kunci dekripsi. Jadi lebih tepat itu adalah wiper. Nama yang digunakan dalam catatan penghapus adalah “Azov”, sebuah resimen pasukan khusus di Ukraina dengan masa lalu neo-Nazi yang aneh, yang kebetulan memainkan retorika Rusia tentang perang mereka di sana. Kemudian catatan tersebut mengklaim berasal dari Hasherezade, dan mencantumkan beberapa peneliti keamanan yang menangani Twitter. Kemudian menyebutkan Krimea dan mengeluh tentang tidak cukup bantuan untuk Ukraina. jAda pesan khusus untuk rakyat AS, menyerukan presiden Biden, menyerukan revolusi dan kemudian menjatuhkan slogan “Jaga Amerika Hebat”. Kemudian sebuah pesan ke Jerman, dengan bantuan dijalankan melalui Google Terjemahan memberi kami: “Anda! Seorang pria dari Jerman, ayo, keluar!
Tapi itu adalah malapetaka yang dibawa Biden kepada mereka. Betapa menyenangkannya ketika Merkel ada di sana?” Dan yang lebih aneh lagi, catatan itu diakhiri dengan tagar “#TaiwanIsChina”, yang tampaknya merupakan slogan retorika yang disponsori PKC di sekitar Taiwan.

Sulit untuk mengetahui dengan tepat apa yang terjadi dengan kampanye ini. Ini jelas bukan apa yang diklaimnya. Peretas pro-Rusia atau anti-Rusia mencoba mencari dukungan? Sesuatu yang lain sama sekali, menggunakan geopolitik untuk perlindungan? Infeksi semua tampaknya merupakan hasil dari SmokeLoader, salah satu botnet malware-as-a-service. Bayar sejumlah uang, dorong muatan Anda ke mesin di botnet. Sekedar mengingatkan, jika Anda atau seseorang yang Anda kenal terkena salah satu kampanye ini, kantor penegak hukum ingin mencatatnya. Untuk menemukan dan mengadili para penjahat di balik perusahaan-perusahaan ini, mereka memerlukan beberapa kasus konkret untuk memulai. Dan sepertinya penjahat ransomware tidak akan pernah tertangkap, mereka bisa diidentifikasi dan ditangkap.

Project Zero Menolak Menyebutnya XML4Shell

[Felix Wilhelm] menemukan masalah Java, dan untuk kesenangan kami bersama, dia tidak merasa perlu membuat moniker “4shell” untuk itu. Kisah ini dimulai dengan SAML, Security Assertion Markup Language, protokol berbasis XML yang mendukung sebagian besar dukungan sistem masuk tunggal web. Anda ingin mengunjungi situs web X, Penyedia Layanan (SP) dan menggunakan akun Anda dari situs web Y, Penyedia Identitas (IdP) Anda. SP membuat permintaan SAML, dalam bentuk dokumen XML, dan browser Anda mengirimkan dokumen tersebut ke IdP. IdP mengonfirmasi bahwa Anda memiliki akun di sana, dan mengirimkan kembali tanda tangan XML, melalui browser. Karena merupakan masalah potensial yang jelas bagi browser pengguna yang menangani data masuk, data itu sendiri diverifikasi sebagai bagian dari tanda tangan. Seluruh prosesnya rumit dan salah satu kerumitannya adalah tanda tangan dapat menyertakan referensi ke tanda tangan lain. Sebelum tanda tangan diverifikasi sepenuhnya, dokumen XML yang ditandatangani mungkin perlu melalui beberapa langkah transformatif, dan bahasa eXtensible Stylesheet Language Transformations (XSLT) didukung. Ya, ini adalah bahasa lengkap turing tepat di objek SAML Anda. Dan jika kode yang melakukan verifikasi tidak mengaktifkan secureValidation, kode tersebut akan dikompilasi ke dalam kode Java untuk peningkatan kinerja.

Bagian dari proses kompilasi ini adalah mengonversi nilai dalam input XSLT ke kumpulan konstanta Java. Kumpulan itu memiliki ukuran terbatas, dan proses kompilasi tidak melakukan pemeriksaan batas dengan benar. Apa yang terjadi ketika Anda menulis melewati ujung kolam? Data itu dipahami sebagai bidang kelas — bidang seperti definisi metode. Lakukan pekerjaan untuk membuat nilai yang valid untuk tiga bidang yang overflow ini akan gagal, dan Anda memiliki kemampuan untuk menjalankan bytecode arbitrer. Ini berfungsi untuk aplikasi Java apa pun yang menangani tanda tangan XML — secara teori. Peringatan besar adalah bahwa secureValidation menonaktifkan semua transformasi XSLT, tetapi itu hanya diaktifkan secara default di JDK 17.

urlscan.io Menyimpan Rahasia

Layanan yang disediakan oleh urlscan.io sebenarnya cukup berguna. Beri dia tautan web, dan itu akan memuatnya, mempratinjau halaman untuk Anda, dan mengeluarkan beberapa statistik tentangnya. Seseorang mengirim tautan aneh, dan Anda tidak ingin membukanya di mesin Anda? Inilah solusi Anda. Satu-satunya hal yang perlu diingat adalah bahwa kecuali Anda secara eksplisit menandai pemindaian sebagai pribadi, tautan dan hasilnya dapat dilihat oleh publik. Github mendapat sedikit tahun terakhir ini, secara tidak sengaja membocorkan nama repositori pribadi ke layanan. Ini membuat [FABIAN BRÄUNLEIN] bertanya-tanya, apakah layanan lain melakukan kesalahan serupa? Ya. Ada tautan ke dokumen Google pribadi, kunci API, undangan Sharepoint dan Zoom, dan banyak lagi. Rupanya beberapa layanan keamanan otomatis mendorong tautan ke layanan tanpa interaksi pengguna apa pun, dan tidak menggunakan API dengan benar. Ups.