OAuth Phishing: Hacker Bisa Bobol Akun Tanpa Curi Password

Serangan phishing kini tidak selalu membutuhkan halaman login palsu untuk mencuri username dan password. Salah satu teknik yang semakin perlu diwaspadai adalah OAuth consent phishing, serangan yang memanfaatkan proses otorisasi resmi dari layanan seperti Microsoft dan Google untuk membuat korban memberikan akses kepada aplikasi berbahaya.

Teknik ini memanfaatkan satu hal yang selama ini menjadi fondasi keamanan digital: kepercayaan pengguna terhadap layanan resmi. Alih-alih membuat korban memasukkan kredensial ke situs palsu, penyerang justru mengarahkan korban melalui alur login yang benar-benar sah. Korban bahkan bisa menyelesaikan multi-factor authentication (MFA) tanpa menyadari bahwa pada saat yang sama mereka sedang memberikan akses kepada aplikasi yang dikendalikan penyerang.

Situasi tersebut membuat OAuth phishing berbeda dari phishing konvensional. Masalah utamanya bukan lagi apakah halaman login terlihat palsu, melainkan apakah pengguna memahami aplikasi apa yang sedang diberi akses dan izin apa yang diberikan.

Apa Itu OAuth Consent Phishing?

OAuth consent phishing adalah serangan yang menipu pengguna agar memberikan izin kepada aplikasi OAuth berbahaya melalui proses otorisasi dari penyedia identitas yang sah.

OAuth sendiri merupakan mekanisme yang memungkinkan sebuah aplikasi memperoleh akses tertentu ke layanan atau data pengguna tanpa harus mengetahui password pengguna. Dalam penggunaan normal, mekanisme ini sangat berguna. Misalnya, sebuah aplikasi dapat meminta izin untuk mengakses kalender, email, file, atau layanan lain yang terhubung dengan akun pengguna.

Masalah muncul ketika mekanisme tersebut disalahgunakan.

Penyerang dapat membuat atau mendaftarkan aplikasi yang terlihat meyakinkan, kemudian membujuk korban agar memberikan izin. Setelah pengguna menyetujui permintaan tersebut, aplikasi memperoleh token yang dapat digunakan untuk melakukan aktivitas melalui API atas nama pengguna.

Pada kondisi tertentu, token yang diperoleh juga dapat berupa refresh token. Token ini memungkinkan aplikasi mendapatkan access token baru setelah access token sebelumnya kedaluwarsa. Dengan demikian, akses tidak selalu berhenti ketika sesi login awal berakhir.

Inilah yang membuat OAuth phishing berbeda dari pencurian password. Penyerang tidak harus mengetahui password korban untuk dapat mengakses sumber daya yang telah diizinkan.

Mengapa MFA Tidak Selalu Menghentikan OAuth Phishing?

MFA selama ini menjadi salah satu lapisan perlindungan penting terhadap pencurian akun. Namun, pada OAuth phishing, penyerang sering kali tidak perlu melewati MFA secara langsung. Bayangkan seorang pengguna menerima email yang mengarahkan mereka ke halaman Microsoft atau Google. Pengguna kemudian login menggunakan akun mereka dan menyelesaikan MFA seperti biasa.

Dari sudut pandang pengguna, proses tersebut tampak normal.

Namun setelah autentikasi berhasil, muncul permintaan untuk memberikan izin kepada sebuah aplikasi. Jika pengguna menekan tombol persetujuan tanpa memeriksa detailnya, aplikasi tersebut dapat memperoleh akses yang sebelumnya diberikan.

Dengan kata lain, masalah terjadi setelah autentikasi berhasil. MFA memang dapat memastikan bahwa orang yang melakukan login telah melewati mekanisme verifikasi yang ditetapkan. Namun, jika pengguna sendiri memberikan persetujuan kepada aplikasi berbahaya setelah login, MFA tidak otomatis membatalkan izin OAuth tersebut.

Karena itu, keamanan akun tidak cukup hanya mengandalkan MFA. Organisasi juga perlu memperhatikan mekanisme pemberian izin aplikasi.

Bagaimana Serangan OAuth Consent Phishing Berlangsung?

Serangan biasanya dimulai dengan teknik rekayasa sosial yang tidak jauh berbeda dari phishing biasa. Korban dapat menerima email yang mengandung pesan mendesak, dokumen penting, pemberitahuan keamanan, permintaan berbagi file, atau informasi lain yang dirancang untuk mendorong korban segera bertindak.

Tautan dalam email tersebut kemudian mengarahkan korban menuju proses yang terlihat sah.

