S3 Ep146: Beri tahu kami tentang pelanggaran itu! (Jika Anda menghendaki.)

Tidak ada pemutar audio di bawah? Mendengarkan langsung di Soundcloud.

---

ANJING.  Pembaruan Firefox, yang lain Bug Dengan Nama yang Mengesankan, dan SEC menuntut pengungkapan.

Semua itu, dan banyak lagi, di podcast Naked Security.

[MODEM MUSIK]

Selamat datang di podcast, semuanya.

Saya Doug Aamoth; dia adalah Paul Ducklin.

Paul, saya harap Anda akan bangga pada saya… Saya tahu Anda adalah penggemar bersepeda.

Saya mengendarai sepeda kemarin sejauh 10 mil Amerika, yang saya yakini kira-kira 16 km, sambil menarik seorang anak kecil tapi tidak berat di belakang sepeda dengan kereta roda dua.

Dan aku masih hidup untuk menceritakan kisah itu.

Apakah itu jauh untuk mengendarai sepeda, Paul?

---

BEBEK.  [TERTAWA] Itu tergantung seberapa jauh Anda benar-benar harus melangkah.

Seperti, jika sebenarnya Anda harus menempuh jarak 1200 meter dan Anda tersesat… [TERTAWA]

Antusiasme saya untuk bersepeda sangat tinggi, tapi bukan berarti saya sengaja bersepeda lebih jauh dari yang saya perlukan, karena itu cara utama saya untuk berkeliling.

Tapi 10 mil tidak apa-apa.

Tahukah Anda bahwa mil Amerika dan mil Inggris sebenarnya identik?

---

ANJING.  Itu baik untuk diketahui!

---

BEBEK.  Dan sejak tahun 1959, ketika banyak negara termasuk, menurut saya, Kanada, Afrika Selatan, Australia, Amerika Serikat, dan Inggris berkumpul dan setuju untuk membuat standar pada "inci internasional".

Saya pikir inci Imperial menjadi sangat, sangat sedikit lebih kecil dan inci Amerika menjadi sangat, sangat sedikit lebih panjang, dengan hasil bahwa inci (dan oleh karena itu pekarangan, dan kaki, dan mil)…

…mereka semua didefinisikan dalam satuan meter.

Satu inci persis 25.4mm

Tiga angka penting adalah semua yang Anda butuhkan.

---

ANJING.  Menarik!

Nah, berbicara tentang menarik, saatnya untuk kita Minggu ini dalam Sejarah Teknologi segmen.

Minggu ini, pada 01 Agustus 1981, Music Television, juga dikenal sebagai MTV, ditayangkan langsung sebagai bagian dari paket televisi kabel dan satelit Amerika, dan memperkenalkan video musik kepada publik.

Yang pertama dimainkan [SINGS, FAKTANYA BAIK] “Video Killed the Radio Star” oleh The Buggles.

Pas saat itu, meski ironis saat ini MTV jarang memutar video musik lagi, dan tidak memutar video musik baru sama sekali, Paul.

---

BEBEK.  Ya, ironis, bukan, bahwa TV kabel (dengan kata lain, di mana Anda memiliki kabel yang mengalir di bawah tanah ke rumah Anda) mematikan bintang radio (atau nirkabel), dan sekarang terlihat seperti TV kabel, MTV… semacam itu mati karena semua orang memiliki jaringan seluler yang bekerja secara nirkabel.

Apa yang terjadi akan terjadi, Douglas.

---

ANJING.  Baiklah, mari kita bicara tentang pembaruan Firefox ini.

Kami mendapatkan dosis ganda pembaruan Firefox bulan ini, karena siklusnya 28 hari:

Firefox memperbaiki banyak kekurangan dalam rilis pertama dari dua rilis bulan ini

Tidak ada nol hari di babak pertama ini, tetapi beberapa momen yang bisa diajar.

Kami telah mendaftarkan mungkin setengah dari ini di artikel Anda, dan satu yang sangat menonjol bagi saya adalah: Izin potensial meminta bypass melalui clickjacking.

---

BEBEK.  Ya, clickjacking lama yang bagus lagi.

Saya suka istilah itu karena cukup menggambarkan apa itu.

Anda mengklik di suatu tempat, mengira Anda mengklik tombol atau tautan yang tidak bersalah, tetapi Anda secara tidak sengaja mengizinkan sesuatu terjadi yang tidak jelas dari apa yang ditampilkan layar di bawah kursor mouse Anda.

Masalahnya di sini tampaknya adalah bahwa dalam keadaan tertentu, ketika dialog izin akan muncul dari Firefox, misalnya, katakan, “Apakah Anda benar-benar yakin ingin membiarkan situs web ini menggunakan kamera Anda? memiliki akses ke lokasi Anda? menggunakan mikrofon Anda?”…

… semua hal yang, ya, Anda ingin tanyakan.

Rupanya, jika Anda bisa mendapatkan browser ke titik kinerja (sekali lagi, kinerja versus keamanan) di mana ia berjuang untuk mengikuti, Anda dapat menunda munculnya pop-up izin.

Tetapi dengan memiliki tombol di tempat pop-up akan muncul, dan memikat pengguna untuk mengkliknya, Anda dapat menarik klik, tetapi klik tersebut kemudian akan dikirim ke dialog izin yang belum Anda lihat.

Semacam kondisi balapan visual, jika Anda suka.

---

ANJING.  Oke, dan yang lainnya adalah: Kanvas di luar layar dapat melewati batasan lintas asal.

Anda melanjutkan dengan mengatakan bahwa satu halaman web dapat mengintip gambar yang ditampilkan di halaman lain dari situs yang berbeda.

---

BEBEK.  Itu tidak seharusnya terjadi, bukan?

---

ANJING.  Tidak!

---

BEBEK.  Istilah jargon untuk itu adalah “same-origin policy”.

Jika Anda menjalankan situs web X dan Anda mengirimi saya sejumlah besar JavaScript yang menyetel seluruh cookie, maka semua itu disimpan di browser.

Tetapi hanya JavaScript lebih lanjut dari situs X yang dapat membaca kembali data tersebut.

Fakta bahwa Anda menjelajah ke situs X di satu tab dan situs Y di tab lain tidak membiarkan mereka mengintip apa yang dilakukan pihak lain, dan browser seharusnya memisahkan semua hal itu.

Itu jelas sangat penting.

Dan tampaknya di sini, sejauh yang saya mengerti, jika Anda merender halaman yang belum ditampilkan…

… kanvas di luar layar, tempat Anda membuat, jika Anda mau, halaman web virtual dan kemudian di beberapa titik di masa mendatang Anda berkata, "Saat ini saya siap untuk menampilkannya," dan bingo, halaman tersebut muncul semua di sekali.

Masalahnya datang dengan mencoba memastikan bahwa hal-hal yang Anda render secara tidak terlihat tidak secara tidak sengaja membocorkan data, meskipun pada akhirnya tidak pernah ditampilkan kepada pengguna.

Mereka melihatnya, atau diungkapkan secara bertanggung jawab, dan ditambal.

Dan keduanya, menurut saya, termasuk dalam apa yang disebut kerentanan tingkat "Tinggi".

Sebagian besar yang lain adalah “Sedang”, dengan pengecualian tradisional Mozilla, “Kami menemukan banyak bug melalui fuzzing dan melalui teknik otomatis; kami tidak menyelidiki mereka untuk mengetahui apakah mereka dapat dieksploitasi sama sekali, tetapi kami bersedia berasumsi bahwa seseorang yang berusaha cukup keras dapat melakukannya.

Itu adalah pengakuan yang sangat kami sukai, Doug… karena bug potensial layak untuk dihilangkan, bahkan jika Anda merasa yakin di hati bahwa tidak ada yang akan tahu cara mengeksploitasinya.

Karena dalam keamanan siber, tidak ada gunanya mengatakan tidak pernah!

---

ANJING.  Baiklah, Anda sedang mencari Firefox 116, atau jika Anda sedang dalam rilis yang diperpanjang, 115.1.

Sama dengan Thunderbird.

Dan mari kita lanjutkan ke… oh, bung!

Paul, ini menarik!

Kami memiliki BWAIN baru setelah BWAIN ganda minggu lalu: Bug Dengan Nama yang Mengesankan.

Yang ini disebut Tabrakan + Kekuatan:

Performa dan keamanan bentrok lagi dalam serangan “Collide+Power”.

---

BEBEK.  [TERTAWA] Ya, itu menarik, bukan, bahwa mereka memilih nama yang memiliki tanda plus di dalamnya?

---

ANJING.  Ya, itu membuatnya sulit untuk dikatakan.

---

BEBEK.  Anda tidak dapat memiliki tanda tambah di nama domain Anda, jadi nama domainnya adalah collidepower.com.

---

ANJING.  Baiklah, izinkan saya membaca dari para peneliti sendiri, dan saya kutip:

Akar masalahnya adalah bahwa komponen CPU bersama, seperti sistem memori internal, menggabungkan data penyerang dan data dari aplikasi lain, menghasilkan sinyal kebocoran gabungan dalam konsumsi daya.

Dengan demikian, dengan mengetahui datanya sendiri, penyerang dapat menentukan nilai data yang tepat yang digunakan di aplikasi lain.

---

BEBEK.  [TERTAWA] Ya, sangat masuk akal jika Anda sudah tahu apa yang mereka bicarakan!

Untuk mencoba dan menjelaskan ini dalam bahasa Inggris sederhana (saya harap saya mengerti ini dengan benar)…

Ini turun ke masalah kinerja versus keamanan yang telah kita bicarakan sebelumnya, termasuk podcast minggu lalu dengan itu Zenbleed bug (omong-omong, yang jauh lebih serius):

Zenbleed: Bagaimana pencarian kinerja CPU dapat membahayakan kata sandi Anda

Ada banyak sekali data yang disimpan di dalam CPU ("cache" adalah istilah teknis untuk itu) sehingga CPU tidak perlu pergi dan mengambilnya nanti.

Jadi ada banyak hal internal yang tidak bisa Anda kelola; CPU menjaganya untuk Anda.

Dan inti dari serangan ini sepertinya seperti ini…

Yang dilakukan penyerang adalah mengakses berbagai lokasi memori sedemikian rupa sehingga penyimpanan cache internal mengingat lokasi memori tersebut, sehingga tidak perlu pergi dan membacanya lagi dari RAM jika digunakan kembali dengan cepat.

Jadi penyerang entah bagaimana mengisi nilai cache ini dengan pola bit yang diketahui, nilai data yang diketahui.

Kemudian, jika korban memiliki memori yang *mereka* sering gunakan (misalnya, byte dalam kunci dekripsi), jika nilainya tiba-tiba dinilai oleh CPU lebih mungkin untuk digunakan kembali daripada salah satu nilai penyerang, itu mengeluarkan nilai penyerang dari lokasi cache super cepat internal itu, dan menempatkan nilai baru, nilai korban, di sana.

Dan apa yang ditemukan para peneliti ini (dan sejauh serangan itu terdengar dalam teori dan dalam praktiknya, ini adalah hal yang cukup menakjubkan untuk ditemukan)…

Jumlah bit yang berbeda antara nilai lama di cache dan nilai baru *mengubah jumlah daya yang diperlukan untuk melakukan operasi pembaruan cache*.

Oleh karena itu, jika Anda dapat mengukur konsumsi daya CPU dengan cukup tepat, Anda dapat membuat kesimpulan tentang nilai data mana yang ditulis ke dalam memori cache internal, tersembunyi, atau tidak terlihat di dalam CPU yang dianggap CPU bukan urusan Anda.

Cukup menarik, Doug!

---

ANJING.  Luar biasa.

Oke, ada beberapa mitigasi.

Bagian itu dimulai dengan: "Pertama-tama, Anda tidak perlu khawatir," tetapi juga hampir semua CPU terpengaruh.

---

BEBEK.  Ya, itu menarik, bukan?

Dikatakan "pertama-tama" (teks normal) "kamu” (dalam huruf miring) “tidak perlu khawatir" (dalam huruf tebal). [TERTAWA]

Jadi, pada dasarnya, tidak ada yang akan menyerang Anda dengan ini, tetapi mungkin perancang CPU ingin memikirkan hal ini di masa mendatang jika ada jalan lain. [TERTAWA]

Saya pikir itu cara yang menarik untuk menggambarkannya.

---

ANJING.  Oke, jadi mitigasinya pada dasarnya mematikan hyperthreading.

Apakah itu cara kerjanya?

---

BEBEK.  Hyperthreading membuat ini jauh lebih buruk, sejauh yang saya bisa lihat.

Kita sudah tahu bahwa hyperthreading adalah masalah keamanan karena ada banyak kerentanan yang bergantung padanya sebelumnya.

Di situlah CPU, katakanlah, dengan delapan inti berpura-pura memiliki 16 inti, tetapi sebenarnya mereka tidak berada di bagian chip yang terpisah.

Mereka sebenarnya sepasang pseudo-core yang berbagi lebih banyak elektronik, lebih banyak transistor, lebih banyak kapasitor, daripada mungkin ide yang bagus untuk alasan keamanan.

Jika Anda menjalankan OpenBSD lama yang bagus, saya pikir mereka memutuskan hyperthreading terlalu sulit untuk diamankan dengan mitigasi; mungkin juga matikan saja.

Pada saat Anda mengambil hit kinerja yang diperlukan mitigasi, Anda mungkin juga tidak memilikinya.

Jadi saya berpikir bahwa mematikan hyperthreading akan sangat mengimunisasi Anda terhadap serangan ini.

Hal kedua yang dapat Anda lakukan adalah, seperti yang penulis katakan dengan huruf tebal: jangan khawatir. [TAWA]

---

ANJING.  Itu mitigasi yang bagus! [TERTAWA]

---

BEBEK.   Ada banyak hal (saya harus membaca ini, Doug)…

Ada bagian yang bagus di mana para peneliti sendiri menemukan bahwa untuk mendapatkan informasi yang dapat diandalkan sama sekali, mereka mendapatkan kecepatan data antara 10 bit dan 100 bit per jam dari sistem.

Saya percaya bahwa setidaknya CPU Intel memiliki mitigasi yang menurut saya akan membantu mengatasi hal ini.

Dan ini membawa kita kembali ke MSR, register khusus model yang kita bicarakan minggu lalu dengan Zenbleed, di mana ada bagian ajaib yang dapat Anda aktifkan yang berbunyi, "Jangan lakukan hal berisiko."

Ada fitur yang dapat Anda atur disebut penyaringan RAPL, dan RAPL adalah kependekan dari menjalankan batas daya rata-rata.

Ini digunakan oleh program mana yang ingin melihat kinerja CPU untuk tujuan manajemen daya, jadi Anda tidak perlu masuk ke ruang server dan memasang monitor daya ke kabel dengan probe kecil di motherboard. [TERTAWA]

Anda sebenarnya bisa membuat CPU memberi tahu Anda berapa banyak daya yang digunakannya.

Intel setidaknya memiliki mode ini yang disebut penyaringan RAPL, yang sengaja memperkenalkan jitter atau kesalahan.

Jadi, Anda akan mendapatkan hasil yang, rata-rata, akurat, tetapi pembacaan setiap individu akan tidak aktif.

---

ANJING.  Sekarang mari kita mengalihkan perhatian kita ke kesepakatan SEC yang baru ini.

Komisi Keamanan dan Pertukaran menuntut batas pengungkapan empat hari untuk pelanggaran keamanan siber:

SEC menuntut batas pengungkapan empat hari untuk pelanggaran keamanan siber

Tapi (A) Anda harus memutuskan apakah serangan cukup serius untuk dilaporkan, dan (B) batas empat hari tidak dimulai sampai Anda memutuskan sesuatu yang cukup penting untuk dilaporkan, Paul.

Jadi, awal yang bagus, tapi mungkin tidak seagresif yang kita inginkan?

---

BEBEK.  Saya setuju dengan penilaian Anda di sana, Doug.

Kedengarannya bagus ketika saya pertama kali melihatnya: "Hei, Anda mendapatkan pengungkapan empat hari ini jika Anda memiliki pelanggaran data atau masalah keamanan siber."

Tapi kemudian ada sedikit tentang, "Yah, itu harus dianggap sebagai masalah material," sebuah istilah hukum yang berarti bahwa itu sebenarnya cukup penting untuk diungkapkan sejak awal.

Dan kemudian saya sampai pada bagian itu (dan itu bukan siaran pers yang sangat panjang dari SEC) yang mengatakan, “Segera setelah Anda memutuskan bahwa Anda benar-benar harus melaporkan ini, maka Anda masih punya waktu empat hari. untuk melaporkannya.”

Sekarang, saya membayangkan bahwa, secara hukum, itu tidak akan berhasil. Doug

Mungkin kita sedikit keras dalam artikel ini?

---

ANJING.  Anda memperbesar serangan ransomware, mengatakan bahwa ada beberapa jenis yang berbeda, jadi mari kita bicarakan… penting untuk menentukan apakah ini serangan material yang perlu Anda laporkan.

Jadi jenis ransomware apa yang sedang kita lihat?

---

BEBEK.  Ya, hanya untuk menjelaskan, saya pikir itu adalah bagian penting dari ini.

Bukan untuk menuding SEC, tapi ini adalah sesuatu yang tampaknya belum keluar di banyak atau negara mana pun…

…apakah hanya menderita serangan ransomware sudah cukup untuk menjadi pelanggaran data material.

Dokumen SEC ini sebenarnya tidak menyebutkan "kata-R" sama sekali.

Tidak disebutkan hal-hal khusus ransomware.

Dan ransomware adalah masalah, bukan?

Dalam artikel tersebut, saya ingin memperjelas bahwa kata “ransomware”, yang masih banyak kita gunakan, bukanlah kata yang tepat lagi, bukan?

Kita mungkin harus menyebutnya "blackmailware" atau cukup "cyberextortion".

Saya mengidentifikasi tiga jenis utama serangan ransomware.

Tipe A adalah tempat penjahat tidak mencuri data Anda, mereka hanya mengacak data Anda di situ.

Jadi mereka tidak perlu mengunggah satu hal pun.

Mereka mengacak semuanya sedemikian rupa sehingga mereka dapat memberi Anda kunci dekripsi, tetapi Anda tidak akan melihat satu byte data pun meninggalkan jaringan Anda sebagai tanda bahwa sesuatu yang buruk sedang terjadi.

Lalu ada serangan ransomware Tipe B, di mana para penjahat pergi, “Anda tahu, kami tidak akan mengambil risiko menulis ke semua file, ketahuan melakukan itu. Kami hanya akan mencuri semua data, dan alih-alih membayar uang untuk mendapatkan kembali data Anda, Anda membayar untuk kebisuan kami.

Dan kemudian, tentu saja, ada serangan ransomware Tipe C, dan itu adalah: “Baik A maupun B.”

Di situlah penjahat mencuri data Anda * dan * mereka mengacaknya dan berkata, "Hei, jika bukan satu hal yang akan membuat Anda dalam masalah, itu yang lain."

Dan alangkah baiknya untuk mengetahui di mana menurut saya profesi hukum menyebut materialitas (dengan kata lain, signifikansi hukum atau relevansi hukum dengan peraturan tertentu)…

… di mana itu terjadi, dalam kasus serangan ransomware.

---

ANJING.  Nah, ini saat yang tepat untuk menghadirkan Komentator Minggu Ini, Adam, dalam cerita ini.

Adam memberikan pemikirannya tentang berbagai jenis serangan ransomware.

Jadi, dimulai dengan Tipe A, di mana itu hanya serangan ransomware langsung, di mana mereka mengunci file dan meninggalkan catatan tebusan untuk membukanya…

adam berkata:

Jika sebuah perusahaan terkena ransomware, tidak menemukan bukti eksfiltrasi data setelah penyelidikan menyeluruh, dan memulihkan data mereka tanpa membayar uang tebusan, maka saya cenderung mengatakan, "Tidak [diperlukan pengungkapan]."

---

BEBEK.  Anda telah melakukan cukup?

---

ANJING.  Ya.

---

BEBEK.  Anda tidak cukup mencegahnya, tetapi Anda melakukan hal terbaik berikutnya, jadi Anda tidak perlu memberi tahu investor Anda….

Ironisnya, Doug, jika Anda melakukan itu sebagai sebuah perusahaan, Anda mungkin ingin memberi tahu investor Anda, “Hei, coba tebak? Kami mengalami serangan ransomware seperti orang lain, tetapi kami berhasil keluar tanpa membayar uang, tanpa terlibat dengan penjahat, dan tanpa kehilangan data apa pun. Jadi meskipun kami tidak sempurna, kami adalah hal terbaik berikutnya.”

Dan sebenarnya mungkin sangat berat untuk mengungkapkannya secara sukarela, bahkan jika hukum mengatakan Anda tidak perlu melakukannya.

---

ANJING.  Dan kemudian, untuk Tipe B, sudut pemerasan, Adam berkata:

Itu situasi yang sulit.

Secara teoritis, saya akan mengatakan, "Ya."

Tapi itu kemungkinan akan menyebabkan banyak pengungkapan dan merusak reputasi bisnis.

Jadi, jika Anda memiliki banyak perusahaan yang keluar dan berkata, “Lihat, kami terkena ransomware; kami tidak berpikir hal buruk terjadi; kami membayar para penjahat untuk membuat mereka diam; dan kami percaya bahwa mereka tidak akan membocorkan rahasia, ”bisa dikatakan…

…itu memang menciptakan situasi yang rumit, karena dapat merusak reputasi perusahaan, tetapi jika mereka tidak mengungkapkannya, tidak akan ada yang tahu.

---

BEBEK.  Dan saya melihat bahwa Adam merasakan hal yang sama seperti Anda dan saya tentang urusan, "Anda memiliki empat hari, dan tidak lebih dari empat hari... sejak saat Anda berpikir bahwa empat hari harus dimulai."

Dia juga mengacau, bukan?

Dia berkata:

Beberapa perusahaan kemungkinan besar akan mengadopsi taktik untuk sangat menunda memutuskan apakah ada dampak material.

Jadi, kami tidak begitu tahu bagaimana ini akan terjadi, dan saya yakin SEC juga tidak tahu.

Mungkin diperlukan beberapa uji kasus bagi mereka untuk mengetahui jumlah birokrasi yang tepat untuk memastikan bahwa kita semua mempelajari apa yang perlu kita ketahui, tanpa memaksa perusahaan untuk mengungkapkan setiap kesalahan kecil TI yang pernah terjadi dan mengubur kita semua dalam sebuah beban dokumen.

Yang pada dasarnya mengarah pada kelelahan istirahat, bukan?

Jika Anda mendapat begitu banyak berita buruk yang tidak terlalu penting hanya membanjiri Anda…

… entah bagaimana, mudah untuk melewatkan hal-hal yang sangat penting yang ada di antara semua pertanyaan "apakah saya benar-benar perlu mendengar tentang itu?"

Waktu akan memberi tahu, Douglas.

---

ANJING.  Ya, rumit!

Dan saya tahu saya mengatakan ini sepanjang waktu, tetapi kami akan mengawasi ini, karena akan sangat menarik untuk menyaksikan ini terungkap.

Jadi, terima kasih, Adam, telah mengirimkan komentar itu.

---

BEBEK.  Ya memang!

---

ANJING.  Jika Anda memiliki cerita menarik, komentar atau pertanyaan yang ingin Anda sampaikan, kami akan senang membaca di podcast.

Anda dapat mengirim email ke tips@sophos.com, Anda dapat mengomentari salah satu artikel kami, atau Anda dapat menghubungi kami di sosial: @nakedsecurity.

Itu acara kami untuk hari ini; terima kasih banyak untuk mendengarkan.

Untuk Paul Ducklin, saya Doug Aamoth, mengingatkan Anda sampai waktu berikutnya untuk…

---

KEDUA.  Tetap aman.

[MODEM MUSIK]