Belajar Kerberos - Kerberos Preauth & FAST

#Pendahuluan

Di episode 11 kita mengamankan fondasi kriptografi Kerberos: memilih encryption type AES modern dan menyingkirkan DES/RC4 yang lemah. Enkripsi yang kuat itu tidak ada gunanya bila proses autentikasi awalnya sendiri bisa diserang secara offline. Kali ini kita mengunci pintu yang paling awal: preauthentication — bukti bahwa klien benar-benar tahu rahasianya sebelum KDC menerbitkan tiket — lalu naik satu tingkat dengan FAST (Flexible Authentication via Secure Tunneling) yang membungkus seluruh proses autentikasi di dalam terowongan terenkripsi.

Bayangkan sebuah hotel. Saat check-in, resepsionis seharusnya memverifikasi identitas kalian dulu sebelum memberikan kartu kunci kamar. Bayangkan jika ia malah menyerahkan amplop berisi "petunjuk rahasia" kepada siapa pun yang memintanya, tanpa bertanya apa pun. Pencuri pun tinggal membawa amplop itu pulang dan mencoba memecahkannya dengan tenang di rumah. Itulah gambaran Kerberos tanpa preauth.

#Kenapa Preauth Ada: Masalah di Balik AS-REP yang Terbuka

Ingat kembali alur AS dari episode 3: klien mengirim AS-REQ untuk meminta TGT, dan KDC membalas AS-REP. Bagian pentingnya: TGT di dalam AS-REP dienkripsi dengan kunci jangka panjang (long-term key) klien — kunci yang diturunkan dari password.

Masalahnya, jika preauth tidak diwajibkan, klien bisa mengirim AS-REQ tanpa membuktikan apa pun. KDC tetap membalas dengan AS-REP berisi ciphertext yang dienkripsi dengan kunci turunan password itu. Penyerang yang tidak punya akun sama sekali bisa merekam ciphertext tersebut dan melakukan brute force offline — mencoba jutaan kata sandi di komputer sendiri, tanpa batasan percobaan login. Serangan inilah yang dikenal sebagai AS-REP roasting (saudara dari Kerberoasting yang akan kita bahas di episode 21).

Ini adalah kebocoran desain klasik: KDC tidak boleh memberikan bahan serangan sebelum klien membuktikan dirinya. Preauth menutup celah itu di sumbernya.

#Encrypted Timestamp Preauth: Bukti Sebelum Tiket

Mekanisme preauth paling sederhana dan paling banyak dipakai adalah encrypted timestamp (PA-ENC-TIMESTAMP). Alurnya:

1. Klien mengambil waktu saat ini (timestamp).
2. Klien mengenkripsi timestamp tersebut dengan kunci turunan password-nya.
3. AS-REQ dikirim bersama data preauth terenkripsi ini.
4. KDC mencari kunci klien dari database, mendekripsi timestamp, dan memverifikasi: (a) apakah terdekripsi dengan benar — berarti klien tahu passwordnya, dan (b) apakah timestamp masih segar — berarti bukan replay attack.

Inti keamanannya: untuk membuat ciphertext yang valid, penyerang harus tahu passwordnya. Tanpa password, tidak ada bukti — dan KDC menolak menerbitkan TGT. Dan karena timestamp diverifikasi kesegarannya, tiket yang direkam tidak bisa diputar ulang beberapa menit kemudian.

#Menerapkan Preauth: Flag requires_preauth

Preauth tidak otomatis aktif untuk semua principal di semua versi lama. Penegakannya dilakukan lewat flag pada principal, bernama requires_preauth. Lewat kadmin, flag ini ditulis dengan +requires_preauth (menyalakan) atau -requires_preauth (mematikan):

kadmin.local -q "modprinc +requires_preauth alice@EXAMPLE.COM"
kadmin.local -q "getprinc alice@EXAMPLE.COM" | grep -i preauth

Untuk principal service seperti host/server.example.com yang mengautentikasi lewat keytab, set +requires_preauth juga — memastikan hanya klien dengan TGT yang benar-benar terautentikasi yang bisa mendapat service ticket untuknya.

Jika preauth diwajibkan tetapi klien mengirim AS-REQ tanpa preauth, KDC membalas error KRB5KDC_ERR_PREAUTH_REQUIRED. Klien modern seperti kinit membaca error itu, lalu otomatis mengulang permintaan dengan preauth. Karena itu transisi ke preauth biasanya tidak terasa di sisi pengguna:

kinit -V alice@EXAMPLE.COM

Bagi organisasi, cara terbaik memastikan semua principal baru sudah preauth sejak awal adalah lewat default_principal_flags di kdc.conf. Flag +preauth pada baris ini membuat principal yang baru dibuat di realm tersebut langsung mewarisi requires_preauth:

kdc.conf - memberlakukan preauth untuk semua principal baru

[realms]
    EXAMPLE.COM = {
        default_principal_flags = +preauth
        restrict_anonymous_to_tgt = true
    }

#AS-REP Roasting: Serangan yang Memotivasi Semua Ini

Karena relevansinya begitu langsung, mari kita bedah serangan ini lebih dalam. AS-REP roasting bekerja dengan tiga langkah sederhana:

1. Penyerang mencantumkan semua principal yang tidak mewajibkan preauth (bisa didapat lewat LDAP query atau dari dump AD).
2. Untuk setiap principal tersebut, penyerang mengirim AS-REQ tanpa preauth.
3. KDC membalas AS-REP berisi ciphertext. Penyerang melakukan brute force offline terhadap ciphertext itu — kecepatannya tergantung GPU, bukan batasan login server.

Dampaknya: sebuah akun dengan password lemah dan tanpa preauth bisa dipecahkan tanpa pernah menghasilkan satu pun log percobaan login yang mencurigakan. Inilah kenapa langkah terpenting bukan sekadar "pakai password kuat", melainkan pastikan flag requires_preauth aktif untuk semua orang.

Deteksinya juga jelas di sisi KDC: lihat log keberhasilan autentikasi di mana preauth tidak dipakai (di AD, event 4768 dengan PreAuthType: 0). Setiap kali ada keberhasilan login tanpa preauth, anggap itu alarm.

#FAST: Terowongan untuk Autentikasi

Preauth menutup celah AS-REP, tetapi pertukaran AS masih berjalan di teks terang. Penyerang yang bisa melihat lalu lintas jaringan tetap dapat melakukan serangan offline terhadap data preauth itu sendiri, menurunkan versi enkripsi (downgrade), atau bahkan memalsukan pesan error KDC untuk menyesatkan klien.

FAST (RFC 6113) menyelesaikan masalah ini dengan membungkus seluruh pertukaran AS di dalam terowongan terenkripsi. Kuncinya adalah armor ticket: sebuah TGT yang dipakai sebagai material enkripsi untuk "melapisi" AS-REQ/AS-REP sesungguhnya.

Cara kerja FAST:

1. Klien dan KDC sepakat memakai armor ticket (bisa TGT biasa milik klien, atau anonymous ticket).
2. AS-REQ asli dibungkus di dalam lapisan FAST yang terenkripsi dengan kunci dari armor ticket.
3. KDC membuka terowongan, memproses preauth asli, lalu mengirim AS-REP kembali melalui terowongan yang sama.

Hasilnya, kredensial dan data preauth klien tidak pernah terpapar di jaringan terbuka, dan respons KDC dijamin tidak bisa dimodifikasi di tengah jalan. FAST juga memungkinkan mekanisme preauth baru yang menuntut kerahasiaan untuk dipakai — sesuatu yang mustahil tanpa terowongan.

Sebuah analogi: preauth biasa seperti menunjukkan KTP di meja resepsionis yang terbuka — penjaga pintu lain di sekitar bisa mengintip. FAST seperti membisikkan nomor identitas itu ke telinga resepsionis lewat kanal tertutup, sementara penjaga lain hanya melihat amplop tersegel keluar masuk.

#Konfigurasi FAST & Anonymous PKINIT

FAST didukung bawaan oleh KDC MIT; yang perlu kalian lakukan hanyalah mengaktifkannya di sisi klien. Caranya dengan -T untuk menentukan cache tiket yang dipakai sebagai armor, atau lewat atribut pa_fast_armor:

kinit -T FILE:/tmp/armor.cc alice@EXAMPLE.COM
kinit -X pa_fast_armor=FILE:/tmp/armor.cc alice@EXAMPLE.COM

Varian yang lebih menarik adalah anonymous PKINIT: klien memperoleh anonymous ticket lewat sertifikat publik (tanpa identitas), lalu memakainya sebagai armor. Identitas klien yang sesungguhnya baru diungkap di dalam terowongan — dari sudut pandang pengintai, hanya ada lalu lintas anonim yang tidak berguna. Inilah model yang dipakai untuk mengamankan proses login di banyak lingkungan enterprise.

Untuk mengaktifkannya:

• Pasang sertifikat KDC dan konfigurasi pkinit_anchors di kedua sisi (kita bedah detail PKINIT sebentar lagi).
• Di kdc.conf, set restrict_anonymous_to_tgt = true (lihat blok konfigurasi di atas). Pengaturan ini mengizinkan anonymous ticket untuk armor sekaligus mencegah anonymous principal mengakses layanan lain secara sembarangan.
• Klien meminta anonymous ticket dengan:

kinit -n @EXAMPLE.COM

#PKINIT dan OTP: Preauth Non-Password

PKINIT (RFC 4556) adalah mekanisme preauth berbasis kunci publik: klien membuktikan identitasnya dengan sertifikat digital — biasanya dari smart card atau hardware token — bukan password. Keunggulannya: tidak ada lagi "rahasia bersama" yang bisa di-brute force, dan autentikasi bisa dua faktor (sertifikat + PIN). Di sisi klien, PKINIT dikonfigurasi lewat atribut -X atau pkinit_identities di krb5.conf:

kinit -X X509_user_identity=FILE:/etc/ssl/private/alice.pem,alice.key alice@EXAMPLE.COM

Sementara itu, OTP (One-Time Password) menyediakan preauth berbasis token sekali pakai (RFC 6560). KDC MIT mendukung OTP langsung, dan bisa dihubungkan ke RADIUS sehingga token dari vendor apa pun — yang berbicara RADIUS — bisa dipakai untuk autentikasi Kerberos. Kombinasi "password + token OTP" adalah implementasi nyata dari two-factor authentication di dunia Kerberos, dan keduanya berjalan sebagai mekanisme preauth di dalam terowongan FAST yang aman.

#Penutup

Pada episode ini kita mengunci fase paling awal dari autentikasi Kerberos: preauthentication untuk memastikan klien membuktikan pengetahuan rahasianya sebelum KDC menerbitkan tiket — menutup celah AS-REP roasting; encrypted timestamp preauth sebagai mekanisme utamanya; flag requires_preauth sebagai tuas penegakannya; FAST sebagai terowongan terenkripsi yang melindungi seluruh pertukaran; serta PKINIT dan OTP sebagai jalur preauth non-password.

Inti dari episode ini: preauth adalah dinding pertama, FAST adalah atapnya. Satu prinsip yang sama menaungi keduanya — jangan pernah beri musuh bahan untuk bekerja di rumahnya sendiri; paksa semua pembuktian terjadi di tempat yang kalian kontrol.

Sekarang fondasi autentikasi kita sudah kokoh. Di episode 13 kita mengeksploitasi kekuatan itu: SSH dengan Kerberos via GSSAPI — login ke puluhan server tanpa password, tanpa kunci publik yang tersebar, cukup satu kinit di pagi hari. Sampai jumpa di sana!