OWASP API Security (Offensive Prespective) : Broken User Authentication #2
Assalamualaikum Wr. Wb
Authentication adalah aktivitas untuk memverifikasi identitas seseorang, siapa pemilik sebuah informasi. hal tersebut sama hal nya seperti penggunaan passport, EKTP, Tanda Tangan, dll..
Sudah sejak 60 tahun lalu mekanisme authentication ini hadir, dan memiliki perkembangan yang tergolong cepat, sebagai teknologi untuk mendevelop dan menyimpan data personal dalam jumlah banyak pada cloud server, pastinya mekanisme ini makin kesini semakin menjadi complex. Bermula dari penggunaan plain teks yang hanya digunakan oleh instansi pemerintah saja, hingga penggunaan teknologi infrared untuk Face ID yang bisa ditemukan di masing-masing device orang-orang seperti saat ini.
Faktor Authentication
Menurut Wikipedia mekanisme authentikasi terdapat 3 faktor penentu yaitu dari Pengetahuan User, Kepemilikan User, dan Informasi Biometric User itu sendiri, faktor tersebut akan dijadikan acuan untuk melakukan verifikasi identitas sebelum sistem memberikan mu akses kepada sebuah sistem.
Faktor: Pengetahuan User?
Faktor yang berdasarkan dari informasi yang kamu ketahui saja, beberapa hal contohnya seperti:
- Password
- Partial-Password
- Security Question
- Challange Response
- PIN
Faktor: Kepemilikan User?
Faktor yang berdasarkan dari informasi mengenai hal-hal kepemilikan user saja, contohnya seperti:
- E-KTP
- SIM
- Handphone
- Software Token
- Hardware Token
Faktor: Biometric User?
Faktor yang berdasarkan dari diri user itu sendiri ataupun apa yang user itu sendiri lakukan, contohnya seperti:
- Tanda tangan
- Sidik Jari
- DNA
- Pola Retinal
- Wajah
- Suara
Berdasarkan klasifikasi faktor authentication yang saya sebutkan sebelumnya tidak semua developer menggunakan keseluruhan dari factor tersebut (Multi-Factor Authentication), ada juga yang menggunakan salah satu factor saja untuk melakukan aktivitas authentication (Single Factor Authentication).
Single Factor Authentication
Salah satu penggunaan mekanisme authentication paling lemah, karena hanya menggunakan salah satu dari 3 komponen factor authentication untuk mengidentifikasi data personal. Sangat tidak di sarankan hanya menggunakan satu faktor saja untuk melakukan identifikasi user, untuk melakukan sebuah transaksi yang melibatkan data user, harus menggunakan level authentikasi yang lebih tinggi.
Multi Factor Authentication
Penggunaan dua atau lebih factor untuk melakukan proses authentication, seperti yang diimplementasikan salah satunya pada sistem perbankan, terdapat faktor kepemilikan user (Kartu Debit, Kartu ATM, Kartu Credit), faktor pengetahuan (PIN & Password), faktor Biometric (Sidik jari, Wajah, tanda tangan).
Federated Identity Management
Menggunakan satu service dan identity provider untuk melakukan authentication nantinya akan diberikan sebuah token yang akan digunakan untuk mengakses ke banyak service / aplikasi bisa juga antar domain Contohnya seperti:
- SSO (Single Sign On)
- SAML
- OpenID
- Etc..
Broken User Authentication
Sebuah kerentanan yang disebabkan lemahnya sistem authentikasi atau pengenalan identitas user, yang mengakibatkan pihak luar dapat masuk dengan mudah pada sebuah sistem.
Tipe Attack Schema beserta Resikonya
Type attack dari Broken User Authentication seharusnya beragam karena banyaknya methodologi authentication yang ada pada aplikasi saat ini, beberapa kerentanan yang terdapat pada sistem authentication API sebagai berikut:
- Credential Stuffing
- Weak Password
- Session Fixation (waybackurl)
- Stealing token
Credential Stuffing
Sebuah aktivitas bruteforcing ke banyak service / situs menggunakan bot, yang dimana bot tersebut menggunakan informasi terkait email password beberapa pengguna yang diperoleh dari data breach atau hasil dumping dari kerentanan yang dapat melakukan dumping pada database aplikasi.
Salah satu casenya adalah para carder yang memanfaatkan credential yang valid untuk melakukan bruteforcing attack pada layanan virtual payment seperti paypal, dan ada juga social media, bahkan ecommerce seperti amazon dan ebay.
Weak Password
Sebuah kerentanan yang disebabkan karena sistem tidak menerapkan standarisasi password seperti limitasi jumlah character, penggunaan character kombinasi angka,huruf dan simbol, tidak menggunakan password angka yang incremental. Attacker dapat melakukan authentication pada sistem hanya dengan melakukan bruteforcing dengan common wordlists.
Session Fixation
Sebuah kerentanan yang disebabkan karena token/session tidak menerapkan account lockout dan account timeout yang menyebabkan url yang berisi token akan dapat digunakan ulang oleh attacker. Namun adapula dikarenakan tidak ada validasi token dimana attacker dapat impersonating token milik pengguna lain.
Disini saya gunakan case dari temuan saya sendiri terhadap sebuah web dari singapore.
Saya menggunakan tools Waybackurls milik tomnomnom, untuk mencari url history yang terindex oleh mesin pencarian, disini saya menemukan salah satu URL verifikasi email yang memuat sebuah UUID.
Lalu saya mencoba membuka URL tersebut pada browser, ternyata URL tersebut masih aktif, lalu apa yang terjadi setelah saya mencoba kembali ke menu utama?
Ternyata saya berhasil login ke sebuah akun hanya dengan UUID token tersebut. Permasalahan yang ada pada kerentanan tersebut adalah ketika token tersebut tidak memiliki expired date, serta reusable.
Ini beresiko jika attacker melakukan skema yang sama, attacker akan mencoba mengirimkan link token yang serupa namun dengan token akun milik attacker, setelah korban menjalankan URLnya, secara tidak sadar pada browser korban session akun attacker berubah. Jika sewaktu-waktu korban melakukan transaksi pada website tersebut secara tidak sadar korban akan mengisi data payment / informasi pribadi korban pada akun attacker.
Stealing Token
Sebuah kerentanan yang disebabkan karena misconfigurasi untuk URI callback yang terdaftar pada OAuth services, yang berakibat attacker dapat merubah callback URI yang seharusnya berisi URI pada domain yang sama dengan Service provider (Aplikasi Client) menjadi website attacker.
Sebelum penjelasan mengenai takeover account / stealing token dengan misconfig pada Oauth, saya ingin menjelaskan sedikit secara sederhana flow pada Oauth ini dalam proses authentication.
Terlihat pada gambar diatas, User mengirim request credetial ke Service provider (aplikasi client), lalu Service provider melakukan generate token yang berisi informasi credential yang kita kirim kan sebelumnya, lalu dikirimkan kepada Identity provider (SSO system) untuk di validasi. Lalu setelah Identity provider mengkonfirmasi, Identity provider tersebut mengenerate token untuk dapat mengakses endpoint Service provider. Lalu token tersebut di berikan kembali pada user browser untuk mengakses informasi service provider tersebut.
Disini terlihat terdapat client_id & redirect_uri yang seharusnya milik service provider (Aplikasi client), yang nanti nya setelah proses autentication berhasil Identity provider akan meredirect ke website service provider yang ada pada redirect_uri.
Disinilah letak kemungkinan kerentanan yang disebabkan misconfigurasi terjadi, akibat dari configurasi whitelisting domain URI. Seperti yang terlihat pada gambar di atas, attacker mengubah value dari redirect_uri menjadi website milik attacker.
Setelah berhasil terauthentication, maka identity provider melakukan redirect ke URI sebelumnya dengan membawa sebuah token yang di generate oleh identity provider untuk melakukan akses informasi pada service provider.
Attacker dapat melihat URL berisi token tersebut pada log server milik attacker, dan dapat menggunakan URL tadi untuk mengakses informasi korban.
Bagaimana cara pencegahanya?
- Jika masih menggunakan HTTP Basic Authentication, gunakan HTTPS.
- Implementasikan account lockout serta session timeout.
- Jangan terima JWT tokens unsigned atau weak signed (“alg”:”none”) atau validasi expiration date.
- Jangan gunakan depracated encryption ke sebuah key atau password.
- Gunakan Federated Identity Management, seperti OpenID, SAML, SSO dll..
- Implementasikan Input Validasi.
- Penggunaan whitelisting domain pada service SSO.
Terimakasih telah membaca artikel saya, saya harap article ini dan selanjutnya dapat membantu dan bermanfaat.
Wassalam.
