S3 Ep95: Kebocoran kendur, serangan Github, dan kripto pasca-kuantum [Audio + Teks]

Klik-dan-tarik gelombang suara di bawah untuk melompat ke titik mana pun. Anda juga bisa dengarkan langsung di Soundcloud.

ANJING.  Kebocoran kendur, kode GitHub nakal, dan kriptografi pasca-kuantum.

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

[MODEM MUSIK]

Selamat datang di podcast, semuanya.

Saya Doug Aamoth.

Dengan saya, seperti biasa, adalah Paul Ducklin.

Paulus, bagaimana kabarmu hari ini?

---

BEBEK.  Super duper, seperti biasa, Doug!

---

ANJING.  Saya sangat-duper bersemangat untuk mencapai minggu ini Sejarah Teknologi segmen, karena…

... Anda ada di sana, kawan!

Minggu ini, pada 11 Agustus…

---

BEBEK.  Oh tidak!

Saya pikir sen baru saja jatuh ...

---

ANJING.  Saya bahkan tidak perlu menyebutkan tahunnya!

11 Agustus 2003 - dunia memperhatikan worm Blaster, mempengaruhi sistem Windows 2000 dan Windows XP.

Blaster, juga dikenal sebagai Lovesan dan MsBlast, mengeksploitasi buffer overflow dan mungkin paling dikenal karena pesannya, “Billy Gates, mengapa Anda membuat ini mungkin? Berhenti menghasilkan uang dan perbaiki perangkat lunak Anda.”

Apa yang terjadi, Paulus?

---

BEBEK.  Yah, itu era sebelumnya, mungkin, kami menganggap keamanan dengan sangat serius.

Dan, untungnya, bug semacam itu akan jauh lebih sulit untuk dieksploitasi akhir-akhir ini: itu adalah buffer overflow berbasis stack.

Dan jika saya ingat dengan benar, versi server Windows sudah dibangun dengan apa yang disebut perlindungan tumpukan.

Dengan kata lain, jika Anda membanjiri tumpukan di dalam suatu fungsi, maka, sebelum fungsi itu kembali dan merusak tumpukan yang rusak, itu akan mendeteksi bahwa sesuatu yang buruk telah terjadi.

Jadi, itu harus mematikan program yang menyinggung, tetapi malware tidak bisa berjalan.

Tetapi perlindungan itu tidak ada di versi klien Windows pada waktu itu.

Dan seingat saya, itu adalah salah satu malware awal yang harus menebak versi sistem operasi yang Anda miliki.

Apakah Anda pada tahun 2000? Apakah Anda di NT? Apakah Anda di XP?

Dan jika salah, maka bagian penting dari sistem akan macet, dan Anda akan mendapatkan peringatan "Sistem Anda akan dimatikan".

---

ANJING.  Ha, aku ingat itu!

---

BEBEK.  Jadi, ada kerusakan tambahan yang, bagi banyak orang, merupakan tanda bahwa Anda terkena infeksi…

…yang bisa dari luar, seperti jika Anda hanya pengguna rumahan dan Anda tidak memiliki router atau firewall di rumah.

Tetapi jika Anda berada di dalam perusahaan, kemungkinan besar serangan akan datang dari orang lain di dalam perusahaan, memuntahkan paket di jaringan Anda.

Jadi, sangat mirip dengan serangan CodeRed yang kita bicarakan, yang terjadi beberapa tahun sebelumnya, dalam podcast baru-baru ini, itu benar-benar skala, volume, dan kecepatan dari hal ini yang menjadi masalahnya.

---

ANJING.  Baiklah, itu sekitar 20 tahun yang lalu.

Dan jika kita memutar waktu kembali ke lima tahun yang lalu, saat itulah Slack mulai bocor kata sandi yang di-hash. [TAWA]

---

BEBEK.  Ya, Slack, alat kolaborasi populer…

…memiliki fitur di mana Anda dapat mengirim tautan undangan ke orang lain untuk bergabung dengan ruang kerja Anda.