Inilah salah satu bagian paling berbahaya dari OAuth phishing. Korban tidak selalu menemukan domain asing atau halaman login dengan desain buruk. Mereka dapat melihat halaman autentikasi resmi milik penyedia identitas yang memang biasa digunakan sehari-hari.

Setelah berhasil login, korban melihat consent screen atau layar persetujuan yang meminta akses kepada sebuah aplikasi. 

Jika korban tidak memeriksa permintaan tersebut dengan teliti dan memilih Accept, aplikasi memperoleh izin yang diminta. Bergantung pada scope yang diberikan, akses tersebut dapat memungkinkan aplikasi membaca email, mengirim pesan atas nama pengguna, mengakses file, atau menggunakan layanan lain yang terhubung dengan akun.

Dengan demikian, keberhasilan serangan sangat bergantung pada satu tindakan yang tampak sederhana: pengguna menyetujui aplikasi.

Contoh Skenario OAuth Phishing

Salah satu skenario yang mungkin terjadi adalah penyerang membuat aplikasi dengan nama yang terdengar meyakinkan, misalnya "Secure Document Viewer". Korban kemudian menerima email yang mengatakan bahwa sebuah dokumen penting perlu diperiksa. Email tersebut menyediakan tautan untuk membuka dokumen.

Ketika korban mengklik tautan, mereka diarahkan ke halaman login Microsoft atau Google yang asli. Korban memasukkan informasi login dan menyelesaikan MFA jika diminta. Setelah itu, muncul permintaan agar pengguna memberikan akses kepada aplikasi.

Permintaan tersebut mungkin mencakup izin seperti:

• Membaca email.
• Mengirim email atas nama pengguna.
• Mengakses file di OneDrive atau Google Drive.
• Mempertahankan akses ketika pengguna sedang offline.
• Mengakses layanan lain yang tersedia melalui API.
• Jika pengguna menekan tombol Accept, proses serangan pada dasarnya telah berhasil.

Penyerang kemudian dapat memanfaatkan token yang diberikan kepada aplikasi untuk melakukan aktivitas sesuai dengan izin yang disetujui. Yang membuat serangan ini sulit dikenali adalah pengguna mungkin merasa tidak pernah memasukkan password ke situs mencurigakan. Mereka juga telah menyelesaikan MFA dan menggunakan situs resmi.

Device Code Phishing, Varian yang Perlu Diwaspadai

OAuth phishing juga memiliki varian yang dikenal sebagai device code phishing. Serangan ini menyalahgunakan mekanisme OAuth 2.0 Device Authorization Grant, sebuah alur autentikasi yang memang dirancang untuk perangkat yang memiliki keterbatasan dalam memasukkan informasi, seperti smart TV, printer, atau perangkat lain.

Dalam alur normal, pengguna dapat melihat kode tertentu pada perangkat dan memasukkannya pada halaman verifikasi yang disediakan penyedia identitas. Mekanisme tersebut kemudian dimanfaatkan penyerang untuk melakukan rekayasa sosial. Penyerang terlebih dahulu memulai proses otorisasi perangkat untuk aplikasi yang mereka kendalikan. Penyedia identitas menghasilkan device code dan URL verifikasi.

Selanjutnya, korban diarahkan ke halaman verifikasi resmi dan diminta memasukkan kode tersebut. Karena URL yang digunakan merupakan layanan resmi, korban dapat merasa aman. Namun, kode yang dimasukkan sebenarnya berkaitan dengan proses otorisasi aplikasi milik penyerang.

Di sisi lain, aplikasi yang dikendalikan penyerang menunggu hingga korban menyelesaikan proses autentikasi. Setelah proses tersebut selesai, aplikasi dapat memperoleh token yang memungkinkan akses melalui API. Serangan ini memanfaatkan kebiasaan pengguna yang menganggap memasukkan kode sebagai bagian biasa dari proses login atau autentikasi perangkat. Padahal, kode tersebut dapat menjadi bagian dari proses pemberian akses kepada aplikasi tertentu.

Contoh Serangan Device Code Phishing

Skenario device code phishing dapat dimulai dari email yang terlihat seperti pemberitahuan resmi. 

Korban mengklik tautan dan diarahkan ke situs yang dikendalikan penyerang. Situs tersebut dapat meminta alamat email korban dan kemudian menampilkan instruksi untuk melakukan "secure authentication". Korban kemudian diberi sebuah kode dan diminta melanjutkan proses menggunakan Microsoft Authenticator atau layanan autentikasi terkait.

