Pendahuluan

Untuk pendahuluan mengenai Vulnerability / Kerentanan Log4j2 ini bisa dilihat di artikel sebelumnya. link

Untuk penyebab Vulnerability / Kerentanan Log4j2 ini bisa dilihat di artikel sebelumnya. link

Untuk Mitigasi Vulnerability / Kerentanan Log4j2 terkait dengan Library nya sendiri ini bisa dilihat di. link

Sekarang kita mencoba melihat apa saja tindakan lain yang bisa dilakukan tanpa memodifikasi library nya Log4j2 .

Artinya kita mau melihat apa saja yang kita bisa lakukan untuk menambah pertahanan dari sisi aplikasi pendukung dan jaringan sekitar aplikasi kita yang memakai library Log4j2 ini.


Apa saja kemungkinannya ?

1. Setting konfigurasi RMI / LDAP untuk mencegah Remote Code Execution

Ancaman utama dari Log4j2 Vulnerability ini adalah RCE (Remote Code Execution), dimana peretas dengan hanya passing String "${jndi:ldap/rmi:xxxx}" akan bisa memicu dieksekusinya Malicious Code Java dari server lain yang sudah dipersiapkan oleh peretas.

Hal ini dimungkinkan karena fitur JNDI yaitu JNDI Remote Class Loading.

JNDI Remote Class Loading ini secara otomatis meload object dari RMI server dan menjalankannya ketika tipe object nya adalah Reference ke server lain.

JNDI Remote Class Loading ini bukan lagi di handle di library Log4j, tetapi di handle oleh library Java / JDK.

Oleh karenanya, agar RCE (Remote Code Execution) tidak terjadi, maka kita harus menonaktifkan fungsi ini di level JRE/JVM Javanya.

Konfigurasinya adalah sbb (agar tidak melakukan Remote Class Loading) :

  • com.sun.jndi.rmi.object.trustURLCodebase = false
  • com.sun.jndi.cosnaming.object.trustURLCodebase = false

Sejak Java versi 8u121 (https://www.oracle.com/java/technologies/javase/8u121-relnotes.html), maka secara otomatis telah mengakomodasi hal tersebut.

Akan tetapi kalau Anda mempunyai versi Java dibawah 8u121, maka harus disetting atau ditambahkan manual di file properties.


2. Menambahkan Web Application Firewall (WAF) di depan aplikasi kita untuk menfilter incoming request.

Web Application Firewall (WAF) adalah aplikasi firewall yang melindungi aplikasi web kita dari serangan berbagai macam cara umum peretas.

Ini bukanlah seperti Network Firewall yang berjalan di level Network (Level 3 OSI) yang menfilter berdasarkan data IP, host, port, akan tetapi WAF ini berada di Level Application (Level 7 OSI)..

WAF ini bisa mendeteksi lebih banyak dibandingkan hanya alamat IP, host, dan port, seperti isi payload HTTP, parameter HTTP Header, serangan DDoS, Rate Limiting, Filtering berdasarkan string tertentu, dll.

Dengan menambahkan WAF di depan server kita, maka peretas yang mencoba untuk menggunakan string ${jndi:xxxx} bisa diblok terlebih dahulu sebelum masuk ke server kita dan berkemungkinan memaksa library Log4j2 tadi untuk menjalankan Vulnerability nya.


3. Menambahkan whitelisting untuk akses keluar / Engress dari server kita keluar.

Kalau sebelumnya kita memakai Web Application Firewall (WAF) untuk melakukan blocking dari luar ke dalam,

Maka kita juga perlu menambahkan blocking akses dari dalam aplikasi kita ke server JNDI di luar.

Istilahnya kalau memang perlu dilakukan koneksi dari server kita ke server JNDI di luar, maka kita perlu menambahkan manual.

Akan tetapi, yang penting defaultnya adalah tidak ada yang bisa melakukan koneksi dari server kita ke server luar (Engress).


Kesimpulan

Demikian 3 cara mitigasi Log4j2 vulnerability ini, selain dari modifikasi langsung terkait dengan Log4j2 nya sendiri.

Kita akan lanjut dengan analisa Framework Java Umum apa saja yang mungkin terdampak.