Dan, bayangkan: Anda mengklik tombol yang bertuliskan "Generate a link", dan itu akan membuat semacam paket jaringan yang mungkin memiliki beberapa JSON di dalamnya.

Jika Anda pernah memiliki undangan rapat Zoom, Anda akan tahu bahwa itu memiliki tanggal, dan waktu, dan orang yang mengundang Anda, dan URL yang dapat Anda gunakan untuk rapat, dan kode sandi, dan semua itu hal - itu memiliki cukup banyak data di sana.

Biasanya, Anda tidak menggali data mentah untuk melihat apa yang ada di sana – klien hanya berkata, “Hei, ini rapat, ini detailnya. Apakah Anda ingin Menerima / Mungkin / Menolak?”

Ternyata ketika Anda melakukan ini dengan Slack, seperti yang Anda katakan, selama lebih dari lima tahun, yang dikemas dalam undangan itu adalah data asing yang tidak sepenuhnya relevan dengan undangan itu sendiri.

Jadi, bukan URL, bukan nama, bukan tanggal, bukan waktu…

…tapi *mengundang hash kata sandi pengguna* [TERTAWA]

---

ANJING.  hmmm.

---

BEBEK.  Saya tidak bercanda!

---

ANJING.  Itu terdengar buruk…

---

BEBEK.  Ya, itu benar-benar, bukan?

Berita buruknya adalah, bagaimana itu bisa ada di sana?

Dan, begitu berada di sana, bagaimana bisa ia luput dari perhatian selama lima tahun tiga bulan?

Bahkan, jika Anda mengunjungi artikel tentang Keamanan Telanjang dan melihat URL lengkap artikel, Anda akan melihat tulisan di akhir, blahblahblah-for-three-months.

Karena, ketika saya pertama kali membaca laporan itu, pikiran saya tidak ingin melihatnya sebagai 2017! [TAWA]

Saat itu 17 April hingga 17 Juli, jadi ada banyak "17" di sana.

Dan pikiran saya mengabaikan 2017 sebagai tahun awal – saya salah membacanya sebagai “April hingga Juli *tahun ini*” [2022].

Saya berpikir, “Wow, *tiga bulan* dan mereka tidak menyadarinya.”

Dan kemudian komentar pertama pada artikel itu adalah, “Ehem [BATUK]. Itu sebenarnya 17 April *2017*.”

Wow!

Tetapi seseorang mengetahuinya pada 17 Juli [2022], dan Slack, untuk kredit mereka, memperbaikinya pada hari yang sama.

Seperti, "Oh, astaga, apa yang kita pikirkan?!"

Jadi itu berita buruknya.

Berita baiknya adalah, setidaknya itu adalah kata sandi * hash *.

Dan mereka tidak hanya di-hash, tetapi juga *salted*, di mana Anda mencampur data acak per pengguna yang dipilih secara unik dengan kata sandi.

Gagasan tentang ini ada dua.

Pertama, jika dua orang memilih kata sandi yang sama, mereka tidak mendapatkan hash yang sama, jadi Anda tidak dapat membuat kesimpulan apa pun dengan melihat melalui basis data hash.

Dan dua, Anda tidak dapat menghitung sebelumnya kamus hash yang diketahui untuk input yang diketahui, karena Anda harus membuat kamus terpisah untuk setiap kata sandi *untuk setiap garam*.

Jadi bukan latihan sepele untuk memecahkan kata sandi yang di-hash.

Karena itu, seluruh gagasannya adalah bahwa mereka tidak seharusnya menjadi masalah catatan publik.

Mereka di-hash dan diasinkan *jika* bocor, bukan *agar bisa* bocor.

Jadi, telur di wajah Slack!

Slack mengatakan bahwa sekitar satu dari 200 pengguna, atau 0.5%, terpengaruh.

Tetapi jika Anda adalah pengguna Slack, saya akan berasumsi bahwa jika mereka tidak menyadari bahwa mereka membocorkan kata sandi hash selama lima tahun, mungkin mereka juga tidak menghitung daftar orang yang terpengaruh sepenuhnya.

Jadi, pergi dan ubah kata sandi Anda ... Anda mungkin juga.