Pada kenyataannya, kode tersebut bukan kode MFA biasa. Kode tersebut merupakan device code yang berkaitan dengan proses OAuth 2.0 Device Authorization Grant yang sebelumnya telah dimulai oleh penyerang. Korban kemudian diarahkan ke situs Microsoft yang benar-benar resmi untuk memasukkan kode.

Di titik inilah serangan menjadi semakin sulit dikenali. Domain yang dikunjungi memang sah dan proses autentikasi juga berlangsung melalui infrastruktur resmi.

Jika korban sudah login, kode tersebut dapat mengotorisasi aplikasi yang dikendalikan penyerang. Jika belum login, korban mungkin diminta melakukan login dan MFA terlebih dahulu. Setelah proses selesai, aplikasi berbahaya dapat memperoleh akses berdasarkan izin yang diberikan.

Mengapa OAuth Phishing Menjadi Ancaman Serius?

Salah satu persoalan utama OAuth phishing adalah akses yang diperoleh penyerang tidak selalu terlihat seperti kompromi akun tradisional. Dalam serangan pencurian password, misalnya, tim keamanan dapat mencari login dari lokasi tidak biasa, perangkat asing, atau pola autentikasi yang mencurigakan.

Pada OAuth phishing, aktivitas setelah kompromi dapat berlangsung melalui API menggunakan token yang telah diberikan. Akibatnya, beberapa indikator tradisional mungkin tidak muncul. 

Risiko lainnya adalah persistensi akses. Selama token atau izin aplikasi belum dicabut, aplikasi dapat terus memiliki akses sesuai dengan permission yang diberikan. Dalam situasi tertentu, akses tersebut dapat bertahan dalam waktu lama.

Hal ini menjadi semakin berisiko ketika pengguna memberikan scope yang terlalu luas. Sebuah aplikasi mungkin hanya membutuhkan akses terbatas untuk menjalankan fungsi tertentu, tetapi pengguna dapat menyetujui permintaan yang jauh lebih luas tanpa memahami konsekuensinya.

Bagi organisasi, kompromi semacam ini dapat berdampak pada email, dokumen internal, data bisnis, komunikasi, hingga layanan lain yang terhubung dengan identitas pengguna.

Cara Mencegah OAuth Phishing

Mencegah OAuth phishing membutuhkan kewaspadaan karena serangan ini dapat berlangsung melalui alur login yang sah. Pengguna tidak cukup hanya memastikan alamat situs terlihat resmi, tetapi juga perlu memeriksa aplikasi dan izin yang diminta sebelum memberikan akses. Dengan memahami pola serangan serta menerapkan kebiasaan keamanan yang tepat, risiko akun dan data disalahgunakan dapat dikurangi. Berikut sejumlah langkah yang dapat dilakukan untuk mencegah OAuth phishing:

Kesadaran Pengguna Menjadi Lapisan Pertahanan Penting
Menghadapi OAuth phishing, edukasi pengguna perlu diperluas. Pelatihan keamanan tidak cukup hanya mengajarkan cara mengenali halaman login palsu, alamat email mencurigakan, atau domain berbahaya.

Pengguna juga harus memahami bahwa halaman yang benar-benar resmi tidak selalu berarti tindakan yang dilakukan di dalamnya aman. Sebuah halaman Microsoft atau Google yang asli dapat digunakan untuk memberikan izin kepada aplikasi pihak ketiga.

Karena itu, setiap kali muncul permintaan consent, pengguna perlu berhenti sejenak dan memeriksa beberapa hal.

• Pertama, periksa nama aplikasi.
• Kedua, periksa penerbit atau publisher aplikasi.
• Ketiga, perhatikan permission atau scope yang diminta.
• Keempat, tanyakan apakah izin tersebut memang masuk akal dengan aktivitas yang sedang dilakukan.

Misalnya, jika pengguna hanya ingin membuka sebuah dokumen tetapi aplikasi meminta kemampuan membaca seluruh email dan mengakses berbagai file, permintaan tersebut patut diperiksa lebih lanjut.

Prinsip sederhananya adalah: jangan hanya memastikan bahwa situsnya resmi, tetapi pastikan juga aplikasi dan izin yang diberikan memang sesuai kebutuhan.

Organisasi Perlu Membatasi OAuth Consent
Dari sisi administrator, organisasi dapat menerapkan kebijakan yang membatasi kemampuan pengguna memberikan persetujuan kepada aplikasi OAuth. Salah satu pendekatan adalah mewajibkan persetujuan administrator untuk aplikasi tertentu, terutama aplikasi yang meminta akses dengan dampak tinggi.

