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 permintaan ke dalam log. Kerentanan ini, yang juga disebut Log4Shell, dapat membuat sistem yang menjalankan Apache Log4j versi 2.0 hingga 2.15 disusupi dan membiarkan penyerang mengeksekusi kode arbitrer.
Kerentanan ini tidak memengaruhi Cloud Logging atau agen yang disediakannya untuk mengumpulkan log dari aplikasi pihak ketiga. Namun, 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 menggunakan Logs Explorer untuk upaya yang ada guna mengeksploitasi kerentanan Log4j 2.
- Pastikan teknik mitigasi yang Anda gunakan, seperti kebijakan keamanan Google Cloud Armor, dan kontrol akses Identity-Aware Proxy, telah dikonfigurasi dengan benar dan beroperasi sesuai harapan dengan memblokir upaya eksploitasi Log4j 2 ini.
- Buat kebijakan pemberitahuan untuk memberi tahu Anda jika pesan eksploitasi mungkin ditulis ke log Anda.
Tinjau Log4j 2 Security Advisory Google Cloud untuk menilai produk dan layanan Google Cloud kami 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 mencakup log yang telah disimpan dalam bucket log dan juga 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 Agen Operasional atau Agen Logging, log tersebut tidak akan dapat diakses dalam Cloud Logging.
Membuat kueri untuk log
Anda dapat menggunakan Logs Explorer untuk membantu mendeteksi potensi serangan
di layanan Anda yang memanfaatkan kerentanan Log4j 2. Jika menggunakan Cloud Logging untuk mencatat permintaan ke layanan ke dalam log, Anda dapat memeriksa kolom httpRequest yang berisi konten buatan pengguna untuk mengetahui potensi eksploitasi.
Nilai di kolom httpRequest mungkin memiliki token string seperti
${jndi:ldap://,
tetapi ada banyak variasi terkait cara kerentanan ini dieksploitasi.
Misalnya, ada banyak cara untuk menggunakan escaping atau Unicode untuk 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 eksploitasi. 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 (PP):
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 lama untuk diselesaikan saat Anda memindai log dalam jumlah besar. Agar kueri berjalan lebih cepat, Anda dapat memanfaatkan kolom terindeks seperti resource.type, resource.labels, atau logName untuk mempersempit kueri ke kumpulan layanan atau aliran log tertentu.
Mendeteksi entri log yang cocok bukan berarti telah terjadi penyusupan. Jika ada sesuatu yang terdeteksi, sebaiknya ikuti
proses respons insiden organisasi Anda. Adanya kecocokan dapat menunjukkan bahwa
seseorang menyelidiki untuk mengeksploitasi kerentanan dalam project atau
beban kerja Anda. Atau mungkin positif palsu (PP), jika aplikasi Anda menggunakan pola seperti ${jndi: dalam kolom permintaan HTTP. Periksa kembali log Anda untuk memastikan bahwa pola ini bukan bagian dari perilaku aplikasi yang normal.
Saring kueri agar sesuai dengan lingkungan Anda.
Menelusuri alamat IP yang melanggar
Jika Anda menemukan hasil yang cocok, dan jika ingin menggabungkan alamat IP jarak jauh yang mengirim permintaan tersebut, tambahkan kolom remoteIp ke panel Log fields di Logs Explorer. Untuk menambahkan kolom remoteIp,
klik nilai kolom di entri log yang cocok, lalu pilih Add field to Logs pane, seperti yang ditunjukkan pada screenshot berikut:
Sekarang, Anda dapat melihat alamat IP jarak jauh teratas yang mengirim permintaan yang cocok di panel Log fields:
Panduan ini memberi Anda perincian tentang asal 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, catat rentang alamat IP statis yang digunakan oleh Web Security Scanner.
Menelusuri aplikasi yang ditargetkan dan memverifikasi teknik mitigasi
Anda juga mungkin perlu menggabungkan aplikasi yang ditargetkan, dan mengidentifikasi apakah permintaan berbahaya benar-benar telah mencapai aplikasi Anda. Jika telah mengaktifkan teknik mitigasi menggunakan kebijakan keamanan oleh Google Cloud Armor atau kontrol akses dengan Identity-Aware Proxy (IAP), Anda juga dapat memverifikasi bahwa teknik mitigasi berfungsi seperti yang diharapkan 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.
Kini Anda dapat melihat aplikasi atau layanan backend teratas Anda yang ditarget oleh pemindaian eksploitasi Log4j 2. Untuk menentukan apakah upaya eksploit ini bahkan mencapai layanan backend Anda, gunakan kolom jsonPayload.statusDetails yang diisi oleh Load Balancer HTTP(S) untuk mengetahui apakah permintaan di-proxy-kan ke backend, atau berhasil diblokir oleh layanan seperti IAP atau Google Cloud Armor. Klik nilai kolom jsonPayload.statusDetails
dari hasil entri log, lalu pilih Add field to Logs fields pane.
Sekarang Anda dapat melihat perincian tentang cara penanganan permintaan, di panel Kolom log:
Dalam contoh ini, sebagian besar permintaan diblokir oleh IAP
yang jika diaktifkan pada layanan backend, akan 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 memiliki statusDetails yang ditetapkan sebagai denied_by_security_policy.
Untuk mengetahui detail tentang cara menerapkan aturan WAF cve-canary baru 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 Log fields. 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 merancang kueri yang menemukan log yang terpengaruh di layanan Anda, Anda dapat menggunakan kueri tersebut untuk membuat pemberitahuan berbasis log yang akan memberi tahu Anda saat entri log baru cocok dengan kueri tersebut. Pemberitahuan ini dapat diteruskan ke pusat operasi keamanan (SOC) organisasi Anda atau tim respons insiden yang sesuai.
Untuk mengetahui informasi tentang cara membuat pemberitahuan berbasis log, lihat Membuat pemberitahuan berbasis log (Logs Explorer). Saat membuat pemberitahuan, pastikan Anda menggunakan kueri untuk string exploit, bukan kueri yang ditentukan dalam contoh.
Membuat kebijakan pemberitahuan untuk metrik berbasis log
Untuk memantau endpoint atau layanan mana yang mencatat kemungkinan upaya eksploitasi ke dalam log, buat kebijakan pemberitahuan pada metrik berbasis log:
Buat metrik berbasis log untuk menghitung kemunculan kemungkinan string eksploitasi di log Anda. Misalnya, Anda dapat menggunakan Google Cloud CLI untuk membuat metrik semacam itu:
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 lebih lanjut mengenai pembuatan metrik berbasis log, lihat Mengonfigurasi metrik penghitung.
Buat kebijakan pemberitahuan untuk memberi tahu Anda jika jumlah kemunculan yang dipilih tercapai. Untuk mengetahui informasi tentang cara menyiapkan kebijakan pemberitahuan, lihat Membuat kebijakan pemberitahuan pada metrik penghitung.
Langkah selanjutnya
Periksa dokumen ini untuk mengetahui pembaruan saat informasi baru tersedia.
Untuk mengetahui informasi selengkapnya tentang kerentanan Log4j 2 dan layanan Google Cloud Anda, lihat artikel berikut: