Risiko Delegasi Kerberos

8

Saya telah menghabiskan berjam-jam mencoba untuk belajar dan memahami Otentikasi Windows, Kerberos, SPNs, dan Delegasi Terkendala di IIS 7.5. Satu hal yang tidak saya dapatkan adalah mengapa berisiko "membiarkan delegasi diaktifkan (yaitu tidak menonaktifkan delegasi untuk akun sensitif) untuk Admin, CEO, dll. Dapatkah seseorang tolong jelaskan hal ini kepada saya dalam istilah sederhana? Harap bingkai jawaban Anda sehubungan dengan lingkungan intranet.

Alasan saya adalah bahwa itu tidak boleh menjadi masalah, karena delegasi hanya memungkinkan server web front-end, misalnya, untuk bertindak atas nama orang Windows Otentikasi ketika berkomunikasi dengan server lain. Jika orang tersebut memiliki akses, mereka memiliki akses, saya tidak mengerti mengapa ini harus menjadi perhatian.

Maafkan ketidaktahuan saya. Saya terutama pengembang, tetapi perusahaan saya berjalan sangat ramping hari ini dan saya terpaksa memakai topi admin server juga ... sayangnya, itu masih tidak cocok, lol.

— Chiramisu
sumber

7

Dua contoh:

Delegasi terbatas memungkinkan peniruan tanpa memiliki kredensial atau token otentikasi pengguna. Sebagai contoh, lihat jawaban ini .
Dalam skenario delegasi tanpa daging dan kentang yang lebih tipikal, apakah itu autentikasi terintegrasi windows atau autentikasi bentuk, memiliki akses delegasi ke token otentikasi pengguna sangat kuat. Itu secara harfiah berarti token yang dapat digunakan untuk menyamar sebagai pengguna untuk mengakses sumber daya jaringan apa pun. Siapa pun yang terlibat dalam proses itu, seperti pengembang, dapat menggunakannya dengan cara jahat untuk mendapatkan akses yang tidak sah.

Dalam kedua contoh, jika kotak dicentang untuk "akun sensitif dan tidak dapat didelegasikan", ini bukan masalah keamanan. Mungkin juga untuk merancang sistem / fitur di mana kemampuan ini memang ada, tetapi dikontrol dengan ketat.

Kotak itu harus diperiksa untuk akun administratif, seperti anggota grup Admin Perusahaan, karena (semoga) akun tersebut jarang perlu menggunakan aplikasi yang memerlukan peniruan identitas. Ini juga merupakan ide bagus untuk eksekutif senior yang memiliki akses ke informasi sensitif, seperti CIO, COO, kepala Keuangan / Perbendaharaan, dll.

Jadi intinya adalah, Microsoft menyediakan kotak centang dan peringatan yang menyertainya untuk alasan yang sangat baik, dan itu tidak boleh diabaikan atau dianggap enteng kecuali dapat ditunjukkan bahwa skenario tertentu tidak memiliki paparan risiko yang tidak diinginkan, atau kontrol kompensasi. Ini biasanya melibatkan pemeriksaan oleh beberapa orang yang berkualifikasi yang tidak terlibat dalam implementasi atau pengembangan aplikasi atau sistem yang sebenarnya.

— Greg Askew
sumber

Pertama, jawaban yang sangat membantu dan mendalam. Tidak bisa memberi tahu Anda betapa saya menghargainya. :) Saya masih bertanya-tanya, apa yang perlu untuk dieksploitasi karena orang-orang tentu tidak akan memiliki akses ke kredensial eksekutif kami. Juga harus dicatat bahwa sistem yang kami berikan memungkinkan delegasi terbatas dapat diakses oleh setiap karyawan di jaringan. Juga, saya mencoba untuk mencapai ini dengan mode pipeline terintegrasi dan peniruan ASP.NET.

— Chiramisu

1

Bahkan jika menggunakan mode pipeline terintegrasi, jika token auth hadir, itu dapat dimanfaatkan oleh IIS dan aplikasi apa pun yang sedang berjalan. Saat menggunakan otentikasi terintegrasi Windows, token auth merupakan bagian dari header http. Mungkin bermanfaat untuk mencoba melakukan tes penetrasi pada konfigurasi yang diusulkan untuk menentukan apakah apa yang Anda anggap benar.

— Greg Askew

Sial! Bagian dari Header HTTP? Setidaknya harus dienkripsi kan? Kalau tidak, itu hanya gila! Mengapa Microsoft bahkan membuat rekomendasi menggelikan seperti itu? Saya khawatir saya tidak memiliki petunjuk pertama tentang pengujian pena, jadi saya hanya harus mengambil kata-kata Anda untuk itu. Namun, tidak ada aplikasi di server intranet khusus ini dibatasi secara internal jadi saya pikir itu akan aman. Token dibatasi waktu dan dihasilkan secara dinamis, bukan? Kami hanya membatasi halaman tertentu menggunakan allow/ denytag otorisasi.

— Chiramisu

2

Saya sudah menyiapkan 1000 pelanggan dengan delegasi sebagian besar tidak dibatasi. Saya pikir penting untuk dicatat bahwa jika Anda tidak mempercayai aplikasi Anda (katakanlah disebarkan di IIS) atau Anda memberikan kredensial akun layanan yang didelegasikan kepada kami untuk digunakan orang lain secara bebas, maka delegasi yang dibatasi mungkin merupakan ide yang bagus. Namun, jika Anda tidak mengharapkan siapa pun memiliki kemampuan untuk menulis ulang aplikasi Anda, Anda menjaga kredensial akun layanan Anda aman, dan Anda percaya bahwa aplikasi Anda hanya akan didelegasikan ke layanan yang dirancang untuk mereka, maka di sana biasanya tidak perlu dikhawatirkan. Saya telah melihat beberapa pelanggan "yang sadar akan keamanan" sangat berfokus pada masalah-masalah seperti ini sementara sumber daya mereka dapat dihabiskan lebih baik untuk bekerja pada ancaman keamanan nyata ...

— BasicTek
sumber

Saya sangat menghargai wawasan Anda; sangat membantu. Saya sudah lama menyerah untuk mengkonfigurasi delegasi di Intranet kami dan kembali menjalankan AppPool di IIS di bawah akun khusus dengan akses ke sumber daya yang diperlukan seperti yang telah disiapkan sebelumnya. Saya berharap untuk meninjau kembali masalah ini dan mendapatkan solusi nyata di tempat, tetapi kurangnya waktu dan pengalaman dengan delegasi menghalangi harapan itu untuk saat ini. :(

— Chiramisu