Organisasi juga dapat membatasi atau memblokir aplikasi yang belum diverifikasi. Verifikasi penerbit dapat membantu mengurangi risiko aplikasi yang mencoba menggunakan identitas atau nama yang menyerupai layanan tepercaya.

Selain itu, administrator perlu melakukan inventarisasi terhadap aplikasi enterprise yang memiliki akses ke lingkungan organisasi.  Aplikasi yang tidak dikenal, tidak lagi digunakan, atau memiliki izin yang tidak sesuai perlu diperiksa dan, jika diperlukan, dicabut aksesnya. Token dan izin yang sudah tidak dibutuhkan juga sebaiknya ditinjau secara berkala.

Untuk organisasi yang tidak membutuhkan device code flow, mekanisme tersebut dapat dipertimbangkan untuk dibatasi atau diblokir menggunakan kebijakan Conditional Access, sesuai dengan kebutuhan dan konfigurasi lingkungan masing-masing.

Deteksi Harus Mengamati Aktivitas API
Pertahanan terhadap OAuth phishing juga membutuhkan kemampuan deteksi yang tidak hanya berfokus pada login. Tim keamanan perlu memperhatikan aktivitas API dan perubahan pada aplikasi enterprise.

Beberapa indikator yang dapat dipantau antara lain munculnya aplikasi OAuth baru, pemberian consent yang tidak biasa, aplikasi yang meminta scope berisiko tinggi, serta aktivitas API yang berbeda dari pola penggunaan normal.

Misalnya, akun pengguna yang biasanya tidak mengakses sejumlah besar file tiba-tiba melakukan aktivitas API dalam jumlah besar setelah memberikan izin kepada aplikasi baru. Pola seperti ini tidak otomatis membuktikan adanya serangan, tetapi dapat menjadi sinyal yang perlu diperiksa lebih lanjut.

Pemantauan juga dapat membantu organisasi menemukan aplikasi yang memperoleh akses tanpa sepengetahuan administrator. Dengan menghubungkan informasi mengenai pemberian consent dengan aktivitas API setelahnya, tim keamanan dapat memperoleh gambaran yang lebih lengkap mengenai kemungkinan penyalahgunaan OAuth.

Jangan Terkecoh Hanya karena URL Resmi
OAuth phishing menunjukkan perubahan penting dalam pola serangan siber.

Pada masa lalu, pengguna sering diajarkan bahwa tanda bahaya utama adalah URL palsu atau halaman login yang mencurigakan. Pendekatan tersebut masih relevan, tetapi tidak lagi cukup untuk menghadapi seluruh jenis serangan.

Dalam OAuth phishing, penyerang justru dapat memanfaatkan layanan autentikasi yang benar-benar resmi. Korban bisa mengunjungi domain yang sah, melakukan login yang sah, bahkan menyelesaikan MFA dengan benar. Masalah kemudian muncul ketika korban memberikan persetujuan kepada aplikasi yang tidak seharusnya memperoleh akses.

Karena itu, pengguna perlu mengubah kebiasaan dari sekadar bertanya "Apakah situs ini resmi?" menjadi "Aplikasi apa yang sedang saya beri akses, siapa penerbitnya, dan data apa yang akan dapat diakses?" Perubahan sederhana dalam pola pikir tersebut dapat menjadi bagian penting dari pertahanan terhadap OAuth phishing.

Pertahanan Membutuhkan Kombinasi Manusia dan Teknologi

OAuth phishing memperlihatkan bahwa keamanan identitas tidak dapat hanya bergantung pada satu lapisan perlindungan. MFA tetap menjadi bagian penting dari keamanan akun, tetapi organisasi juga perlu mengelola pemberian izin aplikasi, memantau token, membatasi OAuth consent, mengawasi aktivitas API, serta memberikan edukasi kepada pengguna.

Dari sisi pengguna, kewaspadaan terhadap permintaan consent menjadi kunci. Dari sisi administrator, pembatasan izin dan pemantauan aplikasi dapat mengurangi ruang gerak penyerang. Sementara itu, tim keamanan perlu memperhatikan indikator yang mungkin muncul setelah pengguna memberikan akses, bukan hanya mencari tanda-tanda login mencurigakan.

Pada akhirnya, OAuth dirancang untuk memberikan akses aplikasi secara terkontrol, bukan menjadi celah keamanan. Namun ketika pengguna tidak memahami izin yang diberikan dan organisasi tidak mengelola aplikasi serta token secara ketat, mekanisme tersebut dapat dimanfaatkan untuk melakukan serangan.

Karena itu, setiap permintaan OAuth perlu diperlakukan sebagai keputusan keamanan, bukan sekadar langkah tambahan untuk menyelesaikan proses login.