Keamanan Minggu Ini: Git Deep Dive, Mailchimp, dan SPF

Keamanan Minggu Ini: Git Deep Dive, Mailchimp, dan SPF

Stempel Waktu: 20 Januari 2023 10
Node Sumber: 1910203

Pertama, git telah diaudit. Ini adalah upaya yang disponsori oleh Open Source Technology Improvement Fund (OSTIF), sebuah organisasi nirlaba yang berupaya meningkatkan keamanan proyek Open Source. Auditnya sendiri dilakukan oleh peneliti dari X41 dan GitLab, dan dua kerentanan kritis ditemukan, keduanya disebabkan oleh kebiasaan pengkodean yang buruk — menggunakan int untuk menahan panjang buffer.

Pada sistem modern, a size_t selalu tidak ditandatangani, dan panjang bitnya sama dengan lebar bit arsitektur. Ini adalah tipe data yang tepat untuk panjang string dan buffer, karena dijamin tidak akan meluap ketika menangani panjang hingga memori beralamat maksimum pada sistem. Di sisi lain, sebuah int biasanya panjangnya empat byte dan ditandatangani, dengan nilai maksimum 2^31-1, atau 2147483647 — sekitar 2 GB. Buffer yang besar, namun jumlah datanya tidak terlalu besar. Lemparkan sesuatu sebesar itu ke git, dan benda itu akan pecah dengan cara yang tidak terduga.

Contoh pertama kami adalah CVE-2022-23521, penulisan di luar batas yang disebabkan oleh int meluap ke negatif. A .gitattributes file dapat dikomit ke repositori dengan klien git yang dimodifikasi, dan kemudian memeriksa repositori tersebut akan menyebabkan num_attrs variabel meluap. Dorong overflow hingga ke angka negatif kecil, dan git kemudian akan mengalokasikan buffer atribut secara jauh lebih sedikit, dan menulis semua data melewati akhir buffer yang dialokasikan.

CVE-2022-41903 adalah luapan bilangan bulat bertanda lainnya, kali ini format cetak cantik disalahgunakan untuk melakukan sesuatu yang tidak terduga. Lihatlah blok kode ini:

 int sb_len = sb->len, offset = 0; if (c->flush_type == flush_left) offset = padding - len; else if (c->flush_type == flush_both) offset = (padding - len) / 2; /* * we calculate padding in columns, now * convert it back to chars */ padding = padding - len + local_sb.len; strbuf_addchars(sb, ' ', padding); memcpy(sb->buf + sb_len + offset, local_sb.buf, local_sb.len);

Format eksploitasinya akan terlihat seperti ini %>(2147483647)%a%>(2147483646)%x41, di mana kode di atas dijalankan untuk setiap instance padding (The %>(#) blok) ditemukan dalam format. Pertama kali melalui kode ini menambahkan (2^31)-1 spasi ke depan string keluaran. Angka itu kebetulan merupakan nilai maksimal dari bilangan bulat bertanda empat byte. Namun blok kode di atas dijalankan di lain waktu, dan sekali lagi teks ditambahkan ke buffer, mendorong panjangnya melebihi nilai integer maksimal. Baris pertama dari blok itu melakukan cast secara implisit size_t untuk int, pengaturan sb_len ke nilai negatif.

Lalu di memcpy() panggilan, sb->buf adalah penunjuk ke awal buffer, sb_len adalah angka negatif besar yang meluap, dan offset akan menjadi nilai yang dikontrol pengguna. Ini berarti lokasi tujuan pengiriman memcpy() dapat secara tidak sengaja disetel ke lokasi memori yang lebih rendah daripada awal buffer yang dimaksudkan. Penulisan yang dikendalikan penyerang. Saya telah menambahkan beberapa pernyataan debug printf() ke blok teks ini, dan menjalankan kasus uji:

$ ./bin-wrappers/git log -1 --pretty="format:%>(2147483647)%a%>(2147483635)%s" >/dev/null
Padding: 2147483647
sb_len: 0
offset: 2147483647
Memcpy: Padding: 2147483635
sb_len: -2147483647
offset: 2147483591
Memcpy: CI: upgrade to macos-12, and pin OSX version
=================================================================
==844038==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fd8989f97c8 at pc 0x7fdb15e49d21 bp 0x7ffe8fa5c100 sp 0x7ffe8fa5b8b0
WRITE of size 44 at 0x7fd8989f97c8 thread T0
0x7fd8989f97c8 is located 56 bytes to the left of 4831838268-byte region [0x7fd8989f9800,0x7fd9b89f983c)

Kuartet keluaran pertama di sana adalah pengaturan, melapisi baris log dengan padding menjadi max int long. Kuartet kedua adalah buffer overrun, dimana sb_len diatur ke negatif, dan kemudian ditambahkan ke offset untuk memberi kita lokasi 56 byte di sebelah kiri awal buffer. Konten yang dicetak ke lokasi tersebut adalah dalam kasus ini %s, yang digantikan oleh baris subjek komit — panjangnya 44 byte. Para penulis berpendapat bahwa hal ini dapat digunakan untuk melawan “git forge”, AKA GitHub dan GitLab, karena rangkaian perangkat lunak tersebut menjalankan perintah git archive, yang dapat memanggil string cantik yang dikontrol pengguna.

Perbaikan telah dikirimkan ke kode sumber git pada tanggal 8 Desember, tetapi rilis baru yang berisi perbaikan tersebut baru saja tersedia. Ada sekitar 2200 contoh mentah int masalah, dan itu akan memakan waktu cukup lama untuk dibersihkan, bahkan dengan beberapa peretasan menyenangkan seperti itu cast_size_t_to_int(), fungsi inline yang hanya mematikan program jika 2 GB+ size_t ditangani. Jadi, perbarui!

Mailchimp — Sekali lagi

Tampaknya orang-orang di Mailchimp tidak bisa istirahat alat administrasi internal mereka diakses sekali lagi oleh penyerang, yang mengarah pada paparan 133 akun pelanggan, termasuk WooCommerce. Ini adalah ketiga kalinya Mailchimp terkena rekayasa sosial atau serangan phishing dalam setahun terakhir, dan setiap kali terjadi email spear-phishing yang dikirim ke pengguna akhir. Jadi, jika Anda berada di milis Mailchimp mana pun, ingatlah pelanggaran ini saat email terkait datang lagi. (Catatan Editor: Dua buletin Hackaday menggunakan Mailchimp, dan kami tidak diberi tahu, jadi kami yakin kami baik-baik saja.)

Ransomware Surat Kerajaan

Dalam sebuah cerita yang bisa mempunyai konsekuensi besar, itu Royal Mail Inggris mengalami serangan ransomware pada sistem mereka untuk menangani surat internasional. Serangan tersebut menggunakan Lockbit ransomware, sebuah kelompok yang diduga merupakan geng ransomware berbahasa Rusia. Hal ini bisa menjadi hal yang signifikan, karena serangan terhadap lembaga pemerintah jauh lebih serius dibandingkan serangan terhadap perusahaan. Karena Lockbit dijalankan sebagai ransomware-as-a-service, akan sangat sulit untuk menentukan secara pasti siapa yang sebenarnya melakukan serangan tersebut. Untuk saat ini, rekomendasinya sederhana: jangan mengirim surat internasional apa pun. Aduh.

Memindai Catatan SPF

[Sebastian Salla] memiliki hobi yang mungkin dianggap aneh, dalam bentuk memindai catatan SPF untuk kesalahan konfigurasi yang aneh. Dalam petualangan terbarunya, pemindaian tersebut merupakan 3 juta domain teratas yang paling banyak dikunjungi. Dan kesalahan konfigurasi ditemukan.

Tapi tunggu dulu, apa itu SPF dan mengapa kita peduli? Kerangka Kebijakan Pengirim adalah catatan txt yang merupakan bagian dari catatan DNS domain. Dan ini menentukan alamat IP apa yang sebenarnya diizinkan untuk mengirim email untuk domain tersebut. Jadi, jika email masuk mengaku berasal dari domain dengan data SPF yang valid, dan alamat IP pengirimnya tidak ada dalam data tersebut, jelas email tersebut tidak benar-benar berasal dari domain yang diklaim.

Dan penolakan email domain Anda karena masalah SPF adalah salah satu cara paling pasti untuk mendapatkan kritik. Jadi kita tergoda untuk membuat catatan SPF sedikit lebih … *liberal* dari yang seharusnya. Dan iterasi paling ekstrim dari hal ini adalah dengan menampar a +all pada catatan SPF Anda dan selesaikan. Tentu saja, hal ini memberi tahu dunia bahwa setiap pelaku spam di mana pun yang menggunakan domain Anda sebenarnya mengirimkan email asli, namun setidaknya hal ini membuat email keluar bos berfungsi kembali. Dengan lebih dari seribu domain disetel ke SPF +all, rupanya kesalahan itu lebih umum daripada yang diperkirakan.

Hal yang paling menarik adalah siapa saja di antara domain-domain yang salah dikonfigurasi tersebut, seperti beberapa lembaga pemerintah AS, domain pemerintah lain di seluruh dunia, dan beberapa universitas. Yang paling menarik adalah Kementerian Pertahanan Ukraina, dimana catatan SPF dipotong dari a -all untuk +all sekitar 4 bulan yang lalu.

Bit dan Byte

Tailscale menemukan potensi masalah serius, yaitu mengetahui ID node klien lain akan memungkinkan penyerang menambahkan node ke tailnet mereka sendiri. Ini akan menempatkan penyerang di dalam VPN Anda, dan ini jelas merupakan skenario yang buruk. Namun sebelum Anda mendapatkan garpu rumput, kode yang rentan diterapkan kurang dari empat bulan sebelum diperbaiki. Itu dilaporkan secara pribadi pada tanggal 11 bulan ini, dan ditetapkan pada tanggal 12. Dan yang lebih penting lagi, serangan tersebut meninggalkan tanda log yang dapat dipindai oleh Tailscale, dan menyimpulkan bahwa serangan tersebut diisolasi untuk pengujian pembuktian konsep. Anda dapat memeriksa dasbor Anda sendiri untuk setiap node yang dibagikan dari tailnet mereka sendiri untuk konfirmasi. Dan meskipun ini merupakan kerentanan yang buruk, bagus bagi Tailscale untuk mengungkapkannya. Banyak vendor akan mengabaikan hal ini dan tidak pernah mempublikasikannya.

Grafik Kernel Linux mengalami buffer overflow dalam kode Netfilter-nya, dimana buffer overflow dapat mengakibatkan kebocoran data dan eksekusi kode. Tidak ada jalur menuju eksploitasi jarak jauh, namun email yang tertaut di atas berisi PoC lengkap untuk eskalasi hak istimewa lokal. Dan jika eksploitasi Kernel adalah pilihan Anda, Project Zero dari Google memilikinya tulisan baru tentang subjek tersebut, semua tentang dereferensi nol.

Dan jika Anda menggunakan ManageEngine dari Zoho, hari ini rambut Anda mungkin terbakar, jika Anda belum memperbarui ke rilis yang memperbaiki CVE-2022-47966. Peneliti di Horizon3 telah merekayasa balik patch tersebut, dan membocorkan rahasia tentang RCE ini. Ini adalah masalah dalam penerapan sistem masuk tunggal SAML, sebagian karena pustaka yang sangat lama yang dikemas sebagai bagian dari produk. Ini adalah eksploitasi yang cukup mudah untuk dilakukan, jadi saatnya memeriksa kembali instalasi tersebut!

Stempel Waktu:

Lebih dari Hack Sehari