---

ANJING.  Oke, kami juga mengatakan: jika Anda tidak menggunakan pengelola kata sandi, pertimbangkan untuk mendapatkannya; dan nyalakan 2FA jika Anda bisa.

---

BEBEK.  Saya pikir Anda akan seperti itu, Doug.

---

ANJING.  Ya, saya bersedia!

Dan kemudian, jika Anda Slack atau perusahaan seperti itu, pilih a algoritma salt-hash-and-stretch terkemuka saat menangani kata sandi sendiri.

---

BEBEK.  Ya.

Masalah besar dalam respons Slack, dan hal yang menurut saya kurang, adalah mereka hanya berkata, "Jangan khawatir, kami tidak hanya meng-hash kata sandi, kami juga mengasinkannya."

Saran saya adalah jika Anda terjebak dalam pelanggaran seperti ini, maka Anda harus bersedia mendeklarasikan algoritma atau proses yang Anda gunakan untuk pengasinan dan hashing, dan juga idealnya apa yang disebut peregangan, yang mana Anda tidak hanya meng-hash kata sandi yang diasinkan sekali, tetapi mungkin Anda mem-hash-nya 100,000 kali untuk memperlambat segala jenis kamus atau serangan brute force.

Dan jika Anda menyatakan algoritma apa yang Anda gunakan dan dengan parameter apa.. misalnya, PBKDF2, bcrypt, scrypt, Argon2 – itu adalah algoritma “salt-hash-stretch” kata sandi paling terkenal di luar sana.

Jika Anda benar-benar menyatakan algoritme apa yang Anda gunakan, maka: [A] Anda bersikap lebih terbuka, dan [B] Anda memberi calon korban masalah kesempatan untuk menilai sendiri seberapa berbahayanya hal ini menurut mereka .

Dan keterbukaan semacam itu sebenarnya bisa banyak membantu.

Slack tidak melakukan itu.

Mereka hanya berkata, "Oh, mereka diasinkan dan diasamkan."

Tapi yang tidak kita ketahui adalah, apakah mereka memasukkan dua byte garam dan kemudian mem-hash-nya sekali dengan SHA-1…

…atau apakah mereka memiliki sesuatu yang sedikit lebih tahan terhadap retak?

---

ANJING.  Berpegang pada subjek hal-hal buruk, kami memperhatikan tren yang berkembang di mana orang-orang berada menyuntikkan hal-hal buruk ke GitHub, hanya untuk melihat apa yang terjadi, mengekspos risiko…

...kami punya satu lagi dari cerita-cerita itu.

---

BEBEK.  Ya, seseorang yang sekarang diduga keluar di Twitter dan berkata, “Jangan khawatir teman-teman, tidak ada salahnya. Itu hanya untuk penelitian. Saya akan menulis laporan, menonjol dari Blue Alert. ”

Mereka menciptakan ribuan proyek GitHub palsu, berdasarkan penyalinan kode resmi yang ada, dengan sengaja memasukkan beberapa perintah malware di sana, seperti "menelepon ke rumah untuk instruksi lebih lanjut", dan "menafsirkan isi balasan sebagai kode pintu belakang untuk dieksekusi", dan segera.

Jadi, hal-hal yang benar-benar dapat membahayakan jika Anda menginstal salah satu dari paket-paket ini.

Memberi mereka nama yang terlihat sah…

…meminjam, tampaknya, riwayat komit dari proyek asli sehingga hal itu tampak jauh lebih sah daripada yang mungkin Anda harapkan jika hanya muncul dengan, “Hei, unduh file ini. Anda tahu Anda mau!”

Betulkah?! Riset?? Kami belum tahu ini?!!?

Sekarang, Anda dapat berdebat, "Yah, Microsoft, yang memiliki GitHub, apa yang mereka lakukan sehingga orang-orang dapat dengan mudah mengunggah hal-hal semacam ini?"

Dan ada beberapa kebenaran untuk itu.

Mungkin mereka bisa melakukan pekerjaan yang lebih baik untuk mencegah malware keluar.

