Kerentanan keamanan CVE-2021-44228 dan CVE-2021-45046 telah diungkapkan di library Apache Log4j versi 2.0 hingga 2.15. Aplikasi utilitas Apache Log4j adalah komponen yang biasa 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 disediakannya untuk mengumpulkan log dari aplikasi pihak ketiga, tetapi jika Anda menggunakan Log4j 2, layanan Anda mungkin akan terpengaruh.
Anda dapat menggunakan Cloud Logging untuk mengidentifikasi kemungkinan serangan. Dokumen ini menjelaskan cara melakukan hal berikut:
- Buat kueri log Anda menggunakan Logs Explorer untuk menemukan upaya yang ada guna mengeksploitasi kerentanan Log4j 2.
- Pastikan teknik mitigasi yang diaktifkan seperti kebijakan keamanan Google 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 kemungkinan pesan eksploit ditulis ke log Anda.
Tinjau Konsultasi Keamanan Log4j 2 Google Cloud untuk penilaian produk dan layanan Google Cloud saat ini. Anda dapat menilai eksposur dengan membaca laporan kerentanan dari National Institute of Standards and Technology (NIST) untuk CVE-2021-44228.
Deteksi Cloud Logging
Hasil kueri Cloud Logging hanya menyertakan 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 untuk memperluas visibilitas Anda ke lingkungan.
Jika menggunakan Load Balancer HTTP(S), Anda harus mengaktifkan logging agar log permintaan tersedia di Cloud Logging. Demikian pula, jika Anda memiliki server web seperti Apache atau NGINX yang berjalan di VM, tetapi belum menginstal Ops Agent atau Logging agent, log tersebut tidak akan dapat diakses dalam Cloud Logging.
Membuat kueri terhadap log
Anda dapat menggunakan Logs Explorer untuk membantu mendeteksi potensi serangan
pada layanan Anda yang mengeksploitasi kerentanan Log4j 2. Jika menggunakan Cloud Logging untuk mencatat log permintaan ke layanan, Anda dapat memeriksa kolom httpRequest dengan konten buatan pengguna untuk menemukan 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 escape atau Unicode guna menghindari deteksi.
String berikut menunjukkan beberapa contoh umum yang menunjukkan 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 kemungkinan string eksploit. 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 hal ini 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 berjalan lebih cepat, Anda dapat menggunakan kolom yang diindeks seperti resource.type, resource.labels, atau logName untuk mempersempit kueri ke sekumpulan layanan atau aliran log tertentu.
Mendeteksi entri log yang cocok tidak berarti telah terjadi
penyeberangan yang berhasil. Jika ada sesuatu yang terdeteksi, sebaiknya ikuti
proses respons insiden organisasi Anda. Kecocokan mungkin menunjukkan bahwa seseorang sedang menyelidiki untuk mengeksploitasi kerentanan dalam project atau workload Anda. Atau mungkin 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.
Pertajam kueri agar sesuai dengan lingkungan Anda.
Menelusuri alamat IP yang melanggar
Jika Anda menemukan hasil yang cocok, dan jika Anda ingin menggabungkan 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, lalu 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 Log fields:
Hal ini memberi Anda perincian tentang asal pemindaian eksploit 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.
Menelusuri aplikasi yang ditargetkan dan memverifikasi teknik mitigasi
Anda juga dapat menggabungkan aplikasi yang ditargetkan, dan mengidentifikasi apakah permintaan berbahaya benar-benar telah menjangkau aplikasi Anda. Jika telah mengaktifkan teknik mitigasi menggunakan kebijakan keamanan oleh Google Cloud Armor atau kontrol akses oleh Identity-Aware Proxy (IAP), Anda juga dapat memverifikasi bahwa teknik tersebut berfungsi sebagaimana mestinya dari informasi yang dicatat dalam log Load Balancer HTTP(S).
Pertama, untuk menambahkan aplikasi yang ditargetkan ke panel Log fields, pilih salah satu
hasil entri log, luaskan resource.labels, klik nilai kolom resource.labels.backend_service_name, lalu pilih Add field to Logs fields pane.
Sekarang Anda dapat melihat aplikasi atau layanan backend teratas yang ditargetkan oleh
pemindaian eksploit 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 Google Cloud Armor. Klik nilai kolom jsonPayload.statusDetails
dari hasil entri log, lalu pilih Tambahkan kolom ke panel kolom Logs.
Sekarang Anda dapat melihat perincian cara permintaan ditangani, di panel Kolom log:
Dalam contoh ini, sebagian besar permintaan diblokir oleh IAP
yang, saat diaktifkan di layanan backend, memverifikasi identitas pengguna dan menggunakan konteks
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 Google Cloud Armor dengan kebijakan keamanan yang benar yang disertakan di layanan backend, semua permintaan yang diblokir Google Cloud Armor akan menetapkan statusDetails sebagai denied_by_security_policy.
Untuk mengetahui detail tentang cara menerapkan aturan WAF cve-canary yang telah dikonfigurasi sebelumnya ke kebijakan keamanan Google Cloud Armor, lihat Aturan WAF Google Cloud Armor untuk membantu mengurangi kerentanan Apache Log4j.
Untuk memfilter permintaan yang diizinkan yang benar-benar menjangkau layanan backend, pilih response_sent_by_backend
di bagian statusDetails di panel Kolom log. Pertimbangkan untuk mengaktifkan IAP untuk layanan backend ini
dan/atau menerapkan kebijakan keamanan Google Cloud Armor dengan aturan WAF cve-canary yang telah dikonfigurasi sebelumnya untuk membantu memblokir upaya eksploitasi ini.
Membuat pemberitahuan berbasis log
Setelah mendesain kueri yang menemukan log yang terpengaruh di layanan, Anda dapat menggunakan kueri tersebut untuk membuat pemberitahuan berbasis log yang akan memberi tahu Anda saat entri log baru cocok dengan kueri. Notifikasi ini dapat diteruskan ke pusat operasi keamanan (SOC) organisasi Anda atau tim respons insiden yang sesuai.
Untuk informasi tentang cara membuat pemberitahuan berbasis log, lihat Membuat pemberitahuan berbasis log (Logs Explorer). Saat membuat pemberitahuan, pastikan untuk menggunakan kueri untuk string eksploit, bukan kueri yang ditentukan dalam contoh.
Membuat kebijakan pemberitahuan untuk metrik berbasis log
Untuk memantau endpoint atau layanan yang mencatat kemungkinan upaya eksploitasi, buat kebijakan pemberitahuan pada metrik berbasis log:
Buat metrik berbasis log untuk menghitung kemunculan kemungkinan string eksploit 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 informasi selengkapnya tentang cara membuat metrik berbasis log, lihat Mengonfigurasi metrik penghitung.
Buat kebijakan pemberitahuan untuk memberi tahu Anda saat jumlah kejadian yang dipilih tercapai. Untuk informasi tentang cara menyiapkan kebijakan pemberitahuan, lihat Membuat kebijakan pemberitahuan pada metrik penghitung.
Langkah selanjutnya
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 hal berikut: