Analisis Risiko UX OAuth Phishing Kode Perangkat

Trik phishing paling kejam tidak selalu berupa halaman login palsu dengan domain topeng Halloween diskon. Kadang-kadang, yang dipakai justru halaman otorisasi asli, tersenyum sopan sambil meminta pengguna merestui hal yang salah. Device code phishing adalah jenis masalah identitas yang membuat para pembela keamanan menatap fitur yang sepenuhnya sah dan berbisik, tentu saja ini berubah menjadi alat serangan dasar. Pelajarannya bukan bahwa OAuth rusak. Pelajarannya adalah bahwa UX login, akses bersyarat, dan prompt persetujuan kini menjadi bagian dari permukaan serangan, dan semuanya layak mendapat kecurigaan yang sama seperti yang biasanya kita berikan kepada basis data yang terekspos dan siaran pers tentang betapa seriusnya keamanan.

Apa yang terjadi, menurut Proofpoint dan Rubrik

Proofpoint menggambarkan device code phishing sebagai evolusi dalam pengambilalihan identitas, bukan mantra baru misterius yang ditemukan di buku sihir ruang bawah tanah. Riset ancamannya mengatakan phishing kredensial masih memungkinkan pengambilalihan akun, penipuan, ransomware, dan spionase, sementara pelaku ancaman telah berkembang ke device code dan OAuth phishing saat organisasi meningkatkan pertahanan terhadap phishing MFA yang umum. Itulah perkembangan alurnya: ketika pembela membuat trik lama kurang menguntungkan, lawan tidak pensiun, mereka mencari alur kerja yang sudah dipercaya pengguna. Pembahasan Rubrik dengan peneliti Proofpoint Selena Larson membingkai masalah ini sebagai penyalahgunaan alur autentikasi, dengan lawan mengeksploitasi struktur komunikasi yang sah untuk menangkap akses administratif dan perusahaan. Pemilihan kata itu penting karena penyamarannya bukan hanya merek palsu atau domain yang mirip. Penyamaran itu adalah upacara masuk yang normal itu sendiri, yang berarti tim keamanan harus meninjau upacaranya, bukan hanya kredensial yang dimasukkan selama proses itu.

Bagaimana alur asli menjadi umpan, menurut Proofpoint

Proofpoint mengatakan bahwa dari 2020 hingga sekitar 2022, red team dan sesekali pelaku kriminal serta pelaku ancaman spionase menggunakan device code phishing untuk menipu seseorang agar mengotorisasi permintaan berbahaya. Itulah bagian penting bagi para pembangun: korban tidak selalu mengetik kata sandi ke halaman palsu. Mereka mungkin menyelesaikan alur otorisasi asli dan memberikan akses dalam konteks yang tidak mereka pahami. Ini menggeser pertanyaan pertahanan dari apakah pengguna melihat halaman palsu menjadi apakah sistem membuat pilihan berisiko mudah dipahami sebelum persetujuan diberikan. Prompt yang mengatakan setujui kode ini mungkin secara teknis akurat dan tetap tidak berguna bagi seseorang yang sedang mencoba menyelesaikan undangan rapat, chat dukungan, atau ritual tempat kerja lain yang penuh kepanikan ringan. Akurasi tidak sama dengan pemahaman, dan penyerang berkembang di celah itu seperti jamur di kulkas kantor yang terlupakan.

Apa yang terekspos, menurut Krebs dan BleepingComputer

Krebs on Security mendokumentasikan versi lama dari kisah identitas ini pada 2022, ketika phishing SMS menargetkan karyawan di perusahaan penyedia tenaga kerja komersial dan membawa mereka ke halaman yang meniru layar autentikasi Okta. Krebs melaporkan bahwa mereka yang mengirimkan kredensial kemudian diminta memberikan kode sandi satu kali untuk MFA. Tekniknya berbeda, tetapi pelajarannya terasa suram dan akrab: jika langkah autentikasi dapat diteruskan atau direkayasa secara sosial, keberadaan MFA tidak otomatis berarti keputusan itu aman. Liputan BleepingComputer tentang OAuth device code phishing di Azure dan Google menunjukkan kerumitan praktis lainnya: pertahanan identitas hidup di dalam implementasi yang spesifik untuk tiap platform. Itu tidak berarti setiap tim harus menjadi penghobi komite standar OAuth, meskipun selamat untuk tiga orang yang memang sudah begitu. Artinya, pembela harus menginventarisasi di mana otorisasi perangkat diaktifkan, aplikasi mana yang dapat memintanya, dan bagaimana tiap platform menjelaskan permintaan tersebut kepada orang yang memegang keyboard.

Cara membatasinya, menurut Rubrik dan Krebs Percakapan

Rubrik mengarahkan pembela ke kontrol arsitektural, termasuk kebijakan akses bersyarat dan kerangka kepatuhan perangkat yang ketat. Memang di sanalah tempatnya. Melatih pengguna mengenali prompt mencurigakan itu berguna, tetapi membuat setiap karyawan secara pribadi men-debug OAuth di bawah tekanan tenggat bukanlah strategi, itu adalah tes stres tempat kerja dengan token cloud. Krebs juga melaporkan pada 2022 bahwa Apple, Google, dan Microsoft mengumumkan dukungan untuk pendekatan masuk tanpa kata sandi yang mengandalkan pembukaan kunci smartphone, dengan para ahli mengatakan perubahan itu seharusnya membantu mengalahkan banyak jenis phishing sambil memperingatkan bahwa masa depan yang benar-benar tanpa kata sandi mungkin masih bertahun-tahun lagi bagi sebagian besar situs web. Tanpa kata sandi dapat mengurangi pencurian kata sandi, tetapi device code phishing adalah pengingat bahwa pertarungan berikutnya adalah kejelasan otorisasi. Jika pengguna menyetujui akses, produk harus menunjukkan apa yang disetujui, untuk aplikasi mana, dari konteks mana, dan mengapa permintaan itu tidak biasa.

Apa arti sebenarnya bagi Anda, menurut Proofpoint dan Krebs Untuk tim identitas,

intinya cukup sederhana untuk ditulis di sticky note dan cukup menyedihkan untuk merusak makan siang: tinjau alur login sebagai permukaan produk, bukan hanya pipa keamanan. Kerangka pengambilalihan akun dari Proofpoint dan sejarah phishing kode sandi dari Krebs sama-sama menunjuk ke mode kegagalan yang sama, ketika langkah autentikasi yang secara teknis valid berubah menjadi panggung rekayasa sosial. Audit ketersediaan device code, perketat akses bersyarat, wajibkan perangkat yang patuh jika sesuai, dan tulis ulang prompt agar pengguna dapat memahami risiko sebelum mereka menyetujui. Untuk semua orang lainnya, jangan perlakukan halaman login asli sebagai bukti bahwa permintaan itu sah. Perlambat langkah saat prompt meminta Anda memasukkan kode, menyetujui perangkat, atau mengotorisasi aplikasi yang tidak sengaja Anda mulai gunakan. Pertahanan identitas berikutnya yang berguna mungkin bukan kotak centang lain di panel pengaturan MFA. Mungkin itu kalimat yang lebih jelas tepat pada saat seseorang hampir menyerahkan kunci kepada karakter yang salah.