Kali ini, Anda akan belajar tentang Mendeteksi Log4Shell dengan Wazuh
Apache Log4J adalah salah satu perpustakaan logging paling umum di Jawa, terutama digunakan untuk pesan kesalahan. Ini adalah bagian dari beberapa aplikasi bernilai tinggi termasuk iCloud, Twitter, dan Minecraft antara lain.
Baru-baru ini, kerentanan zero-day yang dijuluki Log4Shell dengan CVE CVE-2021-44228 terdeteksi di Log4J 2 Apache yang memungkinkan pelaku jahat meluncurkan serangan Remote Code Execution (RCE). Ini berarti penyerang dapat mengirim perintah dari jarak jauh ke server yang menjalankan aplikasi rentan.
Versi Apache Log4j 2 yang terpengaruh adalah 2.0-beta9
ke 2.15
.
Faktanya, versi 2.15.0
yang merupakan perbaikan awal untuk kerentanan kemudian ditemukan masih rentan. Jadi disarankan untuk memperbarui ke versi 2.16.0
yang menonaktifkan JNDI dan menghapus %m{lookups}
.
Ada beberapa cara untuk mempertahankan sistem Anda dari kerentanan dan potensi serangan ini:
- Menjalankan pemindaian untuk mendeteksi saat ada versi rentan Apache Log4j 2 di sistem Anda.
- Menambal kerentanan dengan memperbarui ke Apache Log4j 2 versi
2.16.0
atau menonaktifkan JNDI. - Membuat aturan deteksi yang memantau koneksi dan log akses web untuk mendeteksi upaya eksploitasi.
Kunci untuk memerangi gelombang serangan saat ini adalah deteksi dini kerentanan untuk patching segera, dan pemantauan konstan semua aset untuk mengidentifikasi saat ada upaya untuk mengeksploitasi kerentanan ini.
Kami akan melihat bagaimana Wazuh dapat membantu pemantauan dan deteksi kerentanan ini di bagian berikut.
silahkan cek langkah-langkah instalasi wazuh disini “https://unixcop.com/wazuh-the-open-source-security-platform/”
Memindai versi rentan Apache Log4j 2
Kami akan menggunakan kebijakan Wazuh SCA (Penilaian Konfigurasi Keamanan) untuk ini. Kebijakan SCA ditulis dalam format YAML dan digunakan untuk menjalankan pemeriksaan untuk pengerasan sistem; dalam banyak kasus mendeteksi perangkat lunak yang rentan juga termasuk dalam kategori ini.
Kecuali dinyatakan lain, semua konfigurasi berikut dilakukan di sisi server Wazuh. Biasanya tidak perlu mengedit konfigurasi lokal dari agen yang dipantau.
Pertama, kita buat file kebijakan baru di /var/ossec/etc/shared/default/log4j_check.yml
:
policy:
id: "log4j_check"
file: "log4j_check.yml"
name: "Log4j dependency check"
description: "This document provides prescriptive guidance for identifying Log4j RCE vulnerability"
references:
- https://nvd.nist.gov/vuln/detail/CVE-2021-44228
- https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
requirements:
title: "Check if Java is present on the machine"
description: "Requirements for running the SCA scan against machines with Java on them."
condition: all
rules:
- 'c:sh -c "ps aux | grep java | grep -v grep" -> r:java'
checks:
- id: 10000
title: "Ensure Log4j is not on the system or under 2.16"
description: "The Log4j library is vulnerable to RCE on versions between 2.10 and 2.15."
remediation: "Update the log4j library to version 2.16 or set log4j2.formatMsgNoLookups to true if possible."
condition: none
rules:
- 'c:find / -regex ".*log4j.*.jar" -type f -exec sh -c "unzip -p {} META-INF/MANIFEST.MF | grep Implementation-Version" \; -> r: 2.10.| 2.11.| 2.12.| 2.13.| 2.14.| 2.15.'
- id: 10001
title: "Ensure Java is not running or is properly configured"
description: "The Log4j library is vulnerable to RCE on versions between 2.10 and 2.15."
remediation: "Update the log4j library to version 2.16 or set log4j2.formatMsgNoLookups to true if possible."
condition: any
rules:
- 'c:sh -c "ps aux | grep java | grep -v grep" -> r:java && r:Dlog4j2.formatMsgNoLookups=true'
policy:
id: "log4j_check"
file: "log4j_check.yml"
name: "Log4j dependency check"
description: "This document provides prescriptive guidance for identifying Log4j RCE vulnerability"
references:
- https://nvd.nist.gov/vuln/detail/CVE-2021-44228
- https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
requirements:
title: "Check if Java is present on the machine"
description: "Requirements for running the SCA scan against machines with Java on them."
condition: all
rules:
- 'c:sh -c "ps aux | grep java | grep -v grep" -> r:java'
checks:
- id: 10000
title: "Ensure Log4j is not on the system or under 2.16"
description: "The Log4j library is vulnerable to RCE on versions between 2.10 and 2.15."
remediation: "Update the log4j library to version 2.16 or set log4j2.formatMsgNoLookups to true if possible."
condition: none
rules:
- 'c:find / -regex ".*log4j.*.jar" -type f -exec sh -c "unzip -p {} META-INF/MANIFEST.MF | grep Implementation-Version" \; -> r: 2.10.| 2.11.| 2.12.| 2.13.| 2.14.| 2.15.'
- id: 10001
title: "Ensure Java is not running or is properly configured"
description: "The Log4j library is vulnerable to RCE on versions between 2.10 and 2.15."
remediation: "Update the log4j library to version 2.16 or set log4j2.formatMsgNoLookups to true if possible."
condition: any
rules:
- 'c:sh -c "ps aux | grep java | grep -v grep" -> r:java && r:Dlog4j2.formatMsgNoLookups=true'
Kami melakukan ini agar kebijakan SCA dibagikan dengan sekelompok agen, yang akan menjalankan pemeriksaan. Dalam kasus kami, kami membagikan kebijakan dengan grup default, oleh karena itu default
direktori.
Catatan: Perlu diketahui bahwa, tergantung pada sistem yang dipantau, find
perintah yang digunakan untuk mendeteksi aplikasi yang rentan dapat memakan banyak CPU.
Selain itu, setelah file kebijakan SCA dibuat, pemilik dan grup diubah sehingga dapat digunakan oleh Wazuh:
chown ossec:ossec /var/ossec/etc/shared/default/log4j_check.yml
Selanjutnya, kami menambahkan blok SCA ke /var/ossec/etc/shared/default/agent.conf
untuk mengaktifkan kebijakan baru pada agen Wazuh yang termasuk dalam default
grup:
<agent_config>
<sca>
<enabled>yes</enabled>
<scan_on_start>yes</scan_on_start>
<interval>24h</interval>
<skip_nfs>yes</skip_nfs>
<policies>
<policy>/var/ossec/etc/shared/log4j_check.yml</policy>
</policies>
</sca>
</agent_config>
Di bawah ini kami mengedit pengaturan lokal pada file konfigurasi agen Wazuh. Ini dilakukan secara langsung pada sistem yang sedang dipantau, karena tidak ada cara untuk mendorong pengaturan ini dari server Wazuh. Tujuan dari modifikasi ini adalah untuk mengaktifkan eksekusi perintah dalam kebijakan SCA yang diterima dari server Wazuh. Ini tidak diperlukan jika kebijakan SCA tersebut bersifat lokal bagi agen.
echo "sca.remote_commands=1" >> /var/ossec/etc/local_internal_options.conf
Agar pengaturan baru berlaku, kami memulai ulang agen Wazuh. Server juga mendorong file kebijakan SCA baru secara otomatis.
Kita dapat melihat di bawah peristiwa SCA bahwa sistem saat ini memiliki versi Log4J 2 yang rentan.
Mendeteksi Upaya Eksploitasi Log4Shell
Untuk menambahkan lapisan keamanan lain, kami membuat aturan yang akan mendeteksi upaya eksploitasi Log4Shell.
Untuk kasus khusus ini, kami memantau log akses web dan mencari pola tertentu yang diketahui digunakan untuk eksploitasi ini.
Kami menambahkan aturan berikut ke server Wazuh kami di /var/ossec/etc/rules/local_rules.xml
berkas:
<group name="log4j, attack,">
<rule id="110002" level="7">
<if_group>web|accesslog|attack</if_group>
<regex type="pcre2">(?i)(((\$|24)\S*)((\{|7B)\S*)((\S*j\S*n\S*d\S*i))|JHtqbmRp)</regex>
<description>Possible Log4j RCE attack attempt detected.</description>
<mitre>
<id>T1190</id>
<id>T1210</id>
<id>T1211</id>
</mitre>
</rule>
<rule id="110003" level="12">
<if_sid>110002</if_sid>
<regex type="pcre2">ldap[s]?|rmi|dns|nis|iiop|corba|nds|http|lower|upper|(\$\{\S*\w\}\S*)+</regex>
<description>Log4j RCE attack attempt detected.</description>
<mitre>
<id>T1190</id>
<id>T1210</id>
<id>T1211</id>
</mitre>
</rule>
</group>
Kami juga memulai ulang pengelola Wazuh untuk menerapkan aturan ini:
systemctl restart wazuh-manager
Sistem agen kami menjalankan server web Apache.
Dalam beberapa kasus, Wazuh mungkin belum memantau file log web. Kami mengaktifkan pengumpulan data log dengan memodifikasi grup konfigurasi di sisi server Wazuh. Untuk ini, kami menambahkan blok berikut ke /var/ossec/etc/shared/default/agent.conf
:
<localfile>
<log_format>syslog</log_format>
<location>/var/log/apache2/access.log</location>
</localfile>
Untuk menguji aturan ini, kami mengirim permintaan web dengan pola Log4Shell yang diketahui ke sistem yang dipantau. Permintaan dapat dikirim dari perangkat apa pun yang memiliki konektivitas jaringan dengan titik akhir:
http://your_system_ip_address/?x=${jndi:ldap://${localhost}.{{test}}/a}
Kami segera mencatatnya di bawah peristiwa keamanan.
Kesimpulan
Singkatnya, kami dapat mendeteksi keberadaan kerentanan Log4Shell dengan memanfaatkan kebijakan SCA. Kami juga membuat aturan yang memantau log akses web untuk mendeteksi bila ada pola eksploitasi yang diketahui dalam permintaan web.
Ini berguna bagi mereka yang ingin tetap proaktif dengan menerapkan langkah-langkah yang akan memperingatkan bila ada indikasi kerentanan Log4Shell.