Kerentanan keamanan CVE-2021-44228 dan CVE-2021-45046 telah diungkapkan di library Apache Log4j versi 2.0 hingga 2.15. Utilitas Apache Log4j adalah komponen yang umum digunakan untuk mencatat log permintaan. Kerentanan ini, yang juga disebut Log4Shell, dapat memungkinkan sistem yang menjalankan Apache Log4j versi 2.0 hingga 2.15 disusupi dan memungkinkan penyerang mengeksekusi kode arbitrer.
Kerentanan ini tidak memengaruhi Cloud Logging atau agen yang disediakan untuk mengumpulkan log dari aplikasi pihak ketiga, tetapi jika Anda menggunakan Log4j 2, layanan Anda mungkin terpengaruh.
Anda dapat menggunakan Logging untuk mengidentifikasi kemungkinan serangan. Dokumen ini menjelaskan cara melakukan hal berikut:
- Kueri log Anda menggunakan Logs Explorer untuk mengetahui upaya yang ada untuk mengeksploitasi kerentanan Log4j 2.
- Pastikan teknik mitigasi yang diaktifkan seperti kebijakan keamanan Cloud Armor dan kontrol akses Identity-Aware Proxy dikonfigurasi dengan benar dan beroperasi seperti yang diharapkan dengan memblokir upaya eksploitasi Log4j 2 ini.
- Buat kebijakan pemberitahuan untuk memberi tahu Anda saat pesan kemungkinan eksploitasi ditulis ke log Anda.
Tinjau Log4j 2 Security Advisory Google Clouduntuk penilaian produk dan layanan Google Cloud saat ini. Anda dapat menilai eksposur Anda dengan membaca laporan kerentanan dari National Institute of Standards and Technology (NIST) untuk CVE-2021-44228.
Deteksi logging
Hasil kueri pencatatan hanya mencakup log yang telah disimpan di bucket log dan juga berada dalam batas retensi yang ditentukan pengguna. Meskipun sebagian besar layanan Google Cloud mengaktifkan log secara default, log yang dinonaktifkan atau dikecualikan tidak disertakan dalam kueri Anda. Sebaiknya aktifkan log di seluruh lingkungan Anda untuk memperluas visibilitas Anda ke lingkungan tersebut.
Jika Anda menggunakan Load Balancer HTTP(S), Anda harus mengaktifkan logging agar log permintaan tersedia di Logging. Demikian pula, jika Anda memiliki server web seperti Apache atau NGINX yang berjalan di VM, tetapi belum menginstal Agen Operasional atau Agen logging, log tersebut tidak akan dapat diakses dalam Logging.
Membuat kueri log
Anda dapat menggunakan Logs Explorer untuk membantu mendeteksi potensi serangan pada layanan Anda yang mengeksploitasi kerentanan Log4j 2. Jika Anda menggunakan
Logging untuk mencatat permintaan ke layanan Anda, Anda dapat memeriksa kolom httpRequest dengan konten buatan pengguna untuk mengetahui potensi eksploitasi.
Nilai di kolom httpRequest mungkin memiliki token string seperti
${jndi:ldap://,
tetapi ada banyak variasi dalam cara kerentanan ini dieksploitasi.
Misalnya, ada banyak cara untuk menggunakan karakter escape atau Unicode untuk menghindari deteksi.
String berikut menunjukkan beberapa contoh umum yang mengindikasikan upaya eksploitasi terhadap sistem Anda, tetapi ini bukan kumpulan varian yang lengkap:
${jndi:
$%7Bjndi:
%24%7Bjndi:
${jNdI:ldAp
${jndi:${lower:l}${lower:d}${lower:a}${lower:p}:
${${lower:j}${lower:n}${lower:d}i:
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}:
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}
Anda dapat membuat kueri di Logs Explorer yang memindai beberapa string eksploitasi yang mungkin terjadi. Misalnya, kueri berikut mencoba mencocokkan berbagai variasi string ${jndi: yang di-obfuscate di kolom httpRequest dalam log permintaan Load Balancer HTTP(S). Perhatikan bahwa ekspresi
reguler yang digunakan dalam kueri tidak mendeteksi semua variasi, dan
dapat menyebabkan positif palsu:
resource.type="http_load_balancer"
httpRequest.requestUrl=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR
httpRequest.userAgent=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR
httpRequest.referer=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)"
Anda dapat menggunakan kueri sebelumnya untuk memindai log permintaan di layanan lain dengan
mengubah nilai resource.type.
Kueri sebelumnya dapat memerlukan waktu yang lama untuk diselesaikan saat Anda memindai log dalam jumlah besar. Agar kueri Anda berjalan lebih cepat, Anda dapat menggunakan kolom yang diindeks seperti resource.type, resource.labels, atau logName untuk mempersempit kueri Anda ke sekumpulan layanan atau aliran log tertentu.
Mendeteksi entri log yang cocok tidak berarti telah terjadi kompromi yang berhasil. Jika sesuatu terdeteksi, sebaiknya Anda mengikuti proses respons insiden organisasi Anda. Kecocokan dapat menunjukkan bahwa seseorang sedang menyelidiki untuk mengeksploitasi kerentanan dalam project atau workload Anda. Atau, mungkin juga merupakan positif palsu, jika aplikasi Anda menggunakan
pola seperti ${jndi: di kolom permintaan HTTP. Lihat kembali log Anda untuk memastikan bahwa pola ini bukan bagian dari perilaku aplikasi normal.
Perbaiki kueri agar sesuai dengan lingkungan Anda.
Menelusuri alamat IP yang melanggar
Jika Anda menemukan hasil yang cocok, dan jika Anda ingin melakukan agregasi pada alamat IP jarak jauh yang mengirim permintaan tersebut, tambahkan kolom remoteIp ke panel Kolom log di Logs Explorer. Untuk menambahkan kolom remoteIp, klik nilai kolom dalam entri log yang cocok dan pilih Tambahkan kolom ke panel Kolom log, seperti yang ditunjukkan dalam screenshot berikut:
Sekarang Anda dapat melihat alamat IP jarak jauh teratas yang mengirim permintaan yang cocok di panel Kolom log:
Dengan begitu, Anda akan mendapatkan perincian sumber pemindaian eksploitasi kerentanan Log4j 2 ini. Beberapa di antaranya mungkin merupakan pemindaian yang sah dari alat pemindaian kerentanan aplikasi yang mungkin telah Anda konfigurasi, seperti Web Security Scanner. Jika Anda menggunakan Web Security Scanner dari Security Command Center, perhatikan rentang alamat IP statis yang digunakan oleh Web Security Scanner.
Telusuri aplikasi yang ditargetkan dan verifikasi teknik mitigasi
Anda juga dapat melakukan agregasi pada aplikasi yang ditargetkan, dan mengidentifikasi apakah permintaan berbahaya benar-benar telah mencapai aplikasi Anda. Jika telah mengaktifkan teknik mitigasi menggunakan kebijakan keamanan oleh Cloud Armor atau kontrol akses oleh Identity-Aware Proxy (IAP), Anda juga dapat memverifikasi bahwa teknik tersebut berfungsi seperti yang diharapkan dari informasi yang dicatat dalam log Load Balancer HTTP(S).
Pertama, untuk menambahkan aplikasi yang ditargetkan ke panel Kolom log, pilih salah satu hasil entri log, luaskan resource.labels, klik nilai kolom resource.labels.backend_service_name, lalu pilih Tambahkan kolom ke panel Kolom log.
Sekarang Anda dapat melihat aplikasi atau layanan backend teratas yang menjadi target pemindaian eksploitasi Log4j 2. Untuk menentukan apakah upaya eksploitasi ini bahkan mencapai layanan backend Anda, gunakan kolom jsonPayload.statusDetails yang diisi oleh Load Balancer HTTP(S) untuk mempelajari apakah permintaan di-proxy ke backend, atau berhasil diblokir oleh layanan seperti IAP atau Cloud Armor. Klik nilai kolom jsonPayload.statusDetails dari hasil entri log, lalu pilih Tambahkan kolom ke panel Kolom log.
Sekarang Anda dapat melihat perincian cara permintaan ditangani, di panel Kolom log:
Dalam contoh ini, sebagian besar permintaan diblokir oleh IAP
yang, jika diaktifkan di layanan backend, memverifikasi identitas pengguna dan konteks
penggunaan sebelum mengizinkan akses. Permintaan yang diblokir IAP tersebut memiliki
statusDetails yang ditetapkan sebagai handled_by_identity_aware_proxy. Selain itu
(atau sebagai alternatif), jika menggunakan Cloud Armor dengan kebijakan
keamanan yang tepat terpasang pada layanan backend, semua permintaan yang diblokir
Cloud Armor akan memiliki statusDetails yang ditetapkan sebagai denied_by_security_policy. Untuk mengetahui detail cara menerapkan aturan WAF cve-canary yang telah dikonfigurasi sebelumnya ke kebijakan keamanan Cloud Armor, lihat Aturan WAF Google Cloud Armor untuk membantu mengurangi kerentanan Apache Log4j.
Untuk memfilter permintaan yang diizinkan yang benar-benar mencapai layanan backend, pilih
response_sent_by_backend di bagian statusDetails pada panel Kolom log.
Pertimbangkan untuk mengaktifkan IAP untuk layanan backend ini dan menerapkan
kebijakan keamanan Cloud Armor dengan aturan WAF cve-canary yang telah dikonfigurasi sebelumnya
untuk membantu memblokir upaya eksploitasi ini.
Membuat kebijakan pemberitahuan berbasis log
Setelah mendesain kueri yang menemukan log yang terpengaruh di layanan Anda, Anda dapat menggunakan kueri tersebut untuk membuat kebijakan pemberitahuan berbasis log yang akan memberi tahu Anda saat entri log baru cocok dengan kueri. Insiden yang dibuat oleh kebijakan pemberitahuan dapat diteruskan ke pusat operasi keamanan (SOC) organisasi Anda atau tim respons insiden yang sesuai.
Untuk mengetahui informasi tentang cara membuat kebijakan pemberitahuan berbasis log, lihat Membuat kebijakan pemberitahuan berbasis log (Logs Explorer). Saat Anda membuat kebijakan pemberitahuan, pastikan untuk menggunakan kueri Anda untuk string eksploitasi alih-alih kueri yang ditentukan dalam contoh.
Membuat kebijakan pemberitahuan untuk metrik berbasis log
Untuk memantau endpoint atau layanan mana yang mencatat kemungkinan upaya eksploitasi, buat kebijakan pemberitahuan pada metrik berbasis log:
Buat metrik berbasis log untuk menghitung kemunculan kemungkinan string eksploitasi dalam log Anda. Misalnya, Anda dapat menggunakan Google Cloud CLI untuk membuat metrik tersebut:
gcloud logging metrics create log4j_exploits \ --description="Detect log4j exploits" \ --log-filter='httpRequest.requestUrl=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR httpRequest.userAgent=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)" OR httpRequest.referer=~"(?i)(\$|\%24)(\{|\%7b).*j.*n.*d.*i.*(\:|\%3a)"'Untuk mengetahui informasi selengkapnya tentang cara membuat metrik berbasis log, lihat Mengonfigurasi metrik penghitung.
Buat kebijakan pemberitahuan untuk memberi tahu Anda saat jumlah kemunculan yang dipilih tercapai. Untuk mengetahui informasi tentang cara menyiapkan kebijakan pemberitahuan, lihat Membuat kebijakan pemberitahuan pada metrik penghitung.
Langkah berikutnya
Periksa dokumen ini untuk mengetahui info terbaru saat informasi baru tersedia.
Untuk mengetahui informasi selengkapnya tentang kerentanan Log4j 2 dan layanan Google Cloud Anda, lihat artikel berikut: