Mendukung Extended Protection for Authentication (EPA) dalam layanan
| Fitur | Berlaku untuk |
|---|---|
| EPA | semua OS Windows yang didukung |
| EPA Audit Mode | Windows Server 2019 Windows Server 2022 Windows Server 23H2 |
Apa masalahnya?
Ada kelas serangan pada layanan terautentikasi yang disebut serangan penerusan. Serangan ini memungkinkan musuh untuk melewati autentikasi dan bertindak sebagai pengguna lain. Karena ini adalah serangan pada layanan dan bukan protokol autentikasi itu sendiri, terserah layanan terautentikasi untuk menggagalkan serangan penerusan.
Bagaimana cara kerja serangan penerusan?
Saat layanan atau aplikasi memanggil API AcceptSecurityContext untuk mengautentikasi klien, layanan atau aplikasi meneruskan blob data yang diterima dari panggilan klien ke InitializeSecurityContext. Protokol autentikasi bertanggung jawab untuk memverifikasi bahwa blob yang disediakan berasal dari pengguna yang ditunjukkan. AcceptSecurityContext tidak dapat membuat pernyataan tentang keaslian sisa pesan aplikasi yang tidak dilihatnya.
Kesalahan keamanan umum dalam aplikasi memperlakukan lalu lintas aplikasi seperti yang diautentikasi setelah keberhasilan autentikasi blob protokol autentikasi dalam. Ini paling umum terjadi dengan aplikasi yang menggunakan TLS untuk protokol kawat mereka. TLS biasanya tidak menggunakan sertifikat klien; server menyediakan jaminan integritas dan kerahasiaan kepada server, tetapi bukan autentikasi. Autentikasi dalam menyediakan autentikasi klien, tetapi hanya untuk blob-nya. Ini tidak mengautentikasi saluran TLS atau sisa protokol aplikasi yang terkandung di dalamnya.
Penyerang menjalankan serangan penerusan dengan memasukkan blob autentikasi dari satu sumber dengan permintaan yang dibuat penyerang. Misalnya, penyerang dapat mengamati lalu lintas autentikasi pada jaringan dan memasukkannya ke dalam permintaannya sendiri ke server. Ini memungkinkan penyerang untuk mendapatkan akses ke server sebagai klien dari lalu lintas autentikasi yang ditangkap.
Konsep utama di sini adalah bahwa pesan autentikasi SSPI dirancang untuk diekspos pada kawat; Mereka tidak diharapkan untuk dirahasiakan. Ini berbeda dari banyak skema autentikasi berbasis web yang menggunakan token pembawa yang selalu dirahasiakan di dalam saluran TLS.
Apa solusinya?
Solusi yang disukai adalah menggunakan kunci sesi protokol autentikasi untuk menandatangani atau mengenkripsi (MakeSignature, EncryptMessage) lalu lintas lainnya. Karena kunci sesi berasal secara kriptografis selama pertukaran protokol autentikasi, data yang diautentikasi, dan lalu lintas apa pun yang dilindungi oleh kunci tersebut dijamin berasal dari klien yang diautentikasi.
Ini tidak selalu menjadi pilihan. Dalam beberapa kasus, format pesan protokol aplikasi diperbaiki oleh standar yang dirancang untuk token pembawa. Dalam hal ini, Extended Protection for Authentication (EPA), juga dikenal sebagai Pengikatan Saluran, dapat melindungi dari penerusan melalui saluran TLS/SSL.
Apa itu EPA?
EPA secara kriptografi mengikat kunci sesi TLS ke kunci sesi protokol autentikasi, memungkinkan TLS untuk menyediakan autentikasi klien yang sama dengan kunci protokol autentikasi. Lihat Proteksi yang Diperluas untuk Gambaran Umum Autentikasi untuk informasi selengkapnya.
Pengikatan Layanan
Bagian kedua dari EPA disebut Pengikatan Layanan. Tidak seperti Pengikatan Saluran, ini tidak memberikan layanan dengan jaminan kriptografi dan berfungsi sebagai pertahanan upaya terakhir di mana pengikatan saluran tidak dimungkinkan. Mekanisme ini memungkinkan server memanggil QueryContextAttributes untuk mengambil atribut SECPKG_ATTR_CLIENT_SPECIFIED_TARGET yang berisi nama klien terautentikasi yang diteruskan ke InitializeSecurityContext.
Misalnya, bayangkan layanan yang berada di belakang load balancer penghentian TLS. Ini tidak memiliki akses ke kunci sesi TLS dan hanya dapat menentukan dari pengikatan saluran bahwa autentikasi klien ditujukan untuk layanan yang dilindungi TLS. Nama yang disediakan oleh klien harus bernama sama dengan yang digunakan untuk memvalidasi sertifikat server TLS. Dengan memverifikasi bahwa klien mengautentikasi ke nama yang cocok dengan sertifikat TLS server dari load balancer, layanan mendapatkan keyakinan tinggi bahwa autentikasi berasal dari klien yang sama dengan saluran TLS.
Artikel ini tidak akan membahas cara mendukung pengikatan layanan. Lihat Cara: Menentukan Pengikatan Layanan dalam Konfigurasi untuk informasi selengkapnya.
Bagaimana Anda mendukung EPA?
Saat memberlakukan EPA, layanan mungkin melihat klien gagal mengautentikasi karena masalah kompatibilitas. Oleh karena itu, kami telah membuat mode audit EPA di mana layanan dapat mengaktifkan audit, memberikan admin kontrol untuk mengamati bagaimana klien merespons sebelum memberlakukan EPA.
layanan Microsoft mendukung mode audit meliputi:
Catatan
Di bawah ini Anda akan menemukan langkah-langkah opsional untuk mengaktifkan fungsionalitas audit EPA. Harap dicatat, mengaktifkan fungsionalitas audit EPA tanpa memberlakukan EPA tidak melindungi dari serangan relai. Kami menyarankan agar layanan yang memilih untuk terlebih dahulu mengaktifkan EPA dalam mode audit saja, kemudian mengambil langkah-langkah untuk memulihkan klien yang tidak kompatibel dan akhirnya secara ketat memberlakukan EPA untuk menghindari potensi serangan relai.
Catatan
Pengikatan saluran yang diteruskan ke AcceptSecurityContext tidak perlu menjadi pengikatan khusus audit untuk mendapatkan hasil audit. Layanan dapat menjalankan mode audit saat masih memberlakukan EPA.
Klien
- Gunakan QueryContextAttributes(TLS) untuk mendapatkan pengikatan saluran (isi unik vs titik akhir)
- Panggil InitializeSecurityContext, dan lewati pengikatan saluran di SECBUFFER_CHANNEL_BINDINGS
Server
- Gunakan QueryContextAttributes(TLS), seperti pada klien
- (Opsional) Masuk ke audit-saja dengan memanggil SspiSetChannelBindingFlags
- (Opsional) Tambahkan buffer hasil pengikatan saluran ke buffer output untuk ASC.
- Tentukan tingkat EPA dan konfigurasi lainnya dengan memanggil AcceptSecurityContext dengan SECBUFFER_CHANNEL_BINDINGS
- (Opsional) Gunakan bendera untuk mengontrol perilaku dalam kasus sudut:
- ASC_REQ_ALLOW_MISSING_BINDINGS - Jangan gagalkan klien yang tidak mengatakan apa-apa sama sekali, seperti perangkat pihak ketiga lama. Klien yang tercerahkan yang tidak mendapatkan SECBUFFER_CHANNEL_BINDINGS akan mengirim pengikatan kosong daripada tidak ada.
- ASC_REQ_PROXY_BINDINGS - Kasus langka untuk TLS menghentikan load balancer. Kami tidak memiliki SECBUFFER_CHANNEL_BINDINGS untuk diteruskan, tetapi masih ingin menegakkan bahwa klien memasukkan permintaan ke dalam saluran TLS. Ini paling berguna dengan pengikatan layanan untuk memastikan bahwa klien juga dimasukkan ke dalam saluran TLS yang sertifikasi servernya cocok dengan nama kami.
Bagaimana Anda menerapkan EPA?
Setelah layanan mendukung EPA, admin dapat mengontrol status EPA sepanjang jalan dari audit hingga penegakan penuh. Ini memberi layanan alat untuk mengevaluasi kesiapan ekosistem mereka untuk EPA, memulihkan perangkat yang tidak kompatibel, dan secara progresif memberlakukan EPA untuk melindungi lingkungan mereka.
Atribut dan nilai berikut dapat digunakan untuk memberlakukan berbagai tingkat EPA di lingkungan Anda:
| Nama | Deskripsi |
|---|---|
| Tidak | Tidak ada validasi pengikatan saluran yang dilakukan. Ini adalah perilaku semua server yang belum diperbarui. |
| Bolehkan | Semua klien yang telah diperbarui harus memberikan informasi pengikatan saluran ke server. Klien yang belum diperbarui tidak perlu melakukannya. Ini adalah opsi perantara yang memungkinkan kompatibilitas aplikasi. |
| Wajib | Semua klien harus memberikan informasi pengikatan saluran. Server menolak permintaan autentikasi dari klien yang tidak melakukannya. |
Atribut ini dapat digabungkan dengan fungsi audit untuk mengumpulkan informasi tentang kompatibilitas perangkat di berbagai tingkat penerapan EPA. Anda akan meneruskan konfigurasi yang Anda inginkan ke SspiSetChannelBindingFlags.
- Audit - Mode audit dapat digunakan bersama dengan salah satu tingkat penerapan EPA di atas.
Bagaimana Anda menginterpretasikan hasil audit EPA?
Hasil audit adalah sekumpulan bendera bit:
| Bendera | Deskripsi |
|---|---|
| SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT | Klien menunjukkan bahwa itu mampu mengikat saluran. |
| SEC_CHANNEL_BINDINGS_RESULT_ABSENT | Klien tidak menyediakan pengikatan ke saluran luar. |
| SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH | Pengikatan klien menunjukkan saluran yang berbeda dari server. |
| SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING | Pengikatan saluran gagal karena SEC_CHANNEL_BINDINGS_RESULT_ABSENT. |
| SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED | Saluran berhasil diikat. |
| SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY | Klien menunjukkan pengikatan ke saluran luar, yang diteruskan karena ASC_REQ_PROXY_BINDINGS. |
| SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING | Pengikatan saluran diteruskan karena ASC_REQ_ALLOW_MISSING_BINDINGS. |
Ada juga definisi untuk set bit:
| Bendera | Deskripsi |
|---|---|
| SEC_CHANNEL_BINDINGS_RESULT_VALID | Digunakan untuk menguji semua kasus SEC_CHANNEL_BINDINGS_VALID_*. |
| SEC_CHANNEL_BINDINGS_RESULT_NOTVALID | Digunakan untuk menguji semua kasus SEC_CHANNEL_BINDINGS_NOTVALID_*. |
Alur audit
OS apa pun yang mendukung hasilnya akan selalu menetapkan setidaknya satu bit dari SEC_CHANNEL_BINDINGS_RESULT_VALID dan SEC_CHANNEL_BINDINGS_RESULT_NOTVALID.
Pengikatan saluran gagal: Uji bit apa pun dari SEC_CHANNEL_BINDINGS_RESULT_NOTVALID. Untuk pengikatan yang tidak hanya audit, ini sesuai dengan ASC yang gagal dengan STATUS_BAD_BINDINGS atau SEC_E_BAD_BINDINGS.
- SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH: Klien dan server sama-sama tahu tentang pengikatan saluran tetapi tidak setuju tentang saluran. Ini adalah kasus serangan atau konfigurasi keamanan yang tidak tepat yang tidak dapat dibedakan dari serangan karena konfigurasi telah membahayakan HTTPS untuk memeriksa lalu lintas (misalnya Fiddler). Ini juga bisa menjadi klien dan server yang tidak setuju tentang pengikatan titik akhir yang unik versus.
- SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING dibagi menjadi dua kasus:
- Dengan SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT, itu berarti bahwa klien membuktikan bahwa ia tahu tentang pengikatan saluran dan mengatakan tidak ada saluran. Ini bisa menjadi serangan penerusan dari layanan non-TLS, tetapi kemungkinan menjadi aplikasi yang tidak tercerahkan yang berjalan pada klien yang melakukan TLS tetapi tidak memberi tahu autentikasi dalam tentang hal itu.
- Tanpa SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT, ini adalah klien yang tidak mampu mengikat saluran. Semua versi Windows yang didukung mampu mengikat saluran, jadi ini adalah pihak ketiga atau sistem yang memiliki nilai registri SuppressExtendedProtection yang ditetapkan. Ini adalah kasus yang berubah menjadi SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING jika Anda lulus ASC_REQ_ALLOW_MISSING_BINDINGS.
Pengikatan saluran berhasil: Ini adalah inversi dari pemeriksaan kegagalan, atau pengujian untuk SEC_CHANNEL_BINDINGS_RESULT_VALID.
- SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED adalah kasus keberhasilan. Perlindungan keamanan berfungsi (atau akan berfungsi jika EPA diaktifkan sebagai audit saja).
- SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING berarti bahwa ASC_REQ_ALLOW_MISSING_BINDINGS diteruskan, jadi kami mengizinkan klien yang tidak mengklaim dukungan untuk pengikatan saluran. Klien yang mencapai kasus ini tidak dilindungi dan harus diselidiki untuk melihat apa yang salah. Mereka perlu diperbarui untuk mendukung pengikatan saluran, atau nilai registri SuppressExtendedProtection harus dihapus setelah aplikasi yang rusak diperbarui.
- SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY adalah kasus khusus yang terkait dengan bendera ASC_REQ_PROXY_BINDINGS yang digunakan saat TLS dihentikan pada load balancer alih-alih mencapai server. Server tidak dapat memverifikasi bahwa klien menggunakan koneksi TLS yang sama seperti yang dihentikan di load balancer. Untuk tujuan audit, ini diperlakukan sama dengan SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED.
Baca juga
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk