FlawOpen

flawopen.com/Incidents/log4shell-jndi-injection-december-2021

● Apache Software Foundation · CVE-2021-44228 · December 2021 · CVSS 10.0 · Kritis
Riset Keamanan · FlawOpen

Log4Shell (CVE-2021-44228): penyebab dan perbaikan

CVE-2021-44228 membuat data log memicu lookup Log4j 2 dan pemuatan kelas melalui JNDI. Perbarui Log4j dan inventarisasi salinan tertanam.[1], [2], [4]

💡 Penjelasan Sederhana (ELI5)

Sebuah kantor punya juru tulis yang tugasnya hanya mencatat apa yang dikatakan tamu. Seseorang menemukan bahwa jika tamu mengucapkan kalimat tertentu, juru tulis berhenti menulis, pergi ke alamat yang disebut dalam kalimat itu, mengambil amplop tersegel dari orang asing, lalu mengikuti instruksi di dalamnya. Padahal juru tulis itu hanya seharusnya mencatat.[1]

Konsep Kunci & Istilah

Lookup pesan
Fitur Log4j 2 yang mengganti ekspresi ${...} di dalam pesan log dengan nilai saat pencatatan. Sebelum 2.15.0, fitur ini juga berlaku pada data di dalam pesan, bukan hanya pada pola yang dikonfigurasi.[1]
JNDI
Java Naming and Directory Interface, API untuk mencari objek di layanan direktori seperti LDAP. Lookup JNDI ke server jarak jauh bisa mengembalikan kelas untuk dimuat JVM.[1]
Injeksi ekspresi (CWE-917)
Data tak tepercaya mencapai pengevaluasi ekspresi, sehingga teks yang diberikan sebagai data dijalankan sebagai instruksi.[1]
Dependensi transitif
Pustaka yang ada di aplikasi Anda hanya karena pustaka lain membutuhkannya. Banyak paparan Log4Shell berasal dari salinan Log4j yang tidak pernah dicatat siapa pun.[4]
Daftar komponen perangkat lunak (SBOM)
Daftar yang dapat dibaca mesin berisi setiap komponen dan versi dalam sebuah build, sehingga pertanyaan "di mana kita menjalankan Log4j 2.14?" bisa cepat dijawab.[4], [3]

Pemetaan kerangka kerja

Kronologi Insiden

2021-11-24

Chen Zhaojun dari Alibaba Cloud Security melaporkan celah ini secara privat kepada Apache.[1]

2021-12-09

Celah menjadi publik; Log4j 2.15.0 dirilis dan pemindaian massal dimulai dalam hitungan jam.[1], [4]

2021-12-17

CISA mengeluarkan Emergency Directive 22-02 yang mewajibkan lembaga federal AS menemukan dan memitigasi Log4j.[3]

2021-12-28

Log4j 2.17.1 memperbaiki CVE-2021-44832, yang terakhir dari tiga CVE lanjutan setelah 2.15.0 (bersama CVE-2021-45046 dan CVE-2021-45105).[1]

Alur Serangan Langkah demi Langkah

Langkah 1

Teks penyerang mencapai panggilan log

Nilai apa pun yang dicatat aplikasi, seperti nama pengguna, header, atau kata pencarian, bisa membawa ekspresi lookup pilihan penyerang.[1]

Langkah 2

Log4j mengevaluasi ekspresi

Versi yang rentan memproses lookup di dalam data yang dicatat, sehingga ekspresi itu diselesaikan alih-alih ditulis sebagai teks.[1], [2]

Langkah 3

JNDI terhubung ke luar

Lookup JNDI membuat server terhubung ke layanan direktori yang disebut dalam ekspresi, sering kali di infrastruktur penyerang.[1], [4]

Langkah 4

Kode jarak jauh berjalan

Direktori jarak jauh dapat menunjukkan kepada JVM sebuah kelas untuk dimuat, yang kemudian berjalan dengan hak istimewa aplikasi. Di tempat koneksi keluar diblokir, langkah ini gagal.[1], [2]

Kode Sumber: Rentan vs Aman

Konfigurasi Maven ilustratif. Mengimpor log4j-bom membuat semua modul Log4j, termasuk salinan yang dibawa pustaka lain, diselesaikan ke satu versi terkini. Aturan enforcer lalu menggagalkan build jika masih ada log4j-core yang lebih lama dari 2.17.1 yang terjangkau, termasuk secara transitif, sehingga dependensi baru tidak bisa diam-diam membawa kembali kode yang rentan. Pembaruan adalah perbaikan sebenarnya; memblokir LDAP dan RMI keluar dari server aplikasi adalah pertahanan berlapis yang memutus eksploitasi bahkan di tempat patch terlambat.

IMPLEMENTASI RENTAN
<!-- pom.xml: a direct dependency pinned to a vulnerable release -->
<dependencies>
  <dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.14.1</version>
  </dependency>
</dependencies>
<!-- Nothing stops another library from pulling in an older log4j-core transitively. -->
PERBAIKAN AMAN & KUAT
<!-- pom.xml: one version for every Log4j module, and a build that fails on old ones -->
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-bom</artifactId>
      <version>2.24.3</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-enforcer-plugin</artifactId>
      <version>3.5.0</version>
      <executions>
        <execution>
          <id>ban-vulnerable-log4j</id>
          <goals><goal>enforce</goal></goals>
          <configuration>
            <rules>
              <bannedDependencies>
                <searchTransitive>true</searchTransitive>
                <excludes>
                  <exclude>org.apache.logging.log4j:log4j-core:[2.0-beta9,2.17.1)</exclude>
                </excludes>
              </bannedDependencies>
            </rules>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

Daftar Periksa Penguatan Sistem Rekayasa

Sumber