Tapi itu akan sedikit berlebihan untuk mengatakan, "Oh, itu semua salah Microsoft."

Lebih buruk lagi menurut saya, untuk mengatakan, “Ya, ini adalah penelitian asli; ini sangat penting; kita harus mengingatkan orang bahwa ini bisa terjadi.”

Nah, [A] kami sudah tahu itu, terima kasih banyak, karena banyak orang telah melakukan ini sebelumnya; kami mendapat pesan keras dan jelas.

Dan [B] ini *bukan* penelitian.

Ini dengan sengaja mencoba mengelabui orang agar mengunduh kode yang memberikan kendali jarak jauh kepada penyerang potensial, dengan imbalan kemampuan untuk menulis laporan.

Itu terdengar lebih seperti "alasan besar" bagi saya daripada motivator yang sah untuk penelitian.

Jadi rekomendasi saya adalah, jika menurut Anda ini *adalah* penelitian, dan jika Anda bertekad untuk melakukan hal seperti ini lagi, *jangan berharap banyak simpati* jika Anda ketahuan.

---

ANJING.  Baiklah - kami akan kembali ke ini dan komentar pembaca di akhir acara, jadi tetaplah di sini.

Tapi pertama-tama, mari kita bicara tentang lampu lalu lintas, dan apa hubungannya dengan keamanan siber.

---

BEBEK.  Ahh, ya! [TERTAWA]

Nah, ada yang namanya TLP, Protokol Lampu Lalu Lintas.

Dan TLP adalah apa yang Anda sebut sebagai "protokol penelitian keamanan siber manusia" yang membantu Anda memberi label pada dokumen yang Anda kirim ke orang lain, untuk memberi mereka petunjuk tentang apa yang Anda harapkan akan mereka lakukan (dan, yang lebih penting, apa yang Anda harapkan akan mereka lakukan * tidak*) lakukan dengan data.

Secara khusus, seberapa luas mereka seharusnya mendistribusikannya kembali?

Apakah ini sesuatu yang sangat penting sehingga Anda bisa menyatakannya kepada dunia?

Atau apakah ini berpotensi berbahaya, atau apakah itu berpotensi mencakup beberapa hal yang belum ingin kami publikasikan... jadi simpan sendiri?

Dan itu dimulai dengan: TLP:RED, yang artinya, “Simpanlah untuk dirimu sendiri”; TLP:AMBER, yang berarti “Anda dapat mengedarkannya di dalam perusahaan Anda sendiri atau kepada pelanggan Anda yang menurut Anda mungkin sangat perlu mengetahuinya”; TLP:GREEN, yang berarti, “Oke, Anda dapat membiarkan ini beredar luas di dalam komunitas keamanan siber.”

Dan TLP:WHITE, yang berarti, "Anda dapat memberi tahu siapa pun."

Sangat berguna, sangat sederhana: MERAH, KUNING, HIJAU… metafora yang bekerja secara global, tanpa khawatir tentang apa perbedaan antara "rahasia" dan "rahasia" dan apa perbedaan antara "rahasia" dan "rahasia", semua hal rumit yang membutuhkan banyak undang-undang di sekitarnya.

Nah, TLP baru saja mendapat beberapa modifikasi.

Jadi, jika Anda tertarik dengan penelitian keamanan siber, pastikan Anda mengetahuinya.

TLP:WHITE telah diubah menjadi apa yang saya anggap sebagai istilah yang jauh lebih baik sebenarnya, karena putih memiliki semua nuansa budaya yang tidak perlu yang dapat kita lakukan tanpanya di era modern.

Jadi, TLP:WHITE baru saja menjadi TLP:CLEAR, yang menurut saya adalah kata yang jauh lebih baik karena mengatakan, "Anda dapat menggunakan data ini," dan niat itu dinyatakan, ahem, dengan sangat jelas. (Maaf, saya tidak bisa menahan permainan kata-kata itu.)

Dan ada lapisan tambahan (jadi ini sedikit merusak metafora – sekarang menjadi *lima*-warna lampu lalu lintas warna!).

Ada level khusus yang disebut TLP:AMBER+STRICT, dan artinya, “Anda dapat membagikan ini di dalam perusahaan Anda.”

Jadi Anda mungkin diundang ke rapat, mungkin Anda bekerja untuk perusahaan keamanan siber, dan cukup jelas bahwa Anda perlu menunjukkan ini kepada pemrogram, mungkin kepada tim TI Anda, mungkin kepada orang penjaminan kualitas Anda, sehingga Anda dapat melakukan penelitian masalah atau cara mengatasinya.

Tapi TLP:AMBER+STRICT artinya meskipun Anda dapat mengedarkannya di dalam organisasi Anda, *jangan beri tahu klien atau pelanggan Anda*, atau bahkan orang di luar perusahaan yang menurut Anda perlu diketahui.

Simpan dalam komunitas yang lebih ketat untuk memulai.

TLP:AMBER, seperti sebelumnya, berarti, "Oke, jika Anda merasa perlu memberi tahu pelanggan Anda, Anda bisa."

Dan itu bisa menjadi penting, karena terkadang Anda mungkin ingin memberi tahu pelanggan Anda, “Hei, kami punya perbaikan. Anda harus mengambil beberapa langkah pencegahan sebelum perbaikan tiba. Tetapi karena ini agak sensitif, bolehkah kami meminta Anda untuk tidak memberi tahu dunia dulu? ”

Terkadang, memberi tahu dunia terlalu dini sebenarnya lebih banyak dimainkan oleh para penjahat daripada di tangan para pembela.

Jadi, jika Anda seorang responden keamanan siber, saya sarankan Anda pergi: https://www.first.org/tlp

---

ANJING.  Dan kamu bisa baca lebih lanjut tentang itu di situs kami, telanjangsecurity.sophos.com.

Dan jika Anda mencari bacaan ringan lainnya, lupakan kriptografi kuantum… kita beralih ke kriptografi pasca-kuantum, Paulus!

---

BEBEK.  Ya, kita sudah membicarakan ini beberapa kali sebelumnya di podcast, bukan?

Gagasan komputer kuantum, dengan asumsi komputer yang cukup kuat dan andal dapat dibangun, adalah bahwa jenis algoritma tertentu dapat dipercepat di atas keadaan seni saat ini, baik untuk nada akar kuadrat ... atau lebih buruk lagi, *logaritma* dari skala masalah hari ini.

Dengan kata lain, alih-alih mengambil 2²⁵⁶ mencoba menemukan file dengan hash tertentu, Anda mungkin dapat melakukannya hanya ("hanya"!) 2¹²⁸ mencoba, yang merupakan akar kuadrat.

Jelas jauh lebih cepat.

Tapi ada seluruh kelas masalah yang melibatkan produk faktorisasi bilangan prima yang menurut teori dapat dipecahkan dalam *logaritma* dari waktu yang mereka ambil hari ini, secara longgar.

Jadi, alih-alih mengambil, katakanlah, 2¹²⁸ hari untuk retak [JAUH LEBIH LAMA DARI USIA ALAM SEMESTA SAAT INI], mungkin hanya perlu 128 hari untuk retak.

Atau Anda dapat mengganti "hari" dengan "menit", atau apa pun.

Dan sayangnya, algoritma waktu logaritmik itu (disebut Algoritma Faktorisasi Kuantum Shor)… yang secara teori dapat diterapkan pada beberapa teknik kriptografi saat ini, terutama yang digunakan untuk kriptografi kunci publik.

Dan, seandainya perangkat komputasi kuantum ini menjadi layak dalam beberapa tahun ke depan, mungkin kita harus mulai mempersiapkan sekarang untuk algoritma enkripsi yang tidak rentan terhadap dua kelas serangan tertentu ini?

Khususnya yang logaritma, karena mempercepat serangan potensial sedemikian rupa sehingga kunci kriptografi yang saat ini kita pikirkan, "Yah, tidak ada yang akan pernah mengetahuinya," mungkin akan terungkap pada tahap selanjutnya.

Bagaimanapun, NIST, itu Institut Nasional Standar dan Teknologi di AS, selama beberapa tahun telah mengadakan kompetisi untuk mencoba dan menstandarisasi beberapa algoritme publik, yang tidak dipatenkan, dan diteliti dengan baik yang akan tahan terhadap komputer kuantum ajaib ini, jika mereka muncul.

Dan baru-baru ini mereka memilih empat algoritme yang siap mereka standarkan sekarang.

Mereka memiliki nama yang keren, Doug, jadi saya harus membacanya: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCON, dan SPHINCS+. [TAWA]

Jadi mereka memiliki nama yang keren, jika tidak ada yang lain.

Tetapi, pada saat yang sama, NIST berpikir, “Ya, itu hanya empat algoritma. Apa yang akan kami lakukan adalah kami akan memilih empat lagi sebagai calon sekunder yang potensial, dan kami akan melihat apakah salah satu dari mereka harus lolos juga.”

Jadi ada empat algoritme standar sekarang, dan empat algoritme yang mungkin akan distandarisasi di masa depan.

Atau *ada* empat pada tanggal 5 Juli 2022, dan salah satunya adalah SIKE, kependekan dari enkapsulasi kunci isogeni supersingular.

(Kami memerlukan beberapa podcast untuk menjelaskan isogeni supersingular, jadi kami tidak akan repot. [TERTAWA])

Tapi, sayangnya, yang ini, yang bertahan di sana dengan peluang berjuang untuk distandarisasi, sepertinya telah rusak tanpa bisa diperbaiki, meskipun setidaknya lima tahun telah terbuka untuk pengawasan publik.

Jadi, untungnya, tepat sebelum atau dapat distandarisasi, dua kriptografer Belgia menemukan, “Tahukah Anda? Kami pikir kami punya cara untuk mengatasinya dengan menggunakan perhitungan yang memakan waktu sekitar satu jam, pada CPU yang cukup rata-rata, hanya menggunakan satu inti.”

---

ANJING.  Saya kira lebih baik untuk mengetahuinya sekarang daripada setelah menstandarkannya dan mengeluarkannya di alam liar?

---

BEBEK.  Memang!

Saya kira jika itu adalah salah satu algoritma yang sudah distandarisasi, mereka harus mencabut standar dan membuat yang baru?

Tampaknya aneh bahwa ini tidak diperhatikan selama lima tahun.

Tapi saya rasa itulah keseluruhan gagasan pengawasan publik: Anda tidak pernah tahu kapan seseorang mungkin baru saja menemukan celah yang dibutuhkan, atau irisan kecil yang dapat mereka gunakan untuk masuk dan membuktikan bahwa algoritme tidak sekuat yang diperkirakan semula.

Pengingat yang baik bahwa jika Anda * pernah * berpikir untuk merajut kriptografi Anda sendiri ...

---

ANJING.  [TERTAWA] Saya belum!

---

BEBEK.  ..meskipun kami telah memberi tahu Anda di podcast Naked Security N kali, “Jangan lakukan itu!”

Ini harus menjadi pengingat utama bahwa, bahkan ketika para ahli sejati mengeluarkan algoritma yang tunduk pada pengawasan publik dalam kompetisi global selama lima tahun, ini masih belum tentu memberikan cukup waktu untuk mengekspos kelemahan yang ternyata cukup buruk.

Jadi, itu pasti tidak terlihat bagus untuk ini SIKE algoritma.

Dan siapa tahu, mungkin itu akan ditarik?

---

ANJING.  Kami akan mengawasi itu.

Dan saat matahari perlahan-lahan terbenam di acara kami untuk minggu ini, inilah saatnya untuk mendengar dari salah satu pembaca kami tentang cerita GitHub yang telah kami diskusikan sebelumnya.

Merampok menulis:

“Ada beberapa kapur dan keju di komentar, dan saya benci mengatakannya, tapi saya benar-benar bisa melihat kedua sisi argumen. Apakah berbahaya, merepotkan, membuang-buang waktu dan menghabiskan sumber daya? Ya, tentu saja begitu. Apakah itu yang akan dilakukan oleh orang-orang yang berpikiran kriminal? Ya, ya, itu. Apakah ini pengingat bagi siapa pun yang menggunakan GitHub, atau sistem penyimpanan kode lainnya, bahwa bepergian dengan aman di internet memerlukan tingkat sinisme dan paranoia yang sehat? Ya. Sebagai seorang sysadmin, sebagian dari diri saya ingin memuji eksposur risiko yang ada. Sebagai sysadmin untuk sekelompok pengembang, saya sekarang perlu memastikan semua orang baru-baru ini menjelajahi setiap tarikan untuk entri yang dipertanyakan.”

---

BEBEK.  Ya, terima kasih, RobB, untuk komentar itu, karena saya kira penting untuk melihat kedua sisi argumen.

Ada komentator yang hanya mengatakan, “Apa masalahnya dengan ini? Ini bagus!”

Satu orang berkata, “Tidak, sebenarnya pen testing ini bagus dan berguna. Bersyukurlah ini diekspos sekarang alih-alih membesarkan kepala jelek mereka dari penyerang yang sebenarnya. ”

Dan tanggapan saya untuk itu adalah, "Yah, ini *adalah* serangan, sebenarnya."

Hanya saja seseorang sekarang telah keluar setelah itu, berkata, “Oh, tidak, tidak. Tidak ada salahnya dilakukan! Sejujurnya, aku tidak nakal.”

Saya tidak berpikir Anda wajib membeli alasan itu!

Tapi bagaimanapun, ini bukan pengujian penetrasi.

Tanggapan saya adalah mengatakan, sangat sederhana: “Penguji penetrasi yang bertanggung jawab hanya pernah bertindak [A] setelah menerima izin eksplisit, dan [B] dalam batas perilaku yang disepakati secara eksplisit sebelumnya.”

Anda tidak hanya membuat aturan sendiri, dan kami telah membahas ini sebelumnya.

Jadi, seperti yang dikatakan komentator lain, yang menurut saya, adalah komentar favorit saya… kata Ecurb, “Saya pikir seseorang harus berjalan dari rumah ke rumah dan memecahkan jendela untuk menunjukkan betapa tidak efektifnya kunci pintu. Ini sudah lewat jatuh tempo. Seseorang melompat ke sini, tolong. ”

Dan kemudian, kalau-kalau Anda tidak menyadari bahwa itu adalah sindiran, teman-teman, katanya, "Tidak!"

---

BEBEK.  Saya mendapatkan ide bahwa ini adalah pengingat yang baik, dan saya mendapatkan ide bahwa jika Anda adalah pengguna GitHub, baik sebagai produsen maupun konsumen, ada beberapa hal yang dapat Anda lakukan.

Kami mencantumkannya di komentar dan di artikel.

Misalnya, letakkan tanda tangan digital pada semua komit Anda sehingga jelas bahwa perubahan itu berasal dari Anda, dan ada semacam keterlacakan.

Dan jangan hanya mengkonsumsi barang secara membabi buta karena Anda melakukan pencarian dan "tampaknya" itu mungkin proyek yang tepat.

Ya, kita semua dapat belajar dari ini, tetapi apakah ini benar-benar dianggap sebagai mengajar kita, atau apakah itu hanya sesuatu yang harus kita pelajari?

Saya pikir ini *bukan* mengajar.

Hanya saja *tidak memiliki standar yang cukup tinggi* untuk dihitung sebagai penelitian.

---

ANJING.  Diskusi hebat seputar artikel ini, dan terima kasih telah mengirimkannya, Rob.

Jika Anda memiliki cerita, komentar, atau pertanyaan menarik yang ingin Anda sampaikan, kami ingin membacanya di podcast.

Anda dapat mengirim email tips@sophos.com; Anda dapat mengomentari salah satu artikel kami; atau Anda dapat menghubungi kami di sosial: @NakedSecurity.

Itulah acara kami hari ini – terima kasih banyak telah mendengarkan.

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

---

KEDUA.  Tetap aman!

[MODEM MUSIK]